JP5172850B2 - セッションベースの通信 - Google Patents

Description

本発明は、通信システムにおけるセッションベースの通信に係り、より詳細には、複数のメディア形式をオファーできる通信に係る。

背景技術の以下の説明は、洞察、発見、理解又は開示或いは関連を、本発明以前に当該技術で知られておらず本発明により提供される開示と一緒に含む。本発明の幾つかのこのような貢献を以下に特に指摘するが、本発明の他のこのような貢献は、それらの状況から明らかとなろう。

特に、ＩＰベースの通信技術及びエンドユーザターミナルのような通信技術の進化で、多様な通信の可能性が生じると共に、異なるサービスが導入された。通信システムに垂直的に一体化されたものでなく、マルチメディアアーキテクチャーを構築するツールであるＳＩＰ（セッションイニシエーションプロトコル）により提供されるプリミティブを使用して、益々多くのサービスが実施されている。より詳細には、ＳＩＰは、１人以上の参加者とのセッションを生成し、変更し、終了するためのＩＥＴＦ定義のアプリケーション−レイヤ制御（シグナリング）プロトコルである。

ＳＩＰセッションを利用できる１つの特定の特徴は、グループ通信である。ここで使用する「グループ」という語は、２人以上のユーザの論理的なグループ、即ち同じグループ通信に参加することが意図されるグループメンバーを指し、そしてグループ通信は、２人以上の参加者の間のセッションをカバーする。グループ通信は、例えば、会議、インターネット電話コール、マルチメディア配布、マルチメディア会議、インスタントメッセージング、及びチャットを含む。

多様な通信の可能性があるために、ボイス、インスタントメッセージ、ビデオ、ゲームサービス、音楽、ファイル転送、等の異なるメディア形式をグループにおいて使用することができる。典型的に、これらメディア形式のうちの幾つかがセッションに使用されるだけである。他のグループメンバーとセッションを確立したいユーザは、セッションのためにユーザがオファーしたいメディア形式を定義するＳＤＰ（セッション記述プロトコル）オファーを有するＳＩＰ要求を送信することができる。しかしながら、ポリシー又はルールが定義されていて、例えば、セッションが既に存在するために、セッションの確立又はグループメンバーを制御するサーバーにより、オファーされたメディア形式の１つ以上が拒絶されることが生じ得る。上述した構成に関連した問題の１つは、なぜセッション確立要求が一部分しか受け入れられず、即ち完全には受け入れられないか、即ちその理由が、例えば、セッションが既に存在するからであるという情報をユーザが受け取らないことである。

従って、本発明の目的は、上述した問題を克服するための方法、及びこの方法を実施するための装置を提供することである。この目的は、独立請求項に記載されたことを特徴とする方法、装置、モジュール、シグナリングメッセージ、システム及びプログラム製品によって達成される。好ましい実施形態は、従属請求項に開示される。

以下、添付図面を参照して、本発明を詳細に説明する。

グループ通信サービスを提供する通信システムの一般的なアーキテクチャーを例示する。 装置の簡単なブロック図である。 装置の簡単なブロック図である。 装置の機能を示すフローチャートである。 装置の機能を示すフローチャートである。 装置の機能を示すフローチャートである。 一実施形態によるシグナリングを示す。

以下の実施形態は、例示に過ぎない。明細書の多数の位置で、「ある(an)」、「１つの(one)」又は「幾つかの(some)」実施形態に言及するが、これは、必ずしも、各々が同じ実施形態を言及することを意味するものでも又は特徴が単一の実施形態のみに適用されることを意味するものでもない。又、異なる実施形態の単一の特徴を結合して、他の実施形態を構成することもできる。

本発明は、任意のユーザターミナル、サーバー、対応するコンポーネント、及び／又は任意の通信システム、或いはＳＩＰベースのセッションをサポートする異なる通信システムの任意の組み合せに適用することができ、且つセッションに対する複数のメディア形式をオファーする可能性を提供する。セッションの形式、又はメディアの形式、又はオファーメカニズムに対して何ら制約は存在しない。通信システムは、固定の通信システム、又はワイヤレス通信システム、或いは固定及びワイヤレスの両ネットワークを使用する通信システムでよい。使用するプロトコル、通信システム、サーバー及びユーザターミナル、又はそれに対応するコンポーネントの仕様は、特にワイヤレス通信の場合、急速に進展する。このような進展は、ある実施形態に対して余計な変更を必要とすることがある。それ故、全ての用語及び表現は、広く解釈されるべきであり、それらは、その実施形態を例示するもので、それを限定するものではない。

