JPH09512970A - 通信ネットワーク用サービス作成装置 - Google Patents

Abstract

(57)【要約】 インテリジェント・ネットワーク型の通信ネットワーク用のサービス作成システムは、各レベルでサービス作成作業が実行できる、ＳＣＥ１、ＳＣＥ２、ＳＣＥ３という三つの異なるレベルを持っている。分離されたレベルの使用により、ネットワーク内の異なる関心をもつユーザのために機能的に分離して保存されているサービス作成システムへのアクセスが可能となる。したがって、選択されたサービスを利用可能とするためにネットワーク・エレメント・レベルでインストールしなくてはならないフィーチャーは、ＳＣＥ１で作成することができる。フィーチャーがその呼出し処理論理をそのフィーチャーのサポートと管理の説明書と一緒にカプセル化しているフィーチャーの概要を与える市場性のあるサービス・フィーチャーは、ＳＣＥ２で作成することができる。市場性のあるサービス・フィーチャーの集まりがサービス固有のサポートと管理の説明書と一緒にサービスの要件を満足させるということを可能にするサービス・パッケージは、ＳＣＥ２またはＳＣＥ３のどちらかで作成できる。ユーザのためにサービスに関連するフィーチャーをリストアップし、また各フィーチャーに必要なデータのためのデータ・スロットを用意しているプロファイルは、ＳＣＥ３内で供給され修正されることが可能である。

Description

