JP2008515296A - ネットワーク相互間遠隔通信サービスを管理する無線装置 - Google Patents

Abstract

通信の遠隔制御システムであって、それにより、ユーザがクライアント装置を用いて各種の電話ネットワークを横断する呼管理機能を遠隔構成できる。本通信遠隔制御システムは、中央でユーザの電話に対する呼管理を取り扱う。本通信遠隔制御システムは、中央に集中したアドレスブック、呼通信記録、およびボイスメールを提供できる。ユーザは、本通信遠隔制御システムに格納されるモード、フィルタ、スケジュール等を含む各種のパラメータを規定できる。本通信遠隔制御システムは、電話ネットワークにかかってきた呼を、クライアント装置の一部のこともあるユーザの配信装置にルーティングする。かかってきた呼は、規定した電話番号にルーティングするか、ボイスメールに送信するか、または破棄するが、ユーザは、モードを手動で変更でき、または時刻、曜日、場所および／または他の要因に基づいて自動モード選択を規定できる。

Description

関連出願の相互参照
本出願は、２００４年９月２９日付け出願の米国仮特許出願第６０／６１４，８４４号、および２００５年９月２８日付け出願の米国ユーティリティ特許第（未定）号、発明の名称「ネットワーク相互間遠隔通信サービスを管理するための無線装置」による特典および優先権を主張し、開示を引用して本明細書に組み込む。

本出願は、２００５年２月１６日付け出願の米国特許出願第１１／０６０，２３２号、発明の名称「個人通話を管理する無線装置」に関連し、開示を引用して本明細書に組み込む。

本出願は、２００５年２月１６日付け出願の米国特許出願第１１／０６０，６４２号、発明の名称「動的ルーティング電話呼び出し」に関連し、開示を引用して本明細書に組み込む。

本出願は、２００５年２月１６日付け出願の米国特許出願第１１／０６０，０８５号、発明の名称「被呼者行動モードの発呼者への通知」に関連し、開示を引用して本明細書に組み込む。

本発明は、一般に、電話呼び出し等の通信の遠隔管理に関し、より詳細には、多数の通信接続業者を横断する通信の、無線装置を用いた遠隔管理に関する。

多くの人々（被呼者）は、発呼する可能性のある人に配布する多数の電話番号（以下、ＴＮと略称する）を有する。このＴＮのセットには、自宅用、オフィス用、および携帯電話用の番号が含まれ、これらは様々な通信接続業者と対応付けられているのが普通である。通信接続業者はそれぞれ、他の通信接続業者と孤立して動作する自身の機能セットを有する。ユーザが同一通信接続業者の２つのＴＮを持っていたとしても、一つのＴＮに対する機能セットは他のものとは隔絶して動作することがある。

発呼者（電話の掛け手）が被呼者（電話の受け手）の２つ以上のＴＮを知っている場合、発呼者は最も被呼者に通じる可能性のある番号を選択し、別の番号を試みる前に音声メールメッセージを残すことが多い。発呼者は、被呼者に最も通じやすい呼び出しシーケンスを決定するのに負担を感じる。これが原因となって、最終的に被呼者に通じたとしても、一つ以上の音声メールメッセージを（自宅、オフィス、携帯電話に）残すことが多い。この状況は、接続を確立するプロセスを遅らせ、発呼者に努力および時間を要求するために、費用が増大し、本来の接続を行う確率が低下する。更に、多数の音声メールメッセージが被呼者を悩ませる。

呼管理（呼び出し管理）は、典型的には電話番号である呼び出しアドレスから配信装置への、選択可能な電話呼び出しの再ルーティングであり、電話または音声メールのサービスが代表的である。初歩的な可変着信転送の形式の呼制御が、幅広く利用されている。既存の管理機能は、通信接続業者ネットワーク内の電話回線にかかってきた呼に適用しているだけである。例えば、消費者向けボイスオーバーＩＰ（ＶｏＩＰ）の２大通信接続業者は、自社の電話番号への着呼に対して呼のリダイレクションを提供している。この機能を構成するには、ユーザはその通信接続業者のウェブサイトにログオンし、構成ウェブページに転送番号を入力しなければならない。構内交換機（ＰＢＸ）システムによっては、ＰＢＸ局（電話）またはプライベートの企業イントラネットウェブサイトで構成した選択可能な転送機能を有する。地域交換事業者（ＬＥＣ）は、可変着信転送機能を提供しているのが普通である。この機能を用いるには、ユーザが、転送される電話の場所にいること；ユーザが電話をオフフックにすること；およびユーザが、難解な数字に続けて、全ての呼び出しを転送する電話回線の電話番号を入力しなければならない。これらの場合のどれも構成は静的である。システムの構成を一旦行うと、システムはそれが変更されるまで同じ様に動作する。構成を変更するのは面倒なことが多く、難解な数字コードをキーパッドで入力する必要がある。多数の電話を管理するには、ユーザは、物理的場所が多数となる可能性がある通信接続業者のそれぞれから、別々のユーザーインターフェースにアクセスする。

遠隔通信の機能によっては、通信接続業者のネットワークに取り付けた装置と切り離されている。例えば、発呼者のＩＤボックスは、地域交換事業者（ＬＥＣ）が提供する電話回線に接続される。発呼者のＩＤボックスは、その電話回線への着呼を表示し、記録を保持することしかできない。同様に、最も最新の携帯電話は、かかってきた呼およびダイヤルした呼の通話記録を格納するが、通話記録は、その携帯電話が受信した呼および発信した呼にしか適用されない。

システムおよび方法に必要とされるのは、どの電話番号を用いれば特定個人につながるのかを発呼者が考えなくても済むように、電話の呼び出しを自動的に処理、ルーティング、および管理することである。システムおよび方法に更に必要とされるのは、異なる通信接続業者用の異なる電話番号への呼び出しに対して、かかってきた呼を処理する方法を被呼者が規定できることと、呼び出された時点でのリアルタイムの状態に動的に対応することである。

本発明は、中央の遠隔管理システムを用いて、マルチ通信ネットワークへの着信呼を取り扱う方法を被呼者が規定できるようにする技法を提供する。被呼者は、ユーザの各種のアドレスまたは電話番号に対する行動モードに基づいて、通信管理ディレクティブを設定し、そのディレクティブを通信ネットワークと離れているデータベースに格納する。そのディレクティブは、ユーザーアドレスへの通信に応じて検索され、通信をルーティングするためにユーザーアドレスと対応付けられる通信ネットワークに提供される。

一態様では、本発明は、多数の電話ネットワークを横断して協調動作する呼管理機能セットの、遠隔構成を可能にする無線装置を含む技法およびシステムを提供する。

更なる本発明の機能、その特徴および様々な利点は、付帯の図面および以下の詳細な説明から一層明らかとなろう。

付帯の図面は、本発明の幾つかの実施の形態を示し、本説明と併せて、本発明の基本原理を表明するのに役立つ。

本明細書での説明では、用語「被呼者」は、呼出されているか、または将来のある時点に呼出される可能性がある個人または事業体を指すのに用いる。用語「ユーザ」は「被呼者」と交換可能に用いられる。

「発呼者」は、ユーザに発信するか、または発信しようとしているか、または発信する可能性がある人である。

「ダイヤルされた電話番号（ダイヤルされたＴＮ）」は、発呼者がダイヤルした番号である。実際の電話装置と対応付けられていても、対応付けられていなくてもよい。

「配信電話装置」は、着呼を受信するのに用いることができる装置である。

「ユーザープロファイル」は、呼管理パラメータを規定するユーザの構成情報である。

「モード」は、「在宅中」、「職場」等の被呼者の動作モードである。以下に説明するように、モードは、ユーザが明示的に、またはユーザープロファイルにより暗示的に選択できる。

「フィルタ」は、ユーザを呼び出す可能性がある発呼者のサブセットを識別するための定義済みの仕組みであり、彼らからの呼び出しを異なる方法で取り扱う。

追加の用語は、以下の説明の文脈内において本明細書で定義する。

本発明の幾つかの実施の形態を示す付帯の図面を参照して、本発明をより全体的に説明する。本発明は、多くの異なる形式で実施することができるので、本明細書で説明する実施の形態に限定すると解釈すべきではない。むしろ、本開示を完全なものとするとともに、当該分野の技術者に本発明を全体的に伝えるように、これらの実施の形態を提供する。

説明のために、以下の記載は、北米番号計画（ＮＡＮＰ）の番号等の、電話番号（ＴＮ）をダイヤルすることにより発信する呼（呼び出し）を取り扱う観点から、本発明を説明する。しかし、当該分野の技術者には言うまでもなく、本明細書で説明する技法は、他の方法で開始される通信を取り扱うために用いることができる。特に、発呼者は、ダイヤルＴＮ、テキスト文字列、非ＮＡＮＰ数字シーケンス等にかかわらず、何らかの種類の発呼者識別子を用いて被呼者を特定できる。本明細書では用語「ユーザーアドレス（ＵＡ）」を用いて、被呼者を識別するための何らかのこのようなメカニズムを表す。

以下の説明では、用語「配信電話番号（配信ＴＮ）」は、ユーザへの呼の終端となる装置またはシステムの電話番号（つまりＵＡ）を指す。配信ＴＮは、電話、ボイスメールプラットフォーム（従来型または電子メール配信のみ）、自動音声応答（ＩＶＲ）システム等の、配信装置に接続する。ダイヤルされたＴＮ（発呼者がダイヤルしたＴＮ）は、被呼者の配信ＴＮのものと同一番号であっても、そうでなくてもよく、すなわち、ダイヤルされたＴＮへの呼は、同一の配信ＴＮによりアドレスされる装置に接続されても、接続されなくてもよい。従って、場合によっては、ダイヤルされたＴＮは、仮想的であり、物理的な配信装置のアドレスではない。

以下に更に詳細に説明するように、一実施の形態では、本発明は、被呼者のＵＡセットおよびこれらＵＡの配信装置に対するリアルタイムマッピングを管理する。ＵＡにかかってきた呼は、配信ＴＮに対応する配信装置の内の一台（またはそれ以上）にルーティングされることになる。本システムは、モード、フィルタ、発呼者選択（案内係）、ビジー状態、および無応答状態の組合せを用いて、適切な配信ＴＮに呼をルーティングすべきかどうか、およびその方法を決定する。

本発明は、対称または非対称の方法で実装できる。対称実装は、全ての配信ＴＮがダイヤルされたＴＮのセット内にある場合で、それ以外の実装は非対称である。

呼管理システム（呼び出し管理システム）は、各種のユーザＴＮに対して、電話呼び出しのルーティングを取り扱う。電話サービス通信接続業者は、ユーザが設定した呼管理ディレクティブ（呼び出し管理命令）に基づいて、または通信接続業者がユーザ行動モードに基づいて決定するディレクティブ（命令）に従って、業者に向けられた電話の呼び出しをルーティングできる。遠隔呼管理システムは、多数の通信接続業者を含むユーザのサービス通信接続業者の内のどれかに向けられた電話呼び出しのルーティングを取り扱うことができる。遠隔呼管理システムは、呼情報および音声メールを中央に格納でき、複数のユーザＴＮに向けられた電話呼び出しのルーティングを取り扱うことができる。ユーザは無線クライアント装置を用いて遠隔呼管理システムを構成できる。呼管理システム用アーキテクチャを図１〜図２０に示す。遠隔呼管理システム用アーキテクチャは図２１に示す。

図１を参照すると、一実施の形態による本発明を実施するためのアーキテクチャを表すブロック図が示されている。

発呼者１０１は、電話局（ＣＯ）、移動通信交換局（ＭＳＣ）、または構内交換機（ＰＢＸ）等の、地域電話交換機１０２を経由して発呼する。発信呼は、公衆交換電話網（ＰＳＴＮ）１０３を経由してＣＯ１０４Ａ、ＭＳＣ１０４Ｂ、またはＰＢＸ１０４Ｃ等の、送信先交換機１０４まで進む。本発明は、発信元または送信先で用いられている交換機１０２、１０４の特定型式にかかわらず実装できる。送信先交換機１０４は、呼管理モジュール１０５に問い合わせて、呼をどこにルーティングするかを決定する。モジュール１０５は、ユーザープロファイルデータベース１０５Ａをチェックして、ユーザ用の呼管理設定を取得する。一実施の形態では、モジュール１０５は、外部入力１２０（被呼者場所、被呼者識別子等）を利用して、呼をルーティングする場所を決定する。

モジュール１０５は、呼（呼び出し）に対する所望のルーティングを指示する応答を交換機１０４に送信する。適切な配信装置１０８（例えば、自宅電話１０８Ａ、無線電話１０８Ｂ、オフィス電話１０８Ｃ、音声メールプラットフォーム１０６等を含む）が、呼を受け取り、配信装置は、あたかも直接受信したかのようにその呼を取り扱う。次いで、被呼者１０９は、選択した配信装置１０８を経由して呼を受信する。

一実施の形態では、音声メールプラットフォーム１０６が呼を取り扱う場合、モジュール１０５に問い合わせて、音声メールメッセージを電子メール添付ファイル１１０として被呼者１０９が受信するよう電子メールリーダー１１１に配信すべきかどうかを決定することができる。別の実施の形態では、音声メールプラットフォーム１０６が呼を取り扱う場合、モジュール１０５内に指示されているような被呼者の選択に従って、いずれかのまたは全ての配信装置１０８に警報（例えば、ディスプレイ上の点滅灯、音声、またはインジケータ）を発することができる。

一実施の形態では、送信先交換機１０４からの各問い合わせには、例えば、ダイヤルされたＴＮおよび発呼者ＴＮ（既知の場合）が含まれる。当該分野の技術者には言うまでもなく、問い合わせには他の情報を含めることもできる。一実施の形態では、問い合わせ受信に応答して、モジュール１０５は、ダイヤルされた番号と対応する配信装置１０８、または別の装置１０８、または音声メールプラットフォーム１０６を表す送信先ＴＮを返す。音声メールプラットフォーム１０６は、送信先交換機１０４と同一のネットワーク内にあっても、ＰＳＴＮ１０３を越えてアクセスできるものでもよい。

一実施の形態では、音声メールプラットフォーム電子メール配信問い合わせ１０７には、ダイヤルされたＴＮおよび発呼者ＴＮ（既知の場合）が含まれる。応答に際して、モジュール１０５は、配信フラグ（ＹｅｓまたはＮｏ）、および電子メールアドレスを提供する。

本発明は、電話機とは無関係に、かつ電話サービスプロバイダとは無関係に、自宅電話、オフィス電話、および無線電話を含む任意の型式の電話システムと接続して実装できる。

図１４を参照すると、本発明の技法による呼管理機能を実装するための一アーキテクチャを表すブロック図が示されている。発呼者１０１が被呼者１０９に呼を発信すると、呼はサービスデータベース１０５Ａに格納されたルールに基づいて被呼者１０９にルーティングされる。

発呼者２０２は、被呼者１０９の地上線ＴＮまたは無線ＴＮを発呼できる。地上線の場合、図１４は、呼の「事後ベル（ベルが鳴った後の）」管理を示す。地上線電話機１４２０は、接続されたＬＥＣ１４０１内ＣＯ交換機１０２Ａによりベルが鳴らされる。電話機１４２０が無応答のままでいると、その呼は、（事前に規定しておいた「話中時着信転送／無応答時着信転送」切り換え機能を用いて）公衆交換電話網（ＰＳＴＮ）１０３を経由して、無線通信事業者の移動通信交換機１０４Ｂに転送され、そこで管理される。移動通信交換機（ＭＳＣ）１０４Ｂは、ＳＳ７ネットワーク１４０３を越え、一つ以上の信号中継局（ＳＴＰ）を経由し、信号ゲートウエイ１４０７を通って、アプリケーションプロセッサ１０５Ｂに問い合わせを送信する。

アプリケーションプロセッサ１０５Ｂは、データベース１０５Ａに問い合わせ、移動通信交換機１０４Ｂが用いるルーティング情報を含む回答を返して、呼をルーティングする。可能性のあるルーティング先には、被呼者１０９の無線電話および通信事業者の音声メールプラットフォーム１０６が含まれる。

実施の形態によっては、移動通信交換機１０４Ｂからの問い合わせが、ホームロケーションレジスタ（ＨＬＲ）１４０２を通過してもよい。同じような方法で、発呼者１０１が、被呼者の有線電話１４２０ではなく、被呼者１０９の無線電話に呼を発信する場合、発信元の交換機１０２Ａ２からＰＳＴＮを通りＭＳＣ１０４Ｂに呼をルーティングする。ＭＳＣ１０４Ｂは、これらの呼の「事前ベル」を管理してから携帯電話を鳴らす。場合によっては、発呼者１０１は自動案内係（対話式音声応答、つまりＩＶＲ；図１４には不図示）に接続される。

例えば、被呼者１０９が、家族と地上線１４２０を共有している場合、音声メールプラットフォーム１０６に発呼者１０１を一時的に接続し、音声メールプラットフォーム１０６に、メッセージゲートウエイ１４０８経由でアプリケーションプロセッサ（不図示）の指示のもとに、せりふを再生するような方法をＭＳＣ１０４Ｂに命令することができる。呼は、企業１４１３内でも管理される。この場合、ＰＢＸ１４１１は、情報をルーティングするためのサービスを問い合わせ、音声メール１４１２を企業内で用いることができる。