以下、実施形態を適用できるシステムアーキテクチャーの一例として、シグナリング及びセッション確立のためのＳＩＰと、オファーされたメディア形式に関する情報を搬送するためのＳＤＰとに基づくアーキテクチャーを使用する異なる実施形態について説明するが、実施形態は、このようなアーキテクチャーに限定されない。ＳＩＰ及びＳＤＰは、インターネットエンジニアリングタスクフォース（ＩＥＴＦ）によって定義される。ＳＩＰは、１人以上の参加者とのセッションを生成し、変更し及び終了するための制御（シグナリング）プロトコルである。ＳＤＰは、メディアの詳細、トランスポートアドレス、及び他のセッション記述メタデータ、例えば、メディア形式を、その情報がどのようにトランスポートされるかに関わらず、搬送するためのテキストフォーマットアプリケーションレイヤプロトコルである。換言すれば、ＳＩＰ及びＳＤＰは、通信システムに垂直的に一体化されない。ＩＥＴＦ仕様及びインターネットドラフトは、ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇにおいて見ることができる。

メディア形式は、ここでは、ユーザターミナルのようなエンドポイント間で交渉できるデータ及び／又は通信手段の一般的形式を網羅する。メディア形式は、例えば、テキスト（テキスト情報）、映像（映像データ）、オーディオ（オーディオデータ）、ビデオ（ビデオデータ）、アプリケーション（何らかの他の種類のデータ、典型的に、アプリケーションにより処理されるべき未解釈のバイナリーデータ又は情報）、マルチパート（独立したデータ形式の複数エンティティより成るデータ）、及びメッセージ（カプセル化メッセージ）を含むが、これらに限定されない。更に、メディア形式は、グループ通信サービスを提供する異なるサブ形式及び／又は接続形式（異なるオーバーレイサービスを含む）も含む。従って、メディア形式は、例えば、「ｐｏｃ」、「ｉｍ」、「オーディオ」、「ビデオ」、「会議」、「アプリケーション」、「全」、「他」のグループから選択することができる。

ＳＩＰベースのセッションを提供する通信システムの一般的アーキテクチャーが図１に示されている。図１は、幾つかのエレメント及び機能的エンティティしか示さない簡単なシステムアーキテクチャーであり、それらは、全て、図示されたものとは異なるように実施されてもよい論理的ユニットである。図１に示す接続は、論理的な接続であり、実際の物理的な接続は、それとは異なってもよい。当業者であれば、システムは、他のファンクション及び構造も含むことが明らかであろう。又、グループ通信に使用され又はそのために使用されるファンクション、構造、エレメント及びプロトコルは、実際の発明には関わりないものであることが明らかであろう。それ故、それらは、ここで詳細に説明する必要はない。

図１に示す通信システム１００は、ユーザターミナル（ＵＴ）２００を備え、これは、必要に応じて、アクセス及びコアネットワークを含む１つ以上のネットワーク４００を経てサーバー３００に接続することができる。

ユーザターミナル２００は、ユーザターミナル及びそのユーザを契約に関連付け又は関連付けるように構成され且つユーザが通信システムと対話できるようにする装置又は装置の断片である。ユーザターミナルは、ユーザに情報を提示し、ユーザが情報を入力できるようにする。換言すれば、ユーザターミナルは、ネットワークから情報を受信でき及び／又はネットワークへ情報を送信でき、又、ネットワークにワイヤレスで、又は固定接続を経て接続できる任意のターミナルでよい。ユーザターミナルは、例えば、パーソナルコンピュータ、ゲームコンソール、ラップトップ（ノートブック）、パーソナルデジタルアシスタント、移動ステーション（移動電話）、及び回線電話を含む。

サーバー３００は、セッションをホストする装置又は装置の断片である。セッションをホストするサーバーは、セッションを処理し、即ちセッションを制御するか、或いはセッションのための焦点又は制御ファンクションとして働く。換言すれば、セッションに関連した全ての制御トラフィックがサーバーを通過し、そしてサーバーは、異なるポリシー、例えば、サーバー特有のポリシー、或いはグループ特有又はユーザ特有のポリシーを使用して、セッション及びセッション確立を制御する。

