JP3867079B2 - 通信ネットワーク上の目標エンティティへのアクセス方法 - Google Patents

通信ネットワーク上の目標エンティティへのアクセス方法 Download PDF

Info

Publication number
JP3867079B2
JP3867079B2 JP2003411553A JP2003411553A JP3867079B2 JP 3867079 B2 JP3867079 B2 JP 3867079B2 JP 2003411553 A JP2003411553 A JP 2003411553A JP 2003411553 A JP2003411553 A JP 2003411553A JP 3867079 B2 JP3867079 B2 JP 3867079B2
Authority
JP
Japan
Prior art keywords
service
uri
server
resource
dns
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
JP2003411553A
Other languages
English (en)
Other versions
JP2004194330A (ja
Inventor
ロウ・コリン
シーボーン・アンドリュー・フランクリン
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
HP Inc
Original Assignee
Hewlett Packard Co
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=10789104&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=JP3867079(B2) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Application filed by Hewlett Packard Co filed Critical Hewlett Packard Co
Publication of JP2004194330A publication Critical patent/JP2004194330A/ja
Application granted granted Critical
Publication of JP3867079B2 publication Critical patent/JP3867079B2/ja
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/4228—Systems providing special services or facilities to subscribers in networks
    • H04M3/42306—Number translation services, e.g. premium-rate, freephone or vanity number services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
    • H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4535—Network directories; Name-to-address mapping using an address exchange platform which sets up a session between two nodes, e.g. rendezvous servers, session initiation protocols [SIP] registrars or H.323 gatekeepers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4552—Lookup mechanisms between a plurality of directories; Synchronisation of directories, e.g. metadirectories
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4557—Directories for hybrid networks, e.g. including telephone numbers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/54—Arrangements for diverting calls for one subscriber to another predetermined subscriber
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M7/00—Arrangements for interconnection between switching centres
    • H04M7/006—Networks other than PSTN/ISDN providing telephone service, e.g. Voice over Internet Protocol (VoIP), including next generation networks with a packet-switched transport layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q3/00—Selecting arrangements
    • H04Q3/0016—Arrangements providing connection between exchanges
    • H04Q3/0029—Provisions for intelligent networking
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q3/00—Selecting arrangements
    • H04Q3/0016—Arrangements providing connection between exchanges
    • H04Q3/0029—Provisions for intelligent networking
    • H04Q3/0037—Provisions for intelligent networking involving call modelling techniques, e.g. modifications to the basic call state model [BCSM]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q3/00—Selecting arrangements
    • H04Q3/0016—Arrangements providing connection between exchanges
    • H04Q3/0029—Provisions for intelligent networking
    • H04Q3/0045—Provisions for intelligent networking involving hybrid, i.e. a mixture of public and private, or multi-vendor systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M7/00—Arrangements for interconnection between switching centres
    • H04M7/12—Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13093—Personal computer, PC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13097—Numbering, addressing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13103—Memory
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13106—Microprocessor, CPU
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13175—Graphical user interface [GUI], WWW interface, visual indication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13176—Common channel signaling, CCS7
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13196—Connection circuit/link/trunk/junction, bridge, router, gateway
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13204—Protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13209—ISDN
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13345—Intelligent networks, SCP
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13389—LAN, internet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13517—SLEE - service logic execution
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13526—Indexing scheme relating to selecting arrangements in general and for multiplex systems resource management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13527—Indexing scheme relating to selecting arrangements in general and for multiplex systems protocols - X.25, TCAP etc.
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13534—Internet - WWW, HTML, browsers etc.
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13546—Intelligent Peripheral

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Telephonic Communication Services (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Telephone Function (AREA)
  • Application Of Or Painting With Fluid Materials (AREA)

Description

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

Claims (15)

  1. 入力電話番号の番号ストリングによって識別される目標エンティティと通信するためのデータにアクセスする方法であって、
    (a)各々が対応するドメイン名に関連し、前記通信するためのデータの位置を定めるＵＲＩ（統一資源識別子）を含む複数のレコードをＤＮＳ型データベース・システムに保存するステップを含み、
    前記ドメイン名のそれぞれは、前記入力電話番号に関連づけられていて、該入力電話番号の少なくとも一部分をドメイン名の少なくとも一部分に解析することを含むプロセスによってドメイン名を取り出すことができるようになっており、
    (b)目標エンティティを識別する前記入力電話番号に対して前記プロセスを実行することによって、関連したドメイン名を形成するステップと、
    (c)前記ステップ(b)において形成されたドメイン名を前記ＤＮＳ型データベース・システムに供給して、対応するレコードに保有されているＵＲＩを取り出すステップと、
    (d)前記ステップ(c)において取り出されたＵＲＩを使用して前記通信するための出データにアクセスするステップと、
    を含む方法。
  2. 少なくとも１つの前記レコードに保有されているＵＲＩが前記通信するためのデータ自体に関するＵＲＩである、請求項１に記載の方法。
  3. 少なくとも１つの前記レコードに保有されているＵＲＩが前記通信するためのデータの複数項目に対するアクセスを行う機能性を有し、
    前記ステップ(d)が、ＵＲＩを使用して、該通信するためのデータの所望の項目の識別子(すなわちＲＲＩ)を供給するため該機能性にアクセスし、それに応じて戻される通信データを受け取るステップを含む、請求項１に記載の方法。
  4. 識別子(すなわちＲＲＩ)は、前記ＵＲＩに組み込まれ、組み込まれた形式で前記機能性に供給される、請求項３に記載の方法。
  5. 識別子(すなわちＲＲＩ)が、前記ＵＲＩと別のエレメントとして前記機能性に供給される、請求項３に記載の方法。
  6. 少なくとも１つの前記レコードに保有されているＵＲＩが、アクセス方式およびホスト・アドレスを含むＵＲＬを含む、請求項１乃至請求項５のいずれかに記載の方法。
  7. 前記ホスト・アドレスがドメイン名である、請求項６に記載の方法。
  8. 前記番号ストリングのそれぞれが電話番号の形式をなす、請求項１乃至請求項７のいずれかに記載の方法。
  9. 前記ＤＮＳ型データベース・システムがインターネットのドメイン名システム(すなわちＤＮＳ)である、請求項１乃至請求項８のいずれかに記載の方法。
  10. 電話網(すなわちＰＳＴＮ)を経由して目標エンティティにアクセスする方法であって、
    目標エンティティに関する電話番号の形式をなす通信するためのデータが請求項１乃至請求項９のいずれかに記載の方法に従ってアクセスされ、この電話番号が該電話網を介して目標エンティティを呼び出すため使用される、方法。
  11. ＤＮＳ型分散データベース・システムのサーバであって、
    該サーバは、ドメイン名から、入力電話番号の番号ストリングで識別される目標エンティティと通信するためのデータの位置を定めるＵＲＩへのマッピングを提供する資源レコードを記憶しており、該ドメイン名の少なくとも一部分が、前記番号ストリングから解析される複数のドメイン名ラベルである、サーバ。
  12. 前記ＵＲＩが、前記通信するためのデータにアクセスするためのアクセス方式およびホスト・アドレスを含むＵＲＬを含む、請求項１１に記載のサーバ。
  13. 前記番号ストリングが電話番号の少なくとも実質的一部分である、請求項１１に記載のサーバ。
  14. 前記ＵＲＩが通信データの複数項目に対するアクセスを行う機能性を有している、請求項１１に記載のサーバ。
  15. 前記ＤＮＳ型分散データベースがインターネットのドメイン名システム(すなわちＤＮＳ)である、請求項１１乃至請求項１４のいずれかに記載のサーバ。
JP2003411553A 1996-02-20 2003-12-10 通信ネットワーク上の目標エンティティへのアクセス方法 Expired - Lifetime JP3867079B2 (ja)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
GBGB9603590.2A GB9603590D0 (en) 1996-02-20 1996-02-20 Method of accessing a target entity over a communciations network

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP52987197A Division JP4159603B2 (ja) 1996-02-20 1996-12-11 通信ネットワーク上の目標エンティティへのアクセス方法

Publications (2)

Publication Number Publication Date
JP2004194330A JP2004194330A (ja) 2004-07-08
JP3867079B2 true JP3867079B2 (ja) 2007-01-10

Family

ID=10789104

Family Applications (2)

Application Number Title Priority Date Filing Date
JP52987197A Expired - Lifetime JP4159603B2 (ja) 1996-02-20 1996-12-11 通信ネットワーク上の目標エンティティへのアクセス方法
JP2003411553A Expired - Lifetime JP3867079B2 (ja) 1996-02-20 2003-12-10 通信ネットワーク上の目標エンティティへのアクセス方法

Family Applications Before (1)

Application Number Title Priority Date Filing Date
JP52987197A Expired - Lifetime JP4159603B2 (ja) 1996-02-20 1996-12-11 通信ネットワーク上の目標エンティティへのアクセス方法

Country Status (10)

Country Link
EP (3) EP1207704B1 (ja)
JP (2) JP4159603B2 (ja)
CN (1) CN1209249A (ja)
AU (1) AU719651C (ja)
CA (1) CA2239495A1 (ja)
DE (2) DE69632495T2 (ja)
GB (1) GB9603590D0 (ja)
NO (1) NO325606B1 (ja)
NZ (1) NZ323991A (ja)
WO (1) WO1997031490A2 (ja)

Families Citing this family (43)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3084681B2 (ja) * 1996-12-06 2000-09-04 財団法人流通システム開発センタ− 統合情報通信システム
US5974453A (en) * 1997-10-08 1999-10-26 Intel Corporation Method and apparatus for translating a static identifier including a telephone number into a dynamically assigned network address
DE19747583B4 (de) * 1997-10-28 2006-04-20 Telefonaktiebolaget Lm Ericsson (Publ) Kommunikationssystem und Verfahren
WO1999028979A2 (en) * 1997-12-02 1999-06-10 Alcatel Usa Sourcing, L.P. Digital phone system
WO1999029083A1 (en) * 1997-12-02 1999-06-10 Alcatel Usa Sourcing, L.P. Method and apparatus for dynamic domain names
GB2338871B (en) * 1997-12-05 2000-08-30 Miyaguchi Res Co Ltd Integrated information communication system
US6215784B1 (en) * 1997-12-24 2001-04-10 Nortel Networks Limited Method and system for voice call completion using information retrieved from an open application on a computing machine
IL125432A (en) 1998-01-30 2010-11-30 Easynet Access Inc Personalized internet interaction
IL123129A (en) 1998-01-30 2010-12-30 Aviv Refuah Www addressing
JP2000059441A (ja) * 1998-06-12 2000-02-25 Alcatel Usa Sourcing Lp プログラム可能な通信インタフェ―ス
GB9815585D0 (en) * 1998-07-18 1998-09-16 Fitton Stuart J Computer network addressing system
WO2000059237A1 (en) * 1999-03-26 2000-10-05 Nortel Networks Limited Control node with intelligent network
US6963928B1 (en) 1999-05-27 2005-11-08 Bagley David T Systems and methods for communicating across various communication applications using single address strings
YU92801A (sh) * 1999-05-27 2003-07-07 Internet Management Systems Inc. Sistemi i metodi za komuniciranje kroz različite komunikacione aplikacije korišćenjem jedinstvene adrese
IL147545A0 (en) * 1999-07-09 2002-08-14 Harris Mark J Network addressing and method using telephone numbers
NL1012721C2 (nl) * 1999-07-28 2001-01-30 Benno Henricus Nicolaas Hijl Inrichting voor registratie, adressering, structurering en het vinden van entiteiten en gegevens, gebaseerd op identificatiecodes.
WO2001029001A2 (en) * 1999-10-15 2001-04-26 Nametree, Inc. Domain name searching
SE517354C2 (sv) * 1999-12-01 2002-05-28 Ericsson Telefon Ab L M System och ett förfarande för privat telekommunikationsnät
SE517319C2 (sv) * 1999-12-01 2002-05-28 Ericsson Telefon Ab L M System och anordning i privata telekommunikationssystem där IP-nät används för signalering rörande förfrågnings- och svarsmeddelanden
US9781257B2 (en) 2000-01-19 2017-10-03 Sony Mobile Communications Ab Technique for obtaining caller-originated alert signals in IP-based communication sessions
US8400946B2 (en) 2000-01-19 2013-03-19 Sony Corporation System and method for sharing common location-related information between communication devices
US8548010B2 (en) 2000-01-19 2013-10-01 Sony Corporation Method and apparatus for event-based synchronization of information between communication devices
US6826403B1 (en) 2000-09-12 2004-11-30 Phonepages Of Sweden Ab Method and system for identifying a user
DE10053717B4 (de) * 2000-10-28 2004-05-19 Web.De Ag Verfahren und Vorrichtung zum Aufbau einer Telefonverbindung über eine Internet-Telefonieanwendung
US7027582B2 (en) * 2001-07-06 2006-04-11 Telefonaktiebolaget L M Ericsson (Publ) Method and apparatus for resolving an entity identifier into an internet address using a domain name system (DNS) server and an entity identifier portability database
US20030074461A1 (en) * 2001-10-09 2003-04-17 I-Dns.Net International Pte. Ltd. Method of mapping names or identifiers to telecommunications network resource locations
US11341497B2 (en) * 2001-10-24 2022-05-24 Oleg Serebrennikov Method for performing transactional communication using a universal transaction account identifier assigned to a customer
AU2003216062A1 (en) * 2002-01-15 2003-07-30 Idetic, Inc. Method and system of accessing shared resources using configurable management information bases
US7161933B2 (en) 2002-09-24 2007-01-09 Intel Corporation Optimistic caching for address translations
FI20030797A0 (fi) * 2003-05-27 2003-05-27 Nokia Corp Tietokannan suorituskyvyn parantaminen nimipalvelinjärjestelmässä
US7454569B2 (en) * 2003-06-25 2008-11-18 Commvault Systems, Inc. Hierarchical system and method for performing storage operations in a computer network
DE602004008335T2 (de) 2003-12-19 2008-05-08 France Telecom Verfahren und Vorrichtung zum Senden von Abfragen von einer abfragenden Maschine zu einem Domainnamenserver
CN100359874C (zh) * 2004-01-12 2008-01-02 华为技术有限公司 接收方所在的多媒体业务中心获取私网地址的方法
CN1314239C (zh) * 2004-03-31 2007-05-02 中国科学院计算技术研究所 一种移动自组织网络中域名系统的实现方法
CN1878164A (zh) * 2005-06-08 2006-12-13 华为技术有限公司 E.164号码域名存储和查询方法
US20070091878A1 (en) * 2005-09-30 2007-04-26 Marian Croak Method and apparatus for providing endpoint and access independent virtual numbers
WO2007132108A2 (fr) * 2006-05-15 2007-11-22 France Telecom Procede de routage pour numeros non standard dans un mecanisme de routage pour numeros standard
US8879545B2 (en) 2007-12-31 2014-11-04 At&T Intelletual Property I, L.P. Methods and apparatus to route a communication session directly to a voicemail mailbox
WO2009105771A1 (en) * 2008-02-22 2009-08-27 Sage Connex, Llc Personal data portal on a pstn and online home with virtual rooms and objects
JP5753999B2 (ja) 2013-09-12 2015-07-22 メタフロンティア合同会社 端末装置、データ処理プログラム、及びデータ管理システム
CN103905581A (zh) * 2014-02-26 2014-07-02 曾宪钊 基于行为差异性的dns高速解析方案和配套的抗流量类攻击安全方案
US10673681B2 (en) * 2017-03-15 2020-06-02 Charles Lap San Chan System and method for enabling cross-domain communication over network
CN109787907A (zh) * 2017-11-14 2019-05-21 北京星河星云信息技术有限公司 一种云智能dns调度系统及其用户接入和域名解析方法

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2173304C (en) * 1995-04-21 2003-04-29 Anthony J. Dezonno Method and system for establishing voice communications using a computer network

Also Published As

Publication number Publication date
EP1207703B1 (en) 2004-08-18
JP2004194330A (ja) 2004-07-08
WO1997031490A2 (en) 1997-08-28
CN1209249A (zh) 1999-02-24
CA2239495A1 (en) 1997-08-28
DE69632495T2 (de) 2005-05-12
EP0876733A1 (en) 1998-11-11
GB9603590D0 (en) 1996-04-17
WO1997031490A3 (en) 1997-11-13
DE69633205D1 (de) 2004-09-23
NO982513L (no) 1998-08-05
NZ323991A (en) 1999-06-29
JP2000504917A (ja) 2000-04-18
EP1207703A2 (en) 2002-05-22
AU719651C (en) 2007-09-06
EP1207704B1 (en) 2004-05-12
JP4159603B2 (ja) 2008-10-01
AU719651B2 (en) 2000-05-11
NO325606B1 (no) 2008-06-23
AU1104597A (en) 1997-09-10
NO982513D0 (no) 1998-06-02
EP1207704A3 (en) 2002-09-18
DE69633205T2 (de) 2005-07-14
EP1207704A2 (en) 2002-05-22
DE69632495D1 (de) 2004-06-17
EP1207703A3 (en) 2002-09-18

Similar Documents

Publication Publication Date Title
JP3867079B2 (ja) 通信ネットワーク上の目標エンティティへのアクセス方法
JP3742108B2 (ja) 遠隔通信サービス提供方法
JP3742109B2 (ja) 遠隔通信サービス提供方法
US7903641B2 (en) Method and apparatus for accessing communication data relevant to a target entity identified by a number string
US6466570B1 (en) Method of accessing service resource items that are for use in a telecommunications system
US6131095A (en) Method of accessing a target entity over a communications network

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20060112

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20060314

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20060607

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20060612

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20060905

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20060928

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20061006

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20091013

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20101013

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20111013

Year of fee payment: 5

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20121013

Year of fee payment: 6

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20121013

Year of fee payment: 6

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313113

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20121013

Year of fee payment: 6

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20131013

Year of fee payment: 7

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

EXPY Cancellation because of completion of term