JP2012502371A5 - 協調的なショートメッセージ及びディスカッションのためのシステム及び方法 - Google Patents

Description

本発明はインターネットを介して電子的メッセージを送受信することに関し、より詳細には協調的なショートメッセージ及びディスカッションのためのシステム及び方法に関する。

オンライン又はモバイルによるソーシャルネットワーキングのアプリケーションにより、ユーザーは他のユーザーへ又は他のユーザーからのメッセージを送信したり受信したり、オンラインでアカウントを作ったり、他のユーザーにより貼り付けられたメッセージを見たりすることができる。一般に、ユーザーはプロフィールを作成し、そしてユーザーのネットワークに参加するよう他のユーザーを招いたり、コンピュータ上に記録された現存する関係を見つけ出すソフトウェアを用いることにより、彼らのネットワークに関連するユーザーを定義する（例えば、フェイスブック、マイスペース、及びリンクトイン）。

より近年においては、マイクロブログが協調的ディスカッションの効果的方法となってきており、参加者は特定の話題に関していかなる時間においても情報を共有することができる。マイクロブログのソーシャルネットワーク（例えば、ツィッター）において、ユーザーはウェブサイト、ショートメッセージサービス（ＳＭＳ）又は専用アプリケーションソフトウェアを介してメッセージを送信したり受信したりすることができる。しかし、典型的なソーシャルネットワーキングのアプリケーションのように、マイクロブログのソーシャルネットワークは最小限のメッセージをスレッドする能力を有する。特定の話題に関し最も最近の情報を検索するユーザーは関係しない多くのメッセージを見ることとなる。なぜなら、メッセージのコアはその検索されている話題には必ずしも関係しないからである。

協調的なショートメッセージ及びディスカッションのためのシステム及び方法を説明する。一実施形態によれば、協調的なショートメッセージ及びディスカッションのためのコンピュータにより実行される方法は、現存する共有属性に基づいてユーザーをクライアントネットワークにグループ化することを含む。システムリソースはクライアントネットワ ークに亘ってメッセージングするために区分けされる。クライアントネットワーク内のユーザーはそのクライアントネットワーク内のメッセージに対してのみ見る又は返信することができる。

本特許出願は引用により本明細書に組み込まれる、「協調的なショートメッセージ及びディスカッションのためのシステム及び方法」の名称で２００８年９月５日に出願された、米国仮特許出願第６１／０９４，８１８号に基づく利益及び優先権を主張する。

本明細書の一部として含まれる添付図面は本発明の現在の最もより好ましい実施形態を説明するものであり、上述の一般的な説明及びより好ましい実施形態の詳細な説明と共に本発明の原理を説明及び教示するのに役立つ。

一実施形態による協調的なショートメッセージ及びディスカッションのための例示的なシステムを示す図である。 一実施形態による本システムと共に用いられるウェブクライアントインターフェイスの例示的な実施形態を示す図である。 一実施形態によるメッセージ配布のための例示的なプロセスのブロック図である。 一実施形態によるメッセージ処理のための例示的なプロセスのフローチャートである。 一実施形態によるメッセージを保持し関連づけるための例示的なデータ構造を示す図である。 一実施形態によるメッセージのブロードキャスティングのための例示的なプロセスのフローチャートである。 一実施形態によるメッセージフィードをキャッシュするための例示的なプロセスのフローチャートである。 一実施形態によるウェブメッセージのリクエストのための例示的なプロセスのフローチャートである。

図面は必ずしも比例して描かれているわけではなく、また概して同様の構造又は機能の要素については各図を通して説明の目的のために同様の参照番号により表されている。また、図面は本明細書内に記載された様々な実施形態の説明を促すためのみのものである。図面は、本明細書に記述される開示の各態様を記述するものではなく、特許請求の範囲を制限するものではない。

協調的なショートメッセージ及びディスカッションのためのシステム及び方法が開示される。一実施形態によると、コンピュータネットワークのショートメッセージ及びディスカッションシステムは現存するグループ内の協調のために設計される。機能は、メッセー ジのスレッド化と、個人のメッセージ及びグループのキーワードによるタグ付けを含む。

