JP2016505995A - 複数のクライアントデバイスに亘る通知フィード - Google Patents

Abstract

イベント通知は複数のクライアントデバイスまたはプラットフォームに亘ってユーザに提供されうる。ユーザがあるデバイスにおいて行動を起こした場合、すべてのデバイスにおける通知はその行動を反映するべく更新可能である。例えば、通知はトピックおよび時間シーケンス（または他のシーケンス）によってインデクス化されうる。現在の情報がユーザに提供されうるよう、同じトピックに関する複数の通知はサーバまたはクライアントにおいて統合されうる。【選択図】図１

Description

本開示は一般にオンラインコンテンツ管理サービスに関し、特にそのようなサービスから複数のクライアントデバイスに通知を提供することに関する。

オンラインコンテンツ管理サービスは、インターネットを使用して、ユーザが複数のデバイスに亘るコンテンツにアクセスしそのコンテンツを管理することを可能とする。典型的なオンラインコンテンツ管理サービスでは、ユーザはサービス提供者にアカウントを開設し、種々のコンテンツアイテムをそのアカウントと関連付ける。例えば、あるオンラインコンテンツ管理サービスは、ユーザがコンテンツアイテム（テキストドキュメント、電子メールメッセージ、テキストメッセージ、他のタイプのメッセージ、写真やビデオや音声ファイルなどのメディアファイル、および／または複数のファイルを含むフォルダを含むがそれに限定されない）を格納し、他のユーザが選択的にそのコンテンツアイテムにアクセスすることを可能としてもよい。コンテンツアイテムはサービス提供者によって維持されているマスタレポジトリに保持されてもよく、種々のユーザデバイス上のローカルコピーに反映されるか同期されてもよい。ユーザは他のユーザの行動に基づいて更新を受けることができる。例えば、ソーシャルネットワークにおいて、状態更新またはあるユーザによって掲示された他のコンテンツアイテムは、受け取ることへの関心を示した他のユーザに伝搬されうる。

モバイルコンピューティングデバイスの急増と共に、ユーザは今やウェブブラウザやデスクトップアプリケーションプログラムやモバイルデバイスアプリケーションなどのさまざまなクライアントから、同じオンラインコンテンツ管理サービスにアクセスすることが可能である。オンラインコンテンツ管理サービス提供者にとって、ユーザのクライアントすべてを同期したままにすることは困難でありうる。

本発明のある実施の形態は、複数のクライアントデバイスまたはプラットフォームに亘ってユーザにイベント通知を提供することに関する。ある実施の形態では、通知フィードはメッセージのストリームまたはシーケンスを含んでもよい。メッセージのストリームまたはシーケンスは、ユーザが共有コンテンツレポジトリまたはグループに参加するよう招待されたときや、ユーザがそのような招待を受け入れた（または拒否した）ときや、ユーザのアカウントを含む活動（例えば、パスワードなどのセキュリティ設定の変更や課金エラーや割り当て超過など）が検出されたときなどのさまざまなイベントの発生を報告する。ユーザがあるデバイスにおいて行動を起こした場合、すべてのデバイスにおける通知はその行動を反映するべく更新されてもよい。

通知フィードはフレキシブルフィードであってもよい。フレキシブルフィードでは、ユーザに出される通知情報（本明細書では「アラート」とも称される）は、例えば新たなイベントが起こると旧い情報を現在の情報に置き換えることで、現在の状態を反映するよう実質的にリアルタイムで更新される。ある実施の形態では、各通知をトピック識別子に加えてシーケンス情報およびコンテンツを含むよう構成することで、フレキシブルフィードを実装してもよい。通知のリストが与えられると、サーバおよび／またはクライアントはトピック識別子を使用して、同じトピックに係る複数の通知を特定してもよい。複数の通知が同じトピックを含む場合、クライアントは時間シーケンス情報を使用して、どの通知がユーザにアラートとして出されるべきかを決定してもよい。例えば、より古い通知はユーザに対して隠されてもよい。ある実施の形態では、サーバは時間情報を使用して、例えばまだ送られていない通知が後のイベントによってすでに取って代わられている場合にある通知は特定のクライアントには送信される必要がないと決定してもよい。

本発明のある態様はサーバおよびサーバで実行可能な方法に関する。例えば、サーバはターゲットユーザに関連するイベントに係るイベント情報を受け、そのイベント情報に基づいて通知データストアに第１通知レコードを生成してもよい。第１通知レコードはトピックフィールドとシーケンスフィールドとコンテンツフィールドとを含んでもよい。サーバは、第１通知レコードが利用可能であることを示す第１メッセージを生成してもよい。第１メッセージは、ターゲットユーザの識別子と第１通知レコードの識別子とを含んでもよい。サーバは、ターゲットユーザに関連する複数のクライアントに第１メッセージを発してもよい。そのメッセージは、他の任意のクライアントへの発布とは独立して各クライアントに発せられてもよい。

他の例として、サーバはクライアントから新たな通知レコードの要求を受けてもよい。サーバは、通知データストアから、要求に応じた通知レコードの始めの組を取得し、その通知レコードの始めの組から通知レコードの終わりの組を生成してもよい。例えば、終わりの組を生成する際、始めの組の第１通知レコードのトピックフィールドに基づいて、サーバは第１通知レコードが組の他の通知レコードと統合されるべきか否かを決定してもよい。もしそうであれば、サーバはそれらのレコードを統合してもよい。この統合は、通知データストアのレコードに影響を与えずに達成されてもよい。通知レコードの終わりの組は要求したクライアントに送られてもよい。

本発明のある態様はクライアントおよびクライアントで実行可能な方法に関する。例えば、クライアントはサーバから通知レコードを要求し、そのサーバからその要求に応じたひとつ以上の通知レコードを取得してもよい。クライアントは、処理すべき通知レコードの始めの組を特定してもよい。始めの組は、サーバから受けた通知レコードを含む。ある例では、始めの組はサーバに要求する前にクライアントに存在する通知レコードを含んでもよい。クライアントは通知レコードの始めの組から通知レコードの終わりの組を生成してもよい。例えば、始めの組の第１通知レコードのトピックフィールドに基づいて、クライアントは第１通知レコードが始めの組の他の通知レコードと統合されるべきか否かを決定してもよい。もしそうであれば、クライアントはそれらのレコードを統合してもよい。通知レコードの終わりの組に基づき、クライアントはユーザにひとつ以上のアラートを出してもよい。

以下の詳細な説明および添付の図面は、本発明の性質および利点についてのよりよい理解を与えるであろう。

本発明の実施の形態に係るオンラインコンテンツ管理サービスにアクセスするクライアントを示す図である。 本発明の実施の形態に係るクライアントへプッシュ通知を行うためのシステムを示す図である。 代表的なコンピュータシステムを示す簡略化されたブロック図である。 本発明の実施の形態に係るイベント分類体系を示す図である。 本発明の実施の形態に係る通知レコードの例を示す図である。 本発明の実施の形態に係るメッセージについて使用できる一般化可能なデータ構造を示す図である。 本発明の実施の形態に係るユーザに関連する複数のクライアントへイベント通知をプッシュするための処理のフロー図である。 本発明の実施の形態に係るユーザに通知を提供するための処理のフロー図である。 本発明の実施の形態に係るクライアントへ通知レコードを提供するための処理のフロー図である。

本発明のある実施の形態は、複数のクライアントデバイスまたはプラットフォームに亘ってユーザにイベント通知を提供することに関する。ある実施の形態では、通知フィードはメッセージのストリームまたはシーケンスを含んでもよい。メッセージのストリームまたはシーケンスは、ユーザが共有コンテンツレポジトリまたはグループに参加するよう招待されたときや、ユーザがそのような招待を受け入れた（または拒否した）ときや、ユーザのアカウントを含む活動（例えば、パスワードなどのセキュリティ設定の変更や課金エラーや割り当て超過など）が検出されたときなどのさまざまなイベントの発生を報告する。ユーザがあるデバイスにおいて行動を起こした場合、すべてのデバイスにおける通知はその行動を反映するべく更新されてもよい。

通知フィードはフレキシブルフィードであってもよい。フレキシブルフィードでは、ユーザに出される通知情報（本明細書では「アラート」とも称される）は、例えば新たなイベントが起こると旧い情報を現在の情報に置き換えることで、現在の状態を反映するよう実質的にリアルタイムで更新される。ある実施の形態では、各通知をトピック識別子に加えて時間シーケンス情報およびコンテンツを含むよう構成することで、フレキシブルフィードを実装してもよい。通知のリストが与えられると、サーバおよび／またはクライアントはトピック識別子を使用して、同じトピックに係る複数の通知を特定してもよい。複数の通知が同じトピックを含む場合、クライアントは時間シーケンス情報を使用して、どの通知がユーザにアラートとして出されるべきかを決定してもよい。例えば、より古い通知はユーザに対して隠されてもよい。ある実施の形態では、サーバは時間情報を使用して、例えばまだ送られていない通知が後のイベントによってすでに取って代わられている場合にある通知は特定のクライアントには送信される必要がないと決定してもよい。

図１は、本発明の実施の形態に係るオンラインコンテンツ管理サービス１００にアクセスするクライアントを示す図である。オンラインコンテンツ管理サービス１００は、例えば、ファイル保管サービスとファイル共有サービスとユーザがメッセージおよび／または他のコンテンツを掲示することを可能とするソーシャルメディアサービスなどを含んでもよい。オンラインコンテンツ管理サービス１００はサービス提供者によって維持されるサーバ上でホストされ、インターネットなどのネットワーク１０２を介してアクセスされてもよい。

ユーザは、種々のクライアント１１０、１１２、１１４、１１６を操作することでオンラインコンテンツ管理サービス１００にアクセスしてもよい。本明細書において、「クライアント」は主に、ユーザがオンラインコンテンツ管理サービス１００とやりとりすることを可能とするコンピュータハードウエアとソフトウエアとの組み合わせを指す。例えば、クライアント１１０はウェブブラウザ（例えば、インターネットエクスプローラ（登録商標）、グーグルクローム（登録商標）、またはサファリ（登録商標））を実行するデスクトップまたはラップトップコンピュータであってもよい。このウェブブラウザは、ＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）などのウェブプロトコルを使用してオンラインコンテンツ管理サービス１００と通信する。クライアント１１２は、オンラインコンテンツ管理サービス１００の提供者によって提供されるアプリケーションプログラムを実行するデスクトップまたはラップトップコンピュータであってもよい。オンラインコンテンツ管理サービスがファイルへのアクセスを提供するある例では、アプリケーションプログラムはサーバ上にホストされたファイルがクライアントコンピュータのオペレーティングシステムに関連するファイルシステム構造内に存在するように現れることを可能としてもよい。ある例では、同じクライアントコンピュータがウェブブラウザおよびデスクトップアプリケーションプログラムの両方を実行することができることに注意すべきである。したがって、単一の物理的なデバイスがひとつ以上のクライアントを実装しうることは理解されるべきである。