ある実施形態を適用できる１つの具現化環境は、ＸＤＭ（ＸＭＬドキュメントマネージメント）を使用するグループ通信アーキテクチャーである。オープンモバイルアリアンス（ＯＭＡ）は、ＸＤＭを、ＸＣＡＰプロトコル（ＸＭＬコンフィギュレーションアクセスプロトコル）に基づくグループ及びリストマネージメントのための一般的フレームワークとして定義している。ｈｔｔｐ：／／ｗｗｗ．ｏｐｅｎｍｏｂｉｌｅａｌｌｉａｎｃｅ．ｏｒｇにおいてＯＭＡ仕様を見ることができる。ＸＤＭは、ユーザ特有のサービス関連情報、例えば、グループ定義を、ユーザ装置に常駐する異なるアプリケーション（サービスイネーブラー及びクライアントにアクセス可能にすると共に、このような情報の生成、変更、検索及び削除を可能にする共通のメカニズムを定義する。グループ通信サービスを提供するアプリケーションは、ＰｏＣ（プッシュ・ツー・トーク・オーバー・セルラー）、メッセージング、又は会議であり、例えば、ＰｏＣ仕様は、ＯＭＡのもとでＰｏＣワーキンググループにより現在開発中である。ＰｏＣに関する更に詳細な情報は、ＯＭＡの前記インターネットページを経て見ることができる。従って、サーバー３００は、ＰｏＣサーバー、インスタントメッセージングサーバー、或いはオーディオ、ビデオ及びメッセージングのような異なるメディア形式をサポートする会議サーバーでよい。しかしながら、サーバー３００は、必要なファンクションを備えそしてある実施形態に基づいてサーバーとして働くように構成されたユーザターミナルでよい。

図２は、ある実施形態に基づいてユーザターミナルとして構成された装置２００の簡単なブロック図であり、この装置は、以下、ユーザターミナルと称される。このユーザターミナル２００は、１つ以上のアプリケーションクライアントユニット（クライアント）２１を備え、これらアプリケーションクライアントユニットの少なくとも１つは、ある実施形態に基づきアプリケーションクライアントユニットであるように構成され、以下、クライアントと称される。更に、ユーザターミナル２００は、データ記憶装置、例えば、メモリ（ｍｅｍ）２２と、通信信号（メッセージ、情報、シグナリング、異なる出力又は入力）を受信するための受信器（Ｒｘ）２３及びそれを送信するための送信器（Ｔｘ）２４と、ユーザインストラクションを受け取り且つユーザに情報を与えるためのユーザインターフェイス（ＵＩ）２６と、１つ以上のクライアントを処理し、セッションの確立を含む通信の受信及び送信を処理し且つ制御し、ユーザインストラクションを受信し且つユーザインターフェイス２６を経てユーザへ情報を与えるのを処理し且つ制御し、更に、メモリの使用を制御するための１つ以上のオペレーションプロセッサ２５も備えている。当業者であれば、ユーザターミナルは、ここで詳細に説明する必要のない他のコンポーネント、エンティティ、ファンクション及び構造を含んでもよいし、或いは上述したコンポーネントの幾つかだけを含んでもよいことが明らかであろう。又、セッションに参加しているユーザターミナルは、ある実施形態に基づくクライアントを含まず、即ちユーザターミナルは、ある実施形態に基づくユーザターミナルで以下に述べる全てのファンクションを遂行するように構成されず、又、幾つかのファンクションしか実行されないことも考えられる。

クライアント、又はクライアントが常駐するユーザターミナルは、ある実施形態に基づいてメディア形式拒絶の理由を決定するためのクライアント機能を備えるように構成できる。更に、クライアント、又はクライアントが常駐するユーザターミナルは、受け容れられるメディア形式を後で得ることができるかどうか決定するときにその理由を使用するように構成することもできる。このため、クライアント、又はクライアントが常駐するユーザターミナルは、理由又はその指示を少なくとも一時的にデータ記憶装置２２に記憶するように構成することもできる。

クライアント２１のファンクションは、図４及び７を参照して以下に詳細に説明する。

図３は、ある実施形態に基づきサーバーコンポーネントとして構成された装置３００の簡単なブロック図であり、この装置は、以下、サーバーと称される。このサーバー３００は、セッションをホストする１つ以上のアプリケーションホストユニット（ホスト）３１を備え、これらアプリケーションホストユニットの少なくとも１つは、ある実施形態に基づきアプリケーションホストユニットであるように構成され、以下、ホストと称される。更に、サーバー３００は、データ記憶装置、例えば、メモリ（ｍｅｍ）３２と、通信信号（メッセージ、情報、シグナリング、異なる出力又は入力）を受信するための受信器（Ｒｘ）３３及びそれを送信するための送信器（Ｔｘ）３４と、１つ以上のホストを処理し、セッションの確立を含むセッションに関連した通信の受信及び送信を処理し且つ制御し、セッションを処理し且つ制御すると共に、メモリの使用を制御するための１つ以上のオペレーションプロセッサ３５も備えている。当業者であれば、サーバーは、ここで詳細に説明する必要のない他のコンポーネント、エンティティ、ファンクション及び構造を含んでもよいし、或いは上述したコンポーネントの幾つかだけを含んでもよいことが明らかであろう。又、セッションをホストするサーバーは、ある実施形態に基づくホストを含まず、即ちサーバーは、ある実施形態に基づくサーバーで以下に述べる全てのファンクションを遂行するように構成されず、又、幾つかのファンクションしか実行されないことも考えられる。