【発明の詳細な説明】 通信ネットワーク用サービス作成装置 本発明は、通信ネットワーク用サービス作成装置に係わり、インテリジェント ・ネットワークにおいて特定のアプリケーションを見付け出すものである。 通信ネットワークの発展に伴い、ネットワーク事業者が配備しうるサービスの 数と種類は大幅に増加している。ネットワーク事業者が新しいサービスを素早く 効率的に作成して配備しうることが商業上の基本問題になっている。過去の場合 のように、インテリジェント機能が主として交換機上に用意されるのではなく、 通信ネットワーク内の種々の点あるいは通信ネットワークに関連する種々の点で 用意されるアーキテクチャのインテリジェント・ネットワーク形式は、少なくと も部分的には開発されてきており、新しいサービスにスピードと柔軟性を与える ための利便手段をネットワーク事業者に提供するに至っている。 インテリジェント・ネットワーク（ＩＮ）における基本原理は、呼の進行を制 御するソフトウエアから交換経路の設定といった基本的な交換機能を制御するソ フトウエアを分離することである。図２３を参照すれば、こういったことは、ネ ットワーク交換機２３０が呼の進行の修正を必要とする呼を認識し、また通常の 呼処理を中断できるようにすることによって、公知のＩＮ内で達成されてきた。 呼処理を中断する決定は、その呼の期間中にある地点での、例えばダイアル数字 、回線状態あるいは一日の時間といった、事前設定された誘因基準の一致に基づ いている。これは、ネットワーク交換機２３０に備えられている「サービス交換 点（ＳＳＰ）」機能として説明できる。 あるＩＮベースのサービスを必要とする呼を認識すると、ＳＳＰ機能はサービ ス制御点（ＳＣＰ）２３１を参照し、その後、呼の進行は基本ネットワーク交換 機２３０以外のインテリジェント機能によって制御され、その呼が必要とするサ ービスを何でも提供する。 サービスの提供と修正に特に関係するインテリジェント・ネットワーク・アー キテクチャーの一面は、当該サービスの作成・配備システムである。新しいサー ビスの作成を加速するための、ＩＮ内で特に魅力的な特性は次の通りである。 i ． 機能分離：これは、前述のように顧客とサービスに固有の局面がもっと容 易に変更できるように、リアルタイムの呼交換という基本的で核となる機能を顧 客とサービスに固有の機能から分離することである。 ii． 移植可能なソフトウエア環境：一旦開発されたサービスがその後、異なる 提供業者によって提供されるＳＣＰ２３１上でも実行可能にすることである。 iii ． 一般的ビルディングブロック方式：共通のモジュールからサービスを構 築することにより、かなりの再利用を可能にし、それにより開発のスピードアッ プが可能となる。 iv． サービス論理プログラム（ＳＬＰ）：ビルディングブロック間のリンクを 指定するための簡易言語。ＳＬＰは通常、サービス作成ツールによって作成され る。 v ． グラフィカルなサービス作成ツール：これらのツールは、一般的ビルディ ングブロックを表すアイコンの「オン・スクリーン」操作によってサービスが迅 速に作成できるようにする。 vi． サービスとネットワークのシミュレータ：あるサービスが作成された場合 、これによりそのサービスの機能や性能、コストなどのチェックのシミュレーシ ョンができる。 vii ．オンライン配備：あるサービスの配備の用意ができたら、サービス作成ツ ールからネットワークと適当な管理システムにそのサービスを電子的に送付する ことができる。 サービスは、公知のタイプのサービス作成環境２３２の中で、これらブロック の順序とブロック間のなんらかの条件付きリンケージとを指定することによって 、一般的ビルディングブロックから作成される。この指定はしばしばスクリプト またはサービス論理プログラム（ＳＬＰ）として知られており、また通常、サー ビス作成ツールによって生成される。このＳＬＰがネットワーク内に配備された 場合、「実行される」ことが必要である。これは、しばしばＳＣＰ２３１に入っ ているサービス論理実行環境（ＳＬＥＥ）内で行われる。この実行そのものを行 うモジュールは、多くのＩＮ実現の際にそれらのＳＬＰ用に翻訳された言語を使 うことからサービス論理インタプリタ（ＳＬＩ）と呼ばれることが多い。その代 わ りにこれは、例えばサービス・エンジンと呼ぶこともでき、このサービス・エン ジンは更に明らかに、解釈された形式、翻訳された形式、その他の形式のＳＬＰ をサポートする柔軟性を提供することができる。 サービス作成ツール自身と共に、再利用可能な一般的ビルディングブロックの 使用はサービス作成において極めて重要である。一般的なコンピューティングの 世界では利益が膨大であるという理由から、重要なソフトウエアの再利用を達成 しようとする試みに多くの仕事が行われてきた。例えばプログラムを効果的に３ 回再利用すれば、生産性は３倍になり、さらに２回目以降の利用ではリードタイ ムを事実上ゼロにできる。 これらの利益にもかかわらず一般的なソフトウエアの再利用は、実現困難とい う理由でまだ稀である。しかしながら基礎となるネットワークの個別の運用が十 分に理解されているＳＣＰのかなりクローズされたドメインの範囲内では、これ らの基礎的な運用を推進するために一般的な個別ソフトウエアを構築することは 可能である。これらは、種々の分野のＩＮサービスを提供するために多くの異な る順序で集めることのできるビルディングブロックである。 典型的なビルディングブロックは、「時間帯経路選択」であるかもしれない。 このビルディングブロックは、ある特定の番号への午後６時以降の呼は夜警電話 に切り換えられるということを明言し得るユーザ・プロファイル内のデータをチ ェックする。それからこの「時間帯経路選択」ビルディングブロックは、現在時 刻をチェックして呼を適切に経路指定する。 ＳＬＰは、サービス管理システム（ＳＭＳ）２３３経由でＳＬＥＥに引き渡す ことができる。これは一般的に、サービスの管理と配備、顧客へのサービス供給 、およびＳＣＰ２３１とサービス・データ・ポイント（ＳＤＰ）２３４上に保存 されている顧客固有のデータの更新という役割を持っている。 ネットワーク・サービスの提供業者ばかりでなく、加入者やユーザ自身でもサ ービスの作成が実行できるということは便利である。異なるエンティティがサー ビスを開発したり修正したりするのを可能にするサービス作成技術は、AT&T Tec hnical Journal Volume 70，Summer 1991，No.3/4，New York US（米国ニューヨ ーク、ＡＴ＆Ｔテクニカルジャーナル第７０巻、１９９１年夏第３／４号）に発 表されたＭＪモルガン等による出版物"Service Creation Technologies for the Intelligent Network"（「インテリジェントネットワークのためのサービス作 成技術」）に記載されている。 本発明の実施例では、インテリジェント・ネットワーク型の通信ネットワーク のためのサービス作成システムが示されており、このシステムは、各レベルでサ ービス作成作業が実行できる３つの異なるレベルを持っている。 これらのレベルは、例えばＳＣＥ１，ＳＣＥ２，ＳＣＥ３と呼んでもよい。別 々のレベルを使用することにより、そのネットワーク内で異なる関心を持つユー ザのために機能的に分離して保存されるサービス作成システムへのアクセスが可 能になる。したがって選択されたサービスを利用可能にするためにネットワーク ・エレメント・レベルでインストールしなくてはならないフィーチャーは、ＳＣ Ｅ１で作成することができる。フィーチャーがその呼処理論理をフィーチャーの サポートと管理の説明書と一緒にカプセル化しているということにフィーチャー の概要を示している市場性のあるサービス・フィーチャーは、ＳＣＥ２で作成す ることができる。市場性のあるサービス・フィーチャーの集まりがサービス固有 のサポートと管理の説明書と一緒にサービスの要件を満足させるということを可 能にするサービス・パッケージは、ＳＣＥ２またはＳＣＥ３のどちらかで作成で きる。ユーザのためにサービスに関連するフィーチャーをリストアップし、また 各フィーチャーに必要なデータのためのデータ・スロットを用意しているプロフ ァイルは、ＳＣＥ３内で供給され修正されることが可能である。 したがって本発明の好適な実施例においては、各々のレベルは、それぞれ異な るタイプのソフトウエア・エンティティを生成する手段を備えており、前記レベ ルの第１のレベルは、サービス配付システムによってネットワークのエレメント 内に配備することのできるコード・オブジェクトを含むサービス・アプリケーシ ョン・フィーチャーを生成する手段を持っており、また前記レベルの第２のレベ ルは、市場性のあるサービス・フィーチャーを生成する手段を持っており、これ らの市場性のあるサービス・フィーチャーはそのフィーチャーに関するサポート と管理の説明書と一緒にカプセル化されたサービス・アプリケーション・フィー チャーの呼処理論理を含んでいる。 これらのレベルの中の第２レベルは、市場性のあるサービス・フィーチャーを 識別して、その市場性のあるサービス・フィーチャーを通信ネットワークによっ て利用可能な特定のサービスに結び付けるという結合機能を有するソフトウエア ・エンティティであるサービス・パッケージを格納および出力する手段を持つこ ともできて便利である。 これらのレベルの中の第３のレベルは、サービス・パッケージを生成する手段 と、ユーザが前記ネットワークのサービスの選択に際して必要とする一つ以上の フィーチャーのリストを含むプロファイルを生成または修正する手段と、選択さ れたサービスの枠内でフィーチャーがうまく動作できるように各フィーチャーに 関連するデータを格納する手段とを持つこともある。 このタイプのマルチレベル・システムの更なる利点は、種々の制御機構を備え ることができるということである。例えばＳＣＥ３で操作しているユーザにとっ て利用可能な設備や機構などの制御をＳＣＥ２で実行することができる。 本発明の実施例によるサービス作成アーキテクチャーを、下記の添付図面を参 照しながら、例によってのみ、以下に説明する。 図１は、サービス作成アーキテクチャーの概略図を示す。 図２は、図１のアーキテクチャーに関連するサービス作成ドメインと処理の関 係を示す。 図３は、サービス配付インフラストラクチャーと、そのインフラストラクチャ ーと代表的なインテリジェント・ネットワーク・エレメント上の他のプラットフ ォーム・コンポーネントとの関係とを示す。 図４は、図１のアーキテクチャーで使われる概略図的なサービス作成データ・ アーキテクチャーを示す。 図５は、システム中のコンポーネントから、ある型のオブジェクト、市場性の あるサービスフィーチャーの構造を概略図的に示す。 図６は、ある特定のサービス用にユーザが持っているフィーチャーのユーザ関 連リストであるプロファイルの異なるプロファイル型を示す。 図７から図１８までは、ワーク列の例とそれらの関連するアーキテクチャー的 な動きを示す。 図１９から図２２までは、図１のサービス作成アーキテクチャーがサポートす るであろう特定のデータ配付シナリオを示す。 図２３は、ＩＮアーキテクチャーの公知の型の概略図を示す。 以下の説明では、エレメントや処理などの関連の完全な名称の代わりに沢山の 頭字語が使われる。これらは、次の用語集から解釈できる。 用語集 ＡＰＩ アプリケーション・プログラミング・インタフェース ＣＭ 構成管理 ＣＰＥ 顧客構内装置 ＧＳＣ 一般サービス・コンポーネント ＩＮ インテリジェント・ネットワーク ＩＶＲＵ 対話型音声応答装置 ＫＴＮ ネットワークへのキー ＭＳＦ 市場性のあるサービス・フィーチャー ＳＡＦ サービス・アプリケーション・フィーチャー ＳＡＰ 音声アプリケーション・プラットフォーム ＳＣＥ サービス作成環境 ＳＣＰ サービス制御点 ＳＤＳ サービス配付システム ＳＬＡ サービスレベル契約 ＳＬＥＥ サービス論理実行環境 ＳＭ サービス管理 ＳＮ サービス・ノード ＳＰ サービス・パッケージ １． 序論 １．１ 範囲 以下の説明の範囲は、インテリジェント・ネットワーク上でサービス作成要件 を配達し得るようにする論理アーキテクチャーを定義するサービス作成の分野を 取り扱う。 実用目的で構成されるいかなるサービス管理システムも、ここに述べるシステ ムよりは遥かに大きな範囲と責任を持つことになるであろうということに注目さ れたい。しかしながら、サービス管理システムは公知であって、本発明の目的と しては、サービス管理システムはここに記載のサービス作成アーキテクチャーと の互換性だけが必要とされる。したがって、あるサービス管理システム全体を完 全に正確に記述することが、ここでの目的ではない。 このサービス作成アーキテクチャーをサポートするデータ・アーキテクチャー は第５節で説明する。しかしながら、このデータ・アーキテクチャーの開発と特 定のインタフェース（３．１）の背後にある考え方は、データ配付の実現に関す る問題を提起する。これらの問題の議論は以下の説明の範囲内には、きれいに入 らない。その代わりこの議論は、第７節の「付録１」として添付した所を除いて その一部を構成する。 １．２ 用語法 本説明のために、顧客という用語はサービス機能の法人購入者を指す。ユーザ という用語は、顧客によって与えられたサービス機能を利用する顧客の個々の従 業員を指す。したがって一つの顧客は複数のユーザを持つ。 本説明のために、ＳＣＥ１，ＳＣＥ２，ＳＣＥ３という用語が一貫して使われ る。これらは、異なるアーキテクチャー・レベルでサービス作成機能を提供する 統合されたソフトウエア・ツールセットを記述するために使われる。 ＩＮエレメントという用語は、サービス制御点（ＳＣＰ）、サービス・ノード （ＳＮ）、インテリジェント・ペリフェラル（ＩＰ）といったインテリジェント ・ネットワーク・コンピューティング・プラットフォームを指す論理グループと して使われる。ＩＮアーキテクチャーの異なるタイプで使われるコンピューティ ング・プラットフォーム、例えば恐らく、ＳＣＰ上のＩＮにおけるよりも集中度 の少ないインテリジェンスを有するプラットフォームもまた「ＩＮエレメント」 という用語に含まれるということを理解されたい。 １．３ 目的 本説明の目的は、 ・サービス作成アーキテクチャー全体を定義すること ・それに続いて物理システムによって与えられる論理システム設計のハイレベル な概観を指定すること ・サービス作成エンティティ（例えば市場性のあるサービス・フィーチャー、一 般的サービス・コンポーネントなど）を識別し、説明すること ・インタフェースを識別すること ・ワーク・パッケージとアプリケーション・エンティティとを識別すること ・サービス作成を大規模公共ネットワークに移植するためのサービス作成用基本 アーキテクチャーを定義すること である。 ２． サービス作成アーキテクチャーの概要 ２．１ 概要説明 サービス作成アーキテクチャーの概要は、新しいサービスとフィーチャーが自 動化された処理とインタフェースとを使って迅速に配備・供給されるように、既 存のあるいは提案のエンティティ間に存在すると理解されている関係によって定 義される。これらの関係を説明するためには、図１を参照しながらサービス作成 処理を説明することが必要である。 サービス・アプリケーションと再利用可能なフィーチャーは、テスト済みのコ ードとしてＳＣＥ１ ２３２で開発される。このコードは、目標とするＩＮエレ メント（ＳＣＰ２３１、ＳＮ、ＩＰ２３５等）にこのコードを格納・配備する（ インタフェースＩ５経由）リポジトリーとしてのサービス配付システム（ＳＤＳ ）１００に（インタフェースＩ１経由で）配達される。 ＳＣＥ２ ２３２は、ＳＤＳリポジトリー（インタフェースＩ２経由）１００ を使って市場性のあるサービス・フィーチャー（第５．２項参照）とサービス・ パッケージ（第５．３項参照）を構築する。 サービス・パッケージは、サービス供給のために、サービス管理ドメイン２３ ３内のＳＤＳリポジトリ１００からサービス管理機能（ＳＭ）へ（インタフェー スＩ６経由で）およびＳＣＥ３へ（インタフェースＩ４経由で）配達される。 サービス・パッケージあるいはその一部は、新しいサービスのためにこれらを 構成するサポートシステムに（インタフェースＩ７経由で）配達される。 検査のためにＳＭ（インタフェースＩ３経由で）配達されるプロファイル（第 ５．４項参照）はＳＣＥ３ ２３２を使って作成される。 検査済みプロファイルは、ＳＤＳ１００に（インタフェースＩ６経由で）渡さ れ、関連するＩＮエレメントに（インタフェースＩ５経由で）配付される。 インタフェースＩ４はまた、無効とされたプロファイルの更新をサポートする ためにも必要である。これらの更新は、ネットワーク側の更新として更に一般的 に知られている。しかしながらこのアーキテクチャーの下では、いかなる形式の プロファイル更新もＳＣＥ３から出るということを強調しておくべきである。こ のようにして、ＩＮエレメント上または顧客構内装置（ＣＰＥ）内のあるサービ ス内に存在する更新機能はいずれもＳＣＥ３機能として認識される（「２．２ 制約事項ｂ）」を参照、下記）。 ２．２ 制約事項 ａ）ネットワーク事業者のサービス管理システム２３３は、別個のプラットフォ ームとしてかあるいは一連のプラットフォームに亘ってかのどちらかで存在する 。 ｂ）ＳＣＥ３は、サービス管理システム２３３に直接インタフェースする別個の 物理システムまたは、サービス管理システム２３３の一部として併置された物理 システムとしての機能、あるいはネットワーク側の更新をサポートするネットワ ーク・エレメント内の機能としてのどちらかの機能の供給を表わす。大規模ネッ トワークは恐らくＳＣＥ３がこれらすべての機能であることを必要とする。ＳＣ Ｅ３ユーザは通常、ネットワーク事業者のサポート要員と顧客とユーザとからな る。 ｃ）ＳＤＳ（第４．４．２項参照）は、恐らくは配付されてサービス管理システ ム２３３の一部となっているか、あるいは個別のプラットフォームを必要とする リポジトリーおよび配付システムを表す。これは、目標とするネットワークの大 きさとそのネットワーク実現に関連する性能・コスト要件に依存する。 ｄ）ＩＮエレメントは、サービス制御点（ＳＣＰ）２３１とか、サービス・ノー ド（ＳＮ）（図示せず）とか、サービス・アプリケーションとそれに関連の顧客 データストアとをサポートできるインテリジェント・ペリフェラル（ＩＰ）２３ ５といったネットワークベースのコンピューティング設備からなる。 ｅ）インタフェースと管理システムは、一般システムに亘って完全に自動化され たサービス配備とサービス供給とを行なう。これをベースにサービス作成アーキ テクチャー設計とそれに続くワーク列の分析とが進行する。 ３．サービス作成アーキテクチャー 図２は、サービス作成アーキテクチャーの更に詳細な表現を示す。この図は、 主要な（Ｐ．９）機能範囲と音声ベースのサービスの開発に係わる主なサブシス テムの位置づけとの間の関係を示している。方向の矢印を持ったインタフェース は、図１に示し、第３．１節にリストアップしたインタフェースに対応している （インタフェースＩ７を除く）。ドメイン内の処理の間の接続線は、ソフトウエ ア・エンティティ間の統合の形を表している。これは、インタフェース、ファイ ル転送、処理間通信、あるいはアプリケーション統合（内部データ共有）といっ た形をとるであろう。 このアーキテクチャーは、システムよりもむしろドメインと処理によって表さ れる。サービス作成ドメイン２３２は５個の論理ドメインに細分されているが、 これらのドメイン内に常駐する処理は一連のプラットフォームと環境とに亘って 動作する。 これら３個のＳＣＥドメインは論理的に分離されていて、満足しなくてはなら ない用法とユーザとの異なる要件とタイプとを区別する。これらは、次のように 類別される。 ３．１ インタフェース ４． ドメインの説明 ４．１ ＳＣＥ１ドメイン ＳＣＥ１は、サービス作成作業の基本層を表す。ＳＣＥ１の開発者は、これら のアプリケーションが配備されるＩＮエレメント上およびサービス配付インフラ ストラクチャー上でのサービス・アプリケーションの開発に責任を持っている。 サービス・アプリケーションは、再利用可能なサービス・アプリケーション・フ ィーチャーの形で配達される。これらは、十分に開発され、テストされたコード からなる。ＳＣＥ１は、コードをネットワーク内に展開するアーキテクチャー内 の唯一の場所である。 ４．１．１ 市販ソフトウエア開発環境 このシステムは、開発のライフサイクルをサポートするソフトウエア・ツール を統合してひとまとめにしたものである。これらのツールは主として、商業的に 利用可能なエディター、コンパイラー、構成管理システム、分析、設計、テスト 、文書作成などのツールである。これらは、一般に従来のコンピュータ援用ソフ トウエア・エンジニアリング（ＣＡＳＥ）ツールに基づいている。これらの開発 環境の中の幾つかは、特定のＩＮエレメント上での開発をサポートする業者によ って提供される。少なくともＳＣＥ１は動的配備をサポートするために、一まと めの配備／テストのツールを備えなければならない。 実際のビルディングブロックを目標システムにダウンロードすることに加え、 ＳＣＥ１ツールは、このビルディングブロックの表示記号もＳＣＥ２に渡さなく てはならない。この表示記号は、以下のものを含む。 ・情報用およびヘルプテキスト用としての、ブロックの文章的記述。 ・概略図的に機能を表すオン・スクリーン表現すなわちアイコン。 ・他のビルディングブロックとの対話を管理するルール。 ・ビルディングブロックに関連するデータ。これらは、最終的にある特定の顧客 に供給される必要がある。 ４．１．２ 音声アプリケーション・ツール 音声ベースの対話フィーチャーとサービスの構築をサポートするソフトウエア 開発ツール。これらのツールは一般に、ＩＮエレメントとして予期される目標プ ラットフォームに固有のものであって、プラットフォームと一緒に購入してもよ く、あるいは特定のプラットフォームをサポートするために社内で開発してもよ い。 ４．１．３ マルチメディア・ツールマルチメディア・サービスの供給をサポー トするためには、画像とビデオと特定のファックスの機能をサポートするサービ スが要求され、結果としてこれらをサポートするために適当なサービス作成ツー ルとユーティリティが必要となることは明らかである。 ４．２ ＳＣＥ２ドメイン ＳＣＥ２は、マーケティング、テスト、パッケージング作業として定義できる 。ＳＣＥ２内で行われる作業の特定の範囲は修正できるが、これらは明らかにサ ービス作成処理をサポートする必要がある。 ＳＣＥ２におけるツールは、製品ラインの開発者またはその代理業者によって 使われ、全体的に下記の機能が必要となろう。 ・ 画面上でアイコンをドラッグ・アンド・ドロップし、それらのアイコンをリ ンクすることにより、基本サービスを組み立てる。 ・ どれだけ多くのサービス・フローがＳＣＥ３レベルで、すなわち顧客によっ て変更できるかを定義する。それから残りのサービスはすべての顧客のために効 果的に固定される。 ・ 省略値を有するサービスに関連するデータの一部を事前設定し、これらの中 のどれを顧客が重ね書きしてよいかを再定義する。 ４．２．１ 要件サポート・ツールセット マーケティング要件の捕捉を自動化してそれらをサービス定義に反映させるこ とが望ましい。これにより開発のライフサイクル全体に亘って更に効率的な再利 用が可能になる。ＳＣＥ２は、自動化ツールを使ってその要件捕捉作業をサポー トする。 ４．２．２ パッケージングと可視化のツール サービス・アプリケーション・フィーチャーが、動作中のネットワークでのフ ィーチャーの供給と使用をサポートするために必要な、サービス管理やネットワ ーク管理やＳＤＳと課金などのコンポーネントを含む市場性のあるサービス・フ ィーチャー（第５．２節参照）と結び付けられるのは、ＳＣＥ２のところである 。ＭＳＦが作成されるのもＳＣＥ２のところである。市場性のあるサービス・フ ィーチャーはまた、サービス・パッケージにパッケージされる。ＳＣＥ２は、サ ービス・パッケージ内にカプセル化されたＭＳＦ上でＳＭ用およびＳＣＥ３用の 供給画面を作成あるいは定義することと、サービスレベル契約によって指定され た使用特性／課金特性を識別することと、フィーチャーの対話機能を解決するＳ ＣＥ３用のフィーチャー・エディター・ルールを具備することとができなければ ならない。この点に関して、ＳＣＥ２で作成されたサービス・パッケージはそれ らを使うＳＣＥ３処理の構成をコントロールするということに注目されたい。 ４．２．３ シミュレーションと分析 ＳＣＥ２で作成されたサービス・パッケージは、このレベルで作成されたサー ビスの顧客の容認とネットワークへのインパクトと経済的実現可能性とを決定す るために、挙動特性と通信量ローディングと性能予測と収入予測とができるよう にシミュレーションができなければならない。 ４．２．４ ダイアログ作成機能 ＳＣＥ２ユーザは、サービス・パッケージに包含させるためのサービスあるい は顧客固有のダイアログとアナウンス文を作成できなくてはならない。これらは 、ＭＳＦ内の再利用可能なアナウンス文／ダイアログのサービスレベルでの供給 によって作成される。これらのダイアログ作成ツールは、一連の入力機構（アナ ログとディジタル）と種々の格納フォーマット（ＩＮエレメント固有の）とをサ ポートできなくてはならない。またこれらのツールには、再利用可能な断片から 音声アナウンス文を作成するための巧妙な編集機能と信号処理機能とをサポート することが必要となることもある。 ４．２．５ ＳＣＥ２データストア 進行中の作業を保持するためのローカルなデータストア。ＳＡＦとＭＳＦとサ ービス・パッケージとに関するすべてのマスター・データは、ＳＤＳデータスト ア内に保持されており（下記参照）、ＳＣＥ２ユーザによって検索される。 ４．３ ＳＣＥ３ドメイン ＳＣＥ３の働きは、サービス供給とテーラリングに直接関係している。ＳＣＥ ３でのサービス供給には、動作特性供給とデータ供給という二つの異なるタイプ がある。動作特性供給は、サービスの論理操作に変化をもたらすような仕方にお けるサービスデータの操作である。データ供給は、通常サービス管理システムに よって管理される古典的に認められているタイプのデータ供給であり、それによ って特定のフィーチャーおよび／またはユーザに関連するデータが直接変更でき 、またネットワークが適当に更新できる。 したがってＳＣＥ３にあるツールは、直接的に顧客によってか、特定の顧客の ために働くネットワーク事業者によってか、あるいは顧客グループのために働く マーケティング要員によって使われる。これら種々のシナリオをサポートするた めに、ＳＣＥ３機能は、パソコン（ＰＣ）から精巧なＵＮＩＸワークステーショ ンに至るまでの一連のハードウエアに具備させることができる。 ＳＣＥ３経由でサポートされる一般的な機能は、次の通りである。 ・ サービスのテーラリング：ＳＣＥ２で設定されている制約事項の範囲内でユ ーザは、サービスの特定のバージョンのフローまたは構成を変更してもよい。 ・ サービスデータの一部に顧客固有の値を与える。 ４．３．１ プロファイル・エディター 顧客には、与えられるときには、動作が保証されている完全で十分に特徴付け られたサービスを与える最小のプロファイルを表すサービス・テンプレートを含 むサービス・パッケージが提供される。顧客は、かれらのユーザの必要に応じて このマスター・テンプレートからサブテンプレートの階層を作成することができ る。提供されたツールによって顧客は、ＳＣＥ２で指定されたフィーチャー・エ ディター・ルールによって設定された制約事項の範囲内で、どのユーザグループ がどのフィーチャーへのアクセスを持っているか、またそれらのフィーチャーが どの様にして対話動作を行うかを指定することができる（上記参照）。プロファ イル・エディターによってＳＣＥ３ユーザは、あるサービス内でのそれらのフィ ーチャーの論理的順序づけを見ることができ、後述する制約事項の下でその順序 をグラフィカルに修正することができる。顧客は、特定のプロファイルとそれか らフィーチャー・セットとを作成して個々のユーザに割り当てることができる。 ４．３．２ シミュレータ プロファイル・エディターのサポートは、顧客が彼らのサービスのフローを見 たりそれらの動作を確認したりするのを可能にするシミュレーション・ツールセ ットである。顧客は、彼らの論理的には正しいサービスが要求通りに動作するか どうかの評価を可能にする一連の呼処理シナリオをグラフィカルにシミュレート する機会を有する。 ４．３．３ 供給ツール 顧客は、彼らが開発したテンプレートに基づいて各個別ユーザにプロファイル を供給することができる。各ユーザはそのユーザレベルで、直接にかあるいは顧 客またはサービス提供業者から与えられるリモート・サポートの形でかどちらか によって自分自身のプロファイルへのアクセスをもつことになる。これは、サー ビス提供業者（ネットワーク保護問題に関して）あるいは顧客（彼らが選択する 何らかの理由に関して）のどちらかによって指定されたアクセス許可およびアク セス権によってのみ制約される彼らのプロファイルの更新を可能にする適当な供 給画面を表示する自分自身のフィーチャーの集まりを概観することとなろう。 ４．３．４ アナウンス文のテーラリング（注文仕立て） 供給ツールと共同して動作するアナウンス文テーラリング・ツールは、これを サポートするフィーチャーまたはサービスにおけるアナウンス文のあるレベルの ローカルな個人化を提供するために使うことができる。例としては音声メニュー ・フィーチャーに関する法人向けまたは部門向けアナウンス文または個人向け呼 完了サービスに関する個人化されたメッセージ（ボイス・メールなど）の選択が ある。これらのツールは、何組かの事前定義されたメッセージについての選択シ ステムとして動作することもでき、あるいは対話型の音声アプリケーション・プ ラットフォームといった専用のネットワーク・プラットフォームに配備するため に音声のローカルでの録音を可能にすることもある。 ４．３．５ ＳＣＥ３データストア ローカルの永続的記憶装置。サービス・パッケージを受け取るとすぐＳＣＥ３ を受け入れて構成する。テンプレート階層と不完全プロファイルとのローカルな 格納のために使われる。現行プロファイルの顧客側ローカル・ストアにも責任を 負っている（第７章の付録１参照）。 ４．４ サービス管理ドメイン ４．４．１ サービス管理システム このアーキテクチャーではサービス管理システムは、プロファイルの供給とテ ーラリング以外の分野での顧客サービスの管理とサポートが要求される。サービ ス管理システムは、注文処理、サービスレベル契約の施行、およびサービス管理 （サービスを利用可能にし、中断し、そして引き上げる）を担っている。更にサ ポートシステムへの論理インタフェース（インタフェース１７）は、障害管理、 課金動作、価格設定、ネットワーク管理、エレメント管理、データ配付などがこ のシステムによって可視化され、構成され、制御されるように、サービス管理シ ステム経由で操作してもよい。 ４．４．２ サービス配付システム サービス配付システム（ＳＤＳ）１００は、サービス作成リポジトリーとして 機能する。これは、ＳＣＥ１から渡されたすべてのコードを格納して管理し、そ れをインストールと配備のために適当なＩＮエレメントに配付する。このシステ ムは、市場性のあるサービス・フィーチャー（ＭＳＦ）がこれらのおよびその他 のビルディングブロックから開発できるように、ネットワーク機能情報を（ＳＡ Ｆ／ＧＳＣの形で）ＳＣＥ２にとって利用可能にする。ＳＤＳはまた、これらの ＭＳＦとこれらから作成されたサービスとのためのリポジトリーとしても機能す る。これは、ＳＣＥ２の異なる事例が先に開発されたコンポーネントとこの短縮 された開発期間とに関して最大の再利用能力を持つであろうことを保証する。 データ配付機能としてＳＤＳは、ネットワークの位相幾何学的構造と、サービ ス管理またはネットワーク管理といった運用システムによって指定された顧客分 散構成とにしたがってプロファイルをＩＮエレメントに引き渡す。ＳＤＳにとっ て利用可能な構成データは、物理ネットワークから論理サービス・ネットワーク を切り離す。このようにして、サービス管理システム上での大がかりな更新もデ ータの再供給も必要とせずに、追加のネットワークの交換機能または制御機能を 導入することができる。 ＳＤＳは、ＳＣＥ３システムがデータ配付のためにＩＮエレメントとして登録 できるようにネットワーク側の更新をサービスする際の基本的役割を担う。この 結果、ネットワーク側の更新はどのＩＮエレメントにも適用できて、ＳＤＳはす べての従属システムが確実にプロファイル更新を受け取るようにしている。これ によって開発者は、ネットワーク上の共通のインタフェースにデータを渡すこと ができるようになる。このアーキテクチャー的な決定の結果、ＳＣＥ３の顧客は 、プロファイルを更新することができるか、あるいは彼らの常駐プロファイル・ データをネットワークから更新してもらうことができるようになる。これは、サ ービス・アプリケーションがＣＰＥ（顧客構内装置）からネットワーク側の更新 機能を要求した場合はいつでも、ＳＣＥ３機能を有するＩＮエレメントと解釈さ れる。 ＳＤＳは、それがサポートするＩＮエレメント用の静的なマスター・データス トアを維持する。このデータストアは、ＩＮエレメント内でデータの破壊または 消失が発生した場合にすべてのプロファイルが再構築または再供給可能であるよ うに十分なデータを持っている。 ４．４．３ ＳＤＳデータストア ＳＤＳデータストアは、ネットワークのマスタープロファイル・ストアを含む 永続的記憶アプリケーションである。さらにこのストアは、ネットワーク構成と 、ＩＮエレメントに関するデータおよびこれらのＩＮエレメントに亘る顧客分布 に関するデータとを含んでいる。すべてのプロファイル・データの更新はここで 管理され、そしてＳＤＳは変更事項を、下はＩＮエレメントにまで、上は従属Ｓ ＣＥ３データストアにまで配付する。サービス作成リポジトリーとしてのＳＤＳ データストアは、構成管理制御の下で、迅速なサービス作成機能とコンポーネン ト再利用機能とを備えるＳＣＥ２の事例からのアクセス用に利用可能な、ＳＣＥ ２からＳＣＥ１とすべてのＭＳＦとＳＰとによって配備されたすべてのコードを 含む。この配列は、データストア・アプリケーションとＳＤＳが常駐するプラッ トフォームとの両方に対して性能と大きさとに密接な関係を持っている。 ４．４．４ 構成管理 構成管理システムは、ＳＤＳデータストアのリポジトリー機能を管理するため に必要である。すべてのネットワーク配備されたコードと市場性のあるサービス ・フィーチャーとサービス・パッケージとのための中央リポジトリーとして、ネ ットワークを運用する人々ばかりでなくＳＣＥ１とＳＣＥ２にいるサービス作成 者達は、ロールバック・セキュリティのためだけの場合、配備されたサービスと フィーチャーのすべてのバージョンに対するアクセスを持っている。これは、サ ービスとフィーチャーが幾つかのソースから動的に配備されることになっている 場合に特に重要であり、またよく理解されたソフトウエア開発の最善の実施方法 を表す。 構成管理システムは恐らく、ＳＣＥドメイン（特にＳＣＥ１とＳＣＥ２）の中 に常駐していてローカルな「進行中の作業」の管理的な制御を維持し、また管理 を作り上げたり解放したりするということが認められる。しかしながらこれらの システムはネットワークのＣＭ制御の維持という負担を負うことは期待されてい ない。一旦コード、アプリケーション、サービス、フィーチャーなどが動作中の ネットワーク内に配備されると、それらは動作中のドメインの中に移動し、そし て論理的に分離している制御システムの下に入らなくてはならないということは 明らかである。 顧客データがＳＣＥ３とサービス管理システムからロールバックできるように 、プロファイルの版数管理制御を維持することがＳＤＳ構成管理システムの責任 であるということは自由選択である。代替え手段は、サービス管理システムがこ の機能を備えることである。 ４．５ ＩＮエレメント・ドメイン ４．５．１ サービス配達インフラストラクチャー サービス作成アーキテクチャーは、ＩＮエレメントが迅速なサービスの作成・ 配備作業をサポートする社内的な実現手段を持つという制約の下で、すなわち動 的なフィーチャー配備、プラットフォームからの独立性、フィーチャーの対話動 作の解決などのための適切な機能を提供するものがＩＮエレメント上に存在する という制約の下で設計されてきた。サービス配達インフラストラクチャー（ＳＤ Ｉ）は、これらの要件と迅速なサービス作成のための更に詳細な要件とを満足す る実現のためのデザインである。これはそれ自体、参考のためにここで述べてい るのであってアーキテクチャー的に従属したエンティティとしてではない。特定 のインテリジェント・ペリフェラルといったネットワーク・エンティティは、Ｓ ＤＩのホストにはなれないがこのアーキテクチャーの枠内でサービス作成作業を サポートしなくてはならない。 ＳＤＩは、ネットワークとサービス・アプリケーションの業者固有対話機能と をカプセル化したり分離したりするように設計されてきた。ＳＤＩは、サービス ・アプリケーションとフィーチャーが配備できるオブジェクト指向の枠組みを用 意する。サービス管理、ネットワーク管理、課金、障害管理、呼のモデルなどと いったインタフェースは、オブジェクト内にカプセル化されて、サービスをサポ ートするために存在し得るいずれの伝送・管理システムからもアプリケーション を分離している。ＳＤＩの目的は、下記のものの間の分離を明確に確立すること である。 ＊ 基礎となる物理ネットワーク、 ＊ 個別のサービス・ネットワーク、 ＊ 特定のサービス・ネットワーク内に構成するために利用可能なサービス、お よび ＊ 特定のサービスを構築するために利用可能なフィーチャーと一般機能。 サービスをインフラストラクチャーから分離する主な目的は、動的に拡張可能 な環境を用意して、他のサービスや環境の他の部分に影響を与えずに極めて短い 時間枠内でフィーチャーの豊富なサービスを導入できるようにすることである。 上述のようにＳＤＩは、英国通信株式会社（ＢＴ）の名義で国際特許出願番号 ＧＢ９５／００４２０とＧＢ９５／００４２１として特許出願中になっており、 これらの特許出願の開示は、使用可能なサービス配達インフラストラクチャーの 例として参考までにここに組み入れてある。 図３は、ＳＤＩ３００の形式と典型的なＩＮエレメント上の他のプラットフォ ーム・コンポーネントとの間の関係を表す。ＳＬＥＥのアプリケーション・プロ グラミング・インタフェース（ＡＰＩ）上の機能呼出しによって伝統的に操作さ れる外部システムに対するインタフェースは、これらのシステムのオブジェクト 表現３０１〜３０５にカプセル化されている。仮想交換機３０３は、一つ以上の 業者用交換機（ＳＳＰ）２３０のための呼出しモデルをカプセル化している。 サービスは通常、１顧客当たり一つのサービス・ネットワーク３０６の枠内で 配達される。各々のサービス・ネットワーク３０６は、サービスと仮想ネットワ ーク番号の顧客のダイアル方式を表す番号簿３０８とを区別するためのサービス ・ディレクトリー３０７を持っている。各々のサービス・ネットワーク３０６は 、サービス・アプリケーション・フィーチャーと一般サービス・コンポーネント とから作成された一連のサービスをサポートすることができる。新しいフィーチ ャーとプロファイルは、ＳＤＳ１００から動的に導入される。 ４．５．２ 音声応答アプリケーション 多くのアナウンス、対話、メッセージのサービスは専用のプラットフォームに よって提供されることが期待されている。これらのプラットフォームは、インテ リジェント・ペリフェラルとして主な呼出し制御プロセッサーと対話動作を行う 。ＳＤＩ内のアプリケーションは、複雑な音声ベースのサービスを供給するため にこれらのＩＰが提供する機能を使うことができる。ＳＤＩからの要求を満たす た めに、これらの機能を備えたアプリケーションが開発されるであろう。またこれ らのアプリケーションは、前述のすべてのレベルでサービスの作成と供給が可能 となるように設計されるであろう。音声応答アプリケーションが何らかの呼出し 制御機能を担うことは必要でない。 ５．サービス作成データ・アーキテクチャー 図４を参照すれば、サービス作成アーキテクチャーの基礎をなしているデータ ・アーキテクチャーは、三つのＳＣＥドメインを反映している。これは、サービ ス開発が配備に向かって進むにつれてますます複雑になる情報と論理をカプセル 化するために使われるオブジェクトの階層を備えている。 最下層４００は、サービス・アプリケーション・フィーチャー４０１と一般サ ービス・コンポーネント４０２の層である。これらは、サービス要件を満たして 一般サービス機能を使うように開発されたコード・オブジェクトである。これら は、ＳＣＥ１で開発される。一旦配備されるとこれらのオブジェクトは、ＳＣＥ ２で作成された市場性のあるサービス・フィーチャー４０３によって参照できる 。ＭＳＦ４０３は、サービスの一部として販売できるように、フィーチャーの呼 処理論理とそのフィーチャーの必要なサポートと管理の説明書との両方をカプセ ル化する。またＳＣＥ２で作成されるサービス・パッケージは、ある特定のサー ビスの要件全体を満たす一揃いのＭＳＦ４０３の集まりを可能にする。更にサー ビス・パッケージ４０４は、サービス固有のいかなるサポート・管理情報も含む ことになろう。最後に、サービス・パッケージ４０４は、少なくとも１個のサー ビス・テンプレートを含むであろうが、このテンプレートはそのサービスの操作 を説明し、またサービス操作の修正が生じうる制約事項を定義するものである。 これらのオブジェクトはすべて更に詳細に以下で説明する。 ５．１ サービス・アプリケーション・フィーチャー（ＳＡＦ）４０１ サービス・アプリケーション・フィーチャー（ＳＡＦ）４０１と一般サービス ・コンポーネント（ＧＳＣ）４０２との関係は、次のように説明できる。ＧＳＣ ４０２は、一連のサービスをサポートする一般機能を表す。ＳＡＦ４０１は、あ るフィーチャーとしてネットワーク内に配備される機能の一般名である。これは 通常、ＳＡＦは１個のＧＳＣであるかあるいは複数のＧＳＣから構成されるとい うことを意味する。しかしながら幾つかのサービスは、一般的とはいえない専用 化された機能を必要とすることもある。 ＳＡＦとＧＳＣの両者とも再利用可能となろうが、ＳＡＦすべてが一般的とはな らないであろう。 サービス・アプリケーション・フィーチャー（ＳＡＦ）４０１は、ＩＮエレメ ント上に配備される再利用可能なコード・オブジェクトである。サービス作成者 の観点から、これはサービス作成レベル１（ＳＣＥ１）の外側で認められる粒状 性の最低レベルを表している。これらのオブジェクトは、ＳＣＥ１で設計、開発 、そしてテストされる。またこれらのオブジェクトは、サービスの基本コンポー ネントを表しており、異なるサービスに亘って再利用可能となるように設計され ている。例えば呼の迂回といった番号変換フィーチャーは、幾つもの音声・デー タサービスに亘って再利用可能となるであろう（以後このフィーチャーはＧＳＣ とＳＡＦの両者となろう）。 ＳＡＦは、特定のサービス・アプリケーション実現手段から独立していて、ネ ットワーク・アーキテクチャーや特定のプラットフォームやサービス管理やネッ トワーク管理あるいは課金エンティティについての本質的知識を一切持たないよ うに開発される。 ＳＡＦは、呼処理機能を備えるようにＩＮエレメント上に配備できるフィーチ ャーを表すが、サービス・ネットワークの枠内で特定のサービスと関連するユー ザ状態情報によって例示されるまでは値を持たない。 ５．２ 市場性のあるサービス・フィーチャー（ＭＳＦ） 図４および図５を参照すれば、市場性のあるサービス・フィーチャー（ＭＳＦ ）４０３は、基礎となるＳＡＦ４０１の上に置かれた概観を表している。ＭＳＦ はＳＡＦを含ず、ＳＡＦを参照するだけである。ＭＳＦは、サービス・パッケー ジの一部として販売できるように、ＳＡＦ４０１に価格を追加するようにＳＣＥ ２の中に作成される（下記参照）。ＳＡＦを市場性のあるものとするには、適当 な 課金およびネットワーク管理の参照事項と結び付けなくてはならない。最も重要 なことはこういったフィーチャーのサービス管理面に取り組まなくてはならない ことである。 ＭＳＦ４０３は、フィーチャーの供給可能な面を入力しまた更新するために必 要な画面の定義を含んでいる。これらの供給可能な面は、このフィーチャーが正 しく動作するために必要な情報を含むであろう。しかしながらＭＳＦ４０３の供 給可能な面はＭＳＦが参照する、基礎となるＳＡＦ４０１によって必要とされる それらの面を超えて広がる可能性がある。特にある特定のフィーチャーのために 供給可能なのは、ネットワーク管理と課金の面であるかも知れない。 異なるＭＳＦが、同一の基礎的ＳＡＦを参照してもよい。例えば直進的にスケ ジュールされた番号変換フィーチャーは、サービスのマーケティング要件または 顧客の必要にしたがって、１日の時間、週の日、年の日または特別日の経路指定 、夜間サービスまたはオープン時間などとして販売できる。これらは、同じサー ビス内で異なる装いの下で再販することもできる。これらすべてのＭＳＦは、異 なる供給特性と課金特性を持っているが、基礎となるネットワーク実現はこれら すべてに亘って共通となろう。 ＭＳＦコンセプトの長期的な狙いは、ＭＳＦ４０３とＳＰ４０４が最少のコー ド開発の追加によって、大部分のサービスのためのＳＤＳリポジトリー１００か ら構築できるように、課金、サービス管理、ネットワーク管理、障害管理などの コンポーネントが、それらの目標システム上で再利用可能なビルディングブロッ ク（ＳＡＦ／ＧＳＣのような）として利用可能になるということを想定している 。こういったビルディングブロックの構築は、ＳＣＥ２をサポートするこのよう な管理システムの設計者のあいだで、ある一定量のＳＣＥ１作業が発生するとい うことを意味する。この想定の結果は、ＳＣＥ２におけるサービス作成者は大規 模顧客と個人ユーザの両者について一般インテリジェント・ネットワークへの迅 速な配備のための完全なサービスを構築するためにＩＮエレメントとサポート管 理システムとの両方の完全な機能に対するアクセスを持つことになろうというこ とである。 ５．３ サービス・パッケージ（ＳＰ）４０４ サービス・パッケージ（ＳＰ）４０４は、サービス提供業者が市場性があると 考える特定のサービスとＭＳＦとを結び付けるためにＳＣＥ２内で使われるエン ティティである。ＳＰ４０４は、サービス＆ネットワーク管理と課金とに関する サービス固有の情報だけでなくＭＳＦをも含むことになろう。 ５．３．１ サービス・テンプレート サービス・パッケージ４０４は、ＳＣＥ３顧客が彼らのユーザ・プロファイル の根拠となし得るプロファイル事例を表す一つ以上のサービス・テンプレートを 含むであろう。サービス・テンプレートは、完全に供給された場合に動作するこ とをサービス提供業者が保証するという、サービス操作のテスト済みの表現を表 す。このテンプレートは、サービスの操作や論理を編集したり修正したりしよう とするその後の試みが操作上容認可能な範囲内で制約されるように、ＳＣＥ２か ら与えられる一組のルールをカプセル化する。こうしてＳＣＥ３プロファイル作 成ツールの構成は、ユーザの特定のグループのためにプロファイルをテーラリン グする際に、基礎をなすフィーチャーの対話・従属ルールを顧客が犯すことのな いように、サービス提供業者によって管理される。サービス・テンプレートはま た、配達の前に特定のテーラリングが行えるようにサービスまたは顧客のレベル で部分的供給をするための機構も備えるであろう。 ５．４ プロファイル６００ 図６を参照すると、プロファイルはサービス・テンプレートから得られる。サ ービス・テンプレートは、ＳＣＥ３ユーザが修正したり、部分的あるいは全体的 に供給しておいてもよい。しかしながらサービス・テンプレートは、ある特定の 事例がこのサービスのある特定のユーザと結び付けられるまではプロファイルに ならない。プロファイルは、ユーザが特定のサービスのために持っている１個以 上のフィーチャーのリストを含んでおり、また各フィーチャーは、その特定のサ ービスの枠内でフィーチャーがうまく動作するために十分なデータを供給される 必要がある。 不完全プロファイル６０１と部分プロファイル６０２とは区別しなくてはなら ない。不完全プロファイル６０１は、不完全にあるいは不正確に供給されたフィ ーチャーへの参照事項を含んでいる可能性のあるプロファイルである。正しく供 給されたフィーチャーは、使用禁止にされているフィーチャーか、あるいはそれ がうまく動作するために必要とされるすべてのデータを含んでいるフィーチャー かのどちらかとして定義すべきである。こういうプロファイルは必要なすべての 供給データを含むことがチェックされ確認されるまでＳＣＥ３から現れないとい うことが必要条件である。ＳＣＥ３は、プロファイルの構築中に不完全プロファ イルをローカルに格納することを許している。部分プロファイル６０２は、完全 なサービスを記述するのに必要なフィーチャーをすべては含んでいないプロファ イルであるが、部分プロファイルが含んでいるフィーチャーはすべて正しく供給 されたものである。部分プロファイルは有効であって、サービス管理、ＳＣＥ３ 、ＳＤＳおよびＩＮエレメントの間でプロファイル更新情報として受け渡しされ る。 ６． ワーク列の例 図７〜図１８は事実上、説明を要しない。これらは幾つかのペアとして読み取 るべきであって、各ペアの一番目のものはワーク列の一例を示し、各ペアの二番 目のものは関連するアーキテクチャー的な動きを示す。これらのワーク列の目的 は、アーキテクチャー的な設計を実証するために幾つかのシナリオを動かしてみ ることである。そうすることによって、このアーキテクチャーがこれらの共通の 動きをサポートするであろうということ、またそれによって一般的インテリジェ ント・ネットワークにおいてサービスを配備したり供給やテーラリングをするた めにサービス作成者に課せられた要件を満たすということが示される。各ワーク 列は、特定のシナリオの進行中、動作中のコンポーネントとインタフェースとを ハイライトするメッセージ・シーケンス図と概要図（図２から得られる）の形で 示される。 図７と図８は、ＳＣＥ１からの新しいＳＡＦ／ＧＳＣの配備に係わる。 図９と図１９は、新しいサービスの配備に係わる。 図１１および図１２は、新しいサービスの注文に係わる。 図１３および図１４は、ＳＣＥ３からのプロファイルの更新に係わる。 図１５および図１６は、サービス管理からのプロファイルの更新に係わる。 図１７および図１８は、ＳＣＥ３経由のネットワーク側の更新に係わる。 次の付録は、本開示の一部である。これは、図１９乃至図２２を参照して、前 記のように、サービス作成システムで使用するためのデータ配付の例を説明して いる。 ７． 付録１ ７．１ データ配付：実現のシナリオ 誰がプロファイル（ＳＭまたは顧客）とサービスレベル契約（ＳＬＡ）の執行 権とを所有しているかということは、マスターデータの位置を整理するために重 要である（通常はＳＭの範囲内と見られる）。ここに示すデータ配付の戦略は、 性能上の制約、サービス管理の要件、ネットワーク事業者の方針、顧客要件など にしたがって柔軟に構成できるデータ格納アーキテクチャーを示す。 第１の例では、ＳＣＥ３は特定の永続的ストアまたはデータベース製品の中に 直接には連結されない。この機能は、それを外部のシステム・モジュールとして 取扱って、このストア上で retrieve と storeと send の操作を許している、定 義されたインタフェース経由で取り出される。このアーキテクチャーは、必要と 正当化にしたがってアプリケーションが選択されたりアップグレードされたりで きるように、プロファイル・ストア上の操作をカプセル化することによって、そ のアーキテクチャーの業者からの独立性を維持している。このシステムは、ＳＭ の方針と処理能力とにしたがって異なるプロファイル格納シナリオの構成を可能 にしている。本サービス作成アーキテクチャーは、要件が存在していても一連の 組合せですべてをサポートするであろう。このアーキテクチャーによって可能と されるシナリオは、図１９〜図２２に示す。 ７．１．１ シナリオ１ 図１９を参照すると、プロファイル・ストア１９０はサービス作成ドメイン内 に常駐している。 store（格納）と retrieve（検索）操作はローカルに発生し 、send（送出）操作は供給されたプロファイルがＳＭに伝送されることを可能に する。 含意 ・ 顧客は、自分自身のプロファイル・データがＳＭに引き渡されるまではそれ らを所有して管理し、それらに責任を持っている。 ・ プロファイルは、ネットワーク・サービス・データ全体に支配権を維持して いるＳＤＳデータから再構築される。 ・ ＳＣＥ３顧客は、プロファイルデータ管理のためのアプリケーションとサポ ートとを備えていなくてはならない。 ７．１．２ シナリオ２ 図２０を参照すると、すべてのデータは、ＳＭ上で管理される。プロファイル は、ＳＣＥ３からＳＭ上のプロファイル・ストア２００に渡される。検索の際に はサービス管理データは、プロファイル・ストア２００内の更新済みプロファイ ル内に変換し返されてからＳＣＥ３での問合わせ処理に戻される。 含意 ・ ＳＭは、ユーザ・プロファイルを含めてすべてのデータのマスターでありホ ストである。 ７．１．３ シナリオ３ 図２１を参照すると、分散型プロファイル・ストア２１０は、顧客ごとの性能 や方針および要件にしたがってシナリオ１と２を構成することを可能にする。 含意 ・ 二つのドメイン間のデータ・インタフェースは、何であれ選択されたストア 実現手段内に存在する固有の機構によって管理される。 ・ 選択された格納アプリケーションは、分散型構成をサポートしなくてはなら ない。 ７．１．４ シナリオ４ 図２２を参照すると、ＳＣＥ３は、ＳＭドメイン内に共存・常駐する。これは 、ネットワーク事業者のサービス・パッケージとユーザ・プロファイルの中に顧 客サポートを直接供給して、サービス管理システム上でネットワーク事業者の要 員がＳＣＥ３を使えるようにする。 含意 ・ 顧客とネットワーク事業者のサポート要員の両者とも、同一のツールセット と供給画面とを介してプロファイルを供給し、また更新する。 ・ 幾らかの顧客は、ある形式のグラフィカル・ワークステーションあるいはク ライアント・アプリケーション(例えば exceed)経由でのＳＣＥ３ツールセット へのリモートアクセスを必要とすることがある。 ・ サービス管理プラットフォームは、ＳＣＥ３アプリケーションをサポートし なくてはならない。 本発明の実施例は、異なるユーザの多数のタイプに有益な機能を提供するサー ビス作成システムを提供する。例えば本発明は、市場活動するユーザがサービス ・フィーチャーから完全なサービス・パッケージを構築したり、異なるマーケッ ト用に既存のサービス・パッケージを部分変更したりするのを可能にする。本シ ステムは、サービス・パッケージの論理フローを作成するために種々の仕方で組 合せ可能な一連の市場性のあるサービス・フィーチャーを提供する。すべてのフ ィーチャーは、考慮に入れて置かなくてはならない機密保護、フィーチャーの対 話回避、課金処理、機能供給などの面を持つことができる。本システムは、供給 画面と課金記録とテンプレートおよび配備すべきサービス・パッケージに必要な すべての情報などの作成を自動化することができる。それから本システムは、イ ンテリジェント・ネットワークのノードと、サービスを行う種々の管理システム と、顧客とに対してサービス・パッケージを送る配付サービスにとって利用可能 にすることができる。 使用中に、ある会社はネットワーク事業者（例えばＢＴ）の新サービス提供の ことを耳にしてそのサービスを要求するかも知れない。当初の供給情報がそのネ ットワークのサービス管理システムの中にロードされ、そしてその顧客は現在そ のサービスを持っている。それからその顧客は、端末機おそらくはパソコンを持 つことができ、それによって、顧客はネットワーク事業者のオペレータを使わず に顧客自身のサービスデータを供給したり変更したりできるようになる。顧客は 異なるグループのユーザのために、サービスの適当なレベルへのアクセスをユー ザに与えるテンプレートを作成することができる。顧客はまた、メニュー上のオ プションの順序とかどのサービスが優先権を持つかといったサービス論理を変更 することもできる。本サービス作成システムは、顧客が必要と感じるだけ多いあ るいは少ない、サービスのあるいはサービス内の制御権を持つことができるよう に、十分に柔軟であることが可能である。 前述の説明で「カプセル化」とか「オブジェクト」といった用語法が使われて いることに注目されたい。このタイプの用語法は単に、オブジェクト指向のソフ トウエア・エンジニアリングとプログラミングの言語であると認識されるであろ うが、ここではこの関連技術に精通した人によって理解される意味と同じ意味を 持っている。 本発明の実施例の発明的な面は一般に次のように表現される。 １． ネットワークのユーザにとって利用可能なサービスを作成および／または 修正する際に使用するための一揃いのソフトウエア・ツールからなる通信ネット ワーク用のサービス作成システムにおいて、前記サービス作成システムは、サー ビス作成環境の一つより多いレベルを有しており、また前記レベルは、前記サー ビス作成システムによって提供される選択された組の操作方法が異なるレベルで 利用可能にし得るように、これらのレベルに関連付けられたそれぞれ異なるツー ルセットを有しており、かつ前記レベルの各々は、それぞれ異なるタイプのソフ トウエア・エンティティを生成する手段を備えていることを特徴とする、通信ネ ットワーク用のサービス作成システム。 ２． 前記システムにおいて、前記レベルの第１のレベルは、前記ネットワーク のエレメント内に配備することのできるソフトウエア・オブジェクトからなるサ ービス・アプリケーション・フィーチャーを生成する手段を持ち、前記レベルの 第２のレベルは、市場性のあるサービス・フィーチャーを生成する手段を持ち、 これらの市場性のあるサービス・フィーチャーはそのフィーチャーのサポートと 管理の説明書と一緒にカプセル化されたサービス・アプリケーション・フィーチ ャーの呼出し処理論理からなることを特徴とする、前記「１項」に記載のサービ ス作成システム。 ３． 前記システムにおいて、前記サービス作成環境は、前記ネットワークのサ ービス機能を管理および配備する際に使うためにサービス管理システムとサービ ス配付システムとにインタフェースされ、かつ前記サービス作成環境の異なるレ ベルは、異なるレベルで異なるサービス作成機能を提供するためにサービス管理 および／またはサービス配付システム内のそれぞれ異なるコンポーネントまたは コンポーネントの組にインタフェースされることを特徴とする、前記「１項」ま たは「２項」のいずれかに記載のサービス作成システム。 ４． 前記システムにおいて、前記レベルの第１のレベルは前記サービス配付シ ステムへの出力を備えているがそのシステムからの入力は備えておらず、一方、 少なくとも前記レベルの第２のレベルは前記サービス配付システムへの出力とそ のシステムからの入力との両方を備えていることを特徴とする、前記「３項」に 記載のシステム。 ５． 前記システムにおいて、前記レベルの第３のレベルは前記サービス管理シ ステムにインタフェースされることを特徴とする、前記「４項」に記載のシステ ム。 ６． 前記システムにおいて、前記レベルの第２レベルは、市場性のあるサービ ス・フィーチャーを識別してそれらを前記通信ネットワークによって利用可能な 特定のサービスに結合するための結合機能を有するソフトウエア・エンティティ であるサービス・パッケージを構築、格納および出力する手段を持っていること を特徴とする、前記「１項」から「５項」までのいずれかに記載のシステム。 ７． 前記システムにおいて、前記レベルの第３のレベルは、前記レベルの第２ レベルからサービス・パッケージを受け取る手段と、プロファイルを生成または 修正する手段と、ユーザが選択したサービスの枠内でフィーチャーがうまく動作 できるように各フィーチャーに関連するデータを格納する手段とを持っているこ とを特徴とする、前記「１項」から「６項」までのいずれかに記載のシステム。 ８． 前記システムにおいて、各サービス・パッケージは、ネットワーク・ユー ザへの特定のサービスの供給も共にサポートする複数の市場性のあるサービス・ フィーチャーからなることを特徴とする、前記「６項」または「７項」のいずれ かに記載のシステム。 ９． 前記システムにおいて、各サービス・パッケージは、前記第３レベルにお いてサービス作成環境へのアクセスを有するユーザが前記第３レベルに格納され ているサービス・パッケージからサービス・テンプレートを使って顧客へのサー ビスを利用可能にしたりあるいは修正したりできるように、サービス・プロファ イルが生成できるサービス・テンプレートを少なくとも１個含んでいるというこ とを特徴とする、前記「６項」または「７項」または「８項」のいずれかに記載 のシステム。 １０． 前記システムにおいて、各サービス・テンプレートは、前記レベルの第 ２レベルで決められるルールであってかつ、プロファイルに関して備えるべきサ ービスの操作上の容認可能性を維持するためにそれぞれのテンプレートからある いはそのテンプレートに基づいて生成されるプロファイルに対して制約を付ける 諸ルールからなることを特徴とする、前記「９項」に記載のシステム。

