(57)【特許請求の範囲】
【請求項１】
電話ネットワークのユーザに対してコンテント・ソースを利用可能にさせる方法であって、上記コンテント・ソースが、コンピュータ・ネットワークに接続される少なくとも１つのサーバ上で提供され、上記コンテント・ソースの各々が、それぞれのあらかじめ定められたコードに関連づけられ、対応する既知のＵＲＩによって上記コンピュータ・ネットワーク上で位置を特定されることが可能であり、該方法が、(a)上記電話ネットワークに接続したユーザ電話による呼び出しの間に、上記ユーザ電話による上記呼び出しによって生成された情報に基づいて、所定のコンテント・ソースがアクセスされるべきものであることを判断し、そう判断した場合に、上記ユーザ電話による上記呼び出しによって生成された情報に基づいて、要求されたコンテント・ソースの上記あらかじめ定められたコードを作成するステップであって、判断することまたは作成することの少なくとも一方が上記ユーザ電話から入力された番号を当該情報として使用することを含むステップと、(b)上記あらかじめ定められたコードをそのあらかじめ定められたコードに関連づけられたコンテント・ソースの上記既知のＵＲＩに対応づけるステップと、(c)上記ステップ(b)で導出されたＵＲＩを利用して、上記コンピュータ・ネットワーク上の所望のコンテント・ソースにアクセスするステップと、(d)上記ネットワークを経由して上記コンテント・ソースから上記ユーザ電話にコンテントを伝送するステップと、を含み、ステップ(a)および(b)は、電話ネットワーク内で実行され、ステップ(c)および(d)は、上記コンピュータ・ネットワークに接続された、電話ネットワークのインテリジェント周辺機能を要する方法。
【請求項２】
ステップ(a)において、所定のコンテント・ソースがアクセスされるべきものであることを判断することは、上記ユーザ電話を使用して入力され、サービスの種類を指定する、あらかじめ定められたサービス指定子コードを認識することを含み、上記あらかじめ定められたコードを作成することは、上記サービス指定子コードに続いて入力された番号を、要求されたコンテント・ソースに関する上記あらかじめ定めされたコードの少なくとも一部として使用することを含む請求項１に記載の方法。
【請求項３】
ステップ(a)において、所定のコンテント・ソースがアクセスされるべきものであることを判断することは、上記ユーザ電話を使用して入力され、サービスの種類を指定する、あらかじめ定められたサービス指定子コードを認識することを含み、上記あらかじめ定められたコードを作成することは、上記ユーザ電話の電話番号を、要求されたコンテント・ソースに関する上記あらかじめ定めされたコードの少なくとも一部として使用することを含む請求項１に記載の方法。
【請求項４】
上記ステップ(a)が、呼び出し設定と切断の間に上記電話ネットワークのノードにおけるあらかじめ定められたサービス・トリガー条件を認識し、上記あらかじめ定められたサービス・トリガー条件を認識することにより、アクセスされるべき上記コンテント・ソースを使用する対応するサービスを始動することを含む、請求項１に記載の方法。
【請求項５】
上記サービスが呼び出され側サービスであり、上記ステップ(b)が、上記ユーザ電話において入力された、呼び出され側番号を所望のコンテント・ソースに関する上記あらかじめ定められたコードの少なくとも一部として使用するステップを含む、請求項４に記載の方法。
【請求項６】
ステップ(ｄ)において伝送される上記コンテントが上記呼び出され側サービスの一部として上記電話ユーザに提供されるメッセージである、請求項５に記載の方法。
【請求項７】
複数のコンテント項目が上記コンテント・ソースに保持されていて、ステップ(a)が所望の上記コンテント項目の種類を示すインジケータを収集するステップをさらに含み、ステップ(d)がこのインジケータを使用して所望のコンテント項目だけを上記ユーザ電話へ伝送する、請求項５に記載の方法。
【請求項８】
上記コンテント項目の種類を示すインジケータが、上記ユーザ電話から入力された番号である、請求項７に記載の方法。
【請求項９】
上記コンテント項目の種類を示すインジケータが、呼び出しポイントを示すインジケータである、請求項７に記載の方法。
【請求項１０】
ステップ(ｂ)において、上記ＵＲＩが、上記あらかじめ定められたコードとＵＲＩを関連づける関連テーブルの照合によって対応するあらかじめ定められたコードから導出され、上記関連テーブルが上記コンピュータ・ネットワークに接続された少なくとも１つのデータベース・サーバ上に保持され、ステップ(ｂ)が、上記コンピュータ・ネットワークを経由して上記データベース・サーバにアクセスして上記あらかじめ定められたコードに対応する上記ＵＲＩを決定することを含む、請求項１に記載の方法。
【請求項１１】
上記少なくとも１つのデータベース・サーバが、ＤＮＳタイプ分散データベース・システムによって提供され、上記ＵＲＩがドメイン名と呼ばれるそれぞれの名前に関連づけられ、それによって検索されるレコードに保持され、ステップ(ｂ)が、上記あらかじめ定められたコードを対応する上記ドメイン名に変換しそのドメイン名を使用して所望のコンテント・ソース項目のＵＲＩを上記ＤＮＳタイプ分散データベース・システムから取り出すステップを含む、請求項１０に記載の方法。
【請求項１２】
上記コンピュータ・ネットワークがインターネットであり、上記電話ネットワークがＰＳＴＮである、請求項１乃至請求項１１のいずれかに記載の方法。
【請求項１３】
サービス切り替えポイントを持つ搬送体ネットワーク、サービス制御サブシステムおよびインテリジェント周辺機能を備える電話ネットワークであって、
上記インテリジェント周辺機能が、コンピュータ・ネットワークに接続され、
上記サービス切り替えポイントが、上記搬送体ネットワークに接続したユーザ電話を伴う呼び出し設定の間に、上記コンピュータ・ネットワークに接続したサーバ上の特定のＵＲＩにおいて提供され、あらかじめ定められた関連コードを持つコンテント項目へのアクセスを含むコンテント項目アクセス・サービスが要求されているかどうかを判断する手段を含み、
上記サービス制御サブシステムが、上記コンテント項目アクセス・サービスが要求されているという上記サービス切り替えポイントの判断に応答して、上記ユーザ電話から入力された番号の少なくとも一部を使用して上記あらかじめ定められたコードを形成する手段を含み、
上記サービス制御サブシステムおよびインテリジェント周辺機能の１つが、アクセスされるべきコンテント項目の上記特定のＵＲＩに上記あらかじめ定められたコードを対応づける対応づけ手段を持ち、
上記インテリジェント周辺機能が、上記対応づけ手段によって導出されるＵＲＩを使用して上記コンピュータ・ネットワーク上の所望のコンテント項目にアクセスし、上記ユーザ電話にそれを伝送する、電話ネットワーク。
【請求項１４】
電話ネットワークのユーザに対してコンテント受け手を利用可能にさせる方法であって、上記コンテント受け手が、コンピュータ・ネットワークに接続される少なくとも１つのサーバ上で提供され、上記コンテント受け手の各々が、それぞれのあらかじめ定められたコードに関連づけられ、対応する既知のＵＲＩによって上記コンピュータ・ネットワーク上で位置を特定されることが可能であり、該方法が、(a)上記電話ネットワークに接続したユーザ電話による呼び出しの間に、上記ユーザ電話による上記呼び出しによって生成された情報に基づいて、所定のコンテント・ソースがアクセスされるべきものであることを判断し、そう判断した場合に、上記ユーザ電話による上記呼び出しによって生成された情報に基づいて、要求されたコンテント・ソースの上記あらかじめ定められたコードを作成するステップであって、判断することまたは作成することの少なくとも一方が上記ユーザ電話から入力された番号を当該情報として使用することを含むステップと、(b)上記あらかじめ定められたコードをそのあらかじめ定められたコードに関連づけられたコンテント受け手の上記既知のＵＲＩに対応づけるステップと、(c)上記電話ネットワークさらにコンピュータ・ネットワークを経由して、上記ユーザ電話から上記コンテント受け手にコンテントを伝送するステップであって、コンテント伝送を実施するように、ステップ(b)で導出されたＵＲＩが、上記コンピュータ・ネットワーク上のコンテント受け手にアクセスするのに使用されるステップと、を含み、ステップ(a)および(b)は、電話ネットワーク内で実行され、ステップ(c)は、上記コンピュータ・ネットワークに接続された、電話ネットワークのインテリジェント周辺機能を要する方法。
【請求項１５】
ステップ(a)において、所定のコンテント・ソースがアクセスされるべきものであることを判断することは、上記ユーザ電話を使用して入力され、サービスの種類を指定する、あらかじめ定められたサービス指定子コードを認識することを含み、上記あらかじめ定められたコードを作成することは、上記サービス指定子コードに続いて入力された番号を、要求されたコンテント・ソースに関する上記あらかじめ定めされたコードの少なくとも一部として使用することを含む請求項１４に記載の方法。
【請求項１６】
ステップ(a)において、所定のコンテント・ソースがアクセスされるべきものであることを判断することは、上記ユーザ電話を使用して入力され、サービスの種類を指定する、あらかじめ定められたサービス指定子コードを認識することを含み、上記あらかじめ定められたコードを作成することは、上記ユーザ電話の電話番号を、要求されたコンテント・ソースに関する上記あらかじめ定めされたコードの少なくとも一部として使用することを含む請求項１４に記載の方法。
【請求項１７】
上記ステップ(a)が、呼び出し設定と切断の間に上記電話ネットワークのノードにおけるあらかじめ定められたサービス・トリガー条件を認識し、上記あらかじめ定められたサービス・トリガー条件を認識することにより、アクセスされるべき上記コンテント・ソースを使用する対応するサービスを始動することを含む、請求項１４に記載の方法。
【請求項１８】
上記サービスが呼び出され側サービスであり、上記ステップ(b)が、上記ユーザ電話において入力された、呼び出され側番号を所望のコンテント受け手に関する上記あらかじめ定められたコードの少なくとも一部として使用するステップを含む、請求項１７に記載の方法。
【請求項１９】
ステップ(ｂ)において、上記ＵＲＩが、あらかじめ定められたコードとＵＲＩを関連づける関連テーブルの照合によって対応するあらかじめ定められたコードから導出され、上記関連テーブルが上記コンピュータ・ネットワークに接続された少なくとも１つのデータベース・サーバ上に保持され、ステップ(ｂ)が、上記コンピュータ・ネットワークを経由して上記データベース・サーバにアクセスして上記あらかじめ定められたコードに対応する上記ＵＲＩを決定することを含む、請求項１４に記載の方法。
【請求項２０】
上記少なくとも１つのデータベース・サーバが、ＤＮＳタイプ分散データベース・システムによって提供され、上記ＵＲＩがドメイン名と呼ばれるそれぞれの名前に関連づけられ、それによって検索されるレコードに保持され、上記ステップ(ｂ)が、上記あらかじめ定められたコードを対応する上記ドメイン名に変換しそのドメイン名を使用して所望のコンテント受け入れ項目のＵＲＩを上記ＤＮＳタイプ分散データベース・システムから取り出すステップを含む、請求項１９に記載の方法。
【請求項２１】
上記コンピュータ・ネットワークがインターネットであり、上記電話ネットワークがＰＳＴＮである、請求項１４に記載の方法。
【請求項２２】
あらかじめ定められたＵＲＬにおけるＨＴＴＰサーバに保持されたインターネット・コンテントを検索し、検索したコンテントを、電話システムを介して電話ユーザへ配信するコンテント検索システムであって、
ユーザ電話から電話システムを介して選択データを受け取り、検索したコンテントを聞くことのできる形態で当該電話に送り返す電話システムインタフェースと、
選択データとＵＲＬとの間の対応づけを保持する記憶装置と、特定の選択データに関連付けられた特定の予め定められたＵＲＬによって上記対応づけを指定する、インターネット上のＨＴＴＰプロトコル・メッセージを、電話ユーザから受け取り、当該メッセージにしたがって記憶装置に保持される対応づけを設定するユーザ入力装置と、を備える対応づけ装置と、
電話インタフェースにおける選択データの受け取りに応じて、受け取った特定の選択データに対応する予め定められたＵＲＬを検索するように、対応づけ装置にアクセスする制御装置と、
上記制御装置によって指定された、予め定められたＵＲＬにおいてＨＴＴＰサーバに保持されたインターネット・コンテントを検索し、検索したコンテントを、電話システムインタフェースによって電話システムを介して送るために、聞くことのできる形態に変換するインターネット・インタフェース装置と、を含むコンテント検索システム。
【請求項２３】
上記選択データが、上記ユーザ電話から入力された番号および上記ユーザ電話の電話番号のうちの１つの少なくとも一部を含む請求項２２に記載のコンテント検索システム。
【請求項２４】
電話システムの少なくとも１つのノードに組み込まれている、請求項２２に記載のコンテント検索システム。
【請求項２５】
電話システムの境界に備えられたＩＳＰ設備に組み込まれている、請求項２２に記載のコンテント検索システム。
【発明の詳細な説明】
発明の技術分野
本発明は、電話ネットワークのユーザに対してコンテント資源を利用可能にさせる方法に関するものである。
本明細書において使用される用語「電話ネットワーク」は、(電話番号を呼び出す機能を持つファックスまたは同様の品目を含む)エンド・ユーザ電話機器の間のネットワークを経由して搬送体経路を設定する交換機能を備えた搬送体ネットワークを含むＰＳＴＮ、ＰＬＭＮまたはプライベート電話ネットワークのようなシステムを意味する。電話ネットワーク環境における「呼び出し」は、搬送体ネットワークにわたる搬送体経路設定による通信を意味するものと理解されるべきであり、呼び出し設定、維持および切断は、搬送体ネットワーク上の搬送体経路を設定し、維持し、切断するプロセスを意味するものと見なされるべきである。「呼び出し処理」および「呼び出し取り扱い」のような用語は同様に解釈されるべきである。
発明の背景技術
ＰＳＴＮ(Public Switched Telephone Networksすなわち公共交換電話ネットワーク)およびＰＬＭＮ(Public Land Mobile Networksすなわち公共地上移動体ネットワーク)を運営する遠隔通信会社は、通信サービスを提供する事業を行い、その事業において、８００番サービスや呼び出し転送のような「ＩＮサービス」の形態で行う組み込み情報サービスを発展させている。対照的に、最近爆発的な成長がみられるワールド・ワイド・ウェブ(すなわちＷＷＷ)は、複雑な情報サービスを提供するインターネット型グローバル・ネットワークの１例である。大規模通信ユーティリティおよび非常に動的で開拓精神に富んだＷＷＷ情報文化というこれら２つの世界は、ぎこちない仲間であり、各々は相手によって既に占有された領域に浸透する計画をたてていて、将来、電話通信サービスがＷＷＷを経由して提供され、情報サービスが公共通信下部構造を介して提供されるであろう。
本発明は、これら２つの世界の関係を現在より一層協調的なものにさせる技術を提案する。本発明の脈絡を明確にするため、先ず、これら２つの世界の各々について考察を加える。
ＩＮサービスにおける電話ネットワーク
基本的ＰＳＴＮ。ＰＳＴＮ(すなわちPublic Switched Telephone Network公共交換電話ネットワーク)によって提供される基本的サービスは、呼び出し側電話において入力された呼び出され側電話番号に従った２台の電話の接続(すなわち２つの電話の間の搬送体経路の設定)である。図１は、そのようなサービスを提供しているＰＳＴＮを単純化して表現したものである。特に、(アナログ電話または最近のＩＳＤＮ端末のような)宅内機器(すなわちＣＰＥ)１０は、アクセス・ネットワーク１１を経由して交換ポイント(すなわちＳＰ)１２に接続される。ＳＰ１２は、ＳＰの制御部１５によって制御される相互接続用電話中継線１４および複数のＳＰから構成される相互交換ネットワーク１３におけるノードを形成する。制御部１５によって実施される制御は、宅内機器(ＣＰＥ)および他のＳＰから受け取る入力信号によって決定され、その制御は、呼び出しＣＰＥと呼び出されＣＰＥの間の所望の搬送体経路を作成する呼び出し設定、維持および切断を含む。概念的には、ＰＳＴＮは搬送体ネットワークおよび制御(信号)ネットワークとみなすことができ、後者の機能は、搬送体ネットワーク上の呼び出し制御、すなわち搬送体経路の設定、維持および切断の実行である。実際には、搬送体および信号ネットワークは、同一の物理的回路および場合によっては同一の論理経路を使用することもある。
このように、ＣＰＥが伝統的な、知能のない電話である場合、ＣＰＥとそのローカルＳＰの間の制御信号機能は、バンド内信号機能である。すなわち、信号は音声のために使用されるものと同じ経路で搬送される。この信号は、ＳＰ１２において、専用共通経路信号ネットワークを使用するＳＰ間信号に変換される(現在このような変換はＳＳ７プロトコール規格を使用して実施されている)。ＣＰＥがＩＳＤＮ端末である場合、信号は別の経路を介してＣＰＥから直接搬送される。モデムＳＰは、ＣＰＥが標準の電話かＩＳＤＮ端末であるかを判断する相互交換呼び出し制御信号のためＩＳＵＰ(すなわちＩＳＤＮ User Part)ＳＳ７プロトコルを使用する。
インテリジェント・ネットワーク。基本的呼び出し処理に加えて、ＳＰはいわゆるＩＮサービス(Intelligent Networkの頭文字でインテリジェント・ネットワークの意味)を提供する。この場合、ＳＰはサービス交換ポイント(service switching pointの頭文字をとって以下ＳＳＰと呼称する場合がある)と呼ばれる。ＳＳＰ２５は、特定の基準の充足に基づいて定義された被呼び出しポイントにおける呼び出し処理を中止し、サービス制御ポイント(すなわちＳＣＰ)１７(図２参照)または補助ポイント(すなわちＡＤＪ)１８のいずれかの形態でサービス制御機能(すなわちＳＣＦ)を提供するサービス制御サブシステムに呼び出し処理の継続を一任するように構成される。補助ポイント(ＡＤＪ)１８はＳＳＰ２５に直接接続し、一方、ＳＣＰ１７およびＳＳＰ２５は、信号転送ポイント(すなわちＳＴＰ)を含む拡張共通経路信号ネットワーク(すなわちＣＣＳネットワーク)１６を通して相互に交信する。ＳＣＰ１７は、複数のＳＳＰ２５に接続することもできる。ＳＣＰ１７および補助ポイント１８は１つまたは複数のサービス論理プログラム(すなわちＳＬＰ)のインスタンス２１が実行されるサービス論理実行環境(すなわちＳＬＥＥ)２０を提供する。ＳＬＥＥ２０およびＳＬＰ２１はＳＳＰ２５にサービスを提供するためのサービス制御機能性をともに提供する。
ＳＣＰまたは補助ポイント上で動作するサービス論理は、サービス・データ機能(すなわちＳＤＦ)２２に記憶される加入者情報を一般に活用する。ＳＤＦは、ＳＣＰと補助ポイントに統合されている場合もあれば、それぞれ部分的にあるいは完全に独立している場合もある。サービス・データ機能(ＳＤＦ)は、サービス制御機能(ＳＣＦ)と同様に、ＰＳＴＮのサービス制御サブシステムの一部を構成する。サービス制御機能の一部またはすべてがＰＳＴＮ交換機自体に組み込まれていることもある点に注意する必要がある。
動作に関する限り、ＳＳＰ２５は、呼び出しを受け取ると、内部のトリガー条件、およびおそらく(ダイヤルされた桁のような)ユーザ情報を検査して、呼び出しがサービス制御サブシステム１７、１８によって提供されるべきサービスを要求しているか否かを確認する。トリガー条件の検査は、呼び出し処理におけるいくつかの異なるポイントで実行される。サービスが必要であると判断すると、ＳＳＰ２５は、サービス制御サブシステム(ＳＣＰ１７または補助ポイント１８のいずれか)にメッセージを送り、所望のサービスを要求し、その接続および呼び出し処理状態に関する呼び出しの論理表現をサブシステムに送る。次にサービス制御サブシステムは要求されたサービスを提供するが、それは、ＳＳＰおよびサービス制御サブシステムの間の単一の交信または複数交信のセッションを伴う。典型的サービスは、呼び出され側サービスである呼び出し転送であり、これは，例えば、番号Ｘの加入者の要求に応じて、その加入者の番号が呼び出されて１０回呼び出し音を鳴らしても出ない場合は番号Ｙを呼び出すようなサービスである。この場合、呼び出され側加入者にとってローカルにあるＳＳＰがこのサービスを提供するためその接続ＳＣＰ(または補助ポイント)を起動する。当然のことではあるが、ＳＳＰは呼び出される番号Ｘに関してサービスが提供されるべきことをあらかじめ知っていなければならない。
ＳＣＰ１７およびＡＤＪ１７に加えて、図２のネットワークは、１つまたは複数のＳＳＰ２５に対する搬送体経路接続性を持つインテリジェント周辺機器(ＩＰ)２３を含む。ＩＰ２３は、音声通告およびＤＴＭＦ番号収集機能のような情報をエンド・ユーザと交換する必要がある資源を提供する(エンド・ユーザと搬送体経路の間の受け渡しされるこのようなタイプの非信号情報を本明細書では一般的に「コンテント」と呼ぶ)。このようなＩＰ資源は、ＳＳＰ２５から受け取られる入力に応答してＩＰ２３の資源制御実行環境(ＲＣＥＥ)２６によって管理され制御される。そのような入力は、ＳＬＰ２１の実行の間に、例えば、音声通告がサービス制御サブシステム(ＳＣＰ１７、ＡＤＪ１８)からエンドユーザへ行われるべきことを要求する。この場合、サービス制御サブシステムは、ＩＰ２３に対して搬送体経路を設定するＳＳＰにこの要求を送付し、ＩＰに対して要求された通告の実行を命令する。また、サービス制御サブシステムがＳＳＰ２５を介してではなくＣＣＳネットワークを経由してＩＰと直接通信するように構成することも可能である。
ＩＰ機能性および資源は、また、ＩＰのようにＳＳＰに対する搬送体経路接続性を持つサービス・ノード(ＳＮ)の内部に提供されることもできる。しかしながら、ＳＮは、サービス論理プログラムを実行するためＳＬＥＥ２０に類似するサービス・ノード実行環境(ＳＮＥＥ)２８を含む。このように、ＳＮは、ＳＳＰが呼び出しを通してＳＮへスイッチすると、自動的に一定のサービスを提供する。特に、音声メール、自動化アテンダントおよびファックス・サーバのようなサービスを提供する。これらサービスのすべては、エンド・ユーザとの間の大量のコンテント伝送を必要とする。ＳＮのＩＰ機能性および資源は、必ずしもＳＮのＳＮＥＥの制御にすべて委ねられるのではなく、遠隔ＳＬＥＥによっても使用されることができる。ＳＮが特定タイプのＳＬＰを実行することができる限り、ＳＮは、ネットワークのサービス制御サブシステムの一部を形成する。
ネットワークは、また、ネットワーク全体およびそのサービスをカバーし、ネットワーク監視および制御を実行するオペレーティング・システム(図示されていない)を含むこともある。
ＰＳＴＮにおけるＩＮサービスの提供に関する上述のモデルは、ＧＳＭおよびその他の移動体ネットワークのようなＰＬＭＮ(すなわちPublic Land Mobile Networks公共地上移動体ネットワーク)にもあてはめることができる。移動体加入者の場合、通常の信号要件に加えて、移動体加入者への呼び出し経路を確立する必要があるので、信号制御は一層複雑である。しかしながら、これは、ＰＳＴＮにおける多数の呼び出され側サービスと相違する問題ではない。かくして、ＧＳＭにおいては、サービス・データ機能(ＳＤＦ)は、主に、ホーム・ロケーション・レジスタ(ＨＬＲ)という名前をつけられたシステムに位置し、サービス制御機能は、一般的に各ＳＳＰと１対１で対応するビジタ・ロケーション・レジスタ(ＶＬＲ)という名前をつけられたシステムに位置する(ＳＳＰはＧＳＭの用語では移動体交換センタＭＳＣと呼ばれる)。
加入者が移動体であるので、加入者プロフィールは、ＨＬＲから移動体加入者に機能的に最も近いＶＬＲへ転送され、そのＶＬＲが加入者プロフィールを使用して(定められた)サービスを操作して、ＳＳＰと交信する。このように、ＨＬＲおよびＶＬＲは、その関連データベースを用いて、ＳＣＰまたはＡＤＪと同様のサービス制御サブシステムを構成する。
当然のことながら、プライベート電話システムにおいてＩＮサービスを提供することは可能であり、この場合、サービス制御機能およびサービス・データ機能は、一般的にＰＡＢＸ(構内自動交換設備)に組み込まれるかまたはローカルのコンピュータによって提供される。サービス制御サブシステムはＰＡＢＸと物理的に独立していない場合もある。
ＩＮサービスを提供する上記の一般的アーキテクチャ上のフレームワークは長所と短所を持つ。主な長所は、８００番サービス、クレジットカード呼び出し、音声メールおよび種々の呼び出し待機と転送サービスのような多くのサービスがうまく展開されていることである。しかし、長年の標準化にもかかわらずそのようなサービスは、なおまだネットワーク・プラットフォーム上で一度に１つずつしか実施されず、十分な展開が図れない。何十万何百万もの加入者にサービスを提供する大規模な無故障システムを基に開発が進められ、実現には多くの年を必要とする。更に、これらのサービスをサポートするために使用されるネットワークは基本的電話下部構造を構成しているので、これらのネットワークに付加されるものは何でも厳格に吟味されなければならない。その上、各国および操作員はともすると標準のローカル・バリエーションを持つ傾向があり、それが標準製品の供給を困難にし、競争の力学を破壊する。
ワールド・ワイド・ウェブ(ＷＷＷ)
電話下部構造の慎重な遅い進歩と対照的に、ＷＷＷは１９８９年におけるその発端から爆発的に成長して、情報内容の広がり、可用性および豊富さの観点からみて主要な電子情報分配サービスとなった。誰もが、わずかの出費で、高度に相互接続した情報アーキテクチャにおいて世界中の聴衆への情報提供者になることができる。
ＷＷＷは、インターネットを経由し、クライアントとサーバの間で最も簡単な交換だけを委託するクライアント／サーバ・プロトコルを使用するクライアント／サーバ・アプリケーションである。このプロトコルは、インターネットのようなＴＣＰ／ＩＰネットワーク上の使用のため最適化されたＨＴＴＰ(すなわちHyper Text Transfer Protocol複合テキスト伝送プロトコル)であるが、ＨＴＴＰプロトコルは、異なる通信プロトコル・スタックを使用するネットワーク上で使用することができる。
ＷＷＷに関する文献はＷＷＷ自体と同じように増大しているので、ＷＷＷ、ＨＴＴＰおよびインターネット関する詳細の記述は本明細書において行わない。しかしながら、本発明にとって意味のある特定の特性に焦点をあてた概要の記述だけを以下に行う。
ＷＷＷは相互接続のためインターネットを使用する。インターネットは世界的な規模でネットワークを相互に接続するシステムである。インターネットは、ＴＣＰ／ＩＰプロトコル規格に基づくもので、ＴＣＰ／ＩＰを使用するネットワークへの接続を行う。インターネット上に存在するエンティティ(すなわち実体)は、インターネットに接続したネットワークへのアクセスおよびＩＰアドレスを必要とする。ＩＰアドレスは階層的に構成されている。一般的に、エンティティはユーザ・レベルで名前によって識別され、名前は、インターネットのドメイン名システム(Domain Name Systemの頭文字をとって以下ＤＮＳと略称する場合がある)によって対応するＩＰアドレスに分解される。
ＷＷＷの動作。図３を参照すれば、インターネット３０へのアクセスは、直接または間接的にそれ自体インターネットに接続しているネットワークへの直接接続によって行われる。そのような構成は図３における端末３１によって代表される(この端末は例えばＵｎｉｘワークステーションまたはＰＣである)。このような形式でのインターネットへの接続は、「ネットワーク・アクセス」の実行として知られている。インターネットへネットワーク・アクセスするいかなるエンティティも、十分な関連機能性を持っていることを前提とすれば、インターネット上のサーバとしての役割を果たす。例えば、図３において、ファイル記憶機構３７を持つエンティティ３２は、サーバとしての働きをする。
ＷＷＷの多くのユーザは、インターネットへのネットワーク・アクセスを行わず、その代わりに、ネットワーク・アクセス機能を持つインターネット・サービス・プロバイダすなわちＩＳＰ３３を経由してインターネットへのアクセスを行う。このケースでは、ユーザ端末３４は、一般的には、モデムを使用しＳＬＩＰ(すなわちSerial Line Interface Protocolシリアル・ライン・インタフェース・プロトコル)またはＰＰＰ(すなわちPoint-to-Point Protocolポイント・ツー・ポイント・ポイント・プロトコル)を利用して公共電話システムを経由してＩＳＰ３３と通信する。これらのプロトコルは、インターネット・パケットが通常の電話線で伝送されることを可能にする。この形式のインターネットへのアクセスは、「ダイヤルアップＩＰ」アクセスとして知られている。このアクセス方式では、ユーザ端末３４は各ユーザ・セッションの間一時的にＩＰアドレスを割り当てられる。しかしながら、このＩＰアドレスはセッション毎に異なるので、エンティティ３４はサーバの役割を果たすことはできない。
ＷＷＷの基礎は、統一資源識別子(すなわちUniform Resource Identifierであり以下略してＵＲＩと呼ぶ)という手段によって特定の情報資源の位置を定める能力である。ＵＲＩは、一般に、位置によって資源を特定する統一資源位置特定子(すなわちUniform Resource Locatorであり以下略してＵＲＬと呼ぶ)か、または、ＵＲＬへ変換可能な統一資源名(すなわちUniform Resource Nameであり以下略してＵＲＮと呼ぶ)かのいずれかである。例えば、完全すなわち「絶対」ＵＲＬは次のようなエレメントを含む。
方式      −これは、目標資源にアクセスするために使用されるアクセス方式である。
ホスト    −インターネット・ホスト・ドメイン名またはＩＰアドレス。
ポート    −(ＴＣＰ)接続のためのホスト・ポート。
絶対経路  −ホスト上の資源の絶対経路。
実際には、ポート８０が想定される場合「ポート」は省略できる。
図４は、ヒューレット・パッカード製品ウェルカム・ページのためのＵＲＬを示している。この場合エレメントは次の通りである。
方式      −http
ホスト    −www.hp.com
ポート    −省略(ポート８０が仮定されている)
絶対経路  −Products.html
ＨＴＴＰプロトコルは、要求／応答パラダイムに基づいている。図３を再び参照すれば、アクセスされるべき資源３０を識別する特定のＵＲＩを所与とすれば、クライアントは、ＵＲＩの「ホスト」エレメントに対応するサーバ３１との接続を確立してそのサーバに要求を送る。この要求は、要求方法および「要求ＵＲＩ」を含む(「要求ＵＲＩ」は一般的にＵＲＩの絶対経路によって識別されるサーバ上の資源の絶対経路そのものである)。要求は付加的データ・エレメントを含むこともある。サーバ３１は次に(この例では記憶装置３７に記憶されている)資源３６にアクセスし応答する。この応答は、ＭＩＭＥ(すなわちMultipurpose Internet Mail Extensions汎用インターネット・メール拡張)タイプによって識別されるタイプを持つエンティティを含む。
主な要求方法は次の２つである。
ＧＥＴ  −この方法は、要求ＵＲＩによって識別されるいかなる情報をも(エンティティの形式で)取り出す。重要な点であるが、要求ＵＲＩがデータ作成プロセスを参照している場合応答においてエンティティとして返されるものは作成されたデータであり、プロセスのソース・テキストではない。
ＰＯＳＴ−宛先サーバが要求ＵＲＩによって識別される新しい従属資源として要求に含まれたエンティティを受け入れることを要求するためにこの方法が使用される。ポスト方法は、既存の資源の注釈付けのために使用できる。すなわち、この方法は、例えば、掲示板にメッセージを提供し、データ処理プロセスにデータ(例えば形式を提出する結果として作成されたデータ)を提供し、追加演算を通してデータベースを拡張する。
要約すれば、ＧＥＴ方法は、直接データを取り出すためか、あるいは、(例えばデータあるいはプロセスを実行結果の単なる指示である)エンティティを返すプロセスを起動するために使用される。ＰＯＳＴ方法は、データを登録し、この方法がポストされたデータを適切に処理するためサーバにおけるプロセスを起動させる上で効果的であることを示すために使用される。
ＧＥＴまたはＰＯＳＴいずれかの方法を使用してサーバ上での実行を起動されるプロセスへの情報の伝達は、現在、コモン・ゲートウェイ・インターフェース(すなわちＣＧＩ)と呼ばれるインタフェースに従って行われている。受け取りプロセスはスクリプト言語で書かれることが多い(必ずしも必須ではないが)。典型的には、起動されるサーバ・スクリプトは、ＧＥＴ要求に含まれる照会を取り扱うためデータベースへのインタフェーシングのため使用される。もう一つの用途は、上述のよう、ＰＯＳＴ要求に関連したデータをデータベースへ追加することである。
ＷＷＷの成功におけるその他の重要な要因は、ＷＷＷ上に伝送されるドキュメントの構成を表現するハイパーテキスト・マークアップ・ランゲージ(すなわちＨＴＭＬ)の使用、および、そのようなドキュメントをクライアント端末のユーザに提示するためそれらを解釈するNetscapeやMosaicのような強力なグラフィック・ウェブ・ブラウザの存在である。基本的には、ＨＴＭＬはタイトルまたはグラフィックのようなドキュメントの各部分を識別するために使用され、次に各ドキュメント部分を表示する方法の決定はクライアント端末で実行されるブラウザにまかされる。しかしながら、ＨＴＭＬはそれ以上のものであり、ＵＲＩおよび要求方法を(特定のワードまたは画像のような)ドキュメントのすべてのエレメントに関連づけることを可能にし、従って、ユーザがそのエレメントをポイントしクリックすると、ＵＲＩによって識別された資源が、指定された方式(プロトコル)および要求方法に従ってアクセスされる。このような構成によって、１つのドキュメントから他のドキュメントへのハイパーリンク(複合接続)が提供される。そのようなハイパーリンクを使用して、クライアント端末におけるユーザは、世界の一方の側にあるサーバからダウンロードされたドキュメントを世界の別の側のサーバ上に位置する別のドキュメントへ苦もなく飛ぶ(すなわちスキップする)ことができる。１人の作者によって作成されたドキュメントが別の作者によって作成されたドキュメントへのハイパーリンクを含むこともあるので、中央集権的制御なしに非常に強力なドキュメント相互参照システムが実現する。
ハイパーリンクは、ＨＴＭＬドキュメントに組み込むことができる唯一の機能ではない。もう１つの強力な機能は、ダウンロードされた「形式」ドキュメントに画面上で記入し、入力された情報を収集するように設計された(データベースのような)資源に入力情報を渡してもらうため「提示(commit)」ボタンを起動させる能力である。これは、ＰＯＳＴ要求をデータベース資源のＵＲＩと共に'commit'ボタンをＰＯＳＴ要求方法に関連づけることによって達成される。'commit'ボタンの起動によって、入力された情報は、適切に処理される場所である、識別された資源に渡される。
更にもう１つの強力な可能性は、(一般的には翻訳されるべきスクリプトである)プログラム・コードをグラフィック・ボタンのような特定のドキュメント・エレメントに関連づける機能である。この場合プログラム・コードはボタンが起動されると実行を開始する。これは、ユーザに対し、資源からのプログラム・コードのダウンロードおよびその実行の可能性を与える。
当業者に認められることであろうが、ＨＴＭＬは、上記概説した機能性を提供するいくつかの現在利用できるスクリプト言語のうちの１つにすぎず、いかなるウェブ・ブラウザも複数のスクリプト言語の組み込みサポートを持つであろうことは予想することができる。例えば、Netscape 2.0は、HTML 3.0、Javaおよび(Netscape版権所有スクリプト言語である)LiveScriptをサポートする。
グラフィック・ウェブ・ブラウザ自体の役割の重要性は看過されてはならない。複数のスクリプト言語をサポートする能力に加えて、ウェブ・ブラウザは、標準的媒体タイプに対する組み込みサポートおよびクライアントにプログラムをロードし実行する機能などを提供する。このようなブラウザは、ＷＷＷ交信に関するオペレーティング・システムとみなされることもできる。
ＷＷＷおよび電話ネットワーク
音声入力をデジタル化してインターネット上に離散的パケットの形で送信し、それ端末で受け取って再組み立てすることによって接続された端末の間でインターネットを経由して電話通信サービスを提供することは可能である。これは、インターネット上の通信サービスの１例である。反対に、フランスで広く利用されているMinitelのような電話システム上で提供される種々の情報サービスが可能である。しかしながら、相互の伝統的領域へのこのような浸透はインターネットまたは公共電話システムにとって本当の脅威とならない。
一層関心があるのはインターネットおよび電話システムの協調使用の分野である。実際、図４を参照して記述したものの中にそのような分野の１つがある。それは、インターネットへのダイヤルアップＩＰアクセスを取得するためユーザ・コンピュータ３４からインターネット・サービス・プロバイダ３３へのＰＳＴＮ上のモデム・リンクの使用である。この協調使用は、非常に単純な特性を持っている。すなわち、後に生成されるインターネット・トラフィックのためのＰＳＴＮ上の搬送体経路の設定である。インターネットおよびＰＳＴＮの間には実際の交信はない。
インターネットとＰＳＴＮの協調使用のもう１つの既知の例は、最近実施されたもので、端末コンピュータにサウンド・カードを持つインターネット・ユーザが世界中のどこにでもある標準電話に音声通話を行うことができるサービスである。これは、インターネット上でデジタル化された音声を宛先電話の近くのサービス・プロバイダに伝送することによって達成される。このサービス・プロバイダは、所望の電話にアクセスするためローカルのＰＳＴＮに接続して、インターネット上で受け取った音声トラフィックをそのローカルＰＳＴＮへ転送する。呼ばれた電話からの音声入力は逆経路で取り扱われる。このサービスの鍵は、宛先電話にとって(料金的に)ローカルなサービス・プロバイダを識別する能力である。長距離呼び出しに関して通信操作員に対する競争の可能性をもたらしてはいるが、この構成もまたインターネットとＰＳＴＮの単純な相互連携である。しかしながら、この場合、注意すべきことであるが、宛先にとってローカルなＰＳＴＮ上で宛先電話に対して行われている呼び出しの進捗状況に関してインターネット呼び出し側へ少なくとも最小限度のフィードバックを提供することが必要である。このフィードバックは、単に呼び出しが成功したか否かという観点からのものでよい。
インターネット上で利用可能な情報資源への電話ユーザのアクセスを改善することが本発明の目的である。
発明の開示
本発明の１つの局面に従って、電話ネットワークのユーザに対してコンテント資源を利用可能にさせる方法が提供される。上記コンテント資源は、電話ネットワークのユーザにとって一般的にアクセス可能ではあるが論理的にその電話ネットワークから独立しているコンピュータ・ネットワークに接続される少くとも１つのサーバ上で提供され、そのコンテント資源の各々は、それぞれのあらかじめ定められたコードに関連づけられ、対応する既知のＵＲＩによって上記コンピュータ・ネットワーク上での位置を特定されることが可能である。上記方法は、
(a)--上記電話ネットワークに接続したユーザ電話による呼び出しの間に上記コンテント資源がアクセスされるべきものであることを標示する条件を決定するステップ、
(b)--上記ステップ(a)が上記コンテント資源がアクセスされるべきものであることを標示する場合、
--上記ユーザ電話からダイヤルされた番号、および
--上記ユーザ電話の電話番号
の１つの少なくとも１部を使用して、所望の上記コンテント資源の上記あらかじめ定められたコードを作成するステップ、
(c)--上記あらかじめ定められたコードをそのコードに関連づけられたコンテント資源の上記既知のＵＲＩに対応づけるステップ、
(d)--上記ステップ(c)で導出されたＵＲＩを利用して、上記コンピュータ・ネットワーク上の所望のコンテント資源にアクセスするステップ、および、
(e)--上記ネットワークを経由して上記コンテント資源と上記電話の間の少くとも１つの方向にコンテントを伝送するステップ、を含む。
上記「ダイヤル」という用語が、(現代の電話上に一般に備わる１２キーのキーパッドのような)キーパッドの使用による番号の入力または(例えば特定の記憶された番号に対応するＤＴＭＦ信号を発する装置のように)標準的ダイヤル情報を入力する同等の方法を意味することは理解されるであろう。
コンテント資源は、ダウンロード可能なコンテント項目を保持するコンテント・ソースか、あるいは、ユーザの電話から送信されるコンテント項目を受け取るコンテント受け手である。
本発明の１つの実施形態において、上記ステップ(a)は、呼び出し設定または切断の間に実行されまた電話ネットワークの範囲内で実行され、所望のコンテント資源へのアクセスは、コンピュータ・ネットワークへの接続性を有する電話ネットワークのインテリジェント周辺機能を伴う少くとも上記ステップ(d)および上記ステップ(e)の実行を介して電話ネットワークによって制御される。
別の実施形態において、ステップ(a)は、上記電話ネットワークおよび上記コンピュータ・ネットワークの両方に対する接続性を有するＩＳＰ機器に対する電話ネットワーク経由の呼び出し設定の後に実行され、所望のコンテント資源へのアクセスはＩＳＰ機器によって制御される。
本発明のもう１つの局面に従って、サービス切り替えポイントを持つ搬送体ネットワーク、サービス制御サブシステムおよびインテリジェント周辺機能を備える電話ネットワークが提供される。該電話ネットワークは、
--インテリジェント周辺機能が、電話ネットワークのユーザにとって一般にアクセス可能ではあるが電話ネットワークからは論理的に独立しているコンピュータ・ネットワークに接続され、
--上記サービス切り替えポイントが、上記搬送体ネットワークに接続したユーザ電話を伴う呼び出し設定の間上記コンピュータ・ネットワークに接続したサーバ上の特定のＵＲＩにおいて提供され、あらかじめ定められた関連コードを持つコンテント項目へのアクセスを含むコンテント項目アクセス・サービスが要求されていることを標示する条件を決定し、
--上記サービス制御サブシステムが、上記コンテント項目アクセス・サービスが要求されているという上記サービス切り替えポイントの判断に応答して、上記ユーザ電話からダイヤルされた番号の少なくとも一部を使用して上記あらかじめ定められたコードを形成し、
--上記サービス制御サブシステムおよびインテリジェント周辺機能の１つが、アクセスされるべきコンテント項目の上記特定のＵＲＩに上記あらかじめ定められたコードを対応づける対応付け手段を持ち、
--上記インテリジェント周辺機能が、上記対応付け手段によって導出されるＵＲＩを使用して上記コンピュータ・ネットワーク上の所望のコンテント項目にアクセスし、上記ユーザ電話にそれを伝送する、
という特徴を有する。
コンピュータ・ネットワークが電話ネットワークとは論理的に独立しているという本発明の上記の表現は、両者の間に物理的分離が存在することを示唆するものと取られるべきではなく、実際には、同一の物理的下部構造が頻繁に共同使用される。更に、電話ネットワークに設定される搬送体経路がコンピュータ・ネットワークと同じ伝達媒体を共有するのみならず、そのような搬送体経路はコンピュータ・ネットワーク上のトラフィックのためのパイプの役を果たすこともある。電話ネットワークのユーザにとって一般的にアクセス可能なコンピュータ・ネットワークに関しては、電話ネットワークのすべてのユーザがそのようなアクセスを持つかまたはそのようなアクセスを取得することができると解釈されるべきではなく、むしろ、そのようなユーザの大部分がコンピュータ・ネットワークへのアクセスを持つかまたは取得することができることを意味すると理解されるべきである。意図するところは、搬送体ネットワークの管理または監視専用のコンピュータ・ネットワークを排除し、電話ネットワーク自体の一部をコンピュータ・ネットワークが効果的に形成することである。
例えば、１つのケースにおいて、電話ネットワークのユーザにとって一般的にアクセス可能で論理的にそれとは独立している別のコンピュータ・ネットワークはインターネットであり、電話ネットワークは、公共電話ネットワーク(すなわちＰＳＴＮまたはＰＬＭＮ)である。別のケースでは、電話ネットワークはＰＡＢＸを含むプライベート・システムであり、コンピュータ・ネットワークはイントラネットである。
好ましくは、ＵＲＩは、ＵＲＬおよびＵＲＮのいずれかまたは両者である。更に、サーバは、好ましくは、「ウェブ・ページ」上でユーザによって提供されるサービス資源を備えるＨＴＴＰサーバである。
【図面の簡単な説明】
下記の添付図面を参照しながら、制約を持たない例を用いて、以下に本発明の実施形態を記述する。
図１は、標準的ＰＳＴＮを単純化して示したブロック図である。
図２は、ＩＮサービス機能を持つ既知のＰＳＴＮを単純化して示したブロック図である。
図３は、ワールド・ワイド・ウェブの機能性を示すブロック図である。
図４は、標準的ＵＲＬ形式を示すブロック図である。
図５は、情報(コンテント)項目がＰＳＴＮのＩＰおよびウェブ・ユーザの両者によるアクセス可能なＨＴＴＰサーバ上に保持されている本発明の第１の実施形態を示すブロック図である。
図６は、コンテント項目の使用様態が相違する点を除いて、図５と同様の図である。
発明の実施形態
図５は、ＰＳＴＮのユーザがＷＷＷサーバ上で提供されるコンテント資源にアクセスすることができる本発明の第１の実施形態を示す。具体的に述べれば、ＰＳＴＮはＳＳＰ４１、ＳＣＰ４３およびＩＰを含む。明示の目的から、搬送体ネットワーク(図１および図２のアクセス・ネットワーク１１および相互交換ネットワーク１３)もＣＣＳネットワーク接続も、本明細書において後述される情報サービスに密接に関連する部分を除いて、図５に明示的に示されていない。図５のＰＳＴＮの表現は概要を示しているものと認められることであろう。
ＳＣＰ４３は既知の形態で動作し、ＳＳＰ４１からのサービス要求に応答して、サービス要求に含まれる情報に従って特定のデータに対して特定のＳＬＰを実行させ、呼び出し設定またはその他のサービス提供を実施する適切な命令を要求元ＳＳＰへ送り戻す。トリガー検査ポイントで合致されるあらかじめ定められたトリガー条件に応答してサービス要求がＳＳＰによって生成される。そのような検査ポイントは呼び出しを取り扱う過程の中で少なくとも１つである。
ＳＣＰ４３は、ＩＰ７０によって提供される資源を利用して特定のサービスを提供することができる。ＩＰ７０は、ＩＰに搬送体経路接続性を提供する搬送体ネットワーク・インタフェース７１、ＤＴＭＦ番号収集資源(資源１)およびＩＰにおいてローカルに保有される記録された通告を再生する音声通告中継装置(資源２)のような種々の資源７２、および、ＲＣＥＥを含みＣＣＳネットワークを経由してＳＬＰを実行しているＳＣＰ４３から受け取った信号メッセージに従って資源７２ならびにインタフェース７１を制御するように構成される制御機能７３を備える。(そのようなメッセージはＩＰに対して搬送体経路を設定する必要があるサービス要求を始動したＳＳＰを経由して一般的に送信される。)インタフェース７１は、該当する資源が正しい搬送体経路に接続されることを可能にする切り替え機能を含み、ＩＰは、ＩＰに向けられる複数の搬送体経路に並列的に複数の資源を提供することができるように設計される。
本実施形態に従って、ＩＰ７０は、また、ＳＣＰ４３からの要求の少くともいくつかを処理する過程において一定のコンテント項目４９を利用するため、インターネット５０に対するアクセス・インタフェース７４を備える。これらのコンテント項目４９は、インターネット５０に接続するＨＴＴＰサーバ５１上のＷＷＷページとして保持されるものである。これらのコンテント項目を含むＷＷＷページはＰＳＴＮを経由してアクセスされるように設計されているので、それらＷＷＷページを以下「電話」ページと呼称する。電話ページは、それぞれのＵＲＬまたはＵＲＮ(便宜上、電話ページの位置のインターネット解読可能識別子を意味するように以下では一層一般的用語ＵＲＩを使用する)を使用してインターネットを経由してアクセスすることができる。
コンテント項目は、必要な場合に行われるＩＰ７０における形式変換の後ＰＳＴＮ搬送体ネットワークを経由してエンド・ユーザへ利用できるように伝送されることができるいかなるタイプの情報でもよい。例えば、１つのコンテント項目は、ＩＰ７０へのコピーの後、搬送体経路への伝達のためＩＰのテキスト音声変換資源７２によって音声に変換されることができるテキスト・メッセージの形式を持つ。また、コンテント項目は、実質的変換を行うことなく、ＩＰ７０による(デジタル)搬送体経路への伝達のため、適当なＰ．Ｍ．形式がＩＰ７０によって使用されることが可能なデジタル化された音声ファイルの形式であることもできる。更に、コンテント項目の形式は、この場合もＩＰにおいて実質的変換を行う必要のないようなプログラムまたはその他のデータ・ファイルである場合もある。
各コンテント項目４９は、あらかじめ定められたコンテント・コードによってＰＳＴＮの世界にとって既知のものである。このコードは、一般的には、電話番号(呼び出し側または呼び出され側番号)の全部または一部から構成され、ユーザ入力選択情報または呼び出しポイント情報によって補完される場合もある。本実施形態においては、コンテント項目を取り出すことを望むＳＣＰ４３が、適切なコンテント・コードを決定してそれをＩＰ７０に渡す。次に、ＩＰ７０のインターネット・アクセス・インタフェース７４が、このコンテント・コードを使用して、対応するコンテント項目のＵＲＩを決定し、その後ＨＴＴＰ  ＧＥＴ要求を使用してそのコンテント項目を取り出す。コンテント・コードおよびそれに基づくＵＲＩの導出の詳細を以下に記述する。
図５は、コンテント項目アクセスの１つの簡単な例を示している。特定のコンテント項目(この場合ユーザＢの電話ページ４９上に保持されている項目)にアクセスすることを望むＰＳＴＮユーザは、(典型的には１２キー押しボタン・パッドである)電話キーパッドを使用して対応する電話番号、例えば″３３３ １２３４５６７″をダイヤルするだけでよい。この例では、電話番号の最初の部分″３３３″は、実際には、コンテント項目検索要求の特性としてＰＳＴＮ操作員によってあらかじめ指定されているサービス指定子である。電話番号の２番目の部分″１２３４５６７″は、所望の項目に関する実際のコンテント・コードである。コンテント項目の性質に関しては、この場合、ＩＰ７０の資源７２(資源３)によって音声に変換されることができるテキスト・ストリングであるとみなす。
このコンテント項目のための情報検索サービスは次のように機能する。
[1]--ユーザが電話４０で電話番号″３３３ １２３４５６７″をダイヤルすると、接続されているＳＳＰが、先頭ストリング″３３３″を情報検索サービスが要求されていることを示すものと認識して、ダイヤルされた残りの番号すなわち″１２３４５６７″と共に該当するサービス要求をＳＣＰ４３へ送る。
[2]--ＳＣＰ４３は、要求されたサービスに対応するＳＬＰのインスタンスを実行して、コンテント・コード″１２３４５６７″によって識別されるコンテントの検索および送達を求める要求をＳＳＰ４１を経由してＩＰ７０へ送る。
[3]--制御機能７３は、要求されたコンテント項目を取り出すようにインターネット・アクセス・インタフェース７４に要求する。インタフェース４６は、先ず、供給されたコンテント・コードに基づいてコンテント項目のＵＲＩを決定し、次に、インターネット５０を経由して、該当するＨＴＴＰサーバ５１へＧＥＴ要求を送信する。
[4]--識別された電話４９ページ上に保持されているコンテント項目がサーバ５１からインターネットを経由してアクセス・インタフェース７４へ返され、そこで一時的に記憶される。
[5]--取り出されたコンテント項目がインタフェース７４において完全に受け取られると、制御機能７３は、コンテント項目をテキスト音声資源７２に渡し、ＳＳＰ４１からＩＰ７０へ設定された適切な搬送体経路へこの資源の出力を搬送体ネットワーク・インタフェース７１が送信するように制御する。その後、コンテント項目は搬送体回路６０を経由して電話４０に音声として伝達される。コンテント項目の再生が完了すると、ＩＰ７０の制御機能７３はその信号をＳＣＰ４３および対応するＳＬＰに送信し、制御を元に戻す(これは単に呼び出し終了の始動を伴うか、または、例えばユーザにコンテント項目の再生の選択を与えるものであるかもしれない)。
特定のコンテント項目の伝達のためのＩＰ７０の該当する資源７２の選択は、種々な方法で実施することが可能である。例えば、各コンテント項目に関して必要とされる資源７２は、制御機能７３によってアクセス可能なデータベースに保持することができるであろう。あるいは、別の形態として、異なる形式のコンテント項目に関して異なる初期指定子ストリングを使用して、ＳＣＰが当該コンテント項目に関してどの資源７２を使用すべきか制御機能７３に指示を与えることもできるであろう。しかしながら、本発明の好ましい構成においては、コンテント・タイプ・インジケータ(コンテント項目の種類を示すインジケータ)をコンテント項目に関連づけ(例えば適切なＭＩＭＥタイプ)、次に、制御７３がコンテント・タイプ・インジケータに従って送達資源を選択する。
当然のことながら、ＧＥＴ要求[3]に回答が直ちに返されない可能性はあり、従って、制御機能７３は、タイム・アウト期間を設定することによってそのような遅延に対応する用意をしなければならない。その期間内に回答を受け取らなければ、制御７３は、あらかじめ定められた「項目使用不可」通告を行うか、または、ＳＣＰ４１上で実行中の制御ＳＬＰへ問題を報告する。いずれにせよ次に取るべき措置を決定するのはＳＬＰの責任である。
図５の実施形態において、対応するコンテント・コードから所望のコンテント項目のＵＲＩを導出する責任があるのはＩＰ７０のインターネット・アクセス・インタフェースであるけれども、ＳＣＰ４３がＵＲＩ決定を実行するように構成することも可能である。この場合、ＳＣＰ４３はＩＰ７０にそのコンテント・コードではなく所望のコンテント項目のＵＲＩを渡す。
このように、図５の構成は、ＰＳＴＮユーザが単に適切な番号をダイヤルすることによってＷＷＷサーバ５１上に記憶されている情報(コンテント)項目にアクセスすることを可能にする。各々がそれぞれのコンテント・コードに関連づけらた情報項目のすべての範囲がこのような形態で利用できるようにすることができるであろう。情報を利用可能とすることを必要とするすべての情報提供者は、情報をＷＷＷサーバ上に置き、対応するＵＲＩへのコードの割り当てを行うようにＰＳＴＮ操作員に要求しなければならない。
可能なバリエーションは、コンテント・コードを呼び出し側番号によって設定されるようにするものである。この場合、ＰＳＴＮ操作員の設定するサービスに従って、例えば、ダイヤルされた番号″３３４″に従って、自動的に呼び出し側番号を取りあげ、それをコンテント・コードとして使用してユーザが望む特定の情報を探索する。例えば、ユーザは特定の主題に対して毎日更新することを望むとすると、ユーザは、情報提供者にあらかじめ定められたＵＲＩにおけるＷＷＷサーバ上に毎日更新された情報を置くことを要求する。次に、ユーザは、ＰＳＴＮ操作員がユーザの呼び出し番号をコンテント・コードとして取り扱ってそれをそのＵＲＩに対応づけることを認める。その後、ユーザが番号″３３４″をダイヤルすると、その呼び出し側番号が、所望の情報のＵＲＩに自動的に対応づけられ、それに基づいてＩＰ７０によって所望の情報が取り出され送達される。ユーザがいくつかの情報ソースのどれかを選択することを可能にするため、呼び出し側番号に(例えば０から９の)選択コードを加えたサービス指定子を使用してコンテント・コードを定義することもできる。この場合、そのようなコードの各々は異なるコンテントに対応する異なるＵＲＩに対応する。
図５の構成および前述のバリエーションに関する限り、所望のコンテント項目の検索は、項目の直接の依頼人であるユーザに提供されているサービスを構成する。図６は、図５と同じ下部構造ではあるが、ＨＴＴＰサーバ５１上に記憶されるコンテント項目の使用様態が異なる。図６の例においては、特定のコンテント項目は、もう１つ別のサービスすなわち呼び出され側サービスの一部として検索されユーザに送達される(このような異なる使用様態を示すため呼び出し側サービスもまた選択することが可能である)。
図６を参照して詳細を以下記述する。ユーザＢは、ユーザＢの電話が接続された場合、その電話４９ページ上に、呼び出し側(この場合ユーザＡ)に再生されるべきメッセージ(コンテント項目)を指定する。このメッセージの再生は、適切なトリガー検査ポイントにおいてＢのＳＳＰ４１で始動される。次に″個人化された接続メッセージ″サービスが起動され、次のように機能する。
[1]--呼び出され側番号(Ｂの電話番号)と共にサービス要求がＳＳＰ４１からＳＣＰ４３へ渡される。
[2]--ＳＣＰ４３はサービス要求に対応するＳＬＰのインスタンスを実行し、その結果、Ｂの電話番号に対応するコンテント・コードによって識別されるコンテント項目の検索および送達に関する要求が適切な呼び出しポイントのインジケータ(呼び出しポイントを示すインジケータ)と共にＳＳＰ４１を経由してＩＰ７０へ送られる(このようにして、Ｂは呼び出し設定／切断の間の異なる事象に関する異なるコンテント項目を定義することができる。各項目はそれ自身のコードを持ち異なるＵＲＩに保持されている)。
[3]--制御機能７３がインターネット・アクセス・インタフェース７４に所望のコンテント項目を取り出すように要求する。インタフェース４６は、先ず、供給されたコンテント・コードに基づいてコンテント項目のＵＲＩを決定し、次に、インターネット５０を経由して該当するＨＴＴＰサーバ５１へ要求を送信する。
[4]--識別された電話ページ４９上に保持されるコンテント項目は、一時的記憶のためインターネットを経由してサーバ５１からアクセス・インタフェース７４へ返される。
[5]--取り出されたコンテント項目がインタフェース７４において完全に受け取られると、制御機能７３は、コンテント項目をテキスト音声資源７２(資源３)に渡し、ＳＳＰ４１からＩＰ７０へ設定された適切な搬送体経路へこの資源の出力を搬送体ネットワーク・インタフェース７１が送信するように制御する。その後、コンテント項目は搬送体回路６０を経由してユーザＡの電話４０に音声として伝達される。コンテント項目の再生が完了すると、ＩＰ７０の制御機能７３はその信号をＳＣＰ４３および対応するＳＬＰに送信し、制御を元に戻す(これは単に呼び出し終了の始動を伴うか、または、例えばユーザＡにＢの音声メールへの切り替えの選択を与えるものであるかもしれない)。
注意すべき点であるが、図６の例において、取り出されたコンテント項目が実際に送達されるのは、この項目の送達を指定した側ではない。
コンテント項目の位置特定およびそれへのアクセス
上述のように、コンテント・コードを渡す時所望のコンテント項目にアクセスするのはインターネット・アクセス・インタフェース７４の機能である。これを実行するため、インタフェース７４はＵＲＩ決定ブロック７５の能力を利用することによってコンテント・コードに基づいて対応するＵＲＩを決定する。ブロック７５がどのように正しいＵＲＩを決定するかを記述する前に、コンテント・コードの詳細を記述する。
コンテント・コード−上述の記載から明らかなように、コンテント・コードは、一般的には、ダイヤルされた番号または呼び出し側番号の全部または一部によって構成され、場合によっては更なるユーザ入力選択桁または呼び出しポイント・データによって補完される。更に、一般的には、インターネット経由のアクセスのためコンテント項目を提供する側が、複数のコンテント項目を指定することを望む場合があることは理解されるであろう。そのような項目の各々はそれ自身のコンテント・コードによって定義されることができなければならないが、対応するコンテント・コードから導出できるユニークなＵＲＩによってアクセス可能なそれ自身の電話ページ上に各項目を保持するのではなく、対応するコンテント・コードの共通の部分から導出できるページのＵＲＩと同じページ上にいくつかのコンテント項目を保持する方が一層実用的であろう。この場合、各コードは、同じページ上のいくつかの項目の間で所望の項目を識別することができるように更なる部分を含むであろう。以下の記述において、共通のコード部分をＵＲＩ識別子(ＵＩ)と呼称し、更なる部分を相対的項目識別子(ＲＩＩ)と呼称する。
典型的には、コンテント・コードが電話ページ上のいくつかの項目の中の１つの項目を参照する場合、コンテント・コードのＵＩ部分は、(通常サービス指定子を除いて)、呼び出し側また呼び出され側によって形成されるが、一方、ＲＩＩ部分は、ユーザ入力選択桁または呼び出しポイント識別子によって形成される。
ただ１つのコンテント項目が電話ページ上に記憶されている場合は、対応するコンテント・コードはＵＩ部分だけを含むものと見なされる。
コンテント・アクセス−ＵＲＩ決定ブロック７５が対応するコンテント・コードのＵＩ部分から所望の項目のＵＲＩを決定する。コンテント・コードがＲＩＩ部分を含むならば、コードのＵＩ部分に対応するＵＲＩによって識別される電話ページから所望の項目を選択する２つの可能性が存在する。第１は、ＵＲＩコード部分が該当するＨＴＴＰサーバ５１に渡され、ＨＴＴＰサーバ５１が、正しいコンテント項目を抽出しアクセス・インタフェース７０にそれを返す責任を持つ。第２は、アクセス・インタフェース７４が関連した電話ページすべてを要求し、受け取り、正しいコンテント項目を抽出する。
コンテント・コードに基づくＵＲＩ決定−ＵＲＩ決定ブロック７５の実施形態を次に記述する。ブロック７５の実施形態には次の４つの形態がある。
直接入力
必ずしも便利ではないが、呼び出し側が所望のＵＲＩを直接入力するように構成することは可能である。この場合、呼び出し側は、(ホスト・ドメイン名またはホストＩＰアドレスの形式のいずれかである)所望のＵＲＩのホストＩＤコンポーネントおよびＵＲＩの経路コンポーネントを入力する。例えば、呼び出される側の電話ページがアクセスされるべきものである場合、呼び出し側は呼び出される側のＵＲＩを入力するかもしれないが、この入力が実際に通常の電話番号入力であることもある。ＵＲＩとしての入力であることを識別するため、(例えば'９９９'のような)ストリングを先頭に入力することもできる。入力手段に関する限り、ユーザが標準の１２キー電話だけを持っている場合、アルファベット文字を必要とするホスト・ドメイン名およびその他のＵＲＩエレメントは、電話パッドから入力されるアルファベット文字に関する標準的技術の１つの使用を必要とする(そのような技術は、例えば呼び出し側が呼び出され側の名前の綴りを入力することを可能にするため既に使用されている)。ＵＲＩ入力を容易にするためユーザにすべての英数字キーを含むキーパッドを提供することも可能である。
計算
インターネット上でのコンテント項目アクセスは、あらかじめ定められた機能に従って対応するＵＲＩを計算できる元となるダイヤル番号セットに制約される可能性がある。この場合、この計算はブロック７５の責任である。
関連テーブル照合
ブロック７５に関する最も単純な実施形態は、ＵＲＩを各コンテント・コードのＵＩ部分に関連づける(メモリまたはデータベース・ディスク記憶装置のいずれかの形での)関連テーブルである。
ＤＮＳタイプ照合
資源コードのＵＩ部分を対応するＵＲＩに変換するための代替的照合方法は、インターネットのドメイン名システム(ＤＮＳ)に対するものと同様な、階層構造分散データベース・システムを使用することである。詳細は後述するが、このアプローチは、典型的には、ＵＲＩに関連づけられる番号に関して各ＰＳＴＮ操作員によって維持されるデータベースを必要とする。これらデータベースは、ＤＮＳの場合と同様に該当するデータベースに向けられる変換要求を用いてインターネットのようなネットワークを経由してすべてのＰＳＴＮによってアクセスできる。この場合、ブロック７５は、インタフェース７４を経由してインターネット上でＵＩ変換を要求するように設計される適切な変換プログラムによって構成される。そのようなシステムの更に一層の詳細は、本発明の出願人と同じ出願人による下記国際特許出願に記載されており、参照によりここに取り入れる。
PCT/GB96/03008出願日1996年12月11日
″Method of providing telecommunication services″
PCT/CB96/03009出願日1996年12月11日
″Call setup gateway for telecommunications system″
PCT/GB96/03051出願日1996年12月11日
″Method of providing telecommunication services″
PCT/GB96/03054出願日1996年12月11日
″Method of accessing a target entity over a communications network″
PCT/GB96/03055出願日1996年12月11日
″Method of. accessing service resource items that are for use in a telecommunications system″
コンテント項目の作成
次に、サーバ５１に対するコンテント項目４９がいかに作成されその後更新されるかを記述する。
作成に関する限り、２つの基本的アクションが必要である。すなわち、第１に、コンテント項目がサーバ５１上に配置されなければならず、第２に、コンテント・コード(すなわち番号プラス呼び出しポイントのような条件または複数コンテント項目が提供される場合はそれらのＲＩＩ値)とともにコンテント項目のＵＲＩがＰＳＴＮ操作員へ通知されなければならない。この通知プロセスは、ＰＳＴＮ操作員に対するコンテント項目の「登録」と呼ばれる。当然のことながら、操作員がネットワーク・エンティティをプログラムすることができるようにすることが必要である。一定のサービスに関しては、登録プロセスの一部としてコンテント・コードを指定するのはユーザではなくＰＳＴＮ操作員である。
サーバ５１上にサービス資源を配置するプロセスに関する限り、その実行方法は、そのようなコンテント項目のＰＳＴＮ動作に及ぼす可能な効果に対するＰＳＴＮ操作員の態度に依存する。
操作員がコンテント項目の実施形態または特性に関心を持たないと当面仮定するとすれば、資源がサーバ５１上に配置される方法は主としてサーバの特性に依存する。例えば、ユーザがインターネットへのネットワーク・アクセスのあるコンピュータを持ち、このコンピュータがサーバ５１として使用されるとすれば、ユーザは外部アクセスのためのＷＷＷ電話ページとしてサーバ上に所望の資源を単にロードすることができる。サーバが内部のＬＡＮ上でのアクセスを持つ組織サーバである場合同様の状況が起きる。これら２つの場合、ＷＷＷ電話ページとして資源をロードすること自体はインターネット・アクセスを必要としない。しかしながら、サーバ５１が外部のインターネット・サービス・プロバイダによって実行されるとすれば、ユーザは、サーバ上でユーザに割り当てられたウェブサイト空間に所望のコンテント項目をダウンロードするように取り計らうことができる。これは、インターネット・アクセスを含むことも含まないこともできる。この後者のシナリオの１つの特別なケースは、ＰＳＴＮ操作員がコンテント項目を保持するユーザ電話ページに対して特別なサーバを提供する場合である。
ユーザ自身のコンピュータがサーバ５１の役をする場合を除いて、サーバ上にコンテント項目を配置することは、一般的には、１つまたは複数のパスワード保護のレベルを消去することを伴う。
ＰＳＴＮ操作員がＰＳＴＮの動作に対する悪影響を避けるためコンテント項目４９を支配することを望むとすれば、２つのアプローチが可能である。第１に、あらゆる項目(またはおそらく特定のサブセット)が使用の前に検証プロセスに従わなければならないことを操作員が要求することが可能であり、(特定のデータ項目を除いて)ユーザによる資源の将来の変更を回避する適切な基準が設けられる。これに関して、操作員は、(特定のデータ項目を除いて)資源が操作員の制御の下におかれること、そしてユーザはそのコンテント項目に対する書き込みアクセス権を持たないことを求めることができる。第２に、更に魅力的であるが、コンテント項目４９による悪影響を最小にするアプローチは、ユーザがユーザ自身のデータを追加することができる(また資源がサービス論理を含む場合制約された機能選択を行う)標準的コンテント項目を操作員が提供するものである。その後、特別仕様のコンテント項目が操作員によって制御されるサーバ５１にロードされる。操作員に制御されたサーバからユーザがＷＷＷ上でダウンロードすることができるＨＴＭＬ形式を使用する特定の資源に関してこのプロセスの実施は都合がよい。形式を完成しその形式の「コミット(提示)」ボタンを活動状態にさせると、入力された情報がサーバへ送られ、そこで、その情報を使用して、特別仕様コンテント項目が作成され、インターネット経由のアクセスに備えてそのサーバ上に配置される。このアプローチの利点は、操作員によるコンテント項目の登録が同時に実施される点である。(コンテント項目をサーバにロードさせる動作と別個に登録が行われなければなら場合、ＨＴＭＬ形式の使用は登録プロセスを実施する非常に便利な方法であるという点に留意する必要がある)。
上記の点から明らかなように、作成プロセスは情報がインターネット上で渡されることを必ずしも必要としないが、多くの場合、特に、ＷＷＷ上で交換されるＨＴＭＬ形式が特別仕様のコンテント項目を作成するために使用されることができる場合には、それは最良の解決策である。ＨＴＭＬ形式を使用して特別仕様のコンテント項目を作成することはＰＳＴＮ操作員がサーバを制御する場合に限られない点に留意する必要がある。
バリエーション
当然のことながら、上記の実施形態には多数のバリエーションが存在する。そのようなバリエーションのいくつかを以下に記述する。
本発明の上記実施形態は、ユーザへ電話を経由して送達するためインターネット・サーバ(必ずしもではないが好ましくはＨＴＴＰサーバ)からの情報(コンテント)項目の検索に焦点をあてたけれども、情報項目の流れは、反対方向でもすなわち電話(またはその他のＣＰＥ)からインターネット・サーバへという方向でも同様に可能である。この後者のケースでは、サーバはアップロードされたコンテント項目を受け取り、記憶するか、またはそれをなんらかの方法で処理するかもしれない。このように、サーバはコンテント受け手であるとみなされることができる。同様の用語の使い方ではあるが、サーバがコンテント項目を電話ネットワークに送達する時、それはコンテント″ソース″とみなされることができる。両方のケースで、サーバは、電話ユーザにとってアクセス可能な″資源″である。コンテント項目がＣＰＥの項目からインターネット・サーバへ渡されている時、ＩＰ７０の役割は、先ず、ＣＰＥから供給されているコンテント項目を記憶し、次に、ユーザが対応するコンテント・コードによって識別したコンテント受け手にインターネットを経由してこの項目を(おそらくその形式を変えた後に)送達することである点は理解されるであろう。注意すべき点であるが、このような一層一般的方式においては、コンテント・コードは、特定のコンテント項目というよりはむしろコンテント・ソースおよび受け手を識別するものとして見なされることができる。
コンテント項目のコンテント受け手への送信は(図５におけるコンテンント・ソースからの項目の取り出しの状況と同様に)それ自身サービスの実施を含むこともある。別の形態として、コンテント項目のコンテント受け手への送信は、(図６のケースと同様に)一層大きい呼び出し側／呼び出され側サービスの一部であるようにすることもできる。例えば、図６のステップ[5]に続いて、ユーザＡはユーザＢに対するメッセージを残すこともできる。このメッセージはコンテント項目とみなされ、Ｂがアクセスを持つサーバ５１上の記憶のためインターネットを経由して送信される。
上述の実施形態におけるＳＣＰの役割は、補助機能(ＡＤＪ)またはサービス・ノードＳＮのようないかなる適切なサービス制御エンティティによっても実行されることができる点は認められるであろう。この後者のケースでは、ＩＰ７０は好ましくはＳＮにおいて提供されるＩＰ機能である。
上述された実施形態において、サービス識別のプロセスは呼び出し設定／切断の間に行われ、ＰＳＴＮ(特にＳＣＰ４３およびＩＰ７０)がサービスの実施に責任を持っていた。これに代わる可能性として、ＰＳＴＮが、ＰＳＴＮに対して外部にあるがそれに接続しているＳＰ機器へのユーザ電話からの呼び出しを単に設定するという受動的役割を演ずるようにすることもできる。このＩＳＰ機器はインターネットへの接続性を持つ。この場合、ＩＳＰ機器への初期呼び出しの後、電話ユーザは、所望のコンテント資源のコンテント・コードをダイヤル入力する。そこで、ＩＳＰ機器は、入力コードからコンテント資源のＵＲＩを導出し、ＩＰ７０に関して上述した方法でその資源にアクセスするように処理を進める。
「インターネット」という用語は、インターネットおよび現在のアドレス指定方式のために使用されているＴＣＰ／ＩＰプロトコルの現在時点の仕様のみならず、等時性媒体を取り扱うために必要とされるような発展機能をも含むものと理解されるべきである。更に、ＷＷＷおよびＨＴＴＰプロトコルの参照も、同様に、それらの将来発展したものをも含むものと理解されるべきである。
本発明は、ＰＳＴＮ以外の電話システム、例えば、ＰＬＭＮやその他の移動体ネットワーク、およびＰＡＢＸを使用するプライベート・システムにも適用することができる。プライベート・システムの場合、ＰＡＢＸと同じ内部ユーザに機能を一般的に提供するＬＡＮまたは構内型コンピュータ・ネットワークが上述の実施形態におけるインターネットの役割を果たすであろう。
【図１】
0003773061.tif 000002
【図２】
0003773061.tif 000003
【図３】
0003773061.tif 000004
【図４】
0003773061.tif 000005
【図５】
0003773061.tif 000006
【図６】
0003773061.tif 000007