JP2010528507A - 複数の端末を使用してサービスメッセージを処理する方法、システム、及び装置 - Google Patents

Abstract

複数の端末を使用してビジネスメッセージを処理する方法、システム、及び装置が開示される。方法は、端末から、端末の要求情報を運ぶリクエストメッセージを受信するステップと、要求情報に従って端末にビジネスメッセージを送信するステップとを含む。ユーザが複数の端末を有する場合、プッシュ伝送エージェントは、端末からの通知予約リクエストと、通知予約リクエストによって運ばれる端末要求情報とに従って、特定の端末を選択する。ビジネスが到来した場合、ビジネスメッセージは、選択された端末のみに送信され、その結果、ユーザのすべての端末にビジネスメッセージを送信することが回避される。

Description

本出願は、２００７年１１月１３日出願の中国特許出願第２００７１０１６９４２７．４号の優先権を主張する２００８年１１月１１日出願の国際出願第ＰＣＴ／ＣＮ２００８／０７３０１６号の継続出願であり、当該出願の内容はその全体が参照によって本明細書に援用される。

本発明は、移動通信技術に関し、特に、１人のユーザの複数の端末を使用してサービスメッセージを処理する方法、システム、及び装置に関する。

プッシュ技術（Ｐｕｓｈ技術）は、サーバがクライアントに能動的に情報を送信する、クライアント−サーバメカニズムに基づく技術である。プッシュ技術は、モバイル付加価値サービス（ＶＡＳ）において、適切なコンテンツを遅れずに転送するため、及び、ユーザがコンテンツを好都合に取得するのを助けるために適用される。プッシュメカニズムは、コンテンツ配信メカニズムであり、クライアント−サーバモードで動作し、このモードでは、サーバが、クライアントからの要求を受信することなしに、クライアントによって所望されるコンテンツをクライアントに配信する。図１は、従来技術におけるプッシュサービスを示す。サービスは、サーバによって開始される。プッシュメッセージを生成するプッシュイニシエータ（ＰＩ）は、プッシュプロキシゲートウェイ（ＰＰＧ）に情報をプッシュし、且つ、命令を伝送し、プッシュコンテンツは、更に、ＰＰＧによってユーザに伝送される。システムは、ＰＰＧと、ＰＩと、端末とを備えている。ＰＰＧは、プッシュサーバから、パスワード認証プロトコル（ＰＡＰ）を介してメッセージを取得し、コンテンツを、ワイヤレスアプリケーションプロトコル（ＷＡＰ）ユーザに、プッシュ・オーバー・ジ・エア（ＯＴＡ）プロトコルを介して送信する。ＰＩは、ＰＰＧに、プッシュコンテンツと転送コマンドとを送信し、ＰＰＧは、転送コマンドに従って、端末にプッシュコンテンツを転送する。

図２は、従来技術におけるセッション開始プロトコル（ＳＩＰ）プッシュサービスを示す。ＳＩＰプッシュサービスは、オープンモバイルアライアンス（ＯＭＡ）によって規定された、ＳＩＰサービス上のプッシュＯＴＡであり、このサービスでは、プッシュＯＴＡコンテンツがＳＩＰメッセージ内にカプセル化されて、既存のＳＩＰ／ＩＰコアネットワークを介して転送される。ＳＩＰは、２つ以上の参加者間のマルチメディアセッションをセットアップするための、アプリケーション層プロトコルである。ＰＰＧとクライアントとは、ＳＩＰ／ＩＰコアネットワークのインタフェース点として働く。ＳＩＰプッシュプロセスにおいて、ＳＩＰは次の機能を提供することが可能である。ユーザ到達可能性（ｕｓｅｒ ｒｅａｃｈａｂｉｌｉｔｙ）、ユーザアベイラビリティ（ｕｓｅｒ ａｖａｉｌａｂｉｌｉｔｙ）、ユーザケーパビリティ（ｕｓｅｒ ｃａｐａｂｉｌｉｔｉｅｓ）、セッションセットアップ（ｓｅｓｓｉｏｎ ｓｅｔｕｐ）、及びセッションマネジメント（ｓｅｓｓｉｏｎ ｍａｎａｇｅｍｅｎｔ）。

ＳＩＰ／ＩＰコアネットワークは、豊富なエンドツーエンドメディアセッション及びクライアントとサーバとの間のセッションを提供する。ＳＩＰ／ＩＰコアネットワークは、ＳＩＰゲートウェイと登録サーバとを含み、サービスの認証及び認可をＳＩＰクライアントに提供し、そして、ＳＩＰ登録及びルーティング機能を提供する。ＰＰＧとプッシュクライアントとは、機能において、ＳＩＰ／ＩＰコアへのインタフェース点である。

ＳＩＰをベースにしたイベント通知予約メカニズムすなわちＳＩＰイベントフレームワークは、通知予約プロセスにおける、非同期イベントの通知の許可を規定する。初期登録の後で、プッシュクライアントは、ＰＰＧに、ＳＵＢＳＣＲＩＢＥリクエストを送信しなければならない。プッシュクライアントが、例えばクライアントケーパビリティ情報の転送あるいは特定のイベントの通知予約などの、特定のプッシュサービスについてのプッシュイベントの通知予約を行う必要がある場合、ＰＰＧとプッシュクライアントとは、ＳＵＢＳＣＲＩＢＥメソッドとＮＯＴＩＦＹメソッドとをサポートすることが期待される。特に、プッシュクライアントは、特定のプッシュコンテンツについてのＳＵＢＳＣＲＩＢＥ機能をサポートしなければならず、且つ、プッシュコンテンツの受信をサポートしなければならない。ＰＰＧはＮＯＴＩＦＹ機能をサポートしなければならず、ＰＰＧを介して、ＳＵＢＳＣＲＩＢＥリクエストがプッシュクライアントから受信され、プッシュ情報がクライアントに送信される。

ユーザＩＤは、パブリックユーザアイデンティティである。１つ以上のパブリックユーザアイデンティティが、１人のユーザに、ネットワークを使用するために割り当てられる。ユーザは、別のユーザと通信することを要求する場合、パブリックユーザアイデンティティを使用する。１人のユーザは、さまざまなアピアランス（ａｐｐｅａｒａｎｃｅ）を有してもよい。各アピアランスは、さまざまなパブリックユーザアイデンティティを含む。パブリックユーザアイデンティティのフォーマットは、階層的なＳＩＰユニフォームリソース識別子（ＵＲＩ）である。ＳＩＰ ＵＲＩは、電話番号又はホスト名を介して構成されてもよい（ＳＩＰ：ｕｓｅｒ＠ｃｏｍｐａｎｙ．ｃｏｍなど）。ＳＩＰ ＵＲＩは、電子メールアドレスに類似しており、したがって、ユーザの電子メールアドレスと容易に関連付けられる。

しかし、コンピュータ、２Ｇ端末、又は３Ｇ端末などの、多くの端末をユーザが有する場合、ホームネットワークは、各端末に装置ＩＤを割り当てる。装置ＩＤは、ネットワーク内での各端末の一意性を制御する。例えば、装置ＩＤは、認証、認可、及び管理のために使用される。

プッシュクライアントは、通知予約を更新するため、及び、「ａｐｐｉｄ」パラメータを介して、使用可能なアプリケーションとバージョンを宣言するために、ＳＵＢＳＣＲＩＢＥリクエストを送信してもよい。

プッシュクライアントが１つのみのアプリケーション（例えば、マルチメディアメッセージサービス（ＭＭＳ）である「ａｐｐ１」）の通知予約を行う場合、ＳＵＢＳＣＲＩＢＥリクエストは、次のとおりである。
ＳＵＢＳＣＲＩＢＥ ｓｉｐ：ｕｓｅｒ−ａｏｒ＠ｅｘａｍｐｌｅ．ｃｏｍ ＳＩＰ／２．０
Ｅｖｅｎｔ：ｕａ−ｐｒｏｆｉｌｅ；ｐｒｏｆｉｌｅ−ｔｙｐｅ＝ｏｍａ−ａｐｐ；ａｐｐｉｄ＝”＋ｇ．ｏｍａ．ｉａｒｉ．Ｐｕｓｈ．ｍｍｓ．ｕａ”；