【手続補正書】特許法第１８４条の８ 【提出日】１９９５年１１月２０日 【補正内容】 【図１】 【図６】 【図２】 【図３】 【図４】 【図５】 【図７】 【図８】 【図９】 【図１０】 【図１１】 【図１２】 【図１３】 【図１４】 【図１５】 【図１６】 【図１７】 【図１８】 【図１９】 【図２０】 【図２１】 【図２２】 【図２３】 【手続補正書】特許法第１８４条の８ 【提出日】１９９６年６月１７日 【補正内容】 請求の範囲 １． ネットワークのユーザが利用可能なサービスを作成および／または修正す る際に使用するための一揃いのソフトウエア・ツールを備えた、通信ネットワー ク用サービス作成システムにおいて、前記サービス作成システムは、サービス作 成環境の一つより多いレベルを有し、これらのレベルはそれらの間にインタフェ ースを有し、かつ前記サービス作成システムによって提供された選択された組の 操作が異なるレベルで利用可能にし得るように、これらのレベルに関連付けられ たそれぞれ異なるツールセットを有しており、かつ前記レベルの少なくとも２つ のレベルの各々は、それぞれ異なるタイプのソフトウエア・エンティティを生成 またはアクセスする手段を備えており、さらに ａ） 前記各レベルのうちの第１のレベルは、前記ネットワークのエレメント 内に配備することのできるコード・オブジェクトからなるサービス・アプリケー ション・フィーチャーを生成またはアクセスする手段を持ち、かつ ｂ） 前記各レベルのうちの第２のレベルは、 i） 市場性のあるサービス・フィーチャーを生成する手段を有し、これら の市場性のあるサービス・フィーチャーの各々は、グラフィカル・インタフェー ス手段によって前記サービス・アプリケーション・フィーチャーの暫定的な性質 を修正または入力するためのグラフィカル定義データとともに、前記第１のレベ ルの１または複数のサービス・アプリケーション・フィーチャーに対する基準を 含み、 ii） 前記各レベルのうちの第３のレベルと通信可能な、サービス・パッケ ージを生成するかそれにアクセスする手段を有し、これらサービス・パッケージ の各々は、少なくとも１つのサービス・テンプレートとともに一組の市場性のあ るサービス・フィーチャーまたは１組の市場性のあるサービス・フィーチャーに 対する基準を含んでおり、このテンプレートは、サービスをカスタマイズするた めに前記第３のレベルにおけるユーザによる操作に制約を付す埋込みルールを、 サービスのテスト済み表現に与えるものである、ということを特徴とする、通信 ネットワーク用サービス作成システム。 ２． 前記暫定的な性質は、課金とグラフィカルの定義データとを含み、これら により少なくとも一つのサービス・アプリケーション・フィーチャーの課金上の 性質の修正または入力をサポートすることを特徴とする、請求項１に記載のシス テム。 ３． 前記暫定的な性質は、ネットワーク管理データとグラフィカルの定義デー タとを含み、これらにより少なくとも一つのサービス・アプリケーション・フィ ーチャーのネットワーク管理上の性質の修正または入力をサポートすることを特 徴とする、前記請求項のいずれかに記載のシステム。 ４． 前記サービス作成環境は、前記ネットワークのサービス機能を管理および 配備する際に使用するためにサービス管理システムとサービス配付システムとに インタフェースされ、かつ前記サービス作成環境の異なるレベルは、サービス管 理および／またはサービス配付システム内のそれぞれ異なるコンポーネントまた はコンポーネントの組にインタフェースされることを特徴とする、前記請求項の いずれかに記載のサービス作成システム。 ５． 前記第１のレベルは、前記サービス配付システムへの出力を備えているが そのシステムからの入力は備えておらず、一方少なくとも前記第２のレベルは、 前記サービス配付システムへの出力とそのシステムからの入力との両方を備えて いることを特徴とする、請求項４に記載のシステム。 ６． 前記第３のレベルは、前記サービス管理システムにインタフェースされる ことを特徴とする、請求項５に記載のシステム。

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁶ 識別記号 庁内整理番号 ＦＩ Ｈ０４Ｍ 3/42 9567−5Ｇ Ｈ０４Ｍ 3/42 Ｚ (72)発明者 パビアー、 ジェレミー イギリス国、アイピー４・４エヌティー、 サフォーク、イプスウィッチ、ジュピタ ー・ロード 27ビー (72)発明者 ターナー、 グラハム・デイビッド イギリス国、アイピー12・３エーエス、サ フォーク、ウッドブリッジ、ボードセイ、 ザ・ストリーツ、イーストフィールズ ４ (72)発明者 コックス、 リチャード・デューイット アメリカ合衆国、テキサス州 75044、ガ ーランド、リッジ・オーク・ドライブ 3113 (72)発明者 ハンター、 アンドリュー・ティモシー アメリカ合衆国、テキサス州 75240、ダ ラス、ノエル・ロード・ナンバー727 14000 (72)発明者 ランド、 ジェフリー・ケビン アメリカ合衆国、テキサス州 75019、コ ッペオル、ロッキー・ブランチ 508 【要約の続き】 リストアップし、また各フィーチャーに必要なデータの ためのデータ・スロットを用意しているプロファイル は、ＳＣＥ３内で供給され修正されることが可能であ る。

