(57)【要約】【課題】  カスタム化警報サービスに関与するユーザが行う呼を通知するために用いる警報の特色および／または形態を選択するコンピュータ化システムおよび方法を提供する。【解決手段】  本方法は、関与ユーザに対してカスタム化警報サービス構成を確立し、次いでこの構成を１つ以上のネットワークにアクセス可能なデバイス上に格納する。関与ユーザは、第１通信端末を用いて、第２通信端末に、第１通信サービスを通じて発呼する。すると、第２通信端末は、関与ユーザに対するカスタム化警報サービス構成に応じて選択した選択警報記述子を用いて警報を活性化することによって、呼を通知する。【選択図】      図１
2008295094.tif 000002
【特許請求の範囲】
【請求項１】
カスタム化警報サービスに関与するユーザが行う呼を通知するために用いる警報の特色および／または形態を選択する方法であって、
ａ．関与ユーザに対するカスタム化警報サービス構成を確立し、該カスタム化警報サービス構成を１つ以上のネットワーク・アクセス可能デバイスに格納するステップと、
ｂ．前記関与ユーザが、第１通信端末を用いて第２通信端末に発呼し、該呼に第１通信サービスが対応するステップと、
ｃ．前記第２通信端末が、選択した警報記述子を用いて警報を活性化することによって、前記呼を通知するステップと、
を含み、前記関与ユーザに対する前記カスタム化警報サービス構成に応じて、前記警報記述子を選択する、方法。
【請求項２】
請求項１記載の方法において、関与ユーザに対してカスタム化警報サービス構成を確立するステップは、前記関与ユーザのカスタム化警報サービスとの関連付けのため、少なくとも１つの警報記述子を選択および／または提供し、前記関与ユーザがネットワーク接続デバイスを用いて前記選択を行うステップを含む、方法。
【請求項３】
請求項１記載の方法において、関与ユーザに対してカスタム化警報サービス構成を確立するステップは、前記関与ユーザのカスタム化警報サービスとの関連付けのため、少なくとも１つの警報記述子を選択および／または提供し、前記関与ユーザの代理で前記選択を行うステップを含む、方法。
【請求項４】
請求項２または請求項３記載の方法において、少なくとも１つの警報記述子を選択および／または提供するステップは、１組の利用可能な警報記述子から警報記述子を選択するステップを含む、方法。
【請求項５】
請求項４記載の方法において、前記１組の選択可能な警報記述子を、ネットワークアクセス可能デバイス上に収容する、方法。
【請求項６】
請求項１記載の方法において、２つ以上の端末間における音声呼の最中に、警報記述子情報を一方の通信端末から他方の通信端末に送信する、方法。
【請求項７】
請求項６記載の方法において、警報記述子情報の送信は、
ａ．音声会話の休止中、または
ｂ．音声会話が終了した後、または
ｃ．音声会話と交互に、
行う、方法。
【請求項８】
請求項１記載の方法において、カスタム化警報サービスを確立するステップは、前記関与ユーザまたは第１通信端末または第１通信サービスを特定する情報を提供するステップを含む、方法。
【請求項９】
請求項８記載の方法において、前記選択した警報記述子は、前記識別情報の処理に応じて選択する、方法。
【請求項１０】
請求項９記載の方法において、前記処理を前記第１通信端末が実行する、方法。
【請求項１１】
請求項９記載の方法において、前記処理を前記第２通信端末が実行する、方法。
【請求項１２】
請求項９記載の方法において、前記処理をサーバ・デバイスが実行する、方法。
【請求項１３】
請求項８記載の方法において、関与ユーザに対してカスタム化警報サービス構成を確立するステップは、前記関与ユーザに対する補助情報を選択および／または提供するステップを含む、方法。
【請求項１４】
請求項１３記載の方法において、前記選択した警報記述子は、前記補助情報および前記識別情報の処理に応じて選択する、方法。
【請求項１５】
請求項１４記載の方法において、前記補助情報の処理は、当該補助情報に関連する変数を処理することを含み、前記関連する変数を、
ａ．時間変数、
ｂ．季節および風習変数、
ｃ．地理的変数、
ｄ．近接度変数、および
ｅ．個人変数
から選択する、方法。
【請求項１６】
請求項１記載の方法において、前記選択した警報記述子は、前記関与する通信端末上に実装されているメモリから検索したものである、方法。
【請求項１７】
請求項１記載の方法において、前記選択した警報記述子を、前記第１通信端末から前記第２通信端末に伝達する、方法。
【請求項１８】
請求項１記載の方法において、前記選択した警報記述子を、ネットワーク・アクセス可能デバイスから前記第２通信端末に伝達する、方法。
【請求項１９】
請求項１７記載の方法において、前記選択した警報記述子を、前記第１通信サービスを用いて伝達する、方法。
【請求項２０】
請求項１７または請求項１８記載の方法において、前記選択した警報記述子を、前記第１通信サービス以外の通信経路を用いて伝達する、方法。
【請求項２１】
請求項１９または請求項２０記載の方法において、前記選択した警報記述子を、呼設定プロセスの前に、前記通信端末に伝達しておく、方法。
【請求項２２】
請求項１９または請求項２０記載の方法において、呼設定プロセス中に、前記選択した警報記述子を前記第２通信端末に伝達する、方法。
【請求項２３】
請求項１９または請求項２０記載の方法において、前記選択した警報記述子を、呼設定プロセスとは非同期に、前記第２通信端末に伝達する、方法。
【請求項２４】
請求項２０記載の方法において、前記代替通信経路はインターネットを利用する、方法。
【請求項２５】
請求項１記載の方法において、前記カスタム化警報サービスは、複数の通信端末およびサーバのネットワーク内部で動作し、前記通信端末およびサーバの少なくとも一部は、キャッシング方式に関与し、前記ネットワーク内部にある複数の異なるサーバまたは通信端末から警報記述子を発信させる、方法。
【請求項２６】
請求項１記載の方法において、呼を受信したユーザは、彼らが受信したい種々のカスタム化警報に対する制御を実行することができる、方法。
【請求項２７】
請求項２６記載の方法において、異なる警報を、その特色および／または内容に応じて分類し、呼を受信するユーザは、特定の分類の警報のみを受信するように選択可能とした、方法。
【請求項２８】
請求項２６記載の方法において、呼を受信したユーザは、２つの異なる警報によって呼を通知することを選択することができ、一方の警報を、前記受信したユーザが選択し、他方を発呼側ユーザが選択する、方法。
【請求項２９】
コンピュータ化システムにおいて、当該システムに関与するユーザが、前記システムに関与する通信端末に対して行う呼を通知するために用いる警報の特色および／または形態を、前記関与ユーザの好みに応じて決定することを可能とし、前記システムは、
ａ．少なくとも一部が警報記述子を受信し、それに対して動作可能な、複数の通信端末と、
ｂ．関与ユーザに対してカスタム化警報サービスを作成するデータ入力デバイスと、
ｃ．前記関与ユーザのカスタム化警報サービスを構成する構成ソフトウエアであって、前記関与ユーザのカスタム化警報サービスの構成が、前記関与ユーザのカスタム化警報サービスと共に用いるために、少なくとも１つの警報記述子を選択および／または提供することを含む、構成ソフトウエアと、
ｄ．前記関与ユーザのカスタム化警報サービス構成を格納するデータベースと、
ｅ．前記関与ユーザが受信側通信端末に対して行う呼と共に用いる警報記述子を選択する処理手段と、
ｆ．警報記述子を前記受信側通信端末に伝達する伝達経路と、
を含み、
前記選択した警報記述子は、前記関与ユーザのカスタム化警報サービスの構成に応じて選択する、コンピュータ化システム。
【請求項３０】
請求項２９記載のシステムにおいて、前記関与ユーザのカスタム化警報サービスの構成は、更に、補助情報を提供することを含む、システム。
【請求項３１】
請求項２９記載のシステムにおいて、前記関与ユーザのカスタム化警報サービスの構成は、更に、識別情報を提供することを含む、システム。
【請求項３２】
請求項２９記載のシステムにおいて、前記処理手段は、前記関与ユーザに随伴する通信端末である、システム。
【請求項３３】
請求項２９記載のシステムにおいて、前記処理手段は、受信通信端末である、システム。
【請求項３４】
請求項２９記載のシステムにおいて、前記処理手段は、サーバ・デバイスである、システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信端末（「発呼側端末」）または通信サービス（「発呼側サービス」）のユーザが、第２通信端末（「被呼側端末」）に呼を通知するために用いる警報の形態および／または特色を選択できるようにする方法およびシステムに関する。特に、本発明は、着信呼を通知するために被呼側端末が用いる警報を、コンピュータ化したシステムによる情報解釈の結果として決定し、また場合によっては制御し、発呼側端末ユーザまたは通信サービス加入者または彼らの代理で行動する人がこの情報を提供するようにした方法およびシステムに関するが、これに限られる訳ではない。
【背景技術】
【０００２】
現行の電話ハンドセット、特に、移動電話ハンドセットの多くでは、ユーザは、着信呼をユーザに知らせるために用いられるトーン・シーケンスを選択することができる。一例として、移動電話ハンドセットのユーザは、移動電話ハンドセットの不揮発性メモリ内に格納されている、ある範囲の警報トーン・シーケンスから、好みの警報トーン・シーケンスを選択することができる場合もある。
【０００３】
更に、電話ハンドセットの一部には、追加の機能性を提供することができるものもあり、例えば、ユーザは特定の警報トーン・シーケンスを、特定の個人または個人の集団からの着信呼に割り当てることができる。通例では、電話ハンドセットは、発呼回線番号識別（ＣＬＩ：Calling Line Number Identification）のようなネットワークに設けられている機能を用いて、発呼側の番号を突き止め、次いでこの番号を予め選択してある警報トーン・シーケンスと関連付けることがも可能である。警報トーン・シーケンスを特定のＣＬＩと関連付けると、特定の人または特定の分類に属す人が通話してくる場合に、被呼側端末のユーザに早めの可聴警告を行うことができる。
【０００４】
現在のカスタム化可能な呼警報システムは、有用な機能を提供するには相違ないが、これには多くの制約がある。
第１に、既存のカスタム化可能な呼警報システムが提供する方式では、被呼側だけが、発呼側にどのように通知するか決定できるように思われる。つまり、発呼側は、被呼側にどのように通知されるか選択することはできない。この点について、本明細書において「被呼側」および「発呼側」に言及する場合、被呼側端末および発呼側端末のユーザをそれぞれ指していると理解するものとする。
【０００５】
発呼側が、被呼側にどのように通知されるかを選択することができれば、発呼側は何らかの方法でカスタム化した警報、例えば、発呼側の人格、職業、趣味、好みに合わせたり、あるいはそれ以外でも気まぐれでカスタム化した警報を受けることも選択可能である。このような「カスタム化した警報」は、例えば、感情（例えば、喜び、真剣さ、気まぐれ、怒り、上機嫌、または緊急性）を情報と共に（たとえば、「this must be John the Builder」）伝達することができる。更に、発呼側は、彼らの判断でこのようなカスタム化警報の一覧を有し、日時、または呼を受ける人、または呼を受ける人の種類、または発呼先の国に適したカスタム化警報、または不規則なカスタム化警報、あるいはそれ以外でも、彼らが相応しいと思うようなカスタム化警報によって通知されるようにすることができる。
【０００６】
現在のカスタム化可能呼警報システムの第２の制約は、これらは音響を用いたある範囲の警報からの警報の選択を可能にするに過ぎないように思われることである。通例、電話ハンドセットには、スピーカ、バイブレータ、グラフィック画面、および発光装置を含む、ソフトウエアで制御可能なある範囲の出力が装備されており、これらも着信呼警報プロセスに関与することができる。
【０００７】
第３に、公衆電話交換網（ＰＳＴＮ）および公衆陸線移動ネットワーク（ＰＬＭＮ）の場合、あらゆるネットワークがＣＬＩに対応している訳ではなく、更に、一部の法的権限のみがその使用を許可している。したがって、あるＰＳＴＮ／ＰＬＭＮネットワークまたは法的権限では、ＣＬＩを利用する既存のカスタム化可能呼警報システムが発呼側を特定できない場合もあり、したがって適切な警報シーケンスを選択することはできない。
【０００８】
最後に、ＰＳＴＮ／ＰＬＭＮでは、ＣＬＩは、発呼側に電話番号が登録されていなければ（「無声」、「簿外」）用いることはできない。しかしながら、これらの場合、発呼側が発呼するときに、かれらの電話番号を送信したくなくても、他のプライバシを脅かすことが少ない手段によってであれば特定されてもよいと思うこともある。即ち、彼らの電話番号が被呼側の通信端末に利用されるようにならないのであれば、彼らの呼（複数の呼）を警報するために用いられる警報の特色を選択するために用いられるプロセスの一部として彼らの電話番号が利用されるような場合、彼らは意に介さないであろう。
【発明の開示】
【発明が解決しようとする課題】
【０００９】
本発明の目的は、既存の呼警報システムの制約の内少なくとも一部を克服する、カスタム化可能呼警報システムを提供することである。
【課題を解決するための手段】
【００１０】
一般的な言い方をすれば、本発明は、システム・ユーザが発呼した先の通信端末上で警報を活性化し、システム・ユーザの好みに応じて、活性化する警報を選択または何らかの方法で制御するシステムおよび方法を対象とする。
【００１１】
本発明の第１の側面によれば、カスタム化警報サービスに関与するユーザが発する呼を通知するために用いる警報の特色および／または形態を選択する方法を提供する。この方法は、
ａ．関与ユーザに対するカスタム化警報サービス構成を確立し、カスタム化警報サービス構成を１つ以上のネットワーク・アクセス可能デバイスに格納するステップと、
ｂ．関与ユーザが、第１通信端末を用いて第２通信端末に発呼し、この呼に第１通信サービスが対応するステップと、
ｃ．第２通信端末が、選択した警報記述子を用いて警報を活性化することによって、呼を通知するステップと、
を含み、警報記述子を、関与ユーザに対するカスタム化警報サービス構成に応じて選択する。
【００１２】
「通信端末」は、適した種類の通信端末であればいずれでもよい。これは、本発明の目的に合わせて特別に設計した端末とすることもでき、あるいは標準的なタッチ・トーン電話機(touch-tone telephone)のような、通常の市販されている端末でもよい。
【００１３】
本発明の第２の側面によれば、コンピュータ化システムを提供する。これは、当該システムに関与するユーザが、前記システムに関与する通信端末に対して行う呼を通知するために用いる警報の特色および／または形態を、関与ユーザの好みに応じて決定することを可能とする。このシステムは、
ａ．少なくとも一部が警報記述子を受信し、それに対して動作可能な、複数の通信端末と、
ｂ．関与ユーザに対してカスタム化警報サービスを作成するデータ入力デバイスと、
ｃ．関与ユーザのカスタム化警報サービスの構成する構成ソフトウエアであって、関与ユーザのカスタム化警報サービスの構成が、関与ユーザのカスタム化警報サービスと共に用いるために、少なくとも１つの警報記述子を選択および／または提供することを含む、構成ソフトウエアと、
ｄ．関与ユーザのカスタム化警報サービス構成を格納するデータベースと、
ｅ．関与ユーザが受信側通信端末に対して発する呼と共に用いる警報記述子を選択する処理手段と、
ｆ．警報記述子を受信側通信端末に伝達する伝達経路と、
を含み、
選択した警報記述子は、関与ユーザのカスタム化警報サービスの構成に応じて選択する。
【発明を実施するための最良の形態】
【００１４】
本発明の全体的な説明
本明細書全体において、「警報」という用語に言及する場合、被呼側の注意を着信呼に向けることを意図して、被呼側端末によって発せられる、人が感知可能な放射を指すと理解するものとする。更に、本明細書全体において、「警報記述子」という用語に言及する場合、警報のディジタル・エンコード表現を指すと理解するものとする。
【００１５】
本発明の特定的な一実施形態では、警報サーバによって、関与ユーザのカスタム化警報サービス構成を格納する手段と、関与ユーザのカスタム化警報サービスと関連付けられた警報記述子を選択する手段とを設けることができる。この点について、「警報サーバ」という用語は、本明細書全体を通じて、関与ユーザのカスタム化警報サービス構成を格納することができ、ネットワークにアクセス可能なプログラム式コンピュータを指すと理解することとする。
【００１６】
本発明の好適な形態では、カスタム化警報サーバイスは、関与ユーザによって、またはその代理で構成することができる。
本発明の好適な実施形態によれば、関与ユーザのカスタム化警報サービスを構成するには、補助情報を選択および／または提供することを含むようにするとよい。この点について、「補助情報」という用語は、本明細書全体を通じて、関与ユーザによって、またはその代理で提供され、警報記述子を使用するとよい好ましい状況を判定する際に、警報サーバまたは関与する端末を補助することができる情報（例えば、規則）を指すと理解することとする。本発明のこの好適な形態では、警報記述子を選択するには、関与ユーザと関連する補助情報から引き出した情報を用いることができる。
【００１７】
この説明の目的上、「通信端末」は、一般的に、電話ハンドセット、移動電話ハンドセット、ビデオ電話機、または呼を設定可能なパーソナル・コンピュータのような端末であり、カスタム化警報システムに関与する機器の１つである。通信端末は、それがカスタム化警報システムと共に用いられない端末である場合にも有する機能性に加えて、追加の機能性を有することができる。この点について、通信端末は、何らかのフォーマット（複数のフォーマット）または設定（複数の設定）または群（複数の群）または分類（複数の分類）または種類（複数の種類）または部類（複数の部類）の警報記述子が関連付けられた着信呼を受信し、デコードし、それに応じて正しく動作することができ、更に対応するフォーマット（複数のフォーマット）、設定（複数の設定）、群（複数の群）、分類（複数の分類）、種類（複数の種類）または部類の特定の警報記述子を処理し、必ずしも必要ではないが、完全な忠実度または元来想定されている忠実度で、警報記述子が表現する警報を再生することができるようにするとよい。
【００１８】
一方、本発明は、その好適な実施形態において、カスタム化警報に必要な機能を有していない通信機器と協同して動作する。例えば、洗練されておらず、カスタム化警報を処理できない電話ハンドセットが、カスタム化警報を指定する呼を受信した場合、ハンドセットは通常通りに呼び出すことが好ましい。一方、本発明によるシステムは、カスタム化警報付の呼を、それ自体はカスタム化警報を受信できない電話ハンドセットから作ることを可能とする。この点について、既存の通信端末母集団との「下位互換性」が必要な場合、そのような相互作用が必要なときには、そのカスタム化警報システムまたは構成機器（複数の構成機器）は、一時的にカスタム化警報システムに関係する機構を動作不能とし、カスタム化警報システムがない場合に必要となる方法で、非関与通信端末と双方向処理を行う。あるいは、カスタム化警報システムは、非関与端末に対して透過的（可視ではない）となるように設計することもできる。あるいは、カスタム化警報システムは、前述の設計方針双方を利用して、下位互換性を備えることもできる。例えば、移動電話の状況で用いるように設計したカスタム化警報システムは、通例では、カスタム化警報を受信しそれに応じて動作することができる端末や、それができない端末を含む異質の通信端末母集団に対応する必要がある。このような状況では、被呼側端末に対してネットワークを利用して通知し、呼設定の間に被呼側端末に警報記述子を伝達するようにした特定的なカスタム化警報システムの設計では、この機能は、非関与通信端末には「透過的」な方法で実行することができる（例えば、非関与端末が調査も利用もしない呼設定プロトコル内のパラメータまたはオクテットを利用することにより）。あるいは、カスタム化警報システムは、通信端末が非関与通信端末であることを検出したときに、標準的な呼設定ダイアログを実行するロジックを呼び出すことができる（即ち、カスタム化警報システムがない場合には正しい呼設定ダイアログ）。
【００１９】
各通信端末は、
ａ．カスタム化警報管理システムから警報記述子を要求し検索することを可能にするプログラム・ソフトウエアおよびデータ、および／またはカスタム化警報管理システムが提供するカスタム化警報記述子を受け入れることを可能にするプログラム・ソフトウエアおよびデータ、
ｂ．対応するように意図した警報記述子、または対応する必要がある警報記述子に対して正しく動作させるために必要となり得る追加のソフトウエアおよび／またはハードウエア（例えば、エンコードした警報を再生する）、
ｃ．警報記述子をローカルにインデックス化し、格納し、管理し、検索することによって、カスタム化警報記述子をキャッシュし、以前の呼と同じ警報記述子と関連付けられている呼を今後受けた場合に再利用できるようにするためのプログラム・ソフトウエアおよびデータならびに十分なメモリ、
を含むことが好ましい。
【００２０】
通信端末は、これらが解釈しそれに応じて動作することができるあらゆる警報記述子に応じて動作するように設計または構成することができる。あるいは、通信端末は、特定の部類（または複数の部類）の警報記述子に応じて動作するように制限してもよい。特定の１つまたは複数の部類は、警報記述子の種類（例えば、音響警報記述子のみを処理する）、警報記述子のフォーマット（例えば、ＭＰＥＧ３警報記述子のみを処理する）、および／または警報記述子の発信元を指定する制約（または複数の制約）に応じて規定することができる。例えば、通信端末は、特定のカスタム化警報管理システム（複数のシステム）、または特定の電話会社（複数の会社）、またはインターネット・サービス・プロバイダ（複数のプロバイダ）、またはアプリケーション・サービス・プロバイダ（複数のプロバイダ）、あるいはその他の種類のサービス・プロバイダまたはサービス・プロバイダの集団と関連付けられた警報記述子のみに応じて動作するように制約を設けてもよい。この制約（複数の制約）は、関与ユーザまたはカスタム化警報管理システムの所有者（または操作者）あるいは双方の好みの表現を表してもよい。
【００２１】
本発明の好適な形態では、通信端末は、更に別の追加機構を可能にするサブシステムまたは複数のサブシステムを含むこともできる。例えば、通信端末は、
ａ．警報サーバの機能、
ｂ．カスタム化警報管理システムの機能、および
ｃ．警報記述子の設計／作成／開発機能
の一部または全てを実行可能とするサブシステム、または複数のサブシステムを含むこともできる。
【００２２】
追加機能性を通信端末に組み込むことによって、とりわけ、カスタム化警報システムの実施が可能となり、カスタム化警報システムの必要な機能性全てを通信端末に内蔵することができる。
【００２３】
以上通信端末とカスタム化警報システムとの間の連携について言及してきたが、この連携は１つのみである必要はない。実際、通信端末は、多数のカスタム化警報システムに同時に関与することや、あるいはこれらと相互動作することも可能である。
【００２４】
これより警報記述子に言及するが、本発明の目的上、警報記述子は、警報のディジタル・エンコード表現であり、警報記述子は、通信端末が解釈可能な何らかのフォーマットでエンコードされ、正しくデコードされれば、被呼側端末が、そのように表現された警報を生成できるようになるのに十分な情報を備えている。この点について、警報記述子は、音、静止画像または動画、または他の形態のマルチメディア、あるいはその組み合わせをエンコードまたは指定することができ、更に、警報記述子の副成分を再生するタイミングおよび順序、ならびに警報記述子の副成分を印加する出力デバイスを指定する情報もエンコードすることができる。
【００２５】
単純な警報記述子の一例は、コード化ビット・ストリームであり、被呼側端末がデコードすることができ、適切な音響出力デバイスによって繰り返し対応する警報を再生することによって、被呼側端末が関連する着信呼を通知するという命令と共に、音響波形を表す。このようなカスタム化警報の音響「コンテンツ」は、「ＭＩＤＩ」、ＷＡＶ、ＭＰ３のような何らかの周知の音響フォーマット、あるいは規格に基づくものであれ、企業固有のものであれ、その他の何らかの適当なフォーマットで提供することができる。
【００２６】
本発明を取り巻く状況では、通信端末は、警報記述子を利用して、その制御可能な出力デバイスの１つ、複数または全てを制御または変調し、保留中の呼を通知することができる。適した制御可能出力デバイスの例は、
ａ．音響信号を発信することができる可制御出力デバイス（例えば、スピーカおよびブザー）、
ｂ．電磁放射線を放出または選択的に反射することができる可制御出力デバイス（例えば、電話機またはコンピュータまたはあらゆる種類の「パーソナル・ディジタル・アシスタント」のディスプレイ、ランプ、発光ダイオード）、
ｃ．機械的な移動が可能な可制御出力デバイス（例えば、バイブレータ、機械式アーム）、および
ｄ．臭いを放出することができる可制御可能出力デバイス、
を含む。
【００２７】
警報記述子は、カスタム化警報システムの加入者またはユーザによって、またはその代理で規定した補助情報と関連付けることができ、被呼側端末がこれを用いて、どのようにまたはいつ警報を利用するかを判断することができ、あるいは警報サーバがこれを用いて、システム加入者またはユーザと関連付けられている複数の警報のどれを、呼と共に用いるために被呼側端末に供給するか決定することができる。更に、警報記述子は、名称または識別子またはラベルと関連付けることができても、できなくてもよい。
【００２８】
本発明の好適な形態では、呼に対して被呼側によって警報を再生するために用いられる警報記述子は、警報記述子またはサービスに付随する補助情報のコンピュータ化処理に応答して決定することができる。本発明の好適な実施形態では、決定した警報は、発呼した時点、またはその他の状況に対応することができ、更に呼を受けた特定の人または特定の部類の人に応じて変更することもできる。この点について、特定の呼に対して用いる正しい（または最も適切な）警報の決定は、警報サーバ、または被呼側端末と関連するロジックによる補助情報の処理によって決定することができ、これによって、用いる警報は、「誰が」発呼しているのか（例えば、発呼側端末または発呼側ユーザ）、「誰に」発呼しているのか（例えば、被呼側端末または被呼側）、および好ましくは「その他の」変数の関数であることが好ましい。
【００２９】
本システムの特定的な実現例では、本発明が提供する汎用性を全て利用しなくてもよい場合もある。この点について、警報を選択するために用いるロジックの複雑性を、好適な発明の部分的実施によって簡略化することもできる。例えば、用いる警報は、「誰が」発呼しているのか、およびその他の変数の関数としてもよい。あるいは、用いる警報は、単に、「誰が」発呼しているのかの関数でもよい。
【００３０】
以下の説明では、特定の呼と共に用いる警報を決定するプロセス中において、個々にまたは一体として考慮に入れるとよい「その他の」変数の例を提示する。
（ａ）時間変数
警報をいつ用いるかは、時間関係変数の値によって決定され、この変数は、発呼側の場所または被呼側の場所、あるいは発呼側および被呼側双方の場所またはその他のいずれかの場所において適用される。時間変数の例には、以下のものが含まれる。
（i.）日時（例えば、被呼側の時間帯に示される０８００乃至１８００の間に特定の警報を用いる）、
（ii.）曜日、
（iii.)「週日／週末ステータス」（例えば、週末に特定の警報を用いる）
（ａ）季節および風習(cultural)関数
警報をいつ用いるかは、いずれかの「風習」関数の値によって決定され、この変数は、発呼側の場所または被呼側の場所、あるいは発呼側および被呼側双方の場所またはその他のいずれかの場所において適用する。風習変数の例は、
(i.)現在の季節（例えば、夏、冬、秋、春）、
(ii.)国が定めた祝日、特別な祝日、または宗教的祝日（例えば、イースタ）、
(iii.)特殊行事（例えば、２００４年オリンピックの開催期間中）、および
(iv.)ある関心のある行事の期間中、
が含まれる。
（ａ）地理的変数
警報をいつ用いるかは、被呼側、発呼側の端末または双方の絶対的または相対的な場所によって決定される。地理的変数の例には、
(i.)場所（例えば、都市、地域、州、国）、および
(ii.)地理的座標（例えば、緯度、経度、高度、ある既知の位置からの距離）
（ｄ）近接度関数
警報をいつ用いるかは、被呼側および発呼側の相対的な近接度によって決定される。例えば、警報がガイガー・カウンタを模擬する場合、被呼側および発呼側が互いに近くなる程、これらが離れていく場合よりも頻繁にクリック音を発生する。
（ｅ）個人変数
警報をいつ用いるかは、個人変数の値によって決定され、この変数は、発呼側の場所または被呼側、あるいは発呼側および被呼側双方またはその他のいずれかの相手に適用する。例えば、年齢、星座、性、好みの色、好みの番号がある。
【００３１】
先に提示した変数はいずれも、または全てを、本発明の特定のシステムの目的、および変数を決定させる情報の利用可能性に応じて、被呼側または発呼側のいずれか、あるいは両側と関連付けることができる。この点について、特定の変数の値は、既存の電気通信システムにおいて定期的に得られる情報から決定することも可能である。例えば、現行の移動電話機の殆どは、時計／カレンダー機能を含み、これを用いれば、ある時間関数、季節関数、または風習関数を決定することができる。別の例として、地理的変数は、被呼側の電話番号のプレフィックスおよび関連する参照表を用いることによって、あるいは地理的測地システム（ＧＰＳ）のような地理的測地機能を用いることによって決定することもできる。地理的測地システムは、移動電話ハンドセットと関連させたり、内部に組み込むこともできる。
【００３２】
説明の目的上、以下の例では、呼と共に用いる呼警報を決定する際に適用可能な変数について説明する。
（ａ）占星術適合性警報
この例では、被呼側端末において活性化される警報は、関与する発呼側および被呼側間における「占星術適合性」の評価に応じて生成することができる。「占星術適合性」は、被呼側および発呼側双方によって行われる加入プロセスの一部として既に与えられている「占星術データ」（例えば、星座）から推論する。適合性レベルが高いと評価された場合、鼓動のない(unbeat)聴覚および視覚警報を生成することもできる。あるいは、適合性レベルが低いと評価された場合、下拍(downbeat)聴覚および視覚警報を生成することもできる。好ましくは、「占星術適合性」を決定するには、規則およびその他の占星術者から得られる情報を用いて適合性を決定することができるアルゴリズムを用いるとよい。
（ｂ）潜在的協力者警報
この例では、被呼側端末上にて活性化する警報は、関与する発呼側および被呼側間における「個人的適合性」のレベル評価に応じて決定することができる。この評価は、データを組み合わせて比較するアルゴリズムによって推論され、好ましくは、データには、年齢、性別、既婚／未婚、職業、異性の好み、関心事、および趣味を含み、双方の側から提供される。好ましくは、適合性を決定するために用いるアルゴリズムは、公認の権威、または解説者からの入力、あるいは個人的適合性に基づくようにするとよい。
（ｃ）「アメリカ人および誇り」(American and Proud)
この例では、米国に所在する関与発呼者から海外への呼を通知するために用いる警報は、既知の米国のテーマ(theme)およびアイコン（例えば、Spangled Banner, America the Beautiful,およびStatus of Liberty)に基づく系列の１つから選択することもできる。関与する発呼側は、１つのテーマを常に用いることを要求することもでき、あるいはシステムが、関与する発呼側または関与する発呼側の指定端末から行われた発呼に対して、テーマを不規則にまたは連続して選択することを要求することもできる。この例では、関与する発呼側が米国内に所在する場合について述べているが、同様の機能は他の国においても、対応するテーマおよびアイコンを用いて、同等に利用することができる。更に、国の代わりに、都市、スポーツ・チームの後援会(affiliation)に基づいた同様のサービスを提供することもできる。
（ｄ）社会的認知(Socially Aware)
この例では、関与する発呼側からの呼を通知するために用いる警報は、社会的および環境的原因に基づく系列の１つとすることができる。一例では、関与する発呼側は、利用可能な警報の集合（例えば、Save the Whale（鯨の保護）、Save Raiforests（熱帯雨林の保護）、およびForgive 3rd Wold Debt（第３世界の債務免除）からある数の異なる警報を予め選択しておき、これらを不規則に使用することを示すことができる。更に、警報の選択には、選択した集合に関連する画像およびサウンド（例えば、「熱帯雨林保護」警報は、選択した数の異なる熱帯雨林の１つから、リアル・タイムに引き出すことができる）を利用することもできる。
（ｅ）製品／サービス奨励
この例では、関与する発呼側からの呼を通知するために用いる警報は、特定の商業的企業、サービスまたは製品を奨励するために、商業的に支援し用いることができる。ここでは、商業的スポンサは、発呼が行われる毎に、カスタム化警報のサービス提供者にある量の金を支払い、更に関与する発呼側が彼らの警報を選択した場合にも、恐らくは発呼が行われる毎に支払うようにするとよい。
【００３３】
前述の例を参考にすれば、本発明の特定のシステムの目的に応じて、コンピュータ化したプロセスを用いて警報を決定する（所与の呼と共に用いるのに適した警報記述子の選択を通じて）ことは、比較的簡単であると考えられる。例えば、単一の変数を評価し、次いで評価した変数の値に対応する警報を選択する。他の場合では、変数の決定および警報の選択は、比較的複雑であると考えられ、例えば、多数の変数、および恐らくは、その他の外部情報の検索および評価を伴う複雑なアルゴリズムの実行が必要となる。
【００３４】
本発明の好適な実施形態では、変数の値を決定するのが難しい場合、プロキシ変数(proxy variable)を代わりに用いることができる。例えば、ＣＬＩＤ（発呼回線識別）を、関与発呼側識別子の代わりに用いることができる。
【００３５】
以上警報記述子および通信端末について説明し終えたので、カスタム化警報管理システムについてこれより説明する。
本発明の好適な実施形態によれば、カスタム化警報システムは、カスタム化警報管理システムによって運用(administrate)することができる。好ましくは、カスタム化警報管理システムは、コンピュータ化されたシステムであり、１つ以上のネットワーク形態の計算機または計算装置を含み、合計した処理能力および記憶容量は、必要なアプリケーション・ソフトウエア、データベース、および支援ソフトウエアを動作させることができるのに十分な量である。この点について、カスタム化警報管理システムは、必要な情報のために十分な総ストレージ、および十分なネットワーク接続性も備え、個々のカスタム化警報システムの実現例に合わせて選択した１つまたは複数の警報記述子転送機構に応じて、警報記述子および関連情報を通信端末に分配することもできる。
【００３６】
カスタム化警報管理システムは、専用ハードウエア上に実現する必要はない。実際、カスタム化警報管理システムを実施可能なハードウエアは、他のカスタム化警報システムの機能性も実現する（通信端末を実現するハードウエア等）。更に、カスタム化警報管理システムは、ハードウエアまたはソフトウエア資源のような他の資源を、前記した他のカスタム化警報システムの機能性と共有することもできる。
【００３７】
カスタム化警報管理システムは、単体である必要はなく、むしろ分散実体であってもよい。この点について、カスタム化警報システムの一部をなすアプリケーション・プログラムは、物理的に同じ場所に配してなくてもよく、代わりに多数の場所に配置し、それぞれの１つまたは複数の役割を遂行するための必要性に応じて、データ・リンク、１つまたは複数の通信ネットワーク、または通信相互ネットワークによって、互いに通信できるようにすることもできる。カスタム化警報管理システムは、一人の人間または単一の法的実体が所有、制御、または管理する必要もない。
【００３８】
個々のカスタム化警報管理システムの正確な機能は、カスタム化警報システムの実施の範囲、目的、および態様によって、多少異なる可能性がある。この点について、個々のカスタム化警報システムの設計は、本発明の方法に用いると便利な、特定のプロセスに対応することができる。
【００３９】
簡単な分析において、本発明の方法に関与するプロセスを、
（ａ）展開サブプロセス、および
（ｂ）発呼サブプロセス、
という２つの主要サブプロセスに関して説明する。
【００４０】
展開サブプロセスは、ユーザ即ち加入者が１つまたは複数の警報記述子を選択または備えておき、ユーザ即ち加入者が指定した１つまたは複数の通信サービスからの呼を通知する際に、通信端末によって今後用いることを可能にする、本発明の方法のプロセスである。
【００４１】
発呼サブプロセスは、１つまたは複数の警報記述子を検索し、恐らくは通信端末が利用する間における本発明の方法のプロセスである。
本発明の方法によれば、展開サブプロセスが先行し、発呼サブプロセスに対する前提条件となる。
【００４２】
好ましくは、展開サブプロセスの間、ユーザは、インターネットに接続されている計算装置のような双方向処理媒体を用いて、または実際には適正に装備された通信端末を用いて、カスタム化警報管理システムと双方向処理を行う。
【００４３】
ユーザのカスタム化警報管理システムとの双方向処理は、カスタム化警報管理システムが適切な識別プロセスを実行し、ユーザの素性を認証する際に行うことができる。この点において、カスタム化警報管理システムは、１つまたは複数の資格検証プロセスを実行し、実行しようとしている機能を実行することをユーザが許可されているか否か検証することが好ましい。
【００４４】
資格チェック・プロセスは、指定の通信サービス（複数のサービス）および／または通信端末（複数の通信端末）と関連付けられた１つまたは複数のデータベースとの双方向処理を含むことができる。本発明の好適な一形態では、カスタム化警報管理システムは、電話会社またはインターネット・サービス・プロバイダ、または通信サービス・プロバイダ、またはその他の何らかのサービス・プロバイダのような、１つ以上の他の実体が所有し制御する１つ以上のデータベースと双方向処理を行い、資格チェックを行うことができる。
【００４５】
本発明の好適な実施形態によれば、一旦カスタム化警報管理システムへのアクセスが成立したなら、ユーザは、何らかの対話型選択プロセス、または何らかのその他の適切な手段によって、１つまたは複数の警報を選択することができる。続いて、選択された警報は、通信端末によって用いられ、ユーザ、あるいは他の指定された人または人の群や部類によって通信端末に行われた発呼を通知することができ、このような人々の代理で、警報選択の動作を行っている。あるいは、選択された警報は、続いて通信端末によって用いられ、指定された通信サービスまたは通信端末から行われた発呼を通知することができる。ユーザは、この指定通信サービスまたは通信端末を利用するか、またはその制御を行い、更に、この指定通信サービスまたは通信端末は、ある人あるいは人の群または部類によって利用または制御され、これらの人々の代理で動作する。
【００４６】
本発明の好適な実施形態では、警報選択プロセスによって、ユーザは、カスタム化警報管理システムが利用可能な、ある範囲の既存の警報から選択することが可能となる。理想的には、本発明は、アップロード・プロセスまたはその他の何らかの適当な手段によって、警報記述子の形態で警報をカスタム化警報管理システムに設ける機能もユーザに与える。この点について、そのようにユーザによって提供される警報記述子は、ユーザによってまたはユーザのその代理で自己発現したものでもよく、あるいはウェブ・サイトのような第三者の場所、または実際には特殊化「警報ポータル」ウェブ・サイトから発生することができる。
【００４７】
本発明の好適な実施形態では、カスタム化警報管理システムは、対話型選択、またはアップロード・プロセスによって、ユーザに補助情報を供給させ、カスタム化警報管理システムがこの情報を用いて、１つまたは複数の警報記述子を通信端末に提供すべき好ましい状況を判断する際に補助するようにすることが好ましい。理想的には、本発明は、カスタム化警報管理システムがあらゆるまたは全てのパラメータを、通信端末のような、関与する他の実体に転送することができ、他の関与実体がいつおよび／またはどのように、選択、指定、または提供した１つまたは複数の警報記述子を用いるとよいか判定することができるようにする。
【００４８】
本発明の好適な実施形態では、ユーザは、１つ以上の警報から成る既存の警報一覧を選択することができるようにするとよく、この一覧は特定のテーマ（即ち、カテゴリ）に沿っており、有名なタレント、または場所、または行事、または物に応じて、何らかの方法でこれを反映するように選択する。次いで、選択したテーマ即ちカテゴリを用いて、選択した一覧からの警報を用いて、ユーザからの呼を通知する。あるいは、警報は、不規則にまたは巡回的に、呼毎に、および／または時折変更する。例えば、このようなテーマは、"clean and green"、"Jesus saves"、"Adidas"、"Cola Cola"、"Tiger Woods"、"Fox Movies"、"Sony Top Twenty"、"romantic girl"、"rainforest"、"surfin USA"、"cat lover"を含むことができる。
【００４９】
本発明の特に簡単な実施形態では、ユーザは、タッチ・トーン（ＤＴＭＦトーン）機能付き電話ハンドセットを用いて、警報を選択することができる。この点について、ユーザは、特定の警報をカスタム化警報管理システムに対して識別する番号または番号語(number words)に対応するキーストロークを用いて、警報を選択することができる。あるいは、本発明のこの特に簡単な実施形態を一層使いやすくした場合には、カスタム化警報管理システムは、１つの警報または一連の警報を、ＤＴＭＦ機能付き電話ハンドセットの音響出力装置を通じてユーザのために演奏し、ユーザは、キーストロークまたは一連のキーストロークによって、現在再生中の警報を選択したいことを指示する。
【００５０】
好ましくは、カスタム化警報管理システムが、選択した警報、ユーザが入力したパラメータ、ユーザ、人々、人の群、人の部類、およびその他の必要な情報の間で十分な連携を確立することによって、カスタム化警報管理システムは、警報が通信端末によって要求されたときに、特に、これらを通信端末に分配することを含む動作機能を実行することが可能となる。この点について、カスタム化警報管理システムは、関連する情報および連携を１つまたは複数の適したデータベースに格納することが好ましい。
【００５１】
警報記述子（複数の記述子）および補助情報の通信端末に対する分配が行われるのは、個々の呼に対する呼設定プロセスの前でも、最中でも、後でもよい。この点について、警報分配のタイミングは、ここで本発明の方法の一部として記載した多数の選択肢の内どれを所与のシステムに実施するかによって異なり、恐らく、呼設定の時点における動作状況によっても異なる。例えば、通信端末および基盤ネットワークの機能、ネットワークのレイテンシ、および通信端末の機能が含まれる。
【００５２】
これより、発呼サブプロセスについて言及するが、発呼サブプロセスの実施は、カスタム化警報システムの設計に応じて異ならせることができる。本発明の方法を用いるシステムは、以下の３つの異なる実現例、即ち、
（ａ）「被呼端警報フェッチ」
（ｂ）「発呼端警報提供」、および
（ｃ）「警報プッシュ」(alert push)
の１つ、一部、または全てに対応することができる。
【００５３】
本発明によれば、「被呼端警報フェッチ」プロセスに対応するカスタム化警報システムでは、警報関係処理は、時間的および機能的に、呼設定試行の間に被呼側端末とそのローカル通信ネットワークとの間で行われる呼設定シグナリング・ダイアログに関連付けられており、更に、時間的および機能的に、呼設定試行の間に発呼側端末とそのローカル通信ネットワークとの間で行われる呼設定シグナリング・ダイアログにも関連付けることができる。この点について、呼設定プロセスの間、被呼側端末は、発呼側端末または発呼側ユーザまたは発呼側通信サービスが、カスタム化警報システムに関連付けられているまたは関連付けることができること、および警報記述子がこの呼と共に用いるために入手可能である、または入手可能とすることができることを知らされるか、またはそのように決定するか、またはそのように想定する。更に、警報記述子は、呼設定の間に、被呼側端末に接続する通信ネットワークと関連する処理ロジックによって、被呼側端末に供給することができる。あるいは、被呼側端末自体が、それに提供される情報を用いて、またはローカル通信ネットワークを通じて、警報サーバから警報記述子（複数の記述子）の位置を突き止め、検索することもできる。
【００５４】
「被呼端警報フェッチ」発呼サブプロセスを用いる本発明のシステムの好適な形態では、発呼サブプロセスは、
１．発呼側は、被呼側の端末に対する呼を設定しようとする（例えば、電話の状況では、該当する電話番号をダイアルし、必要であれば、「送信」ボタンまたは同等物を押下することによって）。
２．被呼側端末が、呼確立要求を受信する（例えば、電話の状況では、ローカル通信ネットワークからのシグナリングは着信電話呼を示す）。
３．警報記述子がこの呼と共に用いるために利用可能である、または利用可能であるかもしれないことを、被呼側端末によって通知、決定、または想定する。
４．（必要な場合）警報記述子を被呼側端末によって検索することができる場所の決定。
５．（必要な場合）被呼側端末による警報サーバからの警報記述子の検索。
６．被呼側端末が警報記述子を解釈し利用することによって、警報記述子に対応する、人感知可能出力（即ち、「警報」）の放射。
７．（被呼側は、警報に応答してもしなくてもよい）、および
８．任意に、今後の使用のために、警報記述子をローカルに格納する。
【００５５】
尚、以上提示したステップには、多くの変形が可能であることは理解されよう。
「被呼端警報フェッチ」発呼サブプロセスを用いた本発明の特定的な実施形態では、被呼側端末は、所与の着信呼に警報記述子が利用可能か否か判定できるようにするとよい。ここで、被呼側端末は、呼設定ダイアログの間にこれに供給または中継された警報記述子利用可能性情報を用いて、所与の着信呼に警報記述子が利用可能か否か判定する。この呼設定ダイアログは、そのローカル通信ネットワークによって開始される。この時点において、ローカル通信ネットワークは、追加情報を提供または中継して、被呼側端末が警報サーバ（または複数の警報サーバ）を突き止め、これにアクセスして、呼に用いる警報記述子を検索できるようにする。この点について、可能な状況の１つでは、利用可能性および場所情報は、発呼側端末から被呼側端末に、端末間シグナリングによって中継することができる。この場合、情報は発呼側端末によって事実上提供され、発呼に関与する介在通信ネットワーク（複数のネットワーク）は、カスタム化警報システムの存在を知らず、単純なリレーとして作用する（例えば、最近のディジタル電話ネットワークは、多くの場合、呼設定プロセスの間に透過的端末間情報転送を行うことができる）。また、この場合、警報サーバを発呼側端末内に配置してもよい。
【００５６】
あるいは、要求された情報は、ネットワーク対端末シグナリングによって、被呼側端末に提供してもよい。この状況では、発呼に関与するネットワーク（複数のネットワーク）は、カスタム化警報システムにおいては、アクティブな構成要素となることができ、これらの１つ以上は、発呼側端末識別子（または発呼側サービス識別子）を警報システム関与（即ち、「その」ローカル端末または通信サービスのどれが現在カスタム化警報システムに関与しているかが「わかる」）と関連付ける処理ロジックを組み込むか、またはこれと関連する。この点について、特定的な一状況では、現在発呼側端末と関連するネットワーク対端末シグナリング・システムと関連する前記処理ロジックは、カスタム化警報管理システムに、発呼側端末または通信サービスが発呼を開始していることを知らせ、カスタム化警報管理システムに情報を提供する（例えば、発呼側端末の電話番号またはその他の何らかの相応しい識別子および他の何らかの相応しい識別子の被呼側端末の電話番号）。カスタム化警報管理システムは、この情報を用いて、警報記述子（複数の形状記述子）および恐らくは、補助情報も突き止めて検索することができ、被呼側端末は呼と共にこの情報を用いる。好ましくは、カスタム化警報管理システムは、次に、このように検索した警報記述子（複数の警報記述子）および恐らくは補助情報も、被呼側端末またはサービスを特定する情報と共に、現在被呼側端末またはサービス（同じネットワーク対端末シグナリング・システムであっても、なくてもよい）と関連するネットワーク対端末シグナリング・システムと関連する処理ロジックに提供する。好ましくは、現在被呼側端末と関連するネットワーク対端末シグナリング・システムと関連する処理ロジックは、次に、被呼側端末に、警報記述子が着信呼と共に用いるために利用可能であることを通知し、更に、被呼側端末に、着信呼と共に用いる前記警報記述子の識別名またはラベル、即ち、識別子を提供し、更に、被呼側端末が、ネットワーク・アドレス情報のような、呼を通知するために優先的に用いられる警報記述子を突き止め検索する際に補助となるネットワーク・アドレス情報のような情報を被呼側端末に提供し、更に呼を通知するために優先的に用いられる警報記述子を被呼側端末に提供する。
【００５７】
発呼通信サービスおよび被呼通信サービスが単一のネットワーク運営業者と関連付けられている（または「誘導されている」(homed)）場合、警報関係通信ダイアログは、公認のシグナリング・プロトコルおよびアーキテクチャ（例えば、ＰＳＴＮまたはＰＬＭＮの場合ＩＮおよび／またはＳＳ７；ＩＮＡＰ、ＴＣＡＰ、ＭＡＰ、ＴＵＰ、ＩＳＵＰ）、またはインターネット・プロトコル（ＩＰ）一式、またはセッション開始プロトコル（ＳＩＰ）、またはその他の何らかの相応しい手段を利用することができる。この点について、利用可能な選択肢は、カスタム化警報システムの実施の範囲、目的および態様、ならびにカスタム化警報システムの一部をなすまたはこれに利用可能な基盤ネットワーク（複数のネットワーク）の特色にいくらか左右される。更に、発呼側サービスおよび被呼側サービスが現在異なるネットワーク運営業者と関連付けられている（または「誘導されている」）場合、これら運営業者のネットワーク間の警報関係情報の転送は、更に、公認のまたは固有のまたはカスタム化したネットワーク間シグナリング・プロトコル、リンク、およびネットワークを利用することができ、このようなダイアログは、インターネットまたは私的ネットワーク（複数のネットワーク）のような介在するネットワークを横断してもしなくてもよい。
【００５８】
更に、警報関係通信ダイアログがＰＳＴＮまたはＰＬＭＮおよびインターネットまたはその他のＩＰネットワークを横断しなければならない場合、このようなダイアログは、このようなＩＥＴＦ  ＰＩＮＴ（「ＰＳＴＮおよびＩＮインターネットワーキング）、ＳＰＩＲＩＴＳ（'Service in the PSTN/IN requesting Internet Service'（ＰＳＴＮ／ＩＮ要求インターネット・サービスにおけるサービス）、ＳＩＧＴＲＡＮ（シグナリング・トランスポート）、ＭｅｇａＣｏ（'Media Gateway Control（メディア・ゲートウェイ制御）、およびenum（Telephone Number Mapping（電話番号マッピング）と相互作用するＩＰネットワークにＰＳＴＮ／ＰＬＭＮを促進するように設計されたアーキテクチャおよびプロトコルを利用することができる。
【００５９】
カスタム化警報管理システムは、部分的にまたは全体的に、インテリジェント・ネットワーク・アプリケーションまたはアプリケーション一式として実現することができ、インテリジェント・ネットワーク規格のＡＩＮまたはＩＴＵ−Ｔ系統のような、基準規格または固有インテリジェント・ネットワーク規則、アーキテクチャ、プロトコル、および機能を利用することができる。
【００６０】
被呼側端末およびネットワークまたは被呼側端末および発呼側端末間のダイアログの正確な特色（例えば、どちらが要求し、どちらが応答するか）は、実現例の問題である。適した方式であれば、いずれでも使用可能である。
【００６１】
被呼側端末にそのローカル通信ネットワークまたは発呼側端末によって供給される警報関係情報の形態および特色は、実現例毎に異なる可能性があるが、次を含むことができる。
（ａ）発呼側端末または発呼側サービスが（デフォルトのまたは指定の）カスタム化警報システムに関与している場合、そのことの肯定。
（ｂ）この呼と共に用いるために要求された警報記述子（複数の記述子）を処理することができることを示唆された警報サーバ（複数のサーバ）のネットワーク名（複数のネットワーク名）またはネットワーク・アドレス（複数のネットワーク・アドレス）。
【００６２】
・あるいは、または加えて、この情報を被呼側端末内に、ある早期時点においてロードしておくことも可能である。
・多数の警報サーバが、要求された警報記述子を同時に所有する場合もあり、その場合、所与の呼に用いるのに最適な警報サーバは、発呼時点において被呼側端末の地理的またはネットワーク位置の関数とすることができる。
（ｃ）修正されないまたは修正された形態で警報サーバ（複数のサーバ）に渡され、当該警報サーバ（複数のサーバ）がこの着信呼に適した警報記述子を特定し提供することを可能にする、被呼側端末の情報。これは、ＣＬＩＤ、あるいはカスタム化警報システム内の発呼側の相手または発呼側端末または発呼側サービスを特定する名称の形態、あるいは警報記述子の名称または番号または記述、あるいはこの呼に最も最適な警報記述子を突き止める際に警報サーバを補助することができるその他のいずれかの情報の形態を取ることができる。
【００６３】
あるいは、情報は、単に、この呼と共に用いられる警報記述呼から成るものでもよく、その場合、「被呼端警報フェッチ」発呼サブプロセスのステップ３乃至５を単一のステップと見なすことができ、前述のような他の情報は不要とすることができる。
【００６４】
「被呼端警報フェッチ」発呼サブプロセスを用いる本発明のシステムの代替実施形態では、関与する被呼側端末は、単に、警報記述子が所与の着信呼に利用可能であることを想定する。この実施形態では、ＣＬＩＤが利用可能であり、被呼側端末はローカル通信ネットワークからＣＬＩＤを受信し、これを所定の１つまたは複数の警報サーバに受け渡す。次いで、警報サーバ（複数のサーバ）は、この呼と共に用いる警報が入手可能か否か判定を行う。１つまたは複数の警報サーバは、警報記述子が入手可能な場合は、これを用いて被呼側端末に応答し、または否定で応答し、あるいは全く応答しない。更に、この実施形態では、カスタム化警報システムは、呼に関与しない通信ネットワーク（複数のネットワーク）の協同を必要としないように実施することもできる（例えば、電話の状況では、未修整のＰＳＴＮまたはＰＬＭＮおよび／または呼設定の間端末間通信に対応しない）。
【００６５】
「被呼端警報フェッチ」発呼サブプロセスを用いる本発明のシステムを更に簡略化した実現例では、被呼側端末が警報サーバから警報記述子を検索しなければならない場合、警報サーバは、この発呼側端末（即ち発呼側）に関連する利用可能な１つの警報記述子を所有するのであれば、これを用いて警報検索要求に応答することができる。
【００６６】
本発明の洗練性を高めた実施形態では、警報サーバは、警報記述子検索要求の受信時に、ユーザが提供した補助情報に基づいて追加的にロジックを適用し、最も適した警報記述子を選択し、被呼側端末に転送して、所与の着信呼と共に用いる際に補助することができる。このようなシステムでは、ユーザは、展開サブプロセスの間に、予め多数の警報を、これらをいつどのように用いるとよいかを示す補助情報と共に選択または提供しておくとよい。例えば、１つの警報は家族および友人（指定した電話サービスの）への呼に指定し、他の警報を仕事上の仲間への呼（指定した電話サービスの）に指定し、別の警報を、クリスマスの日に行われる呼に指定する（等）ことができる。
【００６７】
警報記述子検索のプロセスは、ファイル転送プロトコル（ＦＴＰ）、または自明ファイル転送プロトコル（ＴＦＴＰ：Trivial File Transfer Process）、あるいはディジタル情報の転送に適した他のいずれかのプロセスのような、既知のファイル転送プロセスを用いた、名称付きファイルの要求と同じくらい簡単であると思われる。
【００６８】
本発明の特定的な実施形態では、警報記述子検索は、被呼側端末が、要求された警報記述子がローカルに存在すると判断した場合、不要となる場合がある。これは、要求された警報記述子が、同じ警報記述子を用いて行った以前の呼の結果としてローカルメモリ内にキャッシュされていたためであるという場合があり得る。あるいは、要求された警報記述子が、製造または販売の時点で、あるいは恐らくは他のいずれかの時点で電話機にロードされたからであるという場合もあり得る。
【００６９】
好ましくは、被呼側端末が警報記述子を解釈し利用した結果、前述のように通信端末の適用可能な機構を利用して、警報記述子に対応する人感知可能出力（即ち、「カスタム化警報」）を放射する。
【００７０】
本発明の特定的な実施形態では、被呼側端末のユーザは、カスタム化警報を「不変」(sticky)にすることができる（即ち、それよりも新しいバージョンが得られなければ、そして得られるまで、キャッシュ・メモリから消去しない）。
【００７１】
本発明の好適な実施形態では、被呼側端末は、既定のローカル判断基準に応じて、いずれの段階においても発呼サブプロセスを放棄することができる。この点について、所定の時間期間以内に発呼サブプロセスが完了していない場合、被呼側端末は代わりにデフォルト警報または別のローカルに決定した警報を利用して、呼要求を通知する。本発明の特定的な実施形態では、被呼側端末は、警報記述子（複数の記述子）を検索し、恐らくはネットワーク・レイテンシの過剰のため、または被呼側端末が使用中（「通話中」）のため、または被呼側が利用できないため（「リングアウト」）、あるいはその他の何らかの理由のために現行の着信呼と共に用いることができない場合でも、今後の使用可能性のためにそれをキャッシュ・メモリに保持しておく。
【００７２】
以上提示した「被呼端警報フェッチ」発呼サブプロセスの実施形態は多種多様のカスタム化警報システムに適しているが、先に提示した実施形態には、個々のカスタム化警報システムの実現例の範囲、目的、および態様に応じて、多くの変形が可能であることは理解されよう。
【００７３】
以上「被呼端警報フェッチ」プロセスに適用可能な呼プロセスについて説明したので、次に「発呼端警報提供」プロセスについて説明する。この点について、「被呼端警報フェッチ」プロセスおよび「発呼端警報提供」プロセスは、同じ展開サブプロセスを利用できることは理解されよう。更に、本発明の「被呼端警報フェッチ」型または「発呼端警報提供」の個々の実施形態は双方の「プロセス」を必要としないことも理解されよう。
【００７４】
「発呼端警報提供」プロセスに対応する本発明のシステムでは、発呼側端末が警報関係処理を開始するが、発呼側が十分な情報を発呼側端末に提供し、被呼側端末を一意に特定できるようになったなら実際上可能な限り直ぐに開始することが好ましい（例えば、移動電話の状況では、桁の入力完了および「発呼」ボタンの押下後）。
【００７５】
「発呼端警報提供」発呼サブプロセスは、
１．発呼側が、被呼側との呼を設定しようとする（例えば、電話の状況では、該当する電話番号をダイアルし、必要であれば、「送信」ボタンまたは同等物を押下することによって）。尚、この時点以降、呼設定および警報処理は非同期的に進展する。
２．発呼側端末は、警報記述子を被呼側端末に提供する。
３．被呼側端末は、発呼側端末から警報記述子を検索する。
４．被呼側端末は、警報記述子を解釈し利用して、呼を通知する。
【００７６】
以上に提示したステップは、「発呼端警報提供」サブプロセスに適用可能と考えられる一連の動作の一例を提起する。この点について、先に提示したステップには、多くの変形が可能であることは理解されよう。例えば、発呼側端末は、被呼側端末に、カスタム化警報の入手可能性について通知するが、警報サーバとしては動作しないようにしてもよい。この場合、発呼側端末は、「被呼端警報フェッチ」発呼サブプロセスについて説明したのと同様の検索プロセスを用いて、該当する警報サーバから警報記述子を検索できるようにするのに十分な情報を被呼側端末に提供する。
【００７７】
「発呼端警報提供」発呼サブプロセスでは、発呼側端末は、「帯域外」で被呼側端末が使用できるように、情報を被呼側端末に提供することができる。適した方式であればいずれでも使用可能である。汎用性を失うことなく、以下の例を提起する。
（ａ）被呼側端末および発呼側端末が各々、パケット・ネットワークまたは相互ネットワークを通じたパケット系通信、および回路切替ネットワークを通じた回路計通信双方に対応する場合（例えば、電話の状況では、２Ｇ  ＷＡＰ、２．５Ｇ  ＧＰＲＳまたは３Ｇ電話機、あるいはＰＳＴＮ／ＰＬＭＮおよびインターネットまたはサービス・プロバイダＩＰネットワークまたは企業内イントラネットまたはその他の何らかの相互ネットワークのようなパケット・ネットワーク双方に「二重誘導」することができる、「インターネット電話機」、即ち、いわゆる「多弁ＰＤＡ」(talkative PDA)のような電話機）。
（ｂ）被呼側端末および発呼側端末が、セッションに基づく音声呼（例えば、移動電話の状況では、ＧＳＭ  ＳＭＳ（ショートメッセージ・サービス）またはＵＳＳＤ（非構造型補足サービス・データ・ベアラ・サービス、または予示された３ＧＰＰ  ＭＭＳ（マルチメディア・メッセージング・システム）による）に対応可能であることに加えて、非同期的に互いにディジタルメッセージを送受信することができる場合。
（ｃ）被呼側端末が、１つまたは複数のメッセージを発呼側端末に、呼設定プロセスの一部として送ることができる場合（例えば、呼設定プロセス中における透過的端末間情報転送）。
【００７８】
「発呼端警報提供」発呼サブプロセスを用いる本発明のシステムでは、警報処理は呼設定処理とは非同期であり、その実行には、警報記述子の到達が遅すぎて被呼側端末が所与の着信呼を通知するために使用できなくなるという随伴する危険性が伴う（例えば、既に呼に答えている場合）。本発明の特定的な実施形態では、被呼側端末は、警報記述子（複数の記述子）を検索し、恐らくはネットワーク・レイテンシの過剰のため、または被呼側端末が使用中（「通話中」）のため、または被呼側が利用できないため（「リングアウト」）、あるいはその他の何らかの理由のために現行の着信呼と共に用いることができない場合でも、今後の使用可能性のためにそれを保持しておく。
【００７９】
本質的に、「発呼端警報提供」サブシステムを用いる本発明のシステムの警報記述子処理機能は、被呼端が、その「ホーム」ネットワークによって供給された警報記述子識別子またはＣＬＩＤを用いて警報記述子をフェッチしなければならない場合の「被呼端警報フェッチ」について先に説明した警報記述子処理機能と同一である。
【００８０】
以上提示した「発呼端警報提供」発呼サブプロセスの実現例は広範囲のカスタム化警報システムに適しているが、先に提示した実施形態には、個々のカスタム化警報システムの実現例の範囲、目的、および態様に応じて、多くの変形が可能であることは理解されよう。
【００８１】
「発呼端警報提供」プロセスに適用可能な発呼サブプロセスについて説明し終えたので、これより「警報プッシュ」(Alert Push)発呼サブプロセスについて説明する。
本発明の方法によれば、「警報プッシュ」プロセスに対応する本発明のシステムにおいて、カスタム化警報システムに関与するユーザは、カスタム化警報管理システムに、発呼側端末識別子（複数の識別子）または発呼側サービス識別子（複数の識別子）のような情報（そして、任意に、展開サブプロセスの間にユーザによっても提供され、所与の着信呼と共に用いるために最も適切な警報記述子を選択する再に通信端末を補助することができる補助情報）と共に、１つ以上の指定した通信端末に警報記述子を提供することを要求し、前記通信端末が、前記発呼側ユーザまたは発呼側端末または発呼側サービスから今後受信し得る呼（複数の呼）と共に用いるために保持することができる。
【００８２】
この点について、警報プッシュ・プロセスとこれまでに説明したその他のプロセスとの間の相違は、警報プッシュ・プロセスでは、警報記述子を関与する通信端末に提供する際に、当該通信端末への呼と時間的に関連付ける必要がないことにある。実際、警報プッシュ・プロセスの好適な一実現例では、警報記述子は、十分な情報がユーザからカスタム化警報管理システムに提供され、前記指定した通信端末の一意の特定が可能になると直ぐに、指定の通信端末に分配される。
【００８３】
カスタム化警報システムの特定的な実現例では、警報プッシュ・プロセスは、「被呼端警報フェッチ」または「発呼端警報提供」プロセスのいずれかに加えて実施する。このように、関与ユーザは、彼または彼女の警報を、頻繁に通話する友人または仲間の通信端末に予め分配しておき、かける頻度が少ない番号に対しては要求時に利用可能とするようにすることができる。
【００８４】
警報プッシュ・プロセスに可能な一実現例では、ユーザは、選択した警報記述子（複数の記述子）をに自動的に提供し、好ましくはユーザの通信端末の個人住所録内の見出しが示す各通信端末に予め分配しておくように選択することもできる。この可能な実現例では、好ましくは、ユーザの通信端末の個人住所録に変更が生じたなら、自動的に更新を開始させ、新たな警報記述子（複数の記述子）の分配、および／または古い警報記述子（複数の記述子）の「削除」を行わせる。
【００８５】
以上「警報プッシュ」プロセスに適用可能な呼プロセスについて記載し終えたので、本発明の他の機能についてこれより説明する。
ネットワークのレイテンシによってカスタム化警報システムが被る制約を克服するために、本発明の特定的な実施形態は、ここでは「次回使用モード」と呼ぶ一実現例モードを設ける。
【００８６】
所与の番号に少なくとも１回発呼した人は、以前に前記番号に発呼したことがない人よりも、その番号に発呼する可能性が高いということは統計的な事実である。これは、多くの場合、二人の間に何らかの基盤関係、恐らくは社会的または商業的な関係が存在するためである。
【００８７】
「次回使用」モードでは、好ましくは、被呼側端末によって警報記述子を検索し、保持しておき、前記警報記述子を要求するような呼が１回または複数回将来のある時点において受信された場合に、次回以降用いるようにする。つまり、「次回使用」実現例モードは、前記警報記述子を必要とする後続の呼における警報処理に要する時間を短縮するという優れた効果を有することができる。何故なら、警報記述子は既に被呼側端末内に格納しておくことができ、そうすれば、遠隔地から検索する必要がないからである。更に具体的には、
（ａ）ある警報記述子と関連付けられた呼を受信し、必要な警報記述子が被呼側端末のローカルメモリにはないことがわかった場合、デフォルトの警報またはローカルで決定した警報を用いて前記呼を通知することができるが、この警報記述子を（好ましくは呼と同時に）検索し、発呼側端末またはサービスまたはその何らかのプロキシと関連付け（例えばそのＣＬＩＤ）、今後この警報記述子を必要とし得る着信呼があった場合に用いることができるようにローカルに格納しておき、
（ｂ）ある警報記述子と関連付けられた呼を受信し、必要な警報記述子が被呼側端末のローカルメモリにあることがわかった場合、その警報記述子をローカルキャッシュ・メモリから検索し、呼を通知するために用いる。
【００８８】
このように、被呼側端末は、警報記述子の少なくとも一部が今後使用できることを期待して、警報記述子を継続的に収集し格納することができる。この点について、通信端末が有するメモリの警報記述子の格納に使用可能な量は有限であるので、警報記述子をキャッシュする通信端末（この機構は、限定ではないが、「次回使用」モードを利用するシステムにおける通信端末に含まれる）は、頻度の高い発呼者の警報記述子を保持することができ、希な発呼者または一見の発呼者の警報記述子を最終的に破棄することができる方式を実施することができる。警報記述子の明示、インデックス化および管理を行うために適した方式であれば、いずれでも用いることができ、例えば、ＨＴＴＰおよびワールド・ワイド・ウェブと共通して関連するキャッシング・システムがある。
【００８９】
本発明は、ユーザに、その好ましい警報（複数の警報）を、好ましくはいつの時点でも修正または変更する機能を提供するので、通信端末が今後のために保持する警報記述子は陳腐化する可能性がある。この点について、キャッシュ機能を利用する本発明の好適な実施形態では、キャッシュした警報記述子を更新することができる。本発明において有用な適した方式の一例では、通信端末が、警報記述子に関連付けられた呼を受信する毎に、警報記述子を検索し、次回前記警報記述子を要求する呼を受信した場合に用いるために、この警報記述子を格納する。このような構成は、関連付けられた前記警報記述子の検索ができたならば、キャッシュした警報記述子が、２回の呼の間の期間以上は決して古くなり得ないことを保証することができる（後続の呼の事実に先立つ未知の時間期間）。
【００９０】
「次回使用」モードを実施する本発明のシステムは、ラベル付警報記述子(labelled alert descriptor)を利用することもできる。広義に言えば、広い範囲でスキーマ(schema)を明示することにより、多数のシステム・ユーザが所与のラベルを付した警報記述子を選択する尤度が高まるので、「次回使用」モードを一層効率的に実施できるようになる。尚、ここで、「範囲」という用語は、所与の識別子の集合を有効とし認識するネットワーク・システムまたはドメインの数を意味することは理解されよう。
【００９１】
本発明のシステムにおいて、警報記述子の前に警報記述子ラベルを被呼側端末に送るように、被呼側端末に警報記述子を配信するプロトコルを時間的に順序立てれば、一層の効率化が可能となる。この点について、被呼側端末がラベル付き警報記述子をキャッシュしていれば、既に所与のラベル付き警報記述子をキャッシュ内に有するか否か素早く判断し、有するのであればその警報記述子のコピーを利用することができるので、前記警報記述子の第２コピーを得るのに伴う遅延を未然に防げることがわかる。
【００９２】
本発明のシステム内部における「次回使用」モードの存在、または特定の機能性は、ユーザまたはシステムの操作者によって、あるいは自動化した情報処理システムによって実現可能な何らかのロジックによって、制御または変更することができても、できなくてもよい。例えば、本発明のシステムは、通常は「次回使用」モードを実施するが、カスタム化した警報記述子が時間的に都合良く得ることができるのであれば、これを、その検索と同時に、呼のために用いることができるという例外条件を付加することもできる。もっとも、このようなことはそう頻繁には起こらない。
【００９３】
過剰なネットワークのレイテンシのために生ずる虞れがある実際上の難点を克服する手段について説明し終えたので、これより本発明のその他の機能について説明する。
基盤となるネットワークの機能によって、カスタム化警報システムに強いられ得る制約を解消するために、本発明の一実施形態では、ここでは「帯域内警報ダイアログ・トランスポート」と呼ぶ実施モードを設ける。これは、警報を関連付ける呼に対応する音声回路を用いて、警報ダイアログの輸送を可能にする。尚、「帯域内警報ダイアログ・トランスポート」は、カスタム化警報システムを、ＧＳＭのような第２世代の回路切替移動ネットワークと共に実施する場合、特に有効であり得ることがわかる。
【００９４】
「帯域内警報ダイアログ・トランスポート」を実施する本発明のシステムでは、呼に関連付けられる警報記述子ダイアログの一部または全体を、音声通信チャネルによって「帯域内」において輸送する。この音声通信チャネルは、呼の間発呼側端末と被呼側端末との間に存在する。好適な実現例では、音声会話における休止中に、警報記述子ダイアログの一部または全体が発生し、この休止は、何らかの適当な手段によって自動的に検出される。あるいは、代わりにまたは加えて、警報記述子ダイアログは、音声会話が完結した（発呼側または被呼側のいずれかがその電話機上の「通話終了」ボタンを押下することによって示される）後に開始し、発呼側と被呼側との間の音声チャネルの解放は、警報記述子ダイアログが完結または放棄できるまで、一時的に延期する。
【００９５】
「帯域内警報ダイアログ・トランスポート」の代替実現例では、警報記述子ダイアログの一部または全体を、音声通信チャネルを用いて、音声品質を許容可能な量だけ低下させるように警報記述子ダイアログを音声会話のディジタル表現と交互に送るによって、「呼内」で輸送することもできる。この技法も、最初に述べた技法と組み合わせると効果的であると言える。
【００９６】
「帯域内警報ダイアログ・トランスポート」は、発呼側端末と被呼側端末との間で行われ、呼に関与するネットワークには透過的とすることができる。あるいは、「帯域内警報ダイアログ・トランスポート」は、被呼側端末と、発呼側端末と被呼側端末との間の音声回路上で、ディジタル情報の注入が可能な何らかの他の地点との間、例えば、ＰＬＭＮの状況では、被呼側端末と、被呼側端末を連携させるＭＳＣとの間で行うこともできる。
【００９７】
尚、前述の帯域内技法を用いると、警報記述子の利用可能性に関する情報、および／または警報記述子の名称または番号または識別子、および／または警報記述子、および／またはカスタム化警報システムにおいて用いることができるその他のあらゆる情報でも輸送可能であることは理解されよう。
【００９８】
「帯域内警報ダイアログ・トランスポート」は、本発明のシステムにおいて被呼側端末が警報記述子をキャッシュする場合には、特に有効であることがわかる。このような場合には、前述の「次回使用」モードが含まれるが、これに限定されるのではない。
【００９９】
更に、「帯域内警報ダイアログ・トランスポート」は、ＧＳＭのような第２世代回線交換移動ネットワークにおいてカスタム化警報システムを実施する場合特に有効であり得ることもわかる。
【０１００】
以上基盤となるネットワークの機能によってカスタム化警報システムに強いられ得る制約を解消する手段について説明し終えたので、これより本発明のその他の機能について説明する。
【０１０１】
キャッシュ機能を実装した本発明のシステムでは、ここでは「カスケード・キャッシング」(cascade caching)と呼ぶ本発明の一実施形態を用いると、カスタム化警報システムの効率、およびユーザが知覚する有用性を更に最適化することが可能となる。
【０１０２】
「カスケード・キャッシング」を実施する本発明のシステムでは、一部または全ての被呼側端末、および一部または全ての警報サーバ、および１つ以上のキャッシング・サーバが、分散警報記述子キャッシング方式に関与することによって、このようなキャッシング方式がない場合よりも、所与の警報記述子を、ダウンロード時間に関して発生源から一層近く発生することができる平均的な尤度を高める。この点について、適当なキャッシング・アーキテクチャ、方式、システムまたはプロトコルであればいずれを用いても、「カスケード・キャッシング」を実施することができ、既存の分散キャッシング・アーキテクチャ、方式、システムまたはプロトコル（例えば、ＲＦＣ３０４０を含むＩＥＴＦ  ＲＦＣ、またはカリフォルニア大学サンディエゴ校の「Ｓｑｕｉｄ」キャッシング・システムに基づくもの）の改造を含む。
【０１０３】
本発明の好適な実現例では、キャッシングは階層状であり、被呼側端末には透過的である。
本発明の好適な実現例では、「カスケード・キャッシング」は多数のカスタム化警報サービスにわたって用いられる。これによって、関与するカスタム化警報サービス・プロバイダおよびそのユーザ双方に、性能の向上およびローミング(roaming)の有効性が得られることがわかる。
【０１０４】
本発明の好適な実現例では、「カスケード・キャッシング」は多数のカスタム化警報サービスにわたって用いられ、共通の警報記述子明示スキーマが、共有される「カスケード・キャッシング」システム全体で用いられる（しかし、必ずしもこれに限られる訳ではない）。尚、これによって、関与するカスタム化警報サービス・プロバイダおよびそのユーザ双方に、性能の向上およびローミングの有効性が得られることがわかる。
【０１０５】
本発明の特定的な実現例では、「カスケード・キャッシング」は多数のカスタム化警報サービスにわたって用いられ、共通の警報記述子明示スキーマが、共有される「カスケード・キャッシング」システム内部で用いられ（しかし、必ずしもこれに限られる訳ではない）、共通の警報記述子ダイアログ・プロトコルおよびデータ・フォーマットが、関与するカスタム化警報システム内部およびそれらの間で用いられる（しかし、必ずしもこれに限られる訳ではない）。尚、これによって、関与するカスタム化警報サービス・プロバイダおよびそのユーザ双方に、性能の向上およびローミングの有効性が得られることがわかる。
【０１０６】
以上「カスケード・キャッシング」を用いることによってカスタム化警報システムの効率、およびユーザが知覚する有用性を最適化する手段について説明し終えたので、これより本発明のその他の機能について説明する。
【０１０７】
「早期警報記述子フェッチ」を実施する本発明のシステムでは、呼設定中に警報記述子を実際上できるだけ早くフェッチすることによって、カスタム化警報システムの性能および機能性を向上させる。
【０１０８】
「早期警報記述子フェッチ」を実施する本発明のシステムでは、ＰＳＴＮまたはＰＬＭＮ系カスタム化警報システムにおいては、被呼側端末が現在連携されている（または「誘導されている」）交換機と関連する処理ロジックは、被呼側端末またはサービス識別子および発呼側端末またはサービス識別子が呼設定プロセス中に前記交換機（と関連する電話呼処理ロジック）に一意に特定された後実際上できるだけ早く、呼と共に用いる警報記述子（複数の記述子）をフェッチするプロセスを開始する。
【０１０９】
「早期警報記述子フェッチ」の密接に関係する代替実現例では、ＰＳＴＮまたはＰＬＭＮ系カスタム化警報システムにおいては、発呼側端末が現在連携されている（または「誘導されている」）交換機と関連する処理ロジックは、被呼側端末またはサービス識別子および発呼側端末またはサービス識別子が呼設定プロセス中に前記交換機（と関連する電話呼処理ロジック）に一意に特定された後実際上できるだけ早く、呼と共に用いる警報記述子（複数の記述子）をフェッチするプロセスを開始する。
【０１１０】
本発明のシステムをＩＴＵ−Ｔインテリジェント・ネットワーク系電話ネットワークにおいて実施した一例によって「早期警報記述子フェッチ」を例示すると、発呼側端末が現在連携されている（または「誘導されている」）交換機のＳＳＰと関連する処理ロジックが、被呼側端末が現在連携されている（または「誘導されている」）交換機のＳＳＰ（サービス切替地点）と関連する処理ロジックに、ＳＳ７  ＴＵＰ（電話ユーザ部）またはＩＳＵＰ（ＩＳＤＮユーザ部）を用いて呼設定要求を伝達する。被呼側端末が現在連携されている（または「誘導されている」）交換機のＳＳＰが、被呼側端末および発呼側端末を一意に特定するに足る十分な情報を受信したなら、その後直ちに、または実際上できるだけ早くメッセージをカスタム化警報管理システムに送り、呼と共に用いるための警報記述子あるいは警報記述子名、ラベル、または識別子を要求する。更に、カスタム化警報管理システムは、恐らくは関連するＳＤＰ（サービス・データ地点）と共に、インテリジェント・ネットワークＳＣＰ（サービス制御地点）として実施することができれば有利であり、ＳＳＰとＳＣＰ／ＳＤＰ系カスタム化警報管理システムとの間のメッセージは、ＩＮＡＰ（インテリジェント・ネットワーク・ユーザ部）プロトコルまたはＴＣＡＰ（トランザクション機能ユーザ部）プロトコルのような該当するインテリジェント・ネットワーク・プロトコルによって輸送される。
【０１１１】
以上「早期警報記述子フェッチ」について説明し終えたので、これより本発明のその他の機能について説明する。
本発明の特定的な実施形態では、カスタム化警報システムのユーザは、彼らが受信したい様々な種類のカスタム化警報の制御を行うことができる。この点について、少なくとも、関与する端末はカスタム化警報の特徴をいつの時点でも動的にイネーブルまたはディゼーブルできることが好ましい。本発明の密接に関係する第２の特定的な実施形態では、カスタム化警報システムの操作者は、警報を、その内容の形態およびタグ警報記述子によって分類することができ、これに応じて、関与する端末は、警報記述子の分類の知識に基づいて検出し、恐らくは、動作することができる。一例として、カスタム化警報システムの操作者は、そのユーザに、選択のために、多数の「分類１」の警報、多数の「分類２」の警報、および多数の「分類３」の警報を展開フェーズ中に提示することができる。「分類１」は、操作者が、いずれの状況においてもいずれの受信者にも不快感を与える虞れがないと見なした警報を含み、例えば、汽車の警笛があげられる。「分類２」は、操作者が、殆どの状況下において、不快感を与えないと見なした警報を含み、例えば、ターザンのジャングルにおける雄叫びがあげられる。「分類３」は、「分類１」および「分類２」のいずれにも相応しくない警報を含み、例えば、人の放屁音や下劣な画像があげられる。この点について、ユーザは、彼または彼女が用いる端末の環境設定を変更し、「分類１」の警報を常に受け入れるようにしたり、仕事時間以外でのみ、そしてある規定した近傍以内にいない場合に「分類２」の警報を受け入れ、「分類３」の警報を決して受け入れないようにすることができる。この例では、操作者がユーザにカスタム化警報記述子をアップロードさせる場合、このようにしてアップロードされた警報は常に自動的に「分類３」に指定するようにするとよい。
【０１１２】
本発明の関係する第３の好適な実施形態では、関与する端末の環境設定を動的に変更し、一部の時間または常時、カスタム化警報記述子の全てではなく一部の態様または成分に応じて動作するようにすることができる。この点について、関与する端末の操作者は、一連のキー入力またはメニュー選択またはその他の何らかの手段によって、端末が当面の間または不定期にカスタム化警報記述子の可聴成分に応じて動作せず、視覚成分のような、その他の警報記述子の態様または成分に応じて動作し続けるように指示することができる。尚、この機構は、関与する端末の操作者が、彼または彼女の通信端末をその警報によって特定できることを常に望んでいる場合も、またはある時間期間だけ望んでいる場合でも有効であることは認められよう。（例えば、可変警報機構が付いた通信端末を有する人が他にも多数いる場所にいるような場合、ある人は彼または彼女自身の電話機を特定する機能に、その警報によって、発呼側が判定する警報を受信する機能よりも高い値を設定することができる。しかしながら、その相対値による知覚は、一旦その場所を離れたなら、変更することもできる。）本発明の第４の実施形態と意図および効果において密接に関係する本発明の第４の好適な実施形態では、関与する端末は、既定のまたはユーザが構成変更可能な、被呼側端末のデフォルトまたはユーザが選択した警報、およびカスタム化警報を利用可能な呼に対するカスタム化警報の混合組み合わせを用いる。更に、これは、関与する端末の操作者が制御可能な、動的に構成変更可能な選択肢であることが好ましいが、必ずしもそうでなくてもよい。この点について、可能な一実現例では、関与する端末は、デフォルトのまたは端末ユーザが選択した警報を用いてある時間期間通報し始め、次いで警報通知期間だけカスタム化警報に変更することができる。尚、この実施形態では、被呼側端末の操作者に、彼ら自身の選択で擬似的に一意の警報を有するようにしたことによって得られる効果（「通報」している間彼ら自身の電話機を特定することができる機能等）や、発呼側の好みの警報を受け入れることによって得られる効果（これらが与える追加情報および娯楽値等）をもたらすことが認められよう。
【０１１３】
尚、本発明は、多数の異なる警報記述子の選択および転送機構を備え、これらは、本発明の方法を用いるシステムによって、警報記述子を通信端末に分配するために用いることができることは認められよう。
【０１１４】
尚、本発明は、移動電気通信分野に特に適用されると考えられる。
カスタム化警報サービス・システムの操作者またはサービス・プロバイダの役割は、電話サービス・プロバイダ（「電気通信事業者」、「電話会社」）のそれと有利に組み合わせることであると考えられる。この点について、カスタム化警報システムを既存のネットワークおよびサービス・インフラストラクチャおよびシステム、ならびにインテリジェント・ネットワーク、システム、シグナリング・システム、サービス管理システム、加入者管理システム、請求書発行システム、およびディレクトリ・システムのような運用支援システム上に位置付けることによって、コストおよび運用上の相乗効果および効率が得られるという効果がある。更に、この点について、カスタム化警報サービスは、電話サービス・プロバイダの既存のサービス・ポートフォリオと一体化すれば、既存のサービスのサービス・プロバイダおよび顧客双方に恩恵をもたらすことができるという利点がある。
【０１１５】
更に、カスタム化警報システムの操作者またはサービス・プロバイダの役割は、業務用ディレクトリ、即ち、「イエロー・ページ」ディレクトリ・サービスと有利に組み合わせることであると考えられる。この点について、カスタム化警報サービスを用いると、業務用ディレクトリ即ちイエロー・ページ・サービスの広告モデルを拡大し、広告または販売メッセージを伝えるカスタム化警報の使用によって、電話呼、特に、アウトバウンド・ビジネス電話呼を設定する時点における広告も遂行することができ、更に、この点について、カスタム化警報システムを既存のディレクトリ・システムおよびデータベースと一体化することによって、機能性、コストおよび運用上の効率を得ることもできる。
【０１１６】
推察できるだろうが、カスタム化警報システムの操作者またはサービス・プロバイダの役割は、電話サービス・プロバイダ（「電気通信事業者」、「電話会社」）でもあるビジネス・ディレクトリ・サービス・プロバイダの場合、所与の地理的領域について特別な利点に結合する。
【０１１７】
これより、本発明の形態例を示す添付図面を参照しながら、本発明について更に詳しく説明する。尚、これらの図面の特定性は、前述の本発明の汎用性を損なうものではないことは理解されよう。
本発明の好適な実施形態の説明
本発明の方法およびシステムについて、好適な実施形態に関連付けてこれより説明する。したがって、以下の説明は本発明の汎用性を限定する訳ではないことは認められよう。
【０１１８】
本発明の好適な実施形態は、本発明の方法およびシステムにおいて用いて、カスタム化警報システムのユーザまたは加入者にカスタム化警報サービスを提供することができる、カスタム化警報システムの使用について説明する。
【０１１９】
図１を参照すると、先に説明した「被呼端警報フェッチ」発呼サブプロセスの変形を利用した、本発明の好適な構成が示されている。
本発明の方法を用いたシステムでは、ユーザ１０が、インターネット接続デバイス１２、即ち、通信端末１４を用いてカスタム化警報サービスを作成し、カスタム化警報管理システム１６と双方向処理を行う。好ましくは、カスタム化警報サービスの作成では、ユーザ１０がユーザ識別情報を入力し、通信サービスまたはサービスを適用する端末を指定することを伴う。好ましくは、入力した識別情報は、カスタム化警報管理システム１６が用いて、後にユーザが彼らのカスタム化警報サービスにアクセスしたい場合や、恐らくは変更したい場合に、ユーザ１０の識別情報の有効性を判断する。
【０１２０】
カスタム化警報サービスの作成に続いて、ユーザ１０は、警報記述子または複数の警報記述子を選ぶおよび／または設けることによって、彼らのカスタム化警報サービスを構成することができる。警報記述子は、関与する通信端末に対して行う発呼を通知するために優先的に用いられる。警報記述子（複数の記述子）を選ぶおよび／または設けるプロセスは、カスタム化警報管理システム１６がユーザに提示した警報記述子群から警報記述子（複数の警報記述子）を選択することを含めばよい。あるいは、選択プロセスは、カスタム化警報管理システムとは無関係なインターネット・ウェブ・サイトからの警報記述子の選択、およびそれに続く、選択した警報記述子（複数の記述子）のユーザのカスタム化警報サービスへの「アップロード」を含んでもよい。
【０１２１】
ユーザ１０は、彼らのカスタム化警報サービスを構成するプロセスにおいて、補助情報を、規則、好み、条件または命令の形態で選ぶおよび／または設けることもでき、これらは、いつおよび／またはどのようにして、選択した警報記述子を用いて、ユーザからの呼、または指定した通信サービス（複数のサービス）からの呼を通知すればよいかを規定するために用いることが好ましい。
【０１２２】
選択した警報記述子、および付随する補助情報を、カスタム化警報管理システム１６と連携する警報サーバ１８に格納する。この点において、カスタム化警報管理システム１６は、選択した警報記述子と対応する補助情報との間に十分な関連性を持たせることにより、カスタム化警報管理システム１６が、とりわけそして特に、通信端末へのカスタム化警報の分配を含む、必要な将来機能を実行することができるようにする。好ましくは、必要な情報は、相応のデータベースまたは複数のデータベースに格納する。
【０１２３】
警報サーバ１８およびユーザの通信端末１４は、存在する場合でも、物理的に別個な実体である必要はない。実際、通信端末１４は、警報サーバ１８の機能性を組み込むこともでき、その場合、通信端末１４および警報サーバ１８は同じ物理的デバイスとすることができる。
【０１２４】
警報記述子または複数の警報記述子の選択に続いて、ユーザ１０は、カスタム化警報サービスを利用することができる。ユーザ１０は、通信端末１４または相応の電気通信機能（例えば、インターネット・プロトコル上の音声）を有するインターネット接続デバイス１２を用いて、被呼側２０の通信端末２２に対して発呼を行う。
【０１２５】
呼設定要求の検出に応答して、通信ネットワーク３１と関連する処理ロジックは、端末−ネットワーク信号２６から識別情報を抽出することが好ましい。理想的には、抽出した識別情報は、ユーザ１０、または通信端末１４、または通信サービス、あるいはこれらの内の２つ以上を識別する。
【０１２６】
通信ネットワーク３１と関連する処理ロジックは、次に、カスタム化警報管理システム１６と双方向処理を行い、抽出した識別情報をカスタム化警報管理システム１６に提供することが好ましい。好適な実現例では、カスタム化警報サービスと連携する端末またはサービスは、通信ネットワーク３１と関連する処理ロジック３１内部において「フラグ」によってそのように識別され、通信ネットワーク３１と関連する処理ロジックは、カスタム化警報管理システムに、全ての切迫した呼ではなく、切迫した呼の内カスタム化警報サービスと関連することがわかっているものについてのみ通報する。この点について、「フラグ」は、カスタム化警報管理システムと、通信ネットワーク３１と関連する処理ロジックとの間におけるダイアログによって設定または再設定することが好ましく、これは新たなカスタム化警報サービスを設定または修正する時点またはその付近において行われる。
【０１２７】
カスタム化警報管理システム１６が、特定した実体に対するカスタム化警報サービスを突き止めることができない場合、通信ネットワーク２４は、通常の設定プロセスを用いて呼を確立する。
【０１２８】
しかしながら、識別した実体がカスタム化警報サービスと関連がある場合、カスタム化警報管理システム１６は続いて、識別したカスタム化警報サービスに伴う補助情報があれば、その全てを傍受し、恐らく１つ以上の警報記述子を含む、カスタム化警報サービスに対するカスタム化警報サービス情報を、１つ以上の警報サーバ１８から検索する。カスタム化警報管理システム１６は、次に、検索した情報を、通信ネットワーク３２と関連する処理ロジックに提供する。
【０１２９】
検索した情報の一部または全部は、個々の実現例に応じて、潜在的にカスタム化警報記述子（複数の記述子）を含み、次に通信経路２７を通じて被呼側端末２２に転送される。好ましくは、検索した情報は、通信ネットワーク２４と被呼側端末２２との間の呼設定シグナリング・ダイアログと同時に、そしてその一体部分としてまたはその拡張部として、被呼側端末２２に送信される。ダイアログは、これがカスタム化警報とは関連のない呼であっても発生している。
【０１３０】
このようにカスタム化警報管理システム１６によって検索され、このように通信ネットワーク２４（と関連する処理ロジック）に提供され、次いで被呼側端末２２に提供される情報の範囲は、個々のカスタム化警報システムの設計目的に応じて、システム毎に異ならせることができる。
【０１３１】
警報処理が主に被呼側端末の制御下で行われることが望ましいようなカスタム化警報システム設計の一例では、被呼側端末２２には、呼または発呼側ユーザ１０、または発呼側端末１４、または発呼側サービスがカスタム化警報と関連があることだけを通知すればよい。その後、警報処理は被呼側端末２２の担当となり、後に述べるプロセスを用いる。
【０１３２】
別の例において、警報処理が主に通信ネットワーク３１、３２と関連する処理ロジックによって制御することが望ましいカスタム化警報システムの設計では、このように検索されこのように受け渡された情報は、実際には、呼のために用いられるカスタム化警報を組み込むことができる。任意に、検索され受け渡された情報は、いつおよび／またはどのように警報または複数の警報を被呼側端末２２が用いればよいかについて記述する補助情報の一部または全部のような追加情報を含むこともできる。
【０１３３】
更に別の例において、中間のまたは代わりの目的を有するカスタム化警報システムの設計では、カスタム化警報管理システム１６によってそのように検索され、被呼側端末２２にそのように受け渡された情報は、被呼側端末２２が警報処理を実行する際に補助する情報を含むこともできる。例えば、検索した情報は、擬似的に一意の１つまたは複数のラベル、あるいはその他の形態の識別子を含むことができ、これは、被呼側端末２２が、前記呼または発呼側ユーザ１０または発呼側端末１４または発呼側サービスと共に用いるべき正しい１つまたは複数の警報記述子を特定する際に補助することができる。代わりに、検索した情報は、警報サービス１８、あるいは呼または発呼側ユーザ１０または発呼側端末１４または発呼側サービスと共に用いるべき正しい１つまたは複数の警報記述子を提供することができる警報サーバを突き止める際に、被呼側端末２２をイネーブル、または補助するようなものとすることもできる。
【０１３４】
検索した情報が警報記述子（複数の記述子）を含む場合、通信ネットワークは、この警報記述子を、通信ネットワーク２４と被呼側端末２２との間で行われる呼設定プロセスと同時に、通信ネットワーク２４と被呼側端末２２との間のシグナリング・インターフェースを通じて、被呼側端末２２に供給することができる。
【０１３５】
カスタム化警報管理システム１６から被呼側端末２２に通信ネットワーク２４を通じて提供される情報が、ネットワーク名（複数のネットワーク名）または示唆された警報サーバ（複数のサーバ）のアドレス（複数のアドレス）、そして恐らくは、警報サーバ１８がこの着信呼に適した警報記述子を特定し供給することを可能にする情報も収容している場合、被呼側端末２２は、特定した１つまたは複数の警報サーバ１８との通信を確立しようとしてもよい。この設計のシステムの好ましい実現例では、被呼側端末２２と警報サーバ（複数のサーバ）１８との間の通信は、インターネットまたはＩＰ系ネットワークまたはパケット・ネットワークまたは相互ネットワークを通じて行うことができる。警報サーバ１８との通信の確立に続いて、被呼側端末２２は、警報サーバ１８が適切な警報記述子（複数の記述子）を被呼側端末２２に提供することを要求することが好ましい。この点について、被呼側端末２２によって警報サーバ１８に提供された情報が、警報サーバ１８が警報記述子を特定するのを補助または可能にする情報を含む場合、このような情報は、カスタム化警報管理システム１６から発信した情報に制限しなくてもよい。実際、このような情報は、被呼側端末２２によって供給される、被呼側２０または被呼側端末２２の識別に関する追加情報を含むこともある。
【０１３６】
警報サーバ１８は、警報検索要求に応答して、、このユーザ１０に関連する１つの利用可能な警報記述子を所有しているのであれば、これを提供する。
あるいは、警報サーバ１８は、警報記述子検索要求の受信時に、カスタム化警報サービス設定プロセスの間に発呼側ユーザ１０が提供した補助情報に基づいて追加のロジックを適用し、このユーザ１０のカスタム化警報サービスに関連する最も適切な警報記述子を選択し、被呼側端末２２に転送する。
【０１３７】
警報サーバ１８から被呼側端末２２への警報記述子の転送は、ＦＴＰまたはＴＦＴＰのようなファイル転送プロセスによって、あるいはＧＳＭ  ＳＭＳ（ショートメッセージ・サービス）またはＧＳＭ  ＵＳＳＤ（非構造化補足サービス・データ）ベアラによって、あるいはその他の適したプロセスまたはプロトコルによって遂行することができる。
【０１３８】
本発明の代替実施形態では、警報サーバ１８は物理的に発呼側端末１４内に組み込まれており、したがって警報ダイアログおよび検索プロセスは、好ましくは透過的な端末間シグナリング、あるいはＧＳＭ  ＳＭＳまたはＵＳＳＤ、あるいは前述の「インバウンド」技法のいずれか１つによる被呼側端末２２と発呼側端末１２との間通信によって遂行することができる。この状況では、警報記述子情報は、発呼側端末によって提供され、介在する通信ネットワーク（複数のネットワーク）２４は、発呼動作において、カスタム化警報システムの情報トランザクションの存在を知らずに、単純なリレーとして関与する。
【０１３９】
本発明の好適な実施形態では、被呼側端末２２が、必要な警報記述子がローカルに（即ち、被呼側端末２２のローカルメモリ内）存在すると判断した場合、警報記述子の検索を不要とすることができる。これは、同じ警報記述子を用いた以前の呼または呼の試行に伴う警報記述子のフェッチの結果として、必要な警報記述子がキャッシュされたためと考えられる。あるいは、製造または販売の時点、あるいは他のいずれかの時点において被呼側端末２２に、必要な警報記述子が予めロードされたためということもあり得る。
【０１４０】
警報記述子の検索が要求され、理由は何であれ、現行の着信呼と共に実際に用いることができるようにするための十分に短い時間期間内に被呼側端末２２が警報記述子を受信することができなかった場合、被呼側端末２２は警報記述子の検索を放棄することができる。このような場合、被呼側端末２２は、何らかのデフォルトの警報またはローカルで決定した警報を用いて、現行の着信呼を通知すればよい。
【０１４１】
本発明の好適な実施形態では、前述した状況において、警報記述子（複数の記述子）を適時に取得できなかった場合、警報記述子検索プロセスを継続して完了させることが好ましく、最終的に遂行できた場合、検索した警報記述子（複数の記述子）ならびに補助情報（存在する場合）および識別子（存在する場合）は、発呼側ユーザ１０、端末１４またはサービスと関連付けられ、被呼側端末２２によって、好ましくは、相応しいキャッシング・システムによってローカルに格納され、その後この発呼側ユーザ１０、または発呼側端末１４、または発呼側サービスから今後発呼された場合に、この呼のために用いることが好ましい。更に、この点について、被呼側端末２２が、先に説明したように、ローカルで決定した警報を用いて呼を通知している間に、警報記述子検索プロセスが完了した場合、被呼側端末２２は、デフォルトの警報即ちローカルで決定した警報の使用を中止し、そのように検索された警報記述子によって記述されるカスタム化警報を用い始めることができる。
【０１４２】
被呼側２２端末が使用中（「通話中」）であるという状況でも、それにも拘わらず警報記述子検索プロセスを実行することが好ましく、最終的に遂行できた場合、検索した警報記述子（複数の記述子）ならびに補助情報（存在する場合）および識別子（存在する場合）は、発呼側ユーザ１０、端末１４またはサービスと関連付けられ、被呼側端末２２によって、好ましくは、相応しいキャッシング・システムによってローカルに格納され、その後この発呼側ユーザ１０、または発呼側端末１４、または発呼側サービスから今後発呼された場合に、この呼のために用いることが好ましい。これは、発呼し損ねた発呼側は多くの場合後の時点で再度発呼しようとするからである。
【０１４３】
理解を容易にするために、図１は、発呼側端末１４および被呼側端末２２双方を、単一の通信ネットワークと連携するように示している。しかしながら、本発明は、発呼側端末１４および被呼側端末２２が各々、別個の通信ネットワークと連携するという状況にも対応することは理解されよう。この場合、いずれかの数の追加の仲介通信ネットワークがあることもあり得る。更に注記すべきは、発呼側端末１４および被呼側端末２２が各々別個の通信端末と連携される場合、これらは、機能形式、地理的位置および範囲、所有権または技術が異なる場合もあるということである。この点について、唯一の要件は、発呼側端末１４と被呼側端末２２との間におよぶネットワーク全体が、２つの端末間で有意義な二端間通信セッションに対応可能であることである。一例として、発呼側端末１０は、チリにおいてＰＳＴＮ運用者に随伴するＰＯＴＳ端末とすることができ、一方被呼側端末２２は、英国においてワイヤレス・ネットワーク運用者に随伴するＧＰＲＳ／ＧＳＭ  ＷＡＰ移動電話機とすることもできる。
【０１４４】
これより図２を参照すると、先に説明した「被呼端警報フェッチ」発呼サブプロセスの第２の変形を利用した本発明の第２実施形態が示されている。本発明の第２実施形態によれば、ユーザ１０は、本発明の好適な実施形態について説明したのと同じ方法を用いて、警報記述子を選択し、呼を発呼側に通知する。
【０１４５】
しかしながら、本発明の第２実施形態によれば、関与する通信端末に警報記述子を分配する方法を提供し、この場合、呼に関連する通信ネットワーク（複数のネットワーク）が、カスタム化警報システムにおいてアクティブな関与構成である必要はない。
【０１４６】
この方法によれば、被呼側端末２２は、ＣＬＩＤおよび／またはその他の適した識別情報が利用可能な着信呼はいずれも、警報記述子と関連付けることができると想定する。このような呼の場合、呼設定プロセスの間に、ＣＬＩＤおよび／またはその他の適した識別情報の受信後実際上可能な限り早く、被呼側端末２２はＣＬＩＤおよび／またはその他の識別情報を、発呼側端末１４または被呼側端末２２と同じカスタム化警報システムに属する警報サーバ１８または複数のサーバに受け渡す。
【０１４７】
ＣＬＩＤおよび／またはその他の識別情報の受信時に、警報サーバは、それがＣＬＩＤおよび／またはその他の識別情報と関連付けられた１つまたは複数の警報記述子を所有することを察知すると、該当する１つまたは複数の警報記述子を、実際上可能な限り早く被呼側端末２２に戻す。
【０１４８】
したがって、この状況では、被呼側端末２２は、通信ネットワーク２４が供給するＣＬＩＤに基づいて、警報記述子を検索することができる。
更に、本発明のこの実施形態の変更例では、明示的ではなく暗示的に示すが、カスタム化警報管理システムの機能性１６および警報サーバの機能性１８は、論理的および物理的に通信端末１４、２２内に一体化されているので、物理的に別離した専用のカスタム化警報管理システム１６や警報サーバ（複数のサーバ）１８は必要でない。したがって、本発明のこの変更例が規定する分散型カスタム化警報システムでは、カスタム化警報システムの機能性は、通信端末全体に最大限分散され、変更していない通信ネットワーク（複数のネットワーク）２４の上に位置付けることができる。
【０１４９】
次に図３を参照すると、先に説明した「発呼端警報提供」発呼サブプロセスを利用した本発明の第３実施形態が示されている。
本発明の第３実施形態によれば、警報記述子を被呼側端末２２に分配する第３の方法を提供する。この場合、発呼側端末１４は、当該発呼側端末１４から発呼するのと同時にまたはその付近で、被呼側端末２２への呼と共に用いる警報記述子（複数の記述子）を提供する。
【０１５０】
この第３の好ましい実現例では、好ましくは、ユーザ１４が、発呼側端末１４内部に１つ以上の警報記述子を格納させ、前記警報記述子をいつおよび／またはどのように用いればよいか判断する際に発呼側端末１４を補助するあらゆる補助情報と共に、発呼側端末１４から他の通信端末に対して行った発呼を通知するために優先的に用いる。
【０１５１】
その後、第３の実現例によれば、発呼側端末１４が発呼する毎に、正しいまたは最良のまたは現在のところ最も適切な警報記述子を被呼側端末２２に転送させる目的で、呼設定と付随して、被呼側端末２２とのダイアログに入ろうとする。
【０１５２】
被呼側端末２２が通信端末であり、被呼側端末２２が警報記述子の提供を受け入れる場合、何らかの適当な手段（例えば、相応しいファイル転送プロトコル）を用いて、発呼側端末１４から被呼側端末２２に警報記述子を転送する。この点について、提供を行うのは、ユーザ１０が、ユーザ１０または被呼側サービスまたは被呼側端末２２を、発呼側端末１４が一意に特定するのに十分な情報を提供した後、実際上可能な限り最も早いことが好ましい（例えば、移動電話の状況では、番号の入力および「通話」ボタンの押下直後）。
【０１５３】
発呼側端末１４は、提供に続いてある適当な期間だけそのローカル・ネットワーク２４への発呼を遅らせれば、被呼側端末２２が警報記述子の存在を知った後に、ローカルで決定した警報を用いて呼に係わる、即ち、実際に呼を通知する確率を最大限高めることができる。あるいは、発呼側端末１４は、被呼側端末２２が警報記述子の提供を受けたという承認を被呼側端末１４から受信するまで、そのローカル・ネットワーク２４への発呼を遅延させることもできる。更に別の代案では、発呼側端末１４は、被呼側端末２２が呼に関連する警報記述子を受信したという承認を被呼側端末２２から受信するまで、そのローカル・ネットワーク２４への発呼を遅らせることもできる。この点について、被呼側端末１４は、呼が警報記述子と関連付けられていると判断したときに、警報記述子の受信が成功するまで、呼設定処理を遅らせることもできる。
【０１５４】
警報記述子転送機構ダイアログは、発呼側端末１４と被呼側端末２２との間で行われ、規格に基づくまたは固有の端末間シグナリング・プロトコルおよび機能、またはＧＳＭ  ＳＭＳ、またはＵＳＳＤ、あるいは先に説明した「インバウンド」技法の１つによって、呼を設定するネットワーク（複数のネットワーク）に関連するプロトコルおよび機能を利用することができる。あるいは、ダイアログは、呼とは関連のない、その他の何らかのネットワークまたは相互ネットワーク（例えば、ＰＳＴＮを通じて発呼することができるが、警報記述子ダイアログは、インターネット３０またはその他の何らかのネットワークまたは相互ネットワークを通じて形成することができる）を通じて、またはそれ以外のその他の何らかの相応の手段によって、形成することができる。
【０１５５】
第３の実現例を特に簡素化した変形では、発呼側端末１４は、被呼側端末２２に、現在発呼側端末１４からの呼に優先的に用いられている単一の警報記述子を供給してもよい。
第３の好適な実現例を更に洗練化した変形では、発呼側端末１４を、カスタム化警報管理システム１６および／または単一のユーザ１０または発呼側サービスまたは発呼側端末１４にサービスを提供する警報サーバ１８を収容するものと見なすこともできる。
【０１５６】
尚、この第３の実施形態には、他にも多くの変形が可能であることは理解されよう。例えば、発呼側端末１４は、被呼側端末２２に、カスタム化警報の利用可能性を通知するが、警報サーバ１８としては動作しないようにすることもできる。この場合、発呼側端末１４は、被呼側端末２２に、該当する警報サーバ１８から警報記述子を検索できるようにするのに十分な情報を提供することができる。
【０１５７】
一旦警報記述子の検索に用いる警報サーバ１８を特定したなら、警報記述子を被呼側端末に転送するプロセスは、本質的に、第１実施形態について先に説明したステップに従う。
【０１５８】
これより図４を参照すると、先に説明した「警報プッシュ」発呼サブプロセスを利用した、本発明の第４実施形態が示されている。
本発明の第４実施形態によれば、ユーザ１０が、本発明の好適な実施形態について説明したのと同じ方法を用いて、発呼側に呼を通知するための警報（警報記述子）を選択する。
【０１５９】
しかしながら、本発明の第４実施形態によれば、警報記述子を通信端末に分配する第４の方法を提供する。この場合、警報記述子の分配は、呼設定ではなく、警報の選択と時間的に関連付けられる。この実施形態では、ユーザ１０によるまたはユーザ１０の代理としての警報選択に続いて、ユーザ１０が直接または暗示的に特定した１つ以上の通信端末に警報記述子を分配する。目標の１つまたは複数の通信端末２２の特定の後、警報サーバ１８として動作する発呼側端末１４によって、またはカスタム化警報管理システム１６によって、または警報サーバ１８によって、あるいはこれらのいずれかの組み合わせによって、分配を開始することができる。分配は、目標の通信端末（複数の端末）の特定に続いて、適した時点であればいつでも行うことができ、先の実施形態とは異なり、時間的に呼設定と関連付ける必要はない。
【０１６０】
この点について、第４実現例が用いる分配プロセスは、自動とすることができ、どの通信端末に警報記述子を提供すればよいかユーザが指示した後の時点において開始する。これに関して、ユーザは、システムの処理ロジックが通信端末のネットワーク・アドレスを特定できるようにするのに十分な情報を提供しさえすればよい。分配プロセスは背景において行うとよく、通信端末が警報の分配に関わっているときに、通信端末の動作に悪影響を与えないという利点がある。あるいは、分配プロセスを手動操作で開始してもよい。例えば、移動電話機の操作者が、移動電話機の住所録をスクロールして行き、何らかの適当な選択プロセスによって、ある警報記述子または複数の警報記述子を、住所録内のある見出しと関連付けられている通信端末に提供するように指示することができる。
【０１６１】
あるいは、ユーザ１０が、警報記述子または複数の警報記述子を、移動電話機の住所録にある各見出しと関連付けられている通信端末に提供するように指示することもできる。そして、分配は、後のいずれの時点にでも行うことができ、前記分配は電話機の通常動作には干渉しないことが好ましい。
【０１６２】
第４実現例を自動化した変形を実施する本発明のシステムでは、ユーザ１０がカスタム化警報を変更させたときに、警報を自動的に再分配させることができる。
更に、第４実施形態を自動化した変形を実施する本発明のシステムでは、適宜警報を自動的に再分配し、目標の被呼側端末が以前に分配された１つまたは複数の警報記述子の１つまたは複数のコピーを失ってしまう可能性を考慮することもできる。
【０１６３】
また、第４実施形態では、目標通信端末２２が、通信端末の操作者に、カスタム化警報の提供を受け入れる、または拒絶する、または理由を付けて拒絶する機会を与えるロジックを組み込み、提供されたときに、手作業でまたは以前にユーザが設定したパラメータの自動解釈によって、理由をユーザに中継することができる。
【０１６４】
本発明は、一方向または双方向通信セッションに対応し、被呼側の通信端末上の制御可能な出力デバイス（複数のデバイス）または変換器（複数の変換器）にエネルギを供給し、被呼側の注意を着信呼要求に向けさせるステップを含む呼設定プロセスを利用する、あらゆる通信システムまたはネットワークに適用することができる。
【０１６５】
これは、例えば、ＰＳＴＮ／ＰＬＭＮ、個人電話ネットワーク、遠隔会議システムおよびネットワーク、ビデオ電話システムおよびネットワーク、テレビ会議システムおよびネットワーク、ならびに「呼」または「通信セッション」の概念を提起する通信ネットワークのその他の現行および将来の形態を含む。
【０１６６】
電話システムは本発明の範囲内に該当し、テレフォニの場合、本発明は、着信呼要求を通知するために電話ハンドセットが用いる警報の形態および特色を離れたところから指定し制御することによって、通話する人に、彼らが発呼している一人または複数の人に彼らの呼を通知する好ましい方法を選択させるようにするシステムおよびプロセスについて記載すると言うことができる。
【０１６７】
ここに記載したカスタム化警報システムは、インターネット・ポータルあるいはYahooまたはYahoo Instant Messenger、AOLまたはAOL Instant MessengerまたはＩＣＱによって代表されるようなインスタント・メッセージング・システムの拡張として実施することや、これと一体化することや、これと有利に相互作用するように構成することもできる。例えば、カスタム化警報システムおよびインスタント・メッセージング・システムは、ユーザ・インターフェース、ユーザ管理システム、ディレクトリ、ユーザ名または「ハンドル」等を共有することができる。
【０１６８】
以上本発明の方法およびシステムの実施形態について多数説明したが、ここに記載した実施形態に対して別の変形や修正も可能であり、これらも本発明の範囲に該当することに代わりないことは認められよう。
【図面の簡単な説明】
【０１６９】
【図１】図１は、本発明の好適な実施形態によるカスタム化警報システムの機能ブロック図である。
【図２】図２は、本発明の第２実施形態によるカスタム化警報システムの機能ブロック図である。
【図３】図３は、本発明の第３実施形態によるカスタム化警報システムの機能ブロック図である。
【図４】図４は、本発明の第４実施形態によるカスタム化警報システムの機能ブロック図である。
【図１】
2008295094.tif 000003
【図２】
2008295094.tif 000004
【図３】
2008295094.tif 000005
【図４】
2008295094.tif 000006
【手続補正書】
【提出日】平成20年9月22日(2008.9.22)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
カスタム化警報サービスに関与するユーザが行う呼を通知するために用いる警報の特色および／または形態を選択する方法であって、
ａ．関与ユーザに対するカスタム化警報サービス構成を確立し、該カスタム化警報サービス構成を１つ以上のネットワーク・アクセス可能デバイスに格納するステップと、
ｂ．前記関与ユーザが、第１通信端末を用いて第２通信端末に発呼し、該呼に第１通信サービスが対応するステップと、
ｃ．前記第２通信端末が、選択した警報記述子を用いて警報を活性化することによって、前記呼を通知するステップと、
を含み、前記関与ユーザに対する前記カスタム化警報サービス構成に応じて、前記警報記述子を選択する、方法。
【外国語明細書】
2008295094000001.pdf