特許 5667084 統合通信システムおよび方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5667084

(24)【登録日】2014年12月19日

(45)【発行日】2015年2月12日

(54)【発明の名称】統合通信システムおよび方法

(51)【国際特許分類】

   H04M 3/00 20060101AFI20150122BHJP

   H04M 3/42 20060101ALI20150122BHJP

   H04M 15/00 20060101ALI20150122BHJP

【ＦＩ】

   H04M3/00 B

   H04M3/42 E

   H04M15/00 E

【請求項の数】20

【全頁数】77

(21)【出願番号】特願2011-548787(P2011-548787)

(86)(22)【出願日】2010年2月9日

(65)【公表番号】特表2012-517725(P2012-517725A)

(43)【公表日】2012年8月2日

(86)【国際出願番号】GB2010050202

(87)【国際公開番号】WO2010092378

(87)【国際公開日】20100819

【審査請求日】2012年9月20日

(31)【優先権主張番号】0902152.8

(32)【優先日】2009年2月10日

(33)【優先権主張国】GB

【前置審査】

(73)【特許権者】

【識別番号】502303739

【氏名又は名称】オラクル・インターナショナル・コーポレイション

(74)【代理人】

【識別番号】110001195

【氏名又は名称】特許業務法人深見特許事務所

(72)【発明者】

【氏名】クロス，ジェイソン

(72)【発明者】

【氏名】ウェストレイ，アレックス

【審査官】 松元 伸次

(56)【参考文献】

【文献】 特開２００８−０５４０７６（ＪＰ，Ａ）

【文献】 欧州特許出願公開第０１１９９８５２（ＥＰ，Ａ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｂ７／２４−７／２６

Ｈ０４Ｍ１／００

１／２４−３／００

３／１６−３／２０

３／３８−３／５８

７／００−７／１６

１１／００−１１／１０

１５／００−１５／３８

９９／００

Ｈ０４Ｗ４／００−８／２４

８／２６−１６／３２

２４／００−２８／００

２８／０２−７２／０２

７２／０４−７４／０２

７４／０４−７４／０６

７４／０８−８４／１０

８４／１２−８８／０６

８８／０８−９９／００

(57)【特許請求の範囲】

【請求項1】

電気通信ネットワークにおいて第１のユーザと第２のユーザとの間の電気通信リンクを提供する方法であって、
前記第２のユーザへの電気通信リンクを提供するようにとの前記第１のユーザからのリクエストを受信するステップと、
前記電気通信ネットワークとは独立の通信ネットワークを通じてユーザが相互作用するネットワーク化されたユーザコミュニティのホストをするサーバから、前記第１のユーザと前記第２のユーザとが指定された関係を前記ユーザコミュニティにおいて有するか否かを決定するステップと、
前記第１のユーザと前記第２のユーザとが指定された関係を前記ユーザコミュニティにおいて有するか否かに基づいて前記電気通信リンクに対する少なくとも１つの設定を指定するステップとを備え、
前記電気通信リンクに対する少なくとも１つの設定を指定するステップは、前記電気通信リンクに対する課金ポリシーを指定するステップを含み、
前記指定された関係は、
（ａ）あるグループに先に加入している一方のユーザが他方のユーザに対して当該グループへの参加を許可することで形成される関係、
（ｂ）一方のユーザが先に加入していたグループの管理者または管理者権限を有するユーザが、他方のユーザの当該グループへの参加を許可することで形成される関係、および、
（ｃ）一方のユーザが他方のユーザへ前記ユーザコミュニティにおける関係の確立を要請するとともに、前記他方のユーザが当該要請を承認することで形成される関係、
の少なくとも一方を含み、前記方法はさらに、
指定された関係を第３のユーザと前記ユーザコミュニティにおいて形成するようにとの前記第１のユーザからのリクエストを前記電気通信ネットワークを通じて受信するステップを備え、前記リクエストは、前記第３のユーザの識別子を含み、さらに
指定された関係の前記ユーザコミュニティにおける確立を要請する関係リクエストメッセージを前記サーバに送信するステップを備え、前記関係リクエストメッセージは、前記第１のユーザの識別子と、前記第３のユーザの識別子とを含む、方法。

【請求項2】

電気通信ネットワークにおいて第１のユーザと第２のユーザとの間の電気通信リンクを提供する方法であって、
前記第２のユーザへの電気通信リンクを提供するようにとの前記第１のユーザからのリクエストを受信するステップと、
前記電気通信ネットワークとは独立の通信ネットワークを通じてユーザが相互作用するネットワーク化されたユーザコミュニティのホストをするサーバから、前記第１のユーザと前記第２のユーザとが指定された関係を前記ユーザコミュニティにおいて有するか否かを決定するステップと、
前記第１のユーザと前記第２のユーザとが指定された関係を前記ユーザコミュニティにおいて有するか否かに基づいて前記電気通信リンクに対する少なくとも１つの設定を指定するステップと、
前記第１のユーザおよび前記第２のユーザの場所を特定するとともに、前記第１のユーザおよび前記第２のユーザが前記指定された関係に関連付けられたゾーンに存在するか否かに基づいて、前記電気通信リンクのために必要な最小限の支払額を決定するステップとを備え、
前記電気通信リンクに対する少なくとも１つの設定を指定するステップは、前記電気通信リンクに対する課金ポリシーを指定するステップを含み、
前記指定された関係は、
（ａ）あるグループに先に加入している一方のユーザが他方のユーザに対して当該グループへの参加を許可することで形成される関係、
（ｂ）一方のユーザが先に加入していたグループの管理者または管理者権限を有するユーザが、他方のユーザの当該グループへの参加を許可することで形成される関係、および、
（ｃ）一方のユーザが他方のユーザへ前記ユーザコミュニティにおける関係の確立を要請するとともに、前記他方のユーザが当該要請を承認することで形成される関係、
の少なくとも一方を含む、方法。

【請求項3】

電気通信ネットワークにおいて第１のユーザと第２のユーザとの間の電気通信リンクを提供する方法であって、
前記第２のユーザへの電気通信リンクを提供するようにとの前記第１のユーザからのリクエストを受信するステップと、
前記電気通信ネットワークとは独立の通信ネットワークを通じてユーザが相互作用するネットワーク化されたユーザコミュニティのホストをするサーバから、前記第１のユーザと前記第２のユーザとが指定された関係を前記ユーザコミュニティにおいて有するか否かを決定するステップと、
前記第１のユーザと前記第２のユーザとが指定された関係を前記ユーザコミュニティにおいて有するか否かに基づいて前記電気通信リンクに対する少なくとも１つの設定を指定するステップと、
データ記録を生成するステップとを備え、
前記電気通信リンクに対する少なくとも１つの設定を指定するステップは、前記電気通信リンクに対する課金ポリシーを指定するステップを含み、
前記指定された関係は、
（ａ）あるグループに先に加入している一方のユーザが他方のユーザに対して当該グループへの参加を許可することで形成される関係、
（ｂ）一方のユーザが先に加入していたグループの管理者または管理者権限を有するユーザが、他方のユーザの当該グループへの参加を許可することで形成される関係、および、
（ｃ）一方のユーザが他方のユーザへ前記ユーザコミュニティにおける関係の確立を要請するとともに、前記他方のユーザが当該要請を承認することで形成される関係、
の少なくとも一方を含み、
前記データ記録は、
前記電気通信ネットワークにおける前記第１のユーザおよび／または前記第２のユーザの識別子と、
前記電気通信ネットワークにおける前記第１のユーザおよび／または前記第２のユーザのネットワークプロバイダの識別子と、
前記第１のユーザと前記第２のユーザとの間で要請される電気通信リンクの種類の識別子と、
前記第１および第２のユーザが前記電気通信リンクを通じて接続される時間の長さの識別子と、
前記電気通信ネットワークのための前記電気通信リンクに起因すると考えられる値の識別子と、のうち少なくとも１つを含む、方法。

【請求項4】

前記生成されたデータ記録に基づいて、前記第１のユーザおよび前記第２のユーザが属するグループの各ユーザに対して、メッセージを送信するステップをさらに備える、請求項３に記載の方法。

【請求項5】

前記第１のユーザからの前記リクエストは、前記電気通信ネットワークにおける前記第２のユーザの携帯加入者ＩＳＤＮ番号（ＭＳＩＳＤＮ）識別子、前記電気通信ネットワークにおける前記第２のユーザへの接続のためのコールセットアップ接続リクエスト、前記電気通信ネットワークにおける前記第２のユーザへのメッセージの送信のためのメッセージ送信リクエストのうちのいずれかを含む、請求項１〜４のいずれか１項に記載の方法。

【請求項6】

前記ネットワーク化されたユーザコミュニティにおける２人のユーザ間の少なくとも１つの指定された関係を識別する情報を前記サーバから受信し、前記情報をキャッシュに格納するステップをさらに備える、請求項１〜５のいずれか１項に記載の方法。

【請求項7】

前記サーバから前記第１のユーザと前記第２のユーザとが指定された関係を有するか否かを決定するステップは、前記第１のユーザの識別子と前記第２のユーザの識別子とを含むリクエストを前記サーバに送信するステップを含む、請求項１〜６のいずれか１項に記載の方法。

【請求項8】

前記電気通信リンクは、メッセージ伝送路、音声リンク、データリンクのうちのいずれかを含む、請求項１〜７のいずれか１項に記載の方法。

【請求項9】

前記電気通信ネットワークとは独立の前記通信ネットワークは、インターネットワークを含む、請求項１〜８のいずれか１項に記載の方法。

【請求項10】

前記電気通信ネットワークとの通信を管理するためのアプリケーションを前記サーバに提供するステップをさらに備える、請求項１〜９のいずれか１項に記載の方法。

【請求項11】

前記ユーザコミュニティ中のユーザが前記ユーザコミュニティ中の他のユーザとの指定された関係を管理することを可能にするインターフェイスを提供するためのアプリケーションを前記サーバに提供するステップをさらに備える、請求項１〜１０のいずれか１項に記載の方法。

【請求項12】

前記電気通信リンクに対する少なくとも１つの設定を指定するステップは、
前記課金ポリシーを前記電気通信ネットワークにおけるネットワーク事業者に送信するステップを含む、請求項１〜１１のいずれか１項に記載の方法。

【請求項13】

前記第１のユーザと前記第２のユーザとが指定された関係を前記ユーザコミュニティにおいて有するか否かに基づいて前記電気通信リンクのために必要な最小限の支払額を決定するステップをさらに備える、請求項１〜１２のいずれか１項に記載の方法。

【請求項14】

第２のユーザへの接続を確立するようにとの第１のユーザからのリクエストを第１のネットワークにおいて受信するステップをさらに備え、前記リクエストは、前記第１のネットワークにおける前記第２のユーザの識別子を含み、
第２のネットワークにおける前記第２のユーザの識別子を検索するステップと、
前記第１および前記第２のユーザ間の接続を確立するステップとをさらに備え、前記接続は、少なくとも部分的に前記第２のネットワークを通じて確立される、請求項１〜１３のいずれか１項に記載の方法。

【請求項15】

電気通信ネットワークのユーザ間の通信相互作用をソーシャルネットワーキングサービスコミュニティにおいてユーザ間で定義された関係に従って処理する方法であって、
前記電気通信ネットワークの第１および第２のユーザ間の前記電気通信ネットワークを介した電気通信相互作用を処理するステップと、
前記第１および第２のユーザ間の前記ソーシャルネットワーキングサービスコミュニティにおける関係に関するソーシャルネットワーキング関係データを受信するステップと、
前記ソーシャルネットワーキング関係データが指定された関係を示す場合に、前記電気通信相互作用に関する処理を行なうステップとを備え、
前記電気通信相互作用に関する処理を行なうステップは、前記ソーシャルネットワーキング関係データに依存して電気通信リンクに対する課金ポリシーを指定するステップを含み、
前記指定された関係は、
（ａ）あるグループに先に加入している一方のユーザが他方のユーザに対して当該グループへの参加を許可することで形成される関係、
（ｂ）一方のユーザが先に加入していたグループの管理者または管理者権限を有するユーザが、他方のユーザの当該グループへの参加を許可することで形成される関係、および、
（ｃ）一方のユーザが他方のユーザへソーシャルネットワーキングサービスコミュニティにおける関係の確立を要請するとともに、前記他方のユーザが当該要請を承認することで形成される関係、
の少なくとも一方を含み、前記方法はさらに、
指定された関係を第３のユーザと前記ソーシャルネットワーキングサービスコミュニティにおいて形成するようにとの前記第１のユーザからのリクエストを受信するステップと、前記リクエストは、前記第３のユーザの識別子を含み、さらに
指定された関係の前記ソーシャルネットワーキングサービスコミュニティにおける確立を要請する関係リクエストメッセージの送信に係る電気通信相互作用を処理するステップを備え、前記関係リクエストメッセージは、前記第１のユーザの識別子と、前記第３のユーザの識別子とを含む、方法。

【請求項16】

電気通信ネットワークにおいて第１のユーザと第２のユーザとの間の電気通信リンクを提供するための装置であって、
前記第２のユーザへの電気通信リンクを提供するようにとの前記第１のユーザからのリクエストを受信するための手段と、
前記電気通信ネットワークとは独立の通信ネットワークを通じてユーザが相互作用するネットワーク化されたユーザコミュニティのホストをするサーバから、前記第１のユーザと前記第２のユーザとが指定された関係を前記ユーザコミュニティにおいて有するか否かを決定するための手段と、
前記第１のユーザと前記第２のユーザとが指定された関係を前記ユーザコミュニティにおいて有するか否かに基づいて前記電気通信リンクに対する少なくとも１つの設定を指定するための手段とを備え、
前記電気通信リンクに対する少なくとも１つの設定を指定する手段は、前記電気通信リンクに対する課金ポリシーを指定し、
前記指定された関係は、
（ａ）あるグループに先に加入している一方のユーザが他方のユーザに対して当該グループへの参加を許可することで形成される関係、
（ｂ）一方のユーザが先に加入していたグループの管理者または管理者権限を有するユーザが、他方のユーザの当該グループへの参加を許可することで形成される関係、および、
（ｃ）一方のユーザが他方のユーザへ前記ユーザコミュニティにおける関係の確立を要請するとともに、前記他方のユーザが当該要請を承認することで形成される関係、
の少なくとも一方を含み、前記装置はさらに、
指定された関係を第３のユーザと前記ユーザコミュニティにおいて形成するようにとの前記第１のユーザからのリクエストを前記電気通信ネットワークを通じて受信するための手段を備え、前記リクエストは、前記第３のユーザの識別子を含み、さらに
指定された関係の前記ユーザコミュニティにおける確立を要請する関係リクエストメッセージを前記サーバに送信するための手段を備え、前記関係リクエストメッセージは、前記第１のユーザの識別子と、前記第３のユーザの識別子とを含む、装置。

【請求項17】

電気通信ネットワークにおいて第１のユーザと第２のユーザとの間の電気通信リンクを提供するための装置であって、
前記第２のユーザへの電気通信リンクを提供するようにとの前記第１のユーザからのリクエストを受信するための入力インターフェイスと、
前記電気通信ネットワークとは独立の通信ネットワークを通じてユーザが相互作用するネットワーク化されたユーザコミュニティのホストをするサーバから、前記第１のユーザと前記第２のユーザとが指定された関係を前記ユーザコミュニティにおいて有するか否かを決定するよう動作可能なプロセッサと、
前記第１のユーザと前記第２のユーザとが指定された関係を前記ユーザコミュニティに
おいて有するか否かに基づいて前記電気通信リンクに対する少なくとも１つの設定を指定するよう動作可能なプロセッサとを備え、
前記プロセッサは、前記電気通信リンクに対する課金ポリシーを指定し、
前記関係は、
（ａ）あるグループに先に加入している一方のユーザが他方のユーザに対して当該グループへの参加を許可することで形成される関係、
（ｂ）一方のユーザが先に加入していたグループの管理者または管理者権限を有するユーザが、他方のユーザの当該グループへの参加を許可することで形成される関係、および、
（ｃ）一方のユーザが他方のユーザへ前記ユーザコミュニティにおける関係の確立を要請するとともに、前記他方のユーザが当該要請を承認することで形成される関係、
の少なくとも一方を含み、前記装置はさらに、
指定された関係を第３のユーザと前記ユーザコミュニティにおいて形成するようにとの前記第１のユーザからのリクエストを前記電気通信ネットワークを通じて受信するよう動作可能なプロセッサを備え、前記リクエストは、前記第３のユーザの識別子を含み、さらに
指定された関係の前記ユーザコミュニティにおける確立を要請する関係リクエストメッセージを前記サーバに送信するよう動作可能なプロセッサを備え、前記関係リクエストメッセージは、前記第１のユーザの識別子と、前記第３のユーザの識別子とを含む、装置。

【請求項18】

電気通信ネットワークのユーザ間の通信相互作用をソーシャルネットワーキングサービスコミュニティにおいてユーザ間で定義された関係に従って処理するためのシステムであって、
前記電気通信ネットワークの第１および第２のユーザ間の前記電気通信ネットワークを介した電気通信相互作用を処理するための手段と、
前記第１および第２のユーザ間の前記ソーシャルネットワーキングサービスコミュニティにおける関係に関するソーシャルネットワーキング関係データを受信するための手段と、
前記ソーシャルネットワーキング関係データが指定された関係を示す場合に、前記電気通信相互作用に関する処理を行なうための手段とを備え、
前記電気通信相互作用に関する処理を行なう手段は、前記ソーシャルネットワーキング関係データに依存して電気通信リンクに対する課金ポリシーを指定し、
前記指定された関係は、
（ａ）あるグループに先に加入している一方のユーザが他方のユーザに対して当該グループへの参加を許可することで形成される関係、
（ｂ）一方のユーザが先に加入していたグループの管理者または管理者権限を有するユーザが、他方のユーザの当該グループへの参加を許可することで形成される関係、および、
（ｃ）一方のユーザが他方のユーザへソーシャルネットワーキングサービスコミュニティにおける関係の確立を要請するとともに、前記他方のユーザが当該要請を承認することで形成される関係、
の少なくとも一方を含み、前記システムはさらに、
指定された関係を第３のユーザと前記ソーシャルネットワーキングサービスコミュニティにおいて形成するようにとの前記第１のユーザからのリクエストを受信するための手段を備え、前記リクエストは、前記第３のユーザの識別子を含み、さらに
指定された関係の前記ソーシャルネットワーキングサービスコミュニティにおける確立を要請する関係リクエストメッセージの送信に係る電気通信相互作用を処理するための手段とを備え、前記関係リクエストメッセージは、前記第１のユーザの識別子と、前記第３のユーザの識別子とを含む、システム。

【請求項19】

請求項１〜１６のいずれか１項に記載の方法を実現化するための命令を含む、コンピュータプログラム。

【請求項20】

少なくとも１つのメモリと、少なくとも１つのインターフェイスと、請求項１〜１６のいずれか１項に記載の方法を実現化するよう動作可能なプロセッサとを備える、ネットワーク装置。

【発明の詳細な説明】

【技術分野】

【0001】

この発明は、１つのネットワークにおけるまたは複数のネットワークにわたるユーザ間の接続を管理することの分野に関し、特に、この発明は、その後第２のネットワークにおいて利用することができる第１のネットワークにおける接続を管理することに関する。

【背景技術】

【0002】

ユーザは、複数の異なるチャネルを介しておよび異なる種類のネットワークを通じて友達および連絡先と接続する。これらのチャネルの中には、ユーザが、接続されたユーザ間の相互作用の取扱いが接続されていないユーザ間のものとは異なるように、他のユーザへの接続のネットワークをセットアップすることができるものもある。しかしながら、すべてのネットワークがこの機能性を提供するわけではなく、ユーザにとって、彼のネットワーク接続を異なるチャネルのすべてにわたって再現することは、時間がかかりかつ困難なことであるおそれがある。

【0003】

たとえユーザが彼の連絡先の各々にさまざまな異なるネットワークを通じて接続するために必要な時間と投資を投入したとしても、確立された接続は、片方向のみの接続である。彼の連絡先の各々も、発起側ユーザに戻る別個の接続を設定しなくてはならない。

【発明の概要】

【発明が解決しようとする課題】

【0004】

この問題は、同じネットワーク上の友達に友達リンクがセットアップされている場合に割引料金が利用できる可能性があり得る携帯電話ネットワークにおいて、特に重大である。しかしながら、自分の友達のうち誰が同じネットワーク上にいるのかを知ることが非常に難しい。したがって友達リンクの設定が役に立ち得る。友達を割引料金のために登録することも時間がかかる。ユーザは彼らのサービスプロバイダを変更するので、この登録リストを最新のものに保つことは難しい。

【0005】

同時に、ネットワークプロバイダは、コールデータ記録を用いて、彼ら自身のユーザに関する情報にアクセスすることができる。しかしながら、これらのユーザは、競合するネットワークプロバイダに加入しているオフネットワークの他のユーザと連絡を取るものの、ホームネットワークプロバイダにとって、オフネットワークユーザに関する如何なるデータを集めるまたはアクセスすることも非常に難しい。特に、ネットワークプロバイダにとって、対象を絞ったやり方でオフネットユーザを識別するまたはオフネットユーザに連絡を取ることは難しい。

【課題を解決するための手段】

【0006】

１つの局面に従って、電気通信ネットワークにおける第１のユーザと第２のユーザとの間の電気通信リンクを提供する方法が提供され、上記方法は、上記第２のユーザへの電気通信リンクを提供するようにとのリクエストを上記第１のユーザから受信するステップと、上記電気通信ネットワークとは独立の通信ネットワークを通じてユーザが相互作用するネットワーク化されたユーザコミュニティのホストをするサーバから、上記第１のユーザと上記第２のユーザとが上記ユーザコミュニティにおいて指定された関係を有するか否かを決定するステップと、上記第１のユーザと上記第２のユーザとが指定された関係を上記ユーザコミュニティにおいて有するか否かに基づいて上記電気通信リンクに対する少なくとも１つの設定、パラメータまたは特性を指定するステップとを含む。

【0007】

ネットワーク化されたユーザコミュニティは、ソーシャルネットワーキングサービスによって管理されるソーシャルネットワーキングコミュニティの形態であってもよく、好ましくは、このコミュニティにおいてユーザは、ソーシャルネットワーキングウェブサイトまたはソーシャルネットワーキングクライアントソフトウェアをたとえば含めて１つ以上のソーシャルネットワーキングインターフェイスを介して相互作用し、通信し、関係を指定する。ソーシャルネットワーキングサービスは、好ましくは、電気通信ネットワークとは別個かつ独立の通信チャネル（たとえばインターネット）を介したユーザ間の相互作用および通信を可能にするおよび／またはユーザが加入している如何なる電気通信サービスとも独立の相互作用および通信を可能にする。電気通信リンクという用語は、好ましくは、音声およびビデオコールおよびメッセージング（たとえばＳＭＳ／ＭＭＳ）などを含めてユーザ間の任意の種類の電気通信相互作用を包含する。

【0008】

有利には、コミュニティにおいて既に形成され、通信ネットワークがホストである指定された関係を電気通信ネットワークにおいて適用し、そのネットワークにおける設定を変化させるために用いることができる。したがって、これらの関係が既に第１の通信ネットワークに既に存在する場合、ユーザは、電気通信ネットワークにおいて同じユーザとの別個の関係をセットアップする必要がない。その代わり、この方法は、単に通信ネットワークに基づく既存の接続を用いることができる。

【0009】

好ましくは、上記第１のユーザからの上記リクエストは、上記電気通信ネットワークにおける上記第２のユーザのＭＳＩＳＤＮ（Mobile Subscriber Integrated Services Digital Network Number：携帯加入者統合サービスデジタルネットワーク番号）識別子を含む。

【0010】

１つの実施例において、上記第１のユーザからの上記リクエストは、上記電気通信ネットワークにおける上記第２のユーザへの接続のためのコールセットアップ接続リクエストを含む。つまり、電気通信ネットワークにおいて通常の方法で第１のユーザが第２のユーザにコールすると、リンクを提供するようにとのリクエストが黙示的に提供されてもよい。このコールは、音声、ビデオおよび／またはデータコールであってもよい。

【0011】

１つの実施例において、上記第１のユーザからのリクエストは、上記電気通信ネットワークにおける上記第２のユーザへのメッセージの送信のためのメッセージ送信リクエストを含む。たとえば、第１のユーザは、第２のユーザへの送信のためにＳＭＳを電気通信ネットワークに投稿してもよい。これは、少なくとも、電気通信ネットワークにおける電気通信リンクの黙示的なリクエストである。

【0012】

非常に好ましい実施例において、上記電気通信リンクに対する少なくとも１つの設定を指定するステップは、上記電気通信リンクに対する課金ポリシーを指定するステップを含む。

【0013】

好ましくは、ユーザコミュニティにおける指定された関係は、双方向関係である。つまり、ユーザ同士がコミュニティにおいて「友達」である場合、第１のユーザは、第２のユーザと関係を有し、第２のユーザは、等価かつ逆の関係を第１のユーザと有する。したがって、システムは、双方向関係を自動的にセットアップすることができ、そのため一方のユーザしか通信ネットワークにおいて関係を作る必要がないがいずれかのユーザが電気通信リンクを要請すると両者が特典を受ける。