クライアントの他の例は、タブレットコンピュータ１１４や携帯電話１１６などのモバイルデバイスを含み、それらはオンラインコンテンツ管理サービス１００と通信するアプリケーションプログラム（「ａｐｐｓ」とも称される）を実行することができる。様々なときに、ユーザはクライアント１１０、１１２、１１４、１１６のうちのひとつ以上とやりとりしてもよい。

ある実施の形態では、オンラインコンテンツ管理サービス１００は、ユーザおよび／またはクライアントが関心を持ちうるイベントの通知を提供してもよい。本明細書では、「イベント」はユーザに関連する任意のタイプの活動を含んでもよい。例えば、ユーザがファイルを含む共有フォルダへのアクセスを有し、かつ、他のユーザがその共有フォルダのファイルを変更する場合、オンラインコンテンツ管理サービス１００は通知を提供してもよい。他の例としては、第２ユーザはユーザにコンテンツを共有する機会を提供してもよい。これは例えば第２ユーザによって生成または管理される共有フォルダに「参加」するようにユーザを招待することによる。ある実施の形態では、ユーザが現在どのプラットフォームとやりとりしているかによらずに、イベント通知はユーザに関連するすべてのクライアント１１０、１１２、１１４、１１６に提供される。

イベントが通知されることに続いて、通知されたユーザ（または他のユーザ）はそのイベントに関して行動を起こしてもよいし、この行動は他のイベントを構成してもよい。例えば、共有フォルダに参加するための招待を受けることに応じて、ユーザはその招待を受け入れてもよいし拒否してもよい。または招待するユーザは受け取りユーザが受け入れる前にその招待を取り下げてもよい。これらの行動はさらなるイベントを構成してもよく、このさらなるイベントについて通知が作成されうる。

本明細書において、「通知」は主にサービスがひとつ以上のクライアントに提供するイベント関連情報を指す。ある実施の形態では、クライアントはそれが受けた通知のいくつかまたはすべてをユーザによって視認可能（または知覚可能）としてもよい。例えば、クライアントは通知が受け取られたことを示す視覚的インジケータを表示してもよいし、通知を説明するテキスト（例えば「ジョーがフォルダ３を共有するようあなたを誘いました。」）を表示してもよいし、音を流してもよいし、振動してもよいし、通知を説明する言葉を話してもよい。本明細書において、「アラート」という語はユーザ視認可能（知覚可能）な形の通知を指すために使用される。

ある実施の形態では、個々のイベント通知に加えてまたはその代わりに、クライアント１１０、１１２、１１４、１１６の任意のものまたはすべてはユーザに通知フィードを提供してもよい。本明細書において、「通知フィード」（または単に「フィード」）はイベント関連アラートのリストである。例示的なフィード１２０はクライアント１１０のディスプレイ１２２に示される。フィードは時系列にリストされたアラートであってもよく、各通知のコンテンツおよび／または状態についてユーザに知らせる種々のしるしを含んでもよい。フィードは「フレキシブルな」フィードであってもよい。このフレキシブルなフィードでは、同じトピックに係る通知は統合されるかまたは折りたたまれる。これにより例えばフィードは同じトピックに関する直近の通知のみを提供する。例として、フィード１２０は「ジョーがフォルダ３を共有するようあなた（ユーザボブ）を誘いました。」というアラートを含む。ユーザボブがジョーの招待を受け入れた場合、フィード１２０は表示されたアラートを隠し、表示されたアラートを「あなたはフォルダ３を共有するジョーの誘いを受け入れました。」に置き換えるよう更新されてもよい。または表示されたアラートは隠されてもよい。他の例として、ユーザケイが共有フォルダに写真をアップロードすると、各新たな写真はイベント通知を生成してもよく、一方でフィード１２０は「ケイがフォルダ７に写真をアップロードしました。」などの単一のアラートを出してもよい。通知を統合するために使用されうる技術の例は後述する。

フィードはクライアント１１０、１１２、１１４、１１６の任意のものまたはすべてで提示可能である。異なるクライアントで提示されるフィードは同期されうるかまたは整合されうる。例えば、オンラインコンテンツ管理サービス１００はクライアント１１０、１１２、１１４、１１６に「プッシュ」通知を行ってもよい。

図２は、本発明の実施の形態に係るクライアント１１０、１１２、１１４、１１６へプッシュ通知を行うためのシステム２００を示す図である。システム２００は通知サーバ２０２とモバイルディスパッチャ２０４とウェブディスパッチャ２０６とデスクトップディスパッチャ２０８とを含む。これらのすべては、図１のオンラインコンテンツ管理サービス１００の提供者によって維持および／または運営されるサーバ（または他のコンピュータシステム）に実装されうる。サーバ２０２は通知データストア２１０に通信可能に接続される。サーバ２０２はメッセージキュー２１４を維持し、メッセージキュー２１４はモバイルディスパッチャ２０４とウェブディスパッチャ２０６とデスクトップディスパッチャ２０８とによってアクセス可能である。

通知サーバ２０２はイベント通知の生成およびこれらの通知のクライアントへの発布に関する動作を行ってもよい。この例は後述する。ある実施の形態では、通知サーバ２０２はサーバなどの適切なコンピュータハードウエア上で実行されるひとつ以上のソフトウエア（コード）モジュールとして実装されうる。ある例では、通知サーバ２０２は、コンテンツ管理（例えばファイル保管および取得）および／またはユーザアカウント管理（例えばユーザアカウントの生成および更新、課金等）などのオンラインコンテンツ管理サービスの他の側面に関する動作を行う他のサーバから物理的または論理的に離されてもよい。

リスナデータストア２１２は、例えばデータベースまたは他の任意のデータ保管技術と適切なコンピュータ読み取り可能保持媒体とを使用して、実装されてもよい。リスナデータストア２１２は、特定のクライアントデバイスおよび／または特定のユーザに関連するクライアントを特定する情報を含んでもよい。例えば、ユーザ名「ボブ」を有する特定のユーザは、彼の家のコンピュータにインストールされたデスクトップアプリケーションプログラム（例えば、クライアント１１２）と、彼の家のコンピュータまたは他のコンピュータ上で動くウェブブラウザクライアント（例えば、クライアント１１０）と、ｉＯＳオペレーティングシステム（アップル社の製品）を実行するタブレット（例えば、クライアント１１４）と、アンドロイド（登録商標）オペレーティングシステム（Ｏｐｅｎ Ｈａｎｄｓｅｔ Ａｌｌｉａｎｃｅの製品）を実行する携帯電話（例えば、クライアント１１６）と、を有してもよい。リスナデータストア２１２は、ユーザ名「ボブ」で質問された場合に、これらのクライアントのそれぞれについての特定情報を提供できる。リスナデータストア２１２は、種々のクライアントからの通信に基づいてオンラインコンテンツ管理サービスによって入力されてもよい。例えば、ボブが最初に特定のクライアントからオンラインコンテンツ管理サービスにサインインした場合、通知サーバ２０２（またはオンラインコンテンツ管理サービスに関連する他のサーバ）はリスナデータストア２１２にボブとそのクライアントとを関連付けるレコードを生成してもよい。

通知サーバ２０２は、それについての通知が生成されるべきイベントを検出することができる。ある実施の形態では、オンラインコンテンツ管理サービスに関連する他のサーバによって通知サーバ２０２に送られたイベント情報２２０に基づいて、イベントが検出されうる。したがって、例えば、ユーザアカウントサーバまたはコンテンツ管理サーバは、それらのサーバで発生する行動に基づいて通知サーバ２０２にイベント情報２２０を送ってもよい。イベントおよび関連情報の例は図４を参照して後述する。

通知サーバ２０２はイベント情報２２０に基づいて通知レコード２２２を生成し、通知レコード２２２を通知データストア２１０に保持してもよい。通知データストア２１０は、例えばデータベースまたは他の任意のデータ保管技術と適切なコンピュータ読み取り可能保持媒体とを使用して実装されてもよい。通知レコード２２２はデータベーステーブル内の列を含んでもよいし、または任意の構造化されたデータオブジェクトを含んでもよい。列やデータオブジェクトは、クライアントからの要求に応じてサーバ２０２が特定の通知を容易に取得できるようにするような形でイベント情報２２０を表す。通知レコード２２２の例示的な構造は図５を参照して後述する。

通知サーバ２０２は、通知レコードがデータストア２１０に加えられたときにクライアントに知らせるために、クライアントにメッセージを発してもよい。ある実施の形態では、通知サーバ２０２は通知レコード２２２に対応するメッセージ２２４を生成し、メッセージ２２４をメッセージキュー２１４に加える。メッセージ２２４は通知レコード２２２内の実際の情報を含んでもよいが、そうである必要はない。ある実施の形態では、メッセージ２２４は単に通知レコード２２２の存在を示し、かつメッセージ２２４をクライアントへルートするのに使用可能な情報を提供し、かつ受け取るクライアントがデータストア２１０から通知レコード２２２を取得することを可能としてもよい。例えば、メッセージ２２４はメッセージが向けられているユーザの識別子とレコード２２２の識別子とを含んでもよい。メッセージ２２４の例示的な構造は図６を参照して後述する。

クライアントへ発せられたメッセージ２２４の配送は、モバイルディスパッチャ２０４、ウェブディスパッチャ２０６およびデスクトップディスパッチャ２０８などのディスパッチャを使用することでクライアント特定的な形で達成可能である。それらのディスパッチャのそれぞれは、メッセージキュー２２６のなかの新たなメッセージ２２４を独立に検出し、適切な技術を使用して対応するクライアント特定メッセージ（ＣＳＭ）２４０、２４２、２４４、２４６をクライアントにプッシュしてもよい。クライアント特定メッセージ２４０、２４２、２４４、２４６は、メッセージ２２４と構造的および／または内容的に同等であってもよい（が、そうである必要はない）。特定のクライアント特定メッセージのフォーマットおよびコンテンツは、そのクライアントについて使用される配送プロトコルに合わせられる。クライアント特定メッセージが通知データストア２１０内で対応する通知レコードを見つけるのに使用可能な参照情報を含む限り、クライアントは後述のように通知レコードを取得することができるであろう。

例えば、タブレットコンピュータや携帯電話などのモバイルプラットフォームは、クライアント特定メッセージを特定のデバイスに配送するために、そのオペレーティングシステムに関連するプッシュ通知サービスに依存してもよい。プッシュ通知サービスの例は、アップル社によって運営されｉＯＳオペレーティングシステムを実行するデバイスに関連するＡｐｐｌｅ Ｐｕｓｈ Ｎｏｔｉｆｉｃａｔｉｏｎ Ｓｅｒｖｉｃｅ （ＡＰＮＳ）と、グーグル社によって運営されアンドロイド（登録商標）オペレーティングシステムを実行するデバイスに関連するＧｏｏｇｌｅ Ｃｌｏｕｄ Ｍｅｓｓａｇｉｎｇ （ＧＣＭ）と、を含む。

