SNSのフロントライン、その核心と秘密を探る

ユーザー関与に基づくSNS最適化システム

SNSを閲覧していると、いつの間にか自分好みの情報（興味ある情報）が次々と提供された経験はありませんか。このように、ユーザの興味を自動的に特定し、そのユーザ向けに特定の情報を提供する技術は、以前から要望されてきました。今回紹介する発明は、SNS上のメッセージをより適切に分類し、その内容に関心を持ちそうなユーザーに効果的に推薦するためのシステムを提供するものです。

また、これらのメッセージを特定のトピックに関する検索の際にも参照するようにし、ユーザーは自分の関心に合ったコンテンツを簡単に探し出すことができるようになるのです。

発明の背景

本発明は、ソーシャルネットワークサービス（ＳＮＳ）を利用しているユーザ向けの推奨情報を自動的に推測し、その推測した情報をユーザに提供するためのシステムおよび方法です。

通常、ソーシャルネットワークサービス（ＳＮＳ）のユーザは、ソーシャルネットワークを介してコンテンツ（具体的には、メッセージなど）を制作・配布します。しかし、従来、コンテンツ（メッセージなど）の性質を特定するためのメカニズムは、非常に限られてきました。ネット上で開示されたコンテンツの性質を特定できないと、コンテンツの性質に基づいた追加関連サービスの提供機会を失ってしまう問題があります。

例えば、ソーシャルネットワークサービス（ＳＮＳ）を閲覧していると、いつの間にか自分好みの情報（興味ある情報）が次々と提供された経験はありませんか。このように、ユーザの興味を自動的に特定し、そのユーザ向けに特定の情報を提供する技術は、以前から要望されてきました。

どんな発明？

発明の目的

本発明は、ユーザが求めていると推測される推奨情報を提供するためのしくみに関する発明です。

詳しくは、本発明は、ユーザに推奨（推奨情報）を生成するための方法です。本発明の方法では、システムを使って以下のステップを実行します。

本発明の方法で使用するシステムは、コンピュータおよびストレージデバイス（ＳＳＤなどのデータ格納装置）を備えます。ストレージデバイスには、以下の操作をコンピュータに実行させる命令が記録されています。

［取得］　
ソーシャルネットワークプラットフォームで開示されたメッセージについて、メッセージが何の話題であるかを識別するために、このメッセージに反応した第三者アカウントの話題寄与度（その第三者アカウントの興味％や専門知識％など）を取得します。例えば興味％は、アメフト５０％、ラグビー２５％、サッカー２５％などです。開示されたメッセージは、画像や文字の解析によってとりあえずアメリカンフットボールという初期分類に分類しておきます。

［判断］　　
話題寄与度を使用して、メッセージがアメフト、ラグビー、サッカーのいずれの分類に関連しているかを判断します。

［検証］　　
メッセージの初期分類を検証します。これは、アメフト、ラグビー、サッカーのいずれかの分類が、初期分類（例えばアメフトという分類）と同じであるかどうかを判断し、初期分類（例えばアメフトという分類）と同じである場合は、その結果に基づいてメッセージの最終分類（例えばアメフトという分類）を判断します。

［推奨の生成］　　
最終分類（例えばアメフトという分類）を使用して、ソーシャルネットワークプラットフォームの他のアカウントへの推奨（推奨情報）を生成します。

［推奨の拡散］　
推奨（推奨情報）を他のアカウントに広めます。

発明の詳細

本発明のシステムの具体例について図面を参照しつつ説明します。

図１は、本発明のシステムの一例を示します。システムは、クライアントデバイス（100）（ユーザが使うスマートフォンなど）、および、ソーシャルネットワークプラットフォーム（102）（ＳＮＳなど）を備えます。これらについて以下に詳しく説明します。

【図１】

図１に示すように、ソーシャルネットワークプラットフォーム（102）は、アカウントリポジトリ（104）、話題モデルリポジトリ（106）、メッセージリポジトリ（108）、分類エンジン（110）などを含みます。これら（104～110）は、例えば、同じデバイス（装置）に配置されています。デバイス（装置）は、例えば、サーバ、デスクトップパーソナルコンピュータ（ＰＣ）などです。

一方、104～110は、ネットワークを介して接続されている場合もあり、また、有線および無線の接続を組み合わせて通信プロトコルの組み合わせを使用している場合もあります。

ソーシャルネットワークプラットフォーム（102）（いわゆるＳＮＳ）は、ユーザとユーザとを接続し、接続されたユーザ間でプラットフォームメッセージを交換するための機能（インターフェース）を提供します。

本発明では、プラットフォームメッセージ（以下、単にメッセージといいます）は、例えば多数のユーザに送信されるメッセージです。その多数のユーザは、送信するユーザのフォロワーであるか、送信するユーザに対して特定の関係（例えば、友達、家族などのグループに属する）を有するユーザです。メッセージには、ユーザからのコメント、地理的位置、個人のステータスの更新、ソーシャルネットワークの他のユーザへの参照、メッセージの説明を示す用語、商品やサービスの購入または販売のオファーなどが含まれます。それぞれのメッセージは、テキスト、ＵＲＬ、画像などを含みます。ただし、例えばＸ（旧ツイッター）のようにメッセージのサイズが制限（例えば文字数が制限）される場合があります。

ソーシャルネットワークプラットフォーム（102）は、与えられたメッセージに関連する話題を決定するシステムのために機能します。具体的には、メッセージと特定の話題とを関連付け（紐づけ）した後、メッセージに基づいて「推奨（推奨情報）」を決定します。または、メッセージと特定の話題とを関連付け（紐づけ）した後、メッセージをメッセージ検索プールに配置して、検索クエリのサービスに使用することが可能です。なお、検索クエリとは、ユーザが検索したときに実際に使用した単語や単語の組み合わせを指します。すなわち、ユーザが検索したキーワードのことを「検索クエリ」と称します。

ソーシャルネットワークプラットフォーム（102）は、個人間や企業間でリアルタイムのコミュニケーションを促進します。例えば、個人、企業、その他（疑似匿名アカウントなど）の数百万のアカウントを格納できます。各アカウントのユーザは、ソーシャルネットワークプラットフォーム（102）を使用して、他のアカウントにメッセージを送信できます。

ソーシャルネットワークプラットフォーム（102）は、ユーザ同士がコミュニケーションを行い、例えばほぼ同時にユーザ同士で会話できるように構成されます。言い換えますと、ソーシャルネットワークプラットフォーム（102）では、ユーザがメッセージを拡散でき、メッセージを他のユーザに適切な時間内に表示して、ユーザ間の「ライブ」な会話（チャット）を促進できます。

クライアントデバイス（100）は、ソーシャルネットワークプラットフォーム（102）との間で接続（交信）できるように構成されています。例えば、クライアントデバイス（100）は、ソーシャルネットワークプラットフォーム（102）にアクセスできるウェブブラウザアプリケーション（いわゆるブラウザ）を含みます。この例では、アクセスするウェブサイトがソーシャルネットワークプラットフォームのウェブサイト（例えばwww.twitter.com）であるか、その他のウェブサイト（例えばwww.cnn.com）であるかに関わらず、ユーザは接続（交信）できます。

ユーザは、クライアントデバイス（100）を使用してメッセージ、「推奨」（推奨情報）、「検索クエリ」（ユーザが検索したキーワード）への応答などを受信できます。

以下で登場する「リポジトリ」とは、情報が保管されるデータベースです。

図１に示すアカウントリポジトリ「アカウント情報保管データベース」（104）は、ソーシャルメディアプラットフォーム内のアカウントに関する情報を格納します。具体的には、ユーザの位置、ユーザの自己紹介、アカウントが興味を有する話題（以下、興味話題と称します）や専門知識（以下、専門知識話題と称します）などのアカウントデータ項目を格納します。

「興味話題」は、アカウントを所有するユーザが興味および興味を示す話題です。「興味話題」は、例えば、アカウントを所有するユーザが直接入力した内容に基づきます。また、アカウントを所有するユーザの関連情報に基づいて、ソーシャルネットワークプラットフォーム（または第三者）が、そのユーザが特定の話題に興味を有すると判断する場合もあります。

「専門知識話題」は、その話題に関してあるユーザが専門知識を持っていると、ソーシャルネットワーク内の他のアカウントが予想している話題です。

すなわち、「興味話題」は、アカウントが行ったアクションに基づくものですが、「専門知識話題」は、他のアカウントの行動に基づくものです。

図１に戻り、話題モデルリポジトリ「話題モデル情報保管データベース」（106）は、話題モデルを含んでいます。話題モデルは、メッセージの内容を分析したり、話題間に競合があるかどうかを判断したりするために使用され、文字列、キーワード、フレーズ、ハッシュタグなどを含みます。例えば、メッセージに話題モデルとして「ＮＢＡ」が含まれている場合、話題モデルはそのメッセージが「バスケットボール」の話題と関連している可能性が高いことを示します。

また、話題モデルは、競合する話題に関わる規則を含む場合があります。例えば、話題モデルには、「ヘビーメタル」という話題が「クラシック音楽」という話題とあまり関連しないという規則があり、これによりヘビーメタルとクラシック音楽との間に競合があることが示されます。言い換えると、例えば「エレキギター」という特定のメッセージが上記の話題の両方に関連付けられる（紐づけされる）可能性は低いです。

話題モデルは、ソーシャルネットワークプラットフォームのユーザ（または管理者）によって手動で生成されることもあり、自動的にソーシャルネットワークプラットフォームによって生成されることもあり、または、ソーシャルネットワークプラットフォームのユーザまたは管理者でない第三者（サードパーティ）から取得されることもあります。

ソーシャルネットワークプラットフォームは、メッセージリポジトリ「メッセージ情報保管データベース」（108）を含む場合があります。このメッセージリポジトリは、「メッセージデータ項目」を格納する機能を有します。「メッセージデータ項目」は、メッセージと「メッセージのメタデータ」（下記に説明）、および、必要に応じて「その他」（下記に説明）を含みます。

「メッセージのメタデータ」は、メッセージの発信元アカウントの識別子、メッセージを受信したアカウントのリスト、メッセージを受信したアカウントの数、メッセージを転送する起点アカウントに対する接続アカウントの比率、メッセージが送信された時刻および日付などを含みます。

必要に応じて各メッセージデータ項目は、「その他」に、応答するアカウントの識別子、応答の種類、応答のタイムスタンプ、応答の場所を含む場合があります。

応答するアカウントの識別子は、メッセージに応答するアカウントを識別します。
応答の種類は、応答の種類を識別します。応答の種類には、「表示」（または「表示／展開」）、リポスト（リツイート等）、返信、同意などが含まれます。
応答のタイムスタンプは、応答が発生した時刻の記録です。
応答の場所は、アカウントがメッセージに応答した地理的位置の記録です。応答の場所は、応答の際に記録されたＧＰＳ座標を含む場合があります。

上記応答の種類のうち、応答タイプが「表示」（または「表示／展開」）である場合、メッセージが表示されたことを示します。メッセージは、例えば、スマートフォンで実行されるモバイルアプリケーション（旧Twitterアプリなど）で表示されます。

応答タイプが「リポスト」の場合、メッセージを受け取ったアカウントが、そのメッセージをソーシャルネットワークプラットフォーム内の他のアカウントに転送することを示します。応答タイプ「リポスト」の具体例として、「リツイート」があります。

応答タイプが「返信」の場合、初めてメッセージを受け取ったアカウントが、メッセージの内容に応じて新しいメッセージを生成します。新しいメッセージは、メッセージの作者だけに送信される場合もあり、ソーシャルネットワークプラットフォーム内の他のアカウントに送信される場合もあります。

応答タイプが「同意」（いいね！など）の場合、メッセージを受け取ったアカウントが、メッセージの内容に同意することを示します。特定のアカウントがメッセージに同意したことを示すものであり、これはメッセージの作者だけに伝えられる場合もあり、ソーシャルネットワークプラットフォーム内の他のアカウントに伝えられる場合もあります。

図１に戻り、メッセージリポジトリ「すなわちメッセージ情報保管データベース」（108）は、どのアカウントが特定のメッセージにどのように応答するかを追跡します。以下に、応答の具体例を示します。

ソーシャルネットワークプラットフォームのユーザ「Ａさん」が“コーヒーαの新しいフレーバーが好きです！”というメッセージを作成してソーシャルネットワークプラットフォームに送信します。

Ｂさんはソーシャルネットワークプラットフォームでメッセージを読み、自分のアカウントを使用して「リポスト＠Ａさん：“コーヒーαの新しいフレーバーが好きです！”」という形式でメッセージを再投稿します。

ＢさんはＡさんのメッセージに応答しました。ＣさんもＡさんのメッセージを見て、応答するために「私もです！＠Ａさん：“コーヒーαの新しいフレーバーが好きです！”」という形式でメッセージを作成します。

ＣさんもＡさんのメッセージに応答しました。最後に、ＤさんはＡさんのメッセージを見て、ソーシャルネットワークプラットフォームのウェブサイトに表示されたメッセージの隣にある「同意」ボタンをクリックします。

Ｄさんもメッセージに応答しました。Ｂさん、Ｃさん、Ｄさんによる応答は、メッセージリポジトリ（またはソーシャルネットワークプラットフォームと操作的に接続された他のリポジトリ）によって追跡されます。

図１の分類エンジン（110）は、メッセージリポジトリ（108）から選択されたメッセージを分類（またはカテゴリ化）するための分類モデルを格納しています。分類エンジン（110）は、例えば、各メッセージのテキスト部分、画像部分ごとに分類モデルを有します。

ここで、以下に続く内容のために「モダリティ」を説明します。「モダリティ」とは、文章中で書き手の主観を表わす部分です。例えば、「きっと当選するだろう」という文章において、「当選する」に対する書き手の推測が「きっと～だろう」で表されています。この部分がモダリティです。

分類エンジン（110）は、複数モダリティの（いろいろな主観を含む）メッセージについて、どの主観に基づく分類が優先するかを決定するための判断ロジック（判断理論）を含んでいます。

次に、具体的なシナリオの例を挙げて説明します。

具体例１

「スミスによる素晴らしいタックルだった」というメッセージが分析されると、このメッセージの潜在的な話題が以下のようにして特定されます。
アメリカンフットボール：話題の確実性評価が60％、サッカー：話題の確実性評価が40％、ラグビー：話題の確実性評価が40％。
さらに、メッセージの作者のアカウントが以下の専門知識話題を有すると判断されます。アメリカンフットボール：専門レベル60％、サッカー：専門レベル0％、ラグビー：専門レベル10％。
そして、次のように決定されます：話題がアメリカンフットボールである確率36％（60％×60％）、話題がサッカーである確率0％；話題がラグビーである確率4％（40％×10％）。
上記の結果に基づいて、メッセージにはアメリカンフットボールの話題が関連付けられます。この情報は、メッセージと共に、メッセージリポジトリ「すなわちメッセージ情報保管データベース」（108）（図１を参照）に保存される可能性があります。

具体例２