【0014】

好ましい実施例において、上記方法は、上記ネットワーク化されたユーザコミュニティにおける２人のユーザ間の少なくとも１つの指定された関係を識別する情報を上記サーバから受信し、上記情報をキャッシュに格納するステップをさらに含む。サーバは、好ましくは、上記通信ネットワークにおいて関係が形成されるにつれ周期的な更新情報を送信する。これらを電気通信ネットワーク中のローカルデータベースに記憶することができる。したがって、ローカルデータベースは、通信ネットワークにおいて作成された関係をミラーリングする記憶装置を有する。

【0015】

好ましくは、上記の第１のユーザと上記第２のユーザとが指定された関係を有するか否かサーバから決定するステップは、少なくとも１つの指定された関係に関する情報をキャッシュから検索するステップを含む。電気通信ネットワークにおける接続を行なう前に各関係を検証するには、外部サーバへのコールに頼るよりもキャッシュにローカルに記憶された情報を探索する方がより速くより効率的である。

【0016】

これに代えて、サーバから上記第１のユーザと上記第２のユーザとが指定された関係を有するか否かを決定するステップは、上記第１のユーザの識別子と上記第２のユーザの識別子とを含むリクエストを上記サーバに送信するステップを含んでもよい。つまり、情報は、通信ネットワーク中のネットワーク化されたコミュニティから取得されてもよい。これにより、電気通信ネットワークにおいて接続が形成される前に、ユーザコミュニティにおける関係に関する情報が最新のものであることが確実になってもよい。このステップを、関係をキャッシュ中で照合するという前の特徴に付加して用いてもよい。たとえば、関係がキャッシュ中に見つからない場合、サーバに直接問合せして、関係がユーザコミュニティにおいて存在しないことを照合してもよい。

【0017】

好ましくは、指定された関係があるか否かを決定するステップおよび少なくとも１つの設定を選択するステップは、電気通信リンクが第１および第２のユーザ間に形成される前に行なわれる。しかしながら、代替的な実施例においては、まず電気通信リンクを形成し、関係を照合し、それに従って設定を後の段階で決定する。これは、それによりユーザ間のリンクの初期セットアップの遅延が最小化されるため、たとえば課金料率を電気通信リンクのセットアップ後に計算することができる場合に役立ってもよい。たとえば、デフォルトで、ユーザは、電気通信リンクに対して満額の料率で課金されてもよく、ユーザ間に関係が見つかった場合、課金料率に対する調節は、一旦リンクが形成されてから適用されてもよい。もう１つの変化例において、たとえば課金計算をコール記録に基づいてオフラインで行う場合、関係を照合し、電気通信リンクの完了／終了後（たとえばコールの終了後またはテキストメッセージが届けられた後）設定を決定してもよい。よって、用語「設定」は、アクティブな通信リンクの動作的特性に限定されるものではなく、リンク中であれまたはその後であれ、リンクを処理する際に用いられる任意のパラメータまたは特性を包含する。

【0018】

１つの実施例において、上記電気通信リンクは、たとえばＳＭＳまたはＭＭＳメッセージのための、メッセージ伝送路を含む。これに代えて、上記電気通信リンクは、たとえば電話での会話のための、音声またはデータリンクを含んでもよい。

【0019】

好ましくは、上記通信ネットワークは、インターネットワーク、特にインターネットなどのパケット交換方式のネットワークを含む。特に、ユーザは、ソーシャルネットワーキングウェブサイト上にたとえばあるウェブインターフェイスを介してユーザコミュニティにアクセスしてもよい。電気通信ネットワークは、好ましくは、たとえばＧＰＲＳ、ＣＤＭＡ、３ＧまたはＷｉ−Ｆｉネットワークのような移動体電気通信ネットワークを少なくとも部分的に含む。

【0020】

上記方法は、好ましくは、接続を第３のユーザと上記ユーザコミュニティにおいて形成するようにとの上記第１のユーザからのリクエストを上記電気通信ネットワークを通じて受信するステップをさらに含み、上記リクエストは、上記第３のユーザの識別子を含み、上記方法は、指定された関係の上記ユーザコミュニティにおける確立を要請する関係リクエストメッセージを上記サーバに送信するステップをさらに含み、上記関係リクエストメッセージは、上記第１のユーザの識別子と、上記第３のユーザの識別子とを含む。よって、このシステムは、ユーザコミュニティにおけるユーザ間の関係を電気通信ネットワークを通じて確立することを可能にする。このリクエストは、第１のユーザからネットワーク事業者が指定するショートコードに送信されるＳＭＳメッセージの形態を取ってもよく、好ましくは、このショートコードは、関係リクエストのために確保されている。

【0021】

好ましくは、上記第１のユーザの上記識別子および上記第３のユーザの上記識別子は、上記電気通信ネットワークにおける識別子、特にユーザの携帯加入者ＩＳＤＮ番号（ＭＳＩＳＤＮ）を含む。これらの番号を、ネットワーク化されたユーザコミュニティのホストをするサーバに、たとえばコミュニティにおける第１および第３のユーザの識別のために渡してもよい。

【0022】

これに代えてまたはこれに加えて、上記第１のユーザの上記識別子および上記第３のユーザの上記識別子は、上記ユーザコミュニティにおける識別子を含んでもよい。これらの識別子をコミュニティのサーバに渡すことができ、この２人のユーザのＭＳＩＳＤＮ番号がコミュニティ中の記憶されたデータにおいて利用可能である場合、それらを電気通信ネットワークに返信することができる。

【0023】

非常に好ましい実施例において、上記方法は、上記電気通信ネットワークとの通信を管理するためのアプリケーションを上記サーバに提供するステップをさらに含む。この管理は、サーバと電気通信ネットワークとの間の通信インターフェイスを設けることを含むことができる。このアプリケーションを用いて、コミュニティ中に形成された関係に関する更新情報を電気通信ネットワーク中のキャッシュに提供し、電気通信ネットワークから受信される関係リクエストを処理することもできる。

【0024】

１つの実施例において、上記方法は、指定された関係を第３のユーザと上記ユーザコミュニティにおいて形成するようにとの第１のユーザからのリクエストを上記アプリケーションで受信するステップをさらに備え、上記リクエストは、上記第３のユーザの識別子を含み、上記方法は、上記第１のユーザの識別子と上記第３のユーザの上記識別子とを上記ユーザコミュニティにおける指定された関係として記憶するステップとをさらに含む。上記リクエストは、上記第１の通信ネットワークからたとえばウェブインターフェイスを介して受信されてもよく、または上記電気通信ネットワークからたとえばＳＭＳまたはＭＭＳメッセージの形態で受信されてもよい。上記第１のユーザの上記識別子および上記第３のユーザの上記識別子は、上記電気通信ネットワークにおける上記ユーザの識別子、たとえばＭＳＩＳＤＮを含んでもよく、または上記ユーザコミュニティにおける上記ユーザの識別子、たとえば上記コミュニティにおけるユーザ名を含んでもよい。

【0025】

好ましくは、上記方法は、上記ユーザコミュニティ中のユーザが上記コミュニティ中の他のユーザとの指定された関係を管理することを可能にするインターフェイスを提供するためのアプリケーションを上記サーバに提供するステップをさらに含む。このインターフェイスは、ウェブベースのインターフェイスであってもよい。コミュニティは、ユーザがコミュニティ内で関係を管理し通信することを可能にするインターフェイスを既に有していてもよい。したがって、この付加的なアプリケーションは、そのインターフェイスに付加的な、たとえば、ＭＳＩＳＤＮをコミュニティにおけるユーザネームと結び付け（またはそれらを既存のユーザプロフィールから抽出し）、新しい関係の詳細および関係更新情報を電気通信ネットワークに送信するような機能性を単に付加してもよい。

【0026】

１つの実施例において、上記方法は、ユーザからの登録リクエストを上記アプリケーションで受信するステップを含み、上記登録リクエストは、上記電気通信ネットワークにおける上記ユーザの識別子と、上記ユーザコミュニティにおける上記ユーザの識別子とを含み、上記方法は、各上記識別子を、登録済ユーザのデータベースに記憶するステップを含む。そのような登録リクエストは、ユーザがサービスに参加し、かつ彼らの指定された関係を電気通信ネットワークにおいて使用し始めるために必要であってもよい。登録プロセスの一部として、ユーザの名前、ＭＳＩＳＤＮおよびコミュニティにおける既存の関係などのユーザの詳細をアプリケーションに記憶し、電気通信ネットワークに任意選択的に送信してもよい。

【0027】

１つの実施例において、上記方法は、ユーザグループの識別子を上記アプリケーションで受信するステップと、上記グループ識別子を上記グループのメンバーである少なくとも１人のユーザの識別子とともに記憶するステップとをさらに含む。この実施例において、上記サーバからの応答は、上記第１のユーザおよび上記第２のユーザが同じ上記ユーザグループのメンバーであるか否かを示す。上記方法は、グループ管理者が上記グループのメンバー構成を制御することを可能にするインターフェイスを提供するステップも含んでもよい。

【0028】

この実施例において、好ましくは、上記第１および第２のユーザが上記ユーザグループのメンバーである場合、上記電気通信リンクに対する支払いは、第１の支払口座から要請され、上記第１および第２のユーザが上記ユーザグループのメンバーではない場合、上記電気通信リンクに対する支払いは、第２の支払口座から要請されされる。このようにして、グループ口座が維持されてもよく、グループのメンバー間の如何なる通信もグループ口座に課金されるが、グループメンバーからグループ外の別のユーザへの如何なる通信もユーザ自身の口座に課金される。これは、たとえば特定のユーザからのコールのなかには会社の口座に課金されるものがあることを可能にするが、その会社グループの一員ではない友達へのコールは自動的にユーザの個人口座に課金されるようにするのに特に有用であってもよい。これにより、ユーザが同じ電気通信装置から個人的なコールを行うことを可能にしたまま、企業口座の管理が容易になってもよい。

【0029】

好ましくは、上記電気通信リンクに対する少なくとも１つの設定を指定するステップは、上記電気通信リンクに対する課金ポリシーを選択するステップと、上記課金ポリシーを上記電気通信ネットワークにおけるネットワーク事業者に送信するステップとを含む。課金ポリシーは、リンクに対する１分当たりの課金料率を含んでもよく、これは、ゼロ以上であってもよい。または課金ポリシーは、たとえばＳＭＳまたはＭＭＳメッセージの送信に対する固定請求のような、リンクに対する固定の１回限りの請求を含んでもよい。課金ポリシーは、請求が適用されるべき口座の識別子も含んでもよい。

【0030】

好ましくは、上記課金ポリシーをネットワーク事業者に送信するステップは、上記課金ポリシーを上記電気通信ネットワーク中の課金サーバに送信するステップを含む。次に課金サーバは、関連する請求を適切な口座に適用することができる。

【0031】

好ましくは、上記方法は、上記第１のユーザと上記第２のユーザとが指定された関係を上記ユーザコミュニティにおいて有するか否かに基づいて上記電気通信リンクのために必要な最小限の支払額を決定するステップをさらに含む。この最小限の支払額は、ユーザが指定された関係を有しかつユーザ間のリンク（たとえばＳＭＳメッセージ）に対する請求がゼロである場合、ゼロであってもよい。しかしながら、コミュニケーションリンクが確立されることを可能にするにはユーザ口座に最小限の額のクレジットがあることが必要である可能性がより高い。

【0032】

好ましくは、上記方法は、上記第１のユーザと関連付けられたユーザ口座からの前払いが必要であるか否かと、上記ユーザ口座において最小限の支払額が支払い可能か否かとを決定するステップと、上記最小限の支払額が上記ユーザ口座において支払い可能であるか否かに基づいて上記電気通信リンクが許可されるかまたは拒否されるかを示すメッセージを生成するステップとをさらに含む。前払いが要求されない場合である後払い（すなわち契約）ユーザに対しては、ユーザに対するクレジット照合なしに通信リンクを確立してもよく、電気通信リンクは、自動的に許可されてもよい。

【0033】

上記方法は、好ましくは、データ記録を生成するステップをさらに含み、上記データ記録は、上記電気通信ネットワークにおける上記第１のユーザおよび／または上記第２のユーザの識別子（たとえばユーザのＭＳＩＳＤＮ）と、上記電気通信ネットワークにおける上記第１のユーザおよび／または上記第２のユーザのネットワークプロバイダの識別子と、上記第１のユーザと上記第２のユーザとの間で要請される電気通信リンクの種類（たとえばＳＭＳ、ＭＭＳ、音声またはデータリンク）の識別子と、上記第１および第２のユーザが上記電気通信リンクを通じて接続される時間の長さの識別子と、上記電気通信ネットワークのための上記電気通信リンクに起因すると考えられる値（たとえば、通信リンクの合計請求額または接続の際用いられた「単位」の数）の識別子とのうち少なくとも１つを含む。

【0034】

好ましくは、上記方法は、選択されたネットワークプロバイダと関連付けられていない少なくとも１人のユーザを識別するために複数のデータ記録を分析するステップをさらに含む。つまり、一つのネットワークプロバイダは、他のネットワークプロバイダに属しているユーザについての情報を要請してもよい。この情報は、指定された時間内にそれらのユーザへなされたすべての通信リンクの数または値を含んでもよい。ネットワークは、それらのユーザの識別子も取得してもよい。これにより、ネットワークプロバイダが彼らのネットワークには登録されていないユーザに関する情報、特に利用情報を集めることが可能になってもよい。これにより、プロバイダが広告およびオファーの対象を特定のユーザに絞って、彼らがネットワークを切替えてプロバイダ自身のネットワークに参加するよう促すことが可能になってもよい。たとえば、プロバイダは、多くの「友達」または関係をこのサービスプロバイダのネットワークに有するオフネットユーザに連絡を取って、このユーザがネットワークを切替えることによって節約し得ることを強調することによって、広告の対象をこのユーザに絞り込んでもよい。

【0035】

利用情報の同様な分析は、既にサービスプロバイダのネットワークの一員である顧客に対しても有用であってもよい。特に、多くのテキストメッセージングを行なうユーザは、大きなテキストメッセージバンドル（bundle）を含む契約の広告の対象として絞り込まれてもよい。

【0036】

上記方法は、第２のユーザへの接続を確立するようにとの第１のユーザからのリクエストを第１のネットワークにおいて受信するステップを含んでもよく、上記リクエストは、上記第１のネットワークにおける上記第２のユーザの識別子を含み、上記方法は、第２のネットワークにおける上記第２のユーザの識別子を検索するステップと、上記第１および上記第２のユーザ間の接続を確立するステップとを含んでもよく、上記接続は、少なくとも部分的に上記第２のネットワークを通じて確立される。好ましくは、上記方法は、上記第２のネットワークにおける上記第１のユーザの識別子を検索し、上記第１のユーザと上記第２のユーザとの間の接続を上記第２のネットワークにおいて確立するステップを含む。上記第２のネットワークにおける上記識別子は、上記第２のネットワークにおける上記ユーザのＭＳＩＳＤＮ番号を含んでもよい。上記第１のユーザからの上記リクエストは、好ましくは、上記第１のネットワークにおいて上記第２のユーザと関連付けられた識別子の、複数のアイコンまたはユーザ識別子のリストからの選択と、上記第１のネットワークにおける上記第２のユーザの識別子の受信とのうち少なくとも一方を含む。

【0037】

もう１つの局面において、この発明は、電気通信ネットワークにおいて第１のユーザと第２のユーザとの間の電気通信リンクを提供するための装置またはシステムを提供し、上記装置またはシステムは、上記第２のユーザへの電気通信リンクを提供するようにとの上記第１のユーザからのリクエストを受信するための手段と、上記電気通信ネットワークとは独立の通信ネットワークを通じてユーザが相互作用するネットワーク化されたユーザコミュニティのホストをするサーバから、上記第１のユーザと上記第２のユーザとが指定された関係を上記ユーザコミュニティにおいて有するか否かを決定するための手段と、上記第１のユーザと上記第２のユーザとが指定された関係を上記ユーザコミュニティにおいて有するか否かに基づいて上記電気通信リンクに対する少なくとも１つの設定、パラメータ、または特性を指定するための手段とを含む。

【0038】

この発明は、さらに、電気通信ネットワークにおいて第１のユーザと第２のユーザとの間の電気通信リンクを提供するための装置またはシステムを提供し、上記装置またはシステムは、上記第２のユーザへの電気通信リンクを提供するようにとの上記第１のユーザからのリクエストを受信するための入力インターフェイスと、上記電気通信ネットワークとは独立の通信ネットワークを通じてユーザが相互作用するネットワーク化されたユーザコミュニティのホストをするサーバから、上記第１のユーザと上記第２のユーザとが指定された関係を上記ユーザコミュニティにおいて有するか否かを決定するよう動作可能なプロセッサと、上記第１のユーザと上記第２のユーザとが指定された関係を上記ユーザコミュニティにおいて有するか否かに基づいて上記電気通信リンクに対する少なくとも１つの設定、パラメータまたは特性を指定するように動作可能なプロセッサとを含む。

【0039】

もう１つの局面に従って、通信ネットワークを通じてユーザが相互作用するネットワーク化されたユーザコミュニティにおけるユーザ間の接続を管理する方法が提供され、上記相互作用は、特定のユーザ間の指定された関係を上記ユーザコミュニティにおいて形成することを含み、上記方法は、上記ユーザコミュニティにおいて第１のユーザと第２のユーザとの間に形成された新しい指定された関係の通知を受信するステップと、上記通信ネットワークとは別個の電気通信ネットワークにおける上記第１および第２のユーザの各々の識別子を決定するステップと、上記電気通信ネットワークにおける上記第１および第２のユーザのうち少なくとも一方のサービスプロバイダを識別するステップと、上記第１および第２のユーザを識別し、かつ指定された関係の上記第１および第２のユーザ間での形成を示す情報を少なくとも１つの識別されたサービスプロバイダに送信するステップとを含む。

【0040】

この方法は、通信ネットワーク内で、たとえば通信ネットワーク中のサーバで、動作しているアプリケーションによって実現化されてもよい。サーバは、少なくとも１つのインターフェイスを有し、サーバは、このインターフェイスを介して電気通信ネットワークに接続することができ、この方法は、インターフェイスを提供するステップをさらに含んでもよい。この実施例は、システムがコミュニティ内で形成された新しい関係を電気通信ネットワークに通知することを可能にすることが理解されるであろう。次に、電気通信ネットワークは、この情報をキャッシュに記憶し、この情報を効率的に用いて電気通信ネットワーク中のリンクを管理することができる。

【0041】

もう１つの局面に従って、通信ネットワークを通じてユーザが相互作用するネットワーク化されたユーザコミュニティにおけるユーザ間の接続を管理する方法が提供され、上記相互作用は、特定のユーザ間の指定された関係を上記ユーザコミュニティにおいて形成することを含み、上記方法は、ユーザ間の直接の電気通信リンクを提供するために上記通信ネットワークとは別個の電気通信ネットワークへのインターフェイスを提供するステップと、第１および第２のユーザ間の要請される通信リンクを識別する問合せを上記電気通信ネットワークから受信するステップと、上記問合せから上記第１および第２のユーザの識別子を抽出するステップと、指定された関係が上記第１および第２のユーザ間に上記ユーザコミュニティにおいて存在するか否かを決定するために上記第１および第２のユーザの識別子を分析するステップと、指定された関係が上記第１および第２のユーザ間に上記ユーザコミュニティにおいて存在するか否かを示す返信メッセージを上記電気通信ネットワークに送信するステップとを含む。

【0042】

この局面において、アプリケーションがサーバに提供され、指定された関係が２人の当事者間に存在するか否か決定するようにとの電気通信ネットワークからのリクエストにリアルタイムで応答してもよい。これを用いて、通信リンクが電気通信ネットワークにおいて形成されるときに最新の情報が用いられることを確実にすることができる。

【0043】

この発明のもう１つの局面において、電気通信ネットワークのユーザ間の通信相互作用をソーシャルネットワーキングサービスコミュニティにおいてユーザ間で定義された関係に従って処理する方法が提供され、上記方法は、上記電気通信ネットワークの第１および第２のユーザ間の上記電気通信ネットワークを介した電気通信相互作用を処理するステップと、上記第１および第２のユーザ間の上記ソーシャルネットワーキングサービスコミュニティにおける関係（定義済み）に関するソーシャルネットワーキング関係データを受信するステップと、上記電気通信相互作用に関する処理を上記ソーシャルネットワーキング関係データに依存して行なうステップとを含む。

【0044】

電気通信相互作用は、たとえば、音声もしくはビデオコールまたはテキストもしくは画像メッセージであってもよい。ソーシャルネットワーキングサービスコミュニティは、１つ以上のサーバによって管理されていてもよい。関係データを受信するステップは、ソーシャルネットワーキングサービスと関連付けられたサーバからのデータを要請するステップを含んでもよく、またはデータは、本明細書中の他の箇所に説明されるような関係データのキャッシュから受信されてもよい。電気通信相互作用に関する処理は、相互作用に対するコール費用を決定するなどの課金関連処理を含んでいてもよい（またはこれに代えて、電気通信相互作用自体の取扱いに関していてもよい）。関係データは、ソーシャルネットワーキングコミュニティにおいて、ある関係がユーザ間で定義されていることを指定していてもよく、または１つ以上の関係がユーザ間で定義されていることを指定していてもよく、またはユーザ間に定義された関係がないことを指定してもよい。この方法の局面は、本明細書中に記載される他の方法の局面および特徴と組合されてもよい。

【0045】

さらなる局面において、通信ネットワークを通じてユーザが相互作用するネットワーク化されたユーザコミュニティにおけるユーザ間の接続を管理するための装置またはシステムが提供され、上記相互作用は、特定のユーザ間の指定された関係を上記ユーザコミュニティにおいて形成することを含み、上記装置またはシステムは、上記ユーザコミュニティにおいて第１のユーザと第２のユーザとの間に形成された新しい指定された関係の通知を受信するための手段と、上記通信ネットワークとは別個の電気通信ネットワークにおける上記第１および第２のユーザの各々の識別子を決定するための手段と、上記電気通信ネットワークにおける上記第１および第２のユーザのうち少なくとも一方のサービスプロバイダを識別するための手段と、上記第１および第２のユーザを識別し、かつ指定された関係の上記第１および第２のユーザ間での形成を示す情報を少なくとも１つの識別されたサービスプロバイダに送信するための手段とを含む。

【0046】

もう１つの局面において、通信ネットワークを通じてユーザが相互作用するネットワーク化されたユーザコミュニティにおけるユーザ間の接続を管理するための装置またはシステムが提供され、上記相互作用は、特定のユーザ間の指定された関係を上記ユーザコミュニティにおいて形成することを含み、上記装置またはシステムは、ユーザ間の直接の電気通信リンクを提供するために上記通信ネットワークとは別個の電気通信ネットワークへのインターフェイスを提供するための手段と、第１および第２のユーザ間の要請される通信リンクを識別する問合せを上記電気通信ネットワークから受信するための手段と、上記問合せから上記第１および第２のユーザの識別子を抽出するための手段と、指定された関係が上記第１および第２のユーザ間に上記ユーザコミュニティにおいて存在するか否かを決定するために上記第１および第２のユーザの識別子を分析するための手段と、指定された関係が上記第１および第２のユーザ間に上記ユーザコミュニティにおいて存在するか否かを示す返信メッセージを上記電気通信ネットワークに送信するための手段とを含む。

【0047】

もう１つの局面において、この発明は、電気通信ネットワークのユーザ間の通信相互作用をソーシャルネットワーキングサービスコミュニティにおいてユーザ間で定義された関係に従って処理するための装置またはシステムを提供し、上記装置またはシステムは、上記電気通信ネットワークの第１および第２のユーザ間の上記電気通信ネットワークを介した電気通信相互作用を処理するための手段と、上記第１および第２のユーザ間の上記ソーシャルネットワーキングサービスコミュニティにおける関係に関するソーシャルネットワーキング関係データを受信するための手段と、上記電気通信相互作用に関する処理を上記ソーシャルネットワーキング関係データに依存して行なうための手段とを含む。

【0048】

より一般的には、上述の如何なる方法の局面に対応する装置の局面も提供され、好ましい方法の特徴は、装置においても実現化されてもよい。特に、ネットワーク装置または一団の相互にリンクされたネットワーク装置を用いて、上記に記載の方法を実現化してもよく、またはこれらの方法は、複数のプロセッサにおいてたとえばインターネットのようなネットワークを通じて実現化されてもよい。データベースも、サーバにおいてまたは説明されたデータを記憶する別個のデータベースサーバにおいて実現化される。ユーザがインターフェイス接続および相互作用を説明された方法ですることと、システムのためのインターフェイスを見ることを可能にするユーザ端末も設けられる。この発明は、説明された方法の局面および特徴に対応するコンピュータプログラムの局面、コンピュータプログラム製品の局面およびコンピュータが読むことのできる媒体の局面も提供する。

【0049】

システムおよび方法の実施例を次に図面を参照して説明する。

【図面の簡単な説明】

【0050】

【図1】１つの実施例に従った関係モデルの概略図である。

【図2】代替的な実施例に従った関係モデルの概略図である。

【図3a】１つの実施例に従ったプリペイドシステムのためのグローバルアーキテクチャの概略図である。