あるプッシュ通知サービスは、クライアントへのメッセージのソースが宛先デバイスの識別子とメッセージの内容とを提供することを要求する。したがって、ある実施の形態では、モバイルディスパッチャ２０４がメッセージキュー２１４に新たなメッセージ２２４を検出した場合、モバイルディスパッチャ２０４はメッセージ２２４からユーザ識別子を抽出してもよい。モバイルディスパッチャ２０４はユーザ識別子を使用してリスナデータストア２１２に質問し、どの（あれば）モバイルデバイスがユーザ識別子と関連付けられているかを決定してもよい。リスナデータストア２１２からの情報に基づいて、モバイルディスパッチャ２０４は、例えばＡＰＮＳ（クラウド２３２として表される）、ＧＣＭ（クラウド２３４として表される）または特定のモバイルデバイスにとって適切な他のプッシュ通知サービスと通信することによって、ひとつ以上のプッシュ通知（クライアント特定メッセージ２４０、２４２として表される）を生成してもよい。

ウェブディスパッチャ２０６は、ロングプリング（ｌｏｎｇ ｐｕｌｌｉｎｇ）などの技術を使用して、クライアント１１０などのアクティブなウェブクライアントにクライアント特定メッセージ２４４を（例えば（明示的には図示されていない）インターネットを介して）配送してもよい。

デスクトップディスパッチャ２０８は、クライアント１１２などのアクティブなデスクトップクライアントにクライアント特定メッセージ２４６を（例えばインターネットを介して）配送してもよい。デスクトップクライアント１１２とオンラインコンテンツ管理サービスとの間に確立された特定の通信プロトコルに応じて、種々の技術が使用可能である。その例は、ロングプリングやデスクトップクライアントによるディスパッチャ２０８のポーリングやＨＴＴＰサーバプッシュなどを含む。

各ディスパッチャ２０４、２０６、２０８は独立にメッセージキュー２１４をスキャンし、それがまだ処理していないメッセージを特定してもよい。ある実施の形態では、ディスパッチャ２０４、２０６、２０８はメッセージキュー２１４からメッセージを除去しない。代わりに、キュー２１４はＦＩＦＯ（ｆｉｒｓｔ ｉｎ、ｆｉｒｓｔ ｏｕｔ）キューとして管理されてもよく、各ディスパッチャは個別にキュー内での自己の現在のリード位置を追跡してもよい。この場合、各ディスパッチャはすべてのメッセージを時系列で読むことができる。その結果、各ディスパッチャ２０４、２０６、２０８はキュー２１４内の各メッセージを適切なクライアントへ送り出すことができ、特定のユーザに関連するすべてのクライアントはそのユーザへのすべてのメッセージを受けることができる。

ある実施の形態では、メッセージキュー２１４から定期的に、古いメッセージ（例えば、１日や１週間などのある固定期間の後にメッセージは期限切れとなってもよい）および／またはすべてのディスパッチャ２０４、２０６、２０８によって処理されたことが知られているメッセージがパージされうる。

メッセージ２２４に対応するクライアント特定メッセージ（例えば、メッセージ２４０、２４２、２４４、２４６のひとつ）を受けることに応じて、受け取ったクライアントは、例えばサーバ２０２または他のサーバ（不図示）に要求を送ることで、関心のあるレコードを特定するための受け取ったクライアント特定メッセージに含まれる情報を使用して、通知データストア２１０から対応する通知レコード２２２を要求してもよい。

本明細書で説明される種々の動作はコンピュータシステムに実装されてもよく、そのようなコンピュータシステムは一般的に用いられているデザインのものであってもよい。図３は、代表的なコンピュータシステム３００を示す簡略化されたブロック図である。種々の実施の形態では、コンピュータシステム３００または類似のシステムは、クライアント（例えば、プラットフォーム１１０、１１２、１１４、１１６のいずれか）またはサーバ（例えば、サーバ２００）を実現してもよい。

コンピュータシステム３００は、処理ユニット３０５と保持サブシステム３１０と入力デバイス３２０と出力デバイス３２５とネットワークインタフェース３３５とバス３４０とを備える。

処理ユニット３０５は単一のプロセッサを含んでもよく、そのプロセッサはひとつ以上のコアを有してもよい。あるいは処理ユニット３０５は複数のプロセッサを含んでもよい。ある実施の形態では、処理ユニット３０５は汎用プライマリプロセッサに加えて、グラフィックプロセッサやデジタル信号プロセッサなどのひとつ以上の特定用途コプロセッサを含んでもよい。ある実施の形態では、いくつかまたはすべての処理ユニット３０５は、特定用途向け集積回路（ＡＳＩＣｓ）やフィールドプログラマブルゲートアレイ（ＦＰＧＡｓ）などのカスタマイズされた回路を使用して実装されてもよい。ある実施の形態では、そのような集積回路は回路自体に保持されているインストラクションを実行する。他の実施の形態では、処理ユニット３０５は保持サブシステム３１０に保持されるインストラクションを実行してもよい。

保持サブシステム３１０は、システムメモリやリードオンリーメモリ（ＲＯＭ）やパーマネントストレージデバイスなどの種々のメモリユニットを含んでもよい。ＲＯＭは、処理ユニット３０５および電子デバイス３００の他のモジュールが必要とする静的データおよびインストラクションを保持してもよい。パーマネントストレージデバイスは読み書きメモリデバイスであってもよい。このパーマネントストレージデバイスは、コンピュータシステム３００の電源が切られた場合でもインストラクションおよびデータを保持する不揮発性メモリユニットであってもよい。本発明のある実施の形態は、パーマネントストレージデバイスとしてマスストレージデバイス（例えば、磁気ディスクや光学ディスクやフラッシュメモリ）を使用してもよい。他の実施の形態は、パーマネントストレージデバイスとしてリムーバブルストレージデバイス（例えば、フロッピー（登録商標）ディスクやフラッシュドライブ）を使用してもよい。システムメモリは、読み書きメモリデバイスであってもよく、あるいはまたダイナミックランダムアクセスメモリなどの揮発性の読み書きメモリであってもよい。システムメモリは、処理ユニット３０５が実行中に必要とするいくつかまたはすべてのインストラクションおよびデータを保持してもよい。

保持サブシステム３１０は、いろいろな種類の半導体メモリチップ（ＤＲＡＭ、ＳＲＡＭ、ＳＤＲＡＭ、フラッシュメモリ、プログラマブルリードオンリーメモリ）などを含むコンピュータ読み取り可能保持媒体の任意の組み合わせを含んでもよい。磁気ディスクおよび／または光学ディスクが使用されてもよい。ある実施の形態では、保持サブシステム１１０は読み取り可能および／または書き込み可能なリムーバブルストレージ媒体を含んでもよい。そのような媒体の例は、コンパクトディスク（ＣＤ）やリードオンリーデジタルバーサタイルディスク（例えば、ＤＶＤＲＯＭやデュアルレイヤＤＶＤＲＯＭ）やリードオンリーかつ記録可能ブルーレイ（登録商標）ディスクやウルトラデンシティー光学ディスクやフラッシュメモリカード（例えば、ＳＤカードやミニＳＤカードやマイクロＳＤカードなど）や磁気「フロッピー（登録商標）」ディスクなどを含む。コンピュータ読み取り可能保持媒体は、無線で通過するまたは有線接続を介する搬送波も一時的な電気信号も含まない。

ある実施の形態では、保持サブシステム３１０は、オペレーティングシステムやブラウザアプリケーションやオンラインコンテンツ管理サービスにアクセスするためのモバイルアプリケーションやオンラインコンテンツ管理サービスにアクセスするためのデスクトップアプリケーションなどの、処理ユニット３０５によって実行されるべきひとつ以上のソフトウエアプログラムを保持してもよい。「ソフトウエア」は主に、処理ユニット３０５によって実行されるとコンピュータシステム３００に種々の動作を行わせ、したがってソフトウエアプログラムの動作を実行するひとつ以上の特定のマシン実装を規定する一連のインストラクションを指す。インストラクションは、リードオンリーメモリに存在するファームウエアとしておよび／または不揮発性保持媒体に保持されるアプリケーションとして保持されてもよく、処理ユニット３０５による実行のために揮発性の作業メモリに読み出されてもよい。ソフトウエアは、単一のプログラムとして、または別個のプログラムの集合として、または所望の通りに作用し合うプログラムモジュールとして、実装されてもよい。処理ユニット３０５は保持サブシステム３１０から実行すべきプログラムインストラクションと処理すべきデータとを取得し、本明細書で説明される種々の動作を実行してもよい。

ユーザインタフェースは、ひとつ以上のユーザ入力デバイス３２０とひとつ以上のユーザ出力デバイス３２５とによって提供されてもよい。入力デバイス３２０は、それを介してユーザがコンピュータシステム３００に信号を提供できる任意のデバイスを含んでもよい。コンピュータシステム３００はその信号を、特定のユーザ要求または情報を示すものとして解釈してもよい。種々の実施の形態では、入力デバイス３２０は、キーボード、タッチパッド、タッチスクリーン、マウスまたは他のポインティングデバイス、スクロールホイール、クリックホイール、ダイアル、ボタン、スイッチ、キーパッド、マイクロホンなどのいずれかまたはすべてを含んでもよい。

ユーザ出力デバイス３２５は、それを介してコンピュータシステム３００が情報をユーザに提供できる任意のデバイスを含んでもよい。例えば、ユーザ出力デバイス３２５はコンピューティングシステム３００によって生成された画像を表示するディスプレイを含んでもよい。ディスプレイは、例えば液晶ディスプレイ（ＬＣＤ）や有機発光ダイオード（ＯＬＥＤ）を含む発光ダイオード（ＬＥＤ）や投影システムや陰極線管（ＣＲＴ）などの種々の画像生成技術を、支持エレクトロニクス（例えばデジタルアナログコンバータやアナログデジタルコンバータやシグナルプロセッサなど）といっしょに組み入れてもよい。ある実施の形態は、入力デバイスおよび出力デバイスの両方として機能するタッチスクリーンなどのデバイスを含んでもよい。ある実施の形態では、他のユーザ出力デバイス３２５がディスプレイに加えてまたはその代わりに提供されてもよい。その例は、インジケータライトやスピーカや触覚「ディスプレイ」デバイスやプリンタなどを含む。

