JP2008505528A - プッシュメッセージによって開始されるサービスのための装置および方法 - Google Patents

Abstract

本発明は、移動通信端末（１０２ａ）と、移動通信端末の方法と、ネットワークノード（１０６ａ）と、そして、移動クライアント端末（１０２ａ）にサービスを配信するためのベアラサービスに要求されるサービス品質に対してサービスプロバイダが影響を及ぼすことを可能にするネットワークノードの方法とに関するものであり、その場合、そのサービスはサービスプロバイダからのプッシュメッセージ（３０９）によって開始され、ベアラサービスの設定はプッシュメッセージの受信後にクライアント端末によって開始される（３０４）。本発明に従えば、プッシュメッセージ（３０９）は、クライアント端末（１０２ａ）に配信されるサービスコンテンツの表示だけでなく、サービスコンテンツを受信するためのベアラサービス用にサービスプロバイダが推奨するサービス品質パラメータの組も含んでいる。それによって、クライアント端末（１０２ａ）は、ベアラサービスの設定を要求するとき、サービスプロバイダの推奨を考慮に入れることができる。

Description

関連出願の相互参照
本願は、同一出願人による同時係属の、２００４年７月５日出願の発明の名称を「通信ネットワークにおけるサービス品質管理のためのバインディングメカニズム（Binding Mechanism for Quality of Service Management in a Communication Network）」という国際特許出願番号ＰＣＴ／ＳＥ０４／＿＿と、２００４年７月５日出願の発明の名称を「サービス品質パラメータをＨＴＴＰメッセージに供給するための方法と装置（Methods and Devices for Supplying Quality of Service Parameters in HTTP Messages）」という国際特許出願番号ＰＣＴ／ＳＥ０４／＿＿と、２００４年７月５日出願の発明の名称を「サービス品質を変更する方法および装置（Methods and Devices for Changing Quality of Service）」という国際特許出願番号ＰＣＴ／ＳＥ０４／＿＿とに関係するものであり、それらの開示は、参照により本願に組み込まれる。

本発明は、移動通信システムにおける装置と方法に関するものであり、特に、パケットデータサービスに関する送信のサービス品質要求の制御に関するものである。

データビット形式でパケットベースの情報通信を行う通信ネットワークは、当業者にはよく知られている。移動通信の重要性が増すにつれ、無線接続によってデータを転送する需要が高まる。ワイヤレス・アプリケーション・プロトコル（ＷＡＰ）は、無線通信ネットワーク上で動作するアプリケーションを運用者や製造者が提供できるようにする一組のプロトコルを定義する。ＷＡＰアーキテクチャを介して提供可能なサービスの一例にＷＡＰプッシュがあるが、これはコンテンツを移動体機器にプッシュするサービスである。

この“プッシュ（push）”技術は、クライアント／サーバモデルの中のサーバが、クライアントからの明確な要求がなくても、情報をクライアントに送信することを意味している。これは“プル（pull）”技術とは異なっている。プル技術は代表的な例で言えば、ワールドワイドウェブ（World Wide Web）を閲覧するのに用いられており、この場合、クライアントがサーバからのサービスや情報を要求し、サーバはクライアントに情報を送信することによって応答する。言い換えると、情報の“プル”トランザクションはクライアントから開始され、他方、“プッシュ”トランザクションはサーバが開始する。

ＷＡＰプッシュ動作では、プッシュイニシエータ（ＰＩ）がプッシュコンテンツおよび配信命令をプッシュプロキシゲートウェイ（ＰＰＧ）に送信し、ＰＰＧはその後、配信命令に従って、ＷＡＰクライアント、例えば、移動電話や何か他の種類のＷＡＰ機能を持つ端末にプッシュコンテンツを配信する。

ＰＩは、普通のウェブサーバ上で実行されるアプリケーションであってもよい。ＰＩはプッシュアクセスプロトコル（ＰＡＰ）を用いてＰＰＧと通信し、他方、ＰＰＧはプッシュ・オーバ・ジ・エア（ＯＴＡ）プロトコルを用いてプッシュコンテンツをクライアントに配信する。ＷＡＰプッシュの枠組みに関する詳細情報は、非特許文献１に見出すことができる。

非特許文献１で説明されているとおり、プッシュコンテンツの配信には、多くの場合、クライアントがベアラを起動させる必要がある。このためクライアントは、ＰＰＧからのセッション開始要求（ＳＩＲ）を聴取し、端末が適切だと考えるベアラサービスを起動してその後、所望のＰＰＧに連絡を取ることによって応答するようなアプリケーションを備えている。ＳＩＲはコネクションレス・プッシュを用いてクライアントに送信されることが多く、例えば、１個のＳＭＳの中に組み込まれる。

ＷＡＰプッシュの枠組みにより、どんなＭＩＭＥメディアタイプでもＰＩとクライアントの間で配信ができる。既存のＭＩＭＥタイプでは未提供の機能を追加するため、いくつかの特定のメディアタイプも具体的に定義されている。そのような特定のメディアタイプの一例として、サービス表示（ＳＩ）メディアタイプがあるが、これは非同期の方法でクライアントに通知を送信する機能を提供する。その通知は、例えば、新着の電子メール、株価の変動やサッカーの試合のスコア、ニュースの見出し、広告、前払残高低下の注意等であってもよい。基本的なＳＩは、短いメッセージと、サービスを表示するＵＲ（Uniform Resource Identifier）とを有する。そのメッセージはクライアントの適切なアプリケーションへと送信され、受信時にエンドユーザに提示される。ユーザは、ＵＲＩが表示するサービスをすぐに開始するか、あるいは後で処理するようＳＩを延期するかの選択肢が与えられる。ＵＲＩによって表示されるサービスの開始をユーザが選択すると、端末の中でそのサービスのために規定されている要件に従って、アプリケーションがベアラサービスの設定を開始する。