【図3b】１つの実施例に従ったコンバージェンスシステムのためのグローバルアーキテクチャの概略図である。

【図3c】１つの実施例に従ったスタンドアローンシステムのためのグローバルアーキテクチャの概略図である。

【図4a】１つの実施例に従った参加リクエストを行なうプロセスを概略的に示す図である。

【図4b】１つの実施例に従った参加リクエストを行なうプロセスを概略的に示す図である。

【図4c】１つの実施例に従った参加リクエストを行なうプロセスを概略的に示す図である。

【図5】本明細書中に説明される方法の実施例を実現化するために用いてもよいシステムの概略図である。

【図6】本明細書中に説明されるシステムのアーキテクチャの１つの実施例を示す図である。

【図7】本システムのためのアーキテクチャの代替的な実施例を示す図である。

【図8】ChargingMaxシステムの１つの実施例を示す図である。

【図9】ChargingMaxシステムのもう１つの実施例を示す図である。

【図10】１つの実施例に従った音声コールに対する請求システムの概略図である。

【図11】１つの実施例に従ったポストペイド音声コールを説明する図である。

【発明を実施するための形態】

【0051】

本明細書中に説明されるシステムおよび方法の実現化例の１つの実施例の説明を以下に記載する。この説明は、システムが実現化されてもよい１つの方法を記載するものであり、如何なるようにも限定することを意図するものではない。

【0052】

２つの全く異なる構成が、ソーシャル・リレーションシップ・マネージャ（Social Relationship Manager：ＳＲＭ）の実現化のためにある。第１のものは、エクリプス（Eclipse）モデルと呼ばれる。加入者のコミュニティグループに加えられたすべての加入者は、このコミュニティグループ内の他のグループメンバーへのコール時に優遇料金または割引を受ける。

【0053】

エクリプスモデルには、幅広い可能性がある。コミュニティグループの形態は多くあり、たとえば、学校、サッカークラブ、協会、大学、職場または社交場、興味または趣味である。さらに、ＳＲＭは、ビジネスに用いられてもよく、たとえばＳＭＥ（中小企業：small or medium size enterprises）などである。従業員のグループは、互いにコールして、以下に説明されるコミュニティグループ特典を受けることができる。しかしながら、ＳＲＭは、クローズド・ユーザ・グループ（ＣＵＧ：Closed User Group）サービスを提供するための手段として用いることも可能であり、これにより、従業員が企業内のコールに対して個人的に支払わないように、これらのコールに対して企業ウォレットから請求することさえ可能である。また、ある事業者が仮想移動体通信事業向けサービス事業者（ＭＶＮＥ：Mobile Virtual Network Enabler）になる、または若年層などの市場の特定の層を対象としたい場合、ＳＲＭエクリプスモデルを用いて、マイクロ仮想移動体通信事業者（ＭＶＮＯ：Mobile Virtual Network Operator）を作成することさえあり得る。

【0054】

エクリプス関係モデルは、概略的に図１に示されており、図１には、ユーザ間のリンクが示されている。

【0055】

関係の第１のグループは、「コリンのグループ」１１０という名のコミュニティグループである。メンバーは７人いる。矢印は、メンバーのいずれかの間の関係を表し、たとえば、これらのメンバーのうちいずれか１人がコリンのグループ内のいずれかの他のメンバーにコールするときである。「ジャック」という名の第２のコミュニティグループも１１２に示されている。メンバーは４人である。上記のように、これらのユーザの各々の間に関係がある。メンバーのうち１人、ジェームズ１１４は、「ジャック」１１２と「コリン」１１０グループとの両方のメンバーである。このシナリオにおいて、ジェームズ１１４は、両グループのメンバーと関係を有する。この作成された２つのグループの我々が見た加入者の全員は、皆、オンネット加入者である。しかしながら、デービット１１６は、異なるネットワークからであり、そのためオフネット加入者と称される。ＳＲＭは、オフネット加入者をコミュニティグループに加えることができるが、関係は、一方向矢印によって示される一方向のものである。すなわち、「ジャック」グループ１１２のあるメンバーがデービット１１６にコールすると、彼らは事業者によって規定される割引または料金を受けるであろう。デービット１１６が「ジャック」グループ１１２のいずれかのメンバーにコールすると、彼は、彼のオフネット事業者で規定した彼の価格決定プランに従って割引なしに請求される。

【0056】

認知されている第２のモデルの種類は、原子モデルという種類である。このモデルは、フェイスブック（Facebook）（登録商標）などのソーシャルネットワーキングサイトの高まり続ける人気に基づいている。まず、ユーザＡは、「友達リクエスト」をユーザＢに送信する。ユーザＢがこの「友達リクエスト」を受信すると、彼は、承認するか無視するかのいずれかのオプションを有する。友達リクエストが承認されるシナリオにおいて、直接の関係リンクがこの２人のユーザ間に作成される。この結果とりわけ、第１に、彼らは互いのプロフィールを見ることができるようになるが、第２に彼らは互いに通信することができる。原子モデルは、加入者が互いにコールすると、後に説明される多くの他の特徴の中でもとりわけ、特別な割引または代替的な料金を受けることができるように、彼らの間に直接の関係リンクを作成することを目的とするものである。原子モデルは、ユーザ間に強い結び付きを作り、これらの関係からの多くの特典を活用することが可能である。

【0057】

原子モデルは、図２に概略的に示されている。３人の加入者は、「友達」関係リンクをコリン２１０と有しており、したがって、彼は、これらの３人の加入者と直接リンクを有する。彼らが互いにコールするときはいつでも、代替的な友達リンク料金または割引が適用される。ジャック２１２に対する「友達」関係も示されている。彼は、彼の友達との直接リンクを４つ有する。トニー２１４は、直接の友達関係を３つ有する。上記の関係はすべて、オンネット加入者とのもののみである。デービット２１６は、１人のオンネット加入者との直接の関係を有する。デービット２１６がトニー２１４にコールすると、オンネット友達料金が適用される。しかし、他のネットワークの加入者と友達関係を有することも可能である。デービット２１６がたとえば加入者２１８にコールすると、オフネット友達料金が適用される。これは、オフネット友達リンク関係である。

【0058】

エクリプスモデルと原子モデルとを組合せて、グループと友達リンクとの両方の管理を、関連付けられた料金／課金ポリシーなどとともに可能にしてもよい。

【0059】

特注の独立したＳＲＭソリューションを提供して、上記モデルを実現化してもよいが、以下により詳細に説明されるように、ＳＲＭは、代替的にまたは付加的に既存の外部のソーシャルネットワーキングサービス（たとえばマイスペース（Myspace）（登録商標）、フェイスブック、ツイッター（Twitter）（登録商標））とインターフェイス接続し、これらのサービスから、友達リンク、グループメンバー構成、フォロア関係などをたとえば規定するような関係データを得てもよい（たとえばフェイスブックは、友達リンク情報とグループ情報との両方を提供してもよい）。つぎに、料金／課金ポリシーを、それら外部ソーシャルネットワーキングサービスにおいて定義されているユーザ関係／グループに基づいて決定してもよい。外部サービスへのインターフェイスは、ソーシャルネットワーキングサービス（たとえばフェイスブック）におけるユーザのプロフィールに追加することができるユーザアプリケーションおよび／または所有権下にあるもしくはオープンな関連するソーシャルネットワーキングＡＰＩ（たとえばFacebook ＡＰＩ、OpenSocial ＡＰＩ）を含んでもよい。いくつかの例を以下により詳細に説明する。たとえば複数の外部ソーシャルネットワーキングサービスからのような、複数の情報源からの関係データをＳＲＭで組合せてもよい。

【0060】

好ましい実施例において、ＳＲＭは、以下の３つのモードで利用可能であり、これらのモードは、図３ａから図３ｃに概略的に示される。
１．プリペイド、図３ａに示される
２．コンバージェンス、図３ｂに示される
３．スタンドアローン、図３ｃに示される
各特徴に互換性がある場合、ＳＲＭのすべての特徴をすべてのモードにおいて利用可能である。

【0061】

［エクリプスモデル］
動作のエクリプスモデルの１つの実現化例を次により詳細に説明する。エクリプスモデルにおいて、ＳＲＭは、さまざまなセクションに分けられる。各セクションは、ＳＲＭサービスのための機能性の別個の分類である。各事業者は、ＳＲＭを購入すると標準特徴を有し、付加的なセクションの各々は、任意選択的に実現化されてもよい。いろいろなセクション、すなわち
・標準機能性
・ＳＲＭ一斉通信
・ＳＲＭ紹介方式
・ＳＲＭサービスバンドル
・ＳＲＭ位置情報ベースサービス
・ＳＲＭ PromoMax Express
を、以下により詳細に各々説明する。

【0062】

上記の、以下の節に詳しく述べる機能性の分類のオン／オフを切換えることが可能である。最も基本的なレベルは、標準機能性しか有さないものである。次に事業者は、パッケージ化された標準機能性とともに用いる任意の組合せの機能性を選択することができる。すべての機能性を実現化することが可能である。サービスプロバイダが、機能性のうちあるセクションを実現化しない場合、彼らは、他の特徴を彼らのスクリーンを通して見ることはない。

【0063】

［標準機能性］
開放ソーシャルグループおよび閉鎖ソーシャルグループ
ソーシャルグループ（ＳＧ）には２種類ある。開放ソーシャルグループは、登録済加入者ならば誰にでも参加を許可する。さらに、登録済加入者ならば誰でも、任意のアクティブにされた加入者をＳＧに参加するように招待することができる。閉鎖ＳＧは、未知の加入者がＳＧのメンバーになることを防ぐ権限手段を包含する。実際、加入者は、彼ら自身の行動を通じては閉鎖ＳＧに参加できない。加入者は、管理者によって加えられるか、または参加するようにとのリクエストを管理者または管理者権限のあるＳＧ加入者から受けることしかできない。事業者は、あるＳＧについて許可される最小および最大メンバー数を定義することが可能である。

【0064】

登録済加入者ならば誰でも、開放ソーシャルグループ（ＳＧ）を作ることができる。登録済加入者ならば誰でも、開放ＳＧに参加することができる。ＳＧメンバーならば誰でも、任意の登録済加入者をＳＧに参加するよう招待することができる。グループ作成者がそのグループの管理者である。管理者は、管理者権限を他のＳＧメンバーに譲渡することができる。グループ管理者は、メンバーをＳＧから外すことができる。全グループメンバーは、グループ一斉通信を送信することができる。グループ管理者は、グループ一斉通信（Mass Communication）ＳＭＳ（ＭＣ ＳＭＳ）を送信することができる。

【0065】

登録済加入者ならばで誰も、閉鎖ソーシャルグループ（ＳＧ）を作ることができる。招待された登録済加入者ならば誰でも、閉鎖ＳＧに参加することができる。グループ作成者が、そのグループの管理者である。管理者は、管理者権限を他のＳＧメンバーに譲渡することができる。グループ管理者のみが登録済加入者を参加するよう招待することができる。グループ管理者は、メンバーをＳＧから外すことができる。グループ管理者は、グループ一斉通信ＳＭＳ（ＭＣ ＳＭＳ）を送信することができる。

【0066】

ＳＲＭ加入者−登録済および非アクティブにされたもの
ＳＲＭに関して加入者のとることができる状態は２種類あり、すなわち非アクティブにされたものと登録済とである。デフォルトで、すべての加入者は、ソーシャル・リレーションシップ・マネージャを非アクティブにしている。

【0067】

非アクティブにされた加入者ならば誰でも、以下のオプションを受ける。
・ＳＧリクエストを受信しない
・ＳＧに参加できない
・登録を通じてサービスをアクティブにすることができる。これを行うことにより、加入者は登録済加入者となる。

【0068】

登録済ＳＲＭ加入者ならば誰でも、ＳＲＭの特典をすべて受ける権利を有する。登録済ＳＲＭ加入者ならば誰でも、以下を行うことができる。
・開放ＳＧリクエストを受信する
・閉鎖ＳＧリクエストを受信する
・開放ＳＧリクエストを承認する
・閉鎖ＳＧリクエストを承認する
・オンデマンドで開放ＳＧに参加する（セルフケア機構を通じて）
・他のアクティブにされた／登録済加入者に彼らが帰属する開放ＳＧに参加するよう要請する
加入者は、ＳＭＳをショートコードに送信することによってＳＲＭに登録することができる。加入者は、一旦サービスに登録すると、彼らのＭＳＩＳＤＮをニックネームと関連付けている。この番号からＳＧリクエストを行なうと、ＳＭＳが招待された側の加入者に送信される。受信箱の送信者には、通常はＭＳＩＳＤＮまたは電話帳からの関連付けられた名前が表示されるものだが、これが、登録の際に招待する側の加入者によって選択されたニックネームとともに表示されるようになる。

【0069】

加入者は、事業者が定義可能なショートコードにＳＭＳを送信することによってＳＲＭに登録することができる。このＳＭＳは、事業者が定義可能だが、そのユーザのニックネームまたはユーザネームを含まなくてはならない。ニックネームの最大の長さは、事業者が定義可能である。

【0070】

あるニックネームが既に付けられているシナリオにおいて、その名前の後ろに数字が割当てられる。たとえば、アレックス・ウェストリー（Alex Westley）が要請され、既に別の加入者によって付けられている場合、アレックス・ウェストリー１（Alex Westley1）というニックネームが割当てられる。名前が重複すると、元の名前＋１桁が昇順に付けられる。

【0071】

構成可能な料金をＳＲＭへの登録に対して請求することができる。これは、商品種類によって構成可能であることができる。この請求を負担するのに十分なクレジットをプリペイドユーザが有していない場合、登録は起こらず、ユーザは、知らせを受け、さらなるクレジットを提供するよう求められる。

【0072】

電子データ記録（ＥＤＲ：Electronic Data Record）が登録完了請求に対して作成される。これは、ＣＣＰによって問合せ可能であり、第三者課金システムに送信されて、ポストペイド課金明細書にたとえば組込まれる。

【0073】

次に確認ＳＭＳが、登録中の加入者に送信されて、彼らのニックネームまたは重複ニックネームを確認する。このＳＭＳの残りの部分は、事業者が定義することができる。それは、登録済加入者にパスワードも割当て、彼らは、このパスワードを用いて事業者が管理する（ＳＧなどおよび設定を管理するために用いられる）ウェブポータルにログインすることができる。

【0074】

登録ＳＭＳは、ニックネームをユーザのＭＳＩＳＤＮと関連付ける。この登録済加入者がＳＧリクエストを送信すると、彼らの名前は、ＳＧリクエストＳＭＳおよびＭＳＩＳＤＮに着信番号として含まれるようになる（しかしニックネームとして表示される）。この加入者がウェブページ上に表示されるＳＧのメンバーであるとき、ＭＳＩＳＤＮおよびニックネームは、ＳＲＭのための事業者ウェブページ上に示される。

【0075】

管理者
管理者は、ＳＧのメンバーである加入者に対する責任がある。開放ＳＧにおいて、デフォルトで、そのＳＧを作成する登録済加入者がＳＧ管理者である。開放ＳＧにおいて、管理者は、ＳＧメンバーをＳＧから外すことができるという付加的な機能性を有する。彼らは、これを行なうことができる権利を他のメンバーに譲渡することができる。彼らは、管理者が彼らのパスワード、グループ名およびまたはグループ番号を用いてログインすることができる管理者ウェブサイトを用いることによって、加入者をグループから外すことができる。

【0076】

閉鎖ＳＧにおいて、管理者は、この閉鎖ＳＧに参加するよう登録済加入者にリクエストを送信することができる。管理者は、リクエストを個々に送信することができ、または番号のリストを管理者が管理するウェブページに入力することができる。このリストが完成すると、ＳＧリクエストは、リスト全体に対して送信される。管理者は、他のＳＧメンバーをグループ管理者になるよう任命することができる。グループ管理者は、ＳＧメンバーをＳＧから外すこともできる。これを行なうために、彼は、管理者が管理するウェブサイトを用いる。以下は、グループ管理者についての機能性のリストである。
・開放ＳＧリクエストを受信することができる
・閉鎖ＳＧリクエストを受信することができる
・開放ＳＧリクエストを承認することができる
・閉鎖ＳＧリクエストを承認することができる
・開放ＳＧにオンデマンドで（セルフケア機構を通じて）参加することができる
・他の登録済加入者に彼らが帰属する開放ＳＧに参加するよう要請することができる
・他の登録済加入者に彼らが管理者である閉鎖ＳＧに参加するよう要請することができる
・既にＳＧのメンバーである他の登録済加入者に管理権を譲渡することができる
・グループ一斉通信ＳＭＳ（ＭＣ ＳＭＳ）を送信することができる
・ＳＧメンバーを外すことができる
開放ソーシャルグループの作成
登録済加入者ならば誰でも、開放ソーシャルグループを作成することができる。これを行なうために、加入者は、要請されるＳＧ名をショートコードへ送信することができる。これに代えて、選択された加入者のみがＳＧを作成することができるよう定義することができる。
・すべての加入者がＳＧを作成することができるよう定義することができる。
・商品種類によってＳＧ作成を制限することが可能である
・招待された加入者のみがＳＧを作成することができるようにＳＧの作成を制限することが可能である−ここで新しい残高の種類を「ＳＧ作成」に対して作成することができる。この残高の種類を選択された加入者にサービスバンドル機能性を通じて送信することができる。

【0077】

ＳＧを作成するために、加入者は、ＳＭＳをショートコードに送信することができる。この名前がまだ付けられていない場合、グループは作成される。

【0078】

管理者が定義可能なショートコードへＳＭＳを送信することにより開放ソーシャルグループを作成することができるのは、登録済加入者のみである。このＳＭＳは、事業者が定義可能であるが、開放ソーシャルグループを作成するための特定のショートコードに送信される提案されるグループ名を含まなくてはならない。グループ名の最大の長さは、事業者が定義可能である。

【0079】

ＳＧ名が既に付けられている場合、そのグループ名は、後ろに数字が付いて割当てられる。この重複番号は、時間順に増える。すなわち、そのグループ名が付けられている場合、返信ＳＭＳは、＜group name（グループ名）＞および＜SG number（ＳＧ番号）＞とともに送信される。たとえば、要請されたグループ名が「イプスウィッチ・ラグビー・クラブ（Ipswich rugby club）」であってこの名前が既に付けられていた場合、作成されるグループ名は、「イプスウィッチ・ラグビー・クラブ１（Ipswich rugby club1）」となる。これは、ＳＭＳとしてグループ作成者に送信されて、割当てられた名前をグループ作成者に通知する。もし重複する名称が提案されている場合は、そのグループ名が作成される前に加入者がそのニックネームを返信ＳＭＳで確認することが必要であってもよい。

【0080】

ＳＭＳ例は以下のとおりであり得る：「イプスウィッチ・ラグビー・クラブ」は既に付けられています。「イプスウィッチ・ラグビー・クラブ１」を承認するには、はい（ＹＥＳ）と返信して下さい。別の名前を選ぶには、新しいグループ名（最大２０文字）を７７７に送信して下さい。」確認するためには、加入者は、単に事業者に事業者が定義可能なコマンド語、たとえば、はい（ＹＥＳ）を返信ＳＭＳで送信するだけでよい。そうでなければ、加入者がこのグループ名に不満足な場合、彼らはこのプロセスをやり直すことができる。

【0081】

事業者により請求が適用される場合は、プリペイド加入者がグループを作成するのに十分なクレジットを有する場合にのみグループの作成が成功する。ポストペイドユーザに対しては、ＥＤＲが作成されるので、これを彼らの月毎の明細書に載せることができる。

【0082】

加入者は、形成されたグループの詳細を彼の友達との口コミによって広めることができる。さらに、これは開放ＳＧであるため、メンバーならば誰でも他のアクティブにされている加入者を参加するよう招待することができる。

【0083】

ＳＭＳは、１２７４などのグループ番号をグループに割当てもする。加入者が、グループに参加したいとき、彼らは、セルフケアＩＶＲをたとえば用いて、グループ番号を入力してグループを見つけ、その結果参加することができる。

【0084】

開放ＳＧの作成に対して構成可能な料金を請求することができる。これは、たとえば商品種類によってまたは残高カスケード（cascade）によって設定可能であり得る（「ＳＧ作成」残高バケット（bucket）のある加入者のみがＳＧを作成することができてもよい）。プリペイドユーザが、この請求を負担するのに十分なクレジットまたは充分な残高バケットを残高カスケードに有していない場合、登録は起こらない。

【0085】

ＣＤＲ／ＥＤＲは、開放ＳＧの作成に対して作成される。これは、ＣＣＰによって問合せ可能であり、ＥＤＲ／ＣＤＲは、たとえばポストペイド課金明細書に組込むために、第三者課金システムに送信される。

【0086】

開放ソーシャルグループが作成され次第、返信ＳＭＳがグループ作成者へ送信される。グループ作成者は、デフォルトでグループの管理者でもある。このＳＭＳは、事業者が定義可能であり、以下の情報を含む。
・グループ名または重複名の確認
・ＳＧ名およびＳＧ番号の割当て
・グループ管理者へのパスワードの割当て。これを用いて、事業者が管理するウェブサイトにログインすることができる。ここでは、ＳＧメンバーを管理することができる。
・事業者ウェブサイトの詳細を伝える
・確認ＳＭＳ例：「ありがとうございました。イプスウィッチ・ラグビー・クラブ１が作成されています。グループ番号 １２３４５。メンバー管理のためのパスワード sgfitbne。ウェブサイト www.esg.srm.co.uk」。

【0087】

加入者がこのＳＭＳを保存することが推奨される。加入者がこれらの詳細のいずれかを忘れた場合、彼らは、携帯装置へのパスワードの再送信を要請するか、または彼らのＭＳＩＳＤＮからカスタマーサービスに電話を掛けることができる。そうすると、ＣＳＲは、パスワードなどを再送信することができる。

【0088】

加入者がＳＧの詳細を保存していないシナリオにおいて、彼らは、事業者が定義可能なコマンド語を備えたＳＭＳをショートコードに送信することによって、彼らがメンバーであるすべてのＳＧの詳細を要請することができる。ＳＲＭは、すべてのＳＧ名およびＳＧ番号のリストをＳＭＳを介して送信する。問合せメッセージの一例は、以下のようであり得る：＜Query Groups（グループ問合せ）＞が７７７へ送信される。

【0089】

閉鎖ソーシャルグループの作成
登録済加入者ならば誰でも、閉鎖ＳＧを作成することができる。これを行なうために、登録済加入者は、ＳＭＳをショートコードへ送信することができる。閉鎖ＳＧを作成する登録済加入者が、管理者である。開放ＳＧとの主な違いは、管理者は、他の登録済加入者へＳＧリクエストを送信することができるだけである点である。彼らは、これを彼らの電話の使用を通じてまたは事業者が管理するウェブサイトを通じて行なうことができる。

【0090】

このＳＧプロセスは、閉鎖ＳＧリクエストが開放ＳＧ作成リクエストについてのものとは異なる、事業者が定義可能なショートコードへ送信される点を除いて、開放ＳＧ作成プロセスと同一である。

【0091】

管理者権限
開放ＳＧにおいて、ＳＧメンバーは、一旦管理者権限を有すると、他のＳＧメンバーをそのＳＧから外すことができる。閉鎖ＳＧにおいて、ＳＧメンバーは、一旦管理者権限を有すると、ＳＧ招待状を他の登録済加入者に送信することも、グループ一斉通信を送信することもできる。彼らは、ＳＧメンバーをそのＳＧから外すこともできる。管理権のあるＳＧメンバーについての機能性には、以下が含まれる。
・開放および閉鎖ＳＧリクエストを受信することができる
・開放および閉鎖ＳＧリクエストを承認することができる
・開放ＳＧに（セルフケア機構を通じて）オンデマンドで参加することができる
・他の登録済加入者に彼らが帰属する開放ＳＧに参加するように要請することができる
・他の登録済加入者に彼らが管理者である閉鎖ＳＧに参加するよう要請することができる
・グループ一斉通信を送信することができる
・ＳＧメンバーを外すことができる
管理者は、事業者が管理するポータルを用いて、グループメンバーの上でクリックすることによって管理権を別のＳＧメンバーに譲渡することができる。

【0092】

管理者が一旦管理者権限を新しい閉鎖ＳＧメンバーへ譲渡すると、リアルタイムにこの新しい管理者にＳＭＳが送信される。このＳＭＳは、事業者が定義可能なものであり、以下の情報を含んでもよい。
・管理者＜Member name（メンバー名）＞このＳＭＳの初めに含まれるかまたは送信者ＩＤとして含まれるかのいずれかは事業者によって定義可能である
・ＳＧ名
・ＳＧ番号
・ＳＧパスワード
ＳＭＳ例は、「イプスウィッチ・ラグビー・クラブ１２、グループ番号１２３４５の管理者権限を貴方に譲渡しました。パスワードは１２３４５です。」であり得る。

【0093】

管理者権限を譲渡するには、管理者は、事業者管理者データベースを通じてログインし、単にグループメンバーの上でクリックすることによって権利を譲渡することができる。より詳細には、ウェブポータル事業者ＰＩの項を参照されたい。一旦管理権が新しい閉鎖ＳＧメンバーに譲渡されると、リアルタイムにこの新しい管理者にＳＭＳが送信される。