「スミスによる素晴らしいタックルだった」というメッセージが分析されると、このメッセージの潜在的な話題が以下のようにして特定されます。
アメリカンフットボール：話題の確実性評価が60％、サッカー：話題の確実性評価が40％、ラグビー：話題の確実性評価が40％。
さらに、メッセージの作者のアカウントには専門知識話題がないと判断されます。ただし、メッセージに応答したアカウントが以下の興味確率を有すると判断されます。アメリカンフットボール：関連アカウントの30％、サッカー：関連アカウントの50％、アメリカンフットボールやサッカー以外の興味を有するアカウントの20％。
そして、次のように決定されます：話題がアメリカンフットボールである確率18％（60％×30％）、話題がサッカーである確率20％（40％×50％）、話題がラグビーである確率0％。
上記の結果に基づいて、メッセージにはサッカーの話題が関連付けられます。この情報は、メッセージと共に、メッセージリポジトリ「すなわちメッセージ情報保管データベース」（108）（図１を参照）に保存される可能性があります。

具体例３

「スミスによる素晴らしいタックルだった」というメッセージが分析されると、このメッセージの潜在的な話題が以下のようにして特定されます。
アメリカンフットボール：話題の確実性評価が60％、サッカー：話題の確実性評価が40％、ラグビー：話題の確実性評価が40％。
さらに、メッセージの作者のアカウントが以下の専門知識話題を有すると判断されます。アメリカンフットボール：専門レベル60％、サッカー：専門レベル30％、ラグビー：専門レベル10％。
最後に、メッセージに応答したアカウントが以下の興味確率を有すると判断されます。アメリカンフットボール：関連アカウントの30％、サッカー：関連アカウントの50％、ラグビー：関連アカウントの20％。
そして、次のように決定されます：話題がアメリカンフットボールである確率11％（60％×60％×30％）、話題がサッカーである確率6％（40％×30％×50％）、話題がラグビーである確率1％（40％×10％×20％）。
上記の結果に基づいて、メッセージにはアメリカンフットボールの話題が関連付けられます。この情報は、メッセージと共に、メッセージリポジトリ「すなわちメッセージ情報保管データベース」（108）（図１を参照）に保存される可能性があります。

次に、本発明に関連する類似発明を紹介します。

図４は、画像データを含むメッセージを分類するためのフローチャートを示しています。言い換えますと、テキストデータ（文字データ）および画像データの両方を含むメッセージを分類するためのプロセスを示しています。

【図４】

ステップ400では、メッセージを選択します。
ステップ402では、メッセージが画像を含むことを確認します。
ステップ404では、画像のピクセル分析が行われ、画像コンテンツを特定します。ピクセル分析は、従来から知られている技術で実施できます。
この段階で、画像コンテンツがあらかじめ設定された分類基準に合致するかどうかを決定します（ステップ406）。詳しくは、ソーシャルネットワークプラットフォームは、画像がソーシャルネットワークプラットフォームでの投稿に適さないかどうかを確定するための基準を有します。

例えば、画像に武器が含まれている場合、公序良俗に反する暴力的な画像かもしれません。別の例として、画像の大部分に人間の肌が含まれている場合、肌の露出が多い不適切なコンテンツと見なされるかもしれません。したがって、ステップ406では、解析された画像のコンテンツが、画像への公開のための基準を満たすかどうかを確認するフィルタ機能がはたらきます。

画像が基準を満たさない場合、ステップ408で画像がテキストデータ（文字データ）などを含むかどうか２度目の判断を行います。

画像がテキストデータなどを含む場合、メッセージ中のテキストデータは、メッセージの分類および初期分類を取得するために使用される可能性があります（ステップ410）。

一方、ステップ406で画像が基準を満たす場合、メッセージの画像コンテンツをステップ412で分類します。

ステップ414では、メッセージの画像コンテンツを分類した後、メッセージにテキストデータなどが含まれるかどうかの判断を行います。メッセージにテキストデータなどが含まれる場合、メッセージ中のテキストデータも分類されます。

テキストデータの初期分類を取得するときに、ステップ416で、メッセージ中の画像およびテキストデータの両方で同じ分類が得られるかどうかを判断します。分類が一致する場合（つまり、分類が互いに競合しない場合）、ステップ418でメッセージの結合された初期分類が得られ、プロセスを終了します。

ステップ416で分類が一致しない場合（つまり、分類が競合する場合）、ステップ420で分類決定ルールが適用されてメッセージの初期分類を決定する場合があります。ステップ420の分類決定ルールは、例えば、分類の確実性評価、メッセージの著者の興味情報や専門知識情報、または、メッセージに関連する関連データなどを考慮に入れます。

以下は、図４で説明されるプロセスに従って画像分類を実行するための具体例です。

具体例４

ステップ400で選択されたメッセージが、ランジェリーモデルの画像だけを含む場合を考えてみます。この場合、ステップ404で画像が解析されたときに、画像コンテンツは、ステップ406での基準を満たさないかもしれません。つまり、画像のピクセルデータによって、画像中の肌面積の割合が高いと判断されるため、プラットフォームは画像を不適切と見なす可能性があります。

したがって、ステップ408でメッセージがテキストデータなどを含まないと確定したら、プロセスを終了します。この場合、メッセージの初期分類は、「投稿しないでください」、「画像コンテンツを無視する」、または「メッセージが投稿に適さない」などとなる可能性があります。

しかしながら、例えば２４〜４８時間後に、その画像がファッションショーに関するテキストとともに再投稿され、ファッションコミュニティの多くの人々が同意したり再投稿したりした場合を考えてみます。この場合、ステップ206でメッセージを取り巻く関連データが分析され、関連データが閾値を超える場合、メッセージの初期分類の検証に進みます。画像と一緒に添えられたテキストデータの意味を分析し、メッセージの著者の興味情報および専門知識情報を取得します。

さらに、画像を含むメッセージに関連するアカウントを分析し、得られた情報を使用して話題の曖昧性解消が行われます。その結果、話題｛ファッション、ファッションショー｝という結果が返されるかもしれません。

上記のシナリオでは、初期分類の検証により、メッセージコンテンツが不適切ではなくファッションに関する画像に変更され、キーワード「ファッション」および「ファッションショー」で画像が分類されます。その後、画像はこれらのキーワードの下でメッセージ検索プールに配置されたり、または画像の分類に基づいて提供される推奨事項が提供されたりします。

具体例５

別の例として、メッセージに画像およびテキストデータが含まれる場合を考えてみます。この場合、メッセージには「◆◆ブランドのファッションショー！」というテキスト（文字）が含まれ、ファッションモデルがランウェイでランジェリーを着用している画像も含まれています。

この例では、画像によって分類されると「投稿しないでください」または「無視する」となるかもしれませんが、テキストデータによって分類されると、メッセージは｛ファッション、ファッションショー｝として分類され得ます。

さらに、メッセージが拡散し、メッセージを取り巻く会話がソーシャルネットワークプラットフォーム上のイベントになる場合を考えてみます。この情報は、リアルタイムでなく遅延する可能性があります。ただし、メッセージを取り巻く関連データも同じキーワード／話題｛ファッション、ファッションショー｝で分類される場合には、ソーシャルネットワークプラットフォームは、検索可能な同じキーワードまたは同じ話題を使用して全体の会話を分類できます。

なお、本発明は、ほとんどすべてのタイプのコンピューティングシステムで実行できます。例えば、コンピューティングシステムは、モバイルデバイス（ノートパソコン、スマートフォン、タブレットコンピュータなど）、デスクトップコンピュータ、サーバを含みます。また、特定のプラットフォームや環境に依存せず、クラウドコンピューティング環境（クラウドサーバや仮想マシンなど）で実行することもできます。

本発明は、ソフトウェアプログラム、コードセグメント、スクリプトなどの形式で提供でき、これらは様々なプログラミング言語で記述できます。

ここがポイント！

以上説明しましたように、本発明は、ユーザへの推奨（推奨情報）を生成するためのシステムおよび方法です。

本発明の方法で使用するシステムは、コンピュータおよびデータ格納装置を備えます。データ格納装置には、以下の操作をコンピュータに実行させる命令が記録されています。

［取得］
ソーシャルネットワークプラットフォームで開示されたメッセージについて、メッセージが何の話題であるかを識別するために、このメッセージに反応した第三者アカウントの話題寄与度（その第三者アカウントの興味％や専門知識％など）を取得します。例えば興味％は、アメフト５０％、ラグビー２５％、サッカー２５％などです。開示されたメッセージは、画像や文字の解析によってとりあえずアメリカンフットボールという初期分類に分類しておきます。

［判断］
話題寄与度を使用して、メッセージがアメフト、ラグビー、サッカーのいずれの分類に関連しているかを判断します。

［検証］
メッセージの初期分類を検証します。これは、アメフト、ラグビー、サッカーのいずれかの分類が、初期分類（例えばアメフトという分類）と同じであるかどうかを判断し、初期分類（例えばアメフトという分類）と同じである場合は、その結果に基づいてメッセージの最終分類（例えばアメフトという分類）を判断します。

［推奨の生成］
　最終分類（例えばアメフトという分類）を使用して、ソーシャルネットワークプラットフォームの他のアカウントへの推奨（推奨情報）を生成します。

［推奨の拡散］
推奨（推奨情報）を他のアカウントに広めます。

上記の本発明では、コンテンツ（メッセージなど）の性質を特定できます。そして、コンテンツ（メッセージなど）の性質を特定して、コンテンツ（メッセージなど）の性質に基づいた追加の関連サービスをユーザに提供できます。

未来予想

本特許は、世界的に有名な旧ツイッター社（現エックス社）から出願されました。エックス社はＩＴ関連技術のうち特にソーシャルネットワークサービス技術に強いというイメージの通り、ユーザの開示情報や閲覧情報を基にして推奨情報を生成する技術に関わる、上記のような特許出願をしています。

本発明は、例えば、ユーザが有する興味に沿った情報を次々と提供するためのアイデアです。ＳＮＳを利用していると、次々と関連情報が出てくるしくみは、本発明のような技術の利用によって実行されていると思われます。本特許発明以外にも、さまざまなアイデアが利用されて、推奨情報が提供されていると考えられます。

特許の概要

メッセージストリームで情報をスマートに取得！

私たちの日常生活において、様々なデジタルプラットフォームで情報がやり取りされており、いまやこのような情報のやりとりなしでは生活が成り立たないほどに情報化が進みました。しかし、大量の情報が飛び交う中で、本当に必要な情報だけを効率的に手に入れるのは難しいと感じたことはないでしょうか？

今回紹介する「メッセージストリーム最適化」の技術は、この問題に答える一つの解決策です。このシステムは、ユーザーが事前に設定したキーワードやクエリを元に、リアルタイムで流れてくるメッセージから必要な情報だけを取り出して提供します。例えば、特定のプロジェクトやキーワードに関連するメッセージだけを見たいとき、その条件を設定するだけで、関連するメッセージだけがユーザーの手元に届きます。具体的にどのような技術なのか、詳説していきます。

発明の背景

ソーシャルメディアメッセージングプラットフォームは、ユーザー間で数百万または数億のソーシャルメディアメッセージの交換を促進することができます。プラットフォームで交換されるメッセージは、しばしばプラットフォームのユーザーに最新の更新や現在の出来事に関する報告を提供できます。一部の例では、ユーザーがプラットフォーム上で検索を実行し、1つまたは複数のキーワードと一致するメッセージを時間経過で表示できるような結果のストリームを受け取ることができます。

しかし、非常に大きなメッセージストリームを一定の期間にわたってマッチングし、それらのメッセージをユーザーにリアルタイムでレンダリングすることは、処理速度、コンピュータリソースの割り当て、およびセキュリティの問題など、複雑で技術的な課題を伴うことが問題点でした。

どんな発明？

発明の目的

本発明は、上記課題に鑑み、メッセージングプラットフォームで交換される大量のメッセージストリームからのコンテンツと一致するクエリサブスクリプションに基づいて、クライアントアプリケーションにリアルタイムメッセージを時間経過でストリームすることを目的としています。

この方法は、メッセージの配信速度を向上させ、アクティブなクエリサブスクリプションの数の変動を処理するためのコンピュータリソースの管理を効果的に制御し、著者の視点から生成されたメッセージに対してクエリサブスクリプションを一致させるセキュリティを向上させるものです。そして、それらのメッセージを、クエリサブスクリプションを開始したユーザーの視点からリアルタイムで配信します。

※クエリサブスクリプションは、特にウェブアプリケーションやモバイルアプリケーションの開発で用いられる技術で、リアルタイムのデータの変更を読み込み、それをクライアントに即座に通知する仕組みを指します。具体的な例として、GraphQLのサブスクリプションを挙げることができます。GraphQLは、APIクエリ言語およびランタイムとして機能し、クライアントが必要とするデータを正確にリクエストできるように設計されています。GraphQLのサブスクリプションは、サーバー側のデータの変更をクライアントにリアルタイムでプッシュする機能を提供します）

ユーザーは、ユーザーインターフェースをリフレッシュしたり、ユーザーインターフェースで新しいメッセージを表示するための別のリクエストを送信したりする必要はありませんが、クエリサブスクリプションと一致するメッセージをメッセージングプラットフォームに投稿する他のユーザーへの応答として、メッセージがユーザーのユーザーインターフェースにプッシュされます。

例えば、ユーザーは「犬」という検索語を入力してアクティブなクエリを生成し、その後「犬」という検索語を含むメッセージのストリームを受け取り、新しいメッセージがメッセージングプラットフォームに作成および投稿されるたびに「犬」という検索語を含むメッセージを受け取り続けることができます（アクティブなクエリが期限切れになるまで）。静的なクエリでは、静的なクエリ（例えば、検索リクエストに対するウェブ結果のリストを受け取るなど）を提出した時点で一度結果が提供されますが、ユーザーはアクティブなクエリの提出後（およびアクティブなクエリが期限切れになるまで）一致するコンテンツを表示し続けることができます。

イベントプロデューサーシステムには、イベントプロデューサーマネージャと複数のイベントプロデューサーが含まれ、それらは同時にクエリサブスクリプションを実行して一致するコンテンツを識別するように設定されています。イベントプロデューサーマネージャはサブスクリプションエグゼキュータからクエリサブスクリプションを受け取り、クエリサブスクリプションが指定されたイベントプロデューサーで保存されるようにクエリサブスクリプションを1つ以上のイベントプロデューサーに割り当てます。

例えば、イベントプロデューサーマネージャは、イベントプロデューサーからの期限切れ（または不良）のクエリサブスクリプションを削除し、新しいクエリサブスクリプションがイベントプロデューサーマネージャで受け取られるときに新しいクエリサブスクリプションを割り当てることができます。指定されたイベントプロデューサーは、メッセージキューからのメッセージがクエリサブスクリプションと一致することを応答して応答イベントを生成します。応答イベントは、クエリサブスクリプションと一致するコンテンツを持つメッセージを識別することができます。

サブスクリプションエクゼキュータは、レスポンスイベントを受け取り、クエリサブスクリプションを開始したユーザーの視点からのデータを持つレスポンスイベントによって特定されたメッセージを生成し、メッセージをトランスポートエンジンに提供して、配信チャンネルを通じて配信します。例えば、メッセージキュー内のメッセージは、その著者の視点から生成されています。

しかし、クライアントアプリケーションに配信されるメッセージは、リクエストを開始したユーザーの視点からのデータを持つ必要があります。サブスクリプションエクゼキュータは、イベントプロデューサーシステムによって一致した後、トランスポートエンジンによる配信の前に、メッセージ（例：メッセージのハイドレートおよび可視性ルールの適用）を生成することができます。このようにして、一致したメッセージの著者が、クエリサブスクリプションを開始したユーザーを制限している場合（例：ブロックまたはミュート）、サブスクリプションエクゼキュータはそのメッセージを破棄することができ、メッセージングプラットフォームのセキュリティを高めることができます。