プッシュ用に特に定義されているメディアタイプの別の例として、サービスローディング（ＳＬ）メディアタイプがある。ＳＩと違って、ＳＬはユーザの関与をまったく含まない。ＳＬは、コンテンツが実行／提供されるべきか、あるいはキャッシュメモリの中に配置されるべきかというエンドユーザの確認や命令がなくても、クライアントによってロードされる何らかのコンテンツを指し示すＵＲＩを有している。クライアント端末のアプリケーションでＳＬを受信した後、受信側のアプリケーションはＰＩからクライアントにコンテンツを配信するためのベアラサービスの設定を開始する。ＳＬについてのさらなる情報、およびＳＬがクライアント端末の他の動作とどのように調整されるかについてのさらなる情報は、非特許文献２に見出すことができる。
ＷＡＰプッシュアーキテクチャの概要（WAP Push Architectural Overview）、２００１年７月３日版、ＷＡＰフォーラム（登録商標）、ウェブサイト＜URL:http://www.wapforum.org＞ サービスローディング（Service Loading）、２００１年７月３１日版、ＷＡＰフォーラム（登録商標）、ウェブサイト＜URL:http://www.wapforum.org＞

ＳＩとＳＬに共通する特徴は、ＰＩがクライアントに配信することを望むサービスコンテンツのことをクライアントに知らせるため、サービス表示メッセージ（ＳＩ）またはサービスローディング（ＳＬ）のメッセージをクライアントに送信することによって第１のサービス開始を行うのはＰＩ（即ち、クライアント／サーバモデルのサーバのこと）であるとしても、コンテンツ配信のためのベアラサービスの設定を開始するのはクライアントである点である。ベアラサービスの設定を要求するとき、クライアントはそのベアラサービスの特定のサービス品質（ＱｏＳ）についても要求する。ベアラサービス用に要求されたＱｏＳは、１組のＱｏＳパラメータによって指定される。要求されたベアラＱｏＳに対するアプリケーションレベルからのマッピングはクライアント端末で行われるが、これは端末ベンダの端末での符号化に依存する。従って、同じサービス表示メッセージ（ＳＩ）であっても、異なるベンダの端末に送信されると、ベアラＱｏＳが異なるという結果になることもあり得る。さらにまた、クライアント端末が要求するＱｏＳは、サービスを提供するＰＩの観点からすればサービスコンテンツ配信に適しているとは全く言えないこともあり得る。

本発明の目的は、プッシュメッセージによって開始されるサービスのサービスプロバイダが、そのサービスプロバイダからのサービスコンテンツをクライアント移動体端末で受信するために設定されるベアラサービスのサービス品質パラメータの選択に影響を及ぼすことが可能な装置と方法を提供することである。

上記の目的は、請求項１および１０に従う移動通信端末、請求項１１および２０に従う移動通信端末における方法、請求項２１に従うネットワークノード、そして、請求項３３に従うネットワークノードの方法によって達成される。

本発明の基本的な考え方とは、サービスプロバイダがサービスを開始する契機となるプッシュメッセージ中のサービスコンテンツの表示だけでなく、１組の推奨サービス品質パラメータも転送することである。それによって、移動端末は、プッシュメッセージ受信時に、１組の推奨サービス品質パラメータを取り出すことができ、また、プッシュメッセージによって示されるサービスコンテンツを受信するためのベアラサービスを要求するときに、その１組の推奨サービス品質パラメータを考慮に入れることができる。本発明の基本的な考え方を実施するには、新たな修正された移動端末、新たな修正されたネットワークノード、並びに、それらの移動端末およびネットワークノードに新たな方法がそれぞれ必要であるが、それらはすべて、本発明の異なる態様によって提供される。

本発明を第１の側面からみると、サービスプロバイダから少なくとも１個のパケットデータサービスを受信するためのアプリケーションを備えた移動通信端末が提供される。そのアプリケーションは、サービスプロバイダからプッシュされたサービス表示メッセージを受信するように構成されており、そのサービス表示メッセージは、サービスプロバイダが端末に配信するためのサービスコンテンツを有しているという情報を含んでいる。アプリケーションはさらに、サービスコンテンツ受信のためのベアラサービスの設定を開始するよう構成されている。移動通信端末はさらに、受信したサービス表示メッセージに含まれている１組の推奨サービス品質パラメータを取り出す処理手段を有している。この推奨サービス品質パラメータの組は、サービスコンテンツを受信するためのベアラサービス用に端末が要求することをサービスプロバイダが推奨している１組のサービス品質パラメータである。その処理手段はさらに、その推奨サービス品質パラメータの組に基づいて処理済サービス品質パラメータの組を決定し、サービスコンテンツを受信するためのベアラサービス用にその処理済サービス品質パラメータの組を要求するため、その推奨サービス品質パラメータの組を処理するように構成されている。

第２の側面からみると、本発明はパケットデータサービスの組をサービスプロバイダからクライアント移動体端末に提供するネットワークにおけるネットワークノードを提供する。このネットワークノードは、第１のクライアント端末にプッシュ送信されるサービス表示メッセージを創成するためのメッセージ創成手段と、そのサービス表示メッセージを第１のクライアント端末にプッシュするためのインタフェースとを有している。メッセージ創成手段は、サービスプロバイダが第１のクライアント端末に配信するサービスコンテンツを有しているという情報と、サービスコンテンツを受信するためのベアラサービス用に第１のクライアント端末が要求することをサービスプロバイダが推奨する推奨サービス品質パラメータの組とを、サービス表示メッセージの中に含めるように構成されている。

第３および第４の側面からみると、本発明は移動通信端末における方法とネットワークノードにおける方法とを提供する。