プッシュクライアントが複数のアプリケーション（例えば、ａｐｐ１、ａｐｐ２、ａｐｐ３）の通知予約を行う場合、ＳＵＢＳＣＲＩＢＥリクエストは、次のとおりである。
ＳＵＢＳＣＲＩＢＥ ｓｉｐ：ｕｓｅｒ−ａｏｒ＠ｅｘａｍｐｌｅ．ｃｏｍ ＳＩＰ／２．０
Ｅｖｅｎｔ：ｕａ−ｐｒｏｆｉｌｅ；ｐｒｏｆｉｌｅ−ｔｙｐｅ＝ｏｍａ−ａｐｐ；ａｐｐｉｄ＝”ａｐｐ１，ａｐｐ２，ａｐｐ３”；

プッシュクライアントがａｐｐ１、ａｐｐ２、及びａｐｐ３の通知予約を行い、しかし、ＰＰＧはａｐｐ１及びａｐｐ２のみをサポートする場合、ＰＰＧによって返されるＮＯＴＩＦＹメッセージは、ａｐｐ１及びａｐｐ２の、２つのみのパラメータを含み、２つのアプリケーションサービスが正常に通知予約されたことを示す。ＳＵＢＳＣＲＩＢＥリクエスト及びＮＯＴＩＦＹメッセージは、次のとおりである。
ＳＵＢＳＣＲＩＢＥ ｓｉｐ：ｕｓｅｒ−ａｏｒ＠ｅｘａｍｐｌｅ．ｃｏｍ ＳＩＰ／２．０
Ｅｖｅｎｔ：ｕａ−ｐｒｏｆｉｌｅ；ｐｒｏｆｉｌｅ−ｔｙｐｅ＝ｏｍａ−ａｐｐ；ｐｐｉｄ＝”ａｐｐ１，ａｐｐ２，ａｐｐ３”；
ＮＯＴＩＦＹ
Ｅｖｅｎｔ：ｕａ−ｐｒｏｆｉｌｅ；ｐｒｏｆｉｌｅ−ｔｙｐｅ＝ｏｍａ−ａｐｐ；ａｐｐｉｄ＝”ａｐｐ１，ａｐｐ２”；

ユーザがＭＭＳの通知予約を行った場合、端末向けのＭＭＳをＰＰＧが受け取ったら、ＭＭＳ通知がユーザの端末に送信される。通知は、着信ＭＭＳメッセージをユーザが有しており、そのメッセージをユーザがＰＰＧから取り出してもよい、ということを示す。ユーザは、自動的にＭＭＳメッセージを取り出して端末上に記憶するように、端末を設定してもよく、又は、ＭＭＳ通知を受信した後の好都合な時にメッセージを取り出してもよい。

ＳＩＰプッシュサービスでは、現在のところ、同じユーザが複数の端末を有してもよい。例えば、ユーザは、２Ｇ携帯電話と、３Ｇ携帯電話と、デスクトップコンピュータと、ノートブックコンピュータとを同時に有する。ＰＰＧは、ユーザを識別するためにパブリックユーザアイデンティティを記憶する。ＰＰＧは、各装置向けの呼又はメッセージを送信するために、端末を識別するための、端末の装置アドレスも記憶する。ＰＰＧは、各端末が通知予約を行った、特定のサービスに関する情報も記憶する。複数の端末によって通知予約された、いずれかのサービスが到来した場合、すべての端末がサービスを受信してもよい。通知予約に応じることができるサービスとしては、ＭＭＳ、ショートメッセージサービス（ＳＭＳ）、電子メール通知、及び装置管理が挙げられる。ＰＰＧがＳＩＰ／ＩＰコアネットワークを介してユーザにＭＭＳメッセージを送信する場合、ＭＭＳの通知予約を行った各ユーザ端末が、ＭＭＳメッセージの通知を受信する、というシナリオが存在する。

図３は、従来技術における、ユーザが複数の端末を有する場合の、ＭＭＳ通信のフローチャートである。ユーザが第１の端末と第２の端末と第３の端末とを同時に有する場合、マルチメディアメッセージサービスセンター（ＭＭＳＣ）はＰＩであり、ＰＰＧはＰＰＧである。フローは以下のステップを含む。

ステップＳ３０１：ＭＭＳＣは、ユーザ向けのＭＭＳ通知メッセージを有し、ＰＰＧにＭＭＳ通知を送信する。ＭＭＳ通知を受信した後で、ＰＰＧは、ユーザが３つの端末を有することを見出し、したがって、３つの端末のそれぞれに通知を転送する。

ステップＳ３０２：ユーザは、通知されたＭＭＳメッセージの自動取り出しを設定し、したがって、３つの端末はそれぞれ、ＭＭＳＣ ＰＰＧに、ハイパーテキスト転送プロトコル（ＨＴＴＰ）ＧＥＴメッセージを送信して、ＭＭＳメッセージの取り出しを要求する。

ステップＳ３０３：第１の端末からＧＥＴメッセージを受信した後で、ＰＰＧは、第１の端末に、ＭＭＳメッセージを運ぶＨＴＴＰ ２００ ＯＫレスポンスを送信する。

ステップＳ３０４：ＭＭＳＣ ＰＰＧは、第１の端末によってすでに取り出されたＭＭＳメッセージを削除し、そして、第２の端末と第３の端末とは、ＭＭＳＣによって返されたＨＴＴＰ ４ｘｘエラーレスポンスを受信する。ＭＭＳ通知は、ＳＩＰ／ＩＰコアネットワークによって３つの端末に転送されてもよい。

本発明を実現するプロセスにおいて、発明者は、従来技術における少なくとも以下の欠点を見出した。

ユーザの各端末は同じＭＭＳ通知を受信し、これにより、リソースの浪費がもたらされ、且つ、ネットワーク伝送負荷が増加する。その上、ユーザは同じ情報を重ねて受信しなければならない。更に悪いことに、ＭＭＳＣは、ユーザによって現在保持されている端末の数を認識しない。ＭＭＳＣが通知を送信した後で、ＰＰＧ又はＳＩＰ／ＩＰコアネットワークが、ユーザの各端末に通知を転送する。ユーザが、ＰＰＧからのＭＭＳメッセージの自動取り出しを設定した場合、１つのみの端末がＭＭＳメッセージを正常に取り出すことができる。残りの端末はメッセージの取り出しに失敗するか、又は、ＭＭＳＣがユーザに、メッセージが存在しないこと、又は、すでに取り出されたことを知らせる。したがって、ユーザ体験は悪化する。

同じユーザＩＤを有するすべての端末にＰＰＧがサービスメッセージを送信し、したがって、リソースが浪費され、ネットワーク伝送負荷が増加し、ユーザ体験が悪化するという、従来技術における欠点を克服するために、本発明の実施形態では、ユーザの複数の端末を使用してサービスメッセージを処理する方法、システム、及び装置が提供される。

前述の目的を達成するために、本発明の一実施形態では、１人のユーザの複数の端末を使用してサービスメッセージを処理する方法が提供される。方法は、端末から、端末の要求情報を運ぶリクエストメッセージを受信し、要求情報に従って端末にサービスメッセージを送信することを含む。

更に、本発明の一実施形態では、１人のユーザの複数の端末を使用してサービスメッセージを処理するシステムが提供される。システムは、ＰＰＧと、同じユーザＩＤを有する少なくとも２つの端末とを含む。端末は、ＰＰＧに、端末の要求情報を運ぶリクエストメッセージを送信するように構成される。ＰＰＧは、端末からリクエストメッセージを受信し、要求情報に従って端末にサービスメッセージを送信するように構成される。

更になお、本発明の一実施形態では、ＰＰＧが提供される。ＰＰＧは、
端末から、端末の要求情報を運ぶリクエストメッセージを受信するように構成された、リクエスト受信モジュールと、
サービスが到来した場合に、要求情報に従って端末にサービスメッセージを送信するように構成された、処理モジュールとを含む。

従来技術と比較すると、本発明による技術的解決法は、以下の利点を有する。

ＰＰＧは、すべての端末にサービスメッセージを送信するのではなく、端末によって送信された要求情報に従って、特定の端末に、対応するサービスメッセージのみを送信する必要がある。したがって、同じユーザの複数の端末が同じサービスメッセージを重ねて受信する必要はなく、リソースの浪費が回避される。