ここで、レスポンスイベントがサブスクリプションのためにユーザーがリクエストしたデータのみを含む場合、イベントバスに公開されるデータの量が減少し、クライアントに送信される余分なデータがなくなり、秒あたりのイベントをより多くストリームするための帯域を節約するのに役立つ可能性があります。

イベントプロデューサーは、複数のイベントプロデューサーグループにグループ分けされ、各イベントプロデューサーグループが完全なメッセージストリームを受け取ります。各プロデューサーグループは、複数のイベントプロデューサーを含み、各イベントプロデューサーは、完全なメッセージストリームの別々の部分を受け取ります。各イベントプロデューサーグループには、クエリサブスクリプションの別々の部分が割り当てられます。イベントプロデューサーマネージャーは、サブスクリプションクエリをイベントプロデューサーグループに割り当てることができ、グループ内の各イベントプロデューサーがクエリサブスクリプションを保存および実行します。

いくつかの例では、イベントプロデューサーマネージャーは、サブスクリプションを最初のイベントプロデューサーグループと2つ目のイベントプロデューサーグループに割り当てることができるため、イベントプロデューサーグループのいずれかでクエリサブスクリプションの処理にエラーが発生した場合でも、クエリサブスクリプションを維持することができます。

このようにして、システムは、クエリサブスクリプションとレスポンスイベントの変動量を考慮して、イベントプロデューサーグループの数を増減させたり、各グループのイベントプロデューサーの数を増減させたりすることで、イベントプロデューサーシステムでのレスポンスの量を簡単に制御することができます。

例えば、単一のイベントプロデューサーグループ内のイベントプロデューサーの数が増加した場合、各個別のイベントプロデューサーは、メッセージストリームから処理するためのメッセージを少なく受け取ることができ、結果として追加の検索を処理するための計算能力が増える可能性があります。イベントプロデューサーグループの数が増えることを受けて、イベントプロデューサーに割り当てられる検索用語の数を減少させてもよいでしょう。

いくつかの例では、イベントプロデューサーシステムは、イベントプロデューサーからのレスポンスイベントを受け取り、ストリーミングレートがストリーミングレートのしきい値以下となるように、レスポンスイベントによって特定されたメッセージがクライアントアプリケーションにストリームされるように、1つ以上のレスポンスイベントを破棄するコレクターサービスを含みます。

例えば、メッセージが高速でストリームされる場合、ユーザーはストリームされたメッセージを消費することができないかもしれません。そのため、コレクターサービスは、メッセージがストリームされるレートがしきい値以下となるように、ストリーミングレートをスロットリングすることができます。

例えば、ストリーミングレートのしきい値が1秒あたり10メッセージである場合、コレクターサービスは、1秒の時間間隔内で10以上のレスポンスイベントを破棄することができます。例えば、コレクターサービスは、レスポンスイベントが生成された時点以外の他の属性に基づいてメッセージを破棄することができます。さらに、コレクターサービスは、しきい値未満のストリーミングレートでメッセージを提供するために、低品質または攻撃的と予測されるメッセージを破棄することができます。

発明の詳細

では、図面を交えて、本発明の詳細について説明をしていきます。

図１は、メッセージングプラットフォームで交換されるメッセージを持つメッセージストリームのコンテンツに一致するクエリサブスクリプションに基づいて、クライアントアプリケーションにリアルタイムメッセージを時間経過でストリーミングするシステムの概要図です。

これは、1つ以上のサーバーコンピューター102で実行可能なメッセージングプラットフォーム104と、計算デバイス124によって実行可能なクライアントアプリケーション126を含むシステム100を示したものです。

メッセージングプラットフォーム104は、メッセージ配信の速度を向上させる、アクティブなクエリサブスクリプション141の数の変動を処理するためのコンピュータリソースの管理を効果的に制御する、および/または、クエリサブスクリプション141の一致およびこれらのメッセージ132をリアルタイムで配信するセキュリティを高める方法で、メッセージストリーム114のコンテンツと一致するクエリサブスクリプション141に従って、リアルタイムメッセージ132をクライアントアプリケーション126に時系列でストリームするように構成されています。

メッセージングプラットフォーム104は、リアルタイム通信を促進するためのプラットフォームであり、クライアントアプリケーション126はネットワーク150を介してメッセージングプラットフォーム104と通信するように構成されています。メッセージ132は、新しいメッセージの作成や投稿などのメッセージ作成イベントを指すことができます。

メッセージングプラットフォーム104には、サブスクリプションエグゼキュータ116、イベントプロデューサーシステム106、およびトランスポートエンジン122が含まれています。これらの各モジュールは、メッセージの一致、生成、配信のためのさまざまな機能を提供します。例えば、メッセージ132は、タイムライン130の1つ以上にストリームされることができます。クライアントアプリケーション126を使用して、検索用語「犬」を含むメッセージ132を取得するアクティブなクエリを提出することができます。そして、クライアントアプリケーション126は、検索用語「犬」を含むメッセージ132をタイムライン130にストリームします。

この方法で、クエリサブスクリプション141の管理は、2つの別々のモジュール、すなわち、サブスクリプションエグゼキュータ116とトランスポートエンジン122を使用して、メッセージ132の配信から分離されています。イベントプロデューサーシステム106は、メッセージキュー112のメッセージストリーム114に対するクエリの一致により、ストリーム検索クエリ結果をサポートするように構成されています。

図2は、クエリサブスクリプション生成の操作をさらに詳しく示すシステム100を示しています。図1および図2を参照すると、クライアントアプリケーション126は、クエリサブスクリプションリクエスト140を生成し、そのリクエストをネットワーク経由でサブスクリプションエクスキュータ116のデータクエリAPI118に送信します。

ユーザーはクライアントアプリケーション126のユーザーインターフェース128を使用してアクティブなクエリを送信し、アクティブなクエリの送信に応じて、クライアントアプリケーション126はクエリサブスクリプションリクエスト140を生成して送信します。クエリサブスクリプションリクエスト140は、新しいクエリサブスクリプション141の開始と、イベントプロデューサーシステム106でのクエリサブスクリプション141の実装の開始を設定するためのものです。クエリサブスクリプションリクエスト140は、HTTP上のGraphQLサブスクリプションクエリです。

クエリサブスクリプションリクエスト140には、サブスクリプションデータ142が含まれています。サブスクリプションデータ142には、1つまたは複数のクエリ用語144とユーザーのユーザー識別子146が含まれています。クエリ用語144には、ユーザーによって提供された検索用語が含まれています。サブスクリプションデータ142には、変数や1つ以上の操作名が含まれています。

サブスクリプションデータ142には、クライアントアプリケーション識別子と認証されたユーザー識別子が含まれています。クエリサブスクリプションリクエスト140には、クエリサブスクリプション141がアクティブである時間値を示す有効期限時間148が含まれています。時間が有効期限時間148を超えると、クエリサブスクリプション141はタイムアウトと見なされます（再度リクエストが受信されない限り）。クライアントアプリケーション126は、有効期限時間148の値を決定し、それはクライアントアプリケーション126によって送信された時間および/または再更新サブスクリプションの数に依存します。

クエリサブスクリプションリクエスト140の受け取りに応じて、サブスクリプションエクスキュータ116は、サブスクリプションデータ142のクエリ用語144に基づいてトランスポートトピック134を識別します。トランスポートトピック134は、トランスポートエンジン122で検出可能な記述的および/または数値的な識別子です。サブスクリプションエクスキュータ116は、トピックライブラリ135を使用してトランスポートトピック134を識別します。

これは、トランスポートトピックの複数を定義するものです。例として、サブスクリプションエクスキュータ116は、トピックライブラリ135の複数のトランスポートトピックのうち、クエリ用語144に対応するものを識別することができます。サブスクリプションエクスキュータ116がクエリ用語144を使用してトピックライブラリ135からトランスポートトピック134を識別できない場合、サブスクリプションエクスキュータ116は、クエリサブスクリプション141が失敗したことを示す応答を生成して送信することができます。

データクエリAPI118は、サブスクリプションデータ142を使用してトランスポートトピック134を識別します。データクエリエクスキュータ120は、サブスクリプションデータ142を使用してトランスポートトピック134を識別します。

クエリサブスクリプションリクエスト140の受け取りに応じて、サブスクリプションエクスキュータ116は、サブスクリプションデータ142に基づいてサブスクリプション識別子136を生成します。サブスクリプション識別子136は、クエリサブスクリプション141を識別する識別子です。データクエリAPI118がサブスクリプション識別子136を生成することがあります。データクエリエクスキュータ120がサブスクリプション識別子136を生成することがあります。

サブスクリプションエクスキュータ116は、ユーザー識別子146、クエリ用語144、および/またはサブスクリプションデータ142に含まれるその他の情報（変数、操作名、認証されたユーザー識別子、および/またはクライアントアプリケーション識別子など）に基づいてサブスクリプション識別子136を生成することがあります。サブスクリプションエクスキュータ116は、サブスクリプションデータ142をシリアライズしてハッシュ化し、サブスクリプション識別子136を生成するように設定されています。

データクエリAPI118は、ネットワーク150経由で、クライアントアプリケーション126にサブスクリプションステータス応答152を送信するように設定されています。サブスクリプションステータス応答152には、トランスポートトピック134が含まれています。サブスクリプションステータス応答152には、サブスクリプション識別子136が含まれています。サブスクリプションステータス応答152には、クエリサブスクリプションリクエスト140が成功したかどうかを示すステータスメッセージが含まれています。

サブスクリプションステータス応答152の受け取りに応じて、クライアントアプリケーション126は、ネットワーク150経由でトランスポートエンジン122にサブスクライブリクエスト154を生成して送信します。

サブスクライブリクエスト154には、トランスポートトピック134が含まれています。クライアントアプリケーション126は、サブスクリプションステータス応答152で識別されたトランスポートトピック134を使用してサブスクライブリクエスト154を行います。クライアントアプリケーション126は、サブスクリプションエクスキュータ116と同じ方法でサブスクリプションデータ142を使用してトランスポートトピック134を識別することがあります。

サブスクライブリクエスト154には、サブスクリプション識別子136が含まれています。サブスクライブリクエスト154には、ユーザー識別子146が含まれています。クライアントアプリケーション126は、サブスクリプションステータス応答152の受け取りに応じてサブスクライブリクエスト154を送信します。クライアントアプリケーション126は、クエリサブスクリプションリクエスト140の送信とほぼ同時にサブスクライブリクエスト154を送信します。

クライアントアプリケーション126は、クエリサブスクリプションリクエスト140を送信した後、クエリサブスクリプションリクエスト140の送信から500ms未満の期間でサブスクライブリクエスト154を送信します。クライアントアプリケーション126は、クエリサブスクリプションリクエスト140を送信した後、クエリサブスクリプションリクエスト140を送信した後の100-200msの期間でサブスクライブリクエスト154を送信します。

サブスクライブリクエスト154に応答して、トランスポートエンジン122は、メッセージ132をクライアントアプリケーション126にストリームするためのデリバリーチャンネル125を確立します。デリバリーチャンネル125は、トランスポートトピック134に関連付けられており、デリバリーチャンネル125を介して配信されるメッセージ132は、トランスポートトピック134に対応しています。

トランスポートエンジン122は、ユーザー識別子146およびクエリ用語144（および/またはコントリビュータ識別子）に対応するトランスポートトピック134にクライアントアプリケーション126をサブスクライブさせることがあります。

デリバリーチャンネル125は、クエリサブスクリプション141がアクティブである間、開いたままであり、アクティブです。トランスポートエンジン122は、デリバリーチャンネル125にチャンネル識別子を割り当てることがあります。トランスポートエンジン122は、ネットワーク150を介して、チャンネル識別子をクライアントアプリケーション126に送信することがあります。クライアントアプリケーション126は、定期的にデリバリーチャンネル125に再サブスクライブすることがあります（例：毎2分）。

クエリがアクティブである場合（例：ユーザーインターフェース128に可視の検索列が表示されている場合）、クライアントアプリケーション126は自動的に再サブスクライブリクエストを送信します。クエリが終了する場合（例：列がユーザーインターフェース128からスクロールオフされる場合）、クライアントアプリケーション126は、トランスポートトピック134のサブスクリプションを解除するメッセージをトランスポートエンジン122に送信することがあり、これによりデリバリーチャンネル125が閉じられます。

図3は、イベントプロデューサシステム106とサブスクリプションエグゼキュータ116の動作を示しており、イベントプロデューサシステム106でクエリサブスクリプション141を設定し、イベントプロデューサシステム106からのレスポンスイベント156を受け取る様子を示しています。図4は、サブスクリプションエグゼキュータ116とトランスポートエンジン122がデリバリーイベント160をトランスポートエンジン122に配信する動作を示しています。

クエリサブスクリプションリクエスト140を受け取った応答として、データクエリAPI118はクエリサブスクリプション141を生成し、イベントプロデューサマネージャ108に送信します。データクエリAPI118は、クエリサブスクリプション141をThriftリクエストとしてイベントプロデューサマネージャ108に送信することができます。Thriftリクエストは、メッセージングプラットフォーム104のさまざまなコンポーネント間で通信するために使用されるリモートプロシージャコールシステムです。クエリサブスクリプション141は、サブスクリプションデータ142（例：クエリ用語144を含むことができる）と、ユーザー識別子146を含んでいます。

クエリサブスクリプション141はサブスクリプション識別子136を含みます。また、クエリサブスクリプション141は有効期限148を含みます。さらに、クエリサブスクリプション141がイベントプロデューサマネージャ108に送信される際には、ユーザー識別子146と他のサブスクリプション関連データを含むことで、イベントプロデューサシステム106がレスポンスイベント156内でそれらを返すことができるようにします。イベントプロデューサマネージャ108は、有効期限148を使用してクエリサブスクリプション141がタイムアウトしたかどうかを判断します。例えば、時間が有効期限148を超えていた場合、イベントプロデューサマネージャ108はイベントプロデューサ110にクエリサブスクリプション141を削除するよう指示することができます。

イベントプロデューサマネージャ108は、クエリサブスクリプション141をイベントプロデューサ110（またはイベントプロデューサ110のグループ）に割り当てます。いくつかの例では、イベントプロデューサマネージャ108は、ユーザー識別子146に基づいてクエリサブスクリプション141を割り当てます。クエリサブスクリプション141は、イベントプロデューサ110（またはグループ内の各イベントプロデューサ110）に保存されます。イベントプロデューサ110は、メッセージストリーム114からのメッセージがクエリサブスクリプション141のクエリ用語144を含むと判断された応答としてレスポンスイベント156を生成します。イベントプロデューサ110は、レスポンスイベント156をレスポンスイベントバス123に公開することができます。

コレクターサービス170がレスポンスイベント156を受け取り、レスポンスイベント156をレスポンスイベントバス132に公開します。さらに、コレクターサービス170は、同じメッセージ132に関連するレスポンスイベント156を重複削除することや、ストリーミングレートが閾値を下回るように一つ以上のレスポンスイベント156を破棄すること、および/またはイベントプロデューサシステム106のクエリサブスクリプション141の健康状態に関する定期的なステータスメッセージを生成することができます。各レスポンスイベント156は、クエリサブスクリプション141に一致するメッセージ132を一意に識別するメッセージ識別子158を含んでいます。各レスポンスイベント156はサブスクリプションデータ142（例えば、クエリ用語144）とユーザー識別子146を含みます。

