イベント通知機能提供システム
【課題】各アプリケーションで大量に発生するイベントを処理する。
【解決手段】アプリケーションを管理するサービス提供サーバから送信されたイベントの発生を受信する第１サーバと、第１サーバからの依頼に応じ、イベントの発生を記憶手段に登録する登録処理を行う第２サーバと、を備え、第１サーバは、サービス提供サーバから受信したイベントの発生の登録処理を第２サーバに依頼するとともに、第２サーバからの完了通知を受け取ることなく、イベントの発生の登録処理を行った旨のレスポンスをサービス提供サーバに対して送信する。
【解決手段】アプリケーションを管理するサービス提供サーバから送信されたイベントの発生を受信する第１サーバと、第１サーバからの依頼に応じ、イベントの発生を記憶手段に登録する登録処理を行う第２サーバと、を備え、第１サーバは、サービス提供サーバから受信したイベントの発生の登録処理を第２サーバに依頼するとともに、第２サーバからの完了通知を受け取ることなく、イベントの発生の登録処理を行った旨のレスポンスをサービス提供サーバに対して送信する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ウェブ上のアプリケーション間でイベントの発生を通知する技術に関する。
【背景技術】
【０００２】
近年、インターネットにおいては、例えばソーシャル・ネットワーキング・サービス（以下、ＳＮＳ）などのように、ユーザ個人が記事や写真や動画といったコンテンツを投稿し、他ユーザに公開することができる場を構築するアプリケーションをウェブ上で提供するサービスが普及している。
【０００３】
これらのサービスは、一般にＣＧＭ（Consumer Generated Media）とも呼ばれ、コンテンツを作成したユーザから他ユーザへの情報発信のツールとしてだけでなく、ユーザ間のコミュニケーションのツールとしても利用されている。たとえば、或るユーザが投稿した日記に対して、その日記を閲覧した他ユーザが個々にコメントを付記することで、その日記を媒介としてユーザ間で意見交換が行われる、というものである。
【０００４】
そして、最近、上記のようなサービスでは、或るコンテンツに対してユーザによりコメントが付記された場合に、そのコンテンツを投稿したユーザに対して、新着のコメントがあった旨を通知するようにしたものが提案されている（例えば、特許文献１を参照。）。このような通知は、そのときサービスの利用中であればクライアントのブラウザにより表示されているウェブページに差し込むことで行われる。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００７−３２８５３７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかし、上記のような従来のサービスでは、扱われるコンテンツの数は膨大であり、それに伴い、発生するイベントは大量となる。そのため、上記のようなサービスを提供するサーバは、大量に発生するイベントを処理するべく、そのような負荷に耐えうる仕組みを構築することが求められている。
【０００７】
そこで、本発明は、大量に発生するイベントを処理することが可能なサーバ構成を有するイベント通知機能提供システムを提供することを目的とする。
【課題を解決するための手段】
【０００８】
上記の課題を解決するため、本発明は以下のような態様を要旨とする。
【０００９】
（１） ウェブ上のアプリケーションで任意に定義されたイベントの発生を大量に処理するためのサーバ構成を有し、各アプリケーション間でイベントの発生を通知するイベント通知機能提供システムであって、
アプリケーションを管理するサービス提供サーバから送信されたイベントの発生を受信する第１サーバと、
前記第１サーバからの依頼に応じ、前記イベントの発生を記憶手段に登録する登録処理を行う第２サーバと、を備え、
前記第１サーバは、
前記サービス提供サーバから受信したイベントの発生の登録処理を前記第２サーバに依頼するとともに、前記第２サーバからの完了通知を受け取らずに前記イベントの発生を受信した後に、イベントの発生の登録処理を行った旨のレスポンスを前記サービス提供サーバに対して送信することを特徴とするイベント通知機能提供システム。
【００１０】
（１）によれば、第１サーバがサービスサーバから送信されるイベントの発生を受信すると、イベントの発生を受信した直後に、登録処理を行った旨のレスポンスをサービスサーバに返送し、その一方で、イベントの登録処理を第２サーバに依頼するようにした。したがって、サービスサーバとの間で、各アプリケーションで発生する大量のイベントを滞りなく処理することができる。
【００１１】
（２） 前記第１サーバは、
前記サービス提供サーバから送信されるイベント発生メッセージを、イベントの発生として受信し、
前記第２サーバは、
前記イベント発生メッセージから抽出した、ユーザ識別子、イベントが発生したアプリケーションの識別子、イベントが発生したコンテンツの識別子、発生したイベントの識別子及びイベントの内容を含むイベント情報を、ユーザ識別子に関連づけてデータベースに登録し、かつ、前記データベースに登録されているイベント情報から作成したサマリー情報をキャッシュに登録し、
前記第１サーバは、
前記サービス提供サーバからのリクエストに応じて、前記キャッシュに登録されているサマリー情報をサービス提供サーバに送信することを特徴とする（１）のイベント通知機能提供システム。
【００１２】
（２）によれば、イベントの登録処理については第２サーバがバックグラウンドで行う一方で、イベントの参照処理については第１サーバがキャッシュにアクセスすることで行う。これにより、第１サーバが、データベースに直接アクセスすることによる処理パフォーマンスの低下を防ぐことができ、大量に発生するイベントを処理するのに好適である。
【００１３】
（３） ウェブ上のアプリケーションで任意に定義されたイベントの発生を大量に処理し、各アプリケーション間でイベントの発生を通知するイベント通知機能提供システムの動作方法であって、
第１サーバが、アプリケーションを管理するサービス提供サーバから送信されたイベントの発生を受信する工程と、
第２サーバが、前記第１サーバからの依頼に応じ、前記イベントの発生を記憶手段に登録する登録処理を行う工程と、
第１サーバが、前記サービス提供サーバから受信したイベントの発生の登録処理を前記第２サーバに依頼するとともに、前記第２サーバからの完了通知を受け取らずに前記イベントの発生を受信した後に、イベントの発生の登録処理を行った旨のレスポンスを前記サービス提供サーバに対して送信する工程と、を含むことを特徴とするイベント通知機能提供システムの動作方法。
【００１４】
（３）によれば、（１）と同様の効果を奏する。
【発明の効果】
【００１５】
本発明によれば、各アプリケーションで大量に発生するイベントを処理することが可能となる。
【図面の簡単な説明】
【００１６】
【図１】実施形態にかかるシステム全体の構成例を示す図である。
【図２】実施形態にかかるイベント通知機能提供システムの構成例を示す図である。
【図３】イベントテーブルのデータ構造例を示す図である。
【図４】コンテンツテーブルのデータ構造例を示す図である。
【図５】キャッシュテーブルのデータ構造例を示す図である。
【図６】イベント定義データ共有リストのデータ構造例を示す図である。
【図７】実施形態の処理例を示すシーケンス図（イベント登録）である。
【図８】実施形態の処理例を示すシーケンス図（イベント参照：サマリー）である。
【図９】イベントの通知に関する画面例（サマリー）を示す図である。
【図１０】実施形態の処理例を示すシーケンス図（イベント参照：イベント一覧）である。
【図１１】イベントの通知に関する画面例（イベント一覧）を示す図である。
【図１２】実施形態の処理例を示すシーケンス図（イベント消去）である。
【図１３】イベント通知機能提供システムの第２サーバの詳細な構成例を示す図である。
【図１４】ｆａｒｍＩＤ対応付けテーブルのデータ構造例を示す図である。
【図１５】実施形態の処理例を示すシーケンス図（イベント登録）である。
【図１６】実施形態の処理例を示すフローチャート図（依頼先サーバ決定処理）である。
【発明を実施するための形態】
【００１７】
以下、図面を参照して、本発明を実施するための形態（以下、実施形態）について説明する。
【００１８】
＜構成＞
図１を参照して、本実施形態に係るイベント通知機能提供システム（ノーティスプラットフォーム）３を含むシステム全体の構成について説明する。
【００１９】
イベント通知機能提供システム３は、複数のサービス提供サーバ５（５ａ、…、５ｘ）とネットワークＮを介して接続されている。また、サービス提供サーバ５は、複数のユーザ端末７（７ａ、…、７ｘ）とネットワークを介して接続されている。
【００２０】
イベント通知機能提供システム３、サービス提供サーバ５及びユーザ端末７は、ＣＰＵ等の制御装置、メモリやＨＤＤ等の記憶装置、通信Ｉ／Ｆ等の通信装置といったハードウェア資源を有するコンピュータ（単一或いは複数）により構成される。ユーザ端末７は、ユーザが利用するＰＣ（Personal Computer）や携帯電話端末等であり、上記のようなハードウェア資源に加え、キーボタンやタッチパネル等の入力装置、液晶ディスプレイ等の出力装置を備える。
【００２１】
（ユーザ端末７）
ユーザ端末７は、一般的なブラウザを備えている。ブラウザは、インターネットの標準プロトコルであるＨＴＴＰ（Hyper Text Transfer Protocol）等に従い、ＨＴＭＬ（Hyper Text Markup Language）等の言語で記述されたページデータの要求、取得及び表示、フォームデータの送信等を行う機能を有している。ユーザは、ユーザ端末７のブラウザを通じて、サービス提供サーバ５により提供されるアプリケーションを利用する。
【００２２】
（サービス提供サーバ５）
複数のサービス提供サーバ５は、それぞれ個別のアプリケーション（以下、ＡＰ）をユーザ端末７に対して提供し、ウェブ上のサービスを実現する。ウェブ上のサービスの例は、ユーザが記事や写真や動画等といったコンテンツを閲覧したり、ユーザ白身がコンテンツを投稿して他のユーザに公開したり、商取引を行う場を提供するサービスであり、ニュースサービス、ＳＮＳ（ソーシャルネットワーキングサービス）、オークションサービス、地図情報サービス等が該当する。ＡＰは、ユーザ端末７に対して、コンテンツの投稿やコンテンツに対する何らかのアクションの入力や、コンテンツの検索、閲覧等をユーザが行うための各種機能を提供する。
【００２３】
本実施形態では、各ＡＰにおいて任意に定義されるものであって、ユーザに関わりのあるコンテンツをターゲットとした何らかのアクションを示す情報を「イベント」という。
【００２４】
例えば、オークションサービスであれば、一のユーザ（ユーザＡとする）が出品したアイテムに対して他のユーザ（ユーザＢやユーザＣとする）により入札が行われた場合、ユーザＡから見たユーザＢやユーザＣの入札行為を「イベント」と定義することができる。
【００２５】
また、別の例では、オークションサービスにおいて、一のユーザ（ユーザＢとする）が或るアイテムに対して入札を行い、その入札を行ったアイテムに対してさらに他のユーザ（ユーザＣとする）により入札が行われた場合、ユーザＢから見たユーザＣの入札行為を「イベント」と定義することができる。
【００２６】
また、別の例では、ＳＮＳにおいて、一のユーザ（ユーザＸとする）を他のユーザ（ユーザＹとする）が友だちに登録した場合、ユーザＸから見たユーザＹの登録行為を「イベント」と定義することができる。
【００２７】
さらに、別の例では、オークションサービスにおいて、一のユーザ（ユーザＺとする）の出品物が誰にも落札されないで終了した場合、ユーザＺから見た、その終了したという結果を「イベント」と定義することができる。この例でいうアクションは、ユーザが直接的に生じさせたものではないが、このようにＡＰの動作上で自動的に発生した出来事もアクションに含めることができる。
【００２８】
なお、本実施形態では、一のサービス提供サーバ５が一のＡＰを管理する構成について説明するが、本発明はこれに限らず、一のサービス提供サーバ５が複数のＡＰを管理する構成や、一のＡＰを複数のサービス提供サーバ５が管理する構成を採用することができる。
【００２９】
サービス提供サーバ５は、一のＡＰにつき、入力受付手段５１と、入力情報処理手段５２と、イベント送信手段５３と、イベント参照手段５４と、イベント受信手段５５と、ページデータ提供手段５６と、を備えている。
【００３０】
入力受付手段５１は、ユーザ端末７のブラウザから、マウスクリック、キーボード入力に基づいたユーザの各種リクエスト及び入力情報を受信する機能を有する。
【００３１】
入力情報処理手段５２は、入力受付手段５１が受信したユーザのリクエスト及び入力情報の内容に応じて、投稿されたコンテンツやコンテンツに対するアクションのデータベースヘの登録、検索、参照等の各種処理を行う機能を有する。また、入力情報処理手段５２は、コンテンツに対するアクションを登録する際に、イベントの定義付けをする。例えば、オークションサービスにおいて、ユーザの入力情報の内容が「出品物１への１つ目の入札」であった場合、出品物１の識別子（ｉｔｅｍ＿０００１）に、1つ目の入札を示す識別子（ｅｖｅｎｔ＿０００１）を割り当てる。
【００３２】
イベント送信手段５３は、入力情報処理手段５２がコンテンツに対するアクションをイベントとして定義した場合に、イベントの発生メッセージをイベント通知機能提供システム３に対して送信する機能を有する。
【００３３】
イベント参照手段５４は、入力受付手段５１が受信したユーザのリクエストに応じて、イベント通知機能提供システム３に対してイベントの参照リクエストを送信する機能を有する。
【００３４】
イベント受信手段５５は、イベント通知機能提供システム３から送信された、各ＡＰにおけるイベントの発生状況を受信する機能を有する。
【００３５】
ページデータ提供手段５６は、ページデータを作成し、ユーザ端末７のブラウザに対して送信する機能を有する。例えば、イベント受信手段５５が受信した、各ＡＰにおけるイベントの発生状況に基づいてページデータを作成し、ユーザ端末７のブラウザに対して送信し、ユーザに対してイベントの発生を通知する。
【００３６】
イベント送信手段５３、イベント参照手段５４及びイベント受信手段５５は、イベント通知機能提供システム３の管理者側から提供されたＡＰＩ（Application Program Interface）をＡＰに組み込むことで実現される機能である。各サービス提供サーバ５が管理するＡＰとイベント通知機能提供システム３との間の通信は任意の形式とすることができる。
【００３７】
（イベント通知機能提供システム３）
一方、イベント通知機能提供システム３は、複数のＡＰのそれぞれにおいて任意に定義されているイベントの発生を収集し、一括管理し、各ＡＰに対して通知する機能を有する。イベント通知機能提供システム３は、イベント受信手段３１と、イベント登録手段３２と、イベント読出手段３３と、イベント通知手段３４と、イベント消去手段３５と、イベント記憶手段３６と、を備えている。
【００３８】
イベント受信手段３１は、各ＡＰ（より詳しくはイベント送信手段５３）からそれぞれ送信されたイベントの発生メッセージを受信する。イベント登録手段３２は、イベント受信手段３１が受信した各ＡＰにおけるイベントの発生メッセージに基づいて、イベント記憶手段３６に対するイベントの登録処理を行う。
【００３９】
イベント記憶手段３６は、各ユーザに関するイベントの発生状況を記憶している。ユーザに関するイベントの発生状況とは、各ＡＰで発生したイベントをユーザ単位で分類し、時系列に従って蓄積したデータである。詳しいデータ構成は後述するが、イベント記憶手段３６は、イベントが発生したコンテンツ及びＡＰと、イベントの発生の通知対象となるユーザとを特定可能なデータを少なくとも記憶している。
【００４０】
イベント読出手段３３は、各ＡＰ（より詳しくはイベント参照手段５４）から送信されたイベントの参照リクエストに応じて、イベント記憶手段３６からイベントの発生状況を読み出す。なお、本実施形態でのイベントの読み出しは、いわゆるプル型の通知を行う場合のものであるが、プッシュ型の通知を行う場合など任意のタイミングを採用することができる。
【００４１】
イベント通知手段３４は、イベント読出手段３３が読み出したイベントの発生状況を、各ＡＰ（より詳しくはイベント受信手段５５）に対して送信する。イベント消去手段３５は、イベント通知手段３４が各ＡＰに対して送信したイベントの発生状況のうち、ユーザにより通知の確認が行われたイベントに関するレコードを、イベント記憶手段３６から消去する。
【００４２】
（イベント通知機能提供システム３のサーバ構成）
図１ではイベント通知機能提供システム３の機能的な構成について説明したが、以下では、図２を参照してハードウェア的な構成について説明する。図２は、本実施形態にかかるイベント通知機能提供システム３のサーバ構成を示す図である。
【００４３】
イベント通知機能提供システム３は、第１サーバ１１と、第２サーバ１２と、データベースサーバ（以下、ＤＢサーバ）１３と、キャッシュサーバ１４と、を備え、これらの各サーバ１１〜１４が相互に通信可能に接続されて構成されている。各サーバ１１〜１４間の通信は、任意の形式とすることができる。各サーバ１１〜１４は、ＣＰＵ等の制御装置、メモリやＨＤＤ等の記憶装置、通信Ｉ／Ｆ等の通信装置といったハードウェア資源を有するコンピュータにより構成される。
【００４４】
第１サーバ１１は、複数のサービス提供サーバ５のそれぞれにより管理されているＡＰとの窓口となる。つまり、第１サーバ１１は、各サービス提供サーバ５からのリクエストを受け付け、処理結果をレスポンスとして返送するフロントエンド部としての機能を有する。第２サーバ１２は、第１サーバ１１の依頼を受けてイベントの登録処理を行う機能を有する。ＤＢサーバ１３及びキャッシュサーバ１４は、各ＡＰにおいて発生したイベントを管理する。
【００４５】
ここで、図１との関係において、第１サーバ１１は、前述したイベント受信手段３１、イベント読出手段３３及びイベント通知手段３４として機能する。また、第２サーバ１２は、イベント登録手段３２及びイベント消去手段３５として機能する。さらに、ＤＢサーバ１３及びキャッシュサーバ１４は、イベント登録手段３２、イベント消去手段３５及びイベント記憶手段３６として機能する。
【００４６】
（イベントの登録処理）
ここで、本実施形態のイベント通知機能提供システム３は、各ＡＰにおいて発生する大量のイベントを処理するため、イベントの登録処理に関して以下のような処理を行うようにしている。
【００４７】
第１サーバ１１は、まず、サービス提供サーバ５からイベントの発生メッセージを受信すると、受信したイベントの登録処理を第２サーバ１２に対して依頼する。このとき、第１サーバ１１は、第２サーバ１２からの処理完了の通知を受け取ることなく、イベントの発生メッセージを受信した直後、イベントの登録処理を行った旨のレスポンスを受信元のサービス提供サーバ５に対して送信する。
【００４８】
一方で、第１サーバ１１から依頼を受けた第２サーバ１２は、イベントの登録処理をＤＢサーバ１３及びキャッシュサーバ１４に対して行う。
【００４９】
このようにして、イベントの登録処理を、各サービス提供サーバ５からのリクエストを直接受け付ける第１サーバ１１ではなく、第２サーバ１２がバックグラウンドで行うようにしたので、第１サーバ１１はイベントの発生メッセージを受信するとそのままサービス提供サーバ５に対してレスポンスを送信できるようになり、各ＡＰにおいて発生する大量のイベントを滞りなく処理することができるようになる。また、第１サーバ１１は、イベントの登録処理及び読出処理の両方を行うことによる処理負担から解放されるので、イベントの登録処理及び読出処理の双方に関するパフォーマンスを向上させることができる。
【００５０】
（ＤＢサーバ１３のデータ構成）
次に、図３及び図４を参照して、ＤＢサーバ１３が備えるデータ構造例について説明する。ＤＢサーバ１３は、イベントテーブル（図３）とコンテンツテーブル（図４）と、を備えている。
【００５１】
（イベントを個々に管理するイベントテーブル）
イベントテーブル（図３）は、各ＡＰにおいて発生したイベントに関する情報（以下、イベント情報）を記憶している。イベント情報は、「ユーザ識別子」、「サービス識別子」、「コンテンツ識別子」、「イベント識別子」、「イベント内容」及び「日時」の各データ項目を含んでいる。これらの各データ項目は、サービス提供サーバ５のＡＰにより任意に定義され、イベントの発生メッセージに含まれて送信されてくるものである。
【００５２】
「ユーザ識別子」は、イベントの発生を通知する対象ユーザを特定するためのデータである。例えば、オークションサービスであれば、入札がつけられた出品物の出品者が有するユーザＩＤである。
【００５３】
「サービス識別子」は、イベントが発生したＡＰを特定するデータである。例えば、識別子「ａｕｃ」であればオークションサービス、識別子「ｂｏａｒｄ」であれば掲示板サービス、という具合に特定される。
【００５４】
「コンテンツ識別子」は、イベントが発生したコンテンツを特定するデータである。例えば、オークションサービスを例にすると、識別子「ｉｔｅｍ」であれば「出品物」であり、識別子「ｉｔｅｍ＿０００１」であれば「出品物Ａ」という具合に特定される。
【００５５】
「イベント識別子」は、発生したイベントを特定するデータである。例えば、オークションサービスの出品物を例にすると、識別子「ｅｖｅｎｔ」であれば「入札」であり、識別子「ｅｖｅｎｔ＿０００１」であれば１つ目の「入札１」、という具合に特定される。
【００５６】
「イベント内容」は、発生したイベントについての付加情報を示すテキストデータである。例えば、イベントを発生させたユーザにより入力された情報の内容であり、オークションサービスであれば、「入札額」や「入札者のユーザＩＤ」などが記述されている。
【００５７】
「日時」は、イベントが発生した日時を特定するデータである。例えば、オークションサービスを例にすると、「入札が行われた日時」となる。
【００５８】
（イベントをコンテンツ単位で管理するコンテンツテーブル）
コンテンツテーブル（図４）は、発生したイベントをコンテンツ単位で集約した情報（以下、コンテンツ情報）を記憶している。コンテンツ情報は、「ユーザ識別子」、「サービス識別子」、「コンテンツ識別子」、「イベント数」、「イベント識別子」、「ＵＲＬ」及び「日時」の各データ項目を含んでいる。
【００５９】
「イベント数」は、コンテンツに対して発生したイベントの数を特定するデータである。前述のイベントテーブルに記憶されている各イベント情報を、「ユーザ識別子」、「サービス識別子」及び「コンテンツ識別子」の組をキーとして取りまとめ、その数をカウントしたものが記憶されている。「ＵＲＬ」は、各ＡＰで管理されているコンテンツのアドレスを特定するデータである。例えば、オークションサービスを例にすると、１個の出品物に対して新たに入札がついた件数となる。
【００６０】
本実施形態では、ＤＢサーバ１３は、イベント情報とコンテンツ情報をそれぞれ分けて管理していることから、それぞれを別のサーバファームとして構築するような場合に、それぞれのデータ量に応じて拡張が可能になり、スケーラビリティを確保することができる。
【００６１】
（イベントをＡＰ単位で管理するキャッシュテーブル）
次に、図５を参照して、キャッシュサーバ１４が備えるデータ構造例について説明する。キャッシュサーバ１４は、キャッシュテーブル（図５）を備えている。
【００６２】
キャッシュテーブル（図５）は、イベントが発生したコンテンツをＡＰ単位で集約した情報（以下、サマリー情報）を記憶している。サマリー情報は、「ユーザ識別子」、「サービス識別子」、「コンテンツ数」、「コンテンツ識別子」、「イベント識別子」、「ＵＲＬ」及び「日時」の各データ項目を含んでいる。
【００６３】
「コンテンツ数」は、イベントが発生したコンテンツの数を特定するデータである。前述のＤＢサーバ１３のコンテンツテーブルに記憶されているコンテンツ情報を、「ユーザ識別子」及び「サービス識別子」の組をキーとして取りまとめ、その数をカウントしたものが記憶されている。例えば、オークションサービスを例にすると、１０個の出品物を出品しているような場合に、そのうち新たに入札がついた出品物の個数となる。
【００６４】
また、サマリー情報には、コンテンツ数に含まれる個々のコンテンツに関するコンテンツ情報が関連付けて記憶されている。これにより、個々のコンテンツのＵＲＬや発生したイベントの数なども特定可能となる。
【００６５】
（各ＡＰにおける発生イベントの表示の共有）
次に、図６を参照して、イベント定義データ共有リストについて説明する。
【００６６】
イベント定義データ共有リストは、各ＡＰにおいて、他のＡＰで定義されているイベントを把握するために用いられるデータであり、各ＡＰに共通して提供される。また、ユーザ端末７のブラウザにより、他のＡＰにおけるサービス名、コンテンツ名及びイベント名を表示させる際に用いられる。
【００６７】
イベント定義データ共有リストは、各ＡＰにおいて任意に定義されている「サービス識別子」、「コンテンツ識別子」及び「イベント識別子」の一覧に応じて、それぞれを表示する名称が関連付けられている。例えば、サービス識別子「ａｕｃ」に対して「オークション」サービス、コンテンツ識別子「ｉｔｅｍ」に対して「出品物」が関連付けられている。
【００６８】
イベント通知機能提供システム３は、各ＡＰに対して、他のＡＰに関するイベントの発生を通知するとき、前述のサマリー情報等とともに、イベント定義データ共有リストを提供する。これにより、各ＡＰでは、他のＡＰにおいて定義されているコンテンツやイベントを共有することができ、また、イベントの通知を行う際に各ＡＰで共通の表示を行うことができる。
【００６９】
ここで、「サービス識別子」、「コンテンツ識別子」及び「イベント識別子」は、サービス提供サーバ５の運営者により各ＡＰで任意に定義された識別子が設定される。
【００７０】
識別子の設定を行うに際して、イベント通知機能提供システム３は、サービス提供サーバ５に接続された運営者端末（図示せず）のブラウザに設定用ページデータを送信する。サービス提供サーバ５の運営者は、ブラウザに表示された設定用ページを介して、ＡＰ内で任意に定義する識別子を登録し、イベント通知機能提供システム３に対して送信する。
【００７１】
例えば、ＡＰにより提供されるウェブ上のサービスがオークションサービスである場合、運営者は、サービス識別子として「ａｕｃ」を、表示名のテキストとして「オークション」を登録する。また、コンテンツ識別子として「ｉｔｅｍ」を、表示名のテキストとして「出品物」を登録する。さらに、イベント識別子として「ｅｖｅｎｔ」を、表示名のテキストとして「入札」を登録する。
【００７２】
なお、上記設定用ページでは、各ＡＰで任意に定義する識別子の登録のほか、イベントの発生通知を行うページのレイアウト（後述の図９及び図１１を参照）のカスタマイズや、イベントの発生の通知のパターン（後述のＡＰ単位、コンテンツ単位、イベント一覧など）、通知の確認が終了したイベントの消去のタイミングなどを任意に設定できるようにしてもよい。この場合、イベント通知機能提供システム３は、イベントの発生の通知のパターンや消去のタイミングなどの設定情報を、サービス識別子に関連付けて管理し、各ＡＰに応じた処理を行う。
【００７３】
＜動作＞
次に、本実施形態のイベント通知機能提供システム３の動作について説明する。
【００７４】
（イベントの登録）
図７は、本実施形態の処理例を示すシーケンス図であり、サービス提供サーバ５のＡＰから送信されたイベントの発生を、ＤＢサーバ１３及びキャッシュサーバ１４に格納するまでの処理例である。
【００７５】
ユーザ端末７のユーザが、ブラウザからサービス提供サーバ５のＡＰにより提供されるサービスのページを閲覧したい場合、ブラウザからサービス提供サーバ５のＡＰに対してページリクエストを送信する（ステップＳ１１）。例えば、オークションサービスを例にすると、出品物を閲覧するためのページのリクエストである。このリクエストは、ブラウザにおいて、対象コンテンツのＵＲＬを入力するか、他のページに張られたリンクを指定すること等により行われる。
【００７６】
なお、ログイン済みであるかどうかの確認は、例えばセッションＩＤ等を示すクッキーを読み込むことで行う。未だログインされていないものとすると、サービス提供サーバ５は、ユーザ端末７のブラウザにログインページを送信し、ユーザＩＤとパスワードの入力を受け付け、ユーザデータベースに登録されているか否かの照合を行い、ログイン処理を行う。
【００７７】
サービス提供サーバ５は、予め保持されたページデータを取得するか、動的にページデータを作成するかにより、ブラウザに提供するページデータを作成する（ステップＳ１２）。この際、ＡＰが提供するコンテンツと、コンテンツに対して何らかのアクションを入力するための画面領域をページデータに含める。
【００７８】
続いて、サービス提供サーバ５は、作成したページデータをユーザ端末７に対して送信する（ステップＳ１３）。ページデータはＨＴＴＰのレスポンス等に従ってブラウザに送信される。ユーザ端末７は、受信したページデータに基づいてブラウザにページ画面を表示する（ステップＳ１４）。例えば、オークションサービスを例にすると、出品物とともに「入札」及び「入札額」を指定する画面領域が表示されており、その領域に対して入力を行うことで入札を行うことができるようになる。
【００７９】
続いて、ユーザ端末７のユーザが、ページ画面のコンテンツに対するアクションとして所望の内容を入力すると、ブラウザからサービス提供サーバ５のＡＰに対して、入力されたアクションの内容が送信される（ステップＳ１０１）。
【００８０】
サービス提供サーバ５は、受信したアクションの内容をデータベースに登録し、その際、イベントの定義付けを行う（ステップＳ１０２）。すなわち、新たに発行した「イベント識別子（例えば、入札１）」やユーザによる入力情報の内容を示す「イベント内容（例えば入札額）」を、「コンテンツ識別子（例えば出品物Ａ）」、イベントの通知対象となる「ユーザ識別子（例えば、入札がついた出品物Ａの出品者）」、「ＵＲＬ」等とともにデータベースに登録する。
【００８１】
続いて、サービス提供サーバ５は、イベントの発生メッセージをイベント通知機能提供システム３の第１サーバ１１に対して送信する（ステップＳ１０３）。イベントの発生メッセージには、イベントの通知対象となる「ユーザ識別子」、「サービス識別子」、「コンテンツ識別子」、「イベント識別子」、コンテンツの「ＵＲＬ」、「イベント内容」及び「日時」が含まれている。
【００８２】
第１サーバ１１は、サービス提供サーバ５からイベントの発生メッセージを受信すると、その登録処理を第２サーバ１２に依頼するリクエストと共に、第２サーバ１２に送信する（ステップＳ１０４）。続いて、第１サーバ１１は、受信したイベントの発生メッセージについて処理完了のレスポンスを受信元のサービス提供サーバ５に対して送信する（ステップＳ１０５）。なお、第１サーバ１１は、第２サーバ１２への依頼を行う前にサービス提供サーバ５に対するレスポンスを行うようにしても良い。
【００８３】
つまり、第１サーバ１１は、第２サーバ１２による登録処理の完了を待たず、イベントの発生メッセージを受信した後、直ちに、処理完了のレスポンスを返送することになる。
【００８４】
一方、第１サーバ１１から登録処理を依頼された第２サーバ１２は、まず、ＤＢサーバ１３に対してイベント登録リクエストを送信する（ステップＳ１０６）。これを受けたＤＢサーバ１３は、まず、発生メッセージからイベント情報を抽出し、イベントテーブル（図３）に登録する。続いて、ＤＢサーバ１３は、イベントテーブルからコンテンツ情報を生成し、コンテンツテーブル（図４）に登録する（ステップＳ１０７）。各テーブルの参照や更新には、ＳＱＬ（Structured Query Language）等のコマンドが用いられる。
【００８５】
より具体的には、ＤＢサーバ１３は、第１サーバ１１が受信したイベントの発生メッセージから、イベントの通知対象となる「ユーザ識別子」、「サービス識別子」、「コンテンツ識別子」、「イベント識別子」、「イベント内容」及び「日時」の組を抽出し、イベント情報として、イベントテーブルの新たなレコードに設定する。
【００８６】
また、ＤＢサーバ１３は、イベント情報の登録が完了すると、イベントテーブルに記憶されている各イベント情報を、「ユーザ識別子」、「サービス識別子」及び「コンテンツ識別子」の組をキーとして取りまとめ、そのレコード数を「イベント数」としてカウントする。そして、「ユーザ識別子」、「サービス識別子」、「コンテンツ識別子」、「イベント数」、「イベント識別子」、「ＵＲＬ」及び「日時」の組を抽出し、コンテンツ情報として、コンテンツテーブルの新たなレコードに設定する。
【００８７】
ＤＢサーバ１３は、イベントテーブル（図３）及びコンテンツテーブル（図４）への登録を完了すると、その旨の通知を第２サーバ１２に対して送信する（ステップＳ１０８）。
【００８８】
次に、第２サーバ１２は、ＤＢサーバ１３に対してサマリー作成リクエストを送信する（ステップＳ１０９）。これを受けたＤＢサーバ１３は、サマリー情報を作成し（ステップＳ１１０）、第２サーバ１２に対して送信する（ステップＳ１１１）。
【００８９】
より具体的には、ＤＢサーバ１３は、コンテンツテーブル（図４）において新たなレコードとして登録されたコンテンツ情報を、「ユーザ識別子」及び「サービス識別子」の組をキーとして取りまとめ、そのレコード数を「コンテンツ数」としてカウントする。そして、「ユーザ識別子」、「サービス識別子」、「コンテンツ数」、「コンテンツ識別子」、「イベント識別子」、取りまとめたコンテンツのうち最新のイベントが発生したコンテンツの「ＵＲＬ」、最新のイベントの「イベント内容」及び「日時」からなる項目の組合せをサマリー情報とし、これに個々のコンテンツ情報を紐づける。
【００９０】
第２サーバ１２は、ＤＢサーバ１３からサマリー情報を受信すると、キャッシュサーバ１４に対して、サマリー登録リクエストを送信する（ステップＳ１１２）。これを受けたキャッシュサーバ１４は、サマリー情報をキャッシュテーブル（図５）の新たなレコードに設定し、登録を行う（ステップＳ１１３）。なお、サマリー登録リクエストは、ＤＢサーバ１３からキャッシュサーバ１４に対して行われるようにしても良い。
【００９１】
キャッシュサーバ１４は、サマリー情報の登録を完了すると、その旨の通知を第２サーバ１２に対して送信する（ステップＳ１１４）。第２サーバ１２は、イベントの登録完了の通知を第１サーバ１１に対して送信する（ステップＳ１１５）。
【００９２】
これを受けた第１サーバ１１は、更新通知を要求するＡＰが予め設定されている場合には、その対象となるＡＰに対して更新通知を送信する（ステップＳ１１６）。
【００９３】
（イベントの参照）
図８及び図１０は、本実施形態の処理例を示すシーケンス図であり、サービス提供サーバ５のＡＰがイベントの参照リクエストを送信してから、そのＡＰに対してイベントが通知されるまでの処理例である。
【００９４】
（イベントの参照：サマリー一覧）
まず、図８を参照して、サマリー一覧を指定したイベントの参照リクエストを行った場合の処理例について説明する。
【００９５】
図８において、ユーザ端末７のユーザがブラウザからサービス提供サーバ５のＡＰにより提供されるサービスのページを閲覧したい場合、ブラウザからサービス提供サーバ５のＡＰに対してページリクエストを送信する（ステップＳ２０１）。例えば、ショッピングサービスを例にすると、商品を検索・閲覧するためのページのリクエストである。このリクエストは、ブラウザにおいて、対象コンテンツのＵＲＬを入力するか、他のページに張られたリンクを指定すること等により行われる。
【００９６】
サービス提供サーバ５は、ユーザ端末７のブラウザからＡＰに対するページリクエストを受信すると、第１サーバ１１に対して、イベント参照リクエスト「サマリー一覧」を送信する（ステップＳ２０２）。イベント参照リクエストには、当該リクエストを行ったユーザのユーザ識別子が含まれている。
【００９７】
イベント参照リクエストを受信した第１サーバ１１は、イベント参照リクエスト「サマリー一覧」をキャッシュサーバ１４に対して送信する（ステップＳ２０３）。
【００９８】
イベント参照リクエストを受信したキャッシュサーバ１４は、リクエストを行った「ユーザ識別子」をキーとしてキャッシュテーブル（図５）を参照し、対象となるサマリー情報を検索する（ステップＳ２０４）。
【００９９】
（キャッシュヒットありの場合）
ステップＳ２０４での検索の結果、サマリー情報がヒットした場合、キャッシュサーバ１４は、サマリー情報を取得し、第１サーバ１１に対して送信する（ステップＳ２０５）。
【０１００】
サマリー情報を受信した第１サーバ１１は、サマリー情報をサービス提供サーバ５に対して送信する（ステップＳ２０６）。
【０１０１】
サマリー情報を受信したサービス提供サーバ５は、サマリー情報に基づいてページデータを作成し（ステップＳ２０７）、ページリクエストのあったユーザ端末７のブラウザに送信する（ステップＳ２０８）。
【０１０２】
ページデータを受信したユーザ端末７のブラウザはページ画面を表示する（ステップＳ２０９）。図９は、ブラウザのページ画面７０の例を示している。ページ画面７０には、イベント通知領域７１が表示されており、その領域内において、サマリー情報に基づいて作成されたＡＰ単位通知領域７２及びコンテンツ単位通知領域７３が表示されている。
【０１０３】
ＡＰ単位通知領域７２には、ユーザに閲するイベントの発生をＡＰ単位で通知するメッセージが表示される。例えば、「オークションにおいて２つの出品物に入札があります」、「掲示板において１件のトピックに対して新着コメントがあります」といったメッセージが表示され、イベントが発生したＡＰ名とそのＡＰにおいてイベントが発生したコンテンツの数がユーザに通知される。
【０１０４】
一方、コンテンツ単位通知領域７３には、ユーザに関するイベントの発生をコンテンツ単位で通知するメッセージが表示される。例えば、「オークションの出品物Ａに２件の入札があります」、「オークションの出品物Ｂに１件の入札があります」というように、イベントが発生したＡＰ名及びコンテンツ名とそのコンテンツに対して発生したイベントの数をユーザに通知するメッセージが表示される。
【０１０５】
また、ＡＰ単位通知領域７２には、ＡＰ毎に、最新のイベントが発生したコンテンツへのリンク先ＵＲＬが埋め込まれる。一方、コンテンツ単位通知領域７３には、コンテンツ毎に、そのコンテンツへのリンク先ＵＲＬが埋め込まれる。
【０１０６】
リンク先ＵＲＬは、ＵＲＬの文字列を表示するか、或いは、通知メッセージの表示に紐付けるなどし、それらの表示をクリッカブルとすることにより、リンク先ＵＲＬが示すウェブページへの遷移をユーザに指定させる。
【０１０７】
これにより、イベントの発生通知を受けたユーザは、上記リンク先ＵＲＬを介して、イベントが発生したコンテンツのウェブページをブラウザに表示させ、発生したイベントを実際に確認することができる。
【０１０８】
（キャッシュヒットなしの場合） ところで、本実施形態では、イベントの登録処理とイベントの読出処理との間は非同期で行われるため、イベント参照時にサマリー情報が末作成である場合も起こりうる。以下の処理は、この場合における処理例である。
【０１０９】
ステップＳ２０４での検索の結果、サマリー情報がヒットしなかった場合、キャッシュサーバ１４は、サマリー情報の取得に失敗した旨の通知を、第１サーバ１１に対して送信する（ステップＳ２１０）。
【０１１０】
通知を受信した第１サーバ１１は、イベント参照リクエスト「サマリー一覧」をＤＢサーバ１３に対して送信する（ステップＳ２１１）。
【０１１１】
イベント参照リクエストを受信したＤＢサーバ１３は、リクエストを行った「ユーザ識別子」をキーとしてコンテンツテーブル（図４）を参照し、サマリー情報を作成して（ステップＳ２１２）、第１サーバ１１に対して送信する（ステップＳ２１３）。
【０１１２】
より具体的には、ＤＢサーバ１３は、コンテンツテーブル（図４）において新たなレコードとして登録されたコンテンツ情報を、リクエストを行った「ユーザ識別子」をキーに抽出する。そして、これらを「サービス識別子」をキーとして「サービス識別子」単位で取りまとめ、そのレコード数を「コンテンツ数」としてカウントする。そして、「ユーザ識別子」、「サービス識別子」、「コンテンツ数」、「コンテンツ識別子」、「イベント識別子」、取りまとめたコンテンツのうち最新のイベントが発生したコンテンツの「ＵＲＬ」、最新のイベントの「テキスト」及び「日時」からなる組をサマリー情報とし、これに個々のコンテンツ情報を紐づける。
【０１１３】
サマリー情報を受信した第１サーバ１１は、サマリー情報をサービス提供サーバ５に対して送信する（ステップＳ２１４）。
【０１１４】
サマリー情報を受信したサービス提供サーバ５は、サマリー情報に基づいてページデータを作成し（ステップＳ２１５）、ページリクエストのあったユーザ端末７のブラウザに送信する（ステップＳ２１６）。ベージデータを受信したユーザ端末７のブラウザはページ画面（図９参照）を表示する（ステップＳ２１７）。
【０１１５】
また、第１サーバ１１は、キャッシュサーバ１４に対して、サマリー登録リクエストを送信する（ステップＳ２１８）。これを受けたキャッシュサーバ１４は、サマリー情報をキャッシュテーブル（図５）の新たなレコードに設定し、登録を行う（ステップＳ２１９）。これにより次回以降の参照時にはキャッシュサーバ１４にアクセスすればよい。
【０１１６】
（イベントの参照：イベント一覧）
次に、図１０を参照して、イベント一覧を指定したイベントの参照リクエストを行った場合の処理例について説明する。
【０１１７】
図１０において、ユーザ端末７のユーザがブラウザからサービス提供サーバ５のＡＰにより提供されるサービスのページを閲覧したい場合、ブラウザからサービス提供サーバ５のＡＰに対してページリクエストを送信する（ステップＳ３０１）。例えば、ニュースサービスを例にすると、ニュース記事を閲覧するためのページのリクエストである。
【０１１８】
サービス提供サーバ５は、ユーザ端末７のブラウザからＡＰに対するページリクエストを受信すると、第１サーバ１１に対して、イベントの参照リクエスト「イベント一覧」を送信する（ステップＳ３０２）。イベントの参照リクエストには、送信元のサービス識別子や、当該リクエストを行ったユーザのユーザ識別子（例えばユーザＩＤ）が含まれている。
【０１１９】
イベントの参照リクエストを受信した第１サーバ１１は、イベントの参照リクエストをＤＢサーバ１３に対して送信する（ステップＳ３０３）。イベントの参照リクエストを受信したＤＢサーバ１３は、リクエストを行った「ユーザ識別子」をキーとしてイベントテーブル（図３）を参照し、対象となるイベント情報をサービス識別子ごとに取りまとめ、一覧として取得する（ステップＳ３０４）。ＤＢサーバ１３は、取得したイベント情報の一覧を第１サーバ１１に対して送信する（ステップＳ３０５）。
【０１２０】
イベント情報の一覧を受信した第１サーバ１１は、イベント情報の一覧をサービス提供サーバ５に対して送信する（ステップＳ３０６）。イベント情報の一覧を受信したサービス提供サーバ５は、イベント情報の一覧に基づいてページデータを作成し（ステップＳ３０７）、ページリクエストのあったユーザ端末７のブラウザに送信する（ステッブＳ３０８）。
【０１２１】
ページデータを受信したユーザ端末７のブラウザはページ画面を表示する（ステップＳ３０９）。図１１は、ブラウザのページ画面７０の例を示している。ページ画面７０には、イベント通知領域７１が表示されており、その領域内において、イベント情報の一覧に基づいて作成されたイベント一覧通知領域７４が表示されている。
【０１２２】
イベント一覧通知領域７４には、リクエストを行ったユーザに対するイベントの発生をイベント単位で（つまり、個々のイベントを詳細に）通知するメッセージが表示される。例えば、「オークションの出品物Ａに対する入札は以下です」とし、「入札１：詳細（時間／入札者／入札額）」、「入札２：詳細（時間／入札者／入札額）」といったメッセージが表示され、発生したイベントが個別に通知される。
【０１２３】
（イベントの消去）
図１２は、本実施形態の処理例を示すシーケンス図であり、サービス提供サーバ５のＡＰがイベントの消去リクエストを送信してから、ＤＢサーバ１３及びキャッシュサーバ１４により対象のイベントが消去されるまでの処理例である。
【０１２４】
図１２において、サービス提供サーバ５は、前述したように、ユーザ端末７に対してページデータを送信し（ステップＳ２１）、ブラウザに表示させる（ステップＳ２２）ことで、イベントの通知を行う（図８及び図１０）。その後、ユーザ端末７において、イベントが発生したコンテンツのリンク先ＵＲＬがユーザにより指定（クリック）されると（ステップＳ２３）、リンク先ＵＲＬが示すウェブページのページリクエストがサービス提供サーバ５に対して送信される（ステップＳ２４）。
【０１２５】
これを受けたサービス提供サーバ５は、そのページリクエストを処理する（ステップＳ２５）。例えば、他のサービス提供サーバ５で管理されるＡＰ内のコンテンツであれば、そのページリクエストを他のサービス提供サーバ５に受け渡す。
【０１２６】
続いて、サービス提供サーバ５は、発生したイベントをユーザが確認したものとし、イベント通知機能提供システム３の第１サーバ１１に対して、イベントの消去メッセージを送信する（ステップＳ４０１）。イベントの消去メッセージには、消去を行う対象の「ユーザ識別子」、「サービス識別子」及び「コンテンツ識別子」が含まれている。
【０１２７】
第１サーバ１１は、サービス提供サーバ５からイベントの消去メッセージを受信すると、その消去処理を第２サーバ１２に依頼するリクエストと共に、第２サーバ１２に送信する（ステップＳ４０２）。続いて、第１サーバ１１は、消去メッセージについて処理完了のレスポンスを受信元のサービス提供サーバ５に対して送信する（ステップＳ４０３）。
【０１２８】
一方、第１サーバ１１から消去処理を依頼された第２サーバ１２は、まず、ＤＢサーバ１３に対してイベント消去リクエストを送信する（ステップＳ４０４）。これを受けたＤＢサーバ１３は、まず、イベントテーブル（図３）から、消去対象の「ユーザ識別子」、「サービス識別子」及び「コンテンツ識別子」をキーとしてイベント情報を消去する（ステップＳ４０５）。
【０１２９】
また、ＤＢサーバ１３は、該当するイベント情報を消去した後のイベントテーブルからコンテンツ情報を抽出し、コンテンツテーブル（図４）に登録する。これは、消去後のイベント情報をコンテンツ情報に反映するためである。
【０１３０】
ＤＢサーバ１３は、消去を完了すると、その旨の通知を第２サーバ１２に対して送信する（ステップＳ４０６）。次に、第２サーバ１２は、ＤＢサーバ１３に対してサマリー作成リクエストを送信する（ステップＳ４０７）。これは、消去後のイベント情報をサマリー情報に反映するためである。これを受けたＤＢサーバ１３は、サマリー情報を作成し（ステップＳ４０８）、第２サーバ１２に対して送信する（ステップＳ４０９）。
【０１３１】
第２サーバ１２は、ＤＢサーバ１３からサマリー情報を受信すると、キャッシュサーバ１４に対して、サマリー登録リクエストを送信する（ステップＳ４１０）。これを受けたキャッシュサーバ１４は、サマリー情報をキャッシュテーブル（図５）の新たなレコードに設定し、登録を行う（ステップＳ４１１）。
【０１３２】
キャッシュサーバ１４は、サマリー情報の登録を完了すると、その旨の通知を第２サーバ１２に対して送信する（ステップＳ４１２）。第２サーバ１２は、完了の通知を第１サーバ１１に対して送信する（ステップＳ４１３）。
【０１３３】
これを受けた第１サーバ１１は、更新通知を要求するＡＰが予め設定されている場合には、そのＡＰに対して更新通知を送信する（ステップＳ４１４）。
【０１３４】
なお、前述の処理例では、ユーザによりリンク先ＵＲＬが指定されたことをトリガーとして、イベントの消去を行うようにしたが、これに限られるものではなく、例えば、サマリー情報やイベント情報に基づいて作成したページデータをユーザ端末７に対して送信したことをトリガーとして、イベントの消去を行うようにすることもできる。
【０１３５】
（第２サーバ１２の詳細な構成）
以下では、図１３〜図１６を参照し、前述した第２サーバ１２の詳細な構成及び動作について説明する。
【０１３６】
図１３は、第２サーバ１２の詳細構成を示す。第２サーバ１２は、複数のサーバ１２（１２ａ、…、１２ｘ）を組み合わせたサーバファームとして構築されている。すなわち、第２サーバ１２は、第１サーバ１１からの依頼に応じたイベントの更新系処理（登録処理及び消去処理）を、負荷分散により行うべく集積された複数のサーバ群である。
【０１３７】
第２サーバ１２は、２台のサーバを組み合わせたグループ（以下、小ファーム）を複数設けることで構成される。サーバファーム全体を構成する個々のサーバには、それぞれを特定するための識別子（以下、ｆａｒｍＩＤ）が割り当てられる。例えば、サーバファーム全体で２Ｎ台のサーバが設けられる場合、ｆａｒｍＩＤとして、「０」から「（Ｎ−１）＋Ｎ」までの数値を識別子として各サーバに割り当てることができる（図１３参照）。
【０１３８】
第１サーバ１１は、イベントの登録依頼を、上記ｆａｒｍＩＤを指定することにより行う。第１サーバ１１により指定されたサーバは、ＤＢサーバ１３及びキャッシュサーバ１４に対してイベントの登録処理を行う。
【０１３９】
図１４は、ｆａｒｍＩＤ対応付けテーブルを示す。ｆａｒｍＩＤ対応付けテーブルは、複数のサーバ間で互いに対となって小ファームを構成する２台のサーバの組合せが予め定められているテーブルである。小ファームを構成する２台のサーバは、サーバの障害発生時に相互に補い合う関係にある。
【０１４０】
つまり、一方のサーバがダウンすると、そのサーバに対して割り振られていたイベント登録依頼が、同じ小ファーム内の（正常に稼働中の）他方のサーバに対して割り振られる。
【０１４１】
ｆａｒｍＩＤ対応付けテーブルは、第１サーバ１１の記憶部（メモリなど）に記憶されている。つまり、第１サーバ１１は、ｆａｒｍＩＤを指定してイベント登録依頼を行う予定のサーバがダウンしているとき、ｆａｒｍＩＤ対応付けテーブルを参照する。そして、そのｆａｒｍＩＤ（例えば、図示の「ｆａｒｍ_０」）に対応づけられた他方のｆａｒｍＩＤ（例えば、図示の「ｆａｒｍ_（Ｎ−１）＋１」）を読み出し、読み出したｆａｒｍＩＤを指定して他方のサーバに対してイベント登録依頼を行う。
【０１４２】
図１５は、本実施形態の処理例を示すシーケンス図であり、サービス提供サーバ５のＡＰから送信されたイベントの発生を、ＤＢサーバ１３及びキャッシュサーバ１４に格納するまでの処理例である。基本的には、図７に示すシーケンス図と同様であるため、同様の内容（図７と同一の符号で示された処理など）については説明を省略する。
【０１４３】
図１５において、第１サーバ１１は、ステップＳ１０３においてサービス提供サーバ５から送信されたイベントの発生メッセージを受信すると、依頼先サーバ決定処理を行う（ステップＳ５０１）。依頼先サーバ決定処理では、前述の第２サーバ１２のサーバファームのうち、イベントの登録処理を依頼するサーバ（以下、依頼先サーバ）を決定する処理を行う。本処理については、後で図１６を参照して説明する。
【０１４４】
第１サーバ１１は、依頼先サーバ決定処理により決定した依頼先サーバに対して、イベントの登録処理を依頼するリクエストと共に、サービス提供サーバ５から受信したイベントの発生メッセージを送信する（ステップＳ１０４）。これを受けた依頼先サーバは、ＤＢサーバ１３に対してイベント登録リクエストを送信する（ステップＳ１０６）。
【０１４５】
図１６は、前述の依頼先サーバ決定処理の処理例を示すフローチャート図である。
【０１４６】
まず、第１サーバ１１は、イベントの発生メッセージに含まれる「ユーザ識別子」を取得し、その取得した「ユーザ識別子」を数値化情報（＝ｋ）に変換する（ステップＳ５１１）。
【０１４７】
「ユーザ識別子」が、英数字の組合せで構成されるユーザＩＤである場合、第１サーバ１１は、ユーザＩＤに含まれる文字（英字や記号）部分を数値に変換することで、ユーザＩＤ全体を数値化することができる。文字の数値化には、英字（Ａ〜Ｚ）や記号（−、／）などの文字に一意の数字が予め対応づけられたデータ（例えば、ＡＳＣＩＩ文字コード）を用いて行うことができる。例えば、ＡＳＣＩＩコードでは、英字「Ａ〜Ｚ」が数値「６５〜９０」に対応付けられており、ユーザＩＤが「ＡＺ１１１１」だとすると、数値化情報として「６５９０１１１１」を得ることができる。また、得られた数字列をいくつかに分け、それらを加えたものを数値化情報とすることもできる（例えば、６５＋９０＋１１＋１１＝１７７）。
【０１４８】
次に、第１サーバ１１は、第２サーバ１２のサーバファームを構成する全てのサーバ数（＝ｎ）を取得する（ステップＳ５１２）。続いて、第１サーバ１１は、演算式「Ｒｅｓｕｌｔ＝ｋ ｍｏｄ ｎ」を実行する（ステップＳ５１３）。つまり、第１サーバ１１は、「ユーザ識別子」の数値化情報（＝ｋ）を、サーバファームの全サーバ数（＝ｎ）で除算し、その余りを演算結果として出力する。たとえば、「ユーザ識別子」の数値化情報（＝ｋ）が「１７７」であり、全サーバ数（＝ｎ）が「６」とすると、「１７７」が「６」で除算されて剰余値「３」が算出される。
【０１４９】
次に、第１サーバ１１は、演算結果をｆａｒｍＩＤとして取得する（ステップＳ５１４）。続いて、第１サーバ１１は、取得したｆａｒｍＩＤに該当するサーバが正常に稼働しているかどうかを判別する（ステップＳ５１５）。
【０１５０】
第１サーバ１１は、取得したｆａｒｍＩＤに該当するサーバが正常に稼働していると判別した場合、取得したｆａｒｍＩＤに該当するサーバを依頼先サーバとして決定する（ステップＳ５１７）。
【０１５１】
一方、第１サーバ１１は、取得したｆａｒｍＩＤに該当するサーバが正常に稼働していない（サーバダウンである）と判別した場合、ｆａｒｍＩＤ対応付けテーブル（図１４）を参照し、そのｆａｒｍＩＤに対応づけられた他方のｆａｒｍＩＤを取得する（ステップＳ５１６）。そして、取得したｆａｒｍＩＤに該当するサーバを依頼先サーバとして決定する（ステップＳ５１７）。
【０１５２】
このように、１人のユーザに関するイベントの発生の処理は１つの固有のサーバにより行われ、かつ、その固有のサーバには障害時に切り替えられるサーバが割り当てられているので、１人のユーザに関するイベントの発生の処理が複数のサーバに跨って振り分けられることはなく、個々のユーザに関するイベントの発生順序を確保することができる。
【０１５３】
また、個々のユーザに関するイベントの発生を処理するサーバを、ユーザ識別子から一意に、かつ動的に決定することができるようにしたので、スケールアウトの際にも容易に対処できるようになり、スケーラビリティの確保につながる。
【０１５４】
なお、前述の依頼先サーバの決定処理は一例であるから、その具体的な内容は、「各ユーザに固有の識別子を用いてそのユーザに関するイベントの登録処理を担当するサーバを一意に決定する」という目的を逸脱しない範囲で任意に変更可能である。例えば、端末ＩＤなど、ユーザＩＤとは異なるユーザ識別子を用いる場合や、所定の関数を用いるなど、前述の数値化手法とは異なる手法を採用することができる。
【０１５５】
また、ｆａｒｍＩＤ対応付けテーブル（図１４）を参照して、小ファーム内の他方のサーバを決定するようにしたが、これに限らず、テーブルを設けずとも、小ファーム内の他方のサーバを、以下のようにして動的に決定することも可能である。
【０１５６】
サーバファーム全体で２Ｎ台のサーバが設けられる場合に、「０」から「（Ｎ−１）＋Ｎ」までの数値を識別子として各サーバに割り当てたとき、一方のサーバの識別子を「ｘ」であるとすると、他方のサーバの識別子を演算式「ｙ＝ｘ＋Ｎ」により決定することができる。例えば、サーバファーム全体で「２Ｎ＝１０」台のサーバが設けられている場合に、一方のサーバが「ｘ＝３」であるとき、他方のサーバを「ｙ＝８」と決定することができる。このようにすると、２台の組合せを予め定めたテーブルを用意する必要がなくなり、拡張性を持たせるのに好適となる。
【０１５７】
なお、本実施形態のＤＢサーバ１３及びキャッシュサーバ１４についても、複数のサーバを組み合わせたサーバファームとして構築するようにしても良い。そして、この場合は、各ユーザに固有の識別子（ユーザ識別子）とサーバ固有の識別子とを予め紐づけたテーブルなどを用意しておき、そのユーザに関するイベントの管理を担当するサーバを一意に決定するようにすることができる。これにより、あるユーザに関するイベントの発生状況固有のサーバにより管理することができ、データが分散管理されることがない。
【０１５８】
＜総括＞
以上説明したように、本実施形態のイベント通知機能提供システム３では、それぞれで異なるＡＰにおいて任意に定義されたイベントの発生を横断的に管理することができ、一のＡＰにおいて任意に定義されたイベントの発生を他のＡＰに通知する仕組みを提供することができる。これにより、ユーザからすれば、利用しているＡＰ間の隔たりを意識することなく、各ＡＰでのイベントの発生を知ることができるようになる。
【０１５９】
また、発生したイベントの登録処理を、各サービス提供サーバ５からのリクエストを直に受ける第１サーバ１１ではなく、第２サーバ１２がバックグラウンドで行うようにしたので、第１サーバ１１はイベントの発生メッセージを受信するとそのままサービス提供サーバ５に対してレスポンスを送信できるようになり、各ＡＰにおいて発生する大量のイベントを滞りなく処理することができるようになる。また、第１サーバ１１は、イベントの登録処理及び読出処理の両方を行うことによる処理負担から解放されるので、イベントの登録処理及び読出処理の双方に関するパフォーマンスを向上させることができる。
【０１６０】
また、イベントの登録処理については第２サーバがバックグラウンドで行う一方で、イベントの参照処理については第１サーバがキャッシュサーバにアクセスすることで行う。これにより、第１サーバが、ＤＢサーバに直接アクセスすることによる処理パフォーマンスの低下を防ぐことができ、大量に発生するイベントを処理するのに好適である。
【０１６１】
また、各ＡＰでのイベントの発生状況を、通知を行う対象となるユーザ識別子をキーとして管理するので、ユーザ識別子ごとにデータベースを分割管理することができ、これによってユーザごとにデータアクセスの高速化も期待できる。また、イベントの参照時には、通知を行う対象となるユーザ識別子を超えてイベント情報が読み出されることもなく、システムの堅牢性も確保することができる。
【０１６２】
また、発生したイベントを、ＡＰ単位の識別子及びコンテンツ単位での識別子を紐付けて管理するので、イベントの発生状況の通知に、ＡＰ単位での通知、コンテンツ単位での通知、個々のイベント単位での通知という具合に、バリエーションを持たせることができる。
【０１６３】
以上、本発明の好適な実施形態により本発明を説明した。ここでは特定の具体例を示して本発明を説明したが、特許請求の範囲に定義された本発明の広範な趣旨および範囲から逸脱することなく、これら具体例に様々な修正および変更を加えることができることは明らかである。すなわち、具体例の詳細および添付の図面により本発明が限定されるものと解釈してはならない。
【０１６４】
本実施形態のイベント通知機能提供システム３は、複数のサービスを統合してユーザに提供する一のサービス提供企業が利用可能なことはもちろんであるが、異なるサービス提供企業間でも利用可能である。さらに、ウェブ上のサービスをユーザに提供するサービス提供企業に限らず、社員に業務アプリケーションを使用させて情報の共有を行っているような一般企業においても利用可能である。
【０１６５】
なお、本発明は、一のＡＰでのイベントの発生を他のＡＰに対して通知することを要旨とするものであり、そこから先のＡＰ側での処理は、各ＡＰにゆだねることができる。本実施形態では、各ＡＰは、イベントの発生をユーザに対して通知することにより、他のＡＰでのイベントの発生をユーザが知ることができるようにしているが、例えばユーザの行動を分析するためのＡＰであれば、イベントの発生そのものを通知するというよりは、イベントの発生状況を分析した結果を提供することも考えられる。あるＡＰにおけるコンテンツに対してコメントが付きやすい時間帯を集計する、という具合である。また、イベントの発生状況の分析をイベント通知機能提供システム３側で行い、その結果を各ＡＰに対して提供するようにしても良い。
【符号の説明】
【０１６６】
１ システム
３ イベント通知機能提供システム
５ サービス提供サーバ
７ ユーザ端末
１１ 第１サーバ
１２ 第２サーバ
１３ ＤＢサーバ
１４ キャッシュサーバ
１５ イベント消去手段
１６ イベント記憶手段
３１ イベント受信手段
３２ イベント登録手段
３３ イベント読出手段
３４ イベント通知手段
３５ イベント消去手段
３６ イベント記憶手段
５１ 入力受付手段
５２ 入力情報処理手段
５３ イベント送信手段
５４ イベント参照手段
５５ イベント受信手段
５６ イベントデータ提供手段
７０ ページ画面
７１ イベント通知領域
７２ ＡＰ単位通知領域
７３ コンテンツ単位通知領域
７４ イベント一覧通知領域
【技術分野】
【０００１】
本発明は、ウェブ上のアプリケーション間でイベントの発生を通知する技術に関する。
【背景技術】
【０００２】
近年、インターネットにおいては、例えばソーシャル・ネットワーキング・サービス（以下、ＳＮＳ）などのように、ユーザ個人が記事や写真や動画といったコンテンツを投稿し、他ユーザに公開することができる場を構築するアプリケーションをウェブ上で提供するサービスが普及している。
【０００３】
これらのサービスは、一般にＣＧＭ（Consumer Generated Media）とも呼ばれ、コンテンツを作成したユーザから他ユーザへの情報発信のツールとしてだけでなく、ユーザ間のコミュニケーションのツールとしても利用されている。たとえば、或るユーザが投稿した日記に対して、その日記を閲覧した他ユーザが個々にコメントを付記することで、その日記を媒介としてユーザ間で意見交換が行われる、というものである。
【０００４】
そして、最近、上記のようなサービスでは、或るコンテンツに対してユーザによりコメントが付記された場合に、そのコンテンツを投稿したユーザに対して、新着のコメントがあった旨を通知するようにしたものが提案されている（例えば、特許文献１を参照。）。このような通知は、そのときサービスの利用中であればクライアントのブラウザにより表示されているウェブページに差し込むことで行われる。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００７−３２８５３７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかし、上記のような従来のサービスでは、扱われるコンテンツの数は膨大であり、それに伴い、発生するイベントは大量となる。そのため、上記のようなサービスを提供するサーバは、大量に発生するイベントを処理するべく、そのような負荷に耐えうる仕組みを構築することが求められている。
【０００７】
そこで、本発明は、大量に発生するイベントを処理することが可能なサーバ構成を有するイベント通知機能提供システムを提供することを目的とする。
【課題を解決するための手段】
【０００８】
上記の課題を解決するため、本発明は以下のような態様を要旨とする。
【０００９】
（１） ウェブ上のアプリケーションで任意に定義されたイベントの発生を大量に処理するためのサーバ構成を有し、各アプリケーション間でイベントの発生を通知するイベント通知機能提供システムであって、
アプリケーションを管理するサービス提供サーバから送信されたイベントの発生を受信する第１サーバと、
前記第１サーバからの依頼に応じ、前記イベントの発生を記憶手段に登録する登録処理を行う第２サーバと、を備え、
前記第１サーバは、
前記サービス提供サーバから受信したイベントの発生の登録処理を前記第２サーバに依頼するとともに、前記第２サーバからの完了通知を受け取らずに前記イベントの発生を受信した後に、イベントの発生の登録処理を行った旨のレスポンスを前記サービス提供サーバに対して送信することを特徴とするイベント通知機能提供システム。
【００１０】
（１）によれば、第１サーバがサービスサーバから送信されるイベントの発生を受信すると、イベントの発生を受信した直後に、登録処理を行った旨のレスポンスをサービスサーバに返送し、その一方で、イベントの登録処理を第２サーバに依頼するようにした。したがって、サービスサーバとの間で、各アプリケーションで発生する大量のイベントを滞りなく処理することができる。
【００１１】
（２） 前記第１サーバは、
前記サービス提供サーバから送信されるイベント発生メッセージを、イベントの発生として受信し、
前記第２サーバは、
前記イベント発生メッセージから抽出した、ユーザ識別子、イベントが発生したアプリケーションの識別子、イベントが発生したコンテンツの識別子、発生したイベントの識別子及びイベントの内容を含むイベント情報を、ユーザ識別子に関連づけてデータベースに登録し、かつ、前記データベースに登録されているイベント情報から作成したサマリー情報をキャッシュに登録し、
前記第１サーバは、
前記サービス提供サーバからのリクエストに応じて、前記キャッシュに登録されているサマリー情報をサービス提供サーバに送信することを特徴とする（１）のイベント通知機能提供システム。
【００１２】
（２）によれば、イベントの登録処理については第２サーバがバックグラウンドで行う一方で、イベントの参照処理については第１サーバがキャッシュにアクセスすることで行う。これにより、第１サーバが、データベースに直接アクセスすることによる処理パフォーマンスの低下を防ぐことができ、大量に発生するイベントを処理するのに好適である。
【００１３】
（３） ウェブ上のアプリケーションで任意に定義されたイベントの発生を大量に処理し、各アプリケーション間でイベントの発生を通知するイベント通知機能提供システムの動作方法であって、
第１サーバが、アプリケーションを管理するサービス提供サーバから送信されたイベントの発生を受信する工程と、
第２サーバが、前記第１サーバからの依頼に応じ、前記イベントの発生を記憶手段に登録する登録処理を行う工程と、
第１サーバが、前記サービス提供サーバから受信したイベントの発生の登録処理を前記第２サーバに依頼するとともに、前記第２サーバからの完了通知を受け取らずに前記イベントの発生を受信した後に、イベントの発生の登録処理を行った旨のレスポンスを前記サービス提供サーバに対して送信する工程と、を含むことを特徴とするイベント通知機能提供システムの動作方法。
【００１４】
（３）によれば、（１）と同様の効果を奏する。
【発明の効果】
【００１５】
本発明によれば、各アプリケーションで大量に発生するイベントを処理することが可能となる。
【図面の簡単な説明】
【００１６】
【図１】実施形態にかかるシステム全体の構成例を示す図である。
【図２】実施形態にかかるイベント通知機能提供システムの構成例を示す図である。
【図３】イベントテーブルのデータ構造例を示す図である。
【図４】コンテンツテーブルのデータ構造例を示す図である。
【図５】キャッシュテーブルのデータ構造例を示す図である。
【図６】イベント定義データ共有リストのデータ構造例を示す図である。
【図７】実施形態の処理例を示すシーケンス図（イベント登録）である。
【図８】実施形態の処理例を示すシーケンス図（イベント参照：サマリー）である。
【図９】イベントの通知に関する画面例（サマリー）を示す図である。
【図１０】実施形態の処理例を示すシーケンス図（イベント参照：イベント一覧）である。
【図１１】イベントの通知に関する画面例（イベント一覧）を示す図である。
【図１２】実施形態の処理例を示すシーケンス図（イベント消去）である。
【図１３】イベント通知機能提供システムの第２サーバの詳細な構成例を示す図である。
【図１４】ｆａｒｍＩＤ対応付けテーブルのデータ構造例を示す図である。
【図１５】実施形態の処理例を示すシーケンス図（イベント登録）である。
【図１６】実施形態の処理例を示すフローチャート図（依頼先サーバ決定処理）である。
【発明を実施するための形態】
【００１７】
以下、図面を参照して、本発明を実施するための形態（以下、実施形態）について説明する。
【００１８】
＜構成＞
図１を参照して、本実施形態に係るイベント通知機能提供システム（ノーティスプラットフォーム）３を含むシステム全体の構成について説明する。
【００１９】
イベント通知機能提供システム３は、複数のサービス提供サーバ５（５ａ、…、５ｘ）とネットワークＮを介して接続されている。また、サービス提供サーバ５は、複数のユーザ端末７（７ａ、…、７ｘ）とネットワークを介して接続されている。
【００２０】
イベント通知機能提供システム３、サービス提供サーバ５及びユーザ端末７は、ＣＰＵ等の制御装置、メモリやＨＤＤ等の記憶装置、通信Ｉ／Ｆ等の通信装置といったハードウェア資源を有するコンピュータ（単一或いは複数）により構成される。ユーザ端末７は、ユーザが利用するＰＣ（Personal Computer）や携帯電話端末等であり、上記のようなハードウェア資源に加え、キーボタンやタッチパネル等の入力装置、液晶ディスプレイ等の出力装置を備える。
【００２１】
（ユーザ端末７）
ユーザ端末７は、一般的なブラウザを備えている。ブラウザは、インターネットの標準プロトコルであるＨＴＴＰ（Hyper Text Transfer Protocol）等に従い、ＨＴＭＬ（Hyper Text Markup Language）等の言語で記述されたページデータの要求、取得及び表示、フォームデータの送信等を行う機能を有している。ユーザは、ユーザ端末７のブラウザを通じて、サービス提供サーバ５により提供されるアプリケーションを利用する。
【００２２】
（サービス提供サーバ５）
複数のサービス提供サーバ５は、それぞれ個別のアプリケーション（以下、ＡＰ）をユーザ端末７に対して提供し、ウェブ上のサービスを実現する。ウェブ上のサービスの例は、ユーザが記事や写真や動画等といったコンテンツを閲覧したり、ユーザ白身がコンテンツを投稿して他のユーザに公開したり、商取引を行う場を提供するサービスであり、ニュースサービス、ＳＮＳ（ソーシャルネットワーキングサービス）、オークションサービス、地図情報サービス等が該当する。ＡＰは、ユーザ端末７に対して、コンテンツの投稿やコンテンツに対する何らかのアクションの入力や、コンテンツの検索、閲覧等をユーザが行うための各種機能を提供する。
【００２３】
本実施形態では、各ＡＰにおいて任意に定義されるものであって、ユーザに関わりのあるコンテンツをターゲットとした何らかのアクションを示す情報を「イベント」という。
【００２４】
例えば、オークションサービスであれば、一のユーザ（ユーザＡとする）が出品したアイテムに対して他のユーザ（ユーザＢやユーザＣとする）により入札が行われた場合、ユーザＡから見たユーザＢやユーザＣの入札行為を「イベント」と定義することができる。
【００２５】
また、別の例では、オークションサービスにおいて、一のユーザ（ユーザＢとする）が或るアイテムに対して入札を行い、その入札を行ったアイテムに対してさらに他のユーザ（ユーザＣとする）により入札が行われた場合、ユーザＢから見たユーザＣの入札行為を「イベント」と定義することができる。
【００２６】
また、別の例では、ＳＮＳにおいて、一のユーザ（ユーザＸとする）を他のユーザ（ユーザＹとする）が友だちに登録した場合、ユーザＸから見たユーザＹの登録行為を「イベント」と定義することができる。
【００２７】
さらに、別の例では、オークションサービスにおいて、一のユーザ（ユーザＺとする）の出品物が誰にも落札されないで終了した場合、ユーザＺから見た、その終了したという結果を「イベント」と定義することができる。この例でいうアクションは、ユーザが直接的に生じさせたものではないが、このようにＡＰの動作上で自動的に発生した出来事もアクションに含めることができる。
【００２８】
なお、本実施形態では、一のサービス提供サーバ５が一のＡＰを管理する構成について説明するが、本発明はこれに限らず、一のサービス提供サーバ５が複数のＡＰを管理する構成や、一のＡＰを複数のサービス提供サーバ５が管理する構成を採用することができる。
【００２９】
サービス提供サーバ５は、一のＡＰにつき、入力受付手段５１と、入力情報処理手段５２と、イベント送信手段５３と、イベント参照手段５４と、イベント受信手段５５と、ページデータ提供手段５６と、を備えている。
【００３０】
入力受付手段５１は、ユーザ端末７のブラウザから、マウスクリック、キーボード入力に基づいたユーザの各種リクエスト及び入力情報を受信する機能を有する。
【００３１】
入力情報処理手段５２は、入力受付手段５１が受信したユーザのリクエスト及び入力情報の内容に応じて、投稿されたコンテンツやコンテンツに対するアクションのデータベースヘの登録、検索、参照等の各種処理を行う機能を有する。また、入力情報処理手段５２は、コンテンツに対するアクションを登録する際に、イベントの定義付けをする。例えば、オークションサービスにおいて、ユーザの入力情報の内容が「出品物１への１つ目の入札」であった場合、出品物１の識別子（ｉｔｅｍ＿０００１）に、1つ目の入札を示す識別子（ｅｖｅｎｔ＿０００１）を割り当てる。
【００３２】
イベント送信手段５３は、入力情報処理手段５２がコンテンツに対するアクションをイベントとして定義した場合に、イベントの発生メッセージをイベント通知機能提供システム３に対して送信する機能を有する。
【００３３】
イベント参照手段５４は、入力受付手段５１が受信したユーザのリクエストに応じて、イベント通知機能提供システム３に対してイベントの参照リクエストを送信する機能を有する。
【００３４】
イベント受信手段５５は、イベント通知機能提供システム３から送信された、各ＡＰにおけるイベントの発生状況を受信する機能を有する。
【００３５】
ページデータ提供手段５６は、ページデータを作成し、ユーザ端末７のブラウザに対して送信する機能を有する。例えば、イベント受信手段５５が受信した、各ＡＰにおけるイベントの発生状況に基づいてページデータを作成し、ユーザ端末７のブラウザに対して送信し、ユーザに対してイベントの発生を通知する。
【００３６】
イベント送信手段５３、イベント参照手段５４及びイベント受信手段５５は、イベント通知機能提供システム３の管理者側から提供されたＡＰＩ（Application Program Interface）をＡＰに組み込むことで実現される機能である。各サービス提供サーバ５が管理するＡＰとイベント通知機能提供システム３との間の通信は任意の形式とすることができる。
【００３７】
（イベント通知機能提供システム３）
一方、イベント通知機能提供システム３は、複数のＡＰのそれぞれにおいて任意に定義されているイベントの発生を収集し、一括管理し、各ＡＰに対して通知する機能を有する。イベント通知機能提供システム３は、イベント受信手段３１と、イベント登録手段３２と、イベント読出手段３３と、イベント通知手段３４と、イベント消去手段３５と、イベント記憶手段３６と、を備えている。
【００３８】
イベント受信手段３１は、各ＡＰ（より詳しくはイベント送信手段５３）からそれぞれ送信されたイベントの発生メッセージを受信する。イベント登録手段３２は、イベント受信手段３１が受信した各ＡＰにおけるイベントの発生メッセージに基づいて、イベント記憶手段３６に対するイベントの登録処理を行う。
【００３９】
イベント記憶手段３６は、各ユーザに関するイベントの発生状況を記憶している。ユーザに関するイベントの発生状況とは、各ＡＰで発生したイベントをユーザ単位で分類し、時系列に従って蓄積したデータである。詳しいデータ構成は後述するが、イベント記憶手段３６は、イベントが発生したコンテンツ及びＡＰと、イベントの発生の通知対象となるユーザとを特定可能なデータを少なくとも記憶している。
【００４０】
イベント読出手段３３は、各ＡＰ（より詳しくはイベント参照手段５４）から送信されたイベントの参照リクエストに応じて、イベント記憶手段３６からイベントの発生状況を読み出す。なお、本実施形態でのイベントの読み出しは、いわゆるプル型の通知を行う場合のものであるが、プッシュ型の通知を行う場合など任意のタイミングを採用することができる。
【００４１】
イベント通知手段３４は、イベント読出手段３３が読み出したイベントの発生状況を、各ＡＰ（より詳しくはイベント受信手段５５）に対して送信する。イベント消去手段３５は、イベント通知手段３４が各ＡＰに対して送信したイベントの発生状況のうち、ユーザにより通知の確認が行われたイベントに関するレコードを、イベント記憶手段３６から消去する。
【００４２】
（イベント通知機能提供システム３のサーバ構成）
図１ではイベント通知機能提供システム３の機能的な構成について説明したが、以下では、図２を参照してハードウェア的な構成について説明する。図２は、本実施形態にかかるイベント通知機能提供システム３のサーバ構成を示す図である。
【００４３】
イベント通知機能提供システム３は、第１サーバ１１と、第２サーバ１２と、データベースサーバ（以下、ＤＢサーバ）１３と、キャッシュサーバ１４と、を備え、これらの各サーバ１１〜１４が相互に通信可能に接続されて構成されている。各サーバ１１〜１４間の通信は、任意の形式とすることができる。各サーバ１１〜１４は、ＣＰＵ等の制御装置、メモリやＨＤＤ等の記憶装置、通信Ｉ／Ｆ等の通信装置といったハードウェア資源を有するコンピュータにより構成される。
【００４４】
第１サーバ１１は、複数のサービス提供サーバ５のそれぞれにより管理されているＡＰとの窓口となる。つまり、第１サーバ１１は、各サービス提供サーバ５からのリクエストを受け付け、処理結果をレスポンスとして返送するフロントエンド部としての機能を有する。第２サーバ１２は、第１サーバ１１の依頼を受けてイベントの登録処理を行う機能を有する。ＤＢサーバ１３及びキャッシュサーバ１４は、各ＡＰにおいて発生したイベントを管理する。
【００４５】
ここで、図１との関係において、第１サーバ１１は、前述したイベント受信手段３１、イベント読出手段３３及びイベント通知手段３４として機能する。また、第２サーバ１２は、イベント登録手段３２及びイベント消去手段３５として機能する。さらに、ＤＢサーバ１３及びキャッシュサーバ１４は、イベント登録手段３２、イベント消去手段３５及びイベント記憶手段３６として機能する。
【００４６】
（イベントの登録処理）
ここで、本実施形態のイベント通知機能提供システム３は、各ＡＰにおいて発生する大量のイベントを処理するため、イベントの登録処理に関して以下のような処理を行うようにしている。
【００４７】
第１サーバ１１は、まず、サービス提供サーバ５からイベントの発生メッセージを受信すると、受信したイベントの登録処理を第２サーバ１２に対して依頼する。このとき、第１サーバ１１は、第２サーバ１２からの処理完了の通知を受け取ることなく、イベントの発生メッセージを受信した直後、イベントの登録処理を行った旨のレスポンスを受信元のサービス提供サーバ５に対して送信する。
【００４８】
一方で、第１サーバ１１から依頼を受けた第２サーバ１２は、イベントの登録処理をＤＢサーバ１３及びキャッシュサーバ１４に対して行う。
【００４９】
このようにして、イベントの登録処理を、各サービス提供サーバ５からのリクエストを直接受け付ける第１サーバ１１ではなく、第２サーバ１２がバックグラウンドで行うようにしたので、第１サーバ１１はイベントの発生メッセージを受信するとそのままサービス提供サーバ５に対してレスポンスを送信できるようになり、各ＡＰにおいて発生する大量のイベントを滞りなく処理することができるようになる。また、第１サーバ１１は、イベントの登録処理及び読出処理の両方を行うことによる処理負担から解放されるので、イベントの登録処理及び読出処理の双方に関するパフォーマンスを向上させることができる。
【００５０】
（ＤＢサーバ１３のデータ構成）
次に、図３及び図４を参照して、ＤＢサーバ１３が備えるデータ構造例について説明する。ＤＢサーバ１３は、イベントテーブル（図３）とコンテンツテーブル（図４）と、を備えている。
【００５１】
（イベントを個々に管理するイベントテーブル）
イベントテーブル（図３）は、各ＡＰにおいて発生したイベントに関する情報（以下、イベント情報）を記憶している。イベント情報は、「ユーザ識別子」、「サービス識別子」、「コンテンツ識別子」、「イベント識別子」、「イベント内容」及び「日時」の各データ項目を含んでいる。これらの各データ項目は、サービス提供サーバ５のＡＰにより任意に定義され、イベントの発生メッセージに含まれて送信されてくるものである。
【００５２】
「ユーザ識別子」は、イベントの発生を通知する対象ユーザを特定するためのデータである。例えば、オークションサービスであれば、入札がつけられた出品物の出品者が有するユーザＩＤである。
【００５３】
「サービス識別子」は、イベントが発生したＡＰを特定するデータである。例えば、識別子「ａｕｃ」であればオークションサービス、識別子「ｂｏａｒｄ」であれば掲示板サービス、という具合に特定される。
【００５４】
「コンテンツ識別子」は、イベントが発生したコンテンツを特定するデータである。例えば、オークションサービスを例にすると、識別子「ｉｔｅｍ」であれば「出品物」であり、識別子「ｉｔｅｍ＿０００１」であれば「出品物Ａ」という具合に特定される。
【００５５】
「イベント識別子」は、発生したイベントを特定するデータである。例えば、オークションサービスの出品物を例にすると、識別子「ｅｖｅｎｔ」であれば「入札」であり、識別子「ｅｖｅｎｔ＿０００１」であれば１つ目の「入札１」、という具合に特定される。
【００５６】
「イベント内容」は、発生したイベントについての付加情報を示すテキストデータである。例えば、イベントを発生させたユーザにより入力された情報の内容であり、オークションサービスであれば、「入札額」や「入札者のユーザＩＤ」などが記述されている。
【００５７】
「日時」は、イベントが発生した日時を特定するデータである。例えば、オークションサービスを例にすると、「入札が行われた日時」となる。
【００５８】
（イベントをコンテンツ単位で管理するコンテンツテーブル）
コンテンツテーブル（図４）は、発生したイベントをコンテンツ単位で集約した情報（以下、コンテンツ情報）を記憶している。コンテンツ情報は、「ユーザ識別子」、「サービス識別子」、「コンテンツ識別子」、「イベント数」、「イベント識別子」、「ＵＲＬ」及び「日時」の各データ項目を含んでいる。
【００５９】
「イベント数」は、コンテンツに対して発生したイベントの数を特定するデータである。前述のイベントテーブルに記憶されている各イベント情報を、「ユーザ識別子」、「サービス識別子」及び「コンテンツ識別子」の組をキーとして取りまとめ、その数をカウントしたものが記憶されている。「ＵＲＬ」は、各ＡＰで管理されているコンテンツのアドレスを特定するデータである。例えば、オークションサービスを例にすると、１個の出品物に対して新たに入札がついた件数となる。
【００６０】
本実施形態では、ＤＢサーバ１３は、イベント情報とコンテンツ情報をそれぞれ分けて管理していることから、それぞれを別のサーバファームとして構築するような場合に、それぞれのデータ量に応じて拡張が可能になり、スケーラビリティを確保することができる。
【００６１】
（イベントをＡＰ単位で管理するキャッシュテーブル）
次に、図５を参照して、キャッシュサーバ１４が備えるデータ構造例について説明する。キャッシュサーバ１４は、キャッシュテーブル（図５）を備えている。
【００６２】
キャッシュテーブル（図５）は、イベントが発生したコンテンツをＡＰ単位で集約した情報（以下、サマリー情報）を記憶している。サマリー情報は、「ユーザ識別子」、「サービス識別子」、「コンテンツ数」、「コンテンツ識別子」、「イベント識別子」、「ＵＲＬ」及び「日時」の各データ項目を含んでいる。
【００６３】
「コンテンツ数」は、イベントが発生したコンテンツの数を特定するデータである。前述のＤＢサーバ１３のコンテンツテーブルに記憶されているコンテンツ情報を、「ユーザ識別子」及び「サービス識別子」の組をキーとして取りまとめ、その数をカウントしたものが記憶されている。例えば、オークションサービスを例にすると、１０個の出品物を出品しているような場合に、そのうち新たに入札がついた出品物の個数となる。
【００６４】
また、サマリー情報には、コンテンツ数に含まれる個々のコンテンツに関するコンテンツ情報が関連付けて記憶されている。これにより、個々のコンテンツのＵＲＬや発生したイベントの数なども特定可能となる。
【００６５】
（各ＡＰにおける発生イベントの表示の共有）
次に、図６を参照して、イベント定義データ共有リストについて説明する。
【００６６】
イベント定義データ共有リストは、各ＡＰにおいて、他のＡＰで定義されているイベントを把握するために用いられるデータであり、各ＡＰに共通して提供される。また、ユーザ端末７のブラウザにより、他のＡＰにおけるサービス名、コンテンツ名及びイベント名を表示させる際に用いられる。
【００６７】
イベント定義データ共有リストは、各ＡＰにおいて任意に定義されている「サービス識別子」、「コンテンツ識別子」及び「イベント識別子」の一覧に応じて、それぞれを表示する名称が関連付けられている。例えば、サービス識別子「ａｕｃ」に対して「オークション」サービス、コンテンツ識別子「ｉｔｅｍ」に対して「出品物」が関連付けられている。
【００６８】
イベント通知機能提供システム３は、各ＡＰに対して、他のＡＰに関するイベントの発生を通知するとき、前述のサマリー情報等とともに、イベント定義データ共有リストを提供する。これにより、各ＡＰでは、他のＡＰにおいて定義されているコンテンツやイベントを共有することができ、また、イベントの通知を行う際に各ＡＰで共通の表示を行うことができる。
【００６９】
ここで、「サービス識別子」、「コンテンツ識別子」及び「イベント識別子」は、サービス提供サーバ５の運営者により各ＡＰで任意に定義された識別子が設定される。
【００７０】
識別子の設定を行うに際して、イベント通知機能提供システム３は、サービス提供サーバ５に接続された運営者端末（図示せず）のブラウザに設定用ページデータを送信する。サービス提供サーバ５の運営者は、ブラウザに表示された設定用ページを介して、ＡＰ内で任意に定義する識別子を登録し、イベント通知機能提供システム３に対して送信する。
【００７１】
例えば、ＡＰにより提供されるウェブ上のサービスがオークションサービスである場合、運営者は、サービス識別子として「ａｕｃ」を、表示名のテキストとして「オークション」を登録する。また、コンテンツ識別子として「ｉｔｅｍ」を、表示名のテキストとして「出品物」を登録する。さらに、イベント識別子として「ｅｖｅｎｔ」を、表示名のテキストとして「入札」を登録する。
【００７２】
なお、上記設定用ページでは、各ＡＰで任意に定義する識別子の登録のほか、イベントの発生通知を行うページのレイアウト（後述の図９及び図１１を参照）のカスタマイズや、イベントの発生の通知のパターン（後述のＡＰ単位、コンテンツ単位、イベント一覧など）、通知の確認が終了したイベントの消去のタイミングなどを任意に設定できるようにしてもよい。この場合、イベント通知機能提供システム３は、イベントの発生の通知のパターンや消去のタイミングなどの設定情報を、サービス識別子に関連付けて管理し、各ＡＰに応じた処理を行う。
【００７３】
＜動作＞
次に、本実施形態のイベント通知機能提供システム３の動作について説明する。
【００７４】
（イベントの登録）
図７は、本実施形態の処理例を示すシーケンス図であり、サービス提供サーバ５のＡＰから送信されたイベントの発生を、ＤＢサーバ１３及びキャッシュサーバ１４に格納するまでの処理例である。
【００７５】
ユーザ端末７のユーザが、ブラウザからサービス提供サーバ５のＡＰにより提供されるサービスのページを閲覧したい場合、ブラウザからサービス提供サーバ５のＡＰに対してページリクエストを送信する（ステップＳ１１）。例えば、オークションサービスを例にすると、出品物を閲覧するためのページのリクエストである。このリクエストは、ブラウザにおいて、対象コンテンツのＵＲＬを入力するか、他のページに張られたリンクを指定すること等により行われる。
【００７６】
なお、ログイン済みであるかどうかの確認は、例えばセッションＩＤ等を示すクッキーを読み込むことで行う。未だログインされていないものとすると、サービス提供サーバ５は、ユーザ端末７のブラウザにログインページを送信し、ユーザＩＤとパスワードの入力を受け付け、ユーザデータベースに登録されているか否かの照合を行い、ログイン処理を行う。
【００７７】
サービス提供サーバ５は、予め保持されたページデータを取得するか、動的にページデータを作成するかにより、ブラウザに提供するページデータを作成する（ステップＳ１２）。この際、ＡＰが提供するコンテンツと、コンテンツに対して何らかのアクションを入力するための画面領域をページデータに含める。
【００７８】
続いて、サービス提供サーバ５は、作成したページデータをユーザ端末７に対して送信する（ステップＳ１３）。ページデータはＨＴＴＰのレスポンス等に従ってブラウザに送信される。ユーザ端末７は、受信したページデータに基づいてブラウザにページ画面を表示する（ステップＳ１４）。例えば、オークションサービスを例にすると、出品物とともに「入札」及び「入札額」を指定する画面領域が表示されており、その領域に対して入力を行うことで入札を行うことができるようになる。
【００７９】
続いて、ユーザ端末７のユーザが、ページ画面のコンテンツに対するアクションとして所望の内容を入力すると、ブラウザからサービス提供サーバ５のＡＰに対して、入力されたアクションの内容が送信される（ステップＳ１０１）。
【００８０】
サービス提供サーバ５は、受信したアクションの内容をデータベースに登録し、その際、イベントの定義付けを行う（ステップＳ１０２）。すなわち、新たに発行した「イベント識別子（例えば、入札１）」やユーザによる入力情報の内容を示す「イベント内容（例えば入札額）」を、「コンテンツ識別子（例えば出品物Ａ）」、イベントの通知対象となる「ユーザ識別子（例えば、入札がついた出品物Ａの出品者）」、「ＵＲＬ」等とともにデータベースに登録する。
【００８１】
続いて、サービス提供サーバ５は、イベントの発生メッセージをイベント通知機能提供システム３の第１サーバ１１に対して送信する（ステップＳ１０３）。イベントの発生メッセージには、イベントの通知対象となる「ユーザ識別子」、「サービス識別子」、「コンテンツ識別子」、「イベント識別子」、コンテンツの「ＵＲＬ」、「イベント内容」及び「日時」が含まれている。
【００８２】
第１サーバ１１は、サービス提供サーバ５からイベントの発生メッセージを受信すると、その登録処理を第２サーバ１２に依頼するリクエストと共に、第２サーバ１２に送信する（ステップＳ１０４）。続いて、第１サーバ１１は、受信したイベントの発生メッセージについて処理完了のレスポンスを受信元のサービス提供サーバ５に対して送信する（ステップＳ１０５）。なお、第１サーバ１１は、第２サーバ１２への依頼を行う前にサービス提供サーバ５に対するレスポンスを行うようにしても良い。
【００８３】
つまり、第１サーバ１１は、第２サーバ１２による登録処理の完了を待たず、イベントの発生メッセージを受信した後、直ちに、処理完了のレスポンスを返送することになる。
【００８４】
一方、第１サーバ１１から登録処理を依頼された第２サーバ１２は、まず、ＤＢサーバ１３に対してイベント登録リクエストを送信する（ステップＳ１０６）。これを受けたＤＢサーバ１３は、まず、発生メッセージからイベント情報を抽出し、イベントテーブル（図３）に登録する。続いて、ＤＢサーバ１３は、イベントテーブルからコンテンツ情報を生成し、コンテンツテーブル（図４）に登録する（ステップＳ１０７）。各テーブルの参照や更新には、ＳＱＬ（Structured Query Language）等のコマンドが用いられる。
【００８５】
より具体的には、ＤＢサーバ１３は、第１サーバ１１が受信したイベントの発生メッセージから、イベントの通知対象となる「ユーザ識別子」、「サービス識別子」、「コンテンツ識別子」、「イベント識別子」、「イベント内容」及び「日時」の組を抽出し、イベント情報として、イベントテーブルの新たなレコードに設定する。
【００８６】
また、ＤＢサーバ１３は、イベント情報の登録が完了すると、イベントテーブルに記憶されている各イベント情報を、「ユーザ識別子」、「サービス識別子」及び「コンテンツ識別子」の組をキーとして取りまとめ、そのレコード数を「イベント数」としてカウントする。そして、「ユーザ識別子」、「サービス識別子」、「コンテンツ識別子」、「イベント数」、「イベント識別子」、「ＵＲＬ」及び「日時」の組を抽出し、コンテンツ情報として、コンテンツテーブルの新たなレコードに設定する。
【００８７】
ＤＢサーバ１３は、イベントテーブル（図３）及びコンテンツテーブル（図４）への登録を完了すると、その旨の通知を第２サーバ１２に対して送信する（ステップＳ１０８）。
【００８８】
次に、第２サーバ１２は、ＤＢサーバ１３に対してサマリー作成リクエストを送信する（ステップＳ１０９）。これを受けたＤＢサーバ１３は、サマリー情報を作成し（ステップＳ１１０）、第２サーバ１２に対して送信する（ステップＳ１１１）。
【００８９】
より具体的には、ＤＢサーバ１３は、コンテンツテーブル（図４）において新たなレコードとして登録されたコンテンツ情報を、「ユーザ識別子」及び「サービス識別子」の組をキーとして取りまとめ、そのレコード数を「コンテンツ数」としてカウントする。そして、「ユーザ識別子」、「サービス識別子」、「コンテンツ数」、「コンテンツ識別子」、「イベント識別子」、取りまとめたコンテンツのうち最新のイベントが発生したコンテンツの「ＵＲＬ」、最新のイベントの「イベント内容」及び「日時」からなる項目の組合せをサマリー情報とし、これに個々のコンテンツ情報を紐づける。
【００９０】
第２サーバ１２は、ＤＢサーバ１３からサマリー情報を受信すると、キャッシュサーバ１４に対して、サマリー登録リクエストを送信する（ステップＳ１１２）。これを受けたキャッシュサーバ１４は、サマリー情報をキャッシュテーブル（図５）の新たなレコードに設定し、登録を行う（ステップＳ１１３）。なお、サマリー登録リクエストは、ＤＢサーバ１３からキャッシュサーバ１４に対して行われるようにしても良い。
【００９１】
キャッシュサーバ１４は、サマリー情報の登録を完了すると、その旨の通知を第２サーバ１２に対して送信する（ステップＳ１１４）。第２サーバ１２は、イベントの登録完了の通知を第１サーバ１１に対して送信する（ステップＳ１１５）。
【００９２】
これを受けた第１サーバ１１は、更新通知を要求するＡＰが予め設定されている場合には、その対象となるＡＰに対して更新通知を送信する（ステップＳ１１６）。
【００９３】
（イベントの参照）
図８及び図１０は、本実施形態の処理例を示すシーケンス図であり、サービス提供サーバ５のＡＰがイベントの参照リクエストを送信してから、そのＡＰに対してイベントが通知されるまでの処理例である。
【００９４】
（イベントの参照：サマリー一覧）
まず、図８を参照して、サマリー一覧を指定したイベントの参照リクエストを行った場合の処理例について説明する。
【００９５】
図８において、ユーザ端末７のユーザがブラウザからサービス提供サーバ５のＡＰにより提供されるサービスのページを閲覧したい場合、ブラウザからサービス提供サーバ５のＡＰに対してページリクエストを送信する（ステップＳ２０１）。例えば、ショッピングサービスを例にすると、商品を検索・閲覧するためのページのリクエストである。このリクエストは、ブラウザにおいて、対象コンテンツのＵＲＬを入力するか、他のページに張られたリンクを指定すること等により行われる。
【００９６】
サービス提供サーバ５は、ユーザ端末７のブラウザからＡＰに対するページリクエストを受信すると、第１サーバ１１に対して、イベント参照リクエスト「サマリー一覧」を送信する（ステップＳ２０２）。イベント参照リクエストには、当該リクエストを行ったユーザのユーザ識別子が含まれている。
【００９７】
イベント参照リクエストを受信した第１サーバ１１は、イベント参照リクエスト「サマリー一覧」をキャッシュサーバ１４に対して送信する（ステップＳ２０３）。
【００９８】
イベント参照リクエストを受信したキャッシュサーバ１４は、リクエストを行った「ユーザ識別子」をキーとしてキャッシュテーブル（図５）を参照し、対象となるサマリー情報を検索する（ステップＳ２０４）。
【００９９】
（キャッシュヒットありの場合）
ステップＳ２０４での検索の結果、サマリー情報がヒットした場合、キャッシュサーバ１４は、サマリー情報を取得し、第１サーバ１１に対して送信する（ステップＳ２０５）。
【０１００】
サマリー情報を受信した第１サーバ１１は、サマリー情報をサービス提供サーバ５に対して送信する（ステップＳ２０６）。
【０１０１】
サマリー情報を受信したサービス提供サーバ５は、サマリー情報に基づいてページデータを作成し（ステップＳ２０７）、ページリクエストのあったユーザ端末７のブラウザに送信する（ステップＳ２０８）。
【０１０２】
ページデータを受信したユーザ端末７のブラウザはページ画面を表示する（ステップＳ２０９）。図９は、ブラウザのページ画面７０の例を示している。ページ画面７０には、イベント通知領域７１が表示されており、その領域内において、サマリー情報に基づいて作成されたＡＰ単位通知領域７２及びコンテンツ単位通知領域７３が表示されている。
【０１０３】
ＡＰ単位通知領域７２には、ユーザに閲するイベントの発生をＡＰ単位で通知するメッセージが表示される。例えば、「オークションにおいて２つの出品物に入札があります」、「掲示板において１件のトピックに対して新着コメントがあります」といったメッセージが表示され、イベントが発生したＡＰ名とそのＡＰにおいてイベントが発生したコンテンツの数がユーザに通知される。
【０１０４】
一方、コンテンツ単位通知領域７３には、ユーザに関するイベントの発生をコンテンツ単位で通知するメッセージが表示される。例えば、「オークションの出品物Ａに２件の入札があります」、「オークションの出品物Ｂに１件の入札があります」というように、イベントが発生したＡＰ名及びコンテンツ名とそのコンテンツに対して発生したイベントの数をユーザに通知するメッセージが表示される。
【０１０５】
また、ＡＰ単位通知領域７２には、ＡＰ毎に、最新のイベントが発生したコンテンツへのリンク先ＵＲＬが埋め込まれる。一方、コンテンツ単位通知領域７３には、コンテンツ毎に、そのコンテンツへのリンク先ＵＲＬが埋め込まれる。
【０１０６】
リンク先ＵＲＬは、ＵＲＬの文字列を表示するか、或いは、通知メッセージの表示に紐付けるなどし、それらの表示をクリッカブルとすることにより、リンク先ＵＲＬが示すウェブページへの遷移をユーザに指定させる。
【０１０７】
これにより、イベントの発生通知を受けたユーザは、上記リンク先ＵＲＬを介して、イベントが発生したコンテンツのウェブページをブラウザに表示させ、発生したイベントを実際に確認することができる。
【０１０８】
（キャッシュヒットなしの場合） ところで、本実施形態では、イベントの登録処理とイベントの読出処理との間は非同期で行われるため、イベント参照時にサマリー情報が末作成である場合も起こりうる。以下の処理は、この場合における処理例である。
【０１０９】
ステップＳ２０４での検索の結果、サマリー情報がヒットしなかった場合、キャッシュサーバ１４は、サマリー情報の取得に失敗した旨の通知を、第１サーバ１１に対して送信する（ステップＳ２１０）。
【０１１０】
通知を受信した第１サーバ１１は、イベント参照リクエスト「サマリー一覧」をＤＢサーバ１３に対して送信する（ステップＳ２１１）。
【０１１１】
イベント参照リクエストを受信したＤＢサーバ１３は、リクエストを行った「ユーザ識別子」をキーとしてコンテンツテーブル（図４）を参照し、サマリー情報を作成して（ステップＳ２１２）、第１サーバ１１に対して送信する（ステップＳ２１３）。
【０１１２】
より具体的には、ＤＢサーバ１３は、コンテンツテーブル（図４）において新たなレコードとして登録されたコンテンツ情報を、リクエストを行った「ユーザ識別子」をキーに抽出する。そして、これらを「サービス識別子」をキーとして「サービス識別子」単位で取りまとめ、そのレコード数を「コンテンツ数」としてカウントする。そして、「ユーザ識別子」、「サービス識別子」、「コンテンツ数」、「コンテンツ識別子」、「イベント識別子」、取りまとめたコンテンツのうち最新のイベントが発生したコンテンツの「ＵＲＬ」、最新のイベントの「テキスト」及び「日時」からなる組をサマリー情報とし、これに個々のコンテンツ情報を紐づける。
【０１１３】
サマリー情報を受信した第１サーバ１１は、サマリー情報をサービス提供サーバ５に対して送信する（ステップＳ２１４）。
【０１１４】
サマリー情報を受信したサービス提供サーバ５は、サマリー情報に基づいてページデータを作成し（ステップＳ２１５）、ページリクエストのあったユーザ端末７のブラウザに送信する（ステップＳ２１６）。ベージデータを受信したユーザ端末７のブラウザはページ画面（図９参照）を表示する（ステップＳ２１７）。
【０１１５】
また、第１サーバ１１は、キャッシュサーバ１４に対して、サマリー登録リクエストを送信する（ステップＳ２１８）。これを受けたキャッシュサーバ１４は、サマリー情報をキャッシュテーブル（図５）の新たなレコードに設定し、登録を行う（ステップＳ２１９）。これにより次回以降の参照時にはキャッシュサーバ１４にアクセスすればよい。
【０１１６】
（イベントの参照：イベント一覧）
次に、図１０を参照して、イベント一覧を指定したイベントの参照リクエストを行った場合の処理例について説明する。
【０１１７】
図１０において、ユーザ端末７のユーザがブラウザからサービス提供サーバ５のＡＰにより提供されるサービスのページを閲覧したい場合、ブラウザからサービス提供サーバ５のＡＰに対してページリクエストを送信する（ステップＳ３０１）。例えば、ニュースサービスを例にすると、ニュース記事を閲覧するためのページのリクエストである。
【０１１８】
サービス提供サーバ５は、ユーザ端末７のブラウザからＡＰに対するページリクエストを受信すると、第１サーバ１１に対して、イベントの参照リクエスト「イベント一覧」を送信する（ステップＳ３０２）。イベントの参照リクエストには、送信元のサービス識別子や、当該リクエストを行ったユーザのユーザ識別子（例えばユーザＩＤ）が含まれている。
【０１１９】
イベントの参照リクエストを受信した第１サーバ１１は、イベントの参照リクエストをＤＢサーバ１３に対して送信する（ステップＳ３０３）。イベントの参照リクエストを受信したＤＢサーバ１３は、リクエストを行った「ユーザ識別子」をキーとしてイベントテーブル（図３）を参照し、対象となるイベント情報をサービス識別子ごとに取りまとめ、一覧として取得する（ステップＳ３０４）。ＤＢサーバ１３は、取得したイベント情報の一覧を第１サーバ１１に対して送信する（ステップＳ３０５）。
【０１２０】
イベント情報の一覧を受信した第１サーバ１１は、イベント情報の一覧をサービス提供サーバ５に対して送信する（ステップＳ３０６）。イベント情報の一覧を受信したサービス提供サーバ５は、イベント情報の一覧に基づいてページデータを作成し（ステップＳ３０７）、ページリクエストのあったユーザ端末７のブラウザに送信する（ステッブＳ３０８）。
【０１２１】
ページデータを受信したユーザ端末７のブラウザはページ画面を表示する（ステップＳ３０９）。図１１は、ブラウザのページ画面７０の例を示している。ページ画面７０には、イベント通知領域７１が表示されており、その領域内において、イベント情報の一覧に基づいて作成されたイベント一覧通知領域７４が表示されている。
【０１２２】
イベント一覧通知領域７４には、リクエストを行ったユーザに対するイベントの発生をイベント単位で（つまり、個々のイベントを詳細に）通知するメッセージが表示される。例えば、「オークションの出品物Ａに対する入札は以下です」とし、「入札１：詳細（時間／入札者／入札額）」、「入札２：詳細（時間／入札者／入札額）」といったメッセージが表示され、発生したイベントが個別に通知される。
【０１２３】
（イベントの消去）
図１２は、本実施形態の処理例を示すシーケンス図であり、サービス提供サーバ５のＡＰがイベントの消去リクエストを送信してから、ＤＢサーバ１３及びキャッシュサーバ１４により対象のイベントが消去されるまでの処理例である。
【０１２４】
図１２において、サービス提供サーバ５は、前述したように、ユーザ端末７に対してページデータを送信し（ステップＳ２１）、ブラウザに表示させる（ステップＳ２２）ことで、イベントの通知を行う（図８及び図１０）。その後、ユーザ端末７において、イベントが発生したコンテンツのリンク先ＵＲＬがユーザにより指定（クリック）されると（ステップＳ２３）、リンク先ＵＲＬが示すウェブページのページリクエストがサービス提供サーバ５に対して送信される（ステップＳ２４）。
【０１２５】
これを受けたサービス提供サーバ５は、そのページリクエストを処理する（ステップＳ２５）。例えば、他のサービス提供サーバ５で管理されるＡＰ内のコンテンツであれば、そのページリクエストを他のサービス提供サーバ５に受け渡す。
【０１２６】
続いて、サービス提供サーバ５は、発生したイベントをユーザが確認したものとし、イベント通知機能提供システム３の第１サーバ１１に対して、イベントの消去メッセージを送信する（ステップＳ４０１）。イベントの消去メッセージには、消去を行う対象の「ユーザ識別子」、「サービス識別子」及び「コンテンツ識別子」が含まれている。
【０１２７】
第１サーバ１１は、サービス提供サーバ５からイベントの消去メッセージを受信すると、その消去処理を第２サーバ１２に依頼するリクエストと共に、第２サーバ１２に送信する（ステップＳ４０２）。続いて、第１サーバ１１は、消去メッセージについて処理完了のレスポンスを受信元のサービス提供サーバ５に対して送信する（ステップＳ４０３）。
【０１２８】
一方、第１サーバ１１から消去処理を依頼された第２サーバ１２は、まず、ＤＢサーバ１３に対してイベント消去リクエストを送信する（ステップＳ４０４）。これを受けたＤＢサーバ１３は、まず、イベントテーブル（図３）から、消去対象の「ユーザ識別子」、「サービス識別子」及び「コンテンツ識別子」をキーとしてイベント情報を消去する（ステップＳ４０５）。
【０１２９】
また、ＤＢサーバ１３は、該当するイベント情報を消去した後のイベントテーブルからコンテンツ情報を抽出し、コンテンツテーブル（図４）に登録する。これは、消去後のイベント情報をコンテンツ情報に反映するためである。
【０１３０】
ＤＢサーバ１３は、消去を完了すると、その旨の通知を第２サーバ１２に対して送信する（ステップＳ４０６）。次に、第２サーバ１２は、ＤＢサーバ１３に対してサマリー作成リクエストを送信する（ステップＳ４０７）。これは、消去後のイベント情報をサマリー情報に反映するためである。これを受けたＤＢサーバ１３は、サマリー情報を作成し（ステップＳ４０８）、第２サーバ１２に対して送信する（ステップＳ４０９）。
【０１３１】
第２サーバ１２は、ＤＢサーバ１３からサマリー情報を受信すると、キャッシュサーバ１４に対して、サマリー登録リクエストを送信する（ステップＳ４１０）。これを受けたキャッシュサーバ１４は、サマリー情報をキャッシュテーブル（図５）の新たなレコードに設定し、登録を行う（ステップＳ４１１）。
【０１３２】
キャッシュサーバ１４は、サマリー情報の登録を完了すると、その旨の通知を第２サーバ１２に対して送信する（ステップＳ４１２）。第２サーバ１２は、完了の通知を第１サーバ１１に対して送信する（ステップＳ４１３）。
【０１３３】
これを受けた第１サーバ１１は、更新通知を要求するＡＰが予め設定されている場合には、そのＡＰに対して更新通知を送信する（ステップＳ４１４）。
【０１３４】
なお、前述の処理例では、ユーザによりリンク先ＵＲＬが指定されたことをトリガーとして、イベントの消去を行うようにしたが、これに限られるものではなく、例えば、サマリー情報やイベント情報に基づいて作成したページデータをユーザ端末７に対して送信したことをトリガーとして、イベントの消去を行うようにすることもできる。
【０１３５】
（第２サーバ１２の詳細な構成）
以下では、図１３〜図１６を参照し、前述した第２サーバ１２の詳細な構成及び動作について説明する。
【０１３６】
図１３は、第２サーバ１２の詳細構成を示す。第２サーバ１２は、複数のサーバ１２（１２ａ、…、１２ｘ）を組み合わせたサーバファームとして構築されている。すなわち、第２サーバ１２は、第１サーバ１１からの依頼に応じたイベントの更新系処理（登録処理及び消去処理）を、負荷分散により行うべく集積された複数のサーバ群である。
【０１３７】
第２サーバ１２は、２台のサーバを組み合わせたグループ（以下、小ファーム）を複数設けることで構成される。サーバファーム全体を構成する個々のサーバには、それぞれを特定するための識別子（以下、ｆａｒｍＩＤ）が割り当てられる。例えば、サーバファーム全体で２Ｎ台のサーバが設けられる場合、ｆａｒｍＩＤとして、「０」から「（Ｎ−１）＋Ｎ」までの数値を識別子として各サーバに割り当てることができる（図１３参照）。
【０１３８】
第１サーバ１１は、イベントの登録依頼を、上記ｆａｒｍＩＤを指定することにより行う。第１サーバ１１により指定されたサーバは、ＤＢサーバ１３及びキャッシュサーバ１４に対してイベントの登録処理を行う。
【０１３９】
図１４は、ｆａｒｍＩＤ対応付けテーブルを示す。ｆａｒｍＩＤ対応付けテーブルは、複数のサーバ間で互いに対となって小ファームを構成する２台のサーバの組合せが予め定められているテーブルである。小ファームを構成する２台のサーバは、サーバの障害発生時に相互に補い合う関係にある。
【０１４０】
つまり、一方のサーバがダウンすると、そのサーバに対して割り振られていたイベント登録依頼が、同じ小ファーム内の（正常に稼働中の）他方のサーバに対して割り振られる。
【０１４１】
ｆａｒｍＩＤ対応付けテーブルは、第１サーバ１１の記憶部（メモリなど）に記憶されている。つまり、第１サーバ１１は、ｆａｒｍＩＤを指定してイベント登録依頼を行う予定のサーバがダウンしているとき、ｆａｒｍＩＤ対応付けテーブルを参照する。そして、そのｆａｒｍＩＤ（例えば、図示の「ｆａｒｍ_０」）に対応づけられた他方のｆａｒｍＩＤ（例えば、図示の「ｆａｒｍ_（Ｎ−１）＋１」）を読み出し、読み出したｆａｒｍＩＤを指定して他方のサーバに対してイベント登録依頼を行う。
【０１４２】
図１５は、本実施形態の処理例を示すシーケンス図であり、サービス提供サーバ５のＡＰから送信されたイベントの発生を、ＤＢサーバ１３及びキャッシュサーバ１４に格納するまでの処理例である。基本的には、図７に示すシーケンス図と同様であるため、同様の内容（図７と同一の符号で示された処理など）については説明を省略する。
【０１４３】
図１５において、第１サーバ１１は、ステップＳ１０３においてサービス提供サーバ５から送信されたイベントの発生メッセージを受信すると、依頼先サーバ決定処理を行う（ステップＳ５０１）。依頼先サーバ決定処理では、前述の第２サーバ１２のサーバファームのうち、イベントの登録処理を依頼するサーバ（以下、依頼先サーバ）を決定する処理を行う。本処理については、後で図１６を参照して説明する。
【０１４４】
第１サーバ１１は、依頼先サーバ決定処理により決定した依頼先サーバに対して、イベントの登録処理を依頼するリクエストと共に、サービス提供サーバ５から受信したイベントの発生メッセージを送信する（ステップＳ１０４）。これを受けた依頼先サーバは、ＤＢサーバ１３に対してイベント登録リクエストを送信する（ステップＳ１０６）。
【０１４５】
図１６は、前述の依頼先サーバ決定処理の処理例を示すフローチャート図である。
【０１４６】
まず、第１サーバ１１は、イベントの発生メッセージに含まれる「ユーザ識別子」を取得し、その取得した「ユーザ識別子」を数値化情報（＝ｋ）に変換する（ステップＳ５１１）。
【０１４７】
「ユーザ識別子」が、英数字の組合せで構成されるユーザＩＤである場合、第１サーバ１１は、ユーザＩＤに含まれる文字（英字や記号）部分を数値に変換することで、ユーザＩＤ全体を数値化することができる。文字の数値化には、英字（Ａ〜Ｚ）や記号（−、／）などの文字に一意の数字が予め対応づけられたデータ（例えば、ＡＳＣＩＩ文字コード）を用いて行うことができる。例えば、ＡＳＣＩＩコードでは、英字「Ａ〜Ｚ」が数値「６５〜９０」に対応付けられており、ユーザＩＤが「ＡＺ１１１１」だとすると、数値化情報として「６５９０１１１１」を得ることができる。また、得られた数字列をいくつかに分け、それらを加えたものを数値化情報とすることもできる（例えば、６５＋９０＋１１＋１１＝１７７）。
【０１４８】
次に、第１サーバ１１は、第２サーバ１２のサーバファームを構成する全てのサーバ数（＝ｎ）を取得する（ステップＳ５１２）。続いて、第１サーバ１１は、演算式「Ｒｅｓｕｌｔ＝ｋ ｍｏｄ ｎ」を実行する（ステップＳ５１３）。つまり、第１サーバ１１は、「ユーザ識別子」の数値化情報（＝ｋ）を、サーバファームの全サーバ数（＝ｎ）で除算し、その余りを演算結果として出力する。たとえば、「ユーザ識別子」の数値化情報（＝ｋ）が「１７７」であり、全サーバ数（＝ｎ）が「６」とすると、「１７７」が「６」で除算されて剰余値「３」が算出される。
【０１４９】
次に、第１サーバ１１は、演算結果をｆａｒｍＩＤとして取得する（ステップＳ５１４）。続いて、第１サーバ１１は、取得したｆａｒｍＩＤに該当するサーバが正常に稼働しているかどうかを判別する（ステップＳ５１５）。
【０１５０】
第１サーバ１１は、取得したｆａｒｍＩＤに該当するサーバが正常に稼働していると判別した場合、取得したｆａｒｍＩＤに該当するサーバを依頼先サーバとして決定する（ステップＳ５１７）。
【０１５１】
一方、第１サーバ１１は、取得したｆａｒｍＩＤに該当するサーバが正常に稼働していない（サーバダウンである）と判別した場合、ｆａｒｍＩＤ対応付けテーブル（図１４）を参照し、そのｆａｒｍＩＤに対応づけられた他方のｆａｒｍＩＤを取得する（ステップＳ５１６）。そして、取得したｆａｒｍＩＤに該当するサーバを依頼先サーバとして決定する（ステップＳ５１７）。
【０１５２】
このように、１人のユーザに関するイベントの発生の処理は１つの固有のサーバにより行われ、かつ、その固有のサーバには障害時に切り替えられるサーバが割り当てられているので、１人のユーザに関するイベントの発生の処理が複数のサーバに跨って振り分けられることはなく、個々のユーザに関するイベントの発生順序を確保することができる。
【０１５３】
また、個々のユーザに関するイベントの発生を処理するサーバを、ユーザ識別子から一意に、かつ動的に決定することができるようにしたので、スケールアウトの際にも容易に対処できるようになり、スケーラビリティの確保につながる。
【０１５４】
なお、前述の依頼先サーバの決定処理は一例であるから、その具体的な内容は、「各ユーザに固有の識別子を用いてそのユーザに関するイベントの登録処理を担当するサーバを一意に決定する」という目的を逸脱しない範囲で任意に変更可能である。例えば、端末ＩＤなど、ユーザＩＤとは異なるユーザ識別子を用いる場合や、所定の関数を用いるなど、前述の数値化手法とは異なる手法を採用することができる。
【０１５５】
また、ｆａｒｍＩＤ対応付けテーブル（図１４）を参照して、小ファーム内の他方のサーバを決定するようにしたが、これに限らず、テーブルを設けずとも、小ファーム内の他方のサーバを、以下のようにして動的に決定することも可能である。
【０１５６】
サーバファーム全体で２Ｎ台のサーバが設けられる場合に、「０」から「（Ｎ−１）＋Ｎ」までの数値を識別子として各サーバに割り当てたとき、一方のサーバの識別子を「ｘ」であるとすると、他方のサーバの識別子を演算式「ｙ＝ｘ＋Ｎ」により決定することができる。例えば、サーバファーム全体で「２Ｎ＝１０」台のサーバが設けられている場合に、一方のサーバが「ｘ＝３」であるとき、他方のサーバを「ｙ＝８」と決定することができる。このようにすると、２台の組合せを予め定めたテーブルを用意する必要がなくなり、拡張性を持たせるのに好適となる。
【０１５７】
なお、本実施形態のＤＢサーバ１３及びキャッシュサーバ１４についても、複数のサーバを組み合わせたサーバファームとして構築するようにしても良い。そして、この場合は、各ユーザに固有の識別子（ユーザ識別子）とサーバ固有の識別子とを予め紐づけたテーブルなどを用意しておき、そのユーザに関するイベントの管理を担当するサーバを一意に決定するようにすることができる。これにより、あるユーザに関するイベントの発生状況固有のサーバにより管理することができ、データが分散管理されることがない。
【０１５８】
＜総括＞
以上説明したように、本実施形態のイベント通知機能提供システム３では、それぞれで異なるＡＰにおいて任意に定義されたイベントの発生を横断的に管理することができ、一のＡＰにおいて任意に定義されたイベントの発生を他のＡＰに通知する仕組みを提供することができる。これにより、ユーザからすれば、利用しているＡＰ間の隔たりを意識することなく、各ＡＰでのイベントの発生を知ることができるようになる。
【０１５９】
また、発生したイベントの登録処理を、各サービス提供サーバ５からのリクエストを直に受ける第１サーバ１１ではなく、第２サーバ１２がバックグラウンドで行うようにしたので、第１サーバ１１はイベントの発生メッセージを受信するとそのままサービス提供サーバ５に対してレスポンスを送信できるようになり、各ＡＰにおいて発生する大量のイベントを滞りなく処理することができるようになる。また、第１サーバ１１は、イベントの登録処理及び読出処理の両方を行うことによる処理負担から解放されるので、イベントの登録処理及び読出処理の双方に関するパフォーマンスを向上させることができる。
【０１６０】
また、イベントの登録処理については第２サーバがバックグラウンドで行う一方で、イベントの参照処理については第１サーバがキャッシュサーバにアクセスすることで行う。これにより、第１サーバが、ＤＢサーバに直接アクセスすることによる処理パフォーマンスの低下を防ぐことができ、大量に発生するイベントを処理するのに好適である。
【０１６１】
また、各ＡＰでのイベントの発生状況を、通知を行う対象となるユーザ識別子をキーとして管理するので、ユーザ識別子ごとにデータベースを分割管理することができ、これによってユーザごとにデータアクセスの高速化も期待できる。また、イベントの参照時には、通知を行う対象となるユーザ識別子を超えてイベント情報が読み出されることもなく、システムの堅牢性も確保することができる。
【０１６２】
また、発生したイベントを、ＡＰ単位の識別子及びコンテンツ単位での識別子を紐付けて管理するので、イベントの発生状況の通知に、ＡＰ単位での通知、コンテンツ単位での通知、個々のイベント単位での通知という具合に、バリエーションを持たせることができる。
【０１６３】
以上、本発明の好適な実施形態により本発明を説明した。ここでは特定の具体例を示して本発明を説明したが、特許請求の範囲に定義された本発明の広範な趣旨および範囲から逸脱することなく、これら具体例に様々な修正および変更を加えることができることは明らかである。すなわち、具体例の詳細および添付の図面により本発明が限定されるものと解釈してはならない。
【０１６４】
本実施形態のイベント通知機能提供システム３は、複数のサービスを統合してユーザに提供する一のサービス提供企業が利用可能なことはもちろんであるが、異なるサービス提供企業間でも利用可能である。さらに、ウェブ上のサービスをユーザに提供するサービス提供企業に限らず、社員に業務アプリケーションを使用させて情報の共有を行っているような一般企業においても利用可能である。
【０１６５】
なお、本発明は、一のＡＰでのイベントの発生を他のＡＰに対して通知することを要旨とするものであり、そこから先のＡＰ側での処理は、各ＡＰにゆだねることができる。本実施形態では、各ＡＰは、イベントの発生をユーザに対して通知することにより、他のＡＰでのイベントの発生をユーザが知ることができるようにしているが、例えばユーザの行動を分析するためのＡＰであれば、イベントの発生そのものを通知するというよりは、イベントの発生状況を分析した結果を提供することも考えられる。あるＡＰにおけるコンテンツに対してコメントが付きやすい時間帯を集計する、という具合である。また、イベントの発生状況の分析をイベント通知機能提供システム３側で行い、その結果を各ＡＰに対して提供するようにしても良い。
【符号の説明】
【０１６６】
１ システム
３ イベント通知機能提供システム
５ サービス提供サーバ
７ ユーザ端末
１１ 第１サーバ
１２ 第２サーバ
１３ ＤＢサーバ
１４ キャッシュサーバ
１５ イベント消去手段
１６ イベント記憶手段
３１ イベント受信手段
３２ イベント登録手段
３３ イベント読出手段
３４ イベント通知手段
３５ イベント消去手段
３６ イベント記憶手段
５１ 入力受付手段
５２ 入力情報処理手段
５３ イベント送信手段
５４ イベント参照手段
５５ イベント受信手段
５６ イベントデータ提供手段
７０ ページ画面
７１ イベント通知領域
７２ ＡＰ単位通知領域
７３ コンテンツ単位通知領域
７４ イベント一覧通知領域
【特許請求の範囲】
【請求項１】
ウェブ上のアプリケーションで任意に定義されたイベントの発生を大量に処理するためのサーバ構成を有し、各アプリケーション間でイベントの発生を通知するイベント通知機能提供システムであって、
アプリケーションを管理するサービス提供サーバから送信されたイベントの発生を受信する第１サーバと、
前記第１サーバからの依頼に応じ、前記イベントの発生を記憶手段に登録する登録処理を行う第２サーバと、を備え、
前記第１サーバは、
前記サービス提供サーバから受信したイベントの発生の登録処理を前記第２サーバに依頼するとともに、前記第２サーバからの完了通知を受け取らずに前記イベントの発生を受信した後に、イベントの発生の登録処理を行った旨のレスポンスを前記サービス提供サーバに対して送信することを特徴とするイベント通知機能提供システム。
【請求項２】
前記第１サーバは、
前記サービス提供サーバから送信されるイベント発生メッセージを、イベントの発生として受信し、
前記第２サーバは、
前記イベント発生メッセージから抽出した、ユーザ識別子、イベントが発生したアプリケーションの識別子、イベントが発生したコンテンツの識別子、発生したイベントの識別子及びイベントの内容を含むイベント情報を、ユーザ識別子に関連づけてデータベースに登録し、かつ、前記データベースに登録されているイベント情報から作成したサマリー情報をキャッシュに登録し、
前記第１サーバは、
前記サービス提供サーバからのリクエストに応じて、前記キャッシュに登録されているサマリー情報をサービス提供サーバに送信することを特徴とする請求項１に記載のイベント通知機能提供システム。
【請求項３】
ウェブ上のアプリケーションで任意に定義されたイベントの発生を大量に処理し、各アプリケーション間でイベントの発生を通知するイベント通知機能提供システムの動作方法であって、
第１サーバが、アプリケーションを管理するサービス提供サーバから送信されたイベントの発生を受信する工程と、
第２サーバが、前記第１サーバからの依頼に応じ、前記イベントの発生を記憶手段に登録する登録処理を行う工程と、
第１サーバが、前記サービス提供サーバから受信したイベントの発生の登録処理を前記第２サーバに依頼するとともに、前記第２サーバからの完了通知を受け取らずに前記イベントの発生を受信した後に、イベントの発生の登録処理を行った旨のレスポンスを前記サービス提供サーバに対して送信する工程と、を含むことを特徴とするイベント通知機能提供システムの動作方法。
【請求項１】
ウェブ上のアプリケーションで任意に定義されたイベントの発生を大量に処理するためのサーバ構成を有し、各アプリケーション間でイベントの発生を通知するイベント通知機能提供システムであって、
アプリケーションを管理するサービス提供サーバから送信されたイベントの発生を受信する第１サーバと、
前記第１サーバからの依頼に応じ、前記イベントの発生を記憶手段に登録する登録処理を行う第２サーバと、を備え、
前記第１サーバは、
前記サービス提供サーバから受信したイベントの発生の登録処理を前記第２サーバに依頼するとともに、前記第２サーバからの完了通知を受け取らずに前記イベントの発生を受信した後に、イベントの発生の登録処理を行った旨のレスポンスを前記サービス提供サーバに対して送信することを特徴とするイベント通知機能提供システム。
【請求項２】
前記第１サーバは、
前記サービス提供サーバから送信されるイベント発生メッセージを、イベントの発生として受信し、
前記第２サーバは、
前記イベント発生メッセージから抽出した、ユーザ識別子、イベントが発生したアプリケーションの識別子、イベントが発生したコンテンツの識別子、発生したイベントの識別子及びイベントの内容を含むイベント情報を、ユーザ識別子に関連づけてデータベースに登録し、かつ、前記データベースに登録されているイベント情報から作成したサマリー情報をキャッシュに登録し、
前記第１サーバは、
前記サービス提供サーバからのリクエストに応じて、前記キャッシュに登録されているサマリー情報をサービス提供サーバに送信することを特徴とする請求項１に記載のイベント通知機能提供システム。
【請求項３】
ウェブ上のアプリケーションで任意に定義されたイベントの発生を大量に処理し、各アプリケーション間でイベントの発生を通知するイベント通知機能提供システムの動作方法であって、
第１サーバが、アプリケーションを管理するサービス提供サーバから送信されたイベントの発生を受信する工程と、
第２サーバが、前記第１サーバからの依頼に応じ、前記イベントの発生を記憶手段に登録する登録処理を行う工程と、
第１サーバが、前記サービス提供サーバから受信したイベントの発生の登録処理を前記第２サーバに依頼するとともに、前記第２サーバからの完了通知を受け取らずに前記イベントの発生を受信した後に、イベントの発生の登録処理を行った旨のレスポンスを前記サービス提供サーバに対して送信する工程と、を含むことを特徴とするイベント通知機能提供システムの動作方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【公開番号】特開２０１１−６５２４４（Ｐ２０１１−６５２４４Ａ）
【公開日】平成２３年３月３１日（２０１１．３．３１）
【国際特許分類】
【出願番号】特願２００９−２１３２７７（Ｐ２００９−２１３２７７）
【出願日】平成２１年９月１５日（２００９．９．１５）
【出願人】（５００２５７３００）ヤフー株式会社 (1,128)
【Ｆターム（参考）】
【公開日】平成２３年３月３１日（２０１１．３．３１）
【国際特許分類】
【出願日】平成２１年９月１５日（２００９．９．１５）
【出願人】（５００２５７３００）ヤフー株式会社 (1,128)
【Ｆターム（参考）】
[ Back to top ]