一実施の形態では、信号ゲートウエイ１４０７、データベース１０５Ａ、アプリケーションプロセッサ１０５Ｂ、およびメッセージゲートウエイ１４０８は、ローカルエリアネットワーク（ＬＡＮ）１４０６を経由してして相互に通信する。同様に、企業１４１３の構成要素は、ローカルエリアネットワーク（ＬＡＮ）１４０９を経由して相互に通信する。ＬＡＮ１４０６および１４０９は、インターネットプロトコル（ＩＰ）１２０２を用いて相互に通信し、ＬＡＮ１４０６は、ＩＰ１２０２を用いてＶＭ１０６と通信する。ゲートウエイ１４１０は、ＬＡＮ１４０９をＰＳＴＮ１０３に接続する。ＳＴＰ１４０４は、ＳＳ７ １４０５を経由して信号ゲートウエイ１４０７と通信する。

一実施の形態では、ユーザープロファイルデータベース１０５Ａは、被呼者の呼管理設定を規定するために以下の情報を格納する：
・ダイヤルされたＴＮのセット（論理的または物理的）
・配信ＴＮのセット（配信装置へのアドレス）
・モードのセット（職場、自宅等）
・ダイヤルされたＴＮとモードの組合せ毎に、ダイヤルされたＴＮを配信ＴＮにマッピングすること。このマッピングには、マッピングを制御する発呼側ＴＮのセットであるフィルタの創成および適用を含めることができる。以下に詳細に説明する。
・被呼者の制御下にあることを確認するためのダイヤルされたＴＮおよび配信ＴＮの認証。以下に詳細に説明する。
呼管理構成インターフェース

本発明の一実施の形態によれば、上記の呼管理設定は、携帯電話またはＰＤＡを経由するウェブサイト等の、ユーザーインターフェースを介してユーザが規定するか、または既定値設定により規定される。ＡＰＩを用いて第３者が構成を実行してもよい。モード選択は、直接行ってもＡＰＩを介して行ってもよい。

以下の説明は、被呼者が指示する選択に従って、ダイヤル発信されてかかってきた呼を、被呼者管理電話番号の何れかにルーティングするよう被呼者が構成可能なソフトウエア型呼管理システムに関する。例えば、かかってきた異なる呼を、異なる配信装置の内の任意の番号にルーティングするよう被呼者は規定でき、このルーティングは、例えば、発呼者がダイヤルした番号、発呼者の識別子、発呼者の場所、発呼者の場所の環境状態、およびリアルタイムの発呼者／または呼を試みた時点での発呼者の入力、を含む因子の任意の組合せに基づく。

一実施の形態では、被呼者は、呼管理モジュール１０５との通信を支援するウェブ型ユーザーインターフェースを介してこのような構成オプションを規定する。図２〜図７および図９〜図１０を参照すると、このような呼管理構成に対して用いることができるウェブ型フロントエンドの実施例を表すスクリーンショットが示されている。当該分野の技術者には言うまでもなく、これらのスクリーンショットは単に例示に過ぎず、本発明の基本的特性から逸脱することなく、多くの異なる編成およびユーザーインターフェース要素を用いることができる。更に、当該分野の技術者には言うまでもなく、ユーザーインターフェースはウェブ型でなくてもよく、システムの被呼者構成を受け入れるための他の任意の型式のユーザーインターフェースを用いることができる。

図２を参照すると、電話設定スクリーン２００が示されている。以下の説明のために、仮定として、スクリーンと対話するユーザは被呼者であるとする。ただし、ユーザは、被呼者に代わって呼管理パラメータを構成する別の個人とすることができる。

ユーザは、フィールド２０１Ａに自宅の電話番号を、フィールド２０１Ｂに携帯電話番号を、そしてフィールド２０１Ｃにオフィスの電話番号を入力する。ユーザは、フィールド２０１Ｄに任意の数の電話番号を追加でき、プルダウンメニュー２０２を介して、追加電話番号に対する説明を規定できる。他のオプションも入力でき、以下が含まれる：
・発呼者ＩＤを持たない発呼者を拒否すべきかをチェックボックス２０３を介して規定すること。
・チェックボックス２０４を介してＶＩＰリストを有効にすること。

ＶＩＰリストの発呼者は特別待遇となる。例えば、通常の呼が音声メールまたはスクリーニングにルーティングされる場合でも、ＶＩＰ発呼者からの呼は、通過できるようシステムを構成できる。ユーザのＶＩＰリストにある番号（人々）からの呼は、スクリーニングとの関連で、彼らの呼が緊急呼と考えられる時、どの「スクリーン」設定も通過する。このような技法を本明細書では「フィルタ処理」と呼ぶ。

リンク２０５は、ＶＩＰリスト内の名前および番号を追加、編集、および削除するためのＶＩＰリスト管理スクリーンへのアクセスを提供する。

図６を参照すると、一実施の形態によるＶＩＰリスト管理スクリーン６００が示されている。リスト６０１は現在入力されているＶＩＰを示す。ユーザは、編集リンク６０２上をクリックすることにより、入力項目を編集するか、または削除リンク６０３上をクリックすることにより、入力項目を削除できる。

編集リンク６０２上をクリックした後、ユーザはフィールド６０４に名前を規定でき、フィールド６０５Ａおよび６０５Ｂに一つまたは二つの電話番号を規定できる。適用ボタン６０６は、変更を適用し、取消ボタン６０７は、どの変更も適用せずにスクリーン６０６を放棄する。

図２を再度参照すると、ユーザは、フィールド２０６、２０７に、呼び出し通知電子メールのために、および音声メールをそれぞれ受信するために電子メールアドレスを規定できる。ボタン２０８、２０９は、呼管理設定アプリケーション内の他のスクリーンへのナビゲーションを支援する。

図３、図４、および図５を参照すると、一実施の形態による呼管理設定スクリーン３００が示されている。

ユーザは、ユーザ定義のそれぞれのモード（行動モード）に対する呼ルーティングを構成できる。本実施例におけるモードは、「私の既定値」、「仕事中」、「在宅」、および「通勤中」である。ユーザは、行動モードメニュー３０１から定義するモードを選択できる。フィールド３０２には、ユーザはモード（行動モード）に対する名称を規定できる。ポップアップメニュー３０３Ａ、３０３Ｂ、３０３Ｃにより、呼が自宅番号、携帯電話番号、およびオフィス番号で受信した場合、それぞれの呼をどのように扱うかをユーザは規定できる。一実施の形態では、それぞれのポップアップメニュー３０３により、呼を特定宛先装置１０８にルーティングするか、音声メールにルーティングするか、または呼をスクリーン表示する、等の中からユーザが選択できる。

チェックボックス３０４により、ユーザはモードに対する現在のスケジュールを有効にすることができる。チェックボックス３０４がチェックされている場合、モードは、ポップアップメニュー３０５で規定した時点で自動的にアクティブ化される。

チェックボックス３０６により、音声メールメッセージを受信した場合、テキスト通知を携帯電話に送信すべきかどうかをユーザは選択できる。

チェックボックス２０７により、音声メールメッセージを受信した場合、電子メールメッセージを送信すべきかどうかをユーザは選択できる。

適用ボタン３０８は、ユーザが指示した変更を適用する。行動モード削除ボタン４０１は、メニュー３０１からモード（行動モード）を削除する。ナビゲーションボタン２０８、２０９により、ユーザは他の呼設定スクリーンにナビゲーションできる。

図３に示す実施例では、自宅、携帯電話、またはオフィスへの呼がそれぞれの配信装置にルーティングされるように、ユーザが「私の既定値」行動モードを構成したところである。

図４に示す実施例では、自宅への呼が音声メールに送信され、携帯電話およびオフィス両方への呼がオフィスに送信されるように、ユーザが「仕事中」の行動モードを構成したところである。このモードは、毎仕事日の午前９時から午後５時までアクティブとなるようスケジュール化されている。チェックボックス３０６は、ボイスメールを受信するとテキスト通知を送信するように、アクティブ化したところである。

図５に示す実施例では、自宅への呼が携帯電話にスクリーニング転送され、携帯電話またはオフィスへの呼が、携帯電話に接続されるように、ユーザが「通勤中」の行動モードを構成したところである。「あなたがコンタクトしようとしている人は、現在利用できなせん、これが緊急である場合は１を押し、そうでない場合は２を押してメッセージを残してください」というメッセージが発呼者に伝えられる。発呼者が１を押した場合、発呼者は携帯装置に接続され、２を押した場合、ボイスメールプラットフォームに接続される。

設定が完了した後、ユーザは、呼管理設定の要約を見ることができる。図７を参照すると、一実施の形態による呼管理要約スクリーン７００の実施例が示されている。ユーザが設定変更用のスクリーンに戻せる編集ボタン７０２とともに設定の要約７０１が示されている。ラジオボタン７０３の内の一つをクリックすることにより、どのモードをアクティブにするかをユーザが選択できる。適用ボタン７０４は変更を適用する。

一実施の形態では、ユーザは、他の手段により同様にモードの中から選択できる。図８を参照すると、携帯電話ハンドセット８００を経由してモードの中から選択するためのユーザーインターフェースの実施例が示されている。

一実施の形態では、本発明のシステムは、明示的な選択、時刻（および／または曜日）、被呼者の場所（例えば、ＧＰＳ測位による検出場所、またはユーザが特定電話を最近用いた記録による検出場所、またはユーザが明示する場所）の内のいずれかに応じて異なるモードを作動させる。一実施の形態では、スケジュール化したモードは、スケジュール化した時間の間、自動的にアクティブになる。一実施の形態では、スケジュール化は、ハンドセットまたはウェブサイトからＯＮまたはＯＦＦできる。

上記で説明したユーザが規定した構成のオプションに基づいて、呼ルーティングマトリックスを構成できる。図１９を参照すると、一実施の形態による呼ルーティングマトリックス１９００の実施例が示されている。マトリックス１９００は、被呼者モードおよび発呼者識別に従って、呼の取り扱いのユーザ選択を要約できる。マトリックス１９００の各行は、モードを表し、各列はフィルタオプション（特定の発呼者または発呼者グループ）を表す。現在モード１９０４も示す。

図示した実施例では、マトリックス１９００は、追加の呼ルーティング構成オプションを規定するための入力フィールドを提供する。例えば、プルダウンメニュー１９０１により、ユーザは、場所または他の因子に基づいて、特定モードをスケジュール化および／またはモードアクティブ化を自動的に取り扱う方法を規定できる。プルダウンメニュー１９０２により、ユーザは、所望のモードに手動で切り換えることができる。リンク１９０３により、ユーザは、追加の編集オプションにアクセスできる。

一実施の形態では、図１９の要約情報および入力フィールドの何れかまたは全てを、他の型式のユーザーインターフェース、例えば、ＰＤＡまたは携帯電話のスクリーンに対するインターフェースを含む、との関連で示すことができる。
呼の取り扱い

呼が被呼者１０９になされた場合、モジュール１０５は、以下の因子のいずれかの組合せに基づいてその呼を導く：上記に規定したような呼ルーティングルール、現在のアクティブモード、発呼者識別（またはその欠如）、呼び出されている電話番号、モード、および上記で説明したような発呼者または被呼者の入力、のいずれかである。一実施の形態では、呼ルーティングは、ユーザが過去に行ったルーティング決定に基づいてシステムが決定することもできる。このように、本発明は、例えば、ユーザのセットの振る舞いに基づく協調フィルタ処理を行って、明示的な選択がなくてもユーザ選択について学習することを含むインテリジェント呼管理アーキテクチャを用いることができる。

例えば、所与の場所で、全ユーザへの呼がほとんど無応答であることがシステムにわかっている場合、システムは、その場所にいる被呼者への呼をボイスメールに自動的にルーティングできる。このような状況が起きる場所の例は、映画館および講義ホールである。システムは、これらの場所の振る舞いを、例えば、システム使用状況に基づいて、経験的に決定できる。代替として、システムは、場所分類のデータベースを用いて、一つの場所から、類似の分類の別の場所へのユーザの振る舞い（またはユーザの協調的振る舞いのセット）を推定することができる。

一実施の形態では、呼の取り扱いは、以下のように達成できる。ユーザ管理電話番号の内の一つに呼がかかってきた場合、データベース問い合わせを行ってから呼を完了させる。データベース問い合わせの結果により、その呼は、元のダイヤルされた装置（管理電話番号と対応付けられる装置）に対して完了するか、別の配信装置（管理されている電話番号のセット内であっても、そうでなくてもよい）にリダイレクトされるか、またはユーザのボイスメールを取り扱うシステムにリダイレクトされる。このように、呼ルーティングは、発呼者および被呼者の双方にとってシームレスとなるように実行される。
ルールベースルーティング

一実施の形態では、本発明のシステムは、データベース１０５Ａに格納したデータに基づいて、ルールベースルーティングを実装する。

ルールは、オペランドと類似した方法で実装される。何れかの所与の呼管理状況では、呼を確実に処理するために、ただ一つのルールを実行する。

本ルールは、被呼者１０９が自身のアカウントを構成すると、ウェブサーバ上およびデータベース１０５Ａ内のプログラムロジックにより創成される。本発明のシステムが管理された呼を取り扱う場合、どの単一ルールを交換機が実行すべきかに関する決定を行なう。二人以上の被呼者１０９が管理電話線（管理ＴＮ）を共有する場合、それぞれの被呼者１０９に対して単一ルールを識別し、問い合わせをしているサーバ（「電話サーバ」、信号アプリケーションプロセッサ等）に返す。そのサーバは、どのユーザを呼び出しているのかを発呼者に尋ねる（例えば、「１を押すとジョー、２を押すとジェーン」）。発呼者が選択した後、適切な呼ルーティングルールを実行する。ユーザが一人しか管理ＴＮと対応付けられていない場合は、発呼者と対話しなくても、そのユーザに対するルールを実行する。従って、一実施の形態では、データベース１０５Ａが、特定発呼者１０９に対するチャート表現を格納する。チャートはルールのセットを説明するものである。各ルールは以下の何れかまたは全てにより適正化される：
・被呼者がどのモードになっているか？
・どのＴＮを発呼者が呼び出したか？
・発呼者はどのグループ（すなわち、発呼者ＴＮのセット）に属しているか？
・発呼者は発呼者ＩＤを有しているか？

各ルールと対応付けられる一つのアクション（または２つ以上のアクション）をＯＰコードとも称する。例としては以下が含まれる：
・呼をＴＮに配信する；
・呼をＶＭにルーティングする；
・呼の配信を試みてから、無応答またはビジーの場合ＶＭに移る；
・スクリーニング（発呼者ＩＤがない場合、発呼者に電話番号入力を要求する）；
・多数の配信ＴＮをシーケンシャルに鳴らし、被呼者に到達した場合、そのシーケンスを停止する；
・多数の配信ＴＮを同時に鳴らす−被呼者に到達した場合、鳴っている他の装置を停止する。

一実施の形態では、データベース１０５Ａには、幾つかのルール表現が含まれ、それぞれには上記の何れかまたは全てが含まれる。

本明細書で説明するように、被呼者１０９のモードは、明示的な選択もしくは場所に基づくか、またはスケジュールもしくは他の所定の条件による。一実施の形態では、定義した期間の後、特定モードは自動的に消滅し、次いで、被呼者１０９は既定値モードまたは以前のモードに戻る。
ルール選択およびアプリケーション

一実施の形態では、テーブルの仕組みおよびインデックス化は、呼の取り扱い動作中の迅速なルックアップが容易になるよう設計する。交換機（ＬＥＣ、ＭＳＣ、ＰＢＸ等）から、管理電話番号に呼がかかってきたという通知を本発明のシステムが受けた場合、本発明のシステムは以下を実行する：
・１．その管理ＴＮと対応付けられる全ての被呼者１０９を決定する。その結果、ユーザＩＤのセットがもたらされる。
・各被呼者１０９に対して：
・２．発呼者ＴＮ（発呼者ＩＤ）に基づいて、発呼者がどのグループのメンバーであるかを決定する。
・３．被呼者がどのモードにあるかを決定する。
・４．ユーザールールテーブル内の全てのルールを、被呼者１０９のＩＤと一致するユーザＩＤ、被呼者１０９の状態ＩＤと一致するユーザ状態ＩＤ（userStatusID）、管理ＴＮ（テーブル内の１は「構わない（don't care）」を意味するールールは任意の管理ＴＮに適用する）と対応付けられるＩＤと一致するユーザ管理アドレスＩＤ（userManagedAdressID）、およびフィルタ型式（filterType）＝フィルタ（FILTER）の場合、発呼者グループＩＤは、発呼者がメンバーであるグループのセット内にある、により識別する。フィルタ型式＝構わない（DON'T_CARE）の場合、ルールは全ての発呼者に適用する。フィルタ型式＝発呼者ＩＤでない（NO_CID）の場合、ルールは、拒否された発呼者ＩＤを有する発呼者に適用する。
・５．ルールを最小ルールランク番号により選択する。