一実施形態において、本システムはネットワークにより区分けされている。ユーザーは彼らのＥメールアドレスのドメイン部分に基づきクライアントネットワークにグループ化される。例えば、ｊｏｅ＠ｆｏｏ．ｃｏｍ及びｂｏｂ＠ｆｏｏ．ｃｏｍは双方ともｆｏｏ．ｃｏｍクライアントネットワークのメンバーであり、そのメンバーのみがそのコンテンツにアクセスすることができる。ネットワーククライアントの間でデータのオーバーラップがないので、データベース及び他のリソースはネットワークのグループに区分けること ができる。

説明の目的のために、以下の説明では、本明細書において開示される様々な発明性あるコンセプトの完全な理解をもたらすように特定の用語が用いられている。しかしながら、本明細書において開示される様々な発明性あるコンセプトを実施するために、これらの特 定の詳細が必ずしも必要ではないことは本技術分野の当業者にとって明白である。

システムアーキテクチャー
図１は一実施形態による協調的なショートメッセージ及びディスカッションのための例示的なシステムを示す。システム１００はクライアントデバイス１０３、１０４、１１３、１１４、クライアントデバイスが関連するクライアントネットワーク１０５、１１５、インターネット１１０、ネットワーク１０１、ウェブサーバ１２０、ユーザーストレージ １２５、メッセージプロセッシング・ブロードキャスティングサーバ１３０、メモリキャッシュ１４０、インスタントメッセージ（ＩＭ）サーバ１５０、データベース１６０、エンタープライズサーチサーバ１７０、Ｅメールサーバ１８０、及びＳＭＳサーバ１９０を含む。

システム１００はインターネット１１０及びネットワーク１０１によって相互接続される。一実施形態によると、ネットワーク１０１はインターネットであるとして説明されているが、あるいは、ネットワーク１０１は、ワイドエリアネットワーク（ＷＡＮ）、ローカルエリアネットワーク（ＬＡＮ）、又は２つ以上のデバイスが情報を交換可能にする他の相互接続システムであってもよい。

１つ以上のクライアントデバイス１０３、１０４、１１３、１１４により、ＨＴＭＬ及びジャバスクリプトをサポートするマイクロソフトのインターネットエクスプローラ、アップルのサファリ、モズィーラ、ファイアフォックス、又はウェブを介してネットワーク にアクセスできる他のブラウザ等のブラウザを介してウェブにアクセスすることができる。クライアントデバイス１０４、１１３、１１４はパーソナルコンピュータであることが できる。クライアントデバイス１０３はウェブ対応の電話又は他のウェブ対応のモバイルデバイスである。あるいは、クライアントデバイス１０３はＳＭＳが可能なウェブ非対応 のモバイルフォンであることができる。

クライアントデバイス１０３、１０４、１１３、１１４のユーザーは、クライアントネットワークにグループ化される。システム１００内のユーザーは、単一のクライアントネットワークに関連する特定の人のアカウントである。クライアントネットワークは、ユーザー、メッセージ、キーワードのタグの集合体である。クライアントネットワークにおいて、ユーザーのみがそのクライアントネットワーク内の他のユーザーのパブリックインフォメーションを見ることができ、クライアントネットワークの外部のユーザーは、彼らがそのようなクライアントネットワークに特にアクセスを許されていなければ、クライアントネットワーク内のいかなる情報も見ることはできない。より好ましい実施形態において、ユーザーはユーザーのＥメールアドレスのドメイン部分に基いて、クライアントネットワークにグループ化される。例えば、図１において、クライアントデバイス１０３及び１０４のユーザーはクライアントネットワーク１０５においてグループ化される。なぜなら、彼らは同じＥメールドメイン（例えば、ｊｏｅ＠ｆｏｏ．ｃｏｍ及びｂｏｂ＠ｆｏｏ．ｃｏｍ）を共有しているからである。同様に、クライアントデバイス１１３、１１４のユーザーはクライアントネットワーク１１５にグループ化される。なぜなら、彼らは同じＥメールドメインを共有しているからである。

ウェブサーバ１２０は、ハイパーテキストトランスファープロトコル（ＨＴＴＰ）、ファイルトランスファプロトコル（ＦＴＰ）、エクステンシブルメッセージングアンドプレ ゼンスプロトコル（ＸＭＰＰ）、又は他の同様な接続プロトコルを含むプロトコル及び／又はアプリケーションのいずれかを用いるウェブサーバである。オペレーティングシステムは、ウィンドウズ、リナックス、サンソラリス、マックＯＳ、又は他の同様なオペレーティングシステムであることができる。ユーザーは、ウェブサーバ１２０上にアカウントをつくり、クライアントネットワークにグループ化される。メッセージは、インターネット１１０を介してクライアントデバイス１０３、１０４、１１３、又は１１４からウェブサーバ１２０に送られる。メッセージは、ウェブサーバ、Ｅメールサーバ１８０、及び／又はＳＭＳサーバ１９０を介して受信される。

