(57)【要約】本発明は、複数の不均質ネットワーク上でアプリケーションサービスアクセスを提供する方法及びシステムに関するものである。本発明は移動通信から生じたものではあるが、全ての通信分野に適用できる。アプリケーションサービスアクセスは、アプリケーションと複数の不均質ネットワークとの間のインターフェースを提供する少なくとも一つのフレームワークを備えたオープンサービスアクセス（ＯＳＡ）エクステンションを設けることで達成される。【選択図】図１
2004535141.tif 000002
【特許請求の範囲】
【請求項１】
複数の不均質ネットワーク上でアプリケーションサービスアクセスを提供する遠隔通信システムであって、アプリケーションと複数の不均質ネットワークとの間のインターフェースを提供する少なくとも一つのフレームワークを備えたオープンサービスアクセス（ＯＳＡ）エクステンションを含むシステム。
【請求項２】
端末ＩＤに基づいて必要なネットワークを選択するための情報をアプリケーションに提供する端末ＩＤアドミニストレータを含む、請求項１に記載のシステム。
【請求項３】
アプリケーションのための拡張されたオープンサービスアクセスを複数の不均質ネットワークに提供する遠隔通信システムであって、前記ネットワークのための唯一の共用フレームワークと、ネットワーク毎に設けられネットワーク固有のインターフェースを提供する一つのサービスキャパビリティフィーチャ（ＳＣＦ）とを含むシステム。
【請求項４】
サービスキャパビリティフィーチャは、どの下層（underlying）ネットワークとＳＣＦが情報交換しているかを示すジェネラルサービスプロパティを含む、請求項３に記載の遠隔通信システム。
【請求項５】
ジェネラルサービスプロパティは、＜operator, network＞のペアを含む文字列である、請求項３に記載の遠隔通信システム。
【請求項６】
端末ＩＤに基づいてアプリケーションのために必要とされるネットワークサービスキャパビリティフィーチャを選択する端末ＩＤアドミニストレータを含む、請求項３に記載の遠隔通信システム。
【請求項７】
端末ＩＤアドミニストレータは、アプリケーションと端末ＩＤとの間のマッピング情報を含むデータベース／ディレクトリを含む、請求項６に記載の遠隔通信システム。
【請求項８】
端末ＩＤアドミニストレータは、アプリケーションとサービスキャパビリティフィーチャのインスタンスとの間のマッピング情報、サービスキャパビリティフィーチャのインスタンスとネットワークとの間のマッピング情報、及びネットワークと端末ＩＤとの間のマッピング情報を含むデータベース／ディレクトリ含む、請求項６又は７に記載の遠隔通信システム。
【請求項９】
端末ＩＤアドミニストレータは、リアルタイムで更新可能である、請求項６に記載の遠隔通信システム。
【請求項１０】
アプリケーションの問い合わせのためのインターフェースクラスを含む端末アドミニストレータ（ＴＡ  ＳＣＦ）を含み、要求しているアプリケーションと端末ＩＤアドミニストレータとの間のインターフェースを提供する、請求項６に記載の遠隔通信システム。
【請求項１１】
端末アドミニストレータ（ＴＡ  ＳＣＦ）は、アプリケーションに対して、
−所定の端末のための正しいサービスキャパビリティフィーチャのインスタンスについてのリファレンスを得ること、
−幾つかの端末ＩＤについてのサービスキャパビリティインスタンスのリファレンスを同時に問い合わせること、
−所定の端末のネットワークＩＤを得ること、
−そのサービスキャパビリティフィーチャのインスタンスの全てについてのリファレンスを得ること、及び
−特定のネットワーク上のそのサービスキャパビリティフィーチャのインスタンスの全てについてのリファレンスを得ること
を可能にするプログラム手段を含む、請求項４に記載の遠隔通信システム。
【請求項１２】
アプリケーションのための拡張されたオープンサービスアクセスを複数の不均質ネットワークに提供する遠隔通信システムであって、前記ネットワークのための唯一の共用フレームワークと、ネットワークのために設けられ共用ネットワークインターフェースを提供する共用サービスキャパビリティフィーチャ（ＳＣＦ）とを含むシステム。
【請求項１３】
サービスキャパビリティフィーチャは、どの下層ネットワークとＳＣＦが情報交換しているかを示すジェネラルサービスプロパティを含む、請求項１２に記載の遠隔通信システム。
【請求項１４】
ジェネラルサービスプロパティは、各々が＜operator, network＞のペアを含む文字列群である、請求項１３に記載の遠隔通信システム。
【請求項１５】
インターフェースは、アプリケーションと下層のネットワークのインターフェースとの間の一から多数へのマッピングを提供するサービスキャパビリティインターフェースクラスを含む、請求項１２に記載の遠隔通信システム。
【請求項１６】
共用サービスキャパビリティフィーチャは、インターフェースクラスからネットワークインターフェースへマッピングを行うマッピング手段と、要求をアプリケーションから正しいネットワークインターフェースクラスに送るディスパッチャ手段とを含む、請求項１２に記載の遠隔通信システム。
【請求項１７】
ディスパッチャへのネットワークの登録を可能にする、マッピング手段とディスパッチャ手段との間の登録インターフェースを含む、請求項１６に記載の遠隔通信システム。
【請求項１８】
ディスパッチャ手段は、アプリケーションから到着する要求のために正しいサービスキャパビリティフィーチャ（ＳＣＦ）を選択する選択手段を含む、請求項１６に記載の遠隔通信システム。
【請求項１９】
端末ＩＤに基づいてアプリケーションのために必要とされるネットワークサービスキャパビリティフィーチャ（ＳＣＦ）を選択する端末ＩＤアドミニストレータを含む、請求項１２に記載の遠隔通信システム。
【請求項２０】
端末ＩＤアドミニストレータは、アプリケーションと端末ＩＤとの間にマッピング情報を含むデータベース／ディレクトリを含む、請求項１５に記載の遠隔通信システム。
【請求項２１】
端末ＩＤアドミニストレータは、アプリケーションとサービスキャパビリティフィーチャのインスタンスとの間、サービスキャパビリティフィーチャのインスタンスとネットワークとの間、及びネットワークと端末ＩＤとの間にマッピング情報を含むデータベース／ディレクトリを含む、請求項１９又は２０に記載の遠隔通信システム。
【請求項２２】
端末ＩＤアドミニストレータは、リアルタイムで更新可能である、請求項１９に記載の遠隔通信システム。
【請求項２３】
端末ＩＤアドミニストレータ（ＴＡ  ＳＣＦ）は、ＳＣＦディスパッチャ手段のためのインターフェースを提供し、前記端末ＩＤアドミニストレータは、
−そのＳＣＦインスタンスに要求を送るために、所定の端末のための正しいサービスキャパビリティインスタンスについてのリファレンスを得るプログラム手段を含み、これには
−アプリケーションが取り扱っている端末ＩＤを得ること、
−要求しているアプリケーションのアプリケーションＩＤ、及びＳＣＦインスタンスによって返されたサービスキャパビリティフィーチャインスタンスのリファレンスを得ることが含まれる、請求項１９に記載の遠隔通信システム。
【請求項２４】
アプリケーションのための拡張されたオープンサービスアクセスを複数の不均質ネットワークに提供する遠隔通信システムであって、ネットワーク毎に設けられたフレームワークを含み、各フレームワークは，前記ネットワークのためのサービスキャパビリティフィーチャ（ＳＣＦ）を有し、ネットワーク固有のインスタンスを提供するシステム。
【請求項２５】
各フレームワークは，端末ＩＤに基づくネットワーク選択に関連して、アプリケーションにサービスキャパビリティ機能を提供する端末ＩＤインフォメータを含んでいる、請求項２４に記載の遠隔通信システム。
【請求項２６】
端末ＩＤインフォメータは、要求しているアプリケーションに、＜terminal ID, belong(True/False)＞のペアを含む文字列を返す、請求項２５に記載の遠隔通信システム。
【請求項２７】
各フレームワークは、他のフレームワーク内のサービスキャパビリティフィーチャを選択し、このサービスキャパビリティフィーチャに対するリファレンスを受け取ることを可能にする機構を含んでいる、請求項２４に記載の遠隔通信システム。
【請求項２８】
フレームワークのための選択可能なサービスキャパビリティフィーチャは予め定義されている、請求項２７に記載の遠隔通信システム。
【請求項２９】
全てのフレームワークが相互認証手続きを含む、請求項２４に記載の遠隔通信システム。
【請求項３０】
各フレームワークは、前記フレームワークが提供するサービスキャパビリティフィーチャについての情報を他のフレームワークが要求することを可能にする拡張されたインターフェースを含む、請求項２４に記載の遠隔通信システム。
【請求項３１】
拡張されたインターフェースは、要求しているフレームワークの識別情報を、前記フレームワークに提供された予め定義されたサービスキャパビリティフィーチャのリストと共に返す要求手続きと、あるフレームワークが、要求しているアプリケーションによって指定されたサービスプロパティに従って、サービスキャパビリティフィーチャインスタンスのリファレンスを返すことを他のネットワークに対して要求することを可能にする獲得手続きとを含む、請求項３０に記載の遠隔通信システム。
【請求項３２】
端末ＩＤに基づいてアプリケーションのために必要とされるネットワークサービスキャパビリティフィーチャを選択する端末ＩＤアドミニストレータを含む、請求項２４に記載の遠隔通信システム。
【請求項３３】
端末ＩＤアドミニストレータは、アプリケーションと端末ＩＤとの間でマッピング情報を含むデータベース／ディレクトリを含む、請求項３２に記載の遠隔通信システム。
【請求項３４】
端末ＩＤアドミニストレータは、アプリケーションとサービスキャパビリティフィーチャのインスタンスとの間、サービスキャパビリティフィーチャのインスタンスとネットワークとの間、及びネットワークと端末ＩＤとの間でマッピング情報を含むデータベース／ディレクトリ含む、請求項３２又は３３に記載の遠隔通信システム。
【請求項３５】
端末ＩＤアドミニストレータは、各フレームワークがサポートする端末ＩＤの範囲に関する情報を端末ＩＤアドミニストレータに提供する情報インターフェースを含む、請求項３２に記載の遠隔通信システム。
【請求項３６】
端末ＩＤアドミニストレータは、リアルタイムで更新可能である、請求項３２に記載の遠隔通信システム。
【請求項３７】
ネットワークは少なくとも一つの遠隔通信ネットワークと少なくとも一つのコンピュータネットワークである、請求項１、３、１２、又は２４に記載の遠隔通信システム。
【請求項３８】
遠隔通信ネットワークは、移動通信、ＵＭＴＳ、ＧＳＭ、ＰＳＴＮ/ ＩＳＤＮなどの無線又は有線ネットワークである、請求項３７に記載の遠隔通信システム。
【請求項３９】
コンピュータネットワークは、ＩＰ（有線）、無線ＬＡＮ、ブルートゥース又はハイパーＬＡＮ（無線）などのパケット式ネットワークである、請求項３７に記載の遠隔通信システム。
【請求項４０】
複数の不均質ネットワーク上でアプリケーションサービスアクセスを提供する方法であって、アプリケーションと複数の不均質ネットワークとの間のインターフェースを提供する、不均質ネットワークためのアプリケーションプログラミングインターフェース（ＡＰＩ）中の少なくとも一つのフレームワークを用いてオープンサービスアクセス（ＯＳＡ）エクステンションを実行することを含む方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数の不均質ネットワーク上でアプリケーションサービスアクセスを提供する方法及びシステムに関するものである。本発明は移動通信から生じたものではあるが、全ての通信分野に適用できる。また、遠隔通信とコンピューティングとが統合しているので、本発明は、ＩＰ（Internet Protocol）ベースのネットワークなどパケット式ネットワーク上でのデータ通信にも適用できる。
【背景技術】
【０００２】
第三者によるアプリケーションの開発を促進するために、第三世代移動通信システム（ＵＭＴＳ）のための標準化組織である 3ＧＰＰ（第三世代パートナーシッププロジェクト）（http://www.3gpp.org ）は、第三世代移動通信システム（ＵＭＴＳ）のためのオープンサービスアクセス（ＯＳＡ）を導入した。ＯＳＡの標準は、3GPP, Virtual Home Environment ; Open Service Architecture （Release 4）. Valbonne, 2001. （3GPP TS 23.127, V4.1.0, 2001-04）に定義されている。
【０００３】
ＯＳＡにより、アプリケーションは  オープンインターフェースを介して、コールコントロール（ＣＣ）、ユーザステータス（ＵＳ）、メッセージング（Ｍ）、ロケーションインフォメーション（ＬＩ）などのネットワークサービス機能にアクセスすることができる。そのようなアーキテクチャは、ＵＭＴＳの成功に必要な一以上の「キラー（killer）」アプリケーションの実現において重要な役割を果たすことは間違いない。何がそのような「キラー」アプリケーションになるかは誰もまだ知らないことは強調するに値する。実際、ＧＳＭについては、ＳＭＳ（Short Message Service）が「キラー」アプリケーションになることを誰も予測できなっかった。
【０００４】
ＯＳＡは移動通信ネットワークのみを対象としている。しかし、通信とコンピューティングとが統合し、また固定通信と移動通信とが統合してきているため、アプリケーションは、下層のネットワークと独立して適切に動作できることが非常に重要である。従って、ＯＳＡの適用範囲を広げて、ＰＳＴＮ／ＩＳＤＮなどの移動通信ネットワーク以外のネットワークやＩＰベースネットワークを含めることが必要である。ＩＰベースネットワークは、例えば、無線ＬＡＮ（８０２．１１）、ハイパーＬＡＮ、又はブルートゥースなどのように無線式と有線式があることは注目する価値がある。この状況について以下記載する。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
残念なことに、ＯＳＡは移動通信ネットワークのみを対象としており、不均質ネットワークにＯＳＡを実施する方法については明記していない。更に、３ＧＰＰで特定されているように、ＯＳＡは不均質ネットワークに適用するのには充分でない。本発明は、幾つかの異なるネットワークの最上部でＯＳＡを実施するためのいろいろな実施形態を提案する。また、ＯＳＡに追加の機能が必要となり、本発明によってこれが提案される。
【０００６】
発明者らの知識によれば、上記の問題に対する解決策は現在のところ知られていない。ＯＳＡが準拠しているパーレイ（Parlay）アーキテクチャ（http://www.parlay.org ）でさえも、パーレイを不均質ネットワーク上で実施する活動は行われていない。パーレイアーキテクチャの概観では、移動通信ネットワーク、ＩＳＤＮ及びＩＰベースネットワークをカバーするパーレイＡＰＩが示されているが、その実施についの詳細はない。
【課題を解決するための手段】
【０００７】
第１の様相において、本発明は、複数の不均質ネットワーク上でアプリケーションサービスアクセスを提供する遠隔通信システムであって、アプリケーションと複数の不均質ネットワークとの間のインターフェースを提供する少なくとも一つのフレームワークを備えたオープンサービスアクセス（ＯＳＡ）エクステンションを含むシステムを提供する。
【０００８】
端末ＩＤアドミニストレータを設け、端末ＩＤに基づいて必要なネットワークを選択するための情報をアプリケーションに提供するようにしてもよい。
【０００９】
第１の実施形態では、システムは、前記ネットワークのための唯一の共用フレームワークと、ネットワーク毎に設けられ、ネットワーク固有インターフェースを提供する一つのサービスキャパビリティフィーチャ（ＳＣＦ）とを含んでいる。このサービスキャパビリティフィーチャは、ＳＣＦが情報交換する下層ネットワークを示すジェネラルサービスプロパティを含んでいてもよい。このジェネラルサービスプロパティは、＜operator, network＞のペアを含む文字列として表される。
【００１０】
この実施形態では、端末ＩＤアドミニストレータが端末ＩＤに基づいてアプリケーションのために必要とされるネットワークサービスキャパビリティフィーチャを選択する。端末ＩＤアドミニストレータは、アプリケーションと端末ＩＤとの間にマッピング情報を含むデータベース／ディレクトリを含んでいてもよい。また、端末ＩＤアドミニストレータは、アプリケーションとサービスキャパビリティフィーチャのインスタンスとの間、サービスキャパビリティフィーチャのインスタンスとネットワークとの間、及びネットワークと端末ＩＤとの間にマッピング情報を含むデータベース／ディレクトリを含んでいてもよい。端末ＩＤアドミニストレータはリアルタイムで更新可能である。アプリケーションの問い合わせのためのインターフェースクラスを含む端末アドミニストレータ（ＴＡ  ＳＣＦ）によって、要求しているアプリケーションと端末ＩＤアドミニストレータのインスタンスとの間のインターフェースが提供される。端末アドミニストレータ（ＴＡ  ＳＣＦ）は、アプリケーションが、所定の端末のための正しいサービスキャパビリティフィーチャについてのリファレンスを得ること、幾つかの端末ＩＤについてのサービスキャパビリティインスタンスのリファレンスを同時に問い合わせること、所定の端末のネットワークＩＤを得ること、そのサービスキャパビリティフィーチャのインスタンスの全てについてのリファレンスを得ること、及び特定のネットワーク上の全てのサービスキャパビリティフィーチャのインスタンスの全てについてのリファレンスを得ることを可能にするプログラム手段を含む。
【００１１】
別の実施形態では、システムは、上記の構成に代え、前記ネットワークのための唯一の共用フレームワークと、ネットワークのために設けられ、共用ネットワークインターフェースを提供する共用サービスキャパビリティフィーチャ（ＳＣＦ）とを含んでいる。ジェネラサービスプロパティは、ＳＣＦが情報交換する下層ネットワークを示すサービスキャパビリティフィーチャに含まれてもよい。このジェネラルサービスプロパティは、各々が＜operator, network＞のペアを含む文字列群として表される。インターフェースは、アプリケーションと下層のネットワークのインターフェースとの間の一から多数のマッピングを提供するサービスキャパビリティインターフェースクラスを含んでいてもよい。
【００１２】
更に、共用サービスキャパビリティフィーチャは、インターフェースクラスからネットワークインターフェースへマッピングを行うマッピング手段と、要求をアプリケーションから正しいネットワークインターフェースクラスに送るディスパッチャ手段とを含んでいてもよい。マッピング手段とディスパッチャ手段との間の登録インターフェースは、ディスパッチャへのネットワークの登録を可能にする。ディスパッチャ手段は、アプリケーションから到着する要求ために正しいサービスキャパビリティフィーチャ（ＳＣＦ）を選択する選択手段を含む。端末ＩＤアドミニストレータは、端末ＩＤに基づいて、アプリケーションのために必要とされるネットワークサービスキャパビリティフィーチャ（ＳＣＦ）を選択する。アプリケーションと端末ＩＤとの間のマッピング情報は、端末ＩＤアドミニストレータのデータベース／ディレクトリに含まれていてもよい。このデータベース／ディレクトリは、アプリケーションとサービスキャパビリティフィーチャのインスタンスとの間、サービスキャパビリティフィーチャのインスタンスとネットワークとの間、及びネットワークと端末ＩＤとの間にマッピング情報を含んでいる。本実施形態においても、端末ＩＤアドミニストレータはリアルタイムで更新可能である。端末ＩＤアドミニストレータ（ＴＡ  ＳＣＦ）は、ＳＣＦディスパッチャ手段のためのインターフェースを提供し、この端末ＩＤアドミニストレータは、動作時に、そのＳＣＦインスタンスに要求を送るために、所定の端末のための正しいサービスキャパビリティインスタンスについてのリファレンスを得るプログラム手段を含み、これには、アプリケーションが取り扱われる端末ＩＤを得ること、要求しているアプリケーションのアプリケーションＩＤ、及びＳＣＦインスタンスによって返されたサービスキャパビリティフィーチャインスタンスのリファレンスを得ることが含まれる。
【００１３】
更に別の実施形態では、システムは、各ネットワーク用のフレームワークを含んでいてもよく、各フレームワークは，前記ネットワークのためのサービスキャパビリティフィーチャ（ＳＣＦ）を有し、ネットワーク固有のインスタンスを提供する。各フレームワークは、他のフレームワーク内のサービスキャパビリティフィーチャを選択し、このサービスキャパビリティフィーチャに対するリファレンスを受け取ることを可能にする機構を含んでいてもよい。フレームワークのための選択可能なサービスキャパビリティフィーチャは予め定義されてもよい。各フレームワークは，端末ＩＤに基づくネットワーク選択に関連して、アプリケーションにサービスキャパビリティ機能を提供する端末ＩＤインフォメータを含んでいてもよい。端末ＩＤインフォメータは、要求しているアプリケーションに、＜terminal ID, belong(True/False)＞のペアを含む文字列を返す。全てのフレームワークは、要求された時に相互認証手続きを実行するプログラム手段を含んでいてもよい。これは、前記フレームワークが提供するサービスキャパビリティフィーチャについての情報を他のフレームワークが要求する場合である。これを可能にするために、フレームワークは、拡張されたインターフェースを含んでいてもよい。この拡張されたインターフェースは、要求しているフレームワークの識別情報を、前記フレームワークに提供された予め定義されたサービスキャパビリティフィーチャのリストと共に戻す要求手続きと、あるフレームワークが、要求しているアプリケーションによって指定されたサービスプロパティに従って、サービスキャパビリティフィーチャインスタンスのリファレンスを返すことを他のネットワークに対して要求することを可能にする獲得手続きとを実行するプログラム手段を含んでいてもよい。端末ＩＤアドミニストレータは、端末ＩＤに基づいて、アプリケーションのために必要とされるネットワークサービスキャパビリティフィーチャを選択する。選択は、端末ＩＤアドミニストレータと情報交換するデータベース／ディレクトリに基づくマッピング機能によって可能となる。データベース／ディレクトリは、アプリケーションとサービスキャパビリティフィーチャのインスタンスとの間、サービスキャパビリティフィーチャのインスタンスとネットワークとの間、及びネットワークと端末ＩＤとの間にマッピング情報を含んでいてもよい。各フレームワークがサポートする端末ＩＤの範囲に関する情報を端末ＩＤアドミニストレータに提供する情報インターフェースもまた端末ＩＤアドミニストレータに含まれてもよい。端末ＩＤアドミニストレータはリアルタイムで更新可能である。
【００１４】
不均質ネットワークの例としては、移動通信、ＵＭＴＳ、ＧＳＭ、ＰＳＴＮ/ ＩＳＤＮなどの遠隔通信ネットワーク（無線又は有線）、及びＩＰ（有線）、無線ＬＡＮ、ブルートゥース又はハイパーＬＡＮ（無線）などのパケット式ネットワークのようなコンピュータネットワークが挙げられるが、これらに限定されるものではない。
【００１５】
更なる様相では、本発明は、複数の不均質ネットワーク上でアプリケーションサービスアクセスを提供する方法であって、アプリケーションと複数の不均質ネットワークとの間のインターフェースを提供する、不均質ネットワークためのアプリケーションプログラミングインターフェース（ＡＰＩ）中の少なくとも一つのフレームワークを用いてオープンサービスアクセス（ＯＳＡ）エクステンションを実行することを含む方法を提供する。
【００１６】
更に別の様相では、本発明は、アプリケーションのためのオープンサービスアクセスを複数の不均質ネットワークに提供するためのアプリケーションプログラミングインターフェース（ＡＰＩ）のプログラムを提供する。該プログラムは、上記の方法を実施しそして上記のびシステムを確立するための指令群を含んでいる。
【００１７】
別の様相では、本発明は、アプリケーションのためのオープンサービスアクセスを複数の不均質ネットワークに提供するためのアプリケーションプログラミングインターフェース（ＡＰＩ）を記憶した、コンピュータにより読出可能な媒体を提供する。該媒体は、上記の方法を実施し、上記のシステムを確立するための指令群を含んでいる。
【００１８】
本発明は、例えは、ネットワークオペレータ、サービス／アプリケーションプロバイダ、及びユーザなどの、遠隔通信及び情報交換分野における種々の関係者にいろいろな方法で利益をもたらす。ネットワークオペレータは、アプリケーションに対してより柔軟なサービスを提供できるであろう。従って、彼らは、より多くの数のアプリケーション、従って、より高いトラフィックを得ることができ、またより多数のユーザを得ることができる。サービス／アプリケーションプロバイダはアプリケーションをより簡単に開発でき、より興味のあるアプリケーションを開発できる。彼らは、ネットワークの相違を気にする必要がない。アプリケーションは不均質なネットワーク上で動作するため、アプリケーションはより一般的なものとなる。同一のアプリケーションを異なるネットワークで展開できるため、極めて多くの再使用が可能で、大幅な節約になる。ユーザは、ＯＳＡ  ＡＰＩによって不均質なネットワーク上で動作可能とされた広範なアプリケーションを楽しむことができるであろう。本発明はＯＳＡヘ適用するものであるが、ＰＡＲＬＡＹアーキテクチャにも適用可能である。何故なら、ＯＳＡは多くをＰＡＲＬＡＹに依存しているからである。
【００１９】
上記のように、本発明は、不均質なネットワークのためのアプリケーションの開発を簡単にできるため、サービス／アプリケーションプロバイダの問題を解決できる。同時に、不均質なネットワーク（例えは、固定及び移動式の遠隔通信、並びにＩＰベースの通信）を有するネットワークオペレータに機会を与えることができる。本発明は添付の請求の範囲に定義されている。
【発明を実施するための最良の形態】
【００２０】
以下、本発明の実施形態を図面を参照して説明する。
【００２１】
本発明は、二つの主要なアイテムから成っている。
・不均質ネットワークへのＯＳＡの適用の提案。
・不均質ネットワーク上でＯＳＡを実施するための実施形態。各実施形態について、必要な付加機能とそれらのＯＳＡへの組み込みについて述べる。
【００２２】
本発明は、本来は第三世代移動通信ネットワークを対象にしていたＯＳＡ（オープンサービスアクセス）の適用範囲を不均質ネットワークまで広げる、即ち、ＰＳＴＮ、ＩＳＤＮ、及びＩＰベースのネットワーク（インターネット、イントラネット）をも含めるようにする。以下、不均質ネットワーク上でＯＳＡを実施するための４つの実施形態について述べる。各実施形態に関連する問題を検討し、必要となる追加機能や特徴を呈示できる。
【００２３】
実施形態１：全てのネットワークのための共用ＯＳＡフレームワークと各ネットワークのための一つのサービスキャパビリティフィーチャ
本実施形態では、単一のＯＳＡフレームワークが全てのネットワークを受け入れるが、各ネットワークは独自のサービスキャパビリティフィーチャ（ＳＣＦ）を有する。ＧＳＭ／ＵＭＴＳネットワークは、コールコントロール（ＣＣ）ＳＣＦ、ユーザインターラクション（ＵＩ）ＳＣＦ、ユーザステータス（ＵＳ）ＳＣＦなどのＳＣＦを有するであろう。図２に示すようにＰＳＴＮ／ＩＳＤＮネットワーク及びＩＰベースネットワークの場合も同様である。
【００２４】
従って、各ＳＣＦが各ネットワークに固有のインターフェースにマッピングされる。どの様にマッピングが行われるかはネットワークに依存する。例えば、ＧＳＭネットワークについて責任のあるＣＣ  ＳＣＦは、ＧＳＭネットワーク内でコールコントロールを出すインターフェースにマッピングされる。ＰＳＴＮ／ＩＳＤＮネットワーク及びＩＰベースネットワーク内のＣＣ  ＳＣＦの場合も同様である。これにより、我々の不均質ネットワーク環境内の各ネットワークのためのコールコントロール・ネットワークサービスキャパビリティに対して標準化されたＣＣ  ＡＰＩが得られ、第三者のアプリケーションが全てのネットワーク内でコールコントロールキャパビリティを使用できるようになる。他のＳＣＦについても同様である。
【００２５】
必要とされる追加機能
Ａ．ＳＣＦネーミング方式
各下層ネットワークのためのＳＣＦは、ＯＳＡフレームワークを用いて識別されそして登録される必要がある。従って、ＳＣＦのサービスプロパティの値は、各ＳＣＦがどのネットワークに属しているかを示す必要がある。また、ネットワークの所有者、即ちネットワークオペレータを認識する必要がある。この目的のために、ＳＣＦが情報交換している下層ネットワークを示す、"Underlying Network"と呼ばれるジェネラルサービスプロパティが導入される。このプロパティ値は、＜Operator, network＞のペアを含む文字列である。例えは、ユーザステータスＳＣＦの場合、その値は＜Telenor, GSM＞又は＜Netcom, GSM＞又は＜Telenor, IP-based(SIP)＞となり得る。
＜オペレータ，ネットワーク＞のペアを含む文字列である。
【００２６】
Ｂ．端末ＩＤに基づくＳＣＦインスタンスの選択
アプリケーションにとっての大きな問題は、端末識別器、即ち、端末ＩＤ、のみに基づいてどの様にして正しいＳＣＦインスタンスを選択するかということである。通常の電話番号、名前、又はＩＰアドレスを端末ＩＤとすることができる。例えば、アプリケーションが、ある端末に対しての呼び出しを確立することを望む場合、アプリケーションは正しいＣＣ  ＳＣＦに対して申し込む必要がある。幾つかの端末ＩＤは、ＧＳＭネットワーク、例えばＳＩＰアドレス、の範囲になく、従って、これらの端末に対しての呼び出し要求はＧＳＭネットワークに送ってはならず、ＩＰベースネットワークに送らなければならない。
【００２７】
別の問題は、アプリケーションが、例えば、「クリックツーコール（click to call ）」アプリケーションの呼び出しを確立することを望む場合、その呼び出しを確立する下層ネットワーク、即ち、使用するＣＣ  ＳＣＦインスタンスを選択しなければならない。
【００２８】
更に、アプリケーションが、例えばユーザステータスＳＣＦを使用する時に問題が発生する。ユーザステータス（ＵＳ）ＳＣＦは、アプリケーションがユーザの端末の状態（到達可能、到達不可能、及び使用中）を得られるようにする。ＧＳＭネットワークのためのＵＳ  ＳＣＦは、ＧＳＭネットワークの範囲内の端末（ＨＬＲに登録されたＧＳＭ電話）にユーザステータスを伝えることができるだけであり、ＩＰベースネットワークのためのＵＳ  ＳＣＦは、ＳＩＰサーバなどに登録されたユーザにユーザステータスを伝えることができるだけである。ユーザのユーザステータスをチェックすることを望むアプリケーションは、ユーザの端末ＩＤに従って正しいＳＣＦインスタンス、即ち正しい下層ネットワークを選択しなければならない。例えば、端末ＩＤがＧＳＭ番号である場合、アプリケーションはＧＳＭネットワークのためのＵＳ  ＳＣＦインスタンスを選択しなければならない。その後、アプリケーションは、選択したＵＳ  ＳＣＦインスタンスと交信することによって要求したユーザステータスを得ることができる。
【００２９】
上記の例から、ＳＣＦに対してアクションを行う時にアプリケーションは正しいＳＣＦインスタンスを選択しなければならないという問題があることが分かる。アプリケーションは、端末の命名法又は番号の付け方についての情報、即ち、どの端末がどのネットワークに属しているかについての情報を有していなければならない。更に、端末ＩＤと正しいＳＣＦインスタンスとの間にリンクがなければならない。そのような情報は定常的なものでなく頻繁に変化し、頻繁に更新しなければならない。何故なら、人々は、端末、オペレータ、及び申し込み（subscriptions）を頻繁に変更するからである。アプリケーションが端末ＩＤに基づいてＳＣＦを選択するのを助ける端末ＩＤアドミニストレータと呼ばれる追加の機能が必要となる。
【００３０】
端末ＩＤアドミニストレータ（ＴＡ）は、図３に示すように、アプリケーションとＳＣＦインスタンスとの間のマッピング、ＳＣＦインスタンスとネットワークとの間のマッピング、そして最後にネットワークと端末ＩＤとの間のマッピングを含むデータベース／ディレクトリを有している。図面中の数字は基数を示す。１は１だけを示し、＋１は１以上を示す。一つのアプリケーションは１以上のＳＣＦインスタンスを有することができる。一つのＳＣＦインスタンスは一つのアプリケーションしか有しない。一つのＳＣＦは一つのネットワークしか有しないが、一つのネットワークが１以上のＳＣＦを有する場合がある。一つのネットワークは１以上の端末を有しているが、一台の端末は一つのネットワークのみに属している。ＴＡは、ネットワークオペレータが、変化が起きた時にそれを登録できるようにし、またアプリケーションが、上記の全てのマッピングに関する情報、例えば図４に示すような端末ＩＤ群のためのＳＣＦインスタンスについて問い合わせできるようにする。
【００３１】
ＴＡは、ＯＳＡを使用する任意のアプリケーションのための有用な機能を提供する。従って、ＴＡは、アプリケーションのために容易にアクセスできなければならない。この目的のために、ＴＡの機能を標準的なＡＰＩとして要約する、端末アドミニストレータＳＣＦ（ＴＡ  ＳＣＦ）と呼ばれるＯＳＡサービスキャパビリティフィーチャ（ＳＣＦ）が設けられる。ＴＡ  ＳＣＦは、アプリケーションの問い合わせのためのインターフェースクラスを有している。アプリケーションの問い合わせのためのＴＡ  ＳＣＦインターフェースは、アプリケーションが使用できる下記のメソッドを含んでいる。
【００３２】
getSCFinstance(＜terminalID＞,＜applicationID＞＜SCFreference＞)
＜terminalID＞は、アプリケーションが取り扱われる端末ＩＤ、例えば、電話番号。
＜applicationID＞は、要求しているアプリケーションのＩＤ。
＜SCFreference＞は、ＴＡ  ＳＣＦによって返されるＳＣＦインスタンスのリファレンス。
このメソッドにより、アプリケーションは、所定の端末のための正しいＳＣＦインスタンスのリファレンス、例えば電話番号を得ることができる。
【００３３】
getListofSCFinstances(＜listofTerminalID＞,＜applicationID＞,＜listofSCFreferences＞)
＜listofTerminalID＞は、ＳＣＦインスタンスを見つける端末ＩＤのリスト。
＜applicationID＞は、要求しているアプリケーションのＩＤ。
＜listofSCFreferences＞は、ＴＡ  ＳＣＦによって返されるリファレンス及び対応する端末ＩＤのリスト。
このメソッドにより、アプリケーションは、幾つかの端末ＩＤのためのＳＣＦインスタンスのリファレンスを同時に問い合わせることができる。
【００３４】
getNetworkID(＜terminalID＞,＜applicationID＞＜NetworkID＞)
＜terminalID＞は、アプリケーションが取り扱われる端末ＩＤ。
＜applicationID＞は、要求しているアプリケーションのＩＤ。
＜NetworkID＞は、ＴＡ  ＳＣＦによって返される、端末が属しているネットワークのＩＤ。
このメソッドにより、アプリケーションは、所定の端末のネットワークＩＤを得ることができる。
【００３５】
getAllSCFinstance,(＜applicationID＞＜ListofSCFreferencse＞)
＜applicationID＞は、要求しているアプリケーションのＩＤ。
＜SCFreference＞は、ＴＡ  ＳＣＦによって返される、アプリケーションのためのＳＣＦインスタンスのリファレンスのリスト。
このメソッドにより、アプリケーションは、アプリケーションの全てのＳＣＦインスタンスのリストを得ることができる。
【００３６】
getAllSCFinstance,(＜applicationID＞,＜networkID＞,＜ListofSCFreferencse＞)
＜applicationID＞は、要求しているアプリケーションのＩＤ。
＜networkID＞は、ネットワークのＩＤ、例えば、＜Telenor, GSM＞、＜OperatorX, ISDN＞、＜OperatorY, IP-based＞など。
＜SCFreference＞は、ＴＡ  ＳＣＦによって返される、アプリケーションのためのＳＣＦインスタンスのリファレンスのリスト。
このメソッドにより、アプリケーションは、特定のネットワーク上のアプリケーションの全てのＳＣＦインスタンスのリストを得ることができる。
【００３７】
例
アプリケーションが、端末ＩＤ、例えば電話番号１２３４５６７８のユーザステータスを得ることを望んでいると仮定する。アプリケーションは、＜terminalID＞=12345678 とＳＣＦの名称＜SCFtype＞="User Status" を含む問い合わせをＴＡ  ＳＣＦ（getSCFinstance）に送出する。これに応答して、アプリケーションは、要求した端末ＩＤが属しているユーザステータスＳＣＦに対する目的とするリファレンスを受け取る。これにより、アプリケーションは、下層のネットワークを気にすることなく、正しいＵＳ  ＳＣＦを使用できる。従って、ＴＡ  ＳＣＦを使用する時、本実施形態は、ＯＳＡのゴールにより確認される。
上記した実施形態１は図５に要約されている。
【００３８】
実施形態２：全てのネットワークのための共用フレームワーク及び共用ＳＣＦ（サービスキャパビリティフィーチャ）
本発明のこの実施形態では、単一のＯＳＡフレームワークが全てのネットワークを受け入れ、ＳＣＦが全ての下層のネットワークを代表する。例えば、コールコントロールＳＣＦは、ＧＳＭ／ＵＭＴＳネットワーク、ＰＳＴＮ／ＩＳＤＮネットワーク、及びＩＰベースネットワークのためのコールコントロールキャパビリティを組入れる。図６に示す他のＳＣＦについても同様である。
【００３９】
従って、各ＳＣＦが全てのネットワークと通信する。例えば、ＣＣ  ＳＣＦは、ＧＳＭネットワーク、ＰＳＴＮ／ＩＳＤＮネットワーク、及びＩＰベースネットワーク内でコールコントロールを出すインターフェースにマッピングされる。アプリケーションは、単一のＣＣ  ＳＣＦのみを用いて全てのネットワーク上でコールコントロールを行うことができる。他のＳＣＦについても同様である。
【００４０】
追加機能
Ａ．ＳＣＦネーミング方式
この場合、ＳＣＦは幾つかの下層のネットワークを代表しており、それらのすべてを特定する必要がある。また、各ネットワークの所有者、即ち各ネットワークのネットワークオペレータを認識する必要がある。
【００４１】
本発明のこの実施形態では、ＳＣＦが情報交換している下層ネットワークを示す、"Underlying Network"と呼ばれるジェネラルサービスプロパティが導入される。このプロパティ値は、各々が＜Operator, network＞のペアを含む文字列群である。例えは、ユーザステータスＳＣＦの場合、その値は[＜Telenor, GSM＞,＜Netcom, GSM＞,＜Telenor, IP-based(SIP)＞]となり得る。これは図７の例に示されている。図７では、アプリケーションが、ＯＳＡフレームワーク内の所望のサービスプロパティを使用して、ＧＳＭネットワーク及びＩＰベースネットワーク内のユーザステータスＳＣＦを選択する（とトレードする）。これが図７において１で示されている。その後、ＯＳＡフレームワークは、サービス取引き（service trading ）に同意し、ＧＳＭ／ＵＭＴＳネットワークとＩＰベースネットワークの両方と情報交換できるユーザステータスＳＣＦの新しいインスタンスを作り、図７において１．１「新」によって示されているように、このユーザステータスインスタンスへのリファレンスをアプリケーションに返す。
【００４２】
Ｂ．ディスパッチング機能
本実施形態では、各ＳＣＦは、下層のネットワークの全てに対して責任があり、従って、ＳＣＦのインターフェースクラスが、各ネットワークについて全てのインターフェースにマッピングされる必要がある（一つから多数へのマッピング）。例えば、コールコントロールのインターフェースクラスは、ＯＳＡのコールコントロールＡＰＩとＰＳＴＮ／ＩＳＤＮネットワークのためのＳＳ７  ＩＮＡＰとの間のマッピング、ＯＳＡのコールコントロールＡＰＩとＩＰベースネットワークのためのＳＩＰプロトコルとの間のマッピング、及びＯＳＡのコールコントロールＡＰＩとＧＳＭ／ＵＭＴＳネットワークのためのＣＡＭＥＬとの間のマッピングを実施しなければならない。これが図８に示されている。
【００４３】
各下層ネットワーク内のネットワーク機器は種々のベンダーによって開発される可能性がある（例えば、ＧＳＭのためのＩＮシステムはＥｒｉｃｓｓｏｎ、Ａｌｃａｔｅｌによって開発され、ＳＩＰサーバはＨｏｔＳｉｐ、Ｄｙｎａｍｉｃｓｏｆｔ、Ｕｂｉｑｕｉｔｙなどによって開発されている）ため、幾つかの問題が生じる。各ベンダーは、ＯＳＡインターフェースクラスと彼らのネットワーク機器へのインターフェースとの間のマッピングが実施できるだけである。更に、上記の解決策は柔軟性に欠ける。何故なら、一人のベンダーは、ＯＳＡインターフェースクラスから全ての不均質ネットワーク内の全てのネットワーク固有インターフェースへのマッピングを開発しなければならないためである。
【００４４】
本発明のこの実施形態では、ＯＳＡに対して幾つかの必要な変更を加えている。ＳＣＦが二つの別々のコンポーネントに分割されている。
・一方のコンポーネントがＯＳＡインターフェースクラスから下層ネットワークのインターフェースへのマッピングを実施する。
・他方のコンポーネントが、アプリケーションからの要求を、正しい下層ネットワークに接続された正しいＳＣＦへディスパッチする（送る）責任を負う。
【００４５】
ＳＣＦを二つのコンポーネントに分割することにより、ネットワーク機器のベンダーは、ＯＳＡインターフェースクラスから彼らのネットワーク機器へのマッピング（一対一のマッピング）を開発するだけでよく、アプリケーションは、ＳＣＦが多くの不均質ネットワークと情報交換するのにも関わらず、一つのＳＣＦだけを取り扱えばよい。インターフェースマッピングを実施するコンポーネントは、特にＯＳＡで明記されたＳＣＦと同一である。
【００４６】
アプリケーションからの要求をディスパッチするコンポーネントである「ＳＣＦディスパッチャ」は、ＯＳＡに対する追加の機能である。勿論、アプリケーションへのインターフェースは、ＯＳＡ仕様において各ＳＣＦについて明記されているものと同じでなければならない。
【００４７】
更に、二つのＳＣＦコンポーネントの間には「登録インターフェース」が設けられており、各ネットワークのためのＳＣＦが「ＳＣＦディスパッチャ」に登録することを可能にする。ネットワーク固有ＳＣＦは、「ＳＣＦディスパッチャ」にそれ自身へのリファレンスとそれがサポートするサービスプロパティを提供する。従って、「ＳＣＦディスパッチャ」は、ネットワーク固有ＳＣＦの能力についての知識を保持し、従ってそれ自身をＯＳＡフレームワークに登録し、それがサポートするサービスプロパティ、即ち、各ネットワーク固有ＳＣＦインスタンスによって提供される全てのサービスプロパティの全体を提供することができる。
【００４８】
各アプリケーションのためにＳＣＦディスパッチャのインスタンスが作られる。どの下層ネットワークがアプリケーションによるサービスキャパビリティの使用を許容するかに依存して、各ネットワークのためのＳＣＦの対応するインスタンスが作られる。ＳＣＦディスパッチャインスタンスは、これらのＳＣＦインスタンス全てのリファレンスを記憶する。また、「ＳＣＦディスパッチャ」は、アプリケーションからの要求が到着した時に、正しいＳＣＦインスタンスを選択するための機能も有する。そのような機能の必要性を示すために、アプリケーションがＵＳ  ＳＣＦに対してユーザのステータスを要求する場合を想定する。ＧＳＭネットワーク、ＰＳＴＮ／ＩＳＤＮネットワーク、及びＩＰベースネットワーク（ＳＩＰ）のためのＵＳ  ＳＣＦをアプリケーションが使用できるようにするサービスレベルアグリーメントの表示をアプリケーションが有している。ＵＳ  ＳＣＦ（「ＵＳ  ＳＣＦディスパッチャ」）は、三種類の下層ネットワークと情報交換することが可能である。従って、それは、要求を正しいＵＳ  ＳＣＦインスタンスにディスパッチするために、どの下層のネットワークが要求に関連しているかを決定できなければならない。これは、前の実施形態１に記載した要件、即ち、端末ＩＤに基づいて正しいＳＣＦインスタンスを選択するという要件と実際には同じである。
【００４９】
従って、「ＳＣＦディスパッチャ」は、端末ＩＤからＳＣＦインスタンスを問い合わせるために端末ＩＤアドミニストレータ（ＴＡ）を使用しなければならない。これにより、「ＳＣＦディスパッチャ」は、端末ＩＤアドミニストレータへの問い合わせ結果を用いて、アプリケーションからの要求を正しいＳＣＦインスタンスにディスパッチできる。なお、ネットワークＳＣＦからの応答や報告は全て、対応するアプリケーションに送られる前に「ＳＣＦディスパッチャ」を通過することに注意されたい。これが図９に示されている。
【００５０】
Ｃ．端末ＩＤに基づくＳＣＦインスタンスの選択
図９にも示されているように、端末ＩＤアドミニストレータが必要とされる。端末ＩＤアドミニストレータ（ＴＡ）は、アプリケーションとＳＣＦインスタンスとの間のマッピング、ＳＣＦインスタンスとネットワークとの間のマッピング、そして最後にネットワークと端末ＩＤとの間のマッピングを含むデータベース／ディレクトリサービスを有している。図１０は端末ＩＤアドミニストレータによって保持されている関係を示す。図面中の数字は基数を示す。１は１だけを示し、＋１は１以上を示す。
【００５１】
端末ＩＤアドミニストレータは、ネットワークオペレータが、変化が起きた時にそれを登録できるようにする。また、端末ＩＤアドミニストレータは、下記のメソッドを含むＳＣＦディスパッチャへのインターフェースを提供する。
【００５２】
getSCFinstance(＜terminalID＞,＜applicationID＞＜SCFreference＞)
＜terminalID＞は、アプリケーションが取り扱われる端末ＩＤ、
＜applicationID＞は、要求しているアプリケーションのＩＤ、
＜SCFreference＞は、ＳＣＦインスタンスによって返されるＳＣＦインスタンスのリファレンスである。
このメソッドにより、ＳＣＦディスパッチャは、所定の端末のための正しいＳＣＦインスタンスのリファレンスを得て、そのＳＣＦインスタンスへ要求を送ることができる。
【００５３】
本第２実施形態における端末ＩＤアドミニストレータは見ることができず、第１実施形態と同じ方法でアプリケーションに利用することもできないが、例えば、ＳＣＦディスパッチャのためのフレームワーク内のみに存在している。
【００５４】
例
アプリケーションが、端末ＩＤ、例えば電話番号１２３４５６７８のユーザステータスを得ることを望んでいると仮定する。アプリケーションは、＜terminalID＞=12345678 とＳＣＦの名称 ＜SCFtype＞="User Status" を含む問い合わせをＣＣ  ＳＣＦディスパッチャに送出する。ＣＣ  ＳＣＦディスパッチャは、要求（getSCF instance）を、端末ＩＤからＳＣＦインスタンスへのマッピングを介して端末ＩＤアドミニストレータに送る。これに応答して、ＣＣ  ＳＣＦディスパッチャは、要求した端末ＩＤが属しているユーザステータスＳＣＦに対する目的とするリファレンスを受け取る。これにより、ディスパッチャは、下層のネットワークを気にすることなく、正しいＵＳ  ＳＣＦを使用できる。
【００５５】
実施形態３：ネットワーク毎のフレームワーク
本実施形態では、一つのＯＳＡフレームワークが一つの下層ネットワークのみを受け入れる。例えば、ＧＳＭネットワーク内のＯＳＡフレームワークは、ＧＳＭネットワーク内のサービスキャパビリティについてのみ責任があり、ＧＳＭネットワーク内の全てのＳＣＦ（図１１に示すＣＣ  ＳＣＦ及びＵＳ  ＳＣＦ）の全てを制御する。図１１に示すようにＰＳＴＮ／ＩＳＤＮネットワーク及びＩＰベースネットワークについても同様である。
【００５６】
各ＳＣＦが各ネットワークに固有のインターフェースにマッピングされる。例えば、ＧＳＭネットワークのＣＣ  ＳＣＦは、ＧＳＭネットワーク内でコールコントロールを出すインターフェースにマッピングされる。ＰＳＴＮ／ＩＳＤＮネットワーク及びＩＰベースネットワーク内のＣＣ  ＳＣＦについても同様である。これにより、アプリケーションは、各ＯＳＡフレームワークを個別にアドレス指定することにより、全ての下層ネットワーク内のサービスキャパビリティを使用できる。
【００５７】
追加の機能
Ａ．端末ＩＤに基づくフレームワークの選択
アプリケーションは、どのフレームワークがある端末ＩＤをアドレス指定しているのかを知る必要がある。本実施形態では、各フレームワークが、ＳＣＦ「端末ＩＤインフォメータ」を有している。端末ＩＤインフォメータＳＣＦは、フレームワークによってサポートされている下層ネットワークに端末が属しているか否かをアプリケーションが問い合わせることを可能にするインターフェースを有している。この問い合わせ手続きは以下のように表すことができる。
【００５８】
TerminalInfoReq＜terminal ID, belong(True/False)＞
端末ＩＤは、真(True)又は偽(False) と共に、ＳＣＦインターフェースからＯＳＡフレームワークを介して、問い合わせをしたアプリケーションに返される。端末がフレームワークに属していない場合、手続きは偽(False) を返し、アプリケーションは、真(True)を回答として受信するまで、他のフレームワークを問い合わせることで手続きを進める。この様にして、アプリケーションは所望のＳＣＦを選択して使用できる。真／偽はブール論理によって表される。
【００５９】
例
アプリケーションが、端末ＩＤ、例えば電話番号１２３４５６７８のユーザステータスを得ることを望んでいる。アプリケーションは、＜terminalID＞=12345678 とＳＣＦの名称＜SCFtype＞="User Status" を含む問い合わせをＯＳＡフレームワークに送出する。ＯＳＡフレームワークはその要求を端末ＩＤインフォメータＳＣＦに送る。端末ＩＤがそのフレームワーク中に存在していた場合、インフォメータＳＣＦインターフェースがＯＳＡフレームワークに真を返す。これにより、アプリケーションは所望のＳＣＦを選択して使用する。偽が返された場合、アプリケーションは、別のＯＳＡフレームワークに要求を送る。
【００６０】
実施形態４：異なるＯＳＡフレームワーク間の通信と協調
本実施形態では、第３実施形態と同様に、一つのＯＳＡフレームワークは単一の下層ネットワークしか受け入れない。しかし、フレームワーク間での通信と協調が可能となっている。フレームワーク間の相互運用可能性が確立され、多くの不均質ネットワークからのサービスキャパビリティを利用するためには、アプリケーションは一つＯＳＡフレームワークだけと取引きをすればよい（図１２参照）。
【００６１】
アプリケーションは、「ホーム」フレームワークのＳＣＦを使用できるだけでなく、それらの「ホーム」フレームワークに向けて要求を出すだけで、他のネットワーク上の他のフレームワークに属しているＳＣＦも使用できる。フレームワークは、その後、実際のフレームワークと通信して、ＳＣＦインスタンスのリファレンスを問い合わせる。そのようなインスタンスがアプリケーションのために作られていない場合には、「外の（foreign）」フレームワークがインスタンス作り、そのリファレンスを「ホーム」フレームワークに返す。その後、「ホーム」フレームワークは要求しているアプリケーションにリファレンスを返す。サービスキャパビリティフィーチャのために、アプリケーションは、ＧＳＭ、ＰＳＴＮ、ＩＰなどの種々のネットワークを表す幾つかのＳＣＦインスタンスのリファレンスを有し得る。従って、各ＳＣＦインスタンスのサービスプロパティは区別されている。端末ＩＤアドミニストレータは、端末ＩＤが与えられると、使用すべきＳＣＦのリファレンスを返す。これが図１３に示されている。図１３は、ＧＳＭネットワークとＩＰベースネットワークの両方におけるＵＳ  ＳＣＦの使用を示す。
【００６２】
アプリケーションが、ＧＳＭネットワーク内のフレームワークを使用して、ＧＳＭネットワーク内のユーザステータスＳＣＦ及びＩＰベースネットワーク内のユーザステータスＳＣＦを選択する場合を想定する（図１３の１．及び２．）。ＧＳＭネットワーク内のＵＳがＯＳＡによって定義されたような通常の方法でトレードされる。その後、ＧＳＭネットワーク内のフレームワークは、アプリケーションが提供したサービスプロパティを使用してＩＰベースネットワーク内のフレームワークに対して新たなＵＳ  ＳＣＦインスタンスを作ることを依頼し、ＵＳインスタンスへのリファレンスをアプリケーションに返す。（リファレンスは、作られたＳＣＦインスタンスへのポインタである。実際の実施形態は、その実施に依存する）。本実施形態におけるＯＳＡインターフェースは、フレームワークが他のフレームワーク内のＳＣＦを選択すると共に、ＳＣＦインスタンスへのリファレンスを受け取れるようにするための機構を含んでいる。図１３では、この機構が２−１であり、ＧＳＭネットワーク内のＯＳＡフレームワークが、ＩＰベースネットワーク内のＯＳＡフレームワーク内のＯＳＡフレームワーク通信ＡＰＩ内のメソッドを使用して、ＩＰベースネットワーク内のＵＳ  ＳＣＦを選択（トレード）する。その後、フレームワークは、ＯＳＡ標準内に明記された通常のトレーディング機能を使用して、ＳＣＦインスタンスに対するリファレンスをアプリケーションに返す。図１３の２−２おいては、ＩＰベースネットワークのＯＳＡフレームワークがサービストレーディングに同意し、ＩＰベースネットワークのためのＵＳ  ＳＣＦの新しいインスタンスを作り、このＳＣＦに対するリファレンスをＧＳＭネットワーク内のＯＳＡフレームワークに返す。その後、このフレームワークは、リファレンスをＳＣＦアプリケーションに返す。
【００６３】
追加機能
Ａ．フレームワーク間の通信
種々の下層ネットワークのためのＯＳＡフレームワークは、相手のことを互いに知っており、アプリケーションの役に立つために協調する。異なるフレームワーク間でどのようなＳＣＦを提供するかは事前に決められる。更に、以下の機能がＯＳＡフレームワークに含められる。
【００６４】
フレームワーク間の認証
不正使用や攻撃を防ぐために、フレームワーク間での更なる動作を許可する前にフレームワークで強力な相互認証手続きを行うことが好ましい。この認証手続きは、当技術分野で知られている任意のものでよい。
【００６５】
フレームワーク間のサービストレーディング
本発明のこの実施形態では、各フレームワークがインターフェースで拡張され、これにより他のフレームワークが当該フレームワークが提供するＳＣＦについての情報を要求できるようにしている。従って、インターフェースは以下のＳＣＦ要求メソッドを含んでいる。
【００６６】
SCFrequest（＜requestingFrameworkID＞,＜ListOfSCFoffered＞）
＜requestingFrameworkID＞は、要求側フレームワークの識別情報であり、
＜ListOfSCFoffered＞は、要求側フレームワークに提供されるＳＣＦのリストである。このリストは、要求側フレームワークによって異なる。
提供されたＳＣＦのリストを受信すると、要求側ＯＳＡフレームワークは、「ローカル」登録ＳＣＦと同様に、提供されたＳＣＦのリストを保存する。このようにして、要求側ＯＳＡフレームワークは、要求しているアプリケーションにリストを提示できる。また、要求側ＯＳＡフレームワークは、どのＯＳＡフレームワークがどのＳＣＦを有しているかについての情報を保存している。
【００６７】
フレームワーク間のサービス利用
各フレームワークがインターフェースで拡張され、これにより他のフレームワークが当該フレームワークのＳＣＦを利用できるようにしている。インターフェースは以下のメソッドを含んでいる。
【００６８】
getSCFinstance（＜serviceID＞,＜serviceProperties＞,＜reference＞,＜frameworkID＞,
＜applicationID＞)
＜serviceID＞は、要求しているＳＣＦのＩＤ、
＜serviceProperties＞は、要求しているフレームワークに属しているアプリケーションによって特定されたプロパティのリスト、
＜reference＞は、ＳＣＦインスタンスのリファレンス、
＜frameworkID＞は、要求しているフレームワークのＩＤ、
＜applicationID＞は、要求しているアプリケーションのＩＤである。
このメソッドにより、ＯＳＡフレームワークは、他のフレームワークに対して、そのアプリケーションによって依頼されたサービスプロパティに従って、ＳＣＦインスタンスのリファレンスを返すことができる。そのようなインスタンスが存在しない場合、フレームワークはインスタンスを作る。ＯＳＡフレームワークは、受信したリファレンスを各ＯＳＡフレームワークに保存しなければならない。ＯＳＡフレームワークは、ＳＣＦインスタンスのリファレンスとそれらの対応するフレームワークのリストを有していなければならない。上述したインターフェースを用いたＯＳＡフレームワーク間の通信が図１４に示されている。
【００６９】
Ｂ．端末ＩＤアドミニストレータ
端末ＩＤが与えられた場合、アプリケーションは、どのＳＣＦインスタンスを使用すべきかを知る必要がある。何故なら、端末は異なるネットワークに属することがあり、従って異なるＳＣＦインスタンスによって取り扱われる可能性があるからである。ここでも、アプリケーションは、フレームワークの支援を必要とする。本実施形態では、各フレームワークに、ＳＣＦとして実施された端末ＩＤアドミニストレータ（ＴＡ）が設けられている。このＴＡ  ＳＣＦは実施形態１で記載したものと同様である。更に、ＴＡ  ＳＣＦには、各ＯＳＡフレームワークがサポートする端末ＩＤの範囲が供給される。（端末ＩＤは、例えば、電話番号、ＩＰアドレス、又は名前である。）これらは、ＴＡ間での情報交換を可能するか、又は共通の情報データベースを設けることにより、オフラインインストレーションなどの幾つかの方法で供給できる。
【００７０】
例
アプリケーションが、端末ＩＤ、例えば電話番号１２３４５６７８のユーザステータスを得ることを望んでいる。アプリケーションは、＜terminalID＞=12345678 とＳＣＦの名称＜SCFtype＞="User Status" を含む問い合わせをＯＳＡフレームワークに送出する。ＯＳＡフレームワークはその要求を端末ＩＤアドミニストレータＳＣＦに送る。端末ＩＤがそのフレームワーク中に存在していた場合、アプリケーションは所望のＳＣＦを選択して使用する。要求された端末ＩＤがＯＳＡでサポートされる範囲に入っていない場合、ＯＳＡフレームワークは、ＳＣＦインスタンスのリファレンス及びそれらの対応するフレームワークのフレームワークリストに従って、別のフレームワークを要求する。
【００７１】
本発明の好適な実施形態について記載したが、本発明の概念を含む他の実施形態も使用可能であることは当業者には明らかであろう。本発明の上記及びその他の実施例は例示を目的とするものであって、本発明の実際の範囲は添付の請求の範囲から決定すべきものである。
【図面の簡単な説明】
【００７２】
【図１】ＯＳＡを介してアプリケーションが移動通信ネットワークにアクセスする現在のアーキテクチャを左側に示し、本発明の実施形態による不均質ネットワークのための拡張されたＯＳＡを右側に示す。
【図２】共用のフレームワークを使用しているが各ネットワークが独自のＳＣＦを有している、本発明の第１実施形態による不均質ネットワークのための拡張されたＯＳＡを示す。
【図３】本発明の第１実施形態におけるＴＡによって保持されている関係を示す。
【図４】本発明の第１実施形態における端末ＩＤアドミニストレータの幾つかのプロパティを示す。
【図５】本発明の第１実施形態における端末アドミニストレータＳＣＦの使用を示す。
【図６】全ての下層ネットワークを受け入れる共用ＳＣＦと共用フレームワークを使用しての本発明の実施を示す図である。
【図７】本発明の更なる実施形態によるＳＣＦの使用を示す。
【図８】本発明の第２の実施形態の実施の例を示す。
【図９】本発明の第２の実施形態によるＯＳＡ内のディスパッチャ機能の図である。
【図１０】本発明の第２の実施形態による端末ＩＤアドミニストレータによって保持される関係を示す。
【図１１】下層ネットワーク毎に一つのフレームワークを使用した本発明の第３の実施形態を示す。
【図１２】本発明の第４の実施形態によるフレームワーク間における通信と協調を示す。
【図１３】図１２に示す実施形態による、ＧＳＭネットワークとＩＰベースネットワークの両方におけるＵＳ  ＳＣＦの使用を示す。
【図１４】本発明の第４の実施形態によるＯＳＡフレームワーク通信インターフェースを介してのフレームワーク間における通信を示す。
【図１】
2004535141.tif 000003
【図２】
2004535141.tif 000004
【図３】
2004535141.tif 000005
【図４】
2004535141.tif 000006
【図５】
2004535141.tif 000007
【図６】
2004535141.tif 000008
【図７】
2004535141.tif 000009
【図８】
2004535141.tif 000010
【図９】
2004535141.tif 000011
【図１０】
2004535141.tif 000012
【図１１】
2004535141.tif 000013
【図１２】
2004535141.tif 000014
【図１３】
2004535141.tif 000015
【図１４】
2004535141.tif 000016
【国際公開パンフレット】
2004535141.tif 000017
2004535141.tif 000018
2004535141.tif 000019
2004535141.tif 000020
2004535141.tif 000021
2004535141.tif 000022
2004535141.tif 000023
2004535141.tif 000024
2004535141.tif 000025
2004535141.tif 000026
2004535141.tif 000027
2004535141.tif 000028
2004535141.tif 000029
2004535141.tif 000030
2004535141.tif 000031
2004535141.tif 000032
2004535141.tif 000033
2004535141.tif 000034
2004535141.tif 000035
2004535141.tif 000036
2004535141.tif 000037
2004535141.tif 000038
2004535141.tif 000039
2004535141.tif 000040
2004535141.tif 000041
2004535141.tif 000042
2004535141.tif 000043
2004535141.tif 000044
2004535141.tif 000045
2004535141.tif 000046
2004535141.tif 000047
2004535141.tif 000048
2004535141.tif 000049
2004535141.tif 000050
2004535141.tif 000051
2004535141.tif 000052
2004535141.tif 000053
2004535141.tif 000054
2004535141.tif 000055
2004535141.tif 000056
【国際調査報告】
2004535141.tif 000057
2004535141.tif 000058