管理ＴＮと対応付けられる各ユーザに対して、選択したルールの「命令」部分を返す。この命令部分は、ＯＰコードおよび幾つかのオペランドから成る。これらは：ＯＰコードＩＤ（opcodeID）、配信装置ＩＤ１（deliveryDeviceID1）、配信装置ＩＤ２（deliveryDeviceID2）ならびに２つの通知オプションすなわち呼通知電子メールオプション（callNotifyEmailOption）および呼通知ＳＭＳオプション（callNotifySMSOption）である。配信装置ＩＤ（deliverDeviceID）はデータベースのどこかに格納されている電話番号を参照する。データベースにより、問い合わせをしているサーバにルール命令が返されると、電話番号が配信装置ＩＤの代わりに返される。

ユーザがプラットフォームにより識別されると（管理ＴＮ上に多数ユーザがいる場合には、発呼者が選択すると）、関係するルール命令（つまりＯＰコード）が実行される。
実施例

図１７を参照すると、ＯＰコードセットを含む被呼者１０９についての例示のルールセットを含むテーブル１７００が示されている。callNotifyEmailOptionおよびcallNotifySMSOptionは、「Ｙ」に設定した場合、どこかに格納したアドレスを用いて、本発明のシステムが、被呼者１０９に呼通知を送信する通知オプションである。
ＯＰコード

以下は、本発明のシステムが用いるためのＯＰコードセットの実施例である。当該分野の技術者には言うまでもなく、多くの他の型式のＯＰコードも用いることができる。ＯＰコード「ダイヤルされている装置に接続（CONECT_DIALED_DEVICE）」は、呼び出し時間に利用できる情報（特に呼び出されている番号）を用いて、データベースロジックにより「接続（CONNECT）」に変換されてから、問い合わせをしているサーバ（「電話サーバ」）に返される。ＯＰコード「内部ＶＭに接続（CONNECT_INTERNAL_VM）」は、データベース内に格納されているボイスメールアクセス番号が、データベース問い合わせを行っているのと同一の電話サーバにより取り扱われている場合、「ボイスメール（VOICEMAIL）」に変換される。この直接内部接続は、追加の呼を発信するのに必要なリソースを節減する。

一実施の形態では、どの通信接続業者でも、ボイスメールプラットフォーム１０６および他の強化したサービスを提供でき、モジュール１０５の通信接続業者と対応付ける必要はない。ユーザは、任意の数のボイスメール収納庫を持つことができるが、全てのボイスメール呼を単一のボイスメール収納庫に導くのが便利であることがわかるだろう。このように、ユーザは、電話サービスに用いている通信事業者の一つが提供するボイスメールおよび収納庫を選択できる。代替として、ユーザは、ユーザのどの電話にも関係していない第３者の通信接続業者からのボイスメールサービスを選択してもよい。

一実施の形態では、本発明が提供するような呼管理サービスと最初に契約した時に、ユーザは、利用可能な通信接続業者リストからボイスメールサービス通信接続業者を選択できる。

次に、呼をボイスメールに移すべきと呼管理構成が規定すると、モジュール１０５は、呼を適切なボイスメールアクセス電話番号に導く。一実施の形態では、無応答呼（ビジーまたは４回鳴らした後の無応答）も、適切なボイスメールアクセス電話番号にルーティングする。

一実施の形態では、呼通知（電子メール経由、ＳＭＳメッセージ、Ｓｔｕｔｔｅｒ（機関銃のような）ダイヤル音等）または呼の集積記録（ユーザ管理電話全てにわたる着信呼一覧表）のような、他の強化サービスを、ユーザの通信事業者とは無関係に提供できる。
リアルタイムマッピング

一実施の形態では、本発明のシステムは、呼毎基準で、リアルタイムのマッピングおよびルール選択を実行できる。従って、入力は、最新情報に基づいてルールを選択できるように、呼がかかってきた時点で評価される。このように、本発明は、最新の情報および設定ソースに基づいて、確実に、呼を正しくルーティングできる。
非ＮＡＮＰ識別子による呼の識別

上記説明のように、本発明の呼管理システムにより、ユーザ（被呼者）は、電話が到達する方法を制御できる。ユーザの電話番号の一つがダイヤルされると、呼はユーザの要望に従ってルーティングされる。従って、かかってきた呼は、例えば、被呼者の現在場所の電話またはボイスメール（電話呼び出しが利用できないと考えられる場合）にルーティングできる。

一実施の形態では、発呼者は、電話番号以外の何らかの識別子（換言すると、電話番号のための北米番号計画（ＮＡＮＰ）に適合していない識別子）で呼び出すべき被呼者を識別できる。従って、基本的に発呼者は電話番号ではなく人を呼び出すよう試みることができ、実際、被呼者は被呼者の電話番号を知らなくてもよい。

例えば、発呼者は、ウェブインターフェース、ＰＤＡインターフェース、携帯電話インターフェース、または何らかの他の手段を介して、呼を開始できる。発呼者は、被呼者名または電子メールアドレスを選択または入力でき、またはウェブページ上のリンクをクリックして被呼者に到達することさえできる。発呼者の動作により、モジュール１０５は、上記説明のように、データベースルックアップを実行し、現在のモードおよび被呼者の選択に合わせた被呼者への電話を開始できる。このように、本実施の形態では、呼は、上記と類似の方法でルーティングされるが、発呼者は電話番号以外の手段により被呼者を識別している。

一実施の形態では、被呼者が規定できるのは、電話番号以外の何らかのメカニズムで被呼者を識別することにより開始した呼を、電話番号をダイヤルすることにより開始した呼と区別して取り扱うことである。従って、例えば、ウェブページから名前を選択して開始した呼は、ボイスメールに回されることになり、一方、電話番号をダイヤルして開始した呼は、被呼者の無線電話にルーティングされることになる。このようなメカニズムは、例えば、図３に示すスクリーン内に、一つ以上のプルダウンメニューを追加することにより実装でき、被呼者が代替の識別手段を用いて呼び出されている場合に、取るべき対応を選択できる。

図１２を参照すると、一実施の形態による電話番号以外の手段による被呼者識別を実装するためのアーキテクチャを表すブロック図が示されている。

発呼者は、例えば、音声通信アプリケーションを実行しているコンピュータ１２０１を介して呼を発信する。発呼者は、ＮＡＮＰ電話番号入力ではない何らかの手段、例えば、被呼者の電子メールアドレスを入力することにより被呼者を識別する。コンピュータ１２０１上で実行されているアプリケーションは、呼管理構成格納部およびルーティングモジュール１０５に接触して、その呼をルーティングする方法を決定する。被呼者の選択に基づいて、ルーティングモジュール１０５は、その呼を別のコンピュータ１２０４、またはＩＰ／ＰＳＴＮゲートウエイ１２０３を経由してＰＳＴＮ１０３に接続された電話１０８Ａ等のＮＡＮＰ装置、にルーティングする。一実施の形態では、その呼は、コンピュータ１２０１からゲートウエイ１２０３に、またはインターネット１２０２を経由してコンピュータ１２０４に、ルーティングされる、

一実施の形態では、非ＮＡＮＰの呼は、ボイスオーバーインターネットプロトコル（ＶｏＩＰ）を用いて発信できる。これらの呼はセッション開始プロトコル（ＳＩＰ）を用いて開始できる。ＳＩＰ呼を再ルーティングするために、呼管理モジュール１０５に、被呼者のＶｏＩＰ電話呼び出しを取り扱うよう登録（ネットワークソフトスイッチにより）できる。被呼者のＶｏＩＰ電話、またはＶｏＩＰ電話１２０４として作用するコンピュータに呼がかかってくると、ソフトスイッチは「招待」メッセージを呼管理モジュール１０５に送信する。呼管理モジュール１０５は、ソフトスイッチに、元々向けられていたように呼を完了させるか、または別の装置（ＶｏＩＰ／ＳＩＰ電話、ＰＳＴＮ電話、またはボイスメールプラットフォーム）に呼を終端させるかのリダイレクションメッセージにより応答する。
区別可能ベル音

一実施の形態では、本発明は、どの番号がダイヤルされているかを含む幾つかの因子、発呼者識別等の内のどれかに基づいて区別可能ベル音を提供する。

図３との関連で上記に説明したように、呼管理スクリーンは、特定条件に応じた様々な種類の呼通知をユーザが規定できるユーザーインターフェース要素を追加することにより、一実施の形態では強化できる。例えば、通知は、配信装置上の区別可能ベル、またはコンピュータ上の区別可能インスタントメッセージ通知とすることができる。ユーザは、オフィス電話からルーティングされた呼は、交互に鳴る短いベルのサイクルで区別される音を用いて自宅用電話を鳴らし、一方、他の呼は標準のベルを用いると規定できる。一実施の形態では、ベルの種類は、標準のＬＥＣ（地域交換事業者）の「区別可能ベル」機能を用いる電話回線と対応付けられる２つの電話番号の内の一つに呼をルーティングすることにより、操作できる。

一実施の形態では、携帯電話のベルの種類をリアルタイムで直ちに修正してから、本システムは、ショートメッセージサービス（ＳＭＳ）メッセージ（または他のデータメッセージ）を、電話上で実行されているソフトウエアアプリケーションに送信することにより、呼をその電話にルーティングできる。ソフトウエアアプリケーションは、ＳＭＳメッセージ内の送信命令に従って電話のベルの種類を変更する。
呼び出している人を被呼者に通知

一実施の形態では、本発明は、ショートメッセージサービス（ＳＭＳ）、電子メール、インスタントメッセージ等の、代替の通信パスを用いて、誰が呼び出しているかを被呼者に知らせる。被呼者へのメッセージには、呼がどのようにルーティングされたか、発呼者の場所、発呼者の電話番号、発呼者名（ユーザ電話帳またはＣＮＡＭデータベース等の他の情報源からの）、発呼者がダイヤルした番号、および発呼の時間等、を含む呼についての追加情報を含めることができる。

一実施の形態では、被呼者は、かかってきた呼のどれがそのような通知を含むべきか、およびどの種類の通信パス／メカニズムを用いるべきかを規定できる。呼の電子メール通知も構成できる。通知の内容には、発呼者の電話番号、発呼者名（ユーザ電話帳またはＣＮＡＭデータベース等の他の情報源からの）、発呼者がダイヤルした番号、および発呼の時間を含めることができる。代替の実施の形態では、他の種類の情報を含めてもよい。

一実施の形態では、呼管理モジュール１０５が、電話会社の交換機１０２またはＰＢＸ１０４Ｃから問い合わせを受信すると、ユーザプロファイルデータベース１０５Ｂを調べて、問い合わせへの応答方法を決定する。データベース１０５Ｂから返される情報には、被呼者通知構成が含まれる。この情報には、被呼者１０９に通知を送信する方法およびそれをどのフォーマットで送信するかが含まれる。電子メール通知の場合には、呼管理モジュール１０５が電子メールメッセージをフォーマットし、インターネットを通し、電子メール（ＳＭＴＰ）サーバを通じてそのメッセージを送信する。
他種通信に変換する呼

一実施の形態では、本発明は、電話呼び出しを、電子メールメッセージ、ＳＭＳメッセージ、インスタントメッセージ、または他の種類の通信に変換できる。

図９を参照すると、呼管理スクリーン３００は、特定の電話呼び出し（上記説明の因子のどれかによる）を、他の型式の通信に変換するようユーザが規定できるユーザーインターフェース要素を追加することにより、一実施の形態で強化される。より詳細には、図９に示すように、仕事中は、自宅の番号への呼をボイスメールに送信するように被呼者が規定できる「ボイスメールに送信」のオプションがメニュー３０３Ａには含まれる。本システムは、ボイスメールを電子メールメッセージに変換するか、またはそれを電子メールメッセージに添付して被呼者の職場の電子メールアドレスに送信するよう更に構成できる。通信内容には、どのようにルーティングされてきたか、発呼者の場所、発呼者の電話番号、発呼者名（ユーザの電話帳、またはＣＮＡＭデータベース等の他の情報源から）、発呼者がダイヤルした番号、および発呼の時間等を含む呼についての追加情報を含めることができる。一実施の形態では、呼および発呼者についてのこの情報は、導き出された情報（例えば、発信電話番号に基づいた発呼者名の電話帳ルックアップ）と組合せた呼管理モジュール１０５への問い合わせに渡した情報、および呼をシステムが処理した時間等の、独立情報から集められる。

一実施の形態では、ボイスメールプラットフォーム１０６は、モジュール１０５に問い合わせて、電子メールを用いてボイスメールメッセージを配信するかどうかを決定する。モジュール１０５は、データベース１０５Ａからプロファイル情報を取得する。この決定は、モード、被呼者、およびダイヤルされた電話番号のどれかまたは全てに応じて、ユーザ選択に基づいてなされる。
異なる電話番号を異なるモードにマッピング

一実施の形態では、本発明は、異なる電話番号を異なるモードにマッピングするのを支援する。単一の被呼者に対しては、幾つかの電話番号、例えば、重要な呼び出し用に一つ、ビジネス用に一つ、使い捨て用の番号が一つ（またはそれ以上）等、を開設できる。このような編成により、電話番号のセットから状況に応じて適切な番号を割り当てることにより、被呼者は自身への呼をうまく管理できる。各種の電話番号は、現実の物理場所または電話機と何ら相関をもたなくてもよい。

図１０を参照すると、異なる電話番号への呼を別々に取り扱かう呼管理スクリーンの実施例が示されている。本実施例では、ユーザが「優先度大」モードを選択している場合、携帯電話への呼だけは、全体を通じてベルを鳴らす。自宅またはオフィスの電話にかかってきた呼は、ボイスメールに直接ルーティングする。このように、最も重要であるとユーザが考えるこれらの発呼者に、携帯電話の番号を割り当てることができる。

一実施の形態では、使い捨て用の電話番号（限定期間の間だけ有効）が提供される。一時的な（使い捨て用）電話番号にかかってきた呼は、ユーザが表明した選択に応じて、ユーザの配信装置のどれかにまたはボイスメールにルーティングされる。一時的な番号の割り当ては、利用可能番号のプールから動的に行うことができる。その番号は、単一の呼の間、短い経過時間の間、または長い時間経過の間、有効である。

一時的な電話番号を用いる一実施例は、インターネットチャットを用いて人々が通信するための連絡番号としてである。一時的な番号は、そのユーザが電話番号を別の人に与えて単一の呼を行うことができるユーザのための「公衆」番号として提供することができる。ユーザの実際の配信装置電話番号は非公開のままである。使用後、その電話番号はある時間経過の間停止されてから、利用可能な一時的電話番号のプールに戻される。

別の実施の形態では、一時的なアドレス番号が、共通のアクセス番号とともにユーザに与えられる。共通アクセス番号（例えば、無料番号）を発信してから、発呼者は一時的なアドレス番号（一連の数字）を入力する。次いで、適切なユーザの配信装置またはボイスメールに呼をルーティングする。本システムは、一時的なアドレス番号、例えば、限定期間の間だけ有効な一意の数字文字列を生成する。その期間、発呼者が共通アクセス番号を発信すると、電話サーバ（不図示）が応答する。電話サーバは、ユーザプロファイルデータベース１０５Ａに問い合わせる。データベース１０５Ａは、その一時的なアドレス番号を、ルーティングルールを決定するための管理アドレスとして取り扱って、電話サーバに渡す。電話サーバはルーティングルールを実行して、呼を電話、ボイスメール、または何らかの他の呼取り扱い装置に送信する。

家族メンバーのサブセットが、無線電話を有する場合の共有回線の状況では、本発明は、構成プロファイルで定義したように、呼を他の電話（無線またはオフィス）の呼から分離できる。
発呼者装置に関する被呼者モード情報

一実施の形態では、潜在的発呼者は、被呼者のモード情報を見ることができる。一実施の形態では、被呼者は、そのような情報を、潜在的発呼者に利用可能とするかどうか選択できる。更に、所望するなら、被呼者は、そのような情報を何人かの潜在的発呼者にだけ利用可能とするよう選択できる。

一実施の形態では、潜在的発呼者は、携帯電話または他の装置に発呼者の電話番号をキー入力することにより、または電話帳から被呼者を選択することにより、または何らかの他の手段により、モード情報を見ることができる。一実施の形態では、適切な場合、発呼装置は、本発明のシステムに問い合わせて、被呼者の現在のモードの記載を取得する。そのモードの表示が潜在的発呼者にディスプレイされ、呼完了を試みるかどうかを決定できる。

この状況では、被呼者のモード情報は、電話呼び出しのどの種類を受け入れるか、または特定の種類を受け入れるかという被呼者の要望、能力、または性向を反映するラベルである。ユーザＢのモードは、ユーザＡがユーザＢに呼を発信する前に、および／または発信した後に提示できる。

モード情報がユーザＡに提示されてから、ユーザＡがユーザＢに呼を発信する場合、ユーザＢに呼を開始するかどうかを決定するのにユーザＢのモードの知識を利用できる。ユーザＢに呼を発信した後に、モード情報がユーザＡに提示される場合は、ユーザＡは、呼をユーザＢが取った場合にユーザＢとの議論の背景としてその知識を利用できるし、またはユーザＢが呼を取らなかった理由を理解するのに利用できる。

表示されたモードは、被呼者が、被呼者のモードと関連させて明示的に設定できるし、または被呼者のモード機能にもできる。換言すると、被呼者は、表示モードが実際のモードと同一とならないように規定できる。モード決定に用いる全ての入力を用いて、ユーザーモードをアルゴリズム的に決定することもできる。ユーザＡは、ユーザＢのモードをクライアント装置（携帯電話または他の装置）上のアドレス帳の記入を見るか、クライアント装置上の「モード表示」ソフトキーを選択するか、またはクライアント装置上の何らかの他の手段によるかして学習できる。ユーザＡは、ユーザＢに発呼した後に、ユーザＢのモードを学習することもできる。