ホストは、ある実施形態に基づき、メディア形式をオファーするユーザターミナルにメディア形式拒絶の理由を与えるためのホストファンクションを備えるように構成することもできる。更に、ホストは、オファーされたメディア形式を拒絶すべきかどうか判断するように構成することもできる。このため、ホストは、理由又はその指示を少なくとも一時的にデータ記憶装置３２に記憶するように構成することもできる。

ホスト３１のファンクションは、図５、６及び７を参照して以下に詳細に説明する。

装置、例えば、サーバー又はそれに対応するサーバーコンポーネント、ユーザターミナル及び／又は他の対応する装置、或いはある実施形態について述べる対応装置のファンクションを実施する装置は、従来技術の手段を備えるだけでなく、ある実施形態について述べる対応装置のファンクションを実施するための手段も備え、そしてそれらは、各別々のファンクションのための別々の手段、或いは２つ以上のファンクションを遂行するように構成された手段を備えてもよい。本装置は、ある実施形態に利用できるプロセッサ及びメモリを備えている。例えば、アプリケーションクライアントユニット２１又はホストユニット３１は、ソフトウェアアプリケーションであるか、又はモジュールであるか、或いは演算オペレーション又はプログラムとして構成されたユニットであって、オペレーションプロセッサにより実行されるものでもよい。ある実施形態のファンクションを実施するのに必要な全ての変更及び構成は、追加又は更新型ソフトウェアルーチン、アプリケーション回路（ＡＳＩＣ）及び／又はプログラマブル回路として実施できるルーチンとして遂行されてもよい。アプレット及びマクロを含むプログラム製品とも称されるソフトウェアルーチンは、装置読み取り可能なデータ記憶媒体に記憶することができ、そしてそれらルーチンは、特定のタスクを遂行するためのプログラムインストラクションを含む。ソフトウェアルーチンは、装置にダウンロードすることができる。装置、例えば、サーバー又はそれに対応するサーバーコンポーネント、或いはユーザターミナル又はそれに対応するユーザターミナルは、少なくとも、演算オペレーションに使用される記憶エリアを与えるメモリと、演算オペレーションを実行するオペレーションプロセッサとを含む単一チップコンピュータエレメントのようなコンピュータ又はマイクロプロセッサとして構成することができる。オペレーションプロセッサは、例えば、中央処理ユニットを備えている。メモリは、装置に取り外し可能に接続される取り外し可能なメモリでよい。

以下、明瞭化のために、セッションを確立する要求が完全に拒絶されないが、１つ以上のメディア形式が拒絶され、そしてメディア形式が拒絶された場合に、その理由が指示され、且つ拒絶には、ポリシーに基づくものと、セッションが既に存在する、の２つの理由があると仮定して、異なる実施形態を説明する。更に、セッションは、１対１の通信、グループ内の１対１の通信、又は１対多数の通信、又は多数対多数、或いは多数対１の通信に対するものである。この環境において、セッションに参加するユーザ、又はより詳細には、ユーザターミナルは、参加者と称される。換言すれば、要求が送信されるときの参加者の数は、０、１、２、３、等々でよい。

図４は、ユーザターミナルにおけるクライアントの実施形態を示す。しかしながら、明瞭化のために、以下の説明では「ユーザターミナル」という語が使用される。

図４は、ステップ４０１において、ユーザターミナルがセッション確立要求を１つ以上のメディア形式オファーと共に送信するときにスタートする。この要求は、メディア形式をオファーするＳＤＰを伴うＳＩＰ ＩＮＶＩＴＥであり、そしてこの要求は、サーバーのＵＲＩ、又はセッション確立を処理するサーバーの対応サービスへ送信される。ＵＲＩは、抽象的又は物理的リソースを識別するためのユニフォームリソース識別子である。

ユーザターミナルは、要求の少なくとも一部分の受け容れを指示する応答を受け取ると（ステップ４０２）、ステップ４０３において、オファーされたメディア形式が拒絶されたかどうかチェックする。オファーされたメディア形式が拒絶された場合には、ユーザターミナルは、ステップ４０４において、理由の指示が既存のセッションを指示するかどうかチェックする。もしそれが指示すれば、ユーザターミナルは、ステップ４０５において、セッションを確立するのではなく、ユーザターミナルが既存のセッションに加わることを推測し、そしてステップ４０６において、セッションが既に存在すること及び拒絶されたメディア形式をユーザに通知する。これに加えて、ユーザターミナルは、ステップ４０７において、拒絶されたメディア形式が、交渉されたメディア形式の１つではなく、それがセッション中に後でオファーされるかもしれないことを推測し、次いで、ステップ４０８において、通信をスタートする。