【0094】

管理者権限のある加入者のみがＳＧメンバーを外すことができる。これを行なうために、彼らは事業者が管理するウェブサイトにグループ名／番号および彼らのパスワードを用いてログインしなくてはならい。次に彼らは、加入者名またはＭＳＩＳＤＮの上でクリックし、指示に従って、この加入者を外すことができる。このようにして、管理権のあるＳＧメンバーは、事業者が管理するウェブサイトを用いてメンバーをＳＧから外すことができる。このウェブサイトは、外部ＰＩを用いてＣＭＸプラットフォームと接続する。このウェブサイトからのアクションは、加入者をＳＧから外すためのものである。

【0095】

加入者をＳＧから外すことが一旦成功すると、彼らに、以下の情報を含む事業者が定義可能なＳＭＳが送信される。
・ＳＧ名を含む
・事業者が定義可能なメッセージ
このＳＧメンバーは、即時外される。彼らは、グループ管理者から新しい参加リクエストが彼らに送信されない限り、このグループに再び参加することはできない。

【0096】

開放ＳＧシナリオにおいて、ＳＧメンバーがこの外されたＳＧ加入者に招待状を送信する場合、この外された加入者は、加えられず、彼を加えることができない理由を説明するＳＭＳを受信する。したがって、ＳＧから外された加入者は、管理者から招待状が送信された場合にのみ再び参加することができる。要請する側のＳＧメンバーへの返信ＳＭＳが送信される。このＳＭＳは、事業者が定義可能であるが、以下の情報を含んでもよい。
・＜member name（メンバー名）＞
・事業者が定義可能なメッセージ
例「残念ながら、＜Member name（メンバー名）＞はこのグループから外されています。この加入者は＜SG Name（ＳＧ名）＞に加えられていません。」
開放ソーシャルグループメンバーリクエストプロセス
ＳＧメンバーのみがＳＧリクエストを行なうことができる。ＳＧリクエストを行なうために、登録済加入者は、事業者が定義可能なショートコードにＳＭＳを送信することができ、このＳＭＳは、以下の情報を含んでもよい。
・＜The requested MSISDN（要請されたＭＳＩＳＤＮ）＞および＜SG Number（ＳＧ番号）＞をショートコードへ
・例：０７９６８３４６３７＋２１２３４が８８８へ送信される
登録済ＳＧメンバーは、ＳＭＳをＳＧ番号へ送信することによって開放ＳＧリクエストを行なうことができる。それには、以下の情報が含まれてもよい。
・＜The requested MSISDN（要請されたＭＳＩＳＤＮ）＞が＜SG Number（ＳＧ番号）＞に送信される
・例：０７９６８３４６３７＋２１２３４に送信される
図４ａから図４ｃにおけるように、名刺をショートコードに送信することによって、ＳＧ参加リクエストを行なうことも可能である。図４ａにおいて、ユーザがメンバーリクエストを行なう対象の連絡先が選択される。次に「名刺を送る」のオプションが図４ｂにおいて選択され、ショートコードＳＧ番号が図４ｃにおいて入力される。これによりプロセスがエンドユーザにとってより使いやすくなる。

【0097】

図４ｃ中の電話番号は、ＳＧ番号である。登録済加入者は、示されるように、要請されるＭＳＩＳＤＮの名刺をＳＧ番号に送信することによってＳＧ参加リクエストを行なうことができる。ＳＲＭは、この名刺からＭＳＩＳＤＮのみを抽出する。

【0098】

可能性のあるシナリオは３つある。
１．登録済→登録済
２．登録済→非アクティブにされているもの
３．登録済→オフネット
登録済→登録済
登録済加入者がＳＧリクエストを別の登録済加入者に送信する結果、以下のＳＭＳが招待される側の登録済加入者によって受信される。招待される側の登録済ＳＧメンバーは、ＳＧへの招待状をＳＭＳを介して受信する。このＳＭＳは、事業者が定義可能であるが、以下の情報を含んでもよい。
・＜Registered member name（登録済メンバー名）＞
・＜social group name（ソーシャネルグループ名）＞
・３つのオプションを示す：参加する、参加しない、および非アクティブにしＳＧリクエストの受信を停止する
例：
・オリバー・ベケットが送信者ＩＤに表示される
・メッセージには、「イプスウィッチ・ラグビー・クラブ１２に参加することを貴方に要請します。参加するには、はい（ＹＥＳ）と返信して下さい（２ユーロ）。参加しないならば何もしないで下さい。グループリクエストの受信を停止するには、停止する（ＳＴＯＰ）と返信して下さい」と書いてある。

【0099】

ＳＧ参加リクエストの受信後、加入者は、３つのオプション、すなわち参加する、参加しない、およびサービスの完全非アクティブ化を通じてＳＧリクエストの受信を停止する、を有する。

【0100】

登録済加入者がＳＧに参加するためには、この加入者は、＜join（参加する）＞などの事業者が定義可能な語を備えた返信ＳＭＳを送信することができる。

【0101】

エクリプスモデルでは、事業者は、ＳＧのメンバーでいることまたは少なくとも参加することに対して、加入者に請求することを望む可能性が非常に高い。このため、ＳＲＭは、参加するためには加入者がアクションを起こさなくてはならないように設計されている。加入者がこのアクションを行なうことによって、請求を適用することも可能になる。
ＳＧの一員になりたくない登録済加入者は、特にアクションを起こす必要がない。ＳＧリクエストをさらに受信したくない登録済加入者は、単に＜stop（停止する）＞とＳＭＳに返信することによってこのサービスを非アクティブにすることができる。これは、非アクティブ化の項においていっそう詳細に説明される。

【0102】

加入者がサービスを非アクティブにすると、彼らは、
・ＳＧリクエストを受信しなくなる
・ＳＧに参加できなくなる
・登録を通じてサービスを再びアクティブにすることができる。これを行なうことによって、加入者は、登録済加入者となる。
・彼らが既にメンバーであるいずれのＳＧに対する如何なるＳＧ料金／割引も受けなくなる。

【0103】

登録済→非アクティブにされているもの
非アクティブにされている加入者は、ＳＲＭから脱退することを選んでおり、ＳＧリクエストを受信することはできない。登録済加入者が非アクティブにされている加入者に対してＳＧリクエストを行なうシナリオにおいて、非アクティブにされている加入者は、リクエストを受信しない。

【0104】

登録済加入者は、要請された番号がサービスを非アクティブにしているためリクエストは利用不可能であるという返信ＳＭＳを受信する。

【0105】

登録済→オフネット
このＳＧリクエストシナリオにおいては、ＳＧメンバーにとってのオフネット加入者への一方向関係が形成されるように、オフネット番号をソーシャルグループに加える。もしオフネット加入者をＳＧのメンバーに招待する場合、オフネット番号を自動的に加える。

【0106】

この番号が加えられたと説明する、事業者が定義可能なＳＭＳを招待する側のオンネット番号に送信することが可能である。

【0107】

ドバイなど多くの国において、如何なるプロモーションにも参加しないというオプションをオフネット番号が有することが要件とされる。この場合、ＳＭＳがオフネット加入者に送信される。このＳＭＳは、事業者が定義可能であるが、以下の情報を含んでもよい。
・送信者のＩＤは、ショートコードまたは＜SG Number（ＳＧ番号）＞ではない
・招待する側の加入者の＜nickname（ニックネーム）＞を含む
・＜SG name（ＳＧ名）＞を含む
・ＳＧの一員であることを防ぐオプションを示す
例：「＜esgTel＞のオリバー・ベケットが貴方の番号を＜Ipswich Rugby Club（イプスウィッチ・ラグビー・クラブ）＞に加えることを望んでいます。承認するには、何もしないで下さい。これを許可しない場合には、＜no（いいえ）＞と返信して下さい。」
もしこのオフネット加入者が彼の番号をＳＧの一員にすることを許可したくない場合、彼は、いいえと返信することができ、彼の番号は加えられない。すべての関係が変形される。招待する側のオンネット加入者に、オフネット加入者がＳＧに加えられることを望まなかったことと、この番号には料金が適用されないこととを彼に知らせるＳＭＳが送信される。

【0108】

以下に紹介方式を参照して説明されるような機能性を加えることも可能である。
ＳＲＭを非アクティブにするプロセス
加入者がＳＲＭを非アクティブにするためには、加入者は、これを以下の３つの別個の方法で行なうことができる。
・セルフケア機構を通じて
・事業者が規定したショートコードにＳＭＳを送信することによって、たとえば＜stop（停止する）＞が事業者が定義したショートコードに送信される
・ＳＧリクエストＳＭＳに返信することによって。ＳＧリクエスト例は、「アレックス・ウェストリーが貴方をイプスウィッチ・ラグビー・クラブ１２に参加するよう招待しました。参加するには、はい（ＹＥＳ）と返信して下さい（２ユーロ）。参加しないならば、何もしないで下さい。グループリクエストの受信を停止するには、停止する（ＳＴＯＰ）と返信して下さい。」
＜stop（停止する）＞と返信するＭＳＩＳＤＮは、いずれも、非アクティブにされたＳＲＭ状態になる。

【0109】

閉鎖ソーシャルグループリクエストプロセス
ＳＭＳリクエストプロセスは、閉鎖ソーシャルグループについても同じようなしくみだが、グループ管理者または管理者権限のある加入者のみがＳＧリクエストを行なうことができる。管理者権限のないグループメンバーがＳＧリクエストを行なおうとすると、そのリクエストは、行なわれない。管理権のない加入者は、ＳＭＳを受信する。このＳＭＳは、事業者が定義可能であり、＜group name（グループ名）＞を含んでもよい。

【0110】

例：「申し訳ありません、グループ管理者のみがＳＧリクエストを＜group name（グループ名）＞について行なうことができます。リクエストは行なわれません。」
事業者が作成し管理するウェブサイトを介して、管理者がＳＧリクエストを行なうことも可能である。ここで管理者または管理権のある人は、グループ名、ＭＳＩＳＤＮおよび閉鎖ＳＧ作成プロセス中に与えられるパスワードでログインすることができる。管理者は、彼らのパスワードを変更するオプションを有する。一旦リクエストが行なわれると、送信されるリクエストＳＭＳは、オプションソーシャルグループのためのＳＭＳリクエストプロセスと同じプロセスを辿る。

【0111】

ＳＧ料金／割引
一旦関係がソーシャルグループメンバーに関して形成されると、形成された関係があるメンバー間でソーシャルグループコールまたはメッセージが開始されるのに続いて、以下の挙動が起こる。

【0112】

ある加入者がメンバーであるすべてのソーシャルグループにわたって適用されるべきＳＧコール共通料金／割引を事業者が定義することが可能である。これを、加入者が関連付けられている商品種類によって決定付けることができる。事業者が、作成されたあらゆるソーシャルグループに対して個々の料金／割引を定義することも可能である。

【0113】

ある加入者が２つ以上のソーシャルグループのメンバーである場合、コールの費用は、ソーシャルグループに照らしてＡおよびＢ加入者の関係に依存して料率を定められる−両加入者が両者ともに３つ以上の共通のソーシャルグループのメンバーである場合、より大きな割引または最も安い料金を与える料金に従ってコールの料率を定める。

【0114】

ＳＧの料金がＳＧの大きさに依存することも可能である。たとえば、ＳＧのメンバーが多いほど、料金／割引は大きい。あるいは、場合によっては、ＳＧのメンバーが多いほど、割引または料金が少ない。事業者は、ＳＧの大きさとその後の料金／割引との間の関係の概要を定義することができる。この概要には制限はない。

【0115】

一方、事業者が、累積的料金／割引を定義することも可能である。これは、料金または割引が、加入者がメンバーであるＳＧの量に依存し、よって２つ以上のＳＧのメンバーであることによって、より大きな割引または料金が与えられ得ることを意味する。

【0116】

事業者は、ＳＧメンバーの量に関して満たされるべきしきい値を定義することができる。これらのしきい値が満たされると、ＳＧ料金が変化する。ＳＧメンバー全員へ料金が変わったことを彼らに知らせるＳＭＳが送信される。

【0117】

事業者が累積料金／割引を定義することも可能である。これは、料金または割引が、加入者がメンバーであるＳＧの量に応じることを意味し、よって２つ以上のＳＧのメンバーであることによって、より大きな割引または料金が個々の加入者単位で与えられる。

【0118】

ＳＧに参加するための１回限りの料金を事業者が適用することが可能である。加入者の口座から月単位で引落すことができる会費を事業者が定義することが可能である。この会費を、そのＳＧに特定的なものにすることができる。これに代えて、会費の費用を、ＳＧの大きさ、すなわちＳＧのメンバーが何人であるかに結びつけることができる。

【0119】

加入者が２つ以上のＳＧのメンバーである場合、事業者は、加入者がメンバーである各個々のＳＧへの会費に対して加入者に請求することが可能である。たとえば、加入者が１つのＳＧのメンバーであると１つの会費が取られる。加入者が２つのＳＧのメンバーである場合、２つの会費を取ることができる。

【0120】

２つ以上のＳＧのメンバーであるＳＧメンバーに対して、加入者がメンバーであるＳＧの数に基づいて会費を適用することも事業者のオプションである。たとえば、ある加入者は、１つのＳＧのメンバーである−彼は、３ユーロの会費を支払う。別の加入者は、３つのＳＧのメンバーである−彼は５ユーロの会費を支払う。

【0121】

会費が引落されない場合、加入者は、ＳＧメンバーであることの特典の猶予期間に入る。ＳＧ猶予期間中、ＳＧメンバーは、
・ＳＧコール／メッセージに対するＳＧ料金または割引を受けない
・ＭＣ ＳＭＳを受信しない
・加入者をこのグループに参加するよう招待することができない（開放ＳＧの場合）
・ＳＧ猶予期間中、他のＳＧメンバーは、「猶予期間ＳＧメンバー」にコールする／メッセージを送ることができ、このコール／メッセージは、彼らのＳＧ料金／割引に従って料率を定められる。
・ＳＧメンバーが彼のＳＧ会費を猶予期間中に支払った場合、完全な機能性が再開される。

【0122】

猶予期間後、加入者が彼の口座に依然として再入金していない場合、加入者は、彼が以前にメンバーであったＳＧに再加入する必要がある。すべてのＳＧ関係が変形される。加入者に、彼が以前メンバーであったすべてのＳＧを詳しく述べるＳＭＳが送信される。このＳＭＳは、事業者が定義可能であり、これらのＳＧがアクティブではなくなったことを説明する。

【0123】

事業者は、加入者が参加することができるソーシャルグループの最大の数を定義することができる。ＳＲＭには制約はない。

【0124】

会費の費用をＳＧの大きさと結び付けることが可能である。会費の費用を加入者がメンバーであるＳＧの数と結び付けることも可能である。たとえば、ある加入者は、１つのＳＧのメンバーである−彼は３ユーロの会費を支払う。別の加入者は、３つのＳＧのメンバーである−彼は５ユーロの会費を支払う。

【0125】

企業ウォレット
特定のユーザコールを管理し、かつこのコールに対して支払いを行う企業または別個の事業体に対して特定的にソーシャルグループを作成する場合、ＳＧメンバーが行なうすべてのコールに対して企業ウォレットなどの共同ウォレットから請求することが可能である。このシナリオにおいて、作成されるＳＧは、閉鎖ＳＧではなくてはならない。デフォルトで、企業ウォレットは、管理者のウォレットからであるだろう。しかしながら、管理者は、企業ウォレットが管理者権限のある任意の他のメンバーからであるよう割当てることができる。

【0126】

ソーシャルグループが企業に対して特定的に作成される場合、ＳＧメンバー間のすべてのコールに対して二次ウォレットから請求することが可能である。このシナリオにおいて、作成されたＳＧは、閉鎖ＳＧでなくてはならない。デフォルトで、二次ウォレットは、管理者のウォレットからである。しかしながら、管理者は、このウォレットが任意の他のウォレットＩＤからであるよう割当てることができる。

【0127】

ＳＧメンバー間でなされるすべてのコールに対して企業ウォレットから請求することが可能である。管理者が特定のＭＳＩＳＤＮを指定して、彼らのすべてのコールが企業ウォレットから請求されるようにすることも可能である。

【0128】

ＳＧを１ヶ月アクティブにしておくことに対して請求を適用することが可能である。このレンタルにより請求されるＳＧメンバーは、１人のみである。請求は、管理者宛である。猶予期間が終わった後に請求が支払われない場合、ＳＧは閉鎖される。延長された猶予期間をこの種のＳＧに対して定義することができる。

【0129】

多くの事業者が、会社全体のプランについて企業料金などを交渉するための専門部門を有する。ＳＲＭ＋PromoMax Expressは、あるグループが彼らの１ユーザ当たりの平均売上（ＡＲＰＵ：Average Revenue Per User）が増加する場合によりよい料金を受けることを可能にする高度な特徴を有する。したがって、ある企業が、ＳＧに加えられる従業員、ひいてはそのＡＲＰＵという点で拡大するにつれて、料金は、所与のしきい値が満たされるたびによりよくなる。また、それにより、料金などの毎年の見直しの必要がなくなるはずである。

【0130】

個々のＳＧのＡＲＰＵについてカウンタを設置することができる。次に、事業者は、何らかの満たされるべきしきい値を、ＡＲＰＵがこの量に達すると、代替的な料金がグループに対して適用されるように、定義することができる。企業ウォレットを定義したＳＧのみがこのサービスを利用可能であるように定義可能であり得る。

【0131】

例：管理者は、多くの料金を定義することができる。
月１００ユーロ→料金１
月２００ユーロ→料金２
月４００ユーロ→料金３
…
月１０００ユーロ→料金ｘ
自動的にかつＣＳＲの係わり／交渉なしに、企業は、出費されたグループＡＲＰＵに基づいて彼らにふさわしい料金を手に入れることができる。

【0132】

料金変更・入替わりは、レベルに達するとリアルタイムにグループ管理者への確認とともに起こることができる。

【0133】

［エクリプスＳＲＭ＋一斉通信（ＭＣ）］
開放ＳＧおよび閉鎖ＳＧ
あるＳＭＳをＳＧメンバー全員に送信することが可能である。開放コミュニティグループにおいて、グループ管理者のみが一斉通信（ＭＣ：Mass Communication）ＳＭＳを送信することができる。ＳＧ管理者は誰でも、事業者が定義するショートコードにＳＭＳを送信することによってＭＣ ＳＭＳを送信することができる。このＳＭＳは、事業者が定義可能であるが、以下の情報を含んでもよい。
・*＜SG Number（ＳＧ番号）＞♯を含む。たとえばＳＧ番号１２３４５に対しては^*１２３４５♯と書く
・＜Contents of SMS（ＳＭＳの本文）＞これは♯キーの後のＳＭＳの残りの部分である
・ＭＣ ＳＭＳは、事業者が定義可能なショートコードに送信されなくてはならない
事業者は、ＭＣ ＳＭＳの料率を定めるために、別個の料金／割引を定義することができる。事業者がＭＣ ＳＭＳの費用をＳＧメンバーの数との関連で定義することが可能である。

【0134】

全グループメンバーがＭＣ ＳＭＳを受信する。それは以下の形式からなる。
・ＳＧ名を受信箱の送信者に含む
・ＳＭＳの本文を含む
閉鎖ソーシャルグループについては、ＭＣ ＳＭＳに返信することは不可能である。しかしながら、開放ＳＧにおいては、事業者が定義する特定の量のメンバーまで、すべてのメンバーがＭＣ ＳＭＳを返信および送信することが可能である。この機能性がよいエンドユーザ体験である例は、たとえば１０人の小さなソーシャルグループにおけるものである。この場合、ＭＣ ＳＭＳは、効果的なコミュニケーション手段であるだろう。しかしながら、１００名の人からなるＳＧにおいて、この種のメッセージについては、多くのメンバーにあらゆるＭＣ ＳＭＳに返信させることは実現化不可能であるであろう。

【0135】

したがって、事業者が定義する特定の大きさ未満のグループについては、グループメンバー全員がＭＣ ＳＭＳを送信／返信することができる。

【0136】

実施例によっては、ＭＣ ＳＭＳに返信することは（以下の節において説明されるPromoMax Express機能性を用いない限り）不可能である。

【0137】

ＭＣ ＳＭＳをログイン詳細情報が要求される事業者が管理するウェブサイトから送信することも可能である。この場合もまた、管理者または管理権のあるＳＧメンバーのみがこの機能性を有する。

【0138】

ＭＣ ＳＭＳのいくつかの例は以下のとおりである。
・大学−ＳＭＳが全学生に送信される。「電気通信学の全学生：教員が病気のため本日１１：３０開始のゼミは中止されたことにご留意下さい。大学よりお詫び申し上げます。」この簡潔なＳＭＳにより、学生が無駄にキャンパスまで行く手間が省かれ得、これに対して彼は非常に感謝し、このサービスに満足するであろう。このメッセージは、管理者によってのみ送信される。これにより不要なメッセージが送信されることがなくなる。
・ソーシャル・リレーションシップ・マネージャが従業員のグループのために用いられるシナリオにおいて、管理者は、「スタッフの皆さん、鍵が開いたままになっている裏口の門の鍵をどなたかがお持ちです。お心当たりの方は速やかに事務所にお電話下さい」というグループＳＭＳを送信することができる。
・サッカークラブコミュニティグループ−マンチェスター・ユナイテッドがロナルドを放出することを決定−これはファンにとって非常に重要なメッセージである。管理者は、「親愛なるファンの皆さん、２００８年９月１２日午前１０時、マンチェスター・ユナイテッドは、ロナルドをレアル・マドリッドに記録的な１億£で放出したことをお知らせします。これがクラブのために一番であるとお約束致します−マンチェスター・ユナイテッドＦＣ」と書かれたグループＳＭＳを送信する。熱心なファンは、このニュースをこれが起こり次第移動中および彼の携帯電話から知りたいと思うであろう。

【0139】

ＳＧメンバーがＭＣ ＳＭＳの受信を非アクティブにすることが可能である。彼らは、セルフケア機構を用いてまたは事業者ウェブサイトを通じてこれを行なうことができる。

【0140】

オフネット加入者が無料コールの特典のためではなく（これは明らかにありえない）ＳＧ一斉通信ＳＭＳの受信という有用な機能性のためにソーシャルグループに参加したいと思うこともある。オフネット加入者は、ＳＧ ＭＣ ＳＭＳを受信するためには、事業者が定義する番号にメッセージを送信することができる。オフネット加入者がＭＣ ＳＭＳを受信するためにＳＧに参加することは、可能である。これを行なうために、彼らは、事業者が定義する番号［ショートコードではない］にＳＭＳを送信することができる。このＳＭＳは、事業者が定義可能だが、以下の情報を含んでもよい。
・＜join（参加する）＞などのコマンドを含む
・＜SG number（ＳＧ番号）＞を含む
加入者は、コミュニティグループ番号を知らなくてはならない。したがって、コミュニティグループ番号が１２６４であるサフォーク大学に参加するには、加入者は、単に「１２６４に参加する」とメールを打って送信することができる。このプロセスの後、以下のアクションが起こる。
・事業者が定義可能な通知ＳＭＳがオフネット番号に返信される
・たとえば、「ありがとうございました。貴方は「サフォーク大学」に関する通信を受信するようになりました。」
・番号がＳＲＭレポートに送信される
・ソーシャル・リレーションシップ・マネージャは、番号をオフネットＳＧメンバーとして記憶する。オンネットＳＧメンバーがこのオフネット番号にコールすると、彼らは、ＳＧ（オフネット）料金プランに従って請求される。

【0141】

［エクリプスＳＲＭ＋紹介方式］
登録済加入者がオフネット加入者をＳＧのメンバーになるよう招待するとき、この加入者がオフネット加入者である場合、以下の紹介方式を実現化することができる。

【0142】

要請されたＭＳＩＳＤＮがオフネットである場合、招待状を送信したメンバーのソーシャルグループのグループメンバーと要請された側のオフネットＭＳＩＳＤＮとの間に一方向関係が形成される。

【0143】

番号がオフネットの場合、確認ＳＭＳが招待する側の加入者に送信される。それは事業者が定義可能であるが、以下の情報を含んでもよい。
・招待される側のオフネット加入者のＭＳＩＳＤＮを含む
・紹介メッセージ
一例は以下のとおりであり得る。「ありがとうございました。０７９７８３３２９５４９３０は貴方のソーシャルグループに加えられました。彼らはesgTelの加入者ではありません−彼らが参加すれば、貴方に１０ユーロの報奨が与えられます。」
オフネットＭＳＩＳＤＮは、ＳＲＭデータベースに送信される。
・事業者は、これらのオフネット番号についてのレポートをオンデマンドで行なうことができる。
・このレポート中の情報は、オフネット加入者に対称を絞ったキャンペーンにおいて用いることができる。

【0144】

加えて、ＳＭＳが事業者が定義可能なようにオフネット加入者へ送信される。それは、以下の情報を含んでもよい。
・彼らを要請したオンネット加入者のニックネーム
・事業者名
・事業者の電話番号
一例は、以下のとおりであり得る：オリバー・ベケット１２３４５６７は、貴方に＜egsTel＞に参加してほしいと思っています。貴方の番号を＜esgTel＞に届けて、１０ユーロの無料クレジットを受取って下さい。