本発明の利点は、移動端末が要求するサービス品質パラメータにサービスプロバイダが影響を及ぼすことが可能になることである。サービスプロバイダはサービスコンテンツの特徴を知っているため、サービスコンテンツ配信用の適切なサービス品質パラメータを移動端末よりうまく決定できる可能性があるので、これは有益である。また、サービスプロバイダが、高品質のサービスを提供するサービスプロバイダとしての自社のイメージと評判を維持するため、自社サービスの１つと関連して使用されるサービス品質パラメータに影響を及ぼすことを望むこともできる。もし端末があまりに低品質のサービスを要求するならば、たとえサービスの低品質の原因が端末の構造にあったとしても、サービスコンテンツのプロバイダに悪い印象を与えることがあるかもしれない。

本発明のもう１つの利点は、同じサービスまたは同じタイプのサービスについて、異なる端末間でより均一な品質を実現できるようにすることである。本発明の好適な実施例に従う移動端末はベアラサービス用に推奨サービス品質パラメータの組を要求するよう構成されてもよいため、移動端末の符号化がベアラサービスのサービス品質に与える影響を弱めることができる。従来技術による解決策では、移動端末は通常、予め定義されたＰＤＰコンテキストを要求するよう“ハードコーディングされている（hard coded）”。端末ベンダが違えば符号化も違うことがあり、これは、端末のベンダが違えば、端末に対するサービス品質が異なることにつながる。

本発明のさらにもう１つの利点は、ベアラサービス用に要求されたサービス品質パラメータの柔軟な決定が可能となり得ることである。本発明によって、移動端末はたった１つまたはごく少数の予め定義されたベアラサービスのサービス品質パラメータを要求することに限定される必要がなくなる。

本発明の実施例のさらなる利点や特徴は、図面に関連して下記の詳細説明を読むと明らかになるであろう。

本発明について、本発明の好適な実施例が示されている添付図面を参照しながら以下に詳しく説明する。しかしながら、本発明は多くの異なる形態で実施されることができ、この明細書の中に述べられた実施例に限定されると解釈されるべきではなく、むしろ、これらの実施例は、本開示が十分かつ完全であって当業者に本発明の範囲を完全に伝えるように備えられたものである。なお、図面中、同じ番号は同じ要素に言及している。

本発明は移動通信システムにおけるパケット交換サービスに適用可能であり、それらのサービスはプッシュメッセージによってサービスプロバイダから開始される。それらのサービスには、エンドユーザのクライアント移動体端末とアプリケーションサーバとの間のパケット交換通信が含まれる。移動通信システムには、クライアント移動体端末が属しているＷＣＤＭＡ、ＣＤＭＡ２０００、無線ＬＡＮ、ＧＰＲＳネットワークのような無線ネットワークが含まれる。

図１は、本発明が用いられる移動通信システムの一般的なネットワークアーキテクチャを図示する模式的なブロック図である。図１の移動体システム１０１は、サービスプロバイダのネットワークノード１０６と通信し、それによってサービスプロバイダが提供するサービスを受信するクライアント移動体端末１０２を有する。クライアント端末１０２とネットワークノード１０６との間の通信は、無線ネットワーク１０３、コアネットワーク１０４、そしてサービスネットワーク１０５を介して行われる。無線ネットワーク１０３は、例えば、ＵＴＲＡＮ（ＵＭＴＳ地上無線アクセス網）或はＣＤＭＡ２０００ネットワークであってもよく、コアネットワーク１０４は、例えば、ＵＭＴＳコアネットワークであってもよく、サービスネットワークは、例えば、インターネットやサービスプロバイダの専用ＩＰネットワークであってもよい。サービスプロバイダのネットワークノード１０６は、例えば、アプリケーションサーバ、或はプッシュプロキシゲートウェイであってもよい。

図２は、サービスプロバイダのネットワークノードからのプッシュメッセージによって開始される従来技術に従うサービスを模式的に図示した流れ図である。そのサービスは、例えば、クライアント移動体端末のユーザがＷ杯中のサッカーのゴールシーンを写した画像を予約できるようにするサービスであってもよい。サッカーの最新ゴールの画像が入手可能であるとき、サービスプロバイダはプッシュメッセージによって最新画像のことをユーザに知らせる。図２は、サービスプロバイダのネットワークノード１０６が、ステップ２０１で、プッシュメッセージ２０９をクライアント移動体端末１０２に送信することによってサービスを開始することを図示している。この例では、プッシュメッセージ２０９は、ＷＡＰ ＰＵＳＨおよびＳＭＳを介してクライアント移動体端末に送信されるＷＡＰプッシュサービスローディング（ＳＬ）メッセージであり、サービスコンテンツ、即ち、画像は、ＳＬメッセージの中に含まれるＵＲＩによって示される。そのＳＬメッセージはクライアント移動体端末の適切なユーザエージェントまたはアプリケーション２１０に対して宛てられる。この場合、そのサービスはＭＭＳベアラ上で配信される予定であると想定されるため、プッシュメッセージはＭＭＳエージェントに宛てられる。クライアント移動体端末でＳＬメッセージが受信されると、ＳＬメッセージは対象ユーザエージェント２１０に転送され、それから対象ユーザエージェント２１０がステップ２０２で起動し、その後、ステップ２０３で、予め構成されたＰＤＰコンテキストをＭＭＳベアラを用いて要求する。ＰＤＰコンテキストが設定されたという確認をクライアント移動体端末が受信すると、その端末は、ステップ２０４で、受信したＵＲＩによってサービスコンテンツを入手できる。

図２の図解から明らかだが、サービスを開始するのはサービスプロバイダだが、サービスコンテンツ配信用のベアラサービスの設定を要求するのはクライアント端末１０２である。従って、ＰＤＰコンテキストパラメータと、それによってベアラのサービス品質（ＱｏＳ）を要求するのは、クライアント移動体端末である。現在は、各ユーザエージェントまたはアプリケーションは、クライアント移動体端末の中に“ハードコーディングされた（hard coded）”選択されたＱｏＳクラスで予め構成されたＰＤＰコンテキストに結合される。

