(57)【要約】  ネットワーク用通信デバイスのためのメディアクライアント（２００）は、ネットワーク用通信デバイス内のマルチメディアアプリケーションと通信するユーザエージェント（２０２）を含む。ユーザエージェント（２０２）は、マルチメディアアプリケーション（１５０）に対する高レベルのアプリケーションインタフェースを提供する。ユーザエージェント（２０２）の制御下にあるシグナリングエージェント（２０４）は、通信セッションを確立して維持するのに必要なシグナリング操作を実行する。ユーザエージェント（２０２）の制御下にあるメディアエージェント（２０６）は、メディア操作を実行する。メディアクライアント（２００）はネットワーク内に配置され、マルチメディアアプリケーション（１５０）によってリモートアクセスされてもよい。ユーザエージェント（２０２）、シグナリングエージェント（２０４）、及びメディアエージェント（２０６）は、ネットワークインタフェース（２０８，２１０，２１２）を備え、これにより、これらの要素がネットワーク内に分散されてリモートアクセスされることが可能になる。
2008527800.tif 000002
【特許請求の範囲】
【請求項１】
メディアデバイス（３００，３５０，４００）を遠隔制御する方法であって、
インターネットプロトコルによる通信接続を介して前記メディアデバイス（３００，３５０，４００）とのマルチメディアセッションを確立するステップと、
前記マルチメディアセッションの文脈においてマルチメディアメッセージとして制御コマンドを前記メディアデバイス（３００，３５０，４００）へ送信することにより、前記メディアデバイス（３００，３５０，４００）を遠隔制御するステップと、
を備えることを特徴とする方法。
【請求項２】
前記制御コマンドは、リアルタイム伝送プロトコルを使用してテキストメッセージとして送信されることを特徴とする請求項１に記載の方法。
【請求項３】
前記制御コマンドは、メッセージセッション中継プロトコルを使用して送信されることを特徴とする請求項２に記載の方法。
【請求項４】
前記制御コマンドは、リアルタイム伝送プロトコルを使用して送信されることを特徴とする請求項２に記載の方法。
【請求項５】
前記メディアデバイス（３００，３５０，４００）はメディアプレーヤ（３５０，４００）であることを特徴とする請求項１に記載の方法。
【請求項６】
前記メディアデバイス（３００，３５０，４００）はメディアレコーダ（３００）であることを特徴とする請求項１に記載の方法。
【請求項７】
前記メディアデバイス（３００，３５０，４００）はメディアストレージデバイス（３００）であることを特徴とする請求項１に記載の方法。
【請求項８】
メディアデバイス（３００，３５０，４００）を遠隔制御するデバイス（１００）であって、
制御コマンドを生成する遠隔制御アプリケーション（１５０）と、
前記メディアデバイス（３００，３５０，４００）とのメディア接続を管理し、前記制御コマンドを前記メディアデバイス（３００，３５０，４００）への送信のためにメディアメッセージにカプセル化する、メディアエージェント（２０６）と、
を備えることを特徴とするデバイス。
【請求項９】
前記制御コマンドは、リアルタイム伝送プロトコルを使用してテキストメッセージとして送信されることを特徴とする請求項８に記載のデバイス。
【請求項１０】
前記制御コマンドは、メッセージセッション中継プロトコルを使用して送信されることを特徴とする請求項８に記載のデバイス。
【請求項１１】
前記メディアデバイス（３００，３５０，４００）はメディアプレーヤ（３５０，４００）であることを特徴とする請求項８に記載のデバイス。
【請求項１２】
前記メディアデバイス（３００，３５０，４００）はメディアレコーダ（３００）であることを特徴とする請求項８に記載のデバイス。
【請求項１３】
前記メディアデバイス（３００，３５０，４００）はメディアストレージデバイス（３００）であることを特徴とする請求項８に記載のデバイス。
【請求項１４】
メディアデバイス（３００，３５０，４００）を遠隔制御する方法であって、
インターネットプロトコルによる通信接続を介してリモートデバイス（１００）とのメディアセッションを確立するステップと、
前記メディアセッションの文脈においてメディアメッセージにカプセル化された制御コマンドを前記リモートデバイス（１００）から受信するステップと、
前記メディアメッセージから前記制御コマンドを抽出するステップと、
前記制御コマンドに応えて前記メディアデバイス（３００，３５０，４００）を制御するステップと、
を備えることを特徴とする方法。
【請求項１５】
前記制御コマンドは、リアルタイム伝送プロトコルを使用してテキストメッセージとして受信されることを特徴とする請求項１４に記載の方法。
【請求項１６】
前記制御コマンドは、メッセージセッション中継プロトコルを使用して受信されることを特徴とする請求項１５に記載の方法。
【請求項１７】
前記制御コマンドは、リアルタイム伝送プロトコルを使用して受信されることを特徴とする請求項１５に記載の方法。
【請求項１８】
前記メディアデバイス（３００，３５０，４００）はメディアプレーヤ（３５０，４００）であることを特徴とする請求項１４に記載の方法。
【請求項１９】
前記メディアデバイス（３００，３５０，４００）はメディアレコーダ（３００）であることを特徴とする請求項１４に記載の方法。
【請求項２０】
前記メディアデバイス（３００，３５０，４００）はメディアストレージデバイス（３００）であることを特徴とする請求項１４に記載の方法。
【請求項２１】
メディアデバイス（３００，３５０，４００）であって、
リモートデバイス（１００）とのメディア接続を管理し、メディアメッセージにカプセル化された制御コマンドを前記リモートデバイス（１００）から受信する、メディアエージェント（２０６）と、
前記メディアメッセージから前記制御コマンドを抽出し、前記制御コマンドに応えて前記メディアデバイス（３００，３５０，４００）を制御する、アプリケーション（１５０）と、
を備えることを特徴とするメディアデバイス（３００，３５０，４００）。
【請求項２２】
前記制御コマンドは、リアルタイム伝送プロトコルを使用してテキストメッセージとして送信されることを特徴とする請求項２１に記載のメディアデバイス（３００，３５０，４００）。
【請求項２３】
前記制御コマンドは、メッセージセッション中継プロトコルを使用して送信されることを特徴とする請求項２１に記載のメディアデバイス（３００，３５０，４００）。
【請求項２４】
前記メディアデバイス（３００，３５０，４００）はメディアプレーヤ（３５０，４００）であることを特徴とする請求項２１に記載のメディアデバイス（３００，３５０，４００）。
【請求項２５】
前記メディアデバイス（３００，３５０，４００）はメディアレコーダ（３００）であることを特徴とする請求項２１に記載のメディアデバイス（３００，３５０，４００）。
【請求項２６】
前記メディアデバイス（３００，３５０，４００）はメディアストレージデバイス（３００）であることを特徴とする請求項２１に記載のメディアデバイス（３００，３５０，４００）。
【請求項２７】
リモートデバイス（１００）がローカルメディアデバイス（３００，３５０，４００）を制御することを可能にする方法であって、
インターネットプロトコルの通信接続を介して同時的なメディアセッションを確立するステップと、
第１のメディアセッションにおいて、制御コマンドをメディアメッセージとして前記リモートデバイス（１００）から受信するステップと、
第２のメディアセッションにおいて、前記第１のメディアセッションにおいて受信した制御コマンドに応えてメディアデータを送受信するステップと、
を備えることを特徴とする方法。
【請求項２８】
前記第１及び第２のメディアセッションは共に、前記リモートデバイス（１００）とのメディアセッションであることを特徴とする請求項２７に記載の方法。
【請求項２９】
前記第２のメディアセッションにおける前記メディアデータは、前記リモートデバイス（１００）に対して送受信されることを特徴とする請求項２７に記載の方法。
【請求項３０】
前記第２のメディアセッションは、第２のリモートデバイス（１００）とのメディアセッションであることを特徴とする請求項２７に記載の方法。
【請求項３１】
前記メディアデバイス（３００，３５０，４００）はメディアプレーヤ（３５０，４００）であることを特徴とする請求項２７に記載の方法。
【請求項３２】
前記メディアデバイス（３００，３５０，４００）はメディアレコーダ（３００）であることを特徴とする請求項２７に記載の方法。
【請求項３３】
前記メディアデバイス（３００，３５０，４００）はメディアストレージデバイス（３００）であることを特徴とする請求項２７に記載の方法。
【請求項３４】
メディアデバイス（３００，３５０，４００）であって、
１以上のリモートデバイス（１００）との同時的なメディアセッションを確立するシグナリングエージェント（２０４）と、
前記１以上のリモートデバイス（１００）に対するメディア接続を管理し、第１のメディアセッションの文脈においてメディアメッセージにカプセル化された制御コマンドを第１のリモートデバイス（１００）から受信する、メディアエージェント（２０６）と、
前記制御コマンドを前記メディアメッセージから抽出し、前記制御コマンドに応えて第２のメディアセッションの文脈においてメディアデータを送受信する、アプリケーション（１５０）と、
を備えることを特徴とするメディアデバイス（３００，３５０，４００）。
【請求項３５】
前記メディアデータは前記第１のリモートデバイス（１００）に対して送受信されることを特徴とする請求項３４に記載のメディアデバイス（３００，３５０，４００）。
【請求項３６】
前記メディアデータは前記第２のリモートデバイス（１００）に対して送受信されることを特徴とする請求項３４に記載のメディアデバイス（３００，３５０，４００）。
【請求項３７】
前記メディアデバイス（３００，３５０，４００）はメディアプレーヤ（３５０，４００）であることを特徴とする請求項３４に記載のメディアデバイス（３００，３５０，４００）。
【請求項３８】
前記メディアデバイス（３００，３５０，４００）はメディアレコーダ（３００）であることを特徴とする請求項３４に記載のメディアデバイス（３００，３５０，４００）。
【請求項３９】
前記メディアデバイス（３００，３５０，４００）はメディアストレージデバイス（３００）であることを特徴とする請求項３４に記載のメディアデバイス（３００，３５０，４００）。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信ネットワークを介してメディアデバイスを遠隔制御する方法に関する。
【背景技術】
【０００２】
移動体ネットワークとＩＰネットワークとの融合により、サービスプロバイダは、移動体通信の加入者(mobile subscribers)に新しいＩＰサービスを提供することができるようになるであろう。この新しいＩＰサービスは、以前は、例えばインターネットなどのような固定ネットワーク内のユーザにのみ利用可能なものであった。更に、移動体ネットワークとＩＰネットワークとの融合により、例えばセルラ電話及び携帯情報端末（ＰＤＡ）などの移動体デバイスは、他のネットワークのデバイスと通信することが可能になるであろう。この融合により、移動体デバイスの有用性を強化しユーザエクスペリエンスを豊かにする新しい方法で、移動体デバイスを使用することが可能になるであろう。移動体デバイスの１つの可能な用途は、例えばメディアレコーダ（例えばビデオレコーダ及びオーディオレコーダ）、メディアプレーヤ（例えばビデオプレーヤ及びオーディオプレーヤ）、及びメディアストレージデバイスなどのメディアデバイスを、遠隔制御することである。
【発明の開示】
【課題を解決するための手段】
【０００３】
本発明は、例えばインターネットなどの通信ネットワークを介してメディアデバイスを遠隔制御することに関する。リモートデバイス及びメディアデバイスは共に、メディア接続を管理するメディアエージェントを含む。リモートデバイスは、制御されるメディアデバイスとのメディアセッションを確立する。メディアデバイスは、メディアセッションのコンテキストにおけるマルチメディアメッセージとして、制御メッセージをメディアデバイスへ送信する。
【０００４】
１つの代表的な実施形態において、メディアデバイスは、同時的な(concurrent)メディアセッションを確立することができる。同時的なセッションの１つは、リモートデバイスからメディアデバイスへ制御コマンドを送信するためにメディアデバイスとリモートデバイスとの間で確立される。他の同時的なセッションは、メディアデバイスへメディアを送信したりメディアデバイスからメディアを送信したりするために使用される。第２のメディアセッションは、リモートデバイスと、或いは何か他のデバイスと確立され得る。
【発明を実施するための最良の形態】
【０００５】
図１は、本発明を採用可能な移動体通信ネットワーク１０を示す図である。移動体通信ネットワーク１０の文脈で本発明を説明するが、本発明は固定ネットワーク用通信デバイス(fixed networked communication device)間の通信のための固定ネットワークにおいても使用可能であることが、当業者であれば理解できよう。本明細書で使用されるネットワーク用通信デバイス(networked communication device)という用語は、例えばインターネットなどのネットワークを介して通信可能なあらゆるデバイスを含む。
【０００６】
移動体通信ネットワーク１０は、無線アクセスネットワーク（ＲＡＮ）２０、コアネットワーク（ＣＮ）３０、及びＩＰマルチメディアサブシステム（ＩＭＳ）４０を含む。ＲＡＮ２０は、エアインタフェースを介した移動体端末１００との無線通信をサポートする。移動体端末１００は、本明細書で使用される用語としての、ネットワーク用通信デバイスである。移動体通信ネットワーク１０は、典型的には複数のＲＡＮ２０を含むが、図１には１つのみ示す。ＣＮ３０は、インターネット１２、又は例えばウェブブラウジング及びＥメールなどのパケット交換サービスのための他のパケットデータネットワーク（ＰＤＮ）への接続を提供する。ＣＮ３０は更に、例えば音声サービス及びファックスサービスなどの回線交換サービスのための、公衆交換電話網（ＰＳＴＮ）１４、及び／又はサービス総合デジタル網（ＩＳＤＮ）１６（ＰＳＴＮ１４及びＩＳＤＮのうちの少なくとも一方）への接続を提供することができる。ＣＮ３０は例えば、汎用パケット無線サービス（ＧＰＲＳ）ネットワーク、ＣＤＭＡ２０００ネットワーク、或いはＵＭＴＳネットワークを含む。ＣＮ３０は、ＩＭＳ４０と相互接続するためのアクセスゲートウェイ３２を含む。アクセスゲートウェイ３２は、ＧＰＲＳネットワークのためのＧＧＳＮ（ＧＰＲＳ  Ｇａｔｅｗａｙ  Ｓｅｒｖｉｎｇ  Ｎｏｄｅ）、或いはＣＤＭＡ２０００ネットワークのためのＰＤＳＮ（Ｐａｃｋｅｔ  Ｄａｔａ  Ｓｅｒｖｉｎｇ  Ｎｏｄｅ）を含んでもよい。ＩＭＳ４０は、アクセス技術から独立した(access independent)、ＩＰベースのマルチメディアサービスを移動体端末１００に提供し、多種多様なＩＰサービス（ＶｏＩＰ（ｖｏｉｃｅ  ｏｖｅｒ  ＩＰ）、ビデオ及びオーディオのストリーミング、Ｅメール、ウェブブラウジング、ビデオ会議、インスタントメッセージング、プレゼンス(presence)、及び他のサービスを含む）をサポートする。
【０００７】
ＩＭＳ４０は、マルチメディアアプリケーションをサポートするために、オープンなインタフェース、及び、例えばセッション開始プロトコル（ＳＩＰ）などの、アクセス技術から独立したセッション制御プロトコル（ＳＣＰ）を使用する。セッション記述プロトコル（ＳＤＰ）が、メディア能力交換(media negotiation)のために使用される。ＳＤＰは、ＩＥＴＦのＲＦＣ２３２７及びＲＦＣ３２６４に記載されている。ＳＩＰは、１以上の参加者間での通信セッションを確立し、修正し、そして終了させるための、セッション制御プロトコルである。これらのセッションは例えば、インターネットマルチメディア会議、インターネット電話の呼、及びマルチメディア配信を含み得る。ＳＩＰは、ＩＥＴＦの文書であるＲＦＣ３２６１に記載されている。本明細書で説明するように、本発明の好適な実施形態はＳＩＰを使用するが、当業者であれば、本発明は同様に他のＳＣＰを使用してもよいということが理解できよう。ＳＩＰに並んでよく知られている他のプロトコルは、Ｈ．３２３である。ＳＩＰの詳細は本発明にとって重要ではないが、本発明を文脈中により良く配置するために、ＳＩＰの短い概要を以下に示す。
【０００８】
ＳＩＰは、２以上の参加者間で通信セッションを確立するためにＡＳＣＩＩベースのシグナリングメッセージを使用する、シグナリングプロトコルである。ユーザは、本明細書ではＳＩＰアドレスと呼ばれる、固有アドレスによって識別される。ユーザは、各自に割り当てられたＳＩＰアドレスを使用して、登録サーバ（レジストラサーバ）に登録する。登録サーバは、要求に応じて、このアドレスを位置サーバへ提供する。
【０００９】
ユーザが呼を開始するとき、ＳＩＰ要求（ＳＩＰリクエスト）がＳＩＰサーバ（プロキシサーバ又はリダイレクトサーバのいずれか）へ送信される。ＳＩＰ要求は、発呼者のアドレス及び被呼者のアドレスをメッセージヘッダに含む。プロキシサーバがＳＩＰ要求を受信する場合、プロキシサーバはＳＩＰ要求を被呼者へ転送する。被呼者は、他のユーザであってもよいし、ユーザのホームネットワーク内のアプリケーションサーバであってもよい。被呼者はプロキシサーバへ応答し、プロキシサーバは同様に、応答（レスポンス）を発呼者へ転送する。発呼者はその応答について確認応答を返し、次いで、発呼者と被呼者との間でセッションが確立される。ＩＥＴＦのＲＦＣに記載されているリアルタイム伝送プロトコル（ＲＴＰ）又はＩＥＴＦのＲＦＣに記載されているメッセージセッション中継プロトコル（ＭＳＲＰ）が、発呼者と被呼者との間の通信のために使用される。
【００１０】
リダイレクトサーバがＳＩＰ要求を受信する場合、リダイレクトサーバは位置サーバにコンタクトして被呼者への経路（パス）を決定し、その情報を発呼者へ送信する。発呼者はその情報の受信について確認応答を返し、そのリダイレクション情報において特定されるサーバへＳＩＰ要求を再送する（そのサーバは、プロキシサーバの被呼者である場合もあろう）。ＳＩＰ要求が被呼者へ到達すると、被呼者は応答し、発呼者はその応答について確認応答を返す。次いで、ＲＴＰ又はＭＳＲＰを使用した通信が開始する。ＳＩＰは、呼制御及びセッション管理に関するシグナリングメッセージを処理するためにのみ使用される。
【００１１】
上述の通り、ＳＩＰにより、移動体通信ネットワーク１０内のアプリケーションは通信セッションを確立することが可能になる。このアプリケーションは、移動体端末１００内に存在してもよいし、ＩＭＳ４０内のアプリケーションサーバ内に存在してもよい。更に、このアプリケーションは、異なるネットワーク１０内に存在してもよい。
【００１２】
図２は、ＩＭＳ４０の基本的な要素、及びＣＮ３０との関係を示す図である。ＩＭＳ４０は、１以上の呼セッション制御機能（ＣＳＣＦ）４２、メディアゲートウェイ制御機能（ＭＧＣＦ）４４、メディアゲートウェイ（ＭＧＷ）４６、トランスポート・シグナリングゲートウェイ（Ｔ−ＳＧＷ）４８、及びホーム加入者サーバ（ＨＳＳ）５０を含み、これらはＩＰネットワークによって相互接続されている。ＩＭＳ４０は更に、移動体端末１００へマルチメディアサービスを提供するアプリケーションサーバ５２を含んでいてもよい。ＣＳＣＦ４２はＳＩＰサーバとして機能し、通信セッションを確立、修正、及び終了するために使用されるセッション制御シグナリングを処理する。ＣＳＣＦ４２によって実行される機能は、呼制御、アドレス変換(address translation)、認証、能力交換、及び加入者プロファイル管理を含む。ＨＳＳ５０はＣＳＣＦ４２と接続(interface)し、加入者の現在位置に関する情報、及び加入契約情報を提供する。アプリケーションサーバ５２は、マルチメディアサービス又は他のＩＰサービスを移動体端末１００へ提供する。ＭＧＣＦ４４、ＭＧＷ４６、及びＴ−ＳＧＷ４８は、例えばＰＳＴＮ又はＩＳＤＮなどの外部ネットワークとの相互作用をサポートする。ＭＧＣＦ４４は、外部ネットワークとＩＭＳ４０との間の接続を管理する１以上のＭＧＷ４６を制御する。ＭＧＣＦ４４は、ＭＧＷ４６を設定し、ＳＩＰメッセージを、例えばＩＳＤＮユーザパート（ＩＳＰＵ）メッセージなどの異なるフォーマットに変換する。ＭＧＣＦ４４は変換されたメッセージを、例えばＳＳ７ネットワークなどの外部シグナリングネットワークに対してＩＭＳ４０を接続させる、Ｔ−ＳＧＷ４８へ転送する。Ｔ−ＳＧＷ４８は、ＩＰメッセージとＳＳ７とを相互に変換するプロトコル変換器を含む。ＩＭＳ４０は追加の要素を含んでもよいが、これらは図２には示されておらず、本発明を理解するために重要なものではない。
【００１３】
本発明は、ＳＩＰ機能及びＩＭＳ機能を移動体端末１００へ提供するために、移動体端末１００に対して図３に示すメディアクライアント２００を提供する。メディアクライアント２００は、移動体通信ネットワーク１０内のＩＭＳ４０と通信してＩＰサービスを移動体端末１００へ提供することができる。更に、メディアクライアント２００は、例えばインターネットなどの通信ネットワークを介して他のネットワークデバイスと直接通信することができる。提供され得るサービスの例には、プッシュ・トゥ・トーク・オーバー・セルラ（ＰｏＣ）、プレゼンス及びインスタントメッセージング（ＩＭ）、ビデオ及びオーディオのストリーミング、ＶｏＩＰ（ｖｏｉｃｅ  ｏｖｅｒ  ＩＰ）、ビデオ会議、インタラクティブゲーム、ホワイトボード機能、及びコンテンツ共有が含まれる。メディアクライアント２００はユーザアプリケーション１５０と通信し、ユーザアプリケーション１５０を下層のネットワークプロトコルの詳細から切り離す、高レベルアプリケーションインタフェースを提供する。メディア接続は、ユーザアプリケーション１５０にとっては、パイプの別名でも知られる単純なデータストリームとして見える。パイプは、単純なオープン、クローズ、リード、ライトの各コマンドで操作することができる。
【００１４】
図３は、メディアクライアント２００の基本的なアーキテクチャを示す図である。メディアクライアント２００は、ユーザエージェント（ＵＡ）２０２、シグナリングエージェント（ＳＡ）２０４、及びメディアエージェント（ＭＡ）２０６を含む。ＵＳ２０２は、ユーザアプリケーション１５０と通信し、アプリケーションコマンドを適切なシグナリングとメディア操作とに変換する。ＳＡ２０４及びＭＡ２０６は、ＵＡ２０２による制御及び指示の下で動作する。ＵＡ２０２は、接続管理を通じて全体の制御を行うことができ、シグナリングのタスクとメディア管理のタスクとをそれぞれＳＡ２０４とＭＡ２０６とに委任する。図に示す実施形態において、ＳＡ２０４は、シグナリングのタスクを処理するためにＳＩＰ及びＳＤＰのプロトコルを実装する。ＳＡ２０４は、メッセージの伝送のためにＵＤＰ  ｏｖｅｒ  ＩＰを使用する。例えばＨ．３２３などの他のセッション制御プロトコルが使用されてもよい。シグナリングのタスクは、通信セッションをセットアップし、修正し、切断することを含み、また、セッションパラメータを交換し、能力を判定するためにリモートデバイスに問い合わせ、プレゼンスを検出することを含む。ＭＡ２０６は、メッセージセッション中継プロトコル（ＭＳＲＰ）及びリアルタイム伝送プロトコル（ＲＴＰ）を実装し、メディアを処理してメディア再生デバイス(media rendering device)へ出力するための１以上のメディアプレーヤを含む。ＭＡ２０６は、メディア接続を管理し、メディアの種類及びユーザの設定に従ってメディアをルーティングし、必要に応じてメディアを処理するようにメディアプレーヤを動作させる。ＭＡ２０６はＲＴＰメッセージ及びＭＳＲＰメッセージを伝送するために、ＴＣＰ  ｏｖｅｒ  ＩＰ、及び／又はＵＤＰ  ｏｖｅｒ  ＩＰを使用する。
【００１５】
実現方法によっては、統合型アプローチが採用され、ＵＡ２０２、ＳＡ２０４、及びＭＡ２０６を一緒に１つのアプリケーションに統合してもよい。図３に示される実施形態において、ＵＡ２０２、ＳＡ２０４、及びＭＡ２０６の間の、ネットワークインタフェース２０８、２１０、及び２１２によって、ＵＡ２０２、ＳＡ２０４、及び２０６が移動体通信ネットワーク１０内に分散されて分離したアプリケーションになり得るように実装することが可能になる。インタフェース２０８、２１０、及び２１２は、ＵＡ２０２、ＳＡ２０４、及び／又はＭＡ２０６がユーザアプリケーション１５０から離れて配置されることを可能にする、ＴＣＰソケット接続又は他の種類のネットワークインタフェースを使用してもよい。
【００１６】
分散型アプローチは、統合型アプローチに比していくつかの利点を有する。メディアクライアント２００は、ＩＭＳ４０又は他のＩＰネットワーク内のネットワークサーバ内に配置されてもよく、例えばソケット接続を開くためにｔｅｌｎｅｔを使用して、移動体端末１００から遠隔的にアクセスされてもよい。このようにして、ＩＭＳ機能を内蔵しない移動体端末１００に対してＩＭＳサービスを提供することが可能である。ＵＡ２０２、ＳＡ２０４、及びＭＡ２０６の分離により、これらの要素はネットワーク１０内に分散され、ＵＡ２０２、ＳＡ２０４、及びＭＡ２０６はネットワーク１０内の異なる位置に存在することが可能になる。帯域幅の小さな、或いは遅延の大きなネットワーク内にメディアクライアントを配置すると、性能の改善を実現することができる。なぜなら、メディアクライアント２００のための高レベルのＡＰＩは、エアインタフェースを介したシグナリングの量を減少させるからである。更に、大部分のシグナリングを生成するＳＡ２０４及びＭＡ２０６は、ネットワークのバックボーンに対してより近くに配置することができる。ＳＡ２０４及びＭＡ２０６の分離により、スタンドアロン・メディア（例えば、テレビ）デバイス、及び制御（例えば、遠隔制御）デバイスを最適化して実装することも可能になる。
【００１７】
図４は、メディアクライアント２００のいくつかの可能な構成を示す図である。図４において、ＮＣＤ  Ａ、及びＮＣＤ  Ｂは、通信ネットワークをまたぐマルチメディア通信セッションを確立している。ＮＣＤ  Ａは、ＮＣＤ１００内のユーザアプリケーション１５０と通信する、完全に機能するメディアクライアント２００を組み込んでいる。ＮＣＤ  Ｂは、内蔵のＩＭＳ機能を持たず、ネットワーク１０内に配置されたリモートのメディアクライアント２００のサービスを使用する。この場合、ＮＣＤ  Ｂ内に存在するユーザアプリケーション１５０は、ＴＣＰソケット接続（例えば、ｔｅｌｎｅｔ）を介して、ネットワークサーバ内に存在するメディアクライアント２００と通信することができる。ネットワーク内のメディアクライアント２００は、ＮＣＤ  Ａ内に存在するメディアクライアント２００と同じ機能をＮＣＤ  Ｂに提供する。メディアクライアント２００へ遠隔アクセスする能力により、ＩＭＳサービスをレガシーの（旧来の）移動体端末に拡張することが可能になる。これにより、ネットワークオペレータにとって価値のある投資をＩＭＳ技術に対して行うのに必要な、最低限の数量(critical mass)の端末を提供することができる。ＮＣＤ  Ｃは、ネットワーク用通信デバイス１００内のユーザアプリケーションと通信するＵＡ２０２を組み込んでいるが、ＳＡ２０４及びＭＡ２０６はネットワーク内に配置されている。
【００１８】
メディアクライアント２００は、例えばＰＣ又は移動体端末１００などのホストデバイス上で動作する、プロセスとして実装される。ホストデバイスは、本発明を実装するコードを格納するためのメモリ、そのコードを実行する１以上のマイクロプロセッサ、及びネットワークアクセスを提供する通信インタフェースを含む。ＵＡ２０２、ＳＡ２０４、及びＭＡ２０６は、異なるホストに存在しても構わない。起動後、メディアクライアント２００は、指定されたポート（例えば、ポート３５００）に、ＵＡ２０２とユーザアプリケーション１５０との間の通信のためのサーバソケットを開く。メディアクライアント２００と通信することを望むユーザアプリケーション１５０はいずれも、同一のポートにクライアントソケットを開くことができる。ＵＡ２０２とユーザアプリケーション１５０との間の通信のためのポートは、設定ファイルにおいて指定されてもよい。ＵＡ２０２とＳＡ２０４との間、或いはＵＡ２０２とＭＡ２０６との間の通信のために、異なるポートが開かれてもよい。
【００１９】
１つの代表的な実施形態において、ユーザアプリケーション１５０とメディアクライアント２００との間の通信のために、メディアクライアント２００はテキストベースのインタフェースプロトコル（ＵＡ  ＡＰＩ）を使用する。ユーザアプリケーション１５０とメディアクライアント２００との間の全ての通信は、テキスト文字列によってＴＣＰソケットに読み書きされる。ＩＭＳプロトコルは、通信のために２種類のメッセージ（リクエスト(request)とレスポンス(response)）を使用する。ユーザアプリケーション１５０は一般的に、トランザクションを開始するためにＵＡ２０２へリクエストを送信するが、ＵＡ２０２がユーザアプリケーション１５０へリクエストを送信してもよい。リクエストは一般的に、スペースによって区切られたパラメータを有する。ＵＡ２０２は一般的に、リクエストに応えて、レスポンスをクライアントへ送信する。暫定(provisional)レスポンスと最終(final)レスポンスという、２種類のレスポンスが存在する。暫定レスポンスは、対応するリクエストによって開始されたトランザクションを終了させない。最終レスポンスは、このトランザクションを終了させる。
【００２０】
ＵＡ２０２とＳＡ２０４との間のアプリケーションインタフェース（ＳＡ  ＡＰＩ）、及びＵＡ２０２とＭＡ２０６との間のアプリケーションインタフェース（ＭＡ  ＡＰＩ）も、ＵＡ  ＡＰＩに類似したテキストベースのインタフェースプロトコルを使用する。ＳＡ２０４又はＭＡ２０６のいずれかによる動作を要求する、ＵＡ２０２からのリクエストは、ＵＡ２０２と、ＳＡ２０４又はＭＡ２０６との間のトランザクションを開始させる。付録Ａのテーブル１は、ＵＡ  ＡＰＩのための代表的なリクエスト及びレスポンスを示す。付録Ｂのテーブル２は、ＳＡ  ＡＰＩのための代表的なリクエスト及びレスポンスを示す。付録Ｃのテーブル２は、ＭＡ  ＡＰＩのための代表的なリクエスト及びレスポンスを示す。
【００２１】
ＵＡ  ＡＰＩにおける主要なリクエストは、ＲＥＧＩＳＴＥＲリクエスト、ＣＡＬＬリクエスト、ＭＳＧリクエスト、ＡＣＣＥＰＴリクエスト、ＨＵＮＧ−ＵＰリクエスト、ＳＵＢＳＣＲＩＢＥリクエスト、ＮＯＴＩＦＹイベント、及びＰＵＢＬＩＳＨリクエストである。ＲＥＧＩＳＴＥＲリクエスト、ＳＵＢＳＣＲＩＢＥリクエスト、ＮＯＴＩＦＹリクエスト、及びＰＵＢＬＩＳＨリクエストは、標準的なＳＩＰリクエストに対応するが、ユーザアプリケーション１５０のために高レベルの抽象化を提供する。
【００２２】
ＲＥＧＩＳＴＥＲリクエストは、ＳＩＰレジストラに登録するために、ユーザアプリケーション１５０によってメディアクライアント２００へ送信される。典型的なＲＥＧＩＳＴＥＲリクエストは、"register aol.com"又は"register msn.com:5050"という形式を持つ。ＲＥＧＩＳＴＥＲリクエストに応えて、ＵＡ２０２は、ＳＩＰ登録を実行するようにＳＡ２０４に指示する。ＳＩＰレジストラに登録後、ＳＡ２０４は、登録の試みに関するステータス（例えば、成功又は失敗）を示すメッセージをＵＡ２０２へ送信する。代表的なＲＥＧＩＳＴＥＲレスポンスは、登録が成功した場合は"register 200:OK"であり、登録が成功しなかった場合は"register 1xx:failed"である。図５は、登録手続のためのシグナルフローを示す図である（更に詳細な説明は後述）。
【００２３】
ＣＡＬＬリクエストは、リモートデバイスにコンタクトするために、ユーザアプリケーション１５０によってＵＡ２０２へ送信される。ＣＡＬＬリクエストは、ＲＴＰ又はＭＳＲＰのセッションを開始するために使用される。ＣＡＬＬリクエストは、例えばユーザＩＤ、別名（エイリアス）、或いは完全に記述されたネットワークアドレスなどの、被呼者及び呼の種類を特定する情報を含む。プロキシが関与する場合、ＣＡＬＬリクエストは、被呼者のユーザＩＤを特定するであろう。プロキシが関与しない場合、ＣＡＬＬリクエストは、接続先のリモートホストに関する、完全に記述されたアドレス、及びポートを与えるであろう。呼の種類は、例えば、マイムタイプ及びサブタイプ（例えば、video/h263又はaudio/amr）を含むことができる。ＣＡＬＬリクエストは、一般的に、"call alice video/h263"又は"call alice@ims.net:5060 video/h263"又は"call 10.0.0.1:5060 video/h263"の形式を持つ。複数の呼の種類が単一のＣＡＬＬリクエストに含まれてもよい。ＣＡＬＬリクエストの結果に応じて、ＵＡ２０２は、ＣＡＬＬリクエストの結果或いはステータスを示す、ＣＡＬＬレスポンスを送信する。代表的なＣＡＬＬレスポンスは、接続が成功裏に確立された場合は"call connected"であり、接続が成功しなかった場合は"call failed"である。ＣＡＬＬレスポンスは、オプションで（任意的に）、追加情報を提供するステータスコード（例えば、ＣＡＬＬリクエストが成功しなかった理由を示すエラーコードなど）を含んでもよい。接続が成功した場合、ユーザアプリケーション１５０はＲＴＰ又はＭＳＲＰの接続を介して、メディア及び／又はメッセージの送受信を開始することができる。
【００２４】
ＣＡＬＬリクエストは、着呼の場合にもＵＡ２０２によってユーザアプリケーション１５０へ送信され得る。この場合、ＣＡＬＬリクエストは、被呼者ではなく発呼者を識別する情報を含む。それ以外の点では、ＣＡＬＬリクエストは同じである。発呼者を識別する情報は、被呼者のユーザＩＤ、又はリモートホストに関する完全に記述されたアドレスを含み得る。ＣＡＬＬリクエストがＵＡ２０２からユーザアプリケーション１５０へ送信される場合、ユーザアプリケーションはＣＡＬＬレスポンスを送信しない。代わりに、ユーザアプリケーション１５０は、ＣＡＬＬリクエストを終了させるＡＣＣＥＰＴリクエストを送信する。
【００２５】
ＡＣＣＥＰＴリクエストは、着呼を受け付け或いは拒絶するようにＵＡ２０２に指示するために、ＣＡＬＬリクエストに応えて、ユーザアプリケーション１５０によって送信される。ＡＣＣＥＰＴリクエストは、ＵＡ２０２が呼を受け付け或いは拒絶することを示すコマンドを含み、また、オプションで、例えば呼が拒絶された理由を示すコードを含む。複数の呼の種類がＣＡＬＬリクエスト中で指定された場合、ユーザアプリケーション１５０は、一部分を受け付けて残りを拒絶することができる。指定された呼の種類全てよりも少ない種類だけ受け付けるために、ユーザアプリケーションは、受け付けられた呼の種類のリストをＡＣＣＥＰＴリクエストに含める。ＵＡ２０２は、これらのリストされたものを受け付け、残りを拒絶する。ＡＣＣＥＰＴリクエスト中でいかなる呼の種類も指定されていない場合、ＵＡ２０２は、デフォルト設定により、ＣＡＬＬリクエスト中で指定された全ての呼の種類を受け付けることができる。典型的なＡＣＣＥＰＴリクエストは、呼を受け付ける"accept yes"、又は呼を拒絶する"accept no"の形式を有する。全ての指定された呼の種類よりも少ない種類だけ受け付けられる場合、ＡＣＣＥＰＴリクエストは、受け付けられる呼の種類を指定する、"accept OK audio/amr"という形式を有する。
【００２６】
接続が成功裏に行われたか否かに応じて、ＵＡ２０２はＡＣＣＥＰＴレスポンスをユーザアプリケーション１５０へ送信する。ＡＣＣＥＰＴレスポンスは、接続が成功裏に行われたか否かを示すステータスメッセージを含み、また、オプションで、ステータスコードを含む。典型的なＡＣＣＥＰＴレスポンスは、"accept OK"又は"ACCEPT Failed:1xx"の形式を有する。
【００２７】
ＭＳＧリクエストは、メッセージの送信を要求するために、ユーザアプリケーション１５０によってメディアクライアント２００へ送信される。ＭＳＧリクエストは、メッセージが送信される呼を識別するコールＩＤ又はセッションＩＤ、メッセージ長、メッセージタイプ、及びメッセージデータを含む。テキストメッセージに対しては、ＭＳＧリクエストは、"text/plain＼n this is the text"という形式である。ここで、xxxはコールＩＤ又はセッションＩＤであり、nnnはテキストのみの（改行又はヘッダを含まない）長さである。改行文字は、メッセージタイプをメッセージデータから分離する。ＭＳＧリクエストを使用して送信されるテキストメッセージの一例は、"msg 111 5 ext/plain＼n  hello"である。バイナリデータに対しては、ＭＳＧリクエストは、"msg xxx nnn mime/type＼n"という形式である。ここで、xxxはコールＩＤであり、nnnはデータバッファの長さである。バイナリメッセージの一例は、"msg 111 43 image/jpg＼n31290759...93285"である。ＵＡ２０２は、配信の成功又はＭＳＧリクエストの失敗を示す、ＭＳＧレスポンスをユーザアプリケーション１５０へ送信する。代表的なＭＳＧレスポンスは、メッセージが成功裏に配信された場合、"MSG OK"の形式を有し、メッセージが成功裏に配信されなかった場合、"MSG Failed:1xx"の形式を有する。
【００２８】
ＨＡＮＧＵＰリクエストは、接続を終了するために使用される。ＨＡＮＧＵＰリクエストは、ユーザアプリケーション１５０によってメディアクライアント２００へ送信されてもよいし、その逆であってもよい。ＨＡＮＧＵＰリクエストは、１単語"hang-up"又は１文字"h"、及び終了される呼に割り当てられたコールＩＤを含む。代表的なＨＡＮＧＵＰリクエストは、"hangup xxx"という形式である。ここで、xxxはコールＩＤである。ＨＡＮＧＵＰリクエストがユーザアプリケーションによってＵＡ２０２へ送信されると、ＵＡ２０２は、呼が終了したことを確認するために、ＨＡＮＧＵＰレスポンスを送信する。ＨＡＮＧＵＰレスポンスは、"hangup OK"又は"hangup disconnected"の形式を持ち得る。
【００２９】
ＳＵＢＳＣＲＩＢＥリクエストは、プレゼンスサービス又は他の通知サービスに申し込むために、ユーザアプリケーション１５０によってＵＡ２０２へ送信される。ＳＵＢＳＣＲＩＢＥリクエストは、サブスクリプションサービス(subscription service)に対するアドレス、ＳＵＢＳＣＲＩＢＥリクエストの有効期限(expiration time)、及びＳＵＢＳＣＲＩＢＥリクエストが関与するイベントを含む。ＳＵＢＳＣＲＩＢＥリクエストの典型的な形式は、"subscribe someone@domain.com:3600 ttt presence"又は"subscribe someone at his domain.com:3600 ttt presence autofresh"である。ここで、tttはＳＵＢＳＣＲＩＢＥリクエストの有効期限を秒単位で表す。ＳＵＢＳＣＲＩＢＥリクエストに応えて、ＵＡ２０２は、ＳＩＰサブスクリプション手続を実行するようにＳＡ２０４に指示する。ＳＩＰサブスクリプション手続が成功裏に完了した後、ＳＡ２０４はＵＡ２０２に通知し、ＵＡ２０２は同様に、ＳＵＢＳＣＲＩＢＥレスポンスを送信することによってユーザアプリケーション１５０に通知する。ＳＵＢＳＣＲＩＢＥレスポンスはサブスクリプションサービスに対するアドレス、サブスクリプションの有効期限（秒単位）、及びステータスメッセージを含む。有効期限は、要求されたものと異なっていてもよい。ＳＵＢＳＣＲＩＢＥリクエストは、オプションで、ステータスコード、及びＳＵＢＳＣＲＩＢＥリクエストの有効期限が切れたときに自動的に更新（リフレッシュ）するための"autorefresh"コマンドを含んでもよい。リクエストのリダイレクトが原因でＳＵＢＳＣＲＩＢＥリクエストが失敗する可能性がある。この場合、ＳＵＢＳＣＲＩＢＥレスポンスは新しいアドレスを返すことができ、ＵＡ２０２は、この新しいアドレスを使用して再申し込みする(re-subscribe)することができる。ＳＵＢＳＣＲＩＢＥレスポンスは、サブスクリプションが成功裏に実行された場合、"subscribe ttt me@mydomain.com:3600 successful:200"の形式を有し、サブスクリプションが失敗した場合、"subscribe ttt me@mydomain.com 3600 failed:481"の形式を有する。
【００３０】
ＮＯＴＩＦＹリクエストは、プレゼンス通知をユーザアプリケーション１５０に与えるプレゼンスエンティティのプレゼンスステータスが変化したことを、ユーザアプリケーション１５０に通知するために、ＵＡ２０２からユーザアプリケーション１５０へ送信される。ＮＯＴＩＦＹリクエストは、メッセージサイズ、ＮＯＴＩＦＹをトリガした（引き起こした）イベントの種類、メッセージ本体のマイムタイプ、及びメッセージデータを含む。ＮＯＴＩＦＹリクエストの典型的な形式は、"notify 30 someone@hisdomain.com presence application/pidf+xml＼alice is now available"である。ユーザアプリケーション１５０は、ＮＯＴＩＦＹリクエストに確認応答を返すために、"Notify OK"で応答する。
【００３１】
ＰＵＢＬＩＳＨリクエストは、プレゼンスサービス、及び他の通知サービスのために使用される。ＰＵＢＬＩＳＨリクエストは、ユーザのプレゼンス状態が変化したときにプレゼンスサーバに通知するために、ユーザアプリケーション１５０によってメディアクライアント２００へ送信される。ＰＵＢＬＩＳＨリクエストは、プレゼンスサーバのアドレス、及びＰＵＢＬＩＳＨリクエストの有効期限を含む。ＰＵＢＬＩＳＨリクエストは、オプションで、ＰＵＢＬＩＳＨリクエストの有効期限が切れたときに自動的にリフレッシュするための"autorefresh"コマンドを含んでもよい。典型的なＰＵＢＬＩＳＨリクエストは、"publish ttt me@mydomain.com 3600"の形式を持つ。ＵＡ２０２は、ユーザアプリケーション１５０に対して、ｐｕｂｌｉｃａｔｉｏｎが成功した場合は"publish ttt me@mydomain.com 3600 successful:200"で応答し、ｐｕｂｌｉｃａｔｉｏｎが失敗した場合は"publish ttt me@mydomain.com 3600 failed:481"で応答する。
【００３２】
付録Ｂのテーブル２は、ＳＡ  ＡＰＩにおいて使用されるリクエスト及びレスポンスを記載している。主要なリクエストは、ＲＥＧＩＳＴＥＲリクエスト、ＩＮＶＩＴＥリクエスト、ＡＣＫリクエスト、ＳＵＢＳＣＲＩＢＥリクエスト、ＮＯＴＩＦＹリクエスト、ＰＵＢＬＩＳＨリクエスト、ＢＹＥリクエストを含み、これらは標準的なＳＩＰリクエストに対応する。ＲＥＧＩＳＴＥＲリクエストは、ＳＩＰレジストラに登録するために使用される。ＩＮＶＩＴＥリクエスト及びＡＣＫリクエストは、ＳＩＰセッションを確立するために使用される。ＳＵＢＳＣＲＩＢＥリクエスト、ＮＯＴＩＦＹリクエスト、及びＰＵＢＬＩＳＨリクエストは、プレゼンスサービス又は他の通知サービスを実装するために使用される。ＢＹＥリクエストは、ＳＩＰセッションを終了するために使用される。ＳＡ  ＡＰＩにおいて使用されるリクエストのいくつかは、共通のＳＩＰリクエストに対応し、同じ名前を使用する。どのリクエストが言及されているかは、文脈から明白であろう。しかし、混乱を回避するために、ＳＡ２０４に対して送受信される標準的な、ＳＩＰリクエスト及びＳＩＰレスポンスを識別する、ＳＩＰというプレフィックス（接頭辞）が使用される。
【００３３】
ＲＥＧＩＳＴＥＲリクエストは、ユーザアプリケーション１５０からの対応するＲＥＧＩＳＴＥＲリクエストに応えて、ＵＡ２０２からＳＡ２０４へ送信される。ＲＥＧＩＳＴＥＲリクエストは、ＳＩＰレジストラ又はＳＩＰプロキシのネットワークアドレスを含み、また、オプションで、ポートを含む。ＲＥＧＩＳＴＥＲリクエストは、"register server@network.com"という形式である。ＳＡ２０４は、ＲＥＧＩＳＴＥＲリクエストに応えて、ＩＥＴＦのＲＦＣ３２６１に記載されているＳＩＰに従って、ＳＩＰレジストラへの登録を試みる。ＳＡ２０４は、ＲＥＧＩＳＴＥＲリクエストのステータスを示すＲＥＧＩＳＴＥＲレスポンスをＵＡ２０２へ送信する。代表的なＲＥＧＩＳＴＥＲレスポンスは、登録の試みが成功した場合は"register OK"という形式であり、登録の試みが成功しなかった場合は"register failed"という形式である。
【００３４】
ＩＮＶＩＴＥリクエストは、呼の開始側で、ユーザアプリケーション１５０からのＣＡＬＬリクエストに応えて、ＵＡ２０２からＳＡ２０４へ送信される。ＳＡ  ＩＮＶＩＴＥリクエストは、被呼者のアドレス或いは有効なアドレスへ解決（分解）可能なユーザＩＤ、確立される呼の種類を指定するコールタイプ、及び指定された各コールタイプのためのメディアセッションのために使用されるホストアドレスを含む。各コールタイプに対して同一のホストアドレスが使用されてもよいし、異なるアドレスが使用されてもよい。代表的なＩＮＶＩＴＥリクエストは、"invite alice@domain.com video/h263 me@mydomain.com:xxx audio/amr me@mydomain.com:xxx"という形式である。ここで、xxxはポート番号を示す。ＩＮＶＩＴＥリクエストの送信後、ＵＡ２０２は、ＳＡ２０４からの応答を待つ。ＳＡ２０４は、ＩＮＶＩＴＥリクエストに応えて、ＩＮＶＩＴＥリクエストにおいて指定された被呼者へＳＩＰ  ＩＮＶＩＴＥリクエストを送信し、応答を待つ。接続が成功裏に確立された場合、ＳＡ２０４は、招待(invitation)が承認された（受け付けられた）ことを示す、ＩＮＶＩＴＥレスポンスをＵＡ２０２へ送信する。ＩＮＶＩＴＥレスポンスは、本明細書においてコールＩＤと呼ぶ、セッション識別子を含む。
【００３５】
ＩＮＶＩＴＥリクエストはまた、呼の受信側で、ＳＩＰ  ＩＮＶＩＴＥの受信に応えて、ＳＡ２０４によってＵＡ２０２へ送信され得る。この場合、ＩＮＶＩＴＥリクエストは、シグナリングのために使用される発呼者のアドレス、及びメディアセッションのために発呼者によって使用される１以上のアドレスを含む。ＵＡ２０２からＳＡ２０４へのＩＮＶＩＴＥレスポンスは、セッション識別子が含まれない点を除き、上述したものと同様である。この場合、セッション識別子は、ＳＡ２０４が発呼者からＳＩＰ  ＡＣＫを受信後、ＳＡ２０４からＵＡ２０２へのＡＣＫリクエスト中で送信される。
【００３６】
ＳＵＢＳＣＲＩＢＥリクエストは、プレゼンスサービス又は他の通知サービスへのサブスクリプションを開始するために、ＵＡ２０２によってＳＡ２０４へ送信される。ＳＵＢＳＣＲＩＢＥリクエストは、ユーザがプレゼンス状態の情報を受信したい参加者、又はプレゼンスサーバの、アドレスを含む。ＳＡ２０４は、ＳＵＢＳＣＲＩＢＥリクエストをＵＡ２０２から受信すると、ＳＡＳＵＢＳＣＲＩＢＥリクエストにおいて指定されたホストへＳＩＰ  ＳＵＢＳＣＲＩＢＥリクエストを送信し、応答を待つ。ＳＩＰ  ＳＵＢＳＣＲＩＢＥリクエストの送信先のホストは、ＳＩＰ  ＮＯＴＩＦＹリクエストをＳＡ２０４へ返す。ＳＩＰ  ＮＯＴＩＦＹリクエストは、ＳＩＰ  ＳＵＢＳＣＲＩＢＥリクエストが許可(authorize)されたか否かを示し、許可された場合、現在のプレゼンス状態の情報を含む。ＳＡ２０４は、ＳＩＰ  ＮＯＴＩＦＹリクエストに対して確認応答を返し、プレゼンスエージェントのプレゼンス状態の情報を含むＮＯＴＩＦＹリクエストをＵＡ２０２へ送信する。サブスクリプションの有効期限が切れるまで、サブスクリプションを許可したプレゼンスエージェントは、プレゼンス状態の情報が変化する度にＳＩＰ  ＮＯＴＩＦＹリクエストを送信し、ＳＡ２０４は、プレゼンス情報をＵＡ２０２へ転送するために、対応するＮＯＴＩＦＹリクエストをＵＡ２０２へ送信する。
【００３７】
ＰＵＢＬＩＳＨリクエストは、ユーザのプレゼンス状態に変化があったときにプレゼンスサーバに通知するために、ＵＡ２０２によってＳＡ２０４へ送信される。ＳＡ２０４がプレゼンスサーバとして機能する場合、ＳＡ２０４は、プレゼンス状態の変化を自身の加入者(subscriber)に通知するために、ＮＯＴＩＦＹリクエストを加入者へ送信する。別のプレゼンスサーバがプレゼンス情報を配信するために使用される場合、ＳＡ２０４は、対応するＳＩＰ  ＰＵＢＬＩＳＨリクエストをプレゼンスサーバへ送信する。ＳＩＰ  ＰＵＢＬＩＳＨリクエストの送信後、ＳＡ２０４は、ＰＵＢＬＩＳＨリクエストのステータスを示すＰＵＢＬＩＳＨレスポンスをＵＡ２０２へ送信する。
【００３８】
ＢＹＥリクエストは、ＳＩＰセッションを終了させるために、ＵＡ２０２によってＳＡ２０４へ、或いはその反対へ、送信される。ＳＡ２０４はＵＡ２０２からＢＹＥリクエストを受信すると、セッションを終了させるためにＳＩＰ  ＢＹＥリクエストを相手方へ送信する。ＳＩＰ  ＢＹＥリクエストに対する確認応答が返されると、ＳＡ２０４は、ＢＹＥリクエストに対して確認応答を返すために、ＢＹＥレスポンスをＵＡ２０２へ送信する。ＵＡ２０２がＳＡ２０４からＢＹＥリクエストを受信した場合、ＵＡ２０２は、ＢＹＥリクエストにおいて指定された呼のために開かれている接続を閉じる。この場合、ＢＹＥリクエストは強制的なものなので、ＢＹＥリクエストに対する応答は必要とされない。
【００３９】
付録Ｃのテーブル３は、ＭＡ  ＡＰＩを記載している。ＭＡ  ＡＰＩにおける主要なリクエストは、ＬＩＳＴＥＮリクエスト、ＣＯＮＮＥＣＴリクエスト、ＳＥＮＤリクエスト、ＯＰＥＮリクエスト、ＰＥＥＲリクエスト、及びＣＬＯＳＥリクエストを含む。
【００４０】
ＬＩＳＴＥＮリクエストは、マルチメディアメッセージングのためのＭＳＲＰセッションを開始するために、ＵＡ２０２によってＭＡ２０６へ送信される。ＵＡ２０２は、ＭＳＲＰセッションを要求する、ユーザアプリケーション１５０からの呼のリクエストに応えて、ＬＩＳＴＥＮリクエストを送信する。ＬＩＳＴＥＮリクエストは、オプションで、接続の実行元のリモートホストのアドレスを含んでもよい。ＬＩＳＴＥＮリクエストにおいてリモートホストが指定されると、特定のホストからのみ、接続が受け付けられることになるかもしれない。ＬＩＳＴＥＮリクエストに応えて、ＭＡ２０６はメディア接続のためのポートを開き、メディア接続のためのアドレス及びポートを与えるＬＩＳＴＥＮレスポンスをＵＡ２０２へ送信する。
【００４１】
ＣＯＮＮＥＣＴリクエストは、ＭＳＲＰ接続を確立するために、呼の受信側のＵＡ２０２によってＭＡ２０６へ送信される。ＣＯＮＮＥＣＴリクエストは、一般的に、呼の受信側のユーザが発呼者からの呼に参加する招待を受け付けた後に送信される。ＣＯＮＮＥＣＴリクエストは、ＳＩＰ  ＩＮＶＩＴＥにおいて発呼側によって指定されたネットワークアドレス及びポートを含む。代表的なＣＯＮＮＥＣＴリクエストは、"connect anybody@domain.com"という形式である。ＣＯＮＮＥＣＴリクエストに応えて、ＭＡ２０６はＭＳＲＰに従って接続を確立し、ＣＯＮＮＥＣＴレスポンスをＵＡ２０２へ送信する。ＣＯＮＮＥＣＴレスポンスはＣＯＮＮＥＣＴリクエストのステータスを含み、また、オプションで、ステータスコードを含む。代表的なＣＯＮＮＥＣＴレスポンスは、"connect OK"又は"connect failed"という形式である。
【００４２】
ＳＥＮＤリクエストは、ＭＳＲＰセッションが確立されると、マルチメディアメッセージを送信するために使用される。ＵＡ２０２がＭＳＧリクエストをメディアクライアント２００から受信すると、ＵＡ２０２は、ＳＥＮＤリクエストを生成してＭＡ２０６へ送信する。ＳＥＮＤリクエストは、メッセージが送信される呼を固有に識別するコールＩＤ、メッセージ長、メッセージタイプ、及びメッセージデータを含む。代表的なＳＮＥＤリクエストは、"send xxx nnn text/plain＼n this is the text"という形式である。ＭＡ２０６は同様に、ＭＳＲＰに従ってメッセージを送信する。メッセージに対して確認応答が返されると、ＭＡ２０６は、呼を識別し、且つＳＥＮＤリクエストのステータスを示す、ＳＥＮＤレスポンスをＵＡ２０２へ送信する。ＳＥＮＤリクエストは、オプションで、ステータスコードを含んでもよい。代表的なＳＥＮＤレスポンスは、配信の成功を示す"send xxx OK"、又はメッセージが成功裏に配信されなかったことを示す"send xxx failed"という形式である。
【００４３】
ＯＰＥＮリクエストは、ＲＴＰセッションを開始するために使用される。ＵＡ２０２は、ユーザアプリケーション１５０からのＡＣＣＥＰＴリクエストに応えて、ＯＰＥＮリクエストをＭＡ２０６へ送信する。ＯＰＥＮリクエストは、オプションで、メディア接続の受け付け元のリモートホストのネットワークアドレスを含む。リモートホストのアドレスがＯＰＥＮリクエストに含まれる場合、メディア接続は、ＯＰＥＮリクエストにおいて指定されたアドレスからのみ受け付けられることになるかもしれない。ＯＰＥＮリクエストに応えて、ＭＡ２０６はメディア接続のためのポートを開き、メディア接続のためのネットワークアドレス及びポートを示すＯＰＥＮレスポンスを返す。ＯＰＥＮレスポンスは、ＯＰＥＮリクエストのステータスを示し、成功した場合、ホストのアドレス、及びＲＴＰ接続のために開かれたポートを含む。
【００４４】
メディア接続が確立されると、呼の開始側のＵＡ２０２は、ホストアドレス、及びＲＴＰセッションのために相手方で開かれたポートを、ＭＡ２０６に提供するために、ＰＥＥＲリクエストをＭＡ２０６へ送信する。ＰＥＥＲリクエストのためのパラメータは、メディア接続のためのネットワークアドレス及びポートのみである。ＰＥＥＲアドレスリクエストに対するレスポンスは要求されない。代表的なＰＥＥＲリクエストは、"peer someone@domain.com"という形式である。
【００４５】
ＣＬＯＳＥリクエストは、ＲＴＰセッション又はＭＳＲＰセッションのいずれかのために使用されるメディア接続を終了させるために使用される。ＵＡ２０２は、ユーザアプリケーション１５０からのＨＡＮＧＵＰリクエストに応えて、ＣＬＯＳＥリクエストをＭＡ２０６へ送信する。
【００４６】
ＵＡ  ＡＰＩ、ＳＡ  ＡＰＩ、及びＭＡ  ＡＰＩは更に、初期設定中に所定のパラメータを予め設定することを可能にする、ＳＥＴリクエストを有してもよい。ＳＥＴリクエストは、パラメータの名前、及びその名前のパラメータに割り当てられる値を含む。ＳＥＴリクエストは、例えばユーザ名、エイリアス、コンタクトアドレス、各種メディアのためのデフォルトの送信元(source)及び送信先(sink)などの、ユーザ固有の設定内容を設定するために使用され得る。
【００４７】
図５乃至図７は、ＩＭＳのコマンド及びレスポンスがどのようにマルチメエリアアプリケーションによって使用されるかを説明する、呼のフロー図である。図５は、典型的なＳＩＰ登録手続を説明する図である。図６は、代表的なＭＳＲＰセッションを説明する、呼のフロー図である。図７は、代表的なＲＴＰセッションを説明する、呼のフロー図である。
【００４８】
図５は、ＳＩＰ登録手続を説明する、呼のフロー図である。図５において、ユーザＡがＳＩＰレジストラに登録しようとしている。ユーザＡのユーザアプリケーション１５０は、テーブル１に示したＡＰＩを使用して、ＲＥＧＩＳＴＥＲリクエストをＵＡ２０２へ送信する（ａ）。ＵＡ２０２はリクエストを受信し、ユーザ固有の設定データを添付し、ＲＥＧＩＳＴＥＲリクエストをＳＡ２０４へ転送する。ユーザ固有の設定データは、例えばユーザ名、エイリアス、及びコンタクトアドレスなどのデータを含み得る。ＲＥＧＩＳＴＥＲリクエストに応えて、ＳＡ２０４はＳＩＰ登録手続を開始する。ＳＡ２０４は、ＵＡ２０２から受信した情報に基づいてＳＩＰ  ＲＥＧＩＳＴＥＲを構成し、必要に応じて完全なＳＩＰリクエストのためのデフォルトの設定を用いてこの情報を補強する。ＳＡ２０４はＳＩＰ  ＲＥＧＩＳＴＥＲリクエストをＳＩＰレジストラへ送信する（ｃ）。ＩＭＳコア４０は、ＳＩＰリクエストの不必要な再送信を防止するために、暫定ＳＩＰレスポンス（ＳＩＰ  １００  Ｔｒｙｉｎｇ）をＳＡ２０４へ返してもよい（ｄ）。それゆえ、ＳＡ２０４による動作は何も求められない。登録が成功した場合、ＳＩＰレジストラは、ＳＩＰレスポンス（ＳＩＰ  ２００  ＯＫ）をＳＩＰプロキシへ送信し（ｆ）、ＳＩＰプロキシはＳＩＰレジストラのレスポンスをＳＡ２０４へ中継する（ｇ）。ＳＡ２０４は、ＳＡレスポンスをユーザエージェントへ送信し（ｈ）、ユーザエージェントは登録が成功したことをユーザアプリケーション１５０に通知する。この時点で、ユーザＡは、自己の登録ＩＤを使用して、ＳＩＰメッセージを送受信することが可能である。
【００４９】
図６は、２ユーザ間での典型的なＭＳＲＰセッションにおける呼のフローを示す図である。ＭＳＲＰセッションの文脈では、ＳＥＮＤリクエストを用いて一連のメッセージを交換することができる。ＭＳＲＰは、例えばＴＣＰなどの信頼性のある伝送プロトコルを介したセッションモードでの、メッセージのエンド・トゥ・エンド伝送を提供する。ＭＳＲＰセッションは、メッセージキャリアとして、ＳＩＰを利用したＳＤＰオファー・アンサー・モデル（ＩＥＴＦのＲＦＣ３２６４）を用いて確立される。簡潔に要約すると、エンドポイントＡは、エンドポイントＡを表す一時アドレスを持つオファーメッセージ（ＳＩＰ  ＩＮＶＩＴＥ）を送信することにより、エンドポイントＢとの通信セッションを開始することができる。セッションに参加することをエンドポイントＢが望む場合、エンドポイントＢはエンドポイントＡへのＴＣＰ接続を開き、エンドポイントＡによって提供されたアドレスへ宛ててＭＳＲＰ  ＶＩＳＩＴリクエストを送信する。セッションに参加(visit)した後、エンドポイントＢは、ＳＩＰ  ＩＮＶＩＴＥリクエストへのアンサー（返答）を送信する。この返答は、通信セッションのために使用される、エンドポイントＢのアドレスを含む。このやりとりの後、エンドポイントＡ及びＢは、メッセージを交換することができる。メッセージはＳＥＮＤリクエストと共に送信され、受信側のエンドポイントはＯＫリプライにより応答する。エンドポイントＡ及びＢは、ＭＳＲＰ  ＶＩＳＩＴリクエストによって確立されたＴＣＰ接続を介して、ＳＩＰ  ＩＮＶＩＴＥのＳＤＰ  ｂｏｄｙにおいて示されるアドレスへメッセージを送信する。
【００５０】
本発明は、図６に示すように、エンドポイントＡ及びＢのユーザアプリケーションを、ＵＡ２０２、ＳＡ２０４、及びＭＡ２０６によって処理される、ＭＳＲＰ、ＳＩＰ、及びＳＤＰの詳細から分離する。図６に示す手続は、付録のテーブル１乃至３において定義されるＡＰＩを使用する。ユーザアプリケーション１５０は、ＣＡＬＬリクエストをメディアクライアント２００へ送信することにより、ＭＳＲＰセッションを開始する（ａ）。ＣＡＬＬリクエストに応えて、ＵＡ２０２は、ＭＡ  ＬＩＳＴＥＮリクエストをＭＡ２０６へ送信して、ＣＡＬＬリクエストにおいて指定される通信相手（ピア）からのＴＣＰ接続を受け付けるためにＴＣＰソケットを開くようにＭＡ２０６に指示する（ｂ）。ＭＡ２０６は、ホストのネットワークアドレス、及びメディア接続のために開かれたポートを含む、ＭＡ  ＬＩＳＴＥＮレスポンスをＵＡ２０２へ送信する（ｃ）。次いで、ＵＡ２０２は、ＳＡ  ＩＮＶＩＴＥリクエストをＳＡ２０４へ送信することにより、ＳＡ２０４が通信セッションを開始するように指示する（ｄ）。ＳＡ  ＩＮＶＩＴＥリクエストは、ＣＡＬＬリクエストに含まれるパラメータと、ＭＡ２０６によって提供されたメディア接続のためのネットワークアドレス及びポートとを含む。ＳＡ  ＩＮＶＩＴＥは、オプションで、例えばユーザ名及びエイリアスなどのユーザ固有の設定データを含んでもよい。ユーザ固有の設定データに関するパラメータ値は、テーブル１に示すＳＥＴリクエストを使用してユーザアプリケーション１５０が設定してもよい。
【００５１】
ＳＡ２０４は、ＭＳＲＰセッションを確立するために従来のＳＩＰシグナリングを使用する。ＳＡ２０４は、ＵＡ２０２から受信した情報に基づいてＳＩＰ  ＩＮＶＩＴＥリクエストを構成し、必要に応じて完全なＳＩＰ  ＩＮＶＩＴＥリクエストのためにデフォルトの設定を用いてこの情報を補強する。ＳＡ２０４は、ＳＩＰ  ＩＮＶＩＴＥリクエストをエンドポイントＢへ送信する（ｅ）。ＳＩＰ  ＩＮＶＩＴＥリクエストは、マルチメディアセッションを記述する、ＳＤＰ（セッション記述プロトコル）  ｂｏｄｙを含む。エンドポイントＢのＳＡ２０４からのレスポンスを待つ間、エンドポイントＡのＳＡ２０４は、ネットワークがエンドポイントＢとの接続を確立しようと試みていることを示す、暫定ＳＩＰレスポンス（１００  Ｔｒｙｉｎｇ）をネットワークから受信してもよい（ｆ）。
【００５２】
エンドポイントＢのＳＡ２０４によってＳＩＰ  ＩＮＶＩＴＥリクエストが受信されると、エンドポイントＢのＳＡ２０４はＩＮＶＩＴＥリクエストをＵＡ２０２へ送信する（ｈ）。また、ＳＡ２０４がエンドポイントＢのユーザを「呼び出し中である(ringing)」ということを示す、暫定レスポンスをエンドポイントＡのＳＡ２０４へ送信してもよい（ｇ）。エンドポイントＡのＳＡ２０４は同様に、エンドポイントＡのＵＡ２０２へ呼び出しの指示（表示）を提供するために、ＵＡ２０２へ暫定ＳＴＡＴＵＳレスポンスを送信してもよい（ｋ）。アプリケーションによっては、エンドポイントＡのＵＡ２０２は、エンドポイントＢのユーザへ到達するための試みが行われていることをユーザに通知するために、ユーザアプリケーション１５０に暫定ステータス情報を提供してもよい（ｌ）。
【００５３】
ＩＮＶＩＴＥリクエストに応えて、エンドポイントＢのＵＡ２０２は、ＭＳＲＰセッションへの招待が受信されたことをユーザアプリケーション１５０に通知するために、ＣＡＬＬリクエストをユーザアプリケーション１５０へ送信する（ｉ）。ＣＡＬＬリクエストは、発呼者及び呼の種類を識別する情報を含む。ＣＡＬＬリクエストに応えて、ユーザアプリケーション１５０は、呼に応答することをユーザが望むか否かを示す、ＡＣＣＥＰＴリクエストを送信する（ｊ）。この例では、エンドポイントＢのユーザは、招待を受け付ける。呼が複数の種類のメディアに関係する場合、エンドポイントＢのユーザは、どのメディアを受け付けるかをＡＣＣＥＰＴリクエスト中で指定する。次いで、エンドポイントＢのＵＡ２０２は、メディア接続（例えば、ＴＣＰ接続）を開くために、ＣＯＮＮＥＣＴリクエストをＭＡ２０６へ送信する（ｍ）。エンドポイントＢのＭＡ２０６は、ＭＳＲＰ接続を確立するために、エンドポイントＡのＭＡ２０６へＭＳＲＰ  ＶＩＳＩＴメッセージを送信する（ｎ）。エンドポイントＡのＭＡ２０６は、エンドポイントＡ及びＢの間でＭＳＲＰ接続を確立するために、ＭＳＲＰ  ＶＩＳＩＴに対して肯定応答(positive response)（ＭＳＲＰ  ２００  ＯＫ）を送信する（ｏ）。メディア接続の確立後、エンドポイントＢのＭＡ２０６は、メディア接続が成功裏に確立されたことを示すために、ＣＯＮＮＥＣＴレスポンス（Ｃｏｎｎｅｃｔ  ２００  ＯＫ）をエンドポイントＢのＵＡ２０２へ送信する（ｐ）。
【００５４】
この時点で、ＳＩＰ  ＩＮＶＩＴＥリクエストはまだ受け付けられていない。エンドポイントＢのＵＡ２０２は、ＳＡ２０４がエンドポイントＡとのＭＳＲＰセッションに参加する招待を受け付けるべきであるということを示す、ＳＡ  ＩＮＶＩＴＥレスポンス（ＩＮＶＩＴＥ  ２００  ＯＫ）をエンドポイントＢのＳＡ２０４へ送信する（ｑ）。エンドポイントＢのＳＡ２０４は、エンドポイントＡのＳＡ２０４へＳＩＰ  ＩＮＶＩＴＥレスポンス（ＳＩＰ  ２００  ＯＫ  ＋  ＳＤＰ  ｂｏｄｙ）を送信する（ｒ）。ＳＩＰ  ＩＮＶＩＴＥレスポンスは、ＭＳＲＰセッションパラメータを確認するＳＤＰ  ｂｏｄｙを含む。ＳＩＰ  ＩＮＶＩＴＥレスポンスは、ステップ（ｅ）におけるＳＩＰ  ＩＮＶＩＴＥリクエストへの返答であり、メディア接続のためにエンドポイントＢによって使用されるネットワークアドレス及びポートを含む。エンドポイントＡのＳＡ２０４は、ＳＩＰハンドシェイクを完了するために、ＳＩＰ  ２００  ＯＫに対して確認応答を返す（ｓ）。エンドポイントＡにおいて、ＳＡ２０４は、ステップ（ａ）で要求された接続が成功裏に確立されたことを示す、ＳＡ  ＩＮＶＩＴＥレスポンスを送信する（ｔ）。このメッセージは、呼を一意に識別するコールＩＤと、メディア接続のために使用される、エンドポイントＢにおけるホストアドレス及びポートとを含む。エンドポイントＡのＵＡ２０２は同様に、ステップ（ａ）で要求された接続が成功裏に確立されたことを示す、ＣＡＬＬレスポンスをユーザアプリケーション１５０へ送信する（ｕ）。エンドポイントＢで、ＳＡ２０４はＳＩＰ  ＡＣＫに応えて、エンドポイントＡとの接続が成功したことを示し、且つＳＩＰセッション識別情報を含む、ＡＣＫリクエストをＵＡ２０２へ送信する（ｖ）。ＵＡ２０２は同様に、エンドポイントＡとの接続の確立を示す、ＡＣＣＥＰＴレスポンスをユーザアプリケーション１５０へ送信する（ｗ）。この時点で、エンドポイントＡ及びＢは、メッセージの送受信を開始することができる。
【００５５】
エンドポイントＡのユーザアプリケーションがマルチメディアメッセージを生成し、このメッセージはＭＳＧリクエスト中でＵＡ２０２へ渡される（ｘ）。ＭＳＧリクエストは、セッション、メッセージタイプ、及びメッセージサイズを識別する情報を含む。ＵＡ２０２は、マルチメディアメッセージをエンドポイントＢへ転送するために、ＭＳＧリクエストにおいて指定されたパラメータを用いて、ＭＡ２０６へ宛てられたＳＥＮＤリクエストを構成し、ＭＡ２０６へ転送する（ｙ）。ＭＡ２０６は、マルチメディアメセージを配信するためにＭＳＲＰプロトコルを使用する。ＭＡ２０６は、ＭＳＲＰ  ＳＥＮＤリクエストを生成し、必要に応じて完全なＭＳＲＰ  ＳＥＮＤリクエストのためのデフォルトパラメータを補い、このリクエストをエンドポイントＢのＭＡ２０６へ送信する。エンドポイントＢのＭＡ２０６はＭＳＲＰ  ＳＥＮＤリクエストからメッセージコンテンツを抽出し、ＭＡ  ＳＥＮＤリクエスト内でこのメッセージをエンドポイントＢのＵＡ２０２へ配信する（ａａ）。エンドポイントＢのＵＡ２０２は、メッセージコンテンツをユーザアプリケーション１５０へ転送するために、ＭＳＧリクエストを使用する（ｂｂ）。エンドポイントＢのユーザアプリケーション１５０は、ＭＳＧレスポンス（ＭＳＧ  ２００  ＯＫ）を送信することによりメッセージの受信に対して確認応答を返し（ｃｃ）、ＵＡ２０２は同様に、メッセージが成功裏に配信されたことを示すＳＥＮＤレスポンスをＭＡ２０６へ転送する（ｄｄ）。ＭＡ２０６は、メッセージの受信に対して確認応答を返すために、ＭＳＲＰ  ＯＫレスポンス（ＭＳＲＰ  ２００  ＯＫ）を送信する（ｅｅ）。エンドポイントＡのＭＡ２０６は、オプションで、ＭＳＲＰレスポンス（ＭＡ  ＳＥＮＤ  ２００  ＯＫ）を変換してエンドポイントＡのＵＡ２０２へ転送してもよく（ｆｆ）、ＵＡ２０２は同様に、オプションで、メッセージが成功裏に配信されたことを示すＭＳＧレスポンス（ＭＳＧ  ２００  ＯＫ）をエンドポイントＡのユーザアプリケーション１５０へ送信してもよい（ｇｇ）。
【００５６】
セッションを終了させるために、エンドポイントＡのユーザアプリケーション１５０は、ＨＡＮＧ−ＵＰリクエストをエンドポイントＡのＵＡ２０２へ送信する（ｈｈ）。エンドポイントＢも、同様の方法でセッションを終了させることができる。エンドポイントＡのＵＡ２０２は、リクエスト中で指定された呼が終了されるべきであるということを示す、ＳＡ  ＢＹＥリクエストをエンドポイントＡのＳＡ２０４へ送信する（ｉｉ）。ＳＡ２０４は、先のステップで確立されたＳＩＰセッションパラメータに基づいてＳＩＰ  ＢＹＥリクエストを生成し、このメッセージをエンドポイントＢへ送信する（ｊｊ）。エンドポイントＢのＳＡ２０４はＳＩＰ  ＢＹＥリクエストを受信し、メッセージの受信に対して確認応答を返す（ｋｋ）。エンドポイントＡで、ＳＡ２０４は、メディアセッションが閉じられたことを確認するＢＹＥレスポンスをＵＡ２０２へ送信する（ｌｌ）。ＵＡ２０２は、メディアセッションが閉じられたことをユーザアプリケーション１５０に通知するために、ＨＡＮＧＵＰレスポンスをユーザアプリケーション１５０へ送信し（ｍｍ）、メディアセッションのために開かれた接続を閉じるために、ＣＬＯＳＥリクエストをＭＡ２０６へ送信する（ｎｎ）。エンドポイントＢのＳＡ２０４は、ＭＳＲＰセッションが閉じられたことを示すＢＹＥリクエストを生成し、ＵＡ２０２へ転送する（ｏｏ）。同様に、エンドポイントＢのＵＡ２０２は、ＭＳＲＰセッションが閉じられたことをユーザアプリケーションに通知するために、ＨＡＮＧＵＰリクエストをユーザアプリケーション１５０へ送信し（ｐｐ）、メディアセッションのために開かれた接続を閉じるためにＣＬＯＳＥリクエストをＭＡ２０６へ送信する（ｑｑ）。
【００５７】
図７は、エンドポイントＡ及びＢの間の代表的なＲＴＰセッションを示す図である。図７に示される手続は、付録のテーブル１乃至３において定義されるＡＰＩを使用する。エンドポイントＡのユーザアプリケーション１５０は、ＲＴＰセッションを開始するために、ＣＡＬＬリクエストをメディアクライアント２００へ送信する（ａ）。ＣＡＬＬリクエストは、被呼者、及び呼の種類を識別する情報を含む。ＣＡＬＬリクエストに応えて、エンドポイントＡのＵＡ２０２は、ＣＡＬＬリクエストにおいて指定された通信相手とのＲＴＰセッションのためのＵＤＰ接続を開くようにＭＡ２０６に指示する、ＭＡ  ＯＰＥＮリクエストをＵＡ２０６へ送信する（ｂ）。ＭＡ２０６はＵＤＰソケットを開き、ネットワークアドレス、及びＲＴＰセッションのために開かれたＵＤＰセッションのポートを含む、ＭＡ  ＯＰＥＮレスポンスをＵＡ２０２へ返す（ｃ）。次いで、エンドポイントＡのＵＡ２０２は、ＳＡ  ＩＮＶＩＴＥリクエストをＳＡ２０４へ送信する（ｄ）。ＳＡ  ＩＮＶＩＴＥリクエストは、ステップ（ａ）において実行されたＣＡＬＬリクエストに基づくパラメータ、及びステップ（ｃ）においてＭＡ２０６によって提供された接続情報を含み、また、オプションで、例えばユーザ名及びエイリアスなどのユーザ固有の設定を含む。ユーザ固有の設定データに関するパラメータ値は、テーブル１に示すＳＥＴリクエストを使用して、ユーザアプリケーション１５０が設定することができる。
【００５８】
ＳＡ２０４は、エンドポイントＢとの通信セッションを確立するために、従来のＳＩＰシグナリングを使用する。ＳＡ２０４は、ＳＩＰ  ＩＮＶＩＴＥリクエストをエンドポイントＢへ送信する（ｅ）。ＳＩＰ  ＩＮＶＩＴＥリクエストは、マルチメディアセッションを記述するＳＤＰ  ｂｏｄｙを含む。ＳＤＰ  ｂｏｄｙは、セッションパラメータ及びコーデックパラメータを含むメディアを記述する。エンドポイントＢのＳＡ２０４から応答を待つ間、エンドポイントＡのＳＡ２０４は、ネットワークがエンドポイントＢとの接続を確立しようと試みていることを示す暫定レスポンスをネットワークから受信してもよい（ｆ）。
【００５９】
エンドポイントＢのＳＡ２０４によってＳＩＰ  ＩＮＶＩＴＥリクエストが受信されると、エンドポイントＢのＳＡ２０４は、ＲＴＰ接続を開くために、ＳＡ  ＩＮＶＩＴＥリクエストをＵＡ２０２へ送信する（ｈ）。また、ＳＡ２０４がエンドポイントＢのユーザを「呼び出し中である」ことを示す、暫定レスポンスをエンドポイントＡのＳＡ２０４へ送信してもよい（ｇ）。エンドポイントＡのＳＡ２０４は同様に、エンドポイントＡのＵＡ２０２に対して呼び出し表示を提供するために、暫定ＳＴＡＴＵＳレスポンスをＵＡ２０２へ送信してもよい（ｋ）。アプリケーションによっては、エンドポイントＡのＵＡ２０２は、エンドポイントＢのユーザを呼び出す試みが行われていることをユーザに通知するために、ユーザアプリケーション１５０に暫定ステータス情報を提供してもよい（ｌ）。
【００６０】
ステップ（ｈ）におけるＩＮＶＩＴＥリクエストは、エンドポイントＡと、ＲＴＰセッションのための１以上のメディアタイプとを識別する情報を含む。ＵＡ２０２は、ＣＡＬＬリクエストを送信することにより、ＲＴＰセッションへの招待が受信されたことをユーザアプリケーション１５０に通知する（ｉ）。ユーザアプリケーション１５０は、ＡＣＣＥＰＴリクエストを用いてＣＡＬＬリクエストに対して応答する（ｊ）。この例では、ＡＣＣＥＰＴリクエストは、エンドポイントＢのユーザがＲＴＰセッションに参加する招待を受け付けたということを示す。呼が複数の種類のメディアに関係する場合、エンドポイントＢのユーザは、ＡＣＣＥＰＴリクエストにおいて、受け付けるメディアを指定することができる。例えば、ビデオ会議が要求された場合、エンドポイントＢのユーザは、オーディオは受け付けるが、ビデオは拒否することができる。
【００６１】
エンドポイントＢのユーザがＳＩＰ招待を受け付けた後、ＵＡ２０２は、ＲＴＰセッションのためのメディア接続を開くために、ＭＡ  ＯＰＥＮリクエストをＭＡ２０６へ送信する（ｍ）。エンドポイントＢのＭＡ２０６はＵＤＰ接続を開き、ＵＡ２０２へＭＡ  ＯＰＥＮレスポンスを送信してＲＴＰセッションのためのメディア接続に関するアドレス及びポートを与える（ｎ）。この時点では、ステップ（ｅ）で送信されたＳＩＰ  ＩＮＶＩＴＥリクエストは受け付けられていない。エンドポイントＢのＵＡ２０２は、エンドポイントＡとのＲＴＰセッションに参加する招待をＳＡ２０４が受け付けるべきであるということを示すＳＡ  ＩＮＶＩＴＥレスポンス（ＩＮＶＩＴＥ  ２００  ＯＫ）をエンドポイントＢのＳＡ２０４へ送信する（ｏ）。このリクエストは、ＯＰＥＮレスポンスにおいてＭＡ２０６によって返された、メディアホスト及びポートの情報を含む。エンドポイントＢのＳＡ２０４は、ＳＩＰ  ＩＮＶＩＴＥレスポンス（ＳＩＰ  ２００  ＯＫ＋ＳＤＰ  ｂｏｄｙ）をエンドポイントＡのＳＡ２０４へ送信する（ｐ）。ＳＩＰ  ＩＮＶＩＴＥレスポンスは、全二重通信を確立するために必要とされるＲＴＰ接続パラメータを確認する、ＳＤＰ  ｂｏｄｙを含む。ＳＩＰ  ＩＮＶＩＴＥレスポンスは、ステップ（ｅ）におけるＳＩＰ  ＩＮＶＩＴＥに対する返答である。エンドポイントＡのＳＡ２０４は、ＳＩＰハンドシェイクを完了させるために、ＳＩＰ  ２００  ＯＫレスポンスに対して確認応答を返す（ｑ）。
【００６２】
エンドポイントＡにおいて、ＳＡ２０４は、ステップ（ｄ）で要求された接続が成功裏に確立されたことを示す、ＳＡ  ＩＮＶＩＴＥレスポンスを送信する（ｒ）。このメッセージは、呼を一意に識別するコールＩＤと、メディア接続のために使用される、エンドポイントＢにおけるホストアドレス及びポートとを含む。エンドポイントＡのＵＡ２０２は同様に、ステップ（ａ）で要求された接続が成功裏に確立されたことを示すＣＡＬＬレスポンスをユーザアプリケーション１５０へ送信し（ｓ）、ＳＡ  ＩＮＶＩＴＥレスポンスに含まれるＲＴＰ接続パラメータを伴うＰＥＥＲリクエストをＭＡ２０６へ送信する（ｔ）。エンドポイントＢにおいて、ＳＡ２０４はＳＩＰ  ＡＣＫに応えて、エンドポイントＡとの接続が成功裏に確立されたことを示すＡＣＫリクエストをＵＡ２０２へ送信する（ｕ）。ＵＡ２０２は同様に、エンドポイントＡとの接続の確立を示すＡＣＣＥＰＴレスポンスをユーザアプリケーション１５０へ送信する（ｖ）。この時点で、エンドポイントＡ及びＢは、ＲＴＰメディアの送受信を開始することができる（ｗ）。
【００６３】
セッションを終了させるために、エンドポイントＡのユーザアプリケーション１５０は、ＨＡＮＧ−ＵＰリクエストをエンドポイントＡのＵＡ２０２へ送信する（ｘ）。エンドポイントＢも同様の方法でセッションを終了させることができる。エンドポイントＡのＵＡ２０２は、リクエスト中で指定されたＲＴＰセッションが終了されるべきであるということを示すＳＡ  ＢＹＥリクエストをエンドポイントＢのＳＡ２０４へ送信する（ｙ）。ＳＡ２０４は、ステップ（ｐ）で確立されたＳＩＰセッションパラメータに基づいてＳＩＰ  ＢＹＥリクエストを生成し、このメッセージをエンドポイントＢへ送信する（ｚ）。エンドポイントＢのＳＡ２０４はＳＩＰ  ＢＹＥリクエストを受信し、メッセージの受信に対して確認応答を返す（ａａ）。エンドポイントＡにおいて、ＳＡ２０４は、ＲＴＰセッションが閉じられることを確認するＢＹＥレスポンスをＵＡ２０２へ送信する（ｂｂ）。ＵＡ２０２は、ＲＴＰセッションが閉じられることをユーザアプリケーション１５０に通知するために、ＨＡＮＧＵＰレスポンスをユーザアプリケーション１５０へ送信し（ｃｃ）、ＲＴＰセッションのために開かれた接続を閉じるために、ＣＬＯＳＥリクエストをＭＡ２０６へ送信する（ｄｄ）。エンドポイントＢにおいて、ＳＡ２０４は、ＲＴＰセッションが閉じられたことを示すＢＹＥ  リクエストを生成し、ＵＡ２０２へ転送する（ｅｅ）。エンドポイントＢのＵＡ２０２は、ＲＴＰセッションが閉じられたことをユーザアプリケーションに通知するために、ＨＡＮＧＵＰリクエストをユーザアプリケーション１５０へ送信し（ｆｆ）、メディアセッションのために開かれた接続を閉じるために、ＣＬＯＳＥリクエストをＭＡ２０６へ送信する（ｇｇ）。
【００６４】
図８は、メディアクライアント２００の他の実施形態を示す図であり、メディアクライアント２００はＪＡＶＡ（登録商標）アプリケーションのためのアプリケーションインタフェースを備える。図８に示す実施形態は、前述の様に、ＵＡ２０２、ＳＡ２０４、及びＭＡ２０６を備える。元々の(native)ＵＡ  ＡＰＩに加えて、図８のメディアクライアント２００は、ＪＡＶＡアプリケーションのためのＪＡＶＡアプリケーションインタフェース（ＪＡＶＡ  ＡＰＩ）も含む。ＪＡＶＡ  ＡＰＩは、コネクション型のアプリケーションインタフェースである。ＪＡＶＡ  ＡＰＩは、ＪＡＶＡアプリケーションがＳＩＰプロキシに登録し、接続（呼）を開き、リモート側の能力について問い合わせ、メッセージを送受信し、メディアストリングをリダイレクトし、且つ接続を切ることを可能にする、コマンドを含む。元々のＩＭＡ  ＡＰＩのように、ＪＡＶＡ  ＡＰＩは高レベルの抽象化を提供し、これにより、ＪＡＶＡアプリケーションが、他お手場ＳＩＰ及びＳＤＰなどの下層プロトコルの詳細から分離される。ＪＡＶＡ  ＡＰＩにより、ＪＡＶＡアプリケーションは、ユーザエージェントと通信することが可能になる。一方で、シグナリングエージェント及びメディアエージェントは、下層のシグナリング操作及びメディア操作を処理する。ＪＡＶＡ  ＡＰＩを備えるメディアクライアント２００では、ＪＡＶＡアプリケーションは、ＪＡＶＡアプリケーション中で普通に見つかるシグナリングタスク及びオペレーションタスクを処理することにより、書き込みをより容易に行えるようになる。ＪＡＶＡアプリケーションは、例えばＳＩＰ及びＳＤＰなどの低レベルのプロトコルに直接アクセスすることができないので、異なるオペレータのネットワークや異なる移動体端末において同一のアプリケーションが機能する可能性が高まる。加えて、できの悪いＪＡＶＡアプリケーションがネットワーク内で問題を引き起こす可能性が更に低くなる。また、ＪＡＶＡアプリケーションは、低レベルのプロトコルに直接アクセスすることに伴う、設定や配備の問題について、心配する必要がない。代わりに、設定や配備の問題は、メディアクライアント２００によって処理される。デバイスの製造者は、特定のオペレータのネットワークに固有の設定をセットする、カスタマイズ処理を既に使用しており、特定のオペレータのネットワークのためにメディアクライアント２００を設定することは容易にできる。
【００６５】
本発明のいくつかの実施形態においては、ＭＡ２０６は、ユーザアプリケーション１５０がデータを処理する必要が無い場合に、ユーザアプリケーション１５０を迂回してメディアを直接メディア再生デバイスへルーティングすることが可能であってもよい。例えば、メディアストリーミングにおいて、ユーザアプリケーションは一般的にメディアストリームを受信し、データ処理をせずに円でリアストリームをメディアプレーヤへ出力する。この状況で、ＭＡ２０６は、メディアストリームを直接メディアプレーヤへルーティングすることができる。図９は、リモートデバイスからローカルメディア再生デバイス（例えば、移動体端末１００のスピーカ及び／又はディスプレイ）への、典型的なメディア（例えば、ビデオ又はオーディオ）のストリーミングを示す図である。メディアストリームは、プロトコルスタックの下層を通り、ＭＡ２０６によって、例えばビデオデコーダなどのメディアプレーヤへ直接ルーティングされる。メディアストリームは、ＩＰスタック、ＵＤＰスタック、及びＲＴＰスタックを順に通って、ビデオデコーダへと、上層へ進む。図９はまた、カメラからの出力が、リモートデバイスへの送信のために、ＲＴＰスタック、ＵＤＰスタック、及びＩＰスタックを順に通って、下層へ進むことも示す。メディアストリームも、カメラの出力も、ＭＡ２０４の上層やアプリケーションレイヤーへ流れ込むことはない。アプリケーションによっては、ユーザアプリケーション１５０は、メディアストリームを受信することを望むかもしれない。図１０は、ユーザアプリケーションからの、また、ユーザアプリケーションへの、典型的なメディアストリームを示す図である。
【００６６】
本発明の好適な実施形態において、ユーザアプリケーション１５０は、メディア又はメッセージがどのようにルーティングされるかを指示することができる。ユーザアプリケーション１５０によるメディアの選択的なルーティングを可能にするために、ＵＡ  ＡＰＩは、ＳＥＴＲＯＵＴＥリクエストを含むことができる。ＳＥＴＲＯＵＴＥリクエストは、メディアストリームの特定の送信元(source)又は送信先(sink)を指定するために、ユーザアプリケーション１５０によってメディアクライアント２００へ送信される。送信元又は送信先は、移動体端末１００の内部にあってもよいし外部にあってもよい。ＭＡ  ＡＰＩは、対応するＳＥＴＲＯＵＴＥリクエストを含み、これは、メディアストリームがどのようにルーティングされるかを指定するルーティングテーブルを設定するために、ＵＡ２０２によってＭＡ２０６へ送信される。ＵＡ  ＡＰＩ及びＭＡ  ＡＰＩはまた、例えば実行中の（アクティブな）メディアストリームを中断させるためのＰＡＵＳＥリクエスト、及び中断されたメディアストリームを再開するためのＲＥＳＵＭＥリクエストなどの、メディアストリームを制御するための他のリクエストを含んでもよい。
【００６７】
図１１及び図１２は、本発明のメディアクライアントを使用可能な多様な方法を示す図である。図１１は、３つのネットワーク通信デバイス（移動体デバイス１００、ビデオカメラ３００、及びビデオプレーヤ３５０）を図示する。移動体デバイス１００は、図３に示すように、メディアクライアント２００を組み込んでおり、メディアクライアント２００は、ＵＡ２０２、ＳＡ２０４、及びＭＡ  ２０６を含む。ビデオプレーヤ３５０は、ＭＡ２０６を組み込んでいる。この例では、移動体デバイス１００のユーザは、ビデオカメラ３００から遠隔地のビデオプレーヤ３０５へ向けてビデオを再生することを望む。これは例えば、休暇で不在のときに自分の家を監視するのに有用であろう。移動体デバイス１００のＵＡ２０２は、遠隔地のビデオプレーヤ３５０のＭＡ２０６とのＴＣＰ接続を確立する。移動体デバイス１００のＳＡ２０４は、ＳＩＰを使用して、ビデオカメラ３００とのシグナリング接続を確立する。移動体デバイス１００、ビデオカメラ３００、及びビデオプレーヤの間の通信は、インターネット又は他の通信ネットワーク１２を介したピア・トゥ・ピアのものである。
【００６８】
メディアセッションを開始するために、移動体デバイス１００のアプリケーション１５０は、図７に示す手続を使用する。アプリケーション１５０は、やはり移動体デバイス１００に配置されているＵＡ２０２へＣＡＬＬリクエストを送信することにより、メディアセッションを開始する。移動体デバイス１００のＵＡ２０２は、ＲＴＰセッションのためのＵＤＰソケット接続を開くために、遠隔地のビデオプレーヤ３５０のＭＡ２０６へＯＰＥＮリクエストを送信する。ＯＰＥＮリクエストは、ＴＣＰソケット接続を介して送信される。なお、この例における移動体デバイス１００は、遠隔地に配置されているＭＡ２０６を制御している。ビデオプレーヤ３５０のＭＡ２０６は、ＲＴＰ接続のためのネットワークアドレス及びポートを、移動体デバイス１００のＵＡ２０２へ返す。ＵＡ２０２は、ＩＮＶＩＴＥリクエストをＳＡ２０４へ送信することにより、ＲＴＰセッションを確立するようにＳＡ２０４に指示する。ＳＡ２０４も、移動体デバイス１００に配置されている。ＩＮＶＩＴＥリクエストは、ビデオプレーヤ３５０のＭＡ２０６によって提供されたネットワークアドレス及びポートを含む。ビデオプレーヤ３５０によって提供されたネットワークアドレス及びポートは、ビデオカメラ３００へ送信されるＳＩＰ  ＩＮＶＩＴＥに含まれる。ビデオカメラ３００は、ＲＴＰ接続のためのネットワークアドレス及びポートを、移動体デバイス１００のＳＡ２０４へ返す。移動体デバイス１００のＳＡ２０４は同様に、この情報をＵＡ２０２に提供する。移動体デバイス１００のＵＡ２０２は、ビデオプレーヤ３５０とビデオカメラ３００との間でＲＴＰ接続を確立するために、ビデオカメラ３００によって提供されたネットワークアドレス及びポートを含むＰＥＥＲリクエストを、ビデオプレーヤ３５０のＭＡ２０６へ送信する。その後、ビデオプレーヤ３５０は、ビデオカメラ３００からビデオストリームを受信することができる。
【００６９】
図１２に示す例では、２つのネットワーク用通信デバイス（移動体デバイス１００、及びＤＶＲ／ＤＶＤプレーヤ４００（ここでは、単に「ＤＶＤプレーヤ４００」と呼ぶ））が存在する。移動体デバイス１００のユーザは、遠隔地のＤＶＤプレーヤ４００から移動体デバイス１００に向かって、ＤＶＤ又は格納されたデジタルビデオを再生することを望む。ＤＶＤプレーヤ４００は、例えば、ユーザの家に配置されている。移動体デバイス１００及びＤＶＤプレーヤ４００は共に、図３に示すメディアクライアントを組み込んでいる。ＤＶＤプレーヤ４００のアプリケーションは、ＤＶＤプレーヤ４００の動作を制御し、以下に説明するようなインターネットを介した遠隔制御を可能にする。移動体デバイス１００は、ＭＳＲＰを使用してＤＶＤプレーヤ４００へコマンドを送信することにより、ＤＶＤプレーヤ４００を遠隔制御する。遠隔制御コマンドは、移動体デバイス１００からＤＶＤプレーヤ４００へテキストメッセージとして送信される。ＤＶＤプレーヤに適した代表的なコマンドには、「再生」「停止」「中断（一時停止）」「再開」「早送り」「選択」が含まれる。ＭＳＲＰを介して送信されるテキストベースのコマンドを使用して、移動体デバイス１００は、インターネットを介してビデオ及び／又はオーディオを移動体デバイス１００へ流すようにＤＶＤプレーヤ４００に指示することができる。
【００７０】
ＤＶＤプレーヤ４００を遠隔制御するために、移動体デバイス１００は、コマンド及び／又は制御信号をＤＶＤプレーヤへ送信するためのＭＳＲＰセッションと、ＤＶＤプレーヤ４００から移動体デバイス１００へビデオ及び／又はオーディオを流すための独立したＲＴＰセッションとを、ＤＶＤプレーヤ４００との間で確立する。ＭＳＲＰセッション及びＲＴＰセッションは、それぞれ図６及び図７に示すような手続を使用して確立される。ＭＳＲＰを使用して、移動体デバイス１００は、コマンドをテキストメッセージとしてＤＶＤプレーヤ４００へ送信する。この例では、ＭＳＲＰメッセージは、ＤＶＤプレーヤ４００のメディアクライアントによってアプリケーション１５０へ渡される。アプリケーション１５０は、ここでは、遠隔制御アプリケーションと呼ぶ。ＤＶＤプレーヤ４００の遠隔制御アプリケーション１５０は、移動体デバイス１００によって送信されたコマンドを解析し、それに従ってＤＶＤプレーヤ４００を制御する。図８及び図９に示すように、ＤＶＤプレーヤ４００は、メディアストリームを選択的にルーティングする能力を備えていてもよい。ＤＶＤプレーヤ４００の遠隔制御アプリケーション１５０は、ＳＥＴＲＯＵＴＥリクエストを使用して、ＲＴＰセッション内でビデオ及び／又はオーディオのストリームを移動体デバイス１００へ送信するようにＤＶＤプレーヤ４００に指示することができる。また、当業者であれば、移動体デバイス１００は他の遠隔地のネットワーク用通信デバイスへメディアを送信するようにＤＶＤプレーヤ４００に指示できることが認識できよう。
【００７１】
図１２に示す方法は、例えばビデオカメラ、デジタルスチルカメラ、プリンタ、スキャナ、コピー機、ホームステレオシステム、テレビ、或いはコンピュータなどの、多種多様なデバイスを遠隔制御するために使用可能である。また、当業者であれば、移動体デバイス１００からリモートデバイスへメディアが流されてもよいことが認識できよう。例えば、本発明は、携帯（ポータブル）ＤＶＤプレーヤ又はポータブルＣＤプレーヤからホームコンピュータへオーディオを流し、オーディオがホームコンピュータで記録して格納されるように、使用可能である。他の例として、本発明は、ホームコンピュータでビデオ及び／又はオーディオを記録して格納するために、ポータブルビデオカメラからホームコンピュータへビデオ及び／又はオーディオを流すために使用可能である。
【００７２】
もちろん、本発明の精神及び本質的な特徴から逸脱すること無く、本明細書で説明した以外の特定の方法で、本発明を実施することも可能である。それゆえ、これらの各実施形態は全ての点において、説明的なものであり、限定するためのものではないと解釈されなければならない。そして、添付の請求の範囲の意味及び均等物の中で行われる全ての変更は、ここに包含されることが意図されている。
【図面の簡単な説明】
【００７３】
【図１】本発明のメディアクライアントを使用可能な無線通信ネットワークの機能ブロック図である。
【図２】移動体通信ネットワーク内のＩＰマルチメディアサブシステム（ＩＭＳ）の基本的な構成要素を示すブロック図である。
【図３】本発明に係るメディアクライアントのアーキテクチャを示す図である。
【図４】メディアクライアントを実装する多様な方法を示す図である。
【図５】ＳＩＰ登録手続を説明する、呼のフロー図である。
【図６】ＭＳＲＰセッションを説明する、呼のフロー図である。
【図７】ＲＴＰセッションを説明する、呼のフロー図である。
【図８】ＪＡＶＡアプリケーションインタフェースを備えるメディアクライアントに関する代替実施形態を示す図である。
【図９】本発明に従う、メディアコンテンツの選択的なルーティングを示す図である。
【図１０】本発明に従う、メディアコンテンツの選択的なルーティングを示す図である。
【図１１】ビデオサーバとリモートビデオプレーヤとの間でメディアセッションを確立するために本発明が使用される適用場面（アプリケーション）を示す図である。
【図１２】ＤＶＤプレーヤを遠隔制御し、遠隔地のＤＶＤプレーヤから移動体通信デバイスへメディアを流すために、本発明が使用される適用場面を示す図である。
【図１】
2008527800.tif 000003
【図２】
2008527800.tif 000004
【図３】
2008527800.tif 000005
【図４】
2008527800.tif 000006
【図５】
2008527800.tif 000007
【図６】
2008527800.tif 000008
【図７】
2008527800.tif 000009
【図８】
2008527800.tif 000010
【図９】
2008527800.tif 000011
【図１０】
2008527800.tif 000012
【図１１】
2008527800.tif 000013
【図１２】
2008527800.tif 000014
【手続補正書】
【提出日】平成20年5月8日(2008.5.8)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
メディアデバイス（３００，３５０，４００）を遠隔制御する方法であって、
所定のメディアフォーマットでメディアコンテンツを送信するために、インターネットプロトコルによる通信接続を介して前記メディアデバイス（３００，３５０，４００）とのメディアセッションを確立するステップと、
前記メディアセッションの文脈においてメディアメッセージとして制御コマンドを前記メディアデバイス（３００，３５０，４００）へ送信することにより、前記メディアデバイス（３００，３５０，４００）を遠隔制御するステップと、
を備えることを特徴とする方法。
【請求項２】
メディアデバイス（３００，３５０，４００）を遠隔制御する方法であって、
リモートデバイスから所定のメディアフォーマットでメディアコンテンツを受信するために、インターネットプロトコルによる通信接続を介して前記リモートデバイス（１００）とのメディアセッションを確立するステップと、
前記メディアセッションの文脈においてメディアメッセージにカプセル化された制御コマンドを前記リモートデバイス（１００）から受信するステップと、
前記メディアメッセージから前記制御コマンドを抽出するステップと、
前記制御コマンドに応えて前記メディアデバイス（３００，３５０，４００）を制御するステップと、
を備えることを特徴とする方法。
【請求項３】
リモートデバイス（１００）がローカルメディアデバイス（３００，３５０，４００）を制御することを可能にする方法であって、
前記リモートデバイス（１００）と前記ローカルメディアデバイス（３００，３５０，４００）との間で所定のメディアフォーマットでメディアコンテンツを転送するために、インターネットプロトコルの通信接続を介して同時的なメディアセッションを確立するステップと、
第１のメディアセッションにおいて、制御コマンドをメディアメッセージとして前記リモートデバイス（１００）から受信するステップと、
第２のメディアセッションにおいて、前記第１のメディアセッションにおいて受信した制御コマンドに応えて、選択されたメディアコンテンツを送信又は受信するステップと、
を備えることを特徴とする方法。
【請求項４】
前記第２のメディアセッションは第２のリモートデバイスとのメディアセッションであり、
前記ローカルメディアデバイスは前記第１のリモートデバイスから制御コマンドを受信し、
前記ローカルメディアデバイスは前記第２のリモートデバイスへメディアデータを送信するか、又は前記第２のリモートデバイスからメディアデータを受信する
ことを特徴とする請求項３に記載の方法。
【請求項５】
前記制御コマンドは、メッセージセッションリレープロトコル及びリアルタイム伝送プロトコルのうちの一方を使用して送信又は受信されることを特徴とする請求項１乃至４のいずれか１項に記載の方法。
【請求項６】
メディアデバイス（３００，３５０，４００）を遠隔制御するデバイス（１００）であって、
制御コマンドを生成する遠隔制御アプリケーション（１５０）と、
前記メディアデバイスへ所定のメディアフォーマットでメディアコンテンツを送信するために、前記メディアデバイスとのメディアセッションを確立するシグナリングエージェント（２０４）と、
前記メディアデバイス（３００，３５０，４００）とのメディア接続を管理し、前記制御コマンドを前記メディアデバイス（３００，３５０，４００）への送信のためにメディアメッセージにカプセル化する、メディアエージェント（２０６）と、
を備えることを特徴とするデバイス。
【請求項７】
メディアデバイス（３００，３５０，４００）であって、
リモートデバイスから所定のメディアフォーマットでメディアコンテンツを受信するために、前記リモートデバイス（１００）とのメディアセッションを確立するシグナリングエージェント（２０４）と、
前記リモートデバイス（１００）とのメディア接続を管理し、メディアメッセージにカプセル化された制御コマンドを前記リモートデバイス（１００）から受信する、メディアエージェント（２０６）と、
前記メディアメッセージから前記制御コマンドを抽出し、前記制御コマンドに応えて前記メディアデバイス（３００，３５０，４００）を制御する、アプリケーション（１５０）と、
を備えることを特徴とするメディアデバイス（３００，３５０，４００）。
【請求項８】
メディアデバイス（３００，３５０，４００）であって、
前記メディアデバイスとリモートデバイスとの間で所定のメディアフォーマットでメディアコンテンツを転送するために、リモートデバイス（１００）との同時的なメディアセッションを確立するシグナリングエージェント（２０４）と、
前記リモートデバイス（１００）に対するメディア接続を管理し、第１のメディアセッションの文脈においてメディアメッセージにカプセル化された制御コマンドを第１のリモートデバイス（１００）から受信する、メディアエージェント（２０６）と、
前記制御コマンドを前記メディアメッセージから抽出し、前記制御コマンドに応えて第２のメディアセッションの文脈においてメディアコンテンツを送信又は受信する、アプリケーション（１５０）と、
を備えることを特徴とするメディアデバイス（３００，３５０，４００）。
【請求項９】
前記シグナリングエージェントは、前記第１のメディアセッションを第１のリモートデバイスと、前記第２のメディアセッションを第２のリモートデバイスと、それぞれ確立し、
前記アプリケーションは、前記第２のメディアセッションの文脈において、前記第２のリモートデバイスへメディアデータを送信するか、又は前記第２のリモートデバイスからメディアデータを受信する
ことを特徴とする請求項８に記載のメディアデバイス。
【請求項１０】
前記制御コマンドは、メッセージセッションリレープロトコル及びリアルタイム伝送プロトコルのうちの一方を使用して送信又は受信されることを特徴とする請求項６乃至９のいずれか１項に記載のデバイス。
【国際調査報告】
2008527800.tif 000015
2008527800.tif 000016
2008527800.tif 000017