被呼者モード情報は、別のユーザがそれを問い合わせた時に確定でき、または本システムにより定期的に確定できる。モードを定期的に確定する場合、それを格納して問い合わせに利用可能とすることができ、またはその情報にアクセスする全ユーザのクライアント装置に送り込むことができる。

図１１を参照すると、被呼者の現在の行動モード１１０１（自宅）が表示されている携帯電話のディスプレイの実施例が示されている。このディスプレイは、例えば、携帯電話ユーザが、被呼者の電話番号をキーパッド１１０２でキー入力した直後（または、携帯電話ユーザがオンスクリーンリストまたは電話帳から被呼者名を選択した直後）を示している。

一実施の形態では、モード表示は、被呼者が自宅、仕事中、休暇等のどれかを示している。別の実施の形態では、被呼者の行動モードスケジュール、現在のモードが変更される場合の指示および次のモードの指示、転送情報（代替の電話番号等）、またはこれらの任意の組合せ等の、追加情報を表示できる。被呼者は、どの種の情報を表示するかを規定でき、異なる種類の情報を異なる発呼者に利用可能とするか、または他の因子に応じて指示できる。
システム運営の概観

一実施の形態では、本発明のシステムは、以下のように実装される。最初に、かかってくる呼は、以下のようにインターセプトされる：
・住宅回線への呼は、ＬＥＣ ＣＯ内の送信先交換機アドバンストインテリジェントネットワーク（ＡＩＮ）を用いてインターセプトされる。
・無線電話への呼は、ＭＳＣ内の送信先交換機で無線インテリジェントネットワーク（ＷＩＮ）または移動通信網用拡張ロジックのためのカスタマイズアプリケーション（ＣＡＭＥＬ）を用いてインターセプトされる。
・ＰＢＸ外部からかかってきたＰＢＸ内線への呼は、ＰＢＸに接続されたＬＥＣ ＣＯ内のＡＩＮを用いてインターセプトされる。
・別のＰＢＸ内線からかかってきたＰＢＸ内線への呼は、ＰＢＸ内でインターセプトされる。

次いで、データベースチェックを実行して、呼の処置方法を決定する。処置のオプションは：呼完了する、どこかに転送する、またはボイスメールに送信する、である。データベースチェックは、特殊化データベースまたはミラー上で実行する。データベースへのインターフェースには、ＳＳ７を経由するＳＣＰに、またはインターネットを経由するＸＭＬに、ＡＩＮ／ＷＩＮ／ＣＡＭＥＬが含まれる。

データベースチェックは、直接、またはデータベースへのフロントエンドとしてＳＳ７ネットワークを実行するパートナを通じて、リアルタイムでデータベースと接触することによるか（プル型）、データベースのミラーをホストすることにより（プッシュ型）、行うことができる。
全体アーキテクチャおよび運営メカニズム

図１３を参照すると、一実施の形態による本発明を実装するための詳細なアーキテクチャの実施例が示されている。説明のために過ぎないが、図の無線ネットワークはＧＳＭネットワークである。ＣＤＭＡおよび他の無線プロトコルもサポートする。図示のために過ぎないが、冗長な中央化構成を図１３の実施例に示す。但し、当該分野の技術者には言うまでもなく、本発明は、例えば、地理的に分散したアーキテクチャを用いて実施することもできる。

ＳＳ７ネットワーク１３０１は、サービスプラットフォーム１３０４と、無線通信事業者ネットワーク１３０３との間のＳＳ７接続性を提供する。このようなネットワークは、例えば、Ｖｅｒｉｚｏｎ等の無線電話会社により提供される。当該分野の技術者には言うまでもなく、構成要素１３０４と１３０３とを接続するために他のメカニズムを用いることができる。

企業ネットワーク１３０５は、インターネットプロトコル（ＩＰ）を用いてサービスプラットフォーム１３０４に接続する。ＩＬＥＣ ＳＳ７ネットワーク１３０２を用いて地上線電話上でメッセージ待機をＯＮ、ＯＦＦする。要素１３０１および１３０２は本発明を実践するためには含めなくてもよいオプションの構成要素である。

図１３に示す実施の形態では、管理電話番号に向けられた呼をＭＳＣ１３２１が受信すると、ＭＳＣ１３２１は、呼び出されているＴＮおよび発呼ＴＮを含む問い合わせを、Ｎｏ．７信号方式（ＳＳ７）を通してＴＣＡＰメッセージを用いて、アプリケーションプロセッサ−ＳＣＰ１３３０に送信する。このメッセージは、ＳＳ７ネットワーク１３１２内の一つ以上の信号中継局（ＳＴＰ）１３１５、１３０６を越え、そのフォーマットをＳＣＣＰ−ユーザ適合レイヤ（ＳＵＡ）に変換する信号ゲートウエイ１３２６を通って進む。代替として、問い合わせは、ＳＩＧＴＲＡＮプロトコルを用いて、ＭＳＣ１３２１からエッジＳＳ７ゲートウエイ１３１６を通ってアプリケーションプロセッサ−ＳＣＰ１３３０まで、インターネットプロトコル（ＩＰ）ネットワーク１３２５を越えて進むことができる。

アプリケーションプロセッサは、インテリジェントネットワークサービス制御ポイント（ＳＣＰ）１３３０として作用する。ＳＣＰ１３３０は、データベース１３２９に問い合わせて呼の取り扱い方法を決定する。場合によっては、例えば、管理ＴＮが多数ユーザ間で共有されている場合、発呼者１０１は、数字を入力して所望の被呼者を選択するよう（または他の手段により被呼者を選択するよう）促される。そのために、ＳＣＰ１３３０はセッションを確立し、ＭＳＣ１３２１に応答して、呼を、アプリケーションプロセッサ−インテリジェントペリフェラル（ＩＰ）１３３２に、ＰＳＴＮを越えて音声ＸＭＬゲートウエイ１３２８を通すか、またはＶｏＩＰを用いて、一時的に接続するようＭＳＣに命令する。

アプリケーションプロセッサ−ＩＰ１３３２が、呼を受信すると、アインターネットプロトコル１３３１を越えてプリケーションプロセッサ−ＳＣＰ１３３０と通信して、どの音声せりふを、発呼者１０１に対して再生するかを決定する。ＳＣＰ１３３０からの応答を用いて、せりふ格納部１３３３から音声せりふを選択し、取り出す。そのせりふを発呼者１０１に再生する。例えば、従来電話上のキー押下によるデュアルトーンマルチ周波数（ＤＴＭＦ）信号でなされた発呼者１０１の選択が検出され、ＳＣＰ１３３０に転送される。アプリケーションプロセッサ−ＳＣＰ１３３０は、発呼者の選択を用いて、呼の処置方法を決定する。呼に対する処置はＭＳＣ１３２１に送信される。

ＭＳＣ１３２１は、呼の接続をアプリケーションプロセッサ−ＩＰ１３３２から外し、所望の配信ＴＮに呼を転送する。被呼者１０９は、システムによる無応答呼イベントの通知を受けることができる。所望の呼イベント情報は、データベース１３２９から、通知サーバ１３３４に送信される。通知サーバは、ＳＭＳゲートウエイを経由して被呼者１０９の携帯電話にショートメッセージサービス（ＳＭＳ）を送信することを含む様々な方法で、被呼者１０９に通知できる

本システムは、構内交換機（ＰＢＸ）１３３６に取り付けた企業電話（局）を管理することができる。局にかかってきた呼をＰＢＸ１３３６が受信すると、ＰＢＸ１３３６は、アプリケーションプログラミングインターフェース（ＡＰＩ）１３３７を通して、アプリケーションプロセッサ−ＳＣＰ１３３０に問い合わせを送信する。問い合わせからの応答が、呼の処置方法に関してＰＢＸ１３３６に命令する。

ボイスメールメッセージは、ＶＰＩＭゲートウエイ１３４０を用いて、無線通信事業者のボイスメールプラットフォーム１３２０と、企業のボイスメールプラットフォーム１３３５との間で交換可能である。

一実施の形態では、呼ルーティング（ベクトル化とも呼ばれる）は、送信先交換機１０４（電話局（ＣＯ）１０４Ａ内または移動通信交換局（ＭＳＣ）１０４Ｂ）から転送するか、またはダイヤルされたオフィス電話を制御している構内交換機（ＰＢＸ）１０４Ｃから転送することにより達成される。

一実施の形態では、アドバンストインテリジェントネットワーク（ＡＩＮ）技術をＣＯ１０４Ａ内で用いる。アドバンストインテリジェントネットワーク（ＡＩＮ）は、交換機設備からサービスロジックを分離した電話ネットワークアーキテクチャであり、新サービスをサポートするために交換機を再設計しなくても新サービスを追加できる。

別の実施の形態では、無線インテリジェントネットワーク（ＷＩＮ）、移動通信網用拡張ロジックのためのカスタマイズアプリケーション（ＣＡＭＥＬ）、または他の技術をＭＳＣ１０４Ｂ内に用いて、本明細書で説明する呼管理機能を実装する。
ＷＩＮまたはＣＡＭＥＬを用いる無線通信事業者との統合による実装

図１５を参照すると、ＷＩＮまたはＣＡＭＥＬを用いて無線通信事業者と統合することにより、本発明を実施するためのアーキテクチャの実施例が示されている。

図１５に示す実施は、無線通信事業者の移動通信交換局の交換機（ＭＳＣ）１０４Ｂを用いて、地上線、無線、およびオフィス電話を管理する。被呼者１０９の自宅用電話１０８Ａにかかってきた呼は、電話１０１Ａ、１０１Ｂ、１０１Ｃの何れかにより開始され、ＰＳＴＮ１０３を越えて、呼び出されている自宅用電話１０８Ａと対応付けられる電話局（ＣＯ）１０４Ａにルーティングされる。自宅用電話１０８Ａがビジーまたは無応答の場合、呼は、呼管理をするＭＳＣ１０４Ｂに転送される。

同様に、無線電話１０８Ｂに直接かかってきた呼は、ＭＳＣ１０４Ｂで管理される。

ユーザのオフィス電話１０８Ｃにかかってきた呼は、被呼者の公衆ＴＮ（公開ＴＮ）が、ＰＢＸ１０４ＣによりＭＳＣ１０４Ｂに転送され、オフィス電話１０８Ｃが秘匿ＴＮと対応付けられる場合、ＭＳＣ１０４Ｂが管理する。このようにして、被呼者のオフィス電話１０８Ｃに宛ててかかってきた呼は、呼を管理でき、非公開ＴＮを用いる実際のオフィス電話に転送できる可能性があるＭＳＣ１０４Ｂに到達する。

管理ＴＮに対する呼を受信すると、ＭＳＣ１０４Ｂは、ＳＳ７を通るＷＩＮまたはＣＡＭＥＬトリガーを用いて、呼管理モジュール１０５内部のＳＣＰ１５０１に問い合わせる。本図のＳＣＰ１５０１には、サービスデータベース、およびＭＳＣ１０４Ｂが呼を取り扱う方法を決定するデータベースロジック１０２が含まれる。

管理ＴＮが多数ユーザにより共有されている場合、発呼者１０１が、到達しようとしている被呼者を選択できるように、発呼者１０１にせりふが再生される。各ユーザの音声の名前は、せりふのマスターコピー１５０３にオリジナルで格納され、定期的にＭＳＣ１０４Ｂでミラーデータ格納にコピーされている。ＭＳＣ１０４Ｂは、せりふのローカルコピーを用いて、発呼者１０１に被呼者１０９を選択するよう依頼する（例えば、ジョーには１を押し、メアリーには２を押す等）。選択結果はＳＣＰ１５０１に送信され、ＳＣＰは呼完了させるための命令とともにＭＳＣ１０４Ｂに回答する。命令に応じて、ＭＳＣ１０４Ｂは、呼を被呼者の無線電話１０８Ｂ、オフィス電話１０８Ｃ、またはボイスメールプラットフォーム（図１５には不図示）等に転送できる。本実施例では、呼は自宅電話１０８Ａに転送されないはずである。なぜなら、電話１０８Ａは、ビジーであるかまたは無応答であることが既にわかっているからである。サービスデータベースは、ウェブサイト１５０４を通じてまたは電話自動音声応答（ＩＶＲ）システム１５０５を通じて、コンピュータ１５０６により構成できる。

図１５のアーキテクチャは、以下のステップの内の一つ以上を用いて本発明の機能性を提供する設定である：

自宅の電話１０８Ａは、ビジーまたは無応答のとき携帯電話ＴＮに転送されるよう規定する。代替として、以下の技法の内の一つまたは両方を用いることができる：
・無線通信事業者は、有線から無線への市内電話番号ポータビリティ（ＬＮＰ）を用いて、既存の自宅用電話ＴＮを競合地域交換事業者（ＣＬＥＣ）として働くようそれ自体に移植でき、次いで、既存の自宅用電話線を秘匿の物理的ＴＮにより番号を付け直す。これにより、移動通信交換局（ＭＳＣ）１０２Ｂは、ベルが鳴る前に呼をインターセプトし、発呼者がかけようとしている家族（ユーザ）を発呼者が選択できる自動音声応答（ＩＶＲ）メニューを発呼者に提示する。「誰でも」のオプションは自宅用電話を鳴らす。
・無線通信事業者は、被呼者の家族のためにプロキシの自宅用ＴＮとして割り当てるべきそのネットワーク上の新規の、仮想的なＴＮを提供できる。このＴＮは、上記＃１のように働く。従って、被呼者は、彼らの「自宅用番号」としてそれを割り当てるよう奨励される。

オフィス電話１０８Ｃは、ビジーまたは無応答のとき携帯電話ＴＮに転送されるようＰＢＸ１０４Ｃ内で規定するか、またはオフィス電話転送（可変またはＢＮＡ）は、モードおよび／またはフィルタに基づいて動的に構成することができる。

設定が行われると、呼は以下のように取り扱われる：
ケース１−発呼者が携帯電話をダイヤル

ＭＳＣ１０４Ｂ内の交換機は、携帯電話１０８Ｂに接続するか、またはモードおよびフィルタに基づいて別の電話１０８Ｃ、１０８Ａまたはボイスメール１０６にリダイレクトする。
ケース２−発呼者が自宅用ＴＮをダイヤル

呼が無応答の場合、携帯電話交換機に転送される。固定転送または移植された自宅用ＴＮの場合、全ての呼がＭＳＣ１０２Ｂに行ってから自宅用電話１０８Ａを鳴らす。

自宅用電話１０８Ａを共有している場合、発呼者がＩＶＲにより多数のユーザの内の一人を選択することができるように、ＭＳＣ１０２Ｂ内の交換機は、案内のせりふを再生する。

ＭＳＣ１０４Ｂ内の交換機は、携帯電話１０８Ｂに接続するか、またはモードおよびフィルタに基づいて別の電話１０８Ａ、１０８Ｃまたはボイスメール１０６にリダイレクトできる。
ケース３−発呼者がオフィス用ＴＮをダイヤル

呼が無応答の場合、携帯電話交換機に転送される。

ＭＳＣ１０４Ｂ内の交換機は、携帯電話１０８Ｂに接続するか、またはモードおよびフィルタに基づいて別の電話１０８Ａ、１０８Ｃまたはボイスメール１０６にリダイレクトする。

案内のせりふ１５０３、特に、個人化した挨拶および名前は、中央サイトに記録し、データミラーリングを通じて、ＭＳＣ１０２Ｂのそれぞれに分配できる。ＭＳＣ１０４ＢでのＳＳＰ１７０５は、ＭＳＣ１０４Ｂまたは中央に配置されたインテリジェントペリフェラルを用いて案内のせりふを再生することができる。
ＡＩＮを用いるＬＥＣとの統合

一実施の形態では、送信先交換機１０４でのアドバンストインテリジェントペリフェラル（ＡＩＮ）機能を用いて、フィルタ処理および／または案内のせりふを実行してから、自宅用電話１０８Ａを鳴らすことができる。発呼者１０１が、到達しようとしている被呼者１０９を選択した場合、呼を自宅電話１０８Ａに転送でき（所望のユーザを識別する区別可能ベルを用いることになろう）、呼を別の電話（携帯電話１０８Ｂまたはオフィス電話１０８Ｃを含む）に送信することができ、呼をボイスメールプラットフォーム１０６にルーティングでき、または呼を別のサービスにルーティングすることができる。一実施の形態では、被呼者１０９、特定の発呼者１０１が案内をスキップできるか、または他の発呼者とは別に取り扱われることができるフィルタを規定できる。発呼者１０１をフィルターリストに追加するのは、呼完了の後、または会話の前または会話中を含むどの時点でも、または上記で説明したような構成ツールを用いてどの時点でも実行できる。一実施の形態では、ウェブ型ユーザーインターフェースは、かけてきた発呼者、発呼時間、発呼者が選択したユーザ、の通話記録を、フィルタに発呼者を追加するおよび／またはフィルタから発呼者を削除するのに必要な操作ボタンとともに表示する。
動的な番号ポータビリティを用いる実装