ＵＭＴＳ（全球規模移動体通信システム）では、ＱｏＳはＵＭＴＳベアラサービスを規定する１組の属性によって定義されている。ＵＭＴＳのＱｏＳ属性は以下のようである。即ち、
−トラヒッククラス
−最大ビットレート
−保証ビットレート
−配信順序
−最大ＳＤＵサイズ
−ＳＤＵフォーマット情報
−ＳＤＵ誤り率
−未解決ビット誤り率
−誤ったＳＤＵの配信
−転送遅延
−トラヒック処理優先順位
−割当／捕捉優先順位
−資源統計記述子
−シグナリング表示
である。

これらの属性は、所定のＵＭＴＳ ＱｏＳクラス、即ち、会話クラス、ストリーミングクラス、インタラクティブクラス、バックグラウンドクラスにマップすることができる。ＵＭＴＳ ＱｏＳについての詳細情報は、技術仕様書３ＧＰＰ ＴＳ２３．１０７ Ｖ６．１．０（２００４−０３）及び３ＧＰＰ ＴＳ ２３．２０７Ｖ６．２．０（２００４−０３)に見出すことができる。

ＱｏＳクラスは、ＰＤＰコンテキスト管理を用いてネゴシエーションされ管理される。アプリケーションレベルのＱｏＳの要件は、クライアント移動体端末の中のＰＤＰコンテキストパラメータにマップされる。従来技術による解決策では、パケット交換アプリケーションが起動してネットワークに接続する時、一致する事前構成されたＰＤＰコンテキストが起動されるように、ＰＤＰコンテキストの事前構成がクライアント端末で行われる。このＰＤＰコンテキストは、そのアプリケーションの所望のＱｏＳ要件に合致すべき選択されたＱｏＳクラスを有している。例えば、そのアプリケーションがＷＡＰブラウザまたはＭＭＳクライアントであるとすれば、起動されたＰＤＰコンテキストのＱｏＳクラスは通常、インタラクティブクラスである。

従って、従来技術の解決策では、図２に図示した例の中でサービスコンテンツ配信のために設定されたベアラサービス用のＱｏＳパラメータの選択は、端末ベンダのクライアント移動体端末の構成に依存する。サービスプロバイダはＱｏＳパラメータの選択に影響を与えることはできない。多くの場合、特にサービスプロバイダの観点から、これは問題をはらんでいるが、サービスコンテンツの配信に適していないＱｏＳでベアラサービスを設定する結果にでもなれば、ユーザの立場から見ても問題がある。サービスプロバイダは通常、提供するサービスが一定の最低限の品質で配信されることを保証できることに関心がある。サービス品質が悪いと、たとえ悪い品質の原因がネットワークオペレータや端末ベンダであった場合にも、サービスプロバイダの評判に傷がつく可能性がある。ＱｏＳが悪いと、サービスのユーザはいら立ち、品質が悪いと言ってサービスプロバイダを非難するであろう。あるサービスコンテンツを受信するとき、１つの端末を持つあるユーザに対して受け入れ難い悪いＱｏＳがもたらされる一方で、別のベンダが提供している端末を持つ別のユーザに対しては、同じサービスコンテンツを受信するとき、満足できるＱｏＳがもたらされるということも起こり得る。

本発明によると、プッシュメッセージによって開始されるサービスのサービスコンテンツを配信するのに使われるベアラサービスのＱｏＳパラメータの選択に、サービスプロバイダが影響を与えることができる。これは、クライアント移動体端末によって設定されるベアラサービス用としてサービスプロバイダが推奨する推奨ＱｏＳパラメータも含めるようにプッシュメッセージを修正することによって達成される。

図３は、図２に図示したサービスに対応するけれども、本発明が適用されるサービスを模式的に図示する流れ図である。図３は、サービスプロバイダのネットワークノード１０６ａが、ステップ３０１で、プッシュメッセージ３０９をクライアント移動体端末１０２ａに送信することによってサービスを開始することを図示している。本発明によれば、プッシュメッセージ３０９は推奨ＱｏＳパラメータの組を有している。プッシュメッセージ３０９は、例えば、推奨ＱｏＳパラメータの組を追加することにより修正を施されたＷＡＰプッシュサービスローディング（ＳＬ）メッセージであってもよい。プッシュメッセージ３０９がクライアント移動体端末で受信されると、プッシュメッセージ３０９は対象ユーザエージェント３１０に転送され、その後、対象ユーザエージェント３１０はステップ３０２で起動する。ユーザエージェント３１０或はクライアント移動体端末の中の支援ソフトウェアは処理手段３１１に提供され、その処理手段は、その後、ステップ３０３で、プッシュメッセージから推奨ＱｏＳパラメータの組を取り出して処理し、推奨ＱｏＳパラメータの組に対応するＰＤＰコンテキストパラメータを決定する。その後、ステップ３０４で、ユーザエージェントは、ステップ３０３で決定されたＰＤＰコンテキストパラメータを使ってＰＤＰコンテキストを要求する。ＰＤＰコンテキストが設定されたという確認をクライアント移動体端末が受信した時、その端末はステップ３０５でサービスコンテンツを入手できる。

図３に図示された手順によって、サービスプロバイダは、クライアント移動体端末内部の“ハードコーディングされた（hard coded）”ＱｏＳパラメータに依存する代わりに、ベアラサービスのＱｏＳに影響を与えることができるようになる。図３の手順を実施するには、推奨ＱｏＳパラメータの組も含むようにプッシュメッセージを修正するためにプッシュメッセージの送り手側で、そして、修正されたプッシュメッセージを解釈するために端末側で、それぞれ修正が必要である。