サブスクリプションエグゼキュータ116は、イベントプロデューサシステム106によって公開されたレスポンスイベント156を取得するためにレスポンスイベントバス123に登録します。一般に、サブスクリプションエグゼキュータ116は、メッセージ識別子158によって識別されたメッセージ132（例えば、ハイドレートする）を生成し、トランスポートエンジン122に完全なメッセージ132を提供する前に可視性のルールを適用します。

ハイドレーションとは、生成されたメッセージ132がクライアントアプリケーション126と互換性のあるフォーマットを持ち、ユーザー識別子146によって識別されるユーザーの視点に対応するデータを含むように、メッセージ識別子158とユーザー識別子146からメッセージ132を作成することを指します。サブスクリプションエグゼキュータ116は、メッセージ識別子158とユーザー識別子146に基づいてJavaScriptオブジェクト表記（JSON）メッセージ（例えば、完全なJSONメッセージ）を生成するように設定されています。

サブスクリプションエグゼキュータ116は、各レスポンスイベント156に対応するメッセージ132を生成する際、そのメッセージ132を含む配送イベント160を配送イベントバス121に公開します。

メッセージのハイドレーション中、サブスクリプションエグゼキュータ116は、メッセージ識別子158によって識別されるメッセージ132が可視性ルールに違反していると判断した場合、レスポンスイベント156を破棄することができます。例えば、レスポンスイベント156が、ユーザー識別子146によって識別されるユーザーを制限（例えば、ブロックまたはミュート）したユーザーによって作成されたメッセージ132を識別する場合、サブスクリプションエグゼキュータ116は、レスポンスイベント156を破棄することができます。

データクエリエグゼキュータ120は、レスポンスイベントバス123に登録します。データクエリエグゼキュータ120は、イベントプロデューサ110によってレスポンスイベントバス123に公開されるレスポンスイベント156を取得するためにレスポンスイベントバス123を監視することができます。データクエリエグゼキュータ120は、レスポンスイベントバス123から取得した各レスポンスイベント156に対応するメッセージ132を生成するためにデータクエリAPI118と通信することができます。

例として、レスポンスイベント156の場合、データクエリエグゼキュータ120は、メッセージ識別子158とサブスクリプションのメタデータ（例: サブスクリプションデータ142やサブスクリプション識別子136）をデータクエリAPI118に渡します。データクエリエグゼキュータ120は、メッセージ識別子158とサブスクリプションのメタデータを渡すために、データクエリAPI118にThriftリクエストを実行します。

データクエリAPI118は、メッセージ識別子158とサブスクリプションのメタデータからデータを取り出し、オリジナルのクエリサブスクリプション141をレスポンスイベント156に対して実行し、メッセージ132（例: 完全なJSONメッセージ）を生成します。

データクエリエグゼキュータ120は、データクエリAPI118から実行結果（例: メッセージ132）を受け取り、配送イベントバス121上に配送イベント160を公開します。図4に示されているように、配送イベント160にはメッセージ132が含まれています。配送イベント160には、トランスポートトピック134を識別するトランスポートトピックデータ162が含まれています。

トランスポートエンジン122は、データクエリエグゼキュータ120によって公開された配送イベント160を監視・取得するために、配送イベントバス121を読み込みます。

例として、配送イベント160が配送イベントバス121に公開された場合、トランスポートエンジン122は、配送イベント160を取得し、配送チャンネル125とトランスポートトピック134をマッピングするチャンネルトピックマッピング164に基づいて、配送イベント160内に含まれるメッセージ132をどの配送チャンネル125でストリームするかを決定します。

例えば、トランスポートトピックデータ162は、メッセージ132に関連するトランスポートトピック134を識別し、トランスポートエンジン122は、チャンネルトピックマッピング164に基づいてメッセージ132をストリームする適切な配送チャンネル125を識別します。トランスポートエンジン122は、配送チャンネル125を通じてクライアントアプリケーション126にメッセージ132をストリームするように設定されています。

図5は、複数の配送チャンネル125に関してトランスポートエンジン122の操作の例を示すシステム100を示しています。例えば、クライアントアプリケーション126が複数のクエリサブスクリプション141を確立している場合、トランスポートエンジン122は、アクティブなクエリサブスクリプション141ごとに別々の配送チャンネル125を作成し、それらのメッセージ132をそれぞれの配送チャンネル125を介して配信します。

例えば、検索語「dogs」に関連するクエリサブスクリプション141への応答として、トランスポートエンジン122は、ネットワーク150を介して、第1の配送チャンネル125-1（例:「dogs」配送チャンネル）を介して、サブスクリプションエグゼキュータ116から受け取ったメッセージ132をクライアントアプリケーション126に送信します。

検索語「cats」に関連するアクティブなクエリサブスクリプション141への応答として、トランスポートエンジン122は、ネットワーク150を介して、第2の配送チャンネル125-2（例:「cats」通信チャンネル）を介して、サブスクリプションエグゼキュータ116から受け取ったメッセージ132をクライアントアプリケーション126に送信します。

クライアントアプリケーション126は、メッセージングプラットフォーム104にメッセージ132を生成して受け取るための2つのリクエスト（例: クエリサブスクリプションリクエスト140およびサブスクライブリクエスト154）を送信しますが、一部の例では、クライアントアプリケーション126は、サブスクリプションエグゼキュータ116またはトランスポートエンジン122のいずれかと更新を行うことができます。

一部の例では、クライアントアプリケーション126はトランスポートエンジン122と更新を行います。例えば、トランスポートトピック134へのサブスクリプションは、一定の時間間隔の後に期限切れとなる可能性がありますが、クライアントアプリケーション126によってサブスクリプションが更新される限り、それは期限切れになりません（例: クライアントアプリケーション126は、一定の期間（例: 2分ごと）にトランスポートエンジン122と更新を行わないと、クエリサブスクリプション141が期限切れになります）。

図6は、更新操作の一面に関する操作の例を示すシステム100を示しています。一部の例では、サブスクリプションエグゼキュータ116（例: データクエリエグゼキュータ120）がサブスクリプションの更新を管理するように設定されています。例えば、クライアントアプリケーション126は、トランスポートトピック134へのサブスクリプションを更新するために、ネットワーク150を介して、サブスクライブ更新リクエスト161をトランスポートエンジン122に送信することができます。

サブスクライブ更新リクエスト161への応答として、トランスポートエンジン122は、トランスポートトピックデータ162をデータクエリエグゼキュータ120に提供することができます。

トランスポートトピックデータ162には、トランスポートトピック134、サブスクリプション識別子136、およびユーザー識別子146のレスポンスイベント156を生成するためにどのイベントプロデューサ110が割り当てられているかに関する情報が含まれている可能性があります。トランスポートトピックデータ162への応答として、データクエリエグゼキュータ120は、イベントプロデューサシステム106に更新呼び出し171を送信することができます。

イベントプロデューサマネージャ108は、更新呼び出し171を受け取り、有効期限時間148を更新して、クエリサブスクリプション141がイベントプロデューサ110から削除されないようにします。

更新呼び出し171への応答として、イベントプロデューサマネージャ108は、ステータスメッセージ166をレスポンスイベントバス123に公開し、これはデータクエリエグゼキュータ120によって受け取られます。データクエリエグゼキュータ120は、トランスポートエンジン122がステータスメッセージ166をクライアントアプリケーション126に配信できるように、ステータスメッセージ166を配信イベントバス121に公開することができます。

図7は、図1のクライアントアプリケーション126のユーザーインターフェース728の一例を示しています。クライアントアプリケーション126は、別々のカラムとして複数のタイムラインを表示するように設定されています。例えば、ユーザーはカラムを追加または削除することで、タイムラインを追加または削除することができます。検索を指定するカラムの追加は、クエリサブスクリプション141を開始します。カラムの削除によりクエリサブスクリプション141が期限切れとなります。ユーザーは第1のカラムを追加して、第1のタイムライン730-1を提供することができます。第1のタイムライン730-1は、クエリサブスクリプション141がアクティブな間、特定のユーザー（例: ユーザーA）によって生成されたメッセージ732を表示することができます。

例えば、第1のカラムが表示されている間、ユーザーAによって生成されたメッセージ732は、第1のタイムライン730-1に表示されます。例えば、ユーザーAが特定の時点でメッセージングプラットフォーム104にメッセージ732を投稿すると、そのメッセージ732は、メッセージ732が投稿された時点の近くで、第1のタイムライン130-1にプッシュされ、ユーザーはユーザーAによって新しく作成されたメッセージ732をリアルタイムまたはほぼリアルタイムで表示することができます。一部の例では、第1のタイムライン730-1は、新しく作成されたメッセージ732が第1のタイムライン730-1のトップにプッシュされるように、時系列の順序でレンダリングされます。

ユーザーは第2のカラムを追加して、ハッシュタグ#GraphQLに一致するメッセージ732の第2のタイムライン730-2を提供することができます。例えば、検索語「#GraphQL」を示す第2のカラムの追加は、クエリサブスクリプション141を開始します。第2のタイムライン730-2は、検索語「#GraphQL」を含むコンテンツを含むメッセージ732を表示することができます。例えば、第2のカラムが表示されている間、メッセージングプラットフォーム104で交換される検索語「#GraphQL」を含むメッセージ732は、第2のタイムライン730-2にストリームされます。一部の例では、第2のタイムライン730-2は、検索語「#GraphQL」を含む新しく作成されたメッセージ732が、第2のタイムライン730-2のトップにプッシュされるように、時系列の順序でレンダリングされます。

ユーザーは第3のカラムを追加して、検索語「GraphQL Summit」を含むメッセージ732の第3のタイムライン730-3を提供することができます。例えば、検索語「GraphQL Summit」を示す第3のカラムの追加は、クエリサブスクリプション141を開始します。第3のタイムライン730-3は、検索語「GraphQL Summit」と一致するコンテンツを含むメッセージ732を表示することができます。

例えば、第3のカラムが表示されている間、検索語「GraphQL Summit」と一致するメッセージ732は、クエリサブスクリプション141がアクティブな間、第3のタイムライン730-3にストリームされます。第3のタイムライン730-3は、検索語「GraphQL Summit」を含む新しく作成されたメッセージ732が、第3のタイムライン730-3のトップにプッシュされるように、時系列の順序でレンダリングされます。

図8は、クエリサブスクリプション141に基づいてリアルタイムのメッセージ132をストリームするメッセージングプラットフォーム104の操作例を示すフローチャート800を示しています。フローチャート800は、図1から6のシステム100を参照して説明されています。

操作802では、クライアントアプリケーション126からのクエリサブスクリプションリクエスト140の受領を受けて、サブスクリプション実行者116がクエリサブスクリプション141をイベントプロデューサーシステム106に送信します。

例えば、データクエリAPI118は、ネットワーク150経由でクライアントアプリケーション126からクエリサブスクリプションリクエスト140を受け取り、クエリサブスクリプション141を生成します。データクエリAPI118は、イベントプロデューサーマネージャ108にクエリサブスクリプション141を送信します。クエリサブスクリプションリクエスト140はGraphQLのサブスクリプションクエリであり、データクエリAPI118はGraphQL APIであり、データクエリ実行者120はGraphQLの実行者です。

操作804では、トランスポートエンジン122が、クライアントアプリケーション126とトランスポートエンジン122との間に、ネットワーク150経由でクライアントアプリケーション126から受け取ったサブスクライブリクエスト154の受領を受けて、デリバリーチャンネル125を作成します。

操作806では、イベントプロデューサーシステム106が、メッセージストリーム114のメッセージで、クエリサブスクリプション141の条件を満たす内容を持つものに対して、レスポンスイベント156を生成します。

操作808では、サブスクリプション実行者116が、レスポンスイベント156によって識別されたメッセージの作者が、ユーザー識別子146に関連するユーザーを制限しているか（例：ブロックやミュート）どうかを判断し、操作810では、ユーザーが作者によって制限されていると判断された場合、サブスクリプション実行者116が、レスポンスイベント156によって識別されたメッセージを破棄します。

操作812では、トランスポートエンジン122が、作者によって制限されていないと判断されたユーザーへ、クエリサブスクリプション141がアクティブな期間中に、デリバリーチャンネル125を通じて、クライアントアプリケーション126のユーザーインターフェース128にメッセージ132をストリームします。

図9は、クライアントアプリケーション126がメッセージングプラットフォーム104上でアクティブなクエリを生成し、アクティブなクエリに一致するメッセージ132のストリームを受信する操作の例を示すフローチャート900を示しています。

操作902は、クライアントアプリケーション126が、ネットワーク150を介して、メッセージングプラットフォーム104のサブスクリプション実行者116にクエリサブスクリプションリクエスト140を送信するもので、このクエリサブスクリプションリクエスト140は、サブスクリプション実行者116がメッセージングプラットフォーム104上で交換されるメッセージのメッセージキュー112上で実行されるクエリサブスクリプション141を生成するように設定されています。

操作904は、クライアントアプリケーション126が、ネットワーク150を介して、メッセージングプラットフォーム104のトランスポートエンジン122にサブスクライブリクエスト154を送信するもので、このサブスクライブリクエスト154は、トランスポートエンジン122がトランスポートエンジン122とクライアントアプリケーション126との間にデリバリーチャンネル125を作成するように設定されています。

操作906は、クライアントアプリケーション126が、クエリサブスクリプション141の基準を満たすメッセージ132のストリームを、クエリサブスクリプション141がアクティブな間、クライアントアプリケーション126のユーザーインターフェース128上で時間経過とともにデリバリーチャンネル125を介して受信するものです。

操作908は、クライアントアプリケーション126が、ネットワーク150を介して、トランスポートエンジン122にサブスクライブ更新リクエスト161を定期的に送信するもので、このサブスクライブ更新リクエスト161は、トランスポートエンジン122がデリバリーチャンネル125を更新し、サブスクリプション実行者116がクエリサブスクリプション141を更新するように設定されています。

例として、サブスクライブ更新リクエスト161に応答して、トランスポートエンジン122は、データクエリ実行者120にトランスポートトピックデータ162を提供することができます。トランスポートトピックデータ162に応答して、データクエリ実行者120は、イベントプロデューサーシステム106に更新呼び出し171を送信することができます。したがって、クライアントアプリケーション126はトランスポートエンジン122のみで更新を行い、下記に述べるように、メッセージングプラットフォーム104の構造は、クエリサブスクリプション141がトランスポートエンジン122とサブスクリプション実行者116の両方で更新されるようにすることで、クライアントアプリケーション126とメッセージングプラットフォーム104との間で送信される通信の量を減少させることができます。

図10Aは、サーバーコンピュータ1002で実行可能なメッセージングプラットフォーム1004と、コンピューティングデバイス1024で実行可能なクライアントアプリケーション1026を含むシステム1000の概要図です。メッセージングプラットフォーム1004は、メッセージングプラットフォーム1004で交換される大量のメッセージストリーム1014のコンテンツに一致するクエリサブスクリプション1041に基づいて、リアルタイムのメッセージ1032をクライアントアプリケーション1026にストリームでネットワーク1050を介して送信するように構成されています。図10Bでは、イベントプロデューサーシステム1006の詳細を示しています。