従来技術におけるプッシュサービスの概略図である。 従来技術におけるＳＩＰプッシュサービスの概略図である。 従来技術における、ユーザが複数の端末を有する場合の、ＭＭＳ通信のフローチャートである。 本発明の一実施形態における、サービス通知予約リクエストを送信するフローチャートである。 本発明の一実施形態における、ユーザによって送信されるＳＵＢＳＣＲＩＢＥリクエストの概略図を示す。 本発明の一実施形態における、２００ ＯＫメッセージの概略図を示す。 本発明の一実施形態における、サービス通知予約の活性化指示の概略図を示す。 本発明の一実施形態における、第２の端末のリクエストの概略図を示す。 本発明の一実施形態における、省略可能なステップのフローチャートである。 本発明の別の実施形態における、ＳＵＢＳＣＲＩＢＥリクエストを使用して１つのみのサービスの通知予約を行うフローチャートである。 本発明の別の実施形態における、ユーザによって送信されるＳＵＢＳＣＲＩＢＥリクエストの概略図を示す。 本発明の別の実施形態における、ＭＭＳ通知予約の活性化の概略図を示す。 本発明の別の実施形態における、第２の端末による通知予約の概略図を示す。 本発明の別の実施形態における、サービス通知予約の活性化の概略図を示す。 本発明の別の実施形態における、ＳＵＢＳＣＲＩＢＥリクエストを使用して複数のサービスの通知予約を行うフローチャートである。 本発明の別の実施形態における、第１の端末によってＰＰＧに送信されるＳＵＢＳＣＲＩＢＥリクエストの概略図を示す。 本発明の別の実施形態における、活性化指示の概略図を示す。 本発明の別の実施形態における、第２の端末による通知予約の概略図を示す。 本発明の別の実施形態における、第２の端末によるサービス通知予約の活性化の概略図を示す。 本発明の別の実施形態における、サービスを受信するために、より高い優先度の装置をＰＰＧが選択する方法を示すフローチャートである。 本発明の別の実施形態における、ユーザによって送信されるＳＵＢＳＣＲＩＢＥリクエストの概略図を示す。 本発明の別の実施形態における、２００ ＯＫメッセージの概略図を示す。 本発明の別の実施形態における、サービス通知予約の活性化の概略図を示す。 本発明の別の実施形態における、ＨＴＴＰを介してＰＰＧにサービスリクエストを送信するフローチャートである。 本発明の別の実施形態における、１人のユーザの複数の端末を使用してサービスメッセージを処理するシステムの構成を示す。

本発明の実施形態について、添付の図面を参照しながら、以下で詳細に説明する。

本発明の実施形態は、プッシュメカニズムにおいて複数の端末を使用して同じメッセージを受信する方法を取り扱う。本明細書では複数の解決法が提案され、それは、通知予約プロセスにおいて、ＳＩＰプッシュは、１つのみの端末が特定のサービスの通知予約を行うことができることを要求する、という解決法、又は、通知予約において、特定のサービスについての優先度が設定される必要がある、という解決法である。このようにして、複数の端末を有するユーザに送信される特定のサービスメッセージをＰＰＧが有する場合、すべての端末ではなく、対応する装置ＩＤの端末が、サービスメッセージを受信するために選択される。したがって、ネットワークリソースの浪費が回避され、１人のユーザの複数の端末が同じメッセージを重ねて受信する必要はなく、そして、同じメッセージの重ねての受信によってその他のサービスの受信が影響を及ぼされることはない。特定のサービスに応じて、実装は以下のモードに分類される。

１．通知予約プロセスにおいて、１人のユーザのすべての端末のうち、１つのみの端末が、サービスの通知予約を行うことを許可される。すなわち、現在の端末がすでにサービスの通知予約を行っている場合、そのユーザの別の端末が同じサービスの通知予約を行うことを要求すると、サービスはすでに通知予約されているためサービスは利用できないということを、ＰＰＧは端末に通知する。

２．第１の端末が正常にサービスの通知予約を行った後で、その他の端末に、サービスはすでに通知予約されているということを示す通知が送信される。このようにして、重ねての通知予約が回避され、サービスは１つのみの端末によって通知予約される。

３．すべての端末が、サービスの通知予約を行うことを許可される。通知予約プロセスにおいて、端末の優先度が設定される。優先度ポリシーはＰＰＧ上に記憶され、ＰＰＧはメッセージの配送を制御する。したがって、このサービスが到来した場合、１つのみの端末が最初にサービスメッセージを受信し、その他の端末が同時にサービスメッセージを受信することはない。

４．すべての端末が、サービスの通知予約を行うことを許可される。ＰＰＧが端末の優先度を設定する。ネットワーク状態に応じて、ＰＰＧは、サービスメッセージを受信するための端末を選択し、その他の端末が同時にサービスメッセージを受信することはない。

ユーザ情報、端末情報、又はサービス通知予約情報は、ＲＥＧＩＳＴＥＲリクエスト及び／又はＳＵＢＳＣＲＩＢＥリクエストを介してＰＰＧに送信されてもよい。

ＳＵＢＳＣＲＩＢＥリクエストを例に取って、前述のモードにおける本発明の実施形態を、以下で詳細に説明する。要求情報を運ぶメッセージは、ＳＵＢＳＣＲＩＢＥリクエストに限定されない。この機能が可能なその他のメッセージは、本発明の保護範囲に含まれる。

一実施形態
図４は、本発明の一実施形態における、サービス通知予約リクエストを送信するフローチャートである。第１の端末と第２の端末とは、同じユーザの、２つの異なる装置である。この実施形態では、１つのみの端末が、サービスの通知予約を行うことを許可される。すなわち、現在の端末がすでにサービスの通知予約を行っている場合、ユーザの別の端末が同じサービスの通知予約を行うことを要求すると、サービスはすでに通知予約されているため利用できないということを、ＰＰＧが端末に通知する。ユーザの、異なる端末は、国際移動電話加入者識別番号（ＩＭＳＩ）、プライベートユーザＩＤ（アイデンティティ）、グローバルにルーティング可能なユーザエージェントＵＲＩ（ＧＲＵＵ）、複数のコンタクト情報、ＩＰアドレス、電話番号、又は装置番号によって区別されてもよい。詳細なステップは、以下のとおりである。

ステップＳ４０１：この実施形態では、ユーザ「ｊｏｈｎ．ｄｏｅ＠ｈｏｍｅ１．ｎｅｔ」を例に取ると、ユーザ「ｊｏｈｎ．ｄｏｅ＠ｈｏｍｅ１．ｎｅｔ」の第１の端末が、ＰＰＧに、ＳＵＢＳＣＲＩＢＥリクエストを送信する。このリクエストは、ユーザＩＤと、装置ＩＤと、アプリケーションＩＤとを運び、そして、ＭＭＳサービスの通知予約を行うことを意図するものである。

図５は、本発明の実施形態における、ユーザによって送信されるＳＵＢＳＣＲＩＢＥリクエストを示す。最初に、ＰＰＧは、ユーザの、ユーザＩＤと、装置ＩＤと、アプリケーションＩＤとを識別する。そのようなＩＤが正しいものとして識別された後で、第１の端末は、ＰＰＧに、ＭＭＳサービスの通知予約を行うためのリクエストを送信する。リクエストが受け入られた後で、装置ＩＤがデータベース内に書き込まれる。この装置ＩＤは、端末間を区別してもよい。

ステップＳ４０２：「ｕａ＿ｐｒｏｆｉｌｅ」イベントパッケージのＳＩＰ ＳＵＢＳＣＲＩＢＥリクエストが受信された後で、ＰＰＧは、イニシエータのアイデンティティを認証し、そして、ユーザが現在の装置を介してサービスの通知予約を行うことを許可されるかどうかを、ローカルルールに従って判定する。認証に成功した場合、ＰＰＧは、「ｕａ＿ｐｒｏｆｉｌｅ」イベントパッケージの通知予約セッションを作成し、「Ｅｖｅｎｔ」ヘッダフィールドパラメータに従って、データの変更を識別するためのメソッドを提供し、次に、第１の端末に２００ ＯＫメッセージを返す。このステップにおける２００ ＯＫメッセージを図６に示す。