図１６を参照すると、本発明の別の実施の形態が示され、上記説明の機能が、発信元および／またはゲートウエイ交換機で代替ＴＮを代用する動的番号ポータビリティ（ＤＮＰ）を用いて実装される。

発呼者１０１は、以下の何れか：住宅、会社間または通信事業者間の無線電話１０１Ａ；イントラ通信事業者無線電話１０１Ｂ；またはイントラ企業電話１０１Ｃで呼を発信する。電話局（ＣＯ）交換機１０２Ａは、電話１０１Ａと対応付けられる。移動通信交換局の交換機１０２Ｂは電話１０１Ｂと対応付けられる。

公衆交換電話網（ＰＳＴＮ）１０３は、ＣＯ交換機１０２Ａ、ボイスメール（ＶＭ）プラットフォーム１０６、およびＣＯ交換機１０４Ａ間で呼を搬送する。ＳＳ７ネットワーク１４０５は、交換機１０２Ａまたは１０２Ｂと、呼管理モジュール１０５との間で非呼パス関係化信号（ＮＣＡＳ）を搬送する。

ボイスメール（ＶＭ）プラットフォーム１０６は、発呼者１０１の音声メッセージを記録することができる潜在的な呼の送信先である。ＣＯ交換機１０４Ａは、自宅（住宅）電話配信装置１０８Ａと対応付けられる地上線電話局交換機である。移動通信交換局（ＭＳＣ）の交換機１０４Ｂは、無線（移動）電話配信装置１０８Ｂに接続される。構内交換機（ＰＢＸ）１０４Ｃは、オフィス電話（局）１０８Ｃに接続される。

一実施の形態では、被呼者１０９は、例えば、コンピュータまたは無線電話のソフトウエアアプリケーション１５０６を用いて、本発明のサービスを構成する。このようなアプリケーション１５０６のスクリーンショットの実施例を、図２〜図７および図９〜図１０に示す。

一実施の形態では、呼管理モジュール１０５には、交換機１０２Ａ、１０２Ｂ、１０４Ａ、およびＰＢＸ１０４Ｃから問い合わせを受け、呼ルーティング情報を返すサービス制御ポイント（ＳＣＰ）１５０１が含まれる。ＰＣＭモード、フィルタならびにリダイレクトロジック１５０２およびＰＣＭ案内ロジック１５０２Ａは、ＳＣＰ１５０１と対応付けられるソフトウエアプログラムである。

データ格納部１５０３は、管理された自宅用電話を共有している多数ユーザから選択するための、発呼者１０１を音声案内する際に用いるためのユーザの音声の名前のマスターコピーを含む。

一実施の形態では、ウェブ構成インターフェース１５０４は、被呼者１０９がサービスを構成するウェブサイトを生成する。

一実施の形態では、被呼者１０９は、電話自動音声応答（ＩＶＲ）サーバ１５０５を用いてサービスを構成できる。

一実施の形態では、呼管理は、発信元交換機１０２Ａまたは１０２Ｂ（発呼者１０１の電話回線１０１Ａまたは１０１Ｂと対応付けられる交換機）または、例えば、動的番号ポータビリティ（ＤＮＰ）を用いるＰＢＸ１０４Ｃでルックアップすることにより実行される。従って、呼はリダイレクトされてから発信元交換機１０２を出る。この実装の利点は、システム全体の通信コストを低減するとともに、異なるシステム（ＰＢＸ等）がユーザ電話の重複したサブセットに対してリダイレクトを制御する場合、実行される可能性のある呼のループを除去することである。

代替の電話番号に再ルーティングする呼と関係するコストの低減効果が得られるように、ＤＮＰを全てのネットワークに実装する必要はない。

一実施の形態では、ＤＮＰは、イントラ企業呼をユーザのオフィス電話にリダイレクトするようユニバーサル交換機（ＣＯおよびＭＳＣ）および／またはＰＢＸを関与させて実装する。一実施の形態では、特定サービスエリアに入る場合、呼をルーティング（ベクトル化）できるように、国際ゲートウエイ交換機にも実装する。

別の実施の形態では、ＤＮＰは、例えば、呼が通信会社交換機を通過せずに搬送される場合、呼発信元装置に実装する。このような技法は、ＰＳＴＮ１０３を用いる装置に用いることもできる。このような装置には、ＩＰテレフォニーを用いて呼を発信するコンピュータ、無線通信事業者の携帯電話、またはピアツーピアの交換機のない携帯電話が含まれる。呼の発信元装置は、ＤＮＰデータベースチェックを実行して代替のＴＮ、および代替のＴＮの回答がない場合に呼び出すためのＴＮ等の、他の呼制御情報を受け取る。

発呼者１０１がＴＮをダイヤルすると、交換機１０２Ａまたは１０２Ｂは、ダイヤルされたＴＮがユーザＴＮ（オプションのステップ）であるか判定する。そうであれば、次いで、ダイヤルされたＴＮ、発呼側ＴＮ、発呼側遮断ＣＩＤフラグ、および交換機識別子（代替のＴＮ選択の場合に用いることがある場所特定のため）を渡してＤＮＰチェックを実行する。チェックから返されるのは、代替の電話番号（ＳＴＮ）、ビジー電話番号（ＢＴＮ）、無応答電話番号（ＮＡＴＮ）、無応答ベル回数（または遅延時間）、および請求書事業体番号（ユーザの交換機ＩＤのことがある）である。

交換機１０２Ａまたは１０２Ｂは、ＳＴＮを呼び出す。ビジーの場合、呼は、ＢＴＮに接続される。「無応答ベル回数」が鳴った後でも応答がない場合、呼はＮＡＴＮに接続される。ＳＴＮは、配信装置（有線または無線電話）または案内のＩＶＲサービス等の別の装置でもよい。

加えて、配信装置のための送信先交換機１０４Ａ、１０４Ｂ、または別の送信先交換機が案内サービスとして作用してもよい。案内サービスは、呼をリダイレクトするか、発呼者１０１にオプション（ボイスメールに接続を試みるかもしくはボイスメールに移るか、または発呼者１０１に、オプションのリストからどの被呼者を呼び出すかを選択させる）を提示するか、またはスクリーニング選択を被呼者１０９に提供するかできる。例えば、案内は、被呼者１０９を呼び出し、誰が電話しているかを知らせ、被呼者１０９に呼完了オプションを提示することができる。

ＢＴＮおよびＮＡＴＮを用いることにより、ＬＥＣは無線通信事業者に宛てた呼を撤回することができる。この方法で、彼らは、顧客に、おそらくＬＥＣネットワーク上に単一ボイスメールボックスを持たせることができる。この仕組みにより「ある人のために、その場所毎にではなくメッセージを残す」サービスが可能となる。有線通信事業者は、ＤＮＰにより顧客に有線回線ＴＮの背後にある無線ＴＮを隠させることもできる。

返されたＤＮＰ情報内に含まれるＢＴＮおよびＮＡＴＮにより、発信元の交換機１０２Ａ、１０２Ｂの所有者が、顧客、発呼者に音声メッセージオプションを提供することもできる。このようなサービスは、例えば、＊１１または他のプレフィックスコードまたはアクセスＴＮを１０桁番号の前にダイヤルすることにより、実装できる。被呼者１０９がＤＮＰユーザで、ＢＴＮおよびＮＡＴＮを有する場合、発呼者１０１はボイスメールに直接接続される。ＢＴＮまたはＮＡＴＮが提示されない場合、＊１１サービスは、その呼に直接接続するか、または発呼者１０１にボイスメッセージオプションが利用できないことを知らせることができる。この仕組みにより、「ある人のために、発呼者と話すリスクなしでメッセージを残す」サービスが可能となる。

一実施の形態では、ＤＮＰチェックで返されたＢＴＮおよびＮＡＴＮは、チェックをする交換機によって異なる。ＤＮＰチェックには、ＤＮＰシステム内部の場所にマッピングすることができる交換機ＩＤが含まれる。ＤＮＰはローカルアクセス番号を動的に代用できる。これを行って、例えば、ボイスメールネットワークのアクセス料金を最小化することができる。一実施の形態では、ＢＴＮおよびＮＡＴＮは、ユーザが直接構成しないのが普通である。その代わりに、ユーザは第３者機関のＶＭ通信接続業者を選択し、その通信接続業者がアクセス番号を供給する。

一実施の形態では、案内の挨拶はフィルタおよびモードと関連している。例えば、発呼者１０１が被呼者１０９の自宅ＴＮをダイヤルすると、発呼者１０１は、被呼者１０９の現在のモードに基づく異なる個人的挨拶、すなわち、「現在通勤中です。メッセージを残していただければ、行き先に到着したときにお電話致します」、または「今日は出勤しています。１を押してオフィスの電話に接続してください」を受信することがある。

同様に、一実施の形態では、モードおよび／またはフィルタを用いて、上記に詳細に説明したように、携帯電話または他の電話のベルのモード（大音量、小音量、振動）および／またはベルの音（リンリン“電話ですよ”等）を選択できる。

以下は、一実施の形態によるＤＮＰを用いて本発明の機能を実装するために用いる操作ステップのセットである。
ケース１−発呼者が地上回線電話（ＣＯ交換機に接続されている）または無線電話（ＭＳＣ交換機に接続されている）からＰＳＴＮ ＴＮをダイヤル

発信元交換機は、オプションでＤＮＰが管理するＴＮかどうかを判定する。一実施の形態では、この情報は、ＳＣＰ１５０１内のデータベース（不図示）から定期的に通信事業者に送り出される。一実施の形態では、このデータが通信事業者に送り出された場合、通信事業者は、連携するデータベース（ＳＣＰ１５０１内のデータのミラー）を有するネットワーク内ＳＣＰを用いて、呼ルーティング情報を問い合わせる。このステップはネットワークＳＳ７から出るトラヒックを最小化する。ユーザがＤＮＰを有するかどうかを調べるこのチェックは、ネットワーク内ＬＥＣ、または無線通信事業者の定期的に、例えば、１５分毎に、関与するデータベース上で実行できる。一実施の形態では、ユーザがＤＮＰサービスを有する場合、ＤＮＰデータベースへのＤＮＰチェックが行われて現在データが取得される。

ＴＮがＤＮＰにより管理され、または前回のステップが実行されなかった場合、典型的には、Ｎｏ．７信号システム（ＳＳ７）１４０５上で搬送されるトランザクション機能応用部（ＴＣＡＰ）メッセージを用いて、ＤＮＰチェックを実行する。一実施の形態では、以下の情報が、例えば、交換機１０２Ａまたは１０２Ｂからサービス制御ポイント（ＳＣＰ）１５０１へのＴＣＡＰメッセージを介して、ＤＮＰデータベースに渡される：
・ダイヤルされたＴＮ
・発呼側ＴＮ
・発呼側遮断ＣＩＤフラグ（通知している間番号表示を抑える）
・交換機ＩＤ

一実施の形態では、以下の情報が、例えば、ＳＣＰ１５０１からＳＳＰへのＴＣＡＰメッセージを介して、ＤＮＰデータベースから返される：
・代替のＴＮ（ダイヤルされたＴＮと同一のこともある）
・オプション：ＢＴＮ
・オプションのＮＡＴＮ、ＮＡベル回数または遅延時間
・ユーザ請求書プロキシＩＤ（ユーザの通信事業者または交換機情報のこともある）
ケース２−発呼者がＴＮまたは外線を用いてイントラＰＢＸ呼をダイヤル

ＴＮ／外線を用いて、ＤＮＰチェックを、例えば、ＨＴＴＰを越えるＸＭＬを用いて実行する。一実施の形態では、以下の情報をＤＮＰデータベースに渡す：
・ダイヤルされたＴＮ／外線
・発呼側ＴＮ／外線
・発呼側遮断ＣＩＤフラグ
・ＰＢＸ ＩＤ

一実施の形態では、以下の情報はＤＮＰデータベースから返される：
・代替のＴＮ／外線（ダイヤルされたＴＮ／外線と同一のこともある）
・オプション：ＢＴＮ／外線
・オプション：ＮＡＴＮ／外線、ＮＡベル回数または遅延時間
・ローカル呼フラグ（使用量請求書を創成するために用いる）
・部門請求書ＩＤ

一実施の形態では、ＤＮＰは、マスターデータベース、および多数の地理的に離隔した場所にあるミラーデータベースの分散ネットワーク、により実装される。ＤＮＰチェックをＳＳ７ネットワーク１４０５上で実行すると、グローバルタイトル変換（ＧＴＴ）が用いられて、アクティブな、または最良のデータベース（ＳＣＰ１５０１）を見付けて問い合わせが行われる。ＳＳ７は第３者機関が提供するものでもよい。

一実施の形態では、ＤＮＰチェックは、ＤＮＰサービスのユーザがダイヤルされたＴＮに実行するだけである。事前適格データベースを、ＬＥＣのネットワーク内でＬＥＣがホストできる。このような実装により、ＤＮＰチェックのトラヒックは時間全体にわたって緩やかに増大する。システム障害が起きた場合、既定値の対応は、できれば、元のダイヤルされた番号への呼を完了させることである。事前適格データベースは、アクティブなＤＮＰデータベースの更新よりもずっと低い頻度で更新できる。
ネットワーク内ルーティングおよびネットワーク外ルーティング

本発明は、多様なアーキテクチャで実装でき、呼ルーティングを発信元交換機もしくは送信先交換機、またはゲートウエイ交換機のいずれで実行するかに無関係に動作させることができる。従って、一実施の形態では、呼ルーティングを、発信元変換機で実行する。代替として、呼ルーティングを、呼パスに沿った任意の他の交換機で実行できる。一実施の形態では、多数のルーティングを、呼パスに沿った異なるポイントで実行できる。ＤＮＰチェックは、呼ルーティング操作のための情報を取得するために任意のポイントで行われる。一実施の形態では、多数のＤＮＰチェックが、多数の交換機の要求に従って行われる。別の実施の形態では、フラグを設定して、追加の不要なチェックを避けるために、その呼に対してＤＮＰチェックが既に行われていることを示すことができる。

図２０を参照すると、本発明の実装を用いて、ネットワーク内およびネットワーク外の呼ルーティングに対するアーキテクチャの実施例が示されている。二つの場合を対比すると：

ケース１−ネットワーク内発呼者
ネットワーク２００２に属する発呼者１０１Ａが、ダイヤルＴＮ１０８Ａで被呼者１０９にダイヤルする場合（交換機１０４ＡＢが取り扱う）、発信元交換機１０２ＡＡは、交換機１０４ＡＣを経由して呼を代替のＴＮ１０８Ｂに再ルーティングする。

ケース２ａ−ネットワーク外発呼者
ネットワーク２００２に属さない発呼者１０１ＢがダイヤルＴＮ１０８Ａで被呼者１０９にダイヤルする場合、ゲートウエイ交換機２００１が、交換機１０４ＡＣを経由して呼を代替のＴＮ１０８Ｂに再ルーティングする。

ケース２ｂ−ネットワーク外発呼者
ネットワーク２００２に属さない発呼者１０１ＢがダイヤルＴＮ１０８Ａで被呼者１０９にダイヤルする場合、ゲートウエイ交換機２００１、または他の交換機が呼を再ルーティングしない場合、被呼者の送信先交換機１０４ＡＣは、代替のＴＮ１０８Ｂに呼を再ルーティングできる。
ＤＮＰ請求書

ＤＮＰにより、発信元交換機１０２は、発呼者１０１の代わりに呼を転送する。被呼者１０９は発信元の交換機１０２の所有者の顧客でなくてもよい。従って、一実施の形態では、本発明は、ＤＮＰを使用し、課金転送サブシステムを含む。

本実施の形態によれば、請求書の記録が、発信元交換機１０２から、顧客に請求できる事業体に移管される。請求書記録をダイヤルした番号の交換機に転送できる。発信元がダイヤルしたＴＮと対応付する交換機から、転送番号に呼が転送された場合、その費用は被呼者に課金されるべきである。

以下の表で一実施の形態による請求書の枠組みを説明する。

緊急／災害番号リダイレクション

一実施の形態では、本発明は、緊急または災害の場合の、電話呼び出しの自動および／または事前構成したリダイレクトを提供する。

地震、一台以上のユーザの配信装置の損壊、またはユーザに利用不可能になる等の、災害が発生した場合、ユーザはスクリーン３００を用いて、ユーザの呼を域外配信装置（電話）にルーティングさせることができる。要望があれば、この目的のために「緊急」モードを予め定義しておくことができる。一実施の形態では、「緊急」モードは、電話番号のセットに到達できなくなったことを本発明のシステムが検出した場合、または連絡を受けた場合、自動選択される。

電話交換機への損傷により、交換機が取り扱う管理電話番号に発信した呼ルーティングが本システムで利用不可になった場合、一実施の形態では、送信先の交換機ではなく、発信元の交換機が問い合わせを実行する。一実施の形態では、発信元交換機に基づくリダイレクトは、異常な状況の間だけでなく常時実行される。一実施の形態では、本システムは、交換機が正常であることを監視することにより、交換機に付帯の管理電話番号のセットのための交換機の故障を、例えば、定期的に交換機に問い合わせることにより検出する。無応答の場合、交換機は利用不可と推定され、交換機に付帯の管理電話番号を有する全ユーザは、自動的に「緊急」モードに置かれる。