メッセージプロセッシング・ブロードキャスティングサーバ１３０は、メッセージの内容を処理し、メッセージのキューを操作し、システム１００内の適宜なリソースにメッセージを方向づけることのできるサーバである。オペレーティングシステムはウィンドウズ、リナックス、サンのソラリス、マックＯＳ、又は他の類似のオペレーティングシステムであることができる。メッセージプロセッシング・ブロードキャスティングサーバ１３０ は、Ｅメールサーバ１８０、ＳＭＳサーバ１９０、ＩＭサーバ１５０、メモリキャッシュ１４０、データベース１６０、及びエンタープライズサーチサーバ１７０ヘメッセージを配信することができる。

インスタントメッセージサーバ１５０は、エクステンシブルメッセージングアンドプレ ゼンスプロトコル（ＸＭＰＰ）、ｅｊａｂｂｅｒｄ、バイディレクショナルストリームズ オーバＨＴＴＰ（ＢＯＳＨ）を含むインスタントメッセージを送信するためのプロトコル及び／又はアプリケーションを用いるサーバである。

エンタープライズサーチサーバ１７０は、ＡｐｃｈｅのＳｏｌｒ等のエンタープライズ検索用プロトコル及び／又はアプリケーションを用いるサーバである。

ユーザーストレージ１２５はファイル保管を行うことができるストレージドライブ又は他のデバイスである。好ましくは、ユーザーの写真はユーザーストレージ１２５に保管される。

図２は、一実施形態に係る、本システムで使用されるウェブクライアントインターフェイスの例示的な実施形態を示す。一実施形態において、ウェブクライアントインターフェイス２２０はクライアントデバイス２００上でウェブブラウザ２１０を介して動作する。他の実施形態において、ウェブクライアントインターフェイス２６０は、例えば、マイクロソフトのウィンドウズ又はマックＯＳが動作しているパーソナルコンピュータ用の特定 のアプリケーションソフト、又はアップルのｉｐｈｏｎｅ、リムのブラックベリー、又はグーグルのアンドロイド等のモバイルデバイス用のアプリケーションソフトである。

図３は本発明によるメッセージ配布のためのプロセスのブロック図を示す。メッセージは接続されるすべてのクライアントに配布される必要がある。これはウェブクライアントインターフェイス３９０、ＳＭＳ３７５，Ｅメール３７０、インスタントメッセージ３８０、又は他の通信スキームを介して接続されるクライアントを含む。一実施形態によると、システム１００はそれを要求するユーザーに「すべての」フィードを配信する。追加の実施形態は、このフィードのレートを制限する（及びメッセージングレートが高すぎた場 合に、メッセージを捨てる）、又は単に一部の又はすべてのクライアントに対してオプションとしてそれを取り除くことを含む。

新しいメッセージ３００が送出される前に、それはクライアントデバイス上のメッセージポストハンドリング３１０の支配を受ける。例えば、メッセージポストハンドリングの間に、ユーザーは送信される前にそのメッセージを見ることができる。そのメッセージがクライアントデバイスから送出され、システムによって受信されると、そのメッセージは図４において詳細に説明されるメッセージプロセッシング３２０の支配を受ける。メッセージプロセッシング３２０の後、その新しいメッセージはシステムリソース全体にばらまかれる。これらはエンタープライズサーチ３３０、データベース３４０、メッセージフィード３５０、メッセージブロードキャスティング３６０を含む。エンタープライズサーチ３３０によりメッセージ内のワード検索が可能となる。フィードインボックス３５０はその新しいメッセージをそのメッセージが関連するすべてのメッセージフィードに関連づけ、データベース３６０はそのメッセージをアーカイブする。