ネットワークインタフェース３３５はコンピュータシステム３００にボイスおよび／またはデータ通信能力を提供してもよい。ある実施の形態では、ネットワークインタフェース３３５は、（例えば、携帯電話技術や３Ｇ、４Ｇ、ＥＤＧＥ、ＷｉＦｉ（ＩＥＥＥ８０２．１１ファミリー規格）などのアドバンストデータネットワーク技術や他のモバイル通信技術やそれらの任意の組み合わせを使用して）無線ボイスおよび／またはデータネットワークにアクセスするための無線（ＲＦ）送受信コンポーネント、ＧＰＳレシーバコンポーネント、および／または他のコンポーネント、を含んでもよい。ある実施の形態では、ネットワークインタフェース３３５は無線インタフェースに加えてまたはその代わりに有線ネットワーク接続（例えば、イーサネット（登録商標））を提供してもよい。ネットワークインタフェース３３５は、ハードウエアコンポーネント（例えば、アンテナや変調器／復調器や符号化器／復号化器や他のアナログおよび／またはデジタル信号処理回路）とソフトウエアコンポーネントとの組み合わせを使用して実装されてもよい。

バス３４０は、コンピューティングシステム３００の種々のコンポーネントを通信可能に接続する種々のシステムバス、周辺バスおよびチップセットバスを含んでもよい。例えば、バス３４０は処理ユニット３０５を保持サブシステム３１０と通信可能に接続してもよい。バス３４０は、入力デバイス３２０および出力デバイス３２５に接続されてもよい。バス３４０は、ネットワークインタフェース３３５を介してコンピュータシステム３００をネットワークに接続してもよい。このようにして、コンピューティングシステム３００は複数のコンピュータシステムのネットワーク（例えば、ローカルエリアネットワーク（ＬＡＮ）やワイドエリアネットワーク（ＷＡＮ）やイントラネットやインターネットなどのネットワークのネットワーク）の一部であってもよい。

ある実施の形態は、コンピュータ読み取り可能保持媒体にコンピュータプログラムインストラクションを保持するマイクロプロセッサ、ストレージおよびメモリなどの電子コンポーネントを含む。本明細書で説明される特徴の多くは、コンピュータ読み取り可能保持媒体上で符号化されているプログラムインストラクションの組として特定される処理として実装されてもよい。これらのプログラムインストラクションがひとつ以上の処理ユニットによって実行されると、それらは処理ユニットにそれらのプログラムインストラクションに示される種々の動作を行わせる。プログラムインストラクションまたはコンピュータコードの例は、コンパイラにより生成されるようなマシンコードと、コンピュータや電子コンポーネントやマイクロプロセッサによってインタプリタを使用して実行される高レベルコードを含むファイルと、を含む。

適切なプログラミングを通して、処理ユニット３０５はコンピューティングデバイス３００に種々の機能を提供してもよい。例えば、モバイルコンピューティングデバイスでは、処理ユニット３０５は、プッシュ通知を受けることができるオペレーティングシステムを実行してもよく、またオンラインコンテンツ管理サービス１００と通信するアプリケーションを実行してもよい。デスクトップコンピューティングデバイスでは、処理ユニット３０５は、オンラインコンテンツ管理サービス１００とのインタフェースを提供するデスクトップアプリケーションプログラムおよびオペレーティングシステムを実行してもよい。ある実施の形態では、このインタフェースはオペレーティングシステムによって維持されるファイルシステムとのインタフェースと統合されてもよい。ある実施の形態では、処理ユニット３０５はブラウザアプリケーションを実行してもよい。このブラウザアプリケーションは、オンラインコンテンツ管理サービス１００などのソースからコンテンツアイテムを（例えばＨＴＴＰまたはウェブページを取得して表示するための他のデータトランスファプロトコルを使用して）取得して表示する能力と、見るアイテムの選択や特定のコンテンツアイテムに応じたユーザによるデータの提出（例えば、インタラクティブウェブページ上のフォームに入力すること）などのコンテンツアイテムに係るユーザ入力を受けて解釈する能力と、を提供する。

ある実施の形態では、コンピュータシステム３００または類似のシステムは、通知サーバ２０２および／またはモバイルディスパッチャ２０４やウェブディスパッチャ２０６やデスクトップディスパッチャ２０８などのディスパッチャを実現してもよい。そのような例では、ユーザインタフェースは処理ユニット３０５および／または保持サブシステム３１０から離れて配置されてもよい。同様に、保持サブシステム３１０またはその部分は処理ユニット３０５から離れて配置されてもよい。したがって、ある例では、コンピュータシステム３００の種々のコンポーネントは互いに物理的に近接して配置される必要はない。

コンピュータシステム３００は例示であり、変形や変更が可能であることは理解されるであろう。コンピュータシステム３００は本明細書で特に説明されてはいない他の能力（例えば、携帯電話、グローバルポジショニングシステム（ＧＰＳ）、電力管理、ひとつ以上のカメラ、外部デバイスやアクセサリを接続するための種々の接続ポートなど）を有してもよい。さらに、コンピュータシステム３００は特定のブロックを参照して説明されたが、これらのブロックは説明の便宜上規定されたものであり、コンポーネント部分の特定の物理的な構成を暗示することを意図したものではないことは理解されるべきである。さらに、ブロックは物理的に別個のコンポーネントに対応する必要はない。ブロックは、例えばプロセッサをプログラムするかまたは適切な制御回路を提供することによって、種々の動作を行うよう構成されてもよい。種々のブロックは、初期設定がどのように得られるかに依存して、再構成可能であってもよいし、そうでなくてもよい。本発明の実施の形態は、回路とソフトウエアとの任意の組み合わせを使用して実装される電子デバイスを含む種々の装置で実現されてもよい。

図２を参照して上述した通り、システム２００は種々のイベントをクライアントに知らせるよう動作する。ここで、イベントは複数の起こりうる出来事のいずれかを含んでもよい。ある実施の形態では、さまざまな種類のイベントは階層的分類を参照して特定されてもよい。

図４は、本発明の実施の形態に係るイベント分類体系を示す図である。この例では、イベント（ノード４００）は第１レベルにおいて、イベントがアカウント（ノード４０２）に関するかソーシャル活動（ノード４０４）に関するかに基づいて分類されてもよい。ノード４０２のアカウント関連イベントは第２レベルにおいて、イベントがセキュリティ（ノード４０６）に関するか課金（ノード４０８）に関するかに基づいてさらに分類されてもよい。ノード４０６のセキュリティイベントは、パスワード変更（葉ノード４１０）や疑わしい行動（葉ノード４１２）などの具体的なイベントにさらに分類されてもよい。疑わしい行動は、ユーザのアカウントが毀損されているかまたは攻撃されているかもしれないことを示す。同様に、ノード４０８の課金イベントは、支払いエラー（葉ノード４１４）や割り当ていっぱい（葉ノード４１６）などの具体的なイベントにさらに分類されてもよい。

同様に、ノード４０４のソーシャル活動イベントは第２レベルにおいて、イベントが共有フォルダ（ノード４１８）に関するかリンクの共有（ノード４２０）に関するかに基づいてさらに分類されてもよい。ノード４１８の共有フォルダイベントは、招待（葉ノード４２２）や参加（葉ノード４２４）や更新（葉ノード４２６）などの具体的なイベントにさらに分類されてもよい。ノード４２０のリンク共有イベントは、一般ファイルリンクの共有（葉ノード４２８）や写真リンクの共有（葉ノード４３０）やコレクションの共有（例えば、フォルダへのリンク）（葉ノード４３２）などの具体的なイベントにさらに分類されてもよい。

ある実施の形態では、各イベントには階層構造化イベント識別子が割り当てられてもよい。この識別子は分類体系におけるその位置を表す。例えば、割り当ていっぱいイベントは４０２ ４０８ ４１６というイベント識別子を有しうる。イベント識別子を割り当てるための他の規則が使用されてもよい。

図４に示されるイベント分類体系および具体的なイベントは例示であり、変形や変更が可能であることは理解されるであろう。イベント分類体系は任意の数のレベル（単一レベルが縮退したケースを含む）を含んでもよい。また、各レベルに任意の数のノードが存在してもよい。ある実施の形態では、例えばどのアラートをユーザに出すか決めるためにまたはアラートの出し方を調整するためにまたは通知データストア２１０の検索をより容易にするために、イベント分類体系を使用して通知をフィルタしてもよい。

上述の通り、通知サーバ２０２は通知レコード２２２を生成して保持してもよい。図５は、本発明の実施の形態に係る通知レコード２２２の例を示す図である。この例では、各通知レコード２２２は列５０２に示される構造を有する。列５０４、５０６、５０８はこの構造を有する通知レコードの例を提供する。

この例では、トピックおよび時刻によるソーティングおよび／またはフィルタリングを容易にするように通知レコードを構成する。例えば、トピックフィールド５１０はひとつ以上のフィールドを含んでもよく、これらのフィールドを合わせると通知レコードの主題を示す情報が提供される。この例では、トピックフィールド５１０はイベントタイプ識別子とターゲット対象とターゲットユーザとを含む。イベントタイプ識別子は図４の階層からのノード識別子であってもよい。ターゲット対象はイベントが関連するファイルやフォルダの識別子であってもよい。ターゲットユーザはそのユーザのクライアントが通知を受けるべきであるユーザであってもよい。列５０４、５０６、５０８のそれぞれにおいて、トピックフィールドは通知が同じトピックに係ることを示す。そのトピックはユーザ「ボブ」に対する共有フォルダ招待であって、そのフォルダは「ＶａｃａｔｉｏｎＰｈｏｔｏｓ」と称される。上述の通り、ある実施の形態では、トピックフィールド５１０をキーとして使用することで、統合のための通知レコードを特定してもよい。

シーケンスフィールド５１２は、通知レコードを論理的なシーケンスにソートする並べるのに使用可能な情報を提供する。ある実施の形態では、ソーティングは時刻に基づいてもよく、シーケンスフィールド５１２は通知レコードを時間シーケンスにソートするのに使用可能な時刻ベース情報を提供してもよい。例えば、特定のレコードを特定するために、通知サーバ２０２は各通知レコードが生成されるたびにその通知レコードにシリアル番号を割り当ててもよい。ある実施の形態では、シリアル番号は単調増大的なシーケンスで生成されてもよい。ある実施の形態では、通知データストア２１０のすべてのメッセージに対してシリアル番号は一意であってもよく、特定の通知レコードはそのシリアル番号を参照することで見つけられてもよい。他の実施の形態では、同じターゲットユーザを有するすべてのメッセージに対してシリアル番号は一意であってもよく、特定の通知レコードはターゲットユーザＩＤとシリアル番号とを参照することで見つけられてもよい。