ＤＮＰを用いて耐災害性が高い電話ネットワークを創成することができる。ある区域（電話回線一本から建物、市単位まで）で電話サービスが中断する事態が起きた場合、その区域にかかってくる呼は、代替の場所に迅速に再ルーティングすることができる。災害復旧サービスは、災害が発生したことを顧客が通報した場合（またはそのような状況が他の手段により検出された場合）、全ての管理ＴＮが、対応する代替のＴＮにルーティング（ベクトル化）されるという本発明の技法により予め構成しておくことができる。

図１８を参照すると、本発明の一実施の形態による耐災害ＤＮＰアーキテクチャを実装するためのアーキテクチャを表すブロック図が示されている。

マスターＤＮＰデータベース１８０２のミラーコピー１８０１が提供される。呼管理サーバのバックアップセット１８０６が、地理的に離隔した場所に配置される。交換機１０２Ａおよび１０２Ｂには、どちらにもＤＮＰデータベース１８０２のミラーコピー１８０１を収納して、ローカルにチェックすることができ、または両交換機はＳＳ７ネットワーク１４０５を通じたＴＣＡＰメッセージを用いて通信事業者のネットワークの外側のＤＮＰデータベースをチェックできる。

これらの問い合わせおよび応答は、一つ以上のサービス転送ポイント１８０７を通って進むのが典型的である。一実施の形態では、ＳＴＰ１８０７は、ＳＳ７インターフェース１８０４で対にした高信頼性クロス接続対で実装する。

サービス制御ポイント１５０１（同様に冗長な対で実装される）は、ＤＮＰデータベース１８０２のミラーコピー１８０３をローカルにチェックする。このデータベースチェックは、主呼管理モジュール１０５上、またはミラー１８０６と呼ばれる呼管理サーバのバックアップセット上で実行できる。任意の数のミラー１８０６を提供することができる。

ＰＢＸ１０４Ｃは、ＨＴＴＰインターフェース１８０５を介したＩＰ上のＨＴＴＰを用いて、ＤＮＰデータベース１８０２、またはミラーデータベース１８０３をチェックする。

トラヒック解析器１８０８は、トラヒックパターン解析のためにそれぞれのＤＮＰデータベース１８０２、１８０３から使用量情報を収集する。

構成インターフェースサーバ１５０４は、例えば、被呼者１０９がコンピュータ１５０６を用いて被呼者のサービスを構成できるウェブサイトをホストするウェブサーバとして実装される。

加えて、ＤＮＰを用いて、既知もしくは疑わしいテロリストまたは国家に敵対する他の者の呼び出しパターンによりテロリストのヒューマンネットワークを識別するために、トラヒック解析を支援することができる。呼ごとベース（または定期的更新）の場所情報を追加して、協調した攻撃が、疑わしく、かつ予め定義した使用量パターンをリアルタイムで探すことにより検出できる。図１８を再度参照すると、トラヒック解析構成要素１８０８は、電話使用量の疑わしいパターンを探し出すことができる。例えば、構成要素１８０８は、所与の時間内で多数の空港のゲートへの多数の呼（３空港ゲートからの２つのリンクした呼）を探すことができる。この出来事が検出された場合、適切な政府機関に警報を転送することができる。
共有電話線

多くの家庭では、自宅ＴＮは多数の居住者間で共有されている。一実施の形態では、発呼者１０１が、被呼者１０９の共有自宅電話１０８Ａを呼び出す場合、発呼者１０１は、彼らが接触したい居住者の選択を提示される。この選択は、電話が鳴る前、または代替として、電話が無応答（ビジーまたは無応答）の場合だけ提示する。その呼は、発呼者１０１が選択した後、リダイレクトできる（フィルタ、プロファイルパラメータ、設定、およびモードごとに）。

別の実施の形態では、自宅電話回線を共有する各ユーザは、自身の個人電話番号（ＰＴＮ）を有する。このＰＴＮは、被呼者１０９に与えられた恒久ＴＮでも、一時的なものでもよい。このようなＰＴＮのセットは、同一の自宅電話回線１０８Ａへの全てのポイントに構成される。

ＤＮＰがなければ、これらの別名（エイリアス）のＴＮのそれぞれが同一電話回線を鳴らす。このような個人ＴＮを、ＤＮＰサービスエリア内のどこに住んでいても各人ごとに用いることができる。

ＤＮＰがある場合、被呼者１０９は、被呼者の個人ＴＮへの呼が共通の自宅回線１０８Ａ、または別の電話回線（携帯電話１０８Ｂ、オフィス電話１０８Ｃ、学生寮電話、休暇中の自宅電話等）を鳴らすかどうか決定できる。本実装では、被呼者１０９は、ＤＮＰが有効なエリア（例えば、北米番号計画が有効なエリア）内にいる限り、常に彼らに到達する生涯ＴＮを有する。追加のＴＮは、電話回線の場所専用でもよい。例えば、発呼者１０１は、ユーザＸに対してＰＴＮー１、ユーザＹに対してＰＴＮー２、またはＸおよびＹの住居用電話回線（自宅）に対してＴＮー３をダイヤルすることができる。この場所ＴＮは、ピザ配達等の、場所型サービスに対して割り当てるのが普通である。

呼び出されているＴＮに基づくフィルタのための情報は、被呼者１０９のアドレスブックから抽出できる（バッチまたはリアルタイムで）。このアドレスブックは、ユーザーコンピュータ、異なるサーバ（マイクロソフトエクスチェンジサーバ等）、またはウェブ型アドレスブックに格納できる。
追加のＤＮＰ特記事項

ＤＮＰにより、第３者機関の企業は、共通通信事業者の音声装置の制御に関与する顧客にアプリケーションサービスを提供できる。
セキュリティ

一実施の形態では、代替のＴＮ（ＳＴＮ）（配信ＴＮ）は、誰かが発呼者１０９の呼をハイジャックするリスクを最小限にするために、承認を受けてから使用するよう選択できる。一実施の形態では、この認証プロセスは、ウェブブラウザまたは電話ＩＶＲを使用し、代替電話番号（ＳＴＮ）のユーザーパレットに追加すべき新規番号を記入するユーザーロギングから成る。ユーザは、認証キー（数字のシーケンス等の）を与えられ、次いで、ユーザは特別なアクセス番号（無料番号等）を呼び出す。一実施の形態では、ＳＴＮのユーザ所有権（またはＳＴＮへのアクセス権）が発呼者ＩＤを介して検証できるように、ユーザは、追加すべきＳＴＮからこの呼び出しを行わなければならない。ユーザは認証キーをキー入力する。番号が承認されると、ユーザは、個人構成を変更して、それを自在にリダイレクトできる。この処理を用いて、呼ルーティングのための送信先として利用可能な配信ＴＮのパレットを常駐させる。
ＥＮＵＭ

一実施の形態では、次いで、ＤＮＰチェックから返されたＳＴＮまたはＢＴＮまたはＮＡＴＮを用いて、電子番号マッピング（ＥＮＵＭ）データベースをチェックして、更に、ボイスメール／音声メッセージ配信のための電子メールアドレスを含むユーザの連絡オプションを決定できる。
通知

一実施の形態では、ダイヤルされたＴＮはＤＮＰデータベースによりチェックされ、通知メッセージがＴＮの所有者に送信される。このメッセージは、ＳＭＳ、電子メール、インスタントメッセージ（ＩＭ）等を介して配信できる。このメッセージは、呼び出される番号（ダイヤルされたＴＮ）、発呼者ＴＮ、発呼者名［発呼者名（ＣＮＡＭ）サービスを用いて］、呼の発信場所または他の発呼者モード情報等の内のどれかまたは全てを含むことができる。一実施の形態では、通知は、呼が完了しない場合でも送信することができる。

通知は、本発明の呼管理システムと対応付けられていなくても、任意の装置に送信することができる。通知は、ダイヤルされたＴＮまたはＳＴＮが配信装置に宛てたものかどうかにかかわらず配信装置に送信することもできる。「発呼側遮断ＣＩＤフラグ」が発呼側ＴＮの遮断を示す場合、一実施の形態では、発呼側ＴＮを通知内で送信しない（適切な規則に従う）。
フィルタに基づく優先度

上記説明のように、本発明では、呼は、各種の情報、パラメータ、およびユーザ選択に基づいてルーティングされる。このようなパラメータの一つは、「フィルタ」であり、換言すると、何人かの発呼者からの呼が通過を許可され、他の発呼者からの呼はボイスメール（等）にルーティングされる。

一実施の形態では、呼の優先度に対してもこのようなフィルタを用いる。例えば、通勤モードの間、発呼者が「友人および家族」であることを判定するフィルタは、その呼をユーザの携帯電話に接続し、他の呼はボイスメールにルーティングすることになる。「電話セールス」フィルタは、丁寧かつ個人的な「結構です」メッセージで打ち切る。

このような場合、「電話セールス」フィルタは、マスクされた発呼者ＩＤ、または抑圧した自動番号識別（ＡＮＩ）で呼を探す。抑圧ＡＮＩと遮断発呼者ＩＤを区別できる実装では、遮断発呼者ＩＤの呼は、ユーザが話したい発呼者からということになる。その呼は、発呼者ＩＤがユーザに知らされなくても「許可」フィルタにあるとして事後にマークすることができる。換言すると、本システムは、発呼側ＴＮを見分け、発呼側ＴＮをユーザに知らせなくても、それをユーザ特性と調和させることができる。

州によっては、遮断発呼者ＩＤをもつ発呼者の呼び出した側の番号を格納するのを禁止していることがある。このような場合、フィルタ化を可能にする一技法は、マッチングさせるためのハッシュ関数としてトラップドア暗号アルゴリズムを用いることである。このようにすると、格納されたどんな情報も、遮断発呼者ＩＤを有する発呼者ＴＮに逆変換できず、従って、法規制に準拠することになる。一方向の暗号化データだけが、格納されマッチングされることになる。代替の「電話セールス」フィルタは、電話セールス業者が普通に用いる無料ＴＮ（８００、８６６等）の発呼者ＩＤを有する発呼者をフィルタで除去することになる。

本システムは、呼が電話セールスかどうかを、発呼者が発信する呼のパターンを調べることにより判定することもできる。発呼者が短時間の間に他のユーザ（または非ユーザ）に多数の呼を発信している場合、特に、その呼が連続したＴＮの場合、その発呼者は、電話セールスであると考えられる。発呼者を電話セールスとして分類する別の方法は、ユーザからの入力を受け付けることである。多数のユーザが発呼者からの電話セールスの呼を報告すれば、本システムは、その事実を記録してブラックリストを保守管理することになる。ユーザからの入力は携帯電話から受信できる。電話セールスのＴＮまたは名前の蓄積データベースは、ブラックリストまたは「スパムリスト」として用いることができる。

ＤＮＰにより、ユーザが任意の配信ＴＮを指示できる個人用の、長期間ＴＮが容易になる。このＴＮは、ユーザが番号計画領域内のどこかに住所を変更した場合でも保持される。従って、ＤＮＰはＬＮＰの必要性を未然に防ぐことになる。
追加の変形および特徴
ネットワーク内にメッセージ格納部を有するクライアント型アプリケーション内のボイスメール

一実施の形態では、携帯電話等のクライアント装置が、呼を発信している間にビジーまたは無応答状態を検出すると、その装置は、ボイスメールメッセージを記録し、それを被呼者のボイスメールプラットフォームまたは被呼者のクライアント装置に直接転送する。

ボイスメールメッセージは、ピアツーピアで送信することができるので、ネットワーク内の任意の（またはほとんどの）ボイスメールインフラストラクチャを無視できる。クライアント装置が、ビジーまたは無応答状態を検出すると、被呼者の音声による名前および挨拶について、ならびに被呼者のクライアントにメッセージを配信するのに必要な格納−転送アドレス情報について、ボイスメール制御交換機データベースに問い合わせできる。被呼者のクライアント装置がもはやビジーではなくなると（呼が終了または装置がＯＮになると）、クライアント装置が同一データベースに登録するので、格納ー転送ネットワークは、ボイスメールを配信できる。クライアントが記録したボイスメールメッセージは、電子メール、ＩＭ、またはＭＭＳ経由でユーザにオプションで配信できる。ボイスメール格納部は、電子メールメッセージ格納部に用いられる従来のアーキテクチャと類似の方法でネットワーク内に分散できる。
遠隔呼の管理システムおよび無線クライアント装置

図２１を参照すると、一実施の形態による通信システム２１００のアーキテクチャを表すブロック図が示されている。

通信遠隔制御（ＣＲＣ）システム２１０２が、ＣＯ１０４Ａ、ＭＳＣ１０４Ｂ、およびＰＢＸ１０４Ｃ等の送信先交換機を含む多数の通信サービス接続業者のネットワークを横断する通信サービスを制御し、協調させる。一実施の形態では、ＣＲＣシステム２１０２は、図１〜図２０と関連する上記説明の呼管理システムに実装して、呼管理の遠隔構成、多数の通信接続業者ネットワークを横断する運営、動的構成、および通知等の、追加の機能を提供できる。（簡潔にするために、これらシステムの要素は図２１から省略してある）。被呼者２１０９は、ＣＲＣシステム２１０２を用いて、多数の電話ネットワークを横断する呼管理機能のセットを遠隔構成するためのクライアント装置２１０４を用いる。クライアント装置２１０４は、無線装置であってもよい。クライアント装置２１０４上のユーザーインターフェースは、図２〜図１１との関連で上記説明したインターフェースと類似していてもよい。ＣＲＣシステム２１０２は、多数の交換機１０４からのデータを用いて、被呼者２１０９に利用可能な通信サービス機能を行う。一実施の形態では、被呼者２１０９は、ＣＲＣシステム２１０２サービスの加入者またはメンバーなので、被呼者１０９とは異なる。ＣＲＣシステム２１０２には、呼管理モジュール２１０５を実行するためのサーバ２１１５を含めることができる。クライアント装置２１０４は、例えば、無線の、帯域幅限定のチャンネル（他の通信チャンネルまたはメカニズムを用いることができるが）を通じて、サーバ２１１５と通信する。

他の実施の形態では、クライアント装置２１０４は、携帯電話、携帯情報端末、または携帯コンピュータであってもよい。一実施の形態では、クライアント装置２１０４は、ＣＲＣシステム２１０２もユーザの配信装置１０８Ｂの内の一つとして同様に用いる携帯電話である。クライアント装置２１０４を、図２１に示すように、配信装置１０８Ｂ内にまたはそれと統合して含めることができ、または配信装置１０８Ｂとは別体とすることができる。
管理アドレス

管理アドレスは、配信装置１０８の電話番号でもよく、または任意のの装置または電話回線と直接対応付けられない電話番号でもよい。管理アドレスは、電話番号と無関係な英数字の文字列とすることができる。ユーザ、またはＣＲＣシステム２１０２は、専用で用いるための管理アドレスを割り当てることができる。例えば、緊急呼だけに管理アドレスを指定することができる。管理アドレスは、何れかの通信接続業者との加入者関係より長期間、ユーザに割り当てることができ、または限定期間もしくは限定回数の電話呼び出しの間だけ有効な一時的番号として割り当てることができる。管理されたアドレスには、上記説明のユーザアドレスを含めることができる。

呼管理モジュール２１０５は、送信先ネットワーク１０４を横断する呼の制御およびリダイレクトを取り扱う。呼管理モジュール２１０５は、以下から管理アドレスにリダイレクトする：
１．アドバンストインテリジェントネットワーク（ＡＩＮ）または他の呼ルーティング制御技法を用いる無線通信事業者のローカル交換事業者交換機。
２．無線インテリジェントネットワーク（ＷＩＮ）または移動通信網用拡張ロジックのためのカスタマイズアプリケーション（ＣＡＭＥＬ）または他の呼ルーティング制御技法を用いる無線通信事業者の移動通信交換局の交換機。
３．電話アプリケーションプログラミングインターフェース（ＴＡＰＩ）または他の呼ルーティング制御技法を用いる構内交換機（ＰＢＸ）。
４．セッション開始プロトコル（ＳＩＰ）または他の呼ルーティング制御技法を用いるボイスオーバーＩＰ（ＶｏＩＰ）。
５．標準またはカスタムの呼ルーティング技法を用いる他の音声呼び出し交換装置。

呼管理モジュール２１０５は、ユーザ構成データ、ユーザ状態、およびシステム状態の組合せに基づいて呼を管理できる（例えば、配信装置１０４、ボイスメールプラットフォーム１０６、または他の呼終端装置にルーティングする）。

呼管理モジュール２１０５は、呼の事前ベルまたは事後ベルを管理できる。
事前ベル管理中は、交換機１０４が呼ルーティング情報について呼管理モジュール２１０５に問い合わせてから、配信装置１０８を鳴らすのが典型的である。事後ベル管理中は、交換機１０４が最初に配信装置１０８を鳴らし、無応答で去った（無応答またはビジーで鳴らした）後に、呼ルーティング情報について呼管理モジュール２１０５に問い合わせる。

一ネットワーク上の交換機１０４（所有交換機）と対応付けられる管理アドレスを、別のネットワーク上の交換機１０４（制御交換機）が、無応答の呼を制御交換機に転送するよう所有交換機に提示することにより管理できる。この提示は、一回限りの設定イベントでもよく、所有交換機との継続的な相互作用を必要としない。