イベントプロデューサーシステム1006には、イベントプロデューサーマネージャ1008、イベントプロデューサーマネージャ1008に通信的に接続されたイベントプロデューサ1010、およびイベントプロデューサ1010に通信的に接続されたコレクターサービス1070が含まれています。イベントプロデューサーマネージャ1008は、クエリサブスクリプション1041を取得し、クエリサブスクリプション1041の基準に従ってメッセージストリーム1014からのコンテンツに一致するようにイベントプロデューサ1010を構成します。

イベントプロデューサ1010は、イベントプロデューサーグループ1013に配置され、メッセージストリーム1014に対して多数のクエリサブスクリプション1041を実行します。例えば、イベントプロデューサーシステム1006には、第一のイベントプロデューサーグループ1013-1、第二のイベントプロデューサーグループ1013-2、第三のイベントプロデューサーグループ1013-3、および第四のイベントプロデューサーグループ1013-4など、複数のイベントプロデューサーグループ1013が含まれる可能性があります。各イベントプロデューサーグループ1013は、フルメッセージストリーム1014を受信するように構成されています。

各イベントプロデューサ1010は、メッセージストリーム1014の該当する部分からのメッセージに対してクエリサブスクリプション1041がマッチした際のレスポンスイベント156を生成するように構成されています。また、各イベントプロデューサ1010は、該当するイベントプロデューサ1010でのクエリサブスクリプション1041の健全性を示すステータスレスポンス1075を定期的に生成するように構成されています。

上述したように、クエリサブスクリプション1041は、有効期限と関連付けられている場合があります。例えば、イベントプロデューサーマネージャ1008は、クエリサブスクリプション1041が割り当てられたイベントプロデューサ1010でのアクティブな時間を監視し、その時間が有効期限の値を超えると、リソースを節約するために該当するクエリサブスクリプション1041を解除するように構成されています。

図11は、コレクターサービス1170の例を示しています。このコレクターサービス1170は、図10Bのコレクターサービス1070の例であり、前述の図に関して議論された特徴を持つことができます。コレクターサービス1170は、レスポンスイベント1056をレスポンスイベントバス1023に公開する前に、メモリキャッシュ1180と連携して、レスポンスイベント1056によって識別されたメッセージ1032の重複を削除し、および/またはクライアントアプリケーション1026へのストリーミング速度をストリーミング速度しきい値1173以下にするためにストリーミング速度を減少させることができます。

コレクターサービス1170は、クライアントアプリケーション1026に既に配信されたメッセージ1032を識別するレスポンスイベント1056の重複を削除するために設定されたデデュプリケーター1172を含むことができます。例として、クエリサブスクリプション1041が2つのイベントプロデューサーグループ1013に割り当てられている場合（それぞれがメッセージストリーム1014の全体を受信する）、これはイベントプロデューサー1010が重複したメッセージ1032を識別する原因となる可能性があります。しかし、デデュプリケーター1172は、同じメッセージがクライアントアプリケーション1026に複数回提供されないように重複を識別するように設定されています。

コレクターサービス1170がレスポンスイベント1056をレスポンスイベントバス1023に公開すると、コレクターサービス1170はそのレスポンスイベント1056をメモリキャッシュ1180に格納します。新しいレスポンスイベント1056の受信に対して、デデュプリケーター1172は、新しいレスポンスイベント1056のメッセージ識別子がメモリキャッシュ1180に格納されているかどうかを確認します。メッセージ識別子がメモリキャッシュ1180に格納されていない場合（例えば、それが重複でないことを示している場合）、コレクターサービス1170は新しいレスポンスイベント1056をレスポンスイベントバス1023に公開し、その新しいレスポンスイベント1056をメモリキャッシュ1180に格納します。新しいレスポンスイベント1056のメッセージ識別子がメモリキャッシュ1180に格納されている場合（例えば、それが重複であることを示す場合）、デデュプリケーター1172は新しいレスポンスイベント1056を破棄するように設定されています。

コレクターサービス1170は、メモリキャッシュ1180のステータスレスポンス1075を照会することにより、クエリサブスクリプション1041のヘルスステータスを判断するために設定されたステータスメッセージハンドラー1174を含むことができます。例えば、コレクターサービス1170は、定期的にイベントプロデューサー1010からステータスレスポンス1075を受信し、そのステータスレスポンス1075をメモリキャッシュ1180に格納することができます。

さらに、コレクターサービス1170には、イベントプロデューサー1010でクエリサブスクリプション1041を再起動するために設定されたサブスクリプション再起動者1176、およびレスポンスイベント1056によって識別されるメッセージ1032がクライアントアプリケーション1026にストリーミング速度しきい値1173以下で配信されるようにレスポンスイベント1056の1つ以上を破棄するために設定されたクオータチェッカー1178を含むことができます。

クオータチェッカー1178は、レスポンスイベント1056によって識別されるメッセージ1032のエンゲージメント確率メトリクス1177を受け取るように設定されており、これらのメトリクスはメッセージ1032とのエンゲージメントの予測レベルを示しています。

また、クオータチェッカー1178は、レスポンスイベント1056によって識別されるメッセージ1032のメッセージヘルスメトリクス1179を受け取るように設定されており、これらのメトリクスはメッセージングプラットフォーム1004の1つ以上の条件（例: 悪意のある行動、憎悪的な行動、脅迫など）を違反するリスクレベルを示しています。

図12は、コレクターサービス1270の例を示しています。コレクターサービス1270は、第一のコレクターサービスインスタンス1271-1、第二のコレクターサービスインスタンス1271-2、第三のコレクターサービスインスタンス1271-3など、複数のコレクターサービスインスタンス1271を含むことができます。

図12には三つのコレクターサービスインスタンス1271が示されていますが、コレクターサービス1270は任意の数のコレクターサービスインスタンス1271を含むことができます。各コレクターサービスインスタンス1271は、レスポンスイベント1056および/またはステータスレスポンス1075の異なる部分を受信することができます。

コレクターサービス1270は、2層のストリーミングレート調整プロセスを実行するように構成されています。第一の層では、各コレクターサービスインスタンス1271は、レスポンスイベント1056の異なる部分を受信し、個々のストリーミングレートしきい値1284以下のレスポンスイベント10056の数を持つサブセットを取得するために1つ以上のレスポンスイベント1056を破棄することで、レスポンスイベント1056のサブセットを取得します。

第二の層では、各コレクターサービスインスタンス1271は、そのサブセットをメモリキャッシュ1180に格納し、少なくとも1つのコレクターサービスインスタンス1271がサブセットを集約し、集約されたサブセットがストリーミングレートしきい値1173以下のレスポンスイベント1056の数を持つように、1つ以上のレスポンスイベント1056を破棄します。

加えて、コレクターサービス1270は、2層のデデュプリケーションプロセスを実行するように構成されています。第一の層では、各コレクターサービスインスタンス1271は、レスポンスイベント156の異なる部分を受信し、同じメッセージ1032を識別するレスポンスイベント1056を取り除きます。各コレクターサービスインスタンス1271は、レスポンスイベント1056のそれぞれのグループをメモリキャッシュ1180に格納します。

少なくとも1つのコレクターサービスインスタンス1271が、メモリキャッシュ1180を照会してグループを集約し、集約されたグループから同じメッセージ1032を識別するレスポンスイベント1056を破棄します。

図13は、システム1000の例示的な操作を示すフローチャート1300を描写しています。フローチャートは図10Aおよび10Bのシステム1000を参照して議論されますが、図13の操作はここで議論されているシステムのいずれにも適用可能です。

操作1302は、サーバーコンピュータ1002で実行可能なメッセージングプラットフォーム1004上で交換されるメッセージのメッセージストリーム114を含むメッセージキュー1012の内容と一致するためのクエリーサブスクリプション1041をイベントプロデューサーマネージャ1008で受け取るものです。このメッセージングプラットフォーム1004は、コンピュータデバイス1024で実行可能なクライアントアプリケーション1026のユーザーインターフェースにメッセージ1032を配信するように設定されています。

操作1304は、メッセージキュー1012からメッセージストリーム1014のメッセージを受け取るように設定された複数のイベントプロデューサーグループ1013の1つであるイベントプロデューサーグループ1013に、イベントプロデューサーマネージャ1008がクエリーサブスクリプション1041を割り当てるものです。

操作1306は、クエリーサブスクリプション1041のクエリータームを含むメッセージストリーム114のメッセージのそれぞれの部分からのメッセージに対して、個別のイベントプロデューサー1010が応答イベント1056を生成するものです。

操作1308は、応答イベント1056がクライアントアプリケーション1026に配信されるメッセージ1032のメッセージ識別子を含む場合、コレクターサービス1070が応答イベント1056を応答イベントバス1023に公開するものです。

図14は、図11のコレクターサービス1170および/または図12のコレクターサービス1270を持つ図10Aおよび10Bのシステム1000の例示的な操作を示すフローチャート1400を描写しています。図14の操作はここで議論されているシステムのいずれにも適用可能です。

操作1402には、サーバーコンピュータ1002で実行可能なメッセージングプラットフォーム1004で交換されるメッセージのメッセージストリーム1014を受信することが含まれます。ここで、メッセージングプラットフォーム1004は、計算デバイス1024で実行可能なクライアントアプリケーション1026のユーザーインターフェースにメッセージ1032を配信するように設定されています。

操作1404には、メッセージングプラットフォーム1004でのアクティブなクエリのためのクエリサブスクリプション1041を受信することが含まれます。

操作1406には、クエリサブスクリプション1041がアクティブな間、クエリサブスクリプション1041のクエリ用語を含むメッセージストリーム1014のメッセージに対応してレスポンスイベント1056を生成することが含まれます。

操作1408には、レスポンスイベント1056によって識別されたメッセージが、クライアントアプリケーション1026にストリーミングレートのしきい値1173以下で配信されるようにするために、1つ以上のレスポンスイベント1056を破棄することが含まれます。

操作1410には、ネットワーク1050を介して、ストリーミングレートのしきい値1173以下の方法で、メッセージ1032をクライアントアプリケーション1026に配信することが含まれます。

ここがポイント！

従来のメッセージングシステムでは、大量のメッセージがリアルタイムに交換されるため、特定のクエリや条件に一致するメッセージを効果的に識別し、それらをクライアントアプリケーションに配信することは技術的に難しいものでした。特に、メッセージのストリーミングレートを制御することなく、適切なメッセージを選択し、配信することは困難だったという課題がありました。

そこで、本発明では、メッセージングプラットフォームにおけるメッセージの流れを受け取り、クエリサブスクリプションに基づいて特定のメッセージを効果的に識別するシステムと手法が示されました。このシステムには、イベントプロデューサーマネージャがあり、クエリサブスクリプションを受け取り、それに基づいてイベントプロデューサーグループに分配します。それぞれのイベントプロデューサーは、メッセージの特定の部分を受け取り、クエリ条件に一致するメッセージに対してレスポンスイベントを生成します。そして、ストリーミングレートのしきい値に基づいて、選択されたメッセージをクライアントアプリケーションに適切なレートで配信します。

これにより、大量のメッセージの中から関連性のあるものをリアルタイムで効果的に選択し、適切なストリーミングレートで配信することが可能になるのです。

未来予想

本発明を用いることによる利益としては、上述のとおり、情報の取得やフィルタリングについての迅速性が向上すること、それによる帯域幅の節約（リソースの最適化）が挙げられます。また、クエリベースのサブスクリプションにより、ユーザーは自分の関心や必要に合わせた情報のみを受け取ることができるため、パーソナライズされたユーザーエクスペリエンスが得られます。

近未来の予測として、このような技術と、AI・機械学習技術とを統合すれば、ユーザーの過去の行動や傾向に基づいて、より適切なメッセージや情報を自動的にフィルタリングする技術が考えられます。また、エッジコンピューティングとの統合がなされれば、エッジデバイスでのリアルタイムのメッセージフィルタリングや処理を行い、中央のサーバーへの負荷を軽減する技術の開発が期待されます。

特許の概要

スクロールリフレッシュの特許技術を深掘り！

近年、急速な情報の増加と変化が私たちの日常生活に大きな影響を与えています。SNSの投稿、ニュース記事、ブログエントリーなど、情報は常に私たちの周りに溢れています。その結果、最新情報に追いつくことや、興味深い情報を見逃さないためには、効率的な情報取得方法が求められています。

このような課題に対して、現在ではスマホの画面を下にひっぱることによって情報をリフレッシュする、「スクロールリフレッシュ」の技術がよく用いられています。実はこの技術はTwitter社の特許なのです。この技術によって手間をかけずに常に最新の情報にアクセスできるため、情報収集の効率が向上します。この革新的な技術の特許の内容について、今回は詳説していきます。

発明の背景

近年、コンピューティングデバイスは多くの人々の日常生活でますます重要な役割を果たしています。例えば、多くの人々は自宅や職場でコンピュータを使用し、他者とコミュニケーションをしたり、オンラインニュースや音楽、映画などのデジタルコンテンツを消費したり、デジタルコンテンツを作成したり、データを分析したり、タスクやカレンダーを整理したり、さまざまな他の機能を実行したりしています。

さらに、多くの人々は携帯電話やパーソナルデジタルアシスタント、iPhoneなどのモバイルコンピューティングデバイス、タブレットコンピュータなど、同様の機能を提供するさまざまなコンピューティングデバイスを使用しています。 多くのコンピューティングデバイスは、ユーザーの入力をより便利な方法で受け付けるためにタッチセンシティブディスプレイを備えています。

ただし、コンピューティングデバイスにタッチセンシティブディスプレイが含まれているかどうかにかかわらず、コンピューティングデバイスのユーザーは、そのようなデバイスとの相互作用をより便利で使いやすくしたいという欲求を持っています。多くの場合、このような便益と使いやすさは、ユーザーがコンピューティングデバイスとの対話を行うためのユーザーインターフェースを向上させることによって向上されます。

どんな発明？

発明の目的

上記背景に鑑みて、本発明は、ユーザーインターフェースのメカニズムのいくつかを提供します。1つの側面によれば、コンテンツエリアの表示です。第1のコマンドに関連する入力を受け取り、第1のコマンドにはコンテンツエリアをスクロールする要求が含まれます。次に、第1のコマンドに基づいて第2のコマンドが実行され、第2のコマンドを実行することがコンテンツエリアのリフレッシュのトリガーとなります。

さらに1つの側面によれば、スクロール可能なコンテンツアイテムのリストが表示されます。スクロールコマンドに関連する入力を受け取り、その後、スクロールコマンドに基づいてスクロール可能なリフレッシュトリガーが表示されます。その後、スクロールコマンドに基づいて、スクロール可能なリフレッシュトリガーがアクティベートされたことが判断された場合、スクロール可能なコンテンツアイテムのリストがリフレッシュされます。少なくとも1つのアレンジメントでは、スクロールコマンドがスクロール可能なリフレッシュトリガーが完全に表示された状態で完了したことが判断されることによって、スクロール可能なリフレッシュトリガーがアクティベートされたことが判断されます。

さらに1つ以上の側面によれば、スクロール可能なコンテンツアイテムのリストが表示され、そのリストは年代順に配置された複数の個別のコンテンツアイテムを含みます。スクロールコマンドに関連する入力を受け取り、その入力はタッチベースのユーザー入力を表します。その後、スクロールコマンドに基づいて、スクロール可能なリフレッシュトリガーがスクロール可能なコンテンツアイテムのリストとともに表示されます。