配信を行うために、どのメッセージフィードをユーザーが欲しているか及びどの配信方 法（例えば、ＩＭ、ＳＭＳ、Ｅメール）が使われるかを記述する通知テーブルが参照され る。メッセージブロードキャスティング３６０の間、メッセージはユーザーが配信のためにどの方法を（例えば、ＩＭ、ＳＭＳ、Ｅメール）を起動したかによって、適宜な配信システムにメッセージは転送される。いくらかの配信システムは更なるコンフィグレーションパラメータ（例えば、配信タイムのウィンドウ、又はグローバルオン／オフトグル）を 有してもよく、及びコンフィグレーションパラメータはメッセージを配信する前に参照される。

メッセージのタグ付け
協調的なショートメッセージ及びディスカッションのための本システムにおいて、ユーザーはユーザーに対するメッセージ及び／又はキーワードにタグをつけるオプションを有する。このタグをつける機能により、ユーザーはそのメッセージの作成の間に関連するメッセージフィードにメッセージを途切れることなく方向付けることができる。また、それによりそのクライアントネットワーク内のユーザーは、特定のユーザーにタグ付けされたメッセージ又は特定のキーワードにタグ付けされたメッセージを求めてクライアントネットワークを検索することができる。更に、これによりユーザーはユーザーの特定のタグを含むメッセージフィードを取得することができる。一実施形態において、ユーザーはユー ザー名の前に「＠」をつけることによりメッセージ本文中の他のユーザーをタグ付けすることができる。同様にユーザーはキーワードの前にシャープ「＃」記号を付けることによ りキーワードをタグ付けすることができる。

例えば、ザックパーカー（Ｚａｃｋ Ｐａｒｋｅｒ）： こんにちは、＠ｋｇａｌｅ、彼が＃ｗｏｒｋｆｅｅｄ用の＃ｉｍゲートウェイを終えたかどうかを確認するために＠ａｐｉｓｏｎｙにチェックしてください。

ユーザーのザックパーカーからのこのメッセージは、ユーザーのｋｇａｌｅ及びａｐｉｓｏｎｙと共に、「ｉｍ」及び「ｗｏｒｋｆｅｅｄ」にタグ付けされている。このメッセージへの返信は、これらのタグのすべて（キーワードとユーザーの両方）を継承するので、このタグを伴うユーザーは、人々が忘れないでスレッド内のすべてのメッセージにタグ 付けし続ける必要なしに関連する返信を見ることができる。例えば、ザックパーカーに返信するディビットサックス（Ｄａｖｉｄ Ｓａｃｋｓ）：
ディビットサックス： 私はちょうどアダムと話しました。彼はすでに終えており、彼の＃ｓｋｙｎｅｔプレゼンテーションへ進むと言っていました。

ユーザーのザックパーカーからのオリジナルメッセージへのユーザーのディビットサッ クスからのこの返信は、ユーザーｋｇａｌｅ及びａｐｉｓｏｎｙ、キーワード「ｉｍ」、「ｗｏｒｋｆｅｅｄ」、そしてここでキーワード「ｓｋｙｎｅｔ」にタグ付けされている。「ｓｋｙｎｅｔ」のタグはオリジナルのメッセージには適用されないが、このメッセージへのいかなる返信にも適用されるだろうことに留意すべきである。

まず、新しいメッセージがそのメッセージのキューから取り出され（４００）、そのメッセージの本文はタグ付けされたユーザー名（４１０）が検索される。ユーザー名のタグが見つけられると（４２０）、その送り手のクライアントネットワークが検索され、クライアントネットワーク内にそのタグ付けされたユーザー名が存在するかどうかを判定する（４２３）。タグ付けされたユーザー名がクライアントネットワーク内に存在するなら、ユーザー名のタグが参照番号としてメッセージに追加され（４２５）、プロセスは次に進む。もしユーザー名のタグが見つからないのであれば（４２０）、又はユーザー名がその送り手のクライアントネットワーク内に存在しないのであれば、プロセスは次に進む。

メッセージの本文は、タグ付けされたキーワードを検索される（４３０）。もしキーワードのタグが見つかれば（４４０）、システムはそのキーワードは既に送り手のクライアントネットワーク内にキーワードとして存在するかどうかをチェックする（４４３）。もしタグ付けされたキーワードがキーワードとしてクライアントネットワーク内に現時点で存在しないのであれば、キーワードのタグはクライアントネットワーク内でつくられ（４４５）、キーワードのタグはレファレンス（参照）としてメッセージに追加される（４４７）。もしタグ付けされたキーワードが既に送り手のクライアントネットワーク内にキーワードとして存在するのであれば、それはレファレンスとしてメッセージに追加される（４４７）。

