(58)【調査した分野】(Int.Cl.,DB名)
1つまたは複数のプロセッサを用いて、第1のユーザのアドレスブックを受信するステップであって、前記アドレスブックは第2のユーザに属する電話番号を含む、ステップと、
1つまたは複数のプロセッサを用いて、前記アドレスブック内の前記電話番号を前記第2のユーザのアカウントに関連づけることによってフォン・エッジを生成するステップと、
1つまたは複数のプロセッサを用いて、前記電話番号に関連付けられた前記アカウントを取得するための前記電話番号を含む要求を前記第1のユーザから受信するステップと、
1つまたは複数のプロセッサを用いて、前記第1のユーザに対する前記フォン・エッジに関連付けられたエッジ・コストを決定するステップと、
前記エッジ・コストに基づいて前記フォン・エッジを前記第1のユーザに提供するかどうかを判定するステップと、
ポジティブな判定に応答して前記フォン・エッジを前記第1のユーザに提供するステップと、
を含む、コンピュータ実行型の方法。
前記コンピュータ可読プログラムは、前記コンピュータで実行されたとき、さらに前記コンピュータに、前記第1のユーザに対する前記コストベースのクォータを調節させる、請求項12に記載のコンピュータ使用可能記憶媒体。
前記コンピュータ可読プログラムは、前記コンピュータで実行されたとき、さらに前記コンピュータに、前記第1のユーザに対する前記属性ベースのクォータを調節させる、請求項14に記載のコンピュータ使用可能記憶媒体。
前記命令は、実行されたとき、さらに前記システムに、前記フォン・エッジが前記第1のユーザに提供されているかどうかを前記第1のユーザに通知させる、請求項16に記載のシステム。
【発明を実施するための形態】
【0012】
電話番号検索の割合を限定するためのシステム、方法およびインタフェースが開示される。本開示のシステム、方法およびインタフェースを次にクライアント・サーバ・システムの文脈で説明するが、当該システム、方法およびインタフェースを、絵画的な描画が単一のサーバで実施されるネットワーク上で動作可能に接続されるクライアント・サーバ・システムとは異なるシステムに適用できることは理解されるべきである。例えば、クライアント・デバイス、サード・パーティ・サーバ、電子メール・サーバ、またはアカウント検索アプリケーションが格納されるサーバは本明細書で説明する機能の一部または全部を提供してもよく、サーバのクラスタを使用してかかる機能を提供してもよい。追加の例として、クライアント・ハードウェアは携帯電話またはタブレット・デバイスであってもよい。
【0013】
一般に、電話番号検索の割合を限定するためのシステム、方法およびインタフェースは、コスト、コストベースのクォータおよび属性ベースのクォータを含む基準に基づく。ユーザが連絡先の電話番号を含む要求を送信することで連絡先アカウントの情報を検索するとき、コストが決定される。当該連絡先アカウント情報は、当該電話番号を当該連絡先アカウントにマップするフォン・エッジであることができる。当該コストは、どれだけ多くのユーザが、当該要求された連絡先アカウント情報を取得するために支払うことができるかを示す。名前マッチング・アルゴリズムを使用して当該コストを決定することができる。使用されているアドレスブック内の電話番号に対応する名前が実際の連絡先アカウント名とマッチする場合、最小コストが決定される。当該アドレスブックに当該名前が存在せず、当該実際の連絡先アカウント名にマッチもしないとき、最大コストが決定される。2つの名前の間に部分的なマッチがある場合、最小と最大の間のコストが決定される。当該ユーザは、当該要求された連絡先アカウント情報(例えば、フォン・エッジ)を異なるコストで取得する。
【0014】
コストベースのクォータおよび属性ベースのクォータはまた、当該連絡先アカウント情報を当該ユーザに提供するかどうかを判定するために使用される。当該コストベースのクォータを、名前のマッチに関連付けられたエッジの数、部分的な名前のマッチに関連付けられたエッジの数、名前のマッチおよび対応するコストを有さないエッジの数に基づいて計算することができる。当該ユーザに対するコストベースのクォータを超過した場合、当該ユーザはフォン・エッジを取得することができない。属性ベースのクォータを、当該ユーザに関連付けられたアカウントの属性に基づいて計算してもよい。当該属性は、当該アカウントの作成時刻、当該ユーザの評判スコア等を含む。当該ユーザは、当該属性ベースのクォータ基準が満たされたときに連絡先アカウント情報を取得することができる。
【0015】
検索要求を割合制限するためにコスト、コストベースのクォータおよび属性ベースのクォータを用いることによって、本明細書で説明したシステムおよび方法は、要求を区別し、正当な要求およびユーザができるだけ多くの利益を得、同時に乱用的な要求およびユーザが重く罰せられるように、各要求に対する適切な応答を提供する。
【0016】
図1は、アカウント検索アプリケーション720を用いて電話番号を介してアカウントを取得するための要求を評価し、当該評価に基づいて当該アカウントの情報を含むフォン・エッジをユーザに提供するかどうかを判定するための例示的な方法の流れ
図100を含む。幾つかの実装では、当該アカウントはソーシャル・ネットワーク・アカウントであってもよい。方法100は、第2のユーザに属する電話番号を含む第1のユーザのアドレスブックを受信すること(102)で開始する。幾つかの実装では、当該ユーザはソーシャル・ネットワーク内にいてもよい。1例では、
図8を参照して後にさらに詳細に説明する属性エンジン802が当該アドレスブックを受信してもよい。例えば、属性エンジン822は、電話番号および対応する名前(存在する場合)を、後述するソーシャル・ネットワーク・アプリケーション722により管理される連絡先リストから抽出することでアドレスブックを受信してもよい。あるいは、属性エンジン822は、携帯電話で第1のユーザにより入力された電話番号および名前を受信し、それらをアドレスブックとして格納することができる。
【0017】
方法100は次いで、当該アドレスブック内の電話番号を第2のユーザのアカウントに関連づけることによってフォン・エッジを生成する(104)。
【0018】
1例では、
図8を参照して説明したエッジ生成エンジン824が当該フォン・エッジを生成する。例えば、エッジ生成エンジン824が、第1のユーザのアドレスブック内の電話番号に基づいてユーザ・プロフィールを検索してもよく、第2のユーザのユーザ・プロフィールに列挙された電話番号(例えば、自宅番号、携帯番号)が当該アドレスブック内の電話番号にマッチすると判定する。結果として、エッジ生成エンジン824は第2のユーザを当該電話番号の所有者として識別し、第2のユーザのアカウントを当該電話番号に関連付けてフォン・エッジを生成する。幾つかの事例では、フォン・エッジを生成するとき、エッジ生成エンジン824はまた当該フォン・エッジをマークで注釈付けする。
【0019】
次に、方法100は、当該電話番号に関連付けられた当該アカウントを取得するための当該電話番号を含む要求を第1のユーザから受信し(106)、第1のユーザに対するフォン・エッジに関連付けられたエッジ・コストを決定し(108)、当該エッジ・コストに基づいて当該フォン・エッジを第1のユーザに提供するかどうかを判定し(110)、ポジティブな判定に応答して当該フォン・エッジを第1のユーザに提供してもよい(112)。1例では、
図8を参照して以下でさらに詳細に説明する乱用判定エンジン828がこれらのステップを実装してもよい。
【0020】
エッジ生成エンジン824が電話番号を第1のユーザから受信し当該電話番号をバックエンド・システム内のアカウントにマップするフォン・エッジを生成するとき、当該フォン・エッジは第1のユーザに示されない。しかし、第1のユーザは当該フォン・エッジに含まれる連絡先アカウント情報を知りたいかもしれない。例えば、Aliceは、Janeの電話番号を知っているだけで、Aliceが自分の結婚式の写真をJaneと共有できるようにJaneと連絡を取りたい。乱用判定エンジン828は、当該電話番号に関連付けられた連絡先アカウントを検索する要求を第1のユーザから受信し、当該要求に応答してフォン・エッジを第1のユーザに提供するかどうかを判定する。上の例を続けると、AliceはJaneの電話番号を含む要求を送信してJaneのアカウントを取得する。当該要求に応答して、AliceはJaneのアカウントを受信してJaneと連絡を取ることができる。
【0021】
幾つかの事例では、乱用判定エンジン828は、第1のユーザに対するフォン・エッジに関連付けられたエッジ・コストを決定し(108)、当該エッジ・コストに基づいて当該フォン・エッジを第1のユーザに提供するかどうかを判定する(110)。例えば、乱用判定エンジン828は、AliceがJaneのアカウントをコスト無しに取得できるように、Aliceに対してゼロコストを決定してもよい。しかし、乱用判定エンジン828が1000のコストをAliceに対して決定した場合、Aliceは、Janeのアカウントを取得するために1000を支払う必要がある。この割合制限機構は(例えば、ゼロコストを有する)正当なユーザの利益を保護でき、同時に(例えば、1000コストを有する)乱用的な振舞いのリスクを軽減する。
【0022】
図2Aおよび2Bは、電話番号を介してアカウントを取得するための要求を評価し、当該評価に基づいて当該アカウントの情報を含むフォン・エッジをユーザに提供するかどうかを判定するための特定の例示的な方法の流れ図である。
図2Aでは、方法200は、第2のユーザに属する電話番号を含む第1のユーザのアドレスブックを受信する(202)。方法200は次いで、当該アドレスブック内の電話番号を第2のユーザのアカウントに関連づけることによってフォン・エッジを生成する(204)。方法200は次に、当該電話番号に関連付けられたアカウントを取得するための当該電話番号を含む要求を第1のユーザから受信し、どのように当該要求に応答するかを判定する(206)。
【0023】
当該要求に応答するために、乱用判定エンジン828はまず、当該アドレスブック内の電話番号に対応する名前があるかどうかを決定する(208)。そうである場合、乱用判定エンジン828は、当該アドレスブック内の名前と第2のユーザのアカウント名との間のマッチのレベルを決定し(210)、第1のユーザに対するフォン・エッジに関連付けられたエッジ・コストを計算する(212)。そうでない場合、乱用判定エンジン828は、第1のユーザに対するフォン・エッジに関連付けられたエッジ・コストを直接計算する(212)。例えば、当該アドレスブック内の名前が「John Smith」である場合、これはアカウント名「John Smith」に完全にマッチし、当該乱用判定エンジンは、名前マッチング・エッジ・コストをコスト値10で計算する。当該アドレスブック内の名前が「John」である場合、これは部分的にアカウント名「John Smith」にマッチし、当該乱用判定エンジンは部分名前マッチング・エッジ・コストをコスト値300で計算する。「John Smith」の電話番号に対応する名前がアドレスブックに存在しない場合、当該乱用判定エンジンは非名前マッチング・エッジ・コストをコスト値2000で計算する。
【0024】
次に
図2Bを参照すると、乱用判定エンジン828は、エッジ・コストに基づいて第1のユーザに対するコストベースのクォータを計算する(214)。例えば、第1のユーザに1日最大100個の名前マッチング・エッジ、50個の部分マッチング・エッジおよび20個の非名前マッチング・エッジが許可されており、対応する名前マッチング・エッジ・コスト、部分名前マッチング・エッジ・コストおよび非名前マッチング・エッジ・コストがそれぞれ10、500および1000である場合、乱用判定エンジン828は、46k/日のコストベースのクォータを計算する。即ち、コストベースのクォータ=100×10+50×500+20×1000=46000である。
【0025】
乱用判定エンジン828はまた、第1のユーザまたは第2のユーザのアカウントに関連付けられた少なくとも1つの属性を収集する(216)。例えば、当該少なくとも1つの属性は、第1のユーザに関連付けられた所有者アカウントの作成時刻、第1のユーザの評判スコア等を含む。乱用判定エンジン828は当該少なくとも1つの属性に基づいて第1のユーザに対する属性ベースのクォータを決定する。例えば、Aliceの評判スコアがAndrewの評判スコアより高いので、乱用判定エンジン828はAndrewに割り当てられた属性ベースのクォータよりも高い属性ベースのクォータをAliceに与える。
【0026】
乱用判定エンジン828は、第1のユーザが正当なユーザであるかどうかを判定し(220)、第1のユーザに対するコストベースのクォータおよび属性クォータのうち少なくとも1つを調節する(222)。例えば、第1のユーザのアドレスブック内の名前が実際のソーシャル・ネットワーク・アカウント名にマッチしない場合、乱用判定エンジン828は、第1のユーザが乱用であると判定し、第1のユーザに対するコストクォータを300k/月から10k/月に減らして乱用的な振舞いを罰することができる。乱用判定エンジン828は次いで、エッジ・コスト、コストベースのクォータおよび属性ベースのクォータの少なくとも1つに基づいて、フォン・エッジを第1のユーザに提供するかどうかを判定する(224)。ポジティブな判定に応答して、乱用判定エンジン828は当該フォン・エッジを第1のユーザに提供する(226)。乱用判定エンジン828は第1のユーザに当該判定を通知してもよい(228)。
【0027】
図3は、電話番号を介してアカウントを取得するための要求を評価し、当該評価に基づいて当該アカウントの情報をユーザに提供するかどうかを判定するための例示的な方法の流れ図を含む。方法300は、当該電話番号に関連付けられたアカウントを取得するための第1のユーザからの電話番号を含む直接要求を第1のユーザから受信することで開始する。当該電話番号は第2のユーザに属する。例えば、第1のユーザは、(例えば、後述するソーシャル・ネットワーク・アプリケーション722により管理されるユーザ・プロフィール・ホームページの)検索ボックスに電話番号を入力することにより直接要求を送信して、当該電話番号に対応するアカウントを検索する。幾つかの実装では、方法300は次いで、第1のユーザのアカウントに対する少なくとも1つの属性を収集し(304)、当該少なくとも1つの属性に基づいて第1のユーザに対する属性ベースのクォータを計算する(306)。幾つかの実施形態では、方法300はまた、第2のユーザのアカウントに対する少なくとも1つの属性を収集する(304)。方法300は次に、当該属性ベースのクォータに基づいて、第2のユーザのソーシャル・ネットワーク・アカウントを第1のユーザに提供するかどうかを判定する(308)。ポジティブな判定に応答して、方法300は、当該アカウントの情報を第1のユーザに提供する(310)。方法300はまた、第1のユーザに当該判定を通知する(312)。
【0028】
図4は例示的なアドレスブックのグラフィック表現である。図示した例において、アドレスブック400はユーザの携帯電話に格納される。当該アドレスブックは少なくとも当該ユーザの連絡先の電話番号を含む。当該アドレスブックのエントリ(例えば、402)は電話番号のみを含んでもよい。エントリはまた、電話番号および当該電話番号に対応する名前を含んでもよい。例えば、404は、番号801−123−4561に対応する第1の名前「Amy」を含む。406は番号801−123−4564に対応するニックネーム「Rockstar」を含む。エントリ(例えば、408)はさらに電話番号および当該電話番号に対応するフルネームを含んでもよい。当該ユーザは、当該アドレスブック内の電話番号を使用して、各連絡先に対応するソーシャル・ネットワーク・アカウントを発見して、当該ユーザがこれらの連絡先に接続できるようにしたい。当該ユーザは他の方法で写真を共有し、推奨を提供し、連絡先と対話することができる。当該ユーザが連絡先に接続するのを支援するために、このアドレスブックを、
図8を参照して後述するエンジン822−828に送信して、連絡先アカウントの情報を当該ユーザに提供するかどうかを判定する。
【0029】
図5はユーザに対する例示的な通知のグラフィック表現である。図示した
図5では、ユーザ・プロフィール・ページ500がユーザTom.Lに表示される。ユーザ・プロフィール・ページ500は第1の通知502および第2の通知504を含む。幾つかの事例では、通知エンジン830は、乱用判定エンジン828と通信して、連絡先アカウントの情報をユーザからの要求に応答してユーザに提供するかどうかの判定に基づいて、通知502または504を送信する。第1の通知502は、電話番号801−123−4568に対応するアカウントを取得するためのユーザ要求に応答する。第1の通知502は、要求されたソーシャル・ネットワーク・アカウントがユーザ「Erin Yellow」に関連付けられ、「Erin Yellow」の要求されたソーシャル・ネットワーク・アカウント情報が当該ユーザに提供されていることを、当該ユーザに「Erin Yellow」の写真506と当該ユーザを「Erin Yellow」に接続できるようにするリンク508とを提供することで、当該ユーザに伝える。第2の通知504は、電話番号801−123−4561に対応するアカウントを取得するためのユーザ要求に応答する。第2の通知504は、要求された情報を提供できないことを当該ユーザに通知する。さらに、第2の通知504はまた、なぜ当該ユーザが当該要求された情報を取得できないかに関する説明(例えば、クォータ基準を満たすのに失敗したこと)と、リトライ要求の数を制限するために当該ユーザが2日後に同一の要求をリトライすべきというリマインダとを含む。
【0030】
図6は乱用に対する例示的な通知のグラフィック表現である。図示した
図6において、ユーザ・プロフィール・ページ600がユーザTom.Lに表示される。ユーザ・プロフィール・ページ600は通知602を含む。通知602は、電話番号801−123−4567に対応するアカウントを取得するためのユーザ要求に応答する。通知602は、現在の要求が乱用的な要求として分類され、当該ユーザは乱用として分類されるので、当該要求された情報を当該ユーザに提供できないと当該ユーザに通知する。通知602はさらに、当該分類に関する説明、例えば、当該ユーザが当該電話番号を用いてソーシャル・ネットワーク・アカウントを得ようと何回も試みたがその殆どが失敗したとの説明を与える。例えば、当該ユーザは、実際の電話番号(例えば、非ゼロの数で始まる10桁等)のフォーマットでランダムに生成された電話番号の巨大なリストを有してもよい。当該ユーザはこのリストを使用して、どのソーシャル・ネットワーク・アカウントがこれらの電話番号にマッチしうるかを推定し、その結果、当該ユーザは、(例えば、これらのソーシャル・ネットワーク・アカウントに広告することで)これらのソーシャル・ネットワーク・アカウントに接続することから利益を得ることができる。かかる乱用的な振舞いを通知602により示すように検出することができる。通知602はさらに、当該ユーザに対するクォータが減ったとユーザに通知する。これはまた、将来の乱用的な振舞いに対する予防的措置である。
【0031】
図7は、電話番号を介してアカウントを取得するための要求を評価し、当該評価に基づいて当該アカウントの情報をユーザに提供するかどうかを判定するためのシステム700のブロック図を示す。図示したシステム700は、ユーザ714a、714n、サーバ701、電子メール・サーバ730およびサード・パーティ・サーバ740によりアクセスされるクライアント・デバイス706a、706nを備える。図示した例において、これらのエンティティはネットワーク705を介して通信可能に接続される。
図1および残りの図面において、参照番号の後の文字、例えば、「706a」は、その特定の参照番号を有する要素に対する参照である。後続の文字がないテキスト内の参照番号、例えば、「706」は、その参照番号をもつ要素の異なる実施形態に対する一般的な参照である。2つのデバイスのみが図示されているが、当業者は、任意数のクライアント・デバイス706nが任意数のユーザ714nに利用可能であることを認識する。
【0032】
ネットワーク705は従来のタイプ、有線または無線であってもよく、星形構成、トークンリング構成または他の構成を含む多数の異なる構成を有してもよい。さらに、ネットワーク705は、ローカル・エリア・ネットワーク(LAN)、広域ネットワーク(WAN)(例えば、インターネット)、および/または複数のデバイスが通信できる他の相互接続されたデータ経路を含んでもよい。幾つかの事例では、ネットワーク705はピア・ツー・ピア・ネットワークであってもよい。ネットワーク705はまた、様々な異なる通信プロトコルでデータを送信するための電気通信ネットワークの一部に接続されるかまたはそれを含んでもよい。幾つかの他の事例では、ネットワーク705は、Bluetooth(登録商標)通信ネットワークまたはショート・メッセージ・サービス(SMS)、マルチメディア・メッセージング・サービス(MMS)、ハイパーテキスト転送プロトコル(HTTP)、直接データ接続、WAP、電子メール等を介してデータを送受信するためのセルラ通信ネットワークを含む。
図1はクライアント・デバイス706およびサード・パーティ・サーバ740に接続された1つのネットワーク705を示すが、実際には1つまたは複数のネットワーク705はこれらのエンティティに接続することができる。
【0033】
図1のクライアント・デバイス706a、706nは例として使用されている。2つのクライアント・デバイス706のみが示されているが、本開示は任意数のクライアント・デバイス706を有するシステムアーキテクチャに適用される。図示した実装では、ユーザ714a、714nはそれぞれクライアント・デバイス706a、706nと信号線712a、712nを介して対話する。クライアント・デバイス706a、706nはそれぞれ信号線704a、704nを介してネットワーク705に通信可能に接続され、サーバ701、電子メール・サーバ730およびサード・パーティ・サーバ740と情報を交換する。例えば、クライアント・デバイス706aは、電話番号を介してアカウントを検索するための要求をサーバ701に送信する。当該アカウントはユーザに関連付けられる。サーバ701は、当該要求を処理し、当該要求されたアカウント情報をクライアント・デバイス706aに提供するかどうかを判定する。
【0034】
幾つかの事例では、クライアント・デバイス706は、メモリおよびプロセッサを含む任意のコンピューティング・デバイスであることができる。例えば、クライアント・デバイス706は、ラップトップコンピュータ、デスクトップコンピュータ、タブレットコンピュータ、モバイル電話、携帯情報端末、モバイル電子メールデバイス、ポータブルゲーム・プレイヤ、ポータブル音楽プレイヤ、1つまたは複数のプロセッサを組み込むかまたはそれに接続されるテレビまたはネットワーク705にアクセスできる任意の他の電子デバイス等であることができる。
【0035】
サーバ701は、プロセッサ、メモリおよびネットワーク通信能力を含むハードウェアサーバであることができる。サーバ701は、信号線718を介してネットワーク705に通信可能に接続される。幾つかの事例では、サーバ701は、クライアント・デバイス706、電子メール・サーバ730およびサード・パーティ・サーバ740のうち1つまたは複数に対してネットワーク705を介してデータを送受信する。サーバ701はソーシャル・ネットワーク・アプリケーション722を含む。
【0036】
ソーシャル・ネットワークは、ユーザが共通の特徴により接続されうる一種の社会的構造であることができる。当該共通の特徴は関係/接続、例えば、友達関係、家族、仕事、関心等を含む。当該共通の特徴は、明示的に定義された関係および他のオンラインユーザとのソーシャル接続により示唆された関係を含む1つまたは複数のソーシャルネットワーキングシステムにより提供されうる。当該関係はソーシャル・グラフを形成する。幾つかの例では、当該ソーシャル・グラフは、これらのユーザのマッピングを反映し、どのようにそれらを関連付けうるかを反映できる。サーバ701内のソーシャル・ネットワーク・アプリケーション722は、ユーザの登録、コンテンツの公開(例えば、投稿、コメント、写真、リンク、チェックイン等)を処理し、マルチユーザ通信セッションをホストし、グループを管理し、異なる共有レベルを管理し、ソーシャル・グラフを更新すること等によって、当該ソーシャル・ネットワークを管理する。ソーシャル・ネットワーク・アプリケーション722は、ユーザ名およびパスワードのような情報を受信することでユーザを登録し、当該ユーザに関連付けられ当該ソーシャル・グラフの一部として格納されるユーザ・プロフィールを生成する。幾つかの事例では、当該ユーザ・プロフィールは、関心(例えば、サッカー、読書、食事、購読等)、アクティビティ(例えば、検索履歴、承認の指示、投稿、コメント、マルチユーザ通信セッション等)、人口(例えば、年齢、民族、位置等)およびプロフィール評価および評判(例えば、知識評価、ユーモア評価等)を含む、ユーザに関する追加の情報を含む。システム700は従来のソーシャル・ネットワークサーバ、電子メール・サーバ、マイクロ−ブログサーバ、ブログサーバ、フォーラムサーバ、メッセージサーバ等を含む複数のサーバ701を含んでもよい。
【0037】
さらに、サーバ701およびソーシャル・ネットワーク・アプリケーション722は1つのソーシャル・ネットワークを代表してもよい。ネットワーク705に接続される複数のソーシャル・ネットワークがあってもよく、それぞれは、独自のサーバ、アプリケーションおよびソーシャル・グラフを有する。例えば、第1のソーシャル・ネットワークはビジネスネットワーキングにより関連し、第2のソーシャル・ネットワークはより学術に関連するかまたは集約され、第3のソーシャル・ネットワークはローカルビジネスにより関連してもよい。
【0038】
電子メール・サーバ730は、プロセッサ、メモリおよびネットワーク通信能力を含むハードウェアサーバであることができる。電子メール・サーバ730は、信号線728を介してネットワーク705に通信可能に接続される。幾つかの事例では、電子メール・サーバ730は検索エンジン730を含む。検索エンジン730は、検索要求をクライアント・デバイス706から受信し、当該検索要求に基づいて検索を行い、検索結果をクライアント・デバイス706に送信し戻す。例えば当該検索要求は「電話」、「セル」、または「連絡先」等のようなキーワードを含む。当該検索結果は電話番号を含み、当該電話番号に関連付けられた連絡先名であってもよい。サーバ701は、クライアント・デバイス706と通信して、当該検索結果に基づいてアドレスブックを決定し、当該アドレスブックを処理して、電話番号に対応するアカウントをユーザに提供するかどうかを判定する。
【0039】
サード・パーティ・サーバ740は、プロセッサ、メモリおよびネットワーク通信能力を含むコンピューティング・デバイスであることができる。サード・パーティ・サーバ740は信号線738を介してネットワーク705に接続される。サード・パーティ・サーバ740は、ネットワーク705を介してクライアント・デバイス706、サーバ701およびシステム700の検索サーバとデータを送受信する。例えば、サード・パーティ・サーバ740は、サードパーティアプリケーション(例えば、電話番号生成器)を格納し、当該サードパーティアプリケーションから受信した電話番号をサーバ701にさらなる処理のために送信する。
【0040】
幾つかの事例では、サーバ701はアカウント検索アプリケーション720aを含む。他の事例では、アカウント検索アプリケーション720bをクライアント・デバイス706に格納してもよい。例えば、アカウント検索アプリケーション720bは、クライアント・デバイス706上のアカウント検索アプリケーション720の部分と、当該ユーザにより要求されたアカウントのユーザ情報を提供するかどうかを判定するための、サーバ701上のアカウント検索アプリケーション720の部分とを含む、シン・クライアントアプリケーションである。
【0041】
アカウント検索アプリケーション720は、アカウントを検索するための要求を第1のユーザから受信し、当該アカウントを第1のユーザに提供するかどうかを判定する。当該要求は電話番号を含む。第1のユーザは、どのソーシャル・ネットワーク・アカウントに当該電話番号が属するかを発見し、第1のユーザが当該アカウントに関連付けられる第2のユーザに接続できるようにしたい。幾つかのシナリオでは、当該電話番号は、第1のユーザが当該アカウントについて知っている唯一のものでありうる。第1のユーザは、当該電話番号にマップするソーシャル・ネットワーク・アカウントをできるだけ多く取得し、彼または彼女がこれらのソーシャル・ネットワーク・アカウントと接続することから利益を得ることができるようにしたいだけである。かかる振舞いは潜在的に乱用的な振舞いである。アカウント検索アプリケーション720は、乱用的な振舞いのリスクを軽減し、同時に正当な振舞いを保護するように動作する。
【0042】
幾つかの事例では、第1のユーザから電話番号を受信したことに応答して、アカウント検索アプリケーション720は、当該電話番号を当該対応するソーシャル・ネットワーク・アカウントにマップするためのフォン・エッジを生成する。アカウント検索アプリケーション720は、このフォン・エッジを生成するが、このフォン・エッジを第1のユーザには示さない。アカウント検索アプリケーション720は、このフォン・エッジを読むための要求を第1のユーザから受信し、コスト、コストベースのクォータおよび属性ベースのクォータを計算して、第1のユーザがこのフォン・エッジを読めるかどうかを判定する。幾つかの事例では、アカウント検索アプリケーション720は、名前マッチング・アルゴリズムを使用して、当該コストおよび当該コストベースのクォータを決定する。例えば、Ryanは番号1234567を有し、この番号1234567が属する人全てと接続したい。アカウント検索アプリケーション720は、この番号1234567がJohn Smithに属すると判定し、この1234567をJohn Smithにマップするためのフォン・エッジを生成する。第1のシナリオでは、RyanはJohn Smithの友達である。RyanはJohnの名前をJohnの電話番号とともに自分のアドレスブックに入れる。したがって、RyanがJohnのソーシャル・ネットワーク・アカウントの情報を要求したとき、アカウント検索アプリケーション720は、Ryanのアドレスブック内の名前がJohn Smithのアカウント名にマッチすると判定する。このマッチに基づいて、アカウント検索アプリケーション720はゼロコストを当該フォン・エッジに割り当て、RyanがコストなしにJohnに接続できるようにする。第2のシナリオでは、Johnは1度Ryanのために働いた配管工である。RyanはJohnの第1の名前および電話番号を自分のアドレスブックに持っている。この時点でRyanはJohnの支援がまた必要であるが、電話でJohnに連絡できない。Ryanは自分の電話番号を用いてJohnを発見し、Johnに接続したい。アカウント検索アプリケーション720は、Ryanのアドレスブック内の名前「John」とソーシャルアカウント名「John Smith」の間の部分的なマッチを決定する。この部分的なマッチに基づいて、アカウント検索アプリケーション720は、コスト50を当該フォン・エッジに割り当てて、Ryanが50を支払ってJohnと接続できるようにする。第3のシナリオでは、Ryanは、電話番号生成器によりランダムに生成された番号のリストを取得する。Ryanは誰が番号1234567を所有するかを知らず、したがってRyanのアドレスブック内のこの番号に関連付けられた名前を有さない。Ryanは、広告を送付できるように、この番号が指す人を知りたい。アカウント検索アプリケーション720はRyanの要求を受信し、名前マッチが全く無いと判定する。この場合、アカウント検索アプリケーション720は、Ryanが5000だけを支払ってJohnの情報を得ることができるように、コスト5000をRyanに設定する。アカウント検索アプリケーション720は、当該3つの要求を3つの異なるシナリオにおいて区別し、各要求に応答するための適切なソリューションを提供する。
【0043】
他の事例では、アカウント検索アプリケーション720はまた、属性ベースのクォータを計算して、要求するユーザに連絡先アカウント情報を提供するかどうかを判定する。例えば、アカウント検索アプリケーション720は、ユーザがより多くのフォロワを得ると当該ユーザの評判スコアが上がるので、当該ユーザに対する属性ベースのクォータを増大させる。より高い属性ベースのクォータは、より多くの数の電話番号に関連付けられた連絡先アカウント情報を当該ユーザに取得させうる。
【0044】
幾つかの事例では、アカウント検索アプリケーション720は要求を正当または乱用的と分類する。上の例に関して、アカウント検索アプリケーション720は、第1のシナリオ内の当該要求を正当と判定し、第3のシナリオ内の当該要求を乱用的な要求と判定してもよい。したがって、アカウント検索アプリケーション720は正当な要求にコスト無しで応答し、一方でコストを5000に上げることで乱用的な要求を罰する。
【0045】
アカウント検索アプリケーション720により提供される同一のソリューションを電子メールに適用することもできる。電子メール検索で使用するとき、アカウント検索アプリケーション720は、電子メールの空間はかなり大きいので、「6または7文字の長さまでの全ての電子メールアドレスの所有者を発見すること」を緩和してもよい。
【0046】
次に
図8を参照すると、アカウント検索アプリケーション720の1例をより詳細に説明する。
図8は、幾つかの実装に従う、プロセッサ802、メモリ804、通信ユニット808、記憶810およびアカウント検索アプリケーション720を含む、コンピューティング・デバイス800のブロック図である。コンピューティング・デバイス800のコンポーネントはバス806により通信可能に接続される。幾つかの事例では、コンピューティング・デバイス800はサーバ701である。他の事例では、コンピューティング・デバイス800はクライアント・デバイス706である。
【0047】
プロセッサ802は、計算を実施し電子表示信号をディスプレイデバイスに提供するための、算術論理ユニット、マイクロプロセッサ、汎用目的コントローラまたは幾つかの他のプロセッサアレイの一部または全部を含む。プロセッサ802は、当該他のコンポーネントと通信するためのバス806に接続される。プロセッサ802は、データ信号を処理し、複雑命令セットコンピュータ(CISC)アーキテクチャ、縮小命令セットコンピュータ(RISC)アーキテクチャ、または命令セットの組合せを実装するためのアーキテクチャを含む様々なコンピューティングアーキテクチャを含んでもよい。
図8は単一のプロセッサを含むが、複数のプロセッサが含まれる。当該処理能力は、画像のディスプレイおよび画像のキャプチャと送信をサポートすることに限定してもよい。当該処理能力はより複雑なタスクを実施するのに十分かもしれず、当該タスクは様々なタイプの特徴抽出とサンプリングを含む。他のプロセッサ、オペレーティング・システム、センサ、ディスプレイおよび物理構成が可能であることは当業者には明らかであろう。
【0048】
メモリ804は、プロセッサ802により実行されうる命令および/またはデータを格納する。メモリ804は他のコンポーネントと通信するためのバス806に接続される。当該命令および/またはデータは、本明細書で説明した技術の何れかおよび/または全てを実施するためのコードを含んでもよい。メモリ804は、動的ランダム・アクセスメモリ(DRAM)デバイス、静的ランダム・アクセスメモリ(SRAM)デバイス、フラッシュメモリまたは当業界で公知な幾つかの他のメモリデバイスであってもよい。幾つかの事例では、メモリ804はまた、不揮発性メモリまたは同様な永続記憶および媒体、例えば、ハードディスクドライブ、フロッピーディスクドライブ、CD-ROMデバイス、DVD-ROMデバイス、DVD-RAMデバイス、DVD-RWデバイス、フラッシュメモリデバイス、または幾つかの他の大容量記憶当業界で公知な情報をより永続に記憶するためのを含む。
【0049】
通信ユニット808は、クライアント・デバイス706、サーバ701、電子メール・サーバ730およびサード・パーティ・サーバ740に対してデータを送受信する。通信ユニット808はバス806に接続される。例えば、通信ユニット808は、クライアント・デバイス706からのアドレスを含むデータを受信し、当該データをサーバ701に送信する。サーバ710は、サーバ701に格納されたアカウント検索アプリケーション720を用いて当該データを処理し、結果をクライアント・デバイス706に送信する。
【0050】
幾つかの事例では、通信ユニット808は、クライアント・デバイス706または別の通信チャネルに対する直接物理接続のためのポートを含む。例えば、通信ユニット808はクライアント・デバイス706との有線通信のためのRJ45ポートまたは同様なポートを含む。他の事例では、通信ユニット808は、IEEE802.11、IEEE802.16、Bluetooth「登録商標」または別の適切な無線通信方法のような1つまたは複数の無線通信方法を用いてクライアント・デバイス706または任意の他の通信チャネルとデータを交換するための無線送受信器(図示せず)を備える。
【0051】
幾つかの他の事例では、通信ユニット808は、ショート・メッセージ・サービス(SMS)、マルチメディア・メッセージング・サービス(MMS)、ハイパーテキスト転送プロトコル(HTTP)、直接データ接続、無線アプリケーションプロトコル(WAP)、e−メールまたは別の適切なタイプの電子通信を介してセルラ通信ネットワーク上でデータをを送受信するためのセルラ通信送受信器を含む。さらに別の実施形態では、通信ユニット808は有線ポートおよび無線送受信器を含む。通信ユニット808はまた、当業者に理解されるようにTCP/IP、HTTP、HTTPSおよびSMTPのような標準的なネットワークプロトコルを用いたファイルおよび/または媒体オブジェクトの配分のためのネットワーク705への他の従来の接続を提供する。
【0052】
記憶810は、本明細書で説明する機能を提供するためのデータを格納する非一時的メモリである。記憶810はバス806に接続される。記憶810は動的ランダム・アクセスメモリ(DRAM)デバイス、静的ランダム・アクセスメモリ(SRAM)デバイス、フラッシュメモリまたは幾つかの他のメモリデバイスであってもよい。幾つかの事例では、記憶810はまた、不揮発性メモリまたは同様な永続記憶およびハードディスクドライブ、フロッピーディスクドライブ、CD-ROMデバイス、DVD-ROMデバイス、DVD-RAMデバイス、DVD-RWデバイス、フラッシュメモリデバイス、または情報をより永続に記憶するための幾つかの他の大容量記憶を含む媒体を含む。
【0053】
幾つかの事例では、記憶810は、ユーザに関連付けられたソーシャル・ネットワークプロフィール、当該ユーザにより収集されたアカウント属性(例えば、アカウントの作成時刻、ユーザの評判スコア等)、当該ユーザのアドレスブック、電話番号をソーシャル・ネットワーク・アカウントにマップするフォン・エッジ、通知等を格納する。
【0054】
幾つかの事例では、アカウント検索アプリケーション720はコントローラ820、属性エンジン822、エッジ生成エンジン824、基準エンジン826、乱用判定エンジン828、および通知エンジン830を含む。
【0055】
コントローラ820はデータを適切なコンポーネントに対して送受信するためのルーチンを含むソフトウェアであることができる。幾つかの事例では、コントローラ820は、データを送受信するための後述する機能を提供するためのプロセッサ802により実行可能な1組の命令であることができる。他の事例では、コントローラ820は、コンピューティング・デバイス800のメモリ804に格納でき、プロセッサ802によりアクセス可能かつ実行可能であることができる。幾つかの事例では、コントローラ820を、プロセッサ802およびコンピューティング・デバイス800の他のコンポーネントとの協調と通信のために適合することができる。
【0056】
幾つかの事例では、コントローラ820は通信ユニット808を介してデータを受信し、データをアカウント検索アプリケーション720の適切なエンジンに送信する。例えば、コントローラ820は、通信ユニット808を介してアドレスブックをクライアント・デバイス106から受信し、当該アドレスブックを属性エンジン822にさらなる処理のために送信する。別の例では、コントローラ820は、アカウントの情報をエッジ生成エンジン824から、少なくとも1つの属性を属性エンジン822から受信し、当該アカウントの情報および当該少なくとも1つの属性を乱用判定エンジン826に送信して、当該少なくとも1つの属性に基づいて当該アカウントの情報を要求するユーザに提供するかどうかを判定する。
【0057】
属性エンジン822は、アカウントに関連付けられた属性情報を収集するためのルーチンを含むソフトウェアであることができる。幾つかの事例では、属性エンジン822は、アカウントに関連付けられた属性情報を収集するための後述する機能を提供するためのプロセッサ802により実行可能な1組の命令であることができる。他の事例では、属性エンジン822は、コンピューティング・デバイス800のメモリ804に格納でき、プロセッサ802によりアクセス可能かつ実行可能であることができる。幾つかの事例では、属性エンジン822を、プロセッサ802およびコンピューティング・デバイス800の他のコンポーネントとの協調と通信のために適合することができる。
【0058】
属性エンジン822は、ソーシャル・ネットワーク・アプリケーション722と通信して、アカウントの属性情報を収集する。当該アカウントは第1のユーザに関連付けられた所有者アカウントであることができる。第1のユーザは、電話番号を用いて別のソーシャル・ネットワーク・アカウントを検索することを要求する。第1のユーザにより要求された他のソーシャル・ネットワークは連絡先アカウントである。当該連絡先アカウントは第2のユーザに関連付けられる。属性エンジン822により収集された属性を使用して、第2のユーザに関連付けられた連絡先アカウントを要求するための第1のユーザからの要求が正当であるかどうかを判定し、当該連絡先アカウント情報を第1のユーザに提供するかどうかを判定することができる。当該連絡先アカウント情報は少なくとも第2のユーザのアカウント名および第2のユーザのユーザ・プロフィールを含む。
【0059】
幾つかの事例では、属性エンジン822は、所有者アカウントの名前、当該所有者アカウントの作成時刻、当該所有者アカウントの年齢、アカウント健康属性等を含む、当該所有者アカウントに対する属性を収集する。幾つかの事例では、当該アカウント健康属性は、評判スコア、ユーザ分類(例えば、乱用、スパマ、ヘルパ等)または他のサーバ(例えば、携帯電話、電子メール・サーバ等)にインストールされた乱用検出システムから受信された他の信号を含む。例えば、第1のユーザが良好な評判を有するという指示が、第1のユーザからの検索要求が正当であると判定する際に優先されてもよい。他の事例では、当該アカウント健康属性は、当該所有者アカウントのプロフィール構成が完了しているかどうか、当該所有者アカウントのユーザ・プロフィールが最後に更新されたのはいつか、平均してどれくらい長く当該所有者アカウントのユーザ・プロフィールが更新されているか等に関する活動データを含む。例えば、当該アカウント健康属性が、過去2か月に電話番号を介した連絡先アカウントの要求を除いて、当該所有者アカウントにおいてゼロ回の更新を示すことは、当該要求が正当であることに対する指示である。
【0060】
他の事例では、属性エンジン822は、連絡先アカウントの名前、当該連絡先アカウントの作成時刻、当該連絡先アカウントの年齢を含む当該連絡先アカウントに対する属性、および当該連絡先アカウントに関連付けられた第2のユーザが、第3のソーシャル・ネットワーク・アカウント(即ち、異なる連絡先アカウント)を要求する所有者として動作するかどうか、どれだけ頻繁に第2のユーザが異なる連絡先アカウントに対する要求を開始するか等を含む活動データに基づく属性を収集する。
【0061】
幾つかの他の事例では、属性エンジン822は、どの更新を所有者アカウントが連絡先アカウントに関連する情報に対して行っているかに関する属性を収集する。例えば、属性エンジン822は、第1のユーザが第1のユーザのアドレスブック内のどのエントリをどのように更新するかを判定する。当該エントリは、電話名前および名前のような連絡先の情報を含む。属性エンジン822は、エントリが電話番号に対応する連絡先名「John Smith」なしに最初に生成され、次いで第1の名前「John」が当該電話番号に対応するように追加され、最後に姓「Smith」が当該電話番号に対応するように追加されたことを示す属性を収集してもよい。これらの属性は、要求する第1のユーザに第2のユーザの連絡先アカウント情報を提供するかどうかを判定するのを支援する。例えば、第1のユーザのアドレスブックの複数のエントリにおける名前の頻繁な更新は乱用的な振舞いのヒントでありうる。
【0062】
属性は第1のユーザのアドレスブックを含んでもよい。当該アドレスブックは第1のユーザの連絡先の情報を含む。当該アドレスブック内のエントリは電話番号を含む。エントリはまた、当該電話番号が属する連絡先のフルネーム、部分的な名前を含んでもよく、または当該連絡先の名前を含まなくてもよい。例示的なアドレスブックは
図4を参照して以下で説明される。幾つかの事例では、属性エンジン822は、第1のユーザに対するアドレスブックをソーシャル・ネットワーク・アプリケーション722から受信する。例えば、属性エンジン822は、電話番号および対応する名前(存在すれば)をソーシャル・ネットワーク・アプリケーション722により管理される連絡先リストから抽出することによって、アドレスブックを取得する。他の事例では、属性エンジン822は第1のユーザに対するアドレスブックをクライアント・デバイス106から受信する。例えば、属性エンジン822は、第1のユーザの携帯電話に格納されたアドレスブックを取得する。幾つかの実装では、属性エンジン822は、当該携帯電話で第1のユーザにより入力された電話番号および名前を受信し、それらを当該アドレスブックに格納する。当該ユーザが入力した電話番号は、実際の電話番号の形をとり単に検索目的で使用される、ランダムに生成された番号であることができる。幾つかの他の事例では、属性エンジン802は、電子メール・サーバ730と通信し、または幾つかの実装では、サード・パーティ・サーバ740と通信して、第1のユーザに対するアドレス帳を収集する。例えば、属性エンジン802は、電子メール署名の分析に基づいて第1のユーザに対するアドレスブックを取得する。あるいは、属性エンジン802は、連絡先を他のソーシャル・ネットワークサーバから抽出して結合することによって第1のユーザに対するアドレスブックを収集する。属性エンジン802は、様々なソースからのアドレスブックを第1のユーザに対するアドレスブックに結合する。
【0063】
属性エンジン822は、ユーザの同意のもとでユーザに関連する属性を収集する。幾つかの事例では、属性エンジン822は収集された属性を記憶810に格納する。他の事例では、属性エンジン822は収集された属性をエッジ生成エンジン824、基準エンジン826および乱用判定エンジン828にさらなる処理のために送信する。
【0064】
エッジ生成エンジン824は、電話番号を属性エンジン822から受信したことに応答して、フォン・エッジを生成するためのルーチンを含むソフトウェアであることができる。幾つかの事例では、エッジ生成エンジン824は、電話番号を属性エンジン822から受信したことに応答してフォン・エッジを生成するための後述する機能を提供するためのプロセッサ802により実行可能な1組の命令であることができる。他の事例では、エッジ生成エンジン824は、コンピューティング・デバイス800のメモリ804に格納し、プロセッサ802によりアクセス可能および実行可能であることができる。幾つかの事例では、エッジ生成エンジン824を、プロセッサ802およびコンピューティング・デバイス800の他のコンポーネントとの協調と通信のために適合することができる。
【0065】
幾つかの事例では、エッジ生成エンジン824は第1のユーザのアドレスブックを属性エンジン822から受信する。当該アドレスブックのエントリは少なくとも電話番号を含む。当該アドレスブックのエントリはまた、当該電話番号に対応するフルネーム、ニックネームまたは部分的な名前を含んでもよい。エッジ生成エンジン824は、当該電話番号をアカウントにマップすることでフォン・エッジを生成する。当該フォン・エッジは電話番号およびアカウントの間の接続である。例えば、エッジ生成エンジン824は、第1のユーザのアドレスブック内の電話番号に基づいてユーザ・プロフィールを検索し、第2のユーザのユーザ・プロフィールに列挙された電話番号(例えば、自宅番号、携帯番号)がアドレスブック内の電話番号にマッチすると判定する。結果として、エッジ生成エンジン824は第2のユーザを当該電話番号の所有者として識別し、第2のユーザのアカウントを当該電話番号に関連付けてフォン・エッジを生成する。幾つかの事例では、フォン・エッジを生成するとき、エッジ生成エンジン824はまた当該フォン・エッジをマークで注釈付けする。当該マークは、第1のユーザがこのフォン・エッジを読めるかどうかを判定するための後述する乱用判定エンジン828により修正し使用することができる。
【0066】
幾つかの事例では、エッジ生成エンジン824はフォン・エッジをシステム800のバックエンドで生成し、したがって当該フォン・エッジは第1のユーザに示されない。当該フォン・エッジは、第1のユーザのアドレスブックで与えられる電話番号にマップされる連絡先アカウントの情報を含む。かかる情報は第1のユーザには未知であるかもしれず、第1のユーザにより要求される。例えば、AliceはJaneの電話番号のみを知っているが、Aliceが自分の結婚式の写真をJaneと共有できるように、当該電話番号に基づいてJaneと接続したい。幾つかの事例では、第1のユーザのアドレスブック内の電話番号に対するフォン・エッジを生成することに加えて、エッジ生成エンジン824はまた、当該電話番号に関連付けられた連絡先アカウントを検索するための第1のユーザに対する要求を生成する。当該フォン・エッジは、当該要求に対する応答として第1のユーザに示されても示されなくてもよい。上の例を続けると、エッジ生成エンジン824が、Aliceのアドレスブックに列挙されているJaneの電話番号にJaneのソーシャル・ネットワーク・アカウントで接続するためのフォン・エッジを生成するとき、エッジ生成エンジン824はまた、AliceがJaneのソーシャル・ネットワーク・アカウントを要求するための要求を生成する。当該要求に応答して、Aliceは、Janeのソーシャル・ネットワーク・アカウントを受信して、Janeに接続してもよい。当該要求を受信したことに応答して当該フォン・エッジを第1のユーザに提供するかどうかを判定することを、乱用判定エンジン828を参照して以下で詳細に説明する。
【0067】
幾つかの事例では、エッジ生成エンジン824は、第1のユーザのアドレスブックに含まれる電話番号のリストを受信する。エッジ生成エンジン824は、各電話番号を当該電話番号が指すアカウントに関連付けることによって、当該リスト内の電話番号ごとにフォン・エッジを生成する。幾つかの事例では、エッジ生成エンジン824は、属性エンジン822から当該アドレスブックを定期的に受信し、当該アドレスブックに基づいてフォン・エッジを生成する。幾つかの事例では、エッジ生成エンジン824はフォン・エッジを記憶810に格納する。
【0068】
基準エンジン826は、電話番号を介してアカウントを検索するための要求に応答するための少なくとも1つの基準を設定するためのルーチンを含むソフトウェアであることができる。幾つかの事例では、基準エンジン826は、電話番号を介してアカウントを検索するための要求に応答するための少なくとも1つの基準を設定するための後述する機能を提供するためのプロセッサ802により実行可能な1組の命令であることができる。他の事例では、基準エンジン826は、コンピューティング・デバイス800のメモリ804に格納でき、プロセッサ802によりアクセス可能かつ実行可能であることができる。幾つかの事例では、基準エンジン826を、プロセッサ802およびコンピューティング・デバイス800の他のコンポーネントとの協調と通信のために適合することができる。
【0069】
第2のユーザの電話番号を有し第2のユーザと接続したい第1のユーザに対して、当該電話番号を用いて第2のユーザのアカウント(即ち、連絡先アカウント)を検索するための要求を送信するための2つの方法がある。幾つかの事例では、第1のユーザは、(例えば、ソーシャル・ネットワーク・アプリケーション722により管理されるユーザ・プロフィール・ホームページの)検索ボックスに電話番号を入力することで直接要求を送信して、当該電話番号に対応する連絡先アカウントを検索する。他の事例では、エッジ生成エンジン826は、第1のユーザのアドレスブック内の電話番号に対応する連絡先アカウントを検索するための第1のユーザに対する要求を自動的に生成する。この自動的な要求生成機構は、連絡先アカウントを発見するための時間と労力を減らすので、有利である。直接要求および自動的な要求の両方を以降、検索要求と称してもよい。
【0070】
基準エンジン826は、直接要求または自動的な要求を受信したことに応答して、連絡先アカウントの情報を第1のユーザに提供するかどうかを判定するために使用される少なくとも1つの基準を設定する。当該少なくとも1つの基準はコストベースのクォータおよび属性ベースのクォータを含むことができる。
【0071】
幾つかの事例では、基準エンジン826は、コストをフォン・エッジに対して設定し、当該コストに基づいて、要求するユーザ(例えば、第1のユーザ)に対するクォータをどのように計算するかを定義する。このコストおよびコストベースのクォータは、検索要求がエッジ生成エンジン824により自動的に生成されるシナリオでのみ使用できるので、エッジ関連である。当該フォン・エッジは、第1のユーザのアドレスブック内の電話番号を第2のユーザのアカウントにマップする。幾つかの事例では、基準エンジン826は、当該アドレスブック内の電話番号に対応する名前および第2のユーザのアカウント名の間のマッチのレベルに基づいて、当該フォン・エッジに対するコストを決定する。例えば、当該2つの名前がマッチするとき、基準エンジン820は、名前マッチング・エッジ・コストを10と決定し、当該名前マッチング・エッジ・コストを当該フォン・エッジに割り当てる。当該2つの名前が部分的にマッチするとき、基準エンジン820は、部分名前マッチング・エッジ・コストを500と決定し、当該部分名前マッチング・エッジ・コストを当該フォン・エッジに割り当てる。当該2つの名前がマッチしないとき、基準エンジン820は、非名前マッチング・エッジ・コストを1000と決定し、当該非名前マッチング・エッジ・コストを当該フォン・エッジに割り当てる。一般に、名前マッチが少ないと、コストが高くなる。当該名前マッチングシナリオでは、第1のユーザは第2のユーザの電話番号および名前の両方を知っている。第1のユーザはしたがって第2のユーザの知り合いである可能性が高い。第2のユーザのアカウントに対する第1のユーザからの要求が正当である可能性が高い。第1のユーザは最小のコストを有する第2のユーザのアカウントを取得してもよい。当該非名前マッチングシナリオでは、第1のユーザは第2のユーザの電話番号のみを知っている。これは、第1のユーザがランダムな番号で連絡先を推定しようと試みる乱用的なケースでは必ずしもないが、乱用的なケースが支配的になる可能性が高い。当該要求およびエッジは乱用的な振舞いを信号送信しうる。第1のユーザは、第2のユーザのアカウントを取得しないか、または、最大コストでそれを取得してもよい。基準エンジン826が様々な種類のコストおよび異なるコスト値を決定しうることは当業者に知られている。
【0072】
基準エンジン826は、エッジ生成エンジン824により第1のユーザのアドレスブック内の電話番号のリストに基づいて生成されたフォン・エッジにコストを割り当てる。基準エンジン826は次いで、当該コストに基づいて、要求するユーザ(例えば、第1のユーザ)に対するクォータをどのように計算するかを定義する。幾つかの事例では、基準エンジン826は、対応するエッジの数により重み付けされたコストの和としてクォータを定義する。例えば、第1のユーザに対するコストベースのクォータ=名前マッチング・エッジの数×名前マッチング・コスト+部分名前マッチング・エッジの数×部分名前マッチング・コスト+非名前マッチング・エッジの数×非名前マッチング・コストである。他のアルゴリズムを使用してコストに基づいてクォータを計算できることは当業者には知られている。当該コストベースのクォータは、フォン・エッジを第1のユーザに提供するかどうかを判定するために使用される。当該クォータが高いと、第1のユーザが当該フォン・エッジを取得する確率が高い。乱用判定エンジン828は、後述するように、当該コストベースのクォータに基づいてフォン・エッジを、要求するユーザに提供するかどうかを判定する。
【0073】
基準エンジン826はまた、名前マッチのレベルを判定するための基準を設定する。当該基準は、フルネーム・マッチがあるかどうかを判定するステップ、大文字小文字を無視するかどうか(例えば、daViDがDavidにマッチするかどうか)を判定するステップ、名前の中のプレフィックスおよびサフィックスを無視するかどうか(例えば、Mr.David SmithがDavid Smithにマッチするかどうか)を判定するステップ、区別的発音符、句読点、空白文字等を無視するかどうか(例えば、David、SmithがDavid Smithにマッチするかどうか)を判定するステップ、最初の名前マッチまたは中央の名前マッチまたは最後の名前マッチが動作するかどうか(例えば、DavidがDavid Smithにマッチするかどうか、David SがDavid Smithにマッチするかどうか、SmithがDavid Smithにマッチするかどうか、JoeがDavid Joe Smithにマッチするかどうか)を判定するステップ、異なる名前の順序が重要であるかどうか(例えば、David SmithがSmith Davidにマッチするかどうか)を判定するステップ、共通の短い名前およびニックネームが動作するかどうか(例えば、Bob SmithがRobert Smithにマッチするかどうか、JenがJennifer Smithにマッチするかどうか)を判定するステップ、少々ミススペルした名前が動作するかどうかを判定するステップ(例えば、JeniferがJennifer Smithにマッチするかどうか、RadikaがRadhika Smithにマッチするかどうか)、および或る名前が他の名前の部分文字列かどうか(例えば、RadがRadhikaにマッチするかどうか、hikがRadhikaにマッチするかどうか)を判定するステップ等を含む。
【0074】
幾つかの事例では、基準エンジン826が、名前マッチに対する確信度スコアを決定するための基準を設定し、当該確信度スコアを対応するフォン・エッジと関連付ける。当該確信度スコアはゼロと1の間にあってもよい。例えば、基準エンジン826からの基準に基づいて、フルネーム・マッチは1に等しい確信度スコアを有し、Jeniferおよび(1文字のミスマッチを有する)Jennifer Smithの間の名前マッチは、Radおよび(4つの文字ミスマッチを有する)Radhikaの間の名前マッチより高い確信度スコアを有し、RadおよびRadhikaの間の名前マッチがhikおよび(開始文字のマッチがない)Radhikaの間の名前マッチより高い確信度スコアを有する。基準エンジン826は、コストベースのクォータを計算するときに、当該確信度スコアを考慮に入れるためのルールを設定することができる。例えば、基準エンジン826は、当該フォン・エッジに関連付けられた確信度スコアに基づいてフォン・エッジに対するコストを変更する基準を定義してもよく、当該変化するコストに基づいて当該クォータを計算する。
【0075】
他の事例では、基準エンジン826は、アカウントの属性を属性エンジン822から受信し、当該属性に基づいて属性ベースのクォータを定義する。幾つかの事例では、基準エンジン826は、名前、作成時刻、アカウントの年齢、アカウント健康属性(例えば、評判スコア)等を含む属性に基づいて属性ベースのクォータを定義する。例えば、基準エンジン826は、第1のユーザに対して第1の値を割り当てて、第1のユーザに関連付けられた所有者アカウントの作成時刻が閾値期間内であることを反映し、第1のユーザに対して第2の値を割り当てて、第1のユーザが閾値スコアより上の評判スコアで良い評判を有することを反映する。第1の値は第2の値より小さい。基準エンジン826は、第1の値および第2の値を属性ベースのクォータに結合するためのルールを設定する。例えば、当該属性ベースのクォータは第1のおよび第2の値の和である。他の事例では、基準エンジン826は、どの更新を当該所有者アカウントが当該連絡先アカウントに関連する情報に対して行っているかに関する属性に基づいて当該属性ベースのクォータを定義する。例えば、第1のユーザに関連付けられた当該所有者アカウントが、当該正確な連絡先名を取得しようと試みた結果として、電話番号に対応する連絡先名を繰り返し更新する場合、第1のユーザを乱用と分類してもよい。かかる属性は基準エンジン826に低いクォータを第1のユーザに割り当てさせてもよい。
【0076】
幾つかの他の事例では、基準エンジン826はまた他の基準を設定する。例えば、当該基準エンジンは、フォン・エッジを第1のユーザに提供するための以前の失敗と第1のユーザからの当該フォン・エッジに対する現在の要求との間の閾値時間を割り当てる。現在の要求を、以前の失敗と現在の要求の間の時間差が当該閾値時間を超えるときにのみ処理することができる。別の例では、基準エンジン826は、どれだけ多くの非名前マッチング・エッジがエッジ全体に存在しうるかに関する閾値パーセンテージを割り当てる。当該要求されたエッジが非名前マッチング・エッジであるパーセンテージが当該閾値パーセンテージより下である場合にのみ、要求するユーザはフォン・エッジを取得してもよい。
【0077】
基準エンジン826は、乱用判定エンジン826と通信して、コスト、コストベースのクォータ、属性ベースのクォータおよび他の基準を調節することができる。例えば、基準エンジン826は名前マッチング・エッジ・コストを10からゼロに変更することができる。正当なユーザはしたがってコストなしにフォン・エッジを取得することができる。別の例では、基準エンジン826は、第1のユーザが乱用であると判定すると一旦乱用判定エンジン828が判定すると、当該コストベースのクォータを増大させる。基準エンジン826は基準をリアルタイムに設定し調節する。幾つかの事例では、基準エンジン826は当該基準を記憶810に格納する。
【0078】
乱用判定エンジン828は、第1のユーザからの検索要求に応答して、連絡先アカウントの情報を第1のユーザに提供するかどうかを判定するためのルーチンを含むソフトウェアであることができる。幾つかの事例では、乱用判定エンジン828は、第1のユーザからの検索要求に応答して、連絡先アカウントの情報を第1のユーザに提供するかどうかを判定するための後述する機能を提供するためのプロセッサ802により実行可能な1組の命令であることができる。他の事例では、乱用判定エンジン828は、コンピューティング・デバイス800のメモリ804に格納でき、プロセッサ802によりアクセス可能かつ実行可能であることができる。幾つかの事例では、乱用判定エンジン828を、プロセッサ802およびコンピューティング・デバイス800の他のコンポーネントとの協調と通信のために適合することができる。
【0079】
幾つかの事例では、エッジ生成エンジン824は、第1のユーザのアドレスブック内の電話番号のリストを受信し、当該リスト内の各電話番号を対応する連絡先アカウントに関連付けることによって、これらの電話番号に対するフォン・エッジを生成する。この時点で、当該フォン・エッジは、エッジ生成エンジン824によりバックエンドで生成され、第1のユーザにまだ示されていない。エッジ生成エンジン824は、当該フォン・エッジを読むための第1のユーザに対する要求を生成する。当該要求を受信したことに応答して、乱用判定エンジン828は、基準エンジン826によって定義された少なくとも1つの基準に基づいて、当該フォン・エッジを第1のユーザに提供するかどうかを判定する。このように、乱用判定エンジン828は、第1のユーザの読取り時間の間に第1のユーザに返すことができるフォン・エッジの数を制限する。
【0080】
乱用判定エンジン828は、名前マッチング・アルゴリズムを使用して、フォン・エッジを第1のユーザに提供するかどうかを判定する。当該フォン・エッジは、第1のユーザのアドレスブック内の電話番号を第2のユーザのアカウント(例えば、連絡先アカウント)にマップする。当該名前マッチング・アルゴリズムで使用される基準は、名前のマッチに関する基準(例えば、大文字小文字を無視するかどうか、開始文字のマッチがあるかどうか等)、コスト、コストベースのクォータ等を含む。
【0081】
幾つかの事例では、乱用判定エンジン828は、第1のユーザのアドレスブック内に当該電話番号に対応する名前があるかどうかを判定する。名前が当該アドレスブック内にある場合、乱用判定エンジン828は、当該名前と第2のユーザのアカウント名の間のマッチのレベルを決定し、フォン・エッジに対するエッジ・コストを計算する。例えば、乱用判定エンジン828は、フルネーム・マッチに基づいて、名前マッチング・エッジ・コストを第1のフォン・エッジに対するコスト値ゼロで決定し、部分的な名前マッチに基づいて、部分名前マッチング・エッジ・コストを第2のフォン・エッジに対するコスト値500で決定する。当該アドレスブック内に名前がない場合、乱用判定エンジン828は、フォン・エッジに対する非名前マッチング・エッジ・コストを基準エンジン826により割り当てられたコスト値、例えば、10で決定する。幾つかの事例では、乱用判定エンジン828はまた、名前マッチに対する確信度スコアを決定し、当該確信度スコアに基づいてエッジ・コストを計算する。例えば、乱用判定エンジン828は、開始文字のマッチに関する基準に基づいて、JeniとJenniferの間の部分的な名前マッチに対する0.9の確信度スコアを決定する。乱用判定エンジン828はまた、非開始文字のマッチに関する基準に基づいて、hikとRadhikaの間の部分的な名前マッチに対する0.2の確信度スコアを決定する。「Jeni」と「hik」は第1のユーザのアドレスブック内にある。「Jennifer」と「Radhika」は実際の連絡先アカウント名である。当該確信度スコアに基づいて、乱用判定エンジン828は、Jenniferへのフォン・エッジ・マッピングのための550個の部分名前エッジ・マッチング・コストを決定し、Radhikaへのフォン・エッジ・マッピングに対する800個の部分名前エッジ・マッチング・コストを決定する。
【0082】
名前がマッチする場合、乱用判定エンジン828は、対応するフォン・エッジ、このエッジを取得するための要求およびこのエッジを要求した第1のユーザが正当であると判定してもよい。結果として、第1のユーザは、乱用判定エンジン828により提供されたフォン・エッジを取得するための名前マッチング・エッジ・コストを支払うことができる。当該名前マッチング・コストはゼロまたは小さな数でありうる。名前が部分的にマッチする場合、乱用判定エンジン828は依然として当該フォン・エッジを第1のユーザに提供してもよいが、第1のユーザは、当該フォン・エッジをより高いコスト、例えば、部分マッチング・エッジ・コスト600で取得する。名前がマッチしない場合、それは必ずしも乱用的なケースではないが、乱用的なケースである可能性が高い。乱用判定エンジン828は当該フォン・エッジを第1のユーザに提供するが、第1のユーザは、当該フォン・エッジを最大のコストで、例えば、非マッチング・エッジ・コスト1000で取得することが可能である。
【0083】
幾つかの事例では、乱用判定エンジン828はまた、コストベースのクォータに依存して、フォン・エッジを第1のユーザに提供するかどうかを判定する。乱用判定エンジン828は、或る時間長内の第1のユーザに対するコストベースのクォータを計算する。乱用判定エンジン828は次いで、どれだけ多くのフォン・エッジおよびどの種類のフォン・エッジが第1のユーザにより当該時間長内に要求されたかに基づいて、当該時間長内のクォータ利用を計算する。乱用判定エンジン828は、基準エンジン826で定義された同一の基準に基づいて、コストクォータおよびクォータ利用を計算する。フォン・エッジに対する要求を第1のユーザから受信したことに応答して、乱用判定エンジン828は、当該クォータ利用が当該コストベースのクォータを超えたかどうかに基づいて、当該フォン・エッジを第1のユーザに提供するかどうかを判定する。例えば、基準エンジン826は、高々100個の名前マッチング・エッジ、50個の部分マッチング・エッジおよび20個の非名前マッチング・エッジを1日あたり第1のユーザに許可できると定義する。乱用判定エンジン828は、名前マッチング・エッジ・コスト、部分名前マッチング・エッジ・コスト10および非名前マッチング・エッジ・コストがそれぞれ10、500および1000であることが与えられると、46k/dayコストベースのクォータを計算する。即ち、コストベースのクォータ=100×10+50×500+20×1000=46000である。乱用判定エンジン828はまた、第1のユーザに対するクォータ利用を、1日に第1のユーザにより要求された90個の名前マッチング・エッジ、80個の部分マッチング・エッジおよび5個の非名前マッチング・エッジに基づいて、例えば、90×10+80×500+5×1000=45900と計算する。第1のユーザは90+80+5=175個のフォン・エッジを要求している。第1のユーザがその日において176番目の部分マッチング・エッジを要求したとき、乱用判定エンジン828は、当該176番目のフォン・エッジを第1のユーザに提供しない。なぜならば、当該176番目のフォン・エッジを含むクォータ利用は90×10+81×500+5×1000=46400であり、46kを超えるからである。
【0084】
幾つかの事例では、乱用判定エンジン828は、コストベースのクォータに基づいて、フォン・エッジで注釈付けされたマークを変更するかどうかを判定し、当該マークが変更されているかどうかに基づいて、当該フォン・エッジを第1のユーザに提供するかどうかを判定する。例えば、エッジ生成エンジン824は、当該フォン・エッジを生成するときに、全てのフォン・エッジを「偽」マークで注釈付けする。乱用判定エンジン828は、どれだけ多くのエッジを「真」としてマークできるかに関してクォータを決定し、「真」マーカを有するフォン・エッジのみを第1のユーザに返す。1例では、基準エンジン826は、全ての名前マッチング・エッジをゼロコストで「真」とマークできると定義する。基準エンジン826はまた、最大100個の非マッチング・エッジをコスト1で「真」とマークできると定義する。第1のユーザからの検索要求の際、乱用判定エンジン828は、全ての名前マッチング・エッジおよび幾つかの成功する非名前マッチング・エッジを返すことができる。この番号は100未満である。したがって、第1のユーザは30を支払って1000個の名前マッチング・エッジおよび30個の非名前マッチング・エッジを得ることができるが、第1のユーザは1つの名前マッチング・エッジおよび101個の非名前マッチング・エッジを得ることができない。
【0085】
コストベースのクォータに加えて、乱用判定エンジン828はまた、基準エンジン826により定義された少なくとも1つの基準に基づいて属性ベースのクォータを決定する。当該少なくとも1つの基準は、第1のユーザに関連付けられた所有者アカウントの作成時刻、第1のユーザの評判スコア、どの更新を当該所有者アカウントが当該連絡先アカウントに関連する情報に対して行っているか等を含む属性に関連する。例えば、乱用判定エンジン828は、Aliceの評判スコアがAndrewの評判スコアより高いので、Aliceに、Andrewに割り当てられた属性ベースのクォータより高い属性ベースのクォータを与える。乱用判定エンジン828は、当該属性ベースのクォータに基づいて、フォン・エッジを第1のユーザに提供するかどうかを判定する。例えば、(例えば、システム700に統合された他の乱用検出システムにより検出された幾つかの乱用的な振舞いに起因した)第1のユーザの評判の悪化が、属性ベースのクォータが超過することをもたらすかもしれない。結果として、乱用判定エンジン828は、第1のユーザからの検索要求に応答してフォン・エッジを第1のユーザに提供しない。
【0086】
幾つかの事例では、乱用判定エンジン828は、第1のユーザからのフォン・エッジに対する現在の要求の前に、当該フォン・エッジを第1のユーザに提供するのに失敗したかどうかを判定する。当該失敗は、アドレスブック内の名前および実際のソーシャル・ネットワーク・アカウント名をマッチできなかったことまたはクォータ基準を満たせなかったことに起因してもよい。失敗があった場合、乱用判定エンジン828は、当該失敗が発生した時刻と現在の要求が受信された時刻の時間差を計算し、当該時間差が閾値時間、例えば、1週間を超過したかどうかを判定する。乱用判定エンジン828は、当該時間差が当該閾値時間を超えるときにのみ現在の要求に応答する。したがって、第1のユーザから今日100個の検索要求を受信したことに応答して、乱用判定エンジン828が連絡先アカウント情報を第1のユーザに提供するのに失敗した場合、乱用判定エンジン828は、次の数日間における同一の100個の検索要求を処理する必要はない。乱用判定エンジン828はしたがって、リトライ回数を制限することによって効率を得る。他の事例では、乱用判定エンジン828はまた、或る期間に第1のユーザから受信された検索要求の数を制限する。
【0087】
幾つかの事例では、エッジ生成エンジン824により生成された自動的な要求に応答して、乱用判定エンジン828はコストベースのクォータおよび属性ベースのクォータに基づいて全体クォータを決定し、当該コストベースのクォータ、当該属性ベースのクォータおよび当該全体クォータのうち少なくとも1つに基づいて、フォン・エッジを第1のユーザに提供するかどうかを判定する。他の事例では、(例えば、電話名前を検索ボックスに入力することによって)第1のユーザからの直接要求に応答して、乱用判定エンジン828は、当該属性ベースのクォータを使用して、連絡先アカウントの情報を第1のユーザに提供するかどうかを判定する。このシナリオでは、乱用判定エンジン828は、エッジ生成エンジン824と通信することなく当該直接要求を処理する。フォン・エッジが生成されないので、乱用判定エンジン828は、連絡先アカウント情報を第1のユーザに返すかどうかを判定するためにエッジ関連のコストおよびコストベースのクォータを使用しなくてもよい。
【0088】
乱用判定エンジン828は、上述のコスト、コストベースのクォータおよび属性ベースのクォータに基づいて、第1のユーザに対する電話番号を用いて連絡先アカウントを検索するための要求が正当であるかどうかを判定する。例えば、乱用判定エンジン828は、名前マッチング・エッジに対する第1の要求が正当であると判定し、第2の要求の前かつ或る期間内に第1のユーザにより要求された非名前マッチング・エッジのパーセンテージが閾値パーセンテージを超えるので、第2の要求が乱用的な要求であると判定する。幾つかの事例では、乱用判定エンジン828はまた、連絡先アカウントを要求する第1のユーザが正当なユーザまたは乱用であるかどうかを判定する。例えば、乱用判定エンジン828は、或る時間期間内の第1のユーザからの乱用的な要求が閾値を超えた場合に、第1のユーザが乱用であると判定する。
【0089】
乱用判定エンジン828は、要求が正当な要求かどうかまたはユーザが正当なユーザかどうかに基づいて、コスト、コストベースのクォータおよび属性ベースのクォータを調節することができる。正当な要求またはユーザに対して、乱用判定エンジン828は、当該コストを減らすか、または、当該ユーザを利するために当該コストまたはクォータを増やすことができる。乱用的な要求またはユーザに対して、乱用判定エンジン828は、当該ユーザを罰するために当該コストまたはクォータを低下させることができる。例えば、乱用判定エンジン828が、第1のユーザが正当なユーザであり、第1のユーザのアドレスブック内の名前がすべて実際のソーシャル・ネットワークの名前にマッチすると判定した場合、乱用判定エンジン828は、第1のユーザに対するコストクォータを300k/月から600k/月にアップグレードすることができる。しかし、第1のユーザのアドレスブック内の名前の何れも実際のソーシャル・ネットワーク・アカウント名にマッチしない場合、乱用判定エンジン828は、第1のユーザに対するコストクォータを300k/月から10k/月に減らし、第1のユーザに対する非マッチエッジ・コストを1000から5000に増大させることができる。当該要求を区別することによって、乱用判定エンジン828は、正当なユーザが出来るだけ多くの利益を得ることを保証し、同時に乱用が重く罰せられることを保証する。
【0090】
通知エンジン830は、連絡先アカウントの情報が第1のユーザに提供されるかどうかを第1のユーザに通知するためのルーチンを含むソフトウェアであることができる。幾つかの事例では、通知エンジン830は、当該連絡先アカウントの情報が第1のユーザに提供されるかどうかを第1のユーザに通知するための後述する機能を提供するためのプロセッサ802により実行可能な1組の命令であることができる。他の事例では、通知エンジン830は、コンピューティング・デバイス800のメモリ804に格納でき、プロセッサ802によりアクセス可能かつ実行可能であることができる。幾つかの事例では、通知エンジン830を、プロセッサ802およびコンピューティング・デバイス800の他のコンポーネントとの協調と通信のために適合することができる。
【0091】
通知エンジン830は、第2のユーザに関連付けられた連絡先アカウント情報を第1のユーザに乱用判定エンジン828から提供するかどうかの判定を受信し、第1のユーザに当該判定を通知する。ポジティブな判定に対して、当該通知は、第2のユーザのアカウント名と、第2のユーザに関連付けられたユーザ・プロフィールへのリンク、第2のユーザの写真、第2のユーザに接続する第1のユーザに対するリンク等を含む他の情報とを含む。ネガティブな判定に対して、当該通知は、乱用判定エンジン828がなぜ第2のユーザの連絡先アカウント情報に対する第1のユーザの要求を拒否したのかに関する説明を含む。例えば、通知エンジン830は、第1のユーザがクォータ基準を満たせないので第1のユーザが要求された連絡先アカウント情報を取得できないことを示す通知を送信する。当該通知はまた、他の情報、例えば、第1のユーザがいつ同一の連絡先アカウント情報を検索するのを再度試みることができるかのリマインダを含んでもよい。
【0092】
幾つかの事例では、当該通知は様々な形式をとることができる。当該通知は、携帯電話上のポップアップウィンドウ、第1のユーザに表示されたウェブ・ページ上に提供されたオーバレイ、電子メッセージ等であることができる。幾つかの事例では、通知エンジン830は当該通知を記憶810に格納する。
【0093】
以下の説明では、説明の目的のため、本明細書の徹底的な理解を提供するために多数の具体的な詳細を説明した。しかし、当該技術をこれらの具体的な詳細なしに実践できることは当業者には明らかである。他の事例では、構造およびデバイスは、説明を不明瞭にするのを避けるためにブロック図の形で示してある。例えば、本明細書は、ユーザインタフェースおよび特定のハードウェアを参照して幾つかの事例で説明されている。しかし、当該説明は、データおよびコマンドを受信できる任意の種類のコンピューティング・デバイス、およびサービスを提供する任意の周辺デバイスに適用される。
【0094】
本明細書における「幾つかのインスタンス」または「1実施形態」という参照は、当該実施形態に関連して説明した特定の特徴、構造、または特性が本説明の少なくとも幾つかのインスタンスに含まれることを意味する。本明細書内の様々な場所における「幾つかのインスタンスにおいて」というフレーズの出現は必ずしも全て同一の実施形態を指すものではない。
【0095】
詳細な説明の幾つかの部分はコンピュータメモリ内のデータビットに対する動作のアルゴリズムおよび記号的表現の観点から説明されている。これらのアルゴリズム的説明および表現は、当該データ処理分野の当業者が使用する手段を、かれらの成果物を他の当業者に最も効果的に伝達するものである。アルゴリズムは一般に、所望の結果をもたらすと考えられる首尾一貫したステップのシーケンスと考えられる。当該ステップは物理量の物理操作を必要とするものである。通常、必ずしもそうではないが、これらの量は、格納し、転送し、結合し、比較し、または操作できる電気または磁気信号の形態をとる。これらの信号をビット、値、要素、シンボル、文字、項、番号等として参照することが、主に共通的な使用のために、しばしば都合が良いことが分かっている。
【0096】
しかし、これらのおよび同様な用語のすべてが当該適切な物理量に関連付けられ、都合が良いこれらの量に適用されるラベルであることに留意すべきである。特に断らない限り以下の議論から明らかなように、本明細書の説明にわたって、「処理」または「コンピューティング」または「計算」または「判定」または「表示」等のような用語を用いた議論は、当該コンピュータシステムのレジスタおよびメモリ内の物理(電子)量として表されたデータを操作し、当該コンピュータシステムメモリまたはレジスタまたは他のかかる情報記憶、送信またはディスプレイデバイス内の物理量として同様に表された他のデータに変換するコンピュータシステム、または同様な電子コンピューティング・デバイスのアクションおよびプロセスを指すことは理解される。
【0097】
本明細書が、本明細書の動作を実施するための装置に関してもよい。当該装置は、特に当該必要な目的のために構築されてもよく、または当該コンピュータに格納されたコンピュータプログラムにより選択的に起動または再構成される汎用目的コンピュータを含んでもよい。かかるコンピュータプログラムはコンピュータ可読記憶媒体に格納されてもよく、これにはそれぞれコンピュータシステムバスに接続されたフロッピーディスク、光ディスク、CD-ROM、および磁気ディスク、読取専用メモリ(ROM)、ランダム・アクセスメモリ(RAM)、EPROM、EEPROM、磁気または光カード、不揮発性メモリまたは電子命令を格納するのに適した任意の種類の媒体を有するUSBキーを含むフラッシュメモリを含む任意の種類のディスクがあるがこれらに限られない。
【0098】
本明細書は、もっぱらハードウェア実施形態、もっぱらソフトウェア実施形態またはハードウェアおよびソフトウェア要素の両方を含む実施形態の形態をとることができる。幾つかの事例では、本明細書がソフトウェアで実装され、当該ソフトウェアは、ファームウェア、常駐ソフトウェア、マイクロコード等を含むがこれらに限られない。
【0099】
さらに、当該説明は、コンピュータまたは任意の命令実行システムによりまたはそれと関連して使用するためのプログラムコードを提供するコンピュータ−使用可能またはコンピュータ−可読媒体からアクセス可能なコンピュータプログラム製品の形態をとることができる。この説明のため、コンピュータ−使用可能またはコンピュータ可読媒体は、当該命令実行システム、装置、またはデバイスによりまたはそれらと接続して使用するためのプログラムを含み、格納し、通信し、伝播し、または転送できる任意の装置であることができる。
【0100】
Aプログラムコードを格納および/または実行するのに適したデータ処理システムは、システムバスを通じて直接または間接にメモリ要素に接続された少なくとも1つのプロセッサを含む。当該メモリ要素は、当該プログラムコードの実際の実行中に使用されるローカルメモリ、バルク記憶、およびコードを実行中にバルク記憶から抽出しなければならない回数を削減するために少なくとも幾つかのプログラムコードの一時記憶を提供するキャッシュメモリを含むことができる。
【0101】
入出力またはI/Oデバイス(キーボード、ディスプレイ、ポインティングデバイス等を含むがこれらに限られない)を、直接にまたは介在するI/Oコントローラを介して、当該システムに接続することができる。
【0102】
ネットワークアダプタを当該システムに接続して、当該データ処理システムが、介在するプライベートまたはパブリックネットワークを通じて他のデータ処理システムまたはリモートプリンタまたはソーシャル・ネットワークデータ・ストアに接続されるようにできる。モデム、ケーブルモデムおよびイーサネット(登録商標)カードは現在利用可能なタイプのネットワークアダプタのごく幾つかにすぎない。
【0103】
最後に、本明細書で提供したアルゴリズムおよびディスプレイは任意の特定のコンピュータまたは他の装置に本来的には関連しない。様々な汎用目的システムを本明細書の教示事項に従うプログラムで使用してもよく、または当該必要な方法ステップを実施するためのより特化した装置を構築するのに都合が良いことを証明できる。様々なこれらのシステムに対する必要な構造は以下の説明から明らかになろう。さらに、本明細書はどの特定のプログラミング言語を参照して説明されていない。様々なプログラミング言語を使用して本明細書の教示事項を本明細書で説明したように実装してもよいことは理解されよう。
【0104】
本明細書の実施形態の以上の説明を例示および説明の目的のために提示した。包括的であることは意図しておらず、本明細書を開示した厳密な形態に限定する意図もない。多数の修正および変形が上述の教示事項に照らして可能である。本開示の範囲はこの詳細な説明により限定されず、本願の特許請求の範囲により限定されることが意図されている。当業者にわかるように、本明細書を、その趣旨または本質的な特性から逸脱せずに他の特定の形態で具現化してもよい。同様に、エンジン、ルーチン、特徴、属性、方法および他の態様の特定の名前付けおよび分割は必須でも重要でもなく、本明細書またはその特徴を実装する機構が異なる名前、分割および/または形式を有してもよい。さらに、当業者に明らかなように、本開示のエンジン、ルーチン、特徴、属性、方法および他の態様をソフトウェア、ハードウェア、ファームウェアまたはその3つの任意の組合せとして実装することができる。また、本明細書のコンポーネントが、その1例はエンジンであるが、ソフトウェアとして実装されるときは常に、当該コンポーネントを、スタンドアロンプログラムとして、大規模プログラムの一部として、複数の別個のプログラムとして、静的リンクにまたは動的リンクライブラリとして、カーネルロード可能エンジンとして、デバイスドライバとして、および/またはコンピュータプログラミングの業界で当業者に対して既知または将来知られる全ての任意の他の方法で実装することができる。さらに、本開示は決して、任意の特定のプログラミング言語における実装、または任意の特定のオペレーティング・システムまたは環境に対する実装に限定されない。したがって、本開示は本明細書の範囲の例示的であって限定的ではなく、それは添付の特許請求の範囲で説明される。