JP2002514330A - Internet-based subscriber profile management for communication systems - Google Patents

Internet-based subscriber profile management for communication systems

Info

Publication number
JP2002514330A
JP2002514330A JP55052898A JP55052898A JP2002514330A JP 2002514330 A JP2002514330 A JP 2002514330A JP 55052898 A JP55052898 A JP 55052898A JP 55052898 A JP55052898 A JP 55052898A JP 2002514330 A JP2002514330 A JP 2002514330A
Authority
JP
Japan
Prior art keywords
subscriber
receiving
data
token
providing
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.)
Pending
Application number
JP55052898A
Other languages
Japanese (ja)
Inventor
アレン ミラー，ジェームズ
エス ヴァイディヤ，ラムチャンドラ
Original Assignee
エムシーアイ ワールドコム インコーポレーテッド
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US08/862,134 external-priority patent/US6587867B1/en
Application filed by エムシーアイ ワールドコム インコーポレーテッド filed Critical エムシーアイ ワールドコム インコーポレーテッド
Publication of JP2002514330A publication Critical patent/JP2002514330A/en
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2854—Wide area networks, e.g. public data networks
    • H04L12/2856—Access arrangements, e.g. Internet access
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/101—Access control lists [ACL]
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q11/00—Selecting arrangements for multiplex systems
    • H04Q11/04—Selecting arrangements for multiplex systems for time-division multiplexing
    • H04Q11/0428—Integrated services digital network, i.e. systems for transmission of different types of digitised signals, e.g. speech, data, telecentral, television signals
    • H04Q11/0435—Details
    • 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/0033—Provisions for intelligent networking customer-controlled
    • 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Telephonic Communication Services (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

(57)【要約】 電気通信システムは、多種多様なサービスを含む。例えば、そのシステムは、加入者のためのただ一つの番号による多種多様な通信サービスを提供する。加入者は、インターネットを介して、サービスもしくは当該加入者特有のサービスを記述した加入者プロフィールにアクセスすることにより、それらのサービスを容易に、コンフィギュレーションし、管理し、および、アップデートすることができる。加入者プロフィールは、加入者の電話番号を呼び出す個々の人々に対し、当該加入者がどの通信サービスの提供を望むかを特定する。前記システムは、加入者プロフィールへのワールド・ワイド・ウェブのアクセス方法を提供する。前記システムは、システムにセキュリティを確保するセキュリティ安全装置を含む。 (57) [Summary] Telecommunications systems include a wide variety of services. For example, the system provides a wide variety of communication services with a single number for the subscriber. Subscribers can easily configure, manage, and update their services by accessing, via the Internet, a service or a subscriber profile that describes the services specific to the subscriber. . The subscriber profile specifies to each individual who calls the subscriber's telephone number which communication service the subscriber wishes to provide. The system provides a method for accessing the World Wide Web to a subscriber profile. The system includes a security device that secures the system.

Description

【発明の詳細な説明】 通信システムのインターネット−ベースの加入者プロフィール管理 技術分野 本発明は、広く通信システムに関し、より詳細には多種多様な通信サービスに アクセスするただ一つの電話番号をもつシステムのような電気通信システムを管 理することに関する。 発明の背景 在来の電気通信システムにおいては、多くの異なる電気通信サービスが加入者 に提供されている。それぞれの電気通信サービスは、一般に独自の電話番号を必 要とする。独自の電話番号を必要とする電気通信サービスの例としては、自動ル ーティングサービス、ボイスメールサービス、ファクシミリサービス、ページン グサービス、セルラー電話サービス、パーソナル８００番がある。別個の電話番 号を必要とする各サービスの欠点の一つは、種々の電話番号を管理及び拡布する ことが、種々の通信サービスを利用する加入者にとって非常に厄介になる場合が あることである。例えば、加入者は、ファクシミリサービスのためには第１の電 話番号を、ボイスメールサービスのためには第２の電話番号を、セルラーサービ スのためには第３の電話番号を備えなければならないことになる。このため、加 入者は、それらの独自の電話番号をすべて覚えていなければならず、かつ、自分 の電話番号に電話をかける人々に対しては、どのサービスがどの電話番号と関連 しているのかを明らかにしなければならない。しばしば、関係者は、複数のサー ビスへの電話番号のマッピングを混同するとともに、その関係者に教えられた電 話番号をダイヤルして誤ったサービスを受けることになってしまう。例えば、発 呼者がある人に電話連絡をしようと思いながらある番号をダイヤルしても、その 発呼者は代わりにファクシミリ機につながることがある。 在来のシステムの他の欠点は、加入者に供給される電気通信サービスに関する 融通性の欠如である。加入者は、様々な時に別々の人に対して異なるサービスへ のアクセスを準備しておかなければならないことがある。例えば、加入者は、週 の労働期間中には電話の呼がその加入者の仕事場へ向けられるようにしておかな ければならないが、週末には電話の呼が自分の家もしくはセルラー電話へ向けら れるようにしておかなければならないことになる。その加入者はまた、その週末 に電話で自分と連絡することのできる人を制限することを望む場合もある。その 上さらに、その加入者は、自分のボイスメールへ他の人々にアクセスさせること を望む場合もあり得る。 あいにく在来のシステムによっては、電気通信サービスのかかる適合性は得ら れない。さらに、加入者は、各サービスが異なる番号をもっ場合、多数の通信サ ービスを管理することが困難になる。例えば、加入者がそのサービス（例えばボ イスメール）の様々なメニューを電話によってアップデートすることを望むので あれば、種々の反復されるメニューの選択と提示とが必要である。 米国特許Ｎｏ．５，３７５，１６１は、ただ一つの電話番号を用いて加入者に 多数のサービスを提供する電話システムを開示している。その加入者は、多数の ボイスメニューと、押ボタンもしくはデュアルトーン多重周波数（ＤＴＭＦ(dua l-tone multi-frequency)）の入力とにより、自身の電話サービスのコンフィギ ュレーションをすることができる。その加入者は、選択した電話サービスをコン フィギュレーションすることができるとともに、そのコンフィギュレーションを メモリに記憶させることができる。あいにくこの特許に基づくシステムは、加入 者のメモリをプログラムする間、反復される種々のメニューの選択を相互作用す る必要性から悪影響を受ける。加えて、加入者は、それぞれのメモリと自身の電 話サービスを速隔操作でプログラムするそのメモリの内容とに関連付けられた番 号をリコールしなければならない。 発明の概要 本発明の特徴は、ここに詳細に述べるように、従来の電気通信システムの問題 を克服し、かつ、さらなる追加の利益を提供する。本発明の最良の実施形態のも とでは、電気通信システムは、一人の加入者に対してはただ一つの番号に関連付 けられた多数の通信サービスを提供する。その加入者は、インターネットのよう なネットワークを通じて、それらのサービスをコンフィギュレーションし、管理 し、かつ、アップデートすることを容易に行うことができる。加入者は、サービ ス、または、当該加入者特有のサービスを詳述する加入者プロフィールに、イン ターネットによってアクセスすることができる。加入者は、スクリーン上に同時 に表示されるいくつかの選択対象の一つを選ぶことにより、当該加入者が再コン フィギュレーションすることを望む特定のサービスを迅速に識別することができ る。そのようなスクリーン上に多数同時に提示されるオプションの選択は、加入 者がオーディオベースのメニューにおける音声メッセージの一連の流れを聞くこ とを必要とする場合よりも、極めて迅速である。 従来の問題は、従来のシステムに多数のパーソナルＩＤ（ＰＩＮ(personal id entification)）もしくは他のコードの入力を試行することにより、従来の電気 通信サービスへ自動的にアクセスすることを、しようと思えばできたということ である。最良の実施形態は、そのようにはせずに、従来のシステムを越えて高め られたセキュリティを提供する。例えば、その模範的実施形態のもとで加入者が 初めにウェブサーバへアクセスするときには、“トークン”は当該加入者のセッ ションと関連付けられる。加入者のトークンは、その加入者のパスワードおよび インターネットアドレスに部分的に基づいて確認もしくは認証される。 本発明は、インターネットに接続された通信システムにおいて用いるコンピュ ータ実行方法（a computer-implemented method）を構成する。その方法は、(a) インターネットを介して、システムとの関係を示す加入者特有の記録にアクセス するための要求を受信するステップと、(b)インターネットを介して、前記記録 に代わる代替データを受信するステップと、(c)受信された代替データに基づい て前記記録をアップデートするステップとを具備している。 本発明はまた、電気通信ネットワークにおける装置をも構成する。その装置は 、メモリとネットワークサーバとを有する。前記メモリは、システムとの関係を 示す加入者特有の記録を記憶する。前記ネットワークサーバは、前記メモリとイ ンターネットとの間に接続される。前記ネットワークサーバは、(a)インターネ ットを介して前記記録のためのアクセス要求を受信し、(b)インターネットを介 して、前記記録に代わる代替データを受信し、および、(c)受信された代替デー タに基 づいて前記メモリにおける前記記録の改変を要求する。 図面の簡単な説明 本発明の模範的な実施形態は、以下に、次の図面に関してより詳細に説明され る。 図１Ａは、本発明の最良な実施形態を実践するのに好適な第１のシステムコン フィギュレーションを示すブロックダイヤグラムである。 図１Ｂは、本発明の最良な実施形態を実践するのに好適な第２のシステムコン フィギュレーションを示すブロックダイヤグラムである。 図２は、図１Ａおよび１Ｂのシステムの部分の詳細を示すブロックダイヤグラ ムである。 図３は、加入者の開始もしくはログインのプロセスを例示したデータもしくは メッセージのフローダイヤグラムである。 図４Ａ、４Ｂおよび４Ｃは、図３のログインプロセスの間に、それぞれ、図２ のウェブブラウザ、ウェブサーバおよびトークンサーバによって実行されるステ ップを示すフローダイヤグラムである。 図５は、代表的な加入者のログインのスクリーンを示すコンピュータのスクリ ーンの正面図である。 図６は、代表的なサービス選択のスクリーンを示すコンピュータのスクリーン の正面図である。 図７は、代表的なログインの失敗のスクリーンを示すコンピュータのスクリー ンの正面図である。 図８は、サービス選択プロセスを例示したデータもしくはメッセージのフロー ダイヤグラムである。 図９Ａ−９Ｃは、図８のサービス選択プロセスの間に、それぞれ、図２のウェ ブブラウザ、ウェブサーバおよびトークンサーバによって実行されるステップを 示すフローダイヤグラムである。 図１０は、代表的な呼のルーティング・オプションのスクリーンを示すコンピ ュータのスクリーンの正面図である。 図１１は、代表的なゲスト・メニュー・オプションのスクリーンを示すコンピ ュータのスクリーンの正面図である。 図１２は、代表的なオーバーライド・ルーティング・オプションのスクリーン を示すコンピュータのスクリーンの正面図である。 図１３は、代表的なスビードダイヤル番号の選択スクリーンを示すコンピュー タのスクリーンの正面図である。 図１４は、代表的なボイスメール・オプションのスクリーンを示すコンピュー タのスクリーンの正面図である。 図１５は、代表的なファックスメール・オプションのスクリーンを示すコンピ ュータのスクリーンの正面図である。 図１６は、代表的な呼のスクリーニング・オプションのスクリーンを示すコン ピュータのスクリーンの正面図である。 図１７は、代表的なエラーのスクリーンを示すコンピュータのスクリーンの正 面図である。 図１８は、代表的な最後のスクリーンを示すコンピュータのスクリーンの正面 図である。 図１９は、代表的なスクリーンレイアウトの概略的なダイヤグラムである。 図２０は、図２のシステム部分のもとでのトークンに関するデータフローを含 む代表的なデータのフローダイヤグラムである。 図２１は、その中に代表的なフィールドをもつ代表的な加入者プロフィールで ある。 図２２は、トークンの代表的なデータ構造である。 図２３は、図２のウェブサーバによって利用される代表的なディレクトリ構造 である。 発明の詳細な説明 Ｉ．概要 従来技術の問題を克服するシステムは、発明の名称を“Single Telephone Num ber Access to Multiple Communications Services”とする出願と、共に同時に 出願され、かつ、本願の譲受人に譲渡されて同様に係属中の米国特許出願におい て、詳細に開示されている。この出願に開示されているように、プラットフォー ムは、多種多様な電気通信サービスをただ一つの電話番号によってアクセス可能 にすることができるようにする。これにより、例えば、ページングサービス、フ ァクシミリサービス、ルーティングサービス、ボイスメールサービス、コーリン グカードサービス、および、パーソナル８００番サービスへのアクセスは、ただ 一つの電話番号によって達成されることになる。加入者は、これらのサービスへ のアクセスを完全に支配する。特に、加入者は、どのような人々に対して、どの ようなときに、どのようなサービスが利用可能かを特定することができる。した がって、その加入者が加入するサービスの第１番目のサブセットは、１度目に第 １番目の関係者に利用可能となり、かつ、サービスの第２番目のサブセットは、 ２度目に第２番目の関係者に利用可能となる。さらに、ただ一人の関係者が、何 時であるかによって異なるサービスのサブセットへアクセスしてもよい。本発明 の模範的な実施形態のプラットフォームはまた、同じ電話番号を使用してあらゆ る場所から多種多様な呼（multiple calls）をかけるとともにすべての呼をただ 一つのアカウントに料金請求するシステムも加入者に提供する。 加入者は、料金無料の８００番あるいは８８８番のようなただ一つの電話番号 を割り当てられる。この一つの電話番号は、他の関係者（“ゲスト”）によって 使用されて、加入者によりプログラムされたどの呼出先の電話番号でも、その加 入者に到達する。加えて、その一つの電話番号は、その加入者へファックスを送 るため、その加入者のためにボイスメール・メッセージを残すため、あるいは、 その加入者をページングするために、使用されることになる。その加入者はまた 、当該加入者の前記一つの電話番号にかけられた呼が多種多様な場所で当該加入 者に届くように、ルーティングをプログラムすることもできる。また、上述した ように、それぞれの発呼者が多種多様なサービスに達することもできる。一例と しては、ある一定の発呼者からの呼が自動的にページを発生し、発行させ、ある いは、自動的にボイスメール内へかけられるようにすることとしてもよい。 加入者は、多種多様なパーソナルＩＤ番号（ＰＩＮｓ(personal identificati on numbers)）を割り当てられる。それぞれのＰＩＮには、英数字文字の短いシ ーケンスである。それぞれのＰＩＮは、異なるサービス・コンフィギュレーショ ンが設けられる。ＰＩＮｓのうちの一つは、ただその加入者による使用に割り当 てられる。そして、当該加入者が自身の割り当てられた電話番号を呼び出すとと もに自身のＰＩＮを入力したときに、プラットフォームは、それが呼び出しをし ている当該加入者であると認識し、かつ、加入者のみのサービスを提供する。他 のＰＩＮｓには、異なるサービスプロフィールを割り当ててもよい。これらのＰ ＩＮｓは、適当な関係者に拡布され、どのようなサービスがそれらの関係者に利 用可能となるかを特定する。例えば、第１のＰＩＮは、加入者の家族のメンバー に与えられ、これに対して第２のＰＩＮは、前記加入者の業務提携者に与えられ る。その結果、家族のメンバーは、サービスの第１のセットへのアクセスを有す ることになるとともに、業務提携者は、サービスの第２のセットへのアクセスを 有することになる。 国内の呼出先または国際間の呼出先への多数の市外へ向かう呼は、ただ一つの アカウントに料金請求される。このアカウントは、コーリングカードのアカウン ト、クレジットカードのアカウント、または、このサービスのグルービングのた めに特別に作られたアカウントであってもよい。この結果、加入者は、多種多様 な呼をかける場合に何回もコーリングカード番号を入力する必要はなくなる。加 入者はまた、それらのアカウントにアクセスし、維持されているサービスプロフ ィールをアップデートすることもできる。一例として、加入者は、自身に到達す るために使用されている終端接続電話番号を変更することができる。同様に、加 入者は、どの発呼者がボイスメールへ送られるかということと、どの発呼者が自 動的に送られるページを発生するかということとを変更することができる。 上に引用した米国特許出願のもとでは、加入者は、彼らのアカウントにダイヤ ルすることにより、彼らのサービスプロフィールにアクセスし、かつ、これを改 変する。あいにく、加入者は一般的に、一般の電話機上の１２個のＤＴＭＦボタ ンのようなデュアルトーン多重周波数（ＤＴＭＦ(dual-tone multi-frequency) ）入力しか入力することができない。このため、ＤＴＭＦ入力は制限される。本 発明の一実施形態のもとでは、加入者は、インターネットのようなコンピュータ が 導入されたネットワークもしくは相互通信網を介して加入者がアクセスするグラ フィカル・ユーザ・インターフェースを通じて、加入者プロフィールの彼らのサ ービスを、コンフィギュレーションし、管理し、および、アップデートすること を容易に行うことができる。インターネット上の場合には、加入者は、彼らの一 つの番号を呼び出す個々の人々に対し、自身がどの通信サービスを供給すること を望むかを特定するワールド・ワイド・ウェブ（“Ｗｅｂ”）のアクセスを通じ て、彼らのプロフィールにアクセスする。 本発明の一実施形態のもとでは、加入者は、自身の加入者プロフィールにアク セスするために、いずれのウェブブラウザおよびインターネット・アクセス・プ ロバイダをも使用することができる。彼らのウェブブラウザ上で特定のインター ネットアドレスを入力することにより、加入者は、本発明の一実施形態に基づく システムの一部を形成するウェブサーバに到達する。そのウェブサーバを含むそ のシステムは、それぞれの加入者を認証する。その後、そのシステムは、加入者 が彼らの加入者プロフィールをアップデートするのに使うユーザ−フレンドリー なウェブページの形で、グラフィカル・ユーザ・インターフェース（ＧＵＩ(gra phical user interface)）を提供する。それらのアップデートは、近くにリアル タイムで記録およびアップデートされて、加入者の番号へ生成された次の呼がそ のアップデートされたプロフィールによってサービスされるようにする。 II．プラットフォーム・アーキテクチャ 図１Ａは、本発明の模範的な実施形態を実施するための第１のシステム・アー キテクチャを例示したブロックダイヤグラムである。ここで、本システム・アー キテクチャは、より大きな電気通信ネットワークの一部である。本システムは、 多種多様な構成要素を包含するプラットフォーム１０を有している。プラットフ ォーム１０は、一加入者のための多種多様な電気通信サービスに対して、一つの 電話番号アクセスを提供する。加入者は、この環境において、一つの電話番号が 割り当てられる顧客である。その一つの電話番号は、加入者と当該加入者への発 呼者（例えばゲスト）との双方によってアクセスされるものとなる。図１Ａ中に 記載された呼発信器１２は、プラットフォーム１０への呼の発生を提示する。こ の呼は、加入者、または、加入者に割り当てられた電話番号に到達するための捜 索を行っている発呼者からのものである。また、この呼は、ファクシミリ機また はコンピュータからのものであってもよい。この呼は、市内交換キャリア、私設 回線、専用アクセス回線、もしくは、国際間キャリアを含む、多数の経路におい ても、サービスプロバイダのスイッチ・ネットワーク１４に到達する。スイッチ ・ネットワーク１４は、この呼を、解除リンク中継線（ＲＬＴ(a release link trunk)）１６を介して、プラットフォーム１０内の自動呼分配器（ＡＣＤ(an au tomated call distributor)）１８へルーティングする。ＲＬＴ１６は、呼がAC Ｄ１８によってスイッチ・ネットワーク１４へ戻され届いた時に、呼から解除さ れる音声中継線である。 前記ＡＣＤ１８は、到来する呼を正しく処理するためのプラットフォーム内の 適切な構成要素へ到来する呼をルーティングする。ＡＣＤ１８は、呼の待ち行列 作成および分配を実行するためのプログラムを具備した在来のデジタル・マトリ クス・スイッチである。適切なＡＣＤとしては、ノーザン・テレコムのＤＭＳ− １００がある。 前記プラットフォーム１０はまた、ＡＣＤ１８が設けられたアプリケーション ・プロセッサ（ＡＰ）４６も具備している。そのＡＰは、ＡＣＤ１８に知的アプ リケーション処理（intelligent application processing）を行う専用のコンピ ュータ・システムであってもよい。ＡＣＤ１８によって実行される一定の機能が ＡＰ４６にオフ−ロードされることにより、ＡＣＤはスイッチングと待ち行列作 成の機能の実行に集中できるようになる。ＡＰ４６は、スイッチ／コンピュータ のアプリケーション・インターフェース（ＳＣＡＩ(a switch/computer applica tion interface)）リンク３０の、統合サービス・デジタル・ネットワーク（Ｉ ＳＤＮ(an Integrated Services Digital Network)）手段を介して、ＡＣＤ１８ にリンクされている。 前記プラットフォーム１０は、音声応答およびメニュー・ルーティングの機能 を発呼者に提供する音声応答装置（ＡＲＵ(an audio response unit)）２０を具 備している。ＡＲＵ２０は、電話機のキーパッド上のキーを押圧することによる ような、発呼者のＤＴＭＦディジットの選択による入力を容易にする。ＡＲＵ２ ０は、発呼者が所望のサービスに到達するために進めていく様々な自動化された メニューを提供してもよい。ＡＲＵ２０は、ネットワーク・オーディオ・サーバ （ＮＡＳ(a network audio server)）２２を具備している。このＮＡＳ２２は、 ＡＣＤ１８への音声電話インターフェースを有するサーバ・コンピュータである 。ＮＡＳ２２は、多重音声中継線２３を介してＡＣＤ１８にリンクされており、 通常は発呼者に音声インターフェースを提供する。ＡＲＵ２０はまた、自動呼プ ロセッサ（ＡＣＰ(an automated call processor)）２４も具備している。ＡＣ Ｐ２４は、ＡＲＵ２０に知的呼処理機能（intelligent call processing functi ons）を提供する。ＡＲＵ２０は、プラットフォーム１０のために、初期の市内 へ向かう呼のすべてを処理する責任を負う。ＡＣＰ２４は、スクリプトを実行す ることによって動作する。前記スクリプトは、適切なサービスを提供するために 、一連のメニューを通じて発呼者を案内し、発呼者の入力を受け付け、発呼者の 入力に基づいて決定を行い、および、別の呼出先への呼の転送のような機能を実 施する。ＡＣＰ２４は、スクリプトを再生するためにＮＡＳ２２の動作を促し、 あるいは、ＤＴＭＦディジット入力を収集し、様々な記録されたメッセージを再 生し、および、発呼者を他の呼出先に向けるために、発呼者の動作を促す。ＡＣ Ｐ２４は、インターナショナル・ビジネス・マシーンズ・コーポレーション（In ternational Business Machines Corporation）製のＩＢＭ ＲＳ／６０００もし くはデジタル・イクイップメント・コーポレーション（Digital Equipment Corp oration）製のＤＥＣアルファ−ベースのコンピュータのような、ハイグレード ・ミッド−レンジのコンピュータで実施することとしてもよい。 前記ＡＣＰ２４によって実行されるスクリプトは、発呼者にどの通信サービス を提供すべきかを決定し、それからＮＡＳ２２にその呼を適切なサービスプロバ イダへ転送することを命令することにより、それらのサービスを提供する。ＡＣ Ｐ２４によって実行されるスクリプトは、入力されるデータのように、加入者プ ロフィールを使用することによって加入者に対してカスタマイズされている。そ の加入者プロフィールは、後にもまたより詳細に説明するように、プラットフォ ームによる使用のために蓄積されている。加入者プロフィールは、どのサービス が加入者およびゲストに利用可能かと、どの呼出先電話番号が使用されるべきか とを、特定する。ＮＡＳ２２とＡＣＰ２４とは、例えば、イーサネット（商標） ・ローカル・エリア・ネットワーク（ＬＡＮ(local area network)）２６により 、リンクされることになる（イーサネットはゼロックス社の商標である。）。 前記プラットフォーム１０は、１つまたは２つ以上のオペレータ・コンソール ２８を具備する。これらのオペレータ・コンソール２８は、人間のオペレータに よって操作されている、特殊化されたワークステーションである。オペレータ・ コンソール２８は、ＡＲＵ２０によって実行されるのと同様な機能の多くを実行 する。特に、オペレータ・コンソール２８にいる人間のオペレータは、適当なス クリプト、動作の促進および転送を実行する。 前記プラットフォーム１０は、ボイスメール／ファックスメール・プラットフ ォーム（ＶＦＰ(a voicemail/faxmail platform)）３２を具備する。このプラッ トフォームは、ボイスメールメッセージとファクシミリメッセージの双方を、収 集し、蓄積し、および、管理する。それは、グループＤ特殊機構（ＦＧＤ(Featu re Group D)）の中継線３３を介してスイッチ・ネットワーク１４からボイスメ ールおよびファクシミリのメッセージを収集する。ボイスメールもしくはファク シミリのサービスを要求する呼は、後により詳細に説明するように、ＡＲＵ２０ からＶＦＰ３２へ転送される。転送は、ＡＣＤ１８およびスイッチ・ネットワー ク１４の援助によって生じる。ＶＦＰ３２はまた、イーサネットＬＡＮ２６とも 接続されている。 前記プラットフォーム１０は、多種多様なネットワーク手段配布サーバ（ＮＩ ＤＳ(network implementation distribution servers)）２７、３４および３６ を具備している。これらＮＩＤＳのそれぞれは、別々のコンピュータ・システム として具現することとしてもよい。ＮＩＤＳは、冗長にあり、かっ、通常は加入 者プロフィールを包含するデータベースの情報を蓄積する役割を果たす。図１Ａ に示したシステム・コンフィギュレーションにおいて、ＮＩＤＳ２７、３４およ び３６は、すべてイーサネットＬＡＮ２６と接続されている。 前記ＮＩＤＳ２７は、ＡＣＰ２４がイーサネットＬＡＮ２６を経由することを 要せずに直接加入者プロフィールにアクセスすることができるように、ＡＲＵ２ ０の一部として示されている。通常、ＡＣＰ２４は、ＮＩＤＳ２７にテータベー スの問い合わせを申し出て加入者プロフィール上のデータを得る。加入者プロフ ィールは、発呼者のためにどのようなスクリプトを再生すべきかを決定し、発呼 者にどのような通信サービスが提供され得るかを決定し、および、どのような呼 出先電話番号とメールボックス識別子が使用されるべきかを決定するのに用いら れる。ＶＦＰ３２は、加入者プロフィールの情報およびボイスメールもしくはフ ァクシミリのメッセージ処理のために、ＮＩＤＳ３４に問い合わせを申し出る。 ＮＩＤＳ２７・３４・３６はまた、トークン・リング・ローカル・エリア・ネ ットワーク（ＬＡＮ）３８によって相互接続されている。このＬＡＮ３８は、加 入者プロフィールに施されるアップデートのために使用されるとともに、多数の ＮＩＤＳ上に蓄積されたデータベースをメインフレーム・プロフィール管理シス テム４０（専用メインフレームもしくは他の適切なコンピュータ・システム上に ある。）によって維持されている集中化されたプロフィールのデータベースと一 致させておくために使用される。ＮＩＤＳ２７・３４・３６のうちの一つにおい て変更もしくはアップデートが生じると、影響を受けたＮＩＤＳがメインフレー ム・プロフィール管理システム４０へメッセージを送る。これにより、メインフ レーム・プロフィール管理システム４０は、集中化されたプロフィールのデータ ベースをアップデートし、その後、他のＮＩＤＳ上のプロフィール・データベー スのそれぞれがアップデートされることを確保する。 プラットフォーム１０は、１つまたは２つ以上のウェブサーバ４２を具備して いる。これらのウェブサーバ４２は、トークン・リングＬＡＮ３８と接続され、 加入者がインターネット４４を通じてアクセスしたウェブサイトを提供する。後 に詳述するように、ウェブページまたはウェブサーバ４２にあるページは、加入 者がインターネットを通じて当該加入者のための加入者プロフィールをアップデ ートすることができるようにする。それらのアップデートは、メインフレーム・ プロフィール管理システム４０へ発送され、メインフレーム・プロフィール管理 システム４０は、ＮＩＤＳ２７・３４・３６に蓄積されている情報を順次アップ デートする。あるいは、ＮＩＤＳは、ウェブサーバに常駐させてもよい。ウェブ サーバに設けられたＮＩＤＳはプロフィールの情報をアップデートし、かつ、そ のアップデートをメインフレーム・プロフィール管理システム４０へ回送するこ とになる。ウェブサーバ４２はインターネットよりもむしろイントラネットの一 部でもよく、このことは当業者によって理解される。その上さらに、ウェブサー バ４２は、より一般的には、加入者にユーザ・インターフェースを提供して加入 者がコンピュータによってサービス・プロフィールの情報をアップデートできる ようにするプログラムでもよく、このことは当業者であれば理解できる。したが って、プログラムは、ＬＡＮもしくはワイド・エリア・ネットワーク（ＷＡＮ(w ide area network)）のような分散形システムの一部であるサーバ上に常駐する プログラムでもよい。 図１Ｂは、本発明の模範的な実施形態を実践するのに好適な第２のシステム・ コンフィギュレーションを示している。この第２のコンフィギュレーションは、 いくつかの点において前記第１のコンフィギュレーションと相違している。第１ に、ＡＲＵ内にＮＩＤＳが存在せず、かつ、ＶＦＰと関連付けられたＮＩＤＳが 存在しない。この第２のシステム・コンフィギュレーションにおいては、ＶＦＰ ３２におけるＡＣＰ２４からのデータベースの問い合わせは、イーサネットＬＡ Ｎ２６を通ってＮＩＤＳ３６へ送られる。第２に、ＶＦＰ３２は、ＦＧＤ中継線 ３３’によって直接ＡＣＤ１８へ達している。この結果、ＡＲＵ２０からＶＦＰ ３２への呼の転送は、プラットフォーム１０内部のＡＣＤ１８によって実行され ることになる。プラットフォームの外部へ呼を転送する必要はない。 図１Ａと１Ｂに示されたシステム・コンフィギュレーションは単なる例示を意 図するものであり、このことは当業者であれば理解できる。例えば、与えられた 電気通信システムの範囲で多種多様なプラットフォームを具現化することができ る。さらに、多種多様なオペレータ・コンソール２８をプラットフォーム１０内 部に設けることができ、かつ、多種多様なＡＣＤを設けることができる。それぞ れのＡＣＤは、それ自身が関連付けられたＡＰを有することになる。その上さら に、与えられたプラットフォームの範囲で多種多様なＡＲＵを備えることができ 、かつ、一つのＶＦＰに多種多様なＡＣＤを組み合わせることができる。その上 さらに、それらの構成要素は、ＬＡＮの異なるタイプ、または、図１Ａおよび１ Ｂに示されたものとは異なる相互接続により、接続することができる。プラット フォーム１０およびその関連するサービスについてのさらなる詳細は、それぞれ 発明の名称を“Single Telephone Number Accessto Multiple Communications S ervices”、“Multiple Routing Options In A Telecommunications Service Pl atform”、“Outbound Calling Services On A Telecommunications Service Pl atform”、“Integrated Messaging Platform”、“Integrated Voicemail and Faxmail Platform For A Communications System”として、同様に係属中の米国 特許出願において、より一層詳細に開示されている。それらは、これと共に同時 に出願され、かつ、本願の共通譲受人に譲渡されている。 図２を参照すると、プラットフォーム１０とインターネット４４との間の接続 の論理アーキテクチャが示されている。そのアーキテクチャは論理的であって、 その中では、多くのサーバ構成要素をコンピュータの共用するリソース（例えば 、メモリ、プロセッサ等）上に実現することができる。図２には３つのウェブサ ーバ４２が示されているが、プラットフォーム１０は、当該プラットフォームに おけるインターネット・トラフィック量に応じて、より少ないまたはより多いウ ェブサーバを使用することができる。 ウェブサーバ４２は、別々のアプリケーション・サーバ（図示略）を使用する ことができる。それぞれのアプリケーション・サーバは、１つまたは２つ以上の アプリケーション専用である。このアプリケーションは、加入者プロフィールの 管理、加入者のためのパーソナル・ウェブ・スペース、Ｅメール、ボイスメール および／またはファックスメールのためのメッセージ・センタ、スマート・カー ドのための加入者プロフィール等のようなものである。追加のアプリケーション ・サービスは、追加のアプリケーションをプラットフォーム１０に加えてそれぞ れのウェブサーバ４２に加えることができる。 加入者は、ネットスケープ社（Netscape Corp.）によるインターネット・ナビ ゲータ（Internet Navigator（商標））のような、様々なウェブブラウザ６０の いずれをも使用することができる。加入者は、いずれのインターネット・サービ ス・プロバイダ（ＩＳＰ(Internet service provider)）を利用することによっ ても、インターネット４４にアクセスする。ウェブブラウザ６０、ＩＳＰおよび インターネット４４を介して、加入者は、ウェブサーバ４２のうちの一つにアク セスする。ウェブサーバ４２は、ネットスケープのコマース・サーバＨＴＴＰサ ー バ（Commerce Server HTTP Server）のような、固有のウェブ操作システムを秘 密モードで運転する。ここで一般に使用されるような“秘密”（“secure”）と は、秘密ソケット・レイヤ（ＳＳＬ(the secure socket layer)）を使用するこ と、または、ウェブブラウザ６０とウェブサーバ４２との間の接続が傍受できな いことを保証する他の方法を指す。ＳＳＬの使用は、ウェブブラウザ５０が稼動 している加入者のプラットフォームへの物理アクセスを持たずにデータまたはト ークン（後述）が盗聴されることを防止する。 加入者プロフィールへのアクセスのための要求に応答して、ウェブサーバ４２ は、トークンサーバ６２を通じてトークンデータベース６４からのトークンを要 求する。図２では、トークンサーバ６２がウェブサーバ４２のそれぞれと接続さ れた独立のブロックとして示されているが、それぞれのウェブサーバは、それ自 身のトークンサーバを具備するものとし、かつ、それによって共通のハードウェ ア・プラットフォームを共用するものとすることができる。トークンの情報は、 トークンデータベース６４によって維持されている。トークンデータベース６４ は、トークンに関する情報を蓄積するだけでなく、パスワード、加入者のIDコー ド等のような情報の付加的データベースをも提供する。そしてこのようなことか ら、ここではトークンデータベース６４は、トークンデータベース６４として、 および、データベース６４として、交換できるように照会される。トークンサー バ６２とトークンデータベース６４は、加入者のログインおよび認証のために使 用されるとともに、後述するように、プラットフォーム１０のセキュリティのた めに特に役立つ。確認されたトークンがトークンサーバ６２によって発行される と、そのトークンは、ウェブサーバ４２との加入者の交信のための巡回状態情報 （track state information）に使われる（“ウェブセッション”）。発行され 、かつ、確認されたトークンは、加入者に対し、ＬＡＮ３８を介して、１つまた は２つ以上のＮＩＤＳ２７、３４および／または３６上に記憶された当該加入者 のプロフィールへアクセスすることを許可する。 ウェブサーバ４２は、２つの主要なタスクを実行する。第１に、ウェブサーバ ４２は、後述するように、ログインにおける最初の加入者認証手続によってユー ザを認証する。第２に、ウェブサーバ４２は、少なくともサービスのデフォルト のページまたはスクリーンを加入者へ送る。後述するように、それは加入者に提 示される最初のスクリーンとなる。 オプションのＮＩＤＳ６６もまた、ウェブサーバ４２と接続させることができ 、あるいは、ウェブサーバ４２に常駐させることができる。このＮＩＤＳ６６は 、ＬＡＮ３８と通信を行う。ＮＩＤＳ６６は、加入者プロフィールのアップデー トを、ＬＡＮ３８を通ってメインフレーム・プロフィール管理４０へ送る。ここ でいうように、ＮＩＤＳ６６は、ルータ−ベースのファイアウォール１１７（図 ３）によってウェブサーバ４２から分離されている。ファイアウォール１１７は また、トークンデータベース６４をトークンサーバ６２およびウェブサーバ４２ から分離している。別のファイアウォール１１５は、ウェブサーバ４２をインタ ーネット４４から遮蔽している。一般に“ファイアウォール”（“firewall”） は、一台のコンピュータもしくは一群のコンピュータが外部からの攻撃にさらさ れないように制限をするハードウェアとソフトウェアの組合せである。このため 、ファイアウオール１１５は、インターネット４４とウェブサーバ４２との間の 境界を強化し、一方、ファイアウォール１１７は、トークンデータベース６４お よびＮＩＤＳ６６（および他のＮＩＤＳデータベース）と、トークンサーバ６２ およびウェブサーバ４２との間の境界を強化する。 図３に示すように、プラットフォーム１０は、加入者および加入者のウェブブ ラウザ６０とウェブサーバ４２との間に第１のファイアウォール１１５を使用す る。第２のファイアウォール１１７は、トークンサーバ６２とトークンデータベ ース６４との間に広がっている。この結果、データ管理区域（ＤＭＺ(a data ma nagement zone)）は、ウェブサーバ４２およびトークンサーバ６２を、（第１の ファイアウォール１１５により）インターネット４４から、および、（第２のフ ァイアウォール１１７により）トークンデータベース６４内に蓄積されたデータ から分離する、第１および第２のファイアウォール１１５および１１７の間に、 広がることになる。 III．システム・オペレーション 加入者プロフィールへのアクセスは、ログインおよび認証のプロセスとともに 開始する。以下、加入者のための模範的なログインおよび認証のプロセスについ て、図３のデータフローダイヤグラム、図４Ａ−４Ｃのフローチャート、および 、図５−７のスクリーン画像に関して説明する。図４Ａ−４Ｃのフローチャート は、ウェブブラウザ６０、ウェブサーバ４２およびトークンサーバ６２によって 実行されるステップを時期順に提示している。 ルーチン２００（図４Ａ）のステップ２０２において、ウェブブラウザ６０と ともに相互に動作する加入者は、そのウェブブラウザにウェブサーバ４２のうち の一つに対する“get login”要求のスクリーンを出させる。ステップ２０２に おぃて、その加入者は、“directline.MCI.com.”のような適切なＵＲＬ（unifo rm resource locator）を入力することにより、ウェブサーバ２０２への接続を 要求する。このＵＲＬには、ウェブサーバ４２の１つまたは２つ以上を割り当て ることが可能である。ラウンド−ロビン・アドレス指定（round-robin addressi ng）のような任意の所望のアルゴリズムを使用し、ウェブサーバ４２のうちの一 つがウェブサーバの組から選択される。 ウェブサーバ４２は、ハイパーテキストのドキュメントまたはＨＴＭＬ（Hype rtext mark-up language）のページのコレクションを有している。ここで、“ス クリーン”（“screen”）の文言と“ページ”（“page”）の文言とは、一般に 交換可能なものとして使用されている。ウェブブラウザ６０は、公知のハイパー テキスト・トランスポート・プロトコル（ＨＴＴＰ(Hypertext transport proto col)）を使用して個々のＨＴＭＬページにアクセスする。これにより、ウェブブ ラウザ６０がインターネット４４へ供給する模範的なＵＲＬは、“HTTP://direc tline.mci.com.”という形式を持ったものになる。トークンサーバ６２は、通常 、ウェブサーバ４２からのトークンを求める要求のためのＴＣＰ（Transmission Control Protocol）ポート上で特有のコマンドを聴取する。トークサーバ６２ は、順次、トークンデータベース６４からのトークンの確認を要求する。 ＨＴＭＬページは、ウェブサーバ４２からウェブブラウザ６０へ送られる。公 知のように、ＨＴＭＬページは、特に、コンピュータ・スクリーン上での表示用 ドキュメントが構成されたものを記述する。最初のＨＴＭＬページは、必要とさ れるすべての基準または言語条件を遵守しているかどうか、ウェブブラウザ６０ をチェックするとともに、ウェルカム・メッセージを表示する。例えば、最初の ＨＴＭＬページは、ウェブブラウザ６０が短いアプリケーションもしくはＪａｖ ａのような与えられた言語で記述されたアプレットに従うかもしくはこれを解釈 可能であることを、確認する。ウェブブラウザ６０が従うものでなければ、ウェ ブサーバ４２は、そのウェブブラウザがその加入者のプロフィールにアクセスし 、および／または、同プロフィールをアップデートすることに使用できないこと を知らせる、適当なメッセージを発行する。 ウェブブラウザ６０からの“get login”要求に応答して、ウェブサーバ４２ は、ルーチン３００のステップ３０４において、ただ一つの使用のトークンを求 める要求をトークンサーバ６２へ送信する（図４Ｂ）。ステップ３０４において 、ウェブサーバ４２はまた、加入者のＩＰアドレスを受け取る。このＩＰアドレ スは、当該加入者の最初の要求と関連付けられるものである。トークンサーバ６ ２は、そのトークン要求に応答して、ルーチン４００のステップ４０４でトーク ンを発行する（図４Ｃ）。ルーチン２００・３００・４００は、それぞれ、ウェ ブブラウザ６０、ウェブサーバ４２およびトークンサーバ６２によって実行され る。ステップ４０６において、トークンサーバ６２は、発行時刻のような付加的 データおよび受信ウェブサーバのＩＤとともに、選択されたトークンが発行され たトークンデータベース６４をアップデートする。ステップ４０８では、トーク ンサーバ６２は、選択されたトークンをウェブサーバ４２へ送信する。 ステップ３１０において、ウェブサーバ４２は、加入者のインターネット・プ ロトコル（ＩＰ(Internet Protocol)）・アドレスのようなネットワーク接続ア ドレスとともに、選択されたトークンのＩＤを記録する（図４Ｂ）。模範的な実 施形態においては、多種多様な異なる暗号化をし、もしくは、スクランブルをか け、そのウェブサーバ内部のデータベースに蓄積されたアプレットのうちの一つ を、ステップ３１８でウェブサーバ４２が選択する。ウェブサーバ４２は、選択 されたトークンのＩＤおよび加入者のＩＰアドレスとともに、その選択されたア プレットを前記データベースに記録する。ステップ３１２において、ウェブサー バ４２は、ウェブブラウザ６０にログイン・スクリーンを送る。さらに、ウェブ サーバ４２は、選択されたアプレットとともにそのトークンにスクランブルをか け 、そのスクランブルをかけられたトークンとアプレットをウェブブラウザ６０へ 送る。ウェブブラウザ６０が加入者に対して表示する模範的な初期のログイン・ スクリーンは、図５に示されている。そのログイン・スクリーン１２０は、ここ に記述される他のスクリーンないしページと同様に、共通ケートウェイ・インタ ーフェース（ＣＧＩ(common gateway interface)）のスクリプトが描かれたペー ジである。このページは、後でより完璧に説明するように、はめ込まれた単独使 用のトークンと、小アプリケーションプログラム（アプレット）と、ユーザのＩ Ｄコードおよびパスワードのような情報を識別あるいは入力するためのユーザ用 のフォーム・フィールドとを含む。 ステップ２１４において、ウェブブラウザ６０は、ログイン・スクリーン１２ ０を受け取る。このログイン・スクリーン１２０は、加入者にある一定の加入者 データを入力するよう指示する。例えば、加入者は、自身のユーザＩＤコードお よびパスワードの入力を求められる（図４Ａ）。ユーザＩＤコードは、便宜上、 当該ユーザの８００番（一つの電話番号）と同一とすることができる。そのユー ザＩＤコードは、おそらく秘密でない番号になる。逆に、パスワードは、６桁の 番号のようなユーザによって選択された秘密の英数字文字列である。そのパスワ ードは、ＡＲＵ２０を通じてユーザオプションにアクセスするために当該ユーザ によって使用されるパスワードと同一である。ステップ２１６では、ウェブブラ ウザ６０がユーザＩＤコード、パスワードおよびトークンをウェブサーバ４２へ 送る。 ステップ３１８において、ウェブサーブ４２は、ログイン要求を認証する。ウ ェブサーバ４２は、ステップ３１０で記録されたデータを受信されたデータと比 較し、加入者のＩＰアドレス、トークンのＩＤおよび他のデータが相互に関連す ることを確認する。この結果、ステップ３１０におけるウェブサーバ４２は、加 入者がトークンを変更するようにデータを細工しなかったことを確認する。ステ ップ３１８においては、ウェブサーバ４２はまた、そのＩＰアドレスをデータベ ースに蓄積された不適合なＩＰアドレスのテーブルと比較することもできる。そ の不適合ＩＰアドレステーブルは、プラットフォーム１０のセキュリティを破る ことを企てる可能性のあるＩＰアドレスを列挙している。受信ＩＰアドレスがそ の不適合ＩＰアドレステーブル上のアドレスの１つに一致した場合には、その時 にウェブサーバ４２が（図７に関して後述するように）ログイン失敗のスクリー ンを送る。不適合ＩＰアドレステーブルは、データベース６４またはウェブサー バ４２にあるデータベールに蓄積しておくことができる。不適合ＩＰアドレスの 各記録は、次のフィールドを含んでいる。ここで、括弧内の数字は、各フィール ド用のキャラクタ数ないしバイト数に対応する。 １．不適合ＩＰアドレス（１６）； ２．ＩＰアドレスにより試行された無効なアクセスの数； ３．ＩＰアドレスがプラットフォーム１０にアクセスした最初の時間 （４）； ４．ＩＰアドレスがプラットフォーム１０のアクセスに失敗した最後 の時間（４）； ステップ３２０において、ウェブサーバ４２は、トークンサーバ６２へトーク ンを送信する。ステップ４２２において、トークンサーバ６２は、そのトークン を確認する（図４Ｃ）。トークンサーバ６２は、トークンデータベース６４へ要 求を送信し、あるいは、実際にトークンデータベース６４にアクセスして、前に 発行されたトークンに対応するデータを求める。トークンがまだステップ４０４ で前に発行されたものと同一であれば、その時トークンサーバ６２は、ステップ ４２４において確認有効の応答をウェブサーバ４２へ送信する。ステップ３２０ において、ウェブサーバ４２はまた、加入者データ（例えばユーザＩＤコードお よびパスワード）も確認する。ウェブサーバ４２は、データベース６４へ要求を 送信し、あるいは、データベース６４にアクセスして、そのユーザコードに対応 するパスワードにアクセスする。データベース６４に蓄積されたパスワードがそ の加入者のデータにおいて受信されたパスワードと一致する場合には、その時に ウェブサーバ４２はその加入者のデータを有効と確認する。これに対し、それら のパスワードが一致しない場合、または、トークンが変更されていた場合には、 ウェブサーバ４２がその要求を無効とし、または、トークンサーバ６２が確認無 効の応答を同ウェブサーバへ送信する。 ステップ３２６において、ウェブサーバ４２は、トークンサーバ６２からの有 効確認の応答メッセージに応答して、サービス選択スクリーンをウェブブラウザ ６０へ送る（図４Ｂ）。トークンは、加入者とのカレント・セッションのために 、そのサービス選択スクリーンと続くすべてのスクリーンにはめ込まれる。この 結果、そのトークンは、後により詳細に説明するように、当該加入者がログオフ するまで、当該加入者とのカレント・セッションを巡回する。ウェブサーバ４２ は、パスワードが正しくないと断定し、または、トークンサーバ６２から確認無 効の応答メッセージを受信した場合には、ログイン失敗のスクリーンを送信する 。模範的なログイン失敗のスクリーン１２４が図７に示されている。ユーザは、 その時には上述したステップを繰り返して２度目のログインを試行しなければな らない。それぞれのログイン試行の間、ウェブサーバ４２は、ログインカウンタ をインクリメントし、その加入者のＩＰアドレスを不適合ＩＰアドレステーブル に記録する。加入者がログインに成功すれば、その時にログインカウンタが０に リセットされるとともに、当該加入者のＩＰアドレスが不適合ＩＰアドレステー ブルから除去される。ユーザが予め定められた回数（例えば、ログインカウンタ ＝３）の後にログインに失敗すると、その時にステップ３２６におけるウェブサ ーバ４２が当該加入者のＩＰアドレスを不適合ＩＰアドレステーブルに記録する 。以後においては、いつ当該加入者のＩＰアドレスに遭遇しても、それぞれのロ グイン試行の間に、ログイン試行を遅滞させるタイム−アウト・カウンタがリセ ットされる。ログインを行っているときの試行回数も不適合ＩＰアドレステーブ ルに記録される。続いてステップ２２８において、ウェブブラウザ６０は、サー ビス選択スクリーンかまたはログイン失敗スクリーンのいずれかを受け取る（図 ４Ａ）。模範的なサービス選択スクリーン１２２が図６に示されている。 ここで、模範的な加入者のサービスの選択について、図８におけるダイヤグラ ムのデータまたは信号フローと図９Ａ−９Ｃのフローチャートとに関して説明す る。ログインを行った後、加入者は、オプションを選択し、あるいは、ウェブブ ラウザ６０によって表示されたスクリーンに関連するその加入者の電気通信サー ビスのうちの一つに関するデータを変更する。例えば、加入者は、図６のサービ ス選択スクリーン１２２において示されたサービスのうちの一つを選択する。 ルーチン２５０のステップ２５において、ウェブブラウザ６０は、選択された サービスをウェブサーバ４２へ通知する（図９Ａ）。ルーチン３５０のステップ ３５４および３５６において、ウェブサーバ４２は加入者の要求を認証する（図 ９Ｂ）。一方、トークンサーバ６２は、ルーチン４５０のステップ４５８でその 要求を確認し、かつ、ルーチン３００および４００に関して上述したのとほぼ同 様な手法により、ステップ４６０で確認有効または確認無効の応答を前記ウェブ サーバへ送信する（図９Ｃ）。ルーチン２５０、３５０および４５０は、それぞ れ、ウェブブラウザ６０、ウェブサーバ４２およびトークンサーバ６２によって 実行される。 ステップ３６２において、ウェブサーバ４２は、要求を処理し、かつ、応答を 、場合によっては新たなスクリーンとともに、加入者に発行する。ウェブサーバ ４２は、ここに述べるように、その加入者のプロフィールに対するあらゆる変更 を、ＬＡＮ３８を介してメインフレーム・プロフィール管理システム４０へ発送 する。例えば、加入者は、図６のスクリーンからサービス・オプションのうちの 一つを選択することとしてもよく、かつ、それに対する応答で図１０−１６（後 述）に示されたスクリーンのような選択されたサービスのためのスクリーンを受 信することとしてもよい。 ウェブサーバ４２がトークンサーバ６２から確認無効の応答メッセージを受信 した場合には、同ウェブサーバが“サービス利用不可”（“service not availa ble”）のスクリーンを発行する。例えば、加入者のＩＰアドレスが不適合ＩＰ アドレステーブルにおけるアドレスと一致した場合、または、加入者のトークン が消滅していた場合には、ウェブサーバ４２がログイン失敗のスクリーン１２４ を発送する。ステップ２６４において、ウェブブラウザ６０は、ウェブサーバ４ ２から応答および／またはスクリーンを受け取る（図９Ａ）。処理された要求に 応じて、ユーザは追加のサービスを選択できることになる。そうなると、その加 入者によって実行される追加のサービスの要求それぞれに対して、ルーチン２５ ０、３５０および４５０のもとでのステップが繰り返される。この結果、加入者 がサービス・スクリーンのうちの一つにおいて自身の選択をしたときには、ログ インの間に最初に発行されたトークンがその選択に同伴する。このトークンは、 サービス選択の間に加入者によって試行されるすべてのアクセスにおいて、有効 な ものと確認される。 次に、選択および加入者のプロフィールのアップデートについて、図６及び図 １０−１８のスクリーンに関して説明する。本発明の模範的な実施形態は、概し て、加入者に対し、彼らのファインド−ミー・ルーティング（find-me routing ）における電話番号の追加もしくは変更を含む彼らのプロフィールのアップデー トをすることと、彼らのフォロー−ミー・ルーティング（follow-me routing） におけるスケジュールを変更することと、デフォルトもしくは代替のルーティン グを追加することと、その他ここで述べる多数の可能なこととを、許可する。こ れらのアップデートは、図５−１８に示されたスクリーンを有するユーザ−フレ ンドリーなＧＵＩを介して加入者によって入力される。それらのスクリーンは、 ウェブサーバ４２によって加入者のウェブブラウザ６０へ供給される。加入者が そのプロフィールにおけるサービスをアップデートする際には、ウェブサーバ４ ２がそのアップデートされたプロフィールをＬＡＮ３８を介してメインフレーム ・プロフィール管理システム４０へ送信する。メインフレーム・プロフィール管 理システム４０は、集中化された加入者のプロフィールの記録のデータベースを アップデートするとともに、そのアップデートされた記録を分散されたＮＩＤの ２７、３４、３６および６６へ分配する。 ログインおよび認証のプロセスの後、ウェブサーバ６０は、上述したように図 ６のサービス選択スクリーン１２２を表示する。加入者は、呼ルーティング、ス ピード・ダイヤル番号、ボイスメール、ファックスメール、呼スクリーニング等 のような、いくつかのサービス・オプションのうちの一つを選択することができ る。サービス選択スクリーン１２２におけるそれぞれの加入者サービス・オプシ ョンは、次のような関連するスクリーンとリンクするハイパーテキスト・リンク を有している。呼ルーティング・オプションは、図１０のスクリーン１２８（こ のスクリーンは、図１１および１２のスクリーン１３０および１３２へ順次リン クする。）へリンクする。スピード−ダイヤル番号オプションは、図１３のスク リーン１３４へリンクする。ボイスメール・オプションは、図１４のスクリーン １３６へリンクする。ファックスメール・オプションは、図１５のスクリーン１ ３８へリンクする。そして、呼スクリーニング・オプションは、図１６のスクリ ーン１４０へリンクする。ユーザは、カーソルを位置決めしてサービス上でクリ ックすることにより、あるいは、他の公知のユーザ入力および選択方法により、 図６のスクリーンに示されたサービス・オプションのうちの一つを選択すること としてもよい。 サービス選択スクリーン１２２はまた、ログオフボタン１２７も具備している 。そのログオフボタン１２７上をクリックすることにより、加入者は、その加入 者のカレント・セッションから直ちにログアウトすることができる。ウェブサー バ４２は、カレント・トークンに付帯された制限時間を直ちに終了させるととも に、ウェブブラウザ６０へログイン・スクリーン１２０を送る。 図１０に示すように、加入者がサービス選択スクリーン１２２から呼ルーティ ング・オプションを選択した場合には、ウェブサーバ４２は、ウェブブラウザ６ ０による加入者への表示のために、このスクリーン１２８を発送する。スクリー ン１２８の呼受取セクション１４４においては、加入者は、当該加入者のコンピ ュータ・スクリーン上に表示された２つのボタンのうちの一つを選択することに より、当該加入者のアカウント上で呼が受け取られるかどうかを指定する。加入 者が呼を受け取らない方のボタンを選択すると、その時には、当該加入者への発 呼者は、当該加入者が当該加入者の一つの電話番号を通じては呼を受け取ってい ないことを当該発呼者らに知らせるメッセージを、受信することになる。選択選 出セクション（a choose selections section）１４６においては、加入者は、 ゲスト発呼者がゲスト・メニューを受信するものとするかまたはオーバーライド （override）・ルーティングの取扱を受けるものとするかどうかを指定する。選 択対象のゲスト・メニューを選択することにより、ウェブサーバ４２は、ゲスト ・メニュー・スクリーン１３０をウェブブラウザ６０へ送る。これに対し、加入 者が選択対象のメニューを何も選択しなかったときは、ウェブサーバ４２は、オ ーバーライド・ルーティング・スクリーン１３２をウェブブラウザ６０へ送る。 以下、これら双方のスクリーンについて説明する。 スクリーン１２８の利用者利用不能セクション（a subscriber unavailable s ection）において、加入者は、当該加入者に連絡できない時に受信される呼の取 扱を指定する（代替端末）。セクション１４８の下、加入者は、当該加入者への 連絡ができない場合、呼を当該加入者のボイスメール、ページャ、ボイスメール およびページャに終結させるかどうか、または、ゲストの呼に対して閉鎖中メッ セージ（a closing message）を受信させるかどうか、を決定する。スクリーン １２８もしくはここで検討されている他のスクリーンに提示されたオプションの どれを選択もしくはアップデートした後でも、ウェブサーバ４２は、当該加入者 のためにスクリーン上でステータス・メッセージを供給する。例えば、代替端末 セクション１４８で加入者が閉鎖中メッセージのオプションを選択した後には、 ウェブサーバ４２が“発呼者は、後で呼出をしてみるように求めるメッセージを 聞くことになります。“（“callers will hear a message asking them to try their call later,”）という閉鎖中メッセージを送り、それをウェブブラウザ ６０がスクリーン１２８上で加入者に対して表示する。 図１１に示すように、加入者が呼ルーティング・スクリーン１２８で選択対象 のゲスト・メニューを選択した場合には、ウェブサーバ４２は、ウェブブラウザ ６０による表示のために、このゲスト・メニュー・スクリーン１３０を送信する 。ファインドミー・ルーティング・セクション（a Findme routing section）１ ５０においては、ゲスト・メニュー・スクリーン１３０は、加入者が彼らへの呼 のルーティングを計画するオプションを提示するとともに、当該加入者の検出を 連続的に試みる３つまでの番号を提供する。模範的な実施形態においては、加入 者は、３つまでの番号と、代わる番号を試行する前にその番号において実行され るべき呼出音の回数とを入力する。国内番号における先頭の“１”の番号および すべての番号でないもの（例えば括弧およびダッシュ）は、セクション１５０に 示された３つの枠へ入力されるすべての番号から取り除かれる。呼出音の回数は 、その呼出音の回数を６倍する式に基づいて秒に換算されて、また、加入者が何 らの数値も入力しなかった場合には３回の呼出音（１８秒）というデフォルトの 数値とともに、加入者のプロフィール内に好ましく記憶される。０から８秒が１ 呼出音と解釈され、一方、８秒より大きいすべての数値は６で除算され、呼出音 の回数を参照して四捨五入された結果により、最大１６までとなる。 第２の選択セクション１５２において、ゲスト・メニュー・スクリーン１３０ は、ゲスト発呼者がホイスメールとファックスの双方を残しておけることを示し ている。加入者はまた、ゲスト発呼者がページを送信できることにするかどうか も選択することができる。オペレータ・コンソール２８（図１Ａ）のオペレータ と通信をすることにより、ファックスを送信することのような、ある一定のオプ ションだけは選択されないようにしてもよい。 図１２を参照すると、オーバーライド・ルーティング・スクリーン１３２は、 加入者に対し、加入者がゲストの呼を特定の呼出先へ発送することを望むことの 確認を行い、それによってゲスト・メニューの提示を迂回する。加入者は、オー バーライド・ルーティング・スクリーン１３２のもとでオーバーライド・ルーテ ィングの選択を確定しなければならない。 図１３を参照すると、スピード−ダイヤル（speed-dial）番号スクリーン１３ ４は、加入者にウェブブラウザ６０を通じて９つまでのスピード−ダイヤル番号 を入力することを許可する。図１３に示すように、スピード−ダイヤル番号スク リーン１３４は、ユーザが９つのスピード−ダイヤル番号を入力する９つの枠を 与える番号入力セクション１５４を提供する。ウェブサーバ４２は、ウェブブラ ウザ６０から（加入者による入力として）受信するすべての番号を好ましく確認 する。スクリーン１３４へ入力された番号およびここで述べる他のスクリーンへ の入力の確認は、ブロックされていない、有効な国際番号が、すべての国際電話 番号に対して入力されることを確認する。国内番号については、ウェブサーバ４ ２は、１０桁が入力されることを確認するとともに、有効な番号計画領域（ＮＰ Ａ(numbering plan area)）もしくは“エリア・コード”がその１０桁に対して 入力されることを確認する。加えて、ウェブサーバ４２は、入力された番号が“ ９７６”番号であれば９７６ブロッキングが有効かどうか、あるいは、他の特定 された番号がブロックされているかどうか（例えば、ある一定のノース・アメリ カン・ディレクトリ・プラン（ＮＡＤＰ(North American directory plan)）の 番号）、を断定することができる。加入者によって入力された番号が受け入れら れるものであるとウェブサーバ４２が確認したと仮定すると、その後同ウェブサ ーバは、ＬＡＮ３８を介してその番号をメインフレーム・プロフィール管理シス テム４０へ転送する。 図１４を参照すると、ボイスメール・サービス・スクリーン１３６は、加入者 に対し、当該加入者がボイスメールを受信した時にはいつでもページングされる ことを許可する。図１５において、ファックスメール・サービス・スクリーン１ ３８は、加入者に対し、当該加入者がファックス・メッセージを受信した時には いつでもページングされることを同様に許可するオプションを提供する。ファッ クスメール・サービス・スクリーン１３８は、模範的な実施形態において、加入 者のファックス番号を表示する。 図１６を参照すると、呼スクリーニング・サービス・スクリーン１４０は、呼 スクリーニング選択セクション１５６を提供する。セクション１５６においては 、加入者は、到来する呼がどのようにスクリーニングされるかを決定することが できる。例えば、名前だけにより、電話番号だけにより、または、名前と電話番 号により、スクリーニングされるものと決定することができる。ゲスト発呼者が 彼らの名前を供給するのに失敗すると、プラットフォーム１０は、そのゲスト発 呼者の電話番号を供給することになる。 図１７に示すように、模範的なエラー・スクリーン１６０は、加入者が入力、 すなわち適切なデータを入力するのに失敗したときに表示される。エラー・スク リーン１６０における第１のメッセージ１６２は、“あなたの第１番目の番号は ブランクでない可能性があります。”（“your first number may not be blank ”）ということを示している。ウェブサーバ４２は、加入者がゲスト・メニュー ・サービス・スクリーン１３０（図１１）のセクション１５０内のような適切な 箇所に第１番目の番号を入力しなかった場合、その第１のメッセージ１６２をウ ェブブラウザ６０へ送る。第２のメッセージ・セクション１６４は、加入者に対 し、当該加入者が入力したある番号がブロックされているかまたは無効であるこ とを示す表示を提供する。上述したように、加入者がいかなる番号を入力した場 合にも、ウェブサーバ４２がそれらの番号を確認する。同ウェブサーバが無効な 番号を認識した場合には、同ウェブサーバは、ウェブブラウザ６０へ第２のメッ セージ１６４を送る。 図１８を参照すると、ファイナルないしはエクジットのスクリーン１６６が示 されている。ウェブサーバ４２によって有効と確認されかつ受け入れられる適切 なデータを加入者が入力すると、同ウェブサーバは、そのデータをメインフレー ム・プロフィール管理システム４０へ送信し、当該加入者のプロフィールをアッ プデートする。プロフィールのアップデートに成功した後、ウェブサーバ４２は 、エクジット・スクリーン１６６をウェブブラウザ60へ送り、加入者に対してプ ロフィールのアップデートが成功したことを示す適切なメッセージを供給する。 例えば、スクリーン１６６は、“あなたのゲスト・メニュー・オプションは、ア ップデートが成功しました。”（“your guest menu options have been succes sfully updated.”）ということを示している。 図１９を参照すると、ページおよびスクリーンのための模範的なＨＴＭＬのレ イアウトが示されている。上側左隅のフォト・フレーム１７０は、グラフィック もしくは他のイメージを表示し、かつ、４０×１６０ピクセルでもよい。模範的 な実施形態におけるフォト・フレーム１７０は、各サービス・スクリーン間で継 続的な静的アイコンを表示する。スクリーンの上側右隅のタイトル・フレーム１ ７２は、当該スクリーン用のタイトルを表示する。タイトル・フレーム１７２に は、４０ピクセルの高さと利用可能なスクリーンサイズによって決定される幅と を持たせることができる。フォト・フレーム１７０に表示されるグラフィックは 、加入者によって要求され、かつ、スクリーン上に表示された特定のサービスを 好ましく強調する。模範的な実施形態において、タイトル・フレームは、加入者 によってアクセスされたアプリケーションのタイトルを示している。それはまた “ＭＣＩ”のようなサービス・プロバイダのロゴも表示することになる。タイ トル・フレーム１７２内に表示された情報は、フォト・フレーム１７０同様、加 入者がプラットフォーム１０内へログインしたままでいる限り、加入者との全体 のセッションを通じて変わらない。 スクリーンの下部にあるボトム・フレーム１７４は、プラットフォーム１０に よって提供される他の様々なサービスへのハイパーテキスト・リンクを有する。 ボトム・フレーム１７４には、４０ピクセルの高さと利用可能なスクリーンのサ イズによって決定される幅とを持たせることができる。模範的な実施形態におい ては、ボトム・フレーム１７４または他のスクリーンの部分は、他のウェブ・サ イト同様、ＭＣＩサービスのようなプラットフォーム１０のオペレータによって 処理される他のサービスへのハイパーテキスト・リンクを含む。そのようなリン クは、加入者に対し、要求があれば、ログイン・プロセスから効果的にキャンセ ルし、および、他のサービスもしくはサイトへ移動することを、許容する。 スクリーンの左部分にあるリスト・フレーム１７６は、ユーザがアクセスした アプリケーションの範囲で、他の、特別なスクリーンの（screen-specific）、 アプリケーションおよびスクリーンへのハイパーテキスト・リンクを表示する。 リスト・フレームは、１６０ピクセルの幅でかつ利用可能なスクリーンのサイズ によって決定される高さにすることができる。テキスト・フレーム１７８は、加 入者によって要求されたデータを表示する。テキスト・フレーム１７８もリスト ・フレーム１７６も加入者によって選択されるすべての新たなスクリーンに変化 する。テキスト・フレーム１７８およびリスト・フレーム１７６は、上述した図 ５−１８に記載されたスクリーンを表示する。 図２０を参照すると、図２のプラットフォーム１０の部分の内部での楔範的な データフローが示されている。図２０に示されたデータの流れは、図３、４Ａ− ４ｃ、８および９Ａ−９Ｃに関して上述したものに対応する。通常、トークンデ ータベース６４は、新たな記録を生成し、与えられたトークンの値用の記録を読 み出し、かつ、その与えられたトークンの値のための記録をアップデートするた めに、トークンサーバ６２によってアクセスされる、トークンデータベースサー ビスを、具備している。個々のアップデートサービスまたはアプリケーションは 、ウェブサーバ４２によって実行され、ウェブサーバ４２は、トークンデータベ ース６４にアクセスするとともに、周期的基準で（例えば毎時に）旧式の記録を 削除する。ウェブサーバ４２は、トークンデータベース６４を連続的にスキャン するとともに、消滅したトークンに関する記録を削除する。 ウェブサーバ４２によって供給されるデータは無状態（stateless）である。 状態情報は、ＮＩＤＳ上の貯蔵データベース（cache database）を通じた書込に よって保持され、かつ、トークンによってインデックスされる（それらはそれぞ れユニークである。）。この結果、多種多様なウェブサーバ４２の間でデータの 同期をとる必要がなくなる。それぞれのウェブサーバ４２はまた、１つ以上のサ ービスも提供する。ウェブサーバ４２によって提供されるサービスは、それらウ ェブサーバのドキュメント・ルートにおけるそれらのロケーションによって区別 さ れる（後述）。 トークンサーバ６２は、トークンデータベース６４のクライアントであり、か つ、ログイン試行の間、ウェブサーバ４２にトークンを発行する。発行されたト ークンは、一度確認されると、ウェブサーバ４２のうちの一つによる接続のため に、状態情報を巡回するのに使用される。この結果、トークンサービス６２は、 重要な３つのタスクを実行する。（１）加入者の認証もしくはログインの間に単 独使用（single-use）のトークンを発行する、（２）単独使用のトークンを確認 する、および、（３）多使用（multi-use）のトークンを確認する（そのような トークンが使用されている場合）。上述したように、それぞれのトークンは、す べてのログイン要求に対してユニークでなければならない。 図２１を参照すると、加入者プロフィールのための模範的な記録がレコード１ ８０として示されている。レコード１８０は、スピード−ダイヤル番号、１次端 末番号およびゲスト・メニュー・ルーティング・サービスのためのタイム−アウ ト値（呼出音の回数）、メッセージの受信に基づいて加入者がページングされる かどうか、呼スクリーニングの状態等のような、多数のフィールドを有している 。加入者プロフィールに対応するレコード１８０は、２７、３４、３６および６ ６のＮＩＤに蓄積されている。レコード１８０のフィールドは、概して、ここで 提供される詳細な説明を参照することにより、説明を要しないものである。 ウェブサーバ４２、および、広くいえばプラットフォーム１０は、侵害者、ハ ッカー、および、敵意を持ってプラットフォーム１０に悪影響を及ぼすこともし くは認証なしでデータを取り出すことを望む他の不満を持つ者に対し、傍受でき ないものでなければならない。このため、ウェブサーバ４２は、傍受できない眠 っているプログラム（secure daemons）を好ましく動作させる。例えば、ウェブ サーバ４２は、傍受できないＨＴＴＰの眠っているプログラムを動作させる。公 知のように、“眠っているプログラム”（“daemon”）とは、ＵＮＩＸサーバ上 のように継続的に処理を行い、かつ、ネットワーク上でクライアントのシステム にリソースを供給する仮想代理人ソフトプログラムである。一般に、眠っている プログラムは、低水準処理システムのタスクを扱うために使用されるバックグラ ウンド・プロセスである。 ここで使用されるトークンはまた、プラットフォーム１０のためのセキュリテ ィも提供する。図２２を参照すると、模範的なトークン５００が示されている。 トークン５００は、括弧内に表された模範的なバイト数ないしキャラクタ数を有 する次のフィールドを含んでいる。 １．ヴァージョン５０２（１）； ２．使用フラグ５０４（単独対多数の使用）（１）； ３．トークン値５０６（１６）； ４．加入者のＩＰアドレス５０８（１６）； ５．ユーザＩＤコード５１０（１６）； ６．与えられた時間５１２（４）；および ７．消滅５１４（４）。 ＩＰアドレスのフィールドは十分大きく、要求される場合に拡張されたＩＰヴ ァージョン６のアクセスを保持する。タイム−アウトのタイマは、それぞれのト ークンの与えられた時間５１２および消滅時間５１４の値と関連付けられ、一定 時間の期間中（例えば１０分間）使用されないトークンがウェブサーバ４２によ って無効と確認されるようにする。 トークン値５０６は１６個のキャラクタを有している。ここで、それぞれのキ ャラクタは６２の可能なキャラクタ値を持ち、それらはセット（わ−９、ａ−ｚ 、Ａ−Ｚ）から選択される。トークン値５０６のわ、１および２の位置における キャラクタは、固定され、かつ、トークンサーバ６２に割り当てられる。もし多 種多様なトークンサーバ６２が使用されていれば、０、１および２の位置におけ るキャラクタは、それぞれのトークンサーバをユニークに定義し、これにより、 それぞれのウェブサーバ４２によって使用されるトークンがユニークになる。０ の位置にあるキャラクタは、トークンサーバ６２の物理的なロケーションを識別 するのに使用される。１の位置にあるキャラクタは、前記物理的なロケーション にあるサーバを識別する。一方、２の位置にあるキャラクタは予備の値を持ち、 その値はトークンサーバ６２のヴァージョン・ナンバーの識別または他の情報に 使用し得るものとなっている。 トークン値５０６の残りの１３個のキャラクタは、６２の可能なキャラクタ値 を用いて連続的に生成される。１０−１５のキャラクタ位置は、プラットフォー ム１０用のカレント時間に割り当てられる（トークンサーバ６２のセット−アッ プにおいて）。システム時間（３２−ビット量（a 32-bit quantity））は、６ 桁ベースの６２の数値（a 6-digit base 62 number）として計算され、その数値 が１０−１５の位置に配置される。トークン値は、３の位置が最下位の位置とな って、３−１５の位置の全体にわたって連続的にインクリメントされる。キャラ クタ値は、上位から下位への桁の値の順序が次の通りであるものとする。“ｚ” −“ａ”、“Ｚ”−“Ａ”および“９”−“０”。この結果、システム時間が４ バイトの値で計算されれば、トークンサーバ６２はユニークなトークンを生成す る。それは、１０−１５の位置における６個のベース−６２のキャラクタ（a 6 base-62 characters in positions 10-15）を計算する。これは、与えられるい かなるトークンサーバ６２においても、トークンサーバ６２が１秒間に６２7（ ３５＊１０12）個以上のトークンを生成しないことを仮定している。これにより 、侵害者が実際にトークン値を解き当てる確率は、４．７×１０28のうちの１と なる。正しく解き当てられたトークン値であっても、加入者の適切なＩＰアドレ スが正しくなければならず、かつ、トークンの時間が終了していない必要がある ので、ファイヤウォール１１５を通過して侵入することに成功する保証は全くな い。 上述したように、それぞれのトークンは、ウェブサーバ４２がウェブブラウザ ６０へ送る、サービス特有のスクリーン内にはめ込まれる。与えられたスクリー ンが型枠を含んでいる場合には、トークンは、その型枠の隠されたフィールド内 にあってもよい。Ｊａｖａのアプレットのようなアプレットをそのスクリーンが 含んでいる場合には、トークンは、そのアプレットのパラメータであってもよい 。そのスクリーンがハイパーテキスト・リンク（例えば、ハイパーテキスト・リ ンクが指し示すファイルの名前もしくはＵＲＬを特定するハイパーテキスト・リ ファレンス（ＨＲＥＦ(a Hypertext reference)））を含んでいる場合には、ト ークンは、そのリンク自体の一部であってもよい。通常、与えられるトークンの 特定の値は、傍受されない状態に維持されることを必ずしも要しない。トークン のセキュリティは、プラットフォーム１０内でのＳＳＬの使用、トークンの消滅 もしくはタイム−アウト、および、加入者の（クライアントの）ＩＰアドレスへ の トークンのリンクによって提供される。 模範的な実施形態において、ウェブサーバ４２がウェブブラウザ６０へ送るす べてのＨＴＭＬページは、パール−ベース（Perl-based）の共通ゲートウェイ・ インターフェース（ＣＧＩ(Common Gateway Interface)）のスクリプトのような 共通の言語における共通のルールを用いて生成される。公知のように、ＣＧＩス クリプトは、ＨＴＴＰの眠っているプログラムを拡張する標準的な方法であり、 それはＰｅｒｌ、Ｃまたはシェルのスクリプトを用いて共通に記述される。ウェ ブブラウザ６０によるウェブサーバ４２へのすべてのアクセスは、ＣＧＩスクリ プトの記述に移される。図２３を参照すると、すべてのＣＧＩスクリプトは、ウ ェブサーバ４２内のディレクトリに好ましく備わっている。そして、そのディレ クトリは、ＨＴＴＰの眠っているプログラムのdocument-rootディレクトリの中 にはなく、これによってウェブサーバ４２にセキュリティを提供するものとなっ ている。上述したように、それぞれのリクエストの認証および有効なトークンの 発行は、すべての加入者の要求に対して、そしてこのようにすべてのスクリプト のスタートに、必要とされる。 ウェブサーバ４２上でのそれぞれのアプリケーションは、それ自体のドキュメ ント・ルートと、ＣＧＩスクリプト（cgi-bin）、テンプレート（templ）、イメ ージ、Ｊａｖａクラス・ライブラリおよび必要であればイメージ・マップ（map ）のディレクトリの、関連付けられたコレクションとを有する。ウェブサーバ４ ２上にある模範的なウェルカム・サーバ・ディレクトリの構造が図２３に示され ている。図２３に示されたように、ドキュメント・ルート・ディレクトリは、サ ーバのルート・ディレクトリから切り離されている。ドキュメント・ルート・デ ィレクトリは、セキュリティのために、ウェルカムおよびアクセス失敗／拒否の ＨＴＭＬページのみをホールドしている。それらのディレクトリは、アプリケー ション特有のＵＲＬによってアクセス可能となるように、サーバの指示を通じて マッピングされている。ＣＧＩスクリプト同様に、多くのアプリケーションがイ メージおよびクラスのライブラリを蓄積するものとしてもよい。図２３に示され たように、分配されたオブジェクトは、別々に分配されたディレクトリ・ツリー 内に維持されている。これらの分配されたオブジェクトに対するＵＲＬマップは 存 在しない。しかし代わりに、分配されたオブジェクトは、プラットフォーム１０ の運転開始時に、その分配されたオブジェクトへリンクされたそのアプリケーシ ョン特有のＵＲＬを通じてアクセスされる。共通のサーバ・ルート・ディレクト リは、ウェブサーバ４２のための処理パラメータを包含している。そのような情 報は、多種多様なウェブサーバ４２に対して同じ環境を維持するために、共通の データベースに保持される。 本発明の特定の実施形態と例が、例示目的のために、ここで説明されたが、関 連する技術分野の当業者によって認識されるように、本発明の精神および範囲を 逸脱することなく、様々な等価な変形をなすことが可能である。ここで提供され た本発明の教示は、他の通信もしくはネットワークのシステムに適用することが でき、必ずしも上述した模範的な電気通信システムに適用することには限られな い。例えば、本発明の実施形態は、概して、電気通信プラットフォーム１０とと もに使用されるものとして、上に説明したが、本発明は、ワールド・ワイド・ウ ェブの手段によってユーザの記録のアップデートを提供するコンピュータのネッ トワークのような、他の通信システムに同様に適用できる。本発明の実施形態の もとでのある一定のオプションは、概してシリアルの形式で発生するものとして 説明したが、より多くもしくはより少なく同時に、または、ここで述べたのとは 異なる別の順序で、いくつかの処理を実施することが完全に本発明の範囲内であ ることは、関連する技術分野の当業者に理解される。 本発明の特徴は、呼ルーティング、スピードダイヤル番号、ボイスメール、フ ァックスメール、呼スクリーニング等のような、多数の機能を提供するただ一つ の電話番号の電気通信システムに関連して上に説明された。ただ一つの電話番号 のシステムはまた、電子メール（音声認識およびテキスト−トゥー−スピーチ（ text-to-speech）の可能出力を含む）、ビデオ・メール、テレックス・サービス 等のような、追加の機能を含むこととしてもよい。本発明の他の実施形態は、デ ィスプレイを含み、かつ、電子メール、ビデオ・メール、テレックス・サービス 等のコンフィギュレーションを提供するものとしてもよい。例えば、加入者は、 音声認識およびテキスト−トゥ−スピーチのワードのユーザ保持辞書（a user-m aintained dictionary）にインターネットを介してアクセスできる。加えて、 その加入者は、当該加入者に次の選択肢の選択を許すスクリーンの提示を受ける ことができる。すなわち、ボイス・タイプ（例えば、男性または女性の声）、ピ ッチ（声のピッチの選択をするアビリティ）、話す早さ（ゆっくりなスピーチ、 中間のスピーチまたは早いスピーチを規定するアビリティ）、モード（自然なス ピーチ、１回に１語または綴られた語のオプション）、言語／地方語（language /dialect）（話される言語（英語、スペイン語等）および地方語を選択する）等 である。 ウェブサーバ４２は、ＨＴＭＬページのみならず、音声、ファクシミリ、ビデ オ、テレックスおよび他のメッセージを蓄積することのできる、加入者のための メールボックスをも具備することとしてもよい。マウス、キーボードまたは他の ポインタ／テキスト−ベース（pointer/text-based）のスクリーン表示可能な入 力を用いてオプションを選択する方がよく、本発明の他の実施形態は、選択をし かつ選択を入力する表示可能なスクリーン間および内部のボイス・ナビケーショ ンを用いることも許容する。 上記米国特許および出願のすべては、引用により、あたかもそっくりそのまま 説明を始めたかのように、ここに取り込まれる。本発明の実施形態は、本発明の 一層さらなる実施形態を提供するために、上記米国特許および出願の開示する実 施形態に基づいて変形することができる。 これらのおよび他の変形は、上述した詳細な説明に鑑みて、本発明の実施形態 に対してなすことができる。概して、以下の請求の範囲において、使用されてい る文言は、明細書および請求の範囲に開示されている特定の実施形態に本発明を 限定するように解釈されてはならないが、ユーザの記録をアップデートするため の処理を提供する請求の範囲に基づく処理を行う、記録をアップデートする、い かなるシステムをも、含むものと解釈されなければならない。したがって、本発 明は、開示によって限定されるものではなく、その範囲は専ら以下の請求の範囲 によって決定されるべきものである。Description: FIELD OF THE INVENTION The present invention relates generally to communication systems, and more particularly to a system having a single telephone number to access a wide variety of communication services. Managing such telecommunications systems. BACKGROUND OF THE INVENTION In conventional telecommunications systems, many different telecommunications services are provided to subscribers. Each telecommunications service generally requires a unique telephone number. Examples of telecommunications services that require unique telephone numbers include automatic routing services, voice mail services, facsimile services, paging services, cellular telephone services, and personal 800 numbers. One of the drawbacks of each service that requires a separate telephone number is that managing and disseminating different telephone numbers can be very cumbersome for subscribers utilizing different communication services. . For example, the subscriber must have a first telephone number for facsimile service, a second telephone number for voicemail service, and a third telephone number for cellular service. become. For this reason, subscribers must remember all of their own phone numbers, and for those who call their phone numbers, which services are associated with which phone numbers Must be revealed. Often, a party confuses the mapping of a telephone number to multiple services and dials the telephone number given to the party to receive the wrong service. For example, if a caller dials a number while trying to reach a person, the caller may instead be connected to a facsimile machine. Another disadvantage of conventional systems is the lack of flexibility with respect to telecommunication services provided to subscribers. Subscribers may have to arrange for different people to access different services at different times. For example, a subscriber must ensure that telephone calls are directed to the subscriber's office during the weekly work period, but on weekends the telephone call is directed to his home or cellular telephone. You have to do that. The subscriber may also want to restrict who can contact him over the weekend. Still further, the subscriber may wish to have other people access to their voicemail. Unfortunately, some conventional systems do not provide such compatibility for telecommunication services. In addition, subscribers have difficulty managing a large number of communication services if each service has a different number. For example, if a subscriber wants to update various menus of its services (eg, voicemail) by telephone, then various repeated menu selections and presentations are required. U.S. Pat. No. 5,375,161 discloses a telephone system that provides multiple services to subscribers using a single telephone number. The subscriber can configure his telephone service with multiple voice menus and push buttons or dual-tone multi-frequency (DTMF) input. The subscriber can configure the selected telephone service and store the configuration in memory. Unfortunately, the system based on this patent suffers from the need to interact with the repeated menu selections while programming the subscriber's memory. In addition, the subscriber must recall the number associated with each memory and the contents of that memory that program their telephone service with swift operation. SUMMARY OF THE INVENTION The features of the present invention overcome the problems of conventional telecommunications systems and provide still additional benefits, as described in detail herein. Under the preferred embodiment of the present invention, a telecommunications system provides a single subscriber with multiple communication services associated with only one number. The subscriber can easily configure, manage and update these services through a network such as the Internet. The subscriber can access the service or a subscriber profile detailing the service specific to the subscriber via the Internet. The subscriber can quickly identify the particular service that the subscriber wants to reconfigure by choosing one of several choices displayed simultaneously on the screen. The choice of a large number of simultaneously presented options on such a screen is much faster than if the subscriber needed to hear a sequence of voice messages in an audio-based menu. The conventional problem seems to be to automatically access conventional telecommunications services by attempting to enter a large number of personal IDs (PINs) or other codes into the conventional system. That was done. The best embodiment, instead, provides enhanced security over conventional systems. For example, when a subscriber first accesses a web server under the exemplary embodiment, a "token" is associated with the subscriber's session. The subscriber's token is verified or authenticated based in part on the subscriber's password and Internet address. The present invention constitutes a computer-implemented method used in a communication system connected to the Internet. The method comprises the steps of: (a) receiving, via the Internet, a request to access a subscriber-specific record indicating a relationship with the system; and (b) transmitting, via the Internet, alternative data for the record. Receiving; and (c) updating the record based on the received replacement data. The invention also constitutes a device in a telecommunications network. The device has a memory and a network server. The memory stores a subscriber-specific record indicating the relationship with the system. The network server is connected between the memory and the Internet. The network server (a) receives the access request for the record via the Internet, (b) receives alternative data for the record via the Internet, and (c) the received alternative Requesting alteration of the record in the memory based on the data. BRIEF DESCRIPTION OF THE DRAWINGS Exemplary embodiments of the invention are described in more detail below with reference to the following drawings. FIG. 1A is a block diagram illustrating a first system configuration suitable for practicing the preferred embodiment of the present invention. FIG. 1B is a block diagram illustrating a second system configuration suitable for practicing the preferred embodiment of the present invention. FIG. 2 is a block diagram showing details of parts of the system of FIGS. 1A and 1B. FIG. 3 is a data or message flow diagram illustrating a subscriber initiation or login process. FIGS. 4A, 4B and 4C are flow diagrams illustrating the steps performed by the web browser, web server and token server of FIG. 2, respectively, during the login process of FIG. FIG. 5 is a front view of a computer screen showing a typical subscriber login screen. FIG. 6 is a front view of a computer screen showing a typical service selection screen. FIG. 7 is a front view of a computer screen showing a typical login failure screen. FIG. 8 is a data or message flow diagram illustrating the service selection process. 9A-9C are flow diagrams illustrating the steps performed by the web browser, web server, and token server of FIG. 2, respectively, during the service selection process of FIG. FIG. 10 is a front view of a computer screen showing a typical call routing options screen. FIG. 11 is a front view of a computer screen showing a screen of a representative guest menu option. FIG. 12 is a front view of a computer screen showing a typical override routing option screen. FIG. 13 is a front view of a computer screen showing a typical speed dial number selection screen. FIG. 14 is a front view of a computer screen showing a typical voice mail options screen. FIG. 15 is a front view of a computer screen showing a typical fax mail option screen. FIG. 16 is a front view of a computer screen showing a typical call screening option screen. FIG. 17 is a front view of a computer screen showing a typical error screen. FIG. 18 is a front view of a computer screen showing a representative last screen. FIG. 19 is a schematic diagram of a typical screen layout. FIG. 20 is a representative data flow diagram including a data flow for a token under the system portion of FIG. FIG. 21 is a representative subscriber profile with a representative field therein. FIG. 22 shows a typical data structure of a token. FIG. 23 is a typical directory structure used by the web server of FIG. DETAILED DESCRIPTION OF THE INVENTION Overview A system that overcomes the problems of the prior art is co-filed with an application entitled "Single Telephone Number Access to Multiple Communications Services," and assigned to the assignee of the present application and is similarly pending. It is disclosed in detail in U.S. patent applications. As disclosed in this application, the platform allows a wide variety of telecommunication services to be accessible by a single telephone number. Thus, for example, access to a paging service, a facsimile service, a routing service, a voice mail service, a calling card service, and a personal 800 number service is achieved by a single telephone number. Subscribers have complete control over access to these services. In particular, the subscriber can specify what services are available to whom and when. Thus, the first subset of services to which the subscriber subscribes is made available to the first party for the first time, and the second subset of services is made available to the second party for the second time. Available to the public. Further, only one party may access a different subset of services depending on when. The platform of the exemplary embodiment of the present invention also provides a system for making a variety of multiple calls from anywhere using the same telephone number and billing all calls to a single account. To provide. Subscribers are assigned a single telephone number, such as 800 or 888, which is free of charge. This one telephone number is used by another party ("guest") to reach the subscriber at any of the called telephone numbers programmed by the subscriber. In addition, the one telephone number will be used to send a fax to the subscriber, leave a voicemail message for the subscriber, or page the subscriber. . The subscriber can also program routing so that calls made to the one telephone number of the subscriber reach the subscriber at a variety of different locations. Also, as described above, each caller can reach a wide variety of services. As an example, a call from a certain caller may automatically generate and issue a page or be automatically placed into voice mail. Subscribers are assigned a wide variety of personal identification numbers (PINs). Each PIN is a short sequence of alphanumeric characters. Each PIN is provided with a different service configuration. One of the PINs is only assigned for use by that subscriber. Then, when the subscriber calls his assigned telephone number and enters his PIN, the platform recognizes that it is the calling party and calls only the subscriber. Providing services. Other PINs may be assigned different service profiles. These PINs are spread out to the appropriate parties and specify what services will be available to those parties. For example, a first PIN is given to a member of the subscriber's family, while a second PIN is given to the subscriber's business associate. As a result, family members will have access to the first set of services, and business associates will have access to the second set of services. Multiple outbound calls to domestic or international destinations are billed to a single account. The account may be a calling card account, a credit card account, or an account created specifically for grooving the service. As a result, the subscriber does not need to enter the calling card number multiple times when making a wide variety of calls. Subscribers can also access their accounts and update the maintained service profile. As an example, a subscriber can change the terminating telephone number used to reach himself. Similarly, the subscriber can change which callers are sent to voicemail and which callers generate automatically sent pages. Under the above-cited U.S. patent application, subscribers access and modify their service profile by dialing their account. Unfortunately, subscribers generally can only enter dual-tone multi-frequency (DTMF) inputs, such as 12 DTMF buttons on a typical telephone. This limits DTMF input. Under one embodiment of the present invention, subscribers can view their subscriber profile through a graphical user interface accessed by the subscriber over a computer-implemented network such as the Internet or an intercommunication network. Services can be easily configured, managed, and updated. When on the Internet, subscribers of the World Wide Web ("Web") identify to each individual calling their one number which communication services they wish to provide. Access their profile through Access. Under one embodiment of the present invention, a subscriber can use any web browser and internet access provider to access his or her subscriber profile. By entering a particular Internet address on their web browser, the subscriber reaches a web server that forms part of a system according to one embodiment of the present invention. The system, including the web server, authenticates each subscriber. The system then provides a graphical user interface (GUI) in the form of a user-friendly web page that subscribers use to update their subscriber profile. These updates are recorded and updated in real time nearby, so that the next call generated to the subscriber's number will be served by the updated profile. II. Platform architecture FIG. 1A is a block diagram illustrating a first system architecture for implementing an exemplary embodiment of the present invention. Here, the system architecture is part of a larger telecommunications network. The system has a platform 10 that contains a wide variety of components. Platform 10 provides one telephone number access for a wide variety of telecommunication services for one subscriber. A subscriber is a customer who is assigned one telephone number in this environment. The one telephone number will be accessed by both the subscriber and the caller (eg, guest) to the subscriber. The call originator 12 described in FIG. 1A indicates the origination of a call to the platform 10. The call is from a subscriber or a calling party searching to reach the telephone number assigned to the subscriber. The call may also be from a facsimile machine or a computer. The call reaches the service provider's switch network 14 over a number of routes, including local exchange carriers, private lines, leased access lines, or international carriers. The switch network 14 routes the call over a release link trunk (RLT) 16 to an automatic call distributor (ACD) 18 in the platform 10. . RLT 16 is a voice trunk that is released from the call when the call arrives back at switch network 14 by ACD 18. The ACD 18 routes incoming calls to the appropriate components within the platform to properly handle incoming calls. ACD 18 is a conventional digital matrix switch with a program for performing call queuing and distribution. A suitable ACD is DMS-100 from Northern Telecom. The platform 10 also includes an application processor (AP) 46 provided with an ACD 18. The AP may be a dedicated computer system that performs intelligent application processing on the ACD 18. The off-load of certain functions performed by ACD 18 to AP 46 allows the ACD to focus on performing switching and queuing functions. The AP 46 connects to the ACD 18 via an integrated services digital network (ISDN) means of a switch / computer application interface (SCAI) link 30 of a switch / computer. Linked. The platform 10 includes an audio response unit (ARU) 20 that provides voice response and menu routing functions to the caller. ARU 20 facilitates entry by the caller's selection of DTMF digits, such as by pressing a key on a telephone keypad. ARU 20 may provide various automated menus that callers may navigate to reach a desired service. The ARU 20 includes a network audio server (NAS) 22. The NAS 22 is a server computer having a voice telephone interface to the ACD 18. The NAS 22 is linked to the ACD 18 via a multiplexed voice trunk 23 and typically provides a voice interface to the caller. ARU 20 also includes an automated call processor (ACP) 24. The ACP 24 provides the ARU 20 with intelligent call processing func- tions. ARU 20 is responsible for handling all of the initial city-bound calls for platform 10. The ACP 24 operates by executing a script. The script guides the caller through a series of menus, accepts caller input, makes decisions based on the caller input, and provides another destination to provide the appropriate service. Perform functions such as forwarding calls to The ACP 24 prompts the NAS 22 to play the script, or collects DTMF digit input, plays various recorded messages, and sends a call to direct the caller to another destination. Encourage caller action. The AC P24 is a high-grade computer such as an IBM RS / 6000 from International Business Machines Corporation or a DEC Alpha-based computer from Digital Equipment Corporation. -It may be implemented on a mid-range computer. The script executed by the ACP 24 determines which communication services should be provided to the caller and then provides those services by instructing the NAS 22 to forward the call to the appropriate service provider. . The script executed by the ACP 24 is customized for the subscriber by using the subscriber profile, such as the data entered. The subscriber profile is stored for use by the platform, as will be described in more detail below. The subscriber profile specifies which services are available to subscribers and guests and which called telephone numbers should be used. The NAS 22 and the ACP 24 are linked by, for example, an Ethernet (trademark) local area network (LAN) 26 (Ethernet is a trademark of Xerox Corporation). The platform 10 includes one or more operator consoles 28. These operator consoles 28 are specialized workstations operated by human operators. Operator console 28 performs many of the same functions as performed by ARU 20. In particular, a human operator at the operator console 28 performs the appropriate scripts, action enhancements and transfers. The platform 10 includes a voice mail / fax mail platform (VFP) 32. The platform collects, stores, and manages both voicemail and facsimile messages. It collects voicemail and facsimile messages from the switch network 14 via a trunk 33 of a Group D special feature (FGD). Calls requesting voicemail or facsimile services are forwarded from the ARU 20 to the VFP 32, as described in more detail below. The transfer occurs with the aid of the ACD 18 and the switch network 14. The VFP 32 is also connected to the Ethernet LAN 26. The platform 10 includes a variety of network implementation distribution servers (NIDS) 27, 34 and 36. Each of these NIDSs may be embodied as a separate computer system. NIDS is redundant, and serves to store information in a database that typically contains subscriber profiles. In the system configuration shown in FIG. 1A, NIDSs 27, 34 and 36 are all connected to Ethernet LAN 26. The NIDS 27 is shown as part of the ARU 20 so that the ACP 24 can access the subscriber profile directly without having to go through the Ethernet LAN 26. Typically, the ACP 24 submits a database query to the NIDS 27 to obtain data on the subscriber profile. The subscriber profile determines what scripts should be played for the caller, what communication services can be provided to the caller, and what called telephone numbers And is used to determine if the mailbox identifier should be used. VFP 32 offers to NIDS 34 for subscriber profile information and voice mail or facsimile message processing. The NIDSs 27, 34, 36 are also interconnected by a token ring local area network (LAN) 38. This LAN 38 is used for updates made to subscriber profiles, and stores the database stored on a number of NIDSs on a mainframe profile management system 40 (dedicated mainframe or other suitable computer system). Used to keep up with the centralized profile database maintained by. When a change or update occurs in one of the NIDSs 27, 34, 36, the affected NIDS sends a message to the mainframe profile management system 40. This allows the mainframe profile management system 40 to update the centralized profile database, and then ensure that each of the profile databases on other NIDSs is updated. The platform 10 includes one or more web servers 42. These web servers 42 are connected to the token ring LAN 38 and provide websites accessed by subscribers through the Internet 44. As will be described in greater detail below, a web page or a page on web server 42 allows a subscriber to update a subscriber profile for that subscriber over the Internet. These updates are sent to the mainframe profile management system 40, which updates the information stored in the NIDSs 27, 34, 36 sequentially. Alternatively, the NIDS may reside on a web server. The NIDS provided on the web server updates the profile information and forwards the update to the mainframe profile management system 40. Web server 42 may be part of an intranet rather than the Internet, as will be appreciated by those skilled in the art. Still further, the web server 42 may be, more generally, a program that provides a user interface to the subscriber and allows the subscriber to update service profile information with a computer, which is well known to those skilled in the art. If you can understand. Thus, the program may be a program that resides on a server that is part of a distributed system, such as a LAN or a wide area network (WAN). FIG. 1B illustrates a second system configuration suitable for practicing the exemplary embodiment of the present invention. This second configuration differs from the first configuration in several respects. First, there is no NIDS in the ARU and no NIDS associated with the VFP. In this second system configuration, database queries from the ACP 24 in the VFP 32 are sent to the NIDS 36 through the Ethernet LAN 26. Second, the VFP 32 reaches the ACD 18 directly via the FGD trunk line 33 '. As a result, the transfer of the call from the ARU 20 to the VFP 32 is performed by the ACD 18 inside the platform 10. There is no need to transfer calls outside the platform. The system configurations shown in FIGS. 1A and 1B are intended to be merely exemplary, as will be appreciated by those skilled in the art. For example, a wide variety of platforms can be implemented within a given telecommunications system. Further, a wide variety of operator consoles 28 can be provided within platform 10 and a wide variety of ACDs can be provided. Each ACD will have its own associated AP. Furthermore, a wide variety of ARUs can be provided within a given platform range, and a single VFP can be combined with a wide variety of ACDs. Still further, the components may be connected by different types of LANs, or by different interconnects than those shown in FIGS. 1A and 1B. For further details on platform 10 and its associated services, see the titles of the inventions "Single Telephone Number Access to Multiple Communications Services", "Multiple Routing Options In A Telecommunications Service Platform", and "Outbound Calling Services On A Telecommunications Service Pl, respectively. atforms, "Integrated Messaging Platform," and "Integrated Voicemail and Faxmail Platform for A Communications System" are also disclosed in further detail in pending US patent applications. They have been filed concurrently therewith and assigned to the common assignee of the present application. Referring to FIG. 2, the logical architecture of the connection between the platform 10 and the Internet 44 is shown. The architecture is logical, in which many server components can be implemented on shared resources of a computer (eg, memory, processor, etc.). Although three web servers 42 are shown in FIG. 2, the platform 10 may use fewer or more web servers, depending on the amount of Internet traffic on the platform. The web server 42 can use a separate application server (not shown). Each application server is dedicated to one or more applications. This application can be used to manage subscriber profiles, personal web space for subscribers, message centers for email, voicemail and / or fax mail, subscriber profiles for smart cards, etc. It is something. Additional application services can add additional applications to the respective web servers 42 in addition to the platform 10. The subscriber can use any of a variety of web browsers 60, such as an Internet Navigator ™ by Netscape Corp. The subscriber accesses the Internet 44 by using any Internet service provider (ISP). Through a web browser 60, the ISP and the Internet 44, the subscriber accesses one of the web servers 42. The web server 42 operates a proprietary web operating system, such as a Netscape Commerce Server HTTP Server, in a secret mode. As used herein, “secure” refers to using a secure socket layer (SSL) or between the web browser 60 and the web server 42. Refers to another way to ensure that a connection cannot be intercepted. The use of SSL prevents data or tokens (described below) from being eavesdropped on without having physical access to the subscriber's platform on which the web browser 50 is running. In response to the request for access to the subscriber profile, web server 42 requests a token from token database 64 through token server 62. Although in FIG. 2 the token server 62 is shown as a separate block connected to each of the web servers 42, each web server shall have its own token server and thereby have a common The hardware platform may be shared. Token information is maintained by the token database 64. The token database 64 not only stores information about the token, but also provides an additional database of information such as passwords, subscriber ID codes, and the like. Thus, here, the token database 64 is queried so that it can be exchanged as the token database 64 and as the database 64. Token server 62 and token database 64 are used for subscriber login and authentication, and are particularly useful for platform 10 security, as described below. Once the confirmed token is issued by the token server 62, the token is used for track state information for subscriber communication with the web server 42 ("web session"). The issued and verified token allows the subscriber to access the subscriber's profile stored on one or more NIDSs 27, 34 and / or 36 via LAN 38. To give permission. Web server 42 performs two main tasks. First, the web server 42 authenticates the user through an initial subscriber authentication procedure at login, as described below. Second, web server 42 sends at least a default page or screen for the service to the subscriber. It will be the first screen presented to the subscriber, as described below. The optional NIDS 66 may also be connected to the web server 42 or may reside on the web server 42. The NIDS 66 communicates with the LAN 38. NIDS 66 sends subscriber profile updates to mainframe profile manager 40 over LAN 38. As mentioned herein, NIDS 66 is separated from web server 42 by router-based firewall 117 (FIG. 3). Firewall 117 also separates token database 64 from token server 62 and web server 42. Another firewall 115 shields web server 42 from Internet 44. Generally, a "firewall" is a combination of hardware and software that limits a computer or group of computers from exposure to outside attacks. To this end, the firewall 115 strengthens the boundary between the Internet 44 and the web server 42, while the firewall 117 connects the token database 64 and NIDS 66 (and other NIDS databases) with the token server 62 and web server 42. Strengthen the boundaries between. As shown in FIG. 3, the platform 10 uses a first firewall 115 between the subscriber and the subscriber's web browser 60 and web server 42. The second firewall 117 extends between the token server 62 and the token database 64. As a result, the DMZ (a data management zone) connects the web server 42 and the token server 62 from the Internet 44 (by the first firewall 115) and the token (by the second firewall 117). It will spread between the first and second firewalls 115 and 117, separating from the data stored in the database 64. III. System operation Access to the subscriber profile begins with the login and authentication process. Hereinafter, an exemplary login and authentication process for a subscriber will be described with respect to the data flow diagram of FIG. 3, the flowcharts of FIGS. 4A-4C, and the screen images of FIGS. 5-7. The flowcharts of FIGS. 4A-4C present the steps performed by web browser 60, web server 42, and token server 62 in chronological order. In step 202 of routine 200 (FIG. 4A), the subscriber interacting with web browser 60 causes that web browser to screen for a "get login" request to one of web servers 42. In step 202, the subscriber enters "directline. MCI. com. Request a connection to the web server 202 by entering an appropriate URL (uniform resource locator) such as "". This URL can be assigned to one or more of the web servers 42. Using any desired algorithm, such as round-robin addressing, one of the web servers 42 is selected from the set of web servers. It has a text document or a collection of HTML (Hypertext mark-up language) pages, where the wording “screen” and the wording “page” are: Generally, the web browser 60 is used as a replaceable one.The web browser 60 is a well-known hypertext transport protocol (HTTP). transport protocol)) to access individual HTML pages, so that an exemplary URL that the web browser 60 provides to the Internet 44 is "HTTP: // direcline. mci. com. The token server 62 normally listens for a specific command on a TCP (Transmission Control Protocol) port for a request for a token from the web server 42. In turn, it requests confirmation of the token from the token database 64. The HTML page is sent from the web server 42 to the web browser 60. As is well known, HTML pages are, in particular, documents for display on a computer screen. The first HTML page checks the web browser 60 for compliance with all required standards or language requirements and displays a welcome message, for example, the first HTML page. An HTML page is an application with a short web browser 60 Or that it can interpret or interpret applets written in a given language such as Java or Java.If the web browser 60 does not comply, the web server 42 In response to a "get login" request from web browser 60, the web server issues a suitable message indicating that the profile cannot be used to access the subscriber's profile and / or update the profile. 42 sends a request for a single use token to the token server 62 (FIG. 4B) in step 304 of the routine 300. In step 304, the web server 42 also receives the subscriber's IP address. The IP address is associated with the subscriber's initial request. In response to the token request, the token server 62 issues a token in step 404 of the routine 400 (FIG. 4C). Performed by the web server 42 and the token server 62. In step 406, the token server 62 updates the token database 64 from which the selected token was issued, along with additional data such as issue time and the ID of the receiving web server. In step 408, the token server 62 sends the selected token to the web server 42. In step 310, the web server 42 sends the subscriber's Internet Protocol (IP) address, such as an Internet Protocol (IP) address. network With continued addresses, and records the ID of the selected token (Fig. 4B). In an exemplary embodiment, the web server 42 selects one of a variety of differently encrypted or scrambled applets stored in a database within the web server at step 318. . The web server 42 records the selected applet in the database, along with the ID of the selected token and the IP address of the subscriber. In step 312, web server 42 sends a login screen to web browser 60. Further, the web server 42 scrambles the token with the selected applet, and sends the scrambled token and the applet to the web browser 60. An exemplary initial login screen displayed by the web browser 60 to the subscriber is shown in FIG. The login screen 120 is a page on which a script of a common gateway interface (CGI) is drawn, like other screens or pages described here. This page, as will be described more fully below, contains a single-use token embedded, a small application program (applet), and a user for identifying or entering information such as the user's ID code and password. And form fields for In step 214, web browser 60 receives login screen 120. This login screen 120 instructs the subscriber to enter certain subscriber data. For example, a subscriber is required to enter his or her user ID code and password (FIG. 4A). The user ID code may be the same as the user's 800 number (one telephone number) for convenience. The user ID code will probably be a non-secret number. Conversely, a password is a secret alphanumeric string selected by the user, such as a six digit number. The password is the same as the password used by the user to access the user options through ARU 20. At step 216, web browser 60 sends the user ID code, password and token to web server 42. In step 318, web serve 42 authenticates the login request. The web server 42 compares the data recorded in step 310 with the received data and verifies that the subscriber's IP address, token ID and other data are interrelated. As a result, the web server 42 in step 310 confirms that the subscriber has not crafted the data to change the token. In step 318, web server 42 may also compare its IP address to a table of non-conforming IP addresses stored in a database. The non-conforming IP address table lists IP addresses that may attempt to break the security of platform 10. If the received IP address matches one of the addresses on the non-conforming IP address table, then web server 42 sends a login failure screen (as described below with respect to FIG. 7). The non-conforming IP address table can be stored in a database at the database 64 or the web server 42. Each record of a non-conforming IP address contains the following fields: Here, the numbers in parentheses correspond to the number of characters or bytes for each field. 1. 1. Incompatible IP address (16); 2. The number of invalid accesses attempted by the IP address; 3. First time IP address accessed platform 10 (4); Last time when the IP address failed to access the platform 10 (4); In step 320, the web server 42 sends a token to the token server 62. In step 422, the token server 62 confirms the token (FIG. 4C). The token server 62 sends a request to the token database 64 or actually accesses the token database 64 for data corresponding to a previously issued token. If the token is still the same as previously issued in step 404, then token server 62 sends a confirmation valid response to web server 42 in step 424. At step 320, web server 42 also verifies the subscriber data (eg, user ID code and password). Web server 42 sends a request to database 64 or accesses database 64 to access the password corresponding to the user code. If the password stored in database 64 matches the password received in the subscriber's data, then web server 42 validates the subscriber's data. On the other hand, if the passwords do not match, or if the token has been changed, the web server 42 invalidates the request, or the token server 62 sends a confirmation invalid response to the web server. I do. In step 326, the web server 42 sends a service selection screen to the web browser 60 in response to the validity confirmation response message from the token server 62 (FIG. 4B). The token fits into its service selection screen and all subsequent screens for the current session with the subscriber. As a result, the token cycles through the current session with the subscriber until the subscriber logs off, as described in more detail below. When the web server 42 determines that the password is not correct or receives a response message indicating that the confirmation is invalid from the token server 62, the web server 42 transmits a login failure screen. An exemplary login failure screen 124 is shown in FIG. The user must then attempt a second login by repeating the steps described above. During each login attempt, web server 42 increments the login counter and records the subscriber's IP address in a non-conforming IP address table. If the subscriber logs in successfully, the login counter is reset to 0 at that time and the IP address of the subscriber is removed from the non-conforming IP address table. If the user fails to log in after a predetermined number of times (eg, login counter = 3), then web server 42 in step 326 records the subscriber's IP address in the nonconforming IP address table. Thereafter, whenever the subscriber's IP address is encountered, a time-out counter that delays the login attempt is reset between each login attempt. The number of trials during login is also recorded in the nonconforming IP address table. Subsequently, at step 228, web browser 60 receives either a service selection screen or a login failure screen (FIG. 4A). An exemplary service selection screen 122 is shown in FIG. An exemplary subscriber service selection will now be described with reference to the diagram data or signal flow in FIG. 8 and the flowcharts in FIGS. 9A-9C. After logging in, the subscriber selects an option or changes data relating to one of the subscriber's telecommunication services associated with the screen displayed by web browser 60. For example, the subscriber selects one of the services shown on the service selection screen 122 of FIG. In step 25 of the routine 250, the web browser 60 notifies the web server 42 of the selected service (FIG. 9A). In steps 354 and 356 of routine 350, web server 42 authenticates the subscriber's request (FIG. 9B). On the other hand, the token server 62 confirms the request in step 458 of the routine 450 and, in a manner substantially similar to that described above with respect to routines 300 and 400, sends a confirmation valid or invalid (FIG. 9C). Routines 250, 350 and 450 are executed by web browser 60, web server 42 and token server 62, respectively. In step 362, web server 42 processes the request and issues a response, possibly with a new screen, to the subscriber. Web server 42 dispatches any changes to the subscriber's profile to mainframe profile management system 40 via LAN 38, as described herein. For example, the subscriber may select one of the service options from the screen of FIG. 6 and, in response, select a service option such as the screen shown in FIGS. 10-16 (described below). The screen for the service may be received. When the web server 42 receives the confirmation invalid response message from the token server 62, the web server issues a "service not available" screen. For example, if the subscriber's IP address matches an address in the non-conforming IP address table, or if the subscriber's token has expired, web server 42 sends a login failure screen 124. In step 264, web browser 60 receives a response and / or screen from web server 42 (FIG. 9A). Depending on the processed request, the user will be able to select additional services. Then, the steps under routines 250, 350 and 450 are repeated for each additional service request performed by the subscriber. As a result, when the subscriber makes his choice on one of the service screens, the token originally issued during login will accompany that choice. This token is validated for all accesses attempted by the subscriber during service selection. Next, selection and updating of a subscriber's profile will be described with respect to the screens of FIGS. 6 and 10-18. Exemplary embodiments of the present invention generally allow subscribers to update their profile, including the addition or modification of telephone numbers in their find-me routing, Change the schedule in the follow-me routing, add default or alternative routing, and many other possibilities described herein. These updates are entered by the subscriber via a user-friendly GUI with the screen shown in FIGS. 5-18. The screens are provided by the web server 42 to the subscriber's web browser 60. When the subscriber updates the service in the profile, web server 42 sends the updated profile to mainframe profile management system 40 via LAN 38. Mainframe profile management system 40 updates the database of centralized subscriber profile records and distributes the updated records to distributed NIDs 27, 34, 36 and 66. After the login and authentication process, web server 60 displays service selection screen 122 of FIG. 6 as described above. The subscriber can select one of several service options, such as call routing, speed dial numbers, voice mail, fax mail, call screening, and the like. Each subscriber service option on the service selection screen 122 has a hypertext link that links to the associated screen as follows. The call routing option links to screen 128 of FIG. 10 (which sequentially links to screens 130 and 132 of FIGS. 11 and 12). The speed-dial number option links to screen 134 of FIG. The voicemail option links to screen 136 in FIG. The fax mail option links to screen 138 of FIG. The call screening option then links to screen 140 of FIG. The user may select one of the service options shown on the screen of FIG. 6 by positioning the cursor and clicking on the service, or by other known user input and selection methods. Is also good. The service selection screen 122 also has a log off button 127. By clicking on the log off button 127, the subscriber can immediately log out of the subscriber's current session. The web server 42 immediately ends the time limit attached to the current token, and sends the login screen 120 to the web browser 60. As shown in FIG. 10, if the subscriber selects the call routing option from the service selection screen 122, the web server 42 sends this screen 128 for display to the subscriber by the web browser 60. I do. In the call receiving section 144 of the screen 128, the subscriber receives a call on his account by selecting one of the two buttons displayed on his computer screen. Specify whether or not to If the subscriber selects the button that does not accept the call, then the caller to the subscriber will make a call indicating that the subscriber has not received a call through one of his telephone numbers. The message that informs the callers will be received. In a choose selections section 146, the subscriber specifies whether the guest caller should receive the guest menu or be subject to override routing. I do. By selecting the guest menu to be selected, the web server 42 sends the guest menu screen 130 to the web browser 60. On the other hand, when the subscriber has not selected any menu to be selected, the web server 42 sends an override routing screen 132 to the web browser 60. Hereinafter, both screens will be described. In a subscriber unavailable section of screen 128, the subscriber specifies the handling of calls received when the subscriber cannot be contacted (alternate terminal). Under section 148, if the subscriber is unable to contact the subscriber, the call is terminated to the subscriber's voicemail, pager, voicemail and pager, or closed for a guest call Determine whether to receive a message (a closing message). After selecting or updating any of the options presented on screen 128 or other screens discussed herein, web server 42 provides status messages on the screen for the subscriber. For example, after the subscriber selects the closed message option in the alternate terminal section 148, the web server 42 will hear "a caller will hear a message asking him to try the call later."("Callers will hear a message asking them to try their call later,"), and the web browser 60 displays it to the subscriber on the screen 128. As shown in FIG. 11, when the subscriber selects the guest menu to be selected on the call routing screen 128, the web server 42 displays the guest menu screen 130 for display by the web browser 60. Send In a Findme routing section 150, a guest menu screen 130 provides options for the subscriber to plan the routing of calls to them, and continuously detects the subscriber. Provide up to three numbers to try. In an exemplary embodiment, the subscriber enters up to three numbers and the number of rings to be performed on that number before trying an alternate number. Leading "1" numbers and all non-numbers (eg, parentheses and dashes) in the national number are removed from all numbers entered into the three boxes shown in section 150. The number of ring tones is converted to seconds based on a formula that multiplies the number of ring tones by six, and three rings (18 seconds) if the subscriber does not enter any numerical value. Is preferably stored in the subscriber's profile with a default value of 0 to 8 seconds are interpreted as 1 ring, while all numbers greater than 8 seconds are divided by 6 and rounded up to the number of rings, up to a maximum of 16. In the second selection section 152, the guest menu screen 130 indicates that the guest caller can leave both a hoist mail and a fax. The subscriber can also choose whether to allow the guest caller to send the page. By communicating with the operator at operator console 28 (FIG. 1A), only certain options, such as sending a fax, may not be selected. Referring to FIG. 12, the override routing screen 132 confirms to the subscriber that he wishes to route the guest's call to a particular destination, thereby presenting a guest menu. Make a detour. The subscriber must confirm the override routing selection under the override routing screen 132. Referring to FIG. 13, a speed-dial number screen 134 allows the subscriber to enter up to nine speed-dial numbers through the web browser 60. As shown in FIG. 13, the speed-dial number screen 134 provides a number entry section 154 that provides nine boxes for the user to enter nine speed-dial numbers. Web server 42 preferably verifies all numbers received from web browser 60 (as input by the subscriber). Confirmation of the numbers entered on screen 134 and the other screens described herein ensure that a valid, unblocked international number is entered for all international telephone numbers. For the domestic number, the web server 42 confirms that 10 digits are input, and a valid numbering plan area (NPA) or “area code” is assigned to the 10 digits. Confirm that it is entered. In addition, web server 42 may indicate whether 976 blocking is enabled if the entered number is a "976" number, or whether other specified numbers are blocked (eg, certain North American A directory plan (NADP (North American directory plan) number) can be determined. Assuming the web server 42 confirms that the number entered by the subscriber is acceptable, the web server then forwards the number over the LAN 38 to the mainframe profile management system 40. Referring to FIG. 14, the voicemail service screen 136 allows the subscriber to be paged whenever the subscriber receives a voicemail. In FIG. 15, the fax mail service screen 138 provides the subscriber with the option of also allowing him to be paged whenever he receives a fax message. Fax mail service screen 138, in the exemplary embodiment, displays the subscriber's fax number. Referring to FIG. 16, the call screening service screen 140 provides a call screening selection section 156. In section 156, the subscriber can determine how incoming calls are screened. For example, it may be determined that a screen is to be screened by name alone, by phone number alone, or by name and phone number. If a guest caller fails to provide their name, platform 10 will provide the guest caller's telephone number. As shown in FIG. 17, an exemplary error screen 160 is displayed when a subscriber fails to enter, ie, enter the appropriate data. The first message 162 on the error screen 160 indicates that "Your first number may not be blank". Web server 42 displays the first message 162 if the subscriber did not enter the first number in an appropriate location, such as within section 150 of guest menu service screen 130 (FIG. 11). Send to web browser 60. The second message section 164 provides the subscriber with an indication that certain numbers entered by the subscriber are blocked or invalid. As described above, if the subscriber enters any numbers, web server 42 will verify those numbers. If the web server recognizes the invalid number, it sends a second message 164 to the web browser 60. Referring to FIG. 18, a final or exit screen 166 is shown. When the subscriber enters appropriate data that is validated and accepted by web server 42, the web server sends the data to mainframe profile management system 40 to update the subscriber's profile. After successfully updating the profile, the web server 42 sends an exit screen 166 to the web browser 60 and provides the subscriber with an appropriate message indicating that the profile update was successful. For example, screen 166 shows "Your guest menu options have been succes sfully updated." Referring to Figure 19, an exemplary HTML layout for pages and screens is shown. A photo frame 170 in the upper left corner displays a graphic or other image. And the photo frame 170 in the exemplary embodiment displays a continuous static icon between each service screen.The title frame 172 in the upper right corner of the screen is The title frame 172 may have a height of 40 pixels and a width determined by the available screen size, and the graphics displayed in the photo frame 170 may include: Specific services requested by the subscriber and displayed on the screen. In an exemplary embodiment, the title frame indicates the title of the application accessed by the subscriber, which also displays the service provider's logo, such as "MCI". The information displayed in the title frame 172, like the photo frame 170, does not change throughout the entire session with the subscriber as long as the subscriber remains logged into the platform 10. At the bottom of the screen The bottom frame 174 has hypertext links to various other services provided by the platform 10. The bottom frame 174 has a height of 40 pixels and a width determined by the size of the available screen. Can be provided. In a typical embodiment, the bottom frame 174 or other portion of the screen contains hypertext links to other services handled by the operator of the platform 10, such as MCI services, as well as other web sites. Such a link allows the subscriber to effectively cancel the login process and move on to other services or sites, if requested.List on the left part of the screen Frame 176 displays other, screen-specific, hypertext links to applications and screens within the application accessed by the user List frame is 160 pixels wide And depending on available screen size It can be as high to be constant. Text frame 178 displays the data requested by the subscriber. Both text frame 178 and list frame 176 change to every new screen selected by the subscriber. Text frame 178 and list frame 176 display the screen described above in FIGS. 5-18. Referring to FIG. 20, an exemplary data flow within a portion of the platform 10 of FIG. 2 is shown. The data flow shown in FIG. 20 corresponds to that described above with respect to FIGS. 3, 4A-4c, 8, and 9A-9C. Typically, the token database 64 is accessed by the token server 62 to generate a new record, read the record for a given token value, and update the record for the given token value. Provided, a token database service. Each update service or application is executed by the web server 42, which accesses the token database 64 and deletes outdated records on a periodic basis (eg, hourly). The web server 42 continuously scans the token database 64 and deletes records relating to expired tokens. The data provided by the web server 42 is stateless. State information is maintained by writing through a cache database on NIDS and indexed by tokens (each of which is unique). As a result, there is no need to synchronize data between various web servers 42. Each web server 42 also provides one or more services. The services provided by web servers 42 are distinguished by their location in the web server's document root (described below). Token server 62 is a client of token database 64 and issues tokens to web server 42 during login attempts. The issued token, once confirmed, is used to circulate state information for connection by one of the web servers 42. As a result, the token service 62 performs three important tasks. (1) issue a single-use token during subscriber authentication or login; (2) confirm a single-use token; and (3) multi-use token. (If such a token is used). As mentioned above, each token must be unique for every login request. Referring to FIG. 21, an exemplary record for a subscriber profile is shown as record 180. Record 180 includes a speed-dial number, a primary terminal number and a time-out value (number of rings) for the guest menu routing service, whether the subscriber is paged based on the receipt of the message, It has a number of fields, such as the status of call screening. Records 180 corresponding to the subscriber profiles are stored in 27, 34, 36 and 66 NIDs. The fields of the record 180 are generally self-explanatory by reference to the detailed description provided herein. The web server 42 and, broadly speaking, the platform 10 may be used by infringers, hackers, and others with hostility to adversely affect the platform 10 or to retrieve data without authentication. Must not be intercepted. Therefore, the web server 42 preferably operates sleeping programs (secure daemons) that cannot be intercepted. For example, the web server 42 operates a sleeping program of HTTP that cannot be intercepted. As is known, a "sleeping program"("daemon") is a virtual agent software program that processes continuously as on a UNIX server and supplies resources to client systems over a network. It is. Generally, sleeping programs are background processes used to handle low-level processing system tasks. The token used here also provides security for platform 10. Referring to FIG. 22, an exemplary token 500 is shown. The token 500 includes the following fields with the exemplary number of bytes or characters represented in parentheses. 1. Version 502 (1); 2. Use flag 504 (single versus multiple use) (1); 3. Token value 506 (16); 4. Subscriber IP address 508 (16); 5. User ID code 510 (16); 6. given time 512 (4); and Disappearance 514 (4). The IP address field is large enough to hold extended IP version 6 access when required. A time-out timer is associated with the value of the given time 512 and expiration time 514 of each token so that unused tokens for a certain period of time (eg, 10 minutes) are confirmed invalid by the web server 42. To The token value 506 has 16 characters. Here, each character has 62 possible character values, which are selected from the set (W-9, az, AZ). Characters at positions 1 and 2 of the token value 506 are fixed and assigned to the token server 62. If a wide variety of token servers 62 are used, the characters at positions 0, 1 and 2 uniquely define each token server, thereby ensuring that the tokens used by each web server 42 are unique. become. The character at position 0 is used to identify the physical location of the token server 62. The character at position 1 identifies the server at the physical location. On the other hand, the character at position 2 has a reserve value, which can be used for identification of the version number of the token server 62 or other information. The remaining 13 characters of the token value 506 are continuously generated using 62 possible character values. Character positions 10-15 are assigned to the current time for platform 10 (in token server 62 set-up). The system time (a 32-bit quantity) is calculated as a 6-digit base 62 number, which is placed at 10-15. The token value is continuously incremented throughout the positions 3-15, with position 3 being the lowest position. In the character value, the order of the values of the digits from the upper to the lower is as follows. "Z"-"a", "Z"-"A" and "9"-"0". As a result, if the system time is calculated with a 4-byte value, the token server 62 generates a unique token. It calculates a 6 base-62 characters in positions 10-15 at positions 10-15. This means that for any given token server 62, the token server 62 7 (35 * 10 12 ) Does not generate more than one token. As a result, the probability that the infringer actually guesses the token value is 4.7 × 10 28 Becomes one of the following. Even with a correctly assigned token value, the intruder passes through the firewall 115 because the subscriber's appropriate IP address must be correct and the token time must not expire. There is no guarantee that it will succeed. As described above, each token fits within a service-specific screen that web server 42 sends to web browser 60. If the given screen contains a formwork, the token may be in a hidden field of that formwork. If the screen contains an applet, such as a Java applet, the token may be a parameter of the applet. If the screen contains a hypertext link (eg, a hypertext reference (HREF) specifying the name or URL of the file to which the hypertext link points), the token It may be a part of itself. Typically, the particular value of a given token does not necessarily need to be kept unintercepted. Token security is provided by the use of SSL within the platform 10, the expiration or timeout of the token, and the linking of the token to the subscriber's (client) IP address. In the exemplary embodiment, all HTML pages that the web server 42 sends to the web browser 60 are shared by a common, such as Perl-based, Common Gateway Interface (CGI) script. Generated using common rules in the language. As is well known, CGI scripts are a standard way to extend sleeping programs in HTTP and are commonly described using Perl, C or shell scripts. All accesses to the web server 42 by the web browser 60 are transferred to the description of the CGI script. Referring to FIG. 23, all CGI scripts are preferably located in directories within web server. Then, the directory is not in the document-root directory of the sleeping program of HTTP, and thereby provides security to the web server 42. As mentioned above, authentication of each request and issuance of a valid token is required for every subscriber's request and thus at the start of every script. Each application on the web server 42 has its own document root and CGI scripts (cgi-bin), templates (templ), images, Java class libraries and, if necessary, image maps (map). It has an associated collection of directories. The structure of an exemplary welcome server directory on the web server 42 is shown in FIG. As shown in FIG. 23, the document root directory is separated from the server root directory. The document root directory holds only welcome and access failed / denied HTML pages for security. These directories are mapped through server instructions so that they can be accessed by application-specific URLs. As with CGI scripts, many applications may store libraries of images and classes. As shown in FIG. 23, distributed objects are maintained in a separately distributed directory tree. There is no URL map for these distributed objects. However, instead, the distributed object is accessed at startup of the platform 10 through its application-specific URL linked to the distributed object. The common server root directory contains the processing parameters for web server 42. Such information is maintained in a common database to maintain the same environment for a wide variety of web servers 42. While particular embodiments and examples of the present invention have been described herein for purposes of illustration, without departing from the spirit and scope of the invention, as will be appreciated by those skilled in the relevant arts, Various equivalent modifications can be made. The teachings of the present invention provided herein may be applied to other communication or network systems and are not necessarily limited to the exemplary telecommunications systems described above. For example, while embodiments of the present invention have been described above generally for use with a telecommunications platform 10, the present invention is not limited to computer systems that provide updates to user records by means of the World Wide Web. It is equally applicable to other communication systems, such as networks. Certain options under embodiments of the present invention have been described as generally occurring in a serial fashion, but more or less simultaneously, or in another order different from that described herein. It will be appreciated by those skilled in the relevant art that performing some processing is entirely within the scope of the present invention. The features of the present invention have been described above in relation to a single telephone number telecommunications system providing a number of functions, such as call routing, speed dial numbers, voice mail, fax mail, call screening, and the like. . The single phone number system also provides additional features such as e-mail (including voice recognition and possible text-to-speech output), video mail, telex services, etc. May be included. Other embodiments of the present invention may include a display and provide a configuration for e-mail, video mail, telex service, and the like. For example, a subscriber may have access to a user-maintained dictionary of speech recognition and text-to-speech words via the Internet. In addition, the subscriber may be presented with a screen that allows the subscriber to select the next option. Voice type (e.g., male or female voice), pitch (ability to select the pitch of the voice), speed of speaking (ability to define slow, medium or fast speech), mode (natural) Language / locale (language / dialect) (select the language spoken (English, Spanish, etc.) and local language). Web server 42 may include a mailbox for subscribers that can store not only HTML pages, but also voice, facsimile, video, telex, and other messages. It is better to select options using a mouse, keyboard or other pointer / text-based screen-viewable input, and other embodiments of the invention make selections and make selections. The use of voice navigation between and within displayable screens to enter is also allowed. All of the above U.S. patents and applications are incorporated herein by reference, as though set forth in their entirety. Embodiments of the present invention can be modified based on the embodiments disclosed in the above US patents and applications to provide still further embodiments of the present invention. These and other variations can be made to embodiments of the invention in light of the above detailed description. In general, in the following claims, the terms used should not be construed to limit the invention to the specific embodiments disclosed in the specification and the claims, but may disclose the records of the user. It should be construed to include any system that performs claims-based processing, updates records, or provides processing for updating. Accordingly, the invention is not limited by the disclosure, whose scope is to be determined entirely by the following claims.

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ， ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＡＵ，ＣＡ，Ｊ Ｐ，ＭＸ (72)発明者 ヴァイディヤ，ラムチャンドラ エス アメリカ合衆国 アイオワ 52402―7082 セダー ラピッズ タウン ハウス ド ライブ エヌ イー 2830 ユニット シ ー────────────────────────────────────────────────── ─── Continuation of front page    (81) Designated country EP (AT, BE, CH, CY, DE, DK, ES, FI, FR, GB, GR, IE, I T, LU, MC, NL, PT, SE), AU, CA, J P, MX (72) Inventors Vadiya, Ramchandra S             United States Iowa 52402-7082               Cedar Rapids Town House De             Live NE 2830 Unit             ー

Claims (1)

【特許請求の範囲】 １．加入者を有する電気通信システムにおいて、前記加入者は前記システムか ら複数のサービスを受信し、 インターネットを介して、サービスのオプションを選択した加入者を特定する アカウントの記録へのアクセスを、前記加入者により要求するステップと、 前記加入者の要求を確認するステップと、 前記加入者の要求が確認された場合には、前記サービスのうちの少なくとも一 つを前記加入者が選択できるメニューを、前記加入者に供給するステップと、 インターネットを介して、前記メニューにおいて与えられる選択対象のうちの 一つに対応する、前記加入者の入力を受信するステップと、 受信される加入者の入力に基づいて前記アカウントの記録をアップデートする ステップと を具備する方法。 ２．インターネットが、複数のウェブページを有するワールド・ワイド・ウェ ブを含み、 要求をする前記ステップは、前記システムに関連付けられたウェブページを検 索するステップを含む、請求項１記載の方法。 ３．確認をする前記ステップは、 アクセスを要求する前記ステップに応答して、トークンを要求しかつ受信する ステップと、 前記加入者からの入力データを要求するステップと、 前記加入者からの入力データを受信するステップと、 前記入力データを、対応する記憶されたデータと比較するステップと、 前記入力データが前記記憶されたデータに適切に相当する場合には、前記トー クンを確認するステップと を含む、請求項１記載の方法。 ４．供給をする前記ステップは、 少なくとも前記サービスのいくつかを提供する第１のスクリーンを、前記加入 者に供給するステップと、 複数の前記サービスのうちの少なくとも一つを選択する、最初の加入者の入力 を受信するステップと、 前記メニューを供給する第２のスクリーンを前記加入者に供給するステップと を含む、請求項１記載の方法。 ５．供給をする前記ステップは、前記加入者への前記メニューを有するスクリ ーンを供給するステップを含み、 前記スクリーンは、それとともに含まれた、確認されたトークンおよび実行可 能なアプリケーションを有する 請求項１記載の方法。 ６．受信をする前記ステップは、 前記加入者の要求を再度確認するステップと、 前記加入者の要求が再度確認された場合にのみ、前記アカウントをアップデー トするステップと を含む、請求項１記載の方法。 ７．インターネットに結合された通信システムにおいて、 インターネットを介して、前記システムとの関係を示す加入者特有の記録にア クセスするための要求を、受信するステップと、 インターネットを介して、前記記録に代わる代替データを受信するステップと 、 受信される代替データに基づいて前記記録をアップデートするステップと を具備するコンピュータ実行方法。 ８．アップデートをする前記ステップより前に、前記受信される要求を確認す るステップをさらに具備する、請求項７記載の方法。 ９．代替データを受信する前記ステップより前に、加入者の選択可能なオプシ ョンの組を供給するステップをさらに具備し、 前記オプションが前記記録における登録に対応する、請求項７記載の方法。 １０．要求を受信する前記ステップは、前記記録にアクセスする要求を受信す るステップを含み、 前記記録が、前記システムにおいて加入者が選択可能な通信サービスのオプシ ョンに対応するデータ・フィールドを有する、請求項７記載の方法。 １１．要求を受信する前記ステップは、前記システムに関連付けられたページ にアクセスするための要求を受信するステップを含む、請求項７記載の方法。 １２．要求を受信する前記ステップに応答して、トークンを要求しかつ受信す るステップと、 前記加入者に関連するデータを受信するステップと、 前記加入者データに関連する前記データを、対応する記憶されたデータと比較 するステップと、 入力データが前記記憶されたデータに適切に相当する場合には、前記トークン を確認するステップと をさらに具備する、請求項７記載の方法。 １３．前記システムによって提供されるサービスに対応する複数のオプション を与えるページを供給するステップと、 前記オプションのうちの一つを選択する加入者の入力を受信するステップと をさらに具備する、請求項７記載の方法。 １４．メニューを有するスクリーンを供給するステップをさらに具備し、 前記スクリーンは、それとともに含まれた、アクセスのための要求に関連する トークンを有する、請求項７記載の方法。 １５．メニューを有するスクリーンを供給するステップをさらに具備し、 前記スクリーンは、前記記録においてテキスト−トゥー−スピーチの変更をす るためのオプションを供給する、請求項７記載の方法。 １６．代替データを受信する前記ステップは、前記記録をアップデートするた めの指示を与える音声データを受信することを含む、請求項７記載の方法。 １７．前記加入者に対して電子メールボックスへのアクセスを提供するステッ プをさらに具備する請求項７記載の方法。 １８．通信システム内のコンピュータに対する命令を包含したコンピュータ読 取可能な媒体であって、前記コンピュータ読取可能な媒体の命令は、 インターネットを介して、前記システムによって提供されるサービスとの関連 を示す加入者特有の記録にアクセスするための要求を、受信するステップと、 インターネットを介して、前記記録に代わる代替データを受信するステップと 、 受信される代替データに基づいて前記記録をアップデートするステップと を具備する媒体。 １９．アップデートをする前記ステップより前に、受信される要求を確認する ステップをさらに具備する、請求項１８記載のコンピュータ読取可能な媒体。 ２０．代替データを受信する前記ステップより前に、加入者の選択可能なオプ ションの組を供給するステップをさらに具備し、 前記オプションが前記記録における登録に対応する、請求項１８記載のコンピ ュータ読取可能な媒体。 ２１．要求を受信する前記ステップは、前記システムに関連するページにアク セスする要求を受信するステップを含む、請求項１８記載のコンピュータ読取可 能な媒体。 ２２．要求を受信する前記ステップに応答して、トークンを要求しかつ受信す るステップと、 前記加入者に関連するデータを受信するステップと、 前記加入者データに関連するデータを、対応する記憶されたデータと比較する ステップと、 入力データが前記記憶されたデータに適切に相当する場合には、前記トークン を確認するステップと をさらに具備する、請求項１８記載のコンピュータ読取可能な媒体。 ２３．前記システムによって提供されるサービスに対応する複数のオプション を与えるページを供給するステップと、 前記オプションのうちの一つを選択する加入者の入力を受信するステップと をさらに具備する、請求項１８記載のコンピュータ読取可能な媒体。 ２４．メニューを有するスクリーンを供給するステップをさらに具備し、 前記スクリーンは、それとともに含まれた、アクセスのための要求に関連する トークンを有する、請求項１８記載のコンピュータ読取可能な媒体。 ２５．メニューを有するスクリーンを供給するステップをさらに具備し、 前記メニューは、前記記録においてテキスト−トゥー−スピーチの特徴を変更 するためのオプションを供給する、請求項１８記載のコンピュータ読取可能な媒 体。 ２６．代替データを受信する前記ステップは、前記記録をアップデートするた めの指示を与える音声データを受信することを含む、請求項１８記載のコンピュ ータ読取可能な媒体。 ２７．前記加入者に対して電子メールボックスへのアクセスを提供するステッ プをさらに具備する請求項１８記載のコンピュータ読取可能な媒体。 ２８．電気通信ネットワークにおいて、 システムとの関係を示す加入者特有の記録を蓄積するメモリと、 前記メモリとインターネットとの間に接続され、(a)インターネットを介して 、前記記録にアクセスするための要求を受信し、(b)インターネットを介して、 前記記録に代わる代替データを受信し、および、(c)受信された代替データに基 づいて前記メモリ内の前記記録の改変を要求する、ネットワークサーバと を具備する装置。 ２９．前記ネットワークサーバは、改変を要求する前に、受信された要求を確 認する、請求項２８記載の装置。 ３０．前記ネットワークサーバは、代替データを受信する前に、加入者の選択 可能なオプションの組を供給し、 前記オプションは、前記記録における登録に対応する 請求項２８記載の装置。 ３１．トークンデータベースと、 前記トークンデータベースと前記ネットワークサーバとの間に接続されたトー クンサーバとをさらに具備し、 前記メモリは、加入者に対応するデータを蓄積し、 前記ネットワークサーバは、前記トークンサーバからのトークンを要求しかつ 受信し、前記加入者に関連するデータを受信し、前記加入者データに関連するデ ータを対応する蓄積されたデータと比較し、および、入力データが前記蓄積され たデータに適切に相当する場合に前記トークンを確認する 請求項２８記載の装置。 ３２．前記メモリは、ウェブページを蓄積し、 前記ページは、前記システムによって提供されるサービスに対応する複数のオ プションを供給し、 前記ネットワークサーバは、前記ページを供給し、かつ、加入者の入力を受信 し、 前記加入者の入力は、前記オプションのうちの一つを選択する 請求項２８記載の装置。 ３３．前記ネットワークサーバに接続され、多種多様なサービスへの発呼者に 対し、それらのサービスへの加入者の代わりに、一つの電話番号のアクセスを提 供するための、プラットフォームをさらに具備し、前記サービスは、 音声によるメッセージングを容易にするためのボイス・メッセージング・サー ビスと、 ファクシミリによるメッセージングを容易にするためのファクシミリ・メッセ ージング・サービスと、 前記プラットフォームの電話ネットワークとのインターフェースをとるための インターフェースとを含む 請求項２８記載の装置。 ３４．加入者を有する電気通信システムにおいて、前記加入者は前記システム から複数のサービスを受信し、前記システムはコンピュータのネットワークに接 続され、 前記コンピュータのネットワークを介して、加入者の選択された前記サービス のオプションを特定するアカウントの記録へのアクセスを、加入者によって要求 するステップと、 前記加入者の要求を確認するステップと、 前記加入者の要求が確認された場合には、前記サービスのうちの少なくとも一 つのために前記加入者に選択対象を与えるメニューを、前記加入者に供給するス テップと、 前記コンピュータのネットワークを介して、前記メニューにおいて与えられる 選択対象のうちの一つに対応する、加入者の入力を受信するステップと、 受信される加入者の入力に基づいて前記アカウントの記録をアップデートする ステップと を具備する方法。 ３５．前記コンピュータのネットワークがインターネットを含み、 要求をする前記ステップは、前記システムに関連するサイトにアクセスするス テップを含む、請求項３４記載の方法。 ３６．供給をする前記ステップは、メニューを有する加入者へのスクリーンを 供給するステップを含み、 前記スクリーンは、それとともに含まれた、確認されたトークンを有する 請求項３４記載の方法。 ３７．メニューを供給するステップをさらに具備し、 前記メニューは、前記アカウントの記録においてテキスト−トゥー−スピーチ の特徴を変更するためのオプションを供給する、請求項３４記載の方法。 ３８．加入者の入力を受信する前記ステップは、前記アカウントの記録をアッ プデートするための指示を与える音声データを受信することを含む、請求項３４ 記載の方法。 ３９．前記加入者に対して電子メールボックスへのアクセスを提供するステッ プをさらに具備する請求項３４記載の方法。[Claims]   1. In a telecommunications system having a subscriber, the subscriber is the system. Receive multiple services,   Identify subscribers who have selected the service option via the Internet Requesting access to an account record by the subscriber;   Confirming the subscriber's request;   If the subscriber request is confirmed, at least one of the services Providing to the subscriber a menu from which the subscriber can select   Via the Internet, one of the choices given in the menu Receiving, corresponding to one, the input of the subscriber;   Update the account record based on the subscriber input received Steps and   A method comprising:   2. The Internet is a World Wide Web with multiple web pages. Including   The step of making a request includes searching for a web page associated with the system. The method of claim 1, comprising the step of searching.   3. The step of confirming comprises:   Requesting and receiving a token in response to the step of requesting access Steps and   Requesting input data from the subscriber;   Receiving input data from the subscriber;   Comparing the input data with corresponding stored data;   If the input data appropriately corresponds to the stored data, the Steps to confirm Kun   The method of claim 1, comprising:   4. The step of providing   The first screen providing at least some of the services, Supplying to the person;   Initial subscriber input selecting at least one of the plurality of said services Receiving the   Providing a second screen for providing the menu to the subscriber;   The method of claim 1, comprising:   5. The step of providing includes a script having the menu to the subscriber. Providing the   The screen shows the confirmed token and executable included with it Have a functional application   The method of claim 1.   6. The step of receiving includes:   Re-confirming the subscriber's request;   Update the account only if the subscriber's request is confirmed again Steps   The method of claim 1, comprising:   7. In a communication system coupled to the Internet,   Via the Internet, subscribe to a subscriber-specific record indicating its relationship to the system. Receiving a request to access;   Receiving alternative data in place of the record via the Internet; ,   Updating the record based on the received alternative data;   A computer-implemented method comprising:   8. Confirm the received request before the step of updating The method of claim 7, further comprising the step of:   9. Prior to the step of receiving the surrogate data, the subscriber's selectable options Providing a set of options.   The method of claim 7, wherein the options correspond to registrations in the record.   10. Receiving the request includes receiving a request to access the record. Including the steps of   The record is an option for a communication service selectable by a subscriber in the system. The method of claim 7, comprising a data field corresponding to the option.   11. The step of receiving a request comprises a page associated with the system. 8. The method of claim 7, including receiving a request to access the.   12. Requesting and receiving a token in response to the step of receiving a request. Steps   Receiving data associated with the subscriber;   Comparing said data relating to said subscriber data with corresponding stored data Steps to   If the input data appropriately corresponds to the stored data, the token Steps to confirm   The method according to claim 7, further comprising:   13. Multiple options corresponding to the services provided by the system Providing a page that gives   Receiving input of a subscriber selecting one of the options;   The method according to claim 7, further comprising:   14． Providing a screen having a menu,   The screen relates to a request for access included with it The method of claim 7, comprising a token.   15. Providing a screen having a menu,   The screen displays text-to-speech changes in the record. The method of claim 7, further comprising providing an option for:   16. The step of receiving replacement data includes updating the record. 8. The method of claim 7, comprising receiving audio data providing instructions for the operation.   17． Providing a subscriber with access to an e-mail box; The method of claim 7, further comprising a loop.   18. Computer-reading instructions containing instructions for a computer in a communication system The instructions of the computer readable medium, wherein the instructions are:   Connection to services provided by the system via the Internet Receiving a request to access a subscriber-specific record indicating:   Receiving alternative data in place of the record via the Internet; ,   Updating the record based on the received alternative data;   A medium comprising:   19. Check for incoming requests before the step of updating The computer-readable medium of claim 18, further comprising steps.   20. Prior to the step of receiving the surrogate data, the subscriber's selectable options Providing a set of options.   19. The computer of claim 18, wherein the option corresponds to a registration in the record. A computer readable medium.   21. The step of receiving a request includes accessing a page associated with the system. 20. The computer readable medium of claim 18, comprising receiving a request to access. Medium.   22. Requesting and receiving a token in response to the step of receiving a request. Steps   Receiving data associated with the subscriber;   Comparing data associated with the subscriber data with corresponding stored data Steps and   If the input data appropriately corresponds to the stored data, the token Steps to confirm   The computer-readable medium of claim 18, further comprising:   23. Multiple options corresponding to the services provided by the system Providing a page that gives   Receiving input of a subscriber selecting one of the options;   The computer-readable medium of claim 18, further comprising:   24. Providing a screen having a menu,   The screen relates to a request for access included with it 19. The computer readable medium of claim 18, comprising a token.   25. Providing a screen having a menu,   The menu changes text-to-speech features in the record The computer readable medium of claim 18, providing an option to perform. body.   26. The step of receiving replacement data includes updating the record. 19. The computer of claim 18 including receiving voice data providing instructions for Data readable medium.   27. Providing a subscriber with access to an e-mail box; The computer-readable medium of claim 18, further comprising a loop.   28. In telecommunications networks,   A memory for storing a subscriber-specific record indicating the relationship with the system;   Connected between the memory and the Internet, and (a) via the Internet Receiving a request to access the record, (b) via the Internet, Receiving alternative data in place of the record; and (c) receiving alternative data based on the received alternative data. Requesting modification of the record in the memory based on   An apparatus comprising:   29. The network server verifies the received request before requesting the modification. 29. The apparatus of claim 28, wherein   30. The network server may select a subscriber before receiving the alternative data. Supply a set of possible options,   The option corresponds to a registration in the record   29. The device according to claim 28.   31. A token database,   Toe connected between the token database and the network server Further comprising a server   The memory stores data corresponding to the subscriber;   The network server requests a token from the token server and Receiving data associated with the subscriber, receiving data associated with the subscriber data. Data with the corresponding stored data, and the input data is stored in the stored data. Check the token if it corresponds to the data properly   29. The device according to claim 28.   32. The memory stores web pages,   The page has a plurality of services corresponding to the services provided by the system. Supply options,   The network server serves the page and receives subscriber input And   The subscriber input selects one of the options   29. The device according to claim 28.   33. Connected to the network server to callers to various services Provide access to a single telephone number on behalf of subscribers to those services. Further comprising a platform for providing, the service comprising:   Voice messaging service to facilitate voice messaging Screws and   Facsimile message to facilitate facsimile messaging Service and   For interfacing with the platform's telephone network Including interface   29. The device according to claim 28.   34. In a telecommunications system having a subscriber, the subscriber may Receive a plurality of services from the computer, the system connects to a network of computers. Continued,   Via the network of the computer, the service selected by the subscriber Request access to account records specifying subscriber options by subscriber Steps to   Confirming the subscriber's request;   If the subscriber request is confirmed, at least one of the services A menu that gives the subscriber a choice for Tep,   Given in the menu via the computer network Receiving subscriber input corresponding to one of the selections;   Update the account record based on the subscriber input received Steps and   A method comprising:   35. The computer network includes the Internet;   The step of making a request comprises a step of accessing a site associated with the system. 35. The method of claim 34, comprising a step.   36. The step of providing a screen to a subscriber having a menu; Including the step of providing   The screen has a confirmed token included with it   35. The method of claim 34.   37. Further comprising the step of providing a menu;   The menu includes a text-to-speech in the account record. 35. The method of claim 34, further comprising providing an option to change the characteristics of the.   38. The step of receiving subscriber input includes updating a record of the account. 35. Receiving audio data providing instructions for updating. The described method.   39. Providing a subscriber with access to an e-mail box; 35. The method of claim 34, further comprising a step.
JP55052898A 1997-05-22 1998-05-15 Internet-based subscriber profile management for communication systems Pending JP2002514330A (en)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US08/862,134 1997-05-22
US08/862,134 US6587867B1 (en) 1997-05-22 1997-05-22 Internet-based subscriber profile management of a communications system
US92537097A 1997-09-08 1997-09-08
US08/925,370 1997-09-08
PCT/US1998/010227 WO1998053582A1 (en) 1997-05-22 1998-05-15 Internet-based subscriber profile management of a communications system

Publications (1)

Publication Number Publication Date
JP2002514330A true JP2002514330A (en) 2002-05-14

Family

ID=27127674

Family Applications (1)

Application Number Title Priority Date Filing Date
JP55052898A Pending JP2002514330A (en) 1997-05-22 1998-05-15 Internet-based subscriber profile management for communication systems

Country Status (5)

Country Link
EP (1) EP0983671A1 (en)
JP (1) JP2002514330A (en)
AU (1) AU7497998A (en)
CA (1) CA2291137A1 (en)
WO (1) WO1998053582A1 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006121316A (en) * 2004-10-20 2006-05-11 Mitsubishi Electric Corp Monitor system

Families Citing this family (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
ES2195075T3 (en) * 1997-12-19 2003-12-01 Ericsson Telefon Ab L M APPARATUS AND METHOD FOR THE CONTROL OF THE BASIC AND SUPPLEMENTARY SERVICE OF SUBSCRIBER IN A TELEPHONE SYSTEM.
DE19912947A1 (en) * 1999-03-23 2000-09-28 Deutsche Telekom Ag Customer and network management for intelligent networks
US6963928B1 (en) 1999-05-27 2005-11-08 Bagley David T Systems and methods for communicating across various communication applications using single address strings
EP1186145A2 (en) * 1999-05-27 2002-03-13 Internet Management Systems, Inc. Universal address system and method
US6356630B1 (en) * 1999-07-09 2002-03-12 Lucent Technologies, Inc. Telephone calling card service system integrating virtual destination numbers
US7124088B2 (en) 1999-07-30 2006-10-17 Progressive Casualty Insurance Company Apparatus for internet on-line insurance policy service
CA2322083A1 (en) * 1999-10-08 2001-04-08 Nortel Networks Corporation Screen based administration of voice mail configuration
US20020162008A1 (en) * 2000-01-28 2002-10-31 Vincent Hill Method and system for controlling access to a telecommunication or internet system
WO2002005530A1 (en) * 2000-07-12 2002-01-17 Siemens Aktiengesellschaft System and method for managing telecommunication connections by means of an access to an ip-based communication network
US7054866B2 (en) 2001-03-20 2006-05-30 Mci, Inc. Systems and methods for communicating from an integration platform to a provisioning server
US8195738B2 (en) 2001-03-20 2012-06-05 Verizon Business Global Llc Systems and methods for communicating from an integration platform to a profile management server
US7047417B2 (en) 2001-03-20 2006-05-16 Leskuski Walter J Systems and methods for accessing reporting services
US8660017B2 (en) 2001-03-20 2014-02-25 Verizon Business Global Llc Systems and methods for updating IP communication service attributes using an LDAP
US7043480B2 (en) 2001-03-20 2006-05-09 Mci, Inc. Systems and methods for communicating from an integration platform to a lightweight directory access protocol based database
US20020138603A1 (en) * 2001-03-20 2002-09-26 Robohm Kurt W. Systems and methods for updating IP communication service attributes
US8417632B2 (en) 2001-03-20 2013-04-09 Verizon Business Global Llc Systems and methods for interfacing with a billing and account management unit
US7039041B2 (en) 2001-03-20 2006-05-02 Robohm Kurt W Operational support system for telecommunication services

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB9526326D0 (en) * 1995-12-22 1996-02-21 British Telecomm Accessing telecommunications services

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006121316A (en) * 2004-10-20 2006-05-11 Mitsubishi Electric Corp Monitor system
JP4704005B2 (en) * 2004-10-20 2011-06-15 三菱電機株式会社 Monitoring system

Also Published As

Publication number Publication date
AU7497998A (en) 1998-12-11
MX9910721A (en) 2002-12-13
WO1998053582A1 (en) 1998-11-26
EP0983671A1 (en) 2000-03-08
CA2291137A1 (en) 1998-11-26

Similar Documents

Publication Publication Date Title
US6587867B1 (en) Internet-based subscriber profile management of a communications system
US6031904A (en) Service order mechanism for telephone subscriber
JP2002514330A (en) Internet-based subscriber profile management for communication systems
US7593396B2 (en) System and method for providing remote access to telecommunications services
US6393467B1 (en) Network interconnected computing device, server and notification method
US6999478B2 (en) System controlling use of a communication channel
US7647403B2 (en) Method for processing a request for access to a data network
CA2199802C (en) Personal communications internetworking
US20170171385A1 (en) Methods, Systems, and Products for Processing Communications
US6968050B1 (en) Methods and apparatus for authenticating and authorizing ENUM registrants
US6226286B1 (en) Apparatus and method for communication between data network and telecommunication network
EP1211875A2 (en) System and method for delivering profile information relating to a caller
US20040005045A1 (en) System and method for implementing and accessing call forwarding services
US20090016519A1 (en) Methods, Systems, and Products for Processing Calls
JP2000516408A (en) Method of accessing service resource item used in telecommunications system
JP2000516407A (en) Telecommunication service providing method
JP2000516406A (en) Telecommunication service providing method
JP2004194330A (en) Method of accessing target entity over communication network
AU728548C (en) Device and method for communication between a data network and a telecommunications network
US6393116B1 (en) Method for managing a subscriber's telecommunication service data as well as a server and exchange therefor
US20070110036A1 (en) System and method for establishing long distance call connections using a desktop application
EP1228623B1 (en) Establishing data connections
US6829236B1 (en) System and method for providing automated directory assistance via the internet and corresponding call completion within a telecommunications system
US7194079B1 (en) Methods and apparatus for forwarding facsimiles by phone and/or E-mail
US20020122546A1 (en) Internet-aided method of setting up a telephone call