(57)【特許請求の範囲】
【請求項１】
第１デバイス(D1, D1’)から来るとともにマルチメディアIPコアネットワーク(CN1, CN2’)に管理される第２デバイス(D2, D2’)へ送信される受信されたメッセージ(MOPT, MOPT’)を処理するための方法であって、前記方法は、前記受信されたメッセージ(MOPT, MOPT’)が第２デバイス(D2, D2’)の能力および状態を発見するためのメッセージであるときに、処理エンティティ(2, D2’)によって実施されるための方法であり、前記処理エンティティは、前記マルチメディアIPコアネットワークのアプリケーションサーバ内に含まれており、前記アプリケーションサーバは、前記第２デバイスの前記能力および前記状態を発見するために前記第２デバイスに送信された前記メッセージの前記受信の検出時にトリガされ、
・前記受信された発見メッセージ(MOPT, MOPT’)内のフィールドから前記第１デバイス(D1, D1’)の識別子(ID1, ID1’)を取得する、取得ステップ(E20, E40)と、
・前記識別子(ID1, ID1’)に応じて動作し、前記受信された発見メッセージに応答するための応答モード(M1, M2)を選択する、選択ステップ(E50, E70, F70, F90)とを含み、
前記モードは少なくとも２つの応答モード(M1, M2)を含む所定の組(Ω)から選択され、
前記所定の組が、少なくとも、
部分的な、または誤った、発見メッセージに対する応答を前記第１デバイスに送信することを含む応答モードであって、前記発見メッセージに対する部分的な応答は、前記第２デバイスの前記能力のうちのいくつかのみを与え、または、前記第２デバイスの前記状態のみを示す、応答モードと、
前記第２デバイスの前記能力および前記状態を含むトランスペアレントな、前記発見メッセージに対する応答を前記第１デバイスに送信することを含む応答モードと
を含み、
部分的な応答またはトランスペアレントな応答を前記第１デバイスに送信することを含む応答モードが選択されるとき、前記処理方法は、
前記第２デバイスの前記能力および前記状態を発見するための前記メッセージを前記第２デバイスにトランスペアレントに転送するステップと、
前記転送されたメッセージに応答して、前記第２デバイスの前記状態および前記能力を受信するステップと、
前記選択された応答モードに従い前記第２デバイスから受信された前記状態および前記能力から生成されたメッセージに対する応答を前記第１デバイスに送信するステップと
を更に含む、処理方法。
【請求項２】
前記所定の組(Ω)が、少なくとも、
・部分的な、所定の、または誤った、発見メッセージに対する応答を前記第１デバイスに送信することを含む応答モード(M2)、および
・前記第２デバイスの機能および状態を含むトランスペアレントな、発見メッセージに対する応答を前記第１デバイスに送信することを含む応答モード(M1)
を含む、請求項１に記載の処理方法。
【請求項３】
前記所定の組(Ω)が、少なくとも、
・前記第２デバイスの機能および状態を含むトランスペアレントな、発見メッセージに対する応答を第１デバイスに送信することを含む応答モード、および
・発見メッセージに対して応答しないことを含む応答モード
を含む、請求項１に記載の処理方法。
【請求項４】
前記発見メッセージ(MOPT, MOPT’)がSIP OPTIONSメッセージであり、前記第１デバイスの識別子を含むこのメッセージの前記フィールドがFROMフィールドまたはP-Asserted-Identity フィールドである、請求項１に記載の処理方法。
【請求項５】
前記処理ユニット(2, D2’)が、第２デバイスに関連する識別子の少なくとも１つの所定リスト内に前記第１デバイスの識別子が存在するかまたは存在しないかに応じて、前記所定の組(Ω)から応答モードを選択する、請求項１に記載の処理方法。
【請求項６】
前記所定のリストが、前記第２デバイス(D2, D2’)または遠隔機器に記録されたコンタクトリスト(RL2, RL2’)である、請求項５に記載の処理方法。
【請求項７】
前記処理エンティティ(2, D2’)が、前記第２デバイスのネットワークドメインまたは許可されたネットワークドメインに一致するネットワークドメインに属する前記第１デバイスの識別子であるか否かに応じて、前記所定の組(Ω)から応答モードを選択する、請求項１に記載の処理方法。
【請求項８】
前記処理エンティティ(2, D2’)は、前記第１デバイスの識別子が所定のユーザ部分または所定の種類のユーザ部分を含むか否かに基づき、前記所定の組(Ω)から応答モードを選択する、請求項１に記載の処理方法。
【請求項９】
前記第１デバイス(D1)に送信される前記応答は、メッセージの受信において前記第２デバイスについて進行中であるセッションの数および／または種類にも基づく、請求項２に記載の処理方法。
【請求項１０】
コンピュータによってプログラムが実行されるときに、請求項１に記載の処理方法のステップを実行するための命令を含むコンピュータプログラム。
【請求項１１】
請求項１に記載の処理方法のステップを実行するための命令を含むコンピュータプログラムを記録するコンピュータ可読データ媒体。
【請求項１２】
第１デバイス(D1, D1’)から来るとともにマルチメディアIPコアネットワーク(CN2)に管理される第２デバイス(D2, D2’)へ送信される受信されたメッセージ(MOPT, MOPT’)を処理するための処理エンティティ(2, D2’)であって、前記エンティティは、前記受信されたメッセージ(MOPT, MOPT’)が前記第２デバイスの能力および状態を発見するためのメッセージである場合に、アクティベートされる手段を含み、前記処理エンティティは、前記マルチメディアIPコアネットワークのアプリケーションサーバ内に含まれており、前記アプリケーションサーバは、前記第２デバイスの前記能力および前記状態を発見するために前記第２デバイスに送信された前記メッセージの前記受信の検出時にトリガされ、この手段は、
・前記受信された発見メッセージ内のフィールドから前記第１デバイス(D1, D1’)の識別子(ID1, ID1’)を取得するための手段と、
・前記識別子(ID1, ID1’)に応じて動作し、前記受信された発見メッセージに応答するための応答モード(1, 2)を選択するための適切な手段とを含み、
前記モードは少なくとも２つの応答モード(1, 2)を含む所定の組(Ω)から選択され、
前記所定の組が、少なくとも、
部分的な、または誤った、発見メッセージに対する応答を前記第１デバイスに送信することを含む応答モードであって、前記発見メッセージに対する部分的な応答は、前記第２デバイスの前記能力のうちのいくつかのみを与え、または、前記第２デバイスの前記状態のみを示す、応答モードと、
前記第２デバイスの前記能力および前記状態を含むトランスペアレントな、前記発見メッセージに対する応答を前記第１デバイスに送信することを含む応答モードと
を含み、
部分的な応答またはトランスペアレントな応答を前記第１デバイスに送信することを含む応答モードが選択されるとき、前記処理エンティティは、更に、
前記第２デバイスの前記能力および前記状態を発見するための前記メッセージを前記第２デバイスにトランスペアレントに転送し、
前記転送されたメッセージに応答して、前記第２デバイスの前記状態および前記能力を受信し、
前記選択された応答モードに従い前記第２デバイスから受信された前記状態および前記能力から生成されたメッセージに対する応答を前記第１デバイスに送信する、
処理エンティティ。
【請求項１３】
デバイス(D2)を管理するマルチメディアIPコアネットワーク(CN2)に関連するサーバ(2)であって、前記デバイス(D2)に送信される、受信されたメッセージを処理するための請求項１２に記載の処理エンティティを含むサーバ。
【請求項１４】
・第１デバイス(D1, D1’)、およびマルチメディアIPコアネットワーク(CN2)によって管理される第２デバイス(D2, D2’)をであって、前記第１デバイス(D1, D1’)が前記第２デバイスの機能および状態を発見するためのメッセージ(MOPT, MOPT’)を送信するように適合される、第１デバイスおよび第２デバイスと、
・前記発見メッセージ(MOPT, MOPT’)を受信し、それを処理するために適した請求項１２に記載の処理エンティティ(2, D2’)と
を含む通信システム(1, 1’)。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、遠隔通信の一般的な分野およびマルチメディアインターネットプロトコル(IP)ネットワークアーキテクチャに関する。例えば、具体的にはいわゆる「ボイスオーバーIP」(VoIP)技術を用いたネットワークアーキテクチャに関する。
【背景技術】
【０００２】
好ましくかつ限定しない本発明の応用は、インターネット・エンジニアリング・タスクフォース(IETF)標準によって定められ、特にIETFによって2002年6月に出版された「SIP: session initiation protocol」と題されるDocument RFC3261の中で説明されるマルチメディア・セッション・イニシエーション・プロトコル(SIP)を用いたマルチメディアIPコアネットワークの文脈に位置する。特に本発明は、第３世代パートナーシッププロジェクト(3GPP)標準によって提案されるようなIPマルチメディアサブシステム(IMS)アーキテクチャに準拠するマルチメディアIPコアネットワークに応用される。
【０００３】
一方で本発明は、マルチメディアセッション(つまり、音声、テキスト、ビデオ、データ等のセッション)をセットアップするためにSIPプロトコルが使用されるまたは使用されない、例えば専用のアーキテクチャ(proprietary architecture)等のその他のメッセージIPコアネットワークアーキテクチャに関連して使用することもできる。
【０００４】
本発明は、さらに具体的には、処理エンティティを用いて第１デバイスから受信されるとともに、マルチメディアIPコアネットワークによって管理される第２デバイス(端末またはサーバなど)に送信されるメッセージを処理することに関する。この処理は、自動的に遠隔の相手 (言い換えれば、この文脈では第２デバイス)の能力および状態を自動的に発見するための機構に基づくマルチメディア通信サービスの文脈におけるものである。
【０００５】
既知の方法において、そのような自動発見機構は、第１デバイスが、第２デバイスを招待する特定のメッセージを「遠隔」の第２デバイスに送信し、そのメッセージに応答して、はじめにその状態(例えば、利用可能、ビジー、圏外、および未登録等)、次にその能力、例えばサービス、プロトコル、および／またはサポートまたは使用するアプリケーション、を宣言(declare)することを提供する。
【０００６】
以下の説明では、この特定のメッセージは、「遠隔の相手の能力および状態を発見するための」メッセージ、または「第２デバイスの能力および状態を発見するための」メッセージと呼ばれる。SIPプロトコルにおけるこのようなメッセージの一例は、SIP OPTIONSの方法に基づくメッセージである。
【０００７】
この自動発見機構は、特に、「RCS-e advanced communications: services and client specification」(Version 1.1, 2011年4月8日)と題される文献の中で説明される、リッチ・コミュニケーション・スイート‐エンハンスト(RCS-e)メッセージサービスによって使用される。
【０００８】
既知の方法において、RCS-e標準は、IMSコアネットワークに登録される２つの端末がIMSコアネットワークに(例えば、GSM(登録商標)(a global system for mobile communications network)を介して)接続しない回線交換ネットワークを介して通信をセットアップし、この通信に並行して、または、この通信の余地(margin)において、IMSコアネットワークに接続されるパケット交換ネットワークを経由する「エンリッチド・コミュニケーション(enriched communication)」として知られる、例えば、写真転送用サービス、インスタントメッセージングサービス、ファイル共有サービス等の追加のメッセージサービスを使用できるようにする。
【０００９】
この目的のために、具体的には第１端末のコンタクトリストにおいてコンタクトを作成しているときに、または第１端末および第２端末間の呼をセットアップしているときに、RCS-e標準は、SIP OPTIONSメッセージの使用に基づいて第２端末の(および逆の)状態およびRCS-e能力を自動的に第１端末が発見することを可能にする機構を使用する用意を作る。
【００１０】
遠隔の相手の状態および能力を自動的に発見するための機構の使用は、メンテナンス動作がプログラムされる、または求められるデバイスの状態および能力に関して、関係する情報を取得するために、通信会社やサービス提供者によって提供される販売後のサービスの文脈においても想定されうる。
【００１１】
SIPプロトコルに従って、SIP OPTIONS発見メッセージを受信するどんなデバイスも、発見メッセージを送信したデバイスに適切な応答メッセージ送信することによって、さらにトランスペアレントな方法で応答することが要求される。この応答メッセージは、その状態を特定し、その能力を含む。
【００１２】
従って、例えば第２デバイスが利用可能であり、RCS-eサービスに適合している場合、第２デバイスは200 OKメッセージを第１デバイスに送信する。このメッセージは、「feature tag」フィールド内にRCS-eサービスの識別子を含み、また(その他のfeatures tagおよび／またはセッション記述プロトコル(SDP)セッションを通して)第２デバイスによってサポートされるその他のサービスの識別も共に含む。200 OK応答メッセージはまた、第２デバイスによってサポートされるSIPメソッド等も含む。
【００１３】
この標準に従って、SIP OPTIONSメッセージは、第２デバイスのユーザがそのことに気づくことなしに第２デバイスによって受信されることが起こるはずである。ユーザには特に知らされず、これは第２デバイスの全ての呼び出しや、SIP OPTIONSメッセージが受信されたことの通知を全くトリガしない。
【００１４】
つまり、SIP標準は現在、全てのデバイスが、発見機構が使用されたことがその遠隔デバイスのユーザに知らされることなく、またそのような使用のいかなる痕跡も残さずに、SIP OPTIONSメッセージを送信するとともに完全にディスクリートな方法で遠隔デバイスの状態および／または能力を発見することを可能にする。
【００１５】
そのため、この動作モードは悪用される結果につながると理解できる。特に、良心のない経済活動者がユーザの端末に関する情報を取得するために、および単に営利目的のためのそのような情報を使用する(そのような情報を営利会社に転売する)ために、不必要なSIP OPTIONSメッセージを送信することが危惧される。
【００１６】
従って、そのような悪用に対して保護を提供する機構の必要性が存在する。
【発明の概要】
【課題を解決するための手段】
【００１７】
本発明は、第１デバイスから来るとともにマルチメディアIPコアネットワークによって管理される第２デバイスに送信される受信されたメッセージを処理するための処理方法を提供することにより、具体的にこのニーズを満たす。この方法は、受信されたメッセージが第２デバイスの能力および状態を発見するためのメッセージである場合に、処理エンティティによって実施されるための方法である。本発明の処理方法は、
・受信された発見メッセージ内のフィールドから第１デバイスの識別子を取得する、取得ステップと、
・識別子に応じて作動し、受信された発見メッセージに応答するための応答モードを選択する、選択ステップであって、このモードは少なくとも２つのモードを含む所定の組から選択される、選択ステップと
を含むことに格別な特徴を有する。
【００１８】
対応して本発明は、第１デバイスから来るとともにマルチメディアIPコアネットワークによって管理される第２デバイスに送信される受信されたメッセージを処理するための処理エンティティも提供する。このエンティティは、受信されたメッセージが第２デバイスの能力および状態を発見するためのメッセージである場合に、アクティベートされる手段を備える。この手段は、
・受信された発見メッセージのフィールドから第１デバイスの識別子を取得するための手段と、
・前記識別子に応じて作動し、受信された発見メッセージに応答するための応答モードを選択するための適切な手段であって、このモードは少なくとも２つのモードを含む所定の組から選択される、手段と
を備える。
【００１９】
上記のように悪用に対して保護を行うために、本発明はつまり、第２デバイスに送られるような遠隔の相手の能力および状態を発見するためのメッセージをフィルタリングし、メッセージの起源に応じて動作することを提案する。
【００２０】
本発明に基づき、発見メッセージに応答するためのモード(例えば、無応答、またはトランスペアレント応答)(つまり、戦略)を決定するために、発見メッセージを発信する第１デバイスの識別子を考慮することによってフィルタフィングが行われる。
【００２１】
言い換えれば、本発明は、応答が遠隔の相手の能力および状態を発見するためのメッセージに対して与えられる方法において追加の自由度を導入する。つまりこれは、処理エンティティに、第１デバイスの識別子に応じて発見メッセージに対して作られる応答の種類を決定する能力を与える。
【００２２】
当然の結果として、本発明は、例えば第２デバイスのユーザまたはマルチメディアIPコアネットワークのオペレータによって許可または選択されたデバイスへのみ、発見メッセージに対してトランスペアレントな応答が(つまり、第２デバイスの「本当の(real)」状態および能力を含む応答メッセージを送ることによって)与えられるように処理エンティティを構成することを可能にする。
【００２３】
従って、本発明は、現在のSIP標準が第１デバイスに第２デバイスのユーザの自覚なしに第２デバイスの状態および能力を発見させてしまう状況に対処することを可能にする。本発明では、発見メッセージに対して応答するための利用可能な複数の潜在的な応答モードを作ることによって、第１デバイスの識別子に応じてこれらのモードで第１デバイスに与える情報の量および種類を適合させることが可能である。
【００２４】
上記の悪用に対処するためにプロセッサユニットが選択することのできる種々の応答モードを含む所定の組が想定されうる。このような応答メッセージは、有利には、ユーザインタフェース(例えば、ウェブインターフェイスまたはこの目的のために開発されたアプリケーション)を介して第２デバイスのユーザによって個人的に、またはマルチメディアIPコアネットワークのオペレータによって、特定される。
【００２５】
好ましくは、応答モードの所定の組は、
・部分的な、所定の、または誤った(erroneous)、発見メッセージに対する応答を第１デバイスに送信することを含む応答モードと、
・第２デバイスの能力および状態を含むトランスペアレントな、発見メッセージに対する応答を第１デバイスに送信することを含む応答モードと
を少なくとも含む。
【００２６】
これらの応答モードでは、応答のいくつかの種類は、常に第１デバイスへ送信され、これは特にSIPプロトコル内で特定されるように応答する原則(obligation)に従う。
【００２７】
一方で、応答の適切な内容は、第１デバイスの識別子に応じて適合される。つまり、適切な選択ルールを用いて第１デバイスに、
・例えば識別子が所定の基準を満たす場合に、トランスペアレントな応答、つまり第２デバイスのすべての機能および本当の状態を示すおよび／または含む応答を送信する、または
・識別子が基準を満たさない場合に、部分的な(つまり、第２デバイスのいくつかの機能のみを与える、またはその状態のみを示すという意味で不完全な)所定の応答、または誤った情報を含む応答を送信する
ように処理エンティティを構成することが可能である。
【００２８】
応答がトランスペアレントであってもなくてもよいが、第１デバイスに応答を常に送信することによって、第１デバイスが、発見メッセージに対する応答メッセージが受信されない結果としてメッセージを再送信することを防止することを可能にする。これは、ネットワークが、第１デバイスに送信される第２デバイスの状態および能力についての情報に対する制御をロードするとともに維持することから保護する。
【００２９】
異なる形態では、所定の組は、
・第２デバイスの能力および状態を含むトランスペアレントな発見メッセージに対する応答を第１デバイスに送信することを含む応答モードと、
・発見メッセージに対して応答しないことを含む応答モードと
を少なくとも含むことが想定可能である。
【００３０】
第１デバイスに応答を送信しない応答モードを提供することは、第２デバイスのユーザに課金(billing)に関して利益をもたらす。
【００３１】
第２デバイスについての「プライベートな」情報を開示することに加えて、SIP標準によって好ましくは提供される自動発見機構は、第１デバイスへ応答メッセージを送信することに対する、およびこの応答が第２デバイスによってSIP OPTIONSメッセージを受信し、その全てに対して応答する結果の全体を示し得る費用に関しての課金の問題も引き起こす。
【００３２】
より正確には、SIP OPTIONSメッセージに対する応答メッセージを送信することに関連する費用は、一般には第２デバイスの責任である（または、少なくともそれは第２デバイスのユーザが関与するアップリンクのデビット(debit)として会計の一部となり、ネットワークのオペレータとのユーザの合意(subscription)に基づき課金される）。従って、本発明は第２デバイスのユーザが、応答することを望むそれらのデバイスを選択することを可能にするため、関連する費用を制限することができる。
【００３３】
本発明は、遠隔の相手の機能および状態を発見するための、いわばターゲットにされるメッセージに適用され、第２デバイスに送信される全てのメッセージに適用しないことが想定される。本発明は、ユーザに気付かれずに受信されるメッセージであって、第２デバイスが前記標準に従って応答することを要求されるメッセージによって要求される第２デバイスについてのプライベートな情報が悪用されることから第２デバイスのユーザを保護することを試みる。正確に言えば本発明は、遠隔の相手の状態および能力を発見するためのメッセージ以外の他の種類のメッセージを処理することに関しない。
【００３４】
特定の実施形態では、処理エンティティによって処理される発見メッセージは、SIP OPTIONSメッセージであり、第１デバイスの識別子を含むこのメッセージのフィールドは、(特に、マスクされた第１デバイスの識別子の場合には)FROMフィールドまたはP-Asserted-Identifyフィールドである。
【００３５】
上記のように、発見メッセージとともに使用される応答モードは、第１デバイスの識別子の全てまたは一部に関連した(典型的には、SIP OPTIONSメッセージについてのFROMフィールドまたはP-Asserted-Identityフィールドの内容の全てまたは一部に関連した)種々の基準に応じて、および種々の所定の選択ルールに応じて選択され得る。
【００３６】
つまり例えば、プロセッサユニットは、第２デバイスに関連する識別子の少なくとも１つの所定のリスト内に第１デバイスの識別子が存在するか、または存在しないかに応じて所定の組から応答モードを選択することができる。
【００３７】
このリストは、ユーザが自身のデバイスの状態および能力についての情報を送信することを承認したそれらのデバイスに応じて、具体的には第２デバイスのユーザによって定められ得る。
【００３８】
リストは、ユーザによって承認されるデバイスの識別子を含むリストであってもよいし、または対照的にユーザが自身のデバイスの状態および機能を通信することを望まないデバイスの識別子を含む「ブラックリスト」でもよい。
【００３９】
ユーザが自身の能力および状態の一部のみを通信することを望む識別子のリストを定めることを想定することも可能である。
【００４０】
特定の実施形態では、第２デバイスに関連する識別子の所定のリストは、第２デバイスに関連するコンタクト(レパートリー(repertory))のリストの形をとり得る。このリストは、第２デバイスにローカルに記録される、またはマルチメディアIPコアネットワーク(アプリケーションサーバ、またはコアネットワークのオペレータの情報システム)内の、または対照的にいくつかのその他のネットワーク(例えば、マルチメディアIPコアネットワークにアクセスを与えるゲートウェイ、または第２デバイスも接続するローカルネットワークに接続する端末などの装置)内の遠隔機器に記録され得る。
【００４１】
この異なる形態は、本発明が(リストの事前の構成が必要でない)その他のアプリケーションについての既に利用可能なリストを使用することで、実施を単純化することが可能である。
【００４２】
それはさらに、第２デバイスにとってすでに既知である識別子であって、第２デバイスのユーザが色々なときにおいて事前にすでに承認した通信を有するデバイスに対応した識別子に基づくことができる。
【００４３】
その他の実施形態では、第１デバイスの識別子が、第２デバイスのネットワークドメインまたは許可されたネットワークドメインと等しいネットワークドメインに属するか否かに応じて、処理エンティティは、所定の組から応答モードを選択する。
【００４４】
この実施形態は、発見メッセージをフィルタリングするためのネットワークパラメータを考慮することを可能にする。
【００４５】
これは、例えば、外国から来る発見メッセージをフィルタリングのための(例えば、フランスネットワークのドメインの「.fr」以外の拡張子を有する全ての識別子をフィルタリングすることによって)、または特に課金の理由で第２デバイスを管理しているマルチメディアIPコアネットワークのオペレータ以外のオペレータによって操作されるネットワークから来る発見メッセージをフィルタリングするための、好ましい応用を提供する。
【００４６】
その他の実施形態では、処理エンティティは、第１デバイスの識別子が所定のユーザ部分または所定の種類のユーザ部分(例えば国際電話番号プレフィックス、または特定のユニフォームリソース識別子(URI)など)を含むかまたは含まないかに基づき、所定の組から応答モードを選択する。
【００４７】
用語「ユーザ部分」は、第１デバイスのユーザに固有の識別子の部分を意味するために使用される。つまり、「ユーザ部分」は、第１デバイスのユーザを識別する一方で、ドメインや、管理を行うネットワークには対応しない。例えば、タイプ「user_name@domain_name」のアドレスの形をした識別子にとって、ユーザ部分は、「@」記号の左に位置する「user_name」要素に対応する。
【００４８】
SIP OPTIONSメッセージについては、識別子のユーザ部分がFROMフィールドまたはP-Asserted-Identityフィールドの内容の「User-Part」に対応する。
【００４９】
一般的には本発明は１つの特定のフィルタ基準および１つの特定の選択ルールには限定されず、応答モードを選択するために、複数のフィルタ基準が同時にまたは連続して適用されてよい。
【００５０】
さらに、上記のもの以外のフィルタ基準が、組み合わせて、またはお互いに独立に第１デバイスの識別子の全てまたは一部に関連することが想定され得る。
【００５１】
所定の組が少なくとも１つの応答モードを含み、発見メッセージに対する応答が第１デバイスに送信される実施形態において、この応答(つまり、その内容)は、メッセージの受信において第２デバイスについて進行中のセッションの数および／または種類に基づく。
【００５２】
これは、例えば、第１デバイスとの既存の進行中であるダイアログがすでに存在しているか否かに応じて第１デバイスに送信される応答を適合することを可能にする。このような文脈では、第１デバイスが第２デバイスとすでに通信中であるので、第１デバイスに対するトランスペアレントな応答を送信することの問題がより小さい。一方でこれは、発見メッセージが第１デバイスによって送信された状況で、マルチメディアサービスへのアクセスを促進することを容易にすることができる。
【００５３】
さらに、これは第２デバイスで進行中のセッションの状態を第１デバイスに知らせることに役立ち、これにより第１デバイスが必要に応じて第２デバイスとのその交換を適合するように動作することが可能である。
【００５４】
本発明に基づく発見メッセージの処理は、様々なレベルで実施され得る。
【００５５】
従って処理エンティティは、具体的には第２デバイスに組み込まれ得る。
【００５６】
これは、第２デバイスのユーザが、本発明により作成可能であるフィルタリング(具体的にはフィルタ基準および選択ルール)を作成することを容易にする。
【００５７】
異なる形態では、処理エンティティは、第２デバイスを管理するマルチメディアIPコアネットワークのアプリケーションサーバに組み込まれてもよい。例えば、アプリケーションサーバは、第２デバイスに送信される発見メッセージの受信においてマルチメディアIPコアネットワークによってトリガされてもよい。
【００５８】
これは、マルチメディアIPコアネットワークのオペレータがフィルタリングを構成することを容易にする。
【００５９】
さらに、この形態では、発見メッセージを受信するデバイスの現在の動作モードを変更する必要がなく、デバイスがトランスペアレントな方法で発見メッセージに応答することによって、標準に従って動作し続けることが可能である。このとき、フィルタリングは、これらのデバイスからの応答の受信においてマルチメディアIPコアネットワークのアプリケーションサーバによって行われる。
【００６０】
本発明は、マルチメディアIPコアネットワークによって管理される端末も提供する。端末は、装置から受信され端末へ送信されるメッセージを処理するための本発明の処理エンティティを含む。
【００６１】
本発明は、デバイスを管理するマルチメディアIPコアネットワークに関連するサーバも提供する。このサーバは、デバイスへ送信される受信されたメッセージを処理するための本発明の処理エンティティを含む。
【００６２】
例示として、サーバはマルチメディアIPコアネットワークのアプリケーションサーバである。
【００６３】
異なる形態では、それは受信されたメッセージの送信先のデバイスであってよい。
【００６４】
特定の実施形態では、処理方法の種々のステップがコンピュータプログラム命令によって決定される。
【００６５】
結果として、本発明はデータ媒体上のコンピュータプログラムも提供し、プログラムは一般的にコンピュータ内にある１または２以上の処理ユニットで実施されるのが好ましく、プログラムは、上記した処理方法のステップを行うように適合される命令を含む。
【００６６】
プログラムはどのようなプログラミング言語を使っても良いし、またソースコード、オブジェクトコード、または一部がコンパイルされた形である等のソースコードとオブジェクトコードの中間的なコードの形をとっても良いし、または望まれる他のどんな形をとってもよい。
【００６７】
本発明は、上記したコンピュータプログラム命令を含むコンピュータ可読データ媒体も提供する。
【００６８】
データ媒体は、プログラムを記録することが可能などんなエンティティまたはデバイスでもありうる。例示として媒体は、例えばコンパクトディスク(CD)ROMである読み出し専用メモリ(ROM)、マイクロエレクトロニック回路ROM、または例えばフロッピーディスク(登録商標)もしくはハードディスクである磁気記憶手段である記録手段を含む。
【００６９】
さらに、データ媒体は、電気または光ケーブルを介して、電磁波、またはその他の手段で伝達されるのに適した電気または光信号等の伝送媒体であってもよい。本発明のプログラムは、具体的にはインターネットタイプのネットワークからダウンロードされてもよい。
【００７０】
代替として、データ媒体は、プログラムが組み込まれる集積回路であってよく、回路は、問題となる方法の実行を行う、または実行のために使われるように適合される。
【００７１】
その他の態様では、本発明は、
・第１デバイス、およびマルチメディアIPコアネットワークによって管理される第２デバイスであって、第１デバイスが第２デバイスの機能および状態を発見するための発見メッセージを第２デバイスに送信するように適合される、第１デバイスおよび第２デバイスと、
・第１デバイスによって第２デバイスに送信される発見メッセージを受信および処理するために適した本発明の処理エンティティと
を備える通信システムも提供する。
【００７２】
他の実施形態では、本発明の処理方法、処理エンティティ、および通信システムが上記で特定された性質のすべてまたは一部の組み合わせで提供されることも想定可能である。
【００７３】
その他の本発明の性質および利点は、非限定的な特徴を有する実施形態を開示する添付の図面を参照しながら以下の説明から明らかとなる。
【図面の簡単な説明】
【００７４】
【図１】本発明に基づく、第１実施形態における通信システムおよび処理エンティティを示す図である。
【図２】図１において示された処理エンティティのハードウェアアーキテクチャを示す図である。
【図３】第１実施形態において図１の処理エンティティによって行われる、本発明に基づく処理方法の主要ステップを示す図である。
【図４】本発明に基づく、第２実施形態における通信システムおよび処理エンティティを示す図である。
【図５】第２実施形態において図４の処理エンティティによって行われる、本発明に基づく処理方法の主要ステップを示す図である。
【発明を実施するための形態】
【００７５】
図１は、第１実施形態での本発明の処理エンティティ2を伴う２つのデバイスD1およびD2を有する本発明に基づく、その環境における通信システム1を示す。
【００７６】
例示として、デバイスD1およびD2は、スマートフォン等のマルチメディア端末であり、マルチメディアIPコアネットワークCN1およびCN2を介してお互いに通信するために適する。
【００７７】
各々は、デバイスD1およびD2のそれぞれのユーザによって(および／またはコアネットワークCN1およびCN2のオペレータによって)知られているとともにリストされた機器の種々の識別子(例えば、電話番号、SIPアドレスなど)を含む各参照RL1およびRL2を含むローカルコンタクトリスト(またはアドレス帳)を有する。
【００７８】
この例では、コアネットワークCN1およびCN2は、VoIP技術を使用するコアネットワークであり、デバイスD1およびD2をそれぞれ管理する。コアネットワークCN1およびCN2は、Document 3GPP TS 22.228「Service requirements for the IP multimedia core network subsystem (stage 1)」に具体的に定められるようなIMSアーキテクチャ、およびSIPプロトコルを実施する。
【００７９】
一方で、異なる形態で本発明は、コアネットワークCN1およびCN2が１つのマルチメディアIPコアネットワークを構成する場合にも同様に適用される。本発明はまた、その他のデバイスの種類(D1が端末であり、D2がサーバであり得る)、その他のマルチメディアIPコアネットワークアーキテクチャ、およびその他のセッション開始プロトコル、例えば、SIPプロトコルを用いた専用のコアネットワークアーキテクチャ、または遠隔の相手の能力および状態を発見するためのメッセージのための用意を与えるいくつかのその他の専用セッション開始プロトコルなどに適用される。
【００８０】
上記のこの例では、例えばRCS-eサービスなどのマルチメディア通信サービスの文脈において、第１デバイスD1により第２デバイスD2によって送信されるような遠隔の相手の能力および状態を発見するための受信されるMOPTメッセージを、処理エンティティ2が処理することが考えられる。デバイスD1およびD2はそれぞれのコアネットワークCN1およびCN2に登録されることが想定される。
【００８１】
デバイスD1によって送信されるMOPTメッセージは、上記のDocument RFC3261において仕様の詳細が説明されるようなSIP OPTIONSメッセージである。これは、FROMフィールド内に、メッセージを発信するデバイスD1の識別子ID1を含み、Request-URIフィールドおよびTOフィールド内に、メッセージの発信先デバイスD2の識別子ID2を含む。
【００８２】
デバイスD2のユーザは、コアネットワークCN2のオペレータと同意を交わしており、それらのメッセージを発信するとともに本発明の処理方法の実施に基づくデバイスの識別子に応じて送信されるSIP OPTIONSメッセージをフィルタリングするためのサービスをアクティベートする。
【００８３】
デバイスD2に対してSIP OPTIONSメッセージをフィルタリングするためのサービスのアクティベーションは、マルチメディアコアネットワークCN2のホーム購読者サーバ(home subscriber server: HSS)(図１には図示せず)に記録されるデバイスD2のユーザプロファイル内に記録される。
【００８４】
図１に示される第１実施形態では、SIP OPTIONSメッセージを処理するための本発明の処理エンティティ2がコアネットワークCN2のアプリケーションサーバ(AS)に組み込まれ、デバイスD2へ送信されるSIP OPTIONSメッセージを検出することでトリガされる。言い換えると、アプリケーションサーバ２は、本発明の意味における処理エンティティである。
【００８５】
アプリケーションサーバ2は、デバイスD2のユーザのユーザプロファイルに含まれる情報であって、コアネットワークCN2のHSSに記録される情報に従って、具体的には初期フィルタ基準(initial filter criteria: iFC)に従ってトリガされる。この情報は、加入する(subscribing)ユーザについて記録され、フィルタリングサービスをアクティベートする。アプリケーションサーバ2は、SIP OPTIONSメッセージを処理するための本発明の方法を行うための専用のサーバであってもよいし、またはすでに存在しており、他のアプリケーションを実施する際にトリガされるアプリケーションサーバであってもよい。
【００８６】
デバイスD2に送信されるSIP OPTIONSメッセージを検出するため、およびアプリケーションサーバ2をトリガするために実装される機構は、当業者に知られているものであり、従ってここではより詳細を説明しない。
【００８７】
例示として、アプリケーションサーバ2は、デバイスD1から受信されたMOPTメッセージがデバイスD2へ送信されるSIP OPTIONSメッセージであることを検知した後に(具体的には受信されたMOPTメッセージの「Request-URI」フィールドまたは「TO」フィールドによって識別される)、コアネットワークCN2のサービング・コール・セッション・コントロール・ファンクション(S-CSCF)サーバ、またはS-CSCFサーバから下流に位置するその他のいくつかのサーバによってトリガされ得る。ここでデバイスD2は、そこへ送信されたSIP OPTIONSメッセージをフィルタリングするための本発明のサービスをアクティベートしている。
【００８８】
この例では、アプリケーションサーバ2は、図２に示されるコンピュータのハードウェアアーキテクチャを有する。
【００８９】
特に、アプリケーションサーバ2は、プロセッサ2A、ランダムアクセスメモリ(RAM)2B、ROM 2C、および不揮発性フラッシュメモリ2DとともにSIPプロトコルを実行するために特に適した通信手段2Eを備える。これらの通信手段は、コアネットワークCN2のエンティティおよびデバイスD2と通信することを可能にする。
【００９０】
アプリケーションサーバ2のROM 2Cは、プロセッサ2Aによって読み取り可能であり、本発明に基づくコンピュータプログラムを記録する本発明に基づくデータ媒体を構成する。このコンピュータプログラムは、図３を参照して以下で説明される本発明の第１実施形態の処理方法のステップを実行するための命令を含む。
【００９１】
図３は、コアネットワークCN2がデバイスD1によってデバイスD2に送信されるSIP OPTIONS MOPTメッセージを受信したことでトリガされた後、第１実施形態における図１のアプリケーションサーバ2によって実行される本発明の処理方法の主要ステップを示す。
【００９２】
上記のように、本発明によって提案される処理は、(SIP OPTIONSプロトコルにおけるOPTIONSメッセージなどの)発見メッセージを、そのようなメッセージを発信するデバイスの識別子に応じてフィルタリングすること、および識別子に応じて動作し、少なくとも２つの応答モードを含む応答モードの所定の組から応答モードを選択することに、本質を有する。
【００９３】
この処理の実施は、３つの組、つまり、
１）Ωと記載される、受信された発見メッセージに応答するための可能な応答モードの組、
２）Ｃと記載される、そのような発見メッセージを発信するデバイスの識別子と比較するための１または２以上の基準で構成される組(これらの基準は識別子の全てまたは一部に関連する)、および
３）Ｓと記載される、識別子が組Ｃによって決定される１または２以上の基準を満たす場合に、発見メッセージを発信するデバイスの識別子を組Ωの応答モードと関連付けるための選択ルールの組
の事前定義に基づく。
【００９４】
従って、例として、以下の応答モードが組Ωに対して想定され得る。
・発見メッセージに対して応答しない。
・発見メッセージに対するトランスペアレントな応答を送信する。つまり応答は、SIP標準で現在定められるように、問い合わされるデバイス(つまり、この例ではD2)の状態および能力を含む。
・発見メッセージに対する部分的な応答を送信する。例えば、応答は、問い合わされるデバイスの状態を示すがその能力を含まないメッセージによって構成される、または問い合わされるデバイスの状態を示すとともにそのいくつかの能力のみを含むメッセージによって構成される、または単にその能力のみを含む所定のメッセージによって構成される。
・発見メッセージに対する所定の応答を送信する。例えば、所定の応答は、SIPプロトコルにおいて「404 NOT FOUND」、「480 TEMPORARILY UNAVAILABLE」、「408 TIME OUT」、「200 OK」、または「486 BUSY HERE」のメッセージのうちの１つによって構成される。
・発見メッセージに対する誤った応答を送信する。例えば、誤った応答は、問い合わされるデバイスの本当の状態とは異なった状態を示し、および／または問い合わされるデバイスの能力に対応しない能力を送信する。
【００９５】
同様に、発見メッセージを発信するデバイスの識別子の全てまたは一部に関連する以下の基準が、組Ｃに対して想定され得る。
・問い合わされるデバイスに関連する所定のリスト内に発見メッセージを発信するデバイスの識別子が存在するか、存在しないか。このリストは、具体的には問い合わされるデバイスに記録されるか、またはネットワーク内の遠隔機器(例えば、マルチメディアIPコアネットワークCN2内のアプリケーションサーバ2、またはデバイスD2のネットワークのオペレータの情報システム)に記録されるローカルコンタクトリスト(または「アドレス帳」)であり得る。異なる形態において、それは、問い合わされるデバイスの状態および本当の能力を受信することを許可されたデバイスの識別子のリストであり得る。異なる形態においてリストは、問い合わされるデバイスの状態および本当の能力を受信することを許可されたデバイスの識別子のリストであって、例えば、アプリケーションサーバ2またはデバイスD2のネットワークのオペレータの情報システムにおいて記録され、アプリケーションサーバ2によって閲覧可能であり、問い合わされるデバイスのユーザに構成されるリストであってよい。さらに異なる形態において、ユーザによって構成されるとともに、ユーザが自身のデバイスの状態および能力を通信することを拒否する「禁止された」識別子によって構成されるリストであってよい。このリストは、例えばアプリケーションサーバ2またはデバイスD2のネットワークのオペレータの情報システムにおいて記録され、アプリケーションサーバ2によって閲覧されることに適している。
・発見メッセージを発信するデバイスの識別子が、問い合わされるデバイスのネットワークのドメイン、または(コアネットワークのオペレータによって、もしくは問い合わされるデバイスのユーザによって)許可されたドメインに一致するネットワークドメインに属するか否か。
・発見メッセージを発信するデバイスの識別子が所定のユーザ部分(例えば、SIP OPTIONSメッセージについての識別子の「User Part」)の中に、または (例えば、プレフィックス「+33」と異なる、もしくは特定のプレフィックス「+331」、「+335」、「+338」もしくは「+339」等と異なる国際番号を含む、またはSIP URIもしくはTEL URIなどのURIの特定タイプに対応する)ユーザ部分の所定の種類に存在するか否か。
・その他。
【００９６】
最後に、以下の選択ルールが組Ｃに対して想定され得る。
・発見メッセージを発信するデバイスの識別子が問い合わされるデバイスのローカルコンタクトリスト内に存在しない場合、「発見メッセージに応答しない」応答モードが選択される。
・発見メッセージを発信するデバイスの識別子が問い合わされるデバイスのローカルコンタクトリスト内に存在する場合、「発見メッセージにトランスペアレントな応答を送信する」応答モードが選択される。
・その他。
【００９７】
一般的に、これらの例は、単に例示として与えられ、その他の応答モード、全てまたは一部の識別子に関連する他の基準、およびその他の選択ルールが本発明の範囲内で想定され得る。
【００９８】
特に、複数の基準に基づく選択ルールを定めることも可能である(例えば、発見メッセージを発信するデバイスの識別子が、問い合わされるデバイスの識別子と同じネットワークドメイン内にあり、かつ問い合わされるデバイスのローカルコンタクトリスト内にある場合、応答モードは、発見メッセージを発信するデバイスにトランスペアレントな応答を送信するように選択される)。
【００９９】
さらに、応答の内容が、デバイスD2の状態ならびに(例えば、利用可能なサービスに応じて、または対照的に使用されているサービスに応じて)デバイスD2と既に進行中であるセッションの数および／または既に進行中であるセッションの種類などのパラメータに依存する他の応答モードを想定することも可能である。
【０１００】
MOPTメッセージを処理するときに、アプリケーションサーバ2によって実行されるステップを示すために、以下の様な組Ω、Ｓ、およびＣが定められることを想定する。
・応答モードの組Ωが２つの応答モードを含む、つまり、
- モードM1：「発見メッセージに対するトランスペアレントな応答」、
- モードM2：「問い合わされるデバイスの状態のみを含む、発見メッセージに対する部分的な応答」。
・１つの基準を含む基準の組Ｃ、つまり識別子が、問い合わされるデバイスのローカルコンタクトリスト内に存在するか否か。
・選択ルールの組Ｓが２つのルールを含む、つまり、
- 識別子がローカルコンタクトリストに存在する場合、モードM1で応答する、および
- そうでない場合、モードM2で応答する。
【０１０１】
これらの組は、事前の構成ステップ(ステップE0)の間にアプリケーションサーバ2のフラッシュメモリ2Dに記録される。組Ω、Ｓ、およびＣにおける選択は、例えばウェブ、音声、およびテキスト等のインターフェイスを介してデバイスD2のユーザによって個人的に作成されてよい。
【０１０２】
デバイスD2に送信されるSIP OPTIONSメッセージの検出でトリガされた後、本発明に基づきアプリケーションサーバ2によって実行される時のMOPTメッセージの処理の説明が以下に続く。
【０１０３】
アプリケーションサーバ2のトリガリングが、アプリケーションサーバ2によるMOPTメッセージの受信を引き起こす(ステップE10)。
【０１０４】
アプリケーションサーバ2は、受信したMOPTメッセージのFROMフィールドからデバイスD1の識別子を抽出する(ステップE20)。FROMフィールドに含まれるデバイスD1の識別子は、この例では、識別子ID1である。
【０１０５】
FROMフィールドがデバイスD1の識別子を含まない、または(例えば、デバイスD1の識別子が送信においてデバイスD1によってマスクされるため)デバイスD1が匿名であることを示す場合、アプリケーションサーバ2は、MOPTメッセージがSIP PRIVACYフィールドを含むか否かを判断する。
【０１０６】
必要に応じて、アプリケーションサーバ2は、デバイスD1によって送信された後にMOPTメッセージが通過したコアネットワークCN1によって挿入および／または発行されることが可能なデバイスD1の認定されたエンティティを含むMOPTメッセージのP-Asserted-Identityフィールドが存在するか否かを判断する。
【０１０７】
既知の方法では、１つのデバイスによって他のデバイスに送信されるメッセージを伝達するネットワークは、様々なニーズ(課金、メッセージルーティング、および法的な傍受等)を満足するために、メッセージを発信するデバイスの認定された識別子を挿入することが可能である。この例では、メッセージのP-Asserted-Identityフィールドに、この識別子がコアネットワークCN1によって挿入される。
【０１０８】
必要に応じて、アプリケーションサーバ2は、このP-Asserted-Identityフィールドに含まれるデバイスD1の識別子を抽出する。
【０１０９】
アプリケーションサーバ2は、MOPTメッセージから抽出されたデバイスD1の識別子ID1が、メモリ2Dに記録された組Ｃで定められる１または２以上のフィルタ基準を満たすか否かを判断する(スッテプE30)。
【０１１０】
この想定される例では、１つのみの基準、つまり「SIP OPTIONSメッセージを発信するデバイスの識別子が問い合わされるデバイスのローカルコンタクトリスト内に存在するか否か」がメモリ2Dに記録される。
【０１１１】
つまり、ステップE30の間、アプリケーションサーバ2は、デバイスD1の識別子ID1が、デバイスD2のローカルリストRL2内に存在するか(例えば、リストされるか)否かを調べる。
【０１１２】
必要に応じて、(テストE40に「YES」を応答し)、組Ｓで定められる選択ルールに従って、アプリケーションサーバ2は、応答モードM1を選択する(ステップE50)。
【０１１３】
言い換えると、アプリケーションサーバ2は、デバイスD2の状態とともにその能力を含む、SIP OPTIONSメッセージに対するトランスペアレントな応答をデバイスD1に送信する(ステップE60)。
【０１１４】
上記のこの実施形態では、デバイスD2の状態およびその能力は、デバイスD2から直接アプリケーションサーバ2によって取得される。
【０１１５】
さらに詳細には、テストE40に対する応答が「yes」の場合、アプリケーションサーバ2は、SIP OPTIONSメッセージを第２デバイスD2にその内容を変更することなく転送(例えば、リレー)する。
【０１１６】
デバイスD2は、SIPプロトコルに従い、トランスペアレントな、つまりその状態とその能力を提供する方法でSIP OPTIONSメッセージに応答する。SIPプロトコルの動作のモードに従い、デバイスD2からの応答は、MOPTメッセージが取った経路の反対の経路に沿って返信される。従ってこの応答は、アプリケーションサーバ2を介して送信される。
【０１１７】
アプリケーションサーバ2は、デバイスD2から来る応答メッセージをインターセプトし、このメッセージを使用して、選択された応答モードM1に従いデバイスD2の状態およびその能力を含むデバイスD1へのトランスペアレントな自身の応答を生成する。
【０１１８】
上記のこの実施形態では、アプリケーションサーバ2によってデバイスD1へ送信されるトランスペアレントな応答は、SIP標準のDocument RFC3261で特定されるようなSIP OPTIONSメッセージに対する応答メッセージ(デバイスD2の状態および機能に関する同様のフォーマットと同様の内容)に類似するか、または一致する。
【０１１９】
一方で、識別子ID1がデバイスD2のローカルコンタクトリストRL2内に含まれない場合(テストE40に対して「NO」を応答し)、アプリケーションサーバ2は、組Ｓで定められる選択ルールに従って動作し、応答モードM2を選択する(ステップE70)。
【０１２０】
言い換えると、アプリケーションサーバ2は、デバイスD2の状態のみを含む部分的な応答をデバイスD1に送信する(ステップE80)。この部分的な応答は、デバイスD2の能力についての情報を含まない。
【０１２１】
ステップE60で上記したように、デバイスD2の状態についての情報は、デバイスD2を問い合わせを行う、この例では受信されたSIP OPTIONS MOPTメッセージをデバイスD2に送信するアプリケーションサーバ2によって、取得される。
【０１２２】
アプリケーションサーバ2が、誤った方法でデバイスD1に応答する、または所定のメッセージ、例えば「404 NOT FOUND」、「480 TEMPORARILY UNAVAILABLE」、または単に「408 TIME OUT」のメッセージを用いて応答することが応答モードとして想定される(選択される)場合、アプリケーションサーバ2は、デバイスD2の状態およびその能力を取得するためにデバイスD2を調査する必要がなく、直接デバイスD1に応答することができる。
【０１２３】
一方で、デバイスD2の本当の状態および／またはその本当の能力を含む応答モードが選択されるときはいつでも、アプリケーションサーバ2は、デバイスD1から受信したSIP OPTIONS MOPTメッセージをトランスペアレントな方法で(つまり、その内容を変更することなく)デバイスD2にリレーする。その後、アプリケーションサーバ2は、デバイスD2から受信する応答を、選択された応答モードのために構成される応答ルールに応じて、SIP OPTIONSメッセージへフィルタリングおよび／または適合する。
【０１２４】
従って、例示として、アプリケーションサーバ2が、デバイスD2がビジー状態であることを判断する場合、アプリケーションサーバ2は、デバイスD2の能力についての情報がない「486 BUSY HERE」応答メッセージをデバイスD1に送信する。
【０１２５】
上記の第1実施形態では、本発明に基づくデバイスD2へ送信されるSIP OPTIONS MOPTメッセージの処理が、マルチメディアIPコアネットワークCN2のアプリケーションサーバ2によって行われる。言い換えると、本発明の処理エンティティがアプリケーションサーバ2である。
【０１２６】
一方で、この想定に限定されることなく、遠隔の相手の状態および機能を発見するためのメッセージを処理するための本発明の処理エンティティは、具体的には発見メッセージの送信先のデバイス等の、いくつかのその他の機器の一部に組み込まれてもよい。
【０１２７】
図４は、その環境における、第２実施形態での本発明に基づく通信システム１’を示す。
【０１２８】
通信システム１’は、マルチメディアIPコアネットワークCN1’およびマルチメディアIPコアネットワークCN2’にそれぞれ管理される２つのデバイスD1’およびD2’を含む。この例では、デバイスD1’およびD2’は、RL1’およびRL2’としてそれぞれ示されるローカルコンタクトリストを有する端末である。
【０１２９】
第２実施形態では、本発明に基づく、デバイスD1’によりデバイスD2’に送信されるMOPT’発見メッセージの処理は、デバイスD2’自身によって行われる。言い換えると、デバイスD2’が、本発明の意味において処理エンティティである。
【０１３０】
デバイスD1’およびマルチメディアIPコアネットワークCN1’ならびにCN2’は、図１を参照して説明されたデバイスD1およびコアネットワークCN1およびCN2に類似または一致する。従って、これらの詳細はここでは再び説明しない。
【０１３１】
デバイスD2’は、図１のデバイスD2に類似する。一方で、デバイスD2’は、本発明の第２実施形態に基づく処理方法のステップを実行するための命令を有する、本発明に基づくコンピュータプログラムを記録するROM3を有する点でデバイスD2とは異なる。ROM3は、デバイスD2’のプロセッサによって読み取り可能な本発明に基づくデータ媒体を構成する。
【０１３２】
図５を参照すると共に、デバイスD1’によってデバイスD2’に送信される、遠隔の相手の状態および能力を発見するためのMOPT’メッセージを処理するためのこの第２実施形態において、デバイスD2’によって行われる主要なステップの説明がいかに続く。
【０１３３】
この例でMOPT’メッセージは、Document RFC3261で詳細に説明されるようなSIP OPTIONSメッセージである。このメッセージは、FROMフィールドに、メッセージを発信したデバイスD1’の識別子ID1’を含み、Request-URIフィールドおよびTOフィールドに、メッセージが送信されるデバイスD2’の識別子ID2’を含む。
【０１３４】
MOPT’メッセージを処理する間に、デバイスD2’に実行されるステップを説明するために、上記した組Ω、Ｓ、およびＣを再び使用する。つまり、
・応答モードの組Ωが２つの応答モードを含む、つまり、
- モードM1：「発見メッセージに対するトランスペアレントな応答」、
- モードM2：「問い合わされるデバイスの状態のみを含む、発見メッセージに対する部分的な応答」。
・１つの基準を含む基準の組Ｃ、つまり識別子が問い合わされるデバイスのローカルコンタクトリスト内に存在するか否か。
・選択ルールの組Ｓが２つのルールを含む、つまり、
- 識別子がローカルコンタクトリストに存在する場合、モードM1で応答する、および
- そうでない場合、モードM2で応答する。
【０１３５】
これらの組は、事前の構成ステップ(ステップF0)の間にデバイスD2’の不揮発性フラッシュメモリに記録される。デバイスD2’の構成、より詳細には組Ω、Ｓ、およびＣの選択は、ウェブ、音声、およびテキスト等のインターフェイスを介してデバイスD2’のユーザによって個人的に行われることが想定され得る。
【０１３６】
デバイスD1’によってデバイスD2’へ送信されるMOPT’メッセージは、コアネットワークCN1’およびCN2’を通過した後にデバイスD2’によって受信される(ステップF10)。
【０１３７】
MOPT’メッセージの受信において、デバイスD2’は、メッセージがその状態およびその機能を発見するためのメッセージであるか否か、言い換えると、本発明に基づいて処理されることが必要なSIP OPTIONSメッセージであるか否かを判断することを開始する(ステップ F20)。
【０１３８】
メッセージがSIP OPTIONSメッセージでない場合（ステップF20で「NO」を応答し）、デバイスD2’は、従来通りSIPプロトコルによって特定される方法で、メッセージの種類に応じて、メッセージを処理する(ステップF30)。
【０１３９】
受信したMOPT’メッセージがSIP OPTIONSメッセージである場合(ステップF20に対して「YES」を応答し)、デバイスD2’は、本発明に基づいてメッセージを処理する。つまり、以下のようである。
・デバイスD2’は、MOPT’メッセージのFROMフィールドまたはP-Asserted-IDフィールドからデバイスD1’の識別子ID1’を抽出する(ステップE20)。
・デバイスD2’は、識別子ID1’が、その不揮発性フラッシュメモリ内に記録される組Ｃで定められる１または２以上のフィルタ基準を満たすか否かを判断する(ステップF50)。言い換えると、この実施形態では、識別子ID1’がデバイスD2’のローカルコンタクトリストRL2’内に存在するか否かを確認する。
・必要に応じて(テストステップF60に対して「yes」を応答し)、デバイスD2’は、応答モードM1を選択し(ステップF70)、自身の「本当の」状態および能力を含む、SIP OPTIONS MOPT’メッセージに対するトランスペアレントな応答をデバイスD1’へ送信する(ステップF80)か、
・(テストステップF60に対して「NO」を応答して)、応答モードM2を選択し(ステップF90)、その状態のみを含みその能力を識別しない、SIP OPTIONS MOPT’メッセージに対する部分的な応答をデイバスD1’に送信する(ステップF100)。
【０１４０】
ステップF40、F50、F60、F70およびF90は、ステップE20、E30、E40、E50、およびE70と等しいため、これらについてより詳細をここでは説明しない。ステップF80およびF100は、ステップE60およびE80と、デバイスD2’がその状態および／またはその能力に基づきSIP MOPT’メッセージに対する応答を直接する生成する点で、それぞれ異なる。
【０１４１】
上記した２つの実施形態において、SIP OPTIONSメッセージは、デバイスD1およびD2またはデバイスD1’およびD2’の間にいかなるダイアログが存在するか否か関わらず、本発明に基づいて処理される。
【０１４２】
異なる形態では、デバイス間のスタンドアロンなトランザクション、つまりデバイス間で既に確立されているダイアログにおいて行われないトランザクション、またはそのようなダイアログを開始しないトランザクションにおいてメッセージが送信される場合に限り、本発明に基づきSIP OPTIONSメッセージを処理することを想定する事が可能である。このような状況では、発見メッセージの送信先のデバイスは、発見メッセージを発信するデバイスと通信するためのその同意がすでに与えられているため、本発明は追加の利点を提供する。
【符号の説明】
【０１４３】
2A  プロセッサ
2B  ランダムアクセスメモリ
2C  読み出し専用メモリ(ROM)
2D  不揮発性メモリフラッシュ
2E  通信手段
1, 1’  通信システム
2  アプリケーションサーバ
3  読み出し専用メモリ(ROM)
D1, D1’  第１デバイス、メッセージを発信するデバイス
D2, D2’  第２デバイス、メッセージの発信先デバイス
CN1, CN1’  D1またはD1’を管理するマルチメディアIPコアネットワーク
CN2, CN2’  D2またはD2’を管理するマルチメディアIPコアネットワーク
RL1, RL2  参照
【図１】
0006293740.tif 000002
【図２】
0006293740.tif 000003
【図３】
0006293740.tif 000004
【図４】
0006293740.tif 000005
【図５】
0006293740.tif 000006