(57)【要約】オープン・サービス・アーキテクチャにおける第１のサービス・イネーブラと第２のサービス・イネーブラの間を移行する方法は、オープン・サービス・アーキテクチャ・フレームワーク内で第２のサービス・イネーブラを登録することを含む。登録した第２のサービス・イネーブラの特性は、少なくとも第１のサービス・イネーブラの特性と比較され、第２のサービス・イネーブラの第１のサービス・イネーブラに対する下位互換性の有無を決定する。第２のサービス・イネーブラの第１のサービス・イネーブラに対する下位互換性の有無に関する情報は、第１のサービス・イネーブラを使用中のアプリケーションに送られる。同じメッセージでアプリケーションに送られうるその他の情報は、たとえば、第２のサービス・イネーブラが第１のサービス・イネーブラを旧式化したこと、移行戦略およびアプリケーションが既に使用を開始することができる第２のサービス・イネーブラのインタフェースへの参照である。
2005502145.tif 000002
【特許請求の範囲】
【請求項１】
登録・発見サーバに第２のサービスを登録するステップと、
前記第２のサービスの特性と少なくとも１つの第１のサービスの特性を比較して、前記第２のサービスの前記少なくとも１つの第１のサービスに対する下位互換性の有無を判定するステップと、
前記少なくとも１つの第１のサービスを使用する少なくとも１つのアプリケーションに対して、前記第２のサービスの前記少なくとも１つの第１のサービスに対する下位互換性の有無に関する情報を送るステップと、
を有する方法。
【請求項２】
請求項１に記載の方法において、前記登録・発見サーバは、オープン・サービス・アーキテクチャ・フレームワークを含む前記方法。
【請求項３】
先行する請求項のいずれかに記載の方法であって、前記第２のサービスによってサポートされる少なくとも１つの特性を前記オープン・サービス・アーキテクチャ・フレームワークに与えるステップを更に有する前記方法。
【請求項４】
先行する請求項のいずれかに記載の方法において、前記送るステップは、前記第２のサービスの前記少なくとも１つの第１のサービスに対する下位互換性の有無に関する情報を、前記少なくとも１つの第１のサービスを使用する複数のアプリケーションに対して送るステップを更に有する前記方法。
【請求項５】
先行する請求項のいずれかに記載の方法において、前記第２のサービスと前記少なくとも１つの第１のサービスは、サービス・ケイパビリティ機能を有する前記方法。
【請求項６】
先行する請求項のいずれかに記載の方法において、前記送るステップは、前記サービスを与える機能エンティティの少なくとも１つのインタフェースに対してポインタを送るステップを更に含む前記方法。
【請求項７】
請求項６に記載の方法において、前記機能エンティティは、サービス・ケイパビリティ・サーバを有する前記方法。
【請求項８】
先行する請求項のいずれかに記載の方法において、前記情報は、前記第２のサービスで前記少なくとも１つの第１のサービスを置換するか否かを指定する前記方法。
【請求項９】
先行する請求項のいずれかに記載の方法において、前記情報は、前記第２のサービスが前記少なくとも１つの第１のサービスを旧式化するか否かを指定する前記方法。
【請求項１０】
先行する請求項のいずれかに記載の方法において、前記情報は、前記第２のサービスから前記少なくとも１つの第１のサービスへの移行戦略を指定する前記方法。
【請求項１１】
先行する請求項のいずれかに記載の方法において、前記情報は、前記第２のサービスによって与えられる前記方法。
【請求項１２】
請求項１から請求項１０のいずれかに記載の方法において、前記情報は、前記登録・発見サーバによって与えられる前記方法。
【請求項１３】
先行する請求項のいずれかに記載の方法であって、前記少なくとも１つの第１のサービスを前記第２のサービスで置換えるステップを更に有する前記方法。
【請求項１４】
少なくともサービス・ケイパビリティ機能と第２のサービス・ケイパビリティ機能を与える少なくとも１つのサービス・ケイパビリティ・サーバと、
前記第２のサービス・ケイパビリティ機能を前記オープン・サービス・アーキテクチャ・フレームワークに登録し、前記第２のサービス・ケイパビリティ機能の特性を前記第１のサービス・ケイパビリティ機能の特性と比較して前記第２のサービス・ケイパビリティ機能の前記第１のサービス・ケイパビリティ機能に対する下位互換性の有無を決定し、さらに前記第１のサービス・ケイパビリティ機能を使用する少なくとも１つのアプリケーションに対し、前記第２のサービス・ケイパビリティ機能の前記第１のサービス・ケイパビリティ機能に対する下位互換性の有無に関する情報を送るように構成されるオープン・サービス・アーキテクチャ・フレームワークと、
を含むオープン・サービス・アーキテクチャ。
【請求項１５】
請求項14に記載のオープン・サービス・アーキテクチャにおいて、前記オープン・サービス・アーキテクチャ・フレームワークは、前記第２のサービス・ケイパビリティ機能によってサポートされる少なくとも１つの特性を決定するように更に構成される前記オープン・サービス・アーキテクチャ。
【請求項１６】
請求項14と請求項１５のいずれかに記載のオープン・サービス・アーキテクチャにおいて、前記オープン・サービス・アーキテクチャ・フレームワークは、前記第２のサービス・ケイパビリティ機能の前記第１のサービス・ケイパビリティ機能に対する下位互換性の有無に関する情報を、前記第１のサービス・ケイパビリティ機能を使用する複数のアプリケーションに対して送るように更に構成される前記オープン・サービス・アーキテクチャ。
【請求項１７】
請求項14から請求項16のいずれかに記載のオープン・サービス・アーキテクチャにおいて、前記オープン・サービス・アーキテクチャ・フレームワークは、前記第１のサービス・ケイパビリティ機能を与える前記少なくとも１つのサービス・ケイパビリティ・サーバの少なくとも１つのインタフェースに対してポインタを送るように更に構成される前記オープン・サービス・アーキテクチャ。
【請求項１８】
請求項14から請求項17のいずれかに記載のオープン・サービス・アーキテクチャにおいて、前記情報は、前記第２のサービス・ケイパビリティ機能で前記第１のサービス・ケイパビリティ機能を置換するか否かを指定する前記オープン・サービス・アーキテクチャ。
【請求項１９】
請求項14から請求項18のいずれかに記載のオープン・サービス・アーキテクチャにおいて、前記情報は、前記第２のサービス・ケイパビリティ機能が前記第１のサービス・ケイパビリティ機能を旧式化するか否かを指定する前記オープン・サービス・アーキテクチャ。
【請求項２０】
請求項14から請求項19のいずれかに記載のオープン・サービス・アーキテクチャにおいて、前記情報は、前記第２のサービス・ケイパビリティ機能から前記第１のサービス・ケイパビリティ機能への移行戦略を指定する前記オープン・サービス・アーキテクチャ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、オープン・サービス・アーキテクチャに関し、より詳細には、オープン・サービス・アーキテクチャにおいて１つのサービス・イネーブラ（service enabler）から他のサービス・イネーブラに移行する場合のアプリケーションを支援する方法に関する。
【背景技術】
【０００２】
今日のネットワークにおいては、アプリケーションとサービスはネットワーク・オペレータの領域の一部であり、インテリジェント・ネットワーク・テクノロジを使用して構築される。この方法はシンプルな大量市場のアプリケーションとしては優れているが、移動性とインターネット・プロトコルが出現するに及んで、各種機能と企業の重要なデータを結合する画期的なアプリケーションを迅速に配置することが課題となっている。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
Parlayや3GPPのような多くの業界フォーラムや標準化機構がこの課題に対処し、アプリケーションとコア・ネットワークの間のインタフェースとして機能するAPI（application program interface）を指定している。オープン・サービス・アーキテクチャという用語は、Parlay、3GPPおよびETSIによって開発されたAPIのセットのことである。オープン・サービス・アーキテクチャ（OSA）の内部では、新しいサービス・ケイパビリティ機能（service capability feature：SCF）が利用可能になった場合にOSA内のアプリケーションが加入できることを連絡するようにする基本メカニズムが存在している。しかし、このメカニズムは、現在アプリケーションが使用中の既存のSCFとその新しいSCFがどの程度下位互換性があるか（backward compatible）についての表示を提供していない。したがって、オープン・サービス・アプリケーションでは、新しいSCFと既存のSCFとの互換性をアプリケーションに知らせるメカニズムの必要性が存在している。
【課題を解決するための手段】
【０００４】
本発明は、オープン・サービス・アーキテクチャにおいて第１のサービスと第２のサービスの間を移行する（migrating）システムと方法を使用して前述の課題およびその他の問題点を克服する。第２のサービスは、オープン・サービス・アーキテクチャ・フレームワークに登録し、それに応じて第２のサービスの特性と第１のサービスの特性を比較し、第２のサービスの第１のサービスに対する下位互換性の有無を決定する。第２のサービスの第１のサービスに対する下位互換性の有無に関する情報は、この比較の後でその第１のサービスを使用している少なくとも１つのアプリケーションに送られる。
【０００５】
（実施例の詳細な説明）
本発明の方法と装置のより完全な理解は、添付の図面とともに以下の詳細な説明を参照することによって得られるであろう。
【０００６】
次に図１を参照すると、第３世代ネットワークのネットワーク・アーキテクチャは、水平階層化原理（horizontal layering principle）に基づいており、アプリケーション・ネットワークまたはサービス・ネットワーク10と呼称される上部層内でアプリケーション40とアプリケーション・サーバ45が論理的に設定される。サービス・ネットワークという用語は、コア・ネットワークと区別するために使用される。サービス・ネットワーク10はオープン分散テクノロジ（open distributed technology）（JAVA（登録商標）、CORBA）に基づいているので、アプリケーションは、オープンかつ標準化されたアプリケーション・プログラム・インタフェース（API）20によってコア・ネットワークの機能にアクセスすることができ、アプリケーション・プログラム・インタフェース20を介してアプリケーションは１つまたは複数のサービス・ケイパビリティ・サーバ（service capability server：SCS）50と通信することができる。SCS50は、移動通信ネットワーク5、IPネットワーク6および固定ネットワーク7またはそれらのいずれかに接続することができる。
【０００７】
図２に示す階層化アーキテクチャにおけるオープン・サービス・アーキテクチャ（OSA）は、サービス・ネットワーク10とコア・ネットワーク15の間のアプリケーション・プログラム・インタフェースを含む。本発明は、Parlay、3GPPおよびETSIで決められたオープン・サービス・アーキテクチャについて説明されているが、本発明は、特定の詳細な実施例がOSAとは若干異なることがありうるウエブ・サービスを使用した方法にも適用可能である。アプリケーション・サーバ45に配置されたアプリケーション40は、サービス・ケイパビリティ・サーバ（SCS）50で提供されるサービス・ケイパビリティ機能を利用する。サービス・ケイパビリティ・サーバ50は、サービス・ケイパビリティ機能（SCF）35を実行し、コア・ネットワーク15と対話する論理エンティティ（logical entities）である。アプリケーション40とアプリケーション・サーバ45は、前に説明したようにサービス・ネットワーク層10の内部に位置する。したがって、オープン・サービス・アーキテクチャ30は、サービス・ネットワーク10とコア・ネットワーク15の間のAPIとして機能することが判る。
【０００８】
OSAフレームワーク55は、登録・発見（registration and discovery）サーバであり、オープン・サービス・アーキテクチャの開放性（openness）を可能にし、後で説明するように、開放性や新機能の発見と統合という点で、IN（インテリジェント・ネットワーク）を凌駕することが可能になる。OSAフレームワーク55は、オープン・サービス・アーキテクチャ30の中に新しいサービス・ケイパビリティ機能が追加されたことをアプリケーションに連絡する。OSAフレームワーク55は、SCS50へのアクセスを制御し、SCS50は分散型技術（distributed technology）と組み合わせてビジネスに使用する場合のアプリケーションの位置の融通性を支援する。さらに、OSAフレームワーク55は、マルチ・ベンダーシップ（multi-vendorship）を可能にするとともに、APIのセットを拡張することさえも可能にする。
【０００９】
図３に示すように、実際にはOSAフレームワーク55はサービス・ケイパビリティ機能のファミリーであり、そのコア部分は、ドメインの認証を可能にするトラスト（信用）とセキュリティ管理（Trust and Security Management）60、オペレータによって提供される新しいSCFの発見を可能にするサービス発見（Service Discovery）65、フレームワークに新しいSCFを登録するサービス登録（Service Registration）70および新しいSCFインスタンス（new SCF instances）の生成を可能にするサービス・ファクトリ（Service Factory）75からなる。それだけでなく、APIは、負荷平衡化、障害管理およびハートビート（heart beat）のような保全性（Integrity）管理80と特定のイベントを連絡するイベント連絡（Event Notification）85を備えている。
【００１０】
次に図４を参照すると、新しいサービス・ケイパビリティ・サーバ（Service Capability Server:SCS）50によって提供されるSCF35を使用してアプリケーションがスタートできる方法が示されている。第１の段階でSCS50は、OSAフレームワーク55と接触しステップ90、95で認証・登録インタフェースを要求する。次にSCS50は、登録インタフェースを使用して自身の機能（capabilities）を公開し、ステップ100で自身のサービス・ファクトリに参照（reference）を追加する。ファクトリのパターンは、一般的なデザインパターンであり、OSAフレームワーク55がSCF35のインタフェースをつくることをSCS50に要求することを可能にする。この時点で、OSAフレームワーク55とSCS50は互に知り合うこととなる。
【００１１】
アプリケーション40は、ステップ105でOSAフレームワーク55と接触し認証される。アプリケーション40は、ステップ110で発見インタフェースを要求する。OSAフレームワーク55がステップ115で発見インタフェースに参照またはポインタを戻すと、その後、アプリケーション40はこのインタフェースを使用してSCF35のタイプとアプリケーション40によって必要とされる特殊な機能を要求する。このとき、OSAフレームワーク55は、アプリケーション40がどんな条件でSCF35を使用することが可能になるか否かを追跡する。これは、ネットワーク・オペレータとサービスプロバイダの間のサービスレベル協定（SLA）の中で取得される。アプリケーションがSCF35を使用することができれば、OSAフレームワーク55は、そのアプリケーションの必要性を満たすことができるすべてのSCF35のIDを戻す。
【００１２】
次にアプリケーション40はステップ120でSCF35の１つを選択して、いわゆるサービス協定（Service Agreement）にサインする。OSAフレームワーク55はステップ125で、SCS50のサービス・ファクトリと接触し、アプリケーションがSCF35を使用することが許される条件を送る。ステップ130でSCS50は、このアプリケーションで使用されるSCF35のインスタンス（SCF35 instances）をつくりだすと共に条件をチェックすることもでき、フレームワークはステップ135でアプリケーションに参照またはポインタを戻す。この時点以後、アプリケーションはSCF35を使用することが許可される。説明したこの登録と発見処理は、フレームワークをして利用可能な各種SCF35と、連絡インタフェースを介して新しいSCS50の潜在的な可用性とをアプリケーションに知らせることを可能にするが、新しいSCF35と前から存在していたSCF35との下位互換性をアプリケーションに連絡するメカニズムは存在していない。アプリケーションはフレームワーク55上のイベント連絡APIを使用してイベントに加入することができる。イベントの一例は、新しいSCFが利用可能になるときである。
【００１３】
次に図５を参照すると、SCFの下位互換性を判定する方法が示されている。新しいSCFが利用可能になると、図４について前に説明したように、SCFはステップ150で第１にOSAフレームワーク55に登録しなければならない。この処理中に、SCFは、ステップ155でSCFのこのインプリメント（implementation）によって支援される特性（properties）をOSAフレームワーク55に提供する。OSAフレームワーク55には、特定のネットワーク・オペレータの領域の中で利用可能な既存のSCFをそれぞれ実行することに関する情報、既存のSCFを使用するアプリケーションに関する情報およびサービスレベル協定によるSCFの使用に適用される制限事項がある。この情報を使用してOSAフレームワークはステップ160で前から存在しているバージョンに対する新しいSCFのインプリメント（new SCF implementation）の特性のチェックを実行することができる。このチェックでは、新SCFインプリメントがネットワークで使用されている他のバージョンのSCFとどの程度の下位互換性があるかに関する表示が取得される。この情報は、ステップ165で新しいSCSのインタフェースに対するオプションとしての参照とともに旧バージョンのSCFを使用しているアプリケーションに送られる。これらのインタフェースに対して参照を与えるためには、現在のフレームワークの連絡メカニズム（framework notification mechanism）の拡張が使用されるであろう。フレームワークの連絡メカニズムは専用サービスの特性（dedicated service properties）によって案内される。この専用サービスの特性とは、指定された旧SCFインプリメントを前記SCFインプリメントで置換えるまたは該旧SCFのインプリメントを旧式化する（outdates）ことを指定するか、または移行戦略（migration strategy）を指定するものである。下位互換性のレベル、旧SCFを前記SCFで置換するかまたは旧SCFを旧式化すること、移行戦略などに関する情報は、新しいSCSによって提供されフレームワークを介してアプリケーションに送られるか、または新しいSCSが登録されるとき、その特性を解析した後フレームワークによって提供されるかまたは両者の協調により提供される。
【００１４】
上に説明した拡張を実施することにより、SCFの旧バージョンと新バージョンの間のアプリケーションのインプリメントシームレスな移行または適用（application）が可能になりうる。これにより、オペレータはほとんど自動的にSCFの旧式化（outdate）または更新（update）を実行することができる。またオペレータは、アプリケーションをバックアップSCFに送ることにより、保守活動のために１つのSCFをサービスからはずすことが可能になる。
【００１５】
上記は、本発明を実施するための好適実施例に関する説明であり、本発明の範囲は必ずしもこの説明で限定されるものではない。本発明の範囲は、特許請求の範囲によって定義されている。
【図面の簡単な説明】
【００１６】
【図１】第３世代の論理的ネットワーク・アーキテクチャを示す図である。
【図２】オープン・サービス・アーキテクチャの概要を示す図である。
【図３】OSAフレームワークの各種機能を示す図である。
【図４】オープン・サービス・アーキテクチャ内のアプリケーションによるサービス登録を示す図である。
【図５】アプリケーションが新しいSCFに移行することを支援する本発明の方法を示す流れ図である。
【図１】
2005502145.tif 000003
【図２】
2005502145.tif 000004
【図３】
2005502145.tif 000005
【図４】
2005502145.tif 000006
【図５】
2005502145.tif 000007
【国際公開パンフレット】
2005502145.tif 000008
2005502145.tif 000009
2005502145.tif 000010
2005502145.tif 000011
2005502145.tif 000012
2005502145.tif 000013
2005502145.tif 000014
2005502145.tif 000015
2005502145.tif 000016
2005502145.tif 000017
2005502145.tif 000018
2005502145.tif 000019
2005502145.tif 000020
2005502145.tif 000021
【国際公開パンフレット（コレクトバージョン）】
2005502145.tif 000022
2005502145.tif 000023
【国際調査報告】
2005502145.tif 000024
2005502145.tif 000025