ステップＳ４０３：ＰＰＧは、空のボディを運び、かつ、サービス通知予約が活性化されたことを示す最初のＳＩＰ ＮＯＴＩＦＹメッセージを、生成して送信する。図７は、本発明の実施形態における、サービス通知予約の活性化指示を示す。通知予約されたＭＭＳサービスを有効にするためには、このステップにおいて、ＭＭＳサービスの通知予約が活性化される必要がある。

ステップＳ４０４：第１の端末上のプッシュクライアントは、２００ ＯＫメッセージを使用して応答する。

ＰＰＧは、サービスリクエストを受信した場合、ＳＩＰ ＮＯＴＩＦＹメッセージにプッシュコンテンツを追加することによって、プッシュコンテンツを提出する。ＳＩＰ ＮＯＴＩＦＹメッセージは、サービスリクエストを送信した端末に送信される。

ステップＳ４０５：ユーザの第２の端末が、ＭＭＳサービスの通知予約を行うためのリクエストを送信する。第２の端末のパブリックユーザアイデンティティは、「ｊｏｈｎ．ｄｏｅ＠ｈｏｍｅ１．ｎｅｔ」であり、第２の端末の装置ＩＤは、第１の端末の装置ＩＤとは異なる。図８は、本発明の実施形態における、第２の端末のリクエストを示す。このステップは、使用される装置がステップＳ４０１とは異なる。すなわち、装置ＩＤが異なる。装置ＩＤは、リクエストを送信する装置を識別する。

ステップＳ４０６：ＰＰＧは、ユーザのパブリックユーザアイデンティティがやはり「ｊｏｈｎ．ｄｏｅ＠ｈｏｍｅ１．ｎｅｔ」であることと、通知予約されるサービスがやはりＭＭＳであることと、ユーザが別の装置を介してＭＭＳサービスの通知予約をすでに行っていることとを見出す。したがって、ＰＰＧは、４ＸＸレスポンスを返して、サービスはすでに正常に通知予約されているため利用できないということを示す。

ユーザの第１の端末は、ＰＰＧからのＭＭＳサービスの通知予約をすでに行っている。したがって、ＰＰＧは、ユーザがＭＭＳサービスの通知予約をすでに行っていると判定し、ユーザの第２の端末に４ＸＸレスポンスを返す。

この実施形態における省略可能なステップは、次のとおりである。第１の端末が正常にサービスの通知予約を行った後で、ＰＰＧは、すべての登録されている端末にＮＯＴＩＦＹメッセージを送信して、サービスはすでに正常に通知予約されており、さらなる通知予約は必要ないということを示す。その他の端末のアドレスは、ＰＰＧ又はＳＩＰ／ＩＰコアネットワーク内に記憶されていてもよく、そして、各端末の登録時にユーザに結び付けてもよい。そのようなアドレスを介して、メッセージは、ユーザのすべての端末に通知されてもよい。

図９は、以下で詳細に説明する、本発明の実施形態における、省略可能なステップのフローチャートである。

ステップＳ９０１：ユーザ「ｊｏｈｎ．ｄｏｅ＠ｈｏｍｅ１．ｎｅｔ」の第１の端末は、ＰＰＧに、ＳＵＢＳＣＲＩＢＥリクエストを送信する。このリクエストは、ユーザＩＤと、装置ＩＤと、アプリケーションＩＤとを運び、そして、ＭＭＳサービスの通知予約を行うことを意図するものである。

ステップＳ９０２：「ｕａ＿ｐｒｏｆｉｌｅ」イベントパッケージのＳＩＰ ＳＵＢＳＣＲＩＢＥリクエストが受信された後で、ＰＰＧは、イニシエータのアイデンティティを確認し、そして、ユーザが現在の装置を介してサービスの通知予約を行うことを許可されるかどうかを、ローカルルールに従って判定する。認証に成功した場合、ＰＰＧは、「ｕａ＿ｐｒｏｆｉｌｅ」イベントパッケージの通知予約セッションを作成し、「Ｅｖｅｎｔ」ヘッダフィールドパラメータに従って、データの変更を識別するためのメソッドを提供し、次に、第１の端末に２００ ＯＫメッセージを返す。

ステップＳ９０３：ＰＰＧは、空のボディを運び、かつ、サービス通知予約が活性化されたことを示す最初のＳＩＰ ＮＯＴＩＦＹメッセージを、生成して送信する。

ステップＳ９０４：第１の端末上のプッシュクライアントは、２００ ＯＫメッセージを使用して応答する。

ステップＳ９０５：ＰＰＧは、その他の端末に、ＮＯＴＩＦＹメッセージを送信する。ＮＯＴＩＦＹメッセージのヘッダフィールド又はボディは、ＭＭＳサービスが第１の端末によって正常に通知予約されており、その他の端末が利用することはできないということを示す情報を運ぶ。

ステップＳ９０６：その他の端末は、２００ ＯＫメッセージを返して、リクエストが受け入れられたことを示す。

この実施形態の通知予約プロセスにおいて、ＳＩＰプッシュメカニズムは、特定のサービスの通知予約を１つのみの端末が行うことを許可する。したがって、ＰＰＧが、ユーザに送信される特定のサービスメッセージを有する場合、ユーザのすべての装置ではなく、この許可された端末のみがメッセージを受信することができ、かくして、ネットワークリソースの浪費が回避される。

別の実施形態
図１０は、本発明の実施形態における、ＳＵＢＳＣＲＩＢＥリクエストが１つのみのサービスの通知予約を意図するものである場合の、コマンド伝送のフローチャートである。この実施形態において示される第１の端末と第２の端末とは、同じユーザの、２つの異なる装置である。第１の端末が、ＰＰＧに、サービスの通知予約を行うためのリクエストを送信する場合、第１の端末はパブリックユーザＩＤとプライベートユーザＩＤとによって識別され、そして、リクエストは優先度パラメータ「Ｑｖａｌｕｅ」を運ぶ。優先度パラメータは以下のことを指示する。通知予約されたサービスについて、ＰＰＧは、最も高い優先度の端末にサービスを送信し、サービスが正常に送信された場合、ＰＰＧは、その後、第２の端末にサービスを送信することはなく、サービスが正常に送信されなかった場合、ＰＰＧは、次の優先度の端末にサービスを送信し、以下同様である。

サービスの実装において、端末は、ＳＵＢＳＣＲＩＢＥリクエストを送信する際に、ＰＰＧに優先度リストを提出する。したがって、ユーザによって所望される端末が、最初にサービスメッセージを受信する。より高いＱｖａｌｕｅは、所与の位置の、より高い重要性を示す。Ｑｖａｌｕｅの範囲は、０〜１であってもよい。

ユーザの、異なる端末は、ＩＭＳＩ、プライベートユーザＩＤ、ＧＲＵＵ、複数のコンタクト情報、ＩＰアドレス、電話番号、又は装置番号によって区別されてもよい。この実施形態は、２つの解決法を介して実装される。ＳＵＢＳＣＲＩＢＥリクエストが、１つのみのサービスの通知予約を行うためのリクエストである場合（すなわち、１つのみのアプリケーションＩＤが存在する場合）、ステップは以下のとおりである。

ステップＳ１００１：ユーザ「ｊｏｈｎ．ｄｏｅ＠ｈｏｍｅ１．ｎｅｔ」の第１の端末は、ＰＰＧに、ＳＵＢＳＣＲＩＢＥリクエストを送信する。このリクエストは、ユーザＩＤと、装置ＩＤと、Ｑｖａｌｕｅパラメータと、アプリケーションＩＤとを運び、そして、ＭＭＳサービスの通知予約を行うことを意図するものである。リクエストは、ＭＭＳサービスの受信において、ユーザの第１の端末が最も高い優先度を有することを示す。サービスが到来した場合、サービスは、最初にこの端末に送信される。図１１は、本発明の実施形態における、ユーザによって送信されるＳＵＢＳＣＲＩＢＥリクエストメッセージを示す。最初に、ユーザが識別され、次に、ＭＭＳサービスの通知予約が行われ、最後に、「ＣＯＮＴＡＣＴ：」において優先度が設定される。この実施形態では、設定される優先度は０．７である（Ｃｏｎｔａｃｔ：＜ｓｉｐ：［５５５５：：ａａａ：ｂｂｂ：ｃｃｃ：ｄｄｄ］：１３５７；ｃｏｍｐ＝ｓｉｇｃｏｍｐ＞；ｑ＝０．７）。そのような優先度設定を介して、サービスメッセージは、選択された端末に送信されてもよい。