メッセージがタグに対して検査されると、そのメッセージが他のメッセージへの返信であるかどうかが判定される（４５０）。その判定の結果として（４５０）、もしそのメッセージが返信であれば、そのメッセージはオリジナルのメッセージのメッセージＩＤを受け取り（４６０）、オリジナルのメッセージのスレッドＩＤを継承する（４７０）。これによりメッセージのスレッド化が可能となる。返信でないメッセージには、その新しいメッセージＩＤに合致する新しいスレッドＩＤが割り当てられる。メッセージのＩＤがそのスレッドＩＤに一致すると、それは「ｔｈｒｅａｄ ｓｔａｒｔｅｒ」（スレッドスタータ）である。このように、スレッドがたった一つのレベルの深さであるとき、返信はそれらが返信するメッセージの情報を維持する。

メッセージの本文内のタグは、そのメッセージがウェブクライアントインターフェイス上に表示されると、後でリンク又は同様のメカニズムにより代替される特別なトークンとして保管される（４８０）。メッセージの本文内のすべてのタグがトークン化されると（４８０）、そのメッセージは保存され（４９０）、受信者への通知のためにキューに加えられる（４９５）。

メッセージの構造
協調的なショートメッセージ及びディスカッションのための本システムにおいて、メッセージは比較的小さいものであるが、多くのアップデートがＳＭＳ及びＩＭを介して掲載 される。より好ましい実施形態において、ウェブクライアントインターフェイスは小さいメッセージを推奨することを考えれば、ほとんどのメッセージは２００文字以下であるが、文字制限は課せられていない。図５は一実施形態によるメッセージを保管するための例示的なデータ構造を示す。

新しいメッセージは、メッセージテーブル内に、本文から始まり参照番号が続き、最後にメタデータを伴ったキューによって保管される。これによりメッセージＩＤのシーケンスに現れる新しいメッセージは即座に配信可能であることを保証する。

メッセージの構造は、テーブル５００、及び関連するテーブル５１０及び５２０からなる。一実施形態によると、テーブル５００は、メッセージＩｄ５０１、そのメッセージが関連するネットワーク、つまりネットワークｉｄ（Ｎｅｔｗｏｒｋ＿ｉｄ）５０２、及びメッセージ本文又はメッセージ本文へのポインタ、つまり本文５０３を含む。関連するテーブル５１０は、メッセージの送出及びスレッド化のための情報を含む。これらは、Ｉｄ５１１、ネットワークｉｄ５１２、返信ｉｄ（Ｒｅｐｌｉｅｄ＿ｉｄ）５１３、スレッドｉｄ（Ｔｈｒｅａｄ＿ｉｄ）５１４、センダーｉｄ（Ｓｅｎｄｅｒ＿ｉｄ）５１５、センダータイプ（Ｓｅｎｄｅｒ＿ｔｙｐｅ）５１６、及びレフｉｄ（Ｒｅｆ＿ｉｄ）５１７を含む。関連するテーブル５２０は、タグ付けされたキーワード等のメッセージのレファレンスのための情報を含む。これらは、Ｉｄ５２１、ネットワークｉｄ５２０、レファレンスｉｄ（Ｒｅｆｅｒｅｎｃｅ＿ｉｄ）５２３、レファレンスタイプ（Ｒｅｆｅｒｅｎｃｅ ＿ｔｙｐｅ）５２４、レファレンスアズ（Ｒｅｆｅｒｅｎｃｅ＿ａｓ）５２５、及びレフｉｄ５２６を含む。

レファレンストアズと呼ばれる列により、個々のメッセージに異なるタイプのレファレンスを関連づけることが可能となる。レファレンストアズの可能な値は、「ｒｅ」、「ｔｏ」、「ｔａｇｇｅｄ」、又は「ｉｎ＿ｔｈｒｅａｄ」である。「ｒｅ」のタイプは、参 照されたタイプがユーザーであり、そのユーザーはこのメッセージが返信しているメッセージの送り手であるときに用いられる。例えば、ディビットが返信したメッセージをザッ クが送るとき、ディビットのメッセージは、彼のユーザーオブジェクトへのレファレンストＩＤ／レファレンストタイプマップ及びレファレンストアズが「ｒｅ」に設定されたメッセージレファレンスレコードを有するだろう。「ｔｏ」のタイプは、メッセージを方向づけることができる。「Ｔａｇｇｅｄ」は、＠又は＃又は類似のタグ付け識別子を用いてメッセージの本文内で明らかにタグ付けされたものに対して用いられる。「Ｉｎ＿ｔｈｒ ｅａｄ」は、レファレンスがスレッド内の前のメッセージから継承されているときに用いられる。

