【誤訳訂正書】
【提出日】平成20年7月30日(2008.7.30)
【誤訳訂正１】
【訂正対象書類名】特許請求の範囲
【訂正対象項目名】全文
【訂正方法】変更
【訂正の内容】
【特許請求の範囲】
【請求項１】
登録・発見サーバに第２のサービスを登録するステップと、
前記第２のサービスの特性と少なくとも１つの第１のサービスの特性を比較して、前記第２のサービスの前記少なくとも１つの第１のサービスに対する後方互換性の有無を判定するステップと、
前記少なくとも１つの第１のサービスを使用する少なくとも１つのアプリケーションに対して、前記第２のサービスの前記少なくとも１つの第１のサービスに対する後方互換性の有無に関する情報を送るステップと、
を有する方法。
【請求項２】
請求項１に記載の方法において、前記登録・発見サーバは、オープン・サービス・アーキテクチャ・フレームワークを含む前記方法。
【請求項３】
先行する請求項のいずれかに記載の方法であって、前記第２のサービスによってサポートされる少なくとも１つの特性を前記オープン・サービス・アーキテクチャ・フレームワークに与えるステップを更に有する前記方法。
【請求項４】
先行する請求項のいずれかに記載の方法において、前記送るステップは、前記第２のサービスの前記少なくとも１つの第１のサービスに対する後方互換性の有無に関する情報を、前記少なくとも１つの第１のサービスを使用する複数のアプリケーションに対して送るステップを更に有する前記方法。
【請求項５】
先行する請求項のいずれかに記載の方法において、前記第２のサービスと前記少なくとも１つの第１のサービスは、サービス・ケイパビリティ機能を有する前記方法。
【請求項６】
先行する請求項のいずれかに記載の方法において、前記送るステップは、前記サービスを与える機能エンティティの少なくとも１つのインタフェースに対してポインタを送るステップを更に含む前記方法。
【請求項７】
請求項６に記載の方法において、前記機能エンティティは、サービス・ケイパビリティ・サーバを有する前記方法。
【請求項８】
先行する請求項のいずれかに記載の方法において、前記情報は、前記第２のサービスで前記少なくとも１つの第１のサービスを置換するか否かを指定する前記方法。
【請求項９】
先行する請求項のいずれかに記載の方法において、前記情報は、前記第２のサービスが前記少なくとも１つの第１のサービスを旧式化するか否かを指定する前記方法。
【請求項１０】
先行する請求項のいずれかに記載の方法において、前記情報は、前記第２のサービスから前記少なくとも１つの第１のサービスへの移行戦略を指定する前記方法。
【請求項１１】
先行する請求項のいずれかに記載の方法において、前記情報は、前記第２のサービスによって与えられる前記方法。
【請求項１２】
請求項１から請求項１０のいずれかに記載の方法において、前記情報は、前記登録・発見サーバによって与えられる前記方法。
【請求項１３】
先行する請求項のいずれかに記載の方法であって、前記少なくとも１つの第１のサービスを前記第２のサービスで置換えるステップを更に有する前記方法。
【請求項１４】
少なくともサービス・ケイパビリティ機能と第２のサービス・ケイパビリティ機能を与える少なくとも１つのサービス・ケイパビリティ・サーバと、
前記第２のサービス・ケイパビリティ機能を前記オープン・サービス・アーキテクチャ・フレームワークに登録し、前記第２のサービス・ケイパビリティ機能の特性を前記第１のサービス・ケイパビリティ機能の特性と比較して前記第２のサービス・ケイパビリティ機能の前記第１のサービス・ケイパビリティ機能に対する後方互換性の有無を決定し、さらに前記第１のサービス・ケイパビリティ機能を使用する少なくとも１つのアプリケーションに対し、前記第２のサービス・ケイパビリティ機能の前記第１のサービス・ケイパビリティ機能に対する後方互換性の有無に関する情報を送るように構成されるオープン・サービス・アーキテクチャ・フレームワークと、
を含むオープン・サービス・アーキテクチャ。
【請求項１５】
請求項14に記載のオープン・サービス・アーキテクチャにおいて、前記オープン・サービス・アーキテクチャ・フレームワークは、前記第２のサービス・ケイパビリティ機能によってサポートされる少なくとも１つの特性を決定するように更に構成される前記オープン・サービス・アーキテクチャ。
【請求項１６】
請求項14と請求項１５のいずれかに記載のオープン・サービス・アーキテクチャにおいて、前記オープン・サービス・アーキテクチャ・フレームワークは、前記第２のサービス・ケイパビリティ機能の前記第１のサービス・ケイパビリティ機能に対する後方互換性の有無に関する情報を、前記第１のサービス・ケイパビリティ機能を使用する複数のアプリケーションに対して送るように更に構成される前記オープン・サービス・アーキテクチャ。
【請求項１７】
請求項14から請求項16のいずれかに記載のオープン・サービス・アーキテクチャにおいて、前記オープン・サービス・アーキテクチャ・フレームワークは、前記第１のサービス・ケイパビリティ機能を与える前記少なくとも１つのサービス・ケイパビリティ・サーバの少なくとも１つのインタフェースに対してポインタを送るように更に構成される前記オープン・サービス・アーキテクチャ。
【請求項１８】
請求項14から請求項17のいずれかに記載のオープン・サービス・アーキテクチャにおいて、前記情報は、前記第２のサービス・ケイパビリティ機能で前記第１のサービス・ケイパビリティ機能を置換するか否かを指定する前記オープン・サービス・アーキテクチャ。
【請求項１９】
請求項14から請求項18のいずれかに記載のオープン・サービス・アーキテクチャにおいて、前記情報は、前記第２のサービス・ケイパビリティ機能が前記第１のサービス・ケイパビリティ機能を旧式化するか否かを指定する前記オープン・サービス・アーキテクチャ。
【請求項２０】
請求項14から請求項19のいずれかに記載のオープン・サービス・アーキテクチャにおいて、前記情報は、前記第２のサービス・ケイパビリティ機能から前記第１のサービス・ケイパビリティ機能への移行戦略を指定する前記オープン・サービス・アーキテクチャ。
【誤訳訂正２】
【訂正対象書類名】明細書
【訂正対象項目名】０００３
【訂正方法】変更
【訂正の内容】
【０００３】
Parlay や3GPPのような多くの業界フォーラムや標準化機構がこの課題に対処し、アプリケーションとコア・ネットワークの間のインタフェースとして機能する API（application program interface）を指定している。オープン・サービス・アーキテクチャという用語は、Parlay、3GPPおよびETSIによって開発されたAPI のセットのことである。オープン・サービス・アーキテクチャ（OSA）の内部では、新しいサービス・ケイパビリティ機能（service capability feature：SCF）が利用可能になった場合にOSA内のアプリケーションが加入できることを連絡するようにする基本メカニズムが存在している。しかし、このメカニズムは、現在アプリケーションが使用中の既存のSCFとその新しいSCFがどの程度後方互換性があるか（backward compatible）についての表示を提供していない。したがって、オープン・サービス・アプリケーションでは、新しいSCFと既存のSCFとの互換性をアプリケーションに知らせるメカニズムの必要性が存在している。
【誤訳訂正３】
【訂正対象書類名】明細書
【訂正対象項目名】０００４
【訂正方法】変更
【訂正の内容】
【０００４】
本発明は、オープン・サービス・アーキテクチャにおいて第１のサービスと第２のサービスの間を移行する（migrating）システムと方法を使用して前述の課題およびその他の問題点を克服する。第２のサービスは、オープン・サービス・アーキテクチャ・フレームワークに登録し、それに応じて第２のサービスの特性と第１のサービスの特性を比較し、第２のサービスの第１のサービスに対する後方互換性の有無を決定する。第２のサービスの第１のサービスに対する後方互換性の有無に関する情報は、この比較の後でその第１のサービスを使用している少なくとも１つのアプリケーションに送られる。
【誤訳訂正４】
【訂正対象書類名】明細書
【訂正対象項目名】００１２
【訂正方法】変更
【訂正の内容】
【００１２】
次にアプリケーション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が登録されるとき、その特性を解析した後フレームワークによって提供されるかまたは両者の協調により提供される。