セッション開始プロトコルのリクエストコンテンツを提供する方法およびシステム
【課題】セッション開始プロトコルのリクエストコンテンツを提供する方法およびシステムの提供。
【解決手段】一実施形態では、登録イベントの結果としてネットワーク構成要素によって伝送されるセッション開始プロトコル（ＳＩＰ）ＮＯＴＩＦＹメッセージを受信するように構成されているプロセッサを含むユーザ機器を提供する。ＳＩＰ ＮＯＴＩＦＹメッセージは、第一のユーザ機器と、ネットワーク構成要素との間に送信される第一のＳＩＰメッセージ内に含まれる情報の少なくとも一部分を含んでいる。別の実施形態では、情報の必要性を指定する１つ以上のインジケータをフィルタ判定基準が含むか否かを決定し、１つ以上のインジケータによって指定された情報を第二のＳＩＰメッセージ内に含めるための、ネットワークノード用の方法および装置を提供する。
【解決手段】一実施形態では、登録イベントの結果としてネットワーク構成要素によって伝送されるセッション開始プロトコル（ＳＩＰ）ＮＯＴＩＦＹメッセージを受信するように構成されているプロセッサを含むユーザ機器を提供する。ＳＩＰ ＮＯＴＩＦＹメッセージは、第一のユーザ機器と、ネットワーク構成要素との間に送信される第一のＳＩＰメッセージ内に含まれる情報の少なくとも一部分を含んでいる。別の実施形態では、情報の必要性を指定する１つ以上のインジケータをフィルタ判定基準が含むか否かを決定し、１つ以上のインジケータによって指定された情報を第二のＳＩＰメッセージ内に含めるための、ネットワークノード用の方法および装置を提供する。
【発明の詳細な説明】
【技術分野】
【０００１】
（関連出願の引用）
本出願は、Ａｎｄｒｅｗ ＡｌｌｅｎおよびＪｏｈｎ−Ｌｕｃ Ｂａｋｋｅｒによって２００８年１月２８日に出願された「Ｐｒｏｖｉｄｉｎｇ ＳＩＰ Ｒｅｑｕｅｓｔ Ｃｏｎｔｅｎｔｓ Ｍｅｔｈｏｄ ａｎｄ Ｓｙｓｔｅｍ」という発明の名称の米国仮出願第６１／０２４，１３２号に対する優先権を主張するものであり、その仮出願は、すべての目的に対して参考として本明細書中に援用される。
【背景技術】
【０００２】
本明細書において用いられる場合に、用語「ユーザエージェント」と「ＵＡ」とは、無線機器（例えば、電気通信能力を有する、携帯電話、携帯情報端末、ハンドヘルドコンピュータまたはラップトップコンピュータ、他のユーザ機器「ＵＥ」、および同様なデバイス）を表し得る。そのようなＵＡは、無線機器と、その関連するユニバーサルＩＣカード（ＵＩＣＣ）（加入者識別モジュール（ＳＩＭ）アプリケーション、ユニバーサル加入者識別モジュール（ＵＳＩＭ）アプリケーション、または取り外し可能なユーザ識別モジュール（Ｒ−ＵＩＭ）アプリケーションを含む）とから成り得るか、またはそのようなカードなしのデバイス自体から成り得る。用語「ＵＡ」はまた、同様な無線能力を有するが可搬型でないデバイス（例えば、電話器、デスクトップコンピュータ、セットトップボックス、またはネットワークノード）を表し得る。ＵＡがネットワークノードである場合に、ネットワークノードは、無線機器などの別の機能の代わりとして作動し、かつ無線機器をシミュレートしたり、エミュレートしたりし得る。例えば、いくつかの無線機器に対して、一般にデバイス上に存在するＩＰ（インターネットプロトコル）マルチメディアサブシステム（ＩＭＳ）セッション開始プロトコル（ＳＩＰ）クライアントは、実際にネットワーク内に存在して、最適化されたプロトコルを用いてＳＩＰメッセージ情報をデバイスに中継する。換言すると、無線機器によって従来から実行されるいくつかの機能は、リモートＵＡという形態で配信され得、リモートＵＡは、ネットワーク内の無線機器を表している。用語「ＵＡ」はまた、ＳＩＰセッションを終了させ得る任意のハードウェアまたはソフトウェア構成要素を表し得る。用語ＵＡとＵＥとは、本明細書において区別なく用いられ得る。用語ＳＩＰメッセージは、ＳＩＰ応答またはＳＩＰリクエストを表し得る。
【０００３】
各々のＳＩＰエンティティは、一般に、２つの様態で動作し得るＵＡを提供され、それらのＵＡは、リクエストメッセージをサーバに向かって発生するユーザエージェントクライアント（ＵＡＣ）と、リクエストメッセージを受信し、それらを処理し、適切な応答を発生するユーザエージェントサーバ（ＵＡＳ）とである。いくつかのアプリケーションのシナリオにおいて、単一のＵＡは、ＳＩＰエンティティにおける双方（例えば、ＵＥデバイスまたはネットワークノード）として機能し得る。最も基本の形態において、ＳＩＰは、６つのタイプ（メソッド）のリクエストを用い、それらのリクエストは、ＩＮＶＩＴＥ、ＡＣＫ、ＢＹＥ、ＣＡＮＣＥＬ、ＯＰＴＩＯＮＳ、およびＲＥＧＩＳＴＥＲである。ＩＮＶＩＴＥリクエストは、ユーザまたはサービスがコールセッションに参加するように招待されていることを示す。ＡＣＫリクエストは、クライアントがＩＮＶＩＴＥリクエストに対する最終的応答を受信したことを確認する。ＢＹＥリクエストは、コール／セッションを終了させ、発呼者または受呼者（ｃａｌｌｅｅ）のいずれかによって送信され得る。ＣＡＮＣＥＬリクエストは、現在進行中のコール／セッションを終了させずに、任意の保留の検索をキャンセルする。ＯＰＴＩＯＮＳリクエストは、サーバの能力をクエリする。ＲＥＧＩＳＴＥＲリクエストは、宛先（Ｔｏ）：ヘッダフィールド内に列挙されているアドレスをＳＩＰサーバによって登録する。ＳＩＰが発展し続け得るので、受領者は、ＳＩＰが認識しないリクエストのメソッドを受信し得る。そのようなリクエストのメソッドは、リクエストのＵＮＫＮＯＷＮメソッドとして処理される。
【０００４】
リクエストに応答して、ＳＩＰは次の応答のカテゴリを用い、それらのカテゴリとは、１ｘｘ情報メッセージ、２ｘｘ成功応答、３ｘｘリダイレクション応答、４ｘｘリクエスト失敗応答、５ｘｘサーバ失敗応答、および６ｘｘ一般的失敗応答である。
【０００５】
ＳＩＰメッセージは、一般に、規格化されたメッセージ構造を提供される。図１は、１つの開始ラインと、１つ以上のヘッダフィールドと、メッセージ本体とを有する例示的な通信プロトコルメッセージ（例えば、ＳＩＰメッセージ）の構造を図示し、メッセージ本体は、可能性として複数の本体部分を含む。コマンドライン部分１２は、開始ライン（例えば、リクエストにおけるリクエストラインと、応答におけるステータスラインと）を識別する。ヘッダ部分１４は、様々な情報の一部分を伝える１つ以上のヘッダフィールド１８−１から１８−Ｎを識別する。１つ以上のメッセージ本体部分２０−１から２０−Ｍが、メッセージ本体の部分１６に提供され得る。周知なように、メッセージ本体は、任意のコンテンツを保持するように動作可能であり、任意のコンテンツとは、例えば、プレーンテキスト、コード化画像、または、例えばＸＭＬ、ＨＴＭＬなどのマークアップ言語で表され得る任意の情報である。各々のメッセージ本体（すなわち本体部分）は、ヘッダフィールドを用いて記述され、そのヘッダフィールドとは、限定ではないが、例えば、コンテンツに関する情報を提供するコンテンツ配置、コンテンツ符号化、コンテンツタイプなどである。一般に、Ｃｏｎｔｅｎｔ−Ｔｙｐｅヘッダフィールドの値は、多目的インターネットメール拡張（ＭＩＭＥ）タイプである。
【０００６】
従来からの無線電気通信システムにおいて、基地局の伝送機器は、セルとして公知の地理的領域のいたるところに信号を伝送する。技術が発展してくるにつれて、より進歩したネットワークアクセス機器が導入され、そのネットワークアクセス機器が、以前には可能でなかったサービスを提供し得る。この進歩したネットワークアクセス機器は、基地局ではないかまたは従来からの無線電気通信システムにおける同等な機器よりもさらに高度に発展した他のシステムおよびデバイスではない、例えば、エンハンストノードＢ（ＥＮＢ）を含み得る。そのような進歩した機器または次世代の機器は、本明細書においてロングタームエボリューション（ＬＴＥ）機器と呼ばれ得、そのような機器を用いるパケットベースのネットワークは、発展型パケット通信システム（ＥＰＳ）と呼ばれ得る。本明細書において用いられる場合に、用語「アクセスデバイス」は、任意の構成要素を表し、任意の構成要素とは、例えば、従来からの基地局、ＬＴＥ ＥＮＢ、または電気通信システム内の他の構成要素へのアクセスをＵＡに提供し得る任意の他の構成要素である。パケットデータに対して、データをＵＡとアクセスデバイスとの間で搬送する信号は、周波数、時間、および符号化のパラメータと、アクセスデバイスによって指定され得る他の特性の特定の組とを有し得る。そのような特性の特定の組を有するＵＡとアクセスデバイスとの間の接続がリソースと呼ばれ得る。アクセスデバイスは、一般に、任意の特定の時間に通信する各々のＵＡに対して異なるリソースを確立する。
【０００７】
回線交換を介して行われ得る通信は、回線交換領域において起こると言われ、パケット交換を介して行われ得る通信は、パケット交換領域において起こると言われ得る。各々の領域において、いくつかの異なるタイプのネットワーク、プロトコル、または技術が用いられ得る。場合に応じて、同じネットワーク、プロトコル、または技術が両方の領域において用いられ得る。無線通信ネットワークは、符号分割多重アクセス（ＣＤＭＡ）、時分割多重アクセス（ＴＤＭＡ）、周波数分割多重アクセス（ＦＤＭＡ）、直交周波数分割多重化（ＯＦＤＭ）、または他の多重アクセススキームに基づき得る。ＣＤＭＡベースのネットワークは、３ＧＰＰ２ ＩＳ−２０００（ＣＤＭＡ １ｘと一般に呼ばれる）、３ＧＰＰ２ ＩＳ−８５６（ＣＤＭＡ １ｘＥＶ−ＤＯと一般に呼ばれる）、または３ＧＰＰ ＵＭＴＳ（Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｙｓｔｅｍ）などの１つ以上の規格を実装し得る。ＴＤＭＡベースのネットワークは、３ＧＰＰ Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ（ＧＳＭ）または３ＧＰＰ Ｇｅｎｅｒａｌ Ｐａｃｋｅｔ Ｒａｄｉｏ Ｓｅｒｖｉｃｅ（ＧＰＲＳ）などの１つ以上の規格を実装し得る。
【０００８】
ＧＳＭは、回線交換モードだけを用いる無線ネットワーク規格の例である。パケット交換だけを用いる無線ネットワーク規格の例は、ＧＰＲＳ、ＣＤＭＡ １ｘ ＥＶ−ＤＯ、Ｗｏｒｌｄｗｉｄｅ Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ ｆｏｒ Ｍｉｃｒｏｗａｖｅ
Ａｃｃｅｓｓ（ＷｉＭＡＸ）、および無線ローカルエリアネットワーク（ＷＬＡＮ）（米国電気電子技術者協会（ＩＥＥＥ）の規格に適合し得る、例えば、８０２．１６、８０２．１６ｅ、８０２．１１ａ、８０２．１１ｂ、８０２．１１ｇ、８０２．１１ｎ、および同様な規格）を含む。回線交換モードと、パケット交換モードとの両方を用い得る無線ネットワーク規格の例は、ＣＤＭＡ １ｘと、ＵＭＴＳとを含む。パケット交換無線ネットワークにおいて用いられ得るアプリケーション層プロトコルの例は、セッション開始プロトコル（ＳＩＰ）である。ＳＩＰは、主としてＩｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ（ＩＥＴＦ）によって規格化され、管理されている。ＩＰ（インターネットプロトコル）マルチメディアサブシステム（ＩＭＳ）は、テキスト、オーディオ、および／またはビデオの部分を含み得るマルチメディアコンテンツがノードの間に伝送されることを可能にするパケット交換技術である。
【発明の概要】
【課題を解決するための手段】
【０００９】
本開示の１つ以上の実施形態の例示的な実装が以下に提供されるが、開示されているシステムおよび／または方法が、現時点で公知であるかまたは存在するか否かにかかわらず、任意の数の技術を用いて実装され得ることは最初に理解されるべきである。本開示は、本明細書中に例示され、記載されている例示的な設計および実装を含む、以下に示されている例示的な実装、図面、および技術に決して限定されるべきではないが、均等物の完全な範囲と共に添付の特許請求の範囲の範囲内において修正され得る。
【００１０】
一実施形態において、方法が、ネットワーク構成要素からアプリケーションサーバとユーザ機器とのうちの少なくとも１つへの第二のセッション開始プロトコル（ＳＩＰ）メッセージ内に情報を含むために提供される。情報は、第一のＳＩＰメッセージから取得され得る。方法は、フィルタ判定基準をネットワーク構成要素にダウンロードすることと、情報を含む必要性を指定する１つ以上のインジケータをフィルタ判定基準が含むか否かを決定することと、フィルタ判定基準によって指定された情報を第二のＳＩＰメッセージ内に含めることとを含む。ネットワーク構成要素はまた、フィルタ判定基準をネットワーク構成要素にダウンロードすることに加えてまたはダウンロードする代わりにフィルタ判定基準と共に構成されるか、さもなければフィルタ判定基準と共に供給され得る。
【００１１】
代替の一実施形態において、電気通信ネットワーク内の構成要素が提供され、構成要素は、構成要素からユーザエージェントサーバへの第二のＳＩＰメッセージ内に含まれる、第一のセッション開始プロトコル（ＳＩＰ）メッセージからの情報に対する必要性を指定する１つ以上のインジケータをフィルタ判定基準が含むか否かを決定するように構成されているプロセッサを含む。プロセッサは、１つ以上のインジケータによって指定された情報を第二のＳＩＰメッセージ内に含めるようにさらに構成される。
【００１２】
代替の一実施形態において、ユーザ機器が提供され、ユーザ機器は、登録イベントの結果としてネットワーク構成要素によって伝送されるＳＩＰ ＮＯＴＩＦＹメッセージを発生するセッション開始プロトコル（ＳＩＰ）イベントパッケージ（Ｅｖｅｎｔ Ｐａｃｋａｇｅ）を受信するように構成されているプロセッサを含む。ＳＩＰ ＮＯＴＩＦＹメッセージは、別のユーザ機器とネットワーク構成要素との間に送信される第一のＳＩＰメッセージ内に含まれる情報の少なくとも一部分を含んでいる。
【００１３】
代替の一実施形態において、方法は、サービングコールセッション制御機能（Ｓ−ＣＳＣＦ）からアプリケーションサーバとユーザ機器とのうちの少なくとも１つへの第二のセッション開始プロトコル（ＳＩＰ）ＲＥＧＩＳＴＥＲリクエスト内に情報を含めるために提供される。方法は、情報の必要性を指定する１つ以上のインジケータを含むフィルタ判定基準をＳ−ＣＳＣＦにダウンロードすることを含む。方法はさらに、フィルタ判定基準によって指定された情報を第二のＳＩＰ ＲＥＧＩＳＴＥＲリクエスト内に含めることを含む。
本発明は、例えば、以下を提供する。
（項目１）
第一のセッション開始プロトコル（ＳＩＰ）メッセージからの情報をネットワーク構成要素からユーザエージェントサーバ（ＵＡＳ）への第二のＳＩＰメッセージ内に含める方法であって、
該情報の必要性を指定する１つ以上のインジケータをフィルタ判定基準が含むか否かを決定することと、
該１つ以上のインジケータによって指定された該情報を該第二のＳＩＰメッセージ内に含めることと
を包含する、方法。
（項目２）
上記１つ以上のインジケータを含む上記フィルタ判定基準を上記ネットワーク構成要素にダウンロードすることと、
該１つ以上のインジケータを含む該フィルタ判定基準によって該ネットワーク構成要素を構成することと
のうちの少なくとも１つのことをさらに包含する、項目１に記載の方法。
（項目３）
上記ＵＡＳは、
ネットワークノードと、
アプリケーションサーバと、
ユーザ機器と
のうちの少なくとも１つに提供される、項目１または項目２に記載の方法。
（項目４）
上記情報は、
ユーザ機器と上記ネットワーク構成要素との間の上記第一のＳＩＰメッセージの少なくともヘッダフィールドと、
ユーザ機器と該ネットワーク構成要素との間の該第一のＳＩＰメッセージの本体の少なくとも一部分と
のうちの少なくとも１つである、項目１〜項目３のうちのいずれか一項に記載の方法。
（項目５）
上記第一のＳＩＰメッセージおよび上記第二のＳＩＰメッセージは、ＳＩＰリクエストと、ＳＩＰ応答とのうちの１つである、項目１〜項目４のうちのいずれか一項に記載の方法。
（項目６）
上記第一のＳＩＰリクエストおよび上記第二のＳＩＰリクエストは、
ＳＩＰ ＲＥＧＩＳＴＥＲリクエストと、
ＳＩＰ ＩＮＶＩＴＥリクエストと、
ＳＩＰ ＲＥＦＥＲリクエストと、
ＳＩＰ ＭＥＳＳＡＧＥリクエストと、
ＳＩＰ ＳＵＢＳＣＲＩＢＥリクエストと、
ＳＩＰ ＩＮＦＯリクエストと、
ＳＩＰ ＰＵＢＬＩＳＨリクエストと、
ＳＩＰ ＮＯＴＩＦＹリクエストと
のうちの１つである、項目５に記載の方法。
（項目７）
上記情報を上記第二のＳＩＰメッセージ内に、
該第二のＳＩＰメッセージ内のヘッダと、
該第二のＳＩＰメッセージの本体内の多目的インターネットメール拡張（ＭＩＭＥ）本体と
のうちの１つとして含めることをさらに包含する、項目１〜項目６のうちのいずれか一項に記載の方法。
（項目８）
上記ＭＩＭＥ本体を上記第二のＳＩＰメッセージの上記本体内に、
複数部分混合型のＭＩＭＥ本体内にカプセル化されたＭＩＭＥ本体と、
ＳＩＰリクエストおよびＳＩＰ応答のうちの一方のすべてまたは一部を含んでいるＭＩＭＥ本体と
のうちの１つとして含めることをさらに包含する、項目７に記載の方法。
（項目９）
ＳＩＰリクエストおよびＳＩＰ応答のうちの一方のすべてまたは一部を含んでいる上記ＭＩＭＥ本体は、該ＭＩＭＥ本体の関連するコンテンツタイプを有するＭＩＭＥ本体である、項目８に記載の方法。
（項目１０）
ＳＩＰリクエストおよびＳＩＰ応答のうちの一方のすべてまたは一部を含んでいる上記ＭＩＭＥ本体内に上記情報が含まれる場合に、該ＭＩＭＥ本体は、
ユーザ機器と上記ネットワーク構成要素との間の第一のＳＩＰメッセージの初期開始ラインと、
ユーザ機器と該ネットワーク構成要素との間の第一のＳＩＰメッセージの少なくともヘッダフィールドと、
ユーザ機器と該ネットワーク構成要素との間の第一のＳＩＰメッセージの本体の少なくとも一部分と
のうちの少なくとも１つを含む、項目８に記載の方法。
（項目１１）
上記情報の必要性を指定する上記１つ以上のインジケータが、上記第二のＳＩＰメッセージ内に、どのヘッダフィールド、本体または本体の部分、および開始ラインが含まれるべきであるかを示しているか否かを決定することをさらに包含する、項目１〜項目１０のうちのいずれか一項に記載の方法。
（項目１２）
上記第二のＳＩＰメッセージは、登録イベントの結果として伝送される登録イベントパッケージを含んでいるＳＩＰ ＮＯＴＩＦＹメッセージであり、該第二のＳＩＰメッセージは、上記第一のＳＩＰメッセージからの情報の少なくとも一部分を含んでいる、項目１〜項目１１のうちのいずれか一項に記載の方法。
（項目１３）
上記第一のＳＩＰメッセージからの上記情報は、上記ＳＩＰ ＮＯＴＩＦＹメッセージ内に、
直接的に上記登録イベントパッケージ内に包含することと、
該ＳＩＰ ＮＯＴＩＦＹメッセージ内のＭＩＭＥ本体に対する参照によって包含することと
のうちの１つのことによって含まれる、項目１２に記載の方法。
（項目１４）
上記ＳＩＰ ＮＯＴＩＦＹメッセージ内に含まれる上記情報の少なくとも一部分は、ＳＩＰリクエストまたはＳＩＰ応答のすべてまたは一部を含んでいる、項目１３に記載の方法。
（項目１５）
上記ＳＩＰ ＮＯＴＩＦＹメッセージを受信し、上記ＳＩＰリクエストおよび上記ＳＩＰ応答のうちの一方の上記すべてまたは一部を取り出すユーザ機器をさらに含んでいる、項目１４に記載の方法。
（項目１６）
上記ネットワーク構成要素は、サービングコールセッション制御機能である、項目１〜項目１５のうちのいずれか一項に記載の方法。
（項目１７）
電気通信ネットワーク内の構成要素であって、
プロセッサであって、第一のセッション開始プロトコル（ＳＩＰ）メッセージからの情報の、該構成要素からユーザエージェントサーバ（ＵＡＳ）への第二のＳＩＰメッセージ内に含まれる必要性を指定する１つ以上のインジケータをフィルタ判定基準が含むか否かを決定するように構成され、該１つ以上のインジケータによって指定された該情報を該第二のＳＩＰメッセージ内に含めるようにさらに構成されている、プロセッサ
を備えている、構成要素。
（項目１８）
上記構成要素は、上記フィルタ判定基準を、
上記１つ以上のインジケータを含む該フィルタ判定基準を該構成要素にダウンロードすることと、
該１つ以上のインジケータを含む該フィルタ判定基準によって該構成要素を構成することと
のうちの少なくとも１つのことによって受信する、項目１７に記載の構成要素。
（項目１９）
上記ＵＡＳは、
ネットワークノードと、
アプリケーションサーバと、
ユーザ機器と
のうちの少なくとも１つに提供される、項目１７または項目１８に記載の構成要素。
（項目２０）
上記情報は、
ユーザ機器と上記構成要素との間の上記第一のＳＩＰメッセージの少なくともヘッダフィールドと、
ユーザ機器と該構成要素との間の該第一のＳＩＰメッセージの本体の少なくとも一部分と
のうちの少なくとも１つである、項目１７〜項目１９のうちのいずれか一項に記載の構成要素。
（項目２１）
上記第一のＳＩＰメッセージおよび上記第二のＳＩＰメッセージは、ＳＩＰリクエストおよびＳＩＰ応答のうちの１つである、項目１７〜項目２０のうちのいずれか一項に記載の構成要素。
（項目２２）
上記第一のＳＩＰリクエストおよび上記第二のＳＩＰリクエストは、
ＳＩＰ ＲＥＧＩＳＴＥＲリクエストと、
ＳＩＰ ＩＮＶＩＴＥリクエストと、
ＳＩＰ ＲＥＦＥＲリクエストと、
ＳＩＰ ＭＥＳＳＡＧＥリクエストと、
ＳＩＰ ＳＵＢＳＣＲＩＢＥリクエストと、
ＳＩＰ ＩＮＦＯリクエストと、
ＳＩＰ ＰＵＢＬＩＳＨリクエストと、
ＳＩＰ ＮＯＴＩＦＹリクエストと
のうちの１つである、項目２１に記載の構成要素。
（項目２３）
上記情報は、上記第二のＳＩＰメッセージ内に
該第二のＳＩＰメッセージ内のヘッダと、
該第二のＳＩＰメッセージの本体内の多目的インターネットメール拡張（ＭＩＭＥ）本体と
のうちの１つとして含まれる、項目１７〜項目２２のうちのいずれか一項に記載の構成要素。
（項目２４）
上記ＭＩＭＥ本体を上記第二のＳＩＰメッセージの上記本体内に、
複数部分混合型のＭＩＭＥ本体内にカプセル化されたＭＩＭＥ本体と、
ＳＩＰリクエストおよびＳＩＰ応答のうちの一方のすべてまたは一部を含んでいるＭＩＭＥ本体と
のうちの１つとして含めることをさらに包含する、項目２３に記載の構成要素。
（項目２５）
ＳＩＰリクエストおよびＳＩＰ応答のうちの一方のすべてまたは一部を含んでいる上記ＭＩＭＥ本体は、コンテンツタイプメッセージ／ｓｉｐｆｒａｇのＭＩＭＥ本体である、項目２４に記載の構成要素。
（項目２６）
ＳＩＰリクエストおよびＳＩＰ応答のうちの一方のすべてまたは一部を含んでいる上記ＭＩＭＥ本体内に上記情報が含まれる場合に、該ＭＩＭＥ本体は、
ユーザ機器と上記構成要素との間の第一のＳＩＰメッセージの初期開始ラインと、
ユーザ機器と該構成要素との間の第一のＳＩＰメッセージの少なくともヘッダフィールドと、
ユーザ機器と該構成要素との間の第一のＳＩＰメッセージの本体の少なくとも一部分と
のうちの少なくとも１つを含む、項目２４に記載の構成要素。
（項目２７）
上記１つ以上のインジケータは、どのヘッダフィールド、本体または本体の部分、および開始ラインが上記第二のＳＩＰメッセージ内に含まれるかを示している、項目１７〜項目２６のうちのいずれか一項に記載の構成要素。
（項目２８）
上記第二のＳＩＰメッセージは、登録イベントの結果として伝送される登録イベントパッケージを含んでいるＳＩＰ ＮＯＴＩＦＹメッセージであり、該第二のＳＩＰメッセージは、上記第一のＳＩＰメッセージからの情報の少なくとも一部分を含んでいる、項目１７〜項目２７のうちのいずれか一項に記載の構成要素。
（項目２９）
上記第一のＳＩＰメッセージからの上記情報は、上記ＳＩＰ ＮＯＴＩＦＹメッセージ内に、
直接的に上記登録イベントパッケージ内に包含することと、
該ＳＩＰ ＮＯＴＩＦＹメッセージ内のＭＩＭＥ本体に対する参照によって包含することと
のうちの１つのことによって含まれる、項目２８に記載の構成要素。
（項目３０）
上記ＳＩＰ ＮＯＴＩＦＹメッセージ内に含まれる上記情報の少なくとも一部分は、ＳＩＰリクエストまたはＳＩＰ応答のすべてまたは一部を含んでいる、項目２９の構成要素。
（項目３１）
上記ＳＩＰ ＮＯＴＩＦＹメッセージを受信し、上記ＳＩＰリクエストと上記ＳＩＰ応答とのうちの一方の上記すべてまたは一部を取り出すユーザ機器をさらに含んでいる、項目３０の構成要素。
（項目３２）
上記構成要素は、サービングコールセッション制御機能である、項目１７〜項目３１のうちのいずれか一項に記載の構成要素。
（項目３３）
ユーザ機器であって、
登録イベントの結果としてネットワーク構成要素によって伝送されるセッション開始プロトコル（ＳＩＰ）ＮＯＴＩＦＹメッセージを受信するように構成されているプロセッサであって、該ＳＩＰ ＮＯＴＩＦＹメッセージは、別のユーザ機器と該ネットワーク構成要素との間に送信される第一のＳＩＰメッセージ内に含まれる情報の少なくとも一部分を含んでいる、プロセッサ
を備えている、ユーザ機器。
（項目３４）
上記ネットワーク構成要素は、上記ＳＩＰ ＮＯＴＩＦＹメッセージ内に含まれる情報の上記部分を指定する１つ以上のインジケータを含むフィルタ判定基準を含み、該インジケータによって指定された該情報の該部分を該ＳＩＰ ＮＯＴＩＦＹメッセージ内に含めるように構成され、該ＳＩＰ ＮＯＴＩＦＹメッセージ内に含まれる該情報の該部分は、
上記第一のＳＩＰメッセージの開始ラインと、
該第一のＳＩＰメッセージのヘッダの少なくとも一部分と、
該第一のＳＩＰメッセージの本体の少なくとも一部分と
のうちの少なくとも１つを含む、項目３３に記載のユーザ機器。
（項目３５）
上記第一のＳＩＰメッセージ内の上記情報の上記部分は、ＳＩＰ ＮＯＴＩＦＹメッセージ内に
該ＳＩＰ ＮＯＴＩＦＹメッセージ内のヘッダと、
該ＳＩＰ ＮＯＴＩＦＹメッセージの本体内の多目的インターネットメール拡張（ＭＩＭＥ）本体と
のうちの１つとして含まれる、項目３３または項目３４に記載のユーザ機器。
（項目３６）
上記第一のＳＩＰメッセージからの上記情報は、上記ＳＩＰ ＮＯＴＩＦＹメッセージ内に、
直接的に該ＳＩＰ ＮＯＴＩＦＹメッセージ内の登録イベントパッケージ内に包含することと、
該ＳＩＰ ＮＯＴＩＦＹメッセージ内のＭＩＭＥ本体に対する参照によって包含することと
のうちの１つのことによって含まれる、項目３３〜項目３５のうちのいずれか一項に記載のユーザ機器。
（項目３７）
上記第一のＳＩＰメッセージは、上記ＳＩＰ ＮＯＴＩＦＹメッセージをトリガしたＳＩＰ ＲＥＧＩＳＴＥＲメッセージである、項目３３〜項目３６のうちのいずれか一項に記載のユーザ機器。
（項目３８）
上記プロセッサは、上記ＳＩＰ ＮＯＴＩＦＹメッセージを受信する際に、上記第一のＳＩＰメッセージ内に含まれている上記情報の上記部分を取り出すようにさらに構成されている、項目３３〜項目３７のうちのいずれか一項に記載のユーザ機器。
（項目３９）
上記プロセッサは、上記第一のＳＩＰメッセージ内に含まれている上記情報の上記部分を利用するようにさらに構成されている、項目３３〜項目３８のうちのいずれか一項に記載のユーザ機器。
（項目４０）
第一のセッション開始プロトコル（ＳＩＰ）メッセージからの情報をサービングコールセッション制御機能（Ｓ−ＣＳＣＦ）からユーザエージェントサーバ（ＵＡＳ）への第二のＳＩＰメッセージ内に含める方法であって、
該情報の必要性を指定する１つ以上のインジケータをフィルタ判定基準が含むか否かを決定することと、
該１つ以上のインジケータによって指定された該情報を該第二のＳＩＰメッセージ内に含めることと
を包含する、方法。
（項目４１）
上記１つ以上のインジケータを含む上記フィルタ判定基準を上記ネットワーク構成要素にダウンロードすることと、
該１つ以上のインジケータを含む該フィルタ判定基準によって該ネットワーク構成要素を構成することと
のうちの少なくとも１つのことをさらに包含する、項目４０に記載の方法。
（項目４２）
上記ＵＡＳは、ユーザ機器（ＵＥ）デバイスと、ネットワークノードとのうちの一方に提供される、項目４０または項目４１に記載の方法。
（項目４３）
上記ネットワークノードは、アプリケーションサーバ（ＡＳ）である、項目４２に記載の方法。
（項目４４）
上記情報は、ＵＥと上記Ｓ−ＣＳＣＦとの間の上記第一のＳＩＰメッセージのすべてまたは一部である、項目４０〜項目４３のうちのいずれか一項に記載の方法。
（項目４５）
上記ＵＥと上記Ｓ−ＣＳＣＦとの間の上記第一のＳＩＰメッセージの上記すべてまたは一部は、
該第一のＳＩＰメッセージのすべてと、
該第一のＳＩＰメッセージのヘッダの少なくとも一部分と、
該第一のＳＩＰメッセージの本体の少なくとも一部分と
のうちの少なくとも１つである、項目４４に記載の方法。
（項目４６）
上記第一のＳＩＰメッセージは、入るＲＥＧＩＳＴＥＲリクエストと、該入るＲＥＧＩＳＴＥＲリクエストに対する最終的応答とのうちの少なくとも１つであり、上記第二のＳＩＰリクエストは、サードパーティＲＥＧＩＳＴＥＲリクエストであり、上記フィルタ判定基準は、該入るＲＥＧＩＳＴＥＲリクエストと、該入るＲＥＧＩＳＴＥＲリクエストに対する該最終的応答とのうちの少なくとも１つを該サードパーティＲＥＧＩＳＴＥＲリクエスト内に含めるための指示を含んでいる、項目４５に記載の方法。
（項目４７）
上記Ｓ−ＣＳＣＦは、上記フィルタ判定基準によって示される場合に、上記サードパーティＲＥＧＩＳＴＥＲリクエスト内に上記入るＲＥＧＩＳＴＥＲリクエストと、該入るＲＥＧＩＳＴＥＲリクエストに対する上記最終的応答とのうちの上記少なくとも１つを含める、項目４６に記載の方法。
（項目４８）
上記フィルタ判定基準によって示される場合に、上記入るＲＥＧＩＳＴＥＲリクエストと、該入るＲＥＧＩＳＴＥＲリクエストに対する上記最終的応答とのうちの上記少なくとも１つは、上記サードパーティＲＥＧＩＳＴＥＲリクエストの本体に追加される、項目４７に記載の方法。
（項目４９）
上記入るＲＥＧＩＳＴＥＲリクエストを上記サードパーティＲＥＧＩＳＴＥＲリクエスト内に含める上記指示は、ＸＭＬ要素である、項目４８に記載の方法。
（項目５０）
上記入るＲＥＧＩＳＴＥＲリクエストに対する上記最終的応答を上記サードパーティＲＥＧＩＳＴＥＲリクエストの上記本体内に含める上記指示は、ＸＭＬ要素である、項目４８に記載の方法。
（項目５１）
上記第二のＳＩＰメッセージは、ＲＥＧＩＳＴＥＲリクエストであり、上記アプリケーションサーバは、該ＲＥＧＩＳＴＥＲリクエスト内に含まれる上記第一のＳＩＰメッセージからの該ＲＥＧＩＳＴＥＲリクエスト情報から引き出すように構成されている、項目４３に記載の方法。
（項目５２）
ＸＭＬ要素が上記アプリケーションサーバ用の上記フィルタ判定基準内に提供される場合に、上記Ｓ−ＣＳＣＦは、上記入るＲＥＧＩＳＴＥＲリクエストを上記サードパーティＲＥＧＩＳＴＥＲリクエスト本体内のＭＩＭＥ本体内に含め、コンテンツタイプの値を設定する、項目４６に記載の方法。
（項目５３）
アプリケーションサーバクラスは、
サービス情報ＸＭＬ要素のゼロまたは１つのインスタンスと、
上記入るＲＥＧＩＳＴＥＲリクエストを上記サードパーティＲＥＧＩＳＴＥＲリクエスト内に含めることを示すＸＭＬ要素のゼロまたは１つのインスタンスと、
該入るＲＥＧＩＳＴＥＲリクエストに対する上記最終的応答を該サードパーティＲＥＧＩＳＴＥＲリクエスト内に含めることを示すＸＭＬ要素のゼロまたは１つのインスタンスと
のうちの少なくとも１つを含む、項目４６に記載の方法。
（項目５４）
上記入るＲＥＧＩＳＴＥＲリクエストを上記サードパーティＲＥＧＩＳＴＥＲリクエスト内に含めることを示す上記ＸＭＬ要素と、該入るＲＥＧＩＳＴＥＲリクエストに対する上記最終的応答を含めることを示す上記ＸＭＬ要素とは、フィルタ判定基準の少なくとも１つのトリガポイントが満足される場合に、該入るＲＥＧＩＳＴＥＲリクエストと、該入るＳＩＰ ＲＥＧＩＳＴＥＲリクエストに対する該最終的ＳＩＰ応答とが、アプリケーションサーバに転送されることを上記Ｓ−ＣＳＣＦに対して示す、項目５３に記載の方法。
（項目５５）
コンピューティングデバイスのプロセッサによって実行可能なコンピュータ読み取り可能な命令を格納しているコンピュータ読み取り可能な媒体であって、項目１〜項目５４のうちのいずれか一項に記載の方法を該デバイスに実装させる、コンピュータ読み取り可能な媒体。
【図面の簡単な説明】
【００１４】
本開示に関するさらなる完全な理解のために、同様な参照番号が同様な部分を表す添付の図面、および詳細な説明と共に理解される以下の簡単な説明への参照がここで行われる。
【図１】図１は、本開示の実施形態に従った、ＳＩＰメッセージのための規格化されたメッセージ構造の図である。
【図２】図２は、本開示の実施形態に従った、ＩＭＳアーキテクチャの一部分の図である。
【図３】図３は、本開示の実施形態に従った、ネットワーク構成要素からアプリケーションサーバおよび／またはユーザ機器へのＳＩＰメッセージ内に情報を含める方法の図である。
【図４】図４は、本開示のいくつかの実施形態を実装することに適したプロセッサおよび関連する構成要素を例示する。
【発明を実施するための形態】
【００１５】
第３世代パートナーシッププロジェクト（３ＧＰＰ）は、モバイルネットワークおよび地上通信線ネットワークのためのマルチメディアサービス用の次世代ＳＩＰ／ＩＰベースのネットワークとしてＩＰマルチメディアサブシステム（ＩＭＳ）を規格化した。図２は、ＩＭＳアーキテクチャ内に存在し得る構成要素の一部分を例示する。ＩＭＳ能力を有するＵＥ１１０は、ＩＭＳベースのサービスを要求し、受信し得る。サービングコールセッション制御機能（Ｓ−ＣＳＣＦ）１２０は、ＳＩＰレジストラとして、およびＵＥ１１０から１つ以上のアプリケーションサーバ１３０へのプロキシＳＩＰリクエストに対するサービスプロキシとして作動する。当該分野で周知なように、Ｓ−ＣＳＣＦ１２０は、サーバ、仮想サーバ、プロセッサとメモリとを有するスタンドアロン型サーバであり得るかまたは他の形態をとり得る。アプリケーションサーバ１３０は、マルチメディア電話、音声コール連続性、および個人化ネットワーク管理などのＩＭＳサービスおよびアプリケーション用のサービスロジックを実行する。３つのアプリケーションサーバ１３０が示されているが、他の数のアプリケーションサーバが存在し得る。
【００１６】
初期フィルタ判定基準（ｉＦＣ）１４０の組は、ＵＥ１１０からのＳＩＰリクエストが、どのアプリケーションサーバ１３０にルーティングされるかを決定するために用いられ得る。ＵＥ１１０に対するＳＩＰ登録手順の間、Ｓ−ＣＳＣＦ１２０は、ｉＦＣ１４０をホーム用加入者サーバ（ＨＳＳ）１５０または同様な構成要素からダウンロードする。ｉＦＣ１４０は、どのアプリケーションサーバ１３０に対してリクエストがルーティングされるべきであるかを識別する多くのサービスポイントトリガ（ＳＰＴ）を含み得る。Ｓ−ＣＳＣＦ１２０はまた、ｉＦＣ１４０と共に構成されるか、さもなければｉＦＣ１４０と共に供給され得、従って、Ｓ−ＣＳＣＦ１２０は、各々のＳＩＰ登録手順の間、ｉＦＣ１４０をダウンロードすることを要求されないことがあり得る。さらに、Ｓ−ＣＳＣＦ１２０は、ユーザ、デバイス、セッションのタイプなどの組に対して用いられるフィルタ判定基準の共通の組を含み得る。フィルタ判定基準の共通の組（１つ以上）は、ｉＦＣ１４０内に含まれ得るか、またはｉＦＣ１４０から分離され得る。フィルタ判定基準の共通の組（１つ以上）は、Ｓ−ＣＳＣＦ１２０にダウンロードされ得、および／またはＳ−ＣＳＣＦ１２０は、フィルタ判定基準の共通の組（１つ以上）と共に構成されるか、さもなければフィルタ判定基準の共通の組（１つ以上）と共に供給され得る。
【００１７】
Ｓ−ＣＳＣＦ１２０がＵＥ１１０からＳＩＰ ＲＥＧＩＳＴＥＲリクエストを受信する場合に、サードパーティ登録は、ｉＦＣ１４０に含まれる指示に基づいて実行され得る。サードパーティ登録手順とは、ＵＥ１１０が登録したことをアプリケーションサーバ１３０の１つ以上に対してＳ−ＣＳＣＦ１２０が示すことと、そのＵＥ１１０に役立つために割り当てられるＳ−ＣＳＣＦ１２０のユニフォームリソース識別子（ＵＲＩ）をＳ−ＣＳＣＦ１２０が示すこととを可能にする仕組みである。サードパーティ登録手順は、Ｓ−ＣＳＣＦ１２０による、アプリケーションサーバ１３０のうちの１つに対するＵＥのＳＩＰ
ＲＥＧＩＳＴＥＲリクエストの単なるプロキシ化ではない。なぜならば、ＵＥのＳＩＰ
ＲＥＧＩＳＴＥＲリクエストがＳ−ＣＳＣＦ１２０において終了するからである。代わりに、新しいＳＩＰ ＲＥＧＩＳＴＥＲリクエストが、Ｓ−ＣＳＣＦ１２０からアプリケーションサーバ１３０のうちの１つ、例えば、アプリケーションサーバ１３０２に送信される。
【００１８】
ＵＥ１１０からＳ−ＣＳＣＦ１２０に送信されるＳＩＰ ＲＥＧＩＳＴＥＲリクエストは、入るＲＥＧＩＳＴＥＲリクエスト１６０、最初のＲＥＧＩＳＴＥＲリクエスト１６０、第一のＳＩＰリクエスト１６０、または第一のＳＩＰメッセージ１６０と呼ばれ得る。Ｓ−ＣＳＣＦ１２０からアプリケーションサーバ１３０のうちの１つ以上に送信されるＳＩＰ ＲＥＧＩＳＴＥＲリクエストは、出るＲＥＧＩＳＴＥＲリクエスト１７０、新しいＲＥＧＩＳＴＥＲリクエスト１７０、サードパーティＲＥＧＩＳＴＥＲリクエスト１７０、第二のＳＩＰリクエスト、または第二のＳＩＰメッセージと呼ばれ得る。いくつかの実施形態において、第一のＳＩＰメッセージおよび第二のＳＩＰメッセージは、ＲＥＧＩＳＴＥＲリクエストではないが、ＳＩＰ ＩＮＶＩＴＥリクエスト、ＳＩＰ ＲＥＦＥＲリクエスト、ＳＩＰ ＭＥＳＳＡＧＥリクエスト、ＳＩＰ ＳＵＢＳＣＲＩＢＥリクエスト、ＳＩＰ ＩＮＦＯリクエスト、ＳＩＰ ＰＵＢＬＩＳＨリクエスト、ＳＩＰ ＮＯＴＩＦＹリクエスト、他のＳＩＰリクエスト、または任意のこれらのＳＩＰリクエストに対する応答であり得る。また、下記のように、第二のＳＩＰメッセージは、サードパーティＲＥＧＩＳＴＥＲリクエスト１７０であることの代わりにまたはサードパーティＲＥＧＩＳＴＥＲリクエスト１７０であることに加えて、アプリケーションサーバ１３０のうちの１つ以上に送信され、および／またはユーザ機器１１０に送信されるＳＩＰ ＮＯＴＩＦＹメッセージ１９３であり得る。
【００１９】
３ＧＰＰ ＩＭＳにおいて、サードパーティ登録は、いくつかのヘッダ値を含んでいるＳＩＰ ＲＥＧＩＳＴＥＲリクエストを用いる。「宛先」ヘッダは、登録されているユーザのＳＩＰ ＵＲＩに設定され得る。「送信元（Ｆｒｏｍ）」ヘッダは、Ｓ−ＣＳＣＦ１２０のＳＩＰ ＵＲＩに設定され得る。「連絡先（Ｃｏｎｔａｃｔ）」ヘッダは、登録されたＵＥ１１０に行先を定められたリクエストかまたは登録されたＵＥ１１０に代わって送信されるリクエストにアドレスするために、アプリケーションサーバ１３０２が用いるべきであるＳ−ＣＳＣＦ１２０のＳＩＰ ＵＲＩに設定され得る。第一のＳＩＰメッセージ１６０内のコールＩＤヘッダは、通常、サードパーティＳＩＰ ＲＥＧＩＳＴＥＲリクエスト１７０内のコールＩＤヘッダと異なる。リクエストＵＲＩパラメータは、アプリケーションサーバ１３０２のＳＩＰ ＵＲＩを含み得る。
【００２０】
Ｓ−ＣＳＣＦ１２０がアプリケーションサーバ１３０２に対してプロキシ化するいくつかのＳＩＰリクエスト（例えば、ＳＩＰ ＩＮＶＩＴＥメッセージ）に対して、Ｓ−ＣＳＣＦ１２０は、入るメッセージ内に含まれている情報（例えば、ＳＩＰリクエストＵＲＩ、ＳＩＰヘッダ、およびＳＩＰ本体）のすべてを出るメッセージ内に含める。しかしながら、サードパーティ登録手順において用いられる、出るＳＩＰ ＲＥＧＩＳＴＥＲリクエスト１７０が、入るＳＩＰ ＲＥＧＩＳＴＥＲリクエスト１６０のプロキシ化ではなく新しいリクエストであるので、入るＳＩＰ ＲＥＧＩＳＴＥＲリクエスト１６０の完全なコンテンツは、出るＳＩＰ ＲＥＧＩＳＴＥＲリクエスト１７０内に含まれない。出るＳＩＰ ＲＥＧＩＳＴＥＲリクエスト１７０内のリクエストＵＲＩと、宛先、送信元および連絡先のヘッダとが、サードパーティ登録ＳＩＰ ＲＥＧＩＳＴＥＲリクエストに対して前に規定された値を有しなければならないので、ＵＥ１１０からの最初のＳＩＰ ＲＥＧＩＳＴＥＲリクエスト１６０からの値は、新しいＳＩＰ ＲＥＧＩＳＴＥＲリクエスト１７０内の同じヘッダに含まれることができない。
【００２１】
最初のＳＩＰ ＲＥＧＩＳＴＥＲリクエスト１６０からのこれらのヘッダは、アプリケーションサーバ１３０２に有用な情報を含み得る。例えば、リクエストＵＲＩと、宛先、送信元および連絡先のヘッダとは、ＵＲＩパラメータと、ヘッダパラメータとを含み、ならびに用いられた最初のＵＲＩを含み得る。例えば、連絡先ヘッダは、ＵＥの能力を示すメディア機能タグを含み得る。これらのメディア機能タグは、出るＳＩＰ ＲＥＧＩＳＴＥＲリクエスト１７０の連絡先ヘッダ内に含めることができない。なぜならば、このリクエスト１７０が、ＵＥ１１０のＵＲＩではなくＳ−ＣＳＣＦ１２０のＵＲＩを含み、従って、それらの能力がＵＥ１１０に属する代わりにＳ−ＣＳＣＦ１２０に属していることを示し得るからである。
【００２２】
入るＳＩＰ ＲＥＧＩＳＴＥＲリクエスト１６０はまた、追加のＳＩＰヘッダ（例えば、タイムスタンプヘッダと、ユーザエージェントヘッダと）を含み得、様々な理由のために、追加のＳＩＰヘッダは、出るＳＩＰ ＲＥＧＩＳＴＥＲリクエスト１７０内にＳＩＰ
ＲＥＧＩＳＴＥＲリクエストのヘッダフィールドとして含まれるべきではない。いくつかのヘッダは含まれ得ない。なぜならば、そのような態様でのそれらヘッダの使用がそれらの規定された意味論に適合しないことがあり得、最初のＳＩＰ ＲＥＧＩＳＴＥＲリクエスト１６０から新しいＳＩＰ ＲＥＧＩＳＴＥＲリクエスト１７０へのヘッダのコンテンツを、単にコピーするＳＩＰプロトコルに違反し得るからである。そのことはまた、特定のＳＩＰヘッダのコンテンツが含まれるか否かにかかわらずサービス特有の問題であり得るので、コンテンツを含むことは、情報が不要なアプリケーションサーバ１３０によって受信される冗長な情報を結果としてもたらし得る。
【００２３】
Ｓ−ＣＳＣＦ１２０のためのイベントパッケージは、他のＳＩＰエンティティ（例えば、アプリケーションサーバ１３０と、他のＩＭＳ ＵＥと）に対して登録状態に関する情報を提供し得る。登録イベントパッケージは、連絡先ヘッダパラメータ（例えば、ＵＥの能力を示すメディア機能タグ）などの最初のリクエスト内に含まれているいくつかのコンテンツを含み得る。しかしながら、登録イベントパッケージは、潜在的に関心のあるすべてのヘッダを現時点で含むわけではない。さらに、アプリケーションサーバ１３０２またはＵＥ１１０がＳＩＰ ＲＥＧＩＳＴＥＲリクエスト内の単一のヘッダ値に関心があるだけの場合には、登録イベントパッケージによって用いられるＳＩＰ登録／通知の仕組みは、過大なシグナリングのオーバヘッドを浪費し得る。さらに、新しい拡張がＳＩＰ ＲＥＧＩＳＴＥＲ／登録用のＳＩＰプロトコルに行われる場合には（例えば、新しいヘッダおよび新しいパラメータ）、登録イベントパッケージは、この新しい情報が提供されるように拡張される必要があり得る。登録イベントパッケージへの拡張が既存のＳＩＰ規格に対する修正を必要とし得、そのような拡張を必要とする任意の新しいサービスがＳ−ＣＳＣＦ１２０に対するアップグレードを伴い得るので、単に新しいサービスを作り出すために登録イベントパッケージに対する拡張を必要とすることは、サービス展開の時間的尺度の点から容認できないことであり得る。
【００２４】
さらに、ＩＭＳコアインフラストラクチャをアプリケーションとサービスとから分離することは設計目標であり得る。すなわち、Ｓ−ＣＳＣＦ１２０が、アプリケーション不可知論的であり、サービスとアプリケーションとを理解する必要が全くないことは望ましいことであり得る。従って、Ｓ−ＣＳＣＦ１２０に対する修正が、新しいサービスとアプリケーションとを展開するために必要とされておらず、そのサービスとアプリケーションとに特有の挙動が、アプリケーションサーバ１３０の領域内（およびＵＥ１１０内のクライアントアプリケーション）にとどまることは望ましいことであり得る。新しいサービスが適切に機能するために、サービス特有の挙動を有する既存のコアＩＭＳのインフラストラクチャ構成要素をアップグレードすることは、新しいサービスの展開における実質的な遅れを引き起こし得る。
【００２５】
一実施形態において、これらの問題に対する一般的な解決策が提供される。新しいトリガ１８０が、既存のサービスポイントトリガ（ＳＰＴ）から独立したｉＦＣ１４０内に規定される。＜ＩｎｃｌｕｄｅＣｏｎｔｅｎｔｓＴｒｉｇｇｅｒ＞トリガと呼ばれ得るこれらの新しいトリガ１８０は、第二のＳＩＰリクエスト１７０内に含まれる必要がある情報を識別し得る。いくつかの場合において、第二のＳＩＰリクエストがサードパーティＲＥＧＩＳＴＥＲリクエスト１７０である場合には、トリガ１８０の一方の組が用いられ得、第二のＳＩＰリクエストがＳＩＰ ＮＯＴＩＦＹメッセージ１９３である場合には、トリガ１８０の別方の組が用いられ得る。他の場合において、トリガの同じ組が、サードパーティＲＥＧＩＳＴＥＲリクエスト１７０と、ＳＩＰ ＮＯＴＩＦＹメッセージ１９３との両方に対して用いられ得る。
【００２６】
この態様で新しいトリガ１８０を用いることは、Ｓ−ＣＳＣＦ１２０に、ＳＩＰリクエストを適切なアプリケーションサーバ１３０に対して送信させる第一のＳＩＰメッセージ内の関心のあるポイントを識別するために、ｉＦＣ１４０内の既存のＳＰＴを用いることと対比され得る。新しいサービスは、アプリケーションに到達するために、単に、新しいアプリケーションサーバ１３０（またはアプリケーションサーバ用アプリケーション）を追加することと、新しいクライアント用アプリケーションをＵＥ１１０にダウンロードすることと、ＨＳＳ１５０内のｉＦＣデータを構成することとによって、既存のＳ−ＣＳＣＦ１２０と、他のＩＭＳインフラストラクチャとを用いて展開され得る。上記のように、本明細書における議論がサードパーティ登録手順に集中しているが、ここに規定されている仕組みはまた、Ｓ−ＣＳＣＦ１２０と、アプリケーションサーバ１３０との間の他のＳＩＰメッセージ（例えば、ＳＩＰ ＩＮＶＩＴＥ、ＲＥＦＥＲ、ＭＥＳＳＡＧＥ、ＳＵＢＳＣＲＩＢＥ、ＮＯＴＩＦＹ、ＩＮＦＯ、ＰＵＢＬＩＳＨなど）に適しており、そこでは、Ｓ−ＣＳＣＦ１２０がユーザエージェントまたは背面の（ｂａｃｋ−ｔｏ−ｂａｃｋ）ユーザエージェントとして作動するか、またはサードパーティ呼制御を実行する。
【００２７】
一実施形態において、新しいトリガ１８０が、第一のＳＩＰメッセージ１６０内に見出された情報がサードパーティＲＥＧＩＳＴＥＲリクエスト１７０内に含まれるべきであることを識別する場合には、その情報は、サードパーティＲＥＧＩＳＴＥＲリクエスト１７０のＳＩＰヘッダとして直接的に含まれ得る。アプリケーションサーバ１３０は次いで、サードパーティＲＥＧＩＳＴＥＲリクエスト１７０内に直接的に含まれる関心のあるヘッダからサービス特有の情報を取得し得る。単一のサードパーティＲＥＧＩＳＴＥＲリクエスト１７０が単一のアプリケーションサーバ１３０に対して送信されるように記述されてきたが、複数のサードパーティＲＥＧＩＳＴＥＲリクエスト１７０が、複数のアプリケーションサーバ１３０に対して送信され得、アプリケーションサーバ１３０の各々が、情報をサードパーティＲＥＧＩＳＴＥＲリクエスト１７０から取得し得ることは理解されるべきである。
【００２８】
上記のように、第一のＳＩＰメッセージ１６０からのすべてのヘッダを、サードパーティＳＩＰ ＲＥＧＩＳＴＥＲリクエスト１７０内に直接的に含めることは可能でないことがあり得る。別の実施形態において、第一のＳＩＰメッセージ１６０からの情報は、サードパーティＳＩＰ ＲＥＧＩＳＴＥＲリクエスト１７０の本体内のＳＩＰリクエストまたはＳＩＰ応答のすべてまたは一部を含んでいる多目的インターネットメール拡張（ＭＩＭＥ）本体１９０の包含を介してサードパーティＳＩＰ ＲＥＧＩＳＴＥＲリクエスト１７０内に含められる。アプリケーションサーバ１３０は、次いで、サードパーティＳＩＰ ＲＥＧＩＳＴＥＲリクエスト１７０の本体内のＳＩＰリクエストまたはＳＩＰ応答のすべてまたは一部を含んでいるＭＩＭＥ本体１９０内に含まれる関心のある、開始ライン、ヘッダフィールドまたは本体（部分）からのサービス特有の情報を取得し得る。サードパーティＳＩＰ ＲＥＧＩＳＴＥＲリクエスト１７０が別の本体（例えば、セッション記述プロトコルまたはアプリケーション／３ｇｐｐサービス情報）を同様に含み得るので、ＳＩＰリクエストまたはＳＩＰ応答のすべてまたは一部を含んでいるＭＩＭＥ本体１９０は、サードパーティＳＩＰ ＲＥＧＩＳＴＥＲリクエスト１７０内の複数部分混合型（ｍｕｌｔｉｐａｒｔ ｍｉｘｅｄ）ＭＩＭＥ本体内にさらにカプセル化され得る。ＳＩＰヘッダフィールドに加えて、第一のＳＩＰリクエスト１６０のリクエストＵＲＩおよび本体は、ＳＩＰリクエストまたはＳＩＰ応答のすべてまたは一部を含んでいるＭＩＭＥ本体１９０内に含まれ得る。
【００２９】
一実施形態において、ＳＩＰリクエストまたはＳＩＰ応答のすべてまたは一部を含んでいるＭＩＭＥ本体１９０は、コンテンツタイプメッセージ／ｓｉｐｆｒａｇのＭＩＭＥ本体である。
【００３０】
一実施形態において、サードパーティＳＩＰ ＲＥＧＩＳＴＥＲリクエスト１７０に含める情報を示すｉＦＣトリガ１８０は、情報がＳＩＰヘッダとして含まれるか、あるいはＳＩＰリクエストまたはＳＩＰ応答のすべてまたは一部を含んでいるＭＩＭＥ本体１９０として含まれるかを示すパラメータを含み得る。
【００３１】
一実施形態において、サードパーティＳＩＰ ＲＥＧＩＳＴＥＲリクエスト１７０は、入るＲＥＧＩＳＴＥＲリクエスト１６０に対する最終的応答を含む。
【００３２】
追加の本体コンテンツがリクエスト内に含まれるか、またはＳＩＰリクエストとＳＩＰ応答との両方の部分がリクエスト内に含まれる実施形態において、ＭＩＭＥ本体は、複数部分ＭＩＭＥ本体のコンテンツタイプ内にさらにカプセル化される。
【００３３】
上記の解決策は、ＳＩＰ ＲＥＧＩＳＴＥＲメソッドと、他の任意のＳＩＰメッセージとに対して適用され得る。以下の例は、ＲＥＧＩＳＴＥＲメッセージ内のＳＩＰリクエストまたはＳＩＰ応答のすべてまたは一部を含んでいるＭＩＭＥ本体１９０の使用を示す。１ ＲＥＧＩＳＴＥＲ ＩＭＳ ＵＥ −＞ Ｓ−ＣＳＣＦ
【００３４】
【数１】
２ Ｓ−ＣＳＣＦは、ＨＳＳからの初期フィルタ判定基準を含むユーザプロフィールをダウンロードする。
Ｓ−ＣＳＣＦは、次の２００ ＯＫによって応答する。
３ ２００ ＯＫ Ｓ−ＣＳＣＦ −＞ ＩＭＳ ＵＥ
【００３５】
【数２】
４ フィルタ検査： 初期フィルタ判定基準は、サードパーティレジスタがＡＳ１に送信され、コンテンツタイプメッセージ／ｓｉｐｆｒａｇのＭＩＭＥ本体内に次のヘッダ
リクエストＵＲＩ、
宛先、
送信元、
連絡先、
タイムスタンプ
が含まれるべきであることを示すトリガを含んでいる。
５ ＲＥＧＩＳＴＥＲ Ｓ−ＣＳＣＦ −＞ ＡＳ
【００３６】
【数３−１】
【００３７】
【数３−２】
６ ２００ ＯＫ ＡＳ −＞ Ｓ−ＣＳＣＦ
【００３８】
【数４】
となる。
【００３９】
ＳＩＰ登録が起こる場合に、登録イベントパッケージを含んでいるＳＩＰ ＮＯＴＩＦＹメッセージ１９３が一般に、ＵＥ１１０、アプリケーションサーバ１３０、および／または他のＳＩＰベースの構成要素に対して登録状態の通知として送信される。一実施形態において、ＳＩＰ ＮＯＴＩＦＹメッセージ１９３は、ＳＩＰ ＮＯＴＩＦＹメッセージ１９３をトリガした第一のＳＩＰメッセージ１６０内に含まれている情報の少なくとも一部分をさらに含む。この情報の部分は、ＳＩＰ ＮＯＴＩＦＹメッセージ１９３内のＭＩＭＥ本体１９６に含まれる。いくつかの実施形態において、ＭＩＭＥ本体１９６は、登録イベントパッケージ内に直接的に含まれる。他の実施形態において、情報を含むＭＩＭＥ本体１９６は、ＳＩＰ ＮＯＴＩＦＹメッセージ１９３内の別のＭＩＭＥ本体によって参照される。すなわち、ＳＩＰリクエストまたはＳＩＰ応答のすべてまたは一部を含んでいるＭＩＭＥ本体１９６は、ＳＩＰ ＮＯＴＩＦＹメッセージ１９３内の登録イベントパッケージ内に直接的に含まれ得る。あるいは、ＳＩＰ ＮＯＴＩＦＹメッセージ１９３内の追加であるが別個のＭＩＭＥ本体は、ＳＩＰリクエストまたはＳＩＰ応答のすべてまたは一部を含んでいるＭＩＭＥ本体１９６に対する参照を含み得る。ＳＩＰ ＮＯＴＩＦＹメッセージ１９３内のＳＩＰリクエストまたはＳＩＰ応答のすべてまたは一部を含んでいるＭＩＭＥ本体１９６内に含まれるＳＩＰ ＲＥＧＩＳＴＥＲリクエスト１６０の部分は、上記のように、ｉＦＣ１４０内の新しいトリガ１８０に基づいて決定され得る。ＳＩＰ ＮＯＴＩＦＹ１９３は、ＵＥ１１０、アプリケーションサーバ１３０、あるいは他のＳＩＰユーザエージェントまたはＳＩＰ端末に送信され得る。ＵＥ１１０、アプリケーションサーバ１３０、あるいは他のＳＩＰユーザエージェントまたはＳＩＰ端末は次いで、サービス特有の情報をＳＩＰ ＮＯＴＩＦＹメッセージ１９３から取得し得る。
【００４０】
これらの実施形態は、Ｓ−ＣＳＣＦ１２０に対する１回限りのアップグレードを必要とし得るが、これらの実施形態は、一般的であり、サービス特有ではない。一旦、Ｓ−ＣＳＣＦ１２０がこの新しい仕組みをサポートすると、新しいアプリケーションは、単にｉＦＣトリガデータを更新することによって、ＳＩＰメッセージ（例えば、ＳＩＰ ＲＥＧＩＳＴＥＲリクエスト）から必要な情報を取得し得る。
【００４１】
新しいトリガ１８０を実装するために用いられ得る、拡張可能マークアップ言語（ＸＭＬ）コードの例が以下に提供される。このコードが単に例として提供され、同様な結果を提供する様々な構文的および構造的な修正がなされ得ることは理解されるべきである。この例において、第二のＳＩＰメッセージ内に情報の包含をトリガする第一のメッセージは、ＲＥＧＩＳＴＥＲリクエストであるが、同様な考察が、他のＳＩＰメッセージにあてはまり得る。
【００４２】
この例において、＜ＩｎｃｌｕｄｅＣｏｎｔｅｎｔｓＴｒｉｇｇｅｒ＞要素は、＜Ｃｏｎｄｉｔｉｏｎ＞要素を含んでいる。ヘッダの＜Ｃｏｎｄｉｔｉｏｎ＞要素に対する「Ｃｏｎｄｉｔｉｏｎａｌ」の値は、そのヘッダが第一のＳＩＰ ＲＥＧＩＳＴＥＲリクエスト１６０に含まれている場合には、そのヘッダが、第一のＳＩＰ ＲＥＧＩＳＴＥＲリクエスト１６０からサードパーティＳＩＰ ＲＥＧＩＳＴＥＲリクエスト１７０の中に、および／またはＳＩＰ ＮＯＴＩＦＹメッセージ１９３の中にコピーされることを示している。ヘッダの＜Ｃｏｎｄｉｔｉｏｎ＞要素の「Ｕｎｃｏｎｄｉｔｉｏｎａｌ」は、そのヘッダが第一のリクエスト１６０に含まれているか否かにかかわらず、＜ＳＩＰＨｅａｄｅｒ＞要素内の識別されたＳＩＰヘッダが、＜Ｃｏｎｔｅｎｔ＞要素内に指定されたコンテンツに含まれることを示している。この例において、Ｐ−Ｓｅｒｖｉｃｅ−Ｉｄｅｎｔｉｔｙヘッダは、無条件にＣｏｎｔｅｎｔ「Ｓｅｒｖｉｃｅ１」に含まれている。
【００４３】
＜Ｃｏｎｔｅｎｔ＞要素が、「Ｃｏｎｄｉｔｉｏｎａｌ」の＜Ｃｏｎｄｉｔｉｏｎ＞要素を有する＜ＩｎｃｌｕｄｅＣｏｎｔｅｎｔｓＴｒｉｇｇｅｒ＞要素内に現われる場合には、最初のリクエスト１６０内のＳＩＰヘッダのコンテンツが、最初のＳＩＰリクエスト１６０からサードパーティＳＩＰ ＲＥＧＩＳＴＥＲリクエスト１７０の中に、および／またはＳＩＰ ＮＯＴＩＦＹメッセージ１９３の中にＳＩＰヘッダがコピーされるために、＜Ｃｏｎｔｅｎｔ＞要素内に指定されたコンテンツと一致する必要があることを示している。この例において、コンテンツが「Ｈｏｍｅ１．ｎｅｔ」を含まない場合には、Ｐ−Ａｃｃｅｓｓ−Ｎｅｔｗｏｒｋヘッダが条件付きで含まれる。
【００４４】
「１」の値を有する＜ＣｏｎｄｉｔｉｏｎＮｅｇａｔｅｄ＞要素は、Ｃｏｎｄｉｔｉｏｎの否定（論理否定）を示す。＜Ｇｒｏｕｐ＞要素は、＜ＳＰＴ＞トリガ要素を有する＜ＩｎｃｌｕｄｅＣｏｎｔｅｎｔｓＴｒｉｇｇｅｒ＞要素に関連する。＜Ｂｏｄｙ＞要素は、値をＳＩＰ本体に割り当て得る。条件付きの場合の空の＜Ｂｏｄｙ＞要素は、入るメッセージの本体がコピーされることを示す。複数の本体が含まれる場合には、メッセージは、処理後に適格である、すなわち複数部分／混合型が適用される必要があり得るべきである。
【００４５】
【数５−１】
【００４６】
【数５−２】
となる。
【００４７】
次は、コンテンツタイプメッセージ／ｓｉｐｆｒａｇのＭＩＭＥ本体を含んでいる登録イベントパッケージの通知の例である。
【００４８】
【数６−１】
【００４９】
【数６−２】
【００５０】
【数６−３】
となる。
【００５１】
図３は、ネットワーク構成要素からアプリケーションサーバおよび／またはユーザ機器に対する第二のＳＩＰメッセージ内に情報を含める方法２００の実施形態を例示する。ブロック２１０において、情報が第二のＳＩＰメッセージ内に含まれる必要性を指定する１つ以上のインジケータを含むフィルタ判定基準が、ネットワーク構成要素に対してダウンロードされ、および／またはネットワーク構成要素が、第二のＳＩＰメッセージ内に情報が含まれる必要性を指定する１つ以上のインジケータを含むフィルタ判定基準と共に構成されるか、さもなければフィルタ判定基準と共に供給される。ブロック２１５において、ネットワーク構成要素は、第二のＳＩＰメッセージ内に情報が含まれる必要性を指定する１つ以上のインジケータをフィルタ判定基準が含むか否かを決定する。ブロック２２０において、１つ以上のインジケータによって示された情報が、第二のＳＩＰメッセージ内に含まれる。
【００５２】
いくつかの実施形態において、サービス情報ＸＭＬ要素がアプリケーションサーバ用のフィルタ判定基準内に提供される場合には、Ｓ−ＣＳＣＦは、サービス情報を＜ｓｅｒｖｉｃｅ−ｉｎｆｏ＞ＸＭＬ要素内のサードパーティＲＥＧＩＳＴＥＲリクエスト本体内に含め、かつコンテンツタイプの値をＭＩＭＥタイプに設定する。
【００５３】
いくつかの実施形態において、２つ以上のメッセージ本体がサードパーティＲＥＧＩＳＴＥＲリクエスト内に含まれる場合には、Ｓ−ＣＳＣＦは、複数部分のメッセージ本体をサードパーティＲＥＧＩＳＴＥＲリクエスト内に含め、Ｃｏｎｔｅｎｔ−Ｔｙｐｅヘッダの値を「複数部分／混合型」に設定し、ＭＩＭＥ本体の要素のＣｏｎｔｅｎｔ−Ｔｙｐｅを本体用に指定されたコンテンツタイプに設定する。
【００５４】
いくつかの実施形態において、１つのメッセージ本体だけがサードパーティＲＥＧＩＳＴＥＲリクエスト内に含まれる場合には、Ｓ−ＣＳＣＦは、Ｃｏｎｔｅｎｔ−Ｔｙｐｅヘッダフィールドを本体用に指定されたコンテンツタイプに設定する。
【００５５】
上記のＵＥ１１０と他の構成要素とは、上記の動作に関連する命令を実行することが可能な処理構成要素を含み得る。図４は、本明細書中に開示されている１つ以上の実施形態を実装することに適した処理構成要素１３１０を含むシステム１３００の例を示している。プロセッサ１３１０（中央処理ユニットまたはＣＰＵと呼ばれ得る）に加えて、システム１３００は、ネットワーク接続用デバイス１３２０と、ランダムアクセスメモリ（ＲＡＭ）１３３０と、読出し専用メモリ（ＲＯＭ）１３４０と、二次ストレージ１３５０と、入力／出力（Ｉ／Ｏ）デバイス１３６０とを含み得る。これらの構成要素はバス１３７０を介して互いに通信し得る。場合に応じて、これらの構成要素のいくつかが存在しないことがあり得るか、あるいは互いにまたは示されてない他の構成要素と様々な組み合わせにおいて組み合わされ得る。これらの構成要素は、単一の物理的エンティティ内または２つ以上の物理的エンティティ内に配置され得る。プロセッサ１３１０によって行われるように本明細書中に記述された任意の動作が、プロセッサ１３１０単独で行われるか、あるいは上記のＤＳＰ５０２などの図面中に示されたかまたは示されていない１つ以上の構成要素と共にプロセッサ１３１０によって行われ得る。ＤＳＰ５０２は別個の構成要素として示されているが、ＤＳＰ５０２は、プロセッサ１３１０の中に組み込まれ得る。
【００５６】
プロセッサ１３１０は、ネットワーク接続用デバイス１３２０、ＲＡＭ１３３０、ＲＯＭ１３４０、または二次ストレージ１３５０（ハードディスク、フロッピィディスク、または光ディスクなどの様々なディスクベースのシステムを含み得る）からアクセスし得る命令、コード、コンピュータプログラム、またはスクリプトを実行する。単に１つのＣＰＵ１３１０が示されているが、複数のプロセッサが存在し得る。従って、命令がプロセッサによって実行されるように論じられ得るが、命令は、同時に連続的に実行されるか、さもなければ１つまたは複数のプロセッサによって実行され得る。プロセッサ１３１０は、１つ以上のＣＰＵチップとして実装され得る。
【００５７】
ネットワーク接続用デバイス１３２０は、モデム、モデムバンク、イーサネット（登録商標）デバイス、ユニバーサルシリアルバス（ＵＳＢ）インタフェースデバイス、シリアルインタフェース、トークンリングデバイス、ファイバ分散型データインタフェース（ＦＤＤＩ）デバイス、無線ローカルエリアネットワーク（ＷＬＡＮ）デバイス、符号分割多重アクセス（ＣＤＭＡ）デバイスなどの無線トランシーバデバイス、ｇｌｏｂａｌ ｓｙｓｔｅｍ ｆｏｒ ｍｏｂｉｌｅ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ（ＧＳＭ）無線トランシーバデバイス、ｗｏｒｌｄｗｉｄｅ ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ ｆｏｒ ｍｉｃｒｏｗａｖｅ ａｃｃｅｓｓ（ＷｉＭＡＸ）デバイス、デジタル加入者回線（ｘＤＳＬ）デバイス、ｄａｔａ ｏｖｅｒ ｃａｂｌｅ ｓｅｒｖｉｃｅ ｉｎｔｅｒｆａｃｅ
ｓｐｅｃｉｆｉｃａｔｉｏｎ（ＤＯＣＳＩＳ）モデム、および／またはネットワークに接続するための他の周知のデバイスの形態をとり得る。これらのネットワーク接続用デバイス１３２０は、プロセッサ１３１０が情報を受信し得るかまたはプロセッサ１３１０が情報を出力し得る、インターネットまたは１つ以上の電気通信ネットワークまたは他のネットワークとプロセッサ１３１０が通信することを可能にし得る。
【００５８】
ネットワーク接続用デバイス１３２０はまた、無線周波数信号またはマイクロ波周波数信号などの電磁波という形態でデータを無線で送信および／または受信できる１つ以上のトランシーバ構成要素１３２５を含み得る。あるいは、データは、電気伝導体の中またはその表面上、同軸ケーブルの中、導波管の中、光ファイバなどの光媒体の中、または他の媒体の中を伝播し得る。トランシーバ構成要素１３２５は、別個の受信ユニットと送信ユニットと、または単一のトランシーバを含み得る。トランシーバ構成要素１３２５によって送信されるかまたは受信される情報は、プロセッサ１３１０によって処理されるデータか、またはプロセッサ１３１０によって実行される命令を含み得る。そのような情報は、例えば、コンピュータデータのベースバンド信号かまたは搬送波に組み入れられた信号の形態でネットワークから受信され、ネットワークに出力され得る。データは、データの処理または発生、データの送信または受信に望ましくあり得るように、異なる順序に従って配列され得る。ベースバンド信号、搬送波に埋め込まれた信号、あるいは現在用いられているかまたは今後開発される他のタイプの信号は、伝送媒体と呼ばれ得、当業者に周知のいくつかの方法に従って発生され得る。
【００５９】
ＲＡＭ１３３０は、揮発性のデータを格納し、可能性としては、プロセッサ１３１０によって実行される命令を格納するために用いられ得る。ＲＯＭ１３４０は、一般に、二次ストレージ１３５０のメモリ容量よりも少ないメモリ容量を有する不揮発性メモリデバイスである。ＲＯＭ１３４０は、命令を格納し、可能性としては、命令の実行の間に読み取られるデータを格納するために用いられ得る。ＲＡＭ１３３０とＲＯＭ１３４０との両方に対するアクセスは、一般に、二次ストレージ１３５０に対するよりも高速である。二次ストレージ１３５０は一般に、１つ以上のディスクドライブまたはテープドライブから構成されており、ＲＡＭ１３３０がすべての作業用データを保持するために十分に大きくない場合には、データの不揮発性ストレージ用またはオーバフローデータのストレージ用として用いられ得る。二次ストレージ１３５０は、そのようなプログラムが実行のために選択される場合に、ＲＡＭ１３３０の中にロードされるプログラムを格納するために用いられ得る。
【００６０】
Ｉ／Ｏデバイス１３６０は、液晶ディスプレイ（ＬＣＤ）、タッチスクリーンディスプレイ、キーボード、キーパッド、スイッチ、ダイアル、マウス、トラックボール、音声認識器、カードリーダ、紙テープリーダ、プリンタ、ビデオモニタ、または他の周知の入力デバイスを含み得る。また、トランシーバ１３２５は、ネットワーク接続用デバイス１３２０の構成要素であることの代わりにまたはその構成要素であることに加えて、Ｉ／Ｏデバイス１３６０の構成要素であると考えられ得る。
【００６１】
以下の第三世代パートナーシッププロジェクト（３ＧＰＰ）の技術仕様（ＴＳ）は、参考として本明細書中に援用され、それらのＴＳは、ＴＳ ２３．２１８ Ｖ７．７．１（２００７−０６）、ＴＳ ２３．２２８ Ｖ７．９．０（２００７−０９）、ＴＳ ２４．２２９ Ｖ７．８．０（２００７−１２）、ＴＳ ２９．２２８ Ｖ７．１０．０（２００７−１２）、およびＴＳ ２９．２２９ Ｖ７．７．０（２００７−１２）である。また、「ＳＩＰ：セッション開始プロトコル」、２００２年６月のＲＦＣ３２６１、およびＲＦＣ３２６５、ＲＦＣ３６８０、およびＲＦＣ３４２０が、参考として本明細書中に援用される。
【００６２】
いくつかの実施形態が本開示において提供されてきたが、開示されたシステムおよび方法が、本開示の精神または範囲から逸脱することなく、多くの他の特定の形態に組み入れられ得ることは理解されるべきである。本例は、限定としてではなく例示として斟酌され、本明細書中に与えられた詳細に限定されないことが意図されている。例えば、様々な要素または構成要素は、別のシステム内に組み合わされるかまたは一体化され得、特定の機能が、省略されるかまたは実装されないことがあり得る。
【００６３】
また、様々な実施形態の中で分離しているかまたは別個であるように記載され、例示された技術、システム、サブシステム、および方法は、本開示の範囲を逸脱することなく他のシステム、モジュール、技術、または方法と組み合わされるかまたは一体化され得る。結合したかまたは直接結合したかまたは互いに通信するように示され、または論じられた他の項目は、電気的、機械的、またはその他にかかわらず、いくつかのインタフェース、デバイス、または中間の構成要素を介して間接的に結合されるかまたは通信する。変化、置換、および変更の他の例は、当業者によって確認可能であり、本明細書中に開示された精神および範囲から逸脱することなく作られ得る。
【技術分野】
【０００１】
（関連出願の引用）
本出願は、Ａｎｄｒｅｗ ＡｌｌｅｎおよびＪｏｈｎ−Ｌｕｃ Ｂａｋｋｅｒによって２００８年１月２８日に出願された「Ｐｒｏｖｉｄｉｎｇ ＳＩＰ Ｒｅｑｕｅｓｔ Ｃｏｎｔｅｎｔｓ Ｍｅｔｈｏｄ ａｎｄ Ｓｙｓｔｅｍ」という発明の名称の米国仮出願第６１／０２４，１３２号に対する優先権を主張するものであり、その仮出願は、すべての目的に対して参考として本明細書中に援用される。
【背景技術】
【０００２】
本明細書において用いられる場合に、用語「ユーザエージェント」と「ＵＡ」とは、無線機器（例えば、電気通信能力を有する、携帯電話、携帯情報端末、ハンドヘルドコンピュータまたはラップトップコンピュータ、他のユーザ機器「ＵＥ」、および同様なデバイス）を表し得る。そのようなＵＡは、無線機器と、その関連するユニバーサルＩＣカード（ＵＩＣＣ）（加入者識別モジュール（ＳＩＭ）アプリケーション、ユニバーサル加入者識別モジュール（ＵＳＩＭ）アプリケーション、または取り外し可能なユーザ識別モジュール（Ｒ−ＵＩＭ）アプリケーションを含む）とから成り得るか、またはそのようなカードなしのデバイス自体から成り得る。用語「ＵＡ」はまた、同様な無線能力を有するが可搬型でないデバイス（例えば、電話器、デスクトップコンピュータ、セットトップボックス、またはネットワークノード）を表し得る。ＵＡがネットワークノードである場合に、ネットワークノードは、無線機器などの別の機能の代わりとして作動し、かつ無線機器をシミュレートしたり、エミュレートしたりし得る。例えば、いくつかの無線機器に対して、一般にデバイス上に存在するＩＰ（インターネットプロトコル）マルチメディアサブシステム（ＩＭＳ）セッション開始プロトコル（ＳＩＰ）クライアントは、実際にネットワーク内に存在して、最適化されたプロトコルを用いてＳＩＰメッセージ情報をデバイスに中継する。換言すると、無線機器によって従来から実行されるいくつかの機能は、リモートＵＡという形態で配信され得、リモートＵＡは、ネットワーク内の無線機器を表している。用語「ＵＡ」はまた、ＳＩＰセッションを終了させ得る任意のハードウェアまたはソフトウェア構成要素を表し得る。用語ＵＡとＵＥとは、本明細書において区別なく用いられ得る。用語ＳＩＰメッセージは、ＳＩＰ応答またはＳＩＰリクエストを表し得る。
【０００３】
各々のＳＩＰエンティティは、一般に、２つの様態で動作し得るＵＡを提供され、それらのＵＡは、リクエストメッセージをサーバに向かって発生するユーザエージェントクライアント（ＵＡＣ）と、リクエストメッセージを受信し、それらを処理し、適切な応答を発生するユーザエージェントサーバ（ＵＡＳ）とである。いくつかのアプリケーションのシナリオにおいて、単一のＵＡは、ＳＩＰエンティティにおける双方（例えば、ＵＥデバイスまたはネットワークノード）として機能し得る。最も基本の形態において、ＳＩＰは、６つのタイプ（メソッド）のリクエストを用い、それらのリクエストは、ＩＮＶＩＴＥ、ＡＣＫ、ＢＹＥ、ＣＡＮＣＥＬ、ＯＰＴＩＯＮＳ、およびＲＥＧＩＳＴＥＲである。ＩＮＶＩＴＥリクエストは、ユーザまたはサービスがコールセッションに参加するように招待されていることを示す。ＡＣＫリクエストは、クライアントがＩＮＶＩＴＥリクエストに対する最終的応答を受信したことを確認する。ＢＹＥリクエストは、コール／セッションを終了させ、発呼者または受呼者（ｃａｌｌｅｅ）のいずれかによって送信され得る。ＣＡＮＣＥＬリクエストは、現在進行中のコール／セッションを終了させずに、任意の保留の検索をキャンセルする。ＯＰＴＩＯＮＳリクエストは、サーバの能力をクエリする。ＲＥＧＩＳＴＥＲリクエストは、宛先（Ｔｏ）：ヘッダフィールド内に列挙されているアドレスをＳＩＰサーバによって登録する。ＳＩＰが発展し続け得るので、受領者は、ＳＩＰが認識しないリクエストのメソッドを受信し得る。そのようなリクエストのメソッドは、リクエストのＵＮＫＮＯＷＮメソッドとして処理される。
【０００４】
リクエストに応答して、ＳＩＰは次の応答のカテゴリを用い、それらのカテゴリとは、１ｘｘ情報メッセージ、２ｘｘ成功応答、３ｘｘリダイレクション応答、４ｘｘリクエスト失敗応答、５ｘｘサーバ失敗応答、および６ｘｘ一般的失敗応答である。
【０００５】
ＳＩＰメッセージは、一般に、規格化されたメッセージ構造を提供される。図１は、１つの開始ラインと、１つ以上のヘッダフィールドと、メッセージ本体とを有する例示的な通信プロトコルメッセージ（例えば、ＳＩＰメッセージ）の構造を図示し、メッセージ本体は、可能性として複数の本体部分を含む。コマンドライン部分１２は、開始ライン（例えば、リクエストにおけるリクエストラインと、応答におけるステータスラインと）を識別する。ヘッダ部分１４は、様々な情報の一部分を伝える１つ以上のヘッダフィールド１８−１から１８−Ｎを識別する。１つ以上のメッセージ本体部分２０−１から２０−Ｍが、メッセージ本体の部分１６に提供され得る。周知なように、メッセージ本体は、任意のコンテンツを保持するように動作可能であり、任意のコンテンツとは、例えば、プレーンテキスト、コード化画像、または、例えばＸＭＬ、ＨＴＭＬなどのマークアップ言語で表され得る任意の情報である。各々のメッセージ本体（すなわち本体部分）は、ヘッダフィールドを用いて記述され、そのヘッダフィールドとは、限定ではないが、例えば、コンテンツに関する情報を提供するコンテンツ配置、コンテンツ符号化、コンテンツタイプなどである。一般に、Ｃｏｎｔｅｎｔ−Ｔｙｐｅヘッダフィールドの値は、多目的インターネットメール拡張（ＭＩＭＥ）タイプである。
【０００６】
従来からの無線電気通信システムにおいて、基地局の伝送機器は、セルとして公知の地理的領域のいたるところに信号を伝送する。技術が発展してくるにつれて、より進歩したネットワークアクセス機器が導入され、そのネットワークアクセス機器が、以前には可能でなかったサービスを提供し得る。この進歩したネットワークアクセス機器は、基地局ではないかまたは従来からの無線電気通信システムにおける同等な機器よりもさらに高度に発展した他のシステムおよびデバイスではない、例えば、エンハンストノードＢ（ＥＮＢ）を含み得る。そのような進歩した機器または次世代の機器は、本明細書においてロングタームエボリューション（ＬＴＥ）機器と呼ばれ得、そのような機器を用いるパケットベースのネットワークは、発展型パケット通信システム（ＥＰＳ）と呼ばれ得る。本明細書において用いられる場合に、用語「アクセスデバイス」は、任意の構成要素を表し、任意の構成要素とは、例えば、従来からの基地局、ＬＴＥ ＥＮＢ、または電気通信システム内の他の構成要素へのアクセスをＵＡに提供し得る任意の他の構成要素である。パケットデータに対して、データをＵＡとアクセスデバイスとの間で搬送する信号は、周波数、時間、および符号化のパラメータと、アクセスデバイスによって指定され得る他の特性の特定の組とを有し得る。そのような特性の特定の組を有するＵＡとアクセスデバイスとの間の接続がリソースと呼ばれ得る。アクセスデバイスは、一般に、任意の特定の時間に通信する各々のＵＡに対して異なるリソースを確立する。
【０００７】
回線交換を介して行われ得る通信は、回線交換領域において起こると言われ、パケット交換を介して行われ得る通信は、パケット交換領域において起こると言われ得る。各々の領域において、いくつかの異なるタイプのネットワーク、プロトコル、または技術が用いられ得る。場合に応じて、同じネットワーク、プロトコル、または技術が両方の領域において用いられ得る。無線通信ネットワークは、符号分割多重アクセス（ＣＤＭＡ）、時分割多重アクセス（ＴＤＭＡ）、周波数分割多重アクセス（ＦＤＭＡ）、直交周波数分割多重化（ＯＦＤＭ）、または他の多重アクセススキームに基づき得る。ＣＤＭＡベースのネットワークは、３ＧＰＰ２ ＩＳ−２０００（ＣＤＭＡ １ｘと一般に呼ばれる）、３ＧＰＰ２ ＩＳ−８５６（ＣＤＭＡ １ｘＥＶ−ＤＯと一般に呼ばれる）、または３ＧＰＰ ＵＭＴＳ（Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｙｓｔｅｍ）などの１つ以上の規格を実装し得る。ＴＤＭＡベースのネットワークは、３ＧＰＰ Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ（ＧＳＭ）または３ＧＰＰ Ｇｅｎｅｒａｌ Ｐａｃｋｅｔ Ｒａｄｉｏ Ｓｅｒｖｉｃｅ（ＧＰＲＳ）などの１つ以上の規格を実装し得る。
【０００８】
ＧＳＭは、回線交換モードだけを用いる無線ネットワーク規格の例である。パケット交換だけを用いる無線ネットワーク規格の例は、ＧＰＲＳ、ＣＤＭＡ １ｘ ＥＶ−ＤＯ、Ｗｏｒｌｄｗｉｄｅ Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ ｆｏｒ Ｍｉｃｒｏｗａｖｅ
Ａｃｃｅｓｓ（ＷｉＭＡＸ）、および無線ローカルエリアネットワーク（ＷＬＡＮ）（米国電気電子技術者協会（ＩＥＥＥ）の規格に適合し得る、例えば、８０２．１６、８０２．１６ｅ、８０２．１１ａ、８０２．１１ｂ、８０２．１１ｇ、８０２．１１ｎ、および同様な規格）を含む。回線交換モードと、パケット交換モードとの両方を用い得る無線ネットワーク規格の例は、ＣＤＭＡ １ｘと、ＵＭＴＳとを含む。パケット交換無線ネットワークにおいて用いられ得るアプリケーション層プロトコルの例は、セッション開始プロトコル（ＳＩＰ）である。ＳＩＰは、主としてＩｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ（ＩＥＴＦ）によって規格化され、管理されている。ＩＰ（インターネットプロトコル）マルチメディアサブシステム（ＩＭＳ）は、テキスト、オーディオ、および／またはビデオの部分を含み得るマルチメディアコンテンツがノードの間に伝送されることを可能にするパケット交換技術である。
【発明の概要】
【課題を解決するための手段】
【０００９】
本開示の１つ以上の実施形態の例示的な実装が以下に提供されるが、開示されているシステムおよび／または方法が、現時点で公知であるかまたは存在するか否かにかかわらず、任意の数の技術を用いて実装され得ることは最初に理解されるべきである。本開示は、本明細書中に例示され、記載されている例示的な設計および実装を含む、以下に示されている例示的な実装、図面、および技術に決して限定されるべきではないが、均等物の完全な範囲と共に添付の特許請求の範囲の範囲内において修正され得る。
【００１０】
一実施形態において、方法が、ネットワーク構成要素からアプリケーションサーバとユーザ機器とのうちの少なくとも１つへの第二のセッション開始プロトコル（ＳＩＰ）メッセージ内に情報を含むために提供される。情報は、第一のＳＩＰメッセージから取得され得る。方法は、フィルタ判定基準をネットワーク構成要素にダウンロードすることと、情報を含む必要性を指定する１つ以上のインジケータをフィルタ判定基準が含むか否かを決定することと、フィルタ判定基準によって指定された情報を第二のＳＩＰメッセージ内に含めることとを含む。ネットワーク構成要素はまた、フィルタ判定基準をネットワーク構成要素にダウンロードすることに加えてまたはダウンロードする代わりにフィルタ判定基準と共に構成されるか、さもなければフィルタ判定基準と共に供給され得る。
【００１１】
代替の一実施形態において、電気通信ネットワーク内の構成要素が提供され、構成要素は、構成要素からユーザエージェントサーバへの第二のＳＩＰメッセージ内に含まれる、第一のセッション開始プロトコル（ＳＩＰ）メッセージからの情報に対する必要性を指定する１つ以上のインジケータをフィルタ判定基準が含むか否かを決定するように構成されているプロセッサを含む。プロセッサは、１つ以上のインジケータによって指定された情報を第二のＳＩＰメッセージ内に含めるようにさらに構成される。
【００１２】
代替の一実施形態において、ユーザ機器が提供され、ユーザ機器は、登録イベントの結果としてネットワーク構成要素によって伝送されるＳＩＰ ＮＯＴＩＦＹメッセージを発生するセッション開始プロトコル（ＳＩＰ）イベントパッケージ（Ｅｖｅｎｔ Ｐａｃｋａｇｅ）を受信するように構成されているプロセッサを含む。ＳＩＰ ＮＯＴＩＦＹメッセージは、別のユーザ機器とネットワーク構成要素との間に送信される第一のＳＩＰメッセージ内に含まれる情報の少なくとも一部分を含んでいる。
【００１３】
代替の一実施形態において、方法は、サービングコールセッション制御機能（Ｓ−ＣＳＣＦ）からアプリケーションサーバとユーザ機器とのうちの少なくとも１つへの第二のセッション開始プロトコル（ＳＩＰ）ＲＥＧＩＳＴＥＲリクエスト内に情報を含めるために提供される。方法は、情報の必要性を指定する１つ以上のインジケータを含むフィルタ判定基準をＳ−ＣＳＣＦにダウンロードすることを含む。方法はさらに、フィルタ判定基準によって指定された情報を第二のＳＩＰ ＲＥＧＩＳＴＥＲリクエスト内に含めることを含む。
本発明は、例えば、以下を提供する。
（項目１）
第一のセッション開始プロトコル（ＳＩＰ）メッセージからの情報をネットワーク構成要素からユーザエージェントサーバ（ＵＡＳ）への第二のＳＩＰメッセージ内に含める方法であって、
該情報の必要性を指定する１つ以上のインジケータをフィルタ判定基準が含むか否かを決定することと、
該１つ以上のインジケータによって指定された該情報を該第二のＳＩＰメッセージ内に含めることと
を包含する、方法。
（項目２）
上記１つ以上のインジケータを含む上記フィルタ判定基準を上記ネットワーク構成要素にダウンロードすることと、
該１つ以上のインジケータを含む該フィルタ判定基準によって該ネットワーク構成要素を構成することと
のうちの少なくとも１つのことをさらに包含する、項目１に記載の方法。
（項目３）
上記ＵＡＳは、
ネットワークノードと、
アプリケーションサーバと、
ユーザ機器と
のうちの少なくとも１つに提供される、項目１または項目２に記載の方法。
（項目４）
上記情報は、
ユーザ機器と上記ネットワーク構成要素との間の上記第一のＳＩＰメッセージの少なくともヘッダフィールドと、
ユーザ機器と該ネットワーク構成要素との間の該第一のＳＩＰメッセージの本体の少なくとも一部分と
のうちの少なくとも１つである、項目１〜項目３のうちのいずれか一項に記載の方法。
（項目５）
上記第一のＳＩＰメッセージおよび上記第二のＳＩＰメッセージは、ＳＩＰリクエストと、ＳＩＰ応答とのうちの１つである、項目１〜項目４のうちのいずれか一項に記載の方法。
（項目６）
上記第一のＳＩＰリクエストおよび上記第二のＳＩＰリクエストは、
ＳＩＰ ＲＥＧＩＳＴＥＲリクエストと、
ＳＩＰ ＩＮＶＩＴＥリクエストと、
ＳＩＰ ＲＥＦＥＲリクエストと、
ＳＩＰ ＭＥＳＳＡＧＥリクエストと、
ＳＩＰ ＳＵＢＳＣＲＩＢＥリクエストと、
ＳＩＰ ＩＮＦＯリクエストと、
ＳＩＰ ＰＵＢＬＩＳＨリクエストと、
ＳＩＰ ＮＯＴＩＦＹリクエストと
のうちの１つである、項目５に記載の方法。
（項目７）
上記情報を上記第二のＳＩＰメッセージ内に、
該第二のＳＩＰメッセージ内のヘッダと、
該第二のＳＩＰメッセージの本体内の多目的インターネットメール拡張（ＭＩＭＥ）本体と
のうちの１つとして含めることをさらに包含する、項目１〜項目６のうちのいずれか一項に記載の方法。
（項目８）
上記ＭＩＭＥ本体を上記第二のＳＩＰメッセージの上記本体内に、
複数部分混合型のＭＩＭＥ本体内にカプセル化されたＭＩＭＥ本体と、
ＳＩＰリクエストおよびＳＩＰ応答のうちの一方のすべてまたは一部を含んでいるＭＩＭＥ本体と
のうちの１つとして含めることをさらに包含する、項目７に記載の方法。
（項目９）
ＳＩＰリクエストおよびＳＩＰ応答のうちの一方のすべてまたは一部を含んでいる上記ＭＩＭＥ本体は、該ＭＩＭＥ本体の関連するコンテンツタイプを有するＭＩＭＥ本体である、項目８に記載の方法。
（項目１０）
ＳＩＰリクエストおよびＳＩＰ応答のうちの一方のすべてまたは一部を含んでいる上記ＭＩＭＥ本体内に上記情報が含まれる場合に、該ＭＩＭＥ本体は、
ユーザ機器と上記ネットワーク構成要素との間の第一のＳＩＰメッセージの初期開始ラインと、
ユーザ機器と該ネットワーク構成要素との間の第一のＳＩＰメッセージの少なくともヘッダフィールドと、
ユーザ機器と該ネットワーク構成要素との間の第一のＳＩＰメッセージの本体の少なくとも一部分と
のうちの少なくとも１つを含む、項目８に記載の方法。
（項目１１）
上記情報の必要性を指定する上記１つ以上のインジケータが、上記第二のＳＩＰメッセージ内に、どのヘッダフィールド、本体または本体の部分、および開始ラインが含まれるべきであるかを示しているか否かを決定することをさらに包含する、項目１〜項目１０のうちのいずれか一項に記載の方法。
（項目１２）
上記第二のＳＩＰメッセージは、登録イベントの結果として伝送される登録イベントパッケージを含んでいるＳＩＰ ＮＯＴＩＦＹメッセージであり、該第二のＳＩＰメッセージは、上記第一のＳＩＰメッセージからの情報の少なくとも一部分を含んでいる、項目１〜項目１１のうちのいずれか一項に記載の方法。
（項目１３）
上記第一のＳＩＰメッセージからの上記情報は、上記ＳＩＰ ＮＯＴＩＦＹメッセージ内に、
直接的に上記登録イベントパッケージ内に包含することと、
該ＳＩＰ ＮＯＴＩＦＹメッセージ内のＭＩＭＥ本体に対する参照によって包含することと
のうちの１つのことによって含まれる、項目１２に記載の方法。
（項目１４）
上記ＳＩＰ ＮＯＴＩＦＹメッセージ内に含まれる上記情報の少なくとも一部分は、ＳＩＰリクエストまたはＳＩＰ応答のすべてまたは一部を含んでいる、項目１３に記載の方法。
（項目１５）
上記ＳＩＰ ＮＯＴＩＦＹメッセージを受信し、上記ＳＩＰリクエストおよび上記ＳＩＰ応答のうちの一方の上記すべてまたは一部を取り出すユーザ機器をさらに含んでいる、項目１４に記載の方法。
（項目１６）
上記ネットワーク構成要素は、サービングコールセッション制御機能である、項目１〜項目１５のうちのいずれか一項に記載の方法。
（項目１７）
電気通信ネットワーク内の構成要素であって、
プロセッサであって、第一のセッション開始プロトコル（ＳＩＰ）メッセージからの情報の、該構成要素からユーザエージェントサーバ（ＵＡＳ）への第二のＳＩＰメッセージ内に含まれる必要性を指定する１つ以上のインジケータをフィルタ判定基準が含むか否かを決定するように構成され、該１つ以上のインジケータによって指定された該情報を該第二のＳＩＰメッセージ内に含めるようにさらに構成されている、プロセッサ
を備えている、構成要素。
（項目１８）
上記構成要素は、上記フィルタ判定基準を、
上記１つ以上のインジケータを含む該フィルタ判定基準を該構成要素にダウンロードすることと、
該１つ以上のインジケータを含む該フィルタ判定基準によって該構成要素を構成することと
のうちの少なくとも１つのことによって受信する、項目１７に記載の構成要素。
（項目１９）
上記ＵＡＳは、
ネットワークノードと、
アプリケーションサーバと、
ユーザ機器と
のうちの少なくとも１つに提供される、項目１７または項目１８に記載の構成要素。
（項目２０）
上記情報は、
ユーザ機器と上記構成要素との間の上記第一のＳＩＰメッセージの少なくともヘッダフィールドと、
ユーザ機器と該構成要素との間の該第一のＳＩＰメッセージの本体の少なくとも一部分と
のうちの少なくとも１つである、項目１７〜項目１９のうちのいずれか一項に記載の構成要素。
（項目２１）
上記第一のＳＩＰメッセージおよび上記第二のＳＩＰメッセージは、ＳＩＰリクエストおよびＳＩＰ応答のうちの１つである、項目１７〜項目２０のうちのいずれか一項に記載の構成要素。
（項目２２）
上記第一のＳＩＰリクエストおよび上記第二のＳＩＰリクエストは、
ＳＩＰ ＲＥＧＩＳＴＥＲリクエストと、
ＳＩＰ ＩＮＶＩＴＥリクエストと、
ＳＩＰ ＲＥＦＥＲリクエストと、
ＳＩＰ ＭＥＳＳＡＧＥリクエストと、
ＳＩＰ ＳＵＢＳＣＲＩＢＥリクエストと、
ＳＩＰ ＩＮＦＯリクエストと、
ＳＩＰ ＰＵＢＬＩＳＨリクエストと、
ＳＩＰ ＮＯＴＩＦＹリクエストと
のうちの１つである、項目２１に記載の構成要素。
（項目２３）
上記情報は、上記第二のＳＩＰメッセージ内に
該第二のＳＩＰメッセージ内のヘッダと、
該第二のＳＩＰメッセージの本体内の多目的インターネットメール拡張（ＭＩＭＥ）本体と
のうちの１つとして含まれる、項目１７〜項目２２のうちのいずれか一項に記載の構成要素。
（項目２４）
上記ＭＩＭＥ本体を上記第二のＳＩＰメッセージの上記本体内に、
複数部分混合型のＭＩＭＥ本体内にカプセル化されたＭＩＭＥ本体と、
ＳＩＰリクエストおよびＳＩＰ応答のうちの一方のすべてまたは一部を含んでいるＭＩＭＥ本体と
のうちの１つとして含めることをさらに包含する、項目２３に記載の構成要素。
（項目２５）
ＳＩＰリクエストおよびＳＩＰ応答のうちの一方のすべてまたは一部を含んでいる上記ＭＩＭＥ本体は、コンテンツタイプメッセージ／ｓｉｐｆｒａｇのＭＩＭＥ本体である、項目２４に記載の構成要素。
（項目２６）
ＳＩＰリクエストおよびＳＩＰ応答のうちの一方のすべてまたは一部を含んでいる上記ＭＩＭＥ本体内に上記情報が含まれる場合に、該ＭＩＭＥ本体は、
ユーザ機器と上記構成要素との間の第一のＳＩＰメッセージの初期開始ラインと、
ユーザ機器と該構成要素との間の第一のＳＩＰメッセージの少なくともヘッダフィールドと、
ユーザ機器と該構成要素との間の第一のＳＩＰメッセージの本体の少なくとも一部分と
のうちの少なくとも１つを含む、項目２４に記載の構成要素。
（項目２７）
上記１つ以上のインジケータは、どのヘッダフィールド、本体または本体の部分、および開始ラインが上記第二のＳＩＰメッセージ内に含まれるかを示している、項目１７〜項目２６のうちのいずれか一項に記載の構成要素。
（項目２８）
上記第二のＳＩＰメッセージは、登録イベントの結果として伝送される登録イベントパッケージを含んでいるＳＩＰ ＮＯＴＩＦＹメッセージであり、該第二のＳＩＰメッセージは、上記第一のＳＩＰメッセージからの情報の少なくとも一部分を含んでいる、項目１７〜項目２７のうちのいずれか一項に記載の構成要素。
（項目２９）
上記第一のＳＩＰメッセージからの上記情報は、上記ＳＩＰ ＮＯＴＩＦＹメッセージ内に、
直接的に上記登録イベントパッケージ内に包含することと、
該ＳＩＰ ＮＯＴＩＦＹメッセージ内のＭＩＭＥ本体に対する参照によって包含することと
のうちの１つのことによって含まれる、項目２８に記載の構成要素。
（項目３０）
上記ＳＩＰ ＮＯＴＩＦＹメッセージ内に含まれる上記情報の少なくとも一部分は、ＳＩＰリクエストまたはＳＩＰ応答のすべてまたは一部を含んでいる、項目２９の構成要素。
（項目３１）
上記ＳＩＰ ＮＯＴＩＦＹメッセージを受信し、上記ＳＩＰリクエストと上記ＳＩＰ応答とのうちの一方の上記すべてまたは一部を取り出すユーザ機器をさらに含んでいる、項目３０の構成要素。
（項目３２）
上記構成要素は、サービングコールセッション制御機能である、項目１７〜項目３１のうちのいずれか一項に記載の構成要素。
（項目３３）
ユーザ機器であって、
登録イベントの結果としてネットワーク構成要素によって伝送されるセッション開始プロトコル（ＳＩＰ）ＮＯＴＩＦＹメッセージを受信するように構成されているプロセッサであって、該ＳＩＰ ＮＯＴＩＦＹメッセージは、別のユーザ機器と該ネットワーク構成要素との間に送信される第一のＳＩＰメッセージ内に含まれる情報の少なくとも一部分を含んでいる、プロセッサ
を備えている、ユーザ機器。
（項目３４）
上記ネットワーク構成要素は、上記ＳＩＰ ＮＯＴＩＦＹメッセージ内に含まれる情報の上記部分を指定する１つ以上のインジケータを含むフィルタ判定基準を含み、該インジケータによって指定された該情報の該部分を該ＳＩＰ ＮＯＴＩＦＹメッセージ内に含めるように構成され、該ＳＩＰ ＮＯＴＩＦＹメッセージ内に含まれる該情報の該部分は、
上記第一のＳＩＰメッセージの開始ラインと、
該第一のＳＩＰメッセージのヘッダの少なくとも一部分と、
該第一のＳＩＰメッセージの本体の少なくとも一部分と
のうちの少なくとも１つを含む、項目３３に記載のユーザ機器。
（項目３５）
上記第一のＳＩＰメッセージ内の上記情報の上記部分は、ＳＩＰ ＮＯＴＩＦＹメッセージ内に
該ＳＩＰ ＮＯＴＩＦＹメッセージ内のヘッダと、
該ＳＩＰ ＮＯＴＩＦＹメッセージの本体内の多目的インターネットメール拡張（ＭＩＭＥ）本体と
のうちの１つとして含まれる、項目３３または項目３４に記載のユーザ機器。
（項目３６）
上記第一のＳＩＰメッセージからの上記情報は、上記ＳＩＰ ＮＯＴＩＦＹメッセージ内に、
直接的に該ＳＩＰ ＮＯＴＩＦＹメッセージ内の登録イベントパッケージ内に包含することと、
該ＳＩＰ ＮＯＴＩＦＹメッセージ内のＭＩＭＥ本体に対する参照によって包含することと
のうちの１つのことによって含まれる、項目３３〜項目３５のうちのいずれか一項に記載のユーザ機器。
（項目３７）
上記第一のＳＩＰメッセージは、上記ＳＩＰ ＮＯＴＩＦＹメッセージをトリガしたＳＩＰ ＲＥＧＩＳＴＥＲメッセージである、項目３３〜項目３６のうちのいずれか一項に記載のユーザ機器。
（項目３８）
上記プロセッサは、上記ＳＩＰ ＮＯＴＩＦＹメッセージを受信する際に、上記第一のＳＩＰメッセージ内に含まれている上記情報の上記部分を取り出すようにさらに構成されている、項目３３〜項目３７のうちのいずれか一項に記載のユーザ機器。
（項目３９）
上記プロセッサは、上記第一のＳＩＰメッセージ内に含まれている上記情報の上記部分を利用するようにさらに構成されている、項目３３〜項目３８のうちのいずれか一項に記載のユーザ機器。
（項目４０）
第一のセッション開始プロトコル（ＳＩＰ）メッセージからの情報をサービングコールセッション制御機能（Ｓ−ＣＳＣＦ）からユーザエージェントサーバ（ＵＡＳ）への第二のＳＩＰメッセージ内に含める方法であって、
該情報の必要性を指定する１つ以上のインジケータをフィルタ判定基準が含むか否かを決定することと、
該１つ以上のインジケータによって指定された該情報を該第二のＳＩＰメッセージ内に含めることと
を包含する、方法。
（項目４１）
上記１つ以上のインジケータを含む上記フィルタ判定基準を上記ネットワーク構成要素にダウンロードすることと、
該１つ以上のインジケータを含む該フィルタ判定基準によって該ネットワーク構成要素を構成することと
のうちの少なくとも１つのことをさらに包含する、項目４０に記載の方法。
（項目４２）
上記ＵＡＳは、ユーザ機器（ＵＥ）デバイスと、ネットワークノードとのうちの一方に提供される、項目４０または項目４１に記載の方法。
（項目４３）
上記ネットワークノードは、アプリケーションサーバ（ＡＳ）である、項目４２に記載の方法。
（項目４４）
上記情報は、ＵＥと上記Ｓ−ＣＳＣＦとの間の上記第一のＳＩＰメッセージのすべてまたは一部である、項目４０〜項目４３のうちのいずれか一項に記載の方法。
（項目４５）
上記ＵＥと上記Ｓ−ＣＳＣＦとの間の上記第一のＳＩＰメッセージの上記すべてまたは一部は、
該第一のＳＩＰメッセージのすべてと、
該第一のＳＩＰメッセージのヘッダの少なくとも一部分と、
該第一のＳＩＰメッセージの本体の少なくとも一部分と
のうちの少なくとも１つである、項目４４に記載の方法。
（項目４６）
上記第一のＳＩＰメッセージは、入るＲＥＧＩＳＴＥＲリクエストと、該入るＲＥＧＩＳＴＥＲリクエストに対する最終的応答とのうちの少なくとも１つであり、上記第二のＳＩＰリクエストは、サードパーティＲＥＧＩＳＴＥＲリクエストであり、上記フィルタ判定基準は、該入るＲＥＧＩＳＴＥＲリクエストと、該入るＲＥＧＩＳＴＥＲリクエストに対する該最終的応答とのうちの少なくとも１つを該サードパーティＲＥＧＩＳＴＥＲリクエスト内に含めるための指示を含んでいる、項目４５に記載の方法。
（項目４７）
上記Ｓ−ＣＳＣＦは、上記フィルタ判定基準によって示される場合に、上記サードパーティＲＥＧＩＳＴＥＲリクエスト内に上記入るＲＥＧＩＳＴＥＲリクエストと、該入るＲＥＧＩＳＴＥＲリクエストに対する上記最終的応答とのうちの上記少なくとも１つを含める、項目４６に記載の方法。
（項目４８）
上記フィルタ判定基準によって示される場合に、上記入るＲＥＧＩＳＴＥＲリクエストと、該入るＲＥＧＩＳＴＥＲリクエストに対する上記最終的応答とのうちの上記少なくとも１つは、上記サードパーティＲＥＧＩＳＴＥＲリクエストの本体に追加される、項目４７に記載の方法。
（項目４９）
上記入るＲＥＧＩＳＴＥＲリクエストを上記サードパーティＲＥＧＩＳＴＥＲリクエスト内に含める上記指示は、ＸＭＬ要素である、項目４８に記載の方法。
（項目５０）
上記入るＲＥＧＩＳＴＥＲリクエストに対する上記最終的応答を上記サードパーティＲＥＧＩＳＴＥＲリクエストの上記本体内に含める上記指示は、ＸＭＬ要素である、項目４８に記載の方法。
（項目５１）
上記第二のＳＩＰメッセージは、ＲＥＧＩＳＴＥＲリクエストであり、上記アプリケーションサーバは、該ＲＥＧＩＳＴＥＲリクエスト内に含まれる上記第一のＳＩＰメッセージからの該ＲＥＧＩＳＴＥＲリクエスト情報から引き出すように構成されている、項目４３に記載の方法。
（項目５２）
ＸＭＬ要素が上記アプリケーションサーバ用の上記フィルタ判定基準内に提供される場合に、上記Ｓ−ＣＳＣＦは、上記入るＲＥＧＩＳＴＥＲリクエストを上記サードパーティＲＥＧＩＳＴＥＲリクエスト本体内のＭＩＭＥ本体内に含め、コンテンツタイプの値を設定する、項目４６に記載の方法。
（項目５３）
アプリケーションサーバクラスは、
サービス情報ＸＭＬ要素のゼロまたは１つのインスタンスと、
上記入るＲＥＧＩＳＴＥＲリクエストを上記サードパーティＲＥＧＩＳＴＥＲリクエスト内に含めることを示すＸＭＬ要素のゼロまたは１つのインスタンスと、
該入るＲＥＧＩＳＴＥＲリクエストに対する上記最終的応答を該サードパーティＲＥＧＩＳＴＥＲリクエスト内に含めることを示すＸＭＬ要素のゼロまたは１つのインスタンスと
のうちの少なくとも１つを含む、項目４６に記載の方法。
（項目５４）
上記入るＲＥＧＩＳＴＥＲリクエストを上記サードパーティＲＥＧＩＳＴＥＲリクエスト内に含めることを示す上記ＸＭＬ要素と、該入るＲＥＧＩＳＴＥＲリクエストに対する上記最終的応答を含めることを示す上記ＸＭＬ要素とは、フィルタ判定基準の少なくとも１つのトリガポイントが満足される場合に、該入るＲＥＧＩＳＴＥＲリクエストと、該入るＳＩＰ ＲＥＧＩＳＴＥＲリクエストに対する該最終的ＳＩＰ応答とが、アプリケーションサーバに転送されることを上記Ｓ−ＣＳＣＦに対して示す、項目５３に記載の方法。
（項目５５）
コンピューティングデバイスのプロセッサによって実行可能なコンピュータ読み取り可能な命令を格納しているコンピュータ読み取り可能な媒体であって、項目１〜項目５４のうちのいずれか一項に記載の方法を該デバイスに実装させる、コンピュータ読み取り可能な媒体。
【図面の簡単な説明】
【００１４】
本開示に関するさらなる完全な理解のために、同様な参照番号が同様な部分を表す添付の図面、および詳細な説明と共に理解される以下の簡単な説明への参照がここで行われる。
【図１】図１は、本開示の実施形態に従った、ＳＩＰメッセージのための規格化されたメッセージ構造の図である。
【図２】図２は、本開示の実施形態に従った、ＩＭＳアーキテクチャの一部分の図である。
【図３】図３は、本開示の実施形態に従った、ネットワーク構成要素からアプリケーションサーバおよび／またはユーザ機器へのＳＩＰメッセージ内に情報を含める方法の図である。
【図４】図４は、本開示のいくつかの実施形態を実装することに適したプロセッサおよび関連する構成要素を例示する。
【発明を実施するための形態】
【００１５】
第３世代パートナーシッププロジェクト（３ＧＰＰ）は、モバイルネットワークおよび地上通信線ネットワークのためのマルチメディアサービス用の次世代ＳＩＰ／ＩＰベースのネットワークとしてＩＰマルチメディアサブシステム（ＩＭＳ）を規格化した。図２は、ＩＭＳアーキテクチャ内に存在し得る構成要素の一部分を例示する。ＩＭＳ能力を有するＵＥ１１０は、ＩＭＳベースのサービスを要求し、受信し得る。サービングコールセッション制御機能（Ｓ−ＣＳＣＦ）１２０は、ＳＩＰレジストラとして、およびＵＥ１１０から１つ以上のアプリケーションサーバ１３０へのプロキシＳＩＰリクエストに対するサービスプロキシとして作動する。当該分野で周知なように、Ｓ−ＣＳＣＦ１２０は、サーバ、仮想サーバ、プロセッサとメモリとを有するスタンドアロン型サーバであり得るかまたは他の形態をとり得る。アプリケーションサーバ１３０は、マルチメディア電話、音声コール連続性、および個人化ネットワーク管理などのＩＭＳサービスおよびアプリケーション用のサービスロジックを実行する。３つのアプリケーションサーバ１３０が示されているが、他の数のアプリケーションサーバが存在し得る。
【００１６】
初期フィルタ判定基準（ｉＦＣ）１４０の組は、ＵＥ１１０からのＳＩＰリクエストが、どのアプリケーションサーバ１３０にルーティングされるかを決定するために用いられ得る。ＵＥ１１０に対するＳＩＰ登録手順の間、Ｓ−ＣＳＣＦ１２０は、ｉＦＣ１４０をホーム用加入者サーバ（ＨＳＳ）１５０または同様な構成要素からダウンロードする。ｉＦＣ１４０は、どのアプリケーションサーバ１３０に対してリクエストがルーティングされるべきであるかを識別する多くのサービスポイントトリガ（ＳＰＴ）を含み得る。Ｓ−ＣＳＣＦ１２０はまた、ｉＦＣ１４０と共に構成されるか、さもなければｉＦＣ１４０と共に供給され得、従って、Ｓ−ＣＳＣＦ１２０は、各々のＳＩＰ登録手順の間、ｉＦＣ１４０をダウンロードすることを要求されないことがあり得る。さらに、Ｓ−ＣＳＣＦ１２０は、ユーザ、デバイス、セッションのタイプなどの組に対して用いられるフィルタ判定基準の共通の組を含み得る。フィルタ判定基準の共通の組（１つ以上）は、ｉＦＣ１４０内に含まれ得るか、またはｉＦＣ１４０から分離され得る。フィルタ判定基準の共通の組（１つ以上）は、Ｓ−ＣＳＣＦ１２０にダウンロードされ得、および／またはＳ−ＣＳＣＦ１２０は、フィルタ判定基準の共通の組（１つ以上）と共に構成されるか、さもなければフィルタ判定基準の共通の組（１つ以上）と共に供給され得る。
【００１７】
Ｓ−ＣＳＣＦ１２０がＵＥ１１０からＳＩＰ ＲＥＧＩＳＴＥＲリクエストを受信する場合に、サードパーティ登録は、ｉＦＣ１４０に含まれる指示に基づいて実行され得る。サードパーティ登録手順とは、ＵＥ１１０が登録したことをアプリケーションサーバ１３０の１つ以上に対してＳ−ＣＳＣＦ１２０が示すことと、そのＵＥ１１０に役立つために割り当てられるＳ−ＣＳＣＦ１２０のユニフォームリソース識別子（ＵＲＩ）をＳ−ＣＳＣＦ１２０が示すこととを可能にする仕組みである。サードパーティ登録手順は、Ｓ−ＣＳＣＦ１２０による、アプリケーションサーバ１３０のうちの１つに対するＵＥのＳＩＰ
ＲＥＧＩＳＴＥＲリクエストの単なるプロキシ化ではない。なぜならば、ＵＥのＳＩＰ
ＲＥＧＩＳＴＥＲリクエストがＳ−ＣＳＣＦ１２０において終了するからである。代わりに、新しいＳＩＰ ＲＥＧＩＳＴＥＲリクエストが、Ｓ−ＣＳＣＦ１２０からアプリケーションサーバ１３０のうちの１つ、例えば、アプリケーションサーバ１３０２に送信される。
【００１８】
ＵＥ１１０からＳ−ＣＳＣＦ１２０に送信されるＳＩＰ ＲＥＧＩＳＴＥＲリクエストは、入るＲＥＧＩＳＴＥＲリクエスト１６０、最初のＲＥＧＩＳＴＥＲリクエスト１６０、第一のＳＩＰリクエスト１６０、または第一のＳＩＰメッセージ１６０と呼ばれ得る。Ｓ−ＣＳＣＦ１２０からアプリケーションサーバ１３０のうちの１つ以上に送信されるＳＩＰ ＲＥＧＩＳＴＥＲリクエストは、出るＲＥＧＩＳＴＥＲリクエスト１７０、新しいＲＥＧＩＳＴＥＲリクエスト１７０、サードパーティＲＥＧＩＳＴＥＲリクエスト１７０、第二のＳＩＰリクエスト、または第二のＳＩＰメッセージと呼ばれ得る。いくつかの実施形態において、第一のＳＩＰメッセージおよび第二のＳＩＰメッセージは、ＲＥＧＩＳＴＥＲリクエストではないが、ＳＩＰ ＩＮＶＩＴＥリクエスト、ＳＩＰ ＲＥＦＥＲリクエスト、ＳＩＰ ＭＥＳＳＡＧＥリクエスト、ＳＩＰ ＳＵＢＳＣＲＩＢＥリクエスト、ＳＩＰ ＩＮＦＯリクエスト、ＳＩＰ ＰＵＢＬＩＳＨリクエスト、ＳＩＰ ＮＯＴＩＦＹリクエスト、他のＳＩＰリクエスト、または任意のこれらのＳＩＰリクエストに対する応答であり得る。また、下記のように、第二のＳＩＰメッセージは、サードパーティＲＥＧＩＳＴＥＲリクエスト１７０であることの代わりにまたはサードパーティＲＥＧＩＳＴＥＲリクエスト１７０であることに加えて、アプリケーションサーバ１３０のうちの１つ以上に送信され、および／またはユーザ機器１１０に送信されるＳＩＰ ＮＯＴＩＦＹメッセージ１９３であり得る。
【００１９】
３ＧＰＰ ＩＭＳにおいて、サードパーティ登録は、いくつかのヘッダ値を含んでいるＳＩＰ ＲＥＧＩＳＴＥＲリクエストを用いる。「宛先」ヘッダは、登録されているユーザのＳＩＰ ＵＲＩに設定され得る。「送信元（Ｆｒｏｍ）」ヘッダは、Ｓ−ＣＳＣＦ１２０のＳＩＰ ＵＲＩに設定され得る。「連絡先（Ｃｏｎｔａｃｔ）」ヘッダは、登録されたＵＥ１１０に行先を定められたリクエストかまたは登録されたＵＥ１１０に代わって送信されるリクエストにアドレスするために、アプリケーションサーバ１３０２が用いるべきであるＳ−ＣＳＣＦ１２０のＳＩＰ ＵＲＩに設定され得る。第一のＳＩＰメッセージ１６０内のコールＩＤヘッダは、通常、サードパーティＳＩＰ ＲＥＧＩＳＴＥＲリクエスト１７０内のコールＩＤヘッダと異なる。リクエストＵＲＩパラメータは、アプリケーションサーバ１３０２のＳＩＰ ＵＲＩを含み得る。
【００２０】
Ｓ−ＣＳＣＦ１２０がアプリケーションサーバ１３０２に対してプロキシ化するいくつかのＳＩＰリクエスト（例えば、ＳＩＰ ＩＮＶＩＴＥメッセージ）に対して、Ｓ−ＣＳＣＦ１２０は、入るメッセージ内に含まれている情報（例えば、ＳＩＰリクエストＵＲＩ、ＳＩＰヘッダ、およびＳＩＰ本体）のすべてを出るメッセージ内に含める。しかしながら、サードパーティ登録手順において用いられる、出るＳＩＰ ＲＥＧＩＳＴＥＲリクエスト１７０が、入るＳＩＰ ＲＥＧＩＳＴＥＲリクエスト１６０のプロキシ化ではなく新しいリクエストであるので、入るＳＩＰ ＲＥＧＩＳＴＥＲリクエスト１６０の完全なコンテンツは、出るＳＩＰ ＲＥＧＩＳＴＥＲリクエスト１７０内に含まれない。出るＳＩＰ ＲＥＧＩＳＴＥＲリクエスト１７０内のリクエストＵＲＩと、宛先、送信元および連絡先のヘッダとが、サードパーティ登録ＳＩＰ ＲＥＧＩＳＴＥＲリクエストに対して前に規定された値を有しなければならないので、ＵＥ１１０からの最初のＳＩＰ ＲＥＧＩＳＴＥＲリクエスト１６０からの値は、新しいＳＩＰ ＲＥＧＩＳＴＥＲリクエスト１７０内の同じヘッダに含まれることができない。
【００２１】
最初のＳＩＰ ＲＥＧＩＳＴＥＲリクエスト１６０からのこれらのヘッダは、アプリケーションサーバ１３０２に有用な情報を含み得る。例えば、リクエストＵＲＩと、宛先、送信元および連絡先のヘッダとは、ＵＲＩパラメータと、ヘッダパラメータとを含み、ならびに用いられた最初のＵＲＩを含み得る。例えば、連絡先ヘッダは、ＵＥの能力を示すメディア機能タグを含み得る。これらのメディア機能タグは、出るＳＩＰ ＲＥＧＩＳＴＥＲリクエスト１７０の連絡先ヘッダ内に含めることができない。なぜならば、このリクエスト１７０が、ＵＥ１１０のＵＲＩではなくＳ−ＣＳＣＦ１２０のＵＲＩを含み、従って、それらの能力がＵＥ１１０に属する代わりにＳ−ＣＳＣＦ１２０に属していることを示し得るからである。
【００２２】
入るＳＩＰ ＲＥＧＩＳＴＥＲリクエスト１６０はまた、追加のＳＩＰヘッダ（例えば、タイムスタンプヘッダと、ユーザエージェントヘッダと）を含み得、様々な理由のために、追加のＳＩＰヘッダは、出るＳＩＰ ＲＥＧＩＳＴＥＲリクエスト１７０内にＳＩＰ
ＲＥＧＩＳＴＥＲリクエストのヘッダフィールドとして含まれるべきではない。いくつかのヘッダは含まれ得ない。なぜならば、そのような態様でのそれらヘッダの使用がそれらの規定された意味論に適合しないことがあり得、最初のＳＩＰ ＲＥＧＩＳＴＥＲリクエスト１６０から新しいＳＩＰ ＲＥＧＩＳＴＥＲリクエスト１７０へのヘッダのコンテンツを、単にコピーするＳＩＰプロトコルに違反し得るからである。そのことはまた、特定のＳＩＰヘッダのコンテンツが含まれるか否かにかかわらずサービス特有の問題であり得るので、コンテンツを含むことは、情報が不要なアプリケーションサーバ１３０によって受信される冗長な情報を結果としてもたらし得る。
【００２３】
Ｓ−ＣＳＣＦ１２０のためのイベントパッケージは、他のＳＩＰエンティティ（例えば、アプリケーションサーバ１３０と、他のＩＭＳ ＵＥと）に対して登録状態に関する情報を提供し得る。登録イベントパッケージは、連絡先ヘッダパラメータ（例えば、ＵＥの能力を示すメディア機能タグ）などの最初のリクエスト内に含まれているいくつかのコンテンツを含み得る。しかしながら、登録イベントパッケージは、潜在的に関心のあるすべてのヘッダを現時点で含むわけではない。さらに、アプリケーションサーバ１３０２またはＵＥ１１０がＳＩＰ ＲＥＧＩＳＴＥＲリクエスト内の単一のヘッダ値に関心があるだけの場合には、登録イベントパッケージによって用いられるＳＩＰ登録／通知の仕組みは、過大なシグナリングのオーバヘッドを浪費し得る。さらに、新しい拡張がＳＩＰ ＲＥＧＩＳＴＥＲ／登録用のＳＩＰプロトコルに行われる場合には（例えば、新しいヘッダおよび新しいパラメータ）、登録イベントパッケージは、この新しい情報が提供されるように拡張される必要があり得る。登録イベントパッケージへの拡張が既存のＳＩＰ規格に対する修正を必要とし得、そのような拡張を必要とする任意の新しいサービスがＳ−ＣＳＣＦ１２０に対するアップグレードを伴い得るので、単に新しいサービスを作り出すために登録イベントパッケージに対する拡張を必要とすることは、サービス展開の時間的尺度の点から容認できないことであり得る。
【００２４】
さらに、ＩＭＳコアインフラストラクチャをアプリケーションとサービスとから分離することは設計目標であり得る。すなわち、Ｓ−ＣＳＣＦ１２０が、アプリケーション不可知論的であり、サービスとアプリケーションとを理解する必要が全くないことは望ましいことであり得る。従って、Ｓ−ＣＳＣＦ１２０に対する修正が、新しいサービスとアプリケーションとを展開するために必要とされておらず、そのサービスとアプリケーションとに特有の挙動が、アプリケーションサーバ１３０の領域内（およびＵＥ１１０内のクライアントアプリケーション）にとどまることは望ましいことであり得る。新しいサービスが適切に機能するために、サービス特有の挙動を有する既存のコアＩＭＳのインフラストラクチャ構成要素をアップグレードすることは、新しいサービスの展開における実質的な遅れを引き起こし得る。
【００２５】
一実施形態において、これらの問題に対する一般的な解決策が提供される。新しいトリガ１８０が、既存のサービスポイントトリガ（ＳＰＴ）から独立したｉＦＣ１４０内に規定される。＜ＩｎｃｌｕｄｅＣｏｎｔｅｎｔｓＴｒｉｇｇｅｒ＞トリガと呼ばれ得るこれらの新しいトリガ１８０は、第二のＳＩＰリクエスト１７０内に含まれる必要がある情報を識別し得る。いくつかの場合において、第二のＳＩＰリクエストがサードパーティＲＥＧＩＳＴＥＲリクエスト１７０である場合には、トリガ１８０の一方の組が用いられ得、第二のＳＩＰリクエストがＳＩＰ ＮＯＴＩＦＹメッセージ１９３である場合には、トリガ１８０の別方の組が用いられ得る。他の場合において、トリガの同じ組が、サードパーティＲＥＧＩＳＴＥＲリクエスト１７０と、ＳＩＰ ＮＯＴＩＦＹメッセージ１９３との両方に対して用いられ得る。
【００２６】
この態様で新しいトリガ１８０を用いることは、Ｓ−ＣＳＣＦ１２０に、ＳＩＰリクエストを適切なアプリケーションサーバ１３０に対して送信させる第一のＳＩＰメッセージ内の関心のあるポイントを識別するために、ｉＦＣ１４０内の既存のＳＰＴを用いることと対比され得る。新しいサービスは、アプリケーションに到達するために、単に、新しいアプリケーションサーバ１３０（またはアプリケーションサーバ用アプリケーション）を追加することと、新しいクライアント用アプリケーションをＵＥ１１０にダウンロードすることと、ＨＳＳ１５０内のｉＦＣデータを構成することとによって、既存のＳ−ＣＳＣＦ１２０と、他のＩＭＳインフラストラクチャとを用いて展開され得る。上記のように、本明細書における議論がサードパーティ登録手順に集中しているが、ここに規定されている仕組みはまた、Ｓ−ＣＳＣＦ１２０と、アプリケーションサーバ１３０との間の他のＳＩＰメッセージ（例えば、ＳＩＰ ＩＮＶＩＴＥ、ＲＥＦＥＲ、ＭＥＳＳＡＧＥ、ＳＵＢＳＣＲＩＢＥ、ＮＯＴＩＦＹ、ＩＮＦＯ、ＰＵＢＬＩＳＨなど）に適しており、そこでは、Ｓ−ＣＳＣＦ１２０がユーザエージェントまたは背面の（ｂａｃｋ−ｔｏ−ｂａｃｋ）ユーザエージェントとして作動するか、またはサードパーティ呼制御を実行する。
【００２７】
一実施形態において、新しいトリガ１８０が、第一のＳＩＰメッセージ１６０内に見出された情報がサードパーティＲＥＧＩＳＴＥＲリクエスト１７０内に含まれるべきであることを識別する場合には、その情報は、サードパーティＲＥＧＩＳＴＥＲリクエスト１７０のＳＩＰヘッダとして直接的に含まれ得る。アプリケーションサーバ１３０は次いで、サードパーティＲＥＧＩＳＴＥＲリクエスト１７０内に直接的に含まれる関心のあるヘッダからサービス特有の情報を取得し得る。単一のサードパーティＲＥＧＩＳＴＥＲリクエスト１７０が単一のアプリケーションサーバ１３０に対して送信されるように記述されてきたが、複数のサードパーティＲＥＧＩＳＴＥＲリクエスト１７０が、複数のアプリケーションサーバ１３０に対して送信され得、アプリケーションサーバ１３０の各々が、情報をサードパーティＲＥＧＩＳＴＥＲリクエスト１７０から取得し得ることは理解されるべきである。
【００２８】
上記のように、第一のＳＩＰメッセージ１６０からのすべてのヘッダを、サードパーティＳＩＰ ＲＥＧＩＳＴＥＲリクエスト１７０内に直接的に含めることは可能でないことがあり得る。別の実施形態において、第一のＳＩＰメッセージ１６０からの情報は、サードパーティＳＩＰ ＲＥＧＩＳＴＥＲリクエスト１７０の本体内のＳＩＰリクエストまたはＳＩＰ応答のすべてまたは一部を含んでいる多目的インターネットメール拡張（ＭＩＭＥ）本体１９０の包含を介してサードパーティＳＩＰ ＲＥＧＩＳＴＥＲリクエスト１７０内に含められる。アプリケーションサーバ１３０は、次いで、サードパーティＳＩＰ ＲＥＧＩＳＴＥＲリクエスト１７０の本体内のＳＩＰリクエストまたはＳＩＰ応答のすべてまたは一部を含んでいるＭＩＭＥ本体１９０内に含まれる関心のある、開始ライン、ヘッダフィールドまたは本体（部分）からのサービス特有の情報を取得し得る。サードパーティＳＩＰ ＲＥＧＩＳＴＥＲリクエスト１７０が別の本体（例えば、セッション記述プロトコルまたはアプリケーション／３ｇｐｐサービス情報）を同様に含み得るので、ＳＩＰリクエストまたはＳＩＰ応答のすべてまたは一部を含んでいるＭＩＭＥ本体１９０は、サードパーティＳＩＰ ＲＥＧＩＳＴＥＲリクエスト１７０内の複数部分混合型（ｍｕｌｔｉｐａｒｔ ｍｉｘｅｄ）ＭＩＭＥ本体内にさらにカプセル化され得る。ＳＩＰヘッダフィールドに加えて、第一のＳＩＰリクエスト１６０のリクエストＵＲＩおよび本体は、ＳＩＰリクエストまたはＳＩＰ応答のすべてまたは一部を含んでいるＭＩＭＥ本体１９０内に含まれ得る。
【００２９】
一実施形態において、ＳＩＰリクエストまたはＳＩＰ応答のすべてまたは一部を含んでいるＭＩＭＥ本体１９０は、コンテンツタイプメッセージ／ｓｉｐｆｒａｇのＭＩＭＥ本体である。
【００３０】
一実施形態において、サードパーティＳＩＰ ＲＥＧＩＳＴＥＲリクエスト１７０に含める情報を示すｉＦＣトリガ１８０は、情報がＳＩＰヘッダとして含まれるか、あるいはＳＩＰリクエストまたはＳＩＰ応答のすべてまたは一部を含んでいるＭＩＭＥ本体１９０として含まれるかを示すパラメータを含み得る。
【００３１】
一実施形態において、サードパーティＳＩＰ ＲＥＧＩＳＴＥＲリクエスト１７０は、入るＲＥＧＩＳＴＥＲリクエスト１６０に対する最終的応答を含む。
【００３２】
追加の本体コンテンツがリクエスト内に含まれるか、またはＳＩＰリクエストとＳＩＰ応答との両方の部分がリクエスト内に含まれる実施形態において、ＭＩＭＥ本体は、複数部分ＭＩＭＥ本体のコンテンツタイプ内にさらにカプセル化される。
【００３３】
上記の解決策は、ＳＩＰ ＲＥＧＩＳＴＥＲメソッドと、他の任意のＳＩＰメッセージとに対して適用され得る。以下の例は、ＲＥＧＩＳＴＥＲメッセージ内のＳＩＰリクエストまたはＳＩＰ応答のすべてまたは一部を含んでいるＭＩＭＥ本体１９０の使用を示す。１ ＲＥＧＩＳＴＥＲ ＩＭＳ ＵＥ −＞ Ｓ−ＣＳＣＦ
【００３４】
【数１】
２ Ｓ−ＣＳＣＦは、ＨＳＳからの初期フィルタ判定基準を含むユーザプロフィールをダウンロードする。
Ｓ−ＣＳＣＦは、次の２００ ＯＫによって応答する。
３ ２００ ＯＫ Ｓ−ＣＳＣＦ −＞ ＩＭＳ ＵＥ
【００３５】
【数２】
４ フィルタ検査： 初期フィルタ判定基準は、サードパーティレジスタがＡＳ１に送信され、コンテンツタイプメッセージ／ｓｉｐｆｒａｇのＭＩＭＥ本体内に次のヘッダ
リクエストＵＲＩ、
宛先、
送信元、
連絡先、
タイムスタンプ
が含まれるべきであることを示すトリガを含んでいる。
５ ＲＥＧＩＳＴＥＲ Ｓ−ＣＳＣＦ −＞ ＡＳ
【００３６】
【数３−１】
【００３７】
【数３−２】
６ ２００ ＯＫ ＡＳ −＞ Ｓ−ＣＳＣＦ
【００３８】
【数４】
となる。
【００３９】
ＳＩＰ登録が起こる場合に、登録イベントパッケージを含んでいるＳＩＰ ＮＯＴＩＦＹメッセージ１９３が一般に、ＵＥ１１０、アプリケーションサーバ１３０、および／または他のＳＩＰベースの構成要素に対して登録状態の通知として送信される。一実施形態において、ＳＩＰ ＮＯＴＩＦＹメッセージ１９３は、ＳＩＰ ＮＯＴＩＦＹメッセージ１９３をトリガした第一のＳＩＰメッセージ１６０内に含まれている情報の少なくとも一部分をさらに含む。この情報の部分は、ＳＩＰ ＮＯＴＩＦＹメッセージ１９３内のＭＩＭＥ本体１９６に含まれる。いくつかの実施形態において、ＭＩＭＥ本体１９６は、登録イベントパッケージ内に直接的に含まれる。他の実施形態において、情報を含むＭＩＭＥ本体１９６は、ＳＩＰ ＮＯＴＩＦＹメッセージ１９３内の別のＭＩＭＥ本体によって参照される。すなわち、ＳＩＰリクエストまたはＳＩＰ応答のすべてまたは一部を含んでいるＭＩＭＥ本体１９６は、ＳＩＰ ＮＯＴＩＦＹメッセージ１９３内の登録イベントパッケージ内に直接的に含まれ得る。あるいは、ＳＩＰ ＮＯＴＩＦＹメッセージ１９３内の追加であるが別個のＭＩＭＥ本体は、ＳＩＰリクエストまたはＳＩＰ応答のすべてまたは一部を含んでいるＭＩＭＥ本体１９６に対する参照を含み得る。ＳＩＰ ＮＯＴＩＦＹメッセージ１９３内のＳＩＰリクエストまたはＳＩＰ応答のすべてまたは一部を含んでいるＭＩＭＥ本体１９６内に含まれるＳＩＰ ＲＥＧＩＳＴＥＲリクエスト１６０の部分は、上記のように、ｉＦＣ１４０内の新しいトリガ１８０に基づいて決定され得る。ＳＩＰ ＮＯＴＩＦＹ１９３は、ＵＥ１１０、アプリケーションサーバ１３０、あるいは他のＳＩＰユーザエージェントまたはＳＩＰ端末に送信され得る。ＵＥ１１０、アプリケーションサーバ１３０、あるいは他のＳＩＰユーザエージェントまたはＳＩＰ端末は次いで、サービス特有の情報をＳＩＰ ＮＯＴＩＦＹメッセージ１９３から取得し得る。
【００４０】
これらの実施形態は、Ｓ−ＣＳＣＦ１２０に対する１回限りのアップグレードを必要とし得るが、これらの実施形態は、一般的であり、サービス特有ではない。一旦、Ｓ−ＣＳＣＦ１２０がこの新しい仕組みをサポートすると、新しいアプリケーションは、単にｉＦＣトリガデータを更新することによって、ＳＩＰメッセージ（例えば、ＳＩＰ ＲＥＧＩＳＴＥＲリクエスト）から必要な情報を取得し得る。
【００４１】
新しいトリガ１８０を実装するために用いられ得る、拡張可能マークアップ言語（ＸＭＬ）コードの例が以下に提供される。このコードが単に例として提供され、同様な結果を提供する様々な構文的および構造的な修正がなされ得ることは理解されるべきである。この例において、第二のＳＩＰメッセージ内に情報の包含をトリガする第一のメッセージは、ＲＥＧＩＳＴＥＲリクエストであるが、同様な考察が、他のＳＩＰメッセージにあてはまり得る。
【００４２】
この例において、＜ＩｎｃｌｕｄｅＣｏｎｔｅｎｔｓＴｒｉｇｇｅｒ＞要素は、＜Ｃｏｎｄｉｔｉｏｎ＞要素を含んでいる。ヘッダの＜Ｃｏｎｄｉｔｉｏｎ＞要素に対する「Ｃｏｎｄｉｔｉｏｎａｌ」の値は、そのヘッダが第一のＳＩＰ ＲＥＧＩＳＴＥＲリクエスト１６０に含まれている場合には、そのヘッダが、第一のＳＩＰ ＲＥＧＩＳＴＥＲリクエスト１６０からサードパーティＳＩＰ ＲＥＧＩＳＴＥＲリクエスト１７０の中に、および／またはＳＩＰ ＮＯＴＩＦＹメッセージ１９３の中にコピーされることを示している。ヘッダの＜Ｃｏｎｄｉｔｉｏｎ＞要素の「Ｕｎｃｏｎｄｉｔｉｏｎａｌ」は、そのヘッダが第一のリクエスト１６０に含まれているか否かにかかわらず、＜ＳＩＰＨｅａｄｅｒ＞要素内の識別されたＳＩＰヘッダが、＜Ｃｏｎｔｅｎｔ＞要素内に指定されたコンテンツに含まれることを示している。この例において、Ｐ−Ｓｅｒｖｉｃｅ−Ｉｄｅｎｔｉｔｙヘッダは、無条件にＣｏｎｔｅｎｔ「Ｓｅｒｖｉｃｅ１」に含まれている。
【００４３】
＜Ｃｏｎｔｅｎｔ＞要素が、「Ｃｏｎｄｉｔｉｏｎａｌ」の＜Ｃｏｎｄｉｔｉｏｎ＞要素を有する＜ＩｎｃｌｕｄｅＣｏｎｔｅｎｔｓＴｒｉｇｇｅｒ＞要素内に現われる場合には、最初のリクエスト１６０内のＳＩＰヘッダのコンテンツが、最初のＳＩＰリクエスト１６０からサードパーティＳＩＰ ＲＥＧＩＳＴＥＲリクエスト１７０の中に、および／またはＳＩＰ ＮＯＴＩＦＹメッセージ１９３の中にＳＩＰヘッダがコピーされるために、＜Ｃｏｎｔｅｎｔ＞要素内に指定されたコンテンツと一致する必要があることを示している。この例において、コンテンツが「Ｈｏｍｅ１．ｎｅｔ」を含まない場合には、Ｐ−Ａｃｃｅｓｓ−Ｎｅｔｗｏｒｋヘッダが条件付きで含まれる。
【００４４】
「１」の値を有する＜ＣｏｎｄｉｔｉｏｎＮｅｇａｔｅｄ＞要素は、Ｃｏｎｄｉｔｉｏｎの否定（論理否定）を示す。＜Ｇｒｏｕｐ＞要素は、＜ＳＰＴ＞トリガ要素を有する＜ＩｎｃｌｕｄｅＣｏｎｔｅｎｔｓＴｒｉｇｇｅｒ＞要素に関連する。＜Ｂｏｄｙ＞要素は、値をＳＩＰ本体に割り当て得る。条件付きの場合の空の＜Ｂｏｄｙ＞要素は、入るメッセージの本体がコピーされることを示す。複数の本体が含まれる場合には、メッセージは、処理後に適格である、すなわち複数部分／混合型が適用される必要があり得るべきである。
【００４５】
【数５−１】
【００４６】
【数５−２】
となる。
【００４７】
次は、コンテンツタイプメッセージ／ｓｉｐｆｒａｇのＭＩＭＥ本体を含んでいる登録イベントパッケージの通知の例である。
【００４８】
【数６−１】
【００４９】
【数６−２】
【００５０】
【数６−３】
となる。
【００５１】
図３は、ネットワーク構成要素からアプリケーションサーバおよび／またはユーザ機器に対する第二のＳＩＰメッセージ内に情報を含める方法２００の実施形態を例示する。ブロック２１０において、情報が第二のＳＩＰメッセージ内に含まれる必要性を指定する１つ以上のインジケータを含むフィルタ判定基準が、ネットワーク構成要素に対してダウンロードされ、および／またはネットワーク構成要素が、第二のＳＩＰメッセージ内に情報が含まれる必要性を指定する１つ以上のインジケータを含むフィルタ判定基準と共に構成されるか、さもなければフィルタ判定基準と共に供給される。ブロック２１５において、ネットワーク構成要素は、第二のＳＩＰメッセージ内に情報が含まれる必要性を指定する１つ以上のインジケータをフィルタ判定基準が含むか否かを決定する。ブロック２２０において、１つ以上のインジケータによって示された情報が、第二のＳＩＰメッセージ内に含まれる。
【００５２】
いくつかの実施形態において、サービス情報ＸＭＬ要素がアプリケーションサーバ用のフィルタ判定基準内に提供される場合には、Ｓ−ＣＳＣＦは、サービス情報を＜ｓｅｒｖｉｃｅ−ｉｎｆｏ＞ＸＭＬ要素内のサードパーティＲＥＧＩＳＴＥＲリクエスト本体内に含め、かつコンテンツタイプの値をＭＩＭＥタイプに設定する。
【００５３】
いくつかの実施形態において、２つ以上のメッセージ本体がサードパーティＲＥＧＩＳＴＥＲリクエスト内に含まれる場合には、Ｓ−ＣＳＣＦは、複数部分のメッセージ本体をサードパーティＲＥＧＩＳＴＥＲリクエスト内に含め、Ｃｏｎｔｅｎｔ−Ｔｙｐｅヘッダの値を「複数部分／混合型」に設定し、ＭＩＭＥ本体の要素のＣｏｎｔｅｎｔ−Ｔｙｐｅを本体用に指定されたコンテンツタイプに設定する。
【００５４】
いくつかの実施形態において、１つのメッセージ本体だけがサードパーティＲＥＧＩＳＴＥＲリクエスト内に含まれる場合には、Ｓ−ＣＳＣＦは、Ｃｏｎｔｅｎｔ−Ｔｙｐｅヘッダフィールドを本体用に指定されたコンテンツタイプに設定する。
【００５５】
上記のＵＥ１１０と他の構成要素とは、上記の動作に関連する命令を実行することが可能な処理構成要素を含み得る。図４は、本明細書中に開示されている１つ以上の実施形態を実装することに適した処理構成要素１３１０を含むシステム１３００の例を示している。プロセッサ１３１０（中央処理ユニットまたはＣＰＵと呼ばれ得る）に加えて、システム１３００は、ネットワーク接続用デバイス１３２０と、ランダムアクセスメモリ（ＲＡＭ）１３３０と、読出し専用メモリ（ＲＯＭ）１３４０と、二次ストレージ１３５０と、入力／出力（Ｉ／Ｏ）デバイス１３６０とを含み得る。これらの構成要素はバス１３７０を介して互いに通信し得る。場合に応じて、これらの構成要素のいくつかが存在しないことがあり得るか、あるいは互いにまたは示されてない他の構成要素と様々な組み合わせにおいて組み合わされ得る。これらの構成要素は、単一の物理的エンティティ内または２つ以上の物理的エンティティ内に配置され得る。プロセッサ１３１０によって行われるように本明細書中に記述された任意の動作が、プロセッサ１３１０単独で行われるか、あるいは上記のＤＳＰ５０２などの図面中に示されたかまたは示されていない１つ以上の構成要素と共にプロセッサ１３１０によって行われ得る。ＤＳＰ５０２は別個の構成要素として示されているが、ＤＳＰ５０２は、プロセッサ１３１０の中に組み込まれ得る。
【００５６】
プロセッサ１３１０は、ネットワーク接続用デバイス１３２０、ＲＡＭ１３３０、ＲＯＭ１３４０、または二次ストレージ１３５０（ハードディスク、フロッピィディスク、または光ディスクなどの様々なディスクベースのシステムを含み得る）からアクセスし得る命令、コード、コンピュータプログラム、またはスクリプトを実行する。単に１つのＣＰＵ１３１０が示されているが、複数のプロセッサが存在し得る。従って、命令がプロセッサによって実行されるように論じられ得るが、命令は、同時に連続的に実行されるか、さもなければ１つまたは複数のプロセッサによって実行され得る。プロセッサ１３１０は、１つ以上のＣＰＵチップとして実装され得る。
【００５７】
ネットワーク接続用デバイス１３２０は、モデム、モデムバンク、イーサネット（登録商標）デバイス、ユニバーサルシリアルバス（ＵＳＢ）インタフェースデバイス、シリアルインタフェース、トークンリングデバイス、ファイバ分散型データインタフェース（ＦＤＤＩ）デバイス、無線ローカルエリアネットワーク（ＷＬＡＮ）デバイス、符号分割多重アクセス（ＣＤＭＡ）デバイスなどの無線トランシーバデバイス、ｇｌｏｂａｌ ｓｙｓｔｅｍ ｆｏｒ ｍｏｂｉｌｅ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ（ＧＳＭ）無線トランシーバデバイス、ｗｏｒｌｄｗｉｄｅ ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ ｆｏｒ ｍｉｃｒｏｗａｖｅ ａｃｃｅｓｓ（ＷｉＭＡＸ）デバイス、デジタル加入者回線（ｘＤＳＬ）デバイス、ｄａｔａ ｏｖｅｒ ｃａｂｌｅ ｓｅｒｖｉｃｅ ｉｎｔｅｒｆａｃｅ
ｓｐｅｃｉｆｉｃａｔｉｏｎ（ＤＯＣＳＩＳ）モデム、および／またはネットワークに接続するための他の周知のデバイスの形態をとり得る。これらのネットワーク接続用デバイス１３２０は、プロセッサ１３１０が情報を受信し得るかまたはプロセッサ１３１０が情報を出力し得る、インターネットまたは１つ以上の電気通信ネットワークまたは他のネットワークとプロセッサ１３１０が通信することを可能にし得る。
【００５８】
ネットワーク接続用デバイス１３２０はまた、無線周波数信号またはマイクロ波周波数信号などの電磁波という形態でデータを無線で送信および／または受信できる１つ以上のトランシーバ構成要素１３２５を含み得る。あるいは、データは、電気伝導体の中またはその表面上、同軸ケーブルの中、導波管の中、光ファイバなどの光媒体の中、または他の媒体の中を伝播し得る。トランシーバ構成要素１３２５は、別個の受信ユニットと送信ユニットと、または単一のトランシーバを含み得る。トランシーバ構成要素１３２５によって送信されるかまたは受信される情報は、プロセッサ１３１０によって処理されるデータか、またはプロセッサ１３１０によって実行される命令を含み得る。そのような情報は、例えば、コンピュータデータのベースバンド信号かまたは搬送波に組み入れられた信号の形態でネットワークから受信され、ネットワークに出力され得る。データは、データの処理または発生、データの送信または受信に望ましくあり得るように、異なる順序に従って配列され得る。ベースバンド信号、搬送波に埋め込まれた信号、あるいは現在用いられているかまたは今後開発される他のタイプの信号は、伝送媒体と呼ばれ得、当業者に周知のいくつかの方法に従って発生され得る。
【００５９】
ＲＡＭ１３３０は、揮発性のデータを格納し、可能性としては、プロセッサ１３１０によって実行される命令を格納するために用いられ得る。ＲＯＭ１３４０は、一般に、二次ストレージ１３５０のメモリ容量よりも少ないメモリ容量を有する不揮発性メモリデバイスである。ＲＯＭ１３４０は、命令を格納し、可能性としては、命令の実行の間に読み取られるデータを格納するために用いられ得る。ＲＡＭ１３３０とＲＯＭ１３４０との両方に対するアクセスは、一般に、二次ストレージ１３５０に対するよりも高速である。二次ストレージ１３５０は一般に、１つ以上のディスクドライブまたはテープドライブから構成されており、ＲＡＭ１３３０がすべての作業用データを保持するために十分に大きくない場合には、データの不揮発性ストレージ用またはオーバフローデータのストレージ用として用いられ得る。二次ストレージ１３５０は、そのようなプログラムが実行のために選択される場合に、ＲＡＭ１３３０の中にロードされるプログラムを格納するために用いられ得る。
【００６０】
Ｉ／Ｏデバイス１３６０は、液晶ディスプレイ（ＬＣＤ）、タッチスクリーンディスプレイ、キーボード、キーパッド、スイッチ、ダイアル、マウス、トラックボール、音声認識器、カードリーダ、紙テープリーダ、プリンタ、ビデオモニタ、または他の周知の入力デバイスを含み得る。また、トランシーバ１３２５は、ネットワーク接続用デバイス１３２０の構成要素であることの代わりにまたはその構成要素であることに加えて、Ｉ／Ｏデバイス１３６０の構成要素であると考えられ得る。
【００６１】
以下の第三世代パートナーシッププロジェクト（３ＧＰＰ）の技術仕様（ＴＳ）は、参考として本明細書中に援用され、それらのＴＳは、ＴＳ ２３．２１８ Ｖ７．７．１（２００７−０６）、ＴＳ ２３．２２８ Ｖ７．９．０（２００７−０９）、ＴＳ ２４．２２９ Ｖ７．８．０（２００７−１２）、ＴＳ ２９．２２８ Ｖ７．１０．０（２００７−１２）、およびＴＳ ２９．２２９ Ｖ７．７．０（２００７−１２）である。また、「ＳＩＰ：セッション開始プロトコル」、２００２年６月のＲＦＣ３２６１、およびＲＦＣ３２６５、ＲＦＣ３６８０、およびＲＦＣ３４２０が、参考として本明細書中に援用される。
【００６２】
いくつかの実施形態が本開示において提供されてきたが、開示されたシステムおよび方法が、本開示の精神または範囲から逸脱することなく、多くの他の特定の形態に組み入れられ得ることは理解されるべきである。本例は、限定としてではなく例示として斟酌され、本明細書中に与えられた詳細に限定されないことが意図されている。例えば、様々な要素または構成要素は、別のシステム内に組み合わされるかまたは一体化され得、特定の機能が、省略されるかまたは実装されないことがあり得る。
【００６３】
また、様々な実施形態の中で分離しているかまたは別個であるように記載され、例示された技術、システム、サブシステム、および方法は、本開示の範囲を逸脱することなく他のシステム、モジュール、技術、または方法と組み合わされるかまたは一体化され得る。結合したかまたは直接結合したかまたは互いに通信するように示され、または論じられた他の項目は、電気的、機械的、またはその他にかかわらず、いくつかのインタフェース、デバイス、または中間の構成要素を介して間接的に結合されるかまたは通信する。変化、置換、および変更の他の例は、当業者によって確認可能であり、本明細書中に開示された精神および範囲から逸脱することなく作られ得る。
【特許請求の範囲】
【請求項１】
ネットワーク構成要素によってアプリケーションサーバ（ＡＳ）に情報を提供する方法であって、前記方法は、
ユーザ機器（ＵＥ）からセッション開始プロトコル（ＳＩＰ）ＲＥＧＩＳＴＥＲメッセージを受信することと、
フィルタ判定基準が新しいＳＩＰメッセージの必要性を示すか否かを決定し、前記フィルタ判定基準が、前記新しいＳＩＰメッセージが、前記ＳＩＰ ＲＥＧＩＳＴＥＲメッセージの全体またはＳＩＰ応答メッセージのうちの少なくとも１つを含むことになることを示すか否かをさらに決定することであって、これらの決定は、前記ＳＩＰ ＲＥＧＩＳＴＥＲメッセージの受信に応答する、ことと、
前記新しいＳＩＰメッセージの本体内に多目的インターネットメール拡張（ＭＩＭＥ）本体を含めることであって、前記ＭＩＭＥ本体は、前記ＳＩＰ ＲＥＧＩＳＴＥＲメッセージの全体または前記ＳＩＰ応答メッセージのうちの少なくとも１つを含む、ことと
を含む、方法。
【請求項２】
前記新しいＳＩＰメッセージを前記ＡＳに送信することをさらに含む、請求項１に記載の方法。
【請求項３】
前記受信されたＳＩＰ ＲＥＧＩＳＴＥＲメッセージは、第１のリクエストユニフォームリソース識別子（リクエストＵＲＩ）を含み、前記第１のリクエストＵＲＩは、ＳＩＰ ＲＥＧＩＳＴＥＲアドレスを含み、前記新しいＳＩＰメッセージは、第２のリクエストＵＲＩを含み、前記第２のリクエストＵＲＩは、前記ＡＳのアドレスを含む、請求項２に記載の方法。
【請求項４】
ユーザプロフィールを前記ネットワーク構成要素にダウンロードすることをさらに含む、請求項１に記載の方法。
【請求項５】
前記ユーザプロフィールは、前記フィルタ判定基準を含む、請求項４に記載の方法。
【請求項６】
前記含められたＳＩＰ応答メッセージは、前記ＳＩＰ ＲＥＧＩＳＴＥＲメッセージに応答して前記ＵＥに送信されるＳＩＰ ２００ ＯＫメッセージのコピーである、請求項１に記載の方法。
【請求項７】
ネットワークエンティティの前記リクエストユニフォームリソース識別子（リクエストＵＲＩ）を連絡先ヘッダフィールドとして含めることをさらに含む、請求項１に記載の方法。
【請求項８】
前記新しいＳＩＰメッセージは、登録イベントの結果として伝送された登録イベントパッケージを含むＳＩＰ ＮＯＴＩＦＹメッセージであり、前記新しいＳＩＰメッセージは、前記新しいＳＩＰ ＲＥＧＩＳＴＥＲメッセージの全体を含む、請求項１に記載の方法。
【請求項９】
前記新しいＳＩＰメッセージの”Ｔｏ：”フィールドは、前記ＵＥの識別子を含み、前記新しいＳＩＰメッセージの”Ｆｒｏｍ：”フィールドは、ネットワークエンティティの識別子を含む、請求項１に記載の方法。
【請求項１０】
前記ネットワーク構成要素は、サービングコールセッション制御機能である、請求項１に記載の方法。
【請求項１１】
電気通信ネットワーク内の構成要素であって、
前記構成要素は、プロセッサを含み、
前記プロセッサは、
ユーザ機器（ＵＥ）からセッション開始プロトコル（ＳＩＰ）ＲＥＧＩＳＴＥＲメッセージを受信することと、
フィルタ判定基準が新しいＳＩＰメッセージの必要性を示すか否かを決定し、前記フィルタ判定基準が、前記新しいＳＩＰメッセージが、前記ＳＩＰ ＲＥＧＩＳＴＥＲメッセージの全体またはＳＩＰ応答メッセージのうちの少なくとも１つを含むことになることを示すか否かをさらに決定することであって、これらの決定は、前記ＳＩＰ ＲＥＧＩＳＴＥＲメッセージの受信に応答する、ことと、
前記新しいＳＩＰメッセージの本体内に多目的インターネットメール拡張（ＭＩＭＥ）本体を含めることであって、前記ＭＩＭＥ本体は、前記ＳＩＰ ＲＥＧＩＳＴＥＲメッセージの全体または前記ＳＩＰ応答メッセージのうちの少なくとも１つを含む、ことと
を行うように構成されている、構成要素。
【請求項１２】
前記プロセッサは、前記新しいＳＩＰメッセージをアプリケーションサーバ（ＡＳ）に送信するようにさらに構成されている、請求項１１に記載の構成要素。
【請求項１３】
前記受信されたＳＩＰ ＲＥＧＩＳＴＥＲメッセージは、第１のリクエストユニフォームリソース識別子（リクエストＵＲＩ）を含み、前記第１のリクエストＵＲＩは、ＳＩＰ ＲＥＧＩＳＴＥＲアドレスを含み、前記新しいＳＩＰメッセージは、第２のリクエストＵＲＩを含み、前記第２のリクエストＵＲＩは、前記ＡＳのアドレスを含む、請求項１２に記載の構成要素。
【請求項１４】
前記プロセッサは、ユーザプロフィールを前記ネットワーク構成要素にダウンロードするようにさらに構成されている、請求項１１に記載の構成要素。
【請求項１５】
前記ユーザプロフィールは、前記フィルタ判定基準を含む、請求項１４に記載の構成要素。
【請求項１６】
前記含められたＳＩＰメッセージは、前記ＳＩＰ ＲＥＧＩＳＴＥＲメッセージに応答して前記ＵＥに送信さえるＳＩＰ ２００ ＯＫメッセージのコピーである、請求項１１に記載の構成要素。
【請求項１７】
前記新しいＳＩＰメッセージは、登録イベントの結果として伝送された登録イベントパッケージを含むＳＩＰ ＮＯＴＩＦＹメッセージであり、前記新しいＳＩＰメッセージは、前記ＳＩＰ ＲＥＧＩＳＴＥＲメッセージの全体を含む、請求項１１に記載の構成要素。
【請求項１８】
前記構成要素は、サービングコールセッション制御機能である、請求項１１に記載の構成要素。
【請求項１９】
命令を含むコンピュータ読み取り可能なメモリであって、前記コンピュータ読み取り可能な命令は、プロセッサによって実行されると、アプリケーションサーバ（ＡＳ）に情報を提供する方法を実装するように適合されており、前記方法は、
ユーザ機器（ＵＥ）からセッション開始プロトコル（ＳＩＰ） ＲＥＧＩＳＴＥＲメッセージを受信することと、
フィルタ判定基準が新しいＳＩＰメッセージの必要性を示すか否かを決定し、前記フィルタ判定基準が、前記新しいＳＩＰメッセージが、前記ＳＩＰ ＲＥＧＩＳＴＥＲメッセージの全体またはＳＩＰ応答メッセージのうちの少なくとも１つを含むことになることを示すか否かをさらに決定することであって、これらの決定は、前記ＳＩＰ ＲＥＧＩＳＴＥＲメッセージの受信に応答する、ことと、
前記新しいＳＩＰメッセージの本体内に多目的インターネットメール拡張（ＭＩＭＥ）本体を含めることであって、前記ＭＩＭＥ本体は、前記ＳＩＰ ＲＥＧＩＳＴＥＲメッセージの全体またはＳＩＰ応答メッセージのうちの少なくとも１つを含む、ことと
を含み、
前記受信されたＳＩＰ ＲＥＧＩＳＴＥＲメッセージは、第１のリクエストユニフォームリソース識別子（リクエストＵＲＩ）を含み、前記第１のリクエストＵＲＩは、ＳＩＰ ＲＥＧＩＳＴＥＲアドレスを含み、前記新しいＳＩＰメッセージは、第２のリクエストＵＲＩを含み、前記第２のリクエストＵＲＩは、前記ＡＳのアドレスを含む、コンピュータ読み取り可能なメモリ。
【請求項２０】
前記方法は、ユーザプロフィールをダウンロードすることをさらに含み、前記ユーザプロフィールは、前記フィルタ判定基準を含む、請求項１９に記載のコンピュータ読み取り可能なメモリ。
【請求項１】
ネットワーク構成要素によってアプリケーションサーバ（ＡＳ）に情報を提供する方法であって、前記方法は、
ユーザ機器（ＵＥ）からセッション開始プロトコル（ＳＩＰ）ＲＥＧＩＳＴＥＲメッセージを受信することと、
フィルタ判定基準が新しいＳＩＰメッセージの必要性を示すか否かを決定し、前記フィルタ判定基準が、前記新しいＳＩＰメッセージが、前記ＳＩＰ ＲＥＧＩＳＴＥＲメッセージの全体またはＳＩＰ応答メッセージのうちの少なくとも１つを含むことになることを示すか否かをさらに決定することであって、これらの決定は、前記ＳＩＰ ＲＥＧＩＳＴＥＲメッセージの受信に応答する、ことと、
前記新しいＳＩＰメッセージの本体内に多目的インターネットメール拡張（ＭＩＭＥ）本体を含めることであって、前記ＭＩＭＥ本体は、前記ＳＩＰ ＲＥＧＩＳＴＥＲメッセージの全体または前記ＳＩＰ応答メッセージのうちの少なくとも１つを含む、ことと
を含む、方法。
【請求項２】
前記新しいＳＩＰメッセージを前記ＡＳに送信することをさらに含む、請求項１に記載の方法。
【請求項３】
前記受信されたＳＩＰ ＲＥＧＩＳＴＥＲメッセージは、第１のリクエストユニフォームリソース識別子（リクエストＵＲＩ）を含み、前記第１のリクエストＵＲＩは、ＳＩＰ ＲＥＧＩＳＴＥＲアドレスを含み、前記新しいＳＩＰメッセージは、第２のリクエストＵＲＩを含み、前記第２のリクエストＵＲＩは、前記ＡＳのアドレスを含む、請求項２に記載の方法。
【請求項４】
ユーザプロフィールを前記ネットワーク構成要素にダウンロードすることをさらに含む、請求項１に記載の方法。
【請求項５】
前記ユーザプロフィールは、前記フィルタ判定基準を含む、請求項４に記載の方法。
【請求項６】
前記含められたＳＩＰ応答メッセージは、前記ＳＩＰ ＲＥＧＩＳＴＥＲメッセージに応答して前記ＵＥに送信されるＳＩＰ ２００ ＯＫメッセージのコピーである、請求項１に記載の方法。
【請求項７】
ネットワークエンティティの前記リクエストユニフォームリソース識別子（リクエストＵＲＩ）を連絡先ヘッダフィールドとして含めることをさらに含む、請求項１に記載の方法。
【請求項８】
前記新しいＳＩＰメッセージは、登録イベントの結果として伝送された登録イベントパッケージを含むＳＩＰ ＮＯＴＩＦＹメッセージであり、前記新しいＳＩＰメッセージは、前記新しいＳＩＰ ＲＥＧＩＳＴＥＲメッセージの全体を含む、請求項１に記載の方法。
【請求項９】
前記新しいＳＩＰメッセージの”Ｔｏ：”フィールドは、前記ＵＥの識別子を含み、前記新しいＳＩＰメッセージの”Ｆｒｏｍ：”フィールドは、ネットワークエンティティの識別子を含む、請求項１に記載の方法。
【請求項１０】
前記ネットワーク構成要素は、サービングコールセッション制御機能である、請求項１に記載の方法。
【請求項１１】
電気通信ネットワーク内の構成要素であって、
前記構成要素は、プロセッサを含み、
前記プロセッサは、
ユーザ機器（ＵＥ）からセッション開始プロトコル（ＳＩＰ）ＲＥＧＩＳＴＥＲメッセージを受信することと、
フィルタ判定基準が新しいＳＩＰメッセージの必要性を示すか否かを決定し、前記フィルタ判定基準が、前記新しいＳＩＰメッセージが、前記ＳＩＰ ＲＥＧＩＳＴＥＲメッセージの全体またはＳＩＰ応答メッセージのうちの少なくとも１つを含むことになることを示すか否かをさらに決定することであって、これらの決定は、前記ＳＩＰ ＲＥＧＩＳＴＥＲメッセージの受信に応答する、ことと、
前記新しいＳＩＰメッセージの本体内に多目的インターネットメール拡張（ＭＩＭＥ）本体を含めることであって、前記ＭＩＭＥ本体は、前記ＳＩＰ ＲＥＧＩＳＴＥＲメッセージの全体または前記ＳＩＰ応答メッセージのうちの少なくとも１つを含む、ことと
を行うように構成されている、構成要素。
【請求項１２】
前記プロセッサは、前記新しいＳＩＰメッセージをアプリケーションサーバ（ＡＳ）に送信するようにさらに構成されている、請求項１１に記載の構成要素。
【請求項１３】
前記受信されたＳＩＰ ＲＥＧＩＳＴＥＲメッセージは、第１のリクエストユニフォームリソース識別子（リクエストＵＲＩ）を含み、前記第１のリクエストＵＲＩは、ＳＩＰ ＲＥＧＩＳＴＥＲアドレスを含み、前記新しいＳＩＰメッセージは、第２のリクエストＵＲＩを含み、前記第２のリクエストＵＲＩは、前記ＡＳのアドレスを含む、請求項１２に記載の構成要素。
【請求項１４】
前記プロセッサは、ユーザプロフィールを前記ネットワーク構成要素にダウンロードするようにさらに構成されている、請求項１１に記載の構成要素。
【請求項１５】
前記ユーザプロフィールは、前記フィルタ判定基準を含む、請求項１４に記載の構成要素。
【請求項１６】
前記含められたＳＩＰメッセージは、前記ＳＩＰ ＲＥＧＩＳＴＥＲメッセージに応答して前記ＵＥに送信さえるＳＩＰ ２００ ＯＫメッセージのコピーである、請求項１１に記載の構成要素。
【請求項１７】
前記新しいＳＩＰメッセージは、登録イベントの結果として伝送された登録イベントパッケージを含むＳＩＰ ＮＯＴＩＦＹメッセージであり、前記新しいＳＩＰメッセージは、前記ＳＩＰ ＲＥＧＩＳＴＥＲメッセージの全体を含む、請求項１１に記載の構成要素。
【請求項１８】
前記構成要素は、サービングコールセッション制御機能である、請求項１１に記載の構成要素。
【請求項１９】
命令を含むコンピュータ読み取り可能なメモリであって、前記コンピュータ読み取り可能な命令は、プロセッサによって実行されると、アプリケーションサーバ（ＡＳ）に情報を提供する方法を実装するように適合されており、前記方法は、
ユーザ機器（ＵＥ）からセッション開始プロトコル（ＳＩＰ） ＲＥＧＩＳＴＥＲメッセージを受信することと、
フィルタ判定基準が新しいＳＩＰメッセージの必要性を示すか否かを決定し、前記フィルタ判定基準が、前記新しいＳＩＰメッセージが、前記ＳＩＰ ＲＥＧＩＳＴＥＲメッセージの全体またはＳＩＰ応答メッセージのうちの少なくとも１つを含むことになることを示すか否かをさらに決定することであって、これらの決定は、前記ＳＩＰ ＲＥＧＩＳＴＥＲメッセージの受信に応答する、ことと、
前記新しいＳＩＰメッセージの本体内に多目的インターネットメール拡張（ＭＩＭＥ）本体を含めることであって、前記ＭＩＭＥ本体は、前記ＳＩＰ ＲＥＧＩＳＴＥＲメッセージの全体またはＳＩＰ応答メッセージのうちの少なくとも１つを含む、ことと
を含み、
前記受信されたＳＩＰ ＲＥＧＩＳＴＥＲメッセージは、第１のリクエストユニフォームリソース識別子（リクエストＵＲＩ）を含み、前記第１のリクエストＵＲＩは、ＳＩＰ ＲＥＧＩＳＴＥＲアドレスを含み、前記新しいＳＩＰメッセージは、第２のリクエストＵＲＩを含み、前記第２のリクエストＵＲＩは、前記ＡＳのアドレスを含む、コンピュータ読み取り可能なメモリ。
【請求項２０】
前記方法は、ユーザプロフィールをダウンロードすることをさらに含み、前記ユーザプロフィールは、前記フィルタ判定基準を含む、請求項１９に記載のコンピュータ読み取り可能なメモリ。
【図１】
【図２】
【図３】
【図４】
【図２】
【図３】
【図４】
【公開番号】特開２０１３−１０２５３０（Ｐ２０１３−１０２５３０Ａ）
【公開日】平成２５年５月２３日（２０１３．５．２３）
【国際特許分類】
【外国語出願】
【出願番号】特願２０１３−１３９５１（Ｐ２０１３−１３９５１）
【出願日】平成２５年１月２９日（２０１３．１．２９）
【分割の表示】特願２０１０−５４４４８０（Ｐ２０１０−５４４４８０）の分割
【原出願日】平成２１年１月２８日（２００９．１．２８）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＧＳＭ
【出願人】（５０００４３５７４）リサーチ イン モーション リミテッド (531)
【氏名又は名称原語表記】Ｒｅｓｅａｒｃｈ Ｉｎ Ｍｏｔｉｏｎ Ｌｉｍｉｔｅｄ
【住所又は居所原語表記】２９５ Ｐｈｉｌｌｉｐ Ｓｔｒｅｅｔ， Ｗａｔｅｒｌｏｏ， Ｏｎｔａｒｉｏ Ｎ２Ｌ ３Ｗ８ Ｃａｎａｄａ
【Ｆターム（参考）】
【公開日】平成２５年５月２３日（２０１３．５．２３）
【国際特許分類】
【出願番号】特願２０１３−１３９５１（Ｐ２０１３−１３９５１）
【出願日】平成２５年１月２９日（２０１３．１．２９）
【分割の表示】特願２０１０−５４４４８０（Ｐ２０１０−５４４４８０）の分割
【原出願日】平成２１年１月２８日（２００９．１．２８）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＧＳＭ
【出願人】（５０００４３５７４）リサーチ イン モーション リミテッド (531)
【氏名又は名称原語表記】Ｒｅｓｅａｒｃｈ Ｉｎ Ｍｏｔｉｏｎ Ｌｉｍｉｔｅｄ
【住所又は居所原語表記】２９５ Ｐｈｉｌｌｉｐ Ｓｔｒｅｅｔ， Ｗａｔｅｒｌｏｏ， Ｏｎｔａｒｉｏ Ｎ２Ｌ ３Ｗ８ Ｃａｎａｄａ
【Ｆターム（参考）】
[ Back to top ]