シーケンスフィールド５１２はひとつ以上のタイムスタンプを含んでもよい。この例では、送信時刻が含まれる。送信時刻は、サーバ２０２が通知レコードを生成した時刻および／またはサーバ２０２がメッセージキュー２１４のための対応するメッセージ２２４を生成した時刻を反映してもよい。この例では、「フィード時刻」が含まれる。フィード時刻は、基のイベントのソース（例えば、特定のクライアントまたはサーバ）によって確立された時刻基準を反映してもよい。例えば、クライアントが第１イベントに応じた行動を起こした場合、第２通知レコードは、第１通知レコードのフィード時刻にマッチするフィード時刻を有してもよい。ある実施の形態では、クライアントまたはイベントを報告する他のソースは、対応する通知レコードに関連付けられるべきフィード時刻を特定することを許可される。サーバ２０２は許されるフィード時刻について制限を課してもよい。例えば、フィード時刻は送信時刻（これはサーバ２０２によって決定される）より後であってはならないということを規定すうルールである。

他の時刻フィールド（不図示）が含まれてもよい。例えば、通知レコードの生成を導いたイベントがいつ発生したかを示すためにイベント時刻フィールドを使用してもよい。

コンテンツフィールド５１４はイベントに関するさらなる詳細を提供してもよい。例えば、コンテンツフィールド５１４は、ペイロードフィールドと原ユーザフィールドと原アプリケーションフィールドと状態フィールドとを含んでもよい。ペイロードフィールドはイベント特定データを含んでもよい。ある実施の形態では、ペイロードフィールドはキー／値辞書としてフォーマットされてもよい。そこでは、キーおよび値の特定の組み合わせが特定のイベントについて定められる。例えば、ユーザが招待を受け入れるか拒否する場合、ペイロードは招待が受け入れられたかまたは拒否されたかを示すキー値ペアを含んでもよい。原ユーザフィールドは、イベントを引き起こした行動をとったユーザを特定してもよい。例えば、招待の場合、原ユーザは招待を発行したユーザであってもよい。原アプリケーションは、特定のアプリケーションまたはプラットフォームから行動が引き起こされたときのその特定のアプリケーションまたはプラットフォームを特定してもよい。

状態フィールドは通知に関連する状態を示してもよい。ある実施の形態では、状態フィールドは通知レコードの異なる状態に対応する列挙型であってもよい。例えば、列挙値は「ｕｎｒｅａｄ、ｒｅａｄ、ｉｎｖｉｓｉｂｌｅ」を含んでもよい。この例では、「ｕｎｒｅａｄ」はユーザが（おそらく）イベント（または通知）にまだ気付いていないことを示し、「ｒｅａｄ」はユーザが基のイベント（または通知）に気付いたことを示し、「ｉｎｖｉｓｉｂｌｅ」は基のイベント（または通知）を廃れさせるようななんらかの行動が発生したことを示す。ある実施の形態では、クライアントによって通知に対して行動が起こされた場合、更新された状態フィールド（およびおそらくは他の更新されたコンテンツフィールド）を伴う新たなイベントが生成される。

同じトピックに関連する複数の通知を処理するときに、サーバ２０２および／またはクライアント１１０、１１２、１１４、１１６のいずれかまたはすべては状態フィールドを使用してもよい。具体例として、ユーザ（アリス）が自分が生成した「ＶａｃａｔｉｏｎＰｈｏｔｏｓ」と称されるフォルダを共有しませんかとユーザボブを招待したとする。アリスがその招待を送ると、この最初のイベントにより通知サーバ２０２が通知レコード５０４を生成する。イベントトピックは、イベントがフォルダＶａｃａｔｉｏｎＰｈｏｔｏｓについての共有フォルダ招待に関し、ボブに向けられていることを示す。コンテンツフィールドはアリスを原ユーザとして特定し、状態をｕｎｒｅａｄとする。サーバ２０２はボブがその招待を読んだということを示す情報を受け取っていないからである。通知レコード５０４の生成はボブに招待を送ることとは別でありうることは理解されるべきである。例えば、オンラインコンテンツ管理サービス１００はボブのインボックスに実際の招待を含む電子メールまたは他のメッセージを送ってもよい。通知サーバ２０２は、ボブのクライアントにボブが彼の注意を待つ招待を有していることを知らせるための独立した経路を提供する。

次に、通知レコード５０４に基づいてひとつ以上の彼のクライアントによって生成されたアラートを見た結果として、またはどのアラートとも無関係に、ボブは招待を読んでもよい。例えば、ボブはたまたま彼のインボックスをチェックし招待を見るかもしれない。ボブが招待を読むと、この第２イベントにより通知サーバ２０２が通知レコード５０６を生成する。第２イベントもまたアリスからのＶａｃａｔｉｏｎＰｈｏｔｏｓフォルダを共有しませんかという招待に関するので、トピックフィールドは通知レコード５０４のそれと同じであってもよい。時刻フィールドは異なる。これは、ボブが招待を読んだことは別個のイベントであり、この場合ボブのクライアントがイベントのソースとなるため原ユーザおよび原アプリケーションもまた異なりうることを反映する。状態はｒｅａｄとして特定され、ボブが招待を読んだことを示す。

招待を読んだ後のある時点で、ボブはそれを受け入れることを決めるかもしれない。ボブが招待を受け入れると、この第３イベントにより通知サーバ２０２が通知レコード５０８を生成する。第３イベントもまたアリスからのＶａｃａｔｉｏｎＰｈｏｔｏｓフォルダを共有しませんかという招待に関するので、トピックフィールドは通知レコード５０４および５０６のそれと同じであってもよい。時刻フィールドはより後のものである。これは招待の受け入れはそれを読んだ後に発生することを反映する。コンテンツフィールドは、ボブが招待を受け入れた（それを拒否することに対して）ことおよびボブのクライアントが再びイベントのソースであることを示すペイロードを含んでもよい。状態はｉｎｖｉｓｉｂｌｅとして特定され、ボブはもはや通知に関心を持たない可能性が高いことを示す。

この例では、各イベントは既存のレコードの更新よりむしろ新たな通知レコードの生成を導く。後述するように、このメカニズムによって、クライアントは現在の状態をよりよく反映するよう動的に更新されうる通知フィードを提供することができる。

再び図２を参照すると、通知レコード２２２が生成されると、サーバ２０２はメッセージキュー２１４に対応するメッセージ２２４を追加する。メッセージ２２４は通知レコード２２２と同じ情報を含んでもよいが、そうである必要はない。ある実施の形態では、代替的に、メッセージ２２４はクライアントが対応する通知レコード２２２を取得するのに使用可能な情報を提供してもよい。

図６は、本発明の実施の形態に係るメッセージ２２４について使用できる一般化可能なデータ構造６００を示す図である。データ構造６００はソースフィールド６００と対象フィールド６０２と取得コードフィールド６０４とを含む。通知サーバ２０２はメッセージ２２４について構造６００を使用してもよい。ソースフィールド６００は通知サーバ２０２（メッセージ２２４のソース）を特定するのに使用されてもよい。対象フィールド６０２はターゲットユーザを特定するのに使用されてもよい。取得コードフィールド６０４はメッセージのシリアル番号（図５参照）を提供するのに使用されてもよい。上述のように、メッセージの受け手（クライアントデバイス）は、通知データストア２１０から対応する通知レコード２２２を取得するために、フィールド６０４からのシリアル番号をそれだけでまたはフィールド６０２からのターゲットユーザ識別子と組み合わせて使用してもよい。

より一般的には、データ構造６００は異なるソースからのおよび／または異なる宛先に向けられたメッセージについて使用されてもよい。構造６００は通知が利用可能であることを示すクライアントへのメッセージに限られるものではない。例えば、ある実施の形態では、オンラインコンテンツ管理サービス上で保持されるファイルに対する更新はサーバファイルジャーナルに記録される。ファイルの更新に関するメッセージはサーバファイルジャーナルをソースとして特定し、更新されたファイルに関連する名前空間を対象として特定し、シリアルファイルジャーナルエントリに割り当てられたシリアル番号を取得コードとして特定してもよい。そのようなファイル更新メッセージは異なるクライアント間で交換されてもよい。これにより例えば異なるクライアントでデータを同期することができる。またはサーバとクライアントとの間で交換されてもよい。これにより例えばクライアントはファイルのローカルコピーをサーバにより維持されるマスターコピーと同期させることができる。

ある実施の形態では、オンラインコンテンツ管理サービスの提供者はメッセージ２２４のクライアントへの配送を制御できないかもしれない。例えば、モバイルデバイスへのプッシュ通知はセキュアでないチャネルを使用する場合があり、侵入者による傍受に遭うかもしれない。データ構造６００が実際の通知コンテンツを含まない場合、メッセージ傍受によるユーザへの潜在的な危害（例えば、機密データの暴露）は低減される。データ構造６００に準拠するメッセージを受ける認証されたクライアントはセキュアなチャネルを通じてサーバ２０２にアクセスし、通知レコードのコンテンツを取得してもよい。認証されていないクライアントは通知レコードの取得を禁止されてもよい。

図５および図６のデータ構造は例示であり、変形や変更が可能である。通知レコードは任意の数のフィールドを含んでもよく、図示されるよりも多くのまたは少ないフィールドを有してもよい。同様に、メッセージのフィールドの数字および内容は図示のものと異なってもよい。

図５および図６に示されるようなデータ構造を用いることで、図２のシステム２００は特定のユーザに関連する複数のクライアントに亘って通知を調整することができる。これにより、ユーザが任意の所与の時刻にどのクライアント（または複数のクライアント）をアクティブに操作しているかによらずに、すべてのクライアントが関連するユーザに動的通知フィードを提供することが可能となる。クライアント通知サービスを提供するために通知サーバ２０２およびクライアント１１０、１１２、１１４、１１６で実現されてもよい処理の例が下に説明される。

図７は、本発明の実施の形態に係るユーザに関連する複数のクライアントへイベント通知をプッシュするための処理７００のフロー図である。処理７００は例えば通知サーバ２０２などのサーバに実装されてもよい。

ブロック７０２において、通知サーバ２０２はイベントを検出してもよい。例えば、サーバ２０２は他のサーバからまたはクライアントからイベント情報２２０を受けてもよい。ブロック７０４において、通知サーバ２０２は検出されたイベントに基づいて通知レコード２２２を生成してもよい。図５のデータ構造５００または他のデータ構造が使用されてもよい。ある実施の形態では、通知サーバ２０２は、特定のイベントに応じて通知レコードが生成されるべきか否かを判定するための判定ルールを適用してもよい。例えば、ユーザはあらゆる通知の受け取りを許可しないようまたはあるタイプの通知の受け取りを許可しないよう設定できる。通知サーバ２０２はユーザがオプトアウトしたかどうかを判定してもよい。例えば後述されるように、処理の後段で、ユーザオプションが実装されてもよい。

ブロック７０６において、通知サーバ２０２は通知レコード２２２を通知データストア２１０に追加してもよい。ブロック７０８において、通知サーバ２０２は、通知レコード２２２が利用可能であることを示すメッセージ２２４を生成してもよい。図６のデータ構造６００または他のデータ構造が使用されてもよい。