協調的なショートメッセージ及びディスカッションのための本システムは、レファレンス内の値が「ｔａｇｇｅｄ」又はそれ以上、つまり単なる「ｉｎ＿ｔｈｒｅａｄ」ではな く「ｒｅ」、「ｔｏ」又は「ｔａｇｇｅｄ」であるかどうかを判定するために階層としてこのリストを用いる。この階層はまた、同じレファレンスを２回保存することを防ぐためにも用いられる。ユーザーのディビットがユーザーのａｐｉｓｏｎｉに返信して、また本 文内に＠ａｐｉｓｏｎｉを記入すると、「ｔａｇｇｅｄ」の代わりに「ｒｅ」が用いられ、１つのレファレンスのみが保存される。

上記に例示した返信から、４つの承継されたレファレンス（＃ｉｍ、＃ｗｏｒｋｆｅｅｄ、＠ａｐｉｓｏｎｙ、＠ｋｇａｌｅ）がレファレンストアズ＝ｉｎ＿ｔｈｒｅａｄとし て保存され、新しいレファレンス（＃ｓｋｙｎｅｔ）がレファレンストアズ＝ｔａｇｇｅ ｄとして保存される。もう一つの「ｒｅ」レファレンスが、ザックパーカーを表すユーザーのために追加されなければならないだろう。

「ｔａｇｇｅｄ」と「ｉｎ＿ｔｈｒｅａｄ」との間の区別は、タグのページ上に見えるメッセージのリスト（ｉｎ＿ｔｈｒｅａｄ又はそれ以上）をユーザーの「ｒｅｃｅｉｖｅ ｄ」（受信）タグ上に見えるメッセージのリスト（ｔａｇｇｅｄ又はそれ以上）と比較することによりもっともうまく説明され得る。そこに示されるすべてのメッセージは明確にメッセージの本文内のユーザーを参照するので、これにより受信したタグをより明確にする。

オリジナルメッセージのスレッドＩＤを継承すると共に、オリジナルのＩＤを新しいメッセージにタグ付けする返信機能をユーザーにもたらすことにより、スレッド化は達成さ れる。返信でないメッセージは、そのメッセージＩＤにマッチングする新しいスレッドＩ Ｄが与えられ、メッセージＩＤがそのスレッドＩＤに一致する場合、それは「ｔｈｒｅａ ｄ ｓｔａｒｔｅｒ」である。

メッセージのブロードキャスト
図６は一実施形態によるメッセージのブロードキャストのための例示的なプロセスのフローチャートを示す。このプロセスはメッセージのキューから１つのメッセージを引き出すことにより開始する（６００）。このプロセスはそのメッセージが関連するすべてのメッセージフィードを判定する（６１０）。そのメッセージが関連する各メッセージフィードに対して（６１０）、そのプロセスはどのユーザーがそれらのフィードを受信したかを 判定する（６２０）。そのフィードを受信した各ユーザーに対して、そのプロセスはそのユーザーがどの配信方法（例えば、Ｅメール、ＳＭＳ、ＩＭ）を起動したかを判定する（６３０）。そしてそのメッセージは、ステップ６１０、６２０、６３０に従い各ユーザーが起動した配信方法に転送され、そのプロセスはメッセージがメッセージのキュー内にある限り繰り返される（６００）。

メッセージフィード及びサブスクリプション（登録）
非常に大量のユーザー及びメッセージを扱うためにシステムを拡大することを可能とするために、本システムはメッセージをその作成時にフィード内にまとめる。この協調的なショートメッセージ及びディスカッションのための本システムは、いくつかの方法により関連するメッセージ又はフィードの集合体を識別する。

