JP4159603B2 - 通信ネットワーク上の目標エンティティへのアクセス方法 - Google Patents
通信ネットワーク上の目標エンティティへのアクセス方法 Download PDFInfo
- Publication number
- JP4159603B2 JP4159603B2 JP52987197A JP52987197A JP4159603B2 JP 4159603 B2 JP4159603 B2 JP 4159603B2 JP 52987197 A JP52987197 A JP 52987197A JP 52987197 A JP52987197 A JP 52987197A JP 4159603 B2 JP4159603 B2 JP 4159603B2
- Authority
- JP
- Japan
- Prior art keywords
- service
- telephone
- resource
- domain name
- 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
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)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Telephone Function (AREA)
- Application Of Or Painting With Fluid Materials (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
本発明は、通信ネットワーク上で目標エンティティにアクセスする方法に関するものである。本発明は、交換遠隔通信システムにおけるINサービス(すなわちインテリジェント・ネットワーク・サービス)の提供に対する特定の適用を見出すものである。
本明細書において使用される用語「交換遠隔通信システム」は、搬送体ネットワークにわたる搬送体経路を設定する交換機能を備えた搬送体ネットワークを含むシステムを意味する。「交換遠隔通信システム」は、(アナログ電話あるいはISDN型のいずれの使用を問わず)既存の公共およびプライベート電話システムのみならず、現在実施中または将来登場するであろう広帯域(ATM)またはその他の交換型搬送体ネットワークを含むものとみなされるべきである。本明細書において、用語「交換遠隔通信システム」は便宜上遠隔通信システムと短縮して用いる場合がある。
交換遠隔通信システム環境における「呼び出し」は、搬送体ネットワークにわたる搬送体経路設定による通信を意味するものと理解されるべきであり、呼び出し設定、維持および切断は、搬送体ネットワーク上の搬送体経路を設定し、維持し、切断するプロセスを意味するものと見なされるべきである。「呼び出し処理」および「呼び出し取り扱い」のような用語は同様に解釈されるべきである。
本明細書で使用される用語「通信システム」は、交換遠隔通信システムより幅広い意味を持つものとして理解されるべきであり、各データ・パケットが、あらかじめ定められた搬送体経路に従うことなく、搬送体ネットワークを通して独立して経路指定されるデータグラム型通信システムを含むように意図されている。
発明の背景技術
PSTN(Public Switched Telephone Networksすなわち公共交換電話ネットワーク)およびPLMN(Public Land Mobile Networksすなわち公共地上移動体ネットワーク)を運営する遠隔通信会社は、通信サービスを提供する事業を行い、その事業において、800番サービスや呼び出し転送のような「INサービス」の形態で行う組み込み情報サービスを発展させている。対照的に、最近爆発的な成長がみられるワールド・ワイド・ウェブ(すなわちWWW)は、複雑な情報サービスを提供するインターネット型グローバル・ネットワークの1例である。大規模通信ユーティリティおよび非常に動的で開拓精神に富んだWWW情報文化というこれら2つの世界は、ぎごちない仲間であり、各々は相手によって既に占有された領域に浸透する計画をたてていて、将来、電話通信サービスがWWWを経由して提供され、情報サービスが公共通信下部構造を介して提供されるであろう。
本発明は、これら2つの世界の関係を現在より一層協調的なものにさせる技術を提案する。本発明の脈絡を明確にするため、先ず、これら2つの世界の各々について考察を加える。
INサービスにおける電話ネットワーク
基本的PSTN。PSTN(すなわちPublic Switched Telephone Network公共交換電話ネットワーク)によって提供される基本的サービスは、呼び出し側電話において入力された呼び出され側電話番号に従った2台の電話の接続(すなわち2つの電話の間の搬送体経路の設定)である。図1は、そのようなサービスを提供しているPSTNを単純化して表現したものである。特に、(アナログ電話または最近のISDN端末のような)宅内機器(すなわちCPE)10は、アクセス・ネットワーク11を経由して交換ポイント(すなわちSP)12に接続される。SP12は、SPの制御部15によって制御される相互接続用電話中継線14および複数のSPから構成される相互交換ネットワーク13におけるノードを形成する。制御部15によって実施される制御は、宅内機器(CPE)および他のSPから受け取る入力信号によって決定され、その制御は、呼び出しCPEと呼び出されCPEの間の所望の搬送体経路を作成する呼び出し設定、維持および切断を含む。概念的には、PSTNは搬送体ネットワークおよび制御(信号)ネットワークとみなすことができ、後者の機能は、搬送体ネットワーク上の呼び出し制御、すなわち搬送体経路の設定、維持および切断の実行である。実際には、搬送体および信号ネットワークは、同一の物理的回路および場合によっては同一の論理経路を使用することもある。
このように、CPEが伝統的な、知能のない電話である場合、CPEとそのローカルSPの間の制御信号機能は、バンド内信号機能である。すなわち、信号は音声のために使用されるものと同じ経路で搬送される。この信号は、SP12において、専用共通経路信号ネットワークを使用するSP間信号に変換される(現在このような変換はSS7プロトコール規格を使用して実施されている)。CPEがISDN端末である場合、信号は別の経路を介してCPEから直接搬送される。モデムSPは、CPEが標準の電話かISDN端末であるかを判断する相互交換呼び出し制御信号のためISUP(すなわちISDN User Part)SS7プロトコルを使用する。
電話番号割り当て方式−本発明の特定の局面は電話番号の構造によって影響を受けるので、電話番号構造について以下要点を記述する。電話番号は、10進デジットからなるグループに基づく国際的な階層的アドレス指定方式を形成している。階層の最高レベルは、ITU-Tによって管理されていて、主要な地理的地域に1桁の10進数コードを割り当てている(例えば、北アメリカに″1″、アフリカに″2″、ヨーロッパに″3″、南アメリカおよびキューバに″5″等々)。各地域内において各国に2または3桁の10進数が割り当てられる。例えば、地域3内においてフランスには″33″、地域4内において英国には″44″が割り当てられている。各国内の番号割り当て方式の管理は、例えば英国の通信局(通称”Oftel″)のような国家機構に一任されている。以下の記述は、英国の番号割り当て方式に基づいているが、記述される方式は広範な適用性を持っているものと認められることであろう。
英国においては、すべての番号は01から09までで始まる。現在、″01″は地域コードに、″02″は追加地域コードに、″04″は移動電話に、″07″は個人番号に、″08″は(無料電話、情報など)特別サービスに割り当てられている。通常のPSTN加入者電話番号は地理的な地域コードから割り当てられ、現在01で始まるコードだけが割り当てられている。地理的な地域コードは(先頭のゼロを除いて)現在3または4桁で、現在それぞれ638の地理的区域がある。英国のすべてのダイアル式電話番号は次の2つの形式である。
0 171 634 8700
地域コード ローカル番号(7桁)
0 1447 456 987
地域コード ローカル番号(6桁)
最初のケースは、先頭が″0″で、次に3桁の地域コードすなわち市外局番号、7桁のローカル番号と続き、第2のケースは、先頭が″0″、次に4桁の地域コード、6桁のローカル番号と続く。6桁アドレス空間でさえ単一交換にとっては大きすぎるので市外局交換の範囲内で更なるローカル番号の解釈が発生する。典型的なローカル地域に関して、必要とされる数の加入者回線を処理するためいくつかの交換が必要となる。この解釈は一般には見えず、地域サービス・プロバイダの問題である。
現在のPSTNにおいて、電話番号の本来的に階層的でかつ地理的な解釈は、ネットワークの物理的なアーキテクチャによって表される。電話番号は、ネットワーク上で呼び出し経路を定め易い方法で構成される。各ステップにおいて、番号の先頭コードは、現在の経路指定ステップに関する情報を提供し、後部コードは(多分見えないが)引き続く経路指定ステップ関する情報を提供する。交換機が先頭コードを解析し経路指定ステップを実行する方法を知っている限り、後部コードの内容を理解する必要はなく、それは後続の経路指定ステップに委ねられる。この理由のために、国際的および国家的交換網が階層的に組織される。
インテリゲント・ネットワーク。現在の電話ネットワーク下部構造の考察に戻ると、基本的呼び出し処理に加えて、SPはいわゆるINサービス(Intelligennt Networkの頭文字でインテリジェント・ネットワークの意味)を提供する。この場合、SPはサービス交換ポイント(service switching pointの頭文字をとって以下SSPと呼称する場合がある)と呼ばれる。SSP25は、特定の基準の充足に基づいて定義された被呼び出しポイントにおける呼び出し処理を中止し、サービス制御ポイント(すなわちSCP)17(図2参照)または補助ポイント(すなわちADJ)18のいずれかの形態でサービス制御機能(すなわちSCF)を提供するサービス制御サブシステムに呼び出し処理の継続を一任するように構成される。補助ポイント(ADJ)18はSSP25に直接接続し、一方、SCP17およびSSP25は、信号転送ポイント(すなわちSTP)を含む拡張共通経路信号ネットワーク(すなわちCCSネットワーク)16を通して相互に交信する。SCP17は、複数のSSP25に接続することもできる。SCP17および補助ポイント18は1つまたは複数のサービス論理プログラム(すなわちSLP)のインスタンス21が実行されるサービス論理実行環境(すなわちSLEE)20を提供する。SLEE20およびSLP21はSSP25にサービスを提供するためのサービス制御機能性をともに提供する。
SCPまたは補助ポイント上で動作するサービス論理は、サービス・データ機能(すなわちSDF)22に記憶される加入者情報を一般に活用する。SDFは、SCPと補助ポイントに統合されている場合もあれば、それぞれ部分的にあるいは完全に独立している場合もある。サービス・データ機能(SDF)は、サービス制御機能(SCF)と同様に、PSTNのサービス制御サブシステムの一部を構成する。サービス制御機能の一部またはすべてがPSTN交換機自体に組み込まれていることもある点に注意する必要がある。
SCP17および補助ポイント(ADJ)18に加えて、図2のネットワークは情報周辺器(すなわちIP)23を含む場合もある。IP23は、音声通知およびDTMF桁収集機能のような資源をSSP25に提供する。ネットワークは、ネットワークおよびそのサービスの全体を把握し、ネットワーク監視および制御のような機能を実行するオペレーティング・システム(図示されていない)を含む。
動作に関する限り、SSP25は、呼び出しを受け取ると、内部のトリガー条件、およびおそらく(ダイヤルされた桁のような)ユーザ情報を検査して、呼び出しがサービス制御サブシステム17、18によって提供されるべきサービスを要求しているか否かを確認する。トリガー条件の検査は、呼び出し処理におけるいくつかの異なるポイントで実行される。サービスが必要であると判断すると、SSP25は、サービス制御サブシステム(SCP17または補助ポイント18のいずれか)にメッセージを送り、所望のサービスを要求し、その接続および呼び出し処理状態に関する呼び出しの論理表現をサブシステムに送る。次にサービス制御サブシステムは要求されたサービスを提供するが、それは、SSPおよびサービス制御サブシステムの間の単一の交信または複数交信のセッションを伴う。典型的サービスは、呼び出され側サービスである呼び出し転送であり、これは,例えば、番号Xの加入者の要求に応じて、その加入者の番号が呼び出されて10回呼び出し音を鳴らしても出ない場合は番号Yを呼び出すようなサービスである。この場合、呼び出され側加入者にとってローカルにあるSSPがこのサービスを提供するためその接続SCP(または補助ポイント)を起動する。当然のことではあるが、SSPは呼び出される番号Xに関してサービスが提供されるべきことをあらかじめ知っていなければならない。
PSTNにおけるINサービスの提供に関する上述のモデルは、GSMおよびその他の移動体ネットワークのようなPLMN(すなわちPublic Land Mobile Networks公共地上移動体ネットワーク)にもあてはめることができる。移動体加入者の場合、通常の信号要件に加えて、移動体加入者への呼び出し経路を確立する必要があるので、信号制御は一層複雑である。しかしながら、これは、PSTNにおける多数の呼び出され側サービスと相違する問題ではない。かくして、GSMにおいては、サービス・データ機能(SDF)は、主に、ホーム・ロケーション・レジスタ(HLR)という名前をつけられたシステムに位置し、サービス制御機能は、一般的に各SSPと1対1で対応するビジタ・ロケーション・レジスタ(VLR)という名前をつけられたシステムに位置する(SSPはGSMの用語では移動体交換センタMSCと呼ばれる)。
加入者が移動体であるので、加入者プロフィールは、HLRから移動体加入者に機能的に最も近いVLRへ転送され、そのVLRが加入者プロフィールを使用して(定められた)サービスを操作して、SSPと交信する。このように、HLRおよびVLRは、その関連データベースを用いて、SCPまたはADJと同様のサービス制御サブシステムを構成する。
当然のことながら、プライベート電話システムにおいてINサービスを提供することは可能であり、この場合、サービス制御機能およびサービス・データ機能は、一般的にPABX(構内自動交換設備)に組み込まれるかまたはローカルのコンピュータによって提供される。サービス制御サブシステムはPABXと物理的に独立していない場合もある。
INサービスを提供する上記の一般的アーキテクチャ上のフレームワークは長所と短所を持つ。主な長所は、800番サービス、クレジットカード呼び出し、音声メールおよび種々の呼び出し待機と転送サービスのような多くのサービスがうまく展開されていることである。しかし、長年の標準化にもかかわらずそのようなサービスは、なおまだネットワーク・プラットフォーム上で一度に1つずつしか実施されず、十分な展開が図れない。何十万何百万もの加入者にサービスを提供する大規模な無故障システムを基に開発が進められ、実現には多くの年を必要とする。更に、これらのサービスをサポートするために使用されるネットワークは基本的電話下部構造を構成しているので、これらのネットワークに付加されるものは何でも厳格に吟味されなければならない。その上、各国および操作員はともすると標準のローカル・バリエーションを持つ傾向があり、それが標準製品の供給を困難にし、競争の力学を破壊する。
ワールド・ワイド・ウェブ(WWW)
電話下部構造の慎重な遅い進歩と対照的に、WWWは1989年におけるその発端から爆発的に成長して、情報内容の広がり、可用性および豊富さの観点からみて主要な電子情報分配サービスとなった。誰もが、わずかの出費で、高度に相互接続した情報アーキテクチャにおいて世界中の聴衆への情報提供者になることができる。
WWWは、インターネットを経由し、クライアントとサーバーの間で最も簡単な交換だけを委託するクライアント/サーバー・プロトコルを使用するクライアント/サーバー・アプリケーションである。このプロトコルは、インターネットのようなTCP/IPネットワーク上の使用のため最適化されたHTTP(すなわちHyper Text Transfer Protocol複合テキスト伝送プロトコル)であるが、HTTPプロトコルは、異なる通信プロトコル・スタックを使用するネットワーク上で使用することができる。
WWWに関する文献はWWW自体と同じように増大しているので、WWW、HTTPおよびインターネット関する詳細の記述は本明細書において行わない。しかしながら、本発明にとって意味のある特定の特性に焦点をあてた概要の記述だけを以下に行う。
WWWは相互接続のためインターネットを使用する。インターネットは世界的な規模でネットワークを相互に接続するシステムである。インターネットは、TCP/IPプロトコル規格に基づくもので、TCP/IPを使用するネットワークへの接続を行う。インターネット上に存在するエンティティ(すなわち実体)は、インターネットに接続したネットワークへのアクセスおよびIPアドレスを必要とする。IPアドレスは階層的に構成されている。一般的に、エンティティはユーザ・レベルで名前によって識別され、名前は、インターネットのドメイン名システム(Domain Name Systemの頭文字をとって以下DNSと略称する場合がある)によって対応するIPアドレスに分解される。DNSまたはその応用が以下に記述される本発明の少くとも特定の実施形態にとって必須のものであるので、DNSの一般的形式および動作を以下に記述する。
ドメイン名システム(DNS)−DNSはグローバルな分散型データベースであり、その実行、弾力性および拡張性なしにはインターネットは現在の形式でほとんど存在しないであろう。DNSは、クライアントの要求に応答して、インターネット・ホスト・ドメイン名を異なるタイプの1つまたは複数の登録レコード(Registration Recordの頭文字をとって以下RRと略称する場合がある)と関連づける。それらタイプのうちで最も普遍的なものは、(15.144.8.69)のようなアドレス(A)レコードおよび(ドメインのため電子メールを受けるように構成されたドメイン・ホストを識別するために使用される)メール交換(MX)レコードである。RRは世界中のDNSネーム・サーバーに分配され、これらサーバーが連係してドメイン名変換サービスを提供する。単一のDNSサーバーはグローバルなデータベースの小さい部分しか含まないが、各サーバーは、そのデータに自分より近くにあるDNSサーバーを探り当てる方法を知っている。DNSの特徴は次の通りである。
--ホスト名空間は、ツリーに組み立てられたノード階層として構成され、各ホストは対応する葉ノードを持つ。各ノードは(ルート・ノードを除いて)先頭がアルファベットで以下にいくつかの英数字シーケンスが続くラベルを持つ。1つのホストの完全な名前は、各々がピリオドで隔てられた、階層の対応する葉ノードからルート・ノードまでの複数のノード・ラベルのストリングである。後者のルート・ノードは終端ピリオドによって表される。このように、例えば、EnglandのBristolにあるHewlett-Packard Laboratoriesのホスト機″fred″は、″fred.hpl.hp.com.″という認定されたドメイン名を持つこととなる(注:もしもホスト名が終端ピリオドを持たないとすれば、それは名付け階層の現在時ノードに関する名前と解釈される)。
--各ホストは1つまたは複数の関係登録レコード(RR)を持つ。
--各々が名前空間のサブツリーに対する責任を持つ複数のDNSサーバーがある。1つのDNSサーバーは、そのサブツリーの全部または一部に関するRRを持つ。−後者の場合DNSサーバーはサブツリーの残りに関する責任を別の1つまたは複数のDNSサーバーに委譲する。DNSサーバーは責任を委譲したすべてのサーバーのアドレスおよびそのサーバーが管理するサブツリーに関する責任を委譲したサーバーのアドレスを知っている。このように、DNSサーバーは名付け階層において相互にポイントし合う。
--DNSを使用することを望むアプリケーションは、少くとも1つのDNSサーバーのアドレスを知っている関連「解決機構」を通してDNSを使用する。DNSサーバーが指定されたホストのRRに関してこの解決機構によって問い合わせを受けると、DNSサーバーは、要求されたRRか、または、名づけ階層をたどるためRRを保持するサーバーに一層近いDNSサーバーのアドレスか、いずれかを返す。実質的には、解決されるべきドメイン名に対する責任を持つサーバーに到達するまでサーバーの階層を登り、その後、解決されるべきドメイン名に関するRRを持つサーバーまでDNSサーバー階層を下る。
--DNSは、あらかじめ定められたメッセージ形式を使用し(実際それは問い合わせおよび応答に関して同じものであるが)、IPプロトコルを使用する。
DNSのこれらの特徴は、ラベル構文、ラベル組み合わせ方法、メッセージ形式細部、IPプロトコル進化等々におけるような若干のバリエーションを常に許容する″DNSタイプ″システムを定義するものとみなすことができる。
階層的名づけ構造のため、名前空間の管理ドメイン(サブツリー)に対する責任を再帰的に委譲するすることが可能である。従って、トップレベルのドメインはInterNicによって管理される(これらトップレベル・ドメインは、よく知られている’com’、’edu’、’org’、’int’、’net’、’mil’などのドメインや、’us’、’uk’、’fr’などのような標準的2文字によって指定される国ドメインを含む)。次のレベルでは、例えば、ヒューレット・パッカード社は’hp.com’で終わるすべての名前に対して責任を持ち、British Universitiesは’ac.uk’で終わるすべての名前に対して責任を持つ。更にその下のレベルでは、例えば、ドメイン’hpl.hp.com’の管理はヒューレット・パッカード研究所の責任であり、ドメイン’newcastle.ac.uk’の管理はUniversity of Newcastle-upon-Tyneの責任である。
図3は、ヒューレット・パッカード研究所から行われる照会の例の動きを示す。解決されるべきホスト・ドメイン名は、英国のUniversity of Newcastleにある仮想的機械である’xy.newcastle.ac.uk’である。照会は、″hpl.hp.com″サブツリーに責任があるDNSサーバーに提示される。このサーバーは、要求されたRRを持たないので″hp.com″DNSサーバーのアドレスを応答する。次にこのサーバーが照会され、″com″DNSサーバーのアドレスを応答し、次にそのサーバーが’.’(ルート)DNSサーバーのアドレスを応答する。次に照会は、’newcastle.ac.uk’サーバーがそのサブツリーにおける名前’xy’に対するRRレコードを応答するまで’uk’ブランチを反復的に下方向へ進む。
これは非常に非能率に見えるが、DNSサーバーは動的キャッシュを構築するように設計されていて、いくつかのルート・サーバーのアドレスを含むように初期化されているので、実際には反復的な照会はほとんど起こらない。このケースにおいて、’hpl.hp.com’DNSサーバーは、いくつかのルート・サーバーのアドレスを知っていて、’uk’および’ac.uk’サーバーのアドレスはおそらくキャッシュに持っていることであろう。’hpl.hp.com’サーバーへの最初の照会が’ac.uk’サーバーのアドレスを返すであろう。’ac.uk’サーバーへの2番目の照会が’newcastle.ac.uk’サーバーのアドレスを返し、3番目の照会が目的のRRを返すであろう。’newcastle.ac.uk’を先頭に持ついかなるその後の照会も、そのアドレスが″hpl.hp.com″DNSサーバーのキャッシュに保持されるので、newcastleDNSサーバーへ直接進むであろう。実際、ローカルのサブツリーの範囲内の名前は単一照会で解決され、ローカル・サブツリーの外側の名前は2回またはか3回の照会で解決される。
解決機構は、ドメイン名を解決するために必要とされる一連の照会反復を実行することに対して責任があるというよりはむしろ、再帰的な第1の照会を指定してその照会に関して責任のあるDNSサーバに送り、その受け取りDNSサーバーが要求されたRRを直接戻すことができなければ次により近いDNSサーバーへ再帰的照会を発する。
実際には各DNSサーバーは複製されている点、すなわちプライマリと1つまたは複数のセカンダリに構成されている点に注意する必要がある。プライマリDNSサーバーはローカル・ファイル・システム上に維持されるデータベースから自らを初期化し、セカンダリはプライマリから情報を伝送することによって初期化する。サブツリーは、通常1つのプライマリDNSサーバーおよび最高10までのセカンダリを持つ。セカンダリの数の限度は、プライマリからのデータベースを更新するために必要となるセカンダリの時間による。プライマリ・データベースは、サブツリー情報のマスター・ソースでりあ、ドメインDNS管理者によって維持される。セカンダリは単なる待機セカンダリではなく、プライマリではなくセカンダリをポイントする従属サーバーとのDNSに活発に参加する。
BINDのようなDNS実施形態は、大部分のUNIXシステムの標準部分として広く普及していて、現存する最も強力で広範に使われている分散アプリケーションの1つであるといえる。
WWWの動作。図4を参照すれば、インターネット30へのアクセスは、直接または間接的にそれ自体インターネットに接続しているネットワークへの直接接続によって行われる。そのような構成は図4における端末31によって代表される(この端末は例えばUnixワークステーションまたはPCである)。このような形式でのインターネットへの接続は、「ネットワーク・アクセス」の実行として知られている。インターネットへネットワーク・アクセスするいかなるエンティティも、十分な関連機能性を持っていることを前提とすれば、インターネット上のサーバーとしての役割を果たす。例えば、図4において、ファイル記憶機構37を持つエンティティ32は、サーバーとしの働きをする。
WWWの多くのユーザは、インターネットへのネットワーク・アクセスを行わず、その代わりに、ネットワーク・アクセス機能を持つインターネット・サービス・プロバイダすなわちISP33を経由してインターネットへのアクセスを行う。このケースでは、ユーザ端末34は、一般的には、モデムを使用しSLIP(すなわちSerial Line Interface Protocolシリアル・ライン・インタフェース・プロトコル)またはPPP(すなわちPoint-to-Point Protocolポイント・ツー・ポイント・ポイント・プロトコル)を利用して公共電話システムを経由してISP33と通信する。これらのプロトコルは、インターネット・パケットが通常の電話線で伝送されることを可能にする。この形式のインターネットへのアクセスは、「ダイヤルアップIP」アクセスとして知られている。このアクセス方式では、ユーザ端末34は各ユーザ・セッションの間一時的にIPアドレスを割り当てられる。しかしながら、このIPアドレスはセッション毎に異なるので、エンティティ34はサーバーの役割を果たすことはできない。
WWWの基礎は、統一資源識別子(すなわちUniform Resource Identifierであり以下略してURIと呼ぶ)という手段によって特定の情報資源の位置を定める能力である。URIは、一般に、位置によって資源を特定する統一資源位置特定子(すなわちUniform Resource Locatorであり以下略してURLと呼ぶ)か、または、URLへ変換可能な統一資源名(すなわちUniform Resource Nameであり以下略してURNと呼ぶ)かのいずれかである。例えば、完全すなわち「絶対」URLは次のようなエレメントを含む。
方式−これは、目標資源にアクセスするために使用されるアクセス方式である。
ホスト−インターネット・ホスト・ドメイン名またはIPアドレス。
ポート−(TCP)接続のためのホスト・ポート。
絶対経路−ホスト上の資源の絶対経路。
実際には、ポート80が想定される場合「ポート」は省略できる。
図5は、ヒューレット・パッカード製品ウェルカム・ページのためのURLを示している。この場合エレメントは次の通りである。
方式−http
ホスト−www.hp.com
ポート−省略(ポート80が仮定されている)
絶対経路−Products.html
HTTPプロトコルは、要求/応答パラダイムに基づいている。図4を再び参照すれば、アクセスされるべき資源30を識別する特定のURIを所与とすれば、クライアントは、URIの「ホスト」エレメントに対応するサーバー31との接続を確立してそのサーバーに要求を送る。この要求は、要求方法および「要求URI」を含む(「要求URI」は一般的にURIの絶対経路によって識別されるサーバー上の資源の絶対経路そのものである)。要求は付加的データ・エレメントを含むこともある。サーバー31は次に(この例では記憶装置37に記憶されている)資源36にアクセスし応答する。この応答は、MIME(すなわちMultipurpose Internet Mail Extensions汎用インターネット・メール拡張)タイプによって識別されるタイプを持つエンティティを含む。
主な要求方法は次の2つである。
GET−この方法は、要求URIによって識別されるいかなる情報をも(エンティティの形式で)取り出す。重要な点であるが、要求URIがデータ作成プロセスを参照している場合応答においてエンティティとして返されるものは作成されたデータであり、プロセスのソース・テキストではない。
POST−宛先サーバーが要求URIによって識別される新しい従属資源として要求に含まれたエンティティを受け入れることを要求するためにこの方法が使用される。ポスト方法は、既存の資源の注釈付けのために使用できる。すなわち、この方法は、例えば、掲示板にメッセージを提供し、データ処理プロセスにデータ(例えば形式を提出する結果として作成されたデータ)を提供し、追加演算を通してデータベースを拡張する。
要約すれば、GET方法は、直接データを取り出すためか、あるいは、(例えばデータあるいはプロセスを実行結果の単なる指示である)エンティティを返すプロセスを起動するために使用される。POST方法は、データを登録し、この方法がポストされたデータを適切に処理するためサーバーにおけるプロセスを起動させる上で効果的であることを示すために使用される。
GETまたはPOSTいずれかの方法を使用してサーバー上での実行を起動されるプロセスへの情報の伝達は、現在、コモン・ゲートウェイ・インターフェース(すなわちCGI)と呼ばれるインタフェースに従って行われている。受け取りプロセスはスクリプト言語で書かれることが多い(必ずしも必須ではないが)。典型的には、起動されるサーバー・スクリプトは、GET要求に含まれる照会を取り扱うためデータベースへのインタフェーシングのため使用される。もう一つの用途は、上述のよう、POST要求に関連したデータをデータベースへ追加することである。
WWWの成功におけるその他の重要な要因は、WWW上に伝送されるドキュメントの構成を表現するハイパーテキスト・マークアップ・ランゲージ(すなわちHTML)の使用、および、そのようなドキュメントをクライアント端末のユーザに提示するためそれらを解釈するNetscapeやMosaicのような強力なグラフィック・ウェブ・ブラウザの存在である。基本的には、HTMLはタイトルまたはグラフィックのようなドキュメントの各部分を識別するために使用され、次に各ドキュメント部分を表示する方法の決定はクライアント端末で実行されるブラウザにまかされる。しかしながら、HTMLはそれ以上のものであり、URIおよび要求方法を(特定のワードまたは画像のような)ドキュメントのすべてのエレメントに関連づけることを可能にし、従って、ユーザがそのエレメントをポイントしクリックすると、URIによって識別された資源が、指定された方式(プロトコル)および要求方法に従ってアクセスされる。このような構成によって、1つのドキュメントから他のドキュメントへのハイパーリンク(複合接続)が提供される。そのようなハイパーリンクを使用して、クライアント端末におけるユーザは、世界の一方の側にあるサーバーからダウンロードされたドキュメントを世界の別の側のサーバー上に位置する別のドキュメントへ苦もなく飛ぶ(すなわちスキップする)ことができる。1人の作者によって作成されたドキュメントが別の作者によって作成されたドキュメントへのハイパーリンクを含むこともあるので、中央集権的制御なしに非常に強力なドキュメント相互参照システムが実現する。
ハイパーリンクは、HTMLドキュメントに組み込むことができる唯一の機能ではない。もう1つの強力な機能は、ダウンロードされた「形式」ドキュメントに画面上で記入し、入力された情報を収集するように設計された(データベースのような)資源に入力情報を渡してもらうため「提示(commit)」ボタンを起動させる能力である。これは、POST要求をデータベース資源のURIと共に’commit’ボタンをPOST要求方法に関連づけることによって達成される。’commit’ボタンの起動によって、入力された情報は、適切に処理される場所である、識別された資源に渡される。
更にもう1つの強力な可能性は、(一般的には翻訳されるべきスクリプトである)プログラム・コードをグラフィック・ボタンのような特定のドキュメント・エレメントに関連づける機能である。この場合プログラム・コードはボタンが起動されると実行を開始する。これは、ユーザに対し、資源からのプログラム・コードのダウンロードおよびその実行の可能性を与える。
当業者に認められることであろうが、HTMLは、上記概説した機能性を提供するいくつかの現在利用できるスクリプト言語のうちの1つにすぎず、いかなるウェブ・ブラウザも複数のスクリプト言語の組み込みサポートを持つであろうことは予想することができる。例えば、Netscape2.0は、HTML3.0、Javaおよび(Netscape版権所有スクリプト言語である)LiveScriptをサポートする。
グラフィック・ウェブ・ブラウザ自体の役割の重要性は看過されてはならない。複数のスクリプト言語をサポートする能力に加えて、ウェブ・ブラウザは、標準的媒体タイプに対する組み込みサポートおよびクライアントにプログラムをロードし実行する機能などを提供する。このようなブラウザは、WWW交信に関するオペレーティング・システムとみなされることもできる。
WWWおよび電話ネットワーク
音声入力をデジタル化してインターネット上に離散的パケットの形で送信し、それ端末で受け取って再組み立てすることによって接続された端末の間でインターネットを経由して電話通信サービスを提供することは可能である。これは、インターネット上の通信サービスの1例である。反対に、フランスで広く利用されているMinitelのような電話システム上で提供される種々の情報サービスが可能である。しかしながら、相互の伝統的領域へのこのような浸透はインターネットまたは公共電話システムにとって本当の脅威とならない。
一層関心があるのはインターネットおよび電話システムの協調使用の分野である。実際、図4を参照して記述したものの中にそのような分野の1つがある。それは、インターネットへのダイヤルアップIPアクセスを取得するためユーザ・コンピュータ34からインターネット・サービス・プロバイダ33へのPSTN上のモデム・リンクの使用である。この協調使用は、非常に単純な特性を持っている。すなわち、後に生成されるインターネット・トラフィックのためのPSTN上の搬送体経路の設定である。インターネットおよびPSTNの間には実際の交信はない。
インターネットとPSTNの協調使用のもう1つの既知の例は、最近実施されたもので、端末コンピュータにサウンド・カードを持つインターネット・ユーザが世界中のどこにでもある標準電話に音声通話を行うことができるサービスである。これは、インターネット上でデジタル化された音声を宛先電話の近くのサービス・プロバイダに伝送することによって達成される。このサービス・プロバイダは、所望の電話にアクセスするためローカルのPSTNに接続して、インターネット上で受け取った音声トラフィックをそのローカルPSTNへ転送する。呼ばれた電話からの音声入力は逆経路で取り扱われる。このサービスの鍵は、宛先電話にとって(料金的に)ローカルなサービス・プロバイダを識別する能力である。長距離呼び出しに関して通信操作員に対する競争の可能性をもたらしてはいるが、この構成もまたインターネットとPSTNの単純な相互連携である。しかしながら、この場合、注意すべきことであるが、宛先にとってローカルなPSTN上で宛先電話に対して行われている呼び出しの進捗状況に関してインターネット呼び出し側へ少なくとも最小限度のフィードバックを提供することが必要である。このフィードバックは、単に呼び出しが成功したか否かという観点からのものでよい。
インターネットと電話システムの現在の協調使用が非常に単純なレベルにあることは以上の記述から明らかである。
PSTNとWWWの統合を実現する通信ネットワーク上で目標エンティティにアクセスする方法を提供することが本発明の目的である。
発明の開示
本発明の1面に従って、通信ネットワーク上で目標エンティティにアクセスする方法が提供される。該方法は、
(a)−各々が対応するドメイン名に関連づけられ、目標エンティティへのアクセスの際に使用される通信データを含む複数のレコードを記憶し、上記番号ストリングの少なくとも相当な部分を上記ドメイン名の少なくとも一部に解析することを含むプロセスによって対応するドメイン名を取り出すことができるように各ドメイン名がそれぞれの番号ストリングと関連づけられているように構成されたDNSタイプ分散データベース・システムを提供するステップ、
(b)−目標エンティティを標示する番号ストリングを供給し、上記番号ストリングの少なくとも相当な部分を上記ドメイン名の少なくとも一部に解析することを含む上記プロセスによって対応するドメイン名を作成するステップ、
(c)−上記ステップ(b)において作成されたドメイン名をDNSタイプ分散データベース・システムに適用して、対応するレコードに含まれる通信データを取り出すステップ、および、
(d)−目標エンティティにアクセスする際上記ステップ(c)で取り出した通信データを使用するステップ、
を含む。
1つの適用において、通信ネットワークが電話ネットワークであり、目標エンティティが呼び出される側である。この場合、例えば、番号ストリングはダイヤルされた番号を含み、取り出される通信データは呼び出される側の現在時電話番号である。代替的形態において、取り出される通信データが、呼び出される側の現在時電話番号に関するコンピュータ・ネットワーク上の位置を標示するURIであり、このURIを使用して、呼び出される側をアクセスする際に使用される現在時電話番号が取り出される。
別の適用において、通信ネットワークがコンピュータ・ネットワークであり、目標エンティティがそのネットワーク上の対応するURIに保持されている資源項目である。この場合、番号ストリングは目標エンティティに関する電話番号を含み、取り出される通信データは目標資源項目のURIである。この目標資源項目は、例えば、呼び出したい目標エンティティの現在時電話番号であり、上記番号ストリングがその目標エンティティに関する個人電話番号である。
更に一般的には、上記資源項目は、
--アクセスされ次第アクセス・エンティティにダウンロードされるように意図されたダウンロード可能データ、
--アクセスされ次第アクセス・エンティティによる実行のためアクセス・エンティティにダウンロードされるように意図されたダウンロード可能サービス論理、
または、
--アクセスされ次第実行されその結果がアクセス・エンティティに返されるように意図されたサービス論理、
である。
上記番号ストリングの少なくとも相当な部分の上記ドメイン名の少なくとも一部への解析は、すべての番号ストリングに関して同一である分割方式に従って上記相当な部分をラベル・セグメントに分割することによって実施することができる。しかし、番号ストリングが国際電話番号である場合、上記番号解析は、好ましくは、国際電話番号の国コード成分のラベル・セグメントを作成し、次に、そのような番号のすべてに対して同一である分割方式に従って国際電話番号の残り部分から更なるラベル・セグメントを作成することを含む。代替的形態として、国際電話番号の残り部分から更なるラベル・セグメントの作成は、上記国コード成分の識別に依存する分割方式に従って実施される。
DNSタイプ分散データベース・システムは、本明細書において″telname(電話名)空間″と呼ばれる名前空間を構成するドメイン名セットを取り扱うことができるように適用される。1つの構成において、telname空間のルートは、DNSタイプ分散データベース・システムによって取り扱われる全名前空間のルートである。しかしながら、本発明の好ましい実施形態においては、DNSタイプ分散データベース・システムはインターネットのDNSによって提供される。この場合、telname空間はDNSの1つまたは複数のサブドメインによって提供されることもできる。例えば、番号ストリングが電話番号である場合、telname空間は、DNSのドメイン″.itu.int.″における″tel″サブドメインを形成することができるが、代替的方法として、telname空間は、DNSの国ドメインの少くともいくつかにおけるそれぞれのサブドメインによって提供されることもできる。
telname空間が比較的大きい名前空間のサブドメインである場合、番号ストリングのあらかじめ定められた部分を使用して、その比較的大きい名前空間におけるtelname空間のルートに対応するドメイン名末尾を照合することもできる。このドメイン名末尾は、番号ストリングの少なくとも相当な部分の上記解析によって取り出されるドメイン名部分に追加される。このように、番号ストリングが国際電話番号でありtelname空間が国サブドメインの間で分割されている場合、国コード成分を使用して、該当するサブドメインに対応するドメイン名末尾を照合することができる。
【図面の簡単な説明】
下記の添付図面を参照しながら、制約を持たない例を用いて、以下に本発明の実施形態を記述する。
図1は、標準的PSTNを単純化して示したブロック図である。
図2は、INサービスを持つ既知のPSTNを単純化して示したブロック図である。
図3は、インターネットのDNSによるホスト・ドメイン名解決を示すブロック図である。
図4は、ワールド・ワイド・ウェブの機能性を示すブロック図である。
図5は、標準的URL形式を示すブロック図である。
図6は、サービス資源項目がPSTNのサービス制御サブシステムおよびウェブ・ユーザの両者によるアクセス可能なHTTPサーバー上に保持されている本発明の第1の実施形態を示すブロック図である。
図7は、図6のSCPによるサービス要求の処理を示す流れ図である。
図8は、サービス資源項目にアクセスする時図6のSCPによって使用される資源コードの形式を示すブロック図である。
図9は、サービス・コードがRRI部分を含まない場合におけるサービス資源にアクセスするプロセスの流れ図である。
図10は、サービス・コードがRRI部分を含む場合におけるサービス資源にアクセスするプロセスの流れ図である。
図11は、入力電話番号を解析することによってサービス資源のURを導出するプロセスの流れ図である。
図12Aは、あらかじめ定められたセットの電話番号を解析することによって導出されるドメイン名によって構成される名前空間(すなわち’telname space’)を示すブロック図である。
図12Bは、細分化なしでtelnet spaceをDNSに編入する様態を示すブロック図である。
図12Cは、細分化された形態でtelnet spaceをDNSに編入する様態を示すブロック図である。
図13は、標準電話でダイヤルされた電話番号に応答して徘徊番号サービスを提供する際の図6の実施形態の全般的動作を示すブロック図である。
図14は、ウェブ端末に組み込まれた電話インタフェースを通して呼び出しを設定する際にウェブ・ユーザによって利用される場合の図6の実施形態の全般的動作を示すブロック図である。
図15は、電話トラフィックに対してPSTNとインターネットの間のインタフェースが提供される本発明の第2の実施形態のブロック図である。
図16は、PSTNとインターネットの間で呼び出し設定ゲートウェイが提供される本発明の別の実施形態を示すブロック図である。
図17は、着信無料電話サービスがウェブ・ユーザのために実施される本発明の更に別の実施形態を示すブロック図である。
図18は、PSTNのサービス制御サブシステムのエレメントを相互接続する分散処理環境の提供を示す図6と同様のブロック図である。
発明の実施形態
図6は、少なくその一部が、(IPに関連づけられたSSP41である電話中継線および交換機を含む)相互交換ネットワーク13、(電話40のような)顧客機器をネットワーク13に接続するアクセス・ネットワーク11、および要求に基づいてSSP41に対してサービスを提供する少くとも1つのSCPを含むサービス制御サブシステム42を従来の通り含むPSTNにおける諸サービスを提供する構成を示している。図6のPSTN表現は非常に図式化されている点は認められることであろう。
SCP43は、従来技術の方法でSSP41からのサービス要求に応答して、サービス要求に含まれる情報に従って特定のデータに対する特定のサービス論理を実行させ、呼び出し設定を実行するための適切な命令を要求元SSPに送り戻す。SSPは、トリガー・チェック・ポイントにおいて充足されるあらかじめ定められたトリガー条件に応答して、サービス要求を生成する。チェック・ポイントは呼び出しを処理する過程において1つまたは複数存在する(注意すべきは、トリガー条件がSCPからSSPへダウンロードされた場合トリガー条件が満たされ次第SCPにコンタクトする時SSPはSCPによる情報要求に応答しているといえるが、本明細書では、SSPからSCPへのこのような初期的通信を「サービス要求」と呼ぶ)。
SCP43は、また、SSP41からの少なくとも特定のサービス要求の処理の過程において特定のサービス資源項目(以下単にサービス資源と呼ぶ)49を利用するためインターネット50に対するネットワーク・アクセス・インタフェース44を備えている。これらサービス資源49は、HTTPサーバー51上で(特にこれらサーバー51のサービス資源データベース52上で)WWWページとして保持されている。
これらサービス資源を含むWWWページを以下「電話」ページと呼ぶ。サーバー51がインターネットに接続され、電話ページはURLまたはURNを使用してアクセスされ読み取られる(便宜上、以下の記述ではURLまたはURNの代わりに、電話ページの位置のインターネットで解釈可能な識別子を意味するように、より一般的用語URIを使用する)。
サービス資源は場合によってはサービス論理またはサービス・データである。サービス資源は、適切なURIを使用して必要とされる資源の電話ページにアクセスすることによって、SCPの上で動くその他の標準サービス論理プログラムによって使用されることもできる。一定のケースにおいて、サービス資源49は、特定のサービスに関連づけされたサービス制御およびデータのすべてを実質的に提供するかもしれない。この場合、SCP43の中で動くサービス論理プログラムは骨組みの形式であり、サービス要求の受領とともにインスタンス化され、サービス資源アクセスを始動し、そのアクセス結果をサービス要求を行ったエンティティに返すように機能する。実際、このようなアプローチに従って、SCPは電話サービス論理を取り出し実行するプラットホームとして容易に実施することが可能であり、標準のSCPプラットホームによって要求されるような論理のための複雑な準備/管理システムを必要としない。SCPはおそらくあらゆるSSPと関連するようにいたるところに存在させることができる。
図7は、SCP43が電話ページ・サービス資源にアクセスすることによってサービス要求を取り扱う場合の事象のプロセスを示す流れ図である。INAPメッセージにおいてサービス要求を受領するとともに(ステップ100)、SCP43は、当業者に理解される標準的方法でTCAP/INAPメッセージを解読する(ステップ101および102)。次に、SCP43は、要求を処理するためサービス論理プログラム(すなわちSLP)をインスタンス化する(ステップ103)。次に、このSLPは、サービス要求に含まれる情報から判断される要求サービス資源のURLを調べる責任を持つ(ステップ104、105)。例えば、サービス要求が呼び出され側サービスに関するものであれば、要求資源はダイヤルされた番号によって示され、その番号を使用して資源のURLが導出される。要求サービス資源のURLが確認されたならば、(例えばHTTP要求メッセージの形式で)資源要求がインターネットを経由して要求されたサービス資源を持つ対応するサーバーに送られる(ステップ106)。また、サーバーからの応答が適切なSLPインスタンスにリンクされることを可能にするように相関ID(correlation ID)も送られる。またタイマが始動される(ステップ107)。
(ステップ108で検査される)タイムアウト期間の満了の前にアクセスされた資源から応答が受け取られると、通常は宛先番号の形式である応答が、応答と共に渡された相関IDを使用して識別される適切なSLPに送られる(ステップ109)。次に、INAP/TCAP応答メッセージが準備され、オリジナルのサービス要求を行ったエンティティへ送られる(ステップ110および111)。その後、SLPセッションは終了する(ステップ113)。
ステップ108で、応答が受けられる前にタイムアウトが発生する場合、顧客レコードからデフォルトの応答値(一般的にはデフォルトの宛先番号)が取り出され、INAP/TCAPメッセ時に書き込まれ、要求元エンティティへ送り返される(ステップ114および116)。その後、SLPセッションは終了する(ステップ113)。
サービス資源の位置確認およびアクセス
電話ページ資源にアクセスすることに関連する機能性は、図6の資源アクセス・ブロック46によって表される。ブロック46は、ブロック46に渡されるパラメータに基づいて要求された資源を含む電話ページのURIを決定するURI決定ブロック47を含む。次に、ブロック47によって返されるURIを使用して、資源アクセス・ブロック46はインタフェース44を経由してインターネット上で所望のサービス資源49の電話ページにアクセスする。
資源コード−1つまたは複数のサービス資源が特定の電話番号と関連することは可能である。この場合、資源アクセス・ブロック46は、該当するサービス資源を識別することができるように、(現在時呼び出しポイントすなわちpoint-in-call略してpicのような)追加情報を知る必要がある。1つの番号に関連づけらた(複数)サービス資源が異なる電話ページに位置しているとすれば、適切な電話ページのURIを返すことを可能にするため、上記追加情報がURI決定ブロック47へ渡される。1つの番号に関連づけられるサービス資源のすべてを同一の電話ページ上に位置させることも可能である。この場合、資源アクセス・ブロック46は、追加情報を使用してアクセス要求と共に資源識別パラメータを対象電話ページに送る。そこで正しいサービス資源へのアクセスは電話ページに関連する機能性に依存する。
このように、各サービス資源はそれぞれ対応する資源コード54によって識別されることができるが、図8に示されるように、資源コード54は、第1部分と第2部分からなり、第1部分は、その資源がインターネット上で位置するURIを識別するURI識別子(略してUIと呼ぶ)であり、第2部分は、同一URIにおける複数資源の中から該当資源を識別するために使用される相対的資源識別子(略してRRIと呼ぶ)である。
資源アクセス−1つのサービス資源49だけがユニークなURIによって識別される電話ページ58に位置する場合、資源コード54は、単にUIを含むだけである。この場合UIは、一般的には、電話番号、または、電話番号プラスpicパラメータのいずれかである(図9参照)。この場合、資源へのアクセスは、全部の資源コード54を対応するURIにマップし(プロセス55)、次に対応する電話ページ58に要求57を送ることを含む。この電話ページ自体が所望のサービス資源49を構成している。資源49へのアクセスの結果は応答メッセージ59として返される。
対照的に、複数のサービス資源49が同じ電話58ページに位置する場合、図10に示されるように、資源コード54はUIおよびRRIの両方を含む。一般的には、UIは電話番号であり、RRIは、複数共存資源を区別するpicなどのパラメータである。この場合、資源へのアクセスは、資源コード54のUI部分を対応するURIに対応付けして(プロセス55)、次に、該当する電話ページへ資源コードのRRIを含む要求57を送信する(プロセス56)ことを必要とする。電話58ページは、要求メッセージの中のRRIに基づいて所望の資源にアクセスする機能性64を含む。次に、所望の資源49へのアクセスの結果が応答メッセージ59の中に含まれて返される。
1つの電話ページ上で他の資源と共存するサービス資源へアクセスする図10の方法に対する代替方法は、資源コードのUI部分から導出されるURIを使用してインターネットにわたる全ページを取り出し、RRIに基づいて所望の資源を抽出するものである。
資源コードからのURI決定−プロセス55を実行するURI決定ブロック47の実施形態を次に記述する。ブロック47の実施形態には次の4つの形態がある。
直接入力
必ずしも便利ではないが、呼び出し側が所望のURIを直接入力するように構成することは可能である。この場合、呼び出し側は、(ホスト・ドメイン名またはホストIPアドレスの形式のいずれかである)所望のURIのホストIDコンポーネントおよびURIの経路コンポーネントを入力する。例えば、呼び出される側の電話ページがアクセスされるべきものである場合、呼び出し側は呼び出される側のURIを入力するかもしれないが、この入力が実際に通常の電話番号入力であることもある。URIとしての入力であることを識別するため、(例えば’999’のような)ストリングを先頭に入力することもできる。入力手段に関する限り、ユーザが標準の12キー電話だけを持っている場合、アルファベット文字を必要とするホスト・ドメイン名およびその他のURIエレメントは、電話パッドから入力されるアルファベット文字に関する標準的技術の1つの使用を必要とする(そのような技術は、例えば呼び出し側が呼び出され側の名前の綴りを入力することを可能にするため既に使用されている)。URI入力を容易にするためユーザにすべての英数字キーを含むキーパッドを提供することも可能である。
計算
インターネット上でのサービス資源アクセスは、対応するURIを計算できる元となるダイヤル番号セットに制約される可能性がある。この場合、この計算はブロック47の責任である。
関連テーブル照合
ブロック47に関する最も単純な実施形態は、URIを各資源コードのUI部分に関連づける(メモリまたはデータベース・ディスク記憶装置48のいずれかの形での)関連テーブルである。このアプローチにまつわる潜在的問題は、世界の別の側にある呼び出され側番号に関するサービス資源が必要とされるかもしれないということであり、これは、関連テーブルの最新性を維持するための世界的規模でのPSTN操作員間の厳格な更新制度を意味する。(注:サービス要求を起動するため必要とされるものとして呼び出されれ側番号をマークすることに関しては、800番サービスにおけるように、その番号を該当するサービス要求を起動するすべての番号のグループの1つであるように取り決めることができるので、上記のような問題は必ずしもあてはまらない)。
DNSタイプ照合
資源コードのUI部分を対応するURIに変換するための代替的照合方法は、インターネットのドメイン名システム(DNS)に対するものと同様な、階層構造分散データベース・システムを使用することである。詳細は後述するが、このアプローチは、典型的には、URIに関連づけられる番号に関して各PSTN操作員によって維持されるデータベースを必要とする。これらデータベースは、DNSの場合と同様に該当するデータベースに向けられる変換要求を用いてインターネットのようなネットワークを経由してすべてのPSTNによってアクセスできる。この場合、ブロック47は、インタフェース44を経由してインターネット上でUI変換を要求するように設計される適切な変換プログラムによって構成される。
URI決定ブロック47に関するDNSタイプ照合の実施形態を記述する前に、いくつかの一般的コメントを記述する。URI決定のためどのような方法が使用されるとしても、URIにおかれる制約が限定的であれば一定の単純化は可能である。特に、以下のケースにおいてはURIのすべてのコンポーネントを決定することは必要でない。
(i)URIパス・コンポーネントの一部がすべてのサービス資源に対する標準であり得る。この標準部分は、他のURIが決定されたならば、ブロック47によって容易に加えられる。例えば、徘徊番号を照合しなければならない場合、徘徊番号が、便宜上常に特定サーバー上の加入者のディレクトリのサブディレクトリ″tel″のファイル″roam(徘徊)″に保持されているかもしれない。この場合、URIホスト・コンポーネントおよびパス・コンポーネントの加入者固有部分が最初に決定され、次に、残りのパス部分″/tel/roam″が加えられる。
(ii)URIパス・コンポーネントが資源コードのあらかじめ定められた部分と同じものであるように構成できる。この場合、ブロック47はホスト・コンポーネントだけを決定し次にパスを加えるだけでよい。例えば、ホスト機械上でのユニークさを高い確率で保つためパスは常に対象電話番号または終端文字で終了しなけれならないことは理解されるであろう。パスはまたブロック147によって加えられるべき標準コンポーネントを含むかもしれない。
(iii)URIのホスト・コンポーネントを決定するため電話番号の部分だけを使用すればよいように、電話番号のブロックが同じホスト・サーバーに置かれる対応するサービス資源を持つ場合である。この場合、パス・コンポーネントは便宜的に各電話番号の全部または一部を含む。この状況は、電話操作員による厳格な制御を示唆し、電話ユーザはユーザの電話ページを置くホスト・サーバーを選択する自由を持たない。
URIがどのように決定されるとしても、URIのホスト・コンポーネントはホスト・ドメイン名かホストIPアドレスのいずれかの形式で提供されるという点は注意すべきである。ホストがドメイン名によって識別される場合、URIホスト名のIPアドレスへの更なる変換は、インターネットのドメイン名システムを使用してインタフェース44によって標準的方法で実行される。ホスト識別がIPアドレスとして直接提供されるとすれば、この更なる変換は回避できる。
URI変換に番号を提供するためデータベース照合が使用される場合、このデータベースは、その他の顧客関係情報を含む顧客データベースと独立していてもあるいは組み合わされていてもよい。この選択に影響を及ぼす要因として、一方には、番号URI変換情報を広く利用できるようにしたいという要求があり、他方には、他の顧客関係情報へのアクセスを制限したいという要求がある。
DNSタイプURI照合
資源コードのUI部分が電話番号であり、URIに関する制約がなく、従って、URIのホストおよびパス・コンポーネント全体が照合によって返されなければならない場合に関してURI決定ブロック47のDNSタイプ照合の実施形態の詳細を以下に記述する。プロセス全体の重要な部分は、対象電話番号からのホスト・ドメイン名同等情報の形成である。次に、このドメイン名同等情報は、本実施形態においてはDNSによって使用されるものに等しい照合メカニズムによって対応するURIに変換される(照合メカニズムは、独立して実施することも可能ではあるが、実際にはDNSに組み込まれることもある)。
DNSの特性は、図3を参照して「DNSタイプ」システムを記述した際に既に記述した。以下の記述の便宜上、電話番号をURI変換機能に提供するように構成されたDNSタイプ・システムを″DNS-type URI Server″systemの頭文字をとって「Duris」システムと呼称する。
Durisシステムの動作に関連する基本原則は以下の通りである。
-あらゆる電話番号はホスト・ドメイン名に変えることができること(対象電話番号に関するそのようなホスト・ドメイン名を含む名前空間を以下「telname空間」と呼称する)、および、
-ホスト・ドメイン空間におけるあらゆるホスト・ドメイン名に関して、Durisシステムによって保持され、対応するURIを含む登録レコード(以下Registration Recordの頭文字をとってRRと呼称する)が存在すること、
である。
このように、図11に示されるように、本実施形態において、先ず、資源コード54のUI部分を構成する入力電話番号がホスト・ドメイン名を形成するため渡され(ステップ120)、次に、対応するURIを用いてRRを取り出すため(ステップ121)Durisシステムに渡される(図11ではDNS自体によってDurisシステムに送られるように示されている)。URI照合に続いて、返されたURIがドメイン名としてホスト・コンポーネントを持っている場合、ホストIPアドレスを取り出すためDNSが使用される(ステップ122)。当然のことながら、ホスト・コンポーネントがIPアドレスとしてRRに記憶されていればこのステップは不要である。次にURIを使用して該当するサーバーに対する資源要求が作成され、それが資源コードのRRI部分に渡される(ステップ123)
Durisシステムにはいくつかの可能な実施形態がある。
(a)DNSと独立型。このオプションでは、図12Aに示されるように、telname空間が、telname空間ルート″.″を用いて管理されるべき全名前空間を構成する。この場合、DurisシステムはそのDNS自体とは独立している。当然のことながら、Durisシステムは、DNSと同じ基本下部構造(すなわちインターネット)あるいは完全に別のネットワークのいずれかを使用することができる。telname空間が世界中のすべての公共電話番号に対応するすべてのドメイン名を含む場合、完全な国際電話番号の解析によって、完全に有効なドメイン名が与えられる。もちろん、telname空間が、世界的に事業を行っている会社の範囲内の内線番号から導出されるような小規模の名前セットである場合もある。
(b)DNSの範囲内で細分化されてない型のtelname空間。このオプションでは、telname空間はDNS名前空間の1つのドメインでありDurisシステムはそのDNS自体によって提供される。このように、telname空間が世界中の公共電話番号から導出されるすべてのドメイン名を含む場合、telname空間は、図12Bに示されるように、特別サブドメイン″tel″においてITUというドメインの範囲内に配置され、telname空間のルートは″tel.itu.int.″である。ドメイン″tel.itu.int.″を管理する責任はITUが持つこととなる。この後者の例では、完全に有効なドメイン名を入力電話番号から作り上げるため、telname空間の範囲内の構造に対応するドメイン名の部分を形成するため解析された後、末尾″tel.itu.int.″が付加される。次に完全なドメイン名がDNSに適用され、所望のURIを保持する対応するRRレコードが取り出される。また、別の例として、telname空間がヒューレット・パッカード社内の内線番号から導出されたすべての名前であり、telname空間のルートが″tel.hp.com.″で、ヒューレット・パッカード社がこのドメインを管理する全責任を持つ場合を例としてあげることができる。
(c)DNSの範囲内で細分化された型のTelname空間。このオプションでは、telname空間はDNS名前空間の複数のドメインの間に分割されていて、DurisシステムはそのDNS自体によって提供される。telname空間は世界中の公共電話番号から導出されたすべてのドメイン名を含む場合、telname空間は、各国ドメインのそれぞれのサブドメイン″tel″の間で分割されることができる。このように、図12Cで示されるように、フランス(France)の電話番号に対応するtelname空間の部分は、″tel.fr.″というルートを持ち、英国(UK)の電話番号に対応するtelname空間の部分は、″tel.uk.″というルートを持つ。各々のサブドメイン″tel″を管理する責任は各国にある。この後者の例では、入力電話番号から完全に有効なドメイン名を作り上げるために、国コードに続く電話番号部分を解析して国の’tel’サブドメインの範囲内のドメイン名の部分が作成され、次に、対象国に関して適切なホスト・ドメイン名末尾が加えられる。例えばフランスの電話番号に関しては、解析の前に国コード″33″が番号から取り外され、末尾に″tel.fr.″が加えられる。各国に関する末尾は、ローカルの照合テーブルに記憶しておくことができる。更に別の例をあげれば、″xco.com.″および″yco.com.″というそれぞれのDNSドメインを持つ(X社およびY社という)2つの民間組織が、″tel.xco.com.″および″tel.yco.com.″に分割されたtelname空間を持つ共有Durisシステムを運営することに同意する場合である。この場合、x社から入力されたすべてのy社の電話番号は、最後が″tel.yco.com.″となる完全に有効なドメイン名に解析される。逆の場合もまた同様である。
次に、ドメイン名の電話番号への解析、換言すれば、ドメイン名の構造を作成するため文字″.″を番号のどこに挿入すべきか考察する。電話番号は上述の通り各国の番号割り当て方式に従って階層的に組み立てられていることは当然である。従って、1つのアプローチは、各国の番号割り当て方式の構造に準じて電話番号を分割してドメイン名を作り上げるものである。例えば、英国の″441447456987″という電話番号を取り上げれば、″44″は国コードで、″1447″は4桁の地域コードであり、″456987″は6桁のローカル番号である。この番号を分割して45698.1447.44というドメイン名を作り上げることができる(注:この場合ラベル順序の反転はDNSラベルが最後部に配列されるという事実に基づいている)。telname空間が図12Bに示されているような配置を持つDNSのサブドメインであるとすれば、電話番号から導出される完全に有効なドメイン名は、
456987.1447.44.tel.itu.iut.
となるであろう。
しかしながら、ホスト名に電話番号を変換する時番号割り当て方式の階層に合致させようと試みることに必然的に伴う困難性が存在する。第1に、国際番号を正しく解析するためには、この動作に関与するエンティティの各々が各国の番号割り当て方式の構造を知っている必要があり、例えば英国におけるように地域コードの長さが異なっている場合、必要とされる知識は照合テーブルの形式をとらねばならないかもしれない。これは、複雑なコンピュータ・タスクではないとはいえ、各国がその電話番号方式およびその修正についてすべての他国に通知しなければならないことを意味するので、管理上非常に面倒なな問題である。第2の問題は、6桁または7桁のローカル番号は非常に大きいドメインであるということである。性能上の観点からすればサブドメインを作成することが好ましいが、それを実行する明確な方法がない。
このような問題は、ドメイン名への電話番号の解析が国家電話番号割り当て方式の構造に合致しなければならないという制約を放棄することによって、克服することが可能である。実際、DNSサーバーが名前空間の意味について何も知らないのであるからそのような方式に従う強い理由はない。従って、各サブドメインのサイズを制限するため例えば1時点で4桁をとるという確定的アルゴリズムを使用して電話番号を解析し、番号方式の知識なしにピリオドを挿入することは可能である。DNSサーバーによって提供されるDNSドメインおよび地域が正しく作成されている限り、すべてうまくはたらく。
国際番号に関する限り、国コードを切り離すことはなお適切に見えるので、既知の国コードに従ってダイヤルされた番号の最初の部分を解析し、その後(例えば、3,7または4,6または3,3,4などの)決定性方式を使用して桁を分離するという複合解析方式が使用される。当然、図12Cに示されるような細分化されたtelname空間が使用されているとすれば、ホスト名末尾を照合するため国コードが使用される。解析されるのは番号の国部分だけである。
最後に、URIを持つRRレコードを保持するためDNSサーバーを設定する方法の詳細に関しては、O’Reilly & Associates,1992出版のPaul AlbitzおよびCriket Liu両氏著の″DNS and BIND″を参照することができる。この文献はUnix BINDを使用してDNSサーバーを設定する方法を記述している。RRレコードのタイプは例えばテキストである。
DNSラベルの先頭は理論的に数字から始めてはならない点に留意する必要がある。この規則が保持されるならば、電話番号を解析する時、各ラベルの最初の文字として標準の文字を挿入することはもちろん容易である。従って、″t″が標準先頭文字として使用される場合、2826という4桁ラベルは″t2826″となる。
ドメイン名の場合と同様に、(例えばローカル呼び出しが国際番号または地域コードのような先頭番号を必要としない場合のように)入力電話番号が完全な番号でない場合、それはローカル・ドメインにおけるドメイン名に変換される。
上記のDurisシステム実施形態は電話番号をURIに変換する観点からのものであった。この場合、電話番号は資源コードの完全なUIを作成し、Durisシステムが完全なURIを返す。UIの形式およびURIのどの部分が照合されなければならないかという点に関して上述のDurisシステム実施形態に種々の修正を加えることが可能なことは認められるであろう。例えば、各々がそれ自体のファイルにおいて加入者と関連した多数の異なるサービス資源が存在し、所望のソースが資源コードのpic部分によって識別される場合、入力電話番号は完全なURIではなくホスト・コンポーネントを照合するため使用され、パス・コンポーネントのその部分は関連したサブディレクトリに依存し、UIのpic部分が所望の資源ファイルを識別するため追加される。
小規模なローカルのDuris実施形態については、単一のサーバーを用意すればよいかもしれない。しかしながら、そのような実施形態も、その他の適切な機能が備わっていることを前提として、1つのDNSタイプとしてみなされなければならない。
サービス資源の特性
次に、サービス資源49がサーバー51上でどのように提供されるか詳細に考察する。説明の便宜上、(個人または組織、あるいは、呼び出し側または呼び出され側を問わず)特定のPSTNユーザに関連する1つまたは複数のサービス資源を1つまたは複数のWWWページにおけるユーザ端末53からインターネットを経由してサーバー51に配置することができるとする。
サービス資源が電話番号のようなサービス・データ項目であるような単純なケース(例えば呼び出し側によってダイヤルされた番号に対応するユーザの電話が使用中である場合代替番号すなわち転送番号が試行される)を考察する。この転送番号がユーザの電話ページの唯一のサービス資源である場合もある。電話ページURIはHTTPに設定された方式を持つURLであることがある。この場合GET方法を使用して転送番号を取り出すことができる。電話ページが転送番号の機能的取り出しのためにだけ使用されるものであればこのような構成は適当であろう。しかしながら、転送番号がユーザ端末53で視覚的に提示されなければならないなら、番号に説明的材料を加えることが望ましいかもしれない(転送番号が文脈情報を既に提供する既存の表示されたページに返されるように構成することができるのでこの点は必ずしも頻繁に必要となるわけではない)。しかしながら、電話ページが、転送番号だけでなく説明的材料を含む場合、電話ページの機能的利用だけを利用することを望むエンティティは、電話ページを取り出し次に転送番号を抽出するように構成することが可能である(これはもちろん情報を識別する標準的方法が電話ページから抽出されなければならいことを必要とする)。
説明的材料を必要とする資源の観察およびそれに対する機能的アクセスを行うための代替的好ましい構成は、資源設計へのオブジェクト指向アプローチを使用するものである。この場合、資源オブジェクトは、それに関連づけられる2つの異なるアクセス方式を持つ。1つは資源の純粋に機能的使用のためのアクセス方式であり、他方は説明的材料の観察を可能にするためのものである。適切なオブジェクト方法を使用して資源オブジェクトにアクセスすることはアクセスしているエンティティに委ねられる。
説明的材料を必要とする資源の観察およびそれに対する機能的アクセスを行うための更に別の構成は、それぞれの使用のため適切に構成され、それぞれがそれ自身の資源コードを持つ別々の資源を用意するものである(一般にそのような資源は同じ電話ページ上に置かれ、この場合各資源コードのUI部分は同じである)。
ユーザが人間である場合の使用のための電話検索は、PSTNによる使用のための検索ほど一般的に時間的に切迫していない。従って、人間の使用のためサービス資源のURLにおいて指定される方式はHTTPとすることができるが、PSTN使用のためには特別の「電話」方式(アクセス・プロトコル)を定義する方が利益がある。その方式によって、サーバー51が最適化されたアクセス・ルーチンを使用して所望の資源(現在の例では転送番号)にアクセスし最小限の可能な時間でアクセスしているエンティティに応答することができる。
データ項目以外のその他の可能なタイプのサービス資源は、(サーバーにおける)実行のためのサービス論理を含み、この実行の結果は資源にアクセスしているエンティティに返される。また上記サービス論理はアクセスしているエンティティにおける実行のためサーバーからそのエンティティへダウンロードすことが可能であり、情報を記録するための(または単にアクセスされたという事実を記録するための)記録資源がアクセスしているエンティティによってサーバーへ渡される。記録資源は実行可能なサービス論理の特定のケースであることは認められることであろう。
例をあげれば、実行可能サービス論理によって構成されたサービス資源が、時刻に基づく呼び出し機能を実施して、サービス論理の実行の結果、呼び出され側の時間を考慮した電話番号呼び出しを行うように構成することができる。ダウンロード可能なサービス論理によって構成されるサービス資源の1つの例は、IPによって提供される機能を使用して呼び出し側オプションである問い合わせを制御するサービス論理である。記録資源は特定の番号に対する呼び出し回数を記録するため使用することができる。
各資源がそれ自身の電話ページを持ち、資源が未装飾の機能という形式にすぎない場合、HTTP方式は、ダウンロード可能サービス論理および実行可能サービス論理の両者に対するGET方法および記録資源に関するPOST使用のアクセスのために使用することが可能である。説明的材料に各サービス資源を備えることが望まれる場合、データ項目に関して上述された解決策のいずれでも使用することができる。
複数のサービス資源が1つの番号と関連づけられるべき場合、そのような資源の各々は、それ自身のURIを持つそれぞれの電話ページ上に配置することができる。しかしながら、好ましいアプローチは、すべてのサービス資源を同じページ上に配置し、対応する資源コードのRRI部分を使用して該当する資源へのアクセスを可能にするものである。次にアクセスされた資源はその形式に従って取り扱われる(すなわち実行可能サービス論理の場合は実行されダウンロード可能サービス・データまたは論理の場合は返される)。
かくして、転送番号サービス・データ資源および時刻実行サービス論理資源が同じ電話ページに配置されるとすれば、転送番号資源コードが″1″というRRIを持ち、一方時刻資源コードが″2″というRRI値を持つかもしれない。
呼び出し側/呼び出され側オプションがそのような側への提示のためサービス資源に含められるべき場合、これは、後続のサービス資源に対する要求を始動する選択されたオプションを含むダウンロード可能なサービス論理としてサービス資源を構成することによって、実施することができる。
サービス資源は、サービス・データやダウンロード可能なサービス論理および実行可能サービス論理を組み合わせた複合タイプであることが多い。特に強力な組み合わせは、ダウンロード可能なサービス論理が実行可能サービス論理と相互作用するように設計された2つのタイプのサービス論理の組合せである。この構成を使用して、ユーザに複雑なクライアント/サーバー・タイプ・アプリケーションを提供することができる。
サービス資源の使用例
図13は、サーバー51上の資源を利用するサービスの動作を示している。このサービスは、「個人番号」サービスに等しいもので、あるユーザがたとえ番号が実際に異なる電話の間で移動(すなわち徘徊)する時でも単一の不変の番号を通してそのユーザにアクセスすることができるサービスである。これを達成するため、このサービスを必要とするユーザ(本例ではユーザB)に、SSPがダイヤルされた番号をWebtel(ウェブ電話)として識別できるように同じ先頭番号ストリングをすべての番号が持つ番号セットから(この例ではBのWebtel番号と呼ぶ)ユニークな個人番号が割り当てられる。ユーザBは、HTTPサーバー51上の専用の電話ページにサービス資源49を持つ。この場合、この電話ページは、本例では「URL(B電話ページ)」として識別されているURLに配置されている。Bの電話ページは、アクセスされると、Bに到達することができる現在時徘徊番号(すなわち″B-telNb″)を返す。最も簡単なケースでは、Bの電話ページが、Bが異なる電話へ移動するに伴って、(例えば端末53から)Bによって修正される単一の番号である場合である。Bの電話ページが時刻型呼び出し機能を提供する実行可能サービス論理であるように構成することもできる。
本例においては、BのWebtel番号とBの電話ページのURLの間の関連性は、SCP43がアクセス可能な関連テーブルに記憶されている。
ユーザAがBのWebtel番号をダイヤルすることによってユーザBへの連絡を行おうとする場合、Aによって使用されている電話40は、SSP41に対し呼び出し設定要求を送る(図13において、最も太めの実線60は電話ネットワークを通る搬送体経路を示し、次に太い実線は信号の流れを示している)。SSP41は、ダイヤルされた番号をWebtel番号として検出して、BのWebtel番号と共にサービス要求をSCP43へ送る。SCP43は、このサービス要求を受け取ると、BのWebtel番号をBに対する現在時点徘徊番号に変換する動作を制御するサービス論理プログラムを始動する。実際には、本例では、このプログラムは、単に、BのWebtel番号(すなわちBの電話ページ)によって識別されるサービス資源にアクセスするように資源アクセス・ブロック46に要求して、このアクセスの結果を返すにすぎない。すなわち、ブロック46は、先ず、BのWebtel番号をBの電話ページのURLへ変換し、このURLを用いてインターネットを経由して(例えばHTTP GET方法に対応する方法に関連して上述した「電話」方式を使用して)Bの電話ページへアクセスする。この結果、Bの現在時点徘徊番号B-telNbがブロック46に渡され、次にこの番号がSSP41に返され、B-telNbに対応する電話40への呼び出し設定が完了する。
図13は、呼び出され側サービスに関連した例であるが、当然のことながら、インターネットを経由するサービス資源へのアクセス原理は、呼び出され側および呼び出し側の両者ならびにその混合を含むすべてのタイプのサービスに適用することができる。このように、標準的な800番サービスは、800番のダイヤルによって実行可能サービス論理によって構成される電話ページ資源へのアクセスを行い、呼び出し経路を制御する最も適切な番号を返すように実施することができる。図13の例においてSSPからのサービス要求がダイヤルされた番号の先頭番号ストリングによって起動されたが、サービス要求を呼び出し側番号、呼び出され側番号またはその他のユーザ入力を含む種々のトリガーによって起動することが可能である点は認められるであろう。そのようなトリガーは呼び出し設定プロセスによって認定されるようにすることもできる(例えば呼び出され側番号が使用中状態によってまたは一定時間より長いベルによって認定されるようにすることができる)。
上述の記録サービス資源に関する1つの可能なアプリケーションは、電話投票である。この場合、投票番号にダイヤルすると、SSPが呼び出しを取り上げてSCP43へサービス要求を渡す。次に、SCP43がインターネッ上の該当する記録資源に連絡をとり、投票を登録して、その後呼び出しは完了する。ボトルネックを最小にするため、記録資源は各SCP毎に異なるURLで用意され、インターネットを経由してこれら記録資源のすべてから投票を収集し分類することが容易となる。インターネット・アクセスを持つSCPがあらゆるSSPで提供されるとすれば、混雑の危険は大幅に減らされる。
既に述べたように、ユーザの電話ページが複数のサービス資源を持つ場合があり、この場合、アクセスしているSCPからのアクセス要求は、所望の資源を識別する適切なRRIを含む必要がある。
SCPが一部のユーザへの伝統的INサービスとその他のユーザへのインターネット経由サービス資源を使用する同等のサービスの両者を提供すべき場合には、サービス要求が適切に取り扱われることを確実にするため、SCPに照合テーブルが用意されることを必要とするかもしれない。そのような照合テーブルは、便宜上顧客記録データベースと組み合わせることができるであろう。
ユーザBのようなユーザが所望のサービス資源(特に個人用のサービスを定義するサービス論理)を指定する1つまたは複数の電話ページを設定したとすれば。ユーザBがどのPSTN操作員に対してもそのようなサービス資源にアクセスしてそれを活用することを望むのは当然である。Webtel対URIデータベースがすべての操作員にとって利用できるならば、これは可能である。このように、複数の操作員がBの電話ページにアクセスするように設定することができる。操作員がBの電話ページを使用するのを断るならば、(少くともその操作員がユーザ選択に依存する長距離搬送体サービスを提供する場合には)、Bはその操作員を使用しないことを明確に選択することができる。従って、サービス提供が操作員の手数を抑えることを止める結果となるが、操作員による電話ページ利用はPSTN操作の必要な基本的機能になる可能性がある。
サービス資源の作成と更新
次に、サーバー51に対するサービス資源49がいかに作成されその後更新されるかを記述する。
作成に関する限り、2つの基本的アクションが必要である。すなわち、第1に、サービス資源がサーバー51上に配置されなければならず、第2に、資源へのアクセスを要求するトリガー条件(すなわち番号プラス呼び出しポイントのような条件)とともにサービス資源のURIがPSTN操作員へ通知されなければならない。複数の資源が同じURIにおいて提供されるならば、特定のトリガー条件のため適切な資源を取り出すために必要とされるRRI値も通知されなければならない。この通知プロセスは、PSTN操作員に対するサービス資源の「登録」と呼ばれる。当然のことながら、SCP43によって使用される関連テーブルが設定され、トリガー条件がSCP43において設定されることを可能にするため、登録が必要である。図13を参照して上述したような一定のサービスに関して、トリガー番号(図13の例ではWebtel番号)を供給するのはユーザではなく、PSTN操作員が登録プロセスの一部として適切な番号をユーザに割り当てるのである。
サーバー51上にサービス資源を配置するプロセスに関する限り、その実行方法は、そのようなサービス資源のPSTN動作に及ぼす可能な効果に対するPSTN操作員の態度に依存する。サービス資源がアクセスしているエンティティにデータ項目を単に返す場合、操作員は、サービス資源を実施する場合の可能なエラー(偶然であるが故意であろうが)についてあまり心配しないかもしれない。しかしながら、操作員は、資源によって返されるかもしれないいかなるサービス論理の適当な動作に関しては、おそらく、非常に懸念するであろう。実際、操作員はそのようなサービス資源を許容しない可能性がある。
操作員がサービス資源の実施形態または特性に関心をを持たないと当面仮定するとすれば、資源がサーバー51上に配置さる方法は主としてサーバーの特性に依存する。例えば、ユーザがインターネットへのネットワーク・アクセスのあるコンピュータを持ち、このコンピュータがサーバー51として使用されるとすれば、ユーザは外部アクセスのためのWWW電話ページとしてサーバー上に所望の資源を単にロードすることができる。サーバーが内部のLAN上でのアクセスを持つ組織サーバーである場合同様の状況が起きる。これら2つの場合、WWW電話ページとして資源をロードすること自体はインターネット・アクセスを必要としない。しかしながら、サーバー51が外部のインターネット・サービス・プロバイダによって実行されるとすれば、ユーザは、サーバー上でユーザに割り当てられたウェブサイト空間に所望のサービス資源をダウンロードするように取り計らうことができる。これは、インターネット・アクセスを含むことも含まないこともできる。この後者のシナリオの1つの特別なケースは、PSTN操作員がサービス資源を保持するユーザ電話ページに対して特別なサーバーを提供する場合である。
ユーザ自身のコンピュータがサーバー51の役をする場合を除いて、サーバー上にサービス資源を配置することは、一般的には、1つまたは複数のパスワード保護のレベルを消去することを伴う。
ユーザによってサーバー51にロードされるサービス資源の起源に関しては、それはユーザによって生成されるか、あるいは、特に資源がサービス論理を含む場合、(PSTN操作員を含む)第三者によって提供されるかもしれない。
PSTN操作員がPSTNの動作に対する悪影響を避けるためサービス資源49を支配することを望むとすれば、2つのアプローチが可能である。第1に、あらゆる資源(またはおそらく特定のサブセット)が使用の前に検証プロセスに従わなければならないことを操作員が要求することが可能であり、(特定のデータ項目を除いて)ユーザによる資源の将来の変更を回避する適切な基準が設けられる。これに関して、操作員は、(特定のデータ項目を除いて)資源が操作員の制御の下におかれること、そしてユーザはその資源に対する書き込みアクセス権を持たないことを求めることができる。第2に、更に魅力的であるが、サービス資源49による悪影響を最小にするアプローチは、ユーザがユーザ自身のデータを追加することができる(また資源がサービス論理を含む場合制約された機能選択を行う)標準的サービス資源を操作員が提供するものである。その後、特別仕様の資源が操作員によって制御されるサーバー51にロードされる。操作員に制御されたサーバーからユーザがWWW上でダウンロードすることができるHTML形式を使用する特定の資源に関してこのプロセスの実施は都合がよい。形式を完成しその形式の「コミット(提示)」ボタンを活動状態にさせると、入力された情報がサーバーへ送られ、そこで、その情報を使用して、特別仕様サービス資源が作成され、インターネット経由のアクセスに備えてそのサーバー上に配置される。このアプローチの利点は、操作員によるサービス資源の登録が同時に実施される点である。(サービス資源をサーバーにロードさせる動作と別個に登録が行われなければなら場合、HTML形式の使用は登録プロセスを実施する非常に便利な方法であるという点に留意する必要がある)。
上記の点から明らかなように、作成プロセスは情報がインターネット上で渡されることを必ずしも必要としないが、多くの場合、特に、WWW上で交換されるHTML形式が特別仕様のサービス資源を作成するために使用されることができる場合には、それは最良の解決策である。HTML形式を使用して特別仕様のサービス資源を作成することはPSTN操作員がサーバーを制御する場合に限られない点に留意する必要がある。
サービス資源の更新に関しては、特定のデータ項目(例えば徘徊番号)を頻繁に更新する必要がある場合がある。PSTN操作員がサービス資源49に対する制御を持たない場合、更新は比較的簡単な問題であり、単に対象サーバーへの書き込みアクセスを必要とするにすぎない(上述の通り、これは一般に1つまたは複数レベルのパスワード保護を伴う)。しかしながら、PSTN操作員がサービス資源に対する制御を持っている場合、例えば、操作員によって制御されているサーバー上への特別仕様サービス資源がロードされるなら標準サービス資源の特別仕様化を許容するような場合、サービス資源への書き込みアクセスは厳格に制御されるであろう。この場合もまた、HTML形式はデータ項目を修正する便利な媒体として使用されることができる。操作員にとって、これは可能な修正を制限する利益を持ち、一方、ユーザにとっては、形式インタフェースが資源修正への単純な道を提供している。
一層複雑な更新に関しては、初期作成のために必要とされたものと同等なプロセスを通る必要があろう。特にサービス資源がPSTN操作員によって制御されたサーバー51上に保持されている場合、資源更新は、一般的には、インターネット経由の通信を伴う。
ウェブ・ユーザ交信
次に、サーバー51上の電話ページに保持されたサービス資源のその他の可能な用途を記述する。例えばユーザBの電話ページが転送番号を含むとすれば、この電話ページがインターネット経由でユーザAの端末53から読み取りアクセス可能であると仮定すると、ユーザAは、端末53上で動くグラフィカルなウェブ・ブラウザを使用して、Bの電話ページを見てBの転送番号を見つけることができる。前述のように、転送番号は番号の意味を視覚的に表示するためユーザAに渡されたり、説明テキストを含めてユーザAに渡されることがある。
更に一層役立つ例は、ユーザBに関する現在時転送番号サービスである。Bに到達できる現在時徘徊番号を返すためアクセスされる時サーバー上のBの電話ページ(図14参照)が動作可能状態にあると仮定する。更に、ユーザBがHTMLで書かれたいくつかのウェブ・ページのあるウェブサイトを持ち、各ページが、起動されるとBの電話ページへそのURLによってアクセスするためにGET方法を使用する「電話」ボタンを含むと仮定する。そこで、ユーザAが、ユーザAの端末53からWWW経由でBのウェブサイトをブラウズしながら(矢印66)、Bと会話するためBに電話することを決めると、ユーザが現在見ているページ上の電話ボタン65を活動状態にさせるだけで、HTTP要求″GET URL(Bの電話ページ)″を使用してBの電話ページがアクセスされる。
呼び出されるべきBの現在の電話番号が、決定され、ユーザAの端末に送られ(矢印68)そこに表示される。一般的には、番号に関する説明テキストも表示される。例えば「次の番号で私を呼び出してください」というテキストが表示される。このテキストは、電話ボタンに関連付けされたHTMLスクリプトによって提供されることも、現在時番号を返す時電話ページによって提供されることもできる。実際、更に役立つことであるが、Bに到達する現在時番号のみならず、Bに到達できるすべての番号をそれぞれの番号にBがいる確率の高い時間と共にユーザAに提供することもできる。このような追加情報は頻繁な変更を伴うことがありがちなので、情報を提供する唯一の賢明な方法は電話ページから行うものである。このように、Bの電話ページは、Bに到達する現在時点番号のみならず、複数番号と変更のできる時間を含むテキストを提供する。当然のことながら、データの変更は1カ所でのみ実行されなければならないことを確認するようにBの電話ページのスクリプトは作成される。
更に別の例は、Bの電話ページが、ユーザA端末での実行のためにダウンロードすることが可能なサービス論理を含む場合である。この例は、更に電話ページを取り出す後続動作を生成するためのような選択がユーザに提示される場合に役立つ。例えば、最初にアクセスされた電話ページが、家族のための一般的電話番号を与えるだけではなく、家族のメンバ各々の時刻別番号のような電話情報の選択をもユーザに提供する家族電話ページとすることができる。この場合、各家族メンバは、家族ページに続くそれぞれの電話ページを持つ。
上記のシナリオでは、ユーザAはPSTN経由で呼び出すべき番号を与えられた。それにより、ユーザAは自分の標準電話を取り上げ、与えられた番号にダイヤルすることができる。実際には、ユーザAが通常の非ISDNのPSTN回線上のSLIP/PPP接続経由のインターネット・アクセスだけを持つ場合複雑な問題が起きる。なぜならば、この場合、ゲートウェイ90がAの電話への呼び出しを設定しようとする時Aの電話回線はインターネット・アクセスを作成するこことに既に使用されているからである。ISDNを使用していれば、2つの経路が使用可能であり、この問題は発生しない。この問題を克服する1つの方法は、呼び出すべき番号をBの電話ページから取得した後、(アクセスされている現在時WWWのURLのような)必要とされている状態情報を記憶してユーザA端末53のインターネット・セッションを中止させ、そのSLIP/PPP接続を切断して、それによって電話回線を解放することである。その後、AはBに電話することができる。通話の終了とともに、Aは、記録した状態情報を使用してインターネット・セッションを再開して、Bを呼び出すためにAが離れたポイントへ戻ることができる。代替的アプローチは、Aに対する電話線上で適当な多重送信変調方式を動作させ、音声とデータを同時に搬送させるものである。そのような方式はすでに多数存在する。PSTNは次にAから到来する結合されたデータ/音声ストリームをどこかで分離し、それぞれを適切な宛先へ送信する必要がある(インターネット・データはユーザAのためSLIP/PPP接続を提供しているISPに送られ、音声ストリームはBへ転送される)。当然のことながら、逆方向のデータおよび音声はどこかで組み合わされ最終的にAの端末へ送信される必要がある。
Aが標準電話を使用して手動でBへダイヤルするのではなく、ユーザAが端末からPSTNを経由して呼び出しを行うことを可能にする機能性をユーザA端末に備えることも可能である。この機能性は、一般的には、ウェブ・ブラウザ73のようなアプリケーション・ソフトウェアからの入力に応答してインタフェース70を駆動する電話線および電話ドライバ・ソフトウェア71に対するハードウェア・インタフェース70(図14参照)を含む。Aはその電話ソフトウェアを立ち上げ所望の番号を入力するか、あるいは、好ましくは、画面上でBの電話ページから返された番号をAが選択するだけで、それがAの電話ソフトウェアに渡される。実際には、ユーザBがAの端末上のダイアル機能性を提供するソフトウェア71に対するソフトウェア・インタフェースを知っていると仮定すれば、Aが電話したいと望み次第Bの番号を自動的にダイヤルするためBの電話ページがAの端末プログラム・コードへBの番号を返すことも可能である。音声通話を行うことに代わるものとして、Aの端末が適切なモデムおよび制御ソフトウェアを備えているとすれば、Aは、PSTNを経由して、Bの通常の番号またはそのような通信のために使用されるべきものとしてBの電話ページに指定された番号のいずれかへファックスまたはデータを送ることができる。当然のことながら、Aの電話回線がISDNでなくSLIP/PPP接続を経由したインターネット・アクセスである場合、上述したように、PSTN経由でのAの端末からの呼び出しは電話線使用の競合という問題を起こす可能性がある。
Aによってダイヤルされた番号に対応するBの電話が使用中であればこのような問題の可能性は多い。従って、Bが転送番号を指定する電話ページを持ち、BがPSTNに関してこのサービス資源を登録していれば、転送番号がPSTNによって自動的に試行される。しかし、転送番号資源がPSTNに登録されていなければ、使用中信号がAに戻される。Aが標準電話を通して呼び出しを行う場合、Aは通話方法を決定し、Aはあきらめるか、または、Bの電話ページを再度参照して転送番号を照合してその番号を使用して再ダイヤルするか、いずれかを選択する。Aがその端末53を使用してオリジナルの呼び出しを行うとすれば、使用中信号の戻りを検出してBの転送番号を自動的に検索しその番号に再ダイヤルするようにAの端末をプログラムすることができる。この機能性は、Bの電話ページからダウンロードされAの端末上で動くサービス論理に含めることができる。
Aが音声の使用のため電話線を解放するためそのインターネット・セッションを終了しなければならないとすれば、Bの電話ページの再度の参照は、新しいインターネット・セッションの開始を必要とする(実際には、Bに対してダイヤルされるべきオリジナルの番号が提供される時点にBの転送番号が渡されていれば、このような不便さは回避される)。
Bの電話ページが使用中である場合Bの電話ページ上でアクセスされるサービス資源は、当然、転送番号よりも一層複雑なものとすることができる。特に、例えばBのファックスまたは音声メールボックス番号を含むある範囲のオプションをユーザAに提示し、オプションの選択によって適切なアクセス・ソフトウェアが始動するという形態が可能である。別のオプションは、AがBの電話ページからダウンロードした形式を使用してコールバック・メッセージをBに残すというものである。記入された形式がサーバー51へ渡され、Bが適時に検査できるように記録される。
当然のことながら、AがBの現在時点徘徊番号を見出すためBの電話ページにアクセスすることを望んでも、ユーザAがBのウェブサイトのURIを知らずただBのWebtel番号だけを持っているということが起きる可能性がある。AはただPSTNを通してBを呼ぶことができる。その場合、BのWebtel番号の徘徊番号への変換は自動的に実行される(Bがこのサービスを登録していると仮定する)。しかしながら、Aは、Bを直ちに呼び出さず、その現在時徘徊番号を書き留めることを望むかもしれない。Aの問題を解決するため、好ましくは、前述のWebtel対URI関連テーブルを(例えば既知のウェブサイトのような)既知のアドレスでインターネット上でアクセスできるようにする。そこで、Aは、このウェブサイトにアクセスしてBのWebtel番号を渡すだけでよい。Bの電話ページURIがAに返されるので、Aはそれを使用してBの電話ページにアクセスすることができる。当然、Aが関連テーブルのウェブサイトへBのWebtel番号を送る時点からこのプロセスが自動的に実行されるように構成できる。
インターネット/PSTN呼び出しインタフェース
図14のシナリオにおいて、Aの電話の実際の形式がAのコンピュータ端末53に組み込まれたもので標準的電話形式とは相違していたにもかかわらず、PSTNへのAのアクセスは標準電話インタフェースを通してのものであった。図15は、図14の場合のようにBの徘徊番号が与えられた後、Aがインターネット上で始まる経路を経由してBを呼び出し、ユーザ・ネットワーク・インタフェースを介してPSTNに接続する状態を示している。インタフェース80は、PSTN上のISDNタイプ電話信号とIPパケットの形態でインターネット上を搬送される対応する信号の間の変換を行い、更に、電話中継線60上への音声データの転送およびその逆方向の転送を行うように構成されている。
従って、AがBへの呼び出しを始動すると、Aの端末におけるインターネット電話ソフトウェア81が、インターネットを経由してインタフェース80に始動信号を送信する。この場合、その送信先のアドレスはAの端末には既知のものである。インタフェース80において、信号はISDNタイプ信号に変換され、SSP41に渡される。次に、呼び出し設定が通常の方法で進められ、戻り信号がインターネットを経由してA端末におけるソフトウェア81へインタフェース80を通して送り返される。このソフトウェアは、WWWブラウザ73にAに対する表示のため呼び出し設定進捗情報を送る。呼び出しが確立されると、Aは電話を通してBと対話することができる。Aの音声入力は、まず電話ハードウェア・インタフェース83においてデジタル化され、次にソフトウェア81によってIPパケットに挿入されインターネットを通ってインタフェース80に送られる(矢印84)。Bからの音声トラフィックは逆の経路を進む。
SSP41からのサービス要求に応答して、SCPによるINサービスがこの呼び出しに対して提供される。従って、Bの電話が使用中でBが呼び出し転送に関して登録されていれば、SCP43は、サービス要求を受け取ると、呼び出し転送のためBの適切な電話ページにアクセスして転送番号を取り出す。Bの電話が使用中である時SSP41がサービス要求を始動しないように設定されていれば、使用中標識がAの端末に返され、そこで図14を参照して上述した形態でそれは処理される。
実際に、インターフェース80は、条件をトリガーし、それら条件が満たされ次第SCP43に対するサービス要求を生成するため、SSPの場合と同様な機能性を備える。
第三者呼び出し設定ゲートウェイ
図16は、Bの現在時徘徊番号を受け取った後AがBを呼び出す構成を示す。この場合、インターネット50およびSSP41の両者とインタフェースする第三者呼び出し設定ゲートウェイ90が提供される。便宜的に、ゲートウェイ90はSCP43と併設されている(必ずしもその必要はないが)。ゲートウェイ90は、指定された電話の間の呼び出しを設定するようにSSP41に要求する機能を持つ。
従って、AがBへの呼び出しを求めると、第三者呼び出し設定要求がAの端末からインターネットを経由してゲートウェイ90に送られる(矢印91)。この設定要求は、Aの電話番号およびBの現在時徘徊番号を含む。ゲートウェイ90は、先ず、Aの電話への呼び出しを設定することを試み(これは一般的には成功するにちがいない)、その後識別されたBの電話に対する呼び出しを設定する。一旦呼び出しが設定されれば、AおよびBは標準的方法でPSTNを経由して通信する。
Bの電話が使用中であれば、上述したシナリオのいずれかが起きる。
ゲートウェイ90は、また、あらかじめ定められたトリガー条件が満たされ次第SCP43に対するサービス要求を行うように構成することができる。このように、ゲートウェイ90はBの電話の使用中条件を検出し、転送番号に関するSCP43へのサービス要求を始動するように設定することができる。しかしながら、ゲートウェイ90を経由してAの端末へ使用中信号を送り戻す構成の方が、対応策をとる柔軟性をAに与えることができるので、望ましい。
図14に関して上述したように、ユーザAが通常の非ISDNのPSTN回線上のSLIP/PPP接続経由のインターネット・アクセスだけを持つ場合複雑な問題が起きる。なぜならば、この場合、ゲートウェイ90がAの電話への呼び出しを設定しようとする時Aの電話回線はインターネット・アクセスを行うため既に使用されているからである。図14に関連して上述した解決策、すなわち、インターネット・セッションを中断し、音声とインターネット・データを同一の電話回線上で多重化するという方法をここでも使用することができる。ユーザAの端末がインターネット上で送信されるデジタル化された音声として音声を取り扱うことができるとすれば、図14および図15の両方のシナリオに対する代替策が可能である。この場合、音声通話は図15形式のインタフェース80を経由して伝送され、Bの電話ページやゲートウェイ90との音声トラフィックおよびインターネット通信は、両方とも、A端末との間でSLIP/PPP接続を介して伝送されるインターネット・パケットの形態で搬送されるが、端末53上で動く別々のアプリケーションに渡される論理的に独立した流れとして搬送される。
Aの端末からゲートウェイ90に対して出される第三者呼び出し設定要求は、Bの電話ページに保持されサーバー51によって実行されるサービス論理によって同様に作成されることができる点は留意されるべきである(もちろん、そのような構成は、Aの電話番号がBの電話ページ・サービス論理に渡されることを必要とし、ユーザAの端末に提示される形式へ入力された番号が自動的にサーバー51へ送られる構成によって実施されることができる)。
更に、注意すべきは、図15のインタフェース80および図16のゲートウェイ90は、SSP41以外のエンティティによってサービス制御サブシステムに渡されるサービス要求の1つの例を与えている。
WWWに基づく「無料電話」800番サービス
WWWおよびPSTNの組合せを使用して、「着信無料電話」すなわち「800番」タイプのサービスを実施することが可能である。図17を参照して行われる以下の記述から明らかとなるように、WWW/PSTN実施形態は、必ずしも、呼び出し側から呼び出され側への通話料金の転送または特別の「800」番の使用のいずれにも依存しない。これら2つは標準的「無料電話」方式である。しかしながら、WWW/PSTN実施形態は、問い合わせ側および被問い合わせ側の通話を被問い合わせ側の負担で行うことができるようにする一層一般的特性を持つ。
図17の構成において、大規模なデパートのようなユーザDがサーバー51上にウェブサイトを持つ。単純化のため、サーバーは、回線125を経由してサーバーへの直接のコンピュータ・アクセスを持つユーザDの制御の下にあると仮定する。例えば、Dのウェブサイトは、Dによって売り出されている商品を掲載する多くのカタログのウェブ・ページを含む。加えて、Dは無料電話に基づいて行われる問い合わせを取り扱うため着信無料電話ページ124を設ける。このページのURLは、ウェブサイト・カタログ・ページの各々に配置される「着信無料電話」グラフィック・ボタン122に関連づけられる。
端末53のユーザAがDのウェブサイトをブラウズしてカタログ・ページを見る(矢印121)と仮定する。Aは興味のある品目を見て、この品目に関してDに問い合わせしたいと望むと、Aは端末53においてカタログ・ページに関連づけられている着信無料電話ボタン122を活動状態にさせる。ボタンが押されると、Aの端末に現在ロードされているカタログ・ページに埋め込まれたコードがAにAの電話番号およびオプションではあるが名前を入力するように促し、その後、入力されたデータを含むHTTP要求がPOST方法を使用してDの無料電話ページへ送られる(矢印123)。この要求を受け取ると、Dの無料電話ページは、サービス論理を実行して、問い合わせ制御システム126において維持されている問い合わせ待ち行列127に(Aの名前および電話番号を含む)新しい問い合わせを入力する。この例では、問い合わせ制御システムは、インターネットからは外部にある回線125を経由してサーバー51に接続しているが、サーバー51をインターネットを経由して問い合わせ制御システムと通信させるようにすることも可能である。DのウェブサイトがDによって制御されたサーバー上ではなくむしろISPサーバー上にある場合にはこの構成は最も実際的であろう。実際に、無料電話ボタン122が押されると、Aの端末において動いているコードが、サーバー51を経由するのではなく、インターネットを経由して問い合わせ制御システムに問い合わせ要求を直接送信するように構成することができる。
問い合わせ制御システム126は、問い合わせを到着順に確実に処理するように、渡された問い合わせを管理する。システム126は、新しい問い合わせを受領すると、その問い合わせを処理するまでのおよその待ち時間を好ましくは推定する。この推定は、待ち行列に現在ある問い合わせ件数と平均処理時間に基づいて行われる。待ち時間の推定は、POST要求メッセージへの応答としてサーバー51を通してユーザAへ送り戻される。
問い合わせ制御システム126は、電話40およびディスプレイ129を備えている多数の担当者への問い合わせの分配を監視する。Aの問い合わせは待ち行列127の先頭に達すると直ちに取り扱われ、問い合わせを取り扱うことができる担当者が検出される(例えば担当者の電話が受話器に置かれた時点を検出するようにシステムを構成できる)。そのような条件が満たされると、分配および設定制御装置128が、Aの問い合わせを取り上げ、作業可能な担当者D’のディスプレイ129にAの名前および電話番号を表示する。ユーザDがDの過去の顧客または信用格づけデータに関するデータベースを保持していれば、装置128はAに関するそのような既存の情報を表示する。同時に、装置128は、ゲートウェイ90に対して第三者呼び出し設定要求をインターネットを経由して送信して(矢印130)、担当者D’の電話とユーザAの電話の間の呼び出し設定を行うように求める。D’およびAの両者が呼び出しを取り上げれば、問い合わせが進行し、PSTN上の呼び出しを始動したのがDであるので通話料金はDによって支払われる。もしも、何かの理由で(例えばAが応答しなかったため)あらかじめ定められたタイムアウト期間通話ができなければ、装置128が待ち行列127の先頭にある次の問い合わせの処理に自動的に進むように構成することができる。
もちろん、装置128のゲートウェイ90への呼び出し設定要求を行わずに済ませることも、担当者D’が手動でAの番号をダイヤルしたり、あるいは装置126がD’の電話に代わって自動ダイヤルを始動したりする(例えば図14におけるAの場合と同様にコンピュータ組み込み電話を担当者D’が持つ)ことは、可能である。このようなアプローチの利点は、WWW型着信無料電話サービスを実施する際、改作またはいかなるサービスの導入も行わずに、既存のPSTNを使用することができることである。
図11および図13に関連して記述したように、ユーザAが通常の非ISDNのPSTN回線上のSLIP/PPP接続経由のインターネット・アクセスだけを持つ場合ユーザーAに対する呼び出しには複雑な問題が起きる。なぜならば、この場合、ユーザDがAの電話への呼び出しを設定しようとする時Aの電話回線はインターネット・アクセスを行うため既に使用されているからである。図11および図13に関連して上述した解決策、すなわち、インターネット・セッションを中断し、音声とインターネット・データを同一の電話回線上で多重化するという方法をここでも使用することができる。インターネット・セッションの中止に基づく解決策に関する限り、そのような中止は、Aの問い合わせが処理されるまで遅延されるようにすることは可能であるが、これを行うには、制御システム126からのフィードバックをインターネットを経由してAの端末53に提供し、このフィードバックをインターネット・セッションを中止されるコードに関連づける必要がある。これを達成する1つの方法は、Aから出されたオリジナルのPOST要求メッセージに対する応答として送られる応答メッセージに相関コードを含ませることである。システム126からAに送られるいかなる後続のフィードバックもこのコードを含み(サーバーAはまたこのコードを制御システム126へ渡す)、これによって、Aの端末はこのフィードバックを正しく識別することが可能となる。実際、同じメカニズムを使用して、コールバックを受け取るまでどのくらい待たなければならないかを適時に更新してユーザAに知らせることができる。このメカニズムは、Aの電話回線の競合問題とは関係なく使用可能である。
ユーザAが電話40だけを持ち端末53を持たない場合でも、なお図17の基本的構造を使用して、通話料金振り替えという複雑さを伴うことなく、ユーザAに無料電話サービスを提供することは可能である。具体的に述べれば、AがユーザDの着信無料電話サービス(典型的には800番サービス)に関する特別の番号にダイヤルすると、SSP41が標準的方法でこの特別番号を認識し、この特別番号とユーザAの番号を含むサービス要求をSCP43に送る。次に、SCP43が番号対URL変換を実行することによってDの無料電話ページのURLを確認し、要求123の場合と同様なPOST方法HTTP要求を使用してDの着信無料電話ページにアクセスする。一旦この要求がDの着信無料電話ページ124ページによって問い合わせとして登録されれば、無料電話ページはSCP43に要求を送信し、「あなたの着信無料電話問い合わせは登録されました。受話器をおいてください。すぐに電話がつながります。」というような通知を出すように要求する。この通知は、IPによって標準的方法で実行することができる。そこで、Aは電話を切ってDからの呼び出しを受け取る準備をする。
WWWを使用する上記の着信無料電話方式の顕著な利点は、問い合わせが待ち行列に記憶され処理を待つ間ユーザDはPSTNの使用に対する料金を加算しないですむという点にある。
バリエーション
上記の諸構成には当然のことながら多くのバリエーションが可能である。以下にそのいくつかを記述する。
分散処理環境。図18に示されているように、SCP43は、少くとも論理的にインターネットとは独立した分散処理環境すなわちDPE98を経由してHTTPサーバー51にアクセスすることもできる。好ましくは、この場合、サーバー51はPSTN操作員によって制御され、従って数の点で限定される。
DNSタイプ・サーバー上のサービス資源。前述の例においては、サービス資源項目がインターネットに接続したサーバー51上に配置され、所望のサービス資源が、所望のサービス資源項目を識別する資源コードから導出されるURIの使用を通して、PSTNのサービス制御サブシステムやインターネット・ユーザによってインターネットを経由してアクセスされた。電話番号の形式で資源コードからURIを導出する好ましい構成において、対象の電話番号の全部または一部がドメイン名形式に解析され、次に、DNS自体に組み込まれ得るDNSタイプ分散データベース・システムを使用してURIに変換された(図11、図12および関連記述を参照)。実際、サービス資源項目をDNSタイプ分散データベース・システムによって保持される登録記録に直接配置することは可能であり、そうすることによって、解析された電話番号を所望の資源にアクセスするため使用されるURIに変換する代わりに、解析された電話番号が所望のサービス資源項目に直接変換される。このプロセスに使用されるメカニズムは、上述したような、解析された電話番号をURIに変換するメカニズムと全く同じものである。このために使用されるDNSタイプ分散データベース・システムは、サービスのためにだけでなくサービス資源項目にインターネット・ユーザと共にPSTNのサービス制御サブシステムのためサービス資源項目へのアクセスを提供できるように、好ましくはインターネットまたはDNS自体の上でアクセスできるものである(図18を参照して記述した場合と同様の方法で、サービス資源項目を持つDNSタイプ・サーバーは、インターネット以外のネットワークによってサービス制御サブシステムにアクセスすることは可能である)。DNSタイプ・サーバー上に保持されるRRへのサービス資源項目の配置は、サービス資源項目のすべてのタイプにとって適切ではないかもしれないが、頻繁に変わることはない電話番号のような項目には適当であるかもしれない。かくして、適切な使用によって番号可搬性が提供される。この場合、ダイヤルされた個人番号がDNSタイプ・システムにおける照合を起動し、個人の番号の全部または一部が先ず解析され、次に、DNSタイプ・システムに適用され、呼び出しのための現在時番号が返される。すべてのダイヤルされた番号は、個人番号または単にそのような番号のサブセットとみなされることができる。この場合のサブセットは、例えばSSPにおける照合またはあらかじめ定められた先頭桁ストリングの存在によって個人番号として容易に識別できる複数の番号を含む。DNSタイプ分散データベース・システムにおけるドメイン名を作り上げるため電話番号の全体また一部をを解析するという一般的概念は、URIおよびサービス資源項目に加えてその他の情報項目の検索のためにも使用することができる。
フィードバック・メカニズム。図17のWWWに基づく着信無料電話構成を記述する際に、コールバックを受け取るまでの推定待ち時間に関するフィードバックをユーザAに供給することができることを記述した。これは、インターネットを使用して潜在的または実際の電話ユーザにフィードバック経路を与えることのできる1つの例である。また、呼び出し設定の進捗状況が呼び出し設定ゲートウェイによってユーザA端末へ通知されるという別の例が図16に関連して与えられた。事実、一般的には、ユーザがインターネット上で活発に端末を使用していることが知られている場合、呼び出し設定の進展を電話システムを通してユーザにフィードバックする機会が発生する。これを行うためには、当然のことながら、フィードバックが端末A上で動く適切なアプリケーションに渡されることができることを確認する必要があり、これは一般にはアプリケーションが適切なリンク情報を利用可能にすることを要求する。例えば呼び出し待機の間に、呼び出し設定進捗情報の他の情報もまたフィードバックすることができる。例えば、呼び出し待機の間ユーザAに表示するマルチメディア・クリップやビデオを保持する特別なサーバーをインターネット上に提供することもできる。
上記の諸構成において、サーバー51は主として呼び出し設定制御に関係したサービス資源項目を備えていた。別の異なるアプリケーションにおいて、ユーザ始動の電話要求に応答して電話システムからアクセスされ電話ユーザに返されるデータを保持するようにインターネット・サーバーを構成することは可能である点は留意されるべきである。そのようなサービスは、例えば、特定の電話番号の入力に応じてサービス要求を起動するSSPに対応するように提供される。この場合、サービス要求は、SCPを介して、知能型周辺機器を特定のインターネット・サーバー(必ずしもHTTPサーバーではない)にアクセスさせ呼び出し元へ戻すための所望のデータを取り出すように求める。知能型周辺機器には、ユーザにデータを音声で回答するためのテキスト対音声変換器が含まれる。
更に、サービス資源項目自体に関連するフィードバック・プロセスを記述することは有益であろう。例として、電話ユーザGが、Gの電話への呼び出しを最低X分だけ差し止めることができるサービスの利用に加入しているとする(Xはユーザによって設定可能である)。このサービスを実現するため、サーバー51上に使用中状態標示を含む電話ページをGは持つ。Gへの呼び出しが成功すると、GのローカルSSPは、インターネット経由で関連SCPによるメッセージをGの電話ページへ送信する。このメッセージによってGの電話が使用中であることを示すG使用中標示が設定される。メッセージは,また、期間Xの後時間切れとなり、使用時間標示をリセットさせる働きをするタイマーを始動させる。Gへの呼び出しはGの回線が実際に使用中であるのでGのSSPにおいて拒絶されるか、SCPを介してGの電話ページ使用中標示が設定されているか否かを照会するようにSSPに求める。もしも使用中状態標示が設定されていれば(成功のうちの呼び出し終了の後X期間設定されている)、呼び出しの試みは拒絶され、一方、使用中状態標識がリセット状態にあれば呼び出し試行は進められる。Gの電話ページ上に使用中状態標示メカニズムを配置することによって、GがXの値を簡単に変更することができるように構成することが可能である。
更に一般的バリエーション。上述の諸例においてPSTNのサービス制御サブシステムはSCPとして実施されているが、サービス制御サブシステムの機能性をSSPの一部としてまたは関連補助機構に備えることも可能である。更に、サービス要求の始動すなわちトリガーを、SSP以外の機器、例えばSS7信号リンクに挿入されるインタセプト・ボックスによって、実施することも可能である。
「インターネット」という用語は、インターネットおよび現在のアドレス指定方式のために使用されているTCP/IPプロトコルの現在時点の仕様のみならず、等時性媒体を取り扱う扱うために必要とされるような発展機能をも含むものと理解されるべきである。更に、WWWおよびHTTPプロトコルの参照も、同様に、それらの将来発展したものをも含むものと理解されるべきである。
本発明は、PSTN以外の電話システム、例えば、PLMNやその他の移動体ネットワーク、およびPABXを使用するプライベート・システムにも適用することができる。プライベート・システムの場合、PABXと同じ内部ユーザに機能を一般的に提供するLANまたは構内型コンピュータ・ネットワークが上述の実施形態におけるインターネットの役割を果たすであろう。
更に、(例えば広帯域ATMシステムのような)交換型遠隔通信システムがサービス制御を必要とし、その遠隔通信システムのサービス制御サブシステムへのサービス資源伝達のためコンピュータ・ネットワークが使用される場合にも本発明は適用できる。
Claims (8)
- 目標とするエンティティ(B)と電話システム上で通信するための電話番号を取得する方法であって、該エンティティ(B)は番号ストリングによって識別され、
(a)ドメイン名システム(DNS)型の分散データベース・システムに、前記エンティティ(B)の電話番号をもつレコードをドメイン名に関連付けて保存するステップを含み、該ドメイン名は、前記番号ストリングの少なくとも一部分を解析することにより該ドメイン名の少なくとも一部分が得られるようになっており、
(b)呼び出し側の機器から前記番号ストリングが前記電話システム上に出されることに応答して、該番号ストリングの少なくとも一部分を解析してドメイン名を形成するステップと、
(c)前記ステップ(b)において形成されたドメイン名により前記DNS型の分散データベース・システムを検索し、見つけたレコードから電話番号を取り出すステップと、
を含む電話番号を取得する方法。 - 前記DNS型の分散データベース・システムがインターネットのドメイン名システムである、請求項1に記載の方法。
- 前記番号ストリングのそれぞれが電話番号である、請求項1または請求項2に記載の方法。
- 電話網(PSTN)を経由して目標エンティティにアクセスする方法であって、
前記目標エンティティに関する電話番号が請求項1乃至請求項3のいずれかに記載の方法に従って決定され、決定された電話番号が前記電話網(PSTN)を経由して前記目標エンティティを呼び出すために使用される、方法。 - 目標とするエンティティ(B)と電話システム上で通信するための電話番号を取得するシステムであって、該エンティティ(B)は番号ストリングによって識別され、
(a)前記エンティティ(B)の電話番号をもつレコードをドメイン名に関連付けて保存するドメイン名システム(DNS)型の分散データベース・システムを含み、該ドメイン名は、前記番号ストリングの少なくとも一部分を解析することにより該ドメイン名の少なくとも一部分が得られるようになっており、
(b)呼び出し側の機器から前記番号ストリングが前記電話システム上に出されることに応答して、該番号ストリングの少なくとも一部分を解析してドメイン名を形成する第1の手段と、
(c)前記ステップ(b)において形成されたドメイン名により前記DNS型の分散データベース・システムを検索し、見つけたレコードから電話番号を取り出す第2の手段と、
を有するシステム。 - 前記DNS型分散データベースがインターネットのドメイン名システムである、請求項5に記載のシステム。
- ドメイン名システム(DNS)型の分散データベース・システムのサーバであって、
ドメイン名から目標とするエンティティ(B)の電話番号へのマッピングを提供する少なくとも1つの資源レコードを有し、
前記エンティティ(B)を識別する番号ストリングをドメイン名ラベルへと解析する手段と、
このドメインラベルで前記分散データベース・システムを検索する手段と、
前記レコードから電話番号を取得することができるようにする手段と、
を有するサーバ。 - 前記DNS型分散データベース・システムがインターネットのドメイン名システムである、請求項7に記載のサーバ。
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
GB9603590.2 | 1996-02-20 | ||
GBGB9603590.2A GB9603590D0 (en) | 1996-02-20 | 1996-02-20 | Method of accessing a target entity over a communciations network |
PCT/GB1996/003054 WO1997031490A2 (en) | 1996-02-20 | 1996-12-11 | Method of accessing a target entity over a communications network |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2003411553A Division JP3867079B2 (ja) | 1996-02-20 | 2003-12-10 | 通信ネットワーク上の目標エンティティへのアクセス方法 |
Publications (3)
Publication Number | Publication Date |
---|---|
JP2000504917A JP2000504917A (ja) | 2000-04-18 |
JP2000504917A5 JP2000504917A5 (ja) | 2004-11-11 |
JP4159603B2 true JP4159603B2 (ja) | 2008-10-01 |
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 After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2003411553A Expired - Lifetime JP3867079B2 (ja) | 1996-02-20 | 2003-12-10 | 通信ネットワーク上の目標エンティティへのアクセス方法 |
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) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
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 |
Families Citing this family (42)
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 |
WO1999029083A1 (en) * | 1997-12-02 | 1999-06-10 | Alcatel Usa Sourcing, L.P. | Method and apparatus for dynamic domain names |
WO1999028979A2 (en) * | 1997-12-02 | 1999-06-10 | Alcatel Usa Sourcing, L.P. | Digital phone system |
GB2338872B (en) * | 1997-12-05 | 2000-08-30 | Distrib Syst Res Inst | 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 |
AU3502999A (en) * | 1998-06-12 | 1999-12-23 | Alcatel | Programmable telecommunications interface |
GB9815585D0 (en) * | 1998-07-18 | 1998-09-16 | Fitton Stuart J | Computer network addressing system |
AU3140500A (en) * | 1999-03-26 | 2000-10-16 | 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 |
MXPA01012171A (es) * | 1999-05-27 | 2003-06-30 | Internet Man Systems Inc | Sistemas y metodos para comunicaciones a traves de varias aplicaciones de comunicacion usando una sola cadena de direccionamiento. |
JP2003504951A (ja) * | 1999-07-09 | 2003-02-04 | ハリス,マーク,ジェイ. | 電話番号を使用するネットワークアドレス指定システムおよび方法 |
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. |
WO2001029710A2 (en) * | 1999-10-15 | 2001-04-26 | Nametree, Inc. | Derivative domain names |
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 |
SE517354C2 (sv) * | 1999-12-01 | 2002-05-28 | Ericsson Telefon Ab L M | System och ett förfarande för privat telekommunikationsnät |
US8548010B2 (en) | 2000-01-19 | 2013-10-01 | Sony Corporation | Method and apparatus for event-based synchronization of information between communication devices |
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 |
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 |
ES2291970T3 (es) * | 2003-12-19 | 2008-03-01 | France Telecom | Procedimiento y dispositivo de emision de solicitudes hacia un servidor de nombres de dominio desde una maquina solicitante. |
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 |
MX2010009321A (es) * | 2008-02-22 | 2011-05-19 | Sage Connex Llc | Portal de datos personales en una residencia con pstn y en linea con salas y objetos virtuales. |
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)
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 |
-
1996
- 1996-02-20 GB GBGB9603590.2A patent/GB9603590D0/en active Pending
- 1996-12-11 EP EP02000568A patent/EP1207704B1/en not_active Expired - Lifetime
- 1996-12-11 EP EP96941768A patent/EP0876733A1/en not_active Withdrawn
- 1996-12-11 AU AU11045/97A patent/AU719651C/en not_active Ceased
- 1996-12-11 DE DE69632495T patent/DE69632495T2/de not_active Expired - Lifetime
- 1996-12-11 EP EP02000567A patent/EP1207703B1/en not_active Expired - Lifetime
- 1996-12-11 WO PCT/GB1996/003054 patent/WO1997031490A2/en not_active Application Discontinuation
- 1996-12-11 CN CN96180063.1A patent/CN1209249A/zh active Pending
- 1996-12-11 CA CA002239495A patent/CA2239495A1/en not_active Abandoned
- 1996-12-11 NZ NZ323991A patent/NZ323991A/xx unknown
- 1996-12-11 DE DE69633205T patent/DE69633205T2/de not_active Expired - Lifetime
- 1996-12-11 JP JP52987197A patent/JP4159603B2/ja not_active Expired - Lifetime
-
1998
- 1998-06-02 NO NO19982513A patent/NO325606B1/no not_active IP Right Cessation
-
2003
- 2003-12-10 JP JP2003411553A patent/JP3867079B2/ja not_active Expired - Lifetime
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
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 |
Also Published As
Publication number | Publication date |
---|---|
NZ323991A (en) | 1999-06-29 |
CA2239495A1 (en) | 1997-08-28 |
EP1207703A3 (en) | 2002-09-18 |
AU719651B2 (en) | 2000-05-11 |
EP0876733A1 (en) | 1998-11-11 |
AU1104597A (en) | 1997-09-10 |
NO325606B1 (no) | 2008-06-23 |
EP1207704B1 (en) | 2004-05-12 |
DE69633205D1 (de) | 2004-09-23 |
NO982513D0 (no) | 1998-06-02 |
DE69632495D1 (de) | 2004-06-17 |
EP1207704A3 (en) | 2002-09-18 |
CN1209249A (zh) | 1999-02-24 |
DE69633205T2 (de) | 2005-07-14 |
EP1207704A2 (en) | 2002-05-22 |
NO982513L (no) | 1998-08-05 |
EP1207703B1 (en) | 2004-08-18 |
DE69632495T2 (de) | 2005-05-12 |
WO1997031490A2 (en) | 1997-08-28 |
JP2004194330A (ja) | 2004-07-08 |
JP3867079B2 (ja) | 2007-01-10 |
EP1207703A2 (en) | 2002-05-22 |
AU719651C (en) | 2007-09-06 |
GB9603590D0 (en) | 1996-04-17 |
WO1997031490A3 (en) | 1997-11-13 |
JP2000504917A (ja) | 2000-04-18 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP4159603B2 (ja) | 通信ネットワーク上の目標エンティティへのアクセス方法 | |
JP3742108B2 (ja) | 遠隔通信サービス提供方法 | |
JP3742109B2 (ja) | 遠隔通信サービス提供方法 | |
US7903641B2 (en) | Method and apparatus for accessing communication data relevant to a target entity identified by a number string | |
JP2000516408A (ja) | 遠隔通信システムに使用されるサービス資源項目のアクセス方法 | |
US6131095A (en) | Method of accessing a target entity over a communications network |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20031209 |
|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20031209 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060620 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060920 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070626 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070926 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080129 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080425 |
|
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: 20080617 |
|
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080716 |
|
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: 20110725 Year of fee payment: 3 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110725 Year of fee payment: 3 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120725 Year of fee payment: 4 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120725 Year of fee payment: 4 |
|
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: 20120725 Year of fee payment: 4 |
|
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: 20120725 Year of fee payment: 4 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130725 Year of fee payment: 5 |
|
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 |