理由が既存のセッションを指示しない場合には（ステップ４０４）、拒絶の理由は、ポリシーに基づくものである（ステップ４０９）。換言すれば、理由は、例えば、ホストのポリシー、ユーザの加入者情報、又はグループ定義に基づくものである。それ故、ユーザターミナルは、ステップ４１０において、ポリシーが同じままであるために、メディア形式が後でオファーされないことを推測する。次いで、ユーザターミナルは、ステップ４０８において、通信をスタートする。

受け取られる応答は、ＳＤＰ本体が受け容れ及び拒絶のメディア形式を指示すると共に、警報ヘッダが、例えば、フォーマット＜ｘｘｘ＞．＋＜ｅｘｐｌａｎａｔｏｒｙ ｔｅｘｔ＞に基づく３桁テキストコード及び説明テキストを含むようなＳＩＰ ２００ ＯＫでよく、前記フォーマットは、少なくともＯＭＡ ＰｏＣ仕様で定義される。セッションが既に存在することを指示するための説明テキストは、「セッション存在」又は「セッションに参加」或いは「参加者により拒絶」でよい。しかしながら、他の適当なヘッダ、フィールド又はビットを使用して、拒絶の理由を指示したり、又は拒絶の潜在的理由を推測する基礎となる事象の発生や情報の付与を指示したりできると共に、説明テキストの内容に制限がないことが明らかであろう。

別の実施形態では、警報ヘッダ又はそれに対応する指示を伴う拒絶されたメディア形式は、警報ヘッダの内容に関わらず、セッションが既に存在することを意味する、と解釈するようにユーザターミナルが構成される。換言すれば、この実施形態のユーザターミナルは、既存のセッションという１つの理由だけを確認するように構成される。

別の実施形態では、警報ヘッダ又はそれに対応する指示を伴う拒絶されたメディア形式は、警報ヘッダの内容に関わらず、メディア形式の拒絶の理由がセッションが既に存在するためであることを意味すると共に、警報ヘッダ又はそれに対応する指示を伴わない拒絶されたメディア形式は、ポリシーのためにメディア形式が拒絶されたことを意味する、と解釈するようにユーザターミナルが構成される。

セッションが既に存在するために２つ以上のメディア形式が拒絶された場合には、ユーザターミナルは、拒絶された全てのメディア形式を、１つ１つではなく、一度に、ユーザに通知するように構成されてもよい。

ある実施形態において、応答が、２つ以上の拒絶されたメディア形式を含むが、拒絶の理由について１つの指示しか含まない場合には、ユーザターミナルは、全ての拒絶されたメディア形式について同じ理由であると解釈するようにユーザターミナルが構成される。

ある実施形態において、応答が、２つ以上の拒絶されたメディア形式を含むが、拒絶の理由について１つの指示しか含まない場合には、ユーザターミナルは、その理由が、指示に関するメディア形式についてのものであり、又、他のメディア形式は、他の理由で拒絶されると解釈するように構成される。

ある実施形態において、ユーザターミナルは、セッション確立要求の受け容れを指示し且つ少なくとも１つの受け容れられたメディア形式及び少なくとも１つの拒絶されたメディア形式を警報ヘッダのような拒絶の理由の指示と共に含む応答を、セッションが既に存在し、且つセッションを確立するのではなくユーザターミナルが確立されたセッションに加わろうとしていることを指示するものと、解釈するように構成される。

ある実施形態において、ユーザターミナルは、オファーされたメディア形式の１つ以上が拒絶されたことをユーザに指示するのに加えて、それらの拒絶されたメディア形式のうち、後で受け入れられるもの、即ち後でオファーできるものをユーザに指示し、そしてメディア形式を後でオファーすべきかどうか選択すべくユーザに尋ねるように構成される。

拒絶されたメディア形式が拒絶の理由の指示に関連付けられても、そうでなくてもよい実施形態では、ユーザターミナルは、指示が欠落した場合にメディア形式を後でオファーしないことを推測するように構成される。

ある実施形態において、ユーザターミナルは、応答を受け取るのに応じて（ステップ４０２）、受け容れられたメディア形式を使用して通信を直ちにトリガーするように構成される。

図５及び６は、ホストの実施形態を示す。ホストは、典型的に、サーバーに位置されるので、以下の説明では明瞭化のためにサーバーという語が使用される。