その後、スクロール可能なリフレッシュトリガーが完全に表示されたことが判断された場合、スクロール可能なリフレッシュトリガーをアクティベートするための指示が提供されます。コンテンツアイテムのスクロール可能なリストが、スクロール可能なリフレッシュトリガーが完全に表示された状態でスクロールコマンドが完了したことが判断されることによってリフレッシュされます。

さらに、コンテンツアイテムのスクロール可能なリストは自動的にスクロールされ、スクロール可能なコンテンツアイテムのリストがリフレッシュされたことが判断されると、スクロール可能なリフレッシュトリガーが表示されなくなってもよいでしょう。

発明の詳細

図1は、本発明の例によるコンピューティングデバイスを示しています。

コンピューティングデバイス100は、プロセッサ102、メモリ104、入出力インタフェース106、タッチセンシティブディスプレイ108、ネットワークインタフェース110、ワイヤレスインタフェース112、キーパッドインタフェース114、オーディオインタフェース116などのハードウェアおよび/またはソフトウェアコンポーネントを含みます。

これらのコンポーネントのいずれかまたはそれ以上を含むことで、コンピューティングデバイス100はデスクトップコンピュータ、ノートパソコン、サーバ、タブレットコンピュータ、ネットブック、携帯電話、モバイルコンピューティングデバイスなどとして使用されます。少なくとも1つのアレンジメントでは、コンピューティングデバイス100は、ここで説明するコンポーネントのそれぞれを複数含む可能性があります。

例えば、少なくとも1つのアレンジメントでは、コンピューティングデバイス100は2つ以上のプロセッサを含むこともあるでしょう。

コンピューティングデバイス100は、商業的に利用可能なタッチセンシティブなモバイルコンピューティングデバイス（例：APPLE iPhone、APPLE iPad、GOOGLE Nexus One、MOTOROLA Droid、PALM Preなど）を含む可能性があります。少なくとも1つの追加のアレンジメントでは、コンピューティングデバイス100は、商業的に利用可能なコンピューティングデバイス（例：APPLE iMacオールインワンコンピュータ、APPLE MacBookラップトップ、LENOVO ThinkPadラップトップ、ACER Aspire Oneネットブック、DELL OptiPlexデスクトップ、HP Pavilionタブレットなど）を含む可能性があります。

図2は、動作環境の例を示しています。動作環境200には、サーバー202、ゲートウェイ204、公衆交換電話網（“PSTN”）206、および/またはインターネット208、携帯電話ネットワーク、衛星ネットワークなどのその他のネットワークが含まれてもよいでしょう。コンピューティングデバイス100は、上記で説明したハードウェアおよび/またはソフトウェアコンポーネントの1つ以上を使用して、動作環境200内で動作します。

図3は、ここで説明する1つまたは複数の側面に従ってコマンドが実行される方法の例を示しています。図3に示されるような、図示された方法は、コンピューティングデバイス（例えば、コンピューティングデバイス100）で実装され、または実行され、またはそれと連動して実行されます。

ステップ305では、コンテンツ領域が表示されます。例えば、コンピューティングデバイス100は、コンテンツ領域を含むユーザーインターフェースを表示します（例えば、図6のユーザーインターフェース600など）。コンテンツ領域には、テキスト、画像、音声、ビデオ、リンク、および/またはその他のデジタルコンテンツなど、さまざまな種類のコンテンツが含まれます。

例えば、コンテンツ領域には、個人のステータス更新、ブログエントリ、マイクロブログの投稿（ツイートや他のTWITTERのステータス更新、GOOGLE BUZZに関連するステータス更新、FACEBOOKに関連するステータス更新など）、ニュースの見出し、ニュース記事、テキスト、画像、音声、ビデオ、リンク、および/またはその他のコンテンツアイテムの時系列に沿ったリストが含まれます。

ステップ310では、最初のコマンドに関連する入力が受信され、最初のコマンドにはコンテンツ領域をスクロールする要求が含まれます。

例えば、コンピューティングデバイス100は、コンテンツ領域を表示した後（ステップ305）、コンテンツ領域をスクロールする要求に関連するユーザー入力を受信します。このようなユーザー入力は、さまざまな入力アクションに関連して受信されます。

例えば、ユーザーが表示されたスクロールバーと対話する、コンテンツ領域に含まれるコンテンツアイテムをクリックしてドラッグする、マウスに含まれるスクロールホイールを物理的に操作する、コンピューティングデバイス100のハードウェアおよび/またはソフトウェアコンポーネントと対話するなどの操作に関連して受信されます。

例えば、ユーザーは、マウスを使用してコンテンツアイテムと/またはコンテンツ領域に含まれるハンドルをクリックしてドラッグしてスクロールコマンドを開始し（マウスのボタンをクリックしてマウスを動かし続ける）、ドラッグを終了してスクロールコマンドを完了することができます（マウスのボタンを離す）。

少なくとも1つのアレンジメントでは、受信された入力は、タッチベースのユーザー入力を表す場合があります。

例えば、タッチセンシティブディスプレイ108を介してコンピューティングデバイス100が受信したタッチベースのユーザー入力は、ユーザーがコンテンツ領域に対応するディスプレイ上のポイントに物理的に接触し、ポイントをタッチスクリーン上で移動させながら連続的に接触を保ち、次に画面との接触を解除することによって（スクロールコマンドを完了することによって）受信されるものです。

さらに、コンピューティングデバイス100は、タッチセンシティブパッド、タッチセンシティブスタイラス、タッチセンシティブマウス（商業的に利用可能なAPPLE Magic Mouseなど）、または任意のタッチセンシティブな表面を介してタッチベースのユーザー入力を受信することができます。

さらに、タッチセンシティブな表面を使用してスクロールコマンドを要求および/または完了する方法は、上記の例で説明した方法と類似している場合があります（ユーザーはコンテンツアイテムを選択しドラッグしてスクロールコマンドを開始し、ドラッグを解除してスクロールコマンドを完了することができます）。

ステップ315では、第1のコマンドとは独立した第2のコマンドが、第1のコマンドに基づいて実行されます。第2のコマンドは、

例えば、一般的なコンピューティングデバイスでは、第2のコマンドの実行には第1のコマンドの実行が必要ではないか、逆に第1のコマンドの実行には第2のコマンドの実行が必要ではないかという観点から、第1のコマンドとは独立して考えることができます。しかしながら、開示の1つまたは複数の側面によれば、第2のコマンドは第1のコマンドとは独立していますが、第2のコマンドの実行は第1のコマンドに基づいて行われます。より具体的には、第2のコマンドの実行が第1のコマンドに基づいて行われます。ただし、第2のコマンド自体はコンテンツ領域のスクロールとは関連しないコマンドです。少なくとも1つのアレンジメントでは、第2のコマンドの実行は、第1のコマンドに対応するユーザー入力の継続によってトリガーされます。

例えば、第1のコマンドには、指標やアクショントリガーが表示されている間に完了したスクロールコマンドが含まれ、指標やアクショントリガーがスクロールコマンドが完了したときに表示されていたため、第1のコマンドとは独立した第2のコマンド（例えば、コンテンツ領域やコンテンツ領域に含まれるリストのコンテンツのリフレッシュ）が実行されます。この例では、第2のコマンドの実行は、第1のコマンドに対応するユーザー入力の継続によってトリガーされました。スクロールコマンドに関連するユーザー入力が継続し、指標やアクショントリガーが表示されている間に完了したためです。

また、以下でさらに説明する別の例では、第1のコマンドには、第1のスクロール要求と第1のスクロール要求とは異なる第2のスクロール要求とが含まれ、第2のコマンドは第1のスクロール要求と第2のスクロール要求に依存して行われます（

例えば、第1のスクロール要求と第2のスクロール要求の組み合わせによって、第2のコマンドとしてどのアクションやコマンドを実行するかが決まります）。同様に、第1のコマンドには任意の数のスクロールコマンドが含まれ、第1のコマンドに含まれる特定のスクロールコマンドが第2のコマンドを実行するアクションやコマンドを決定します。

上記の例では、コンテンツ領域のリフレッシュが第1のコマンド（スクロールコマンド）とは独立した第2のコマンドの一例として提供されていますが、第2のコマンドには第1のコマンドとは独立した任意の種類のコマンドが含まれます。

例えば、第2のコマンドには、コンテンツ領域の内容の一部を保存する、コンテンツ領域の一部を印刷する、コンテンツ領域の音声および/または視覚的な内容の一部を再生する、テキストを音声で読み上げるためにテキストから音声への変換器を呼び出す、コンテンツ領域の内容に関してさらなるアクションを行うためのダイアログボックスやプロンプトを表示する、コンテンツ領域の内容の一部を他の人に電子メールで送信するためのプロンプトを表示する、コンテンツのページ間をナビゲートする、画面の向きをロックする（画面の向きを“横”ビューにロックする、物理的にデバイスが“縦”向きに回転しても、画面は引き続きコンテンツ領域を横向きで表示する）、新しいモードに入る（ワードプロセシングアプリケーションで、テキスト編集モードからグラフィック編集モードに切り替えるなど）、または他のアクションを含めることができます。

1つまたは複数のアレンジメントにおいて、第1のコマンドは第1のスクロール要求と第2のスクロール要求とを含む場合があります。第2のスクロール要求は、第1のスクロール要求と異なるか別個のものであり、第2のコマンドは第1のスクロール要求と第2のスクロール要求に基づいて実行されます。

また、第1のスクロール要求と第2のスクロール要求は連続的である場合もあります。つまり、第2のスクロール要求（例：画面の右側にスクロールする）は、第1のスクロール要求（例：画面の下側にスクロールする）が開始された後に開始され、完了する前に第1のスクロール要求が完了する前に行われます（例：ユーザーがタッチスクリーンから第1のスクロール要求に対応する指を離す前に、第2のスクロール要求が開始されて完了する）。

さらに、少なくとも1つの追加のアレンジメントにおいては、第1のスクロール要求と第2のスクロール要求はそれぞれ第1の接触点と第2の接触点に対応するタッチベースのユーザー入力と関連付けられます（例：ユーザーは1本の指を使用して第1のスクロール要求を開始して完了させ、もう1本の指を使用して第2のスクロール要求を開始して完了させる）。

例えば、コンテンツ領域を下にスクロール（画面の下部やコンテンツ領域の下部に向かってスクロールして、指標やアクショントリガーが表示されるか、表示されるようになる）し、その後左にスクロールすると、第2のコマンドとして第1のアクションが実行されます（例：コンテンツ領域の内容の一部を保存する、コンテンツ領域の内容の一部を他の人に電子メールで送信するためのプロンプトを表示するなど）。

この例では、コンテンツ領域を下にスクロールすることを第1のスクロール要求と考え、左にスクロールすることを第2のスクロール要求と考えることができます。別の例では、コンテンツ領域を下にスクロール（指標やアクショントリガーが表示されるか、表示されるようになる）し、その後右にスクロールすると、第2のコマンドとして第2のアクションが実行されます（例：テキストから音声への変換器を呼び出してコンテンツ領域の内容の一部を音声で読み上げる、コンテンツ領域の内容の一部を印刷するなど）。この2つ目の例では、コンテンツ領域を下にスクロールすることを第1のスクロール要求とし、右にスクロールすることを第2のスクロール要求と考えることができます。

さらに、第2のコマンドは指標やアクショントリガーやスクロール可能なリフレッシュトリガーが表示されている時間（第1のコマンドが完了する前）に依存し、または変更されてもよいでしょう。

例えば、ある場合には、第1のコマンドにはアクショントリガーが表示されてから4秒未満で完了するスクロールコマンドが含まれます。この場合、第1のコマンドが完了すると、第2のコマンドとしてコンテンツ領域のリフレッシュが実行されます。しかし、別の場合には、第1のコマンドにはアクショントリガーが表示されてから4秒以上かかって完了するスクロールコマンドが含まれます。この場合、第1のコマンドが完了すると、異なる第2のコマンドが実行され、この異なる第2のコマンドには画面の向きをロックするという操作が含まれるとしてもよいでしょう。

図4は、ここで説明された1つまたは複数の側面に従ってコマンドが実行される別の例の方法を示しています。図4のような方法は、ここで説明する方法と同様に、計算デバイス100のようなコンピューティングデバイスによって実装され、実行されます。

ステップ405では、コンテンツ領域が表示されます。

例えば、ステップ305（図3で説明したもの）と同様に、計算デバイス100はコンテンツ領域を含むユーザーインターフェースを表示します（例：図6のユーザーインターフェース600、後述）。コンテンツ領域には、テキスト、画像、音声、ビデオ、リンク、その他のデジタルコンテンツなど、あらゆる種類のコンテンツが含まれます。少なくとも1つのアレンジメントでは、コンテンツ領域にはコンテンツアイテムのリストが含まれます。

例えば、コンテンツ領域には、個人のステータス更新、ブログ記事、マイクロブログの投稿（例：TWITTERと関連するツイートや他のステータス更新、GOOGLE BUZZと関連するステータス更新、FACEBOOKと関連するステータス更新など）、ニュースの見出し、ニュース記事、テキスト、画像、音声、ビデオ、リンクなどが、年代順に並べられたリストが含まれます。

ステップ410では、第1のコマンドに関連する入力を受け取ります。

例えば、ステップ310（図3で説明したもの）と同様に、コンテンツ領域を表示した後（ステップ405で）に、計算デバイス100はコンテンツ領域をスクロールする要求に関連するユーザー入力を受け取ります。

また、コンテンツ領域をスクロールする要求に関連するユーザー入力は、表示されたスクロールバーとの対話、コンテンツ領域に含まれるコンテンツアイテムをクリックしてドラッグする、マウスに含まれるスクロールホイールを物理的に操作する、または計算デバイス100のハードウェアやソフトウェアコンポーネントとの対話など、さまざまな入力アクションに関連して受け取ることができます。

例えば、ユーザーはマウスを使用してコンテンツ領域に含まれるコンテンツアイテムをクリックしてドラッグし（例：コンテンツ領域内のコンテンツアイテムを選択してから、マウスボタンを押し下げたままマウスを移動させる）、スクロールコマンドを開始することができ、スクロールコマンドをドラッグを終了することで完了することができます（例：マウスボタンを離すことで）。

少なくとも1つのアレンジメントにおいて、受け取った入力はタッチベースのユーザー入力を表す場合があります。例えば、受け取った入力は、スクロールコマンドに関連するタッチベースのユーザー入力であり、タッチセンシティブディスプレイ108を介して計算デバイス100が受け取るもので、ユーザーがコンテンツ領域内の特定の位置に指を置き、指をタッチスクリーン上で滑らせる（これにより計算デバイス100にコンテンツ領域をスクロールするように要求）し、その後指を離す（これによりスクロールコマンドが完了）することを示すものです。

さらに、計算デバイス100は、タッチセンシティブパッド、タッチセンシティブスタイラス、タッチセンシティブマウス（例：市販のAPPLE Magic Mouse）やその他のタッチセンシティブな表面を介してタッチベースのユーザー入力を受け取ることもできます。

また、どのタッチセンシティブな表面を使用してスクロールコマンドを要求または完了するかに関する方法は、ユーザーの指を使用した上記の例と同様になる場合があります（例：ユーザーはコンテンツアイテムを選択してドラッグしてスクロールコマンドを開始し、コンテンツアイテムをドラッグしてスクロールコマンドを完了する）。