メッセージを見たいと望むユーザーは適宜なフィードを選択し、リレーショナルデータベースに対して高価な（例えば、時間が掛かり、資源を消費する）クエリー（検索要求） を行う必要なしに、そのフィード内のメッセージにすぐにアクセスする。本システムは大 きさに関していくつかの次元を取り扱う、つまり書くよりも多く読むので、メッセージの可視存続期間の間に数百回又は数千回ではなく、メッセージの作成中に１回、処理されるべき与えられたコンテキストの中でメッセージが可視化されるべきかどうかを把握する困 難な作業を本システムは可能にする。

メッセージの配信は、メッセージポーリングの間に用いられるフィードキャッシュに直接に書き込む。これによりシステムは、リレーショナルデータベースを用いることなしに、又はハードドライブからメッセージをフェッチすることなしに、メモリ上のキャッシュから膨大な量のフィードを処理することができる。

メッセージフィードの例は、特定のクライアントネットワーク内のすべてのパブリックメッセージ、特定のグループでない特定のクライアントネットワーク内のすべてのメッセージ、特定のユーザーからのメッセージ、特定のユーザーにより送られたメッセージ、特定のグループ内のメッセージ、特定のユーザーによる特定のグループ内のメッセージ、特定のキーワードがタグ付けされた特定のグループ内のメッセージ、特定のユーザーへのプライベートメッセージ、特定のキーワードがタグ付けされたメッセージ、特定のユーザー によって「ｆｏｌｌｏｗｅｄ」（フォローされた）すべてのボットからのメッセージ（後 述のサブスクリプションを参照のこと）、特定のボットからのメッセージ、特定のユーザーを参照する又は特定のユーザーへ返信するメッセージ、返信のチェーンを表すメッセージ、特定のユーザーによってフォローされたメッセージ（後述のサブスクリプションを参 照のこと）、返信チェーンにより構成されていないメッセージの特別なコレクションである特定の会話内のメッセージ、特定のユーザーによりお気に入りとしてマークされたメッセージを含む。

一実施形態によると、サブスクリプションは２つの真実に帰着する。サブスクリプショ ンの第１の真実は、１人のユーザーが別のユーザーのメッセージフィードに登録する、又 はタグ付けされたキーワード用のフィードに登録したときに発生する。サブスクリプショ ンの第２の真実は、１人のユーザーがフィード用に特定の配信方法（例えば、Ｅメール、 ＳＭＳ、ＩＭ）を選んだときに発生する。

図７は、一実施形態によるメッセージフィードをキャッシュするためのプロセスのブロック図を示す。新しいメッセージ（７００）は、各関連するユーザーのサブスクリプションのために次のフィードキャッシュに書き込まれる（７１０）。そして、メッセージは各関連するユーザーのカスタムタブ用のカスタムタブフィードキャッシュに書き込まれる（７２０）。そして、ユーザーがそのメッセージの送り手であるかどうか及びそのメッセージが返信であるかどうかが判定される（７３０）。ユーザーがメッセージの送り手であり、そのメッセージが返信であれば（７３０）、メッセージはそのメッセージスレッド内のすべての参加者用の関連するフィードキャッシュに書き込まれる（７４０）。

メッセージ内の各レファレンスに対して、そのレファレンスがそのユーザヘのものであるかどうかが判定される（７５０）。そのユーザーへの（「ｔｏ」）参照を伴うメッセー ジ、そのユーザーへの返信（「ｒｅ」）のメッセージ、又はそのユーザーがメッセージ内でタグ付けされているメッセージ（７５５）は、そのユーザー用の受信したフィードキャッシュに書き込まれる（７６０）。キーワードのタグを含むメッセージ（７７０）は、タグフィードキャッシュに書き込まれる（７８０）。

ウェブメッセージリクエスト
ウェブクライアントインターフェイスを介しての協調的なショートメッセージ及びディスカッションのためのシステムに接続されたユーザーは、一実施形態によると、特定のタグを有するメッセージ、ユーザーの「アップデート」（彼らの返信なし）、ユーザーの「 返信」（彼らの他者への返信）、ユーザー自身の「フォロー」タブ又は何れかの彼らのカスタムのフォロータブ、ユーザーの送信タブ、ユーザーの受信タブ（ユーザーに言及して いる又はユーザーに返信しているすべてのメッセージ）、又はクライアントネットワーク内のすべてのメッセージを含むメッセージフィードを伴った多くのページを見ることができる。これらのページのいずれもスレッド化されたモードで見ることができる。