管理アドレスへの呼は、呼ルートのトポロジー内の「上流」で交換機によりインターセプトし、管理することができる。ＰＢＸ１０４Ｃでは、デスク電話と対応付けられる直接内線ダイヤル（ＤＩＤ：ＰＢＸダイヤルイン）電話番号をＰＢＸ１０４Ｃによりルーティングでき、またはこれらの電話番号をＣＲＣシステム２１０２によりＰＢＸ１０４Ｃの「上流」で管理できる。ＤＩＤ電話番号は、ＰＳＴＮ１０３接続をＰＢＸ１０４Ｃに提供しているＬＥＣまたはＶｏＩＰ通信事業者の交換機により、直接制御される。（これらのＤＩＤ電話番号は、ＰＢＸ１０４Ｃをホストする企業にリースされるのが典型的である）。この状況では、ＤＩＤ電話番号は、企業のために働くＬＥＣまたはＶｏＩＰ交換機により制御される管理アドレスでもよい。管理アドレスへの呼を非ＰＢＸ配信装置にルーティングする場合、この構成によりＰＢＸリソース（音声ポート、処理パワー等の）使用を避けることによる効率化が可能である。
ＣＲＣシステム管理ディレクティブ

被呼者２１０９は、ディレクティブデータベース２１０６内にディレクティブを格納するＣＲＣシステム２１０２により、呼管理サービスを順序付け、アクティブにし、そして構成する呼管理ディレクティブを設定する。クライアント装置２１０４は、被呼者２１０９の入力とは無関係にＣＲＣシステム２１０２に場所情報を提供できる。呼管理ディレクティブおよび場所情報に基づいて、ＣＲＣシステム２１０２は、交換機を通るユーザへの呼に応答して送信先交換機１０４にルーティングおよび処理情報を送信する。

呼管理ディレクティブには、呼ルーティング（ユーザ場所、ユーザの存在、明示的なユーザ選択、および時刻に基づく）、呼スクリーニング、緊急時のみの呼受信、電話セールス遮断またはフィルタ処理、呼通知、ボイスメール通知、携帯電話発呼者ＩＤ、通知ルーティング、ボイスメールルーティング、およびボイスメール転送等の、上記説明のディレクティブが含まれる。

加えて、呼管理ディレクティブには、呼ルーティング（ユーザ場所での行動に基づく）、全ネットワーク通話記録、全ネットワークアドレスブック、ネットワーク相互間ボイスメール、および一元管理された発呼者ＩＤ、を含めることができる。管理アドレスに呼がかかってくると、ＣＲＣシステム２１０２は、ゼロ台、１台またはそれ以上の配信装置１０８に、配信装置１０８上で呼がユーザに利用可能という合図（ベルを鳴らすかまたは何らかの他の通知方法で）、またはユーザの管理アドレスの一つにかかってきたという合図（呼を「取り上げる」ことができなかった場合の通知）をさせる。ＣＲＣシステム２１０２は、動的に、かつリアルタイムで、ユーザの可能性のある同じセットかそれ以上の規模の配信装置セットから、ベルを鳴らす１セットの配信装置１０８を選択する。

ＣＲＣシステム２１０２は、標準ＴＮまたは他のネットワークに一意の識別子を用いて配信装置１０８Ｂをアドレス指定できる。一実施の形態では、単一管理アドレスはユーザの複数の携帯電話１０８Ｂの内の一台にルーティングできる。ユーザは、就業時間中に用いるためのフル機能の大きな携帯電話および個人的な時間に用いるための小型携帯電話を持つことができる。管理アドレスは、ユーザの唯一の携帯電話番号として公開できる。ユーザは、携行している携帯電話をアクティブな携帯電話配信装置１０８Ｂとして取り扱い、ユーザの他の携帯電話配信装置を非アクティブとして扱うようＣＲＣシステム２１０２に命令できる。その携帯電話は、携帯電話の移動（場所変更）、振動、電源ＯＮ、または他の条件に基づいてユーザが自動的に選択できる。

クライアント装置２１０４は、ＣＲＣシステム２１０２が利用できることを、積極的に（例えば、ＳＭＳメッセージ経由で）または受動的に（例えば、クライアント装置のユーザーインターフェースで利用できるサービス情報／注文リンクの存在により）ユーザに知らせることができる。ＣＲＣシステム２１０２は、クライアント装置２１０４上で、直接、注文を受け、アクティブ化し、そして設定（最初に構成）できる。次いで、マルチネットワークのサービス提供が、ユーザの通信サービスプロバイダそれぞれとの電子インターフェースを通じてＣＲＣシステム２１０２により実行される。ユーザの管理アドレスの一つにかかってきたそれぞれの呼に対して、ＣＲＣシステム２１０２は、通信接続業者から呼を取り扱う信号の問い合わせを受け付け、その呼の所望の取り扱いに影響を及ぼすよう応答する。呼は、ダイヤルされた装置への接続を許可され；別の配信装置に再ルーティングされ；ボイスメールプラットフォームに再ルーティングされ；呼をその後どう取り扱うかを決定するためにＣＲＣシステム２１０２が用いる発呼者入力を受け付ける自動案内に接続され；または他の方法によって取り扱われる。ＣＲＣシステム２１０２は、多数の配信装置のベルを鳴らすか、または何らかの他の方法で呼を知らせる。配信装置を同時に鳴らしてもよく、または順番に鳴らしてもよい。配信装置の内の一台以上は、異なるベル音で、つまり「区別できるベル音」で鳴らすことができ、別の配信装置と同時に鳴っている時に、一台だけの配信装置をメロディが鳴るように設定する。区別可能ベル音は、鳴っている全ての配信装置が、同一の呼のせいで鳴っていることをユーザに知らせる。例えば：

列３の管理アドレスは、「自宅」、「オフィス」、「通勤中」等として表すことができる。

発呼者名は、ユーザの電話帳または発呼名データベースサービス（ＣＮＡＭ）から得られる。

多数ユーザで配信装置１０８Ｂを共有している場合、ＣＲＣシステム２１０２は、呼を特定ユーザ、または何人かのユーザのサブセットに宛てて送信する場合、配信装置を違う音で鳴らすことができる。

ＣＲＣシステム２１０２は、ＣＲＣシステム２１０２が取り扱う呼をユーザに知らせる通知メッセージを、ユーザの配信装置の内の一台であっても、そうでなくてもよい装置に送信することができる。それが配信装置１０８である場合、それは呼を取り扱っても、取り扱わなくてもよい。例えば、ユーザの自宅電話にルーティングされた呼をユーザに知らせる携帯電話クライアント装置に、ＳＭＳメッセージを送信することができる。

ＣＲＣサービスの持続的構成は、ＣＲＣシステム２１０２への無線インターフェースとしてクライアント装置を用いて実行できる。クライアント装置２１０４のＣＲＣサービスのユーザーインターフェースは、テキスト、アイコン、音声認識、対話式自動音声応答（ＩＶＲ）、または他のディスプレイおよび入力技法により推進できる。このような構成変更は、ＣＲＣシステム２１０２内に常駐させることができ、ユーザの通信接続業者を通じて更に提供する必要はない。ユーザの通信接続業者はそれぞれ、ユーザの電話番号（管理アドレス）の内の一つが呼を受信するときは常に、ＣＲＣシステム２１０２に問い合わせる。ＣＲＣシステム２１０２からの応答により、呼を進める方法が通信接続業者に知らされる。代表的なオプションは、「接続」または「供給された番号に転送」である。（供給された番号は、配信装置、ボイスメールプラットフォーム、または呼終端システムのことがある）。

ＣＲＣ呼取り扱いと対応付けられるルールは、グループに分割される。ルールの各グループは、ユーザ行動モードと対応付けられる。名前を付けた行動モードのリストは、ユーザが創成でき、および／またはサービス開始時にユーザに与えられる。幾つかの例示の行動モードは、「自宅で呼を受ける」、「自宅で呼を受けない」、「通勤中」等である。任意の時点で、正確に一つの行動モードがアクティブであり、すなわち、それが現在の行動モードである。行動モードと対応付けられるルールのグループは、その行動が現在の行動モードである場合にアクティブとなるだけである。行動モードは、クライアント装置２１０４、ウェブサイト（例えば、ウェブ構成１５０６を介して。図１８参照）、またはＣＲＣシステム２１０２への他のユーザーインターフェースを用いて創成できる。

ユーザは、インスタントメッセージ内の「友人リスト」に似通った人々の集団に見せるために現在の行動モードを公開するよう選択できる。電話の会話に関与するユーザの状態も、他の関係者の名前および／または電話番号と併せて、公開できる。ＣＲＣシステム２１０２が利用できるユーザ関連情報はどれも、人々の集団に見せるために公開できる。この情報は、見ようと見まいと、他のＣＲＣユーザが用いることもできる。この情報には、現在の行動モードを決定するのに用いる全要素が含まれる。人々の集団には、ユーザに呼を発信する人々（他のＣＲＣシステムユーザまたは非ユーザ）が含まれる。現在の行動モードは、クライアント装置上でユーザが選択でき、または現在の行動モードは、以下を含む多数の入力から計算できる：ユーザ場所、クライアント装置場所、クライアント装置上のユーザ選択（ボタン押下、音声コマンド、または他の入力を用いて）、非クライアント装置ＵＩを通じたユーザ選択、クライアント装置状態（使用中、ＯＮ、ＯＦＦ、呼び出し・音量大／呼び出し・振動、電話設定［「会議中」、「オフィス内」］等）、何れかの管理アドレス上の発信呼または受信呼、インスタントメッセージ（ＩＭ）存在状態、非ＩＭ存在状態、「押して話す（Push To Talk）」存在状態、曜日、時刻、スケジュールアプリケーション内に格納されたスケジュール（クライアント装置上、パーソナルコンピュータ、またはスケジュールサーバ）、等である。行動モードは、行動モード計算に対する上記何れかの入力と併せて、他のサービスが使用するようグローバルに存在する電話帳に公開できる。

自動的に制定する行動モードは、何らかの明示的なユーザ入力が無くても選択される行動モードである。自動的に制定する行動モードを用いると、ユーザの相互作用を必要とせずに非常に簡単なユーザ体験が可能になる。ＣＲＣシステム２１０２は、現在の行動モードと矛盾する振る舞いを検出し、ユーザにその矛盾を報告することができるので、適切な変更が可能になる。例えば、現在の行動モードが「自宅」なのに、ユーザの携帯電話から呼が発信される場合、クライアント装置２１０４を介して、行動モードを「動き廻っている」に変更するようユーザを促すことができる。別の実施例として、現在の行動モードに従って配信装置に呼が配信されている場合で、幾つかの数の呼が無応答の場合、ユーザに通知して（ＳＭＳまたは他のメカニズムを経由して）、配信装置が所望の行動モードに設定されているかどうかの確認を要求できる。
ユーザ場所

ＣＲＣシステム２１０２には、管理アドレスの一つに成された呼を取り扱う方法を決定するための、ユーザ場所に対するプロキシとしてクライアント装置２１０４の場所を含めることができる。クライアント装置２１０４または通信接続業者のネットワークは、クライアント装置の場所を特定でき、ＣＲＣシステム２１０２にその場所を提供できる。クライアント装置２１０４は、グローバル測位システム（ＧＰＳ）、電波塔三角測量、ＷｉＦｉ（または他の）無線ＬＡＮ近接法、または他の技法を用いて、その場所を特定できる。通信接続業者ネットワークは、電波塔三角測量または他の技法を用いてクライアント装置の場所を特定できる。

ＣＲＣシステム２１０２は、ユーザの職場での入場カード提示、特定場所でのクレジットカード使用、特定場所からの発信（有線または無線）、ＷｉＦｉまたは他の無線ネットワークによる登録、電子キーシステムを用いてのある場所への入館（自宅、オフィス等）、警報システムへの個人識別番号入力、ユーザの自動車の解錠または起動、低軌道衛星型ヘッドトップ識別、または他の情報源等の、他の情報源からユーザ場所を特定できる。例えば、ユーザの携帯電話がＣＤＭＡネットワーク利用から、ユーザ宅のＷｉＦｉ利用に移行する場合、ＣＲＣシステム２１０２は、ユーザの現在行動モードを「自宅で」に設定できる。

ＣＲＣシステム２１０２は、ユーザの既知の自宅およびオフィスのアドレスと一致する道路地図データベースとユーザの場所情報を連係させて、ユーザが自宅にいるかまたはオフィスにいる場合を特定し、現在の行動モードと対応する「自宅で」の行動モード、または「仕事で」の行動モードを選択することができる。ＣＲＣシステム２１０２は、ユーザが、自宅とオフィスの住所間の可能性のある経路に沿って進んでいる（単調な場所の移動）かどうかを判定でき、これを仕事のスケジュールまたはカレンダと組合せてユーザが通勤している場合を判定し、次いで、「通勤中」の行動モードをアクティブにできる。ユーザは、ＣＲＣシステム２１０２に現在場所を興味がある場所（ＰＯＬ）として記録させることができる。ＰＯＬは、ユーザの自宅、オフィス、または興味のあるどこか他の場所でもよい。ＰＯＬの記録は、クライアント装置２１０４から、ウェブから、または別の入力装置から開始できる。ＰＯＬはユーザが名称を付けることができる。ＣＲＣシステム２１０２は、ユーザの現在場所をユーザの全てのＰＯＬと比較し、現在の行動モードを決定するためにその結果を用いる。ＣＲＣシステム２１０２は、ユーザの速さまたは速度またはユーザのスケジュールプログラム／サービス場所情報を用いて現在の行動モードを判定する。

ＣＲＣシステム２１０２は、ユーザの現在場所の階層的分類に基づいてユーザの行動モードを計算できる。例えば、ＣＲＣシステム２１０２は、ユーザの場所の分類法をマッピングデータベースで見付ける（例えば、レクリエーション→スポーツ→ゴルフ→ゴルフコース）。この分類法の特定の分岐を、ユーザの行動モードと対応付けることができる。ＣＲＣシステム２１０２は、ユーザが特定場所（例えば、ゴルフコース）に到着した（または、あるスレッショールド時間量を費やした）場合、新規行動モードを創成するよう推奨できる。ＣＲＣシステム２１０２は、クライアント装置２１０４を通じて応答するようユーザに促すことにより行動モード（新規または既存の）を推奨できる。ユーザは、その行動モードを制定しまたは呼管理ディレクティブを調整できる。場所情報の不正確さにより、または他の要因により、場所の分類に曖昧さが残ることもある（例えば、レストランの次に映画館）。ＣＲＣシステム２１０２は、この曖昧さを解決するのを選択するようユーザに促すことができる。
呼の通話記録

ＣＲＣシステム２１０２は、全ての管理アドレスに対するマルチネットワークの入ってくる呼および出ていく呼の通話記録２１２０を格納する。呼の通話記録２１２０は、全ての管理アドレスに対する入ってくる呼および出ていく呼の通話記録を中央場所に、およびユーザのために配信装置１０８に格納する。呼の通話記録２１２０はクライアント装置２１０４上に表示できる。この呼の通話記録内の電話番号および名前は、クライアント装置２１０４上のアドレスブック内に統合できる。それらはＣＲＣシステム２１０２を制御するリストに転送することもできる。例えば、特定の呼からの電話番号は、「ＶＩＰリスト」上に置くことができるので、その電話番号からの後続の呼は、常にユーザにルーティングされる（ユーザがそれら自体を「利用不可」として指定した場合、ボイスメールにルーティングされる代わりに）。この情報は、ユーザの電話番号（管理アドレス）をサービスする電話交換機１０４からのネットワーク型トリガー（情報を知らせる）および／または入ってくる呼および出てゆく呼についての情報を検出し、記録し、そして更新する配信装置常駐アプリケーションを用いることにより収集する。呼の通話記録は、ある集団の人々に見えるように公開できる。
ＣＲＣシステムの他の管理ディレクティブ

他のクライアント装置２１０４または通信接続業者のネットワークパラメータは、ＣＲＣシステム２１０２により設定でき、そのパラメータには、ベルの音量、ベルの種類、ベルの音の選択、戻りの音（電話が鳴ってる時の発呼者に聞こえる音）、ボイスメール挨拶、送信される発呼者ＩＤ（番号および／または名前）等が含まれる。ＣＲＣシステム２１０２は、サーバおよび／またはクライアント装置上で実行するプログラムロジックを用いて、これらのパラメータを制御することができる。すなわち、ＣＲＣシステム２１０２は、現在の行動モード、ユーザ場所、または他のシステム入力を用いて、パラメータ値を決定することができる。例えば、ユーザが映画館にいる場合、クライアント装置のベルの種類を、振動に設定することができる。
結論

上記記載では、説明を目的として、数多くの特定の詳細について、本発明の完全な理解を提供するために記述している。しかし、当該分野の技術者には言うまでもなく、本発明はこれらの特定の詳細がなくても実践することができる。他の例では、本発明を曖昧にしないよう、構造および装置をブロック図形式で示している。

本明細書で「一実施の形態」または「実施の形態」を引用する意味は、本発明の少なくとも一実施の形態に、実施の形態との関連で説明した特定の機能、構造、または特性を含むということである。本明細書の至る所に出現する「一実施の形態では」の語句は、同一の実施の形態を参照しているとは限らない。