ステップ415では、第1のコマンドに対応する指標が表示され、第2のコマンドが第1のコマンドと独立している場合に表示されるようにします。

例えば、第1のコマンドにはコンテンツ領域をスクロールさせるスクロールコマンドが含まれ、コンテンツ領域がスクロールされると、指標が表示されるようになります。指標はスクロール可能で（指標はコンテンツ領域に含まれる1つ以上のコンテンツアイテムとともにスクロールすることができます）、表示または非表示のコンテンツアイテムの近くにあります。

少なくとも1つのアレンジメントでは、指標はコンテンツ領域に含まれる最新のコンテンツアイテムの隣にあります。少なくとも1つの追加のアレンジメントでは、指標はコンテンツ領域に含まれる1つまたは複数のコンテンツアイテムに関するユーザーのキーワード検索に基づいて決定される可能性がある、最も関連性のあるコンテンツアイテムの隣にあります。

1つまたは複数のアレンジメントにおいて、指標には追加のコンポーネントが含まれます。

例えば、指標にはアニメーション化されたグラフィック（例：矢印の回転、スプリングの展開、ロックの解除など）、1つ以上の指示（例：指標の表示に関連する指示、第2のコマンドの実行に関連する指示など）、1つ以上のステータスの説明（例：コンテンツの新鮮さを示すステータスの説明、コンテンツ領域および/またはコンテンツ領域に含まれるコンテンツアイテムが最後にリフレッシュされたときを示すステータスの説明、コンテンツ領域がリフレッシュされていることを示すステータスの説明、1つまたは複数のコンテンツアイテムがロードされていることを示すステータスの説明、1つまたは複数のコンテンツアイテムが以前にロードされたときを示すステータスの説明、検索操作で使用されるテキストやキーワードを示すステータスの説明、検索操作が実行されたときを示すステータスの説明など）、1つ以上のプレビューやサムネイル（例：複数のコンテンツページをナビゲートする場合、指標には前のページと/または次のページのサムネイル画像が含まれます）が含まれます。

さらに、第2のコマンドは第1のコマンドと独立している場合があります。

例えば、第1のコマンドがスクロールコマンドを含む場合、第2のコマンドはスクロールコマンドとは独立した他のコマンドを含む場合があります。したがって、第2のコマンドは、

例えば、コンテンツ領域をリフレッシュする、コンテンツ領域に含まれるコンテンツアイテムやリスト（例：コンテンツアイテムのリスト）をリフレッシュする、コンテンツ領域の内容の一部を保存する、コンテンツ領域の一部を印刷する、コンテンツ領域の音声および/または視覚コンテンツの一部を再生する、テキスト読み上げコンバータを呼び出してコンテンツ領域の内容の一部を読み上げる、コンテンツ領域の内容に関してさらなるアクションを実行するためのダイアログボックスやプロンプトを表示する、コンテンツ領域の内容の一部を他の人に電子メールで送信するためのプロンプトを表示する、別のアクションを実行するなどを含む場合があります。

ステップ420では、第1のコマンドが指標が表示された状態で完了したかどうかが判断されます。

例えば、第1のコマンドにはコンテンツ領域をスクロールする要求に関連するスクロールコマンドが含まれ、計算デバイス100はスクロールコマンドが指標が表示されている間に完了したかどうかを判断します。例えば、ユーザーがマウスを使用してコンテンツ領域に含まれるコンテンツアイテムと/またはハンドルをクリックしてドラッグすることでスクロールコマンドを開始した場合（例：コンテンツアイテムを選択してクリックし、その後マウスボタンを押したままにしてマウスを動かすことにより）、ユーザーがドラッグを終了したとき（例：マウスボタンを離すことにより）スクロールコマンドが完了したと判断されます。この例では、ユーザーがドラッグを終了した時点（例：マウスボタンを離すことにより）に指標が表示されていたかどうかを、計算デバイス100は判断することになります。

別の例では、ユーザーが表示されたコンテンツ領域と/またはそれに含まれる1つ以上のコンテンツアイテムに指を1つ以上置き、表示されたコンテンツ領域（例：タッチセンシティブディスプレイ108）を沿って指を滑らせることでスクロールコマンドを開始し、指を滑らせることを終了し、表示されたコンテンツ領域と/または1つ以上のコンテンツアイテムを離し、指を上げたとき（例：指を持ち上げたとき）スクロールコマンドが完了したと判断されます。もちろん、1本以上の指の代わりに、スタイラスや他のオブジェクトも同様の方法で同じ目的を達成するために使用できます。

ステップ425では、第1のコマンドが指標が表示された状態で完了した場合、第2のコマンドが実行されます。

例えば、ステップ420で第1のコマンドが指標が表示された状態で完了したかどうかが判断された場合、第2のコマンドが実行されます。一方で、ステップ420で第1のコマンドが指標が表示されていない状態で完了したかどうかが判断された場合、第2のコマンドは実行されないかもしれません。少なくとも1つのアレンジメントにおいて、第1のコマンドは、第1のコマンドに関連するユーザー入力が終了した時点で完了したものと見なすことができます。

例えば、第1のコマンドがタッチベースのユーザー入力に関連するスクロール要求を含む場合、第1のコマンドは、ユーザーがタッチスクリーンから指を持ち上げる時点で完了したと見なすことができます。

第1のコマンドは第1のスクロール要求と第2のスクロール要求を含む場合があり、第2のスクロール要求は第1のスクロール要求とは異なる場合があります。そして、第2のコマンドは第1のスクロール要求と第2のスクロール要求に基づいて実行されます。

または、第1のスクロール要求と第2のスクロール要求は連続的かもしれません。言い換えれば、第2のスクロール要求（例：ディスプレイの右側にスクロールする）は、第1のスクロール要求（例：ディスプレイの底側にスクロールする）が開始された後に開始され、第1のスクロール要求が完了する前に（例：ユーザーがタッチスクリーンから第1のスクロール要求に対応する指を持ち上げる前に）完了されます。少なくとも1つの追加のアレンジメントにおいては、第1のスクロール要求と第2のスクロール要求は、それぞれ第1の接触点と第2の接触点に対応するタッチベースのユーザー入力と関連付けられる場合があります（例：ユーザーは第1のスクロール要求を開始して完了させるために1本の指を使用し、第2のスクロール要求を開始して完了させるために別の指を使用する）。

例えば、コンテンツ領域を下にスクロールし（例：指標やアクショントリガーを表示または表示させるために）、次に左にスクロールすることで、第2のコマンドとして第1のアクションが実行されます（例：コンテンツ領域の内容の一部を保存する、コンテンツ領域の内容の一部を他の人に電子メールで送信するためのプロンプトを表示するなど）。この例では、コンテンツ領域を下にスクロールすることが第1のスクロール要求と見なされ、左にスクロールすることが第2のスクロール要求と見なされます。別の例では、コンテンツ領域を下にスクロールし（例：指標やアクショントリガーを表示または表示させるために）、次に右にスクロールすることで、第2のアクションが第2のコマンドとして実行されます（例：テキスト読み上げコンバータを呼び出してコンテンツ領域の内容の一部を読み上げる、コンテンツ領域の内容の一部を印刷するなど）。この2つめの例では、コンテンツ領域を下にスクロールすることが第1のスクロール要求と見なされ、右にスクロールすることが第2のスクロール要求と見なされます。

第2のコマンドは、第1のコマンドが完了した際に指標が完全に表示されていた場合にのみ実行されるとしてもよいでしょう。第2のコマンドを、第1のコマンドが完了した際に指標が完全に表示されていた場合にのみ実行することで、指標をトリガーとして使用し、トリガーがエンゲージされたとき（例：指標が完全に表示されているとき）にのみ第2のコマンドが実行されるようにすることができます。

例えば、計算デバイス100は、第1のコマンドが完了した際にタッチセンシティブディスプレイ108上で指標が完全に表示されていたかどうかを判断します。第1のコマンドが完了した際に指標が完全に表示されていたと判断される場合、第2のコマンドが実行されます。一方、第1のコマンドが完了した際に指標が完全に表示されていなかった場合（例：指標が部分的にしか表示されていないか、まったく表示されていない場合）、第2のコマンドは実行されないかもしれません。

ステップ430では、第2のコマンドが実行されたことが判明した際に、指標を削除することがあります。

例えば、計算デバイス100は第2のコマンドが実行されたことを判断し、その後、ディスプレイから指標を削除します（例：タッチセンシティブディスプレイ108に表示されたコンテンツ領域をスクロールして、コンテンツ領域に含まれるコンテンツアイテムに隣接する指標が表示されなくなるようにする）。

例えば、第2のコマンドにコンテンツ領域をリフレッシュすることや、コンテンツ領域に含まれるリストやコンテンツ項目をリフレッシュすることを含む場合、計算デバイス100は指標をディスプレイから削除する前に、リフレッシュ操作が完了するのを待つかもしれません。この場合、計算デバイス100は、新しいコンテンツ項目（例：新しいメールメッセージ、新しいTWITTERツイート、新しいFACEBOOKのステータス更新、新しいGOOGLE BUZZのステータス更新など）がサーバーからダウンロードされてコンテンツ領域に表示されるまで、指標がディスプレイから削除されるのを待つことになるでしょう。

図5は、コンテンツ項目のスクロール可能なリストをリフレッシュするための手法の例を示しています。

ステップ505では、コンテンツ項目のスクロール可能なリストが表示されます。

例えば、計算デバイス100は、スクロール可能なコンテンツ項目のリスト（例：新しいコンテンツ項目が利用可能であることが判明した場合やリストに追加された場合に、計算デバイス100によって自動的にスクロールされること、ユーザーからのコンテンツ項目のリストをスクロールする要求など）を含むユーザーインターフェース（例：下記で詳しく述べる図6のユーザーインターフェース600）を表示します。スクロール可能なリストに含まれる1つまたは複数のコンテンツ項目は、テキスト、画像、音声、ビデオ、リンク、および/または他のデジタルコンテンツなど、どのようなコンテンツでも含まれます。少なくとも1つのアレンジメントにおいて、スクロール可能なリストには、個人のステータス更新、ブログエントリ、マイクロブログの投稿（例：TWITTERのツイートや他のステータス更新、GOOGLE BUZZのステータス更新、FACEBOOKのステータス更新など）、ニュースの見出し、ニュース記事、テキスト、画像、音声、ビデオ、リンク、および/または他のコンテンツ項目の時系列に沿ったリストが含まれます。

ステップ510では、スクロールコマンドに関連する入力が受信されます。

例えば、スクロール可能なコンテンツ項目のリストが表示された後（例：ステップ505で）、計算デバイス100はスクロールコマンドに関連するユーザー入力（例：コンテンツ項目のリストをスクロールするためのユーザーの要求、ユーザーがユーザーインターフェースの1つまたは複数の側面をスクロールするための要求など）を受信します。図3および図4で説明されたユーザー入力と同様に、スクロールコマンドに関連する入力は、さまざまな入力アクションと関連して受信されます。

例えば、ユーザーが表示されたスクロールバーと対話したり、スクロール可能なコンテンツ項目に含まれるコンテンツ項目をクリックしてドラッグしたり、マウスに含まれるスクロールホイールを物理的に操作したり、または計算デバイス100のハードウェアおよび/またはソフトウェアコンポーネントと対話するユーザーの他の方法と関連してスクロールコマンドに関連する入力が受信されます。

例えば、ユーザーは、スクロール可能なリストに含まれるコンテンツ項目をクリックしてドラッグする（例：コンテンツ項目を選択し、その後マウスボタンを押しながらマウスを動かす）ことによってスクロールコマンドを開始し、ドラッグを終了することによって（例：マウスボタンを離すことによって）スクロールコマンドを完了することができ、この場合、ユーザーはスクロールコマンドを開始し、完了することによってスクロールコマンドを完了することができるでしょう。

受信された入力はタッチベースのユーザー入力を表すかもしれません。

例えば、受信された入力はタッチベースのユーザー入力であり、スクロールコマンドに関連し、ユーザーがタッチセンシティブディスプレイ108を介して計算デバイス100に受信されたもので、ユーザーがスクロール可能なコンテンツ項目のリストに対応するタッチスクリーン上のポイントに指を置き、指をタッチスクリーン上で滑らせて（例：計算デバイス100にスクロール可能なコンテンツ項目のリストをスクロールするように要求するために）計算デバイス100に指示し、指を離す（例：スクロールコマンドを完了するために）ことを示すことができます。

また、計算デバイス100はタッチセンシティブパッド、タッチセンシティブスタイラス、タッチセンシティブマウス（例：市販のAPPLE Magic Mouse）、および/または任意のタッチセンシティブな表面を介してタッチベースのユーザー入力を受信します。

さらに、どのタッチセンシティブな表面を使用してスクロールコマンドをリクエストおよび/または完了するかという点に関しては、ユーザーの指を使用する場合と同様の方法が適用されます（例：スクロール可能なコンテンツ項目に含まれるコンテンツ項目をエンゲージしてドラッグしてスクロールコマンドを開始し、コンテンツ項目を離して（例：ドラッグを終了して）スクロールコマンドを完了する）。

ステップ515では、スクロールコマンドに基づいてスクロール可能なリフレッシュトリガーが表示されます。

例えば、スクロールコマンドはスクロール可能なコンテンツ項目のリストをスクロールさせ、スクロール可能なコンテンツ項目のリストがスクロールされると、スクロール可能なリフレッシュトリガーが表示されたり表示されたりします。リフレッシュトリガーはスクロール可能です。なぜなら、リフレッシュトリガーはスクロール可能なコンテンツ項目のリストに含まれる1つ以上のコンテンツ項目とともにスクロールするかもしれないからです。

スクロール可能なリフレッシュトリガーは、スクロール可能なコンテンツ項目のリストに含まれる最新のコンテンツ項目に隣接しています。少なくとも1つの追加のアレンジメントにおいて、スクロール可能なリフレッシュトリガーは、リフレッシュの重要性が決定される（例：スクロール可能なコンテンツ項目のリストに含まれる1つ以上のコンテンツ項目に関してユーザーからのキーワード検索など）基にして最も関連性のあるコンテンツ項目に隣接しています。

オプションのステップ520では、スクロールコマンドに基づいてスクロール可能なリフレッシュトリガーの表示に関連する最初の指示が提供されます。

例えば、計算デバイス100はタッチセンシティブディスプレイ108に最初の指示を表示し、その最初の指示は、スクロール可能なリフレッシュトリガーがどのように表示されるかと/またはスクロール可能なコンテンツ項目のリストがどのようにリフレッシュされるかを説明します。

例えば、その最初の指示は「下に引っ張ってリフレッシュ」という内容かもしれません。少なくとも1つのアレンジメントにおいて、最初の指示はスクロール可能なリフレッシュトリガーに含まれています。スクロール可能なリフレッシュトリガーに含まれる最初の指示の例は、以下で図8に関連してさらに説明されています。

オプションのステップ525では、スクロール可能なリフレッシュトリガーが完全に表示されていると判断した場合、スクロール可能なリフレッシュトリガーをアクティベートするための第2の指示が提供されます。

例えば、計算デバイス100はタッチセンシティブディスプレイ108に第2の指示を表示し、その第2の指示は、スクロール可能なリフレッシュトリガーをどのようにアクティベートするかと/またはスクロール可能なコンテンツ項目のリストがどのようにリフレッシュされるかを説明します。