各ユーザーは特定のＪａｂｂｅｒ（ジャバー）ＩＤ（「ＪＩＤ」）を有する。ユーザーがウェブクライアントインターフェイス上のページを見るときに、特定のリソースが生成され、そのページ／リクエストのためのユーザーのＪＩＤに割り付けられる。例えば、ユーザーのディビットがキーワード「ｗｏｒｋｆｅｅｄ（ワークフィード）」ですべてのメッセージをリクエストすると、リソースがそのリクエストのための識別子として生成され、ディビットのＪＩＤに割り付けられる。このＪＩＤ／リソースの組み合わせは、そのユーザーが見ているフィードに登録され、これによってそのフィードへの新しいメッセージはそのユーザーに配信されるだろう。ＪＩＤ／リソースは、それがオフラインの存在を送 信する場合、そのフィードから解除される。データベース１６０及びメモリキャッシュ１４０は、どのＪＩＤのレコードが現在どのフィードに登録されているかを保管する。

図８は一実施形態による、ウェブメッセージリクエスト（要求）のための例示的なプロセスのフローチャートを示す。最初のリクエストが特定のメッセージフィードを伴ったページに対して行われると（８００）、そのリクエストに関連するメッセージを求めて、そ のメッセージフィードキャッシュを検索し（８１０）、すべての関連するキャッシュされたメッセージを返す（８２０）。もし関連するメッセージが見つからないと（８１０）、データベースが関連するメッセージを求めて検索される（８１５）。関連するメッセージがデータベースの中で見つかると（８１５）、そのデータベースはその関連するメッセージを返して、そのキャッシュは更新され（８２０）、そうでなければ関連するメッセージは存在せず、そのシステムはエラーを返す（８１７）。

関連するメッセージが返されると、特定のリソースが生成され、そのページ／リクエストのためのユーザーのＪＩＤに割り付けられる（８４０）。そのＪＩＤ／リソースの組み合わせは、ユーザーが見ているフィードに登録される（８５０）。そのユーザーがオンラインのままであれば、そのフィードへの新しいメッセージはそのユーザーに配信される（８６５）。そのユーザーがオンライン上に存在しなくなれば、そのユーザーのＪＩＤ／リソースはフィードから解除される。

Claims (7)

1. 第１クライアントソーシャルネットワーク及び第２クライアントソーシャルネットワークを含むクライアントソーシャルネットワーク内で、協調的なショートメッセージ及びディスカッションを管理するためのコンピュータで実行される方法であって、
   前記第１クライアントソーシャルネットワークのユーザーからタグ付けされた文字列を含むメッセージを受信する工程と、
   前記ユーザーと前記タグ付けされた文字列の少なくとも１つと関連する１以上のフィードを判定する工程であって、前記１以上のフィードは、前記第１クライアントソーシャルネットワークのユーザーによってアクセスできるが、前記第２クライアントソーシャルネットワークのユーザーによってアクセスできない工程と、
   前記ユーザーと前記タグ付けされた文字列の少なくとも１つと関連すると判定された前記１以上のフィードに前記メッセージを追加する工程と、
   前記１以上のフィードに登録されており、前記１以上のフィードのいずれかを見ている前記第１クライアントソーシャルネットワークのユーザーに前記メッセージを配信する工程を含む方法。
2. 前記配信する工程の前に、前記メッセージ内の前記タグ付けされた文字列をリンクに置き換える工程を含む請求項１記載の方法。
3. 前記タグ付けされた文字列はキーワードを含む請求項１記載の方法。
4. 前記タグ付けされた文字列がフィードと関連していない判定に応答して、
   前記タグ付けされた文字列と関連しており、前記第１クライアントソーシャルネットワークのユーザーによってアクセスできるが、前記第２クライアントソーシャルネットワークのユーザーによってアクセスできない新しいフィードを生成する工程を含む請求項１記載の方法。
5. 前記タグ付けされた文字列はユーザー名を含む請求項２記載の方法。
6. 前記ユーザー名は前記第１クライアントソーシャルネットワークに登録されていないことを判定する工程と、
   前記リンクを取り除く工程を含む請求項５記載の方法。
7. 前記タグ付けされた文字列は、前記タグ付けされた文字列の前に付けられた所定の記号を介して識別される請求項１記載の方法。