ステップＳ１００２：図１０における、「ｕａ＿ｐｒｏｆｉｌｅ」イベントパッケージのＳＩＰ ＳＵＢＳＣＲＩＢＥリクエストが受信された後で、ＰＰＧは、イニシエータのアイデンティティを認証し、そして、ユーザが現在の装置を介してサービスの通知予約を行うことを許可されるかどうかを、ローカルルールに従って判定する。認証に成功した場合、ＰＰＧは、「ｕａ＿ｐｒｏｆｉｌｅ」イベントパッケージの通知予約セッションを作成し、「Ｅｖｅｎｔ」ヘッダフィールドパラメータに従って、データの変更を識別するためのメソッドを提供し、次に、第１の端末に２００ ＯＫメッセージを返す。

ステップＳ１００３：ＰＰＧは、空のボディを運び、かつ、サービス通知予約が活性化されたことを示す最初のＳＩＰ ＮＯＴＩＦＹメッセージを、生成して送信する。その他の端末の優先度情報も、Ｃｏｎｔａｃｔヘッダフィールドを介して第１の端末に通知されてもよい。図１２は、本発明の実施形態における、ＭＭＳ通知予約の活性化を示す。

ステップＳ１００４：第１の端末上のプッシュクライアントは、２００ ＯＫメッセージを使用して応答する。

ＰＰＧは、サービスリクエストを受信した場合、通知予約プロセスにおいて、プッシュクライアントに送信されるＳＩＰ ＮＯＴＩＦＹメッセージにプッシュコンテンツを追加することによって、プッシュコンテンツを提出する。

ステップＳ１００５：第２の端末は、同様に、ＭＭＳサービスの通知予約を行ってもよく、ＰＰＧにＳＵＢＳＣＲＩＢＥリクエストを送信してもよい。このリクエストは、ユーザＩＤと、装置ＩＤと、Ｑｖａｌｕｅパラメータと、アプリケーションＩＤとを運び、そして、ＭＭＳサービスの通知予約を行うことを意図するものである。リクエストは、ＭＭＳサービスの受信において、ユーザの第２の端末が最も高い優先度に次ぐ優先度を有することを示す。サービスが到来した場合、第１の端末がサービスを正常に受信するのに失敗したら、サービスは第２の端末に送信される。図１３は、本発明の一実施形態における、第２の端末による通知予約を示す。第２の端末において設定される優先度は、（Ｃｏｎｔａｃｔ：＜ｓｉｐ：［５５５５：：ａａａ：ｂｂｂ：ｃｃｃ：ｄｄｄ］：１３５７；ｃｏｍｐ＝ｓｉｇｃｏｍｐ＞；ｑ＝０．６）である。この実施形態では、設定される優先度は０．６である。第２の端末の優先度は、第１の端末の優先度よりも低い。したがって、第１の端末がサービスメッセージを正常に受信するのに失敗した場合、第２の優先度の端末がサービスメッセージを受信するために選択される。

ステップＳ１００６：「ｕａ＿ｐｒｏｆｉｌｅ」イベントパッケージのＳＩＰ ＳＵＢＳＣＲＩＢＥリクエストが受信された後で、ＰＰＧは、イニシエータのアイデンティティを認証し、そして、ユーザが現在の装置を介してサービスの通知予約を行うことを許可されるかどうかを、ローカルルールに従って判定する。認証に成功した場合、ＰＰＧは、「ｕａ＿ｐｒｏｆｉｌｅ」イベントパッケージの通知予約セッションを作成し、「Ｅｖｅｎｔ」ヘッダフィールドパラメータに従って、データの変更を識別するためのメソッドを提供し、次に、第２の端末に２００ ＯＫメッセージを返す。

ステップＳ１００７：ＰＰＧは、空のボディを運び、かつ、サービス通知予約が活性化されたことを示す最初のＳＩＰ ＮＯＴＩＦＹメッセージを、生成して送信する。図１４は、本発明の実施形態における、サービス通知予約の活性化を示す。このステップでは、通知予約されたＭＭＳサービスが活性化される。その他の端末の優先度情報は、Ｃｏｎｔａｃｔヘッダフィールドを介して第２の端末に通知されてもよい。

ステップＳ１００８：第２の端末上のプッシュクライアントは、２００ ＯＫメッセージを使用して応答する。

別の実施形態
図１５は、本発明の実施形態における、ＳＵＢＳＣＲＩＢＥリクエストが複数のサービスの通知予約を意図するものである場合のフローチャートである。この実施形態には複数のアプリケーションＩＤが関与し、また、ここではユーザ「ｊｏｈｎ．ｄｏｅ＠ｈｏｍｅ１．ｎｅｔ」が例に取られる。詳細なステップは、以下のとおりである。

ステップＳ１５０１：ユーザ「ｊｏｈｎ．ｄｏｅ＠ｈｏｍｅ１．ｎｅｔ」の第１の端末は、ＰＰＧに、ＳＵＢＳＣＲＩＢＥリクエストを送信する。このリクエストは、ユーザＩＤと、装置ＩＤと、Ｑｖａｌｕｅパラメータと、複数のアプリケーションＩＤとを運び、そして、複数のサービスの通知予約を行うことを意図するものである。リクエストは、Ａｐｐ１サービスの受信において、ユーザの第１の端末が最も高い優先度を有することを示す。Ａｐｐ１サービスが到来した場合、Ａｐｐ１サービスは、最初に第１の端末に送信される。Ａｐｐ２は、第１の端末の、２番目に優先されるサービスであり、Ａｐｐ３は、第１の端末の、３番目に優先されるサービスである。図１６は、本発明の実施形態における、第１の端末によってＰＰＧに送信されるＳＵＢＳＣＲＩＢＥリクエストを示す。３つの異なる優先度値が、Ａｐｐフィールド内に存在し、ａｐｐｉｄ＝”ａｐｐ１；ｑ＝０．７，ａｐｐ２；ｑ＝０．６，ａｐｐ３；ｑ＝０．５と、高い優先度から低い優先度の順に並べられて存在する。優先度を介して、ＰＰＧは、端末によってどのサービスが優先されるかを認識し、そして、より高い優先度のサービスを端末に送信してもよい。より高い優先度のサービスが送信された後で、ＰＰＧは、より低い優先度のサービスを送信してもよい。

ステップＳ１５０２：「ｕａ＿ｐｒｏｆｉｌｅ」イベントパッケージのＳＩＰ ＳＵＢＳＣＲＩＢＥリクエストが受信された後で、ＰＰＧは、イニシエータのアイデンティティを認証し、そして、ユーザが現在の装置を介してサービスの通知予約を行うことを許可されるかどうかを、ローカルルールに従って判定する。認証に成功した場合、ＰＰＧは、「ｕａ＿ｐｒｏｆｉｌｅ」イベントパッケージの通知予約セッションを作成し、「Ｅｖｅｎｔ」ヘッダフィールドパラメータに従って、データの変更を識別するためのメソッドを提供し、次に、第１の端末に２００ ＯＫメッセージを返す。

ステップＳ１５０３：ＰＰＧは、空のボディを運び、かつ、サービス通知予約が活性化されたことを示す最初のＳＩＰ ＮＯＴＩＦＹメッセージを、生成して送信する。図１７は、本発明の実施形態における、活性化の指示を示す。メッセージは、第１の端末に、各サービスの通知予約が活性化されたかどうかを示してもよい。

ステップＳ１５０４：第１の端末上のプッシュクライアントは、２００ ＯＫメッセージを使用して応答する。ＰＰＧは、サービスリクエストを受信した場合、通知予約プロセスにおいて、プッシュクライアントに送信されるＳＩＰ ＮＯＴＩＦＹメッセージにプッシュコンテンツを追加することによって、プッシュコンテンツを提出する。