図５に示す実施形態を参照すれば、サーバーは、ステップ５０１において、セッション確立要求を１つ以上のメディア形式オファーと共に受け取る。この要求に応答して、サーバーは、ステップ５０２において、セッションが既に存在するかどうかチェックする。セッションが存在しない場合には、サーバーは、ステップ５０３において、セッションの確立を継続する。セッションが実際にどのように確立され、及び／又はセッション内の通信がどのように続くかは、本発明にとって重要でなく、それ故、ここでは詳細に説明しない。

セッションが既に存在する場合には、サーバーは、ステップ５０４において、メディア形式のオファーを取り上げ、そしてステップ５０５において、メディア形式が使用中であるかどうか、即ちセッションのための交渉されたメディア形式であるかどうかチェックする。もしそうであれば、サーバーは、ステップ５０６において、メディア形式を受け入れ、次いで、ステップ５０７において、オファーされた全てのメディア形式がチェックされたかどうか調べる。もしそうでなければ、サーバーは、ステップ５０４から、メディア形式のオファーを取り上げることで動作を続ける。

メディア形式が使用中でない場合には（ステップ５０５）、サーバーは、ステップ５０８において、メディア形式を拒絶し、そしてステップ５０９において、拒絶の理由の指示を応答に追加するように処理する。次いで、サーバーは、ステップ５０７から、オファーされた全てのメディア形式がチェックされたかどうか調べることで動作を続ける。

オファーされた全てのメディア形式がチェックされた場合には（ステップ５０７）、サーバーが、ステップ５１０において、要求に対する応答を送信し、この応答は、オファーされた各メディア形式を受け容れ又は拒絶として指示し、そして拒絶された各メディア形式を拒絶の理由の指示と関連付ける。

図５の実施形態の効果は、セッションの他の参加者が、ステップ５０１で受け取られるセッション確立要求によって妨げられないことである。

図６の実施形態では、サーバーは、好ましくは、セッションの参加者に関する情報を維持し、さもなければ、要求された情報を受け取るように構成される。しかしながら、この実施形態は、参加者に関する情報の検索に対して変更を必要としないので、ここでは詳細に説明しない。

図６に示す実施形態を参照すれば、ステップ６０１ないし６０７は、図５に示すステップ５０１ないし５０７に各々対応し、それ故、ここでは、無駄に説明を繰り返さない。

メディア形式が使用中でない場合には（ステップ６０５）、サーバーは、ステップ６０８において、メディア形式がポリシー要件を満足するかどうかチェックし、即ちメディア形式が、ユーザターミナル、セッション、グループ、サーバー、又は他の何かについて定義されたポリシーに基づくものであるかどうかチェックする。本発明は、ポリシーの定義を制限するものではなく、いかなるポリシーが使用されてもよい。ポリシーの要件は、例えば、ルール又はルールのセットにより定義される。メディア形式がポリシー要件（１つ又は複数）を満足しない場合には、サイバーが、ステップ６０９において、メディアの形式を拒絶し、そしてステップ６０７から、オファーされた全てのメディア形式がチェックされたかどうか調べることで動作を続ける。メディア形式がポリシー要件を満足する場合には、サーバーが、ステップ６１０において、メディア形式をオファーに追加し、そしてステップ６０７から、オファーされた全てのメディア形式がチェックされたかどうか調べることで動作を続ける。

オファーされた全てのメディア形式がチェックされた場合には（ステップ６０７）、サーバーが、ステップ６１１において、メディア形式のオファーを参加者へ送信し、このオファーは、ステップ６１０において追加されたメディア形式（１つ又は複数）を含んでいる。サーバーは、ステップ６１２において、参加者からの応答を受け取り、各応答は、オファーされたメディア形式のどれが受け容れられ、どれが拒絶されたかを指示する。ステップ６１３において、サーバーは、ステップ６０１で受け取られた要求に対する応答を形成するように構成され、この応答は、オファーされた各メディア形式を受け容れ又は拒絶として指示すると共に、拒絶された各メディア形式を拒絶の理由の指示に関連付ける。この応答は、サーバーにより拒絶又は受け容れられたメディア形式を含む（即ち、ステップ６０６及び６０９）。参加者にオファーされるメディア形式に関して、サーバーは、全ての参加者がメディア形式を受け入れた場合にはそれを受け容れ、そして少なくとも１人の参加者がメディア形式を拒絶する場合にはそれを拒絶するように構成される。実施形態に基づき、拒絶の理由の指示は、サーバー又は参加者によってそれが拒絶されたかどうかに関わらず同じでもよいし、或いはこの指示は、メディア形式を拒絶するエンティティに基づくものでもよい。更に、拒絶に関するある付加的な情報が追加されてもよい。