ブロック７１０において、通知サーバ２０２はメッセージ２２４をユーザに関連する複数のクライアントへ発してもよい。ある実施の形態では、メッセージ２２４を発することは、メッセージ２２４をメッセージキュー２１４に追加することを含んでもよい。メッセージキュー２１４は定期的に種々のディスパッチャ２０４、２０６、２０８によって読み取られ、その後そのディスパッチャは上述の通りメッセージをクライアントにプッシュしてもよい。ある実施の形態では、所与のユーザに対するすべてのメッセージはそのユーザのクライアントのすべてに発せられる。他の実施の形態では、発布はより選択的であってもよい。例えば、ユーザは彼の複数のクライアントのうちのすべてではないいくつかについて通知の受け取りを許可しないよう設定できる。ディスパッチャ２０４、２０６、２０８はそのようなユーザのプリファレンスを実現できる。メッセージ２２４を特定のクライアントへ発することによりそのクライアント上でユーザ視認可能なアラートが出されてもよいがその必要はないことは理解されるべきである。アラートの提示に関するユーザプリファレンスはクライアント内で実装され、いくつかまたはすべてのアラートメッセージが抑制されてもよい。

処理７００はサーバが検出するイベントごとに繰り返されてもよい。したがって、各イベントは通知データストア２１０に追加される個々の通知レコードを生じさせてもよい。ある実施の形態では、通知レコードは通知データストア２１０から削除されない。他の実施の形態では、通知レコードは、例えば送信時刻に基づき古いと判定された通知の定期的なパージを通して、削除されてもよい。例えば、通知は固定期間、例えば１日や１週間や１ヶ月、の間維持されて、その後その通知はもはや興味の対象ではないと仮定されて削除されてもよい。イベントタイプや通知トピックに基づくルールなどの通知データストア２１０をパージするためのより複雑なルールが使用されてもよい。例えば、支払いエラーに関する通知はそのエラーが解消されるまで保存されてもよく、一方、共有フォルダ招待の受領や受諾についての通知はある固定期間の後に削除されてもよい。

図８は、本発明の実施の形態に係るユーザに通知を提供するための処理８００のフロー図である。処理８００は例えばクライアント１１６やクライアント１１０、１１２、１１４のいずれかで実装されてもよい。

ブロック８０２において、クライアント１１６は通知が利用可能であることを示すメッセージを受けてもよい。このメッセージは、処理７００のブロック７１０でサーバ２０２によって発せられたメッセージ２２４であってもよい。ブロック８０４において、クライアント１１６は通知サーバ２０２に、対応する通知レコードを求める要求を送ってもよい。

ある実施の形態では、クライアント１１６はメッセージが受け取られるのとリアルタイムで通知レコードを要求してもよい。他の実施の形態では、クライアント１１６は待機し、後の任意のときに通知レコードを要求してもよい。したがって、クライアント１１６がブロック８０４において通知レコードの要求を行う前に、複数のメッセージがサーバ２０２によって発せられおよび／またはクライアント１１６によって受け取られることが可能である。通知レコードがシリアル番号で特定されるある実施の形態では、クライアント１１６は既に受け取った直近の通知レコードのシリアル番号を含む要求を送ってもよい。サーバ２０２は、クライアントによって報告された直近に受け取ったシリアル番号に続くシリアル番号を有する、クライアント１１６のユーザへの通知レコードを送ってもよい。ある実施の形態では、通知レコードを要求するためにおよび／またはどのレコードを提供するかを特定するために、シリアル番号に加えてまたはその代わりに、タイプスタンプを使用してもよい。

ブロック８０６において、クライアント１１６はサーバ２０２からひとつ以上の新たな通知レコードを受けてもよい。ある実施の形態では、クライアント１１６は、新たな通知レコードを、以前に受け取った通知レコードと一緒に保持してもよい。

ある実施の形態では、クライアント１１６は、例えばトピックフィールド５１０のいくつかまたはすべてをキーとして使用することで、同じトピックに関する複数の通知レコード（新たなおよび／または以前に受け取ったレコードを含む）を統合してもよい。したがって、ブロック８０８において、クライアント１１６は、例えばトピックフィールド５１０を比較することによって、ふたつ以上の通知レコードが同じトピックに関するか否かを判定してもよい。ある実施の形態では、トピックフィールド５１０のすべてがマッチする場合（そしてその場合にのみ）、通知は同じトピックに関する。

ふたつ以上の通知レコードのトピックフィールド５１０がマッチする場合、クライアント１１６は例えばシーケンスフィールド５１２のいくつかまたはすべてに基づいて、ブロック８１０においてレコードを統合してもよい。例えば、各レコードに関連するシリアル番号および／またはタイムスタンプに基づいて、クライアント１１６は最も最近のレコードを特定しより古いレコードを廃棄してもよい。他の例では、クライアント１１６はシーケンスフィールド５１２の情報に基づいて同じトピックに関する通知レコードをソートしおよび／または優先順位を付けてもよい。クライアント１１６は所与のトピックに関する通知レコードの部分集合（例えば、ひとつ）を選択し、他のレコードを廃棄してもよい。レコードを廃棄することは、例えばクライアント１１６のストレージからそれを削除することや、それを廃れたものとしてマークすることを含んでもよい。ある実施の形態では、特定のレコードを廃棄するというクライアントの決定はそのローカルコピーのみに影響を与え、通知データストア２１０に保持されるレコードには影響を与えない。ある実施の形態では、統合は複数のレコードからの情報をマージすることを含んでもよい。例えば、ユーザが同じ共有フォルダにファイルをアップロードしたことをそれぞれが示す５つのレコードをクライアント１１６が受ける場合、その５つのレコードは単一のレコードに統合されてもよく、その単一のレコードは５つのファイルが共有フォルダにアップロードされたことを示す。

ブロック８１２において、クライアント１１６は統合された通知レコードに基づいてユーザ視認可能なアラートを表示してもよい。例えば、図５を参照すると、ユーザボブが招待を受け取って読んだがまだ返事をしていない場合、クライアント１１６はサーバ２０２から同時にまたは異なるときに、通知レコード５０４および５０６を受けてもよい。クライアント１１６は例えばより古いレコード５０４を廃棄することで、これらのレコードを統合してもよい。最も直近のレコード５０６に基づいて、ボブに彼が未処理の招待を有していることを思い出させるユーザ視認可能アラートが生成されてもよい。あるいはまた、レコードの状態フィールドはボブが既に招待を読んだことを示しているので、クライアント１１６はレコード５０６に基づきアラートが生成されるべきではないと決定してもよい。任意の特定の通知レコードについてアラートが生成されるか否かはクライアント１１６の特定の実装によるものであり、ユーザプリファレンスおよび設定によって部分的に導かれてもよい。

クライアント１１６は、アラートを生成することに加えてまたはその代わりに、受け取った通知レコードに基づいて他の行動を起こしてもよいことは理解されるべきである。例えば、クライアント１１６はローカルファイルを更新してもよいし、設定を変更してもよいし、ユーザにアラートを出しつつまたは出さずに他の処理を行ってもよい。

処理８００はクライアント１１６（または他のクライアント）によって繰り返し実行されてもよい。これにより、クライアント１１６がほぼリアルタイムでユーザアラートを更新し生成することが可能となる。ある実施の形態では、クライアント１１６はアラートフィード（通知フィードとも単にフィードとも称される）を表示してもよい。アラートフィードは、新たな通知レコードが受け取られて以前のレコードと統合されるにつれて動的に更新される。例えば、ボブが共有フォルダ招待を受けた場合、アラートが生成される。そのアラートはボブがその招待を読んだときに更新されてもよい（例えば、招待が読まれたがまだ未処理であることを示すため）。そしてそのアラートはボブが招待を受け入れた（または拒否した）ときに再び更新される。ある実施の形態では、招待が読まれたか招待が受け入れられたときにアラートは消えてもよい。他の実施の形態では、アラートに関連する表示されたテキストおよび／または他の状態インジケータ（例えば、色、アイコン）は、最新の行動を反映するべく動的に変更されてもよい。例えば、招待が受け取られるとアラートがある色で提示されてもよい。招待が読まれるとその色が変わってもよい。招待が受け入れられると（または拒否されると）アラートは完全に消えてもよいし、ボブに彼が招待に対して行動したことを示すようテキストが変わってもよい（例えば、「あなたには、アリスからのＶａｃａｔｉｏｎＰｈｏｔｏｓというフォルダを共有しようという招待があります」が「あなたは、アリスからのＶａｃａｔｉｏｎＰｈｏｔｏｓというフォルダを共有しようという招待を受け入れました」に変更されてもよい）。ある実施の形態では、アラートのテキストおよび／またはアラートの他のプロパティは、トピックフィールド５１０および／またはコンテンツフィールド５１４に部分的に基づいて決定されてもよい。

クライアントのスタートアップ時（例えば、アプリケーションが開始されたときまたはブラウザクライアントがオンラインコンテンツ管理サービスと接続したとき）、クライアントは通知レコードの現在の組を有さないかもしれない。ある実施の形態では、クライアントのスタートアップ時、クライアントは処理８００をブロック８０４から始める形で実行することでアラートフィードを初期化してもよい。そこでは、クライアントは通知の組を初期化するための要求を送ってもよい。それに応じて、サーバ２０２は通知レコードの「スタートアップ」組を配送してもよい。スタートアップ組は種々の方法で規定されうる。例えば、スタートアップ組は１０個（または他の数の）の直近の通知レコードを含んでもよいし、今から１２時間前までのまたは昨日のまたは他のある期間のすべての通知レコードを含んでもよい。

図９は、本発明の実施の形態に係るクライアント、例えばクライアント１１６（またはクライアント１１０、１１２、１１４のいずれか）へ通知レコードを提供するための処理９００のフロー図である。処理９００は例えば通知サーバ２０２に実装されてもよい。

ブロック９０２において、サーバ２０２はクライアント１１６から通知レコードの要求を受けてもよい。ある実施の形態では、要求は取得されるべき特定の通知レコードの識別子（例えば、シリアル番号またはシリアル番号とユーザＩＤ）を含んでもよい。他の実施の形態では、要求はクライアントが既に受けた最も新しい通知レコードの識別子を含んでもよい。要求は、サーバが特定されたレコードよりも新しい通知レコードのすべてを提供するよう要求してもよい。ある実施の形態では、要求は例えば上述されたような通知レコードのスタートアップ組の要求であってもよい。

