(57)【要約】通信ネットワーク（２０２）において、特定のサービスを配信するのに必要なネットワークリソースを確保する目的で第三者コンテンツプロバイダ（２００）とネットワークの事業者との間でＳＬＡ（サービスレベル契約）を確立するための方法およびＳＬＡポータル（２０４）。サービスを求めるＳＬＡリクエスト（２：１）がコンテンツプロバイダから受信される場合、複数の所定のＳＬＡを保持するＳＬＡデータベース（２０６）から、少なくとも１つの実行可能な所定のＳＬＡが検索される（２：２）。次いで、検索された少なくとも１つの実行可能なＳＬＡが、任意で割り当てられたサービス識別子と共に、提示されるかたちでコンテンツプロバイダへ送信される（２：３）。それによって、ＳＬＡを確立するプロセスが自動化され、いかなる物理的な会合やその他の連絡も回避され、時間とコストの節約になる。
2010517160.tif 000002
【特許請求の範囲】
【請求項１】
第三者コンテンツプロバイダ（２００）と通信ネットワーク事業者（２０２）との間で、前記コンテンツプロバイダからエンドユーザへ配信される場合に特定のサービスまたはサービスタイプに必要なネットワークリソースを確保することを目的として、ＳＬＡ（サービスレベル契約）を確立するための方法であって、
前記ネットワーク事業者のネットワークの中のＳＬＡポータル（２０４）において前記サービスまたはサービスタイプを求めるＳＬＡリクエスト（２：１）を前記コンテンツプロバイダから受信する工程と、
少なくとも１つの実行可能な所定のＳＬＡを、複数の所定のＳＬＡを保持するＳＬＡデータベース（２０６）から検索する工程（２：２）と、
前記サービスまたはサービスタイプにサービス識別子を割り当てる工程と、
前記少なくとも１つの検索された実行可能なＳＬＡを前記コンテンツプロバイダに提示する工程（２：３）と、
前記少なくとも１つの提示された実行可能なＳＬＡから前記コンテンツプロバイダによって選択されたＳＬＡを確立する工程（２：６、２：５ｂ）と
を有し、
前記割り当てられたサービス識別子が、前記サービスが前記コンテンツプロバイダからリクエスト側エンドユーザへ配信される場合にはいつでも、前記確立されたＳＬＡを適用するために用いられることを特徴とする方法。
【請求項２】
前記ＳＬＡポータルが、前記少なくとも１つの提示された実行可能なＳＬＡと共にかまたは別個に、前記割り当てられたサービス識別子も前記コンテンツプロバイダに送信することを特徴とする請求項１に記載の方法。
【請求項３】
前記コンテンツプロバイダからのＳＬＡ確立リクエストに応じて、前記ＳＬＡポータルが前記割り当てられたサービス識別子を参照することによってコンテンツプロバイダデータベースの中でポリシー提供を行う工程を、前記確立する工程が含むことを特徴とする請求項２に記載の方法。
【請求項４】
前記コンテンツプロバイダが、受信した前記割り当てられたサービス識別子を参照することによってコンテンツプロバイダデータベースの中でポリシー提供を行う工程を、前記確立する工程が含むことを特徴とする請求項２に記載の方法。
【請求項５】
前記サービスまたはサービスタイプについてのＵＲＬ等が前記受信したＳＬＡリクエストの中に含まれており、
前記方法は、前記サービスＵＲＬと前記割り当てられたサービス識別子の間の結合を前記ネットワーク事業者のアプリケーション機能（２０８）の中かまたは前記アプリケーション機能にアクセス可能なデータベースの中に記憶する工程をさらに有し、前記アプリケーション機能は前記サービスＵＲＬに対する移動ユーザからのコンテンツリクエストを処理するように構成されていることを特徴とする請求項１乃至４のいずれか１項に記載の方法。
【請求項６】
割り当てられたコンテンツプロバイダ識別子も前記結合の中に含まれることを特徴とする請求項５に記載の方法。
【請求項７】
前記サービスまたはサービスタイプについてのＵＲＬ等に対するエンドユーザからのリクエストを受信した場合に、前記コンテンツプロバイダが、そのＵＲＬを前記サービス識別子にマッピングして、前記サービスを配信するためにネットワークリソースを求めるリクエストの中で前記サービス識別子を参照することを特徴とする請求項２に記載の方法。
【請求項８】
割り当てられたコンテンツプロバイダ識別子が、前記割り当てられたサービス識別子と共に前記コンテンツプロバイダに送信され、かつ、前記コンテンツプロバイダが前記ネットワークリソースリクエストの中に前記コンテンツプロバイダ識別子も有することを特徴とする請求項７に記載の方法。
【請求項９】
前記割り当てられたサービス識別子が、前記コンテンツプロバイダと組み合わせられた前記サービスにも有効であることを特徴とする請求項１乃至５および７のいずれか１項に記載の方法。
【請求項１０】
前記ＳＬＡリクエストより先に前記コンテンツプロバイダから登録リクエストを受信する工程と、
前記コンテンツプロバイダ識別子を割り当てることによって前記リクエストされたコンテンツプロバイダについての登録を確立する工程と、
前記コンテンツプロバイダ識別子を含めて登録応答を前記コンテンツプロバイダへ返信する工程とをさらに含むことを特徴とする請求項５に記載の方法。
【請求項１１】
前記リクエストされた登録を確立する工程が、前記コンテンツプロバイダの信頼性および信用度またはそのいずれかを制御する工程を有することを特徴とする請求項１０に記載の方法。
【請求項１２】
所定のＳＬＡの中の前記サービスパラメータは、選択されたＳＬＡの中に前記コンテンツプロバイダが特定のパラメータ値を設定することができるような、パラメータインタバルを備えた枠組みとして指定されることを特徴とする請求項１乃至１１のいずれか１項に記載の方法。
【請求項１３】
前記ＳＬＡデータベースの中の前記所定のＳＬＡは、代替アクセスメカニズム、課金メカニズム、そして加入タイプのうちから少なくとも１つを含む選択肢を伴って構成されることを特徴とする請求項１乃至１２のいずれか１項に記載の方法。
【請求項１４】
前記ＳＬＡデータベースの中の前記所定のＳＬＡは、デフォルトパラメータ設定および属性で構成され、それらが提示された場合、前記コンテンツプロバイダは、それらを選択されたＳＬＡについての所与の枠組みの限度内で自由に受入れるかまたは変更することを特徴とする請求項１２または１３に記載の方法。
【請求項１５】
前記少なくとも１つの実行可能な所定のＳＬＡが、前記受信されたＳＬＡリクエストの中に与えられた前記コンテンツプロバイダおよびサービスまたはサービスタイプに基づいて前記ＳＬＡデータベースから検索されることを特徴とする請求項１乃至１４のいずれか１項に記載の方法。
【請求項１６】
事業者の通信ネットワーク内のＳＬＡ（サービスレベル契約）ポータルであって、前記コンテンツプロバイダからエンドユーザへ配信される場合に特定のサービスまたはサービスタイプに必要なネットワークリソースを確保する第三者コンテンツプロバイダとＳＬＡを確立することを目的として、
特定のサービスまたはサービスタイプを求めるＳＬＡリクエストをコンテンツプロバイダから受信するための手段（５０４）と、
複数の所定のＳＬＡを保持しているＳＬＡデータベースから少なくとも１つの実行可能な所定のＳＬＡを検索するための手段（５０６）と、
前記サービスまたはサービスタイプにサービス識別子を割り当てるための手段（５０８）と、
前記検索された少なくとも１つの実行可能なＳＬＡを提示するかたちで前記コンテンツプロバイダへ送信する手段（５１０）とを備え、
前記サービスが前記コンテンツプロバイダからリクエスト側エンドユーザへ配信される場合にはいつでも、前記少なくとも１つの提示された実行可能なＳＬＡから前記コンテンツプロバイダによって選択された確立されたＳＬＡを適用するため、前記割り当てられたサービス識別子が用いられることを特徴とするＳＬＡポータル。
【請求項１７】
前記ＳＬＡポータルがさらに、前記少なくとも１つの提示された実行可能なＳＬＡと共にかまたは別個に、前記割り当てられたサービス識別子を前記コンテンツプロバイダに送信するための手段（５１０）を備えることを特徴とする請求項１６に記載のＳＬＡポータル。
【請求項１８】
前記ＳＬＡポータルがさらに、前記コンテンツプロバイダからのＳＬＡ確立リクエストに応じて、コンテンツプロバイダデータベースの中で前記割り当てられたサービス識別子を参照してポリシー提供を実行することによって、前記少なくとも１つの提示された実行可能なＳＬＡから前記コンテンツプロバイダによって選択されたＳＬＡを確立するための手段（５１２）を備えることを特徴とする請求項１７に記載のＳＬＡポータル。
【請求項１９】
前記サービスまたはサービスタイプについてのＵＲＬ等が前記受信したＳＬＡリクエストの中に含まれており、
前記サービスＵＲＬと前記割り当てられたサービス識別子の間の結合を前記事業者のアプリケーション機能の中かまたは前記アプリケーション機能にアクセス可能なデータベースの中に記憶する手段をさらに備え、前記アプリケーション機能は前記サービスＵＲＬに対する移動ユーザからのコンテンツリクエストを処理するように構成されていることを特徴とする請求項１６乃至１８のいずれか１項に記載のＳＬＡポータル。
【請求項２０】
割り当てられたコンテンツプロバイダ識別子も前記結合の中に含まれることを特徴とする請求項１９に記載のＳＬＡポータル。
【請求項２１】
前記サービスまたはサービスタイプについてのＵＲＬ等に対するエンドユーザからのリクエストを受信した場合に、前記コンテンツプロバイダが、そのＵＲＬを前記サービス識別子にマッピングして、前記サービスを配信するためにネットワークリソースを求めるリクエストの中で前記サービス識別子を参照することができるようになるように、前記少なくとも１つの検索された実行可能なＳＬＡと共にかまたは別個に、前記割り当てられたサービス識別子を前記コンテンツプロバイダに送信するための手段をさらに備えることを特徴とする請求項１６に記載のＳＬＡポータル。
【請求項２２】
割り当てられたコンテンツプロバイダ識別子を、前記割り当てられたサービス識別子と共に前記コンテンツプロバイダに送信するように構成され、前記コンテンツプロバイダが前記ネットワークリソースリクエストの中に前記コンテンツプロバイダ識別子も有することができるようになることを特徴とする請求項２１に記載のＳＬＡポータル。
【請求項２３】
前記割り当てられたサービス識別子が、前記コンテンツプロバイダと組み合わせられた前記サービスに有効であることを特徴とする請求項１６乃至１９および２１のいずれか１項に記載のＳＬＡポータル。
【請求項２４】
前記ＳＬＡリクエストより先に前記コンテンツプロバイダから登録リクエストを受信し、前記コンテンツプロバイダ識別子を割り当てることによって前記リクエストされたコンテンツプロバイダについての登録を確立し、そして、前記コンテンツプロバイダ識別子を含めて登録応答を前記コンテンツプロバイダへ返信するように構成されることを特徴とする請求項１９に記載のＳＬＡポータル。
【請求項２５】
前記リクエストされた登録を確立することが、前記コンテンツプロバイダの前記信頼性および信用度またはそのいずれかを制御することを含むことを特徴とする請求項２４に記載のＳＬＡポータル。
【請求項２６】
前記検索手段が、前記受信されたＳＬＡリクエストの中に与えられた前記コンテンツプロバイダおよびサービスまたはサービスタイプに基づいて前記少なくとも１つの実行可能な所定のＳＬＡを前記ＳＬＡデータベースから検索するように構成されることを特徴とする請求項１６乃至２５のいずれか１項に記載のＳＬＡポータル。
【請求項２７】
コンテンツプロバイダからエンドユーザへ配信される場合に特定のサービスまたはサービスタイプに必要なネットワークリソースを確保することを目的として通信ネットワーク事業者とＳＬＡ（サービスレベル契約）を確立するための、コンテンツプロバイダサーバの中の装置であって、
特定のサービスまたはサービスタイプを求めるＳＬＡリクエストを前記ネットワーク事業者の通信ネットワークの中のＳＬＡポータルへ送信するための手段（６０２）と、
前記ＳＬＡポータルから提示され、かつ、複数の所定のＳＬＡを保持しているＳＬＡデータベースから検索された、少なくとも１つの実行可能な所定のＳＬＡを受信するための手段（６０４）と、
前記サービスまたはサービスタイプに割り当てられたサービス識別子をＳＬＡポータルから受信するための手段（６０４）と、
エンドユーザからのリクエストを受信した場合に、前記サービスまたはサービスタイプについてのＵＲＬ等を前記サービス識別子にマッピングするための手段（６０６）と、
前記サービスを前記リクエスト側エンドユーザへ配信するためのネットワークリソースを求めるリクエストであって、前記受信したサービス識別子を参照するような前記リソースリクエストを、送信するための手段（６０８）と
を備えることを特徴とする装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、通信ネットワークにおいて、コンテンツプロバイダと前記ネットワークの事業者との間でサービスレベルの契約を確立することによって、ネットワークリソースをコンテンツプロバイダに提供するための方法および装置に関する。
【背景技術】
【０００２】
今日、コンテンツプロバイダから端末ユーザへ電子的に配信されうる製品およびサービスの市場は急速に拡大している。本明細書では、「コンテンツプロバイダ」という用語は、通信ネットワーク上で、例えばいずれかの注目分野の情報、画像、音声およびビデオコンテンツ等のような電子的なデジタル形式のデータとして配信されるコンテンツを提供する「第三者」を表す。
【０００３】
コンテンツプロバイダは通常、使用される移動ネットワークの利用可能な帯域幅、ビットレート（または「スループット」）、転送遅延、および地理的カバー範囲に大いに依存する、一般的なサービス品質（ＱｏＳ）に関する一定のパラメータに従って、特に移動ユーザに対して多様な製品およびサービスの配信を提供する。例えば、ストリーミングサービスは、受け入れ不可能な遅延または障害がない状態で受信側エンドユーザでの連続的な復号化とコンテンツの提示とを可能にするため、一定の保証されたビットレートの配信を必要とする。
【０００４】
ＵＳ２００４／０１７４８２３Ａ１は、「キャリア」と「顧客」、すなわちエンドユーザ、との間のサポートレベルの契約（「ＳＬＡ」と呼ぶ）を用いるための解決策を開示して、利用可能性、遅延、スループット、顧客サービスおよびコストに関して顧客に対するキャリアの責任の条件を定義している。
【０００５】
提供されたＱｏＳが、コンテンツを端末ユーザに配信する時点で実現されるであろうことを確保するために、コンテンツプロバイダがさらに、下記の明細書の中で「サービスレベル契約」ＳＬＡと呼ばれるコンテンツプロバイダとネットワーク事業者との間の業務契約を、通信ネットワークの事業者と確立してもよい。ＳＬＡは一般に、コンテンツを必要かつ期待されるＱｏＳでエンドユーザに配信するのに必要なネットワークリソースをネットワーク事業者が提供すべきだと命令する。ＳＬＡは通常１つ以上の特定のサービスに関連付けられており、従って、コンテンツプロバイダは異なるサービスについてネットワーク事業者と複数のＳＬＡを有してもよい。
【０００６】
さらに、ネットワーク事業者は、コンテンツプロバイダの代わりに、例えば通常の加入に対する課金またはプリペイド制度によって、いかなる購入されたコンテンツについてもエンドユーザに課金してもよい。コンテンツの購入については、その後、適切な手順に従ってコンテンツプロバイダと定めればよいが、それらは本発明の範囲外である。例えば大手の移動ネットワーク事業者とそのような契約をまとめることによって、コンテンツプロバイダは、そうでない場合より大きな顧客基盤を得ることができる。
【０００７】
図１は、コンテンツプロバイダ１００が、コンテンツをエンドユーザの移動端末Ａに配信する目的で製品およびサービスを提供して、移動ネットワーク事業者１０２からのネットワークリソースを必要とする場合の装置の略図である。第１の段階１：１は、１つ以上のサービスレベル契約（ＳＬＡ）がコンテンツプロバイダ１００ａと事業者１０２の間に確立されることを一般に示し、それには、交渉されたＳＬＡパラメータをコンテンツプロバイダ（ＣＰ）のデータベース１０４に記憶することを含む。従って各ＳＬＡは、コンテンツ配信に必要な帯域幅、ビットレート、および地理的カバー範囲を確保することによって、ＳＬＡに定義されるような一般的なサービス品質を効果的に保証する。
【０００８】
図１のその後の段階は、ネットワーク事業者１０２の各種のよく知られたネットワークノード１０４乃至１１０を用いて、コンテンツプロバイダ１００ａから端末Ａへのコンテンツの配信を可能にするための実現可能な手順を示す。端末Ａはすでに許可され、通常、ＧＧＳＮ（Ｇａｔｅｗａｙ  ＧＰＲＳ  Ｓｗｉｔｃｈｉｎｇ  Ｎｏｄｅ）である事業者のネットワークのゲートウェイ１０６からＩＰ接続を取得していると想定される。
【０００９】
事業者のネットワークの中のアプリケーション機能１０８が、第三者コンテンツプロバイダに対する移動ユーザからのいずれかのリクエストを処理するために用いられる。従って、１：２の段階で事業者１０２のアプリケーション機能１０８は、コンテンツプロバイダ１００ａの特定のサービスに関連するＵＲＬ（Ｕｎｉｆｉｅｄ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）に対する端末Ａからのコンテンツリクエストを受信する。アプリケーション機能１０８がリクエストされたＵＲＬとコンテンツプロバイダ１００ａのＩＤおよび呼び出されたサービスのＩＤとの間のマッピング動作を行った後、リクエストは、ポリシーユニット１１０へさらにルーティングされる。
【００１０】
次の段階１：３では、ポリシーユニット１１０が、識別されたコンテンツプロバイダ／サービスの組み合わせについていずれかのＳＬＡが有効かどうかチェックを行う。有効であれば、リクエストされたコンテンツの端末Ａへの配信についてどのネットワークリソースが割り当てられることになるかを基本的に指示する、そのＳＬＡのポリシーが検索される。
【００１１】
次いで、それに沿って次の段階１：４で、ポリシーユニット１１０が、検索されたポリシーをゲートウェイ１０６にインストールし、そして、必要なネットワークリソースがゲートウェイ１０６に割り当てられ、アプリケーション機能１０８にも通知される。ＳＬＡポリシーをインストールしてネットワークリソースを割り当てる手順は、本発明の概念を理解するためにここで詳細に記述する必要はない。
【００１２】
その後、１：５の段階で、アプリケーション機能１０８は、端末Ａから受信したサービスリクエストをコンテンツプロバイダ１００ａへとルーティングする。それに応じて、最後に示す段階１：６で、リクエストされたコンテンツが、コンテンツプロバイダ１００ａからゲートウェイ１０６を経て、割り当てられたネットワークリソースを用いて配信される。
【００１３】
現在、サービスレベル契約を確立するには通常に、例えばビットレート、帯域幅、転送遅延、地理的カバー範囲に関して、契約のための多様なＳＬＡパラメータを決めることを目的として、コンテンツプロバイダと移動ネットワーク事業者との間の交渉が必要である。従って、多くの場合、ＳＬＡに関して合意することを目的として、当事者双方が物理的に出会って、または少なくともその他のかたちで頻繁に連絡を取り合うことが必要である。上記のように、複数のサービスを提供しているコンテンツプロバイダは、異なるサービスにはＱｏＳ要件に依存して異なるネットワークリソースが必要となる可能性があるため、通常は、特定のサービスの各々についてネットワーク事業者とＳＬＡを確立することを望む。
【００１４】
それゆえ、ＳＬＡの確立に関わる業務は、当然、非常に時間がかかることになり、従って、当事者双方に多大なコストが発生する。従って、多くの小規模なコンテンツプロバイダ等は、ＳＬＡの確立を控えるかもしれず、最終的に、双方にビジネスチャンスを失わせる結果となるかもしれない。従って、コンテンツプロバイダとネットワーク事業者との間のＳＬＡを確立するのに要する努力と時間を全体的に削減することが望ましい。
【００１５】
上記の諸問題は、移動サービスおよび移動ネットワークに排他的に限定されるのではなく、有線ネットワークにおけるサービスにも同様に関連する可能性がある。しかし、無線による通信のための利用可能な帯域幅に限度があることから、ＳＬＡは特に移動ネットワークにおいて必要性が高い。
【発明の概要】
【発明が解決しようとする課題】
【００１６】
上記に概説した諸問題に全般的に取り組むことが本発明の目的である。詳細には、ネットワーク事業者と第三者のコンテンツプロバイダとの間のＳＬＡ（Ｓｅｒｖｉｃｅ  Ｌｅｖｅｌ  Ａｇｒｅｅｍｅｎｔ（サービスレベル契約））を確立するための単純かつ高速でしかも有効なメカニズムを提供することが目的である。
【課題を解決するための手段】
【００１７】
これらの目的等は、以下に添付した独立請求項による方法および装置を提供することによって達成される。
【００１８】
一態様によれば、本発明は、コンテンツプロバイダからエンドユーザへ配信される場合に特定のサービスまたはサービスタイプに必要なネットワークリソースを確保するための、第三者コンテンツプロバイダと通信ネットワーク事業者との間のＳＬＡを確立する方法に関わる。
【００１９】
本発明の方法では、コンテンツプロバイダからのサービスを求めるＳＬＡリクエストが、事業者のネットワーク内のＳＬＡポータルで受信される。少なくとも１つの実行可能な所定のＳＬＡが、複数の所定のＳＬＡを保持しているＳＬＡデータベースから検索され、また、サービス識別子が、そのサービスについて割り当てられる。その少なくとも１つの検索された実行可能なＳＬＡが、コンテンツプロバイダに提示され、その提示されたＳＬＡからコンテンツプロバイダによって選択されたＳＬＡが、確立される。その後、サービスがコンテンツプロバイダからリクエスト側エンドユーザへ配信されるときにはいつでも、確立されたＳＬＡを適用するためにサービス識別子が用いられる。
【００２０】
別の実施形態によれば、ＳＬＡポータルは、少なくとも１つの提示された実行可能なＳＬＡと共にまたは別個に、割り当てられたサービス識別子もコンテンツプロバイダに送信する。ＳＬＡを確立することの中には、コンテンツプロバイダからのＳＬＡ確立リクエストに応じて、ＳＬＡポータルがコンテンツプロバイダデータベースの中でサービス識別子を参照することによってポリシー提供を実行することかまたは、コンテンツプロバイダ自身がコンテンツプロバイダのデータベースの中でサービス識別子を参照することによってポリシー提供を行うことを含んでもよい。
【００２１】
サービスのためのＵＲＬ等がＳＬＡリクエストに含まれていた場合、サービスＵＲＬとサービス識別子との間の結合が、携帯事業者のアプリケーション機能の中かまたはアプリケーション機能にアクセスできるデータベースの中に記憶できてもよい。アプリケーション機能は、そのサービスＵＲＬに対する移動ユーザからのコンテンツリクエストを処理するように構成される。
【００２２】
あるいは、コンテンツプロバイダは、サービスのためのＵＲＬ等に対するリクエストをエンドユーザから受信した場合、そのＵＲＬをサービス識別子とマッピングし、そしてまた、サービスを配信するため、ネットワークリソースを求めるリクエストの中でサービス識別子を参照してもよいだろう。
【００２３】
所定のＳＬＡの中のサービスパラメータは、選択されたＳＬＡの中にコンテンツプロバイダが特定のパラメータ値を設定することができるような、パラメータインタバル（区間）を備えた枠組みとして指定されうる。ＳＬＡデータベースの中の所定のＳＬＡは、代替アクセスメカニズム、課金メカニズム、そして加入タイプのうちから少なくとも１つを含む選択肢を伴って構成されうる。また所定のＳＬＡは、デフォルトパラメータ設定および属性を使って構成することも可能であり、それらが提示された場合、コンテンツプロバイダは、選択されたＳＬＡについての所与の枠組みの限度内でそれらを自由に受入れたり変更したりすることができる。
【００２４】
また別の態様によれば、本発明は、コンテンツプロバイダからエンドユーザへ配信される場合に特定のサービスまたはサービスタイプに必要なネットワークリソースを確保する第三者コンテンツプロバイダとのＳＬＡを確立するための、事業者の通信ネットワーク内のＳＬＡポータルにも関わる。
【００２５】
本発明のＳＬＡポータルは、特定のサービスまたはサービスタイプを求めるＳＬＡリクエストをコンテンツプロバイダから受信する手段と、少なくとも１つの実行可能な所定のＳＬＡをＳＬＡデータベースから検索する手段と、そのサービスのためにサービス識別子を割り当てる手段と、そして、検索された少なくとも１つの実行可能な提示されたＳＬＡをコンテンツプロバイダへ送信する手段とを備える。その後、サービスがコンテンツプロバイダからリクエスト側のエンドユーザへ配信されるときにはいつでも、提示された実行可能なＳＬＡからコンテンツプロバイダによって選択された確立されたＳＬＡを適用するために、割り当てられたサービス識別子が用いられる。
【００２６】
別の実施形態によれば、ＳＬＡポータルは、提示された実行可能なＳＬＡと共にまたは別個に、サービス識別子をコンテンツプロバイダに送信する手段をさらに備える。またＳＬＡポータルは、コンテンツプロバイダからのＳＬＡ確立リクエストに応じて、コンテンツプロバイダデータベースの中で割り当てられたサービス識別子を参照してポリシー提供を行うことによって、提示されたＳＬＡの中からコンテンツプロバイダによって選択されたＳＬＡを確立する手段も備えてもよい。
【００２７】
またＳＬＡポータルは、受信されたＳＬＡリクエストの中に含まれる、サービスのためのサービスＵＲＬ等と、アプリケーション機能がそのサービスＵＲＬに対する移動ユーザからのコンテンツリクエストを処理するように構成されている場合、携帯事業者のアプリケーション機能の中かまたはアプリケーション機能にアクセスできるデータベースの中のサービス識別子との間の結合を、記憶する手段も備えてもよい。
【００２８】
ＳＬＡポータルはさらに、検索された実行可能なＳＬＡと共にかまたは別個に、サービス識別子をコンテンツプロバイダに送信する手段を備えてもよい。またＳＬＡポータルは、割り当てられたコンテンツプロバイダ識別子をサービス識別子と共にコンテンツプロバイダに送信するように構成されてもよく、その場合、コンテンツプロバイダは、コンテンツプロバイダ識別子をネットワークリソースリクエストの中に含むことができるであろう。あるいは、割り当てられたサービス識別子は、コンテンツプロバイダと組み合わさったサービスについて有効であってもよい。
【００２９】
さらに別の態様によれば、本発明はまた、コンテンツプロバイダからエンドユーザへ配信される場合に特定のサービスまたはサービスタイプに必要なネットワークリソースを確保する目的で通信ネットワーク事業者とＳＬＡを確立するための、コンテンツプロバイダサーバの中の装置に関わる。
【００３０】
コンテンツプロバイダサーバの中の本発明の装置は、事業者の通信ネットワーク内のＳＬＡポータルへ特定のサービスまたはサービスタイプを求めるＳＬＡリクエストを送信する手段と、少なくとも１つの提示された実行可能な所定のＳＬＡをＳＬＡポータルから受信する手段と、またサービスに割り当てられたサービス識別子を受信する手段と、エンドユーザからのリクエストの中で受信した場合、サービスのためのＵＲＬ等をサービス識別子にマッピングする手段と、サービスをリクエスト側エンドユーザに配信する目的で、サービス識別子を参照しながら、ネットワークリソースを求めるリクエストを送信する手段とを備える。
【００３１】
本発明によって、特定のサービス／コンテンツプロバイダの組み合わせとネットワーク事業者とのサービスレベル契約を確立する場合に要する努力を全体的に削減することが可能になる。
【００３２】
本発明のさらなる特徴とその利点は、以下の詳細記述の中で説明しよう。
【００３３】
ここで本発明について、好適実施形態によって、また、添付の図面を参照して、より詳細に記述しよう。
【図面の簡単な説明】
【００３４】
【図１】先行技術による、コンテンツプロバイダから移動アクセスネットワークを経て移動端末へのコンテンツ配信を示すブロック図である。
【図２】一実施形態による、コンテンツプロバイダとネットワーク事業者の間でどのようにサービスレベル契約が確立されるかを示すブロック図である。
【図３】別の実施形態による、ネットワーク事業者のＳＬＡポータルに関わる、コンテンツプロバイダとのサービスレベル契約を確立する手順を示すフローチャートである。
【図４】さらに別の実施形態による、コンテンツプロバイダとネットワーク事業者間のサービスレベル契約の確立を示すシグナリング図である。
【図５】さらに別の実施形態による、サービスレベル契約をコンテンツプロバイダと確立するように構成されたネットワーク事業者のＳＬＡポータルを示すブロック図である。
【図６】さらに別の実施形態による、サービスレベル契約をネットワーク事業者と確立するように構成されたコンテンツプロバイダサーバを示すブロック図である。
【発明を実施するための形態】
【００３５】
簡単に言うと、本発明は、「サービスレベル契約ポータル」などと呼ばれてもよいが、これ以降略して「ＳＬＡポータル」と呼ばれる、新しいロジックノードを事業者のネットワーク内に導入する。ＳＬＡポータルは、コンテンツプロバイダによって提供される特定のサービスに関して前記コンテンツプロバイダから発信される、サービスレベル契約を求めるリクエストを自動的に処理し、それによって物理的会合の必要性や当事者双方間の頻繁な連絡の必要性を解消するように構成される。
【００３６】
より詳細には、ＳＬＡポータルは、コンテンツプロバイダからのＳＬＡリクエストに応じて、１つ以上の実行可能な所定のサービスレベル契約をコンテンツプロバイダに提示するように構成される。次いで、リクエスト側コンテンツプロバイダは、特定のサービスまたはサービスタイプについて提示されたサービスレベル契約の１つを選択することができ、それによって、そのサービス／サービスタイプについての選択された契約をネットワーク事業者と自動的に確立することができる。本発明の例示する実施形態を、以下に詳細に記述しよう。下記の例における例については、主に移動ネットワークが用いられるけれども、本発明は、それに限定されず、有線ネットワークについても同様に使用されうる。
【００３７】
図２は、一実施形態による、コンテンツプロバイダ２００とネットワーク事業者２０２との間のサービスレベル契約を確立するための手順と装置とを示すブロック図である。留意すべきだが、図２に従ってＳＬＡを確立した後、エンドユーザの移動端末からのいかなるコンテンツリクエストであっても、基本的に図１に従って処理することができる。従って、図２の本発明の手順を用いて、コンテンツプロバイダについて上記で参照した１：１の段階を基本的に実装して、サービスレベル契約を全般的に確立することができる。下記でコンテンツプロバイダによって行われるいかなる動作も、サーバ等の中に実装されてもよく、従って数２００は、コンテンツプロバイダサーバを表してもよい。
【００３８】
ＳＬＡポータル２０４が、ネットワーク事業者２０２のネットワークの中に導入され、これは、ネットワーク事業者が、異なるサービスおよび異なるコンテンツプロバイダに適用する準備が整っている複数の所定のＳＬＡを有するＳＬＡデータベース２０６を含むかまたはそれに接続している。従って、ＳＬＡデータベース２０６は、特定のサービスまたはサービスタイプに関連する必要でかつ期待されるＱｏＳを使ってコンテンツをエンドユーザに配信するのに必要なネットワークリソースを指示する所定のサービスパラメータの集合を各々が含むような、各種のＳＬＡを構成して記憶することによって構築されうる。
【００３９】
所定のＳＬＡの中のサービスパラメータは、選択されたＳＬＡを確立する場合のポリシー提供プロセスの間に、その中にコンテンツプロバイダが特定のパラメータ値を設定できるようなパラメータインタバルを持つ枠組みとして指定されてもよく、それについては以下に詳述しよう。また所定のＳＬＡは、例えば代替アクセスメカニズム、課金メカニズム、加入タイプ等のような、さらなる属性の選択肢を備えてもよい。ＳＬＡポータル２０４は、コンテンツプロバイダがインターネット経由で容易にアクセスできるいずれかのウェブポータルも含めて、特定のノードとしてかまたは既存のネットワークノードの中の機能的なロジックとして実装されてもよい。
【００４０】
第１のステップ２：１では、ポータル２０４が、ＳＬＡを求めるリクエストをコンテンツプロバイダ２００から受信するが、それは、ＳＬＡがリクエストされている対象のサービスまたはサービスタイプを指定してもよい。あるいは、ＳＬＡポータル２０４は、別個のダイアログの間にそのような情報をある形式等に入力するようコンテンツプロバイダ２００にリクエストすることによってそのようなサービス情報を入手してもよいが、それは本発明の範囲外である。またステップ２：１のＳＬＡリクエストは、サービスに関連付けられたＵＲＬまたは同様のポインタまたは指針を含む。現在、ＵＲＬのフォーマットは典型的にはコンテンツプロバイダからのサービスにアクセスするのに用いられ、それがまた、ここで記述した諸実施形態にも用いられるが、本発明は一般にそれに限定されない。
【００４１】
ＳＬＡリクエストに応答して、ＳＬＡポータル２０４は、ステップ２：２において、所与のサービスまたはサービスタイプ、およびリクエスト側コンテンツプロバイダ２００、或いはそのいずれかに適している可能性がある、１つ以上の所定のＳＬＡをデータベース２０６からフェッチする。できれば、所与のサービスまたはサービスタイプについて事業者がリクエスト側コンテンツプロバイダと確立する準備ができているような実行可能なＳＬＡが選択されて、フェッチされるのが望ましい。留意すべきことは、ＳＬＡポータル２０４は、データベース２０６の中に記憶されているどの所定のＳＬＡがネットワーク事業者にとってもリクエスト側コンテンツプロバイダにとっても実行可能であるかを判定するための特定のロジックを備えることができることだが、それは本発明の範囲外である。
【００４２】
またＳＬＡポータル２０４は、少なくとも１つの識別子ＩＤSを所与のサービスまたはサービスタイプに割り当て、また任意で、以下で図４に関して詳述することになる登録手順の中でまだ事前に割り当てられていないのであれば、識別子ＩＤCPをコンテンツプロバイダにも割り当てる。あるいはまた、単一のサービス識別子が、サービスとコンテンツプロバイダの特定の組み合わせの各々について割り当てられてもよい。コンテンツプロバイダおよびサービスまたはそのいずれかに割り当てられた上記の識別子は、コンテンツプロバイダの「信用証明」と呼ばれることもあり、事業者のネットワークの中でそのコンテンツプロバイダおよびサービスに排他的かつ安全に関連付けられている。
【００４３】
ステップ２：１で受信したＳＬＡリクエストへの応答として、ＳＬＡポータル２０４は、ステップ２：３で、フェッチされた実行可能なＳＬＡをコンテンツプロバイダ２００に提示する。また１つの代替方法によれば、ＳＬＡポータル２０４は、任意のステップ２：４に示すように、ネットワーク事業者２０２のアプリケーション機能２０８の中に、所与のサービスＵＲＬと割り当てられた識別子ＩＤS／（ＩＤCP）との間の結合を記憶する。実際には、結合は、アプリケーション機能２０８にアクセス可能なデータベース等（図示せず）の中に記憶されてもよい。それによって、そのＵＲＬを参照するサービスについてのエンドユーザからのいかなるその後のリクエストも、アプリケーション機能で受信された場合には、例えば段階１：２の後で上記の図１について記述したようにリクエストされたＵＲＬと識別子との間のマッピング動作も含めて、識別子ＩＤS／（ＩＤCP）と関連付けることができる。次いで、対応するＳＬＡを、サービスリクエストを処理する場合にそれに沿って適用することができる。
【００４４】
別の代替方法によれば、ＳＬＡポータル２０４は、割り当てられた識別子ＩＤS／（ＩＤCP）を、提示されたＳＬＡと一緒にステップ２：３で、または任意で、提示されたＳＬＡのうちの１つを選択するコンテンツプロバイダからの応答を受信した後で別個のステップで、コンテンツプロバイダ２００へ送信する。この代替案では、そのＵＲＬを参照するエンドユーザからのその後のリクエストを受信する場合、ステップ２：４でＳＬＡポータルによって結合が記憶されなかったならば、コンテンツプロバイダは、前に受信した識別子ＩＤS／（ＩＤCP）にＵＲＬを関連付けることを、そして、サービスリクエストを処理する場合に対応するＳＬＡがそれに沿って適用されうるように、ネットワークリソースを求めるリクエストの中でこれらの識別子を指定することを求められることがある。
【００４５】
しかし、少なくとも１つの割り当てられたサービス識別子は、いかなる場合にもコンテンツプロバイダへ送信されるべきであり、その識別子をコンテンツプロバイダは、パラメータを設定する場合に、または、選択されたＳＬＡが上記のように異なるオプションの枠組みを含むならば選択されたＳＬＡにおけるオプションの選択を設定する場合に、またはその両方の場合に、参照しなければならない。ＳＬＡの確立は、ネットワーク事業者２０２のコンテンツプロバイダデータベース２１０の中にＳＬＡパラメータおよび他の設定を記憶することを含むが、それについては以下で詳述する。この動作は、「ポリシー提供」と呼ばれ、エンドユーザからのリクエストがあった時点で対象のサービスを提供する場合にはいつでも、コンテンツプロバイダが多かれ少なかれ「保証される」ことになるネットワークリソースの量を設定することを基本的に含む。選択されたＳＬＡについてのポリシー提供は、ＳＬＡがコンテンツプロバイダに提示された後であれば、関連するサービス識別子を参照することによって、いつ行われてもよい。
【００４６】
ステップ２：３で、提示されたＳＬＡを受信した後、コンテンツプロバイダ２００は一般に、ネットワーク事業者２０２との確立のために、選択されたＳＬＡから１つのＳＬＡを選択してもよい。次いでコンテンツプロバイダ２００は、第１のサブステップ２：５ａにおいて、できれば割り当てられたサービス識別子を参照として含めて、選択されたＳＬＡを確立するためのリクエストをＳＬＡポータル２０４へ送信してもよい。次いでＳＬＡポータル２０４は、別の第２のサブステップ２：５ｂにおいてコンテンツプロバイダのデータベース２１０におけるポリシー提供によって、できれば割り当てられたサービス識別子を参照として用いて、選択されたＳＬＡを確立するであろう。従って実際には、ＳＬＡポータル２０４は、サービス識別子を含めて、適切なポリシー提供メッセージを選択されたＳＬＡについてのコンテンツプロバイダのデータベース２１０へ送信してもよい。
【００４７】
実装によっては、コンテンツプロバイダが、選択されたＳＬＡの中の特定のパラメータ値およびその他の属性の選択を、ステップ２：５ａの確立リクエストの中で直接設定するかまたはＳＬＡポータルを使ってダイアログ等（図示せず）の中で設定してもよい。あるいは、コンテンツプロバイダ２００は、最終ステップ２：６で示すように、選択されたＳＬＡを確立するために、コンテンツプロバイダのデータベース２１０の中で直接ポリシー提供を行ってもよい。次いで実際には、コンテンツプロバイダ２００は、選択されたＳＬＡのために、適切なポリシー提供メッセージを、サービス識別子を含めてコンテンツプロバイダのデータベース２１０へ送信してもよい。従って、割り当てられたサービス識別子は、上記のステップ２：５ｂまたはステップ２：６のポリシー提供において参照として用いられることが望ましい。
【００４８】
さらに別の代替方法によれば、コンテンツプロバイダ２００は、デフォルトパラメータを有するＳＬＡを選択してもよく、従って、その中に特定のパラメータ値の設定や他の選択を必要としない。この場合、ＳＬＡの単純な選択以外には、ステップ２：５ａ、２：５ｂまたは２：６における上記のポリシー提供は必要ない。実装によっては、データベース２０６の中のＳＬＡは、デフォルトパラメータ設定およびその他の属性で構成されてもよく、それらが提示された場合、コンテンツプロバイダは、それらを所与の枠組みの限度内で自由に受入れるかまたは変更してよい。
【００４９】
このようにすれば、コンテンツプロバイダとネットワーク事業者の間で特定のサービスまたはサービスタイプについてＳＬＡを確立するプロセスを、完全に自動化することができ、従って、関係する当事者２００、２０２間の物理的会合またはそれ以外の連絡が必要なくなる。代わりに、ＳＬＡポータル２０４が、ステップ２：３で提示するため、ステップ２：１のＳＬＡリクエストかまたはそれ以外のかたちで与えられたコンテンツプロバイダおよびサービスまたはサービスタイプに基づいて、実行可能な所定のＳＬＡであればいかなる数であっても上記のステップ２：２でＳＬＡデータベース２０６から自動的にフェッチするように構成される。ＳＬＡをこのようにして確立するプロセスが、完全に「中立」となり、場合によってはぎこちない「対面での」会合や、それ以外のかたちの手作業での連絡がこのように完全に回避できることはさらなる利点である。
【００５０】
上記で示したように、図２に記述した手順は、例えば、実装を前提として、どのポイントで各尺度、ステップ、メッセージが実行されうるかに関して、複数のさまざまなやり方で修正することができる。
【００５１】
図３は、事業者の通信ネットワーク内でＳＬＡポータルを主に用いて、コンテンツプロバイダとネットワーク事業者の間のサービスレベル契約を確立するための別の実施形態における手順のフローチャートである。図３の手順は、以下に示すように、図２に示す装置に基本的に対応する。
【００５２】
第１のステップ３００では、ＳＬＡポータルが、関連のサービスＵＲＬ等を含む特定のサービスまたはサービスタイプについてのＳＬＡリクエストを、コンテンツプロバイダＣＰから受信する（これは、基本的に図２のステップ２：１に対応する）。実装によっては、コンテンツプロバイダがステップ３００より先にＳＬＡポータルに登録して、コンテンツプロバイダ識別子を入手していてもよい。次のステップ３０２では、ＳＬＡポータルは、（基本的に図２のステップ２：１に対応する）ＳＬＡリクエストの中に与えられたリクエスト側コンテンツプロバイダおよびサービスまたはサービスタイプに基づいて、少なくとも１つの実現可能なまたは実行可能な所定のＳＬＡをＳＬＡデータベースから検索する。
【００５３】
その後、ＳＬＡポータルは次のステップ３０４で、識別子を所与のサービスまたはサービスタイプに割り当て、そして、（基本的に図２のステップ２：３に対応する）その後のステップ３０６で、検索されたＳＬＡを提示されたＳＬＡとしてリクエスト側コンテンツプロバイダへ送信する。次に、ＳＬＡポータルは、アプリケーション機能等においてサービスＵＲＬと割り当てられたサービス識別子の間の結合を記憶してもよいが、（基本的に図２のステップ２：４に対応するけれども）それはここではステップとして示していない。また上述のように、結合は、リクエスト側コンテンツプロバイダに割り当てられた識別子を含んでもよい。またできれば、ＳＬＡポータルは、コンテンツプロバイダがＳＬＡを選択する場合およびサービス配信のためネットワークリソースを求めてリクエストする場合、またはそのいずれかの場合に用いられるように、割り当てられたサービス識別子を、ステップ３０６で提示されたＳＬＡと共にかまたは別個に（図示せず）、コンテンツプロバイダへ送信することが望ましい。
【００５４】
上記で図２について記述する際にさらに述べたように、着信エンドユーザのリクエストのＵＲＬを受信したサービス識別子と関連付ける責任をコンテンツプロバイダに負わせるのならば、エンドユーザへのサービス配信のためのネットワークリソースを求めるリクエストの中にその識別子を指定することを目的として、ＳＬＡポータルがアプリケーション機能の中に結合を記憶する必要はない。
【００５５】
次のステップ３０８は一般に、ステップ３０４で提示されたＳＬＡの中からコンテンツプロバイダによって選択されたＳＬＡの確立を表し、そのステップは、（基本的に図２のステップ２：５または２：５ｂにそれぞれ対応する）コンテンツプロバイダによってかまたは割り当てられたサービス識別子を参照することによりＳＬＡポータルによって行われうる。このステップでは、選択されたＳＬＡについてのポリシーが、例えば図２に示すＣＰデータベース２１０のような、コンテンツプロバイダのデータベース等の中で提供される。
【００５６】
最後に、ＳＬＡの確立の後、ステップ３１０で、割り当てられたサービス識別子を使って、対応するサービスがコンテンツプロバイダからリクエスト側エンドユーザに配信されるときにはいつでも、確立されたＳＬＡを適用することができる。従って、上述のように、リクエストされたＵＲＬを、アプリケーション機能によってかまたはコンテンツプロバイダによって、割り当てられたサービス識別子に関連付けることができる。
【００５７】
ここで、コンテンツプロバイダのためにサービスレベル契約を確立するための別の例示する実施形態による、より詳細なシグナリング手順について、携帯事業者のネットワークの中に本発明を実装するのに用いられうる、図４を参照しながら記述しよう。図は、コンテンツプロバイダ４００とネットワーク内の関与する諸ネットワークノードとを示し、それにはＳＬＡデータベース４０２ａに接続するＳＬＡポータル４０２と、ポリシーユニット４０４ａに接続するコンテンツプロバイダデータベース４０４と、アプリケーション機能ノード４０６とが含まれる。
【００５８】
この実施形態では、コンテンツプロバイダ４００は、特定のサービスまたはサービスタイプについていずれかのＳＬＡをリクエストする前に、最初にＳＬＡポータル４０２に登録してもよい。従って、第１のステップ４：１では、ＳＬＡポータル４０２は、登録リクエストをコンテンツプロバイダ４００から受信する。次のステップ４：２は一般に、ＳＬＡポータル４０２がコンテンツプロバイダ４００のためにリクエストされた登録を確立することを示し、それには、その信頼性および信用度またはそのいずれかを制御すること、およびローカルなデータベース等（図示せず）の中に記憶されているコンテンツプロバイダ４００のための一般的な識別子ＩＤCPを割り当てることが含まれてもよい。次いで、ステップ４：３で、割り当てられた識別子ＩＤCPを含めて、登録応答がコンテンツプロバイダ４００に返信される。
【００５９】
その後ある時点で、コンテンツプロバイダは、前に割り当てられた一般的なコンテンツプロバイダ識別子ＩＤCPおよび特定のサービスまたはサービスタイプに関連付けられたＵＲＬを含めて、特定のサービスまたはサービスタイプを求めるＳＬＡリクエストをステップ４：４でＳＬＡポータル４０２へ送信する。また、できれば、ＳＬＡリクエストは、ＳＬＡポータルによって理解されうるようなサービスの記述または一般的なサービスの識別を含むことが望ましい。そうでない場合、この情報は、上述のように別個のサービスダイアログのかたちで提供されてもよい。
【００６０】
次のステップ４：５では、ＳＬＡポータル４０２が、コンテンツプロバイダの識別子ＩＤCPとＳＬＡリクエストに関連してなんらかのかたちで示されているサービスまたはサービスタイプとに基づいて、少なくとも１つの実行可能な所定のＳＬＡをＳＬＡデータベース４０２ａから検索する。また、このステップでは、サービス識別子ＩＤSもＳＬＡリクエストの中に示されたサービスまたはサービスタイプに割り当てられる。その後、ＳＬＡポータル４０２は、少なくとも１つの検索されたＳＬＡを、少なくとも１つの提示されたＳＬＡとして、割り当てられたサービス識別子ＩＤSと共にコンテンツプロバイダ４００へ、さらなるステップ４：６で送信する。あるいは、上記のように、サービス識別子ＩＤSが、後のステップで、例えばこの例には示されていないが、そこから選択されたＳＬＡを示す応答を受信した後で、コンテンツプロバイダへ送信されてもよい。
【００６１】
また次のステップ４：７で、ＳＬＡポータル４０２は、ＳＬＡリクエストの中のＵＲＬと割り当てられたサービス識別子ＩＤSおよび前に割り当てられたコンテンツプロバイダ識別子ＩＤCPとの間の結合をアプリケーション機能４０６の中に記憶する。図２について上述したように、結合は、アプリケーション機能４０６にアクセス可能なデータベース等の中に記憶されてもよく、そこではそのデータベースは、複数のアプリケーション機能によって共有されてもよい。従って、移動ユーザからそのＵＲＬに向けられてアプリケーション機能４０６に達するその後のいかなるコンテンツリクエストも、サービス識別子ＩＤSとコンテンツプロバイダ識別子ＩＤCPの組み合わせに関連しているとして認識され、それに沿って処理されるであろう。
【００６２】
最後に、コンテンツプロバイダ４００は、提示されたＳＬＡの中から１つのＳＬＡを選択した後、ＣＰデータベース４０４の中に、サービス識別子ＩＤSおよび、使用されるならばコンテンツプロバイダ識別子ＩＤCPとも同様に組み合わされた、選択されたＳＬＡについてのポリシーを確立する。図２のステップ２：５ａおよび２：５ｂのそれぞれの場合のように、コンテンツプロバイダは、割り当てられたサービス識別子ＩＤSを参照として含めて、ＳＬＡ確立リクエストをＳＬＡポータル４０２へ送信し、ステップ４：８の２つの矢印で示すように、ＳＬＡポータルにＳＬＡポリシーをＣＰデータベース４０４の中で実行するように命令してもよい。あるいは、図２のステップ２：６の場合のように、コンテンツプロバイダ自身がＣＰデータベース４０４の中でＳＬＡポリシーの提供を、同様にサービス識別子ＩＤSを参照しながら、別のステップ４：８ａで示したように実行してもよい。
【００６３】
ＳＬＡが確立されてＣＰデータベース４０４の中にポリシーとして記憶された後、コンテンツプロバイダ４００は、コンテンツがコンテンツをリクエストしている移動ユーザに配信されることになる場合にはいつでも、ポリシーユニット４０４ａからネットワークリソースをリクエストすることができる。またコンテンツプロバイダ４００は、ネットワークリソースリクエストの中で識別子ＩＤSとＩＤCPとを参照すべきである。
【００６４】
次いでポリシーユニット４０４ａは、コンテンツプロバイダ識別子ＩＤCPに基づいてコンテンツプロバイダ４００を認証できるであろう。またポリシーユニット４０４ａは、帯域幅、ビットレート、転送遅延、地理的カバー範囲、またはＱｏＳに影響を与えるいずれかの他の通信パラメータに関してコンテンツプロバイダ４００がどのネットワークリソースの権利を与えられているかを判断するために、ＣＰデータベース４０４の中に記憶されたＳＬＡポリシーをチェックするであろう。必要に応じて、ＣＰデータベース４０４の中にすでに記憶されているのでなければ、確立されたＳＬＡの詳細がＳＬＡデータベース４０２ａから検索されてもよい。次いで、関連のネットワークリソースが、現行のＳＬＡに従ってコンテンツ配信に割り当てられる。
【００６５】
ステップ４：４乃至４：８に従って特定のサービスまたはサービスタイプについてＳＬＡを確立するプロセスは、もちろん、コンテンツプロバイダ４００が期待されるＱｏＳを満足しながら安全な配信を保証することを望むいかなるサービスについても反復されることもできる。従って、コンテンツプロバイダは、最終的には、異なるサービスまたはサービスタイプについて構成された複数の異なるＳＬＡを有することになってもよい。
【００６６】
上記のように、単一のサービス識別子が、サービスとコンテンツプロバイダとの特定の組み合わせの各々に対して割り当てられてもよく、その場合、別個のコンテンツプロバイダ識別子を取得する目的でＳＬＡリクエストを行うより前に、コンテンツプロバイダがＳＬＡポータル４０２に登録する必要はない。従って、上記のステップ４：１乃至４：３は、ＳＬＡリクエストが行われた時点でコンテンツプロバイダの何らかの承認および認証が行われうるならば、任意であって実装に依存すると考えることができる。
【００６７】
図５は、例えば図２に示すＳＬＡポータル２０４、または図４に示すＳＬＡポータル４０２のような、事業者の通信ネットワーク内のＳＬＡポータル５００を詳細に示す。ＳＬＡポータル５００は、コンテンツプロバイダからエンドユーザに配信される場合に特定のサービスまたはサービスタイプに必要なネットワークリソースを確保するため、第三者コンテンツプロバイダ（図示せず）とＳＬＡを確立するように構成される。ＳＬＡポータル５００は、下記の機能性ユニット５０２乃至５１２を備えるが、それらは純粋に論理的な意味で理解されるべきである。従って、ユニット５０２乃至５１２は、当業者によっていずれかの実際的なやり方で適切なハードウェアおよびソフトウェアを用いて実装することができる。
【００６８】
中央プロセッサ５０２が、ＳＬＡポータル５００の中の他のユニットのさまざまな機能を調整することが示されているが、プロセッサ５０２は個別ユニット５０４乃至５１２の中に別のやり方で分散されてもよい。
【００６９】
受信ユニット５０４が、特定のサービスまたはサービスタイプを求めるＳＬＡリクエストをコンテンツプロバイダ（図示せず）から受信するように構成される。
【００７０】
検索ユニット５０６が、実行可能な所定のＳＬＡを、例えば図２に示すデータベース２０６のような、複数の所定のＳＬＡを保持しているＳＬＡデータベースＤＢ１から検索するように構成される。
【００７１】
識別子割り当てユニット５０８が、前記ＳＬＡリクエストＲのサービスまたはサービスタイプにサービス識別子を割り当てるように構成される。
【００７２】
送信ユニット５１０が、検索された実行可能なＳＬＡを提示するかたちでコンテンツプロバイダへ送信し、また、割り当てられたサービス識別子を提示されたＳＬＡと共にまたは別個に送信するように構成される。
【００７３】
最後に、ＳＬＡ確立ユニット５１２が、例えば図２に示すデータベース２１０のような、事業者のネットワークの中のコンテンツプロバイダデータベースＤＢ２の中のポリシー提供によって、割り当てられたサービス識別子を参照してそこから選択されたＳＬＡの確立を求めるリクエストに応じて、コンテンツプロバイダの代わりにＳＬＡを確立するように構成される。ＳＬＡポータル５００はさらに、携帯事業者のアプリケーション機能の中でかまたはアプリケーション機能にアクセス可能なデータベースの中で、サービスのＵＲＬと割り当てられたサービス識別子との間の結合を記憶するための機能性（図示せず）を備えてもよい。
【００７４】
図６は、図２に示すコンテンツプロバイダ２００または図４に示すコンテンツプロバイダ４００として基本的に動作している、コンテンツプロバイダサーバ６００をより詳細に示す。コンテンツプロバイダサーバ６００は、コンテンツプロバイダからエンドユーザへ配信される場合に特定のサービスまたはサービスタイプに必要なネットワークリソースを確保するため、通信ネットワーク事業者とのＳＬＡを確立するように構成される。コンテンツプロバイダサーバ６００は、下記の機能性ユニット６０２乃至６０８を備えるが、ここでもやはり、それらは純粋に論理的な意味で理解されるべきである。従って、ユニット６０２乃至６０８は、当業者によって、適切なハードウェアおよびソフトウェアを用いて、いかなる実際的なやり方で実装されてもよい。
【００７５】
第１の送信ユニット６０２が、特定のサービスまたはサービスタイプを求めるＳＬＡリクエストＲを事業者の通信ネットワーク内のＳＬＡポータルへ送信するように構成される。
【００７６】
受信ユニット６０４が、複数の所定のＳＬＡを保持しているＳＬＡデータベースから検索された、提示された実行可能な所定のＳＬＡを、前記ＳＬＡリクエストＲに応じてＳＬＡポータルから受信するように構成される。受信ユニット６０４はさらにＳＬＡポータルから、前記サービスまたはサービスタイプに割り当てられたサービス識別子ＩＤを受信するように構成される。
【００７７】
マッピングユニット６０６が、前記サービスまたはサービスタイプについてのＵＲＬ等を、エンドユーザからのサービスリクエストＳＲの中で受信した場合に、前記サービス識別子ＩＤにマッピングするように構成される。コンテンツプロバイダ６００は典型的には、いかなるサービスリクエストであっても、例えば図１のステップ１：４の場合のように、アプリケーション機能ＡＦを介して受信する。
【００７８】
最後に、第２の送信ユニット６０８が、前記サービスをリクエスト側エンドユーザに配信するためのネットワークリソースを求めるリクエストＲＲをアプリケーション機能ＡＦへ送信するように構成され、その場合、前記リソースリクエストは、サービス識別子ＩＤを参照する。
【００７９】
本発明を用いる場合、以下に例示するように、重要な利点が得られてもよい。
【００８０】
１）ＳＬＡを確立するプロセスは、実行可能な所定のＳＬＡをコンテンツプロバイダおよび関連するサービスについて選択されるように提示することによって、中立となる。
【００８１】
２）ＳＬＡの交渉についての個人的な会合やそれ以外の手作業の連絡が基本的に不要であるため、かなりな量の時間と努力とが節約できる。
【００８２】
３）携帯事業者が、数多くの第三者コンテンツプロバイダと最小限の管理業務でＳＬＡを確立することができるであろうし、もちろん、このプロセスは、コンテンツプロバイダについても円滑化される。
【００８３】
４）例えばストリーミング、メッセージング、位置決め、課金等のサービスのような多様なサービスまたはサービスタイプについてどの程度のどのようなタイプのネットワークリソース並びに帯域幅およびカバー範囲が必要なのかに関して、コンテンツプロバイダが異なれば、要件も非常に異なることがある。従って、いかなるものであろうと提示された所定のＳＬＡを自由に組み合わせることによって、いかなる数であろうと多様なサービスプロフィールを満足させうることは、大きな利点である。
【００８４】
本発明について特定の例示する実施形態を参照しながら記述してきたが、この記述は一般に、本発明の概念を例示することが意図されているにすぎず、本発明の範囲を限定していると考えられてはならない。例えば、上記の実施形態について記述する場合には全体にわたってＳＩＰシグナリングプロトコルおよびＩＭＳ構想が使用されてきたが、いかなる他の標準およびサービスネットワークが基本的に使用されてもよい。本発明は、添付の請求項によって定義される。
【図１】
2010517160.tif 000003
【図２】
2010517160.tif 000004
【図３】
2010517160.tif 000005
【図４】
2010517160.tif 000006
【図５】
2010517160.tif 000007
【図６】
2010517160.tif 000008
【国際調査報告】
2010517160.tif 000009
2010517160.tif 000010
2010517160.tif 000011