本発明に従う移動端末１０２ａは、移動体端末に配信されるサービスコンテンツを表すプッシュメッセージ３０９の中の推奨ＱｏＳパラメータの組を取り出して処理するように適合されている。プッシュメッセージから推奨ＱｏＳパラメータの組を取り出し、取り出したパラメータの組を処理し、そして、取り出したパラメータの組に基づいてベアラサービス用のＱｏＳを要求する処理手段３１１で従来技術による端末を補完することによって、そのような移動端末が実現できる。好適な実施例に従う処理手段３１１はプッシュメッセージ３０９が対象としたアプリケーション３１０のソフトウェアコード手段であろう。また、その処理手段は、アプリケーションの外側にあって、プッシュメッセージの受信時にアプリケーションが呼び出すような、支援ソフトウェア機能のソフトウェア手段であってもよい。一般的なコンピュータ言語を用いてそのようなソフトウェアコード手段がここで説明した機能を実行できるために、そのようなソフトウェアコード手段を実装する方法は当業者にはよく知られており、これ以上詳細には説明しない。

本発明に従う移動端末１０２ａの好適な実施例によれば、プッシュメッセージ３０９の中の推奨ＱｏＳパラメータの組を使ってサービスプロバイダが推奨するのと同じＱｏＳを設定予定のベアラサービス用として要求するように、その移動体端末が構成されている。しかしながら、移動体端末が推奨ＱｏＳパラメータの組を処理し、若干異なるＱｏＳをベアラサービス用に要求するよう決定することも可能である。端末ベンダは、例えば、サービスプロバイダが推奨する何らかの帯域幅に対しても常にあるマージンを加えるように移動体端末を実現するかもしれない。例えば、サービスプロバイダが６４ｋｂ／ｓの保証ビットレートをベアラサービスに推奨していることを示すＱｏＳパラメータをプッシュメッセージが有していると仮定しよう。移動体端末は、その後、プッシュメッセージ中のＱｏＳパラメータを処理するとき、２ｋｂ／ｓのマージンを加えるように実現されてもよく、従って、移動体端末はベアラサービス用に６６ｋｂ／ｓの保証ビットレートを要求することになる。本発明の考え方は、このように、移動体端末は自分のＱｏＳ要求をサービスプロバイダの推奨するＱｏＳに基づいて行えるけれども、それに完全に制限されないようにすることである。

プッシュメッセージ３０９は、サービスプロバイダからプッシュされたメッセージであって、移動体端末に配信するサービスコンテンツをサービスプロバイダが有しているという情報を含むことによってサービスを開始するものであれば、いかなるタイプであってもよい。本発明に従うプッシュメッセージ３０９は、推奨ＱｏＳパラメータの組も有している。そのプッシュメッセージは、例えば、推奨ＱｏＳパラメータの組を追加した形のＱｏＳ情報を備えたＷＡＰプッシュサービス表示メッセージ或はＷＡＰプッシュサービスローディングメッセージであってもよい。サービスプロバイダが端末に配信するサービスコンテンツを有しているという情報は、例えば、サービスコンテンツを示すＵＲＩ（Uniform Resource Identifier：ユニフォーム・リソース・アイデンティファイア）であってもよい。

プッシュメッセージ３０９は多様な技術を用いて移動体端末にプッシュされてもよい。一つの技術は、プッシュメッセージをＳＭＳの中で配信することである。移動体端末が別のサービス用に確立された一次ＰＤＰコンテキストをすでに有しているならば、プッシュメッセージを一次ＰＤＰコンテキストにより端末１０２ａに転送することも可能であるかもしれない。移動端末は、その後、プッシュメッセージ３０９によって示されたサービスコンテンツを配信するための二次ＰＤＰコンテキストを要求するであろう。

時には、プッシュメッセージを受信したとき、サービスコンテンツを受信するためのベアラサービスを設定しない方が望ましい場合もある。これは、例えば、端末の電池残量が少ない場合や、その時ローミング中であるか外国に滞在中で、ユーザの加入条件が海外へのサービス配信をサポートしていない場合などが該当する。そのような場合、移動体端末１０２ａは、プッシュメッセージ３０９に応答しないか、または、例えば、電池が充電されるか端末がローミングしていない状態になるかのいずれかになるまで提案されたサービスの受信を遅延させるかによって、その提案されたサービスを拒否するように構成されてもよい。

ネットワーク側、即ち、プッシュメッセージ３０９を創成して送信する側では、本発明の異なる幾つかの実施例がありえる。さまざまなネットワークノードが、端末にプッシュされるメッセージの中に推奨ＱｏＳパラメータの組を含むように適合されてもよい。ＱｏＳ情報は、例えば、アプリケーションサーバ、ポリシサーバ、或は、プッシュプロキシゲートウェイによって提供されてもよい。