ブロック９０４において、サーバ２０２はクライアントの要求にマッチする通知レコードの組を特定してもよい。サーバ２０２はこの組をクライアントへ送ってもよいし、ある実施の形態ではサーバ２０２は送る前に通知レコードを統合してもよい。例えば、ブロック９０６において、サーバ２０２は、例えばトピックフィールド５１０を比較することによって、ふたつ以上の通知レコードが同じトピックに関するか否かを検出してもよい。ある実施の形態では、トピックフィールド５１０のすべてがマッチする場合（そしてその場合にのみ）、通知は同じトピックに関する。ふたつ以上の通知レコードのトピックフィールド５１０がマッチする場合、サーバ２０２はブロック９０８においてレコードを統合してもよい。例えば、各レコードに関連するシリアル番号および／またはタイムスタンプに基づいて、サーバ２０２は最も最近のレコードを特定し統合された組からより古いレコードを除いてもよい。ブロック９１０において、サーバ２０２はクライアント１１６にレコードの統合された組を送ってもよい。他の例として、サーバ２０２は通知データストア２１０に、複数の通知レコードからの情報を反映するマージされたレコードを生成してもよい。例えば、それはユーザが特定のフォルダに複数のファイルをアップロードしたことを示す単一のレコードであり、各アップロードについての別個のレコードの代わりである。ブロック９０８におけるサーバ２０２による統合は、通知データストア２１０の内容を変更することなしに、特定のクライアントに送られるレコードの組に影響を与えることができることは理解されるべきである。したがって、任意のあるクライアントに送られる通知レコードのシーケンスは他の任意のクライアントに通知レコードを送ることによって影響を受ける必要はないのであって、これにより、各クライアントが自己が要求した任意の通知を受けることが可能となる。

ある実施の形態では、サーバ２０２による統合は繰り返し行われてもよい。例えば、上述の通り、クライアント１１６は固定数（例えば１０）の通知レコードを含む通知レコードのスタートアップ組を要求してもよい。サーバ２０２はブロック９０４においてそのクライアントについての１０個の直近のレコードを特定してもよい（例えば、クライアントに関連するユーザＩＤに基づいて）。しかしながら、ブロック９０８における統合によりレコードの数が減らされてもよく、例えば６となる。これが生じる場合、サーバ２０２は減らされた組を送ってもよい。あるいはまた、サーバ２０２は、数が１０に戻るように組にレコードを追加し、再び統合し、統合された組のレコードの数が１０（または他の所望の固定数）に至るまでこれらの行動を繰り返してもよい。

ある例では、サーバ２０２は、要求に応じて送られるべき通知レコードが存在しないと判定してもよい。その場合、サーバ２０２はクライアント１１６にこの状態を示す応答を返してもよい。

処理７００、８００および９００は例示であり、変形や変更が可能であることは理解されるであろう。逐次的に示されているステップは並列に実行されてもよく、ステップの順番は変更されてもよく、ステップは変更されても組み合わされても追加されても省略されてもよい。処理７００、８００および９００（または類似の処理）が併せて使用されることで、クライアントはユーザに現在の情報を提供しかつ旧い情報を更新する（例えば、上書きまたは除去する）リアルタイム通知フィードを提供することができる。フィードはユーザのクライアントのいずれかまたはすべてで提示されてもよい。各プラットフォームのフィードは任意のクライアントでの行動に基づいて（ほぼリアルタイムで）自動的に更新される。任意のあるクライアントへの通知レコードの配送は任意の他のクライアントへの配送と独立しているので、ユーザの各クライアントはすべての通知を受けることができ、かつ完全な現在のアラートフィードを提示できる。あるクライアントとのユーザインタラクションは他のクライアントで提示されるフィードに反映されてもよい。

本発明が具体的な実施の形態に関して説明されたが、当業者であればさまざまな変形例が可能であることを認識するであろう。例えば、本明細書で説明された特定のイベントやデータ構造やプラットフォームは例示のために使用されているのであって、他のイベントやデータ構造やプラットフォームで置き換えられてもよい。クライアントへメッセージをプッシュする技術もまた特定のクライアントについて適切となるように変更されてもよい。

上述の通り、すべての通知がすべてのクライアントまたはいずれかのクライアントでアラートを生じさせることは要求されない。通知がアラートを生じさせる場合、アラートは所望の態様でユーザに出されてもよい。アラートは視覚的要素（テキストやアイコンや画像や色など）、聴覚的要素（トーンや話語など）、触覚的要素（振動やパルスなど）、および／または他の任意の知覚可能な要素を組み入れてもよい。

上述の実施の形態はデータ構造およびデータベースまたはデータストアを参照してもよい。これらの用語は、コンピュータシステムによって保持され、取得されおよび解釈されうる個々のレコードへと情報を整理するための任意の技術を包含してもよいことは理解されるべきである。

本発明の実施の形態は、専用コンポーネントおよび／またはプログラマブルプロセッサおよび／または他のプログラマブルデバイスの任意の組み合わせを使用して実現されてもよい。本明細書で説明される種々の処理は同じプロセッサまたは任意の組み合わせの異なるプロセッサで実行されてもよい。コンポーネントが所定の動作を行うよう構成されるものとして記述される場合、そのような構成は例えば電子回路をその動作を行うよう設計することにより、またはプログラマブル電子回路（例えば、マイクロプロセッサ）をその動作を行うようプログラムすることにより、またはそれらの任意の組み合わせにより、達成されうる。さらに、上述の実施の形態は特定のハードウエアおよびソフトウエアコンポーネントに言及しているが、当業者であればハードウエアおよび／またはソフトウエアコンポーネントの異なる組み合わせが使用されてもよいこと、およびハードウエアで実行されるものとして記述されている動作がソフトウエアで実行されてもよいことおよびその逆もしかりであること、を理解するであろう。

本発明の種々の特徴を組み入れたコンピュータプログラムは符号化されて種々のコンピュータ読み取り可能保持媒体に保持されてもよい。適切な媒体は、磁気ディスク、磁気テープ、コンパクトディスク（ＣＤ）やＤＶＤ（ｄｉｇｉｔａｌ ｖｅｒｓａｔｉｌｅ ｄｉｓｋ）などの光学保持媒体、フラッシュメモリ、および他の非一時的媒体を含む。プログラムコードで符号化されたコンピュータ読み取り可能媒体はコンパチブルな電子デバイスと共にパッケージされてもよい。またはプログラムコードは電子デバイスとは別に提供されてもよい（例えば、インターネットダウンロードを介してまたは別個にパッケージされたコンピュータ読み取り可能保持媒体として）。

したがって、本発明が具体的な実施の形態に関して説明されたが、本発明は以下の請求の範囲内のすべての変形例および均等物をカバーするよう意図されていることは理解されるであろう。

Claims (30)

1. サーバで実行可能な方法であって、
   クライアントデバイスから新たな通知レコードの要求を受けることと、
   通知データストアから前記要求に応じた通知レコードの始めの組を取得することであって、前記通知レコードの始めの組は第１通知レコードを含み、前記通知レコードのそれぞれはトピックフィールドとシーケンスフィールドとコンテンツフィールドとを含むことと、
   前記通知レコードの始めの組から通知レコードの終わりの組を生成することであって、前記通知レコードの終わりの組を生成することは、
   前記第１通知レコードが通知レコードの前記組の第２通知レコードと統合されるべきか否かを、前記通知レコードの前記トピックフィールドに基づき判定することと、
   前記第１通知レコードが前記第２通知レコードと統合されるべきである場合、前記第１通知レコードの前記シーケンスフィールドおよび前記第２通知レコードの前記シーケンスフィールドに基づき、前記第１通知レコードを前記第２通知レコードと統合することと、を含むことと、
   前記通知レコードの終わりの組を前記複数のクライアントデバイスのうちの前記第１クライアントデバイスに送ることと、を含むことを特徴とする方法。
2. 各通知レコードの前記シーケンスフィールドは時間順序インジケータを含み、
   前記第１通知レコードを前記第２通知レコードと統合することは、
   前記時間順序インジケータに基づき、前記第１通知レコードおよび前記第２通知レコードのうち古い方を特定することと、
   前記第１通知レコードおよび前記第２通知レコードのうち古い方を前記通知レコードの終わりの組から除くことと、を含むことを特徴とする請求項１に記載の方法。
3. 各通知レコードの前記時間順序インジケータは、シリアル番号およびタイムスタンプの一方または両方を含むことを特徴とする請求項２に記載の方法。
4. 前記第１通知レコードを他の通知レコードと統合することは前記通知データストアに影響しないことを特徴とする請求項１に記載の方法。
5. クライアントで実行可能な方法であって、
   サーバから通知レコードを要求することと、
   前記サーバから、前記要求に応じたひとつ以上の通知レコードを受けることと、
   前記クライアントが、処理すべき通知レコードの始めの組を特定することであって、前記通知レコードの始めの組は前記サーバから受けた前記ひとつ以上の通知レコードを含み、前記通知レコードのそれぞれはトピックフィールドとシーケンスフィールドとコンテンツフィールドとを含むことと、
   前記クライアントが、前記通知レコードの始めの組から通知レコードの終わりの組を生成することであって、前記通知レコードの終わりの組を生成することは、前記始めの組の第１通知レコードの前記トピックフィールドが前記始めの組の第２通知レコードの前記トピックフィールドと一致する場合に、前記第１通知レコードを前記第２通知レコードと統合することを含むことと、
   前記通知レコードの終わりの組に基づいて、ひとつ以上のアラートを出すことと、を含むことを特徴とする方法。
6. 前記通知レコードの始めの組はさらに、前記サーバからの前記通知レコードの要求よりも前に前記クライアントに存在するひとつ以上の他の通知レコードを含むことを特徴とする請求項５に記載の方法。
7. 前記サーバから、少なくともひとつの新たな通知レコードが利用可能であることを示すメッセージを受けることをさらに含み、
   前記通知レコードを要求することは、前記メッセージを受けることに応じてなされることを特徴とする請求項５に記載の方法。
8. 前記終わりの組の各通知レコードの前記トピックフィールドは、前記終わりの組の他の通知レコードのそれぞれの前記トピックフィールドと異なることを特徴とする請求項５に記載の方法。
9. 前記第１通知レコードを前記第２通知レコードと統合することは、
   前記第１通知レコードの前記シーケンスフィールドを前記第２通知レコードの前記シーケンスフィールドと比較することと、
   前記シーケンスフィールドの比較結果に基づいて、前記第１通知レコードおよび前記第２通知レコードのうちのひとつを前記通知レコードの終わりの組から除くことと、を含むことを特徴とする請求項５に記載の方法。