例えば、その第2の指示は「離してリフレッシュ」という内容かもしれません。少なくとも1つのアレンジメントにおいて、第2の指示はスクロール可能なリフレッシュトリガーに含まれています。スクロール可能なリフレッシュトリガーに含まれる第2の指示の例は、以下で図9に関連してさらに説明されています。

オプションのステップ530では、スクロール可能なリフレッシュトリガーの表示に応じて最初のオーディオフィードバックが提供されます。

例えば、計算デバイス100はスクロール可能なリフレッシュトリガーを表示した後、スクロール可能なリフレッシュトリガーの表示をユーザーに知らせるために最初のオーディオフィードバックを提供します。このような最初のオーディオフィードバックには、スクロール可能なリフレッシュトリガーやスクロール可能なコンテンツ項目のリストのスクロールと同期するスライディングやシフティングの音が含まれます。

オプションのステップ535では、スクロールコマンドが完了した際にスクロール可能なリフレッシュトリガーが完全に表示されたことを判断し、それに応じてスクロール可能なリフレッシュトリガーがアクティベートされたと判断することがあります。

例えば、計算デバイス100がスクロールコマンドが完了したと判断した際に（マウス入力、タッチ入力、および/またはその他の入力を基に、以下でさらに説明されるように）、スクロール可能なリフレッシュトリガーが完全に表示された状態であった場合、計算デバイス100はスクロール可能なリフレッシュトリガーがアクティベートされたと判断し、それによりスクロール可能なコンテンツ項目のリストがリフレッシュされます。一方、計算デバイス100がスクロールコマンドが完了した際にスクロール可能なリフレッシュトリガーが完全に表示されていないことを判断した場合、計算デバイス100はスクロール可能なリフレッシュトリガーがアクティベートされていないと判断します。

ステップ540では、スクロールコマンドに基づいて、スクロール可能なリフレッシュトリガーがアクティベートされたと判断した場合に、スクロール可能なコンテンツ項目のリストをリフレッシュすることがあります。

例えば、オプションのステップ545が実行され、スクロール可能なリフレッシュトリガーがアクティベートされたと判断される場合、スクロール可能なコンテンツ項目のリストがリフレッシュされます。少なくとも1つのアレンジメントにおいて、スクロール可能なコンテンツ項目のリストのリフレッシュは、サーバー（例：Webサーバー）への接続、新しいコンテンツ項目（新しい電子メール、新しいTWITTERツイート、新しいFACEBOOKのステータス更新、新しいGOOGLE BUZZのステータス更新など）のダウンロード、および新しいコンテンツ項目をスクロール可能なコンテンツ項目のリストに表示することを含むかもしれません。

または、オプションのステップ545が実行されていない場合、スクロール可能なコンテンツ項目のリストは、スクロールコマンドに基づいて、スクロール可能なリフレッシュトリガーがアクティベートされたかどうか（スクロールコマンドがスクロール可能なリフレッシュトリガーが少なくとも部分的に表示されている状態で完了したかどうか）に応じてリフレッシュされます。

例えば、ユーザーがマウスを使用してスクロール可能なコンテンツ項目のリストに含まれるコンテンツ項目やハンドルをクリックしてドラッグしてスクロールコマンドを開始する場合（マウスボタンをクリックして/またはコンテンツ項目を選択し、マウスを動かす際にマウスボタンを押し続けることによって）、ユーザーがドラッグ操作を終了すること（マウスボタンを離すことによって）でスクロールコマンドが完了したと判断することができます。この場合、ユーザーがドラッグ操作を終了したとき（マウスボタンを離すことによって）に、計算デバイス100はスクロールコマンドが完了した際にスクロール可能なリフレッシュトリガーが表示されたかどうか（タッチセンシティブディスプレイ108上で）を判断します。スクロール可能なリフレッシュトリガーがユーザーがドラッグ操作を終了したときに表示されていた場合、計算デバイス100は適切にスクロール可能なコンテンツ項目のリストをリフレッシュします。一方、ユーザーがドラッグ操作を終了したときにスクロール可能なリフレッシュトリガーが表示されていなかった場合、計算デバイス100はスクロール可能なコンテンツ項目のリストをリフレッシュしない可能性があります。

別の例では、ユーザーがスクロール可能なリフレッシュトリガーが表示されているスクロール可能なコンテンツ項目のリスト上に1本または複数の指を置き、表示されたスクロール可能なコンテンツ項目のリストを指でスライドさせてスクロールする場合（タッチセンシティブディスプレイ108上でスクロール可能なコンテンツ項目のリストを指でスライドさせること）、ユーザーがスライド操作を終了し、表示されたスクロール可能なコンテンツ項目のリストやそれに含まれる1本または複数のコンテンツ項目を離す、または1本または複数の指を上げる際に、スクロールコマンドが完了したと判断することができます。もちろん、1本または複数の指の代わりに、スタイラスや他のオブジェクトも同様の方法で同じ目的を達成するために使用できます。

オプションのステップ545では、リフレッシュトリガーがアクティベートされたことを判断した際に、第2のオーディオフィードバックが提供されます。

例えば、計算デバイス100はリフレッシュトリガーがアクティベートされたことを判断した後、リフレッシュトリガーがアクティベートされることをユーザーに知らせるために第2のオーディオフィードバックを提供します。このような第2のオーディオフィードバックには、スクロール可能なリフレッシュトリガーやスクロール可能なコンテンツ項目のリストのスクロールと同期するスライディングやシフティングの音が含まれます。

また、別の例では、リフレッシュトリガーのアクティベートと/またはスクロール可能なコンテンツ項目のリストのリフレッシュと同期するためにポップ音が含まれます。

オプションのステップ550では、リフレッシュ操作が完了したと判断された場合、スクロール可能なリフレッシュトリガーが表示されないように、スクロール可能なコンテンツ項目のリストを自動的にスクロールすることがあります。

例えば、計算デバイス100は、スクロール可能なコンテンツ項目のリストのリフレッシュが完了したと判断し、スクロール可能なリフレッシュトリガーが表示されないようにスクロール可能なコンテンツ項目のリストを自動的にスクロールします。リフレッシュが完了した後に自動的にスクロールすることは、スクロール可能なリフレッシュトリガーの表示を最大限に活用するために望ましい場合があります（例：タッチセンシティブディスプレイ108上で利用可能なスペース）で、スクロール可能なコンテンツ項目のリストに含まれるコンテンツ項目を表示するためです。

図6-11は、ここで説明される1つまたは複数の側面に従ってスクロール可能なコンテンツ項目のリストをリフレッシュするためのサンプルユーザーインターフェースを示しています。

図6に示すように、計算デバイス100などの計算デバイスは、ユーザーインターフェース600を表示します。ユーザーインターフェース600は、ヘッダーバー605、検索バー610、メニューバー615、およびスクロール可能なコンテンツ項目のリスト620を含むかもしれません。スクロール可能なコンテンツ項目のリスト620には、コンテンツ項目620aと620bなどの1つまたは複数のコンテンツ項目が含まれます。

ヘッダーバー605には、ユーザーが特定のコンテンツプロバイダー（例：TWITTER、FACEBOOK、GOOGLE BUZZなど）に関連するアカウントを選択したり、ログインしたり、ログアウトしたりするためのボタンが1つ以上含まれています。ヘッダーバー605には、特定のコンテンツプロバイダー（例：TWITTERプロフィール、FACEBOOKプロフィールなど）に関連するユーザーのプロフィールを編集するボタンや、お気に入りのコンテンツ項目を表示するボタン、ユーザーが作成したコンテンツ項目の下書きを表示および/または編集するボタン、ユーザーが購読するかフォローするユーザーのリストを表示、作成、および/または編集するボタンなどが含まれます。

図7の例では、ユーザーはタッチポイント705に指を置いており、この例ではタッチポイント705はスクロール可能なコンテンツ項目のリスト620に対応するポイントです。その後、ユーザーは指をタッチスクリーン上で滑らせること（タッチポイント705を下にスライドさせること）により、スクロールコマンドを開始し、それによりスクロール可能なコンテンツ項目のリスト620がスクロールされ、スクロール可能なコンテンツ項目のリスト620が下にシフトすることがあります（図6と図7の間で）。

また、スクロール可能なコンテンツ項目のリスト620がスクロールされると、スクロール可能なリフレッシュトリガー710が表示または表示されることがあります。スクロール可能なリフレッシュトリガー710は、スクロール可能なコンテンツ項目のリスト620に含まれる1つ以上のコンテンツ項目と一緒にスクロールされ、スクロール可能なコンテンツ項目のリスト620に含まれる表示されたまたは非表示のコンテンツ項目に隣接する位置に表示されます。したがって、スクロールコマンドに従ってスクロール可能なコンテンツ項目のリスト620がスクロールされると同時に、スクロール可能なリフレッシュトリガー710もスクロールされます。

ユーザーがスクロール可能なコンテンツ項目のリスト620をスクロールし続けると（タッチポイント705をタッチスクリーン上で下にスライドし続けることにより）、計算デバイス100は図8に示すユーザーインターフェース800を表示します。

図8を見ると、スクロール可能なコンテンツ項目のリスト620の継続的なスクロールにより、スクロール可能なリフレッシュトリガー710も継続的にスクロールされ、計算デバイス100によってスクロール可能なリフレッシュトリガー710のより大きな部分が表示されます。

スクロール可能なリフレッシュトリガー710には、指示805やステータス記述810などが含まれます。指示805は、スクロール可能なリフレッシュトリガー710がどのように表示されるか、またはスクロール可能なコンテンツ項目のリスト620をどのようにリフレッシュできるかを説明します。

例えば、指示805は「引っ張って更新」と記述します。ステータス記述810には、1つ以上のステータス記述が含まれ、これについては前述のとおりです。

例えば、ステータス記述810は「最終更新日：10.09.09 2:08 PM」と記述し、スクロール可能なコンテンツ項目のリスト620が最後にリフレッシュされた日時を示すかもしれません。

ユーザーがスクロール可能なコンテンツ項目のリスト620を継続的にスクロールすると（タッチポイント705をタッチスクリーン上で下にスライドし続けることにより）、計算デバイス100は図9に示すユーザーインターフェース900を表示します。

図9を見ると、スクロール可能なコンテンツ項目のリスト620の継続的なスクロールにより、スクロール可能なリフレッシュトリガー710も継続的にスクロールされ、最終的にはスクロール可能なリフレッシュトリガー710が計算デバイス100によって完全に表示されます。図9の点線は、スクロール可能なリフレッシュトリガー710の上部エッジを示しています。

1つまたは複数の側面に従って、スクロール可能なリフレッシュトリガー710が完全に表示されると、指示などのインストラクションが表示されます。指示905は、スクロール可能なリフレッシュトリガー710がどのようにアクティブ化され、またはスクロール可能なコンテンツ項目のリスト620がどのようにリフレッシュされるかを説明します。

例えば、指示905は「更新するには離してください」と記述します。

前述のように、スクロール可能なリフレッシュトリガー710が表示されたまま（または少なくとも一部表示された状態で）スクロールコマンドを完了すると、スクロール可能なコンテンツ項目のリストがリフレッシュされます。

また、前述のように、指示が表示されている間に最初のコマンドを完了すると、第二のコマンドが実行され、第二のコマンドは最初のコマンドとは独立したものとなります。したがって、ユーザーがタッチスクリーン上のタッチポイント705から指を離すか、スクロールコマンドを完了する（ドラッグ操作を終了する、マウスボタンを離すなど）ときに、スクロール可能なリフレッシュトリガー710が表示されている場合、計算デバイス100はスクロール可能なコンテンツ項目のリスト620のリフレッシュを開始し、図10に示すユーザーインターフェース1000を表示します。

図10を見ると、ユーザーがタッチスクリーン上のタッチポイント705から指を離すか、または他の方法でスクロールコマンドを完了した後、ステータス記述1005が表示されることがあります。ステータス記述1005は、「ロード中」などと記述され、計算デバイス100がスクロール可能なコンテンツ項目のリスト620をリフレッシュし、新しいデータを読み込んでいること（例えば、リモートサーバーから最近の未読コンテンツ項目をダウンロードする、TWITTERやFACEBOOKサーバーなど）をユーザーに通知する役割を果たすことがあります。

計算デバイス100が新しいデータを読み込んだ後、計算デバイス100は図11に示すユーザーインターフェース1100を表示します。図11を見ると、ユーザーインターフェース1100にはリフレッシュされたスクロール可能なコンテンツ項目のリスト1105が含まれており、これには新しいおよび/または更新されたコンテンツ項目（例えば、コンテンツ項目1105a、1105b、1105c、1105d、および1105e）が含まれています。

さらに、前述のように、リフレッシュが完了すると、リフレッシュされたスクロール可能なコンテンツ項目1105は自動的にスクロールされたり、スクロール可能なリフレッシュトリガーが表示されなくなるように表示されたりします。ただし、図6と図7のように、ユーザーはリフレッシュされたスクロール可能なコンテンツ項目1105をスクロールしてスクロール可能なリフレッシュトリガーを表示することができます。

ここがポイント！

この発明は、スクロール可能なコンテンツリストのリフレッシュ方法に関するものであり、新たな操作手法を提供しています。従来のスクロール操作に加えて、コンテンツのリフレッシュを効果的かつ効率的に行うことができる画期的な手段です。

従来のスクロール操作では、ユーザーはコンテンツリストをスクロールして新しい情報を表示する際に、リフレッシュの必要性を感じた場合、別途操作を行う必要がありました。一方で、この発明では、スクロール操作そのものが、リフレッシュのトリガーとなります。具体的には、ユーザーがスクロール操作を行うと、スクロールトリガーが表示され、これがユーザーの意図に応じてリフレッシュを開始するシグナルとなります。

この手法により、ユーザーはスムーズな操作によってリフレッシュを行うことができ、新しいコンテンツの更新を素早く確認できます。

例えば、スクロールして新しい情報を読み込む際に、手間をかけずにリフレッシュを行うことができ、ユーザーエクスペリエンスが向上します。

また、この発明は、スクロールトリガーを操作手法に組み込むことで、より多くの情報や指示を提供できる点も魅力です。ユーザーがスクロールトリガーに触れることで、リフレッシュの手順や方法に関する情報を得ることができます。これにより、ユーザーはより使いやすいインターフェースを通じて操作を行うことができます。

未来予想

今回紹介したスクロールリフレッシュの発明は、すでに2023年における我々の世界においては常識となっている技術といえますが、この技術がなかった頃のことを考えてみますと、スマートフォンやタブレットなどのデバイスを通じて、情報をスクロールしながら読み進めることが一般的ではあったものの、新しい情報のアップデートやリフレッシュを行う際には、別途の操作が必要でした。

この発明により、スクロール操作そのものが情報のリフレッシュをトリガーとする手段となりました。つまり、情報をスクロールするだけで、新たなデータがリフレッシュされ、最新情報が更新される仕組みです。これにより、ユーザーはスクロールだけで情報の更新を行え、より迅速かつ効率的に最新情報にアクセスできるようになりました。

今後の未来においては、さらに情報が急速に増加していくことは確実ですが、本発明のような新たな手法の開発がますます重要になっていくでしょう。情報をより効果的に処理し、最新情報に迅速にアクセスするために、画期的なアプローチは今後も求められていきます。さらなる技術革新を期待しましょう。

特許の概要