【0145】

被紹介者が予め定められた期間ネットワーク内にいなかったことを確実にする制御機構があることが必要である。これを制御する１つの機構は、オフネット番号からポートされた番号のみが報奨を受けることが許されるというものである。したがって、ポートされた番号のみが紹介方式の対象となる。これを実現化するには、事業者が彼らのネットワークに番号ポータビリティを導入していることが要件である。ＳＲＭによる照合も行なわれて、そのＭＳＩＳＤＮが構成可能な期間ネットワークになかったことを確かめる。

【0146】

ポートされた番号が事業者のネットワークに参加する場合、報奨は、紹介者と被紹介者との両者のウォレットに自動的に送信され、両者にこれを確認する事業者が定義可能なＳＭＳが送信される。

【0147】

［エクリプスＳＲＭ＋サービスバンドル機能性］
サービスバンドルは、加入者が購入したクレジットを特定のサービスでの使用に利用可能なクレジットに変換することを可能にする。単純な「ＳＧ料金バンドル」の例は、次の１ヶ月以内にＳＧメンバーに使用するための１００通のＳＭＳのパッケージをたった１０ユーロでユーザが購入することができるというものである。

【0148】

ＳＲＭは、サービスライブラリ（Service Library）において設計されるようなサービスバンドル機能性に基づいている。事業者は、加入者がセルフケア機構を通じて購入および選択することができるＳＧサービスバンドルの品揃えを定義することができる。

【0149】

事業者は、サービスバンドルの消費についてのいくつかの規則、たとえば：
・ＳＧサービスバンドルは、特定のＳＧへのコール／メッセージにしか消費することができない
・ＳＧサービスバンドルは、加入者がメンバーであるいずれのＳＧへのコール／メッセージにも消費することができる
を定義することができる。

【0150】

ＳＧメンバーがＳＧ音声コールを行なうまたはメッセージを送信するとき、この費用がＳＧ料金ではなくＳＧサービスバンドルのみから取られるよう定義することができる。一旦このＳＧサービスバンドルからすべての分／ＳＭＳが消費されると、加入者は、彼の次の残高カスケード、たとえば一般現金の使用に逆戻りする。

【0151】

上記の機能性は、加入者が、彼が望むだけ多くのＳＧに加入できることを意味する。しかしながら、事業者は、サービスバンドル機能性を通じてこのＶＡＳから与えられる収入の正確なパーセントを常時監視することができる。加入者が、繰返しサービスバンドルを購入している場合、彼はこのサービスを利用し、事業者にとってより多くの収入を生み出しているのでこれもよいことである。

【0152】

［エクリプスＳＲＭ＋位置情報ベースサービス］
位置情報ベースサービスは、「ホームゾーン」付加価値サービスとしても知られていることがある。ホームゾーン（ＨＺ：Home Zone）コンセプトは、これにより加入者が事業者のサービスを固定の場所から用いるときに割引を受けることができるサービスである。加入者は、好ましいゾーンとして９つまでの異なるエリアを指定することができる。加入者が指定したゾーンのうち１つの中からコールしているとき彼に割引を提供することが可能だが、加入者から着呼する人が発呼側の加入者によって指定されたゾーン内でオンネットの場合、発呼者に割引を提供することも可能である。

【0153】

ソーシャル・リレーションシップ・マネージャにおいて、加入者が固定エリア内からコールを行うとき、彼のＳＧ料金または割引が開始されて、そのコールの料率を定めるか、そのコールの費用は加入者のＳＧサービスバンドルから取られるかのいずれかである。たとえば、閉鎖ソーシャルグループがサフォーク大学という名で作成される。グループ管理者は、セルフケア機構を用いてキャンパスセルＩＤを定義する。学生、つまりソーシャルグループメンバーがこのエリア内からＳＧコールを行なうと必ず、彼らは料金または割引の２番目の段階に照らして料率を定められる。割引をＳＧゾーンに関する以下のシナリオに適用することができる。
・当事者Ａも当事者Ｂもいずれもゾーン内ではない
・当事者Ａはゾーン内である
・当事者Ｂはゾーン内である
・当事者Ａおよび当事者Ｂはゾーン内である
コミュニティグループに対する完全な料金プランを、次に以下のように定義することができる。

【0154】

【表1】

【0155】

加入者が彼ら自身のグループを作成するシナリオにおいて、彼は、彼が物理的にそのゾーン内にいるときセルフケアインターフェイスを用いることによってグループゾーンを設定することができる。ＳＧ管理者または管理者権限のあるＳＧメンバーのみがこれを行なうことができる。

【0156】

位置情報ベースサービス（ＬＢＳ：Location Based Service）コールがなされる場合に優先して有効となる料金プランを事業者が定義することが可能である。ＬＢＳ料金プランは、商品種類によって定義可能である。それは、前のＳＧ料金への割引または別個の付加的な料金プランであり得る。この料金プランに適用可能なサービスは、制御プランに対して、ＣＣＳ性能に関するすべてのサービスを定義する性能を含む。すなわち、事業者は、どのサービスが適用されるかを選択することができる。

【0157】

上記のような料金プランまたは割引は、以下のシナリオ、すなわち当事者Ａがゾーン内、当事者Ｂがゾーン内、当事者ＡおよびＢがゾーン内、に対して定義可能である。

【0158】

ホームゾーン割引があるコールに対してアクティブであるとき、以下のタグがＵＢＥによって作られるＥＤＲに加えられるものとする：ＳＥＲＶＩＣＥ＝ＨＺ。

【0159】

加入者は、彼の現在の場所を彼の好ましいゾーンのうちの１つとしてＩＶＲセルフケアインターフェイスを通じて記録することができるものとする。

【0160】

管理者または管理権のある人のみがＳＧゾーンをＭＳＩＳＤＮの使用を通じて設定することができる。９つまでの異なるゾーンをＳＧゾーンに設定することが可能である。これは事業者が定義可能である。

【0161】

［エクリプスＳＲＭ＋PromoMax Express］
ソーシャル・リレーションシップ・マネージャは、ＳＧまたはＳＧグループメンバーに報奨を与えることができることの根拠としてサービス論理を用いる。特に、PromoMax Expressは、報奨をリアルタイムでまたは各期間の終わりに適用するために用いられてもよい多数のカウンタを事業者が定義することを可能にする。各カウンタは、プロモーションのために用いられるべき期間とともに、名前で定義されている−提供されるオプションは、報奨を日、週、月または年単位で適用することができるというものである。各カウンタの単位は、現金、時間またはイベントの数がプロモーションの基準として用いられることを可能にする−そのため、たとえば、各日のコール時間に対するカウンタおよび各月の出費された現金に対するカウンタを構成してもよい。イベント数機能性により、コール、ＳＭＳ、またはCharging Max ＵＢＥで請求される任意の他のサービスの計数を追跡することが可能になる。

【0162】

Charging Max報奨は、期間の終わりにカウンタの終了中に計算されるか、報奨レベルに達するとセッション終了中にリアルタイムにファイヤされる（fired）かのいずれかである。これにより、事業者が短期間利用キャンペーンに対象を絞ること、またはこれにかえて、各月もしくは各年にわたる使用がプロモーションの基準として用いられる、より長い期間の戦略を考えることが可能になる。

【0163】

このサービスは、ＳＧ内の挙動のカウンタを可能にするように開発される。また、ソーシャル・リレーションシップ・マネージャは、ＳＧ別カウンタが他のＳＧ／ＳＧグループメンバーと比較されることを可能にする。カウンタは、以下について利用可能である。
・ＳＧ作成日
・ＳＧメンバー数
・ＳＧのＡＲＰＵ
・ＳＧ内の個々のＳＧメンバーのＡＲＰＵ
・個々のＳＧメンバーのための制御プランのためのＣＣＳにおける性能に従った特定のサービスへの出費
・個々のＳＧのための制御プランのためのＣＣＳにおける性能に従った特定のサービスへの出費
・個々の加入者がメンバーであるＳＧの数
各サービスおよび料率シナリオが定義されると、更新されるべきカウンタは、プロモーションの一部としてどのサービスが用いられるかについての完全な制御を事業者に与えるように選択される。

【0164】

支出額を以下の方法のうち１つで追跡してもよい。
−現金支出額追跡：これにより加入者が出費した通貨量が追跡される
−時間追跡：これにより加入者のコール時間が追跡される（音声コールのみ）
−単位追跡：これにより加入者が行ったコール／送信したＳＭＳの量が追跡される
各報奨方式に対して異なる追跡方法を構成することが可能であるものとするが、１つの報奨方式内において用いる追跡方法は、１つしかなくてもよい。

【0165】

各報奨方式内で、時間制限を構成し、この時間制限の後、追跡される支出額がリセットされるようにすることが可能であるものとする。可能性のある値は、日毎、週毎、月毎または年毎である。

【0166】

無制限クレジット報奨方式を定義してもよい。クレジット報奨方式において、以下のパラメータ、すなわち
・ＳＧメンバーの数
・ＳＧのＡＲＰＵ
・ＳＧ内の個々のＳＧメンバーのＡＲＰＵ
・個々のＳＧメンバーのための制御プランのためのＣＣＳにおける性能に従った特定のサービスへの出費
・個々のＳＧのための制御プランのためのＣＣＳにおける性能に従った特定のサービスへの出費
・個々の加入者がメンバーであるＳＧの数
からなる支出額またはグループの特定の大きさへの到達は、単一の支出額／大きさのしきい値に照らし合わせて、リアルタイムにかまたは支出額時間制限が切れるときにかのいずれかで評価される。その時点での累積された支出額値／グループの大きさに依存して、加入者の残高のうち１つ／管理者／グループ作成者／グループメンバーにクレジットを加えてもよい。

【0167】

以下のパラメータが設けられてもよい。
−報奨方式名
−追跡方法（現金、時間、単位）
−時間制限（日毎、週毎、月毎、年毎）
−寄与している宛先
−商品種類毎の支出額しきい値
−リアルタイムであるか否か（そうでない場合、報奨は、時間制限が切れるときに与えられる）
−リアルタイム報奨後、支出額カウンタをリセットするか（はいまたはいいえ）
−クレジットの加え先の残高の種類（商品種類に固有）
−クレジット値（商品種類に固有）
−クレジット有効期限（商品種類に固有）
報奨が与えられているとき、ＳＭＳがＳＧメンバー全員、個々のＳＧメンバー、および／またはＳＧ管理者／作成者に送信されるものとする。事業者が定義可能である。

【0168】

カウンタが定義されているサービスの現在の状況をユーザＳＭＳ（ＵＳＭＳ：User SMS）ＧＵＩを介して見ることが可能であるものとする（これはJavaスクリーンにおいて実現化されてもよい）。

【0169】

カウンタが定義されている現在の状況をeServGlobal ＰＩを介して見ることも可能であってもよい。

【0170】

ソーシャル・リレーションシップ・マネージャの機能性は、グループ業績に基づいてＳＧに報奨を与える能力である。報奨を共用の分（minutes）として与えることができる−これを通知ＳＭＳとしてグループ管理者に送信することができる。この機能は、ＳＲＭが従業員のグループを定義するために用いられるとき特に有用である。共用の分は、次にソーシャルグループメンバーによってＳＧ料金プランで消費される。共用の分を、ＳＧ一斉通信に対して支払うために最初に用いられる残高バケットとして定義することもできる。

【0171】

ＳＲＭを用いて定義することができる報奨方式の例を以下に示す。すべての例をＳＲＭを用いて実現化することが可能である。
・報奨が事業者によってオファーされる。１ヶ月以内にさらに１０ユーロの使用時間をＳＧコールに使用すると、ゴールドの商品種類に進む。加入者は、コミュニティ内コールに１０ユーロ使用するとすぐにリアルタイムでゴールドに進み、ＳＭＳを受信する。
・報奨−今月３００通のＳＭＳをＳＧメンバーに送信すると、月の残りの間、ＳＭＳが無料になる。一旦加入者が３００通のＳＧ ＳＭＳを使用すると、彼は、報奨に達したことと、彼が期間の終わりまで無料ＳＭＳを手に入れたこととを彼に知らせるＳＭＳを受信する。
・報奨−グループメンバーは、「おめでとうございます、貴方は月間最も長い間お話されたサフォーク大学グループメンバーです−貴方は、その月の間ビデオコールが８０％割引に無料でなります」というＳＭＳを受信する。
・報奨−グループは、彼らのＳＧの大きさに基づいて報奨を受けることができる。たとえば、あるグループは、定義可能な大きさ、たとえば１００人のグループメンバーに達したことにより報奨を受けることができる。グループがこの大きさに達するとリアルタイムで、メンバー全員は、何らかの報奨を受けることができる。
・報奨−他のグループと比較したグループの大きさに基づいて与えることができる。たとえば、「サフォーク大学」コミュニティのグループメンバーに「エセックス大学」と照らし合わせてより多くのグループメンバーを有することにより報奨を与えることができる。
・報奨−ある企業、eServGlobalは、ソーシャル・リレーションシップ・マネージャを用いて、その従業員のコミュニティグループを定義する。月の間、そのグループの電話通信実績に基づいて、彼らは１０００分のコミュニティ内共用分の資格を得る。グループ管理者に通知が行われる。この分は、ＳＧメンバー全員により平等にＳＧ利用に消費される。
・ソーシャルグループは、一旦出費が事業者が定義する特定のしきい値を超えると、よりよいグループ内料金を報奨として受けることができる。

【0172】

［エクリプスモデル事業者ウェブポータルＰＩコマンド］
加入者は、事業者が作成し管理するウェブサイトに登録時に与えられる彼らのパスワードを用いてログインすることができる。このウェブサイトは、外部ＰＩを用いてＣＭＸプラットフォームと相互作用する。このウェブサイトを用いて、ユーザは、彼らがメンバーである彼らのＳＧを管理し、彼らの口座およびＳＲＭプロモーションに関する情報を見ることができる。これは、網羅的なリストではない。なぜならばより多くの要件がＳＲＳ段階中に見つかってもよいためである。

【0173】

ＰＩコマンドを以下のアクションのうち少なくともいくつかに対して作成することが可能である。
・登録済加入者は、登録プロセス中に割当てられた彼らのニックネーム／ＭＳＩＳＤＮおよびパスワードを用いてログインすることができる。
・ログインした加入者は、彼らがメンバーである彼らのＳＧ（ニックネームおよびＭＳＩＳＤＮ）およびそのグループに対する対応の料金／割引を見ることができる
・ログインした加入者は、彼らがメンバーであるＳＧメンバーを見ることができる（ＭＳＩＳＤＮおよびニックネームで表示される）
・ログインした加入者は、彼らの現在の残高を見ることができる
・ログインした加入者は、彼らのＳＧサービスバンドルオプションを見ることができる
・ログインした加入者は、彼らのPromoMax Express残高を見ることができる−現在の状況および報奨に達するための目標など
・ログインした加入者は、許される彼らの最大ＳＧ数（事業者が定義している場合）および彼らの現在のＳＧの量を見ることができる
・ログインした加入者は、彼ら自身をＳＧから外すことができる
・管理者は、加入者をＳＧに参加するよう招待することができる
・管理者は、加入者をＳＧから外すことができる
・管理者は、管理者権限を他のＳＧメンバーに譲渡することができる
・管理者は、企業ウォレットを、ＳＧ内コールのために割当てることができる
・管理者は、企業ウォレットをすべてのＳＧメンバーコールのために割当てることができる
・管理者は、企業ウォレットを特定のＭＳＩＳＤＮに対するすべてのコールに割当てることができる
以下の節は、ＳＲＭエクリプスモデルを用いて加入者が利用可能なすべてのセルフケア機構に言及する。プロジェクトの範囲内で、セルフケアサービス論理フローが定義される。ＩＶＲ機構を用いて、加入者は、特にＳＲＭサービスのみとの関連で以下のアクションを行なうことができる。これは、網羅的なリストではない。なぜならばより多くの要件がＳＲＳ段階中に見つかってもよいためである。
・サービスの詳細を聞くことができる
・加入者がいくつのＳＧのメンバーになることが許されているのか聞くことができる
・加入者がいくつのＳＧのメンバーであるのか聞くことができる
・ＳＧ名（可能な場合）およびＳＧ番号を聞く
・ＳＧ料金／会費／サービスバンドルの詳細
・利用可能なサービスバンドルを聞く
・ＳＧサービスバンドルを購入する
・アクティブなサービスバンドルを聞く
・残っている分／クレジットなどを聞く
・ＭＣ ＳＭＳの受信をアクティブにする／非アクティブにする
・ホームゾーンセルＩＤを設定する
・アクティブなプロモーションを聞く
・現在のしきい値状況を聞く
・オファー中の報奨
ＳＧを解除するには、加入者は、単に解除するＳＧを選択し、次にこのアクションを確認するだけでよい。ＳＧが解除されると、このＳＧを解除する加入者にＳＭＳが送信される。

【0174】

［コマンドリスト代替例］
各ＳＭＳコマンドに対して、加入者があまり正確でない語を入力することがある可能性は高い。たとえば、コマンドアクションがＳＴＯＰ（停止する）であり加入者がＳＴＰと入力する場合、事業者が可能な限り多くのコマンド語の代替例を各コマンドに対して定義することが可能である。定義された代替例は、正確なコマンドが送信されたのと同じ効果を有する。

【0175】

［原子モデル］
実現化例の原子モデルの実施例を次に例として説明する。原子モデルは、関係が加入者間で形成されることがエクリプスモデルと異なる。原子モデルは、個々の加入者が他の加入者と「友達」であることを要請することによって関係を作成する。この関係は、双方向関係である。一旦関係が形成されると、料金または割引に関する特別な挙動を適用することができる。

【0176】

［標準原子ＳＲＭ機能性］
すべての加入者について、加入者がＳＲＭ原子モデルに関して取り得る状態は３つある。各状態をより詳細に以下に説明する。

【0177】

デフォルトで、全加入者は、サービスをアクティブにしている。このアクティブ状態において、加入者は、以下の機能性を有する。
・友達リクエストを受信し友達として加えられることができる（一方向関係）
・友達リンクを要請することはできない
・サービスを非アクティブにし、友達リンクリクエストの受信を停止することができる
・ＳＲＭに登録することができる
登録済加入者は、サービスを完全にアクティブにしている。機能性は、以下のとおりである。
・友達リクエストを受信し、友達として加えられることができる（双方向関係）
・友達リンクリクエストを要請することができる
・事業者ウェブサイトにログインして友達リンクを管理することができる
・サービスを非アクティブにし、友達リンクリクエストの受信を停止することができる
・定期料金の適用を受けることができる
非アクティブ化された加入者は、サービスを完全に非アクティブにしている。機能性は、以下のとおりである。
・友達リンクリクエストを受信することができない
・友達リンクリクエストを要請することができない
・友達リンクとして加えられることができる（一方向関係）
・登録を通じてサービスを再びアクティブにすることができる
ＳＲＭサービスへの登録
加入者がＳＲＭのすべての特徴の特典を受けるためには、加入者は、まずＳＲＭに登録しなくてはならない。登録済加入者であることの特徴のうち１つは、友達リンクリクエストを行なうことができることである。登録プロセス中、加入者は、彼らのニックネームをＳＲＭに登録することが要求される−そのため彼らが友達リンクリクエストを行なうと、これが要請されている側の加入者が見ることができる名前である。これを行うために、加入者は、事業者が定義するショートコードにＳＭＳを送信することができる。このショートコードは、以下の情報を含んでもよい。＜nickname consisting max number of characters as definable by operator（事業者が定義可能な最大文字数からなるニックネーム）＞が＜a short code operator definable（事業者が定義可能なショートコード）＞に送信される、たとえば、オリバー・ベケット→７７７。

【0178】

加入者が、事業者の定義可能な文字量を超える登録リクエストを送信した場合、事業者が定義可能なとおりの登録リクエストの送信の仕方を説明する返信ＳＭＳが送信される。

【0179】

名前は、ＭＳＩＳＤＮが固有の識別子であるため、重複する可能性がある。
一旦ニックネームまたは重複ニックネームがＳＲＭによって認可されると、確認ＳＭＳが登録する加入者に以下の形式で送信される。
・ＳＭＳは、＜nickname（ニックネーム）＞の確認を含む
・登録を完了するための１回限りの料金または会費の情報を含む。これは、返信の確認ＳＭＳによって適用される。

【0180】

ＳＭＳ例は、「貴方は、オリバー・ベケット１を貴方のニックネームとして選択されました。はい（Yes）と返信して確認するか（登録費用３ユーロ）または別のニックネームを選択するには再登録して下さい」または「貴方は、オリバー・ベケット１を貴方のニックネームとして選択されました。はい（Yes）と返信して確認するか（月毎の会費費用３ユーロ）または別のニックネームを選択するには再登録して下さい」であり得る。

【0181】

ニックネームの承認を確認し、１回限りの請求／会費（定義されている場合）を承認するためには、加入者は、このＳＭＳに以下の形式で返信することができる。＜yes（はい）＞。このコマンドは、事業者が定義可能であり、肯定する回答および否定する回答に対して複数の応答を定義してもよい。

【0182】

登録は、加入者が彼の口座に１回限りの料金または会費の費用を負担するのに十分な資金を有する場合にのみ完全なものとなる。

【0183】

ＳＲＭは、確認ＳＭＳを受信すると
・ニックネームまたは重複ニックネームを登録リクエストを送信したＭＳＩＳＤＮとともに登録する
・加入者が友達リクエストを行なうとこの名前および番号が友達リンク作成リクエストＳＭＳ上に表示されるようにこの情報を記憶する。

【0184】

ニックネームまたは重複ニックネームとＭＳＩＳＤＮとの間の関連が作成されると、登録中の加入者に確認が送信される。
・このＳＭＳは、ニックネームの確認を含む
・加入者は、登録済ＳＲＭ状態に進んでいる
ＳＲＭ例は以下のようであり得る。「ありがとうございました。ニックネーム、オリバー・ベケット１が登録されました」。

【0185】

加入者は、一旦登録済ＳＲＭ状態に入ると、以下に説明される機能性のすべてを有する。各ＭＳＩＳＤＮは、１つしかニックネームを作成できない。

【0186】

友達リンクの作成
加入者は、彼の友達へ定期的にコールしたいと思うであろう。しかしながら、彼は、友達がいるネットワークがどれか知らないかもしれない。ＳＲＭがあれば、加入者は、他のオンネット加入者と双方向友達リンクを、オフネット加入者と一方向友達リンクを作ることができる。加入者は、友達リンクリクエストを行なうことができるようになる前に、まず彼のニックネームおよび番号をＳＲＭプラットフォームに登録しなければならない。
加入者は、以下の２つの方法のうち一方で友達リンクを作成することができる。
１．要請される番号を含むＳＭＳを事業者が定義可能なショートコードに送信することによって。すなわち＜MSISDN of requested number（要請される番号のＭＳＩＳＤＮ）＞が＜operator definable short code（事業者が定義可能なショートコード）＞に送信され、たとえば、０７９６９５６５２３９が７７７に送信される。
２．要請されるＭＳＩＳＤＮの名刺を事業者が定義可能なショートコードに図４ａ-図４ｃにおけるように送信することによって。ＳＲＭは、この名刺からＭＳＩＳＤＮのみを抽出する。名刺が複数の識別を含む場合、これらは、エンドユーザ口座と関連付けられる。

【0187】

ＳＲＭは、以下の名刺に対応している：Ｖカード、Ｈカード、Ｎカードおよび／またはOpen Synch。

【0188】

加入者がこの友達リクエストを行なった後、以下のアクションが起こる。ＳＲＭは、ＭＳＩＳＤＮをプロセス１または２から取り、ＭＳＩＳＤＮがオンネット番号であるかどうかを確かめるためにＨＬＲを照合する。ＨＬＲを照合することにより、ＳＲＭは、ＭＳＩＳＤＮがオンネットであるかまたはオフネットであるか（＋オフネット番号の事業者名）を知る。ＳＲＭは、要請されたＭＳＩＳＤＮが登録済、アクティブ、または非アクティブ加入者であるか否かを照合する。

【0189】

ＳＲＭが要請されたＭＳＩＳＤＮの状態を照合することが必要である。これは、以下の理由による。
・非アクティブにされている加入者は、友達リンクリクエストを受信することができない
・アクティブにされている加入者は、友達リンクリクエストを受信することができる（一方向関係が形成される）
・登録済加入者は、友達リンクリクエストを受信することができる（双方向関係が形成される）
要請されたオンネットＭＳＩＳＤＮが非アクティブにされているＳＲＭ状態であるシナリオにおいて、以下のアクションが起こる。
・双方向友達作成リンクが自動的に作成されるが、それは、登録済加入者がサービスを非アクティブにしている友達リンクにコールすると、彼らは代替的な料金または割引を受けるというように、一方向関係としてのみ働く。
・サービスを非アクティブにしている加入者が友達リンク作成を要請した加入者にコールすると、ＳＲＭ料率決定に関して何も特別な挙動はない。それは、通常のコールである。
・非アクティブにされている加入者がＳＲＭ登録済加入者に将来なる場合、一方向関係として働いている双方向関係は、自動的に、完全に機能する双方向関係へと修復される。つまり、どちらか一方の加入者が他方にコールすると、それが友達リンク料金または割引を開始させる。