10. 前記ひとつ以上のアラートを出すことは、前記ひとつ以上のアラートを含むフィードを出すことを含むことを特徴とする請求項５に記載の方法。
11. サーバで実行可能な方法であって、
    ターゲットユーザに関連するイベントに係るイベント情報を受けることと、
    前記イベント情報に基づいて通知データストアに第１通知レコードを生成することであって、前記第１通知レコードはトピックフィールドとシーケンスフィールドとコンテンツフィールドとを含み、前記トピックフィールドは前記通知データストアから同じトピックに係る複数の通知レコードを特定するのに使用可能であり、前記シーケンスフィールドは同じトピックに係る複数の通知レコードをソート順序でソートするのに使用可能であることと、
    前記第１通知レコードが利用可能であることを示す第１メッセージを生成することであって、前記第１メッセージは前記ターゲットユーザの識別子と前記第１通知レコードの識別子とを含み、前記識別子は前記第１メッセージを受けるものが前記通知データストアから前記第１通知レコードを取得するのに使用可能であることと、
    前記ターゲットユーザに関連する複数のクライアントへ前記第１メッセージを発することと、を含み、
    前記複数のクライアントのそれぞれへ前記第１メッセージを発することは、他の任意のクライアントへ前記第１メッセージを発することと独立であることを特徴とする方法。
12. 前記複数のクライアントデバイスのうちの第１クライアントデバイスから新たな通知レコードの要求を受けることと、
    前記要求に応じた通知レコードの始めの組を特定することであって、前記通知レコードの組は前記第１通知レコードを含むことと、
    前記通知レコードの始めの組から通知レコードの終わりの組を生成することであって、前記通知レコードの終わりの組を生成することは、前記第１通知レコードの前記トピックフィールドが前記始めの組の他の通知レコードの前記トピックフィールドと一致する場合に、前記第１通知レコードを前記他の通知レコードと統合することを含むことと、
    前記通知レコードの終わりの組を前記複数のクライアントデバイスのうちの前記第１クライアントデバイスに送ることと、をさらに含むことを特徴とする請求項１１に記載の方法。
13. 前記第１通知レコードを前記他の通知レコードと統合することは、
    前記第１通知レコードの前記シーケンスフィールドを前記他の通知レコードのシーケンスフィールドと比較することと、
    前記シーケンスフィールドの比較結果に基づいて、前記第１通知レコードおよび前記他の通知レコードのうちのひとつを前記通知レコードの終わりの組から除くことと、を含むことを特徴とする請求項１２に記載の方法。
14. 前記第１通知レコードの前記シーケンスフィールドを前記他の通知レコードのシーケンスフィールドと比較することは、前記第１通知レコードおよび前記第２通知レコードのうちどちらがより古いかを特定することを含み、前記第１通知レコードおよび前記第２通知レコードのうち古い方は前記通知レコードの終わりの組から除かれることを特徴とする請求項１３に記載の方法。
15. 通知データストアと、
    前記通知データストアと接続されているプロセッサと、を備え、
    前記プロセッサは、
    クライアントデバイスから新たな通知レコードの要求を受け、
    通知データストアから前記要求に応じた通知レコードの始めの組を取得し、ここで前記通知レコードのそれぞれはトピックフィールドとシーケンスフィールドとコンテンツフィールドとを含み、
    前記通知レコードの始めの組から通知レコードの終わりの組を生成し、ここで前記通知レコードの終わりの組を生成することは、前記始めの組からのふたつ以上の通知レコードが互いに一致するトピックフィールドを有する場合、前記ふたつ以上の通知レコードを統合することを含み、
    前記通知レコードの終わりの組を前記クライアントデバイスに送る
    よう構成されていることを特徴とするサーバシステム。
16. 前記通知レコードのそれぞれはイベントに対応し、
    前記通知レコードのそれぞれの前記トピックフィールドは、
    前記イベントのイベントタイプを示すタイプ識別子と、
    前記イベント中に作用を受ける対象を示すターゲット対象識別子と、
    前記イベントを知らせるべきターゲットユーザを示すターゲットユーザ識別子と、
    を含むことを特徴とする請求項１５に記載のサーバシステム。
17. 前記クライアントデバイスから受けた前記要求はクライアントユーザ識別子を含み、前記通知レコードの始めの組はその前記ターゲットユーザ識別子が前記クライアントユーザ識別子と一致する通知レコードのみを含むことを特徴とする請求項１６に記載のサーバシステム。
18. 前記プロセッサはさらに、前記タイプ識別子、前記ターゲット対象識別子、前記ターゲットユーザ識別子のそれぞれが同一の場合にのみ、ふたつ以上の通知レコードを統合するよう構成されていることを特徴とする請求項１６に記載のサーバシステム。
19. データ通信インタフェースと、
    ユーザインタフェースと、
    前記データ通信インタフェースおよび前記ユーザインタフェースと接続されているプロセッサと、を備え、
    前記プロセッサは、
    サーバから、ひとつ以上の通知レコードを受け、ここで前記通知レコードのそれぞれはトピックフィールドとシーケンスフィールドとコンテンツフィールドとを含み、
    処理すべき通知レコードの始めの組を特定し、ここで前記通知レコードの始めの組は前記サーバから受けた前記ひとつ以上の通知レコードを含み、
    前記通知レコードの始めの組から通知レコードの終わりの組を生成し、ここで前記通知レコードの終わりの組を生成することは、前記トピックフィールドが一致するふたつ以上の通知レコードを統合することを含み、
    前記通知レコードの終わりの組に基づいて、ひとつ以上のアラートを出すよう構成されていることを特徴とするクライアント。
20. 前記通知レコードのそれぞれはイベントに対応し、
    前記通知レコードのそれぞれの前記トピックフィールドは、
    前記イベントのイベントタイプを示すタイプ識別子と、
    前記イベント中に作用を受ける対象を示すターゲット対象識別子と、
    前記イベントを知らせるべきターゲットユーザを示すターゲットユーザ識別子と、
    を含むことを特徴とする請求項１９に記載のクライアント。
21. 前記タイプ識別子、前記ターゲット対象識別子、前記ターゲットユーザ識別子のそれぞれが同一である場合にのみ、ふたつ以上の通知レコードが統合されることを特徴とする請求項１９に記載のクライアント。
22. 通知データストアと、
    前記通知データストアと接続されているプロセッサと、を備え、
    前記プロセッサは、
    ターゲットユーザに関連するイベントに係るイベント情報を受け、
    前記イベント情報に基づいて前記通知データストアに通知レコードを生成し、ここで前記通知レコードはトピックフィールドとシーケンスフィールドとコンテンツフィールドとを含み、前記トピックフィールドは前記通知データストアから同じトピックに係る複数の通知レコードを特定するのに使用可能であり、前記シーケンスフィールドは同じトピックに係る複数の通知レコードをソート順序でソートするのに使用可能であり、
    前記通知レコードが利用可能であることを示すメッセージを生成し、ここで前記メッセージは前記ターゲットユーザの識別子と前記通知レコードの識別子とを含み、前記通知レコードの前記識別子は前記メッセージを受けるものが前記通知データストアから前記通知レコードを取得するのに使用可能であり、
    前記ターゲットユーザに関連する複数のクライアントへ前記メッセージを発するよう構成され、
    前記複数のクライアントのそれぞれへ前記メッセージを発することは、他の任意のクライアントへ前記メッセージを発することと独立であることを特徴とするサーバシステム。
23. 前記シーケンスフィールドはシリアル番号を含み、前記シリアル番号は前記第１通知レコードの前記識別子として前記第１メッセージに含まれることを特徴とする請求項２２に記載のサーバシステム。
24. 前記トピックフィールドは、
    前記イベントタイプを示すタイプ識別子、
    前記イベント中に作用を受ける対象を示すターゲット対象識別子、または
    前記ターゲットユーザの前記識別子
    のうちのひとつ以上を含むことを特徴とする請求項２２に記載のサーバシステム。
25. 前記シーケンスフィールドは、
    単調に増加するよう前記サーバによって割り当てられるシリアル番号と、
    前記第１通知レコードの生成時刻を示す送信時刻と、
    を含むことを特徴とする請求項２２に記載のサーバシステム。
26. 前記複数のクライアントへ前記メッセージを発することは、複数のメッセージディスパッチャのそれぞれによって読み取り可能なメッセージキューに前記メッセージを書き込むことを含み、
    各メッセージディスパッチャは前記メッセージを読み出し、前記複数のクライアントのうちのひとつ以上に渡すための対応するクライアント専用メッセージを生成するよう構成されていることを特徴とする請求項２２に記載のサーバシステム。
27. 複数の通知レコードを保持する保持手段と、
    クライアントデバイスから新たな通知レコードの要求を受ける手段と、
    前記保持手段から前記要求に応じた通知レコードの始めの組を取得する手段であって、前記通知レコードのそれぞれはトピックフィールドとシーケンスフィールドとコンテンツフィールドとを含む手段と、
    前記通知レコードの始めの組から通知レコードの終わりの組を生成する手段であって、前記通知レコードの終わりの組を生成することは、前記始めの組からのふたつ以上の通知レコードが互いに一致するトピックフィールドを有する場合、前記ふたつ以上の通知レコードを統合することを含む手段と、
    前記通知レコードの終わりの組を前記クライアントデバイスに送る手段と、を備えることを特徴とするサーバシステム。
28. 前記通知レコードのそれぞれはイベントに対応し、
    前記通知レコードのそれぞれの前記トピックフィールドは、
    前記イベントのイベントタイプを示すタイプ識別子と、
    前記イベント中に作用を受ける対象を示すターゲット対象識別子と、
    前記イベントを知らせるべきターゲットユーザを示すターゲットユーザ識別子と、
    を含むことを特徴とする請求項２７に記載のサーバシステム。
29. 前記通知レコードの終わりの組を生成する前記手段は、ふたつ以上の通知レコードの前記タイプ識別子、前記ターゲット対象識別子、前記ターゲットユーザ識別子のそれぞれが同一である場合にのみ、該ふたつ以上の通知レコードを統合することを特徴とする請求項２８に記載のサーバシステム。
30. ターゲットユーザに関連するイベントに係るイベント情報を受ける手段と、
    前記イベント情報に基づいて前記保持手段に通知レコードを生成して保持する手段であって、前記通知レコードはトピックフィールドとシーケンスフィールドとコンテンツフィールドとを含み、前記トピックフィールドは前記通知データストアから同じトピックに係る複数の通知レコードを特定するのに使用可能であり、前記シーケンスフィールドは同じトピックに係る複数の通知レコードをソート順序でソートするのに使用可能である手段と、
    前記通知レコードが利用可能であることを示すメッセージを生成する手段であって、前記メッセージは前記ターゲットユーザの識別子と前記通知レコードの識別子とを含み、前記通知レコードの前記識別子は前記メッセージを受けるものが前記通知データストアから前記通知レコードを取得するのに使用可能である手段と、
    前記ターゲットユーザに関連する複数のクライアントへ前記メッセージを発する手段と、
    をさらに備え、
    前記複数のクライアントのそれぞれへ前記メッセージを発することは、他の任意のクライアントへ前記メッセージを発することと独立であることを特徴とする請求項２７に記載のサーバシステム。

Images