ステップＳ１５０５：第２の端末は、ＰＰＧに、ＳＵＢＳＣＲＩＢＥリクエストを送信する。このリクエストは、ユーザＩＤと、装置ＩＤと、Ｑｖａｌｕｅパラメータと、複数のアプリケーションＩＤとを運び、そして、複数のサービスの通知予約を行うことを意図するものである。リクエストは、ａｐｐ２サービスの受信において、ユーザの、この端末が、最も高い優先度を有することを示す。ａｐｐ２サービスが到来した場合、ａｐｐ２サービスは、最初に第２の端末に送信される。Ａｐｐ１は、第２の端末の、２番目に優先されるサービスであり、Ａｐｐ３は、第２の端末の、３番目に優先されるサービスである。図１８は、本発明の実施形態における、第２の端末による通知予約を示す。最初に、ユーザが識別される。ユーザＩＤと、装置ＩＤと、Ｑｖａｌｕｅパラメータが正しいものとして識別された後で、優先度が、各通知予約されるサービス内に書き込まれる必要がある。この実施形態では、ＡＰＰ２の最も高い優先度は０．７であり、装置ＩＤは最後に書き込まれている。このステップでは、装置は第２の端末である。

ステップＳ１５０６：「ｕａ＿ｐｒｏｆｉｌｅ」イベントパッケージのＳＩＰ ＳＵＢＳＣＲＩＢＥリクエストが受信された後で、ＰＰＧは、第２の端末のアイデンティティを認証し、そして、ユーザが現在の装置を介してサービスの通知予約を行うことを許可されるかどうかを、ローカルルールに従って判定する。認証に成功した場合、ＰＰＧは、「ｕａ＿ｐｒｏｆｉｌｅ」イベントパッケージの通知予約セッションを作成し、「Ｅｖｅｎｔ」ヘッダフィールドパラメータに従って、データの変更を識別するためのメソッドを提供し、次に、第２の端末に２００ ＯＫメッセージを返す。

ステップＳ１５０７：ＰＰＧは、空のボディを運び、かつ、サービス通知予約が活性化されたことを示す最初のＳＩＰ ＮＯＴＩＦＹメッセージを、生成して送信する。その他の端末の優先度情報も、Ｃｏｎｔａｃｔヘッダフィールドを介して第２の端末に通知されてもよい。図１９は、本発明の実施形態における、第２の端末によるサービス通知予約の活性化を示す。その他の端末の優先度情報を第２の端末に通知する必要がある場合、その他の端末の優先度情報は、Ｃｏｎｔａｃｔヘッダフィールドの前に追加されてもよい。

ステップＳ１５０８：第２の端末上のプッシュクライアントは、２００ ＯＫメッセージを使用して応答する。

この実施形態では優先度が設定される。サービスの通知予約時に、より高い優先度の端末がサービスの受信に失敗した場合、より低い優先度の端末が代わりにサービスを受信してもよく、２つの端末が同じサービスを同時に受信することは不可能である。したがって、ユーザの複数の端末が同じメッセージを重ねて受信することはなく、同じメッセージの到来によってその他のサービスの受信が影響を受けることはない。

別の実施形態
図２０は、本発明の実施形態における、サービスを受信するためのより高い優先度の装置を、ＰＰＧが選択する方法を示すフローチャートである。この実施形態におけるユーザのすべての端末は、同じサービスの通知予約を行うことを許可される。ＰＰＧが端末の優先度を設定する。ネットワーク状態に応じて、ＰＰＧは、サービスメッセージを受信するための端末を選択し、その他の端末が同時にサービスメッセージを受信することはない。ユーザのすべての端末は、サービスの通知予約を行うためのリクエストをＰＰＧに送信するために、パブリックユーザＩＤを使用してもよく、リクエストは、プライベートユーザＩＤ（コンタクトアドレスであってもよい）を運ぶ。ＰＰＧは応答を返して、通知予約されたサービスが活性化されたことを、ユーザのすべての端末に対して示す。ユーザの、異なる端末は、ＩＭＳＩ、プライベートユーザＩＤ、ＧＲＵＵ、複数のコンタクト情報、ＩＰアドレス、電話番号、又は装置番号によって区別されてもよい。詳細なステップは、以下のとおりである。

ステップＳ２００１：この実施形態では、ユーザ「ｊｏｈｎ．ｄｏｅ＠ｈｏｍｅ１．ｎｅｔ」を例に取ると、ユーザ「ｊｏｈｎ．ｄｏｅ＠ｈｏｍｅ１．ｎｅｔ」の第１の端末が、ＰＰＧに、ＳＵＢＳＣＲＩＢＥリクエストを送信する。このリクエストは、ユーザＩＤと、装置ＩＤと、アプリケーションＩＤとを運び、そして、ＭＭＳサービスの通知予約を行うことを意図するものである。図２１は、本発明の実施形態における、ユーザによって送信されるＳＵＢＳＣＲＩＢＥリクエストメッセージを示す。最初に、ユーザが識別される。ユーザＩＤが正しいものとして認証された後で、ＭＭＳサービスの通知予約が行われる。最後に、端末の装置ＩＤが追加されて、端末がサービスの通知予約を行ったことが示される。

ステップＳ２００２：「ｕａ＿ｐｒｏｆｉｌｅ」イベントパッケージのＳＩＰ ＳＵＢＳＣＲＩＢＥリクエストが受信された後で、ＰＰＧは、イニシエータのアイデンティティを確認し、そして、ユーザが現在の装置を介してサービスの通知予約を行うことを許可されるかどうかを、ローカルルールに従って判定する。認証に成功した場合、ＰＰＧは、「ｕａ＿ｐｒｏｆｉｌｅ」イベントパッケージの通知予約セッションを作成し、「Ｅｖｅｎｔ」ヘッダフィールドパラメータに従って、データの変更を識別するためのメソッドを提供し、次に、第１の端末に２００ ＯＫメッセージを返す。図２２は、本発明の実施形態における、２００ ＯＫメッセージを示す。

ステップＳ２００３：ＰＰＧは、空のボディを運び、かつ、サービス通知予約が活性化されたことを示す最初のＳＩＰ ＮＯＴＩＦＹメッセージを、生成して送信する。図２３は、本発明の実施形態における、サービス通知予約の活性化を示す。

ステップＳ２００４：第１の端末上のプッシュクライアントは、２００ ＯＫメッセージを使用して応答する。ＰＰＧは、サービスリクエストを受信した場合、通知予約プロセスにおいて、プッシュクライアントに送信されるＳＩＰ ＮＯＴＩＦＹメッセージにプッシュコンテンツを追加することによって、プッシュコンテンツを提出する。

ステップＳ２００５〜Ｓ２００８：第２の端末は、ＰＰＧからのＭＭＳサービスの通知予約を行う。最初に、ユーザＩＤが確認され、そして、ＭＭＳサービスの通知予約が行われ、次に、装置ＩＤが書き込まれる。最後に、ＭＭＳサービスの通知予約が活性化される。

ステップＳ２００９：ユーザに送信されるＭＭＳメッセージが到来した場合、ＰＰＧは、設定された選択基準に従って、ユーザの優先される端末を選択し、そして、選択された端末にサービスメッセージを送信する。優先される端末は、第１の端末と見なされる。

ＰＰＧは、端末装置の優先度に従って、端末の優先を自動的に判定する。一般に、優先度は、ネットワーク品質によって決まる。ＰＰＧは、ユーザがより良好な情報サービスを取得できるように、より良いネットワーク品質の端末を選択してもよい。この実施形態では、第１の端末が優先される端末であり、ユーザは第１の端末を介して情報サービスを取得する。

ステップＳ２０１０：ＮＯＴＩＦＹメッセージを介して、第１の端末に、サービスメッセージが送信される。

ステップＳ２０１１：第１の端末は、２００ ＯＫメッセージを返して、メッセージが正常に受信されたことを示す。

別の実施形態
図２４は、本発明の実施形態における、ＨＴＴＰを介してＰＰＧにサービスリクエストを送信するフローチャートを示す。端末が受信を期待するサービスを、ＰＰＧに通知するために、端末はＰＰＧにリクエストを送信すると仮定される。本実施形態の第２の解決法では、以下で詳細に説明するように、端末は、端末によって設定されたサービス受信優先度リストを、ＨＴＴＰを介してＰＰＧに送信する。

ステップＳ２４０１：ユーザは、第１の端末を使用して、サービスを受信するためのＨＴＴＰ Ｐｏｓｔポリシーのリストを設定する。

ポリシーリストは、優先度リストであってもよい。この優先度リストは、端末によって優先されるサービスを示してもよい。実施形態の第２の解決法では、ＭＭＳサービスが例に取られる。すなわち、第１の端末は、ＭＭＳサービスを最初に受信することを期待する。