詳細な説明の部分の幾つかの部分は、アルゴリズムおよびコンピューターメモリ内のデータビット上の操作のシンボル表現の観点から提示している。これらのアルゴリズムの説明および表現は、データ処理技術の技術者が用いて、当該分野の技術者に最も効率的に彼らの業務の本質を伝達する手段である。アルゴリズムは、ここでは、そして一般的には、所望の結果を導き出す一貫したステップシーケンスと考えられる。そのステップは、物理量の物理的操作を必要とするものである。通常、必ずしもそうとは限らないが、これらの量は、格納、転送、組合せ、比較、および他の操作が可能な電気的または磁気的な信号の形式をとる。これらの信号をビット、値、要素、シンボル、文字、用語、数字等と称することが、主として共通使用するという点から、時には有用であると証明されている。

しかしながら、念頭に浮かぶことは、これらのおよび類似の用語全てが適切な物理量と対応付けられるとともに、これらの量に適用される単なる有用なラベルであるべきであるということである。以下の議論から明らかなように、他に特別に表明しない限り、言うまでもなく、記述全体にわたって、「処理する」、「演算する」、「計算する」、「決定する」、「標準する」等の、用語を利用する説明は、コンピューターシステムのレジスタおよびメモリ内の物理（電子）量として表されるデータを、そのコンピューターシステムのメモリもしくはレジスタまたは他のそのような情報格納装置、伝送装置またはディスプレイ装置内の物理量として同様に表される他のデータに、操作し、変換するコンピューターシステム、または類似の電子計算装置の作用および処理を参照する。

本発明は、また、本明細書の操作を実行するための装置にも関連する。本装置は、要求される目的のために特別に構築しても、またはコンピュータ内に格納したコンピュータープログラムにより選択的にアクティブ化または再構成した汎用コンピュータを備えてもよい。このようなコンピュータープログラムは、限定はしないが、フロッピーディスク、光ディスク、ＣＤ−ＲＯＭ、および光磁気ディスクを含む任意の形式のディスク；読み出し専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気もしくは光カード、または電子命令を格納するために適切な任意の型式の媒体であって、それぞれがコンピューターシステムバスに結合された媒体；等のコンピュータ可読格納媒体内に格納できる。

本明細書で提示されたアルゴリズムおよびモジュールは、本質的には、何らかの特定のコンピュータまたは他の装置と関連していない。本明細書の教示に従うプログラムにより各種の汎用システムを用いることができ、またはより専用化した装置を構築して要求される方法ステップを実行するのが有用であることが実証できる。多様なこれらのシステムに要求される構造は、以下の説明から明らかとなろう。更に、本発明は、特定のプログラム言語を参照して説明しない。言うまでもなく、各種のプログラム言語を用いて、本明細書で説明した本発明の教示を実装できる。更に、関連分野の技術者には言うまでもなく、本発明のモジュール、機能、属性、方法論、および他の態様は、ソフトウエア、ハードウエア、ファームウエアまたはこれら３つの任意の組合せとして実装できる。無論、本発明の構成要素をソフトウエアとして実装するときは常に、より規模の大きなプログラムの一部として、複数の別々のプログラムとして、静的または動的にリンクしたライブラリとして、モジュールをロードできるカーネルとして、デバイスドライバとして、および／または、コンピュータープログラミングの分野の技術者にとって現在または将来にわたって既知のあらゆる他の方法および任意の他の方法で、その構成要素をスタンドアロンのプログラムとして実装できる。更に、本発明は、何らかの特定オペレーティングシステムまたは環境での実装に限定する積もりはない。

本発明を実施するための一実施の形態によるアーキテクチャを示すブロック図である。 一実施の形態による電話設定スクリーンを示すスクリーンショットである。 一実施の形態による呼管理設定スクリーンを示すスクリーンショットである。 一実施の形態による呼管理設定スクリーンを示すスクリーンショットである。 一実施の形態による呼管理設定スクリーンを示すスクリーンショットである。 一実施の形態によるＶＩＰリスト管理スクリーンを示すスクリーンショットである。 一実施の形態による呼管理要約スクリーンの実施例を示すスクリーンショットである。 携帯電話を経由して行動モードの中から選択するためのユーザーインターフェースの実施例を示すスクリーンショットである。 一実施の形態による、幾つかの呼を音声メールに変換する場合の呼管理設定スクリーンを示すスクリーンショットである。 異なる電話番号への呼を別々に取り扱う呼管理設定スクリーンを示すスクリーンショットである。 被呼者についての現在の行動モードが発呼者の装置上に表示される場合の実施例を示すスクリーンショットである。 一実施の形態による、ＮＡＮＰ電話番号以外の手段による被呼者識別を実装するためのアーキテクチャを示すブロック図である。 一実施の形態による本発明を実施するための詳細なアーキテクチャの実施例を示すブロック図である。 本発明の技法による呼管理機能を実装するための一アーキテクチャを示すブロック図である。 ＷＩＮまたはＣＡＭＥＬを用いて無線通信事業者と統合することにより本発明を実施するためのアーキテクチャを示すブロック図である。 ＤＮＰを用いて本発明を実施するためのアーキテクチャを示すブロック図である。 オペレーショナルコード（ＯＰコード）セットを含む被呼者用ルールの実施例セットを含む表である。 本発明の一実施の形態による障害復旧機能のあるＤＮＰアーキテクチャを実装するためのアーキテクチャ示すブロック図である。 一実施の形態による呼ルーティングマトリックスの実施例である。 本発明の実装を用いるインネットワークおよびアウトオブネットワークの呼ルーティングのためのアーキテクチャを示すブロック図である。 一実施の形態による通信遠隔制御システムのためのアーキテクチャを示すブロック図である。

Claims (36)

1. ユーザにかかってきた通信を取り扱うためにコンピュータによって実行される方法であって、
   少なくとも一つのユーザ行動モードにつき、
   複数の通信ネットワークのそれぞれについて、前記ユーザ行動モードに対応付けられるべき少なくとも一つの通信管理ディレクティブを決定するステップと、
   前記通信管理ディレクティブと前記ユーザ行動モードとの間の対応関係を、前記複数の通信ネットワークとは別体のデータベースに格納するステップと
   を実行することと、
   前記ユーザおよび前記複数の通信ネットワークに対応付けられたユーザーアドレスにて開始された通信に応答して、
   前記ユーザの現在の行動モードを決定するステップと、
   前記現在のユーザ行動モードに対する前記格納した対応関係を検索するステップと、
   前記検索した対応関係に応じて、どの通信管理ディレクティブを前記開始された通信に適用するかを決定するステップと、
   前記適用可能な通信管理ディレクティブを前記複数の通信ネットワークの内の一つに提供するステップと
   を実行すること
   からなる方法。
2. 前記通信ネットワークの内の少なくとも一つが、ＰＢＸ、中央オフィス、および無線サービスセンタを含む請求項１の方法。
3. 前記ユーザーアドレスが電話番号を含む請求項１の方法。
4. 少なくとも二つの電話番号が所与のユーザに対応するとともに、どの通信管理ディレクティブを前記開始された通信に適用するかを決定するステップが、前記通信が開始された際にどの電話番号がダイヤルされたかを決定するステップを含む請求項３の方法。
5. 前記通信が電話呼び出しを含むとともに、前記通信管理ディレクティブが、前記ユーザーアドレスと対応する前記通信ネットワークによる前記電話呼び出しを処理するための呼管理ディレクティブを含む請求項１の方法。
6. 前記ユーザーアドレスと対応付けられる通信ネットワークで前記呼び出しをルーティングするステップを更に含む請求項５の方法。
7. 前記呼び出しの発信元が発呼者を含むとともに、前記方法が、
   前記ユーザと対応付けられる前記ユーザーアドレスに対して開始された前記呼び出しに応答して、
   発呼者識別が利用できるかどうかを決定するステップ
   を実行することと、
   発呼者識別が利用できないのに応じて、
   情報を識別するために前記発呼者を促すステップと、
   識別情報を提供する前記発呼者から入力を受信するステップと
   を実行することと、
   を更に具備し、
   どの通信管理ディレクティブを適用するかを決定するステップが、前記識別情報および前記検索した対応関係に応じて通信管理ディレクティブを決定するステップで構成される、請求項５の方法。
8. 少なくとも二つのユーザーアドレスが前記ユーザと対応付けられ、第１ユーザーアドレスは第１電話ネットワークと対応付けられ、第２ユーザーアドレスは前記第１電話ネットワークと異なる第２電話ネットワークと対応付けられる請求項５の方法。
9. 前記電話ネットワークのそれぞれが、
   無線電話ネットワーク、
   ＰＢＸネットワーク、
   ＬＥＣネットワーク、および、
   ソフトスイッチネットワーク、
   かのいずれかである請求項８の方法。
10. 前記ユーザの現在場所と対応付けられる送信先装置に前記呼び出しを送信するステップを更に具備し、前記場所は、前記ユーザーアドレスと対応付けられる送信先装置とは異なる請求項５の方法。
11. 前記適用可能な呼管理ディレクティブに応答して、前記ユーザに対応付けられる複数の送信先装置のそれぞれに対して、複数の可聴ベル音の内の対応する一つを選択するステップであって、選択したそれぞれのベル音は、他の選択ベル音とは異なステップと、
    前記電話呼び出しに応答して、対応する送信先装置で前記選択したベル音を生成するステップと、
    を更に具備する請求項５の方法。
12. 通信管理ディレクティブを決定するステップが、ユーザ行動モードに対する通信管理ディレクティブを規定するユーザ入力を受信するステップを具備する請求項１の方法。
13. 通信管理ディレクティブを規定するユーザ入力を受信するステップが、ウェブ型ユーザーインターフェースを介して前記ディレクティブを受信するステップを含む請求項１２の方法。
14. 通信管理ディレクティブを規定するユーザ入力を受信するステップが、携帯電話を経由して前記ディレクティブを受信するステップを含む請求項１２の方法。
15. 現在のユーザ行動モードを規定するユーザ入力を受信するステップを更に具備する請求項１の方法。
16. 行動モードに対して期間を規定するユーザ入力を受信するステップを更に具備し、現在の行動モードを決定するステップが、前記現在時間が前記規定した期間内かどうかを決定するステップを具備する請求項１の方法。
17. 複数の期間のそれぞれに対する行動モードを規定するユーザ入力を受信するステップを更に具備し、現在の行動モードを決定するステップが、規定した行動モードの内のどれが前記現在時間と対応するかを決定するステップを具備する請求項１の方法。
18. 行動モードに対して少なくとも一つの条件を規定するユーザ入力を受信するステップを更に具備し、現在の行動モードを決定するステップが、前記少なくとも一つの条件が満たされるかどうかを決定するステップを具備する請求項１の方法。
19. 前記少なくとも一つの条件が、場所、速度、周囲環境条件、検出したユーザ行動モード、および手動選択のいずれかである請求項１７の方法。
20. 少なくとも二つのユーザーアドレスが所与のユーザと対応するとともに、どの通信管理ディレクティブを前記開始された通信に適用するかを決定するステップが、前記通信が開始された際にどのユーザーアドレスが用いられたかを決定するステップを具備する請求項１の方法。
21. 少なくとも一つの通信管理ディレクティブを決定するステップが、通信装置に関するユーザの使用パターンを検出するステップを具備する請求項１の方法。
22. 前記適用可能な通信管理ディレクティブが規定する送信先装置に、前記通信をルーティングするステップを更に具備する請求項１の方法。
23. 前記通信をルーティングするステップが、前記適用可能な通信管理ディレクティブが規定する電話番号に接続するステップを具備する請求項２２の方法。
24. 前記通信をルーティングするステップが、ボイスメールメッセージシステムに接続するステップを具備する請求項２２の方法。
25. どの通信管理ディレクティブを前記開始された通信に適用するかを決定するステップが、ユーザ行動モードと通信管理ディレクティブとの間のリアルタイムマッピングを決定するステップを具備する請求項１の方法。
26. ユーザにかかってきた通信を取り扱うためにコンピュータによって実行される方法であって、
    複数の第２通信ネットワークに対する複数の通信管理ディレクティブから選択するための１セットのルールを、第１通信ネットワークを経由して前記ユーザから受信するステップと、
    前記ルールセットを格納するステップと、
    前記ユーザと対応付けられるユーザーアドレスに、前記第２通信ネットワークを経由して発信元が開始している通信に応答して、前記通信に対する通信管理ディレクティブを選択するための前記ルールの内の少なくとも一つを、前記第２通信ネットワークに提供するステップと、
    前記選択した通信管理ディレクティブに従って、第３通信ネットワークに前記通信をルーティングするステップと、
    を具備する方法。
27. 前記通信をルーティングする前記ステップが、前記通信に関連する情報を前記第１通信ネットワークにルーティングするステップを具備する請求項２６の方法。
28. 前記通信をルーティングする前記ステップが、前記選択した通信管理ディレクティブに従って、前記第１または前記第３通信ネットワークのいずれかに、前記通信をルーティングするステップを具備する請求項２７の方法。
29. 前記各ルールが、
    ユーザ行動モード、
    発信元識別子、
    ユーザ場所、
    前記通信が開始されたときに用いられた前記ユーザーアドレス、
    前記発信元から受信した入力、及び
    前記ユーザから受信した入力、
    からなるグループから選択された１セットのパラメータを具備する請求項２６の方法。
30. ユーザにかかってきた通信を取り扱うためのシステムであって、
    少なくとも一つのユーザ行動モードについて、複数の通信ネットワークのそれぞれに対する前記ユーザ行動モードと対応付けられる少なくとも一つの通信管理ディレクティブを受信するための入力装置と、
    前記通信管理ディレクティブと前記ユーザ行動モードとの間の対応関係を格納するための前記通信ネットワークとは別体のユーザープロファイルデータベースと、
    前記ユーザープロファイルデータベースと通信可能に結合され、前記ユーザおよび前記複数の通信ネットワークの内の一つと対応付けられるユーザーアドレスに開始される通信に応答して、
    前記ユーザに対する現在の行動モードを決定し、
    前記ユーザープロファイルデータベースから、前記現在のユーザ行動モードについての前記格納された対応関係を検索し、
    前記検索した対応関係に応じて、どの通信管理ディレクティブを前記開始された通信に適用するかを決定し、
    適用可能な前記通信管理ディレクティブを、前記複数の通信ネットワークの内の一つに提供する、
    ことを行う通信管理モジュールと、
    前記適用可能な通信管理ディレクティブに従って、前記通信をルーティングするための前記通信管理モジュールに結合されて通信し、かつそれとは別体の通信ルーティング装置と、
    を備えるシステム。
31. 前記通信ルーティング装置が交換機を備える請求項３０のシステム。
32. 前記ユーザーアドレスが電話番号を含む請求項３０のシステム。
33. 前記通信が、電話呼び出しを含むとともに、前記通信管理ディレクティブが、呼管理ディレクティブを含む請求項３０のシステム。
34. 前記通信ルーティング装置が、前記ユーザーアドレスと対応付けられる送信先交換機を備える請求項３０のシステム。
35. ユーザにかかってきた通信を取り扱うためのシステムであって、
    それぞれの通信ネットワークが、前記ユーザおよび前記通信ネットワークと対応付けられるユーザーアドレスに開始された通信に応答して通信開始情報を生成するとともに、前記ユーザーアドレスと対応付けられた通信管理ディレクティブに応じて前記通信をルーティングする、複数の通信ネットワークと、
    前記各通信ネットワークに結合され、かつそれとは別体の遠隔呼び出し管理システムと
    を具備し、
    前記遠隔呼び出し管理システムは、
    少なくとも一つのユーザ行動モードについて、複数の通信ネットワークのそれぞれに対する前記ユーザ行動モードと対応付けられる少なくとも一つの通信管理ディレクティブを受信するための入力装置と、
    前記通信管理ディレクティブと前記ユーザ行動モードとの間の対応関係を格納するためのユーザープロファイルデータベースと、
    前記ユーザープロファイルデータベースと通信可能に結合され、前記通信開始情報に応答して、
    前記ユーザに対する現在の行動モードを決定し、
    前記ユーザープロファイルデータベースから、前記現在のユーザ行動モードについての前記格納した対応関係を検索し、
    前記検索した対応関係に応じて、どの通信管理ディレクティブを前記開始された通信に適用するかを決定し、
    前記適用可能通信管理ディレクティブを、前記複数の通信ネットワークの内の一つに提供して、前記適用可能通信管理ディレクティブに従って、前記通信をルーティングする、
    ことを行う通信管理モジュールと、
    を具備することを特徴とするシステム。
36. ユーザにかかってきた通信の取り扱いを遠隔で構築するための装置であって、
    少なくとも一つのユーザ行動モードについて、複数の通信ネットワークのそれぞれに対する前記ユーザ行動モードと対応付けられる少なくとも一つの通信管理ディレクティブを受信するための入力システムと、
    通信遠隔呼び出しシステムに、前記少なくとも一つの通信管理ディレクティブを送信するための送信システムと、
    前記ユーザについての現在の行動モードと対応付けられる少なくとも一つの通信管理ディレクティブに応じて、前記ユーザおよび前記複数の通信ネットワークの内の一つと対応付けられたユーザーアドレスにて開始された通信を受信するための受信システムと
    を備える装置。

Images