JP2000516408A - 遠隔通信システムに使用されるサービス資源項目のアクセス方法 - Google Patents

Abstract

(57)【要約】 電話システムにおける呼び出し設定において使用されるサービス資源項目(４９)が電話システム下部構造と論理的に独立するコンピュータ・ネットワークに接続されるサーバー(５８)上に保持される。コンピュータ・ネットワークは例えばインターネットである。各サービス資源項目(４９)はコンピュータ・ネットワーク上で対応するＵＲＩによってその位置を特定することが可能であり、また特定の電話番号に関連づけられる。電話番号と関連サービス資源項目のＵＲＩの間の対応関係が提供される。特定の電話番号に関連づけられたサービス資源項目(４９)へのアクセスが求められると、この対応関係を使用して対応するＵＲＩが取り出され(ステップ５５)、次にそのＵＲＩを使用して所望のサービス資源項目(５６、５７、５９)へのアクセスが行われる。

Description

【発明の詳細な説明】 遠隔通信システムに使用されるサービス資源項目のアクセス方法 発明の技術分野 本発明は、交換遠隔通信システムを通る搬送体経路を設定する際に使用される ように意図されているサービス資源項目にアクセスする方法に関するものである 。 本明細書において使用される用語「交換遠隔通信システム」は、搬送体ネット ワークにわたる搬送体経路を設定する交換機能を備えた搬送体ネットワークを含 むシステムを意味する。「交換遠隔通信システム」は、(アナログ電話あるいは ＩＳＤＮ型のいずれの使用を問わず)既存の公共およびプライベート電話システ ムのみならず、現在実施中または将来登場するであろう広帯域(ＡＴＭ)またはそ の他の交換型搬送体ネットワークを含むものとみなされるべきである。本明細書 において、用語「交換遠隔通信システム」は便宜上遠隔通信システムと短縮して 用いる場合がある。 交換遠隔通信システム環境における「呼び出し」は、搬送体ネットワークにわ たる搬送体経路設定による通信を意味するものと理解されるべきであり、呼び出 し設定、維持および切断は、搬送体ネットワーク上の搬送体経路を設定し、維持 し、切断するプロセスを意味するものと見なされるべきである。「呼び出し処理 」および「呼び出し取り扱い」のような用語は同様に解釈されるべきである。 本明細書で使用される用語「通信システム」は、交換遠隔通信システムより幅 広い意味を持つものとして理解されるべきであり、各データ・パケットが、あら かじめ定められた搬送体経路に従うことなく、搬送体ネットワークを通して独立 して経路指定されるデータグラム型通信システムを含むように意図されている。発明の背景技術 ＰＳＴＮ(Public Switched Telephone Networksすなわち公共交換電話ネット ワーク)およびＰＬＭＮ(Public Land Mobile Networksすなわち公共地上移動体 ネットワーク)を運営する遠隔通信会社は、通信サービスを提供する事業を行い 、その事業において、８００番サービスや呼び出し転送のような「ＩＮサービス 」の形態で行う組み込み情報サービスを発展させている。対照的に、最近爆発的 な成長がみられるワールド・ワイド・ウェブ(すなわちＷＷＷ)は、複雑な情報サ ービスを提供するインターネット型グローバル・ネットワークの１例である。大 規模通信ユーティリティおよび非常に動的で開拓精神に富んだＷＷＷ情報文化と いうこれら２つの世界は、ぎごちない仲間であり、各々は相手によって既に占有 された領域に浸透する計画をたてていて、将来、電話通信サービスがＷＷＷを経 由して提供され、情報サービスが公共通信下部構造を介して提供されるであろう 。 本発明は、これら２つの世界の関係を現在より一層協調的なものにさせる技術 を提案する。本発明の脈絡を明確にするため、先ず、これら２つの世界の各々に ついて考察を加える。ＩＮサービスにおける電話ネットワーク 基本的ＰＳＴＮ。ＰＳＴＮ(すなわちPublic Switched Telephone Network公共交 換電話ネットワーク)によって提供される基本的サービスは、呼び出し側電話に おいて入力された呼び出され側電話番号に従った２台の電話の接続(すなわち２ つの電話の間の搬送体経路の設定)である。図１は、そのようなサービスを提供 しているＰＳＴＮを単純化して表現したものである。特に、(アナログ電話また は最近のＩＳＤＮ端末のような)宅内機器(すなわちＣＰＥ)１０は、アクセス・ ネットワーク１１を経由して交換ポイント(すなわちＳＰ)１２に接続される。Ｓ Ｐ１２は、ＳＰの制御部１５によって制御される相互接続用電話中継線１４およ び複数のＳＰから構成される相互交換ネットワーク１３におけるノードを形成す る。制御部１５によって実施される制御は、宅内機器(ＣＰＥ)および他のＳＰか ら受け取る入力信号によって決定され、その制御は、呼び出しＣＰＥと呼び出さ れＣＰＥの間の所望の搬送体経路を作成する呼び出し設定、維持および切断を含 む。概念的には、ＰＳＴＮは搬送体ネットワークおよび制御(信号)ネットワーク とみなすことができ、後者の機能は、搬送体ネットワーク上の呼び出し制御、す なわち搬送体経路の設定、維持および切断の実行である。実際には、搬送体およ び信号ネットワークは、同一の物理的回路および場合によっては同一の論理経路 を使用することもある。 このように、ＣＰＥが伝統的な、知能のない電話である場合、ＣＰＥとそのロ ーカルＳＰの間の制御信号機能は、バンド内信号機能である。すなわち、信号は 音声のために使用されるものと同じ経路で搬送される。この信号は、ＳＰ１２に おいて、専用共通経路信号ネットワークを使用するＳＰ間信号に変換される(現 在このような変換はＳＳ７プロトコール規格を使用して実施されている)。ＣＰ ＥがＩＳＤＮ端末である場合、信号は別の経路を介してＣＰＥから直接搬送され る。モデムＳＰは、ＣＰＥが標準の電話かＩＳＤＮ端末であるかを判断する相互 交換呼び出し制御信号のためＩＳＵＰ(すなわちＩＳＤＮ User Part)ＳＳ７プロ トコルを使用する。 電話番号割り当て方式−本発明の特定の局面は電話番号の構造によって影響を 受けるので、電話番号構造について以下要点を記述する。電話番号は、１０進デ ジットからなるグループに基づく国際的な階層的アドレス指定方式を形成してい る。階層の最高レベルは、ＩＴＵ-Ｔによって管理されていて、主要な地理的地 域に１桁の１０進数コードを割り当てている(例えば、北アメリカに"１"、アフ リカに"２"、ヨーロッパに"３"、南アメリカおよびキューバに"５"等々)。各地 域内において各国に２または３桁の１０進数が割り当てられる。例えば、地域３ 内においてフランスには"３３"、地域４内において英国には"４４"が割り当て られている。各国内の番号割り当て方式の管理は、例えば英国の通信局(通称"０ ftel")のような国家機構に一任されている。以下の記述は、英国の番号割り当て 方式に基づいているが、記述される方式は広範な適用性を持っているものと認め られることであろう。 英国においては、すべての番号は０１から０９までで始まる。現在、"０１"は 地域コードに、"０２"は追加地域コードに、"０４"は移動電話に、"０７"は個人 番号に、"０８"は(無料電話、情報など)特別サービスに割り当てられている。通 常のＰＳＴＮ加入者電話番号は地理的な地域コードから割り当てられ、現在０１ で始まるコードだけが割り当てられている。地理的な地域コードは(先頭のゼロ を除いて)現在３または４桁で、現在それぞれ６３８の地理的区域がある。英国 のすべてのダイアル式電話番号は次の２つの形式である。 0 171 634 8700 地域コード ローカル番号(７桁) 0 1447 456 987 地域コード ローカル番号(６桁) 最初のケースは、先頭が"０"で、次に３桁の地域コードすなわち市外局番号、７ 桁のローカル番号と続き、第２のケースは、先頭が"０"、次に４桁の地域コード 、６桁のローカル番号と続く。６桁アドレス空間でさえ単一交換にとっては大き すぎるので市外局交換の範囲内で更なるローカル番号の解釈が発生する。典型的 なローカル地域に関して、必要とされる数の加入者回線を処理するためいくつか の交換が必要となる。この解釈は一般には見えず、地域サービス・プロバイダの 問題である。 現在のＰＳＴＮにおいて、電話番号の本来的に階層的でかつ地理的な解釈は、 ネットワークの物理的なアーキテクチャによって表される。電話番号は、ネット ワーク上で呼び出し経路を定め易い方法で構成される。各ステップにおいて、番 号の先頭コードは、現在の経路指定ステップに関する情報を提供し、後部コード は(多分見えないが)引き続く経路指定ステップ関する情報を提供する。交換機が 先頭コードを解析し経路指定ステップを実行する方法を知っている限り、後部コ ードの内容を理解する必要はなく、それは後続の経路指定ステップに委ねられる 。この理由のために、国際的および国家的交換網が階層的に組織される。 インテリゲント・ネットワーク。現在の電話ネットワーク下部構造の考察に戻る と、基本的呼び出し処理に加えて、ＳＰはいわゆるＩＮサービス(Intelligennt Networkの頭文字でインテリジェント・ネットワークの意味)を提供する。この場 合、ＳＰはサービス交換ポイント(service switching pointの頭文字をとって以 下ＳＳＰと呼称する場合がある)と呼ばれる。ＳＳＰ２５は、特定の基準の充足 に基づいて定義された被呼び出しボイントにおける呼び出し処理を中止し、サー ビス制御ボイント(すなわちＳＣＰ)１７(図２参照)または補助ポイント(すなわ ちＡＤＪ)１８のいずれかの形態でサービス制御機能(すなわちＳＣＦ)を提供す るサービス制御サブシステムに呼び出し処理の継続を一任するように構成される 。補助ポイント(ＡＤＪ)１８はＳＳＰ２５に直接接続し、一方、ＳＣＰ１７およ びＳＳＰ２５は、信号転送ポイント(すなわちＳＴＰ)を含む拡張共通経路信号ネ ットワーク(すなわちＣＣＳネットワーク)１６を通して相互に交信する。ＳＣＰ １７は、複数のＳＳＰ２５に接続することもできる。ＳＣＰ１７および補助ポイ ント１８は１つまたは複数のサービス論理プログラム(すなわちＳＬＰ)のインス タンス２１が実行されるサービス論理実行環境(すなわちＳＬＥＥ)２０を提供す る。ＳＬＥＥ２０およびＳＬＰ２１はＳＳＰ２５にサービスを提供するためのサ ービス制御機能性をともに提供する。 ＳＣＰまたは補助ポイント上で動作するサービス論理は、サービス・データ機 能(すなわちＳＤＦ)２２に記憶される加入者情報を一般に活用する。ＳＤＦは、 ＳＣＰと補助ポイントに統合されている場合もあれば、それぞれ部分的にあるい は完全に独立している場合もある。サービス・データ機能(ＳＤＦ)は、サービス 制御機能(ＳＣＦ)と同様に、ＰＳＴＮのサービス制御サブシステムの一部を構成 する。サービス制御機能の一部またはすべてがＰＳＴＮ交換機自体に組み込まれ ていることもある点に注意する必要がある。 ＳＣＰ１７および補助ポイント(ＡＤＪ)１８に加えて、図２のネットワークは 情報周辺器(すなわちＩＰ)２３を含む場合もある。ＩＰ２３は、音声通知および ＤＴＭＦ桁収集機能のような資源をＳＳＰ２５に提供する。ネットワークは、ネ ットワークおよびそのサービスの全体を把握し、ネットワーク監視および制御の ような機能を実行するオペレーティング・システム(図示されていない)を含む。 動作に関する限り、ＳＳＰ２５は、呼び出しを受け取ると、内部のトリガー条 件、およびおそらく(ダイヤルされた桁のような)ユーザ情報を検査して、呼び出 しがサービス制御サブシステム１７、１８によって提供されるべきサービスを要 求しているか否かを確認する。トリガー条件の検査は、呼び出し処理におけるい くつかの異なるポイントで実行される。サービスが必要であると判断すると、Ｓ ＳＰ２５は、サービス制御サブシステム(ＳＣＰ１７または補助ポイント１８の いずれか)にメッセージを送り、所望のサービスを要求し、その接続および呼び 出し処理状態に関する呼び出しの論理表現をサブシステムに送る。次にサービス 制御サブシステムは要求されたサービスを提供するが、それは、ＳＳＰおよびサ ービス制御サブシステムの間の単一の交信または複数交信のセッションを伴う。 典型的サービスは、呼び出され側サービスである呼び出し転送であり、これは， 例えば、番号Ｘの加入者の要求に応じて、その加入者の番号が呼び出されて１０ 回呼び出し音を鳴らしても出ない場合は番号Ｙを呼び出すようなサービスである 。この場合、呼び出され側加入者にとってローカルにあるＳＳＰがこのサービス を提供するためその接続ＳＣＰ(または補助ポイント)を起動する。当然のことで はあるが、ＳＳＰは呼び出される番号Ｘに関してサービスが提供されるべきこと を あらかじめ知っていなければならない。 ＰＳＴＮにおけるＩＮサービスの提供に関する上述のモデルは、ＧＳＭおよび その他の移動体ネットワークのようなＰＬＭＮ(すなわちPublic Land Mobile Ne tworks公共地上移動体ネットワーク)にもあてはめることができる。移動体加入 者の場合、通常の信号要件に加えて、移動体加入者への呼び出し経路を確立する 必要があるので、信号制御は一層複雑である。しかしながら、これは、ＰＳＴＮ における多数の呼び出され側サービスと相違する問題ではない。かくして、ＧＳ Ｍにおいては、サービス・データ機能(ＳＤＦ)は、主に、ホーム・ロケーション ・レジスタ(ＨＬＲ)という名前をつけられたシステムに位置し、サービス制御機 能は、一般的に各ＳＳＰと１対１で対応するビジタ・ロケーション・レジスタ( ＶＬＲ)という名前をつけられたシステムに位置する(ＳＳＰはＧＳＭの用語では 移動体交換センタＭＳＣと呼ばれる)。 加入者が移動体であるので、加入者プロフィールは、ＨＬＲから移動体加入者 に機能的に最も近いＶＬＲへ転送され、そのＶＬＲが加入者プロフィールを使用 して(定められた)サービスを操作して、ＳＳＰと交信する。このように、ＨＬＲ およびＶＬＲは、その関連データベースを用いて、ＳＣＰまたはＡＤＪと同様の サービス制御サブシステムを構成する。 当然のことながら、プライベート電話システムにおいてＩＮサービスを提供す ることは可能であり、この場合、サービス制御機能およびサービス・データ機能 は、一般的にＰＡＢＸ(構内自動交換設備)に組み込まれるかまたはローカルのコ ンピュータによって提供される。サービス制御サブシステムはＰＡＢＸと物理的 に独立していない場合もある。 ＩＮサービスを提供する上記の一般的アーキテクチャ上のフレームワークは長 所と短所を持つ。主な長所は、８００番サービス、クレジットカード呼び出し、 音声メールおよび種々の呼び出し待機と転送サービスのような多くのサービスが うまく展開されていることである。しかし、長年の標準化にもかかわらずそのよ うなサービスは、なおまだネットワーク・プラットフォーム上で一度に１つずつ しか実施されず、十分な展開が図れない。何十万何百万もの加入者にサービスを 提供する大規模な無故障システムを基に開発が進められ、実現には多くの年を必 要とする。更に、これらのサービスをサポートするために使用されるネットワー クは基本的電話下部構造を構成しているので、これらのネットワークに付加され るものは何でも厳格に吟味されなければならない。その上、各国および操作員は ともすると標準のロ一カル・バリエーションを持つ傾向があり、それが標準製品 の供給を困難にし、競争の力学を破壊する。ワールド・ワイド・ウェブ（ＷＷＷ） 電話下部構造の慎重な遅い進歩と対照的に、ＷＷＷは１９８９年におけるその 発端から爆発的に成長して、情報内容の広がり、可用性および豊富さの観点から みて主要な電子情報分配サービスとなった。誰もが、わずかの出費で、高度に相 互接続した情報アーキテクチャにおいて世界中の聴衆への情報提供者になること ができる。 ＷＷＷは、インターネットを経由し、クライアントとサーバーの間で最も簡単 な交換だけを委託するクライアント／サーバー・プロトコルを使用するクライア ント／サーバー・アプリケーションである。このプロトコルは、インターネット のようなＴＣＰ／ＩＰネットワーク上の使用のため最適化されたＨＴＴＰ(すな わちHyper Text Transfer Protocol複合テキスト伝送プロトコル)であるが、Ｈ ＴＴＰプロトコルは、異なる通信プロトコル・スタックを使用するネットワーク 上で使用することができる。 ＷＷＷに関する文献はＷＷＷ自体と同じように増大しているので、ＷＷＷ、Ｈ ＴＴＰおよびインターネット関する詳細の記述は本明細書において行わない。し かしながら、本発明にとって意味のある特定の特性に焦点をあてた概要の記述だ けを以下に行う。 ＷＷＷは相互接続のためインターネットを使用する。インターネットは世界的 な規模でネットワークを相互に接続するシステムである。インターネットは、Ｔ ＣＰ／ＩＰプロトコル規格に基づくもので、ＴＣＰ／ＩＰを使用するネットワー クへの接続を行う。インターネット上に存在するエンティティ(すなわち実体)は 、インターネットに接続したネットワークへのアクヤスおよびＩＰアドレスを必 要とする。ＩＰアドレスは階層的に構成されている。一般的に、エンティティは ユーザ・レベルで名前によって識別され、名前は、インターネットのドメイン名 システム(Domain Name Systemの頭文字をとって以下ＤＮＳと略称する場合があ る)によって対応するＩＰアドレスに分解される。ＤＮＳまたはその応用が以下 に記述される本発明の少くとも特定の実施形態にとって必須のものであるので、 ＤＮＳの一般的形式および動作を以下に記述する。 ドメイン名システム(ＤＮＳ)−ＤＮＳはグローバルな分散型データベースであ り、その実行、弾力性および拡張性なしにはインターネットは現在の形式でほと んど存在しないであろう。ＤＮＳは、クライアントの要求に応答して、インター ネット・ホスト・ドメイン名を異なるタイプの１つまたは複数の登録レコード(R egistration Recordの頭文字をとって以下ＲＲと略称する場合がある)と関連づ ける。それらタイプのうちで最も普遍的なものは、(15.144.8.69)のようなアド レス(Ａ)レコードおよび(ドメインのため電子メールを受けるように構成された ドメイン・ホストを識別するために使用される)メール交換(ＭＸ)レコードであ る。ＲＲは世界中のＤＮＳネーム・サーバーに分配され、これらサーバーが連係 してドメイン名変換サービスを提供する。単一のＤＮＳサーバーはグローバル なデータベースの小さい部分しか含まないが、各サーバーは、そのデータに自分 より近くにあるＤＮＳサーバーを探り当てる方法を知っている。ＤＮＳの特徴は 次の通りである。 --ホスト名空間は、ツリーに組み立てられたノード階層として構成され、各ホス トは対応する葉ノードを持つ。各ノードは(ルート・ノードを除いて)先頭がア ルファベットで以下にいくつかの英数字シーケンスが続くラベルを持つ。１つ のホストの完全な名前は、各々がピリオドで隔てられた、階層の対応する葉ノ ードからルート・ノードまでの複数のノード・ラベルのストリングである。後 者のルート・ノードは終端ピリオドによって表される。このように、例えば、 EnglandのBristolにあるHewlett-Packard Laboratoriesのホスト機"fred"は、 "fred.hpl.hp.com."という認定されたドメイン名を持つこととなる(注：もし もホスト名が終端ピリオドを持たないとすれば、それは名付け階層の現在時ノ ードに関する名前と解釈される)。 --各ホストは１つまたは複数の関係登録レコード(ＲＲ)を持つ。 --各々が名前空間のサブツリーに対する責任を持つ複数のＤＮＳサーバーがある 。１つのＤＮＳサーバーは、そのサブツリーの全部または一部に関するＲＲを 持つ。−後者の場合ＤＮＳサーバーはサブツリーの残りに関する責任を別の１ つまたは複数のＤＮＳサーバーに委譲する。ＤＮＳサーバーは責任を委譲した したすべてのサーバーのアドレスおよびそのサーバーが管理するサブツリーに 関する責任を委譲したサーバーのアドレスを知っている。このように、ＤＮＳ サーバーは名付け階層において相互にポイントし合う。 --ＤＮＳを使用することを望むアプリケーションは、少くとも１つのＤＮＳサー バーのアドレスを知っている関連「解決機構」を通してＤＮＳを使用する。Ｄ ＮＳサーバーが指定されたホストのＲＲに関してこの解決機構によって問い合 わせを受けると、ＤＮＳサーバーは、要求されたＲＲか、または、名づか階層 をたどるためＲＲを保持するサーバーに一層近いＤＮＳサーバーのアドレスか 、いずれかを返す。実質的には、解決されるべきドメイン名に対す る責任を持つサーバーに到達するまでサーバーの階層を登り、その後、解決さ れるべきドメイン名に関するＲＲを持つサーバーまでＤＮＳサーバー階層を下 る。 --ＤＮＳは、あらかじめ定められたメッセージ形式を使用し(実際それは問い合 わせおよび応答に関して同じものであるが)、ＩＰプロトコルを使用する。 ＤＮＳのこれらの特徴は、ラベル構文、ラベル組み合わせ方法、メッセージ形式 細部、ＩＰプロトコル進化等々におけるような若干のバリエーションを常に許容 する"ＤＮＳタイプ"システムを定義するものとみなすことができる。 階層的名づけ構造のため、名前空間の管理ドメイン(サブツリー)に対する責任 を再帰的に委譲するすることが可能である。従って、トップレベルのドメインは InterNicによって管理される(これらトップレベル・ドメインは、よく知られて いる'com'、'edu'、'org'、'int'、'net'、'mil'などのドメインや、'us'、'uk' 、'fr'などのような標準的２文字によって指定される国ドメインを含む)。次の レベルでは、例えば、ヒューレット・パッカード社は'hp.com'で終わるすべての 名前に対して責任を持ち、British Universitiesは'ac.uk'で終わるすべての名 前に対して責任を持つ。更にその下のレベルでは、例えば、ドメイン'hpl.hp.co m'の管理はヒューレット・パッカード研究所の責任であり、ドメイン'newcastle .ac.uk'の管理はUniversity of Newcastle-upon-Tyneの責任である。 図３は、ヒューレット・パッカード研究所から行われる照会の例の動きを示す。 解決されるべきホスト・ドメイン名は、英国のUniversity of Newcastleにある 仮想的機械である'xy.newcastle.ac.uk'である。照会は、"hpl.hp.com"サブツリー に責任があるＤＮＳサーバーに提示される。このサーバーは、要求されたＲＲを 持たないので"hp.com"ＤＮＳサーバーのアドレスを応答する。次にこのサーバー が照会され、"com"ＤＮＳサーバーのアドレスを応答し、次にそのサーバーが'.' （ルート）ＤＮＳサーバーのアドレスを応答する。次に照会は、'newcastle.ac. u k'サーバーがそのサブツリーにおける名前'xy'に対するＲＲレコードを応答する まで'uk'ブランチを反復的に下方向へ進む。 これは非常に非能率に見えるが、ＤＮＳサーバーは動的キャッシュを構築する ように設計されていて、いくつかのルート・サーバーのアドレスを含むように初 期化されているので、実際には反復的な照会はほとんど起こらない。このケース において、'hpl.hp.com'ＤＮＳサーバーは、いくつかのルート・サーバーのアド レスを知っていて、'uk'および'ac.uk'サーバーのアドレスはおそらくキャッシ ュに持っていることであろう。'hpl.hp.com'サーバーへの最初の照会が'ac.uk'サー バーのアドレスを返すであろう。'ac.uk'サーバーへの2番目の照会が'newcastle.ac. uk'サーバーのアドレスを返し、３番目の照会が目的のＲＲを返すであろう。'ne wcastle.ac.uk'を先頭に持ついかなるその後の照会も、そのアドレスが"hpl.hp. com"ＤＮＳサーバーのキャッシュに保持されるので、newcastleＤＮＳサーバー へ直接進むであろう。実際、ローカルのサブツリーの範囲内の名前は単一照会で 解決され、ローカル・サブツリーの外側の名前は２回またはか３回の照会で解決 される。 解決機構は、ドメイン名を解決するために必要とされる一連の照会反復を実行 することに対して責任があるというよりはむしろ、再帰的な第１の照会を指定し てその照会に関して責任のあるＤＮＳサーバに送り、その受け取りＤＮＳサーバ ーが要求されたＲＲを直接戻すことができなければ次により近いＤＮＳサーバー へ再帰的照会を発する。 実際には各ＤＮＳサーバーは複製されている点、すなわちプライマリと１つま たは複数のセカンダリに構成されている点に注意する必要がある。プライマリＤ ＮＳサーバーはローカル・ファイル・システム上に維持されるデータベースから 自らを初期化し、セカンダリはプライマリから情報を伝送することによって初期 化する。サブツリーは、通常１つのプライマリＤＮＳサーバーおよび最高１０ま でのセカンダリを持つ。セカンダリの数の限度は、プライマリからのデータベー スを更新するために必要となるセカンダリの時間による。プライマリ・データベ ースは、サブツリー情報のマスター・ソースでりあ、ドメインＤＮＳ管理者によ って維持される。セカンダリは単なる待機セカンダリではなく、プライマリでは なくセカンダリをポイントする従属サーバーとのＤＮＳに活発に参加する。 ＢＩＮＤのようなＤＮＳ実施形態は、大部分のＵＮＩＸシステムの標準部分と して広く普及していて、現存する最も強力で広範に使われている分散アプリケー ションの１つであるといえる。 ＷＷＷの動作。図４を参照すれば、インターネット３０へのアクセスは、直接 または間接的にそれ自体インターネットに接続しているネットワークへの直接接 続によって行われる。そのような構成は図４における端末３１によって代表され る(この端末は例えばＵｎｉｘワークステーションまたはＰＣである)。このよう な形式でのインターネットへの接続は、「ネットワーク・アクセス」の実行とし て知られている。インターネットヘネットワーク・アクセスするいかなるエンテ ィティも、十分な関連機能性を持っていることを前提とすれば、インターネット 上のサーバーとしての役割を果たす。例えば、図４において、ファイル記憶機構 ３７を持つエンティティ３２は、サーバーとしの働きをする。 ＷＷＷの多くのユーザは、インターネットへのネットワーク・アクセスを行わ ず、その代わりに、ネットワーク・アクセス機能を持つインターネット・サービ ス・プロバイダすなわちＩＳＰ３３を経由してインターネットへのアクセスを行 う。このケースでは、ユーザ端末３４は、一般的には、モデムを使用しＳＬＩＰ (すなわちSerial Line Interface Protocolシリアル・ライン・インタフェース ・プロトコル)またはＰＰＰ(すなわちPoint-to-Point Protocolポイント・ツー ・ ポイント・ポイント・プロトコル)を利用して公共電話システムを経由してＩＳ Ｐ３３と通信する。これらのプロトコルは、インターネット・パケットが通常の 電話線で伝送されることを可能にする。この形式のインターネットへのアクセス は、「ダイヤルアップＩＰ」アクセスとして知られている。このアクセス方式で は、ユーザ端末３４は各ユーザ・セッションの間一時的にＩＰアドレスを割り当 てられる。しかしながら、このＩＰアドレスはセッション毎に異なるので、エン ティティ３４はサーバーの役割を果たすことはできない。 ＷＷＷの基礎は、統一資源識別子(すなわちUniform Resource Identifierであ り以下略してＵＲＩと呼ぶ)という手段によって特定の情報資源の位置を定める 能力である。ＵＲＩは、一般に、位置によって資源を特定する統一資源位置特定 子(すなわちUniform Resource Locatorであり以下略してＵＲＬと呼ぶ)か、また は、ＵＲＬへ変換可能な統一資源名(すなわちUniform Resource Nameであり以下 略してＵＲＮと呼ぶ)かのいずれかである。例えば、完全すなわち「絶対」ＵＲ Ｌは次のようなエレメントを含む。 方式 −これは、目標資源にアクセスするために使用されるアクセ ス方式である。 ホスト −インターネット・ホスト・ドメイン名またはＩＰアドレス 。 ポート −（ＴＣＰ）接続のためのホスト・ポート。 絶対経路 −ホスト上の資源の絶対経路。 実際には、ポート８０が想定される場合「ポート」は省略できる。 図５は、ヒューレット・パッカード製品ウェルカム・ページのためのＵＲＬを示 している。この場合エレメントは次の通りである。 方式 −http ホスト −www.hp.com ポート −省略(ポート８０が仮定されている) 絶対経路 −Products.html ＨＴＴＰプロトコルは、要求／応答パラダイムに基づいている。図４を再び参 照すれば、アクセスされるべき資源３０を識別する特定のＵＲＩを所与とすれば 、クライアントは、ＵＲＩの「ホスト」エレメントに対応するサーバー３１との 接続を確立してそのサーバーに要求を送る。この要求は、要求方法および「要求 ＵＲＩ」を含む(「要求ＵＲＩ」は一般的にＵＲＩの絶対経路によって識別され るサーバー上の資源の絶対経路そのものである)。要求は付加的データ・エレメ ントを含むこともある。サーバー３１は次に(この例では記憶装置３７に記憶さ れている)資源３６にアクセスし応答する。この応答は、ＭＩＭＥ(すなわちMult ipurpose Internet Mail Extensions汎用インターネット・メール拡張)タイプに よって識別されるタイプを持つエンティティを含む。 主な要求方法は次の２つである。 ＧＥＴ − この方法は、要求ＵＲＩによって識別されるいかなる情報をも(エ ンティティの形式で)取り出す。重要な点であるが、要求ＵＲＩが データ作成プロセスを参照している場合応答においてエンティティ として返されるものは作成されたデータであり、プロセスのソース ・テキストではない。 ＰＯＳＴ − 宛先サーバーが要求ＵＲＩによって識別される新しい従属資源とし て要求に含まれたエンティティを受け入れることを要求するために この方法が使用される。ポスト方法は、既存の資源の注釈付けのた めに使用できる。すなわち、この方法は、例えば、掲示板にメッセ ージを提供し、データ処理プロセスにデータ(例えば形式を提出す る結果として作成されたデータ)を提供し、追加演算を通してデー タベースを拡張する。 要約すれば、ＧＥＴ方法は、直接データを取り出すためか、あるいは、(例えば データあるいはプロセスを実行結果の単なる指示である)エンティティを返すプ ロセスを起動するために使用される。ＰＯＳＴ方法は、データを登録し、この方 法がポストされたデータを適切に処理するためサーバーにおけるプロセスを起動 させる上で効果的であることを示すために使用される。 ＧＥＴまたはＰＯＳＴいずれかの方法を使用してサーバー上での実行を起動さ れるプロセスへの情報の伝達は、現在、コモン・ゲートウェイ・インターフェー ス(すなわちＣＧＩ)と呼ばれるインタフェースに従って行われている。受け取り プロセスはスクリプト言語で書かれることが多い(必ずしも必須ではないが)。典 型的には、起動されるサーバー・スクリプトは、ＧＥＴ要求に含まれる照会を取 り扱うためデータベースへのインタフェーシングのため使用される。もう一つの 用途は、上述のよう、ＰＯＳＴ要求に関連したデータをデータベースへ追加する ことである。 ＷＷＷの成功におけるその他の重要な要因は、ＷＷＷ上に伝送されるドキュメ ントの構成を表現するハイパーテキスト・マークアップ・ランゲージ(すなわち ＨＴＭＬ)の使用、および、そのようなドキュメントをクライアント端末のユー ザに提示するためそれらを解釈するNetscapeやMosaicのような強力なグラフィッ ク・ウェブ・ブラウザの存在である。基本的には、ＨＴＭＬはタイトルまたはグ ラフィックのようなドキュメントの各部分を識別するために使用され、次に各ド キュメント部分を表示する方法の決定はクライアント端末で実行されるブラウザ にまかされる。しかしながら、ＨＴＭＬはそれ以上のものであり、ＵＲＩおよび 要求方法を(特定のワードまたは画像のような)ドキュメントのすべてのエレメン トに関連づけることを可能にし、従って、ユーザがそのエレメントをポイントし クリックすると、ＵＲＩによって識別された資源が、指定された方式(プロトコ ル)および要求方法に従ってアクセスされる。このような構成によって、１つの ドキュメントから他のドキュメントへのハイパーリンク(複合接続)が提供される 。そのようなハイパーリンクを使用して、クライアント端末におけるユーザは、 世界の一方の側にあるサーバーからダウンロードされたドキュメントを世界の別 の側のサーバー上に位置する別のドキュメントへ苦もなく飛ぶ(すなわちスキッ プする)ことができる。１人の作者によって作成されたドキュメントが別の作者 によって作成されたドキュメントへのハイパーリンクを含むこともあるので、中 央集権的制御なしに非常に強力なドキュメント相互参照システムが実現する。 ハイパーリンクは、ＨＴＭＬドキュメントに組み込むことができる唯一の機能 ではない。もう１つの強力な機能は、ダウンロードされた「形式」ドキュメント に画面上で記入し、入力された情報を収集するように設計された(データベース のような)資源に入力情報を渡してもらうため「提示(commit)」ボタンを起動さ せる能力である。これは、ＰＯＳＴ要求をデータベース資源のＵＲＩと共に'com mit'ボタンをＰＯＳＴ要求方法に関連づけることによって達成される。'commit' ボタンの起動によって、入力された情報は、適切に処理される場所である、識別 された資源に渡される。 更にもう１つの強力な可能性は、(一般的には翻訳されるべきスクリプトであ る)プログラム・コードをグラフィック・ボタンのような特定のドキュメント・ エレメントに関連づける機能である。この場合プログラム・コードはボタンが起 動されると実行を開始する。これは、ユーザに対し、資源からのプログラム・コ ードのダウンロードおよびその実行の可能性を与える。 当業者に認められることであろうが、ＨＴＭＬは、上記概説した機能性を提供 するいくつかの現在利用できるスクリプト言語のうちの１つにすぎず、いかなる ウェブ・ブラウザも複数のスクリプト言語の組み込みサポートを持つであろうこ とは予想することができる。例えば、Netscape 2.0は、HTML 3.0、Javaおよび(N etscape版権所有スクリプト言語である)Livescriptをサポートする。 グラフィック・ウェブ・ブラウザ自体の役割の重要性は看過されてはならない 。複数のスクリプト言語をサポートする能力に加えて、ウェブ・ブラウザは、標 準的媒体タイプに対する組み込みサポートおよびクライアントにプログラムをロ ードし実行する機能などを提供する。このようなブラウザは、ＷＷＷ交信に関す るオペレーティング・システムとみなされることもできる。ＷＷＷおよび電話ネットワーク 音声入力をデジタル化してインターネット上に離散的パケットの形で送信し、そ れ端末で受け取って再組み立てすることによって接続された端末の間でインター ネットを経由して電話通信サービスを提供することは可能である。これは、イン ターネット上の通信サービスの１例である。反対に、フランスで広く利用されて いるMinitelのような電話システム上で提供される種々の情報サービスが可能で ある。しかしながら、相互の伝統的領域へのこのような浸透はインターネットま たは公共電話システムにとって本当の脅威とならない。 一層関心があるのはインターネットおよび電話システムの協調使用の分野であ る。実際、図４を参照して記述したものの中にそのような分野の１つがある。そ れは、インターネットへのダイヤルアップＩＰアクセスを取得するためユーザ・ コンピュータ３４からインターネット・サービス・プロバイダ３３へのＰＳＴＮ 上のモデム・リンクの使用である。この協調使用は、非常に単純な特性を持って いる。すなわち、後に生成されるインターネット・トラフィックのためのＰＳＴ Ｎ上の搬送体経路の設定である。インターネットおよびＰＳＴＮの間には実際の 交信はない。 インターネットとＰＳＴＮの協調使用のもう１つの既知の例は、最近実施され たもので、端末コンピュータにサウンド・カードを持つインターネット・ユーザ が世界中のどこにでもある標準電話に音声通話を行うことができるサービスであ る。これは、インターネット上でデジタル化された音声を宛先電話の近くのサー ビス・プロバイダに伝送することによって達成される。このサービス・プロバイ ダは、所望の電話にアクセスするためローカルのＰＳＴＮに接続して、インター ネット上で受け取った音声トラフィックをそのローカルＰＳＴＮへ転送する。呼 ばれた電話からの音声入力は逆経路で取り扱われる。このサービスの鍵は、宛先 電話にとって(料金的に)ローカルなサービス・プロバイダを識別する能力である 。長距離呼び出しに関して通信操作員に対する競争の可能性をもたらしてはいる がこの構成もまたインターネットとＰＳＴＮの単純な相互連携である。しかしな がら、この場合、注意すべきことであるが、宛先にとってローカルなＰＳＴＮ上 で宛先電話に対して行われている呼び出しの進捗状況に関してインターネット呼 び出し側へ少なくとも最小限度のフィードバックを提供することが必要である。 このフィードバックは、単に呼び出しが成功したか否かという観点からのもので よい。 インターネットと電話システムの現在の協調使用が非常に単純なレベルにある ことは以上の記述から明らかである。 ＰＳＴＮおよびＷＷＷの統合を実施する通信ネットワーク上でサービス資源項 目にアクセスする方法を提供することが本発明の目的である。 発明の開示 本発明に従って、交換遠隔通信システムを経由する搬送体経路の設定に関する 使用のためサービス資源項目にアクセスする方法が提供される。該方法は、 (a)--対応する既知のＵＲＩによってコンピュータ・ネットワーク上での位置を 特定することができる複数のサービス資源項目を有する上記コンピュータ・ネ ットワークに接続する少なくとも１つのサーバーを提供するステップであって、 上記コンピュータ・ネットワークが遠隔通信システムとは論理的に独立していて 、上記サービス資源項目が、それぞれあらかじめ定められたコードに関連づけら れているサービス資源項目を持つ上記遠隔通信システムを通る搬送体経路に関す る設定制御に関連していて、上記あらかじめ定められたコードが上記ＵＲＩとは 異なるもので上記搬送体経路に関する終端エンティティを識別する、ステップ、 (b)--上記あらかじめ定められたコードの各々とそのあらかじめ定められたコー ドに関連づけられるサービス資源の上記既知のＵＲＩの間の対応関係を提供する ステップ、および、 (c)--上記あらかじめ定められたコードを利用して、上記対応関係の使用によっ て対応する上記サービス資源項目にアクセスして当該サービス資源項目に対応す るＵＲＩを決定して、次にこのＵＲＩを使用して上記コンピュータ・ネットワー ク上のサービス資源項目にアクセスするステップ、 を含む。 １つの実施形態において、ＵＲＩのすくなくともいくつかは、上記対応付関係 によって指定される関数に従う取り扱いによって対応する上記あらかじめ定めら れたコードから導出することが可能である。また、別の実施形態において、ＵＲ Ｉのすくなくともいくつかは、上記対応関係に従って上記あらかじめ定められた コードとＵＲＩを関連づける関連テーブルにおける照合によって対応する上記あ らかじめ定められたコードから導出することが可能である。 好ましくは、上記関連テーブルがコンピュータ・ネットワークに接続する少な くとも１つのデータベース・サーバ一上に保持されていて、上記ステップ(c)が 、コンピュータ・ネットワーク上のデータベース・サーバーにアクセスして上記 あらかじめ定められたコードに対応するＵＲＩを決定するサブステップを含む。 また、好ましくは、上記少なくと１つのデータベース・サーバーはＤＮＳタイ プ分散データベース・システムよって提供され、ＵＲＩがレコードの取り出しを 行うために使用されるドメイン名と呼ばれるそれぞれの名前に関連づけされたレ コードに保持される。この場合、上記ステップ(c)は、上記あらかじめ定められ たコードを対応するドメイン名に変換するサブステップおよびこのドメイン名を 使用してＤＮＳタイプ分散データベース・システムから所望のサービス資源項目 を取り出すサブステップを含む。 複数のサービス資源が同一のＵＲＩに位置することが可能であり、この場合、 それらサービス資源項目のあらかじめ定められたコードが同一のＵＲＩにおける サービス資源項目の中から所望のサービス資源項目を識別するためサービス資源 項目を保持するサーバーにおいて使用されることができるそれぞれの相対的資源 識別子値を含む。 遠隔通信システムが、呼び出し側の電話番号または呼び出され側の電話番号の いずれかである上記あらかじめ定められたコードを持つ電話システムであること もできる。１つの好ましい実施形態において、上記あらかじめ定められたコード の少なくともいくつかは呼び出され側電話番号であり、対応するサービス資源項 目が呼び出され側の現在時点電話番号である。 一般的には、サービス資源の特性に関しては、これら資源のタイプは以下の通 りである。 --アクセスされ次第対応するサーバーによって実行されるように意図されるサー ビス論理。この実行の結果はアクヤスしているエンティティに返される。 --アクセスされ次第アクセスしているエンティティにダウンロードされるように 意図されているダウンロード・サービス・データ。 --アクセスされ次第実行のためアクセスしているエンティティにダウンロード されるように意図されているダウンロード・サービス論理。 --少くともログ・メッセージの発生を記録する記録資源。 好ましくは、上記ＵＲＩはＵＲＬおよびＵＲＮのいずれかまたは両者である。 更に、上記サーバーは、好ましくは、ＨＴＴＰサーバーである。 コンピュータ・ネットワークが遠隔通信システムとは論理的に独立していると いう上記記述は、２つの物理的な分離が存在することを示唆するものととられる べきではない。実際、同じ物理的下部構造をそれらはしばしば共用している。更 に、遠隔通信システムにおいて設定される搬送体経路はコンピュータ・ネットワ ークと同じ伝送媒体を共有するかもしれないが、そのような搬送体経路はコンピ ュータ・ネットワークにわたるトラフィックのためのパイプの役を果たすかもし れない。コンピュータ・ネットワークが遠隔通信システムとは論理的に独立して いることを必要とする意図は、搬送体ネットワークの管理および監視専用のため のコンピュータ・ネットワークを除外しながら、遠隔通信システム自体の一部を 効果的に構成することである。 好ましくは、コンピュータ・ネットワークは、一般的に、遠隔通信システムの ユーザからアクセスすることが可能である。コンピュータ・ネットワークが遠隔 通信システムのユーザにアクセスできるという記述は、遠隔通信システムのすべ てのユーザがそのようなアクセスを持つかあるいはそのようなアクセスを得るこ とができると解釈されるべきではなく、むしろ、そのようなユーザの大部分がコ ンピュータ・ネットワークへのアクセスを持つか取得することができるというこ とを意味すると理解されるべきである。 本発明の１つの実施形態において、コンピュータ・ネットワークはインターネ ットであって、それは遠隔通信システムのユーザにとって一般的にアクセス可能 であるが遠隔通信システムとは論理的に独立している。また、遠隔通信システム は公共電話システムである。別の実施形態において、遠隔通信システムはＰＡＢ Ｘを含むプライベート・システムであり、コンピュータ・ネットワークはＬＡＮ である。 図面の簡単な説明 下記の添付図面を参照しながら、制約を持たない例を用いて、以下に本発明の 実施形態を記述する。 図１は、標準的ＰＳＴＮを単純化して示したブロック図である。 図２は、 ＩＮサービスを持つ既知のＰＳＴＮを単純化して示したブロック図で ある。 図３は、 インターネットのＤＮＳによるホスト・ドメイン名解決を示すブロッ ク図である。 図４は、 ワールド・ワイド・ウェブの機能性を示すブロック図である。 図５は、 標準的ＵＲＬ形式を示すブロック図である。 図６は、 サービス資源項目がＰＳＴＮのサービス制御サブシステムおよびウェ ブ・ユーザの両者によるアクセス可能なＨＴＴＰサーバー上に保持さ れている本発明の第１の実施形態を示すブロック図である。 図７は、 図６のＳＣＰによるサービス要求の処理を示す流れ図である。 図８は、 サービス資源項目にアクセスする時図６のＳＣＰによって使用される 資源コードの形式を示すブロック図である。 図９は、 サービス・コードがＲＲＩ部分を含まない場合におけるサービス資源 にアクセスするプロセスの流れ図である。 図１０は、サービス・コードがＲＲＩ部分を含む場合におけるサービス資源にア クセスするプロセスの流れ図である。 図１１は、入力電話番号を解析することによってサービス資源のＵＲを導出する プロセスの流れ図である。 図１２Ａは、あらかじめ定められたセットの電話番号を解析することによって導 出されるドメイン名によって構成される名前空間(すなわち’telna me space’)を示すブロック図である。 図１２Ｂは、細分化なしでtelnet spaceをＤＮＳに編入する様態を示すブロック 図である。 図１２Ｃは、細分化された形態でtelnet spaceをＤＮＳに編入する様態を示すブ ロック図である。 図１３は、標準電話でダイヤルされた電話番号に応答して徘徊番号サービスを提 供する際の図６の実施形態の全般的動作を示すブロック図である。 図１４は、ウェブ端末に組み込まれた電話インタフェースを通して呼び出しを設 定する際にウェブ・ユーザによって利用される場合の図６の実施形態 の全般的動作を示すブロック図である。 図１５は、電話トラフィックに対してＰＳＴＮとインターネットの間のインタフ ェースが提供される本発明の第２の実施形態のブロック図である。 図１６は、ＰＳＴＮとインターネットの間で呼び出し設定ゲートウェイが提供さ れる本発明の別の実施形態を示すブロック図である。 図１７は、着信無料電話サービスがウェブ・ユーザのために実施される本発明の 更に別の実施形態を示すブロック図である。 図１８は、ＰＳＴＮのサービス制御サブシステムのエレメントを相互接続する分 散処理環境の提供を示す図６と同様のブロック図である。 発明の実施形態 図６は、少なくその一部が、(ＩＰに関連づけられたＳＳＰ４１である電話中 継線および交換機を含む)相互交換ネットワーク１３、(電話４０のような)顧客 機器をネットワーク１３に接続するアクセス・ネットワーク１１、および要求に 基づいてＳＳＰ４１に対してサービスを提供する少くとも１つのＳＣＰを含むサ ービス制御サブシステム４２を従来の通り含むＰＳＴＮにおける諸サービスを提 供する構成を示している。図６のＰＳＴＮ表現は非常に図式化されている点は認 められることであろう。 ＳＣＰ４３は、従来技術の方法でＳＳＰ４１からのサービス要求に応答して、 サービス要求に含まれる情報に従って特定のデータに対する特定のサービス論理 を実行させ、呼び出し設定を実行するための適切な命令を要求元ＳＳＰに送り戻 す。ＳＳＰは、トリガー・チェック・ポイントにおいて充足されるあらかじめ定 められたトリガー条件に応答して、サービス要求を生成する。チェック・ポイン トは呼び出しを処理する過程において１つまたは複数存在する(注意すべきは、 トリガー条件がＳＣＰからＳＳＰへダウンロードされた場合トリガー条件が満た され次第ＳＣＰにコンタクトする時ＳＳＰはＳＣＰによる情報要求に応答してい るといえるが、本明細書では、ＳＳＰからＳＣＰへのこのような初期的通信を「 サービス要求」と呼ぶ)。 ＳＣＰ４３は、また、ＳＳＰ４１からの少なくとも特定のサービス要求の処理 の過程において特定のサービス資源項目(以下単にサービス資源と呼ぶ)４９を利 用するためインターネット５０に対するネットワーク・アクセス・インタフェー ス４４を備えている。これらサービス資源４９は、ＨＴＴＰサーバー５１上で( 特にこれらサーバー５１のサービス資源データベース５２上で)ＷＷＷページと して保持されている。 これらサービス資源を含むＷＷＷページを以下「電話」ページと呼ぶ。サーバ ー５１がインターネットに接続され、電話ページはＵＲＬまたはＵＲＮを使用し てアクセスされ読み取られる(便宜上、以下の記述ではＵＲＬまたはＵＲＮの代 わりに、電話ページの位置のインターネットで解釈可能な識別子を意味するよう に、より一般的用語ＵＲＩを使用する)。 サービス資源は場合によってはサービス論理またはサービス・データである。 サービス資源は、適切なＵＲＩを使用して必要とされる資源の電話ページにアク セスすることによって、ＳＣＰの上で動くその他の標準サービス論理プログラム によって使用されることもできる。一定のケースにおいて、サービス資源４９は 、特定のサービスに関連づけされたサービス制御およびデータのすべてを実質的 に提供するかもしれない。この場合、ＳＣＰ４３の中で動くサービス論理プログ ラムは骨組みの形式であり、サービス要求の受領とともにインスタンス化され、 サービス資源アクセスを始動し、そのアクセス結果をサービス要求を行ったエン ティティに返すように機能する。実際、このようなアプローチに従って、ＳＣＰ は電話サービス論理を取り出し実行するプラットホームとして容易に実施するこ とが可能であり、標準のＳＣＰプラットホームによって要求されるような論理の ための複雑な準備／管理システムを必要としない。ＳＣＰはおそらくあらゆるＳ ＳＰと関連するようにいたるところに存在させることができる。 図７は、ＳＣＰ４３が電話ページ・サービス資源にアクセスすることによって サービス要求を取り扱う場合の事象のプロセスを示す流れ図である。ＩＮＡＰメ ッセージにおいてサービス要求を受領するとともに(ステップ１００)、ＳＣＰ４ ３は、当業者に理解される標準的方法でＴＣＡＰ／ＩＮＡＰメッセージを解読す る(ステップ１０１および１０２)。次に、ＳＣＰ４３は、要求を処理するためサ ービス論理プログラム(すなわちＳＬＰ)をインスタンス化する(ステップ１０３) 。次に、このＳＬＰは、サービス要求に含まれる情報から判断される要求サービ ス資源のＵＲＬを調べる責任を持つ(ステップ１０４、１０５)。例えば、サービ ス要求が呼び出され側サービスに関するものであれば、要求資源はダイヤルされ た番号によって示され、その番号を使用して資源のＵＲＬが導出される。要求サ ービス資源のＵＲＬが確認されたならば、(例えばＨＴＴＰ要求メッセージの形 式で)資源要求がインターネットを経由して要求されたサービス資源を持つ対応 するサーバーに送られる(ステップ１０６)。また、サーバーからの応答が適切な Ｓ ＬＰインスタンスにリンクされることを可能にするように相関ＩＤ(correlation ID)も送られる。またタイマが始動される(ステップ１０７)。 (ステップ１０８で検査される)タイムアウト期間の満了の前にアクセスされた 資源から応答が受け取られると、通常は宛先番号の形式である応答が、応答と共 に渡された相関ＩＤを使用して識別される適切なＳＬＰに送られる(ステップ１ ０９)。次に、ＩＮＡＰ／ＴＣＡＰ応答メッセージが準備され、オリジナルのサ ービス要求を行ったエンティティへ送られる(ステップ１１０および１１１)。そ の後、ＳＬＰセッションは終了する(ステップ１１３)。 ステップ１０８で、応答が受けられる前にタイムアウトが発生する場合、顧客 レコードからデフォルトの応答値（一般的にはデフォルトの宛先番号)が取り出 され、ＩＮＡＰ／ＴＣＡＰメッセ時に書き込まれ、要求元エンティティへ送り返 される(ステップ１１４および１１６)。その後、ＳＬＰセッションは終了する( ステップ１１３)。サービス資源の位置確認およびアクセス 電話ページ資源にアクセスすることに関連する機能性は、図６の資源アクセス ・ブロック４６によって表される。ブロック４６は、ブロック４６に渡されるパ ラメータに基づいて要求された資源を含む電話ページのＵＲＩを決定するＵＲＩ 決定ブロック４７を含む。次に、ブロック４７によって返されるＵＲＩを使用し て、資源アクセス・ブロック４６はインタフェース４４を経由してインターネッ ト上で所望のサービス資源４９の電話ページにアクセスする。 資源コード−１つまたは複数のサービス資源が特定の電話番号と関連すること は可能である。この場合、資源アクセス・ブロック４６は、該当するサービス資 源を識別することができるように、(現在時呼び出しポイントすなわちpoint- in-call略してpicのような)追加情報を知る必要がある。１つの番号に関連づけ らた(複数)サービス資源が異なる電話ページに位置しているとすれば、適切な電 話ページのＵＲＩを返すことを可能にするため、上記追加情報がＵＲＩ決定ブロ ック４７へ渡される。１つの番号に関連づけられるサービス資源のすべてを同一 の電話ページ上に位置させることも可能である。この場合、資源アクセス・ブロ ック４６は、追加情報を使用してアクセス要求と共に資源識別パラメータを対象 電話ページに送る。そこで正しいサービス資源へのアクセスは電話ページに関連 する機能性に依存する。 このように、各サービス資源はそれぞれ対応する資源コード５４によって識別 されることができるが、図８に示されるように、資源コード５４は、第１部分と 第２部分からなり、第１部分は、その資源がインターネット上で位置するＵＲＩ を識別するＵＲＩ識別子(略してＵＩと呼ぶ)であり、第２部分は、同−ＵＲＩに おける複数資源の中から該当資源を識別するために使用される相対的資源識別子 (略してＲＲＩと呼ぶ)である。 資源アクセス−１つのサービス資源４９だけがユニークなＵＲＩによって識別 される電話ページ５８に位置する場合、資源コード５４は、単にＵＩを含むだけ である。この場合ＵＩは、一般的には、電話番号、または、電話番号プラスpic パラメータのいずれかである(図９参照)。この場合、資源へのアクセスは、全部 の資源コード５４を対応するＵＲＩにマップし(プロセス５５)、次に対応する電 話ページ５８に要求５７を送ることを含む。この電話ページ自体が所望のサービ ス資源４９を構成している。資源４９へのアクセスの結果は応答メッセージ５９ として返される。 対照的に、複数のサービス資源４９が同じ電話５８ページに位置する場合、図 １０に示されるように、資源コード５４はＵＩおよびＲＲＩの両方を含む。一般 的には、ＵＩは電話番号であり、ＲＲＩは、複数共存資源を区別するpicなどの パラメータである。この場合、資源へのアクセスは、資源コード５４のＵＩ部分 を対応するＵＲＩに対応付けして(プロセス５５)、次に、該当する電話ページへ 資源コードのＲＲＩを含む要求５７を送信する(プロセス５６)ことを必要とする 。電話５８ページは、要求メッセージの中のＲＲＩに基づいて所望の資源にアク セスする機能性６４を含む。次に、所望の資源４９へのアクセスの結果が応答メ ッセージ５９の中に含まれて返される。 １つの電話ページ上で他の資源と共存するサービス資源へアクセスする図１０ の方法に対する代替方法は、資源コードのＵＩ部分から導出されるＵＲＩを使用 してインターネットにわたる全ページを取り出し、ＲＲＩに基づいて所望の資源 を抽出するものである。 資源コードからのＵＲＩ決定−プロ七ス５５を実行するＵＲＩ決定ブロック４ ７の実施形態を次に記述する。ブロック４７の実施形態には次の４つの形態があ る。 直接入力 必ずしも便利ではないが、呼び出し側が所望のＵＲＩを直接入力するように 構成することは可能である。この場合、呼び出し側は、(ホスト・ドメイン 名またはホストＩＰアドレスの形式のいずれかである)所望のＵＲＩのホス トＩＤコンポーネントおよびＵＲＩの経路コンポーネントを入力する。例え ば、呼び出される側の電話ページがアクセスされるべきものである場合、呼 び出し側は呼び出される側のＵＲＩを入力するかもしれないが、この入力が 実際に通常の電話番号入力であることもある。ＵＲＩとしての入力であるこ とを識別するため、(例えば'９９９'のような)ストリングを先頭に入力する こともできる。入力手段に関する限り、ユーザが標準の１２キー電話だけを 持っている場合、アルファベット文字を必要とするホスト・ドメイン名およ びその他のＵＲＩエレメントは、電話パッドから入力されるアルファベット 文字に関する標準的技術の１つの使用を必要とする(そのような技術は、例 えば呼び出し側が呼び出され側の名前の綴りを入力することを可能にするた め既に使用されている)。ＵＲＩ入力を容易にするためユーザにすべての英 数字キーを含むキーパッドを提供することも可能である。 計算 インターネット上でのサービス資源アクセスは、対応するＵＲＩを計算でき る元となるダイヤル番号セットに制約される可能性がある。この場合、この 計算はブロック４７の責任である。 関連テーブル照合 ブロック４７に関する最も単純な実施形態は、ＵＲＩを各資源コードのＵＩ 部分に関連づける(メモリまたはデータベース・ディスク記憶装置４８のい ずれかの形での)関連テーブルである。このアプローチにまつわる潜在的問 題は、世界の別の側にある呼び出され側番号に関するサービス資源が必要と されるかもしれないということであり、これは、関連テーブルの最新性を維 持するための世界的規模でのＰＳＴＮ操作員間の厳格な更新制度を意味する 。(注：サービス要求を起動するため必要とされるものとして呼び出されれ 側番号をマークすることに関しては、８００番サービスにおけるように、そ の番号を該当するサービス要求を起動するすべての番号のグループの１つで あるように取り決めることができるので、上記のような問題は必ずしもあて はまらない)。 ＤＮＳタイプ照合 資源コードのＵＩ部分を対応するＵＲＩに変換するための代替的照合方法は 、 インターネットのドメイン名システム(ＤＮＳ)に対するものと同様な、階層 構造分散データベース・システムを使用することである。詳細は後述するが 、このアプローチは、典型的には、ＵＲＩに関連づけられる番号に関して各 ＰＳＴＮ操作員によって維持されるデータベースを必要とする。これらデー タベースは、ＤＮＳの場合と同様に該当するデータベースに向けられる変換 要求を用いてインターネットのようなネットワークを経由してすべてのＰＳ ＴＮによってアクセスできる。この場合、ブロック４７は、インタフェース ４４を経由してインターネット上でＵＩ変換を要求するように設計される適 切な変換プログラムによって構成される。 ＵＲＩ決定ブロック４７に関するＤＮＳタイプ照合の実施形態を記述する前に 、いくつかの一般的コメントを記述する。ＵＲＩ決定のためどのような方法が使 用されるとしても、ＵＲＩにおかれる制約が限定的であれば一定の単純化は可能 である。特に、以下のケースにおいてはＵＲＩのすべてのコンポーネントを決定 することは必要でない。 (i) ＵＲＩパス・コンポーネントの一部がすべてのサービス資源に対する標準で あり得る。この標準部分は、他のＵＲＩが決定されたならば、ブロック４７ によって容易に加えられる。例えば、徘徊番号を照合しなければならない場 合、徘徊番号が、便宜上常に特定サーバー上の加入者のディレクトリのサブ ディレクトリ"tel"のファイル"roam(徘徊)"に保持されているかもしれない 。この場合、ＵＲＩホスト・コンポーネントおよびパス・コンポーネントの 加入者固有部分が最初に決定され、次に、残りのパス部分"/tel/roam"が加 えられる。 (ii)ＵＲＩパス・コンポーネントが資源コードのあらかじめ定められた部分と同 じものであるように構成できる。この場合、ブロック４７はホスト・コンポ ーネントだけを決定し次にパスを加えるだけでよい。例えば、ホスト機械上 でのユニークさを高い確率で保つためパスは常に対象電話番号または終端文 字で終了しなけれならないことは理解されるであろう。パスはまたブロック ４７によって加えられるべき標準コンポーネントを含むかもしれない。 (iii)ＵＲＩのホスト・コンポーネントを決定するため電話番号の部分だけを使 用すればよいように、電話番号のブロックが同じホスト・サーバーに置かれ る対応するサービス資源を持つ場合である。この場合、パス・コンポーネン トは便宜的に各電話番号の全部または一部を含む。この状況は、電話操作員 による厳格な制御を示唆し、電話ユーザはユーザの電話ページを置くホスト ・サーバーを選択する自由を持たない。 ＵＲＩがどのように決定されるとしても、ＵＲＩのホスト・コンポーネントは ホスト・ドメイン名かホストＩＰアドレスのいずれかの形式で提供されるという 点は注意すべきである。ホストがドメイン名によって識別される場合、ＵＲＩホ スト名のＩＰアドレスへの更なる変換は、インターネットのドメイン名システム を使用してインタフェース４４によって標準的方法で実行される。ホスト識別が ＩＰアドレスとして直接提供されるとすれば、この更なる変換は回避できる。 ＵＲＩ変換に番号を提供するためデータベース照合が使用される場合、このデ ータベースは、その他の顧客関係情報を含む顧客データベースと独立していても あるいは組み合わされていてもよい。この選択に影響を及ぼす要因として、一方 には、番号ＵＲＩ変換情報を広く利用できるようにしたいという要求があり、他 方には、他の顧客関係情報へのアクセスを制限したいという要求がある。ＤＮＳタイプＵＲＩ照合 資源コードのＵＩ部分が電話番号であり、ＵＲＩに関する制約がなく、従って 、ＵＲＩのホストおよびパス・コンポーネント全体が照合によって返されなけれ ばならない場合に関してＵＲＩ決定ブロック４７のＤＮＳタイプ照合の実施形態 の詳細を以下に記述する。プロセス全体の重要な部分は、対象電話番号からのホ ス ト・ドメイン名同等情報の形成である。次に、このドメイン名同等情報は、本実 施形態においてはＤＮＳによって使用されるものに等しい照合メカニズムによっ て対応するＵＲＩに変換される(照合メカニズムは、独立して実施することも可 能ではあるが、実際にはＤＮＳに組み込まれることもある)。 ＤＮＳの特性は、図３を参照して「ＤＮＳタイプ」システムを記述した際に既 に記述した。以下の記述の便宜上、電話番号をＵＲＩ変換機能に提供するように 構成されたＤＮＳタイプ・システムを"DNS-type URI Server"systemの頭文字を とって「Duris」システムと呼称する。 Durisシステムの動作に関連する基本原則は以下の通りである。 -あらゆる電話番号はホスト・ドメイン名に変えることができること(対象電話 番号に関するそのようなホスト・ドメイン名を含む名前空間を以下「telnam e空間」と呼称する)、および、 -ホスト・ドメイン空間におけるあらゆるホスト・ドメイン名に関して、Ｄｕ ｒｉｓシステムによって保持され、対応するＵＲＩを含む登録レコード(以 下Registration Recordの頭文字をとってＲＲと呼称する)が存在すること、 である。 このように、図１１に示されるように、本実施形態において、先ず、資源コード ５４のＵＩ部分を構成する入力電話番号がホスト・ドメイン名を形成するため渡 され(ステップ１２０)、次に、対応するＵＲＩを用いてＲＲを取り出すため(ス テップ１２１)Durisシステムに渡される(図１１ではＤＮＳ自体によってDurisシ ステムに送られるように示されている)。ＵＲＩ照合に続いて、返されたＵＲＩ がドメイン名としてホスト・コンポーネントを持っている場合、ホストＩＰアド レスを取り出すためＤＮＳが使用される(ステップ１２２)。当然のことながら、 ホスト・コンポーネントがＩＰアドレスとしてＲＲに記憶されていればこのステ ップは不要である。次にＵＲＩを使用して該当するサーバーに対する資源要求が 作成され、それが資源コードのＲＲＩ部分に渡される(ステップ１２３) Durisシステムにはいくつかの可能な実施形態がある。 (a)ＤＮＳと独立型。このオプションでは、図１２Ａに示されるように、telname 空間が、telname空間ルート"."を用いて管理されるべき全名前空間を構成する 。この場合、DurisシステムはそのＤＮＳ自体とは独立している。当然のこと ながら、Durisシステムは、ＤＮＳと同じ基本下部構造(すなわちインターネッ ト)あるいは完全に別のネットワークのいずれかを使用することができる。tal name空間が世界中のすべての公共電話番号に対応するすべてのドメイン名を含 む場合、完全な国際電話番号の解析によって、完全に有効なドメイン名が与え られる。もちろん、telname空間が、世界的に事業を行っている会社の範囲内 の内線番号から導出されるような小規模の名前セットである場合もある。 (b)ＤＮＳの範囲内で細分化されてない型のtelname空間。このオプションでは、 telname空間はＤＮＳ名前空間の１つのドメインでありDurisシステムはそのＤ ＮＳ自体によって提供される。このように、telname空間が世界中の公共電話 番号から導出されるすべてのドメイン名を含む場合、telname空間は、図１２ Ｂに示されるように、特別サブドメイン"tel"においてITUというドメインの範 囲内に配置され、telname空間のルートは"tel.itu.int."である。ドメイン"te l.itu.int."を管理する責任はITUが持つこととなる。この後者の例では、完全 に有効なドメイン名を入力電話番号から作り上げるため、telname空間の範囲 内の構造に対応するドメイン名の部分を形成するため解析された後、末尾"tel .itu.int."が付加される。次に完全なドメイン名がＤＮＳに適用され、所望の ＵＲＩを保持する対応するＲＲレコードが取り出される。また、別の例として 、telname空間がヒューレット・パッカード社内の内線番号から導出されたす べての名前であり、telname空間のルートが"tel.hp.com."で、ヒュレテット・ パッカード社がこのドメインを管理する全責任を持つ場合を例としてあげるこ とができる。 (c)ＤＮＳの範囲内で細分化された型のTelname空間。このオプションでは、teln ame空間はＤＮＳ名前空間の複数のドメインの間に分割されていて、Durisシス テムはそのＤＮＳ自体によって提供される。telname空間は世界中の公共電話 番号から導出されたすべてのドメイン名を含む場合、telname空間は、各国ド メインのそれぞれのサブドメイン"tel"の間で分割されることができる。この ように、図１２Ｃで示されるように、フランス(France)の電話番号に対応する telname空間の部分は、"tel.fr."というルートを持ち、英国(UK)の電話番号に 対応するtelname空間の部分は、"tel.uk."というルートを持つ。各々のサブド メイン"tel"を管理する責任は各国にある。この後者の例では、入力電話番号 から完全に有効なドメイン名を作り上げるために、国コードに続く電話番号部 分を解析して国の'tel'サブドメインの範囲内のドメイン名の部分が作成され 、次に、対象国に関して適切なホスト・ドメイン名末尾が加えられる。例えば フランスの電話番号に関しては、解析の前に国コード"33"が番号から取り外さ れ、末尾に"tel.fr."が加えられる。各国に関する末尾は、ローカルの照合テ ーブルに記憶しておくことができる。更に別の例をあげれば、"xco.com"およ よび"yco.com."というそれぞれのＤＮＳドメインを持つ(X社およびY社という) ２つの民間組織が、"tel.xco.com."および"tel.yco.com."に分割されたtelnam e空間を持つ共有Durisシステムを運営することに同意する場合である。この場 合、x社から入力されたすべてのy社の電話番号は、最後が"tel.yco.com."とな る完全に有効なドメイン名に解析される。逆の場合もまた同様である。 次に、ドメイン名の電話番号への解析、換言すれば、ドメイン名の構造を作成 するため文字"."を番号のどこに挿入すべきか考察する。電話番号は上述の通り 各国の番号割り当て方式に従って階層的に組み立てられていることは当然である 。従って、１つのアプローチは、各国の番号割り当て方式の構造に準じて電話番 号を分割してドメイン名を作り上げるものである。例えば、英国の"44144745698 7" という電話番号を取り上げれば、"44"は国コードで、"1447"は４桁の地域コード であり、"456987"は６桁のローカル番号である。この番号を分割して45698.1447 .44というドメイン名を作り上げることができる(注：この場合ラベル順序の反転 はＤＮＳラベルが最後部に配列されるという事実に基づいている)。telname空間 が図１２Ｂに示されているような配置を持つＤＮＳのサブドメインであるとすれ ば、電話番号から導出される完全に有効なドメイン名は、 456987.1447.44.tel.itu.iut. となるであろう。 しかしながら、ホスト名に電話番号を変換する時番号割り当て方式の階層に合 致させようと試みることに必然的に伴う困難性が存在する。第１に、国際番号を 正しく解析するためには、この動作に関与するエンティティの各々が各国の番号 割り当て方式の構造を知っている必要があり、例えば英国におけるように地域コ ードの長さが異なっている場合、必要とされる知識は照合テーブルの形式をとら ねばならないかもしれない。これは、複雑なコンピュータ・タスクではないとは いえ、各国がその電話番号方式およびその修正についてすべての他国に通知しな ければならないことを意味するので、管理上非常に面倒なな問題である。第２の 問題は、６桁または７桁のローカル番号は非常に大きいドメインであるというこ とである。性能上の観点からすればサブドメインを作成することが好ましいが、 それを実行する明確な方法がない。 このような問題は、ドメイン名への電話番号の解析が国家電話番号割り当て方 式の構造に合致しなければならないという制約を放棄することによって、克服す ることが可能である。実際、ＤＮＳサーバーが名前空間の意味について何も知ら ないのであるからそのような方式に従う強い理由はない。従って、各サブドメイ ンのサイズを制限するため例えば１時点で４桁をとるという確定的アルゴリズム を使用して電話番号を解析し、番号方式の知識なしにピリオドを挿入することは 可能である。ＤＮＳサーバーによって提供されるＤＮＳドメインおよび地域が正 しく作成されている限り、すべてうまくはたらく。 国際番号に関する限り、国コードを切り離すことはなお適切に見えるので、既 知の国コードに従ってダイヤルされた番号の最初の部分を解析し、その後(例え ば、3,7または4,6または3,3,4などの)決定性方式を使用して桁を分離するという 複合解析方式が使用される。当然、図１２Ｃに示されるような細分化されたteln ame空間が使用されているとすれば、ホスト名末尾を照合するため国コードが使 用される。解析されるのは番号の国部分だけである。 最後に、ＵＲＩを持つＲＲレコードを保持するためＤＮＳサーバーを設定する 方法の詳細に関しては、O'Reilly & Associates,1992出版のPaul AlbitzおよびC riket Liu両氏著の"DNS and BIND"を参照することができる。この文献はUnix BI NDを使用してＤＮＳサーバーを設定する方法を記述している。ＲＲレコードのタ イプは例えばテキストである。 ＤＮＳラベルの先頭は理論的に数字から始めてはならない点に留意する必要が ある。この規則が保持されるならば、電話番号を解析する時、各ラベルの最初の 文字として標準の文字を挿入することはもちろん容易である。従って、"t"が標 準先頭文字として使用される場合、2826という４桁ラベルは"t2826"となる。 ドメイン名の場合と同様に、(例えばローカル呼び出しが国際番号または地域 コードのような先頭番号を必要としない場合のように)入力電話番号が完全な番 号でない場合、それはローカル・ドメインにおけるドメイン名に変換される。 上記のDurisシステム実施形態は電話番号をＵＲＩに変換する観点からのもの であった。この場合、電話番号は資源コードの完全なＵＩを作成し、Durisシス テムが完全なＵＲＩを返す。ＵＩの形式およびＵＲＩのどの部分が照合されなけ ればならないかという点に関して上述のDurisシステム実施形態に種々の修正を 加えることが可能なことは認められるであろう。例えば、各々がそれ自体のファ イルにおいて加入者と関連した多数の異なるサービス資源が存在し、所望のソー スが資源コードのpic部分によって識別される場合、入力電話番号は完全なＵＲ Ｉではなくホスト・コンポーネントを照合するため使用され、パス・コンポーネ ントのその部分は関連したサブディレクトリに依存し、ＵＩのpic部分が所望の 資源ファイルを識別するため追加される。 小規模なローカルのDuris実施形態については、単一のサーバーを用意すれば よいかもしれない。しかしながら、そのような実施形態も、その他の適切な機能 が備わっていることを前提として、１つのＤＮＳタイプとしてみなされなければ ならない。サービス資源の特性 次に、サービス資源４９がサーバー５１上でどのように提供されるか詳細に考 察する。説明の便宜上、(個人または組織、あるいは、呼び出し側または呼び出 され側を問わず)特定のＰＳＴＮユーザに関連する１つまたは複数のサービス資 源を１つまたは複数のＷＷＷページにおけるユーザ端末５３からインターネット を経由してサーバー５１に配置することができるとする。 サービス資源が電話番号のようなサービス・データ項目であるような単純なケ ース(例えば呼び出し側によってダイヤルされた番号に対応するユーザの電話が 使用中である場合代替番号すなわち転送番号が試行される)を考察する。この転 送番号がユーザの電話ページの唯一のサービス資源である場合もある。電話ペー ジＵＲＩはＨＴＴＰに設定された方式を持つＵＲＬであることがある。この場合 ＧＥＴ方法を使用して転送番号を取り出すことができる。電話ページが転送番号 の機能的取り出しのためにだけ使用されるものであればこのような構成は適当で あろう。しかしながら、転送番号がユーザ端末５３で視覚的に提示されなければ ならないなら、番号に説明的材料を加えることが望ましいかもしれない(転送番 号が文脈情報を既に提供する既存の表示されたページに返されるように構成する ことができるのでこの点は必ずしも頻繁に必要となるわけではない)。しかしな がら、電話ページが、転送番号だけでなく説明的材料を含む場合、電話ページの 機能的利用だけを利用することを望むエンティティは、電話ページを取り出し次 に転送番号を抽出するように構成することが可能である(これはもちろん情報を 識別する標準的方法が電話ページから抽出されなければならいことを必要とする )。 説明的材料を必要とする資源の観察およびそれに対する機能的アクセスを行う ための代替的好ましい構成は、資源設計へのオブジェクト指向アプローチを使用 するものである。この場合、資源オブジェクトは、それに関連づけられる２つの 異なるアクセス方式を持つ。１つは資源の純粋に機能的使用のためのアクセス方 式であり、他方は説明的材料の観察を可能にするためのものである。適切なオブ ジェクト方法を使用して資源オブジェクトにアクセスすることはアクセスしてい るエンティティに委ねられる。 説明的材料を必要とする資源の観察およびそれに対する機能的アクセスを行う ための更に別の構成は、それぞれの使用のため適切に構成され、それぞれがそれ 自身の資源コードを持つ別々の資源を用意するものである(一般にそのような資 源は同じ電話ページ上に置かれ、この場合各資源コードのＵＩ部分は同じである )。 ユーザが人間である場合の使用のための電話検索は、ＰＳＴＮによる使用のた めの検索ほど一般的に時間的に切迫していない。従って、人間の使用のためサー ビス資源のＵＲＬにおいて指定される方式はＨＴＴＰとすることができるが、Ｐ ＳＴＮ使用のためには特別の「電話」方式(アクセス・プロトコル)を定義する方 が利益がある。その方式によって、サーバー５１が最適化されたアクセス・ルー チンを使用して所望の資源(現在の例では転送番号)にアクセスし最小限の可能な 時間でアクセスしているエンティティに応答することができる。 データ項目以外のその他の可能なタイプのサービス資源は、(サーバーにおけ る)実行のためのサービス論理を含み、この実行の結果は資源にアクセスしてい るエンティティに返される。また上記サービス論理はアクセスしているエンティ ティにおける実行のためサーバーからそのエンティティへダウンロードすことが 可能であり、情報を記録するための(または単にアクセスされたという事実を記 録するための)記録資源がアクセスしているエンティティによってサーバーへ渡 される。記録資源は実行可能なサービス論理の特定のケースであることは認めら れることであろう。 例をあげれば、実行可能サービス論理によって構成されたサービス資源が、時 刻に基づく呼び出し機能を実施して、サービス論理の実行の結果、呼び出され側 の時間を考慮した電話番号呼び出しを行うように構成することができる。ダウン ロード可能なサービス論理によって構成されるサービス資源の１つの例は、ＩＰ によって提供される機能を使用して呼び出し側オプションである問い合わせを制 御するサービス論理である。記録資源は特定の番号に対する呼び出し回数を記録 するため使用することができる。 各資源がそれ自身の電話ページを持ち、資源が未装飾の機能という形式にすぎ ない場合、ＨＴＴＰ方式は、ダウンロード可能サービス論理および実行可能サー ビス論理の両者に対するＧＥＴ方法および記録資源に関するＰＯＳＴ使用のアク セスのために使用することが可能である。説明的材料に各サービス資源を備える ことが望まれる場合、データ項目に関して上述された解決策のいずれでも使用す ることができる。 複数のサービス資源が１つの番号と関連づけられるべき場合、そのような資源 の各々は、それ自身のＵＲＩを持つそれぞれの電話ページ上に配置することがで きる。しかしながら、好ましいアプローチは、すべてのサービス資源を同じペー ジ上に配置し、対応する資源コードのＲＲＩ部分を使用して該当する資源へのア クセスを可能にするものである。次にアクセスされた資源はその形式に従って取 り扱われる(すなわち実行可能サービス論理の場合は実行されダウンロード可能 サービス・データまたは論理の場合は返される)。 かくして、転送番号サービス・データ資源および時刻実行サービス論理資源が 同じ電話ページに配置されるとすれば、転送番号資源コードが"1"というＲＲＩ を持ち、一方時刻資源コードが"2"というＲＲＩ値を持つかもしれない。 呼び出し側／呼び出され側オプションがそのような側への提示のためサービス 資源に含められるべき場合、これは、後続のサービス資源に対する要求を始動す る選択されたオプションを含むダウンロード可能なサービス論理としてサービス 資源を構成することによって、実施することができる。 サービス資源は、サービス・データやダウンロード可能なサービス論理および 実行可能サービス論理を組み合わせた複合タイプであることが多い。特に強力な 組み合わせは、ダウンロード可能なサービス論理が実行可能サービス論理と相互 作用するように設計された２つのタイプのサービス論理の組合せである。この構 成を使用して、ユーザに複雑なクライアント／サーバー・タイプ・アプリケーシ ョンを提供することができる。サービス資源の使用例 図１３は、サーバー５１上の資源を利用するサービスの動作を示している。こ のサービスは、「個人番号」サービスに等しいもので、あるユーザがたとえ番号 が実際に異なる電話の間で移動(すなわち徘徊)する時でも単一の不変の番号を通 してそのユーザにアクセスすることができるサービスである。これを達成するた め、このサービスを必要とするユーザ(本例ではユーザＢ)に、ＳＳＰがダイヤル された番号をWebtel(ウェブ電話)として識別できるように同じ先頭番号ストリン グをすべての番号が持つ番号セットから(この例ではＢのWebtel番号と呼ぶ)ユニ ークな個人番号が割り当てられる。ユーザＢは、ＨＴＴＰサーバー５１上の専用 の電話ページにサービス資源４９を持つ。この場合、この電話ページは、本例で は「ＵＲＬ(Ｂ電話ページ)」として識別されているＵＲＬに配置されている。Ｂ の電話ページは、アクセスされると、Ｂに到達することができる現在時徘徊番号 (すなわち"B-telNb")を返す。最も簡単なケースでは、Ｂの電話ページが、Ｂが 異なる電話へ移動するに伴って、(例えば端末５３から)Ｂによって修正される単 一の番号である場合である。Ｂの電話ページが時刻型呼び出し機能を提供する実 行可能サービス論理であるように構成することもできる。 本例においては、ＢのWebtel番号とＢの電話ページのＵＲＬの間の関連性は、 ＳＣＰ４３がアクセス可能な関連テーブルに記憶されている。 ユーザＡがＢのWebtel番号をダイヤルすることによってユーザＢへの連絡を行 おうとする場合、Ａによって使用されている電話４０は、ＳＳＰ４１に対し呼び 出し設定要求を送る(図１３において、最も太めの実線６０は電話ネットワーク を通る搬送体経路を示し、次に太い実線は信号の流れを示している)。ＳＳＰ４ １は、ダイヤルされた番号をWebtel番号として検出して、ＢのWebtel番号と共に サービス要求をＳＣＰ４３へ送る。ＳＣＰ４３は、このサービス要求を受け取る と、ＢのWebtel番号をＢに対する現在時点徘徊番号に変換する動作を制御するサ ービス論理プログラムを始動する。実際には、本例では、このプログラムは、単 に、ＢのWebtel番号(すなわちＢの電話ページ)によって識別されるサービス資源 にアクセスするように資源アクセス・ブロック４６に要求して、このアクセスの 結果を返すにすぎない。すなわち、ブロック４６は、先ず、ＢのWebtel番号をＢ の電話ページのＵＲＬへ変換し、このＵＲＬを用いてインターネットを経由して (例えばＨＴＴＰ ＧＥＴ方法に対応する方法に関連して上述した「電話」方式を 使用して)Ｂの電話ページへアクセスする。この結果、Ｂの現在時点徘徊番号B-t elNbがブロック４６に渡され、次にこの番号がＳＳＰ４１に返され、B-telNbに 対応する電話４０への呼び出し設定が完了する。 図１３は、呼び出され側サービスに関連した例であるが、当然のことながら、 インターネットを経由するサービス資源へのアクセス原理は、呼び出され側およ び呼び出し側の両者ならびにその混合を含むすべてのタイプのサービスに適用す ることができる。このように、標準的な８００番サービスは、８００番のダイヤ ルによって実行可能サービス論理によって構成される電話ページ資源へのアクセ スを行い、呼び出し経路を制御する最も適切な番号を返すように実施することが できる。図１３の例においてＳＳＰからのサービス要求がダイヤルされた番号の 先頭番号ストリングによって起動されたが、サービス要求を呼び出し側番号、呼 び出され側番号またはその他のユーザ入力を含む種々のトリガーによって起動す ることが可能である点は認められるであろう。そのようなトリガーは呼び出し設 定プロセスによって認定されるようにすることもできる(例えば呼び出され側番 号が使用中状態によってまたは一定時間より長いベルによって認定されるように することができる)。 上述の記録サービス資源に関する１つの可能なアプリケーションは、電話投票 である。この場合、投票番号にダイヤルすると、ＳＳＰが呼び出しを取り上げて ＳＣＰ４３へサービス要求を渡す。次に、ＳＣＰ４３がインターネッ上の該当す る記録資源に連絡をとり、投票を登録して、その後呼び出しは完了する。ボトル ネックを最小にするため、記録資源は各ＳＣＰ毎に異なるＵＲＬで用意され、イ ンターネットを経由してこれら記録資源のすべてから投票を収集し分類すること が容易となる。インターネット・アクセスを持つＳＣＰがあらゆるＳＳＰで提供 されるとすれば、混雑の危険は大幅に減らされる。 既に述べたように、ユーザの電話ページが複数のサービス資源を持つ場合があ り、この場合、アクセスしているＳＣＰからのアクセス要求は、所望の資源を識 別する適切なＲＲＩを含む必要がある。 ＳＣＰが一部のユーザへの伝統的ＩＮサービスとその他のユーザへのインター ネット経由サービス資源を使用する同等のサービスの両者を提供すべき場合には 、サービス要求が適切に取り扱われることを確実にするため、ＳＣＰに照合テー ブルが用意されることを必要とするかもしれない。そのような照合テーブルは、 便宜上顧客記録データベースと組み合わせることができるであろう。 ユーザＢのようなユーザが所望のサービス資源(特に個人用のサービスを定義 するサービス論理)を指定する１つまたは複数の電話ページを設定したとすれば 。ユーザＢがどのＰＳＴＮ操作員に対してもそのようなサービス資源にアクセス してそれを活用することを望むのは当然である。Webtel対ＵＲＩデータベースが すべての操作員にとって利用できるならば、これは可能である。このように、複 数の操作員がＢの電話ページにアクセスするように設定することができる。操作 員がＢの電話ページを使用するのを断るならば、(少くともその操作員がユーザ 選択に依存する長距離搬送体サービスを提供する場合には)、Ｂはその操作員を 使用しないことを明確に選択することができる。従って、サービス提供が操作員 の手数を抑えることを止める結果となるが、操作員による電話ページ利用はＰＳ ＴＮ操作の必要な基本的機能になる可能性がある。サービス資源の作成と更新 次に、サーバー５１に対するサービス資源４９がいかに作成されその後更新さ れるかを記述する。 作成に関する限り、２つの基本的アクションが必要である。すなわち、第１に 、サービス資源がサーバー５１上に配置されなければならず、第２に、資源への アクセスを要求するトリガー条件(すなわち番号プラス呼び出しポイントのよう な条件)とともにサービス資源のＵＲＩがＰＳＴＮ操作員へ通知されなければな らない。複数の資源が同じＵＲＩにおいて提供されるならば、特定のトリガー条 件のため適切な資源を取り出すために必要とされるＲＲＩ値も通知されなければ ならない。この通知プロセスは、ＰＳＴＮ操作員に対するサービス資源の「登録 」と呼ばれる。当然のことながら、ＳＣＰ４３によって使用される関連テーブル が設定され、トリガー条件がＳＣＰ４３において設定されることを可能にするた め、登録が必要である。図１３を参照して上述したような一定のサービスに関し て、トリガー番号(図１３の例ではWebtel番号)を供給するのはユーザではなく、 ＰＳＴＮ操作員が登録プロセスの一部として適切な番号をユーザに割り当てるの である。 サーバー５１上にサービス資源を配置するプロセスに関する限り、その実行方 法は、そのようなサービス資源のＰＳＴＮ動作に及ぼす可能な効果に対するＰＳ ＴＮ操作員の態度に依存する。サービス資源がアクセスしているエンティティに データ項目を単に返す場合、操作員は、サービス資源を実施する場合の可能なエ ラー(偶然であるが故意であろうが)についてあまり心配しないかもしれない。し かしながら、操作員は、資源によって返されるかもしれないいかなるサービス論 理の適当な動作に関しては、おそらく、非常に懸念するであろう。実際、操作員 はそのようなサービス資源を許容しない可能性がある。 操作員がサービス資源の実施形態または特性に関心をを持たないと当面仮定す るとすれば、資源がサーバー５１上に配置さる方法は主としてサーバーの特性に 依存する。例えば、ユーザがインターネットへのネットワーク・アクセスのある コンピュータを持ち、このコンピュータがサーバー５１として使用されるとすれ ば、ユーザは外部アクセスのためのＷＷＷ電話ページとしてサーバー上に所望の 資源を単にロードすることができる。サーバーが内部のＬＡＮ上でのアクセスを 持つ組織サーバーである場合同様の状況が起きる。これら２つの場合、ＷＷＷ電 話ページとして資源をロードすること自体はインターネット・アクセスを必要と しない。しかしながら、サーバー５１が外部のインターネット・サービス・プロ バイダによって実行されるとすれば、ユーザは、サーバー上でユーザに割り当て られたウェブサイト空間に所望のサービス資源をダウンロードするように取り計 らうことができる。これは、インターネット・アクセスを含むことも含まないこ ともできる。この後者のシナリオの１つの特別なケースは、ＰＳＴＮ操作員がサ ービス資源を保持するユーザ電話ページに対して特別なサーバーを提供する場合 である。 ユーザ自身のコンピュータがサーバー５１の役をする場合を除いて、サーバー 上にサービス資源を配置することは、一般的には、１つまたは複数のパスワード 保護のレベルを消去することを伴う。 ユーザによってサーバー５１にロードされるサービス資源の起源に関しては、 それはユーザによって生成されるか、あるいは、特に資源がサービス論理を含む 場合、(ＰＳＴＮ操作員を含む)第三者によって提供されるかもしれない。 ＰＳＴＮ操作員がＰＳＴＮの動作に対する悪影響を避けるためサービス資源４ ９を支配することを望むとすれば、２つのアプローチが可能である。第１に、あ らゆる資源(またはおそらく特定のサブセット)が使用の前に検証プロセスに従わ なければならないことを操作員が要求することが可能であり、(特定のデータ項 目を除いて)ユーザによる資源の将来の変更を回避する適切な基準が設けられる 。これに関して、操作員は、(特定のデータ項目を除いて)資源が操作員の制御の 下におかれること、そしてユーザはその資源に対する書き込みアクセス権を持た ないことを求めることができる。第２に、更に魅力的であるが、サービス資源４ ９による悪影響を最小にするアプローチは、ユーザがユーザ自身のデータを追加 することができる(また資源がサービス論理を含む場合制約された機能選択を行 う)標準的サービス資源を操作員が提供するものである。その後、特別仕様の資 源が操作員によって制御されるサーバー５１にロードされる。操作員に制御され たサーバーからユーザがＷＷＷ上でダウンロードすることができるＨＴＭＬ形式 を使用する特定の資源に関してこのプロセスの実施は都合がよい。形式を完成し その形式の「コミット(提示)」ボタンを活動状態にさせると、入力された情報が サーバーへ送られ、そこで、その情報を使用して、特別仕様サービス資源が作成 され、インターネット経由のアクセスに備えてそのサーバー上に配置される。こ のアプローチの利点は、操作員によるサービス資源の登録が同時に実施される点 である。(サービス資源をサーバーにロードさせる動作と別個に登録が行われな ければなら場合、ＨＴＭＬ形式の使用は登録プロセスを実施する非常に便利な方 法であるという点に留意する必要がある)。 上記の点から明らかなように、作成プロセスは情報がインターネット上で渡さ れることを必ずしも必要としないが、多くの場合、特に、ＷＷＷ上で交換される ＨＴＭＬ形式が特別仕様のサービス資源を作成するために使用されることができ る場合には、それは最良の解決策である。ＨＴＭＬ形式を使用して特別仕様のサ ービス資源を作成することはＰＳＴＮ操作員がサーバーを制御する場合に限られ ない点に留意する必要がある。 サービス資源の更新に関しては、特定のデータ項目(例えば徘徊番号)を頻繁に 更新する必要がある場合がある。ＰＳＴＮ操作員がサービス資源４９に対する制 御を持たない場合、更新は比較的簡単な問題であり、単に対象サーバーへの書き 込みアクセスを必要とするにすぎない(上述の通り、これは一般に１つまたは複 数レベルのパスワード保護を伴う)。しかしながら、ＰＳＴＮ操作員がサービス 資源に対する制御を持っている場合、例えば、操作員によって制御されているサ ーバー上への特別仕様サービス資源がロードされるなら標準サービス資源の特別 仕様化を許容するような場合、サービス資源への書き込みアクセスは厳格に制御 されるであろう。この場合もまた、ＨＴＭＬ形式はデータ項目を修正する便利な 媒体として使用されることができる。操作員にとつて、これは可能な修正を制限 する利益を持ち、一方、ユーザにとっては、形式インタフェースが資源修正への 単純な道を提供している。 一層複雑な更新に関しては、初期作成のために必要とされたものと同等なプロ セスを通る必要があろう。特にサービス資源がＰＳＴＮ操作員によって制御され たサーバー５１上に保持されている場合、資源更新は、一般的には、インターネ ット経由の通信を伴う。ウェブ・ユーザ交信 次に、サーバー５１上の電話ページに保持されたサービス資源のその他の可能 な用途を記述する。例えばユーザＢの電話ページが転送番号を含むとすれば、こ の電話ページがインターネット経由でユーザＡの端末５３から読み取りアクセス 可能であると仮定すると、ユーザＡは、端末５３上で動くグラフィカルなウェブ ・ブラウザを使用して、Ｂの電話ページを見てＢの転送番号を見つけることがで きる。前述のように、転送番号は番号の意味を視覚的に表示するためユーザＡに 渡されたり、説明テキストを含めてユーザＡに渡されることがある。 更に一層役立つ例は、ユーザＢに関する現在時転送番号サービスである。Ｂに 到達できる現在時徘徊番号を返すためアクセスされる時サーバー上のＢの電話ペ ージ(図１４参照)が動作可能状態にあると仮定する。更に、ユーザＢがＨＴＭＬ で書かれたいくつかのウェブ・ページのあるウェブサイトを持ち、各ページが、 起動されるとＢの電話ページへそのＵＲＬによってアクセスするためにＧＥＴ方 法を使用する「電話」ボタンを含むと仮定する。そこで、ユーザＡが、ユーザＡ の端末５３からＷＷＷ経由でＢのウェブサイトをブラウズしながら(矢印６６)、 Ｂと会話するためＢに電話することを決めると、ユーザが現在見ているページ上 の電話ボタン６５を活動状態にさせるだけで、ＨＴＴＰ要求"ＧＥＴＵＲＬ(Ｂの 電話ページ)"を使用してＢの電話ページがアクセスされる。 呼び出されるべきＢの現在の電話番号が、決定され、ユーザＡの端末に送られ (矢印６８)そこに表示される。一般的には、番号に関する説明テキストも表示さ れる。例えば「次の番号で私を呼び出してください」というテキストが表示され る。このテキストは、電話ボタンに関連付けされたＨＴＭＬスクリプトによって 提供されることも、現在時番号を返す時電話ページによって提供されることもで きる。実際、更に役立つことであるが、Ｂに到達する現在時番号のみならず、Ｂ に到達できるすべての番号をそれぞれの番号にＢがいる確率の高い時間と共にユ ーザＡに提供することもできる。このような追加情報は頻繁な変更を伴うことが ありがちなので、情報を提供する唯一の賢明な方法は電話ページから行うもので ある。このように、Ｂの電話ページは、Ｂに到達する現在時点番号のみならず、 複数番号と変更のできる時間を含むテキストを提供する。当然のことながら、デ ータの変更は１カ所でのみ実行されなければならないことを確認するようにＢの 電話ページのスクリプトは作成される。 更に別の例は、Ｂの電話ページが、ユーザＡ端末での実行のためにダウンロー ドすることが可能なサービス論理を含む場合である。この例は、更に電話ページ を取り出す後続動作を生成するためのような選択がユーザに提示される場合に役 立つ。例えば、最初にアクセスされた電話ページが、家族のための一般的電話番 号を与えるだけではなく、家族のメンバ各々の時刻別番号のような電話情報の選 択をもユーザに提供する家族電話ページとすることができる。この場合、各家族 メンバは、家族ページに続くそれぞれの電話ページを持つ。 上記のシナリオでは、ユーザＡはＰＳＴＮ経由で呼び出すべき番号を与えられた 。それにより、ユーザＡは自分の標準電話を取り上げ、与えられた番号にダイヤ ルすることができる。実際には、ユーザＡが通常の非ＩＳＤＮのＰＳＴＮ回線上 のＳＬＩＰ／ＰＰＰ接続経由のインターネット・アクセスだけを持つ場合複雑な 問題が起きる。なぜならば、この場合、ゲートウェイ９０がＡの電話への呼び出 しを設定しようとする時Ａの電話回線はインターネット・アクセスを作成するこ ことに既に使用されているからである。ＩＳＤＮを使用していれば、２つの経路 が使用可能であり、この問題は発生しない。この問題を克服する１つの方法は、 呼び出すべき番号をＢの電話ページから取得した後、(アクセスされている現在 時ＷＷＷのＵＲＬのような)必要とされている状態情報を記憶してユーザＡ端末 ５３のインターネット・セッションを中止させ、そのＳＬＩＰ／ＰＰＰ接続を切 断して、それによって電話回線を解放することである。その後、ＡはＢに電話す ることができる。通話の終了とともに、Ａは、記録した状態情報を使用してイン ターネット・セッションを再開して、Ｂを呼び出すためにＡが離れたポイントへ 戻ることができる。代替的アプローチは、Ａに対する電話線上で適当な多重送信 変調方式を動作させ、音声とデータを同時に搬送させるものである。そのような 方式はすでに多数存在する。ＰＳＴＮは次にＡから到来する結合されたデータ／ 音声ストリームをどこかで分離し、それぞれを適切な宛先へ送信する必要がある (インターネット・データはユーザＡのためＳＬＩＰ／ＰＰＰ接続を提供してい るＩＳＰに送られ、音声ストリームはＢへ転送される)。当然のことながら、逆 方向のデータおよび音声はどこかで組み合わされ最終的にＡの端末へ送信される 必要がある。 Ａが標準電話を使用して手動でＢへダイヤルするのではなく、ユーザＡが端末 からＰＳＴＮを経由して呼び出しを行うことを可能にする機能性をユーザＡ端末 に備えることも可能である。この機能性は、一般的には、ウェブ・ブラウザ７３ のようなアプリケーション・ソフトウェアからの入力に応答してインタフェース ７０を駆動する電話線および電話ドライバ・ソフトウェア７１に対するハードウ ェア・インタフェース７０(図１４参照)を含む。Ａはその電話ソフトウェアを立 ち上げ所望の番号を入力するか、あるいは、好ましくは、画面上でＢの電話ペー ジから返された番号をＡが選択するだけで、それがＡの電話ソフトウェアに渡さ れる。実際には、ユーザＢがＡの端末上のダイアル機能性を提供するソフトウェ ア７１に対するソフトウェア・インタフェースを知っていると仮定すれば、Ａが 電話したいと望み次第Ｂの番号を自動的にダイヤルするためＢの電話ページがＡ の端末プログラム・コードへＢの番号を返すことも可能である。音声通話を行う ことに代わるものとして、Ａの端末が適切なモデムおよび制御ソフトウェアを備 えているとすれば、Ａは、ＰＳＴＮを経由して、Ｂの通常の番号またはそのよう な通信のために使用されるべきものとしてＢの電話ページに指定された番号のい ずれかへファックスまたはデータを送ることができる。当然のことながら、Ａの 電話回線がＩＳＤＮでなくＳＬＩＰ／ＰＰＰ接続を経由したインターネット・ア クセスである場合、上述したように、ＰＳＴＮ経由でのＡの端末からの呼び出し は電話線使用の競合という問題を起こす可能性がある。 Ａによってダイヤルされた番号に対応するＢの電話が使用中であればこのよう な問題の可能性は多い。従って、Ｂが転送番号を指定する電話ページを持ち、Ｂ がＰＳＴＮに関してこのサービス資源を登録していれば、転送番号がＰＳＴＮに よって自動的に試行される。しかし、転送番号資源がＰＳＴＮに登録されていな ければ、使用中信号がＡに戻される。Ａが標準電話を通して呼び出しを行う場合 、Ａは通話方法を決定し、Ａはあきらめるか、または、Ｂの電話ページを再度参 照 して転送番号を照合してその番号を使用して再ダイヤルするか、いずれかを選択 する。Ａがその端末５３を使用してオリジナルの呼び出しを行うとすれば、使用 中信号の戻りを検出してＢの転送番号を自動的に検索しその番号に再ダイヤルす るようにＡの端末をプログラムすることができる。この機能性は、Ｂの電話ペー ジからダウンロードされＡの端末上で動くサービス論理に含めることができる。 Ａが音声の使用のため電話線を解放するためそのインターネット・セッション を終了しなければならないとすれば、Ｂの電話ページの再度の参照は、新しいイ ンターネット・セッションの開始を必要とする(実際には、Ｂに対してダイヤル されるべきオリジナルの番号が提供される時点にＢの転送番号が渡されていれば このような不便さは回避される)。 Ｂの電話ページが使用中である場合Ｂの電話ページ上でアクセスされるサービ ス資源は、当然、転送番号よりも一層複雑なものとすることができる。特に、例 えばＢのファックスまたは音声メールボックス番号を含むある範囲のオプション をユーザＡに提示し、オプションの選択によって適切なアクセス・ソフトウェア が始動するという形態が可能である。別のオプションは、ＡがＢの電話ページか らダウンロードした形式を使用してコールバック・メッセージをＢに残すという ものである。記入された形式がサーバー５１へ渡され、Ｂが適時に検査できるよ うに記録される。 当然のことながら、ＡがＢの現在時点徘徊番号を見出すためＢの電話ページに アクセスすることを望んでも、ユーザＡがＢのウェブサイトのＵＲＩを知らずた だＢのWebtel番号だけを持っているということが起きる可能性がある。Ａはただ ＰＳＴＮを通してＢを呼ぶことができる。その場合、ＢのWebtel番号の徘徊番号 への変換は自動的に実行される(Ｂがこのサービスを登録していると仮定する)。 しかしながら、Ａは、Ｂを直ちに呼び出さず、その現在時徘徊番号を書き留める ことを望むかもしれない。Ａの問題を解決するため、好ましくは、前述のWebtel 対ＵＲＩ関連テーブルを(例えば既知のウェブサイトのような)既知のアドレスで インターネット上でアクセスできるようにする。そこで、Ａは、このウェブサイ トにアクセスしてＢのWebtel番号を渡すだけでよい。Ｂの電話ページＵＲＩがＡ に返されるので、Ａはそれを使用してＢの電話ページにアクセスすることができ る。当然、Ａが関連テーブルのウェブサイトへＢのWebtel番号を送る時点からこ のプロセスが自動的に実行されるように構成できる。インターネット／ＰＳＴＮ呼び出しインタフェース 図１４のシナリオにおいて、Ａの電話の実際の形式がＡのコンピュータ端末５ ３に組み込まれたもので標準的電話形式とは相違していたにもかかわらず、ＰＳ ＴＮへのＡのアクセスは標準電話インタフェースを通してのものであった。図１ ５は、図１４の場合のようにＢの徘徊番号が与えられた後、Ａがインターネット 上で始まる経路を経由してＢを呼び出し、ユーザ・ネットワーク・インタフェー スを介してＰＳＴＮに接続する状態を示している。インタフェース８０は、ＰＳ ＴＮ上のＩＳＤＮタイプ電話信号とＩＰパケットの形態でインターネット上を搬 送される対応する信号の間の変換を行い、更に、電話中継線６０上への音声デー タの転送およびその逆方向の転送を行うように構成されている。 従って、ＡがＢへの呼び出しを始動すると、Ａの端末におけるインターネット 電話ソフトウェア８１が、インターネットを経由してインタフェース８０に始動 信号を送信する。この場合、その送信先のアドレスはＡの端末には既知のもので ある。インタフェース８０において、信号はＩＳＤＮタイプ信号に変換され、Ｓ ＳＰ４１に渡される。次に、呼び出し設定が通常の方法で進められ、戻り信号が インターネットを経由してＡ端末におけるソフトウェア８１へインタフェース８ ０を通して送り返される。このソフトウェアは、ＷＷＷブラウザ７３にＡに対す る表示のため呼び出し設定進捗情報を送る。呼び出しが確立されると、Ａは電話 を通してＢと対話することができる。Ａの音声入力は、まず電話ハードウェア・ インタフェース８３においてデジタル化され、次にソフトウェア８１によってＩ Ｐパケットに挿入されインターネットを通ってインタフェース８０に送られる( 矢印８４)。Ｂからの音声トラフィックは逆の経路を進む。 ＳＳＰ４１からのサービス要求に応答して、ＳＣＰによるＩＮサービスがこの 呼び出しに対して提供される。従って、Ｂの電話が使用中でＢが呼び出し転送に 関して登録されていれば、ＳＣＰ４３は、サービス要求を受け取ると、呼び出し 転送のためＢの適切な電話ページにアクセスして転送番号を取り出す。Ｂの電話 が使用中である時ＳＳＰ４１がサービス要求を始動しないように設定されていれ ば、使用中標識がＡの端末に返され、そこで図１４を参照して上述した形態でそ れは処理される。 実際に、インターフェース８０は、条件をトリガーし、それら条件が満たされ 次第ＳＣＰ４３に対するサービス要求を生成するため、ＳＳＰの場合と同様な機 能性を備える。第三者呼び出し設定ゲートウェイ 図１６は、Ｂの現在時徘徊番号を受け取った後ＡがＢを呼び出す構成を示す。 この場合、インターネット５０およびＳＳＰ４１の両者とインタフェースする第 三者呼び出し設定ゲートウェイ９０が提供される。便宜的に、ゲートウェイ９０ はＳＣＰ４３と併設されている(必ずしもその必要はないが)。ゲートウェイ９０ は、指定された電話の間の呼び出しを設定するようにＳＳＰ４１に要求する機能 を持つ。 従って、ＡがＢへの呼び出しを求めると、第三者呼び出し設定要求がＡの端末 からインターネットを経由してゲートウェイ９０に送られる(矢印９１)。この設 定要求は、Ａの電話番号およびＢの現在時徘徊番号を含む。ゲートウェイ９０は 、先ず、Ａの電話への呼び出しを設定することを試み(これは一般的には成功す るにちがいない)、その後識別されたＢの電話に対する呼び出しを設定する。一 旦呼び出しが設定されれば、ＡおよびＢは標準的方法でＰＳＴＮを経由して通信 する。 Ｂの電話が使用中であれば、上述したシナリオのいずれかが起きる。 ゲートウェイ９０は、また、あらかじめ定められたトリガー条件が満たされ次 第ＳＣＰ４３に対するサービス要求を行うように構成することができる。このよ うに、ゲートウェイ９０はＢの電話の使用中条件を検出し、転送番号に関するＳ ＣＰ４３へのサービス要求を始動するように設定することができる。しかしなが ら、ゲートウェイ９０を経由してＡの端末へ使用中信号を送り戻す構成の方が、 対応策をとる柔軟性をＡに与えることができるので、望ましい。 図１４に関して上述したように、ユーザＡが通常の非ＩＳＤＮのＰＳＴＮ回線 上のＳＬＩＰ／ＰＰＰ接続経由のインターネット・アクセスだけを持つ場合複雑 な問題が起きる。なぜならば、この場合、ゲートウェイ９０がＡの電話への呼び 出しを設定しようとする時Ａの電話回線はインターネット・アクセスを行うため 既に使用されているからである。図１４に関連して上述した解決策、すなわち、 インターネット・セッションを中断し、音声とインターネット・データを同一の 電話回線上で多重化するという方法をここでも使用することができる。ユーザＡ の端末がインターネット上で送信されるデジタル化された音声として音声を取り 扱うことができるとすれば、図１４および図１５の両方のシナリオに対する代替 策が可能である。この場合、音声通話は図１５形式のインタフェース８０を経由 して伝送され、Ｂの電話ページやゲートウェイ９０との音声トラフィックおよび インターネット通信は、両方とも、Ａ端末との間でＳＬＩＰ／ＰＰＰ接続を介し て伝送されるインターネット・パケットの形態で搬送されるが、端末５３上で動 く別々のアプリケーションに渡される論理的に独立した流れとして搬送される。 Ａの端末からゲートウェイ９０に対して出される第三者呼び出し設定要求は、 Ｂの電話ページに保持されサーバー５１によって実行されるサービス論理によっ て同様に作成されることができる点は留意されるべきである(もちろん、そのよ うな構成は、Ａの電話番号がＢの電話ページ・サービス論理に渡されることを必 要とし、ユーザＡの端末に提示される形式へ入力された番号が自動的にサーバー ５１へ送られる構成によって実施されることができる)。 更に、注意すべきは、図１５のインタフェース８０および図１６のゲートウェ イ９０は、ＳＳＰ４１以外のエンティティによってサービス制御サブシステムに 渡されるサービス要求の１つの例を与えている。ＷＷＷに基づく「無料電話」８００番サービス ＷＷＷおよびＰＳＴＮの組合せを使用して、「着信無料電話」すなわち「８０ ー番」タイプのサービスを実施することが可能である。図１７を参照して行われ る以下の記述から明らかとなるように、ＷＷＷ／ＰＳＴＮ実施形態は、必ずしも 、呼び出し側から呼び出され側への通話料金の転送または特別の「８００」番の 使用のいずれにも依存しない。これら２つは標準的「無料電話」方式である。し かしながら、ＷＷＷ／ＰＳＴＮ実施形態は、問い合わせ側および被問い合わせ側 の通話を被問い合わせ側の負担で行うことができるようにする一層一般的特性を 持つ。 図１７の構成において、大規模なデパートのようなユーザＤがサーバー５１上 にウェブサイトを持つ。単純化のため、サーバーは、回線１２５を経由してサー バーへの直接のコンピュータ・アクセスを持つユーザＤの制御の下にあると仮定 する。例えば、Ｄのウェブサイトは、Ｄによって売り出されている商品を掲載す る多くのカタログのウェブ・ページを含む。加えて、Ｄは無料電話に基づいて行 われる問い合わせを取り扱うため着信無料電話ページ１２４を設ける。このペー ジのＵＲＬは、ウェブサイト・カタログ・ページの各々に配置される「着信無料 電話」グラフィック・ボタン１２２に関連づけられる。 端末５３のユーザＡがＤのウェブサイトをブラウズしてカタログ・ページを見 る(矢印１２１)と仮定する。Ａは興味のある品目を見て、この品目に関してＤに 問い合わせしたいと望むと、Ａは端末５３においてカタログ・ページに関連づけ られている着信無料電話ボタン１２２を活動状態にさせる。ボタンが押されると 、Ａの端末に現在ロードされているカタログ・ページに埋め込まれたコードがＡ にＡの電話番号およびオプションではあるが名前を入力するように促し、その後 、入力されたデータを含むＨＴＴＰ要求がＰＯＳＴ方法を使用してＤの無料電話 ページへ送られる(矢印１２３)。この要求を受け取ると、Ｄの無料電話ページは 、サービス論理を実行して、問い合わせ制御システム１２６において維持されて いる問い合わせ待ち行列１２７に(Ａの名前および電話番号を含む)新しい問い合 わせを入力する。この例では、問い合わせ制御システムは、インターネットから は外部にある回線１２５を経由してサーバー５１に接続しているが、サーバー５ １をインターネットを経由して問い合わせ制御システムと通信させるようにする ことも可能である。ＤのウェブサイトがＤによって制御されたサーバー上ではな くむしろＩＳＰサーバー上にある場合にはこの構成は最も実際的であろう。実際 に、無料電話ボタン１２２が押されると、Ａの端末において動いているコードが 、サーバー５１を経由するのではなく、インターネットを経由して問い合わせ制 御システムに問い合わせ要求を直接送信するように構成することができる。 問い合わせ制御システム１２６は、問い合わせを到着順に確実に処理するよう に、渡された問い合わせを管理する。システム１２６は、新しい問い合わせを受 領すると、その問い合わせを処理するまでのおよその待ち時間を好ましくは推定 する。この推定は、待ち行列に現在ある問い合わせ件数と平均処理時間に基づい て行われる。待ち時間の推定は、ＰＯＳＴ要求メッセージへの応答としてサーバ ー５１を通してユーザＡへ送り戻される。 問い合わせ制御システム１２６は、電話４０およびディスプレイ１２９を備え ている多数の担当者への問い合わせの分配を監視する。Ａの問い合わせは待ち行 列１２７の先頭に達すると直ちに取り扱われ、問い合わせを取り扱うことができ る担当者が検出される(例えば担当者の電話が受話器に置かれた時点を検出する ようにシステムを構成できる)。そのような条件が満たされると、分配および設 定制御装置１２８が、Ａの問い合わせを取り上げ、作業可能な担当者Ｄ'のディ スプレイ１２９にＡの名前および電話番号を表示する。ユーザＤがＤの過去の顧 客または信用格づけデータに関するデータベースを保持していれば、装置１２８ はＡに関するそのような既存の情報を表示する。同時に、装置１２８は、ゲート ウェイ９０に対して第三者呼び出し設定要求をインターネットを経由して送信し て(矢印１３０)、担当者Ｄ'の電話とユーザＡの電話の間の呼び出し設定を行う ように求める。Ｄ'およびＡの両者が呼び出しを取り上げれば、問い合わせが進 行し、ＰＳＴＮ上の呼び出しを始動したのがＤであるので通話料金はＤによって 支払われる。もしも、何かの理由で(例えばＡが応答しなかったため)あらかじめ 定められたタイムアウト期間通話ができなければ、装置１２８が待ち行列１２７ の先頭にある次の問い合わせの処理に自動的に進むように構成することができる 。 もちろん、装置１２８のゲートウェイ９０への呼び出し設定要求を行わずに済 ませることも、担当者Ｄ'が手動でＡの番号をダイヤルしたり、あるいは装置１ ２６がＤ'の電話に代わって自動ダイヤルを始動したりする(例えば図１４におけ るＡの場合と同様にコンピュータ組み込み電話を担当者Ｄ'が持つ)ことは、可能 である。このようなアプローチの利点は、ＷＷＷ型着信無料電話サービスを実施 する際、改作またはいかなるサービスの導入も行わずに、既存のＰＳＴＮを使用 することができることである。 図１１および図１３に関連して記述したように、ユーザＡが通常の非ＩＳＤＮ のＰＳＴＮ回線上のＳＬＩＰ／ＰＰＰ接続経由のインターネット・アクセスだけ を持つ場合ユーザーＡに対する呼び出しには複雑な問題が起きる。なぜならば、 この場合、ユーザＤがＡの電話への呼び出しを設定しようとする時Ａの電話回線 はインターネット・アクセスを行うため既に使用されているからである。図１１ および図１３に関連して上述した解決策、すなわち、インターネット・セッショ ンを中断し、音声とインターネット・データを同一の電話回線上で多重化すると いう方法をここでも使用することができる。インターネット・セッションの中止 に基づく解決策に関する限り、そのような中止は、Ａの問い合わせが処理される まで遅延されるようにすることは可能であるが、これを行うには、制御システム １２６からのフィードバックをインターネットを経由してＡの端末５３に提供し 、このフィードバックをインターネット・セッションを中止されるコードに関連 づける必要がある。これを達成する１つの方法は、Ａから出されたオリジナルの ＰＯＳＴ要求メッセージに対する応答として送られる応答メッセージに相関コー ドを含ませることである。システム１２６からＡに送られるいかなる後続のフィ ードバックもこのコードを含み(サーバーＡはまたこのコードを制御システム１ ２６へ渡す)、これによって、Ａの端末はこのフィードバックを正しく識別する ことが可能となる。実際、同じメカニズムを使用して、コールバックを受け取る までどのくらい待たなければならないかを適時に更新してユーザＡに知らせるこ とができる。このメカニズムは、Ａの電話回線の競合問題とは関係なく使用可能 である。 ユーザＡが電話４０だけを持ち端末５３を持たない場合でも、なお図１７の基 本的構造を使用して、通話料金振り替えという複雑さを伴うことなく、ユーザＡ に無料電話サービスを提供することは可能である。具体的に述べれば、Ａがユー ザＤの着信無料電話サービス(典型的には８００番サービス)に関する特別の番号 にダイヤルすると、ＳＳＰ４１が標準的方法でこの特別番号を認識し、この特別 番号とユーザＡの番号を含むサービス要求をＳＣＰ４３に送る。次に、ＳＣＰ４ ３が番号対ＵＲＬ変換を実行することによってＤの無料電話ページのＵＲＬを確 認し、要求１２３の場合と同様なＰＯＳＴ方法ＨＴＴＰ要求を使用してＤの着信 無料電話ページにアクセスする。一旦この要求がＤの着信無料電話ページ１２４ ページによって問い合わせとして登録されれば、無料電話ページはＳＣＰ４３に 要求を送信し、「あなたの着信無料電話問い合わせは登録されました。受話器を おいてください。すぐに電話がつながります。」というような通知を出すように 要求する。この通知は、ＩＰによって標準的方法で実行することができる。そこ で、Ａは電話を切ってＤからの呼び出しを受け取る準備をする。 ＷＷＷを使用する上記の着信無料電話方式の顕著な利点は、問い合わせが待ち 行列に記憶され処理を待つ間ユーザＤはＰＳＴＮの使用に対する料金を加算しな いですむという点にある。バリエーション 上記の諸構成には当然のことながら多くのバリエーションが可能である。以下 にそのいくつかを記述する。 分散処理環境。図１８に示されているように、ＳＣＰ４３は、少くとも論理的 にインターネットとは独立した分散処理環境すなわちＤＰＥ９８を経由してＨＴ ＴＰサーバー５１にアクセスすることもできる。好ましくは、この場合、サーバ ー５１はＰＳＴＮ操作員によって制御され、従って数の点で限定される。 ＤＮＳタイプ・サーバー上のサービス資源。前述の例においては、サービス資 源項目がインターネットに接続したサーバー５１上に配置され、所望のサービス 資源が、所望のサービス資源項目を識別する資源コードから導出されるＵＲＩの 使用を通して、ＰＳＴＮのサービス制御サブシステムやインターネット・ユーザ によってインターネットを経由してアクセスされた。電話番号の形式で資源コー ドからＵＲＩを導出する好ましい構成において、対象の電話番号の全部または一 部がドメイン名形式に解析され、次に、ＤＮＳ自体に組み込まれ得るＤＮＳタイ プ分散データベース・システムを使用してＵＲＩに変換された(図１１、図１２ および関連記述を参照)。実際、サービス資源項目をＤＮＳタイプ分散データベ ース・システムによって保持される登録記録に直接配置することは可能であり、 そうすることによって、解析された電話番号を所望の資源にアクセスするため使 用されるＵＲＩに変換する代わりに、解析された電話番号が所望のサービス資源 項目に直接変換される。このプロセスに使用されるメカニズムは、上述したよう な、解析された電話番号をＵＲＩに変換するメカニズムと全く同じものである。 このために使用されるＤＮＳタイプ分散データベース・システムは、サービスの ためにだけでなくサービス資源項目にインターネット・ユーザと共にＰＳＴＮの サービス制御サブシステムのためサービス資源項目へのアクセスを提供できるよ うに、好ましくはインターネットまたはＤＮＳ自体の上でアクセスできるもので ある(図１８を参照して記述した場合と同様の方法で、サービス資源項目を持つ ＤＮＳタイプ・サーバーは、インターネット以外のネットワークによってサービ ス制御サブシステムにアクセスすることは可能である)。ＤＮＳタイプ・サーバ ー上に保持されるＲＲへのサービス資源項目の配置は、サービス資源項目のすべ てのタイプにとって適切ではないかもしれないが、頻繁に変わることはない電話 番号のような項目には適当であるかもしれない。かくして、適切な使用によって 番号可搬性が提供される。この場合、ダイヤルされた個人番号がＤＮＳタイプ・ システムにおける照合を起動し、個人の番号の全部または一部が先ず解析され、 次に、ＤＮＳタイプ・システムに適用され、呼び出しのための現在時番号が返さ れる。すべてのダイヤルされた番号は、個人番号または単にそのような番号のサ ブセットとみなされることができる。この場合のサブセットは、例えばＳＳＰに おける照合またはあらかじめ定められた先頭桁ストリングの存在によって個人番 号として容易に識別できる複数の番号を含む。ＤＮＳタイプ分散データベース・ システムにおけるドメイン名を作り上げるため電話番号の全体また一部をを解析 するという一般的概念は、ＵＲＩおよびサービス資源項目に加えてその他の情報 項目の検索のためにも使用することができる。 フィードバック・メカニズム。図１７のＷＷＷに基づく着信無料電話構成を記 述する際に、コールバックを受け取るまでの推定待ち時間に関するフィードバッ クをユーザＡに供給することができることを記述した。これは、インターネット を使用して潜在的または実際の電話ユーザにフィードバック経路を与えることの できる１つの例である。また、呼び出し設定の進捗状況が呼び出し設定ゲートウ ェイによってユーザＡ端末へ通知されるという別の例が図１６に関連して与えら れた。事実、一般的には、ユーザがインターネット上で活発に端末を使用してい ることが知られている場合、呼び出し設定の進展を電話システムを通してユーザ にフィードバックする機会が発生する。これを行うためには、当然のことながら 、フィードバックが端末Ａ上で動く適切なアプリケーションに渡されることがで きることを確認する必要があり、これは一般にはアプリケーションが適切なリン ク情報を利用可能にすることを要求する。例えば呼び出し待機の間に、呼び出し 設定進捗情報の他の情報もまたフィードバックすることができる。例えば、呼び 出し待機の間ユーザＡに表示するマルチメディア・クリップやビデオを保持する 特別なサーバーをインターネット上に提供することもできる。 上記の諸構成において、サーバー５１は主として呼び出し設定制御に関係した サービス資源項目を備えていた。別の異なるアプリケーションにおいて、ユーザ 始動の電話要求に応答して電話システムからアクセスされ電話ユーザに返される データを保持するようにインターネット・サーバーを構成することは可能である 点は留意されるべきである。そのようなサービスは、例えば、特定の電話番号の 入力に応じてサービス要求を起動するＳＳＰに対応するように提供される。この 場合、サービス要求は、ＳＣＰを介して、知能型周辺機器を特定のインターネッ ト・サーバー(必ずしもＨＴＴＰサーバーではない)にアクセスさせ呼び出し元へ 戻すための所望のデータを取り出すように求める。知能型周辺機器には、ユーザ にデータを音声で回答するためのテキスト対音声変換器が含まれる。 更に、サービス資源項目自体に関連するフィードバック・プロセスを記述する ことは有益であろう。例として、電話ユーザＧが、Ｇの電話への呼び出しを最低 Ｘ分だけ差し止めることができるサービスの利用に加入しているとする(Ｘはユ ーザによって設定可能である)。このサービスを実現するため、サーバー５１上 に使用中状態標示を含む電話ページをＧは持つ。Ｇへの呼び出しが成功すると、 ＧのローカルＳＳＰは、インターネット経由で関連ＳＣＰによるメッセージをＧ の電話ページへ送信する。このメッセージによってＧの電話が使用中であること を示すＧ使用中標示が設定される。メッセージは，また、期間Ｘの後時間切れと なり、使用時間標示をリセットさせる働きをするタイマーを始動させる。Ｇへの 呼び出しはＧの回線が実際に使用中であるのでＧのＳＳＰにおいて拒絶されるか 、ＳＣＰを介してＧの電話ページ使用中標示が設定されているか否かを照会する ようにＳＳＰに求める。もしも使用中状態標示が設定されていれば(成功のうち の呼び出し終了の後Ｘ期間設定されている)、呼び出しの試みは拒絶され、一方 、使用中状態標識がリセット状態にあれば呼び出し試行は進められる。Ｇの電話 ページ上に使用中状態標示メカニズムを配置することによって、ＧがＸの値を簡 単に変更することができるように構成することが可能である。 更に一般的バリエーション。上述の諸例においてＰＳＴＮのサービス制御サブ システムはＳＣＰとして実施されているが、サービス制御サブシステムの機能性 をＳＳＰの一部としてまたは関連補助機構に備えることも可能である。更に、サ ービス要求の始動すなわちトリガーを、ＳＳＰ以外の機器、例えばＳＳ７信号リ ンクに挿入されるインタセプト・ボックスによって、実施することも可能である 。 「インターネット」という用語は、インターネットおよび現在のアドレス指定 方式のために使用されているＴＣＰ／ＩＰプロトコルの現在時点の仕様のみなら ず、等時性媒体を取り扱う扱うために必要とされるような発展機能をも含むもの と理解されるべきである。更に、ＷＷＷおよびＨＴＴＰプロトコルの参照も、同 様に、それらの将来発展したものをも含むものと理解されるべきである。 本発明は、ＰＳＴＮ以外の電話システム、例えば、ＰＬＭＮやその他の移動体 ネットワーク、およびＰＡＢＸを使用するプライベート・システムにも適用する ことができる。プライベート・システムの場合、ＰＡＢＸと同じ内部ユーザに機 能を一般的に提供するＬＡＮまたは構内型コンピュータ・ネットワークが上述の 実施形態におけるインターネットの役割を果たすであろう。 更に、(例えば広帯域ＡＴＭシステムのような)交換型遠隔通信システムがサー ビス制御を必要とし、その遠隔通信システムのサービス制御サブシステムへのサ ービス資源伝達のためコンピュータ・ネットワークが使用される場合にも本発明 は適用できる。

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁷ 識別記号 ＦＩ テーマコート゛(参考） Ｈ０４Ｑ 3/00 Ｈ０４Ｑ 3/00 (31)優先権主張番号 ９６０３５８２．９ (32)優先日 平成８年２月20日(1996．2．20) (33)優先権主張国 イギリス（ＧＢ） (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ， ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，Ｌ Ｕ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ， ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＫＥ，ＬＳ，ＭＷ，ＳＤ，Ｓ Ｚ，ＵＧ)，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ ，ＲＵ，ＴＪ，ＴＭ)，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ， ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，Ｇ Ｅ，ＨＵ，ＩＬ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ， ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，Ｐ Ｌ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＵＡ，ＵＧ，ＵＳ，ＵＺ， ＶＮ (72)発明者 ブーサーズ・ニコラス フランス、エフ―38240、メイラン、レ ス・ビャリヤス、レ・ルーポアール 16

Claims (1)

1. 【特許請求の範囲】 １．交換遠隔通信システムを経由する搬送体経路の設定に関する使用のためサ ービス資源項目にアクセスする方法であって、 対応する既知のＵＲＩによってコンピュータ・ネットワーク上での位置を特定 することができる複数のサービス資源項目を有する上記コンピュータ・ネットワ ークに接続する少なくとも１つのサーバーを提供するステップであって、上記コ ンピュータ・ネットワークが遠隔通信システムとは論理的に独立していて、上記 サービス資源項目が、それぞれあらかじめ定められたコードに関連づけられてい る上記サービス資源項目の各々を持つ上記遠隔通信システムを通る搬送体経路に 関する設定制御に関連していて、上記あらかじめ定められたコードが上記ＵＲＩ とは異なるもので上記搬送体経路に関する終端エンティティを識別する、ステッ プ(a)と、 上記あらかじめ定められたコードの各々とそのあらかじめ定められたコードに 関連づけられるサービス資源の上記既知のＵＲＩの間の対応関係を提供するステ ップ(b)と、 上記あらかじめ定められたコードを利用して、上記対応関係の使用によって対 応する上記サービス資源項目にアクセスして当該サービス資源項目に対応するＵ ＲＩを決定して、次にこのＵＲＩを使用して上記コンピュータ・ネットワーク上 のサービス資源項目にアクセスするステップ(c)と、 を含む方法。 ２．上記ＵＲＩのすくなくともいくつかが、上記対応付関係によって指定され る関数に従う取り扱いによって対応する上記あらかじめ定められたコードから導 出される、請求項１に記載の方法。 ３．上記ＵＲＩのすくなくともいくつかが、上記対応関係に従って上記あらか じめ定められたコードとＵＲＩを関連づける関連テーブルにおける照合によって 対応する上記あらかじめ定められたコードから導出される、請求項１に記載の方 法。 ４．上記関連テーブルがコンピュータ・ネットワークに接続する少なくとも１ つのデータベース・サーバー上に保持されていて、上記ステップ(c)が、コンピ ュータ・ネットワーク上の上記データベース・サーバーにアクセスして上記あら かじめ定められたコードに対応する上記ＵＲＩを決定するサブステップを含む、 請求項３に記載の方法。 ５．上記少なくと１つのデータベース・サーバーがＤＮＳタイプ分散データベ ース・システムよって提供され、上記ＵＲＩがレコードの取り出しを行うために 使用されるドメイン名と呼ばれるそれぞれの名前に関連づけられたレコードに保 持され、上記ステップ(c)が、上記あらかじめ定められたコードを対応する上記 ドメイン名に変換するサブステップおよびこのドメイン名を使用して上記ＤＮＳ タイプ分散データベース・システムから所望のサービス資源項目を取り出すサブ ステップを含む、請求項４に記載の方法。 ６．少なくとも２つの上記サービス資源が同一のＵＲＩに位置し、それらサー ビス資源項目の上記あらかじめ定められたコードが同一のＵＲＩにおけるサービ ス資源項目の中から所望のサービス資源項目を識別するためサービス資源項目を 保持するサーバーにおいて使用されるそれぞれの相対的資源識別子値を含む、請 求項１に記載の方法。 ７．上記交換遠隔通信システムが電話システムであり、上記あらかじめ定めら れたコードが、 --呼び出し側の電話番号 --呼び出され側の電話番号 というカテゴリの少なくとも１つに基づく番号を含む、上記請求項のいずれかに 記載の方法。 ８．上記交換遠隔通信システムが電話システムであり、上記あらかじめ定めら れたコードの少なくともいくつかが、呼び出され側電話番号であって、呼び出さ れ側の現在時点電話番号であるサービス資源項目を取り出すため使用される、請 求項１に記載の方法。 ９．少なくと１つの上記サービス資源項目が、アクセスされ次第対応するサー バーによって実行され、その結果が搬送体経路設定制御における使用のためアク セス・エンティティに返されるサービス論理である、上記請求項のいずれかに記 載の方法。 １０．少なくと１つの上記サービス資源項目が、アクセスされ次第搬送体経路 設定制御における使用のためアクセス・エンティティにダウンロードされるダウ ンロード可能サービス・データである、上記請求項のいずれかに記載の方法。 １１．少なくと１つの上記サービス資源項目が、アクセスされ次第搬送体経路 設定制御における実行のためアクセス・エンティティにダウンロードされるダウ ンロード可能サービス論理である、上記請求項のいずれかに記載の方法。 １２．上記コンピュータ・ネットワークが一般的に遠隔通信システムのユーザ からアクセスすることが可能である、請求項１に記載の方法。 １３．上記コンピュータ・ネットワークがインターネットである、上記請求項 のいずれかに記載の方法。 １４．上記交換遠隔通信システムがＰＳＴＮである、上記請求項のいずれかに 記載の方法。 １５．上記遠隔通信システムが、上記サービス制御サブシステムが関連づけら れているＰＡＢＸを含むプライベート・システムであり、上記コンピュータ・ネ ットワークがＬＡＮである、請求項１乃至請求項１３に記載の方法。 １６．上記ＵＲＩがＵＲＬおよびＵＲＮのいずれかまたは両者であり、上記サ ーバーがＨＴＴＰサーバーである、上記請求項のいずれかに記載の方法。