ステップＳ２４０２：ＰＰＧは、２００ ＯＫメッセージを返して、ＰＰＧが端末からＨＴＴＰ Ｐｏｓｔポリシーのリストを受信したことを示す。

ステップＳ２４０３：ユーザは、第２の端末を使用して、サービスを受信するためのＨＴＴＰ Ｐｏｓｔポリシーのリストを設定する。

この実施形態では、第１の端末と同様に、第２の端末は、電子メール通知サービスを第２の端末が最初に受信することを期待することを示してもよい。

ステップＳ２４０４：２００ ＯＫメッセージを返して、ＰＰＧが端末からＨＴＴＰ Ｐｏｓｔポリシーのリストを受信したことを示す。

この実施形態では、端末の優先度が設定されるか、又は、ＨＴＴＰをベースにしたサービス受信ポリシーのリストが設定される。より高い優先度の端末が、より高い優先度の情報サービスをユーザに提供するために選択される。サービスメッセージが送信される場合、その他の端末がサービスメッセージを同時に受信することはない。したがって、サービス品質は向上し、重ねてのデータ伝送は回避される。この実施形態におけるＰＰＧは、この機能が可能なその他のサーバであってもよい。

システム実施形態
図２５は、本発明の一実施形態における、１人のユーザの複数の端末を使用してサービスメッセージを処理するシステムの構成を示す。このシステムは、ＰＰＧ１と、同じユーザＩＤを有する少なくとも２つの端末２とを含む。端末２は、ＰＰＧ１にＳＵＢＳＣＲＩＢＥリクエストを送信するように構成される。ＳＵＢＳＣＲＩＢＥリクエストは、端末の要求情報を運ぶ。ＰＰＧ１は、端末２からＳＵＢＳＣＲＩＢＥリクエストを受信し、要求情報に従って端末２にサービスメッセージを送信するように構成される。要求情報は、ユーザＩＤと、装置ＩＤと、アプリケーションＩＤとを含む。

ＰＰＧ１は、端末２からＳＵＢＳＣＲＩＢＥリクエストを受信するように構成された、リクエスト受信モジュール１１と（ここで、ＳＵＢＳＣＲＩＢＥリクエストは端末２の要求情報を運ぶ）、サービスが到来した場合に、要求情報に従って端末２にサービスメッセージを送信するように構成された、処理モジュール１２とを含む。

処理モジュール１２は、端末２によって要求されたサービスが、同じユーザＩＤの端末によってすでに要求されているかどうかを、要求情報内のユーザＩＤとアプリケーションＩＤとに従って判定するように構成された、判定サブモジュール１２１と、同じユーザＩＤのいずれの端末もまだサービスを要求していないということを判定サブモジュール１２１が判定した場合に、端末２にサービス通知予約の活性化指示を送信するように構成された、通知予約指示送信サブモジュール１２２と、サービスが到来した場合に、端末２にサービスメッセージを送信するように構成された、サービスメッセージ送信サブモジュール１２３とを含む。

処理モジュール１２は、同じユーザＩＤの端末がサービスをすでに要求しているということを判定サブモジュール１２１が判定した場合に、端末２に、サービスの通知予約された状態を示すプロンプトレスポンスを返すように構成された、プロンプトレスポンス返送サブモジュール１２４を更に含む。

処理モジュール１２は、プロンプトメッセージ送信サブモジュール１２５を更に含む。プロンプトメッセージ送信サブモジュール１２５は、通知予約指示送信サブモジュール１２３が端末２にサービス通知予約活性化の指示を送信した後で、端末２と同じユーザＩＤを有するその他の端末に、ＮＯＴＩＦＹメッセージを送信するように構成され、ここで、ＮＯＴＩＦＹメッセージは、その他の端末に、サービスの通知予約を以後行わないよう指示するものである。

処理モジュール１２は、端末２にサービスメッセージを送信する必要があるかどうかを、端末２によって報告されたサービス優先度に従って判定し、必要に応じて、端末２にサービスメッセージを送信するようサービスメッセージ送信サブモジュール１２４に通知するように構成された、優先度判定サブモジュール１２６を含む。

処理モジュール１２は、ネットワーク構成記憶サブモジュール１２７と、優先端末判定サブモジュール１２８とを含む。ネットワーク構成記憶サブモジュール１２７は、ネットワーク構成を記憶するように構成される。優先端末判定サブモジュール１２８は、ネットワーク構成記憶サブモジュール１２７によって記憶されたネットワーク構成と、端末２の装置ＩＤとに従って、端末２が優先される端末であるかどうかを判定し、端末２が優先される端末であると判定された場合、端末２にサービスメッセージを送信するようサービスメッセージ送信サブモジュール１２４に通知するように構成される。

処理モジュール１２は、端末２からＨＴＴＰ Ｐｏｓｔポリシーリストを受信するように構成された、ポリシーリスト受信サブモジュール１２９と（ここで、ＨＴＴＰ Ｐｏｓｔポリシーリストは、サービスを受信するための、端末２の優先度のリストである）、サービスが到来した場合に、ＨＴＴＰ Ｐｏｓｔポリシーリストに従って、サービスメッセージを受信する最も高い優先度の端末を選択するように構成された、ポリシー判定サブモジュール１３０とを含む。

ユーザＩＤは、例えばＳＩＰ ＵＲＩ又はＴＥＬ ＵＲＩなどの、ユーザを識別する任意の識別子であってもよい。ＳＩＰ ＵＲＩは、ｓｉｐ：ａ＠ｅｘａｍｐｌｅ．ｃｏｍ又はｓｉｐ：１２３４５６７８９０＠ｅｘａｍｐｌｅ．ｃｏｍであってもよい。

ＴＥＬ ＵＲＩは、ｔｅｌ：１−１２３−４５６−７８９０であってもよい。例えば、プライベートユーザＩＤは、ｕｓｅｒｎａｍｅ＠ｅｘａｍｐｌｅ．ｃｏｍであってもよい。

本発明の前述の実施形態は、プッシュメカニズムにおいて、ユーザの複数の端末にメッセージを送信するための解決法を提供する。ユーザが複数の端末を有する場合、着信サービスを受信するための特定の端末が、端末のリクエストと、リクエスト内で運ばれる端末要求情報とに従って選択される。サービスが到来した場合、サービスメッセージは、要求情報に従って選択された端末に送信される。かくして、サービスメッセージはユーザのすべての端末には送信されず、ネットワークリソースの浪費が回避され、ユーザの複数の端末が同じメッセージを重ねて受信することはなく、そして、同じメッセージの到来によってその他のサービスの受信が影響を受けることはない。

本明細書で示したメッセージは、例示のみを目的とするものである。本発明は、示されたメッセージメソッド又はメッセージヘッダフィールドに限定されず、本発明の機能が可能なその他のメッセージメソッド及びメッセージヘッダフィールドは、本発明の保護範囲に含まれる。

本発明の実施形態の前述の説明を介して、当業者は、本発明がハードウェアによって、又はソフトウェアと必要な汎用ハードウェアプラットフォームとによって実装されてもよいということを明瞭に認識する。したがって、本発明による技術的解決法は、ソフトウェア製品として実施されてもよい。ソフトウェア製品は、不揮発性記憶媒体（ＣＤ−ＲＯＭ、ＵＳＢディスク、又はモバイルハードディスクなど）に記憶されてもよく、そして、本発明の実施形態で提供された方法をコンピュータ装置（パーソナルコンピュータ、サーバ、又はネットワーク装置など）が実行することを可能にする、いくつかの命令を含んでもよい。

本発明について、いくつかの好ましい実施形態を介して説明してきたが、本発明はそのような実施形態に限定されない。当業者は、本発明の精神及び範囲から逸脱することなく、本発明に対して修正及び変形を行うことが可能であることは明白である。本発明は、それらの修正及び変形を、それらが特許請求の範囲又はその均等物によって規定される保護範囲内に入るならば、包含することを意図するものである。

Claims (26)

1. 複数の端末を使用してサービスメッセージを処理する方法であって、
   端末から、前記端末の要求情報を運ぶリクエストメッセージを受信し、
   前記要求情報に従って前記端末にサービスメッセージを送信すること
   を含む、方法。