【0190】

友達関係が形成され、関連付けられた料金が有効となったというＳＭＳが登録済ＳＲＭ加入者に送信される。このＳＭＳは、事業者が定義可能であるが、要請されている友達リンクのＭＳＩＳＤＮを含むべきである。

【0191】

非アクティブにされているＳＲＭ加入者は、友達リンクリクエストに関するＳＭＳを受信しない。

【0192】

登録済加入者がアクティブにされている加入者に友達リンクリクエストを送信すると以下のアクションが起こる。
・双方向友達作成リンクが自動的に作成されるが、それは、登録済加入者がサービスをアクティブにしている友達リンクにコールすると、彼らが代替的な料金または割引を受けるというように、一方向関係としてのみ働く。
・サービスをアクティブにしている加入者が友達リンク作成を要請した登録済加入者にコールすると、ＳＲＭ料率決定に関して特別な挙動はない。それは通常のコールである。
・アクティブにされている加入者がＳＲＭ登録済加入者に将来なる場合、一方向関係として働いている双方向関係は、自動的に、完全に機能する双方向関係と修復される。つまり、どちらか一方の加入者が他方にコールすると、それが友達リンク料金または割引を開始させる。

【0193】

状態が「アクティブにされている」である場合、友達関係が形成され関連付けられた料金が有効となったというＳＭＳが登録済ＳＲＭ加入者に送信される。このＳＭＳは、事業者が定義可能であるが、要請された友達リンクのＭＳＩＳＤＮを含むべきである。

【0194】

双方向友達関係を作成するためまたは友達リンク関係を拒否するためには、加入者は、登録済ＳＲＭ状態になければならないことから、アクティブにされている加入者は、ＳＭＳで以下のオプションを提示される。
・招待側の加入者の＜nickname（ニックネーム）＞
・事業者が定義可能なＳＭＳ
例：「オリバー・ベケット１が友達リクエストを送っています。貴方がこの番号にコールするときに割引を受けるには、登録して下さい。貴方のニックネーム（最大２０文字）とともに返信下さい。サービスを非アクティブにするには、停止する（ＳＴＯＰ）とご返信下さい」。

【0195】

加入者が登録を通じて承認するために返信するシナリオにおいて、上記の登録プロセスが後に続く。加入者が友達リンクリクエストに返信しないシナリオにおいて、ＳＲＭ関係は、一方向関係として働き続ける。加入者が停止する（ＳＴＯＰ）と友達リンクリクエストに返信するシナリオにおいて、ＳＲＭは、要請された友達リンク加入者のＭＳＩＳＤＮを非アクティブにされている加入者として記憶する。このＭＳＩＳＤＮは、ＳＲＭを非アクティブにされている加入者に対して定義されているとおりのＳＲＭ機能性を受けるようになる。

【0196】

登録済加入者が友達リンクリクエストを別の登録済ＳＲＭ加入者に送信すると、以下のアクションが起こる。友達関係が形成され、関連付けられた料金が有効となったというＳＭＳが招待する側の加入者に送信される。これは、登録済加入者であるので、要請された番号は、既に関連付けられたニックネームを有する。これをＳＭＳに挿入することができる。このＳＭＳは、事業者が定義可能である。このＳＭＳは、招待された側の加入者のＭＳＩＳＤＮおよびニックネームを含むべきである。ＳＭＳ例は以下のようであり得る。「ありがとうございました。＜Oliver Becket1（オリバー・ベケット１）＞＜０７９５７３２９０４９６７＞との友達リンクが形成され、友達リンク料金が適用されるようになりました」。

【0197】

別の加入者が友達リンクを要請したというＳＭＳが、招待された側の加入者に送信される。このＳＭＳは、事業者が定義可能であり、要請する側の加入者のニックネームを含むべきである。ＳＭＳは、以下のオプションを提示する：承認するには何もしない。拒否するには＜no（いいえ）＞と返信する。サービスを非アクティブにするには、＜STOP（停止する）＞と返信する。一例は以下のとおりである。「オリバー・ベケット１２３４５６７は、友達リクエストを送信しました。承認するには、何もしないで下さい−友達リンク料金が現在適用されています。拒否するには、いいえ（ＮＯ）と返信して下さい。サービスを非アクティブにするには、停止する（ＳＴＯＰ）と返信して下さい。」
要請される側の加入者は、友達リンクを作成しようとしている加入者の名前をはっきりと見ることができる。

【0198】

サービスがプラットフォーム上に有する負荷を少なくし、これによりサービスをエンドユーザの観点からより簡単にするために、友達関係は、自動的に形成され、友達リンク料金がＳＭＳにおいて説明されたように適用されるようになる。

【0199】

加入者は、友達リンクリクエストを承認するために何もアクションを起こす必要がない。友達リンク料金は自動的に適用される。

【0200】

友達リクエストを受信する側の加入者がリンクが作られることを望まない場合、彼らは、ショートコードにいいえと返信することができる。これらの「拒否」ＳＭＳは、それら独自の請求可能なイベント料金を事業者によって定義されるように有する。このＳＭＳを無料にすることが可能である。別の加入者が友達リンクを請求したというＳＭＳは、招待された側の加入者にも送信される。以下は、このプロセスをいっそう詳細に説明する。

【0201】

友達リンクリクエストを拒否するためには、登録済加入者は、単に事業者が定義可能なショートコードに以下の形式からなるＳＭＳを送信することによって、このＳＭＳに返信することができる。
・＜NO（いいえ）＞が＜operator definable short code（事業者が定義可能なショートコード）＞に送信される
友達リンクを作成しないというコマンドが送信された後、以下の論理が起こる。

【0202】

友達リクエストが行なわれなかったことを確認するＳＭＳが招待される側の加入者へ送信される。それは、リクエストを行なった登録済加入者のニックネームを含み、事業者が定義可能である。一例は以下のようであり得る「ありがとうございました。これはオリバー・ベケット１からの友達リクエストが作成されなかったことを確認するものです。友達リンク料金は適用されません」。

【0203】

ＳＭＳがリクエストを行なった登録済加入者へ送信されて、友達リクエストが拒否されたことを説明する。それは、事業者が構成可能であるが、招待された側の友達リンク加入者のニックネームおよびＭＳＩＳＤＮを含むべきである。一例は、以下のようであり得る「残念ながらオリバー・ベケット１２３４５６７ ０７９７８３６３７２８３は、貴方の友達リクエストを拒否しました。友達リンク料金は適用されなくなりました」。ＳＲＭ友達リンク料金は、これらの２人の加入者間のコールには適用されない。

【0204】

友達リンクリクエスト オンネット−オフネット
上記のＨＬＲチェックの後、要請された友達リンク加入者がオンネット加入者であるのかオフネット加入者であるのかは、既知である。この節は、それがオフネット加入者であり、紹介方式が実現化されないときに起こる論理を詳細に説明する。紹介方式は以下に説明される。

【0205】

要請されたＭＳＩＳＤＮがオフネットである場合、登録済の要請する側のＭＳＩＳＤＮと要請される側のオフネットＭＳＩＳＤＮとの間に一方向関係が形成される。

【0206】

番号がオフネットである場合、確認ＳＭＳが招待する側の加入者に送信される。それは、事業者が定義可能であるが、招待される側のオフネット加入者のＭＳＩＳＤＮを含むべきである。一例は以下のようであり得る「ありがとうございました。０７９７８３３２９５４９３０が貴方の友達に加えられました」。

【0207】

多くの国において、要請された友達がオフネット番号であっても、彼らが友達リクエストを拒否するオプションを有さなくてはならないことが要件である。このため、以下の論理が適用される。オンネット加入者が友達リンクを要請したというＳＭＳが、招待される側のオフネット加入者へ送信される。このＳＭＳは、事業者が定義可能であり、以下を含むべきである。
・送信者番号は、長い番号であり、ショートコードではない
・要請する側の加入者のニックネームを含む
・招待する側の加入者ネットワークからの事業者名を含む
・以下のオプションを提示する：承認するには何もしない。拒否するには＜no（いいえ）＞と返信する。
一例は、以下のとおりである「＜esgTel＞からのオリバー・ベケット１が友達リクエストを送信しました。承認するには何もしないで下さい。拒否するにはいいえ（ＮＯ）と返信して下さい」。
もしオフネット加入者が返信して友達リクエストを拒否する場合、すべての友達リンク関係が変形される。確認ＳＭＳは、両当事者へ送信され、事業者が定義可能である。

【0208】

ＳＲＭ紹介方式を実現化することも可能である。この機能性は、以下に説明される。
友達問合せ
登録済加入者が彼らの友達リンクを問合せることは、たとえば事業者が定義可能なショートコードにコマンド語を送信することによって可能である。たとえば＜query（問合せ）＞が７７７へ送信される。

【0209】

ＳＲＭは、作成されたすべての友達リンクのリストをＳＭＳを介して送信する。このＳＭＳは、すべての友達リンク−好ましくはニックネームとＭＳＩＳＤＮとの両方、のリストを含む事業者が定義可能なメッセージである。

【0210】

加入者が個々のＭＳＩＳＤＮを問合せして、彼らが友達リンクであるかどうか確かめることが可能である。ＳＲＭは、はい／いいえの返答と、事業者が定義可能なメッセージとを返信する。

【0211】

友達リンク解除
登録済加入者が友達リンクをそれらが作成されてしまってから解除することが可能である。これを行なうためには、加入者は、単に彼らが解除したいリンクのＭＳＩＳＤＮまたは名刺またはニックネームをショートコードに送信する必要がある。たとえば、＜０７９４７２９８４８７２９＞が１０００に送信される。

【0212】

友達リンクを解除する側の加入者にＳＭＳが送信される−これは、事業者が定義可能であるが、解除される側の加入者のニックネームおよび彼らのＭＳＩＳＤＮを含むべきである。一例は、「これはオリバー・ベケット０３２８４７６２８４８４８９との友達リンクが解除されたことを確認するものです。友達リンク料金は、適用されなくなりました」であり得る。

【0213】

友達リンクが解除されたことを知らせるＳＭＳが解除された友達に送信される。それは、事業者が定義可能だが、解除する側の加入者のニックネームを含むべきである。ＳＭＳ例は、以下のようであり得る。「残念ながら、オリバー・ベケット１は、貴方の友達リンクを解除しました。友達リンク料金は、このユーザとは適用されなくなりました」。

【0214】

一旦友達リンクが作成されてからのＳＲＭ挙動
作成された友達リンクがあるようになったならば、両加入者に何らかの特典がなくてはならない。これは、形成された関係があるようになったならば、代替的な料金または割引をそのコールの費用に対して請求してもよいためである。以下は、定義することができる機能である。

【0215】

ＳＲＭは、友達リンクが作成されている別の加入者へのコール時に優遇料率がアクティブにされることを可能にする。別の友達リンクにコールするとき、割引を受けることがあり得、たとえば２０％である。事業者は、音声コールまたはＳＭＳなど、どのサービスをこの方式に含まれるものとするかを定義しなくてはならない。

【0216】

代替的なＳＲＭ料金が以下のものに適用されるかを否かを定義することが可能であるものとする。
−ホーム公衆陸上移動ネットワーク（ＨＰＬＭＮ：Home Public Land Mobile Network）音声、ビデオ、ファックスまたは回線交換コール
−ＨＰＬＭＮ ＳＭＳまたはＭＭＳ ＭＯ
−ＨＰＬＭＮコールとＨＰＬＭＮ ＭＯメッセージングとの任意の組合せ
−いずれにも適用されない（商品種類に対してＳＲＭが無効にされている）
ＳＲＭサービスは、選択されたネットワークサービスに対して全商品種類にわたって有効にされているものとし、ＣＣＳの性能とその後の制御プラン論理とに結びつけられている。

【0217】

各適用可能なサービスについて、加入者に適用される料金／割引は、定義されている商品種類に依存する。たとえば、事業者は、ブロンズ、シルバー、およびゴールドの３つの別個の商品種類を有してもよい。友達リンク料金は、以下のとおり定義される。

【0218】

【表2】

【0219】

友達リンク加入者間の音声コールに対する代替的な料金を構成することが音声コールに対する通常の料金プランに優先して有効となる代替的な料金プランの使用を通じて可能であるものとする。これは、商品種類毎に構成可能であり、すべての発呼者に対して同じ割引プランであり得る。

【0220】

友達リンク加入者間の音声コールに対する代替的な料金を設定することが音声コールに対する通常の料金プランに優先して有効となる割引プランの使用を通じて可能であるものとする。これは、商品種類毎に構成可能であり、すべての発呼者に対して同じ割引プランであり得る。

【0221】

友達リンク加入者間のビデオコールに対する代替的な料金を構成することがビデオコールに対する通常の料金プランに優先して有効となる代替的な料金プランの使用を通じて可能であるものとする。これは、商品種類毎に構成可能であり、すべての発呼者に対して同じ料金プランであり得る。

【0222】

友達リンク加入者間のビデオコールに対する代替的な料金を設定することがビデオコールに対する通常の料金プランに優先して有効となる割引プランの使用を通じて可能であるものとする。これは商品種類毎に構成可能であり、すべての発呼者に対して同じ割引プランであり得る。

【0223】

友達リンク加入者間のＳＭＳに対する代替的な料金プランを構成することがＳＭＳに対する通常の料金プランに優先して有効となる料金プランの使用を通じて可能であるものとする。これは、商品種類毎に構成可能であり、すべての発呼者に対して同じ料金プランであり得る。

【0224】

友達リンク加入者間のＳＭＳに対する代替的な割引料金を構成することがＳＭＳに対する通常の割引プランに優先して有効となる割引プランの使用を通じて可能であるものとする。これは、商品種類毎に構成可能であり、すべての発呼者に対して同じ料金プランであり得る。

【0225】

友達リンク加入者間で送信されるＭＭＳに対する代替的な料金を構成することがＭＭＳに対する通常の料金プランに優先する料金プランの使用を通じて可能であるものとする。これは、商品種類毎に構成可能であり、すべての発呼者に対して同じ料金プランであり得る。

【0226】

友達リンク加入者間のＭＭＳに対する代替的な割引料金を構成することがＭＭＳに対する通常の割引プランに優先する割引プランの使用を通じて可能であるものとする。これは、商品種類毎に構成可能であり、すべての発呼者に対して同じ料金プランであり得る。

【0227】

ＳＲＭ割引または料金がコールまたはメッセージに適用される場合、ＵＢＥによって作成されるＥＤＲにタグが付加されるものとする。一例は、ＳＥＲＶＩＣＥ＝ＳＲＭであり得る。

【0228】

ＳＲＭサービスを通じて割引が得られた場合、適用可能であるかもしれないがＳＲＭよりも低い優先度を有するように設定されている後続の付加価値サービは、いずれも省かれ、さらなる割引はこれらの付加価値サービスからは得られない。

【0229】

各ＳＲＭ加入者に毎期間に請求される任意選択的な繰返し発生するＳＲＭ会費をセットアップすることも可能であるものとする。この料金の額は、商品種類毎に構成可能であるものとする。この料金は、ＳＲＭに登録する際自動的に適用され、その後最後の料金が適用されてから３０日毎に適用されるものとする。この料金が適用されたときは毎回、通知ＳＭＳが送信されるものとする。

【0230】

ＳＲＭ会費のための繰返し発生する月毎の料金が適用されるときに加入者が十分なクレジットを有していない場合、通知ＳＭＳがこの加入者に送信されるものとし、構成可能な日数（最小１日、最大５日）継続するＳＲＭ猶予期間が開始するものとする。この猶予期間中、ＳＲＭサービスは、その加入者に対してアクティブのままであるものとする。

【0231】

再入金が猶予期間中になされた場合、サービスは、月毎の会費を適用しようと二回目に試みるものとする。この試みが成功した場合、サービスを以前通り再開するものとする。この試みが失敗した場合、この加入者に対するＳＲＭサービスは、システムによって非アクティブにされるものとする。両方の場合において、通知ＳＭＳが加入者に送信されるものとする。

【0232】

もし加入者が猶予期間が終わった後でさえＳＲＭサービスに対する月毎の料金を支払わない場合、加入者は、ＳＲＭが非アクティブにされている状態に進む。彼らが、サービスを再びアクティブにすることを十分なクレジットを有するときに望む場合、彼らは、ＳＭＳをショートコードに送信することによってこれを行なうことができる。ＳＲＭは、この加入者を彼らのＭＳＩＳＤＮから認識する。通知期間中に加入者がＳＲＭサービスを再びアクティブにすることは可能でないものとする。

【0233】

加入者は、会費を支払えなかった後、ＳＭＳをショートコードに送信することによって登録済ＳＲＭ状態に進むことが可能である。これは、通知期間の後までは起こることができない。メッセージは、以下の形式を含んでもよい：＜re-register（再登録）＞が＜operator definable short code（事業者が定義可能なショートコード）＞に送信される。支払いが無事引落とされた後、作成された以前の友達リンクはすべて修復される。

【0234】

繰返し発生する毎月の料金がＳＲＭサービスに対して請求される場合において、加入者によるＳＲＭサービスの非アクティブ化は、当該加入者が既に会費を支払った期間の終わりに漸く効力を生じるものとする。この通知期間の終わりに（すなわち最終の月毎の期間）、繰返し発生する料金は、適用されなくなるものとし、加入者のＳＲＭサービスは、システムによって非アクティブにされるものとする。加入者は、ＳＲＭが非アクティブにされた状態に進む。

【0235】

ＳＲＭサービスに対して繰返し発生する料金が請求されない場合においてまたは猶予期間中に加入者がＳＲＭサービスを非アクティブにする場合において、通知期間はないものとし、ＳＲＭサービスの非アクティブ化は、直ちに効力を生じるものとする。加入者は、ＳＲＭが非アクティブにされている状態に直ちに進む。

【0236】

友達リンクコールの通知
加入者にとって友達リンクにコールする／にメッセージを送信するとき最も重要な要素は、そのコールの費用が特別な友達リンク内料金／割引／サービスバンドルで料率を定められていることを彼が認識していることである。これは、２つの別個の機構を通じて達成することができる。

【0237】

友達リンクコールを行うとき、「リンリン」音に接続される前に、加入者は、事業者が定義可能なメッセージを伝える短いメッセージを聞く。
・たとえば、事業者が定義する通りに「これは友達リンクコールです」
・これは、セルフケア機構を用いて加入者がビープ音と置き換えるかまたは省略することができる。

【0238】

ＳＭＳを加入者に送信して、彼にコールまたはＳＭＳの費用、新旧の残高およびコールが友達リンクコール／ＳＭＳとして料率を定められされたことを知らせることができる。

【0239】

［原子ＳＲＭ＋紹介方式］
加入者が別の加入者を友達リンクになるよう招待するときに、この加入者がオフネット加入者である場合、事業者が彼らのネットワークに紹介方式を導入しているならば、ＳＲＭ紹介方式の一部として以下のアクションも起こる。オフネットＭＳＩＳＤＮおよび対応するネットワークがＳＲＭデータベースに送信される。事業者は、これらのオフネット番号についてレポートをオンデマンドで行なうことができる。レポート中の情報は、オフネット加入者に対象を絞ったキャンペーンにおいて用いることができる。

【0240】

加えて、ＳＭＳが事業者によって定義可能なようにオフネット加入者へ送信される。それは少なくとも以下を含んでもよい。
・彼らを要請したオンネット加入者のニックネーム
・事業者名
・事業者が定義可能なテキスト
・一例は、以下のとおりであり得る：オリバー・ベケット１は、貴方に＜esgTel＞に参加してほしいと思っています。貴方の番号を＜esgTel＞に届けて、１０ユーロの無料クレジットを受取って下さい。

【0241】

番号がオフネットである場合、確認ＳＭＳが招待する側の加入者に送信される。それは、事業者が定義可能だが、招待される側のオフネット加入者のＭＳＩＳＤＮと紹介メッセージとを含むべきである。一例は以下のとおりであり得る：「ありがとうございました。０７９７８３３２９５４９３０が貴方の友達リンクに加えられました。彼らはesgTelの加入者ではありません−彼らが参加する場合、貴方に１０ユーロの無料クレジットが報奨として与えられます。」
被紹介者が予め定められた期間ネットワーク内にいなかったことを確実にする制御機構があることが必要である。これを制御する１つの機構は、オフネット番号からポートされた番号のみが報奨を受けることが許されるというものである。

【0242】

ポートされた番号のみが紹介方式の対象となる。事業者が彼らのネットワークに番号ポータビリティを導入していることが要件である。

【0243】

ポートされた番号が事業者のネットワークに参加する場合、報奨は、紹介者と被紹介者との両者のウォレットに自動的に送信され、両者にこれを確認する事業者が定義可能なＳＭＳが送信される。

【0244】

［原子ＳＲＭ＋サービスバンドル］
友達リンクコールを広めるための別の機構は、サービスバンドルの使用を通じてである。このやり方において、登録済ＳＲＭ加入者は、友達リンクサービスバンドルを購入することができる。サービスバンドルは、加入者が購入したクレジットを特定のサービスでの使用に利用可能なクレジットに変換することを可能にする。単純な「友達リンクバンドル」の例は、次の１ヶ月以内に友達リンクに使用するための１０００通のＳＭＳのパッケージをたった１０ユーロでユーザが購入することができるというものである。

【0245】

事業者が、ＳＲＭの月毎の会費がないというキャンペーンを定義することができることが提案される。さらに、形成することができる友達リンクの数の制限または友達リンクコールに対する別個の料金／割引がないことが提案される。これに代えて、加入者は、彼らがそれを必要とするときまたは月単位でこの種のコールのためのサービスバンドルを購入する。彼らのバンドルが使い尽くされた場合、友達リンクコールが行われると、それは、後続のサービスバンドルが購入されるまで彼らの通常の料金に従って請求される。

【0246】

オファー中のサービスバンドルの範囲を事業者は定義することができ、たとえば以下のとおりである。

【0247】

【表3】

【0248】

サービスバンドルサービスは、事業者が１０件までの友達リンクサービスバンドルクレジット移行を定義することを可能にする。サービスバンドルクレジット移行の結果、加入者のウォレットから引落しがなされ（サービスバンドルの費用）、加入者のウォレットにクレジットが加えられる（サービスバンドルのクレジット値）。

【0249】

各友達リンクサービスバンドルに対して、以下のパラメータを定義してもよい。
−バンドル名
−バンドルの費用
−バンドルのクレジット値
バンドルの費用は、現金で表記されるものとする。

【0250】

バンドルのクレジット値は、４つの残高クレジットからなるものとし、これにより、以下のパラメータを各残高クレジットに対して指定する必要がある。
−残高の種類（すべての既存の請求可能な残高の種類が許可される）
−再入金価値（残高の種類に応じて現金、時間または単位で表現される）
−有効期限（日数で表示される）
友達リンクサービスバンドルは、友達リンクコールまたはメッセージにしか消費することができない。

【0251】

加入者が十分なクレジットを有するという条件で、友達リンクサービスバンドルを１回限りの料金を用いて購入することが可能であるものとする。

【0252】

構成されたサービスバンドルが自動的に各月に購入されることをもたらす、繰返し発生するサービスバンドル会費をセットアップすることが可能であるものとする。このサービスバンドルが購入されたときは毎回、通知ＳＭＳが送信されるものとする。最初のサービスバンドル購入は、加入者が会費をアクティブにすると起こるものとする。

【0253】

加入者は、一度に単一のサービスバンドルにしか加入できない。たとえ加入者がアクティブなサービスバンドル会費を有していたとしても、加入者がサービスバンドルを購入することは可能であるものとする。

【0254】

月毎のサービスバンドル購入が実行されるとき加入者が十分なクレジットを有していない場合、通知ＳＭＳがこの加入者に送信されるものとし、構成可能な日数（最小１日、最大５日）間継続する猶予期間が開始するものとする。

【0255】

猶予期間の終わりに、サービスは、サービスバンドルを購入しようと二回目に試みるものとする。この試みが成功した場合、サービスバンドル会費は、アクティブなままであるものとする。この試みが失敗した場合、この加入者に対するサービスバンドル会費は、システムによって非アクティブにされるものとする。両方の場合において、通知ＳＭＳが加入者に送信されるものとする。

【0256】

ＵＳＭＳ ＧＵＩ（Javaスクリーン）を介してサービスバンドルを購入および加入／加入解除することが可能であるものとする。

【0257】

加入者がeServGlobal ＰＩを介してサービスバンドルを購入および加入／加入解除することが可能であるものとする。

【0258】

加入者は、ＩＶＲセルフケアインターフェイスを通じてサービスバンドルを購入および加入／加入解除することができるものとする。

【0259】

［原子ＳＲＭ＋PromoMax Express］
PromoMax Expressライセンスは、報奨をリアルタイムでまたは各期間の終わりに適用するために用いられてもよい多数のカウンタを事業者が定義することを可能にする。各カウンタは、プロモーションのために用いられるべき期間とともに、名前で定義されている−提供されるオプションは、報奨を日、週、月または年単位で適用することができるというものである。各カウンタの単位は、現金、時間またはイベントの数がプロモーションの基準として用いられることを可能にする−そのため、たとえば、各日のコール時間に対するカウンタおよび各月に出費された現金に対するカウンタを構成してもよい。イベント数機能性により、コール、ＳＭＳまたはChargingMax ＵＢＥで請求される任意の他のサービスの計数を追跡することが可能になる。

