(57)【要約】ユーザエージェントの能力を送達するための方法を提供する。方法は、ユーザエージェント（ＵＡ）が、Ｃｏｎｔａｃｔヘッダを含むセッション初期化プロトコル（ＳＩＰ）メッセージを送信することを含み、該Ｃｏｎｔａｃｔヘッダは、少なくとも１つのプッシュリソースを含むプッシュリソース識別子機能タグを含む。上記Ｃｏｎｔａｃｔヘッダはさらに、Ｇｌｏｂａｌｌｙ  Ｒｏｕｔａｂｌｅ  ＵＡ  Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ（ＵＲＩ）（ＧＲＵＵ）を含み得る。
2011527534.tif 000002
【特許請求の範囲】
【請求項１】
ユーザエージェント（ＵＡ）の能力を送達するための方法であって、
ＵＡが、Ｃｏｎｔａｃｔヘッダを含むセッション初期化プロトコル（ＳＩＰ）メッセージを送信することを含み、該Ｃｏｎｔａｃｔヘッダは、少なくとも１つのプッシュリソースを含むプッシュリソース識別子機能タグを含む、方法。
【請求項２】
前記Ｃｏｎｔａｃｔヘッダはさらに、Ｇｌｏｂａｌｌｙ  Ｒｏｕｔａｂｌｅ  ＵＡ  Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ（ＵＲＩ）（ＧＲＵＵ）を含む、請求項１に記載の方法。
【請求項３】
前記ＳＩＰメッセージは、多目的インターネットメール拡張（ＭＩＭＥ）型「ｍｅｓｓａｇｅ／ｅｘｔｅｒｎａｌ−ｂｏｄｙ」を含むヘッダをさらに含む、請求項１に記載の方法。
【請求項４】
前記ヘッダは、前記ＵＡのＯｐｅｎ  Ｍｏｂｉｌｅ  Ａｌｌｉａｎｃｅ（ＯＭＡ）ＵＡプロファイルドキュメントを指し示すＵＲＩをさらに含む、請求項１に記載の方法。
【請求項５】
前記ヘッダは、Ａｃｃｅｐｔヘッダである、請求項３に記載の方法。
【請求項６】
前記ヘッダは、Ａｃｃｅｐｔヘッダである、請求項４に記載の方法。
【請求項７】
前記ヘッダは、Ｃｏｎｔｅｎｔ−Ｔｙｐｅヘッダである、請求項３に記載の方法。
【請求項８】
前記ヘッダは、Ｃｏｎｔｅｎｔ−Ｔｙｐｅヘッダである、請求項４に記載の方法。
【請求項９】
前記ＳＩＰメッセージは、前記ＵＡによってサポートされるＳＩＰ方法を含むＡｌｌｏｗヘッダをさらに含む、請求項１に記載の方法。
【請求項１０】
前記ＳＩＰメッセージは、本文をさらに含む、請求項１に記載の方法。
【請求項１１】
前記ＳＩＰメッセージは、Ｃｏｎｔｅｎｔ−Ｄｉｓｐｏｓｉｔｉｏｎに「ａｔｔａｃｈｍｅｎｔ」をさらに含む、請求項１０に記載の方法。
【請求項１２】
前記ＳＩＰメッセージは、
前記プッシュ受信側エージェントのモデルと、
該プッシュ受信側エージェントの供給元と、
該プッシュ受信側エージェントのバージョンと
のうちの少なくとも１つを含む、Ｕｓｅｒ−Ａｇｅｎｔヘッダをさらに含む、請求項１に記載の方法。
【請求項１３】
前記ＳＩＰメッセージは、ＳＩＰ  ＯＰＴＩＯＮＳ要求である、請求項１に記載の方法。
【請求項１４】
前記ＳＩＰメッセージは、ＳＩＰ  ２００  ＯＫ応答である、請求項１に記載の方法。
【請求項１５】
セッション初期化プロトコル（ＳＩＰ）プッシュ受信側エージェントであって、
該プッシュ受信側エージェントが、少なくとも１つのプッシュリソースを含むプッシュリソース識別子機能タグを含むＣｏｎｔａｃｔヘッダを含むＳＩＰメッセージを送信するように構成される構成要素を備える、プッシュ受信側エージェント。
【請求項１６】
前記Ｃｏｎｔａｃｔヘッダはさらに、Ｇｌｏｂａｌｌｙ  Ｒｏｕｔａｂｌｅ  ＵＡ  Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ（ＵＲＩ）（ＧＲＵＵ）を含む、請求項１５に記載のプッシュ受信側エージェント。
【請求項１７】
前記ＳＩＰメッセージはさらに、多目的インターネットメール拡張（ＭＩＭＥ）型「ｍｅｓｓａｇｅ／ｅｘｔｅｒｎａｌ−ｂｏｄｙ」を含む、ヘッダを含む、請求項１５に記載のプッシュ受信側エージェント。
【請求項１８】
前記ヘッダはさらに、前記プッシュ受信側エージェントのＯｐｅｎ  Ｍｏｂｉｌｅ  Ａｌｌｉａｎｃｅ（ＯＭＡ）ＵＡプロファイルドキュメントを指し示すＵＲＩを含む、請求項１７に記載のプッシュ受信側エージェント。
【請求項１９】
前記ヘッダは、Ａｃｃｅｐｔヘッダである、請求項１７に記載のプッシュ受信側エージェント。
【請求項２０】
前記ヘッダは、Ａｃｃｅｐｔヘッダである、請求項１８に記載のプッシュ受信側エージェント。
【請求項２１】
前記ヘッダは、Ｃｏｎｔｅｎｔ−Ｔｙｐｅヘッダである、請求項１７に記載のプッシュ受信側エージェント。
【請求項２２】
前記ヘッダは、Ｃｏｎｔｅｎｔ−Ｔｙｐｅヘッダである、請求項１８に記載のプッシュ受信側エージェント。
【請求項２３】
前記ＳＩＰメッセージは、前記プッシュ受信型エージェントによってサポートされるＳＩＰ方法を含むＡｌｌｏｗヘッダをさらに含む、請求項１５に記載のプッシュ受信側エージェント。
【請求項２４】
前記ＳＩＰメッセージは、本文をさらに含む、請求項１５に記載のプッシュ受信側エージェント。
【請求項２５】
前記ＳＩＰメッセージは、Ｃｏｎｔｅｎｔ−Ｄｉｓｐｏｓｉｔｉｏｎに「ａｔｔａｃｈｍｅｎｔ」をさらに含む、請求項２４に記載のプッシュ受信側エージェント。
【請求項２６】
前記ＳＩＰメッセージは、
前記プッシュ受信側エージェントのモデルと、
該プッシュ受信側エージェントの供給元と、
該プッシュ受信側エージェントのバージョンと
のうちの少なくとも１つを含む、Ｕｓｅｒ−Ａｇｅｎｔヘッダをさらに含む、請求項１５に記載のプッシュ受信側エージェント。
【請求項２７】
前記ＳＩＰメッセージは、ＳＩＰ  ＯＰＴＩＯＮＳ要求である、請求項１５に記載のプッシュ受信側エージェント。
【請求項２８】
ＳＩＰ  ＯＰＴＩＯＮＳ要求を受信した際に、送信側の能力に関する情報を含む、ＳＩＰ  ２００  ＯＫ応答が送信される、請求項１５に記載のプッシュ受信側エージェント。
【請求項２９】
前記ＳＩＰメッセージは、ＳＩＰ  ２００  ＯＫ応答である、請求項１５に記載のプッシュ受信側エージェント。
【請求項３０】
セッション初期化プロトコル（ＳＩＰ）プッシュ送信側エージェントであって、
該プッシュ送信側エージェントが、少なくとも１つのプッシュリソースを含むプッシュリソース識別子機能タグを含むＣｏｎｔａｃｔヘッダを含むＳＩＰメッセージを受信するように構成される構成要素を備える、プッシュ送信側エージェント。
【請求項３１】
前記Ｃｏｎｔａｃｔヘッダはさらに、Ｇｌｏｂａｌｌｙ  Ｒｏｕｔａｂｌｅ  ＵＡ  Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ（ＵＲＩ）（ＧＲＵＵ）を含む、請求項３０に記載のプッシュ送信側エージェント。
【請求項３２】
前記ＳＩＰメッセージはさらに、多目的インターネットメール拡張（ＭＩＭＥ）型「ｍｅｓｓａｇｅ／ｅｘｔｅｒｎａｌ−ｂｏｄｙ」を含む、ヘッダを含む、請求項３０に記載のプッシュ送信側エージェント。
【請求項３３】
前記ヘッダはさらに、前記メッセージを送信したプッシュ受信側エージェントのＯｐｅｎ  Ｍｏｂｉｌｅ  Ａｌｌｉａｎｃｅ（ＯＭＡ）ＵＡプロファイルドキュメントを指し示すＵＲＩを含む、請求項３２に記載のプッシュ送信側エージェント。
【請求項３４】
前記ヘッダは、Ａｃｃｅｐｔヘッダである、請求項３２に記載のプッシュ送信側エージェント。
【請求項３５】
前記ヘッダは、Ａｃｃｅｐｔヘッダである、請求項３３に記載のプッシュ送信側エージェント。
【請求項３６】
前記ヘッダは、Ｃｏｎｔｅｎｔ−Ｔｙｐｅヘッダである、請求項３２に記載のプッシュ送信側エージェント。
【請求項３７】
前記ヘッダは、Ｃｏｎｔｅｎｔ−Ｔｙｐｅヘッダである、請求項３３に記載のプッシュ送信側エージェント。
【請求項３８】
前記ＳＩＰメッセージは、前記メッセージを送信したプッシュ受信側エージェントによってサポートされるＳＩＰ方法を含むＡｌｌｏｗヘッダをさらに含む、請求項３０に記載のプッシュ送信側エージェント。
【請求項３９】
前記ＳＩＰメッセージは、本文をさらに含む、請求項３０に記載のプッシュ送信側エージェント。
【請求項４０】
前記ＳＩＰメッセージは、Ｃｏｎｔｅｎｔ−Ｄｉｓｐｏｓｉｔｉｏｎに「ａｔｔａｃｈｍｅｎｔ」をさらに含む、請求項３９に記載のプッシュ送信側エージェント。
【請求項４１】
前記ＳＩＰメッセージは、
前記メッセージを送信したプッシュ受信側エージェントのモデルと、
該メッセージを送信した該プッシュ受信側エージェントの供給元と、
該メッセージを送信した該プッシュ受信側エージェントのバージョンと
のうちの少なくとも１つを含むＵｓｅｒ−Ａｇｅｎｔヘッダをさらに含む、請求項３０に記載のプッシュ送信側エージェント。
【請求項４２】
前記ＳＩＰメッセージは、ＳＩＰ  ＯＰＴＩＯＮＳ要求である、請求項３０に記載のプッシュ送信側エージェント。
【請求項４３】
前記ＳＩＰ  ＯＰＴＩＯＮＳ要求を受信した際に、送信側の能力に関する情報を含む、ＳＩＰ  ２００  ＯＫ応答が送信される、請求項４２に記載のプッシュ送信側エージェント。
【請求項４４】
前記ＳＩＰメッセージは、ＳＩＰ  ２００  ＯＫ応答である、請求項３０に記載のプッシュ送信側エージェント。
【発明の詳細な説明】
【背景技術】
【０００１】
ＩＰ（インターネット）マルチメディアサブシステム（ＩＭＳ）は、携帯および固定デバイスの両方にマルチメディアサービスおよびボイスオーバーＩＰ呼出を提供するための標準アーキテクチャである。セッション初期化プロトコル（ＳＩＰ）が、ＩＭＳベースの呼出またはセッションを作成、修正、および終結するための信号伝達プロトコルとして、主にＩｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ  （ＩＥＴＦ）によって標準化され、統括されてきた。本明細書で使用されるように、「ユーザエージェント」および「ＵＡ」という用語は、場合によっては、携帯電話、携帯情報端末、手持ち式またはラップトップコンピュータ、および電気通信能力を有する同様のデバイス等の、携帯デバイスを指す場合がある。そのようなＵＡは、加入者識別モジュール（ＳＩＭ）アプリケーション、汎用加入者識別モジュール（ＵＳＩＭ）アプリケーション、可撤性ユーザ識別モジュール（Ｒ−ＵＩＭ）アプリケーション等であるが、それらに限定されない、デバイスおよびその関連可撤性メモリモジュールから成る場合がある。代替として、そのようなＵＡは、そのようなモジュールを伴わずに、デバイス自他から成ってもよい。他の場合においては、「ＵＡ」という用語は、固定回線電話、デスクトップコンピュータ、セットトップボックス、またはネットワークノード等の、同様の能力を有するが運搬可能ではないデバイスを指す場合がある。ネットワークノードがＵＡの役割を果たすとき、ネットワークノードは、携帯または固定回線デバイス等の別の機能に代わって作用し、デバイスをシミュレートまたはエミュレートすることができる。例えば、いくつかのＵＡについて、典型的にはデバイス上に存在するＩＭＳ  ＳＩＰクライアントは、実際にネットワーク内にも存在することができ、最適化されたプロトコルを使用して、デバイスにＳＩＰメッセージ情報を中継することができる。言い換えれば、伝統的にＵＡによって実行された、いくつかの機能は、遠隔ＵＡの形態で分布することができ、その場合、遠隔ＵＡは、ネットワーク内のＵＡを表す。「ＵＡ」という用語はまた、ＳＩＰセッションを含むが、それに限定されない通信セッションを終結させることができる、任意のハードウェアまたはソフトウェア構成要素も指すことができる。また、「ユーザエージェント」、「ＵＡ」、「ユーザ機器」、「ＵＥ」、および「ノード」という用語は、本明細書では同意語として使用される場合がある。
【発明の概要】
【課題を解決するための手段】
【０００２】
最初に、本開示の１つ以上の実施形態の例証的実装を以下で提供するが、開示されたシステムおよび／または方法は、現在既知であるか、または既存であるかにかかわらず、任意の数の技法を使用して実装されてもよいことを理解されたい。本開示は、本明細書で例証および説明される例示的設計および実装を含む、以下で例証される例証的実装、図面、および技法に決して限定されるべきではないが、同等物の全範囲とともに、添付の請求項の範囲内で修正されてもよい。
【０００３】
通信システムのための技術は、単一の回線またはデバイスのみに一意的にマッピングする単一のアイデンティティ（例えば、電話番号）のみのテレフォニベースの概念から離れつつある。ＳＩＰおよび他のインターネットベースの通信技術は、同じユーザアイデンティティ（公衆ユーザアイデンティティまたはＰＵＩ等）に登録された複数のデバイスを有するという概念をサポートする。各デバイスは、異なるメディア型およびコーデックをサポートする等の、独自の能力を有してもよい。ＳＩＰは、１つのＳＩＰ  ＵＡが問い合せを行い、別のＵＡの能力を通知されるための方法を提供する（例えば、全て同じセッションまたは複数のセッション内で、音声およびビデオとともに、テキストおよび他の種類のメッセージングを含む、種々のメディア型へのサポート）。
【０００４】
これらの能力は、家庭用電話、個人用携帯電話、仕事用電話、別荘用電話、ラップトップコンピュータＶｏＩＰクライアント、ファクス機等に、ユーザが異なるアイデンティティを有する必要性を排除してもよく、その時にユーザがどのデバイスを使用していても、ユーザが連絡可能となることを可能にしてもよい。これはまた、アドレス帳にユーザごとのデバイス指向の連絡先の広範なリストを有し、通信を確立しようとするときに、どのデバイスがユーザに連絡するのに最善であるか決定しなければならないという問題を解決することもできる。
【０００５】
しばしば、ＩＰおよびＳＩＰベースの通信では、ネットワークベースのサーバがＵＡ（しばしば、クライアントと称される）にサービスおよびコンテンツを提供する。Ｏｐｅｎ  Ｍｏｂｉｌｅ  Ａｌｌｉａｎｃｅ（ＯＭＡ）ＳＩＰプッシュイネーブラは、ＳＩＰクライアントがＳＩＰプッシュ送信エージェントからの最初にコンテンツを要求する必要なく、プッシュ送信側エージェントとして知られているネットワークベースのサーバが、プッシュ受信側エージェントとして知られているＳＩＰプッシュクライアントにコンテンツを直接送達する効率的な方法を提供する、システムの実施例である。
【０００６】
ＳＩＰネットワークベースのサーバが使用されるときは、ＳＩＰプッシュ受信側エージェント等のＵＡが、ＳＩＰプッシュ送信側エージェント等のサーバによってサポートされる能力を取得することが必要であってもよい。問い合せを行い、サーバの能力を取得するために、Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ  （ＩＥＴＦ）  Ｒｅｑｕｅｓｔ  ｆｏｒ  Ｃｏｍｍｅｎｔｓ  （ＲＦＣ）  ３２６１で定義されるようなＳＩＰ  ＯＰＴＩＯＮＳ方法を使用することができる。
【０００７】
同様に、ＳＩＰプッシュ送信側エージェント等のＳＩＰネットワークベースのサーバは、ＳＩＰプッシュ受信側エージェント等のＵＡによってサポートされる能力を取得する必要があってもよい。再度、問い合せを行い、ＵＡの能力を取得するために、ＳＩＰ  ＯＰＴＩＯＮＳ方法を使用することができる。ＳＩＰ  ＯＰＴＩＯＮＳ要求へのＳＩＰ  ２００  ＯＫ応答は、ＵＡの能力に関する情報を含む、本文を含むことができる。この情報は、ＳＩＰ  ＯＰＴＩＯＮＳ要求へのＳＩＰ  ２００  ＯＫ応答のＳＩＰヘッダの中で輸送される、ＩＥＴＦ  ＲＦＣ  ３２６１で特定された能力情報に加えたものであってもよい。この本文は、ＯＭＡ  ＵＡプロファイルドキュメント等の能力情報、またはＯＭＡ  ＵＡプロファイルドキュメント等の能力情報を含むドキュメントを指し示す、Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ（ＵＲＩ）あるいは同様の識別子を含むことができる。
【０００８】
ＵＡが利用可能ではない場合があるため（例えば、電源オフおよび電源オンにより、または無線デバイスの場合は無線受信地域の損失および再獲得により）、ＵＡは、システムに登録する必要があってもよい。サーバは、ＵＡが利用可能になっていることを発見しなければならない場合があり、１つ以上の機構を通して、そうしてもよい。１つの機構では、サーバは、ＵＡからＳＩＰ  ＯＰＴＩＯＮＳ要求を受信することによって、ＵＡが利用可能であるかどうかを判定することができる。別の機構では、サーバは、登録イベントパッケージに加入し、ＵＡが登録したことを示す、ＩＥＴＦ  ＲＦＣ  ３６８０で定義されるような通知（ＳＩＰ  ＮＯＴＩＦＹ要求）を受信することができる。別の機構では、サーバは、ＵＡが登録したことを示す、３ｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ  （３ＧＰＰ）  Ｔｅｃｈｎｉｃａｌ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ  （ＴＳ）  ２３．２１８および３ＧＰＰ  ＴＳ  ２４．２２９で定義されるような、第３者登録として知られているＳＩＰ  ＲＥＧＩＳＴＥＲ要求を受信することができる。
【０００９】
いったんＵＡが登録したことをサーバが検出すると、サーバは、ＳＩＰ  ＯＰＴＩＯＮＳ要求を使用して、ＵＡにその能力について問い合せを行う場合がある。ＯＭＡ  ＳＩＰプッシュイネーブラの場合、サーバは、ＵＡ用のＯＭＡ  ＵＡプロファイルドキュメントを取得してもよい。しかしながら、ＳＩＰ  ＯＰＴＩＯＮＳ要求は通常、ユーザの登録された記録のアドレス（ＡｏＲ）またはＰＵＩにアドレス指定されるため、同じユーザに登録された複数のＵＡがあれば、問題が存在する場合がある。そのような場合、登録されたＵＡのうちのどれがサーバからＳＩＰ  ＯＰＴＩＯＮＳ要求を受信し、その能力を返信するかを判定することが可能ではない場合がある。
【００１０】
ＩＥＴＦ  ＲＦＣ  ３２６１によれば、ＳＩＰ  ＯＰＴＩＯＮＳ要求が分岐されないため、サーバは、発見されたサーバが登録したＵＡにＳＩＰ  ＯＰＴＩＯＮＳ要求がルート指定されることを確実にする必要があってもよい。ＳＩＰ  ＯＰＴＩＯＮＳ要求はダイアログを確立しないため、たとえＵＡからのＳＩＰ  ＯＰＴＩＯＮＳ要求の受信を通してＵＡが利用可能であるとサーバが判定しても、サーバは、ＳＩＰダイアログを使用してＳＩＰ  ＯＰＴＩＯＮＳ要求を返信することが可能ではない場合がある。ＳＩＰダイアログを使用してＳＩＰ  ＯＰＴＩＯＮＳ要求を返信することにより、ＳＩＰ  ＯＰＴＩＯＮＳ要求が、元のＳＩＰ  ＯＰＴＩＯＮＳ要求を送信したＵＡに到達したことを確実にすることができる。したがって、ＳＩＰプッシュ送信側エージェントが、同じユーザによって使用される複数のＵＡと関連するＰＵＩまたはＡｏＲを使用して、ＳＩＰプッシュクライアント（プッシュ受信側エージェント）にＳＩＰ  ＯＰＴＩＯＮＳ要求を送信するとき、ＵＡのうちのどれに要求が送信されるかが明確ではない場合がある。
【００１１】
実施形態では、プッシュ送信側エージェント等のサーバは、プッシュ受信側エージェント等のＵＡにＳＩＰ  ＯＰＴＩＯＮＳ要求をアドレス指定するために、ＧＲＵＵ（Ｇｌｏｂａｌｌｙ  Ｒｏｕｔａｂｌｅ  ＵＡ  ＵＲＩ）を使用する。ＧＲＵＵは、ＵＡおよびその関連ＰＵＩまたはＡｏＲの両方を識別するＵＲＩである。ＧＲＵＵは、ＩＥＴＦドキュメント［ｄｒａｆｔ−ｉｅｔｆ−ｓｉｐ−ｇｒｕｕ］で特定されるように、登録過程中にＵＡによって取得することができる。ＳＩＰ  ＯＰＴＩＯＮＳ要求を正しいＵＡに送信するために、プッシュ送信側エージェント等のサーバは、それが発見したＵＡのＧＲＵＵが登録したことを取得する必要があってもよい。
【００１２】
実施形態では、ＳＩＰ  ＯＰＴＩＯＮＳ方法を介したもの、ＩＥＴＦ  ＲＦＣ  ３６８０で説明されている登録イベントパッケージおよびＩＥＴＦドキュメント［ｄｒａｆｔ−ｉｅｔｆ−ｓｉｐｐｉｎｇ−ｇｒｕｕ−ｒｅｇ−ｅｖｅｎｔｓ］で定義されている拡張を使用して、ＩＥＴＦ  ＲＦＣ  ３２６５で説明されているＳＩＰ  ＳＵＢＳＣＲＩＢＥ／ＮＯＴＩＦＹ機構を介したもの、または元のＳＩＰ  ＲＥＧＩＳＴＥＲ要求の内容を含む本文を含む、第３者登録機構を使用するものといった、ＳＩＰプッシュ送信側エージェントが公衆ＧＲＵＵを発見するための３つの方法があってもよい。これらの機構のそれぞれを、以下で詳細に説明する。ＳＩＰプッシュ送信側エージェントがＳＩＰプッシュ受信側エージェントの公衆ＧＲＵＵ値を判定すると、ＳＩＰプッシュ送信側エージェントは、ＳＩＰプッシュ受信側エージェントの公衆ＧＲＵＵを含むＲｅｑｕｅｓｔ−ＵＲＩ部分とともに、ＳＩＰ  ＯＰＴＩＯＮＳ要求を送信する。この要求を受信すると、ＳＩＰプッシュ受信側エージェントは、ＳＩＰ  ２００  ＯＫメッセージの本文に、そのＵＡＰｒｏｆｉｌｅのＵＲＩを含む（または代替として、本文に直接、ＵＡＰｒｏｆｉｌｅドキュメントを含む）。次いで、ＳＩＰプッシュ受信側エージェントは、ＳＩＰ  ２００  ＯＫをＳＩＰプッシュ送信側エージェントに送信し、したがって、その能力をＳＩＰプッシュ送信側エージェントに提供する。
【００１３】
実施形態では、ＵＡ（またはプッシュ受信側エージェント）が、サーバ（またはプッシュ送信側エージェント）に、プッシュ受信側エージェントのＧＲＵＵを含むＳＩＰ  ＯＰＴＩＯＮＳ要求を送信する。ＧＲＵＵは、ＳＩＰ  ＯＰＴＩＯＮＳ要求のＣｏｎｔａｃｔヘッダに含まれる場合がある。次いで、プッシュ送信側エージェントは、プッシュ受信側エージェントに、プッシュ送信側エージェントの能力に関する情報を含む２００  ＯＫメッセージを送信する。次いで、プッシュ送信側エージェントは、以前のＳＩＰ  ＯＰＴＩＯＮＳ要求の中でプッシュ受信側エージェントが提供したＧＲＵＵにＳＩＰ  ＯＰＴＩＯＮＳ要求を送信することによって、プッシュ受信側エージェントの能力を要求する。次いで、プッシュ受信側エージェントは、プッシュ受信側エージェントの能力に関する情報を含む２００  ＯＫメッセージを返信する。場合によっては、２００  ＯＫメッセージは、プッシュ受信側エージェントのＯＭＡ  ＵＡプロファイルドキュメント等のプッシュ受信側エージェントの能力情報を含み、他の場合においては、２００  ＯＫメッセージは、プッシュ受信側エージェントのＯＭＡ  ＵＡプロファイルドキュメント等のプッシュ受信側エージェントの能力情報を指し示すＵＲＩを含む。
【００１４】
代替として、プッシュ送信側エージェントは、プッシュ受信側エージェントからのＳＩＰ  ＯＰＴＩＯＮＳ要求への２００  ＯＫ応答に、その能力を含む場合があるが、プッシュ受信側エージェントの能力を要求するためにＳＩＰ  ＯＰＴＩＯＮＳ要求をプッシュ受信側エージェントのＧＲＵＵに送信しない場合がある。
【図面の簡単な説明】
【００１５】
ここで、本開示のより完全な理解のために、添付の図面および発明を実施するための形態と関連して、以下の簡単な説明を参照し、類似参照数字は、類似部品を表す。
【図１】図１は、本開示の実施形態による、メッセージフロー図である。
【図２】図２は、本開示の実施形態による、別のメッセージフロー図である。
【図３】図３は、本開示のいくつかの実施形態を実装するために好適なプロセッサおよび関連構成要素を図示する。
【発明を実施するための形態】
【００１６】
これらの実施形態の下で、プッシュ受信側エージェントおよびプッシュ送信側エージェントにおいて使用されてもよい手順の実施例を、以下に提供する。
【００１７】
（プッシュ受信側エージェントにおける手順）
［ＦＣ  ３２６１］に従ってＳＩＰ  ＯＰＴＩＯＮＳ要求を生成するとき、プッシュ受信側エージェントは、
１．ＳＩＰ  ＯＰＴＩＯＮＳ要求を生成するものとする。
２．ＳＩＰ  ＯＰＴＩＯＮＳ要求のＲｅｑｕｅｓｔ−ＵＲＩをプッシュ送信側エージェントのＵＲＩに設定するものとする。
３．［ＲＦＣ  ３３２５］の規則および手順に従って、Ｐ−Ｐｒｅｆｅｒｒｅｄ−Ｉｄｅｎｔｉｔｙヘッダにプッシュ受信側エージェントのＵＲＩを挿入してもよい。
４．［ｄｒａｆｔ−ｉｅｔｆ−ｓｉｐ−ｇｒｕｕ］の規則および手順に従って、登録中にプッシュ受信側エージェントが公衆ＧＲＵＵを取得した場合、Ｃｏｎｔａｃｔヘッダに公衆ＧＲＵＵを含むものとする。
５．９．１項で定義されるように、Ｃｏｎｔａｃｔヘッダに、プッシュ受信側エージェントによってサポートされる全てのプッシュリソースの値を含むプッシュリソース識別子機能タグを含むものとする。
６．［ｄｒａｆｔ−ｉｅｔｆ−ｓｉｐ−ｇｒｕｕ］の規則および手順に従って、登録中にプッシュ受信側エージェントが公衆ＧＲＵＵを取得した場合、サポート済みヘッダにｇｒｕｕを挿入するものとする。
７．［ＲＦＣ  ４４８３］で特定されるように、ＭＩＭＥ型、ｍｅｓｓａｇｅ／ｅｘｔｅｒｎａｌ−ｂｏｄｙ、およびａｐｐｌｉｃａｔｉｏｎ／ｏｍａ＿ＰｕｓｈＯｐｔｉｏｎｓを含むＡｃｃｅｐｔヘッダを含むものとする。
８．Ａｌｌｏｗヘッダに、プッシュ受信側エージェントがサポートする全てのＳＩＰ方法を含むものとする。
９．プッシュ受信側エージェントのモデル、供給元、およびバージョンを含む、Ｕｓｅｒ−Ａｇｅｎｔヘッダを含むものとする。
１０．ＳＩＰ／ＩＰコアの手順に従って、ＳＩＰ／ＩＰコアに向かってＳＩＰ  ＯＰＴＩＯＮＳ要求を送信するものとする。
ＳＩＰ  ＯＰＴＩＯＮＳ要求へのＳＩＰ  ２００「ＯＫ」応答を受信すると、プッシュ受信側エージェントは、
１．［ＲＦＣ３８４０］に従ってＣｏｎｔａｃｔヘッダに含まれるプッシュ送信側エージェントのプッシュ能力を、プッシュアプリケーションに提供するものとする。
２．Ａｌｌｏｗヘッダに含まれる、プッシュ送信側エージェントによってサポートされるＳＩＰ方法を、プッシュアプリケーションに提供するものとする。
３．ＳＩＰ  ２００「ＯＫ」応答が本文を含む場合、本文を取り出し、Ｃｏｎｔｅｎｔ−Ｄｉｓｐｏｓｉｔｉｏｎに従って処理するものとする。
【００１８】
ＭＩＭＥ型、ｍｅｓｓａｇｅ／ｅｘｔｅｒｎａｌ−ｂｏｄｙ、およびａｐｐｌｉｃａｔｉｏｎ／Ｄｅｖ−ｃａｐを含むＡｃｃｅｐｔヘッダを含む、ＳＩＰ  ＯＰＴＩＯＮＳ要求を受信すると、プッシュ受信側エージェントは、
１．Ｐ−Ａｓｓｅｒｔｅｄ−Ｉｄｅｎｔｉｔｙヘッダが存在し、Ｐ−Ａｓｓｅｒｔｅｄ−Ｉｄｅｎｔｉｔｙヘッダの中のＵＲＩが信頼されることを検証するものとする。認証チェックが失敗した場合、プッシュ受信側エージェントは、ＳＩＰ  ４０３「Ｆｏｒｂｉｄｄｅｎ」応答を返信するものとする。
２．［ＲＦＣ３２６１］に従ってＳＩＰ  ２００「ＯＫ」応答を生成するものとする。
３．［ｄｒａｆｔ−ｉｅｔｆ−ｓｉｐ−ｇｒｕｕ］の規則および手順に従って、登録中にプッシュ受信側エージェントが公衆ＧＲＵＵを取得した場合、Ｃｏｎｔａｃｔヘッダに公衆ＧＲＵＵを含むものとする。
４．Ａｌｌｏｗヘッダに、プッシュ受信側エージェントがサポートする全てのＳＩＰ方法を含むものとする。
５．［ｄｒａｆｔ−ｉｅｔｆ−ｓｉｐ−ｇｒｕｕ］の規則および手順に従って、登録中にプッシュ受信側エージェントが公衆ＧＲＵＵを取得した場合、サポート済みヘッダにｇｒｕｕを挿入するものとする。
６．Ｃｏｎｔａｃｔヘッダに、プッシュ受信側エージェントによってサポートされる全てのプッシュリソースの値を含むプッシュリソース識別子機能タグを含むものとする。
７．プッシュ受信側エージェントのモデル、供給元、およびバージョンを含む、Ｕｓｅｒ−Ａｇｅｎｔヘッダを含むものとする。
８．［ＲＦＣ  ４４８３］の規則および手順に従って、以下を含むＣｏｎｔｅｎｔ−Ｔｙｐｅヘッダを含むものとする。
ａ．ＭＩＭＥ型ｍｅｓｓａｇｅ／ｅｘｔｅｒｎａｌ−ｂｏｄｙ、
ｂ．ＡＣＣＥＳＳＪΥＰＥパラメータにおける「ＵＲＬ」、
ｃ．ＵＲＬパラメータにおける［ＯＭＡ＿ＵＡＰｒｏｆ］ドキュメントのＨＴＴＰ  ＵＲＬ。
９．［ＲＦＣ  ４４８３］の規則および手順に従って、以下を含む本文を含むものとする。
ａ．Ｃｏｎｔｅｎｔ−Ｔｙｐｅにおけるａｐｐｌｉｃａｔｉｏｎ／Ｄｅｖ−ｃａｐ、
ｂ．Ｃｏｎｔｅｎｔ−Ｄｉｓｐｏｓｉｔｉｏｎにおける「ａｔｔａｃｈｍｅｎｔ」、
ｃ．［ＲＦＣ  ４４８３］の規則および手順に従ったコンテンツＩＤ。
１０．ＳＩＰ／ＩＰコアの手順に従って、ＳＩＰ／ＩＰコアに向かってＳＩＰ  ２００「ＯＫ」応答を送信するものとする。
【００１９】
（プッシュ送信側エージェントにおける手順）
ＳＩＰ  ＯＰＴＩＯＮＳ要求を受信すると、プッシュ送信側エージェントは、
１．Ｐ−Ａｓｓｅｒｔｅｄ−ｉｄｅｎｔｉｔｙヘッダが存在し、Ｐ−Ａｓｓｅｒｔｅｄ−ｉｄｅｎｔｉｔｙヘッダの中のＵＲＩが信頼されることを検証するものとする。認証チェックが失敗した場合、プッシュ送信側エージェントは、ＳＩＰ  ４０３「Ｆｏｒｂｉｄｄｅｎ」応答を返信するものとする。
２．［ＲＦＣ３２６１］に従って、ＳＩＰ  ２００「ＯＫ」応答を生成するものとする。
３．Ｃｏｎｔａｃｔヘッダに、受理されたプッシュリソース値を含むプッシュリソース識別子機能タグを含む。
４．Ａｌｌｏｗヘッダに、プッシュ送信側エージェントがサポートする全てのＳＩＰ方法を含むものとする。
５．ＳＩＰ／ＩＰコアの手順に従って、ＳＩＰ／ＩＰコアに向かってＳＩＰ  ２００「ＯＫ」応答を送信するものとする。
【００２０】
プッシュ送信側エージェントは、プッシュ受信側エージェントおよびプッシュ送信側エージェントの能力について問い合せを行うものとする。
１．［ＲＦＣ  ３２６１］に従ってＳＩＰ  ＯＰＴＩＯＮＳ  要求を生成するものとする。
２．ＳＩＰ  ＯＰＴＩＯＮＳ要求のＲｅｑｕｅｓｔ−ＵＲＩを、受信したＳＩＰ  ＯＰＴＩＯＮＳ要求の中のＰ−Ａｓｓｅｒｔｅｄ−ｉｄｅｎｔｉｔｙからのプッシュ受信側エージェントの公衆ユーザアイデンティティに設定し、または公衆ＧＲＵＵが受信したＳＩＰ  ＯＰＴＩＯＮＳ要求の中のＣｏｎｔａｃｔヘッダの中で受信された場合は、公衆ＧＲＵＵに設定するものとする。
３．［ＲＦＣ  ３３２５］の規則および手順に従って、Ｐ−Ａｓｓｅｒｔｅｄ−Ｉｄｅｎｔｉｔｙヘッダにプッシュ送信側エージェントのＵＲＩを挿入してもよい。
４．９．１項で定義されるように、Ｃｏｎｔａｃｔヘッダに、受理可能なプッシュリソース値を含むプッシュリソース識別子機能タグを含むものとする。
５．［ＲＦＣ  ４４８３］で特定されるように、ＭＩＭＥ型、ｍｅｓｓａｇｅ／ｅｘｔｅｒｎａｌ−ｂｏｄｙ、およびａｐｐｌｉｃａｔｉｏｎ／Ｄｅｖ−ｃａｐを含むＡｃｃｅｐｔヘッダを含むものとする。
６．Ａｌｌｏｗヘッダに、プッシュ送信側エージェントがサポートする全てのＳＩＰ方法を含むものとする。
７．ＳＩＰ／ＩＰコアの手順に従って、ＳＩＰ／ＩＰコアに向かってＳＩＰ  ＯＰＴＩＯＮＳ要求を送信するものとする。
【００２１】
ＳＩＰ  ＯＰＴＩＯＮＳ要求へのＳＩＰ  ２００「ＯＫ」応答を受信すると、プッシュ送信側エージェントは、
１．ＳＩＰ  ２００「ＯＫ」が、ａｐｐｌｉｃａｔｉｏｎ／Ｄｅｖ−ｃａｐのＣｏｎｔｅｎｔ−Ｔｙｐｅおよび特定ドキュメントのＨＴＴＰ  ＵＲＬを含む本文を含む場合、デバイスの能力を取得するように、［ＲＦＣ  ４４８３］の規則および手順に従って、ＵＲＬを記憶し、関連ドキュメントを取り出すものとする。
【００２２】
図１は、この実施形態による、ＳＩＰプッシュ受信側エージェント１０と、ＳＩＰ／ＩＰコア２０と、ＳＩＰプッシュ送信側エージェント３０との間のメッセージフロー例を描写する。イベント１１０において、ＳＩＰプッシュ受信側エージェントは、プッシュ受信側エージェントによってサポートされるプッシュリソースの値を含むプッシュリソース識別子機能タグ（＋ｇ．ｏｍａ．ｐｕｓｈｅｖｅｎｔａｐｐ）とともに、登録過程中に取得した、その公衆ＧＲＵＵ値をＣｏｎｔａｃｔヘッダに含むＳＩＰ  ＯＰＴＩＯＮＳ要求を、ＳＩＰ／ＩＰコアに送信する。以下は、このＳＩＰ  ＯＰＴＩＯＮＳ要求の実施形態である。
ＯＰＴＩＯＮＳ  ｓｉｐ：ｐｕｓｈｓｅｒｖｅｒ＠ｎｅｔｗｏｒｋ．ｎｅｔ  ＳＩＰ／２．０
Ｖｉａ：ＳＩＰ／２．０／ＵＤＰ  ｐｃ３３．ａｔｌａｎｔａ．ｃｏｍ；ｂｒａｎｃｈ＝ｚ９ｈＧ４ｂＫｈｊｈｓ８ａｓｓ８７７
Ｍａｘ−Ｆｏｒｗａｒｄｓ：７０
Ｔｏ：＜ｓｉｐ：ｐｕｓｈｓｅｒｖｅｒ＠ｎｅｔｗｏｒｋ．ｎｅｔ＞
Ｆｒｏｍ：Ａｌｉｃｅ  ＜ｓｉｐ：ａｌｉｃｅ＠ａｔｌａｎｔａ．ｃｏｍ＞；ｔａｇ＝１９２８３０１７７４
Ｐ−Ｐｒｅｆｅｒｒｅｄ−ｉｄｅｎｔｉｔｙ：“Ａｌｉｃｅ”  ＜ｓｉｐ：ａｌｉｃｅ＠ａｔｌａｎｔａ．ｃｏｍ＞；
Ｃａｌｌ−ＩＤ：ａ８４ｂ４ｃ７６ｅ６６７１０
ＣＳｅｑ：６３１０４  ＯＰＴＩＯＮＳ
Ｓｕｐｐｏｒｔｅｄ：ｇｒｕｕ
Ｃｏｎｔａｃｔ：＜ｓｉｐ：ａｌｉｃｅ＠ａｔｌａｎｔａ．ｃｏｍ＞；ｇｒ＝ｕｒｎ：ｕｕｉｄ：ｆ８１ｄ４ｆａｅ−７ｄｅｃ−１１ｄ０−ａ７６５−００ａ０ｃ９１ｅ６ｂｆ６；＋ｇ．ｏｍａ．ｐｕｓｈｅｖｅｎｔａｐｐ＝“ｍｍｓ”
Ａｌｌｏｗ：ＩＮＶＩＴＥ，  ＡＣＫ，  ＣＡＮＣＥＬ，  ＯＰＴＩＯＮＳ，  ＢＹＥ，  ＭＥＳＳＡＧＥ
Ｕｓｅｒ−Ａｇｅｎｔ：ｖｅｎｄｏｒ＝“ｖｅｎｄｏｒ．ｅｘａｍｐｌｅ．ｎｅｔ”；ｍｏｄｅｌ＝“Ｚ−ｐｈｏｎｅ”；ｖｅｒｓｉｏｎ＝“１．２．３”
Ａｃｃｅｐｔ：ｍｅｓｓａｇｅ／ｅｘｔｅｍａｌ−ｂｏｄｙ，ａｐｐｌｉｃａｔｉｏｎ／ｏｍａ＿ＰｕｓｈＯｐｔｉｏｎｓ
Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ：０
このＳＩＰ  ＯＰＴＩＯＮＳ要求のＣｏｎｔａｃｔヘッダ部分は、要求を送信したプッシュ受信側エージェントのＧＲＵＵ（「ｇｒ」パラメータによって示される）を含むことが分かる。イベント１２０において、ＳＩＰ／ＩＰコアは、ＳＩＰ  ＯＰＴＩＯＮＳ要求をＳＩＰプッシュ送信側エージェントに転送する。
【００２３】
イベント１３０では、ＳＩＰプッシュ送信側エージェントは、ＳＩＰプッシュ送信側エージェントの能力に関する情報を含むＳＩＰ  ２００  ＯＫを送信する。ＳＩＰ  ２００  ＯＫはまた、追加プッシュオプション、および／またはそこから追加プッシュオプションが取得される場合があるＵＲＩを含む、本文を含みてもよい。以下は、このＳＩＰ  ２００  ＯＫ応答の実施形態である。
ＳＩＰ／２．０  ２００  ＯＫ
Ｖｉａ：ＳＩＰ／２．０／ＵＤＰ  ｐｃ３３．ａｔｌａｎｔａ．ｃｏｍ；ｂｒａｎｃｈ＝ｚ９ｈＧ４ｂＫｈｊｈｓ８ａｓｓ８７７；ｒｅｃｅｉｖｅｄ＝１９２．０．２．４
Ｔｏ：＜ｓｉｐ：ｐｕｓｈｓｅｒｖｅｒ＠ｎｅｔｗｏｒｋ．ｃｏｍ＞；ｔａｇ＝９３８１０８７４
Ｆｒｏｍ：Ａｌｉｃｅ  ＜ｓｉｐ：ａｌｉｃｅ＠ａｔｌａｎｔａ．ｃｏｍ＞；ｔａｇ＝１９２８３０１７７４
Ｃａｌｌ−ＩＤ：ａ８４ｂ４ｃ７６ｅ６６７１０
ＣＳｅｑ：６３１０４  ＯＰＴＩＯＮＳ
Ｃｏｎｔａｃｔ：＜ｓｉｐ：ｐｕｓｈｓｅｒｖｅｒ＠ｎｅｔｗｏｒｋ．ｃｏｍ＞；＋ｇ．ｏｍａ．ｐｕｓｈｅｖｅｎｔａｐｐ＝“ｍｍｓ”
Ａｌｌｏｗ：ＩＮＶＩＴＥ，  ＡＣＫ，  ＣＡＮＣＥＬ，  ＯＰＴＩＯＮＳ，  ＢＹＥ，  ＭＥＳＳＡＧＥ
Ｓｕｐｐｏｒｔｅｄ：ｇｒｕｕ
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ：ｍｅｓｓａｇｅ／ｅｘｔｅｒｎａｌ−ｂｏｄｙ；
ＡＣＣＥＳＳ−ＴＹＰＥ＝ＵＲＬ；
ＵＲＬ＝“ｈｔｔｐ：／／ｗｗｗ．ｅｘａｍｐｌｅ．ｎｅｔ／ＰｕｓｈＯｐｔｉｏｎｓＳｕｐｐｏｒｔｅｄ”；
ＥＸＰＩＲＡＴＩＯＮ＝“  Ｍｏｎ  ２３  Ｊｕｎ  ２００８  １２：００：００  ＧＷＩＴ”；
ｓｉｚｅ＝２３１
Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ：１０５
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ：ｔｅｘｔ／ｈｔｍｌ
Ｃｏｎｔｅｎｔ−Ｄｉｓｐｏｓｉｔｉｏｎ：ａｔｔａｃｈｍｅｎｔ
Ｃｏｎｔｅｎｔ−ＩＤ：ａ４ｅ５５２４７１２７８２７ｄ＠ｅｘａｍｐｌｅ．ｎｅｔ
イベント１４０では、ＳＩＰ／ＩＰコアは、ＳＩＰ  ２００  ＯＫをＳＩＰプッシュ受信側エージェントに転送する。イベント１５０では、ＳＩＰプッシュ送信側エージェントは、ＳＩＰプッシュ受信側エージェントが以前のＳＩＰ  ＯＰＴＩＯＮＳ要求の中で提供したＳＩＰプッシュ受信側エージェントの公衆ＧＲＵＵを含むＳＩＰ  ＯＰＴＩＯＮＳ要求を、ＳＩＰ／ＩＰに送信する。つまり、プッシュ送信側エージェントは、特定されたＧＲＵＵを有するプッシュ受信側エージェントの能力を要求する。以下は、このＳＩＰ  ＯＰＴＩＯＮＳ要求の実施形態である。
ＯＰＴＩＯＮＳ  ｓｉｐ：ａｌｉｃｅ＠ａｔｌａｎｔａ．ｃｏｍ；ｇｒ＝ｕｒｎ：ｕｕｉｄ：ｆ８１ｄ４ｆａｅ−７ｄｅｃ−１１ｄ０−ａ７６５−００ａ０ｃ９１ｅ６ｂｆ６  ＳＩＰ／２．０
Ｖｉａ：ＳＩＰ／２．０／ＵＤＰ  ｐｃ３３．ａｔｌａｎｔａ．ｃｏｍ；ｂｒａｎｃｈ＝ｚ９ｈＧ４ｂＫｈｊｈｓ８ａｓｓ８７７
Ｍａｘ−Ｆｏｒｗａｒｄｓ：７０
Ｔｏ：＜ｓｉｐ：ａｌｉｃｅ＠ａｔｌａｎｔａ．ｃｏｍ＞
Ｆｒｏｍ：＜ｓｉｐ：ｐｕｓｈｓｅｒｖｅｒ＠ｎｅｔｗｏｒｋ．ｃｏｍ＞；ｔａｇ＝１９２８３０１７７９
Ｐ−Ａｓｓｅｒｔｅｄ−ｉｄｅｎｔｉｔｙ：＜ｓｉｐ：ｐｕｓｈｓｅｒｖｅｒ＠ｎｅｔｗｏｒｋ．ｃｏｍ＞
Ｃａｌｌ−ＩＤ：ａ８４ｂ４ｃ７６ｅ６６７１９
ＣＳｅｑ：６３１０４  ＯＰＴＩＯＮＳ
Ｃｏｎｔａｃｔ：＜ｓｉｐ：ｐｕｓｈｓｅｒｖｅｒ＠ｎｅｔｗｏｒｋ．ｃｏｍ＞，＋ｇ．ｏｍａ．ｐｕｓｈｅｖｅｎｔａｐｐ＝“ｍｍｓ”
Ａｌｌｏｗ：ＩＮＶＩＴＥ，  ＡＣＫ，  ＣＡＮＣＥＬ，  ＯＰＴＩＯＮＳ，  ＢＹＥ，  ＭＥＳＳＡＧＥ
Ｓｕｐｐｏｒｔｅｄ：ｇｒｕｕ
Ａｃｃｅｐｔ：ｍｅｓｓａｇｅ／ｅｘｔｅｒｎａｌ−ｂｏｄｙ．ａｐｐｌｉｃａｔｉｏｎ／Ｄｅｖ−ｃａｐ
Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ：０
ＳＩＰプッシュ受信側エージェントのＧＲＵＵは、このＳＩＰ  ＯＰＴＩＯＮＳ要求のＲｅｑｕｅｓｔ−ＵＲＩ部分に含まれることが分かる。イベント１６０では、ＳＩＰ／ＩＰコアは、ＳＩＰ  ＯＰＴＩＯＮＳ要求をＳＩＰプッシュ受信側エージェントに転送する。イベント１７０では、ＳＩＰプッシュ受信側エージェントは、ＳＩＰ／ＩＰコアに、ＳＩＰプッシュ受信側エージェントの能力に関する情報を含むＳＩＰ  ２００  ＯＫ応答を送信する。ＳＩＰ  ２００  ＯＫ応答はまた、追加プッシュオプション、またはそこから追加プッシュオプションを取得することができるＵＲＩを含む、本文を含みてもよい。以下は、このＳＩＰ  ２００  ＯＫ応答の実施形態である。
ＳＩＰ／２．０２００  ＯＫ
Ｖｉａ：ＳＩＰ／２．０／ＵＤＰ  ｐｃ３３．ａｔｌａｎｔａ．ｃｏｍ；ｂｒａｎｃｈ＝ｚ９ｈＧ４ｂＫｈｊｈｓ８ａｓｓ８７７；ｒｅｃｅｉｖｅｄ＝１９２．０．２．４
Ｔｏ：＜ｓｉｐ：ａｌｉｃｅ＠ａｔｌａｎｔａ．ｃｏｍ＞；ｔａｇ＝９３８１０８７９
Ｆｒｏｍ：＜ｓｉρ：ｐｕｓｈｓｅｒｖｅｒ＠ｎｅｔｗｏｒｋ．ｃｏｍ＞；ｔａｇ＝１９２８３０１７７９
Ｃａｌｌ−ＩＤ：ａ８４ｂ４ｃ７６ｅ６６７１９
ＣＳｅｑ：６３１０４  ＯＰＴＩＯＮＳ
Ｓｕｐｐｏｒｔｅｄ：ｇｒｕｕ
Ｃｏｎｔａｃｔ：＜ｓｉｐ：ａｌｉｃｅ＠ａｔｌａｎｔａ．ｃｏｍ＞；ｇｒ＝ｕｒｎ：ｕｕｉｄ：ｆ８１ｄ４ｆａｅ−７ｄｅｃ−１１ｄＯ−
ａ７６５−００ａ０ｃ９１ｅ６ｂｆ２；＋ｇ．ｏｍａ．ｐｕｓｈｅｖｅｎｔａｐｐ＝“ｍｍｓ”
Ａｌｌｏｗ：ＩＮＶＩＴＥ，  ＡＣＫ，  ＣＡＮＣＥＬ，  ＯＰＴＩＯＮＳ，  ＢＹＥ，  ＭＥＴＨＯＤ
Ｕｓｅｒ−Ａｇｅｎｔ：ｖｅｎｄｏｒ＝“ｖｅｎｄｏｒ．ｅｘａｍｐｌｅ．ｎｅｔ”；ｍｏｄｅｌ＝“Ｚ−ｐｈｏｎｅ”；ｖｅｒｓｉｏｎ＝“１．２．３”
Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ：２７４
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ：ｍｅｓｓａｇｅ／ｅｘｔｅｒｎａｌ−ｂｏｄｙ；
ＡＣＣＥＳＳ−ＴＹＰＥ＝“ＵＲＬ”
ＵＲＬ＝“ｈｔｔｐ：／／ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ／ｕｓｅｒａｇｅｎｔｐｒｏｆｉｌｅ／０７２４２００２”；
ＥＸＰＩＲＡＴＩＯＮ  ＝“Ｍｏｎ，  ２３  Ｊｕｎｅ  ２００８  ０９：００：００  ＧＭＴ”；
ｓｉｚｅ＝４１２３
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ：ａｐｐｌｉｃａｔｉｏｎ／Ｄｅｖ−ｃａｐ
Ｃｏｎｔｅｎｔ−Ｄｉｓｐｏｓｉｔｉｏｎ：ａｔｔａｃｈｍｅｎｔ
Ｃｏｎｔｅｎｔ−ＩＤ：４ｅ５５６２ｃｄ１２１４４２７ｄ＠ｅｘａｍｐｌｅ．ｎｅｔ
このＳＩＰ  ２００  ＯＫ応答のＣｏｎｔｅｎｔ−Ｔｙｐｅ部分は、そこからプッシュ受信側エージェントの能力を取得することができるＵＲＬを含むことが分かる。イベント１８０では、ＳＩＰ／ＩＰコアは、ＳＩＰ  ２００  ＯＫ応答をＳＩＰプッシュ送信側エージェントに転送する。
【００２４】
別の実施形態では、プッシュ受信側エージェントが、ＳＩＰ  ＯＰＴＩＯＮＳ要求においてそのＧＲＵＵをプッシュ送信側エージェントに提供するよりもむしろ、プッシュ送信側エージェントが、ＳＩＰ  ＳＵＢＳＣＲＩＢＥメッセージを使用してＳＩＰ／ＩＰコアからプッシュ受信側エージェントのＧＲＵＵを要求する。ＳＩＰ／ＩＰコアは、ＳＩＰ  ＮＯＴＩＦＹメッセージの中でプッシュ受信側エージェントのＧＲＵＵ値を返信し、次いで、プッシュ送信側エージェントが、プッシュ受信側エージェントの能力を要求するＳＩＰ  ＯＰＴＩＯＮＳ要求をプッシュ受信側エージェントに送信するために、このＧＲＵＵを使用する。
【００２５】
図２は、この実施形態の下で、ＳＩＰプッシュクライアント（またはＳＩＰプッシュ受信側エージェント）１０と、ＳＩＰ／ＩＰコア２０と、ＳＩＰ  ＰＵＳＨサーバ（またはＳＩＰ  プッシュ送信側エージェント）３０との間のメッセージフロー例を描写する。イベント２１０では、ＳＩＰプッシュ送信側エージェントは、ＳＩＰ／ＩＰコアにＳＩＰ  ＳＵＢＳＣＲＩＢＥ要求を送信する。以下は、ＳＩＰ  ＳＵＢＳＣＲＩＢＥ要求の実施形態である。
ＳＵＢＳＣＲＩＢＥ  ｓｉｐ：ｓｉｐ：ａｌｉｃｅ＠ａｔｌａｎｔａ．ｃｏｍ  ＳＩＰ／２．０
Ｖｉａ：ＳＩＰ／２．０／ＵＤＰ  ｈｏｓｔｎｅｔｗｏｒｋ．ｎｅｔ；ｂｒａｎｃｈ＝ｚ９ｈＧ４ｂＫ９ｚｚ８
Ｍａｘ−Ｆｏｒｗａｒｄｓ：７０
Ｆｒｏｍ：＜ｓｉｐ：ｐｕｓｈｓｅｒｖｅｒ＠ｎｅｔｗｏｒｋ．ｎｅｔ＞；ｔａｇ＝ｋｋａｚ−
Ｔｏ：＜ｓｉｐ：ａｌｉｃｅ＠ａｔｌａｎｔａ．ｃｏｍ＞
Ｃａｌｌ−ＩＤ：ｆａｉｆ９ａ＠ｈｏｓｔ．ｎｅｔｗｏｒｋ．ｎｅｔ
ＣＳｅｑ：２  ＳＵＢＳＣＲＩＢＥ
Ｅｖｅｎｔ：ｒｅｇ
Ｅｘｐｉｒｅｓ：３６００
Ｃｏｎｔａｃｔ：＜ｓｉｐ：ｐｕｓｈｓｅｒｖｅｒ＠ｎｅｔｗｏｒｋ．ｎｅｔ＞
Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ：０
イベント２２０では、ＳＩＰ／ＩＰコアは、ＳＩＰ  ＳＵＢＳＣＲＩＢＥ要求を受信し、ＳＩＰ  ２００  ＯＫ応答をＳＩＰプッシュ送信側エージェントに送信する。イベント２３０では、ＳＩＰ／ＩＰコアは、ＳＩＰプッシュ送信側エージェントに、登録過程中に取得されたＳＩＰプッシュ受信側エージェントの公衆ＧＲＵＵ値を含むＳＩＰ  ＮＯＴＩＦＹを送信する。以下は、ＳＩＰ  ＮＯＴＩＦＹ要求の実施形態である。
ＮＯＴＩＦＹ  ｓｉｐ：ｓｉｐ：ｐｕｓｈｓｅｒｖｅｒ＠＠ｎｅｔｗｏｒｋ．ｎｅｔ  ＳＩＰ／２．０
Ｖｉａ：ＳＩＰ／２．０／ＵＤＰ  ｈｏｓｔ．ｎｅｔｗｏｒｋ．ｎｅｔ；ｂｒａｎｃｈ＝ｚ９ｈＧ４ｂＫ９ｚｚ８
Ｍａｘ−Ｆｏｒｗａｒｄｓ：７０
Ｆｒｏｍ：＜ｓｉｐ：ｓｉｐｉｐｃｏｒｅ＠ｎｅｔｗｏｒｋ．ｎｅｔ＞；ｔａｇ＝ｋｋａａ−
Ｒｅｑｕｅｓｔ−ＵＲＩ：＜ｓｉｐ：ｐｕｓｈｓｅｒｖｅｒ＠ｎｅｔｗｏｒｋ．  ｎｅｔ＞
Ｃａｌｌ−ＩＤ：ｆａｉｆ９ａ＠ｈｏｓｔ．ｎｅｔｗｏｒｋ．ｎｅｔ
ＣＳｅｑ：２  ＮＯＴＩＦＹ
Ｅｖｅｎｔ：ｒｅｇ
Ｓｕｂｓｃｒｉｐｔｉｏｎ−Ｓｔａｔｅ：ａｃｔｉｖｅ  ；ｅｘｐｉｒｅｓ＝  ３６００
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ：ａｐｐｌｉｃａｔｉｏｎ／ｒｅｇｉｎｆｏ＋ｘｍｌ
Ｃｏｎｔａｃｔ：＜ｓｉｐ：ｓｉｐｉｐｃｏｒｅ＠ｎｅｔｗｏｒｋ．ｎｅｔ＞
Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ：
＜？ｘｍｌ  ｖｅｒｓｉｏｎ＝“１．０”？＞
＜ｒｅｇｉｎｆｏ  ｘｍｌｎｓ＝“ｕｒｎ：ｉｅｔｆ：ｐａｒａｍｓ：ｘｍｌ：ｎｓ：ｒｅｇｉｎｆｏ”
ｘｍｌｎｓ：ｇｒ＝“ｕｒｎ：ｉｅｔｆ；ｐａｒａｍｓ：ｘｍｌ：ｎｓ：ｇｒｕｕｉｎｆｏ”
ｖｅｒｓｉｏｎ＝“１”  ｓｔａｔｅ＝“ｆｕｌｌ”＞
＜ｒｅｇｉｓｔｒａｔｉｏｎ  ａｏｒ＝“ｓｉρ：ａｌｉｃｅ＠ａｔｌａｎｔａ．ｃｏｍ”  ｉｄ＝“ａ７”
ｓｔａｔｅ＝“ａｃｔｉｖｅ”＞
＜ｃｏｎｔａｃｔ  ｉｄ＝“９２”  ｓｔａｔｅ＝“ａｃｔｉｖｅ”  ｅｖｅｎｔ−“ｒｅｇｉｓｔｅｒｅｄ”
ｄｕｒａｔｉｏｎ−ｒｅｇｉｓｔｅｒｅｄ＝“１  ”  ｅｘρｉｒｅｓ＝“３５９９”
ｃａｌｌｉｄ＝“ｆａｉｆ９ａ＠ｐｃ３３，ａｔｌａｎｔａ．ｃｏｍ”  ｃｓｅｑ＝“２３００１”＞
＜ｕｒｉ＞
ｓｉｐ：ａｌｉｃｅ＠ｐｃ３３．ａｔｌａｎｔａ．ｃｏｍ
＜／ｕｒｉ＞
＜ａｌｌＯｎｅＬｉｎｅ＞
＜ｕｎｋｎｏｗｎ−ｐａｒａｍ  ｎａｍｅ＝“＋ｓｉｐ．ｉｎｓｔａｎｃｅ”＞  “＆ｌｔ；ｕｍ：ｕｕｉｄ：ｆ８１ｄ４ｆａｅ−７ｄｅｃ−１１ｄ０−ａ７６５−００ａ０ｃ９１ｅ６ｂｆ６＆ｇｔ；”
＜／ｕｎｋｎｏｗｎ−ｐａｒａｍ＞
＜／ａｌｌＯｎｅＬｉｎｅ＞
＜ａｌｌＯｎｅＬｉｎｅ＞
＜ｇｒ：ｐｕｂ−ｇｒｕｕ  ｕｒｉ＝“
ｓｉｐ：ａｌｉｃｅ＠ａｔｌａｎｔａ．ｃｏｍ；ｇｒ＝ｕｒｎ：ｕｕｉｄ：ｆ８１ｄ４ｆａｅ−７ｄｅｃ−１１ｄ０−ａ７６５−００ａ０ｃ９１ｅ６ｂｆ６”／＞
＜／ａｌｌＯｎｅＬｉｎｅ＞
＜ａｌｌＯｎｅＬｉｎｅ＞
＜ｇｒ：ｔｅｍｐ−ｇｒｕｕ  ｕｒｉ＝“ｓｉｐ：８ｆｆｋａｓ０８ａｆ７ｆａｓｋｌｚｉ９＠ａｔｌａｎｔａ．ｃｏｍ  ；
ｇｒ”  ｆｉｒｓｔ−ｃｓｅｑ＝”５４３０１’／＞
＜／ａｌｌＯｎｅＬｉｎｅ＞
＜／ｃｏｎｔａｃｔ＞
＜ｃｏｎｔａｃｔ  ｉｄ＝”９３”  ｓｔａｔｅ＝”ａｃｔｉｖｅ”  ｅｖｅｎｔ＝”ｒｅｇｉｓｔｅｒｅｄ”
ｄｕｒａｔｉｏｎ−ｒｅｇｉｓｔｅｒｅｄ＝”１”  ｅｘρｉｒｅｓ＝”３５９９”
ｃａｌｌｉｄ＝”ｆａｅ６７８＠ｐｃ３３．ａｔｌａｎｔａ．ｃｏｍ”  ｃｓｅｑ＝”２３００１”＞
＜ｕｒｉ＞
ｓｉｐ．ａｌｉｃｅ＠ｐｃ３３．ａｔｆａｎｔａ．ｃｏｍ
＜／ｕｒｉ＞
＜ａｌｌＯｎｅＬｉｎｅ＞
＜ｕｎｋｎｏｗｎ−ｐａｒａｍ  ｎａｍｅ＝”＋ｓｉｐ．ｉｎｓｔａｎｃｅ”＞
”＆ｌｔ；ｕｒｎ：ｕｕｉｄ：ｆａ２３５８−７ｄｅｃ−１１  ｄ０−ｂ６７８−００ｃ０ｂ２７ｄ６ａｃ９＆ｇｔ；”
＜／ｕｎｋｎｏｗｎ−ｐａｒａｍ＞
＜／ａｌｌＯｎｅＬｉｎｅ＞
＜ａｌｌＯｎｅＬｉｎｅ＞
＜ｇｒ：ｐｕｂ−ｇｒｕｕ  ｕｒｉ＝”
ｓｉｐ：ａｌｉｃｅ＠ａｔｌａｎｔａ．ｃｏｍ；ｇｒ＝ｕｒｎ：ｕｕｉｄ：ｆａ２３５８−７ｄｅｃ−１１ｄ０−ｂ６７８−００ｃ０ｂ２７ｄ６ａｃ９”／＞
＜／ａｌｌＯｎｅＬｉｎｅ＞
＜ａｌｌＯｎｅＬｉｎｅ＞
＜ｇｒ：ｔｅｍｐ−ｇｒｕｕ
ｕｒｉ＝”ｓｉｐ：ａｆａｓ８ｉ９７０８ｋｌｚｆｆｋａｓｆ＠ａｔｌａｎｔａ．ｃｏｍ
；ｇｒ”  ｆｉｒｓｔ−ｃｓｅｑ＝”５４１０２”／＞
＜／ａｌｌＯｎｅＬｉｎｅ＞
＜／ｃｏｎｔａｃｔ＞
＜／ｒｅｇｉｓｔｒａｔｉｏｎ＞
＜／ｒｅｇｉｎｆｏ＞
イベント２４０では、ＳＩＰプッシュ送信側エージェントは、ＳＩＰ  ２００  ＯＫをＳＩＰ／ＩＰコアに送信する。イベント２５０では、ＳＩＰプッシュ送信側エージェントは、ＳＩＰプッシュ受信側エージェントの公衆ＧＲＵＵをＲｅｑｕｅｓｔ−ＵＲＩに含むＳＩＰ  ＯＰＴＩＯＮＳ要求を、ＳＩＰ／ＩＰコアに送信する。つまり、ＳＩＰ  ＯＰＴＩＯＮＳ要求は、特定されたＧＲＵＵを伴うＳＩＰプッシュ受信側エージェントにアドレス指定される。以下は、ＳＩＰ  ＯＰＴＩＯＮＳ要求の実施形態である。
ＯＰＴＩＯＮＳ  ｓｉｐ：ａｌｉｃｅ＠ａｔｌａｎｔａ．ｃｏｍ；ｇｒ＝ｕｒｎ：ｕｕｉｄ：ｆ８１ｄ４ｆａｅ−７ｄｅｃ−１１ｄ０−ａ７６５−００ａ０ｃ９１ｅ６ｂｆ６  ＳＩＰ／２．０
Ｖｉａ：ＳＩＰ／２．０／ＵＤＰ  ｐｃ３３．ａｔｌａｎｔａ．ｃｏｍ；ｂｒａｎｃｈ＝ｚ９ｈＧ４ｂＫｈｊｈｓ８ａｓｓ８７７
Ｍａｘ−Ｆｏｒｗａｒｄｓ：７０
Ｔｏ：＜ｓｉｐ：ａｌｉｃｅ＠ａｔｌａｎｔａ．ｃｏｍ＞
Ｆｒｏｍ：＜ｓｉｐ：ｐｕｓｈｓｅｒｖｅｒ＠ｎｅｔｗｏｒｋ．ｃｏｍ＞；ｔａｇ＝１９２８３０１７７９
Ｐ−Ａｓｓｅｒｔｅｄ−ｌｄｅｎｔｉｔｙ：＜ｓｉｐ：ｐｕｓｈｓｅｒｖｅｒ＠ｎｅｔｗｏｒｋ．ｃｏｍ＞
Ｃａｌｌ−ＩＤ：ａ８４ｂ４ｃ７６ｅ６６７１９
ＣＳｅｑ：６３１０４  ＯＰＴＩＯＮＳ
Ｃｏｎｔａｃｔ：＜ｓｉｐ：ｐｕｓｈｓｅｒｖｅｒ＠ｎｅｔｗｏｒｋ．ｃｏｍ＞；＋ｇ．ｏｍａ．ｐｕｓｈｅｖｅｎｔａｐｐ＝”ｍｍｓ”
Ａｌｌｏｗ：ＩＮＶＩＴＥ，  ＡＣＫ，  ＣＡＮＣＥＬ，  ＯＰＴＩＯＮＳ，  ＢＹＥ，  ＭＥＳＳＡＧＥ
Ｓｕｐｐｏｒｔｅｄ：ｇｒｕｕ
Ａｃｃｅｐｔ：ｍｅｓｓａｇｅ／ｅｘｔｅｒｎａｌ−ｂｏｄｙ，ａｐｐｌｉｃａｔｉｏｎ／Ｄｅｖ−ｃａｐ
Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ：０
イベント２６０では、ＳＩＰ／ＩＰコアは、ＳＩＰ  ＯＰＴＩＯＮＳ要求を、特定されたＧＲＵＵを伴うＳＩＰプッシュ受信側エージェントに転送する。イベント２７０では、ＳＩＰプッシュ受信側エージェントは、ＳＩＰプッシュ受信側エージェントの能力に関する情報を含むＳＩＰ  ２００  ＯＫ応答をＳＩＰ／ＩＰコアに送信する。ＳＩＰ  ２００  ＯＫ応答はまた、追加プッシュオプション、またはそこから追加プッシュオプションを取得することができるＵＲＩを含む、本文を含みてもよい。以下は、ＳＩＰ  ２００  ＯＫ応答の実施形態である。
ＳＩＰ／２．０２００  ＯＫ
Ｖｉａ：ＳＩＰ／２．０／ＵＤＰ  ｐｃ３３．ａｔｌａｎｔａ．ｃｏｍ；ｂｒａｎｃｈ＝ｚ９ｈＧ４ｂＫｈｊｈｓ８ａｓｓ８７７；ｒｅｃｅｉｖｅｄ＝１９２．０．２．４
Ｔｏ：＜ｓｉｐ：ａｌｉｃｅ＠ａｔｌａｎｔａ．ｃｏｍ＞；ｔａｇ＝９３８１０８７９
Ｆｒｏｍ：＜ｓｉｐ：ｐｕｓｈｓｅｒｖｅｒ＠ｎｅｔｗｏｒｋ．ｃｏｍ＞；ｔａｇ＝１９２８３０１７７９
Ｃａｌｌ−ＩＤ：ａ８４ｂ４ｃ７６ｅ６６７１９
ＣＳｅｑ：６３１０４  ＯＰＴＩＯＮＳ
Ｓｕｐｐｏｒｔｅｄ：ｇｒｕｕ
Ｃｏｎｔａｃｔ：＜ｓｉｐ：ａｌｉｃｅ＠ａｔｌａｎｔａ．ｃｏｍ＞；ｇｒ＝ｕｒｎ：ｕｕｉｄ：ｆ８１ｄ４ｆａｅ−７ｄｅｃ−１１ｄ０−ａ７６５−００ａ０ｃ９１ｅ６ｂｆ２；＋ｇ．ｏｍａ．ｐｕｓｈｅｖｅｎｔａｐｐ＝”ｍｍｓ”
Ａｌｌｏｗ：ＩＮＶＩＴＥ，  ＡＣＫ，  ＣＡＮＣＥＬ，  ＯＰＴＩＯＮＳ，  ＢＹＥ，  ＭＥＴＨＯＤ
Ｕｓｅｒ−Ａｇｅｎｔ：ｖｅｎｄｏｒ＝”ｖｅｎｄｏｒ．ｅｘａｍｐｌｅ．ｎｅｆ；ｍｏｄｅｌ＝”Ｚ−ｐｈｏｎｅ”；ｖｅｒｓｉｏｎ＝”１．２．３”
Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ：２７４
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ：ｍｅｓｓａｇｅ／ｅｘｔｅｒｎａｌ−ｂｏｄｙ；
ＡＣＣＥＳＳ−ＴＹＰＥ＝”ＵＲＬ”
ＵＲＬ＝”ｈｔｔｐ：／／ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ／ｕｓｅｒａｇｅｎｔｐｒｏｆｉｌｅ／０７２４２００２”；
ＥＸＰＩＲＡＴＩＯＮ  ＝”Ｍｏｎ，  ２３  Ｊｕｎｅ  ２００８  ０９：００：００  ＧＭＴ”；
ｓｉｚｅ＝４１２３
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ：ａｐｐｌｉｃａｔｉｏｎ／Ｄｅｖ−ｃａｐ
Ｃｏｎｔｅｎｔ−Ｄｉｓｐｏｓｉｔｉｏｎ：ａｔｔａｃｈｍｅｎｔ
Ｃｏｎｔｅｎｔ−ＩＤ：４ｅ５５６２ｃｄ１２１４４２７ｄ＠ｅｘａｍｐｌｅ．ｎｅｔ
イベント２８０では、ＳＩＰ／ＩＰコアは、ＳＩＰ  ２００  ＯＫ応答をＳＩＰプッシュ送信側エージェントに転送する。
【００２６】
別の実施形態では、ＳＩＰプッシュ送信側エージェントは、元のＳＩＰ  ＲＥＧＩＳＴＥＲ要求のコンテンツを含む本文を含む、第３者登録機構を使用して、ＧＲＵＵを取得することができる。元のＳＩＰ  ＲＥＧＩＳＴＥＲ要求は、ＳＩＰプッシュ受信側エージェントによって送信された元のＳＩＰ  ＲＥＧＩＳＴＥＲ要求からのＣｏｎｔａｃｔヘッダ値を含んでもよい。本文は、ＧＲＵＵを直接含みない場合があるが、元のＳＩＰ  ＲＥＧＩＳＴＥＲ要求のＣｏｎｔａｃｔヘッダは、ｓｉｐ．ｉｎｓｔａｎｃｅ機能タグを含む場合がある。ＳＩＰ／ＩＰコアの方針が、元のＳＩＰ  ＲＥＧＩＳＴＥＲ要求のＣｏｎｔａｃｔヘッダの中のｓｉｐ．ｉｎｓｔａｎｃｅ機能タグの値に等しく設定された公衆ＧＲＵＵの「ｇｒ」パラメータを伴う登録されたＰＵＩまたはＡｏＲから、公衆ＧＲＵＵを導出することであると、ＳＩＰプッシュ送信側エージェントが分かっている場合は、ＳＩＰプッシュ送信側エージェントは、登録したＳＩＰプッシュ受信側エージェントのＧＲＵＵを導出することもできる。
【００２７】
上記で説明される構成要素は、上記で説明される動作に関する命令を実行することが可能である、処理構成要素を含む場合がある。図３は、本明細書で開示される１つ以上の実施形態を実装するために好適な処理構成要素１３１０を含む、システム１３００の実施例を図示する。プロセッサ１３１０（中央プロセッサユニットまたはＣＰＵと呼ばれてもよい）に加えて、システム１３００は、ネットワーク接続デバイス１３２０、ランダムアクセスメモリ（ＲＡＭ）１３３０、読み出し専用メモリ（ＲＯＭ）１３４０、２次記憶装置１３５０、入出力（Ｉ／Ｏ）デバイス１３６０を含む場合がある。これらの構成要素は、存在しなくてもよく、または、相互と、あるいは示されていない他の構成要素と、種々の組み合わせで組み合わせられてもよい。これらの構成要素は、単一の物理的実体に、または１つより多くの物理的実体に位置する場合がある。プロセッサ１３１０によって取られるものとして本明細書で説明される、任意の動作は、プロセッサ１３１０によって単独で、または、デジタル信号プロセッサ（ＤＳＰ）１３８０等の、図面に示されている、または示されていない１つ以上の構成要素と併せて、取られる場合がある。ＤＳＰ１３８０は別個の構成要素として示されているが、ＤＳＰ１３８０はプロセッサ１３１０に組み込まれる場合がある。
【００２８】
プロセッサ１３１０は、それがネットワーク接続デバイス１３２０、ＲＡＭ１３３０、ＲＯＭ１３４０、または２次記憶装置１３５０（ハードディスク、フロッピー（登録商標）ディスク、または光ディスク等の、種々のディスクベースのシステムを含む場合がある）からアクセスする場合がある、命令、コード、コンピュータプログラム、またはスクリプトを実行する。１つだけのＣＰＵ１３１０が示されているが、複数のプロセッサが存在してもよい。したがって、命令は、プロセッサによって実行されるものとして論議されてもよいが、命令は、同時に、連続的に、または別様に、１つまたは複数のプロセッサによって実行されてもよい。プロセッサ１３１０は、１つ以上のＣＰＵチップとして実装されてもよい。
【００２９】
ネットワーク接続デバイス１３２０は、モデム、モデムバンク、イーサネット（登録商標）デバイス、ユニバーサルシリアルバス（ＵＳＢ）インターフェースデバイス、シリアルインターフェース、トークンリングデバイス、光ファイバ分散データインターフェース（ＦＤＤＩ）デバイス、無線ローカルエリアネットワーク（ＷＬＡＮ）デバイス、符号分割多重アクセス（ＣＤＭＡ）デバイス、グローバルシステムフォーモバイルコミュニケーションズ（ＧＳＭ）無線送受信機デバイス等の無線送受信機デバイス、マイクロ波アクセス用の世界的相互運用性（ＷｉＭＡＸ）デバイス、および／またはネットワークに接続するための他の周知のデバイスの形態を成してもよい。これらのネットワーク接続デバイス１３２０は、プロセッサ１３１０が情報を受信する場合がある、またはプロセッサ１３１０が情報を出力する場合がある、インターネットまたは１つ以上の電気通信ネットワーク、あるいは他のネットワークと、プロセッサ１３１０が通信することを可能にしてもよい。ネットワーク接続デバイス１３２０はまた、無線でデータを伝送および／または受信することが可能な１つ以上の送受信機構成要素１３２５を含む場合がある。
【００３０】
ＲＡＭ１３３０は、揮発性データを記憶するために、および、おそらくプロセッサ１３１０によって実行される命令を記憶するために、使用される場合がある。ＲＯＭ１３４０は、典型的には２次記憶装置１３５０のメモリ容量よりも小さいメモリ容量を有する、不揮発性メモリデバイスである。ＲＯＭ１３４０は、命令、およびおそらく命令の実行中に読み出されるデータを記憶するために、使用される場合がある。ＲＡＭ１３３０およびＲＯＭ１３４０の両方へのアクセスは、典型的には、２次記憶装置１３５０へのアクセスよりも速い。２次記憶装置１３５０は、典型的には、１つ以上のディスクドライブまたはテープドライブから成り、ＲＡＭ１３３０が全作業データを保持するほど十分に大きくない場合に、データの不揮発性記憶のために、またはオーバーフローデータ記憶デバイスとして使用される場合がある。２次記憶装置１３５０は、ＲＡＭ１３３０にロードされるプログラムが実行のために選択されると、そのようなプログラムを記憶するために使用されてもよい。
【００３１】
Ｉ／Ｏデバイス１３６０は、液晶ディスプレイ（ＬＣＤ）、タッチスクリーンディスプレイ、キーボード、キーパッド、スイッチ、ダイヤル、マウス、トラックボール、音声認識装置、カード読取装置、紙テープ読取装置、プリンタ、ビデオモニタ、または他の周知の入出力デバイスを含んでもよい。また、送受信機１３２５は、ネットワーク接続デバイス１３２０の構成要素である代わりに、またはそれに加えて、Ｉ／Ｏデバイス１３６０の構成要素と見なされる場合がある。
【００３２】
実施形態では、ユーザエージェントの能力を送達するための方法が提供される。方法は、少なくとも１つのプッシュリソースを含むプッシュリソース識別子機能タグを含む、Ｃｏｎｔａｃｔヘッダを含むＳＩＰメッセージを送信する、ユーザエージェントを含む。
【００３３】
代替実施形態では、ＳＩＰプッシュ受信側エージェントが提供される。プッシュ受信側エージェントは、プッシュ受信側エージェントが、少なくとも１つのプッシュリソースを含むプッシュリソース識別子機能タグを含む、Ｃｏｎｔａｃｔヘッダを含むＳＩＰメッセージを送信するように、構成される構成要素を含む。
【００３４】
代替実施形態では、ＳＩＰプッシュ送信側エージェントが提供される。プッシュ送信側エージェントは、プッシュ送信側エージェントが、少なくとも１つのプッシュリソースを含むプッシュリソース識別子機能タグを含む、Ｃｏｎｔａｃｔヘッダを含むＳＩＰメッセージを受信するように、構成される構成要素を含む。
【００３５】
以下の３ｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ  （３ＧＰＰ）  Ｔｅｃｈｎｉｃａｌ  Ｓｐｅｃｉｆｉｃａｔｉｏｎｓ  （ＴＳ）、およびＩｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ  （ＩＥＴＦ）  Ｒｅｑｕｅｓｔｓ  Ｆｏｒ  Ｃｏｍｍｅｎｔｓ  （ＲＦＣ）が、参照することにより本明細書に組み込まれる。［ＲＦＣ  ３２６１］  Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ，  ［ＲＦＣ  ３２６５］  Ｓｅｓｓｉｏｎ  ＩｎｉｔｉａｔｉｏｎＰｒｏｔｏｃｏｌ  （ＳΙＰ）−Ｓｐｅｃｉｆｉｃ  Ｅｖｅｎｔ  Ｎｏｔｉｆｉｃａｔｉｏｎ、［ＲＦＣ  ３６８０］  Ｒｅｇｉｓｔｒａｔｉｏｎ  Ｅｖｅｎｔ  Ｐａｃｋａｇｅ、［ｄｒａｆｔ−ｉｅｔｆ−ｓｉｐ−ｇｒｕｕ］  Ｏｂｔａｉｎｉｎｇ  ａｎｄ  Ｕｓｉｎｇ  Ｇｌｏｂａｌｌｙ  Ｒｏｕｔａｂｌｅ  Ｕｓｅｒ  Ａｇｅｎｔ  （ＵＡ）  ＵＲＩｓ  （ＧＲＵＵ）  ｉｎ  ｔｈｅ  Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ  （ＳＩＰ）、［ｄｒａｆｔ−ｉｅｔｆ−ｓｉｐｐｉｎｇ−ｇｒｕｕ−ｒｅｇ−ｅｖｅｎｔ］  ＧＲＵＵ  ｒｅｇｉｓｔｒａｔｉｏｎ  ｅｖｅｎｔｓ、ＯＭＡ−ＴＳ−ＳＩ  Ｐ＿Ｐｕｓｈ−Ｖ１＿０−２００８０４１６−Ｄ、３ＧＰＰ  ＴＳ  ２３．２１８、および３ＧＰＰ  ＴＳ  ２４．２２９。
【００３６】
いくつかの実施形態を本開示で提供したが、開示されたシステムおよび方法は、本開示の精神または範囲から逸脱することなく、多くの他の具体的形態で具現化されてもよいことを理解されたい。
【００３７】
本実施例は、制限的ではなく例証的と見なされるものであり、本明細書で与えられる詳細に制限されることを意図するものではない。例えば、種々の要素または構成要素が組み合わされるか、または別のシステムに統合されてもよく、または、ある特徴が省略されるか、あるいは実装されなくてもよい。
【００３８】
また、個別または別個のものとして種々の実施形態で説明および例証される、技術、システム、サブシステム、および方法は、本開示の範囲から逸脱することなく、他のシステム、モジュール、技術、または方法と組み合わされるか、あるいは統合されてもよい。相互に連結される、または直接連結される、あるいは通信するものとして示される、または論議される他の項目は、電気的であろうと、機械的であろうと、または別の方法であろうと、何らかのインターフェース、デバイス、または中間構成要素を通して、間接的に連結されるか、または通信してもよい。変更、置換、および改変の他の実施例が、当業者によって究明可能であり、本明細書で開示される精神および範囲から逸脱することなく行うことができる。
【図１】
2011527534.tif 000003
【図２】
2011527534.tif 000004
【図３】
2011527534.tif 000005
【手続補正書】
【提出日】平成22年12月27日(2010.12.27)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
プッシュ受信側エージェントにおいて、該プッシュ受信側エージェントとプッシュ送信側エージェントとの間での能力送達およびリソース交渉のためのセッション初期化プロトコル（ＳＩＰ）メッセージを生成することと、
Ｃｏｎｔａｃｔヘッダを該ＳＩＰメッセージに含むことであって、該Ｃｏｎｔａｃｔヘッダは、該プッシュ受信側エージェントによってサポートされるプッシュリソースの値を含むプッシュリソース識別子機能タグを含む、ことと
を包含する、方法。
【請求項２】
前記ＳＩＰメッセージは、ＳＩＰ  ＯＰＴＩＯＮＳ要求である、請求項１に記載の方法。
【請求項３】
前記Ｃｏｎｔａｃｔヘッダは、前記プッシュ受信側エージェントを識別するＵｎｉｆｏｒｍ  ｒｅｓｏｕｒｃｅ  ｉｄｅｎｔｉｆｉｅｒ（ＵＲＩ）をさらに含む、請求項２に記載の方法。
【請求項４】
前記ＵＲＩは、Ｇｌｏｂａｌｌｙ  Ｒｏｕｔａｂｌｅ（ＵＡ）ＵＲＩ（ＧＲＵＵ）を含む、請求項３に記載の方法。
【請求項５】
前記プッシュ受信側エージェントによってサポートされるＳＩＰ方法は、ＩＮＶＩＴＥ、ＡＣＫ、ＣＡＮＣＥＬ、ＯＰＴＩＯＮＳ、ＢＹＥおよびＭＥＳＳＡＧＥのうちの少なくとも１つを含む、請求項２に記載の方法。
【請求項６】
前記ＳＩＰ  ＯＰＴＩＯＮＳにユーザエージェントヘッダを含むことをさらに包含し、該ユーザエージェントヘッダは、前記プッシュ受信側エージェントのモデル、供給元およびバージョンのうちの少なくとも１つをさらに含む、請求項２に記載の方法。
【請求項７】
前記ＳＩＰメッセージにＣｏｎｔｅｎｔ−ｔｙｐｅヘッダを含むことをさらに包含し、該Ｃｏｎｔｅｎｔ−Ｔｙｐｅヘッダは、ＭＩＭＥ型としての“ｍｅｓｓａｇｅ／ｅｘｔｅｒｎａｌ−ｂｏｄｙ”、ＡＣＣＥＳＳ＿ＴＹＰＥパラメータとしての“ＵＲＬ”、有効期限パラメータ、および前記ＵＡのプロファイルを特定する文書を指し示すＨＴＴＰ  ＵＲＬを含む、請求項１に記載の方法。
【請求項８】
前記ＳＩＰメッセージに本文を含むことをさらに包含し、該本文は、Ｃｏｎｔｅｎｔ−Ｄｉｓｐｏｓｉｔｉｏｎとして“ａｔｔａｃｈｍｅｎｔ”を含む、請求項７に記載の方法。
【請求項９】
前記ＳＩＰメッセージを送信することに対して、ＳＩＰ  ２００  ＯＫ応答を受信することをさらに包含する、請求項１に記載の方法。
【請求項１０】
請求項１〜９のうちのいずれか１項に記載の方法を実行するように構成されたプッシュ受信側エージェント。
【請求項１１】
プッシュ送信側エージェントにおいて、該プッシュ送信側エージェントとプッシュ受信側エージェントとの間での能力送達およびリソース交渉のためのＳＩＰ  ＯＰＴＩＯＮＳ要求を受信することと、
該プッシュ受信側エージェントにおいて、ＳＩＰメッセージを生成することと、
Ｃｏｎｔａｃｔヘッダを該ＳＩＰメッセージに含むことであって、該Ｃｏｎｔａｃｔヘッダは、該プッシュ受信側エージェントによってサポートされるプッシュリソースの値を含むプッシュリソース識別子機能タグを含み、該プッシュ受信側エージェントは該ＳＩＰ  ＯＰＴＩＯＮＳ要求において指定される、ことと、
Ａｌｌｏｗヘッダを該ＳＩＰメッセージに含むことであって、該Ａｌｌｏｗヘッダは、該プッシュ受信側エージェントがサポートするＳＩＰ方法を含む、ことと、
該ＳＩＰメッセージを送信することと
を包含する、方法。
【請求項１２】
前記ＳＩＰメッセージはＳＩＰ  ２００  ＯＫ応答である、請求項１１に記載の方法。
【請求項１３】
Ａｃｃｅｐｔヘッダを前記ＳＩＰメッセージに含むことをさらに包含し、該Ａｃｃｅｐｔヘッダは、前記プッシュ受信側エージェントによってサポートされるＭＩＭＥ型を含む、請求項１１に記載の方法。
【請求項１４】
前記プッシュ受信側エージェントによってサポートされる前記ＭＩＭＥ型は、“ｍｅｓｓａｇｅ／ｅｘｔｅｒｎａｌ−ｂｏｄｙ”である、請求項１３に記載の方法。
【請求項１５】
請求項１１〜１４のうちのいずれか１項に記載の方法を実行するように構成されたプッシュ送信側エージェント。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】００１４
【補正方法】変更
【補正の内容】
【００１４】
代替として、プッシュ送信側エージェントは、プッシュ受信側エージェントからのＳＩＰ  ＯＰＴＩＯＮＳ要求への２００  ＯＫ応答に、その能力を含む場合があるが、プッシュ受信側エージェントの能力を要求するためにＳＩＰ  ＯＰＴＩＯＮＳ要求をプッシュ受信側エージェントのＧＲＵＵに送信しない場合がある。
例えば、本発明は以下の項目を提供する。
（項目１）
ユーザエージェント（ＵＡ）の能力を送達するための方法であって、
ＵＡが、Ｃｏｎｔａｃｔヘッダを含むセッション初期化プロトコル（ＳＩＰ）メッセージを送信することを含み、該Ｃｏｎｔａｃｔヘッダは、少なくとも１つのプッシュリソースを含むプッシュリソース識別子機能タグを含む、方法。
（項目２）
上記Ｃｏｎｔａｃｔヘッダはさらに、Ｇｌｏｂａｌｌｙ  Ｒｏｕｔａｂｌｅ  ＵＡ  Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ（ＵＲＩ）（ＧＲＵＵ）を含む、項目１に記載の方法。
（項目３）
上記ＳＩＰメッセージは、多目的インターネットメール拡張（ＭＩＭＥ）型「ｍｅｓｓａｇｅ／ｅｘｔｅｒｎａｌ−ｂｏｄｙ」を含むヘッダをさらに含む、項目１に記載の方法。
（項目４）
上記ヘッダは、上記ＵＡのＯｐｅｎ  Ｍｏｂｉｌｅ  Ａｌｌｉａｎｃｅ（ＯＭＡ）ＵＡプロファイルドキュメントを指し示すＵＲＩをさらに含む、項目１に記載の方法。
（項目５）
上記ヘッダは、Ａｃｃｅｐｔヘッダである、項目３に記載の方法。
（項目６）
上記ヘッダは、Ａｃｃｅｐｔヘッダである、項目４に記載の方法。
（項目７）
上記ヘッダは、Ｃｏｎｔｅｎｔ−Ｔｙｐｅヘッダである、項目３に記載の方法。
（項目８）
上記ヘッダは、Ｃｏｎｔｅｎｔ−Ｔｙｐｅヘッダである、項目４に記載の方法。
（項目９）
上記ＳＩＰメッセージは、上記ＵＡによってサポートされるＳＩＰ方法を含むＡｌｌｏｗヘッダをさらに含む、項目１に記載の方法。
（項目１０）
上記ＳＩＰメッセージは、本文をさらに含む、項目１に記載の方法。
（項目１１）
上記ＳＩＰメッセージは、Ｃｏｎｔｅｎｔ−Ｄｉｓｐｏｓｉｔｉｏｎに「ａｔｔａｃｈｍｅｎｔ」をさらに含む、項目１０に記載の方法。
（項目１２）
上記ＳＩＰメッセージは、
上記プッシュ受信側エージェントのモデルと、
該プッシュ受信側エージェントの供給元と、
該プッシュ受信側エージェントのバージョンと
のうちの少なくとも１つを含む、Ｕｓｅｒ−Ａｇｅｎｔヘッダをさらに含む、項目１に記載の方法。
（項目１３）
上記ＳＩＰメッセージは、ＳＩＰ  ＯＰＴＩＯＮＳ要求である、項目１に記載の方法。
（項目１４）
上記ＳＩＰメッセージは、ＳＩＰ  ２００  ＯＫ応答である、項目１に記載の方法。
（項目１５）
セッション初期化プロトコル（ＳＩＰ）プッシュ受信側エージェントであって、
該プッシュ受信側エージェントが、少なくとも１つのプッシュリソースを含むプッシュリソース識別子機能タグを含むＣｏｎｔａｃｔヘッダを含むＳＩＰメッセージを送信するように構成される構成要素を備える、プッシュ受信側エージェント。
（項目１６）
上記Ｃｏｎｔａｃｔヘッダはさらに、Ｇｌｏｂａｌｌｙ  Ｒｏｕｔａｂｌｅ  ＵＡ  Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ（ＵＲＩ）（ＧＲＵＵ）を含む、項目１５に記載のプッシュ受信側エージェント。
（項目１７）
上記ＳＩＰメッセージはさらに、多目的インターネットメール拡張（ＭＩＭＥ）型「ｍｅｓｓａｇｅ／ｅｘｔｅｒｎａｌ−ｂｏｄｙ」を含む、ヘッダを含む、項目１５に記載のプッシュ受信側エージェント。
（項目１８）
上記ヘッダはさらに、上記プッシュ受信側エージェントのＯｐｅｎ  Ｍｏｂｉｌｅ  Ａｌｌｉａｎｃｅ（ＯＭＡ）ＵＡプロファイルドキュメントを指し示すＵＲＩを含む、項目１７に記載のプッシュ受信側エージェント。
（項目１９）
上記ヘッダは、Ａｃｃｅｐｔヘッダである、項目１７に記載のプッシュ受信側エージェント。
（項目２０）
上記ヘッダは、Ａｃｃｅｐｔヘッダである、項目１８に記載のプッシュ受信側エージェント。
（項目２１）
上記ヘッダは、Ｃｏｎｔｅｎｔ−Ｔｙｐｅヘッダである、項目１７に記載のプッシュ受信側エージェント。
（項目２２）
上記ヘッダは、Ｃｏｎｔｅｎｔ−Ｔｙｐｅヘッダである、項目１８に記載のプッシュ受信側エージェント。
（項目２３）
上記ＳＩＰメッセージは、上記プッシュ受信型エージェントによってサポートされるＳＩＰ方法を含むＡｌｌｏｗヘッダをさらに含む、項目１５に記載のプッシュ受信側エージェント。
（項目２４）
上記ＳＩＰメッセージは、本文をさらに含む、項目１５に記載のプッシュ受信側エージェント。
（項目２５）
上記ＳＩＰメッセージは、Ｃｏｎｔｅｎｔ−Ｄｉｓｐｏｓｉｔｉｏｎに「ａｔｔａｃｈｍｅｎｔ」をさらに含む、項目２４に記載のプッシュ受信側エージェント。
（項目２６）
上記ＳＩＰメッセージは、
上記プッシュ受信側エージェントのモデルと、
該プッシュ受信側エージェントの供給元と、
該プッシュ受信側エージェントのバージョンと
のうちの少なくとも１つを含む、Ｕｓｅｒ−Ａｇｅｎｔヘッダをさらに含む、項目１５に記載のプッシュ受信側エージェント。
（項目２７）
上記ＳＩＰメッセージは、ＳＩＰ  ＯＰＴＩＯＮＳ要求である、項目１５に記載のプッシュ受信側エージェント。
（項目２８）
ＳＩＰ  ＯＰＴＩＯＮＳ要求を受信した際に、送信側の能力に関する情報を含む、ＳＩＰ  ２００  ＯＫ応答が送信される、項目１５に記載のプッシュ受信側エージェント。
（項目２９）
上記ＳＩＰメッセージは、ＳＩＰ  ２００  ＯＫ応答である、項目１５に記載のプッシュ受信側エージェント。
（項目３０）
セッション初期化プロトコル（ＳＩＰ）プッシュ送信側エージェントであって、
該プッシュ送信側エージェントが、少なくとも１つのプッシュリソースを含むプッシュリソース識別子機能タグを含むＣｏｎｔａｃｔヘッダを含むＳＩＰメッセージを受信するように構成される構成要素を備える、プッシュ送信側エージェント。
（項目３１）
上記Ｃｏｎｔａｃｔヘッダはさらに、Ｇｌｏｂａｌｌｙ  Ｒｏｕｔａｂｌｅ  ＵＡ  Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ（ＵＲＩ）（ＧＲＵＵ）を含む、項目３０に記載のプッシュ送信側エージェント。
（項目３２）
上記ＳＩＰメッセージはさらに、多目的インターネットメール拡張（ＭＩＭＥ）型「ｍｅｓｓａｇｅ／ｅｘｔｅｒｎａｌ−ｂｏｄｙ」を含む、ヘッダを含む、項目３０に記載のプッシュ送信側エージェント。
（項目３３）
上記ヘッダはさらに、上記メッセージを送信したプッシュ受信側エージェントのＯｐｅｎ  Ｍｏｂｉｌｅ  Ａｌｌｉａｎｃｅ（ＯＭＡ）ＵＡプロファイルドキュメントを指し示すＵＲＩを含む、項目３２に記載のプッシュ送信側エージェント。
（項目３４）
上記ヘッダは、Ａｃｃｅｐｔヘッダである、項目３２に記載のプッシュ送信側エージェント。
（項目３５）
上記ヘッダは、Ａｃｃｅｐｔヘッダである、項目３３に記載のプッシュ送信側エージェント。
（項目３６）
上記ヘッダは、Ｃｏｎｔｅｎｔ−Ｔｙｐｅヘッダである、項目３２に記載のプッシュ送信側エージェント。
（項目３７）
上記ヘッダは、Ｃｏｎｔｅｎｔ−Ｔｙｐｅヘッダである、項目３３に記載のプッシュ送信側エージェント。
（項目３８）
上記ＳＩＰメッセージは、上記メッセージを送信したプッシュ受信側エージェントによってサポートされるＳＩＰ方法を含むＡｌｌｏｗヘッダをさらに含む、項目３０に記載のプッシュ送信側エージェント。
（項目３９）
上記ＳＩＰメッセージは、本文をさらに含む、項目３０に記載のプッシュ送信側エージェント。
（項目４０）
上記ＳＩＰメッセージは、Ｃｏｎｔｅｎｔ−Ｄｉｓｐｏｓｉｔｉｏｎに「ａｔｔａｃｈｍｅｎｔ」をさらに含む、項目３９に記載のプッシュ送信側エージェント。
（項目４１）
上記ＳＩＰメッセージは、
上記メッセージを送信したプッシュ受信側エージェントのモデルと、
該メッセージを送信した該プッシュ受信側エージェントの供給元と、
該メッセージを送信した該プッシュ受信側エージェントのバージョンと
のうちの少なくとも１つを含むＵｓｅｒ−Ａｇｅｎｔヘッダをさらに含む、項目３０に記載のプッシュ送信側エージェント。
（項目４２）
上記ＳＩＰメッセージは、ＳＩＰ  ＯＰＴＩＯＮＳ要求である、項目３０に記載のプッシュ送信側エージェント。
（項目４３）
上記ＳＩＰ  ＯＰＴＩＯＮＳ要求を受信した際に、送信側の能力に関する情報を含む、ＳＩＰ  ２００  ＯＫ応答が送信される、項目４２に記載のプッシュ送信側エージェント。
（項目４４）
上記ＳＩＰメッセージは、ＳＩＰ  ２００  ＯＫ応答である、項目３０に記載のプッシュ送信側エージェント。
【国際調査報告】
2011527534.tif 000006
2011527534.tif 000007