2. 前記リクエストメッセージは、ＳＵＢＳＣＲＩＢＥリクエスト及び／又はＲＥＧＩＳＴＥＲリクエストを含む、請求項１に記載の方法。
3. 前記要求情報は、ユーザ識別子（ＩＤ）、装置ＩＤ、又はアプリケーションＩＤ、或いは、それらの任意の組み合わせを含む、請求項１に記載の方法。
4. 前記要求情報に従って前記端末に前記サービスメッセージを送信することは、
   前記端末によって要求されるサービスが、同じユーザＩＤの別の端末によってすでに要求されているかどうかを、前記要求情報内の前記ユーザＩＤと前記アプリケーションＩＤとに従って判定し、
   前記同じユーザＩＤのいずれの端末も前記サービスをまだ要求していない場合、前記端末にサービス通知予約の活性化指示を送信し、前記サービスが到来したら前記端末に前記サービスメッセージを送信すること
   を含む、請求項３に記載の方法。
5. 前記同じユーザＩＤの別の端末が前記サービスをすでに要求している場合、前記サービスがすでに通知予約されていることを示すためのプロンプトメッセージを、前記端末に送信すること
   を更に含む、請求項４に記載の方法。
6. 前記端末にサービス通知予約の前記活性化指示が送信された後に、前記方法は、
   前記端末と同じユーザＩＤを有するその他の端末にプロンプトメッセージを送信して、その他の端末に指示すること
   を更に含む、請求項４に記載の方法。
7. 前記要求情報は優先度を更に含み、
   前記要求情報に従って前記端末に前記サービスメッセージを送信することは、
   前記端末にサービス通知予約の活性化指示を送信し、
   サービスが到来した場合、前記端末によって報告された前記優先度に従って、前記サービスメッセージが前記端末に送信されるかどうかを判定すること
   を含む、請求項３に記載の方法。
8. 前記サービスメッセージを、最も高いサービス優先度の前記端末に最初に送信すること
   を更に含む、請求項７に記載の方法。
9. 前記サービスメッセージが、前記最も高い優先度の前記端末に送信されるのに失敗した後で、前記サービスメッセージを、前記最も高い優先度に次ぐ優先度の前記端末に送信すること
   を更に含む、請求項８に記載の方法。
10. 前記要求情報は、複数の要求されるサービスと、対応する優先度とを運ぶ、請求項７に記載の方法。
11. 前記要求情報に従って前記端末に前記サービスメッセージを送信することは、
    前記端末の前記装置ＩＤ、及び／又は、ネットワーク構成に従って、前記端末が優先される端末であるかどうかを判定し、前記優先される端末のみに前記サービスメッセージを送信すること
    を含む、請求項３に記載の方法。
12. 前記要求情報に従って前記端末に前記サービスメッセージを送信することの前に、前記方法は、
    前記端末にサービス通知予約の活性化の指示を送信すること
    を更に含む、請求項１１に記載の方法。
13. 前記装置ＩＤは、前記特定の端末を識別するために、リクエストユニフォームリソース識別子（ＵＲＩ）及び／又はメッセージヘッダフィールド内で運ばれてもよい、請求項１１に記載の方法。
14. 前記端末によって、プッシュプロキシゲートウェイ（ＰＰＧ）にポリシーリストを送信することを更に含み、ここで、前記ポリシーリストは、サービスを受信するための、前記端末の優先度のリストであり、
    前記要求情報に従って前記端末に前記サービスメッセージを送信することは、
    前記サービスメッセージが前記端末に送信されるかどうかを、前記ＰＰＧによって、前記ユーザＩＤと前記アプリケーションＩＤと前記ポリシーリストとに従って判定すること
    を含む、請求項３に記載の方法。
15. 前記装置ＩＤは、国際移動電話加入者識別番号（ＩＭＳＩ）、プライベートユーザＩＤ、グローバルにルーティング可能なユーザエージェントＵＲＩ（ＧＲＵＵ）、複数のコンタクト情報、インターネットプロトコル（ＩＰ）アドレス、電話番号、又は装置番号である、請求項３に記載の方法。
16. 前記要求情報は、Ｃｏｎｔａｃｔヘッダフィールド内で運ばれてもよい、請求項１に記載の方法。
17. 前記要求情報は、受信側によって受信、処理、及び記憶されてもよく、そして、サービスが到来した場合に使用されてもよい、請求項１に記載の方法。
18. 複数の端末を使用してサービスメッセージを処理するシステムであって、プッシュプロキシゲートウェイ（ＰＰＧ）と、同じユーザ識別子（ＩＤ）を有する少なくとも２つの端末とを備え、
    前記端末は、前記ＰＰＧにリクエストメッセージを送信するように構成され、前記リクエストメッセージは前記端末の要求情報を運び、
    前記ＰＰＧは、前記端末から前記リクエストメッセージを受信し、前記要求情報に従って前記端末にサービスメッセージを送信するように構成された、システム。
19. 前記要求情報は、前記ユーザＩＤ、装置ＩＤ、又はアプリケーションＩＤ、或いは、それらの任意の組み合わせを含む、請求項１８に記載のシステム。
20. 端末から、前記端末の要求情報を運ぶリクエストメッセージを受信するように構成された、リクエスト受信モジュールと、
    サービスが到来した場合に、前記要求情報に従って前記端末にサービスメッセージを送信するように構成された、処理モジュールと
    を含む、プッシュプロキシゲートウェイ（ＰＰＧ）。
21. 前記処理モジュールは、
    前記端末によって要求された前記サービスが、同じユーザ識別子（ＩＤ）の別の端末によってすでに要求されているかどうかを、前記要求情報内の前記ユーザＩＤとアプリケーションＩＤとに従って判定するように構成された、判定サブモジュールと、
    前記同じユーザＩＤのいずれの端末も前記サービスをまだ要求していないということを前記判定サブモジュールが判定した場合に、前記端末にサービス通知予約の活性化指示を送信するように構成された、通知予約指示送信サブモジュールと、
    前記サービスが到来した場合に、前記端末に前記サービスメッセージを送信するように構成された、サービスメッセージ送信サブモジュールと
    を含む、請求項２０に記載のＰＰＧ。
22. 前記処理モジュールは、
    前記同じユーザＩＤの別の端末が前記サービスをすでに要求しているということを、前記判定サブモジュールが判定した場合に、前記端末に、前記サービスの通知予約された状態を示すプロンプトレスポンスを返すように構成された、プロンプトレスポンス返送サブモジュール
    を更に含む、請求項２１に記載のＰＰＧ。
23. 前記処理モジュールは、
    前記通知予約指示送信サブモジュールが前記端末にサービス通知予約の前記活性化指示を送信した後で、前記端末と同じユーザＩＤのその他の端末に、ＮＯＴＩＦＹメッセージを送信するように構成された、プロンプトメッセージ送信サブモジュール
    を更に含み、
    前記ＮＯＴＩＦＹメッセージは、前記その他の端末に、前記サービスの通知予約を以後行わないよう指示するものである、請求項２１に記載のＰＰＧ。
24. 前記処理モジュールは、
    前記端末に前記サービスメッセージが送信されるかどうかを、前記端末によって報告されたサービス優先度に従って判定し、前記サービスメッセージが送信されるべきである場合、前記端末に前記サービスメッセージを送信するようサービスメッセージ送信サブモジュールに通知するように構成された、優先度判定サブモジュール
    を含む、請求項２０に記載のＰＰＧ。
25. 前記処理モジュールは、
    ネットワーク構成を記憶するように構成された、ネットワーク構成記憶サブモジュールと、
    前記ネットワーク構成記憶サブモジュールによって記憶された前記ネットワーク構成と、前記端末の装置識別子（ＩＤ）とに従って、前記端末が優先される端末であるかどうかを判定し、前記端末が前記優先される端末であると判定された場合、前記端末に前記サービスメッセージを送信するようサービスメッセージ送信サブモジュールに通知するように構成された、優先端末判定サブモジュールと
    を含む、請求項２０に記載のＰＰＧ。
26. 前記処理モジュールは、
    前記端末から、前記サービスを受信するための、端末の優先度のリストであるポリシーリストを受信するように構成された、ポリシーリスト受信サブモジュールと、
    前記サービスが到来した場合に、前記ポリシーリストに従って、前記サービスメッセージを送信するための最も高い優先度の前記端末を選択するように構成された、ポリシー判定サブモジュールと
    を含む、請求項２０に記載のＰＰＧ。

Images