【0260】

各サービスおよび料率決定シナリオが定義されると、更新されるべきカウンタは、プロモーションの一部としてどのサービスが用いられるのかの完全な制御を事業者に与えるように選択される。

【0261】

ChargingMax報奨は、期間の終わりにカウンタの終了中に計算されるか、報奨レベルに達するとセッション終了中にリアルタイムにファイヤされるかのいずれかである。これにより、事業者が短期間利用キャンペーンに対象を絞ること、またはこれに代えて、各月または各年にわたる使用がプロモーションの基準として用いられる、より長い期間の戦略を考えることが可能になる。

【0262】

達した報奨に基づいて、クレジット報奨のみを与えてもよい。
クレジット報奨では、加入者に彼の支出額の分析に基づいてクレジットを与えてもよい。たとえば、加入者が昨月コールするために１０ユーロを出費した場合、彼らは、来月の第１週に使用されてもよい５ユーロの国内コール時間クレジットを受取るかもしれない。

【0263】

PromoMax Expressサービスは、事業者が１つの料金報奨方式および３つまでのクレジット報奨方式を定義することを可能にする。このシステムは、加入者の支出額を常時監視するものとし、報奨方式において定義されたパラメータに従って加入者に報奨を与えるものとする。
友達リンク宛の以下のサービスに対する加入者の支出額を追跡することが可能であるものとする。
−ＨＰＬＭＮ ＭＯ音声またはビデオコール
−ＨＰＬＭＮ ＳＭＳまたはＭＭＳ ＭＯ
−ＨＰＬＭＮ ＭＯ音声またはビデオコールとＨＰＬＭＮ ＳＭＳまたはＭＭＳ ＭＯとの組合せ
選択されたサービスは、すべての報奨方式においてかつすべての商品種類にわたって支出額追跡に寄与するものとする。

【0264】

支出額追跡は、すべての商品種類にわたってすべての定義された報奨方式に対して使用可能であるものとする。

【0265】

支出額を以下の方法のうち１つで追跡してもよい。
−現金支出額追跡：これにより加入者が友達リンクコールに出費した通貨額が追跡される
−時間追跡：これにより加入者の友達リンクコールでのコール時間が追跡される
−単位追跡：これにより加入者が友達リンクに行ったコール／送信したＳＭＳの量が追跡される
各報奨方式に対して異なる追跡方法を構成することが可能であるものとする。１つの報奨方式内において用いる追跡方法は、１つしかなくてもよい。

【0266】

各報奨方式内で、時間制限を構成し、この時間制限の後、追跡される支出額はリセットされるようにすることが可能であるものとする。可能性のある値は、日毎、週毎、月毎、および年毎である。

【0267】

３つまでのクレジット報奨方式を定義してもよい。クレジット報奨方式において、各加入者の支出額は、単一の支出額しきい値に照らし合わせてリアルタイムでかまたは支出額時間制限が切れるときかのいずれかで評価される。その時点で累積された支出額値に依存して、加入者の残高のうち１つにクレジットを加えてもよい。

【0268】

以下のパラメータが提供される必要がある。
−報奨方式名
−追跡方法（現金、時間、単位）
−時間制限（日毎、週毎、月毎、年毎）
−寄与している宛先
−商品種類毎の支出額しきい値
−リアルタイムであるか否か（そうでない場合、報奨は、時間制限が切れるとき与えられる）
−リアルタイム報奨後、支出額カウンタをリセットするか（はいまたはいいえ）
−クレジットの加え先の残高の種類（商品種類に固有）
−クレジット値（商品種類に固有）
−クレジット有効期限（商品種類に固有）
報奨が与えられる前に、ＳＭＳが加入者に事前に送信されるものとする。事業者は、このメッセージがどれだけ前に送信されるかを定義することができる。これに代えて、報奨が与えられているとき、通知ＳＭＳが加入者へ送信されるものとする。

【0269】

加入の支出額をたとえばeServGlobal ＰＩのようなＵＳＭＳ ＧＵＩ（Javaスクリーン）を介して見ることが可能であるものとする。

【0270】

プロモーション例
−報奨が事業者によってオファーされる。１ヶ月以内にさらに１０ユーロの使用時間を友達リンク内のコールに使用すると、ゴールドの商品種類に進む。加入者は、友達リンクコールに１０ユーロ使用するとすぐにリアルタイムでゴールドに進み、ＳＭＳを受信する。
−報奨−今月３００通のＳＭＳを友達リンクに送信すると、月の残りの間、ＳＭＳが無料になる。一旦加入者が３００通の友達リンクＳＭＳを使用すると、彼は、報奨に達したことと、彼が期間の終わりまで無料ＳＭＳを手に入れたこととを知らせるＳＭＳを受信する。
−報奨−アクティブな友達リンクユーザは、「おめでとうございます、貴方は、貴方の友達の中で、月間最も長い間お話された友達です−貴方は、その月の間ビデオコールが８０％割引に無料でなります」というＳＭＳを受信する。
−報奨−個人は、彼らが作成した招待友達リンクの量に基づいて報奨を受けることができる。たとえば、友達加入者は、彼が作成した特定の量の友達リンク、たとえば拒否されなかった１００件の友達リンクリクエスト、を有することに対して報奨を受けることができる。加入者がこの量の友達を得るとリアルタイムで、個々の友達は、何らかの報奨を受ける。
−報奨−個々人に彼らが作成した友達リンクの数に基づいて与えることができる。たとえば、今月２０件の友達リンクリクエストを行なうと２０通の友達リンクＳＭＳという報奨を受ける。

【0271】

［原子ＳＲＭセルフケア］
以下の節は、ＳＲＭ原子モデルを用いて加入者が利用可能なすべてのセルフケア機構に言及する。プロジェクトの範囲内で、セルフケアサービス論理フローが定義される。

【0272】

ＩＶＲ機構を用いて、加入者は、特にＳＲＭサービスのみとの関連で以下のアクションを行なうことができる。これは、網羅的なリストではない。なぜならば、より多くの要件がＳＲＳ段階中に見つかってもよいためである。
・サービスの詳細を聞くことができる
・加入者がいくつの友達リンク持つことが許されているのか聞くことができる
・加入者がいくつの友達リンクを有するのか聞くことができる
・友達リンクニックネーム（可能な場合）およびＭＳＩＳＤＮを聞く
・友達リンク料金／会費／サービスバンドルの詳細
・利用可能なサービスバンドルを聞く
・友達リンクサービスバンドルを購入する
・アクティブなサービスバンドルを聞く
・残っている分／クレジットなどを聞く
・アクティブなプロモーションを聞く
・現在のしきい値状況を聞く
・オファー中の報奨
［原子ＳＲＭ事業者ウェブポータルＰＩコマンド］
加入者は、事業者が作成し管理するウェブサイトにログインすることができる。登録時、各友達は、事業者が管理するウェブサイトを通じて彼らの口座にアクセスするのに要求されるパスワードを提供される。このウェブサイトは、外部ＰＩを用いてＣＭＸプラットフォームと相互作用する。このウェブサイトを用いて、ユーザは、彼らの友達リンクを管理し、彼らの口座およびＳＲＭプロモーションに関する情報を見ることができる。

【0273】

以下の動作に対してＰＩコマンドを作成することが可能である。
・登録済加入者は、登録プロセス中に割当てられた彼らのニックネーム／ＭＳＩＳＤＮおよびパスワードを用いてログインすることができる
・ログインした加入者は、彼らの友達リンク（ニックネームおよびＭＳＩＳＤＮ）を見ることができる
・ログインした加入者は彼らの現在の残高を見ることができる
・ログインした加入者は彼らの友達リンク料金／割引を見ることができる
・ログインした加入者は彼らの友達リンクサービスバンドルオプションを見ることができる
・ログインした加入者は、彼らのPromoMax Express残高を見ることができる−現在の状況および報奨に達するための目標など
・ログインした加入者は、許される彼らの最大友達リンク数（定義されている場合）および彼らの現在の友達リンクの量を見ることができる
・ログインした加入者は、友達リンクを解除することができる。友達リンクを解除するには、加入者は、単に解除されるべき友達リンクを選択し、次にこのアクションを確認するだけでよい。友達リンクが解除されると、ＳＭＳが友達リンクを解除する側の加入者に送信され、ＳＭＳが解除された側の友達に送信される。これらのＳＭＳは、加入者解除プロセスに従っている。

【0274】

［原子ＳＲＭコマンドリスト代替例］
各ＳＭＳコマンドに対して、加入者があまり正確でない語を入力することがある可能性は高い。たとえば、コマンドアクションがＳＴＯＰ（停止する）であり加入者がＳＴＰと入力する場合、事業者が可能な限り多くのコマンド語の代替例を各コマンドに対して定義することが可能である。

【0275】

［ＳＲＭオプションソーシャルモデル］
複数のソーシャルネットワーキングサイトにわたって実行されるアプリケーションを開発することが可能である。本明細書中に説明されるアプリケーションは、ユーザによりネットワーキングサイトのポータル内にインストールされることができ、柔軟性のあるChargingMaxプラットフォーム（ＣＭＸ：ChargingMax platform）とインターフェイスで接続することができる。

【0276】

［ＳＲＭアプリケーション］
ＳＲＭによって開発されたアプリケーションは、OpenSocial ＡＰＩを用いてソーシャルネットワーキングサイトにわたって立上げられる可能性がある。このアプリケーションは、加入者に彼らの携帯電話番号をアプリケーションに入力する可能性を与える。次にアプリケーションは、アプリケーションを実行中で関係をインストールした各ユーザについて「友達」情報を取出す。したがって、友達関係情報は、自動的に結び付けられる。ＳＲＭアプリケーションは、次にＣＭＸプラットフォームとインターフェイスで接続し、この友達関係情報および対応するＭＳＩＳＤＮを通信する。次にＣＭＸプラットフォームは、これらの関係についての制御論理を実行することができる。たとえば、両者とも同じソーシャルネットワーキングサイト上で友達である２人の人が、このアプリケーションをインストールしており、彼らが互いにコールすると、コールの費用は、ＳＲＭ料金または割引に従って料率を定められる。アプリケーションは、事業者に固有なものであり、たとえばOrange ＵＫ加入者専用である。

【0277】

ソーシャルネットワーキングサイトアプリケーションは、変化があると、友達関係および携帯番号をChargingMaxプラットフォームで更新する。友達関係は、リアルタイムで最新のものに保たれる。これには、外部ＰＩが使用される。

【0278】

［アプリケーション設計］
ＳＲＭアプリケーションに関する主なコンセプトは以下のとおりである。
・OpenSocial ＡＰＩを用いているソーシャルネットワーキングサイト上のユーザは、事業者からであるように見えるアプリケーションをインストールすることができ、たとえば、マイスペース上のユーザは、Esg−Telアプリケーションをインストールすることができる
・アプリケーションをインストールし次第、ユーザは、アプリケーションのいずれの特典を受けるためにも彼らのＭＳＩＳＤＮを入力する必要がある。
・ＭＳＩＳＤＮが入力されると、ユーザは、そのアプリケーションを同様にインストールしている、そのソーシャルサイトの彼らの「友達」を見ることができる。アプリケーションは、個々のユーザによって指定されない限り友達のＭＳＩＳＤＮを示さない。
・アプリケーションは、ＣＭＸプラットフォームと通信し、ＭＳＩＳＤＮおよび対応する友達関係の最新の記録を取る。
・アプリケーションに入力されたＭＳＩＳＤＮがアプリケーションに入力された他のＭＳＩＳＤＮにコールすると、ＳＲＭは、この友達リンクを関連付け、「開放ソーシャル」割引などの何らかの種類の論理を制御フローに適用する。
・サービスは、オンネット番号専用に制限されている−オフネット番号が彼らのＭＳＩＳＤＮを入力し、彼らがオンネット事業者からではない場合、彼らは、アプリケーションから外される。これを行なうために、ＳＲＭは、オンネット／オフネットであるべき番号を照合し、その番号がアプリケーションから外されるべき場合、この理由を説明するメッセージがユーザに送信される。

【0279】

アプリケーション概要スクリーン
ＳＲＭアプリケーションを非常に簡単にインストールすることが可能である。ソーシャルネットワーキングサイト上で、それらのサイト上でＧＵＩを介して利用可能であるアプリケーションを探すことが可能である。ユーザがＳＲＭアプリケーションの詳細をさらに見るためには、加入者は、ＧＵＩ上に表示される要請されるアプリケーションの上で単にクリックする必要がある。

【0280】

ＳＲＭアプリケーションは、ユーザにアプリケーションの概要を与えるページを提示する。それは、
・アプリケーション名
・アプリケーションおよびその仕組みの説明
・そのアプリケーションをインストールしている友達
・そのアプリケーションをインストールするというオプション
・そのアプリケーションに対する格付け
などの情報を含むことができる。

【0281】

アプリケーション画面の最終的な見た目および感触は、事業者が定義可能であるように実現化されるべきである。これは、事業者がブランドロゴ、画像フォントサイズ、および色などを使用することができることを意味する。

【0282】

インストール手続き
アプリケーションをインストールするとき、ユーザは、インストールオプションを提示される。たとえば、ユーザは、以下のタスクのうちいずれかをアプリケーションが実行することを許可するよう選択することができる。「私が誰か知り、私の情報にアクセスする」、「私のプロフィールにボックスを置く」、「私の左側ナビゲーションにリンクを置く」、「私のニュースフィードおよびミニフィードに記事を出す」、「いずれのプロフィール上のプロフィール写真の下にもリンクを置く」および「私に電子メールで通知を送信する」。

【0283】

ＳＲＭは、アプリケーションをインストールするために押すことができる最終ボタンを有する。

【0284】

インストール後のアプリケーションメインページ
アプリケーションメインページには、アプリケーションの完全な詳細が載っている。サービスがアクティブになるためには、ユーザは、まず彼らの電話番号を入力しなくてはならない。正規化規則が適用される。

【0285】

一旦加入者が彼らの携帯番号を入力すると、アプリケーションは、アクティブになる。アプリケーションは、そのアプリケーションを同様に実行しているこのユーザの友達についての情報を取出す。加入者は、同様にアプリケーションを実行している当該ソーシャルネットワーキングサイト上の彼らの友達全員をリストから見ることができる。そのため、彼らが互いにコールすると、彼らは、料金または割引を通じて何らかの種類の割引コールを受ける。

【0286】

他人に彼らの電話番号が表示されて見られないように加入者が選択することができることは、オプションである。一方、この番号を表示させることもオプションである−当然、「友達」のみがこの番号を見ることができる。

【0287】

ＳＲＭアプリケーション更新
ＣＭＸプラットフォームは、ＳＲＭアプリケーションをインストールしたすべての友達関係の最新の記録を取る。新しいユーザがそのアプリケーションをインストールするおよびアクティブにするときは毎回、更新情報がＣＭＸプラットフォームに送信される。ＣＭＸプラットフォームは、この情報をアプリケーションから受信し、ＭＳＩＳＤＮを取り、このＭＳＩＳＤＮがオンネット番号であるかどうかを確かめるためにＨＬＲを照合する。ＳＲＭプラットフォームは、このアプリケーションをインストールしたすべての番号を照合して、このナンバーがオンネット番号であることを確実にする。

【0288】

この番号がオンネットである場合、アプリケーションがアクティブであり、ＣＭＸプラットフォームは、アプリケーションを実行しているソーシャルサイト上の加入者の友達全員の間で友達リンク関係を関連付ける。友達リンクは、新しい加入者がアプリケーションを追加する場合、または加入者がアプリケーションを削除する場合に更新される。

【0289】

オンネット番号ではない場合、ＣＭＸプラットフォームは、ＳＲＭアプリケーションと相互作用し、これによりアプリケーションを通じてメッセージをオフネット加入者へ送信することができる。それは、「ＳＲＭアプリケーションは、esgTel加入者専用です。残念ながら、貴方は、esgTel加入者ではありません。したがって、esgTelアプリケーションの特典を受けることができません」に似たことを伝えるであろう。次に事業者は、加入者にネットワークを切換えるよう招待するメッセージを定義することができる。

【0290】

異なるソーシャルネットワーキングサイトの友達を探す
このアプリケーションを用いて、このアプリケーションを実行している他のソーシャルネットワーキングサイトの加入者と友達になることが可能である。

【0291】

ユーザは、このアプリケーションを実行している他のソーシャルサイトのメンバーを探して、彼らがアプリケーション特典を受けることができるよう彼らとアプリケーション内で友達になることができる。この友達関係は、ＳＲＭアプリケーションのみに制約されている。

【0292】

アプリケーション特典
ＳＲＭは、友達リンクが作成されている別の加入者へのコール時に優遇料率がアクティブにされることを可能にする。別の友達リンクにコールするとき、割引を受けることがあり得、たとえば２０％である。事業者は、音声コールまたはＳＭＳなど、どのサービスをこの方式に含まれるものとするかを定義しなくてはならない。

【0293】

加入者に適用される料金／割引は、定義されている商品種類に依存する。たとえば、事業者は、ブロンズ、シルバーおよびゴールドの３つの別個の商品種類を有してもよい。友達リンク料金は以下のとおり定義される。

【0294】

【表4】

【0295】

サービスをアクティブにすることに対して請求がないことから、また加入者は、無制限の量の加入者と友達リンクを作成することが作成することができることから、これは、事業者が安いコールを加入者が行うあらゆるコールに与えるための手段である可能性がある−これは、加入者が彼らのソーシャルネットワーキングサイト上のあらゆるオンネット友達と友達リンクを作成し得るためである−多くの人にとって、特に若者にとって、友達を５００人以上持つことは珍しくない。このシナリオを避けるためには、事業者が利用可能な解決策は２つある。
・友達リンク料金に対して請求／会費を適用する。たとえば、ある加入者は、３０個の彼が定期的にコールする人との友達リンクを有する。彼は、彼が彼の友達リンクへのコール時に彼がより安いコールを手に入れるために、上記料金に対する会費を月毎に支払うことを決める。彼は、より多くの友達リンクを作成するようにも促される。彼が友達リンクではない番号にコールすると、彼の通常料金が優位となり、残高カスケードが適用され、すなわちそれは友達リンクコールではない。
・友達リンク内サービスバンドルを購入する。ソーシャルグループ内サービスバンドルによく似ている。サービスバンドルは、加入者が購入したクレジットを特定のサービスでの使用に利用可能なクレジットに変換することを可能にする。単純な「フレンドリンク内バンドル」の例は、次の１ヶ月以内に友達リンク内で用いるための１０００通のＳＭＳのパッケージをたった１０ユーロで購入することができるというものである。事業者は、オファー中のサービスバンドルの範囲を定義することができ、たとえば以下のとおりである。

【0296】

【表5】

【0297】

・加入者は、サービスバンドルをアプリケーションを通じて購入することができる。アプリケーションは、ＣＭＸ／ＳＲＭプラットフォームとリアルタイムで相互作用し、すなわち第１に加入者がサービスバンドルを購入するのに十分なお金を持っているか否かを確めるために、第２にこのクレジットを加入者の口座から差引くために照合する。加入者の番号へ以下のいずれかを行なうＳＭＳ確認が送信される。
ｏサービスバンドルの購入を確認する、または
ｏそれができなかったこととクレジットが不十分などのその理由とを説明する
・加入者は、サービスバンドルをセルフケア機構を介してまたはeServGlobal ＰＩを通じて、見る／１回限りのこととして購入する／入会することができる。

【0298】

友達リンクサービスバンドル機能性を有することは、事業者が友達リンクコールを通じて与えられる売上または割引の量を制御することができることを意味する。事業者は、望ましい場合、個々の加入者が毎月購入することができるサービスバンドルの最大量を定義することができる。

【0299】

友達リンクコール／利用に対して別個の料金または割引がないことも定義することができる。そうではなく、加入者は、友達リンクサービスバンドルを購入しなくてはならない。一旦彼がこの友達リンクサービスバンドルを消費してしまうと、加入者の通常の料金がすべてのコール／ＳＭＳに対してたとえそれが友達リンクコールであっても適用される−それはこの加入者が別の友達リンクサービスバンドルを購入するまでであり、その場合、コールの費用は、この友達リンクサービスバンドルから差引かれる。

【0300】

アプリケーションは、オファー中のサービスバンドルの完全な詳細を与え、このサービスバンドルの購入の仕方の完全な指示も与える−すなわち、このアプリケーションを通じてまたはこの指示に従って、アプリケーションは、ユーザが彼らの電話からアクセスすることができるセルフケア機構を与える。

【0301】

一旦ＣＭＸプラットフォームが友達リンク関係情報および対応するＭＳＩＳＤＮを有すると、原子モデルでのように別個の割引または料金を定義することが可能になる。特定の要件をＳＲＳ段階中に定義することができるが、原則として同じように働く。

【0302】

一旦ＣＭＸプラットフォームが友達リンク関係情報および対応するＭＳＩＳＤＮを有すると、原子モデルでのようにサービスバンドル機能性を定義することが可能になる。特定の要件をＳＲＳ段階中に定義することができるが、原則として同じように働く。

【0303】

携帯アップロード
撮った写真またはビデオをこれらがアプリケーション上に表示されるように友達が彼らの携帯からアップロードすることが可能である。これを加入者が行うことは非常に容易である−彼は、単にそれをショートコードに送信するだけでよい。次にＳＲＭは、これをソーシャルネットワーキングサイトから見られるアプリケーションにアップロードする。写真は、このアプリケーションを実行している「友達」にしか見えない。

【0304】

このアプリケーションの便益は、第１に事業者のためである−ここで、彼らは、彼らの顧客の写真を表示するためにソーシャルネットワーキングサイトを用いており、この写真を複数のソーシャルネットワーキングサイトにわたる加入者が見ることができる。

【0305】

第２に、加入者は、いつでも写真／ビデオをアップロードすることができる−これはつまり、加入者は、夜町に出て大騒ぎしている−大勢の友達との再会をしているかもしれず、彼らは写真を撮り、これは彼らにとって非常に楽しいことである。次に加入者は、この写真をその場ですぐにショートコードに送信し、彼らが翌朝起きるとアプリケーションを実行している友達全員が見られるよう写真をアプリケーション上に待たせておく。当然、ソーシャルネットワーキングサイトにとっても、彼らのサイト上にアクティブなユーザがいることにより便益がある。

【0306】

ChargingMaxプラットフォーム
上述のように、このシステムは、ユーザに彼らがアクセスするサービスについて請求することの局面を管理および制御するプラットフォームを実現化してもよい。ChargingMaxプラットフォームと名付けられてもよいこのシステムの１つの実施例を以下に説明する。ChargingMaxシステムの１つの実施例は、図８に概略的に示されており、ユニバーサルアプリケーションサーバ８１０と、ユニバーサル課金エンジン８１２と、ユニバーサルサービス管理システム８１４と、第三者による加入者料率決定および管理のためのシステム８１６とを含む。第三者料率決定および課金が設けられている代替的な実施例を、図９に示す。

【0307】

プラットフォームは、差別化されたオンライン請求システム、ハイブリッドコンバージェンス、およびコールカードサービスを可能にするように実現化される。ChargingMaxコンバージェンス製品は、事業者が、ＧＳＭ、固定、ＣＤＭＡ、およびＮＧＮネットワークをリアルタイムで課金システムへ接続することを可能にして、加入者および事業者ＶＡＳを提供する。このコンポーネントは、動的な加入者データが高度なオンライン請求システムサービスにおいて定義され、用いられることを、事業者の必要に応じて可能にする。ユニバーサル課金エンジン（ＵＢＥ：Universal Billing Engine）は、音声、ビデオ、データ、およびＳＭＳ請求のための料率決定、ウォレット、ならびにバウチャー管理を提供する。

【0308】

この解決策は、既存のインターフェイスを用いて最小限の統合努力で実施され、新しいサービスを速やかに立上げるのに役立ち、事業者がより高いユーザ１人当たりの平均売上（ＡＲＰＵ）を引出すことを可能にする。

【0309】

このシステムを用いて、顧客に対するさまざまなサービスのオファーを構築してもよく、これには以下が含まれる：事業者が定義する加入者中心のＶＡＳ、サービスを個人に応じたものにすること−友達および家族、お気に入りの宛先、仲間リストなど、位置情報ベースサービス−ホームゾーン、ＦＭＣシミュレーション、ならびにバウチャーバンドル−バウチャーでの購入サービス。

【0310】

加えて、ChargingMaxスイートは、以下も可能にする：PromoMax Express、ピアツーピアクレジット移行、サービスバンドル、加入者プロフィールマネージャ、制御計画エディタ。これらのような付加的なライセンスは、事業者が特定の領域内の市場予測に基づいてパッケージをカスタマイズすることを可能にする。

【0311】

ChargingMaxの管理は、包括的で詳細なＴＭＮ ＦＣＡＰＳ機能、すなわち障害、構成、課金、性能および機密（Fault, Configuration, Accounting, Performance and Security）管理を通じて達成される。これらは、ユニバーサルサービス管理システムによって提供される。

【0312】