次いで、サーバーは、ステップ６１４において、応答を送信する。

図６の実施形態の効果は、ステップ６０１の要求の送信者がセッションの参加者に対してオファーしたく、しかも、使用中でないメディア形式が、他の参加者にオファーされ、従って、最初の意図を満足することである。

メディア形式が拒絶された場合にその理由が指示される前記実施形態の効果は、例えば、拒絶されたメディアをセッションのその後の段階で再オファーすることが合理的であるかどうかユーザターミナルで推測できることである。例えば、既存のセッションにおいて既に使用中のメディア形式のみが受け容れられるが、他のメディア形式は自動的に拒絶され、且つ指示された理由が「セッションが既に進行中」であることを定義するルール又は他のポリシーが存在する場合に、ユーザターミナルは、関連性（拒絶されたメディア形式、指示された理由）から、拒絶されたメディア形式を後でセッションに提示するオファーが拒絶され、従って、それをオファーする意味はないが、セッションが終了した後にその拒絶されたメディア形式を後で再びオファーすることができ、そして新たなセッションが確立される、ということを推測するように構成することができる。この実施形態の更なる効果は、例えば、エンドユーザの満足度の低下を招く試行錯誤型の解決策を回避できることである。

前記で詳細に説明しなかったが、メディア形式をオファーするユーザにとってあるメディア形式が許されず又は許可されないような付加的な情報が入手できる場合には、ユーザターミナルへの応答は、ユーザがメディア形式をセッションに追加することが許されないような付加的な情報を指示する他の理由も含むことができる。この場合には、ユーザターミナルは、拒絶されたメディアを再びオファーすることが許されないために、そのようにするのが合理的でないことを推測するように構成できる。換言すれば、メディア形式の拒絶に関して１つ以上の理由を応答に含ませることができる。

図７は、セッションを確立する要求がメディアのオファーを含まないが、ある実施形態に基づき拒絶の理由の指示をどのように利用するかを示すシグナリングチャートである。図７の実施例では、セッションが既に存在し、そしてセッションを確立したいユーザターミナルがセッションへの参加を許されたと仮定する。

図７を参照すれば、ユーザターミナルＵＴは、セッションの確立を希望し、セッション確立要求を送信する（７−１）。図示された実施例では、要求がメディアのオファーを含まず、そしてサーバーのＵＲＩにＳＩＰ ＩＮＶＩＴＥが送信され、サーバーは、セッションをホストし、又はユーザターミナルに対するセッション通信を与える。要求に応答して、サーバーは、ポイント７−２において、セッションが既に存在することを検出し、それ故、ポイント７−３において、要求の受け容れを指示する応答に、拒絶の理由の指示を追加し、そして応答を送信する（７−４）。応答は、ＳＩＰ ２００ ＯＫであり、又、指示は、上述した拒絶の理由の指示のいずれかである。

ユーザターミナルは、ポイント７−５において、拒絶の理由の指示と共に受け容れを受け取ったことを検出し、ポイント７−６において、その受け容れが部分的な受け容れで、セッション確立がセッションへの参加に変換されたこと、即ちセッションが既に存在することを指示していると推測し、そしてポイント７−７において、ユーザが既存のセッションに参加することをユーザに通知する。

セッションを確立するが、実際には、既存のセッションに加わると仮定するユーザが、セッションが既に存在するという情報を受け取ることの効果は、ユーザが通信でどこに立つべきかを知り、即ち進行中の通信の一部分となることを心の中で準備することである。従来の解決策は、このような情報をユーザにオファーするメカニズムに欠ける。

図４ないし７において上述したステップ／ポイント、シグナリングメッセージ及び関連ファンクションは、絶対的な時間的順序のものではなく、幾つかのステップ／ポイントは、同時に遂行することもできるし、又は前記とは異なる順序で遂行することもできる。又、他のファンクションは、ステップ／ポイント間又はステップ／ポイント内で実行することもでき、そして他のシグナリングメッセージは、図示されたメッセージ間で送信することもできる。又、ステップ／ポイントの幾つか、又はステップ／ポイントの一部分は、省くこともできるし、或いは対応するステップ／ポイント又はステップ／ポイントの一部分と置き換えることもできる。サーバーオペレーション及びユーザターミナルオペレーションは、１つ以上の物理的又は論理的エンティティにおいて実施できる手順を例示するものである。シグナリングメッセージは、一例に過ぎず、そして同じ情報を伝達するための多数の個別のメッセージで構成されてもよい。更に、メッセージは、他の情報を含んでもよい。

当業者であれば、技術の進歩と共に、本発明の概念を種々の仕方で実施できることが明らかであろう。本発明及びその実施形態は、上述した例に限定されず、特許請求の範囲内で変更し得るものである。