Claims (1)

1. 【特許請求の範囲】 １． ネットワークのユーザにとって利用可能なサービスを作成および／または 修正する際に使用するための一揃いのソフトウエア・ツールからなる通信ネット ワーク用サービス作成システムにおいて、前記サービス作成システムは、サービ ス作成環境の一つより多いレベルを有しており、また前記レベルは、前記サービ ス作成システムによって提供される選択された組の操作が異なるレベルで利用可 能にし得るように、これらのレベルに関連付けられたそれぞれ異なるツールセッ トを有しており、かつ前記レベルの各々は、それぞれ異なるタイプのソフトウエ ア・エンティティを生成する手段を備えていることを特徴とする、通信ネットワ ーク用サービス作成システム。 ２． 前記レベルの第１のレベルは、前記ネットワークのエレメント内に配備す ることのできるソフトウエア・オブジェクトからなるサービス・アプリケーショ ン・フィーチャーを生成する手段を持ち、前記レベルの第２のレベルは、市場性 のあるサービス・フィーチャーを生成する手段を持ち、これらの市場性のあるサ ービス・フィーチャーはそのフィーチャーのサポートと管理の説明書と一緒にカ プセル化されたサービス・アプリケーション・フィーチャーの呼出し処理論理か らなることを特徴とする、請求項１に記載のサービス作成システム。 ３． 前記サービス作成環境は、前記ネットワークのサービス機能を管理および 配備する際に使うためにサービス管理システムとサービス配付システムとにイン タフェースされ、かつ前記サービス作成環境の異なるレベルは、異なるレベルで 異なるサービス作成機能を提供するためにサービス管理および／またはサービス 配付システム内のそれぞれ異なるコンポーネントまたはコンポーネントの組にイ ンタフェースされることを特徴とする、前記請求項のいずれかに記載のサービス 作成システム。 ４． 前記レベルの第１のレベルは前記サービス配付システムへの出力を備えて いるがそのシステムからの入力は備えておらず、一方少なくとも前記レベルの第 ２のレベルは前記サービス配付システムへの出力とそのシステムからの入力との 両方を備えていることを特徴とする、請求項３に記載のシステム。 ５． 前記レベルの第３のレベルは、前記サービス管理システムにインタフェー スされることを特徴とする、請求項４に記載のシステム。 ６． 前記レベルの第２レベルは、市場性のあるサービス・フィーチャーを識別 してそれらを前記通信ネットワークによって利用可能な特定のサービスに結合す るための結合機能を有するソフトウエア・エンティティであるサービス・パッケ ージを構築、格納および出力する手段を持っていることを特徴とする、前記請求 項のいずれかに記載のシステム。 ７． 前記レベルの第３のレベルは、前記レベルの第２レベルからサービス・パ ッケージを受け取る手段と、プロファイルを生成または修正する手段と、ユーザ が選択したサービスの枠内でフィーチャーがうまく動作できるように各フィーチ ャーに関連するデータを格納する手段とを持っていることを特徴とする、前記請 求項のいずれかに記載のシステム。 ８． 各サービス・パッケージは、ネットワーク・ユーザへの特定のサービスの 供給も共にサポートする複数の市場性のあるサービス・フィーチャーからなるこ とを特徴とする、請求項６または７に記載のシステム。 ９． 各サービス・パッケージは、前記第３レベルにおいてサービス作成環境へ のアクセスを有するユーザが前記第３レベルに格納されているサービス・パッケ ージからサービス・テンプレートを使って顧客へのサービスを利用可能にしたり あるいは修正したりできるように、サービス・プロファイルが生成できるサービ ス・テンプレートを少なくとも１個含んでいるということを特徴とする、請求項 ６、７または８に記載のシステム。 １０． 各サービス・テンプレートは、前記レベルの第２レベルで決められるル ールであってかつ、プロファイルに関して備えるべきサービスの操作上の容認可 能性を維持するためにそれぞれのテンプレートからあるいはそのテンプレートに 基づいて生成されるプロファイルに対して制約を付ける諸ルールからなることを 特徴とする、請求項９に記載のシステム。