図４は、アプリケーションサーバ４０９がＱｏＳ情報をプッシュメッセージ３０９に挿入する状況の例を図示する模式的な流れ図である。この例では、プッシュメッセージは、端末１０２ａに配信されるサービスコンテンツを提供するアプリケーションサーバ４０９で創成されるＷＡＰプッシュメッセージである。この実施例に従えば、メッセージ３０９は、対象ユーザエージェント（ＵＡ）の表示、通常のＷＡＰプッシュサービスローディング（ＳＬ）メッセージの情報、そして、推奨ＱｏＳパラメータの組を有している。プッシュメッセージ３０９は、ステップ４０１ａでプッシュプロキシゲートウェイ４１０へと送信される。そのメッセージは、「今日のＯＭＡ／ＷＡＰ標準」で定義されているＰＡＰ ＡＰＩ（プッシュ・アクセス・プロトコル・アプリケーション・プログラミング・インタフェース（Push Access Protocol Application Programming Interface））の修正バージョンを使って送信されてもよく、これについてはＷＡＰフォーラム（登録商標）のウェブサイト（http://www.wapforum.org）で公開中の文書“プッシュ・アクセス・プロトコル（Push Access Protocol）、２００１年４月２９日版”を参照されたい。ＡＰＩは、ＱｏＳパラメータの組をプッシュメッセージの中に包含するのをサポートするように修正される必要がある。メッセージを端末１０２ａに転送する前に、プッシュプロキシゲートウェイは、ステップ４０２で、アプリケーションサーバ４０９がメッセージを端末に送信することを許可されていることを、ポリシサーバ４１１を使ってチェックする。ポリシサーバ４１１からの確認後、プッシュプロキシゲートウェイ４１０は、推奨ＱｏＳパラメータの組を含むメッセージ３０９を端末１０２ａに転送する。この例では、転送はＳＭＳを使って行われる。上述のとおり、端末１０２ａはそれから、指定されたユーザエージェントを起動してメッセージを処理し、その後、そのユーザエージェントは、ステップ４０３ａで、ＵＴＲＡＮのＲＮＣ（無線ネットワーク制御局）を介して、ＵＭＴＳコアネットワークのＳＧＳＮ（サービングＧＰＲＳサポートノード）にＰＤＰコンテキストを起動する要求を送信することによって、ＰＤＰコンテキストを起動するであろう。この要求は、プッシュメッセージ３０９で送信された推奨ＱｏＳパラメータの組を含んでいることが好ましい。当業者にはよく知られているように、ＰＤＰコンテキストの起動は、その後、ＳＧＳＮ４１３からＧＧＳＮ（ゲートウェイＧＰＲＳサポートノード）４１２へのＰＤＰコンテキスト創成要求、ＧＧＳＮからＳＧＳＮへのＰＤＰコンテキスト創成応答、そして、ＳＧＳＮから端末へのＰＤＰコンテキスト起動承認というように、ステップ４０３ｂからｄへと続く。ＰＤＰコンテキストが設定されると、ステップ４０４で、端末はプッシュメッセージに指定されたサービスコンテンツをフェッチでき、ステップ４０５で、アプリケーションサーバ４０９はサービスコンテンツを端末に配信する。

図５は、ポリシサーバ４１１がプッシュメッセージ３０９でＱｏＳ情報を提供する別の実施例の一例を図示する模式的な流れ図である。この場合、アプリケーションサーバ４０９は、ステップ５０１で、従来技術による解決策と同じ方法でＷＡＰプッシュメッセージをプッシュプロキシゲートウェイ４１０に送信する。プッシュプロキシゲートウェイ４１０はそれから、ステップ５０２で、アプリケーションサーバがメッセージを端末に送信することが許可されていることを、ポリシサーバを使ってチェックする。ポリシサーバは、ステップ５０３で、端末に転送されるべき推奨ＱｏＳパラメータの組を応答のプッシュメッセージで送信する。プッシュプロキシゲートウェイ４１０はそれから、ステップ５０４で、ＱｏＳ要件の組を添えてアプリケーションサーバから受信したメッセージを、ＳＭＳを使って端末１０２ａに転送する。図５に図示する残りのステップ５０５ａ−ｄ、５０６、及び５０７は、図４に図示して上記で説明したステップ４０４ａ−ｄ、４０５、及び４０６と同じである。

図６はプッシュプロキシゲートウェイ４１０がプッシュメッセージ３０９にＱｏＳ情報を提供して挿入する別の代替の実施例の一例を図示する模式的な流れ図である。この場合、アプリケーションサーバ４０９は、ステップ６０１で、従来技術による解決策と同じ方法でＷＡＰプッシュメッセージをプッシュプロキシゲートウェイ４１０に送信する。プッシュプロキシゲートウェイ４１０はそれから、ステップ６０２で、アプリケーションサーバがメッセージを端末に送信することを許可されていることを、ポリシサーバ４１１を使ってチェックする。ポリシサーバからの確認後、プッシュプロキシゲートウェイは、ステップ６０３で、端末に送信されるべきＱｏＳパラメータの組を決定し、その組をアプリケーションサーバから受信したプッシュメッセージの中に挿入する。このＱｏＳパラメータが、例えば、サービスコンテンツのタイプと、サービスコンテンツを提供するアプリケーションと、端末が存在するネットワークとの内、少なくともいずれかに依存する規則の組に基づいて決定されるように、プッシュプロキシゲートウェイが実現されてもよい。プッシュプロキシゲートウェイ４１０はそれから、ステップ６０４で、創成されたプッシュメッセージをＱｏＳ要件の組と共に、ＳＭＳを使って端末１０２ａに転送する。図６に図示した残りのステップ６０５ａ−ｄ、６０６、及び６０７は、図４に図示して上記で説明したステップ４０４ａ−ｄ、４０５、及び４０６と同じである。

端末へとプッシュされるメッセージに推奨ＱｏＳパラメータを決定して挿入するように異なるネットワークノードが適合されることは、図４〜図６に図示した例から明らかである。図３に図示されたネットワークノード１０６ａは、従って、例えば、アプリケーションサーバ４０９、ポリシサーバ４１１、或はプッシュプロキシゲートウェイ４１０を表している。推奨ＱｏＳパラメータをプッシュメッセージ３０９に挿入するため、ネットワークノードは好ましくは、推奨ＱｏＳパラメータの組を含むプッシュメッセージの創成をサポートするソフトウェアコード手段３１２とともに実装されるとよい。そのネットワークノードはまた、メッセージを端末１０２ａにプッシュするためのインタフェース３１３を含む必要があるだろう。推奨ＱｏＳパラメータの決定に責任があるノードは、これを行うための手段３１４を備えている必要があるだろう。そのような手段は、例えば、ある特定の基準に基づいて推奨ＱｏＳパラメータを導出するための規則や公式を定義するソフトウェアコード手段であってもよい。推奨ＱｏＳパラメータが依存するそのような特定の基準とは、例えば、端末ユーザの加入条件のタイプ、端末に配信されるべきサービスコンテンツのタイプ、サービスを配信するアプリケーション、曜日、あるいは、ネットワーク負荷や端末の地理的位置といった何らかの関連ネットワーク情報であってもよい。