ChargingMaxは、固定ネットワークまたは携帯ネットワークにおいて（ＳＩＰネットワークを含めて）パケット交換方式と回路交換方式との両方のインフラにおいて導入することができる。１つの実施例において、ChargingMaxは、ソラリス（Solaris）（登録商標）オペレーティングシステムを備えたさまざまな標準サン（Sun）社製アプリケーションサーバハードウェア上に配備される。

【0313】

ChargingMaxオンライン請求システムソリューションは、加入者中心の無線、有線およびＮＧＮネットワークのためのプリペイド機能性を提供する。これらのネットワークインターフェイスを並行して提供することによって、ＩＭＳの夢が今日の技術を用いて叶えられてもよい。その上、事業者は、このソリューションをコンバージェンスアーキテクチャの中に継目なく移行させるオプションを常に有する。

【0314】

コンバージェンスへ向かっての第１のステップとして、多くの事業者は、ハイブリッドオンライン請求システムソリューションを採用している。この経済的に実行可能なオプションは、事業者がオンライン請求システムアーキテクチャをポストペイドパートナーとの密な統合を伴って活用することを可能にする。本質的に、オンライン請求システムソリューションは、定位置に留まって、リアルタイムサービスおよびクレジット制御を提供するが、予め料率を定められたＥＤＲは、請求書生成ならびにポストペイド料金徴収および督促の管理のためのオフライン請求システムへ送信される。

【0315】

ChargingMaxコンバージェンスは、事業者が、付加価値サービス（ＶＡＳ：Value Added Services）ゲートウェイとして働くネットワーク要素をオンライン請求システムに接続することを可能にする。ローカルに記憶するかまたは外部加入者データ機能（ＳＤＦ：Subscriber Data Functions）から加入者情報を収集するかのいずれかによって、このソリューションは、作成されるべき新サービスのためのグラフィック環境を提供する。

【0316】

ChargingMaxパッケージソリューションは、予め定義された技術を用いて開発されており、その結果、革新的に少ない加入者基盤から数百万人の両方に対して価格競争力があるソリューションとなっている。それは、商品化された技術を用いており、マーケティングの専門知識を、サービスライブラリからシステム中に導入される準備ができている選択可能なサービスおよび特徴のオプションとともに販売することに集中している。ＲＯＩが非常に速い高価値高機能システムが最終的にもたらされる。

【0317】

本明細書中に説明されるＳＲＭスタンドアローンソリューションは、ChargingMaxの高度で最新鋭のＶＡＳ性能が第三者ＩＮに利用可能になることを可能にする。これにより、地域的または世界的グループにわたるＳＲＭの展開が可能になる。

【0318】

好ましい実施例において、以下のとおりである。
・ChargingMaxは、事業者の市場に対する要求とともに進化する−プラットフォームは、付加的なサービスおよび機能が制御プランエディタを用いて定義されることを可能にして、事業者が新しいプロモーションおよび機能を作成することを可能にする。これにより、補足的なシステムおよびソフトウェアに投資する必要がなくなり、ChargingMax投資のコンバージェンスが可能になる。
・ChargingMaxは、信頼性がある−電気通信プロバイダとして、最終消費者が受けるサービスの質は、市場における認識に著しい影響を及ぼす。ChargingMaxは、完全に冗長性のあるアーキテクチャをサイト冗長性および障害回復プラットフォームのためのオプションとともに提供する。
・ChargingMaxは、ネットワークには囚われない−同時にＧＳＭ、ＣＤＭＡ、有線、ＳＭＳ、データおよびＮＧＮ ＩＰ接続性を、２Ｇおよび３Ｇネットワークのために提供する。ほとんどのベンダーのコアネットワーク設備に対応しているため、このシステムは、独立しており、複数ベンダー環境においてさえ使用可能である。ネットワークが新しい技術を受入れるために進歩する場合、ネットワーク移行をサポートする均質なサービスプラットフォームを選択することが必須である。
・ChargingMaxは、コンバージェンスへの経路を提供する−あらゆる事業者は、何らかの種類のコンバージェンス課金ソリューションに向かっていくことを考えなくてはならない。その事業者にとって純粋なオンライン請求システムまたはハイブリッドコンバージェンスが正しい選択ではない場合、同じソフトウェアおよび機器を用いて、第三者課金ソリューションを備えたコンバージェンスアーキテクチャに対応することができる。末端顧客への如何なる影響も取除くために、既存のサービスおよび加入者データは、保存される。
・ChargingMaxは、拡張可能である−トラフィックの増加は、ソフトウェアライセンスの単なる獲得を意味することが多い。補足的なハードウェアが必要とされる場合、これを、ターンキーアップグレードの一部として、移行またはサービスの供給停止を要することなく追加してもよい。
・ChargingMaxは、操作が簡単である−ChargingMaxシステムの監督および管理は、ウェブベースのグラフィック管理システムで簡単になっている。監督は、内蔵のＮＭＳ機能によって提供されるか、または業界標準プロトコルを用いるより大きな監督システムの中に統合されている。
・ChargingMaxは、構成要素である−他の一流の付加価値サービスプラットフォームと予め統合されているので、事業者は、あらゆる種類の請求、補充（top up）、メッセージング、および次世代サービスを展開することができる。
・ChargingMaxは、製品である−定期的な投資は、eServGlobalが、毎年２回製品に基づいたリリースを行なうことを目指していることを意味する。これは、事業者が、局地的に必要とされる機能の開発のためのルートを有するのみならず世界規模での請求トレンドを活用することができることを意味する。ユーザグループおよびマーケティングワークショップは、事業者自身の研究および想像力を補足することができる。
・ChargingMaxは、動的である−各加入者について記憶されたデータおよびその末端サービスへの影響の与え方を定義する道具を事業者に与えることにより、事業者が真の柔軟性と独自の市場位置を獲得することを可能にする。
・ChargingMaxは、オープンエンドである−グラフィック制御計画エディタを用いると、プラットフォーム上に展開される請求サービスを制限するものは、事業者の想像力のみである。

【0319】

請求、コール制御、加入者の管理および他の操作は、別個のまたは第三者モジュールによって実行されてもよい。このシナリオにおいて、本システムは、「サービスノード」構成で用いられてもよく、その場合、たとえば、それはトラッカ分析のためのコールセットアップ中に開始される。友達リンクコールに続く標準の請求プラットフォームへのコールハンドオーバー前にプレフィックスまたはＦＣＩを接続動作に加えてもよい。図１０には、プレフィックスを用いたオンライン請求システム音声コールが概略的に示されており、ステップは、以下に要約される。
１．Ｏ−ＣＳＩ会費は、（Ｖ）ＭＳＣに第三者ＳＣＰを開始させるよう知らせる。（Ｖ）ＭＳＣは、第三者ＳＣＰとの直接のダイアログ上での通信を続ける。
２．Ｏ−ＣＳＩ会費は、ＳＲＭサービスのグローバルタイトルをＳＲＭに登録済の加入者に対してのみ反映させる。
３．ＳＲＭは、その内部論理を適用する…
４．ＴＣＡＰダイアログの開始（ＢＥＧＩＮ）状態において、着呼側ＳＣＣＰアドレスを変更することは可能である−これがＳＴＰの仕組みである…
５．プレフィックスまたは特定のサービスキーの使用は、第三者ＩＮに割引が適用されるべきであることを知らせる
６．この時点で−ＴＣＡＰ継続（ＣＯＮＴＩＮＵＥ）動作は、このダイアログに「定着したもの（sticky）」として印を付ける−この時点より先ではＳＣＣＰアドレスを変更することは不可能である
７．（Ｖ）ＭＳＣは、第三者ＳＣＰとの直接のダイアログ上での通信を続ける
図１１には、ＦＣＩを用いたポストペイド音声コールが説明されている。要約すると以下のとおりである。
１．Ｏ−ＣＳＩ会費は、ＳＲＭサービスのグローバルタイトルをＳＲＭに登録済の加入者に対してのみ反映させる
２．ＳＲＭからの（Ｖ）ＭＳＣ ＥＤＲは、次にＦＣＩデータを反映させる−オフライン課金システムにおいて割引する／料率を定めるために
３．ＥＤＲがＦＣＩデータとともにオフライン課金システムへ送信される
紹介方式
加入者が友達リンクリクエストを行なうと、これをインテリジェント紹介方式と組合せて、ソーシャル・リレーションシップ・マネージャコンセプトの便益を受けることが可能である。これにより、獲得および／または頻繁な解約の防止キャンペーンを事業者の既存の顧客基盤から展開することが可能になり、定着した関係からの価値を活用することができる。紹介方式は、既存の加入者が彼らの友達を紹介することを可能にする。これは非常に強力なプロセスである−加入者は、彼の友人をネットワークを切換えるように説得することができ、加入者が彼の友達を紹介する動機は、そうすることによって、その友達がネットワークを切換えた場合に無料コール時間などの事業者からのプレゼントを受取るということである。

【0320】

友達リンクが登録済加入者からオフネット加入者へ送信されると、以下のＳＭＳ例が送信され得る。

【0321】

オンネット加入者へ：「事業者OtherTelの０７９７３２３２９５７との間に友達リンクが形成されました。友達リンク料金がこの番号とは適用されるようになりました。貴方の友達が彼らの番号をeServGlobalTelにポートする場合、貴方は、２００分の友達リンクコールを受取ります。貴方の友達も歓迎のプレゼントを受取ります…」
オフネット加入者へ：「eServGlobalTelのコリン・ベリック０７９６３４９８３８４が友達リンクを送信しています。コリン・ベリックが貴方にコールすると、彼らは安いコールを受取ります。貴方が貴方の番号０７９６３４９３３８４をeServGlobalTelにポートする場合、当ネットワークは貴方とリンクを作成するあらゆるeServGlobalTelの友達ごとに５ユーロの歓迎プレゼントを貴方に差上げます（最大２０ユーロ）。当ネットワークは、貴方が当ネットワークに参加する場合、コリンベリックにもクレジットを加えます。０７９６３４７３３８４にお電話下さい。これらのリクエストの受信を停止するには、停止する（ＳＴＯＰ）と返信下さい（無料）」
ここで、両当事者は、紹介報奨の詳細がはっきりと分かる。バイラルマーケティングを通じて、オンネット加入者がオフネット当事者をネットワークを切換えるよう説得しようとする可能性が高い。ＳＲＭは、これが起こるためのおよびオフネット加入者がオンネットになると両当事者が報奨を受けるために完全に自動化されたプロセスを有する。紹介され友達として加えられたオフネット加入者が彼らの番号をポートすると、彼らは直ちに紹介報奨の特典を受ける。これは、事業者の持込みプロセスに従って適用される単純なＢＰＬ（Business Process Logic：ビジネスプロセス論理）によって適用される。たとえば、報奨は最初のコール後または特定の額を超える最初の再入金がなされたとき、ネットワークを切換えたことに対して適用され得る−この時点で、彼らの友達の各々も彼らの紹介に対するささやかな報奨を受取る。適用することができる報奨は、ＳＲＭサービスのために作成することができるバウチャーの種類に基づいている。
彼らが報奨を受けたのは彼らの友達のうち１人が彼らの番号を事業者にポートしたためであると述べるＳＭＳが友達に送信される。それは、両方のニックネーム、持込まれた加入者のＭＳＩＳＤＮ、バウチャーの種類名および報奨の説明（残高および残高期限切れまでの日数）を含む。ＳＭＳ例は以下のとおりであり得る「＜nickname（ニックネーム）＞ありがとうございました。貴方の友達＜nickname（ニックネーム）＞＜ＭＳＩＳＤＮ＞はeServGlobalTelに参加しました。我々は、皆友達になりました。今後＜new balance expiry period in days（新しい残高有効期限の日数）＞日内に使用されるべき＜300 minutes of fried link calls（３００分の友達リンクコール）＞のプレゼントをお受取下さい。」
最後に、持込まれた加入者へ、彼らが紹介報奨を受取ったことを述べるＳＭＳが送信される。このＳＭＳは、彼らのニックネームと、同様に報奨を受取った彼らの友達の総数と、バウチャーの種類名と、報奨の説明（残高および残高期限切れまでの日数）とを含むことができる。たとえば、「＜count of friends（友達の総数）＞人の貴方の友達に紹介されてeServGlobalTelへようこそ！１ヶ月後に期限が切れる２０ユーロのクレジットのプレゼントをお受取り下さい。ところで各友達リンクもプレゼントを受取っています。ＳＲＭプロモーションに登録して貴方の＜number of friends（友達の数）＞人の友達への安いコールを＜initial charge（初期請求）＞の請求と月毎の＜subscription cost（会費費用）＞の会費請求で受けるには、ＳＭＳを貴方のニックネーム（２０文字以下）とともに１２１に送信して下さい」。

【0322】

PromoMax Express
頻繁な解約を減らすためには、事業者は、彼らの顧客に顧客の消費習慣に基づいて報奨を与えることができる。これは、トラッカがさまざまなサービス利用を見張るために導入されるときのみ可能であり、ＵＢＥのプロモーション管理機能によって行なわれる機能である。ChargingMaxコンバージェンスモードにおいても、ＵＢＥは、配備されなくてはならないが、プロモーションカウンタ機能性を行なうためのみである。料率決定および他の機能は、依然として第三者ＯＣＳに残る。実施例によっては、サービスバンドルを報奨として与えてもよい。

【0323】

ＳＲＭがPromoMax Expressと組合されると、報奨を以下の基準、すなわち友達リンクコール／ＳＭＳおよび友達リンクコールに出費された売上、に基づいて加入者に与えることができる。ＳＲＭビジネスインテリジェンスをPromoMax Expressと連動して用いて、価値のある影響力のある加入者を強調表示することによって、頻繁な解約を削減することができる。。

【0324】

高度なChargingMax論理により、報奨をリアルタイムで適用することが可能になる。つまり、加入者が報奨に達すると、彼らは直ちに報奨を受取る。これは強力な手段である。なぜならば、頻繁な解約を削減するためには、加入者はなぜなら彼らが報奨を受けたかを理解する必要があるためである。報奨に達したときに報奨を適用することによって、加入者は、なぜなら彼らが報奨を受けたのかを十分に認識する。

【0325】

このサービスは、報奨を所与の期間の終わりに適用することができるようにも定義することができる。しかしながら、上述のように、なぜ報奨を受けているのかを加入者が理解することが重要である−たとえ報奨が期間の終わりに与えられたとしても、加入者は、報奨しきい値に達したことを認識することが、そのように説明する通知ＳＭＳを受信することによって依然として可能である。

【0326】

事業者は、支出額期間を非常に簡単に設定することもできる。これは、日毎、週毎、月毎または年毎であり得、頻繁な解約を防止する多くの異なるプロモーションを顧客基盤の異なる階層に対象を絞った異なるプロモーションとともに定義することを可能にする。

【0327】

ＳＲＭ残高しきい値に達したときなど、非リアルタイム報奨が加入者に与えられるとき、課金エンジンプラグインは、報奨を加入者のウォレットに直接適用する。報奨は、バウチャー型再入金をコンバージェンスオンライン請求システムに送ることによって適用される。

【0328】

ＩＶＲセルフケア
加入者のためのエンドツーエンドセルフケア機構を有することにより、大きな費用削減が事業者にもたらされる−カスタマーサービスに電話をかける必要が減る。ＣＳＲ係員が顧客の問題の解決にかける時間が減ることにより、事業者がより大きな費用節約の特典を受けることを可能になる。また、加入者が彼自身の質問または問題をカスタマーサービスに電話をかける必要なしに非常に簡単に解決できるならば、これは、大幅に快適なエンドユーザ体験に繋がる。

【0329】

加入者が双方向音声応答（ＩＶＲ：Interactive Voice Response）セルフケアに電話で接続すると、ＳＲＭは、まず加入者がサービスに登録されていることを照合する。彼らが登録されていない場合、彼らは、登録の仕方、費用などを知らされ、ＩＶＲから接続を切られる。登録済加入者については、彼らは、固定の歓迎の挨拶とたとえば以下のような選択するオプション一式とを聞く。
・第１のオプションは、加入者が彼らが彼らの商品種類に基づいて何人の友達を持つことが許可されているかを聞くことを可能にする
・第２のオプションは、加入者が現在何人の友達を彼らの友達リストに有するかを聞くことを可能にする
・第３のオプションは、加入者が彼らの友達の各々のＭＳＩＳＤＮを聞くことを可能にする
・第４のオプションは、加入者が彼らがＳＲＭコールを行なうと適用される現在の料金または割引を聞くことを可能にする。友達リストの大きさによって異なる料金が適用される場合、現在の友達リストの大きさを用いて、固定の一式の料金から選択する。
・第５のオプションは、ＳＲＭ固有のサービスバンドルについての情報を再生する。新しい特徴ノードは、サービスバンドルと関連付けられた告知ＩＤを名前順に再生する。選択されるサービスバンドルは、加入者の商品種類と関連付けられたものである。
・第６のオプションは、ＳＲＭ PromoMax Express残高および目標を再生する
すべてのオプションが再生された後、加入者は、ＩＶＲシステムから接続を切られる。

【0330】

図６には、本明細書中に説明されるシステムのアーキテクチャの１つの実施例が示されている。図７には、本システムのためのアーキテクチャの代替的な実施例が示されている。

【0331】

クリックコール
上記に説明された実施例のいずれかと連動して、「クリックコール（click-to-call）」インターフェイスをインターフェイスを介して、たとえばソーシャルネットワーキングサイト上のアプリケーションを介して提供してもよい。サービスへのアクセス権を有するユーザ、たとえばアプリケーションをインストールしたユーザは、ウェブインターフェイス上で、彼らがコールしたい友達を表わすアイコンの上でクリックするかまたはリストから友達を選択する。すると、ユーザ間でコールがセットアップされる。たとえば、システムは、まず要請する側のユーザの携帯電話にコールし、第１のユーザが応答すると、第２のユーザにコールしてユーザ同士を接続する。第２のユーザには、このコールは、第１のユーザから直接発信されているように見えるかもしれない。しかしながら、このコールは本アプリケーションを介してセットアップされたので、一方または両方のユーザは、好ましいコール料率の特典を受けてもよい。このコールを、完全に移動体電気通信ネットワークを通じて送信してもよいが、たとえばＶｏＩＰネットワークのような別のネットワークに少なくとも一部肩代わりさせてもよい。

【0332】

本システムは、第１および第２のユーザを含めて、すべての登録済ユーザのＭＳＩＳＤＮを記憶するため、第１のユーザは、第２のユーザのＭＳＩＳＤＮを知らずとも第２のユーザの携帯電話に連絡を取ることができる。この場合、接続は、第１のユーザの第２のユーザとのウェブインターフェイス上の「友達」リンクに単に基づいてセットアップされる。

【0333】

１つの実施例において、このシステムは、第１のユーザと第２のユーザとを電気通信ネットワークを介して接続するが、第２のユーザのＭＳＩＳＤＮを第１のユーザから隠す。好ましくは、逆もまた同様である。別の実施例において、このシステムは、第１のネットワーク（たとえばＩＰネットワーク）中の第１のユーザを第２のネットワーク（たとえば電気通信ネットワーク）中の第２のユーザに接続してもよい。すなわち、コンピュータ端末にいる第１のユーザが、携帯端末にいる第２のユーザに接続されてもよい。

【0334】

別の実施例において、第１のユーザは、彼の携帯端末（たとえば、ウェブ対応携帯電話）上の彼の友達詳細にアクセスし、友達との「クリックコール」接続を彼の携帯端末から直接要請する。次に本システムは、第１のユーザの携帯端末と第２のユーザの携帯端末とを接続する。よって、このシステムは、第１のユーザには彼の携帯端末上の住所録から友達にコールするのと非常に似ているように見えるかもしれないが、第２のユーザの携帯番号を記憶するのではなく、ユーザ間の接続を可能にするには、友達リンクで十分である。

【0335】

この特徴により、ユーザが、彼らのＭＳＩＳＤＮ番号を変更し、本アプリケーションのための彼らの設定のみを更新してもよいという付加的な利点が提供される。彼らにこのアプリケーションを介して接続される他の「友達」は、このユーザの新しい連絡先詳細について彼ら自身の住所録を更新する必要なく、かつユーザの新しい番号を知らされる必要さえなく、本明細書に説明される「クリックコール」機能性を用いて、彼らに連絡を取ることができる。これは、たとえばユーザが一時的に彼の携帯電話をなくした場合または地上通信線番号が特定の時間より便利である場合、彼が彼の連絡先ＭＳＩＳＤＮ番号を定期的にまたは一時的に変更することを可能にしてもよい。

【0336】

実現化例
ユーザは、端末７００を介してこのシステムにアクセスすることができる。この端末の具体的な実施例を、処理システムを用いて実現化することができる。この端末の例を図４に示す。具体的には、処理システム７１０は、概して、バスまたはバス群（図示せず）を介してともに結合された、少なくとも１つのプロセッサ７２０または処理ユニットもしくは複数のプロセッサと、メモリ７１２と、少なくとも１つの入力装置７１４と、少なくとも１つの出力装置７１６とを含む。特定の実施例において、入力装置７１４と出力装置７１６とは同じ装置であり得る。処理システム７１０を１つ以上の周辺装置に結合するためにインターフェイス７１８も設けることができ、たとえば、インターフェイス７１８は、ＰＣＩカードまたはＰＣカードであり得る。インターフェイス７１８は、モデムまたはネットワークアダプタを含んでもよく、たとえばイーサネット（Ethernet）カードである。メモリ７１２は、任意の形態のメモリ装置であり得、たとえば、揮発性または不揮発性メモリ、固体メモリ装置、磁気装置などである。プロセッサ７２０は、処理システム７１０内の異なる機能をたとえば取扱うために、２つ以上の別個の処理装置を含み得る。

【0337】

入力装置７１４は、ユーザからの入力データを受取り、たとえば、キーボード、ペン状の装置またはマウスなどのポインタ装置、マイクなどの音声制御起動およびインターネット電話通信のための受音装置、モデムまたは無線データアダプタなどのデータ受信機またはアンテナ、データ収集カード、ウェブカメラなどの受映像装置などが含まれ得る。入力データは、たとえばネットワークを介して受信したデータと連動したキーボード指示のような、互いに異なるソースからのものであり得る。出力装置７１６は、出力データを作成または生成し、たとえば、表示装置またはモニタ（この場合目に見えるデータが出力される）、プリンタ（この場合データが印刷される）、たとえばＵＳＢポートのようなポート、周辺構成要素アダプタ、映像および／または音声出力装置、ならびにモデムまたはネットワークアダプタなどのデータ送信機またはアンテナなどが含まれ得る。ユーザは、データ出力またはデータ出力の解釈をたとえばモニタ上でまたはプリンタを用いて見得る。

【0338】

使用の際、処理システム７１０は、データまたは情報をローカルメモリ７１２に／からまたはネットワークを介してリモートデータベースに／から有線または無線通信手段を介して記憶するおよび／または検索することを可能にするように構成されていて、本明細書中に説明される方法を実現化する。インターフェイス７１８は、処理ユニット７１０と専用の目的に役立ってもよい周辺構成要素との間の有線および／または無線通信を可能にしてもよい。プロセッサ７１０は、命令を入力データとして入力装置７１４を介して受け、処理された結果または他の出力をユーザに出力装置７１６を利用して表示することができる。２つ以上の入力装置７１４および／または出力装置７１６を設けることができる。入出力データは、リモートサーバ７２４または一団のサーバから／へ、インターフェイス７１８に接続された、インターネットを含んでもよいネットワーク７２２を介して送受信されてもよい。処理システム７１０は、任意の形態の端末、サーバ、専用ハードウェアなどであってもよく、示された実施例に限定されないことが理解されるべきである。

【0339】

処理システム７１０は、データをネットワーク７２２を介して送受信することで他の端末と、またはたとえば複数のデータベース７２６ａ、７２６ｂと接続されたデータベースサーバのような１つ以上のサーバ７２４と通信することによって、データの通信をしやすくするように構成されていてもよい。リモートサーバ７２４は、単一のサーバまたは一団のサーバを含んでもよく、この一団のサーバは、たとえば「クラウド」として実現化されているような、互いに地理的に離れているものであってもよい。サーバ７２４は、本明細書中に説明されるシステムを実現化するスタンドアローン装置であってもよく、また説明されたシステムは、サーバ７２４の一部分上で実現化されてもよく、このサーバは、たとえば他のウェブベースのアプリケーションのサーバをすることによって、他の機能性も提供してもよい。弾力性および冗長性のために、サーバ７２４同士は、好ましくは地理的におよび地形的に分離されている。

【0340】

サーバ７２４は、少なくとも１つのデータベースに、好ましくは複数のデータベース７２６ａ、７２６ｂに接続されている。データベース７２６ａ、７２６ｂも、一団のまたは「クラウド」配置で設けられてもよく、好ましくは、ネットワーク７２２を通じて地理的におよび地形的に分離されている。

【0341】

本明細書中に説明されるシステムおよび方法は、他の種類の物理的機器を用いても実現されてもよく、上記説明は、限定することを意味していないことが当業者には明らかであるだろう。たとえば、ユーザ端末７００を、類似の機能性を提供するラップトップ、ＰＤＡ、または携帯電話などの手持ち式装置で置き換えてもよい。

【図4c】

【図5】

【図1】

【図2】

【図3a】

【図3b】

【図3c】

【図4a】

【図4b】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】