(57)【要約】  協力的なショートメッセージ及びディスカッションのためのシステム及び方法が記載されている。一実施形態によれば、協力的なショートメッセージ及びディスカッションのためのコンピュータにより実行される方法は、現存するシェアされた属性に基づいてクライアントネットワーク内にユーザをグループ化することを含む。システムリソースはクライアントネットワークにかけてメッセージングのため区分けされる。クライアントネットワーク内のユーザはそのクライアントネットワーク内のメッセージのみを見ることができ、返信することができる。
2012502371.tif 000002
【特許請求の範囲】
【請求項１】
現存するシェアされた属性に基づいてクライアントネットワークにユーザをグループ化し、
クライアントネットワークのメッセージングのためのシステムリソースを区分けし、
前記クライアントネットワーク内のメッセージにのみを見るか又は応答するようクライアントネットワーク内のユーザを許容すること、を含む協力的なショートメッセージ及びディスカッションのためのコンピュータにより実行される方法。
【請求項２】
ユーザはシェアされたＥメールアドレスのドメインに基づいてクライアントネットワーク内でグループ化されている請求項１記載のコンピュータにより実行される方法。
【請求項３】
メッセージ内のワードオブジェクトをタグすることをユーザに許可し、
各メッセージについてタグが付されたワードオブジェクトのテーブルを維持し、
特定のワードオブジェクトのためにタグが付されたメッセージをユーザが検索することを許容することを更に含む請求項１のコンピュータにより実行される方法。
【請求項４】
ユーザは特定のタグオブジェクティブを備えたメッセージをサブスクライブすることはできる請求項３記載のコンピュータにより実行される方法。
【請求項５】
協力的なショートメッセージ及びディスカッションのためのクライアントネットワークに参加し、
前記生成の間前記メッセージ内にユーザが１つ以上のワードオブジェクトをタグするショートメッセージを作成することを含むコンピュータにより実行される方法。
【請求項６】
タグが付されたワードオブジェクトはキーワードである請求項３記載のコンピュータにより実行される方法。
【発明の詳細な説明】
【分野】
【０００１】
本発明はインターネットを介して電子的メッセージを送受信することに関し、より詳細には協力的なショートメッセージ及びディスカッションのためのシステム及び方法に関する。
【背景】
【０００２】
オンライン又はモバイルによるソーシャルネットワーキングのアプリケーションにより、ユーザは他のユーザへ又は他のユーザからのメッセージを送ったり受信したりアカウントオンラインを作ったり、他のユーザにより貼り付けられたメッセージを見たりすることができる。一般に、ユーザのネットワークに参加するよう他のユーザを招いたり、コンピュータ上に記録された現存する関係を見つけ出すソフトウェアを用いることにより、ユーザはプロファイルを作成し、彼らのネットワークに関連するユーザを定義する（例えば、フェイスブック、マイスペース、及びリンクエドリン）。
【０００３】
より近年においては、マイクロブロッギングが共同的ディスカッションの効果的方法となってきており、参加者は特定の話題に関するいかなる時間においても情報をシェアすることができる。マイクロブロッギングのソーシャルネットワーク（例えば、ツィッター）において、ユーザはウェブサイト、ショートメッセージサービス（ＳＭＳ）又は特定のアプリケーションソフトウェアを介してメッセージを送ったり受信したりすることができる。しかし、典型的なソーシャルネットワーキングのアプリケーションのように、マイクロブロッギングのソーシャルネットワークは最小限のメッセージをスレッドする能力を有する。特定の話題に関し最も最近の情報のため情報を検索するユーザは関係しない多くのメッセージを見ることとなる。なぜなら、メッセージのコアはその検索されている話題には必ずしも関係しないからである。
【概要】
【０００４】
協力的なショートメッセージ及びディスカッションのためのシステム及び方法が望まれる。一実施形態によれば、協力的なショートメッセージ及びディスカッションのためのコンピュータにより実行される方法は、現存するシェアされた属性に基づいてユーザをクライアントネットワークにグループ化することを含む。システムリソースはクライアントのネットワークにかけてメッセージングのために区分けられる。クライアントネットワーク内のユーザはそのクライアントネットワーク内のメッセージに対してのみを見るか又は返信することができる。
【０００５】
本特許出願は引用により本明細書に組み込まれる、「協力的なショートメッセージ及びディスカッションのためのシステム及び方法」の名称で２００８年９月５日に出願された、米国仮特許出願第６１／０９４，８１８号に基づく優先権を主張する。
【図面の簡単な説明】
【０００６】
本明細書の一部として含まれる添付図面は本発明の現在の最もより好ましい実施形態を説明するものであり、上述の一般的な説明及びより好ましい実施形態の詳細な説明と共に本発明の原理を説明及び教示するのに供する。
【０００７】
【図１】一実施形態による協力的なショートメッセージ及びディスカッションのための例示的なシステムを示す図である。
【図２】一実施形態による本システムと共に用いられるウェブクライアントインターフェイスの例示的な実施形態を示す図である。
【図３】一実施形態によるメッセージ配布のための例示的なプロセスのブロック図である。
【図４】一実施形態によるメッセージ処理のための例示的なプロセスのフローチャートである。
【図５】一実施形態によるメッセージを保持し関連づけるための例示的なデータストラクチャを示す図である。
【図６】一実施形態によるメッセージブロードキャスティングのための例示的なプロセスのフローチャートである。
【図７】一実施形態によるメッセージフィードのキャッチングのための例示的なプロセスのフローチャートである。
【図８】一実施形態によるウェブメッセージデケストのための例示的なプロセスのフローチャートである。
【０００８】
図面は実寸で描かれているわけではなく、また同様の構造又は機能の要素については各図を通して説明の目的のために同様の参照番号により一般的に表されている。また、図面は本明細書内に記載された様々な実施形態の記述を実行するためのみのものである。図面は、本明細書に記述される開示の各アスペクトを記述するものではなく、特許請求の範囲を制限するものではない。
【詳細な説明】
【０００９】
協力的なショートメッセージ及びディスカッションのためのシステム及び方法は開示される。一実施形態によると、コンピュータネットワークショートメッセージ及びディスカッションシステムは現存するグループ内の協力のために設計される。各機能は、キーワード及びプライベートメッセージ及びグループによりメッセージスレッドリング及びタギングすることを含む。
【００１０】
一実施形態において、本システムはネットワークにより区分けされている。ユーザは彼らのＥメールアドレスのドメインポーションに基づきクライアントネットワークにグループ化される。例えば、ｊｏｅ＠ｆｏｏ．ｃｏｍ及びｂｏｂ＠ｆｏｏ．ｃｏｍはｆｏｏ．ｃｏｍクライアントネットワークのメンバーである、そのコンテンツにのみアクセスすることができる。ネットワーククライアントの間でデータのオーバーラップがないので、データベース及び他のリソースはネットワークのグループに区分けられる。
【００１１】
説明の目的のために、以下の説明において本明細書において開示される様々な発明性あるコンセプトの完全な理解をもたらすように特定の用語が用いられている。しかしながら、本明細書において開示される様々な発明性あるコンセプトを実施するために、これらの特典の詳細が必ずしも必要ではないことを本技術分野の当業者にとって明白である。
【００１２】
システムアーキテクチャー
図１は一実施形態による協力的なショートメッセージ及びディスカッションのための例示的なシステムを示す。システム１００はクライアントデバイス１０３、１０４、１１３、１１４、クライアントデバイスが関連するクライアントネットワーク１０５、１１５、及びインターネット１１０、ネットワーク１０１、ウェブサーバ１２０、ユーザーストレイジ１２５、メッセージプロセッシングアンドブロードキャスティングサーバ１３０、メモリキャッシュ１４０、インスタントメッセージ（ＩＭ）サーバ１５０、データベース１６０、エンタープライズサーチサーバ１７０、Ｅメールサーバ１８０、及びＳＭＳサーバ１９０を含む。
【００１３】
システム１００はインターネット１１０及びネットワーク１０１によって相互接続される。一実施形態によると、ネットワーク１０１はインターネットとして説明されているが、選択的にネットワーク１０１がワイドエリアネットワーク（ＷＡＮ）、ローカルエリアネットワーク（ＬＡＮ）、又は情報交換のために２つ以上のデバイスを起動する相互接続の他のシステムであってもよい。
【００１４】
１つ以上のクライアントデバイス１０３、１０４、１１３、１１４により、ウェブを介してネットワークにアクセスできるＨＴＭＬ及びジャバスクリプトを支援するマイクロソフトのインターネットエクスプローラ、アップルのサファリ、モズィーラ、ファイアフォックス又は他のブラウザ等のブラウザを介してウェブにアクセスすることができる。クライアントデバイス１０４、１１３、１１４はパーソナルコンピュータであるかもしれない。クライアントデバイス１０３はウェブにアクセス可能な電話又は他のウェブにアクセス可能なモバイルデバイスである。選択的に、クライアントデバイス１０３はＳＭＳが可能なウェブにアクセスすることができないモバイルフォンであるかもしれない。
【００１５】
クライアントデバイス１０３、１０４、１１３、１１４のユーザはクライアントネットワークにグループ化される。システム１００内のユーザは単一のクライアントネットワークに関連する特定の人のアカウントである。クライアントネットワークはユーザ、メッセージ、キーワードのタグの集合体である。クライアントネットワークにおいて、ユーザはそのクライアントネットワーク内の他のユーザのパブリックインフォメーションを見る能力のみ有し、クライアントネットワークの外側のユーザは、彼らがそのようなクライアントネットワークに特にアクセスを許されていなければ、クライアントネットワーク内のいかなる情報も見ることはできない。より好ましい実施形態において、ユーザはユーザのＥメールアドレスのドメインポーションに基いてクライアントネットワークにグループ化される。例えば、図１において、クライアントデバイス１０３及び１０４のユーザはクライアントネットワーク１０５においてグループ化される。なぜなら彼らは同じＥメールドメイン（例えば、ｊｏｅ＠ｆｏｏ．ｃｏｍ及びｂｏｂ＠ｆｏｏ．ｃｏｍ）をシェアしているからである。同様に、クライアントデバイス１１３、１１４のユーザはクライアントネットワーク１１５にグループ化される。なぜなら彼らは同じＥメールドメインをシェアしているからである。
【００１６】
ウェブサーバ１２０はハイパーテキストトランスファープロトコル（ＨＴＴＰ）、ファイルトランスファプロトコル（ＦＴＰ）、エクステンシブルメッセージプレゼンスプロトコル（ＸＭＰＰ）、又は他の同様な接続プロトコルを含むプロトコル及び／又はアプリケーションのいずれかを用いるウェブサーバである。オペレーティングシステムはウィンドウズ、リナックス、サンソラリス、マックＯＳ、又は他の同様なオペレーティングシステムであるかもしれない。ユーザはウェブサーバ１２０上にアカウントをつくり、クライアントネットワークにグループ化される。メッセージはインターネット１１０を介してクライアントデバイス１０３、１０４、１１３、１１４からウェブサーバ１２０に送られる。メッセージはウェブサーバ、Ｅメールサーバ１８０、及び／又はＳＭＳサーバ１９０を介して受信される。
【００１７】
メッセージプロセッシング及びブロードキャスティングサーバ１３０はメッセージの内容を処理し、メッセージの列を操作し、システム１００内の適宜なリソースにメッセージを方向づけることのできるサーバである。オペレーティングシステムはウィンドウズ、リナックス、サンソラレス、マックＯＳ、又は他の類似のオペレーティングシステムであるかもしれない。メッセージプロセッシング及びブロードキャスティングサーバ１３０はＥメールサーバ１８０、ＳＭＳサーバ１９０、ＩＭサーバ１５０、メモリキャッシュ１４０、データベース１６０、及びエンタープライズサーチサーバ１７０ヘメッセージを配信するかもしれない。
【００１８】
インスタントメッセージサーバ１５０は、エクステンシブルメッセージングアンプレゼンスプロトコル（ＸＭＰＰ）、エジャブレッド、バイディレクショナルストリームオーバＨＴＴＰ（ＢＯＳＨ）を含むインスタントメッセージを送信するためのプロトコル及び／又はアプリケーションを用いるサーバである。
【００１９】
エンタープライズサーチサーバ１７０はＡｐｃｈｅ’ｓＳｏｌｒ等のエンタープライズサーチのためのプロトコル及び／又はアプリケーションを用いるサーバである。
【００２０】
ユーザーストレイジ１２５はファイルストレイジを行うことができるストレイジドライブ又は他のデバイスである。好ましくは、ユーザの写真はユーザーストレイジ１２５に保持される。
【００２１】
一実施形態によると、図２は本システムを用いるためのウェブクライアントインターフェイスの例示的な実施形態を示す。一実施形態において、ウェブクライアントインターフェイス２２０はクライアントデバイス２００上でウェブブラウザ２１０を介して動作する。他の実施形態において、ウェブクライアントインターフェイス２６０はパーソナルコンピュータのオペレーティングマイクロソフトのウィンドウズ又はマックのＯＳ、又はアップルのｉｐｈｏｎｅ、リムのブラックベリー、又はグーグルのアンドロイド等のモバイルデバイスのためのアプリケーションソフトのために設計されている。
【００２２】
図３は本発明によるメッセージ配布のためのプロセスのブロック図を示す。メッセージは接続されるすべてのクライアントに配布される必要がある。これはウェブクライアントインターフェイス１９０、ＳＭＳ３７５，Ｅメール３７０、インスタントメッセージ３８０、又は他の通信スキームを介して接続されるクライアントを含む。一実施形態によると、システム１００はそれを要求するユーザにオールフィードを配信する。追加の実施形態は、このフィードをレイトリミティングすること（メッセージのレイトが高くなるとメッセージを捨てること）又はいくらかの又はすべてのクライアントのためのオプションとしてそれを単に取り除くことを含む。
【００２３】
新しいメッセージ３００が送出される前に、クライアントデバイス上のメッセージポストハンドリング３１０に入力される。例えば、メッセージポストハンドリングの間に、そのユーザがそれが送信される前にそのメッセージを見ることができる。そのメッセージがクライアントデバイスから送出され、システムによって受信されると、そのメッセージは図４において詳細に説明されるメッセージプロセッシング３２０に入力される。メッセージプロセッシング３２０の後、その新しいメッセージはシステムリソース全体にばらまかれる。これらはエンタープライズサーチ３３０、データベース３４０、メッセージフィード３５０、エンタープライズサーチ３３０によりメッセージ内のワードサーチが可能となる。フィードインボックス３５０はその新しいメッセージをそのメッセージが関連するすべてのメッセージフィードに関連づけ、データベース３６０はそのメッセージをアーカイブする。
【００２４】
配信を行うために、どのメッセージフィードをユーザが欲しているか及び配信メソッド（例えば、ＩＭ、ＳＭＳ、Ｅメール）が使われるかを記述するノチフィケーションケーブルがコンサルトされる。メッセージブロードキャスティング３６０の間、メッセージはユーザが配信のためにどの方法を（例えば、ＩＭ、ＳＭＳ、Ｅメール）を起動したかによって、適宜な配信システムにメッセージは転送される。いくらかの配信システムは更なるコンフィグレーションパラメータ（配信タイムのウィンドウ、例えば、又はグローバルオン／オフ）及びコンフィグレーションパラメータはメッセージを配信する前にコンサルトされる。
【００２５】
メッセージにタグをつける
協力的なショートメッセージ及びディスカッションのための本システムにおいて、ユーザはユーザ及び／又はキーワードのためにメッセージにタグをつけるオプションを有する。このタグをつける機能により、ユーザはそのメッセージの作成の間に関連するメッセージのフィードにメッセージをシームレスにダイレクトすることができる。また、それによりユーザはそのクライアントネットワーク内において特定のユーザにタグがつけられたメッセージ又は特定のキーワードによりタグがつけられたメッセージをクライアントネットワーク内にサーチすることができる。更に、これによりユーザはユーザの特定のタグを含むメッセージフィードを取得することができる。一実施形態において、ユーザは＠により備えたユーザーネームを前につけることによりメッセージの本体内に他のユーザをタグすることができる、同様にユーザは＃によりキーワードをフエピクスすることによりキーワードをタグすることができる。
【００２６】
例えば、ザックパーカーＨｅｙ＠ｋｇａｌｅ、彼が＃ワークフィードのための＃ＩＭゲートウェイを終わったかどうかを見るために＠ａｐｉｓｏｎｙをチェックする。
【００２７】
ユーザザックパーカーからのこのメッセージはユーザｋｇａｌｅ及びａｐｉｓｏｎｙと共に、（ＩＭ）及び（ワークフィード）によりタグがつけられる。これらのメッセージへの返信はこれらのタグのすべてに共通に行われ（キーワード及びユーザと共の両者に）、このタグを伴うユーザはスレッド内のすべてのメッセージをタギングしながらすることを覚えていなくてもいいように関連する返信を見ることができる。例えば、ザックパーカーに返信するディビットザック、ディビットザック私はちょうどアダムと話した。彼は彼の＃ｓｋｙｎｅｔプレゼンテーションへ進むと言った。
【００２８】
ユーザディビットザックからユーザディビットパーカーからのオリジナルメッセージへのこの返信は、ユーザｋｇａｌｅ及びａｐｉｓｏｎｙ、キーワード（ｉｍ）、（ワークフィード）そしてキーワード（ｓｋｙｎｅｔ）によりタグがつけられる。「ｓｋｙｎｅｔ」のタグはオリジナルのメッセージには適用されないがこのメッセージのいかなる返信にも適用されるだろうことに留意すべきである。
【００２９】
メッセージ処理
図４は一実施形態によるメッセージ処理のための例示的なプロセスのフローチャートを示す。
【００３０】
まず、新しいメッセージはそのメッセージの列から取り出され（４００）、そのメッセージの本体はタグがつけられたユーザーネーム（４１０）が探される。ユーザーネームのタグが見つけられると（４２０）、その送り手のクライアントネットワークが検索されクライアントネットワーク内にそのタグがつけられたユーザーネームが存在するかどうかを決定する（４２３）。タグがつけられたユーザーネームがクライアントネットワーク内に存在するなら、ユーザーネームのタグが参照番号としてメッセージに追加され（４２５）プロセスは次に進む。もしユーザーネームタグが見つからないのであれば（４２０）、又はユーザーネームがその送り手のクライアントネットワーク内に存在しないのであれば、プロセスは次に進む。
【００３１】
メッセージの本体がタグのつけられたキーワードを探して検索される（４３０）。もしキーワードのタグが見つかれば（４４０）、システムはそのキーワードは既に送り手のクライアントネットワーク内にキーワードとして存在するかどうかをチェックする（４４３）。もしタグのつけられたキーワードがキーワードとしてクライアントネットワーク内に存在しないのであれば、キーワードのタグはクライアントネットワーク内でつくられ（４４５）、キーワードのタグは参照番号としてメッセージに追加される（４４７）。もしタグのつけられたキーワードが既に送り手のクライアントネットワーク内にキーワードとして存在するのであれば、それは参照符合としてメッセージに追加される（４４７）。
【００３２】
メッセージがタグのためにスクリーンされると、そのメッセージが他のメッセージへの返信であるかどうかが決定される（４５０）。その決定の結果として（４５０）、もしそのメッセージが返信であれば、そのメッセージはオリジナルのメッセージＩＤを受け取り（４６０）、オリジナルのメッセージのスレッドＩＤを継承する、受け継ぐ（４７０）。これによりメッセージのスレッディングが可能となる。返信でないメッセージはその新しいメッセージＩＤに合致する新しいスレッドＩＤが割り当てられる。メッセージのＩＤがそのスレッドＩＤに一致すると、それはスレッドのスターターである。このように、スレッドのが唯一の一つのレベルの深さであるとき、返信はそれらが返信するメッセージの知識を維持する。
【００３３】
メッセージの本体内のタグは、そのメッセージがウェブクライアントインターフェイス上に表示されると、後でリンク又は同様のメカニズムにより代替されるスペシャルなトークンとして保持される（４８０）。メッセージの本体内のすべてのタグにトークンがつけられると（４８０）、そのメッセージは保存され（４９０）受信者の通知として列に加えられる（４９５）。
【００３４】
メッセージの構造
協力的なショートメッセージ及びディスカッションのための本システムにおいて、メッセージは比較的小さいものであるが、多くのアップデートはＳＭＳ及びＩＭを介して貼り付けられる。より好ましい実施形態において、ウェブクライアントインターフェイスは小さいメッセージを推奨するとして、ほとんどのメッセージは２００文字以下であるが文字制限は課せられていない。図５は一実施形態によるメッセージを保持するための例示的なデータ構造を示す。
【００３５】
新しいメッセージはメッセージテーブル内に、本体から始まり参照番号が続き最後にメタデータを伴った列が保持される。これによりメッセージＩＤのシーケンスにある新しいメッセージは即座に配信可能であることが確認される。
【００３６】
メッセージの構造はテーブル５００からなり、関連テーブル５１０及び５２０からなる。実施形態によると、テーブル５００はメッセージＩｄ５０１、そのメッセージが関連するネットワークｉｄ５００に、及びメッセージボディ又はポインタそのメッセージボディヘの、ボディ５０３を含む。関連するテーブル５１０はメッセージの送出及びスレッドニングのための情報を含む。これらはＩｄ５１１、ネットワークｉｄ５１２、レプライドｉｄ５１３、スレッドｉｄ５１４、センダーｉｄ５１５、センダータイプ５１６、及びレフｉｄ５１７を含む。関連するテーブル５２０はタグがつけられたキーワード等メッセージのレファレンスのための情報を含む。これらはＩｄ５２１、ネットワークｉｄ５２０、レファレンスｉｄ５２３、レファレンスタイプ５２４、レファレンスアズ５２５、及びレフｉｄ５２６を含む。
【００３７】
レファレンストアズと呼ばれる列により、個々のメッセージに異なるタイプのレファレンスを関連づけることは可能となる。レファレンストアズという可能な値はｒｅ、ｔｏ、タグド、又はインスレッド、である。「ｒｅ」のタイプはレファレンスされたタイプがユーザであるときに用いられ、そのユーザはこのメッセージが返信されるときのメッセージの送り手である。例えば、ザックがディビットが返信したメッセージを送るとき、ディビットのメッセージはレファレンストＩＤ／レファレンストタイプマップが彼のユーザーオブジェクトにマップされており、レファレンスＩＤが「ｒｅ」とセットされているときメッセージレファレンスを有する。「ｔｏ」のタイプはメッセージを方向づけることができる。タグをつけられた＠又は＃又は類似のタッギングするための識別子を用いてメッセージの本体に明らかにタグをつけられたもののために用いられる。インスレッドはレファレンスがスレッド内の前のメッセージに関連するときに用いられる。
【００３８】
協力的なショートメッセージ及びディスカッションのための本システムは、レファレンス内の値がタグ又はよりよいものをｒｅ、ｔｏ又はタグ又はインスレッドを意味するかどうかを決定するために階層としてこのリストを用いる。この階層はまた、同じ参照番号を２回保存することを防ぐためにも用いられる。ユーザディビットがユーザアピソニに返信すると、また本体内に＠アピソニを追加すると１つの参照番号のみが保存されタグの代わりにｒｅが用いられる。
【００３９】
上記に例示した返信から、４つの承継される参照符合（＃ｉｍ、＃ｗｏｒｋｆｅｅｄ、＠ａｐｉｓｏｎｙ、＠ｋｇａｌｅ）がレファレンストアズインスレッドと共に保存され、新しい参照符合（＃ｓｋｙｎｅｔ）がレファレンストアズタグドとして保存される。もう一つの「ｒｅ」は、ザックパーカーをあらわすユーザのために付加されなければならないだろう。
【００４０】
タグドとインスレッドとの間の区別はタグ上に見えるメッセージのリストを（インスレッド又はベター）をユーザのレシーブドタグ上に見えるそれらの同じもの（タグドｏｒベター）に比較することによりもっともうまく説明され得る。そこに示されるすべてのメッセージは明白にメッセージの本体内のユーザをレファレンスするのでこれにより受信したタグをより明確にする。
【００４１】
オリジナルメッセージのスレッドＩＤを継承すると同様に、スレッドニングはオリジナルのＩＤを伴った新しいメッセージにタグをつける返信機能をユーザにもたらすことにより達成され得る。返信でないメッセージは新しいスレッドＩＤそのメッセージＩＤにマッチングするが与えられ、メッセージのＩＤがそのスレッドＩＤに一致するとそれはスレッドスタータである。
【００４２】
メッセージブロードキャスト
図６は一実施形態によるメッセージブロードキャストのための例示的なプロセスのフローチャートを示す。このプロセスはメッセージの列から１つのメッセージを引き出すことにより開始する（６００）。このプロセスはそのメッセージが関連するすべてのメッセージフィードを決定する（６１０）。そのメッセージが関連するどのメッセージフィードについても（６１０）、そのプロセスはそれらのフィードを受信したユーザを決定する（６２０）。そのフィードを受信したどのユーザについても、そのプロセスはそのユーザがどの配信方法を起動したかを決定する（例えば、Ｅメール、ＳＭＳ、ＩＭ）（６３０）。そしてそのメッセージは、ステップ６１０、６２０、６３０に従い各ユーザが起動した配信メソッドに転送され、そのプロセスはメッセージがメッセージの列にある限り繰り返される（６００）。
【００４３】
メッセージフィード及びサブスクリプション
ユーザ及びメッセージをハンドルできる処理できるほどシステムを大きくすることを可能とするために、本システムはフィードに作成する時点においてメッセージをオーガナイズする。この協力的なショートメッセージ及びディスカッションのための本システムはいくつかの方法により関連するメッセージ又はフィードの集合体を識別する。
【００４４】
メッセージを見たいと望むユーザは適宜なフィードを選択し、リレーショナルデータベースに対し高価なクエリーズを実施しなければならないことなしに、そのフィード内でメッセージをすぐにアクセスする（例えば、消費時間及びリソースのインテンシブ）。本システムは書くよりも読む等マグニチュードのいくつかの序列を処理する。本システムはメッセージの見えることができる寿命の間数百回又は数千回よりも多くメッセージ作成の間１回は処理されるべき与えられたコンテキストの中でメッセージは可視化されることが考えられる。
【００４５】
メッセージの配信はフィードキャッシュに直接に書き込みそれはメッセージポーリングの間に用いられる。これによりシステムはリレーショナルデータベースを用いることなしに又はハードドライブからのメッセージをフェッチすることなしにインメモリキャッシュから膨大な量のフィードを処理することができる。
【００４６】
メッセージフィードの例は、特定のクライアントネットワーク内のすべてのパブリックメッセージ、特定のグループでない特定のクライアントネットワーク内のすべてのメッセージ、特定のユーザからのメッセージ、特定のユーザにより送られたメッセージ、特定のグループ内のメッセージ、特定のユーザによる特定のグループ内のメッセージ、特定のグループ内で特定のキーワードがタグされたメッセージ、特定のユーザへのプライベートメッセージ、特定のキーワードが付されたメッセージ、特定のユーザ（サブスクリプション参照）によりボットがつけられたすべてのものからのメッセージ、特定のボットからのメッセージ、特定のユーザへの返信又は参照するメッセージ、チェーンレプライをあらわすメッセージ、特定のユーザ（加入者参照）にフォローされたメッセージ、返信により構成されてない追加のメッセージのコレクションである特定のカンバセーション内のメッセージ、特定のユーザによりマークされたメッセージ等を含む。
【００４７】
一実施形態によると、サブスクリプションは２つの属性に分類され得る。第１の属性は１人のユーザが別のユーザのメッセージフィードを受け取りキーワードが付されたフィードを受けとるとき第１のバラエティサブスクリプションが発生する。第２のバリティサブスクリプションは１人のユーザが特定の配信方法を選んだフィードのための配信方法を選んだ時に発生する（例えば、Ｅメール、ＳＭＳ、ＩＭ）。
【００４８】
図７は一実施形態によるメッセージフィードをキャッシングするためのプロセスのブロック図を示す。新しいメッセージ（７００）は関連するユーザのサブスクリプションのために次のフィードキャッシュに書き込まれる（７１０）。そして、メッセージは各関連するユーザのカスタムタブのためにカスタムタブフィードキャッシュに書き込まれる（７２０）。そして、ユーザがそのメッセージの送り手であるかどうか及びそのメッセージが返信であるかどうかが決定される（７３０）。ユーザがメッセージの送り手であり、そのメッセージが返信であれば（７３０）、メッセージはそのメッセージスレッド内のすべての参加者に対する関連するフィードキャッシュに書き込まれる（７４０）。
【００４９】
メッセージ内の各参照番号について、その参照番号がそのユーザヘのものであるかどうかが決定される（７５０）。そのユーザへの参照番号が付されたメッセージはそのユーザへの返信において、又はそのユーザがメッセージ内にタグが付されているとき（７５５）、そのユーザのための受信したフィードキャッシュに書き込まれる（７６０）。キーワードのタグを含むメッセージ（７７０）はタグフィードキャッシュに書き込まれる（７８０）。
【００５０】
ウェブメッセージリクエスト
ウェブクライアントインターフェイスを介しての協力的なショートメッセージ及びディスカッションのためのシステムに接続されたユーザは、一実施形態によると、特定のタグを有するメッセージ、ユーザのアップデート（彼らの返信なし）、ユーザのレプライ（彼らの他者へのレプライ）、ユーザ自身のフォローイングタブ又は彼それらのカスタムフォローイングタブのいずれか、ユーザセントタブ、ユーザの受信タブ（すべてのメッセージ）又はクライアントネットワーク内のすべてのメッセージを伴った多くのページを見ることができる。これらのページのいかなるものもスレッドをされたモードで見ることができる。
【００５１】
各ユーザは特定のジャバＩＤ（ＪＩＤ）を有する。ユーザがウェブクライアントインターフェイス上のページを見るときに、特定のリソースが生成されそのページ／リクエストのためのユーザのＪＡＤに割り付けられる。例えば、ユーザディビットがキーワードワークフィードを伴ったすべてのメッセージをリクエストすると、リソースがそのリクエストのための識別子として生成され、ディビットのＪＩＤに割り付けられる。このＪＩＤ／リソースの組み合わせはそのユーザが見ているフィードにサブスクライブされ、そのフィードへの新しいメッセージはそのユーザに配信されるだろう。ＪＩＤ／リソースはそれがオフラインプレゼンスを送っているときそのフィードからアンスクライブされる。データベース１６０及びメモリキャッシュ１４０はどのＪＩＤが現在どのフィードにサブスクライブされているかの記録を保持する。
【００５２】
図８は一実施形態による、ウェブメッセージ要求のための例示的なプロセスのフローチャートを示す。初期の要求が特定のメッセージフィードを伴ったページに対して行われると（８００）、そのメッセージフィードキャッシュはその要求に関連するメッセージを検索し（８１０）、すべての関連するキャッシュされたメッセージを戻す（８２０）。もし関連するメッセージが見つからないと（８１０）、データベースは関連するメッセージを求めて検索される（８１５）。関連するメッセージがデータベースの中で見つかると（８１５）、そのデータベースはその関連するメッセージを戻して、そのキャッシュは更新され（８２０）、そうでなければ関連するメッセージが存在せずそのシステムはエラーへと戻る（８１７）。
【００５３】
関連するメッセージが戻されると、特定のリソースが生成されそのページ／リクエストのためのユーザのＪＩＤに割り付けられる（８４０）。そのＪＩＤ／リソースの組み合わせはユーザが見ているフィードにサブスクライブされる（８５０）。そのユーザがオンラインにとどまれば、そのフィードへの新しいメッセージはそのユーザに配信される（８６５）。そのユーザもオンライン上に存在しなくなれば、そのユーザのＪＩＤ／リソースはフィードからアンスクライブされる。
【図１】
2012502371.tif 000003
【図２】
2012502371.tif 000004
【図３】
2012502371.tif 000005
【図４】
2012502371.tif 000006
【図５】
2012502371.tif 000007
【図６】
2012502371.tif 000008
【図７】
2012502371.tif 000009
【図８】
2012502371.tif 000010
【国際調査報告】
2012502371.tif 000011