２１：アプリケーションクライアントユニット（クライアント）
２２：メモリ（ｍｅｍ）
２３：受信器（Ｒｘ）
２４：送信器（Ｔｘ）
２５：オペレーションプロセッサ
２６：ユーザインターフェイス（ＵＩ）
３１：アプリケーションホストユニット（ホスト）
３２：メモリ（ｍｅｍ）
３３：受信器（Ｒｘ）
３４：送信器（Ｔｘ）
３５：オペレーションプロセッサ
１００：通信システム
２００：ユーザターミナル（ＵＴ）
３００：サーバー
４００：ネットワーク

Claims (15)

1. セッションに関する要求であって、セッションに対する１つ以上のメディア形式をオファーするような要求を送信するステップと、
   前記セッションが既に存在し、前記オファーされたメディア形式の１つ以上が拒絶される場合にのみ、前記要求に対する一部分の受け入れを示す応答であって、該セッションに関して少なくとも１つの拒絶されたメディア形式及び拒絶の理由の指示を示すような警告を含む応答を受信するステップと、
   を備えた方法。
2. 前記応答に基づいて前記拒絶の理由を決定するステップを更に備えた、請求項１に記載の方法。
3. 前記要求は、セッション確立要求である、請求項１又は２に記載の方法。
4. 前記理由を使用して、セッションに対するメディア形式を後でオファーするように試みるべきかどうか推測するステップを更に備えた、請求項１、２又は３に記載の方法。
5. セッションに関する要求であって、該セッションに対する１つ以上のメディア形式をオファーするような要求を受信するステップと、
   前記セッションが存在しない場合に、該セッションの確立を継続するステップと、
   前記セッションが既に存在し、前記オファーされたメディア形式の１つ以上が拒絶される場合にのみ、オファーされたメディア形式が前記セッションに関して拒絶されるのに応答して、前記要求に対する一部分の受け入れを示す応答に、少なくとも１つの拒絶されたメディア形式及び拒絶の理由の指示を示すような警告を追加するステップと、
   前記応答を送信するステップと、
   を備えた方法。
6. 前記理由は、既存のセッション、参加者拒絶、及びポリシーに基づく拒絶より成るグループの１つを含む、請求項１から５のいずれかに記載の方法。
7. 前記要求が既存のセッションに対するセッション確立要求であることを通知するステップと、
   オファーされた１つ以上のメディア形式を、セッションに対して交渉された１つ以上のメディア形式と比較するステップと、
   オファーされたメディア形式が、交渉されたメディア形式でない場合には、そのオファーされたメディア形式を拒絶し、そしてその理由が既存のセッションであることを指示するステップと、
   を更に備えた請求項５又は６に記載の方法。
8. 前記要求が既存のセッションに対するセッション確立要求であることを通知するステップと、
   オファーされた１つ以上のメディア形式をセッションの他の参加者へ転送するステップと、
   前記他の参加者から確認を受信するステップと、
   オファーされたメディア形式が参加者により受け容れられない場合には、そのオファーされたメディア形式を拒絶して、その拒絶に対する理由を指示するステップと、
   を更に備えた請求項５又は６に記載の方法。
9. オファーされた１つ以上のメディア形式を、セッションに対して交渉された１つ以上のメディア形式と比較するステップと、
   前記オファーされたメディア形式のうち、前記交渉されたメディア形式ではないものを転送するステップと、
   を更に備えた請求項８に記載の方法。
10. 前記応答は前記要求の受け容れを指示する、請求項１から９のいずれかに記載の方法。
11. 前記指示は、３桁のテキストコード及び説明テキストより成る警報ヘッダである、請求項１から１０のいずれかに記載の方法。
12. 請求項１から１１のいずれかに記載の方法を遂行するための手段を備えた装置。
13. セッションに関する要求を受信し、該セッションが既に存在してオファーされたメディア形式の１つ以上が拒絶される場合にのみ、前記要求においてオファーされたメディア形式が前記セッションに関して拒絶されることに応答して、前記要求においてオファーされたメディア形式が前記セッションに関してなぜ拒絶されたかの理由の指示、及び少なくとも１つの拒絶されたメディア形式を示す警告を含む、前記要求に対する一部分の受け入れを示すメッセージを形成する手段を備えた装置。
14. 請求項１２又は１３に記載の１つ以上の装置を備えたシステム。
15. プログラムがコンピュータ又はマイクロプロセッサ上で実行されるときに請求項１から１１のいずれか１項のいずれかのステップを遂行するプログラムコード手段を備えたコンピュータプログラム。

Images