(57)【特許請求の範囲】
【請求項１】
サービスのアベイラビリティ指標をユーザ端末（９８）へ提供する方法であって、
複数のユーザ端末間での通信に関係する１つ以上の通信パラメータであって、単複の通信相手、通信継続時間、通信回数、通信方向、及び利用済み通信サービスの種別の少なくとも１つを含む前記１つ以上の通信パラメータを評価することによって前記複数のユーザ端末間における端末間の関係を導き出すステップと、
前記ユーザ端末と、前記導き出された端末間の関係とを表すデータ構造（２００）を生成するステップと、
ユーザ端末のうちの少なくともいくつかの端末のために、複数のサービスのそれぞれについて、該複数のサービスのうち１つ以上のサービスにおける利用済みのサービスの種別、サービス利用回数、及びサービス利用の継続時間の少なくとも１つを含むサービス利用情報を導出するステップと、
少なくとも１つの前記ユーザ端末と複数の他の前記ユーザ端末の間における前記端末間の関係によって決定されるような、少なくとも１つのユーザ端末（９８）との所定の関連付けを有する前記複数の他のユーザ端末に対して提供されるサービス利用情報に基づいて、少なくとも１つのユーザ端末（９８）に対してかつ複数のサービスの中から、少なくとも１つのユーザ端末（９８）により利用されていないサービスを選択する選択ステップと、
前記選択したサービスを示すメッセージを少なくとも１つのユーザ端末（９８）へ送信するステップと
を含むことを特徴とする方法。
【請求項２】
前記データ構成（２００）は、ノード（３０２、３０４）と、個々に２つの前記ノード（３０２、３０４）を接続するエッジ（３０６）とを有するネットワークグラフ（３００）として表すことが可能であり、
前記ノード（３０２、３０４）は複数のユーザ端末に対応し、前記エッジ（３０６）は前記端末間の関係から導き出されることを特徴とする請求項１に記載の方法。
【請求項３】
サービス選択の基礎を成す前記所定の関連付けは、前記ネットワークグラフ（３００）へ適用可能な距離の測定値として表現される基準を含むことを特徴とする請求項２に記載の方法。
【請求項４】
各エッジ（３０６）は、前記エッジ（３０６）によって接続される２つのノード（３０２、３０４）間の相互関係を定量化するメトリック情報に関連付けられ、
前記目トリック情報は、１つ以上の通信パラメータから導き出されることを特徴とする請求項２又は３に記載の方法。
【請求項５】
サービス選択の基礎を成す前記所定の関連付けは、前記メトリック情報に適用可能な基準を含むことを特徴とする請求項４に記載の方法。
【請求項６】
１つ以上の前記エッジ（３０６）は、方向付けられる有向エッジであり、
前記サービス選択は、前記有向エッジに適用可能な基準を含むことを特徴とする請求項２乃至５の何れか１項に記載の方法。
【請求項７】
少なくともいくつかのユーザ端末は、複数のクリークにおけるメンバシップと、前記ネットワークグラフ（３００）に関する推移関係の存在との少なくとも１つに基づいて順位付けされ、
前記サービス選択は、前記順位付けに関して表現された基準を含むことを特徴とする請求項２乃至５の何れか１項に記載の方法。
【請求項８】
各エッジ（３０６）は、複数の通信サービスのそれぞれについて個別のメトリック情報と関連付けられることを特徴とする請求項２乃至７の何れか１項に記載の方法。
【請求項９】
前記サービス利用情報は、複数の通信サービスに関係し、
前記選択されるサービスは、通信サービスであることを特徴とする請求項１乃至８の何れか１項に記載の方法。
【請求項１０】
前記通信サービスは、音声サービス、テキストベースのサービス、データサービス、マルチメディアサービス、インスタントメッセージサービス、及びコミュニティサービスの少なくとも１つを含むことを特徴とする請求項９に記載の方法。
【請求項１１】
前記サービス利用情報は、複数のアプリケーションサービスに関係し、
前記選択されるサービスは、前記アプリケーションサービスであることを特徴とする請求項１乃至１０の何れか１項に記載の方法。
【請求項１２】
前記サービス利用情報に従って複数のサービスを順位付けするステップをさらに含み、
前記サービスの選択は、さらに、前記サービスの順位付けに基づくことを特徴とする請求項１乃至１１の何れか１項に記載の方法。
【請求項１３】
前記サービスの順位付けは、前記複数のユーザ端末による、個々の各サービスのトータル利用量に依存することを特徴とする請求項１２に記載の方法。
【請求項１４】
前記１つ以上の通信パラメータは、通話明細記録、イベント詳細記録、通信ネットワークインタフェースプロービング、及び複数のユーザ端末エージェントのうちの少なくとも１つから得られることを特徴とする請求項１乃至１３の何れか１項に記載の方法。
【請求項１５】
請求項１乃至１４の何れか１項に記載の方法の各ステップをコンピュータに実行させることを特徴とするコンピュータプログラム。
【請求項１６】
請求項１５に記載のコンピュータプログラムを記憶したコンピュータで読み取り可能な記憶媒体。
【請求項１７】
サービスのアベイラビリティ指標をユーザ端末（９８）へ提供する装置（１００）であって、
ユーザ端末と、複数のユーザ端末間での通信に関係する１つ以上の通信パラメータから導き出される端末間の関係とを表すデータ構造（２００）を提供し、ユーザ端末のうちの少なくともいくつかの端末のために、複数のサービスのそれぞれについてサービス利用情報を提供する記憶部（１１６）と、
少なくとも１つの前記ユーザ端末と複数の他の前記ユーザ端末の間における前記端末間の関係によって決定されるような、少なくとも１つのユーザ端末（９８）との所定の関連付けを有する前記複数の他のユーザ端末に対して提供されるサービス利用情報に基づいて、少なくとも１つのユーザ端末（９８）に対してかつ複数のサービスの中から、少なくとも１つのユーザ端末（９８）により利用されていないサービスを選択するプロセッサ（１２２）と、
前記選択したサービスを示すメッセージを少なくとも１つのユーザ端末（９８）へ送信するための出力インタフェース（１３０）と
を備え、
前記複数のユーザ端末間における前記端末間の関係は、複数のユーザ端末間での通信に関係する１つ以上の通信パラメータであって、単複の通信相手、通信継続時間、通信回数、通信方向、及び利用済み通信サービスの種別の少なくとも１つを含む前記１つ以上の通信パラメータを評価することによって導き出され、
前記サービス利用情報は、前記複数のサービスのうち１つ以上のサービスにおける利用済みのサービスの種別、サービス利用回数、及びサービス利用の継続時間の少なくとも１つを含むことを特徴とする装置。
【請求項１８】
前記データ構造（２００）は、ノード（３０２、３０４）と、個々に２つの前記ノード（３０２、３０４）を接続するエッジ（３０６）とを有するネットワークグラフ（３００）として表すことが可能であり、
前記ノード（３０２、３０４）は複数のユーザ端末に対応し、前記エッジ（３０６）は前記端末間の関係から導き出されることを特徴とする請求項１７に記載の装置。
【請求項１９】
サービス選択の基礎を成す前記所定の関連付けは、前記ネットワークグラフ（３００）へ適用可能な距離の測定値として表現される基準を含むことを特徴とする請求項１８に記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に通信ネットワークに関するものである。詳細には、本発明は、通信ネットワーク内におけるサービスの（存在を含む）アベイラビリティに関する指標をユーザ端末へ提供する技術分野に関するものである。
【背景技術】
【０００２】
今日の通信ネットワークには多量の様々な通信サービスが存在している。利用可能な通信サービスには、音声サービス、データサービス、ショートメッセージサービス（ＳＭＳ）及びマルチメディア・メッセージングサービス（ＭＭＳ）のような従来の電気通信サービスが含まれている。さらに、インスタントメッセージング（ＩＭ）及び、２人以上の通信相手が潜在的に関与する（典型的にはインターネットプロトコルすなわちＩＰをベースとする）コミュニティベースの通信サービスがますますポピュラーになっている。ＩＰベースのコミュニティサービスとは、例えばブログ、仮想フォーラム等々を含むサービスである。
【０００３】
現在使用されている多数の種々の通信サービスの結果、通信環境は全体としてかなり異質なものになっている。通信環境のこの異質な性質は、通信サービス、特にコミュニティベースの通信サービスの多くが標準化されていないという事実によって表されている。また、（種々の移動電話機のような）種々のユーザ端末が様々なセットの通信サービスをサポートしている場合が多い。このことは、特定の通信サービスに関連して２つのユーザ端末が相互に互換性を有しなくてもよいことを意味する。そのため、通信環境の上記異質な性質は、ある程度までユーザ端末間の接続性を阻止することになる。
【０００４】
別の環境ではユーザ端末間の接続性は専ら制限されるものとなる。その理由として、これら端末の現在の構成では、あるいは、迅速なソフトウェアの更新後あるいはサービスへの加入登録後に、或るユーザが自分のユーザ端末によりサポートされている特別の通信サービスについて知らない場合があるという理由が挙げられる。換言すれば、ユーザは、自分が実際に知っているよりも多くの通信オプションをユーザ端末を介して持っている場合がある。例えば、ユーザ端末が、（汎用移動体通信システム（ＵＭＴＳ）仕様などに準拠する）セルラ通信ネットワーク介して、さらに、（無線ローカルエリアネットワーク（ＷＬＡＮ）を介しても提供され得る）コミュニティベースの通信サービスを介して、従来の電気通信サービスをサポートしていれば、ユーザは自分の端末のＵＭＴＳ機能を認知しているだけでよい。この結果、ユーザはＷＬＡＮカバーエリアのみを有するエリア内のいずれの通信も妨げられることになる。但し端末はＷＬＡＮを介してネットワークアクセスのサポートを受けることは可能である。続いて生じる接続性の不足は、このようなコミュニティベースの通信サービスを定期的に利用している場合、ユーザの潜在的通信相手からなる多数の人々にとって特に腹立たしいものになる。一方、多くの状況では、潜在的通信相手が存在しないか、数人の潜在的通信相手しか存在しないという理由のために、ユーザが利用することのないサポートされている通信サービスについてユーザに通知することが無駄になる場合がある。
【０００５】
通信サービスに関連して上述したことは、或る種のアプリケーションサービスについても同様に当てはまる。すなわち、ユーザは、多くの場合、自分の端末によって、原則として実際にサポートされてはいるが現在未使用のアプリケーションサービスから利益を享受できる場合がある。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
通信ネットワークにおけるサービスのアベイラビリティ指標をさらに効率的にユーザ端末へ提供する技術が必要とされている。
【課題を解決するための手段】
【０００７】
第１の側面によれば、サービスのアベイラビリティ指標をユーザ端末へ提供する方法が提供される。本方法は、ユーザ端末と、これらのユーザ端末間での通信に関係する１つ以上の通信パラメータから導き出される端末間の関係とを表すデータ構造を提供するステップと、上記ユーザ端末のうちの少なくともいくつかの端末のために、複数のサービスのそれぞれについてサービス利用情報を提供するステップと、少なくとも１つのユーザ端末に対して、かつ、複数のサービスの中から、少なくとも１つのユーザ端末により利用されないサービスを、端末間の関係により決定されるような、少なくとも１つのユーザ端末との所定の関連付けを有する、ユーザ端末用として提供されるサービス利用情報に基づいて、選択するステップと、該選択したサービスを示すメッセージを少なくとも１つのユーザ端末へ送信するステップとを有する。本書面において理解されるように、「複数」という用語は１よりも大きな数に関する用語である。
【０００８】
上記データ構造は、抽象的なデータモデルの形で、あるいは、複数のデータセットの形で表されるような種々の形で実現されてもよい。このデータ構造は、個々に２つのノードを接続するノードとエッジとを有するネットワークグラフとして表されるように構成されてもよいし、あるいは、個々に２つのノードを接続するノードとエッジとを有するネットワークグラフとして表すことができるようにしてもよい。ネットワークグラフにおいて、これらのノードはユーザ端末に対応すると共に、これらのエッジは端末間の関係から導き出されてもよい。例えば、ユーザ端末間で通信リンクが過去に確立されたユーザ端末を表す２つのノードを接続するためにエッジが使用されてもよい。ネットワークグラフを使用するとき、サービス選択の基礎を成すユーザ端末（すなわちネットワークグラフのノード）間での所定の関連付けをネットワークグラフのトポロジに関連する特徴という観点から定義してもよい。
【０００９】
現在と過去の少なくともいずれかにおいてこのユーザ端末が使用していない利用可能なサービスをユーザ端末に示すステップに関連して、上記サービス選択処理手順を実行してもよい。この選択は特定のユーザ端末の技術的能力を考慮に入れて、ユーザ端末により実際にサポートされている、（ソフトウェアの更新又はサービス加入登録のみが必要とされるケースを含む）サービスのみの推奨が確かめられるようにしてもよい。推奨のターゲットを形成するユーザ端末と、推奨されるサービスを予め利用する別のユーザ端末との間における所定の関連付けは、１つ以上の基準の形で表現することができる。上記基準は、１つ以上の端末間通信パラメータから導き出されるような端末間の関係に（例えばネットワークグラフのトポロジを介して）直接的又は間接的に関するものであってもよい。
【００１０】
１つの例では、上記サービス選択処理手順の基礎を成す所定の関連付けは、ネットワークグラフで表わされる距離の測定値、若しくは、ネットワークグラフに対して適用可能な距離の測定値として表現される基準を含むものとなる。この距離測定値は、ネットワークグラフ内の「ホップ」相互接続専用ノードの所定数であってもよい。１つの実装例では、上記サービス選択は、例えば、サービスのアベイラビリティ指標が送信される送信先のユーザ端末の直接的近傍である複数のユーザ端末用として提供されるサービス利用情報に基づくものであってもよい。別の実装構成では、上記サービス選択は、サービスのアベイラビリティ指標のターゲットを形成するユーザ端末から（１、２又は３ホップのような）所定の最大ホップ数を用いて着信が可能な対象ユーザ端末用として提供されるサービス利用情報に基づいて行われてもよい。
【００１１】
ネットワークグラフにおいて、個々のエッジは、特定のエッジによって接続された２つのノード間における相互関係を定量化するメトリック情報と関連付けられてもよい。このメトリック情報は少なくとも部分的に１つ以上の通信パラメータから導き出されてもよい（あるいは、これらの通信パラメータは多くの場合上記端末間の関係から導き出される均等物である）。上記とは別に、あるいは、上記に加えて、このメトリック情報はネットワークグラフのトポロジのように別のパラメータから導き出されてもよい。ネットワークグラフのトポロジから導き出されるパラメータには、例えば、クリークの存在、あるいは、特定ノードのから見た場合の推移関係という性質が含まれている。メトリック情報が提供されるケースでは、サービス選択処理手順の基礎を成す所定の関連付けは、メトリック情報に関して表現される基準、若しくは、メトリック情報に対して適用可能な基準を含むものであってもよい。
【００１２】
ネットワークグラフ内のエッジは有向エッジ（方向付けられたエッジ）であってもよい（すなわち、例えば矢印の頭部によって示される望ましい方向を示すエッジであってもよい）。有向エッジは、種々のコンテキストにおいて（例えば、端末間の関係を有する異なるユーザ端末のユーザ間においてレベルの信頼性を表現するために）使用してもよい。一般的信頼性特性の中には、信頼性が推移し、かつ、非対称であるという特性が含まれるものもある（すなわち信頼性は一般に双方向的な性質のものではない）。有向エッジの場合、サービス選択処理手順の基礎を成す所定の関連付けは、エッジの方向に関して表現される基準、すなわち、エッジの方向に対して適用可能な基準を含むものであってもよい。
【００１３】
ネットワークグラフ内のノードのうちの少なくともいくつかのノード（すなわちデータ構造内のユーザ端末）は順位付けられてもよく、かつ、サービス選択の基礎を成す所定の関連付けは、順位付けに関して表現される基準を含んでもよい。１つの変形例では、これらのノードは、クリークにおける上記ノードのメンバシップと、ネットワークグラフに関する推移関係の存在とのうちの少なくとも一方に基づいて順位付けられる。
【００１４】
ネットワークグラフ内の特定のエッジの場合、複数の通信サービスのそれぞれについてメトリック情報の別個の要素が提供されてもよい。このようなシナリオでは、特定の通信サービスに関してサービスのアベイラビリティ指標を提供するか否かについての評価は、この特定の通信サービス用として提供されるメトリック情報に基づいて行われる。換言すれば、単一のエッジに関する種々の通信サービスについての評価にはメトリック情報の種々の要素が含まれることになる。
【００１５】
第１の変形例によればサービス利用情報は通信サービスに関係する。したがって上記選択されるサービスは通信サービスになる。可能な通信サービスには、１つ以上の音声サービス、データサービス、マルチメディアサービス、テキストベースのサービス、インスタントメッセージングサービス及びコミュニティベースの通信サービスが含まれる。別の変形例では、サービス利用情報はアプリケーションサービスに関係し、そのため、選択されるサービスはアプリケーションサービスになる。可能なアプリケーションサービスには、特に複数の移動体ユーザ端末の参加及びインタラクションを潜在的に含む移動体ゲーム用アプリケーション、並びに、位置発見用アプリケーション（すなわち、移動体端末を操作するユーザを特定の場所まで案内するアプリケーション）のような移動体用アプリケーションサービスが含まれる（但しこれ以外を排除するものではない）。これらのアプリケーションサービスは、ユーザ端末が通信サービスを介して接続できる接続先のサービス供給ネットワークと通信ネットワークとを介して提供されるサービスであってもよい。
【００１６】
１つのシナリオでは、個々のサービスはサービス利用情報に従って順位付けられる。この順位付けは、例えば、頻繁に利用されるサービスの方がごくまれにしか利用されないサービスよりも高く順位付けられることを意味する。換言すれば、サービスの順位付けは、個々のユーザ端末によるか、データ構造において考慮された端末によるか、あるいは、さらに大きな端末母集団による個々の各サービスの利用に依存して決めてもよい。このような場合、サービス選択はサービスの順位付けに基づいて行われてもよい。
【００１７】
端末間の関係の基礎を成す１つ以上の通信パラメータは、以下のパラメータ、すなわち、（単複の）通信相手、通信継続時間、通信回数、通信方向、利用済み通信サービスの種別を１つ以上含んでもよい。言うまでもなく、端末間の関係はまた、第１のユーザ端末から第２のユーザ端末を介して第３のユーザ端末に対して行われるメッセージのルーティングのような、正確には２つのユーザ端末間での通信に直接関係しない他のパラメータを考慮に入れて導き出されてもよい。通信パラメータを取得する種々の可能な方法が存在する。これらの通信パラメータは、例えば、通話明細記録と、イベント詳細記録と、通信ネットワークインタフェースプロービングと、ユーザ端末エージェントとのうちの少なくとも１つから取得されてもよい。
【００１８】
さらに別の側面によれば、コンピュータプログラムが１つ以上の計算機によって実行される際に、コンピュータプログラムが提供され、該プログラムには、本願に記載の複数の方法と方法の諸側面とのうちの１つ以上から成るステップを実行するためのプログラムコード部分が含まれる。このコンピュータプログラムは、計算機、ＣＤ、ＤＶＤ等々の内部又はこれらの媒体と関連付けられた永久メモリや再書き換え可能なメモリのようなコンピュータ可読記録媒体に格納されてもよい。これに加えて、あるいは、代替例において、上記コンピュータプログラムは、例えば、インターネットや電話回線又は無線リンクのような専用通信回線などのデータネットワークを介して計算機へダウンロードするために提供されてもよい。
【００１９】
さら別の側面によれば、サービスのアベイラビリティ指標をユーザ端末へ提供する装置が提供される。上記装置は、ユーザ端末を表すと共に、該ユーザ端末間での通信に関係する１つ以上の通信パラメータから導き出される端末間の関係を表すデータ構造を提供する格納装置であって、さらに、上記ユーザ端末のうちの少なくともいくつかの端末用として、複数のサービスの各サービスについてサービス利用情報を提供する格納装置と、少なくとも１つのユーザ端末用として、及び、上記複数のサービスの中から、少なくとも１つのユーザ端末が利用していないサービスを選択するように適合されたプロセッサであって、その場合、上記端末間の関係により決定されるような、少なくとも１つのユーザ端末との所定の関連付けを有する複数のユーザ端末用として提供されるサービス利用情報に基づいて上記サービス選択が行われるようになっているプロセッサと、該選択したサービスを示すメッセージを上記ユーザ端末へ送信する出力インタフェースとを備える。上記格納装置は（単一のデータベース内などの）単一の場所に配置されてもよい。代替の実装例では、この格納装置は（２以上の専用データベース内などの）２以上の場所の間に分散される。
【００２０】
１つの構成では、上記データ構造は、ノードとエッジとを有するネットワークグラフとして（コンピュータモニタ又は他の任意の表示装置上などに）表示されるように適合される。その場合、ノードはユーザ端末を表すと共に、エッジは２つのノードを個々に接続し、かつ、ノード間関係から導き出される。ネットワークグラフのシナリオでは、サービス選択の基礎を成す所定の関連付けは、ネットワークグラフで表わされる距離の測定値、若しくは、ネットワークグラフに対して適用可能な距離の測定値として表現される基準を含んでもよい。
【００２１】
上記装置及び該装置のコンポーネントは本願明細書に記載の方法の１つ以上のステップを実行するように構成されてもよい。
【００２２】
以下、図面に示す実施形態例に関連するさらなる詳細及び側面について説明する。
【図面の簡単な説明】
【００２３】
【図１】サービスのアベイラビリティ指標をユーザ端末に提供する装置の実施形態を示す。
【図２】データ構造の実施形態を示す。
【図３】図２のデータ構造から導き出されるノード及びエッジを有するネットワークグラフを示す。
【図４】方法の実施形態を例示するフローチャートを概略的に示す。
【図５】複数のクリークを含むネットワークグラフを概略的に示す。
【図６】例示のネットワークグラフに関連して推移関係というコンセプトを概略的に示す。
【図７】いくつかのクリークを含むさらに別のネットワークグラフを概略的に示す。
【図８】有向エッジを有するネットワークグラフを示す。
【図９】有向エッジを含むネットワークグラフ内のクリークの定義を示す。
【図１０】エッジカウントメカニズムと、５の平均クラスタサイズを有するクリークカウントメカニズムとの間の比較を例示する線図を示す。
【図１１】エッジカウントメカニズムと、２０の平均クラスタサイズを有するクリークカウントメカニズムとの間の比較を例示する線図を示す。
【発明を実施するための形態】
【００２４】
以下の説明において、限定を目的とするのではなく説明を目的として、本書面において提示される技術の完全な理解を提供するために、具体的な詳細が記載される。これらの特定の側面から外れる別の実施形態においてこれらの技術を実施できることは当業者に明らかであろう。例えば、当業者であれば、移動通信環境に関連するだけでなく、有線通信方式とも関連してこれらの技術が実施されてもよいことを理解するであろう。
【００２５】
当業者であれば、本明細書で以下説明する機能が、個々のハードウェア回路を用いて、プログラム済みのマイクロプロセッサと、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）と、特定用途向け集積回路（ＡＳＩＣ）と、デジタル信号プロセッサ（ＤＳＰ）とのうちの少なくともいずれかと共に機能するソフトウェアを用いて、少なくとも部分的に実現されてもよいことをさらに理解するであろう。
【００２６】
図１に関連して、サービスのアベイラビリティ（可用性）指標を提供するための技術を示す実施形態例について以下説明する。図１は、ユーザ端末９８の母集団１０２に対するサービスのアベイラビリティ指標を生成し、かつ、提供するプロセスにおいて一体に動作する種々のサブシステムを備えた装置１００の実施形態例を示す。
【００２７】
端末母集団１０２は、典型的には、複数の通信ネットワークとネットワークアクセス技術とを介して相互に通信するように構成された移動端末と、固定端末９８との混合物である。端末母集団１０２は、例えば、移動電話機、パーソナル・デジタル・アシスタント、データカードあるいはネットワークカード、パーソナルコンピュータ、ラップトップコンピュータ、等々を含むものであってもよい。ユーザ端末間での通信を可能にする通信ネットワークは、インターネット、移動電話ネットワーク及び固定電話ネットワーク、等々を含んでもよい。ユーザ端末により採用される可能なネットワークアクセス技術には、（広帯域符号分割多元接続、又はＷＣＤＭＡ、及びロングタームエボリューション（ＬＴＥ）技術などの）無線ネットワークアクセス技術、並びに、（デジタル加入者回線（ＤＳＬ）技術などの）有線ネットワークアクセス技術が含まれてもよい。
【００２８】
図１に示す実施形態例において、装置１００全体は、３つの専用サブシステム、すなわち、データ供給サブシステム１０４、データ解析サブシステム１０６並びにメッセージングサブシステム１０８を備える。データ供給サブシステム１０４は、ユーザ端末母集団１０２に関連するデータを集めるように適合されたコンポーネントを備える。このようなデータには、ユーザ端末９８間での通信に関係する通信パラメータ、並びに、ユーザ端末９８による（通信及びアプリケーションサービスのような）種々のサービスの利用に関係するサービス利用パラメータが含まれる。通信サービスの特別のケースでは、通信パラメータとサービス利用パラメータとは少なくとも部分的に同一のものであってもよい。１例として、ある特定の通信セッションの継続時間は、通信セッションの基礎を成す特定の通信サービスに関係するサービス利用パラメータと見なすこともできる通信パラメータを構成する。
【００２９】
データ供給サブシステム１０４により集められたデータはデータ解析サブシステム１０６へ提供される。データ解析サブシステム１０６は、個々のユーザ端末９８に関連してデータ供給サブシステム１０４により提供されるデータを評価するように構成される（あるいは、上記ユーザ端末９８は、多くの場合、個々の加入者又はサービス加入登録に関して均等物となる）。データ解析サブシステム１０６の主要な目的は、個々のユーザ端末９８の接続性を高めることができる個々の通信サービスの特定、並びに、個々のユーザ端末９８のユーザービリティを高めることができる個々のアプリケーションサービスの特定である。
【００３０】
図１に示されているように、データ解析サブシステム１０６はメッセージングサブシステム１０８と結合される。メッセージングサブシステム１０８は、個々のユーザ端末と、データ解析サブシステム１０６から得られる個々のサービスとに関連する情報を受信すると共に、利用可能なサービスを示すメッセージを生成し、かつ、該メッセージを端末母集団１０２の個々のユーザ端末９８へアドレス指定するように構成される。
【００３１】
以下、図１に図示の実施形態例についてより良い理解を提供するために、個々のサブシステム１０４、１０６及び１０８のコンポーネント及び処理動作についてさらに詳細に説明する。この点に関して、図２の概略データ構造２００、図３の例示のネットワークグラフ３００並びに図４のフローチャート４００について言及する。
【００３２】
第１の動作ステージにおいて、データ供給サブシステム１０４は、通信ネットワークと、端末母集団１０２によって利用されるＩＰマルチメディアサブシステム（ＩＭＳ）などのサービス供給ネットワークとから端末母集団１０２に関する情報を収集する。このような情報には、典型的には種々の通信パラメータと、種々のサービス利用パラメータとが含まれる。これらの通信パラメータは、（従来の電話サービスを含む）音声サービス、データサービス、（ＭＭＳを含む）マルチメディアサービス、（ＳＭＳを含む）テキストベースのサービス、ＩＭサービス及び（ブログ及び仮想フォーラムのような）コミュニティベースの通信サービスのような複数の通信サービスのそれぞれについて提供されてもよい。これらの通信サービスのそれぞれについて収集された通信パラメータは、１つ以上の通信継続時間、（関与するユーザ端末９８の永久ネットワークアドレスの形で示されるような）通信相手、（２つの特定のユーザ端末９８間で交換されるＳＭＳの数などの）通信回数、（一方向又は双方向などの）通信方向と、（電話サービス又はＭＭＳなどの）種類の利用される通信サービスとを含んでもよい。
【００３３】
通信サービスの場合、上記サービス利用パラメータは、１つ以上の通信パラメータと、オプションとしてさらに別のサービス専用情報とから導き出されるか、あるいは、上記通信パラメータとサービス専用情報とを含むものであってもよい。アプリケーションサービスの場合、上記サービス利用パラメータは、１つ以上の（ＩＭＳサービスなどの）上記種類の利用済みアプリケーションサービス、（特定のＩＭＳサービスが関与している総数などの）サービスの利用回数、並びに（分又は時間で表されるような）サービス利用の総継続時間を含むものであってもよい。
【００３４】
端末母集団１０２に関する情報は種々の方法で収集されてもよい。データ供給サブシステム１０４は、例えば、端末母集団１０２の個々のユーザ端末９８に常駐すると共に、必要な情報を自動的に収集し、かつ、この収集済み情報をデータ供給サブシステムの中央データ収集モジュール１１２へ送信する端末エージェント１１０を備える。これらの端末エージェント１１０は、例えば、端末母集団１０２を構成する少なくともいくつかのユーザ端末９８上で実行する専用ソフトウェアモジュールの形で実現されてもよい。
【００３５】
データ収集コンポーネント１１２はまた、通話明細記録（ＣＤＲ）及びネットワーク通信事業者のデータベースから取得できるイベント詳細記録（ＥＤＲ）を介して、あるいは、端末エージェント１１０を介して、端末母集団１０２に関する情報を収集してもよい。ＣＤＲ及びＥＤＲデータは、（ある特定の通信セッションの継続時間などの）ユーザの振舞い、及び、（電話番号を含む、関与する通信相手のネットワークアドレスなどの）ユーザ関係を記述する低レベルのデータと考えることができる。
【００３６】
端末母集団１０２に関する情報を取得するさらなる可能な手段性として、データ収集コンポーネント１１２と結合された専用モニタリングコンポーネント１１４を介するネットワークインタフェースのプロービングがある。１つの変形例では、モニタリングコンポーネント１１４はトラフィック監視用として通信ネットワークの所定のインタフェースに配置される。ＵＭＴＳネットワークの例では、モニタリングコンポーネント１１４はＵｕインタフェース、Ｉｕ  ＣＳインタフェース又はＩｕ  ＰＳインタフェースに配置されてもよい。別の変形例では、モニタリングコンポーネント１１４はサービス供給用ネットワークのインタフェースに配置される。ＩＭＳネットワークの例では、モニタリングコンポーネント１１４は、呼セッション制御機能（ＣＳＣＦ）ノードとＩＭＳアプリケーションサーバ（ＡＳ）との間のインタフェースに配置されてもよい。
【００３７】
データ収集モジュール１１２の主要な目的として、端末母集団１０２に関する必要情報の収集、並びに、必要に応じてさらなるデータによる収集済み情報の充実がある。データ収集モジュール１１２により収集された情報は一般に非常に異質な性質を有するものであるため、データ収集コンポーネント１１２の別の重要なタスクとして収集済み情報の正常化に関するタスクがある。データ収集コンポーネント１１２により実行される正常化処理には、極度に逸脱した振舞いを有するイベント、呼、又はユーザ端末を破棄するステップが含まれるものとなる。この正常化処理はさらに、収集済み情報を標準化フォーマットに変えるステップを含む。これらの正規化データは、図１に示す処理手順全体の第２ステージで転送され、記憶部１１６又は他の任意のデータ格納装置の中へ入れられる。
【００３８】
記憶部１１６において、データ収集コンポーネント１１２から受信した正規化データは所定の集約ルールに従って集約される。このデータ集約処理は図１に示す処理手順全体の第３ステージで実行される。可能な集約ルールによって、例えば、特定のユーザ端末９８について、（特定の電話サービスと関連するような）個々の通信セッションの継続時間を合計するように指定してもよい。別の集約ルールによって、特定のユーザ端末９８に関わる通信について、すべての通信相手を格納するように指定してもよい。
【００３９】
集約プロセスの結果として、記憶部１１６は、図４のフローチャート４００に示されるように、ユーザ端末９８間の通信に関係する１つ以上の通信パラメータから導き出される、ユーザ端末９８との端末間の関係を表すデータ構造を提供する（ステップ４０２）。記憶部１１６内にある、あるいは、記憶部１１６外にある上記データ構造又は別のコンポーネントは、端末母集団１０２により利用される複数のサービスのそれぞれについてサービス利用情報をさらに提供してもよい（フローチャート４００のステップ４０４を参照のこと）。
【００４０】
図２は実施形態例を示す図であり、この実施形態例は、データ収集コンポーネント１１２から受信されるような正規化データを記憶部１１６での集約処理の結果から得られるデータ構造２００である。図２に示す例では、データ構造２００は、端末母集団１０２（図１を参照のこと）の個々のユーザ端末９８用として個々のデータセットを有する。個々のデータセットは端末ＩＤ２０２により特定される。端末ＩＤ２０２は、ユーザ端末の移動局のＩＳＮＤ番号（ＭＳＩＳＤＮ）のようなユーザ端末の永久ネットワークアドレスであってもよい。
【００４１】
個々のデータセットは、特定のユーザ端末９８の端末間における通信関係を示すデータセット部分２０４を有する。図２に示すように、上記通信関係は頻度の高い通信相手の端末ＩＤにより特定されてもよい。さらに、個々のデータセットは、部分２０４にリストされる個々の通信関係を定量化するさらなるデータセット部分２０６を有する。通信関係の可能な定量化は、特定の通信相手との通信の総継続時間、特定の通信相手との通信回数、通信方向、並びに、利用した通信サービスの種類のような通信パラメータを含むか、あるいは、該通信パラメータから導き出されてもよい。したがって、データセット部分２０６は、特定のユーザ端末９８が利用した種々の通信サービスについてのサービス利用情報も含むことになる。
【００４２】
オプションとして、個々のデータセットは補足サービス利用情報を格納するための専用データセット部分２０８をさらに有してもよい。データセット部分２０８に格納された補足サービス利用情報は、例えば、アプリケーションサービスの利用に関係する情報や他の任意の非コミュニケーションサービスを含んでもよい。
【００４３】
タイム制御された態様で記憶部１１６により実行される上記集約処理を実行してもよい。例えば、この集約は１日ベースで、１時間ベースで又は週日と週末間の分割により実行することができる。（時間、日などのような）個々の特定の時間単位に対して、基底に在るデータ構造に従って別個のデータセットを生成してもよい。
【００４４】
次にデータ解析サブシステム１０６の動作と、個々の各ユーザ端末９８（又は加入登録）に対する図１に示す処理手順全体の第４ステージとに目を向けると、記憶部１１６内のデータ構造２００として格納されるデータに基づいて（個々の通信サービスなどに関連する）個々の特定のサービスを表すネットワークグラフが導き出される。このネットワークグラフはデータ解析サブシステム１０６のネットワーク分析コンポーネント１１８により生成される。要するに、ネットワーク分析コンポーネント１１８は、個々のユーザ端末及びサービスに関連する、図３に示すネットワークグラフ３００に類似のグラフを生成する。
【００４５】
図３のネットワークグラフ３００は（ノード３０２及び３０４のような）ノードと、個々に２つのノードを接続する（エッジ３０６のような）エッジとから構成される。これらのネットワークグラフ３００のノードがユーザ端末９８を表すものであるのに対して、上記エッジは端末間における通信関係から導き出される。
【００４６】
図３の例示のネットワークグラフ３００は、端末ＩＤ１２３４５６７８９を持つユーザ端末を表す例示のノード３０２に対応する、図２に示すデータセットに基づいて導き出されたグラフである。図２のデータセット部分２０４から明らかになるように、このユーザ端末は７つの他のユーザ端末と（直接の）通信関係を有している。この理由のために、（端末ＩＤ１２３４５６７８１を持つユーザ端末に対応できるノード３０４のような）７つの隣接ノードを有するエッジを介してノード３０２は直接接続される。ネットワークグラフ３００の複雑さを減らすために、（通信回数又は通信の総継続時間に関連するような）所定の低位のしきい値を上回るような通信関係のみがデータセット部分２０４にリストされる。
【００４７】
ここで注目すべき点として、ネットワーク分析コンポーネント１１８によるネットワークグラフ３００の生成時に、（データセット部分２０４にリストされている直接の通信相手などの）ノード３０２の直接的近傍が考慮されるだけでなく、（推移的近傍とも呼ばれる）間接的近傍も考慮されるという点が挙げられる。ここで理解されるように、間接的近傍とは、ノード３０２の近傍のうちの直接的近傍であって、これら直接的近傍自体はノード３０２の直接的近傍ではない近傍を指す。このようにして、いくつかの間接的近傍関係レベルを定義することができる。図３に図示のように、（ノード３０４のような）ノード３０２の直接的近傍が第１の近傍レベル３１０に属しているのに対して、ノード３０２の間接的近傍は、上記間接的近傍がノード３０２の近傍の直接的近傍であるか、間接近傍であるかに依存して、さらに別の近傍レベル３１２、３１４などに配置される。
【００４８】
特定のネットワークグラフ３００内の特定のノード３０２に対して考慮される近傍レベルの数は、ネットワークグラフ３００の複雑さ全体及びそのトポロジ解析を減らすために一般に限定される。多くの場合、１〜３の近傍レベルを考慮すれば十分である。理解されるように、ノード３０２の外側の近傍レベル３１２及び３１４における近傍の特定は、（ノード３０４に対する場合のように）ノード３０２の近傍について、記憶部１１６内で提供されるデータセットの評価を必要とする。
【００４９】
種々の近傍レベル３１０、３１２、３１４に基づいてネットワークグラフ３００において距離測定値を定義することができる。例えば、ノード３０２の直接的近傍は、このノード３０２からの最短距離を有し、第１のレベルの近傍（近傍レベル３１２）はノード３０２からの第２の最短距離を有することになる、等々。この結果、以下さらに詳細に説明するグラフベースのサービス選択処理手順用として距離基準を定義してもよい。
【００５０】
オプションの実施形態において、（２つのノード３０２と３０４とを接続するエッジ３０６のような）個々のエッジは、エッジによって接続された２つのノード間の相互関係（又は関係）を定量化するメトリック情報とさらに関連付けられる。このメトリック情報は、対応するデータセットのデータセット部分２０６内に特定のユーザ端末用として格納されているとき、通信パラメータから導き出されてもよい（図２を参照のこと）。さらに、以下に説明するように、上記メトリック情報は、ネットワークグラフ３００のトポロジから導き出されてもよい。
【００５１】
複数の利用されるサービスのそれぞれのサービス用として、メトリック情報の別個の要素が特定の端末により提供されてもよい。ある特定の通信サービスの例では、（一方向通信、双方向通信などのような）通信方向と、（１つのユーザ端末から別のユーザ端末へ送信されるＳＭＳの数などの）通信回数と、２つのユーザ端末間における通信の総継続時間、等々に基づいて上記メトリック情報を導き出してもよい。
【００５２】
最も単純なケースでは、メトリック情報は、複数の通信パラメータについて評価とネットワークグラフのトポロジとの少なくともいずれかに基づいて生成される単一の数から構成される。ユーザ対ユーザ関係の定義を可能にする個々のサービス（ＩＭサービス、コミュニティベースの通信サービス、或る種のアプリケーションサービスなどを含む）に関連する別個のメトリック情報を原則として生成できるという点に留意することが重要である。
【００５３】
ネットワークグラフ３００を生成するステップに加えて、ネットワーク分析コンポーネント１１８は、サービス選択処理手順に関連して後程利用できる種々のトポロジ基準に関連して、生成済みネットワークグラフ３００の分析処理の管理も行う。このようなトポロジ基準はいわゆるクリークにおける個々のノードのメンバシップ、（すなわち間接的近傍の）推移関係の存在、等々を含んでもよい。さらに、ネットワークグラフ３００内の個々のノードがトポロジ基準に従って順位付けられてもよく、かつ、この順位付けは、その後、サービス選択処理手順中に考慮されてもよい。コンポーネント１１８により実行されるようなネットワークグラフ分析及びノードの順位付け処理については、図５〜図１１に関連して後程さらに詳細に説明する。
【００５４】
図１に示す処理手順全体の第５の動作状態では、記憶部１１６により提供されるようなサービス利用情報が個々のサービス及び特定のユーザ端末９８について分析される。図１に示されるように、サービス利用分析は専用サービス利用コンポーネント１２０により実行される。ここで注目すべき点として、分析される対象サービスが必ずしも、図３のノード３０２に対応するユーザ端末のような調査中のユーザ端末により実際に利用されるサービスに限定される必要はないという点が挙げられる。逆に、特定のネットワークグラフ内の（ノード３０４などに関する）すべてのノードについてサービスの利用が分析されることになる。サービス利用の分析の結果、図３のネットワークグラフ３００のような所定のネットワークグラフの内部で利用されるサービスリストが決定されることになる。
【００５５】
オプションのモードでは、サービスの利用分析はサービス５の順位付けをさらに含む。個々の分析対象サービスは、例えば、特別のネットワークグラフに属するノード間における当該サービスの利用全体に基づいて順位付けられてもよい。換言すれば、（利用継続時間又は利用回数に関するような）最高のサービス利用全体を伴うサービスは最も高く順位付けられる。個々の近傍レベルについてサービスの順位付けを個々に実行してもよい。したがって、図３に示すネットワークグラフシナリオでは、上記アプローチは結果として別個のサービスの３つの順位付けを生むことになる。
【００５６】
図１に示す処理手順全体の次の動作ステージにおいて、いくつかのまたはそれ以上の個々のユーザ端末９８に関連して、オーバーレイコンポーネント１２２は、サービス利用の分析を管理してコンポーネント１２０により決定されるような（単複の）サービスの順位と組み合わされて、ネットワーク分析コンポーネント１１８により生成されるような、ネットワークグラフ３００及び関連付けられた（メトリックの及びその他の）情報を分析する（すなわち「オーバーレイ」する）。オーバーレイコンポーネント１２２により実行されるこの分析の目的は、ネットワークグラフ３００内のノード３０２に対応する特定のユーザ端末ついて、推奨用として１つ以上の順位付けられたサービスを選択することである。
【００５７】
詳細には、上記選択が実行されて、特定のユーザ端末が現在利用していない非常に高い順位にあるサービスが判定されて、この特定のユーザ端末の接続性とユーザービリティの少なくともいずれかが高められる。フローチャート４００内のステップ４０６（図４を参照のこと）に例示のように、例えば、ネットワークグラフ３００に関して、上記特定のユーザ端末との所定の関連付けを有する隣接するユーザ端末用として取得されたサービス利用情報に基づいて上記サービス選択処理手順は実行される。
【００５８】
（図３に示す第１の近傍レベル３１０の範囲内の近傍のような）多数の近い近傍が特定のサービスを利用する場合、サービス選択処理手順の１つの可能な実現中に、距離測定値が印加され、この測定値に従って、特定のサービスが選択される蓋然性は高まる。関連付けられた隣接するユーザ端末を分析する上記アプローチの理由として、選択されたサービスがすでに近い近傍により利用されている場合、特定のユーザ端末の接続性とユーザービリティの少なくともいずれかが特に高まるという事実が挙げられる。換言すれば、ユーザ端末Ａがあるサービスに関連して推奨される場合、ユーザ端末Ａのネットワークグラフ内のユーザ端末Ｃ、Ｄ、Ｅがこのサービスを利用するという理由によって、ネットワークグラフ内でユーザ端末Ａがユーザ端末Ｃ、Ｄ、Ｅにどのくらい近接しているかについて上記推奨の相互検証が行われることになる。ユーザ端末Ａに関連して上記３つのユーザ端末Ｃ、Ｄ、Ｅに対する累積された距離測定値が所定のしきい値（又は他の任意の距離基準）を上回った場合には、特別のサービスはそれ以上考慮されなくなる。
【００５９】
オーバーレイコンポーネント１２２により実行される上記サービス選択処理手順中に、種々の個々の基準及び基準の組み合わせを考慮することができる。上述したように、このサービスをすでに利用しているユーザ端末の近さのみならず、個々のサービスの順位を考慮に入れることができる。さらに、ネットワークグラフ３００内の種々のノードのオプションの順位のみならず、ネットワークグラフ３００内の個々のエッジと関連付けられたメトリック情報も考慮することができる。ネットワークグラフ３００の他のトポロジ基準も同様に考慮してもよい。
【００６０】
オーバーレイコンポーネント１２２は、個々の分析済みユーザ端末９８について、通信ネットワークを介して対応するユーザ端末９８へ送信すべき１つ以上のサービス指標を出力する。オーバーレイコンポーネント１２２により出力されるこれらのサービス指標は、第７の動作ステージで、オプションのサービス推奨コンポーネント１２４へ送信され、この推奨コンポーネントは、図１に示されるように８つの動作状態でこれらのサービス推奨をメッセージングサブシステム１０８へ転送する。
【００６１】
サービス推奨コンポーネント１２４は、オーバーレイコンポーネント１２２と、サービス利用コンポーネント１２０と、ネットワーク分析コンポーネント１１８とによって実行される分析に基づいて、特定のユーザ端末（ノード３０２）のネットワークグラフ３００内の１つ以上のマイクロセグメントを特定する。詳細には、サービス推奨コンポーネント１２４によって特定されるマイクロセグメントは、同様のサービス利用の振舞いとトポロジ相互関係との少なくともいずれかを有するノードをネットワークグラフ３００の中に含む。次いで、上記特定済みマイクロセグメントの範囲内で、マイクロセグメントを構成するノードの範囲内にあるサービスの浸透レベルに基づいてサービスが推奨されてもよい。換言すれば、特定されたマイクロセグメント内の多くのノードが特定のサービスを利用する場合、このサービスをまだ利用していないマイクロセグメント内の他のノードに対してその際このサービスを推奨してもよい。図５〜図１１に関連して以下に説明する技術を用いてネットワークグラフ３００内のマイクロセグメントの特定を行ってもよい。
【００６２】
メッセージングサブシステム１０８において、オーバーレイコンポーネント１２２により選択される（さらに場合に応じてサービス推奨コンポーネント１２４によりフィルタされる）サービスに関するサービス指標は、メッセージエンジン１２６によりサービス選択が行われる対象となる特別のユーザ端末９８の指標と共に受信される。次いで、メッセージエンジン１２６は、プロセス連鎖の第９ステージで、（ホーム・ロケーション・レジスタ（ＨＬＲ）のような）加入登録データベース又はリポジトリにコンタクトして、サービス選択が行われる対象となる（永久ネットワークアドレスなどの）ユーザ端末９８のコンタクト情報を取得する。次いで、図１に示す第１０ステージで、１つ以上の選択済みサービスを示す（ＳＭＳ又は電子メールなどの）メッセージは、加入登録リポジトリ１２８から受信されるようなユーザ端末９８のネットワークアドレスを用いて、端末母集団１０２内にあるユーザ端末９８へ送信される。このメッセージが、メッセージングサブシステム１０８の出力インタフェース１３０を介して送信され、次いで、１つ以上の選択済みサービスのアベイラビリティ（存在など）についてユーザ端末９８に通知する。上記プロセスは図４のフローチャート４００内のステップ４０８に対応する。上記メッセージを受信するユーザ端末９８は、推奨サービスへアクセスするためのすべての必要なステップを自動的に開始するように構成されてもよい。上記とは別に、（ユーザ確認のような）ユーザインタラクションを明示的に要求するようにしてもよい。
【００６３】
サービス指標メッセージの出力に加えて、フラグ又は別の識別子が加入登録リポジトリ１２８に設定される。次いで、このフラグ設定値は、特定のユーザ端末９８から得られるフィードバック情報の受信時に最終の第１１ステージで評価される。例えば、特定のユーザ端末９８が推奨サービスを利用できるようにするために、ソフトウェアのダウンロード、加入登録更新、等々を要求するメッセージの中にフィードバック情報が存在してもよい。これらのフラグ設定値に基づいてフィードバック情報を評価することにより、対応するフィードバック情報がメッセージングサブシステム１０８からデータ解析サブシステム１０６へ提供されて、オーバーレイコンポーネント１２２によって適用されるサービス選択処理手順の形でマシン学習アルゴリズムを実現するようにしてもよい。
【００６４】
メッセージエンジン１２６からユーザ端末９８へ送信されるサービス指標メッセージは、利用可能なサービスについて具体的に言及するか、該サービスについて具体的に説明するかの少なくともいずれかを行うようにしてもよい。メッセージの形のこのサービス参照には、例えば、識別子、ＩＰアドレス又はサービスのユニバーサルリソースロケータ（ＵＲＬ）が含まれてもよい。オプションとして、上記メッセージはまた、特定のサービスの利用を可能にするために必要な実行すべきステップに関する情報を含んでもよい。さらに、このメッセージはネットワークグラフ３００に関して該サービスをすでに利用している推奨の受け手９８の近くにあるユーザ端末に関する指標を含んでもよい。さらに、ネットワークグラフ３００に関して上記受け手に近接するユーザ端末のために集められた情報によって、受け手９８に関連するサービス利用の状況プロファイルを充実するようにしてもよい。
【００６５】
図１に示す処理手順全体について、以上ある程度詳細に説明したが、ネットワークトポロジ解析に関するネットワーク分析コンポーネント１１８のいくつかのオプションの動作モードについて次にさらに考察する。上記トポロジ解析の結果を利用して、オーバーレイコンポーネント１２２により実行されるサービス選択処理に対応する基準を定義してもよい。
【００６６】
ソーシャルネットワークをある程度まで示すものとして（も）図３のネットワークグラフ３００を解釈することによって、調査中のユーザ端末のオペレータの親しい友人が操作するユーザ端末により利用されるサービス用として作成されたサービス指標又は推奨が、特に後者の推奨の場合強力かつ有用なものになることは明らかである。上記理由のために、特定の端末間（すなわち「ユーザ間」）関係の「強さ」（すなわちネットワークグラフ３００内のエッジに対応する同じ順位の「強さ」）を決定するための抽出メカニズムを求める要望が存在する。
【００６７】
以下、ネットワークグラフのトポロジ解析に基づいて純粋に上記要望に取り組むいくつかの抽出メカニズムについて説明する。ノードとエッジの少なくともいずれかに関連するさらに別のメトリック情報の提供に関して、結果を生みだすメカニズムを明細書本文の図１の解析コンポーネント１１８により実現することが可能である。次いで、このさらに別のメトリック情報は、オーバーレイコンポーネント１２２により実行されるサービス選択動作のための追加の基礎を形成してもよい。しかし、本願明細書で以下に説明する技術が他の任意の文脈でも実行され得ることは理解できよう。特に、ユーザ端末とは異なるエンティティに対して、サービスとは異なる要素を推奨するステップに関して以下の技術の実行が可能である。
【００６８】
ネットワークグラフ３００という観点から見ると、ソーシャルグループがいわゆる個々のノードのクラスタとして出現することになる。クラスタの１つの典型的特徴として、通信リンクを表すエッジによってクラスタが密接に接続されるという事実がある。クラスタが十分に接続されていれば、クラスタ内の（頂点とも呼ばれる）すべてのノードは相互に接続され、これらのノードは可能なかぎり緊密にクラスタされる。
【００６９】
＜クリーク＞
完全なグラフとは、（頂点とも呼ばれる）すべてのノードが相互の直接接続部（すなわちエッジ）を有するグラフである。さらに大きなグラフでは、完全なグラフを形成するノードのサブグループを見つけることが関心の対象となる。グラフには、完全なものであるいくつかのサブグループが含まれ、さらに、これらサブグループの個数と、最大の個数と、どのサブグループが最大のサブグループであるかを発見することは、グラフ理論においてクリーク問題（最大クリークの発見）と呼ばれる。図５はノード｛Ｖ０；Ｖ１；Ｖ２；Ｖ３｝から成る４個のノードにより作成されるクリークを示す。これら４個のノードは全て完全に接続されている。すなわちすべてのノードは互いにエッジを有し、かつ、図５のネットワークグラフ５００において最大数のクリーク（４個のクリーク）を形成している。不都合なことに、このクリーク問題は非決定論的ポリノミナルタイム（ＮＰ）である。このことは、容易にスケーリングが可能なアルゴリズムの作成が、不可能ではないとはいえ、困難であり、かつ、その計算時間がグラフのサイズと共に指数関数的に増加することを意味する。そのため、クリーク問題に対する次善策、あるいは、クリーク問題の近似解が得られれば有益である。
【００７０】
３個より大きなすべてのクリークはサイズ３のクリーク（すなわち正確に３個のノードを個々に有するクリーク）に分割することができる。このことは、すべてのクリークがサイズ３のクリークの集合として提示できることを意味する。いくつのサブクリークがサイズｎの大きなクリーク内に存在しているかどうかを計算する公式はｎ×（ｎ−１）／２により定義される。
【００７１】
例えば、図５に示されるようなサイズｎ＝４のクリークを６個（サイズ３（４×３／２）のクリーク）に分割することも可能である。２のクリークと、サイズ３の１つのクリークと、サイズ４の１つのクリークとを持つネットワークグラフ内のユーザ端末は、サイズ９の組み合わされたクリークを有することになる。このようにして、ユーザ端末のクリークがいくつあり、かつ、どのくらいの大きさであるかに関して異なるユーザ端末を比較することが可能である。２つのユーザ端末が共有しているクリークの数がユーザ端末の関係の好適度を示す測定値になることが知られている。したがって、対応するメトリック情報が、上記２つのユーザ端末の関係（すなわち、ネットワークグラフの画像内の相互の接続エッジとの関係）に追加されると共に、サービス選択処理手順中にこのメトリック情報を評価できることになる。
【００７２】
＜推移関係＞
推移関係とは、１よりも長い距離であって、（図３内のノード３０２のような）着目中のノードからの距離をグラフ内に有する関係、すなわち、上記で使用した術語で示した間接的近傍に対応する関係である。別のノードを経由して着目中のノードとの関係を有するノードが、直接的近傍であるノードのようなノードと親密な関係を有するものとして予想されることはない。
【００７３】
上記距離が増加するにつれて、関係の強さは低下する。したがって、どのくらいの深さまで関係の探索を行うかを限定することは適切なことである。「相互の友人」の数もまた関係の結果に影響を与えることになる。この場合、上記推移関係の方が、ただ一人の相互の友人が存在する場合よりも強くなる。図６に示すネットワークグラフ６００はアクティブノードからの２の距離を共有する２つのノードＶ４、Ｖ５を比較するが、ノードのうちの一方は、該一方のノードがアクティブノードＶ０と共有している「相互の友人」の数に起因してより強い関係を有すると考えられる。
【００７４】
＜推測関係値の計算＞
推測された関係、すなわち直接的近傍ｖに対応する着目中のノードｗの順位（ユーザ順位）は下式により示される。ここで注目すべき点として、着目中のノードから１よりも長い距離を有するノードに対しては下式は当てはまらないということが挙げられる。
ｕｓｅｒ＿ｒａｎｋ＝（ｍａｘ＿ｄｅｐｔｈ−ｄｉｓｔａｎｃｅ）＋（｜ｑ｜ｖ，ｗ／｜Ｑ｜ｖ）
但し、｜ｑ｜ｖ，ｗは上記ノードｗとノードｖとが構成メンバである共有クリークの個数であり、かつ、｜Ｑ｜ｖはノードｖが構成メンバであるクリークの総数であり、max_depthはアルゴリズムが考慮に入れる最大深さであり、この最大深さよりも長い距離を有するノードは、着目中のノードに対応する推測値を取得しなくなる。クリークの総数による除算が行われて、ノードのメンバにより構成されているクリークの個数の割合が得られる。より高い割合はより高い順位を意味する。
【００７５】
推移ノードの関係を表す順位の計算ステップは、直接的近傍に関連する順位の計算ステップとは異なるものとなる。着目中のノードと直接的関係を有していないノードは少ない強さの関係を有することになる。しかし、「相互の友人」の数が多くなればなるほど、より高い順位へ導かれる。したがって、上記順位付けは、特定のノードが接続されている着目中のノードの近傍の個数に部分的に依存することになる。
【００７６】
着目中のノードの異なる近傍が異なる順位を有しているため、推移関係の計算時にこれらの近傍を考量する必要がある。着目中のノードは、「相互の友人」との強い関係を有する場合、（メトリック情報に関して）特定のノードと強い関係を有する可能性が大きくなる。
【００７７】
ある特定ノードの順位は下式を用いて計算することができる：
【００７８】
【数１】
0005325989.tif 000002
【００７９】
上式では、「相互の友人」の数が増加するにつれて順位は上昇し、かつ、これらのエッジの値が高い場合、上記「相互の友人」の数はさらに増加する。パラメータｃが、相互の友人の数の重要度と近傍の順位値との間のバランスを決定する定数であるという点に留意されたい。サービス選択処理手順に関して着目中のノードの近傍と関連付けられる絶対順位又は相対順位を評価することができる。換言すれば、より高い順位を有する直接的近傍が利用する特定のサービスが選択される可能性の方が、下位の順位を有する直接的近傍が利用する別のサービスと比べてより高くなる。したがって、特別のユーザービリティのサービスのみの推奨を保証することが可能となる。
【００８０】
＜近似値＞
以下、直接又は直近の近傍の順位を計算する第２のアプローチを提示する。このアプローチはクリークカウントの近似値及びクリーク分割に関与するものである。この着想は、関係を予測するために着目中のノードのクリークを発見するという着想である。上述のようにクリークの分割によって、これらのさらに小さなすべてのクリークの発見が可能となる。これらのクリークのうちで、メンバとして着目中のノードを有する分割済みクリークのみについてさらに考察する。
【００８１】
図７のネットワークグラフ７００は、着目中のノードＶ０に基づいてクリークをクリークのメンバとして計算するシナリオを示す図である。ノードＶ６は３つのクリーク（｛Ｖ６、Ｖ７、Ｖ０｝、｛Ｖ６、Ｖ４、Ｖ０｝、｛Ｖ６、Ｖ５、Ｖ０}）のメンバであり、これらはすべてサイズ３のクリークである。
【００８２】
クリーク｛Ｖ０、Ｖ１、Ｖ２、Ｖ３｝がさらに小さなクリークに分割される場合、すべてのクリークはメンバとしてそのままＶ０を持つ必要がある。したがって、クリークは｛Ｖ０、Ｖ１、Ｖ２｝、｛Ｖ０、Ｖ１、Ｖ３｝、｛Ｖ０、Ｖ２、Ｖ３｝に分割される（ここで｛Ｖ１、Ｖ２、Ｖ３｝がメンバとしてＶ０を有していないこと、したがって｛Ｖ１、Ｖ２、Ｖ３｝は使用されないという点に留意されたい）。これらのノードは、Ｖ０を除いて個々に２つのクリークの構成メンバであることが理解される。このことは、上記クリーク分割では１つのクリークのロスが生じることを意味する。これによって、正規のクリークカウントアルゴリズム間において異なる結果へ導かれることになるとはいえ、良好な近似値が得られることになる。
【００８３】
ノードのメンバにより構成されるクリークの数は、ノードの内外のエッジの総数に関係するので、このクリーク数は内外のエッジの数から１を減じることにより容易に計算することができる。例えば、Ｖ２は３つのエッジを有し、したがってＶ２は、Ｖ０も構成メンバの１つである２つクリークの構成メンバとなる。
【００８４】
前のセクションの場合と同じ式を用いてある特定ノードの順位を計算することが可能であるが、｜Ｑ｜ｖと｜ｑ｜ｖ，ｗの定義は異なるものとなる。詳細には以下の定義が用いられる：
【００８５】
【数２】
0005325989.tif 000003
【００８６】
＜信頼性＞
異なるユーザ端末のユーザ間における信頼性関係が、例えば、以上略述したようなクリーク及び推移関係などのトポロジ特性を用いて抽象的に決定されると、図８に示すようにネットワークグラフ８００の視覚化が可能となる。このネットワークグラフ８００では、「信頼性」が常に過渡的なものであり、かつ、非対称なものであることを考慮に入れながら有向エッジが用いられる。
【００８７】
図８に示す有向グラフの場合、クリークについての特別の定義が適用される。このクリーク定義は、着目中のノードが「信頼性のある」２以上の近傍を有し、かつ、グラフのいずれかの方向に関係を有していれば、このグラフはクリークを形成するというものである。図９は、着目中のノードがＶ０である場合の上記のようなクリークの例を示す図である。
【００８８】
＜パフォーマンステスト＞
クリークの分割を行う計算アルゴリズム（クリークカウントと呼ばれる）と、エッジをカウントする近似アルゴリズム（エッジカウントと呼ばれる）とを比較するためにパフォーマンステストが行われた。これらの結果は、エッジカウントアルゴリズムの方が、クリークカウントアルゴリズムよりもパフォーマンスがすぐれていたことを示している。その差は、ネットワークグラフにおける平均クラスタサイズが増加するにつれて増加する。この増加は、さらに大きなクラスタが存在するとき、したがってそのスケーラビリティを証明するさらに多くの計算量が存在するとき、多くのエッジが存在するという事実に起因して生じるものである（図１０及び図１１の線図１０００及び１１００をそれぞれ参照のこと）。
【００８９】
＜推奨−項目値の予測＞
（サービスのような）要素を推奨できるようにするためには、ユーザ端末（又はユーザ端末のユーザのような他の任意のエンティティ）がどのくらいの量を特定の項目から獲得するようになるかを予測する方法を持つ必要がある。この獲得は下式を用いて予測してもよい：
【００９０】
【数３】
0005325989.tif 000004
【００９１】
但し、ｃ（ｉ）は項目ｉに対して予測される格付け値であり、ｓｉｍ（ｃ，ｐ）はユーザ端末（すなわち別のエンティティ）ｃ及びｐ間の類似度であり、ｐ（ｉ）は項目ｉにおけるユーザ端末（すなわちエンティティ）ｐの格付け済みの値である。エンティティ間の類似度は、このケースでは、上述のアプローチのうちの任意のアプローチにより決定されるようなエンティティ間の関係値になる。上記式を用いて、より高い類似度を有するエンティティの方が、項目値に対してより高い影響を与えていることが理解できる。より高い値の項目の方がエンティティｃに対するより好適な推奨を示す。この推奨は直接的近傍が格付けしたすべての項目について行われる。最大値を持つ項目が着目中のエンティティに対して推奨される。
【００９２】
図５から図１１に示すような上記の技術の利点として、当該技術が、正規の（個別化された）信頼性システムと比較して、近接関係を示すグラフの形でパターンを調べるという事実がある。上記技術がこれらのパターンを単に調べる技術であることに起因して、該技術はデータに対する制限を受けることが全くなく、このことが、あらゆる種類のネットワークグラフにとって、特に、有向エッジを有する（すなわち信頼性を引き出すことができる）ネットワークグラフにとって非常に適したものとなる。（図１のサービス推奨コンポーネント１２４などにより）上記パターンベースの技術を適用して、同様の振舞いを示すユーザ端末のノードグラフ３００内にあるマイクロセグメントであって、利益を享受できない可能性がある上記のようなサービスをフィルタして除去するために上記マイクロセグメントの特定を行うことが可能となる。
【００９３】
図１のオーバーレイコンポーネント１２２とサービス推奨コンポーネント１２４間における協働については、以下のように説明することができる：すなわち、１つの実装例では、オーバーレイコンポーネント１２２は、主として所定の端末母集団の範囲内でのユーザ端末間おけるサービス利用状況の違いを決定すると共に、次いで、（上述のようなネットワークグラフに基づいて）端末母集団を区分して、グループ化が行われる。これらのグループにおいて、「アウトサイダ」（すなわち、特定のサービスを利用しないグループの範囲内のユーザ端末）に対して特定のサービスの利用が推奨される。次いで、サービス推奨コンポーネント１２４は、図５〜図１１に関連して上述したように（例えば潜在的に不適切な推奨をフィルタして除去するために）サービス推奨についてさらに考量するようにしてもよい。
【００９４】
上記した以上のことから明らかになるように、本願に記載のサービス指標技術は、非常に複雑なサービス選択処理手順が適用される場合、個々のユーザ端末の接続性とユーザービリティの少なくともいずれかを高める際に特に有用なものになる。サービス選択処理手順における端末間の関係を考慮することによって、上記サービスのアベイラビリティ指標を「個別的なもの」にすることができ、それによってユーザは特定のサービスを推奨する利点をより良く理解することが可能となる。この利点は、一方で利用可能なサービス間で可能な相互相関の結果であると共に、他方で端末専用ネットワークグラフの結果でもある。さらに、本願に記載の技術は、サービスの推奨及びサービス要求に関する明示的なフィードバック情報を提供し、この提供によってサービス選択処理手順の段階的微調整を可能にするものである。
【００９５】
特別の実施形態例を参照しながら本発明について説明したが、当業者であれば、本発明は、本明細書に記載され、図示されているこれら特定の実施形態例のみに限定されるものではないことを理解するであろう。本開示は一例にすぎないことを理解されたい。それゆえ、本発明は本明細書に添付した特許請求の範囲によってのみ限定されることが意図されている。
【図１】
0005325989.tif 000005
【図２】
0005325989.tif 000006
【図３】
0005325989.tif 000007
【図４】
0005325989.tif 000008
【図５】
0005325989.tif 000009
【図６】
0005325989.tif 000010
【図７】
0005325989.tif 000011
【図８】
0005325989.tif 000012
【図９】
0005325989.tif 000013
【図１０】
0005325989.tif 000014
【図１１】
0005325989.tif 000015