ＱｏＳパラメータを決定するノードにもよるが、異なる基準を考慮することも可能である。例えば、サービスプロバイダがＣＮＮであるとするならば、ＣＮＮは同社のサービスについて常に１２８ｋｂ／ｓの保証ビットレートで受信するようにネットワーク運用者と合意を結んでいるかもしれない。その場合、推奨ＱｏＳパラメータを決定するノードは、ＣＮＮがサービスコンテンツを配信しているときは、推奨ＱｏＳパラメータの１つは１２８ｋｂ／ｓの保証ビットレートとすることを決定するように構成されてもよい。もう一つの例は、推奨ＱｏＳパラメータが端末ユーザの加入条件に依存するときである。第１のユーザがあるネットワーク運用者との“ゴールド（第１級）の加入条件”を有しており、第２のユーザがそのネットワーク運用者との“シルバー（第２級）の加入条件”を有していると仮定しよう。その場合、もしプッシュメッセージが第１の端末に送信される予定であるならば１２８ｋｂ／ｓの保証ビットレートが推奨ＱｏＳパラメータであり、もしプッシュメッセージが第２のユーザに送信される予定であるならば６４ｋｂ／ｓの保証ビットレートが推奨ＱｏＳパラメータであることが、例えば、ポリシサーバによって決定されてもよい。

また、推奨ＱｏＳパラメータの組の決定にいくつかのネットワークノードが関与することもあり得る。アプリケーションサーバが、例えば、推奨ＱｏＳパラメータの第１の組を決定し、それをポリシサーバが端末ユーザの加入条件をチェックした後で修正してもよい。また、推奨ＱｏＳパラメータの決定は、いくつかのネットワークノード間のネゴシエーションに基づいて決定されてもよい。

推奨ＱｏＳパラメータの組は１つのパラメータ値、或は、複数のパラメータを含むことがある。推奨ＱｏＳパラメータの組は、明確なパラメータ値の形、定義済のＵＭＴＳ ＱｏＳ属性についての推奨値の形、或はＰＤＰコンテキストパラメータでもよい。また、推奨Ｑｏｓパラメータの組は、そのためのＱｏＳパラメータが事前に決定されている予め定義された推奨ＵＭＴＳ ＱｏＳクラスの表示とすることもできる。

図７は、あるシナリオを図示する模式的な流れ図である。このシナリオでは、一次ＰＤＰコンテキスト７０１が存在し、プッシュメッセージ３０９が一次ＰＤＰコンテキストにより端末１０２ａに転送される。一次ＰＤＰコンテキストにより、端末ユーザがインターネットを閲覧できるように設定されていてもよい。インターネット閲覧中、ステップ７０２で、ユーザは自分がＭＰ３ファイルを聴取したいと思っていることを示唆することがあり、それに起因して、アプリケーションサーバ４０９が、ステップ７０３ａで、二次ＰＤＰコンテキストの設定を開始するため、プッシュメッセージ３０９をプッシュプロキシゲートウェイ４１０に送信することがある。プッシュプロキシゲートウェイは、プッシュメッセージ３０９を端末１０２ａに転送する前に、ステップ７０４でポリシチェックを開始してもよい。プッシュメッセージ３０９は、通常のＩＰ接続を用いてＧＧＳＮ４１２に転送され、一次ＰＤＰコンテキスト７０１によりＧＧＳＮ４１２から端末１０２ａに転送される。プッシュメッセージ３０９と端末１０２ａの推奨ＱｏＳパラメータの組とを処理した後、ステップ７０５ａ−７０５ｄで、二次ＰＤＰコンテキストが設定される。サービスコンテンツが、その後ステップ７０６で、二次ＰＤＰコンテキストにより端末１０２ａに配信され、それにより端末ユーザはＭＰ３ファイルを聴取できるようになる。図７のプッシュメッセージ３０９の例示は、そのプッシュメッセージがＴＦＴ（トラフィック・フロー・テンプレート）を含んでいることを示している。ＴＦＴは、当業者にはよく知られているとおり、２つのＰＤＰコンテキストのうちどちらでペイロードを送信すべきかを決定するメカニズムを提供するために送信される。

本願では、推奨ＱｏＳパラメータの組は、サービスコンテンツ受信のためのベアラサービス用に端末が要求することをサービスプロバイダが推奨するＱｏＳパラメータの組であることについて述べた。なお、この文言は、異なるネットワークノードが異なる基準に基づいて推奨ＱｏＳパラメータを決定する上記の複数の例をすべて包含することが意図されている。“サービスプロバイダ”という用語は、従って、広義に解釈されるべきであり、例えば、サービスコンテンツのプロバイダとネットワークベアラサービスを提供するネットワークオペレータとを両方包含すると解釈されるべきである。

本発明により、サービスプロバイダからのプッシュメッセージの中に示されていたサービスコンテンツを配信するためのベアラサービス用に端末が要求するＱｏＳにサービスプロバイダが影響を与えることが可能になることが、本発明の代表的な実施例から明らかである。本発明は推奨ＱｏＳパラメータの組をプッシュメッセージの中に含める可能性を提供しているのであるから、このことが可能である。

図面と明細書において、本発明の代表的な好適な実施例を開示してきたが、特定の用語が採用されているとはいえ、それらは一般的な説明の意味でのみ用いられているのであって、限定を目的としているのではなく、本発明の範囲は添付した請求の範囲において説明される。

本発明が用いられる移動通信システムの一般的なネットワークアーキテクチャを図示する模式的なブロック図である。 アプリケーションサーバからのプッシュメッセージによって開始される従来技術に従うサービスを模式的に図示する流れ図である。 図２に図示するサービスに対応するが、本発明が適用されているサービスを模式的に図示する流れ図である。 本発明に従うネットワークノードの代表的な実施例と本発明に従う移動通信端末の代表的な実施例との機能を図示する模式的なシグナリング／流れ図である。 本発明に従うネットワークノードの別の代表的な実施例と本発明に従う移動通信端末の代表的な実施例との機能を図示する模式的なシグナリング／流れ図である。 本発明に従うネットワークノードのさらにもう１つの代表的な実施例と本発明に従う移動通信端末の代表的な実施例との機能を図示する模式的なシグナリング／流れ図である。 本発明に従うネットワークノードのさらに別の代表的な実施例と本発明に従う移動通信端末の代表的な実施例との機能を図示する模式的なシグナリング／流れ図である。

Claims (42)

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. 前記ネットワークノードは、予め確立された第１のパケットデータプロトコルコンテキスト（７０１）により、前記サービス表示メッセージを前記第１のクライアント端末（１０２ａ）にプッシュするよう構成され、
    前記推奨サービス品質パラメータの組は、第２のパケットデータプロトコルコンテキストのためのパケットデータプロトコルコンテキストの推奨サービス品質パラメータの組であることを特徴とする請求項２１乃至２５のいずれか１項に記載のネットワークノード。
27. 前記サービスプロバイダが前記端末に配信するためのサービスコンテンツをもっているという情報は、前記サービスコンテンツを示すユニフォーム・リソース・アイデンファイア（ＵＲＩ）を有していることを特徴とする請求項２１乃至２６のいずれか１項に記載のネットワークノード。
28. 前記推奨サービス品質パラメータの組は、前もって定義されたＵＭＴＳ ＱｏＳクラスに対する表示を有していることを特徴とする請求項２１乃至２７のいずれか１項に記載のネットワークノード。
29. 前記推奨サービス品質パラメータの組は、少なくとも１つのＵＭＴＳ ＱｏＳ属性に対する推奨値を有していることを特徴とする請求項２１乃至２８のいずれか１項に記載のネットワークノード。
30. 前記ネットワークノードは、前記サービスプロバイダのアプリケーションサーバ（４０９）であることを特徴とする請求項２１乃至２９のいずれか１項に記載のネットワークノード。
31. 前記ネットワークノードはポリシサーバ（４１１）であり、
    前記ポリシサーバはさらに、前記サービスプロバイダが前記第１のクライアント端末（１０２ａ）に前記サービス表示メッセージをプッシュすることが許されていることをチェックするために構成されていることを特徴とする請求項２１乃至２９のいずれか１項に記載のネットワークノード。
32. 前記ネットワークノードはプッシュプロキシゲートウェイ（４１０）であり、
    前記プッシュプロキシゲートウェイは、アプリケーションサーバ（４０９）から受信したサービスメッセージに基づいて前記サービス表示メッセージ（３０９）を創成するために構成されていることを特徴とする請求項２１乃至２９のいずれか１項に記載のネットワークノード。
33. パケットデータサービスの組をサービスプロバイダからクライアント移動体端末に提供するネットワークのネットワークノード（１０６ａ）における方法であって、前記方法は、
    第１のクライアント端末（１０２ａ）にプッシュ送信されるサービス表示メッセージ（３０９）を創成する工程と、
    前記サービス表示メッセージ（３０９）を前記第１のクライアント端末（１０２ａ）にプッシュする工程とを有し、
    前記サービス表示メッセージ（３０９）は、前記サービスプロバイダが前記第１のクライアント端末に配信するサービスコンテンツを有しているという情報と、前記サービスコンテンツを受信するためのベアラサービス用に前記第１のクライアント端末が要求することを前記サービスプロバイダが推奨する推奨サービス品質パラメータの組とを含むことを特徴とする方法。
34. 前記方法はさらに、前記サービスコンテンツのタイプと、前記端末のユーザの加入タイプと、前記ベアラサービスが設定される前記ネットワークについての情報と、前記サービスコンテンツのプロバイダとの内の少なくとも１つについての入力情報に基づいて、前記推奨サービス品質パラメータの組を決定することを特徴とする請求項３３に記載の方法。
35. 前記推奨サービス品質パラメータの組は、パケットデータプロトコルコンテキストの推奨サービス品質パラメータの組であることを特徴とする請求項３３又は３４に記載の方法。
36. 前記サービス表示メッセージ（３０９）は、前記推奨サービス品質パラメータの組を付加することにより修正されたＷＡＰプッシュサービスローディングメッセージであることを特徴とする請求項３３乃至３５のいずれか１項に記載の方法。
37. 前記サービス表示メッセージは、前記推奨サービス品質パラメータの組を付加することにより修正されたＷＡＰプッシュサービス表示メッセージであることを特徴とする請求項３３乃至３５のいずれか１項に記載の方法。
38. 前記サービス表示メッセージ（３０９）は、予め確立された第１のパケットデータプロトコルコンテキスト（７０１）により前記第１のクライアント端末（１０２ａ）にプッシュされ、
    前記推奨サービス品質パラメータの組は、第２のパケットデータプロトコルコンテキストのためのパケットデータプロトコルコンテキストの推奨サービス品質パラメータの組であることを特徴とする請求項３３乃至３７のいずれか１項に記載の方法。
39. 前記サービスプロバイダが前記端末に配信するためのサービスコンテンツをもっているという情報は、前記サービスコンテンツを示すユニフォーム・リソース・アイデンファイア（ＵＲＩ）を有していることを特徴とする請求項３３乃至３８のいずれか１項に記載の方法。
40. 前記推奨サービス品質パラメータの組は、前もって定義されたＵＭＴＳ ＱｏＳクラスに対する表示を有していることを特徴とする請求項３３乃至３９のいずれか１項に記載の方法。
41. 前記推奨サービス品質パラメータの組は、少なくとも１つのＵＭＴＳ ＱｏＳ属性に対する推奨値を有していることを特徴とする請求項３３乃至４０のいずれか１項に記載の方法。
42. 前記方法はさらに、前記サービスプロバイダが、所定のポリシをチェックすることにより、前記第１のクライアント端末（１０２ａ）に前記サービス表示メッセージ（３０９）をプッシュすることが許されているかどうかをチェックすること含むことを特徴とする請求項３３乃至４１のいずれか１項に記載の方法。

Images