JP2010016857A - 発信側システムにより制御される呼通知システムとその呼通知方法 - Google Patents

Abstract

【課題】受信側システムの呼通知の態様が、発信側システムにより制御可能な呼通知システムを提供する呼通知システムを提供する。
【解決手段】発信側システムからの呼の開始データの受信に応答して、受信側システムにおいて、呼通知を生成するように構成した呼通知システムにおいて、開始データは、受信側システムをトリガするように構成され、発信側システムとの別個のピアツーピア接続を開き、呼通知を生成するために用いられる呼通知データを発信側システムから取得し、これにより、少なくとも呼通知の態様が、発信側システムにより制御可能であり、受信側システムは、発信側システムに対して、呼通知のステータスに関するフィードバックデータを供給するように構成し、フィードバックデータは、受信側システムにより、呼通知データが受信されたか否かに関し、発信側システムに示すように構成したことを特徴とする。
【選択図】図１

Description

本発明は、呼通知のシステムおよび方法に関し、特に、携帯電話、コンピュータベースの通信システムなどにおける呼通知のカスタマイズに適用可能である。

現代の生活においては、通信に関して、多種多様なメカニズムが使用されている。それらのメカニズムのいずれかを用いて行われる通信を、本明細書では、呼と称する。使用されるメカニズムとしては、移動回線および固定回線による標準的な電話呼、一般にボイスオーバーインターネットプロトコル（ＶｏＩＰ）を用いるインターネットまたはネットワークベースの呼、テレビ電話呼、テキストベースやその他によるチャットセッション、単一マシン上のアプリケーションを２人のユーザ（うち１人はリモートマシン上）が制御することが可能なアプリケーション共有セッションなどがある。これらは、ＭＳＮ Ｍｅｓｓｅｎｇｅｒや他の同様なパッケージを使用する動作において見ることができる。

これらのメカニズムはすべて、少なくとも次の３つのフェーズが順に発生する。
開始フェーズ
通信フェーズ
終了フェーズ
開始フェーズおよび終了フェーズは、「通信」と見なされうるデータ伝送を含むが、通信フェーズは、本文書においては、呼が一方のパーティから開始されて他方のパーティで受け入れられてからの、ユーザ間の（一般に同期した）対話を意味するものとする。
終了フェーズは、資源復旧、課金などを含む。このフェーズは、本発明に特には関連しないので、詳しくは説明しない。

開始フェーズは、呼を要求するパーティ（以下、「発信者」と称する）によってトリガされ、少なくとも１つの他方のパーティ（以下、「受信者」と称する）によって受け入れられる。一般には、発信者が自分のシステムに対して呼の開始を要求した後、「ハンドシェーク」と呼ばれるデータ通信を介して、受信者のシステムとの接続が確立される。ハンドシェークは、一般に、発信者および受信者に対して透過的であり、下層通信メカニズムによって処理される。ハンドシェークの間、発信者のシステムと受信者のシステムと、何らかの中間システムが必要であればそのシステムとが、通信フェーズの開始に必要なデータを交換する。コネクション型の通信の場合、ハンドシェーク段階はさらに、通信フェーズ中のデータのサポートおよびルーティングのために、中間システムとの、必要な機能（帯域幅など）のネゴシエーションを含んでもよい。

受信側システムがハンドシェークを受信すると、典型的には、呼が要求されていることを受信者に知らせる、しかるべき通知が与えられる。受信者は、（受話器を取り上げる、ボタンを押す、ユーザインターフェースからのプロンプトを受け入れる、など）その通信システムにふさわしい形式で呼を受け入れる。通知の形式は、一般に、受信側システムと、それまでに適用されたすべてのカスタマイズまたはパーソナライゼーションとの、性質および機能に依存する。たとえば、受信側システムは、呼の受信時に鳴らされる特定の着信音、表示されるアイコン、実行される動作（携帯電話における振動など）、またはこれらの何らかの組み合わせを選択することが可能である。

ＰＳＴＮまたはＩＳＤＮシステム上で行われる、標準的な固定回線の音声呼の開始フェーズは、一般に発呼回線識別子（ＣＬＩ）と呼ばれる（発信側システムの電話番号だけではない情報を含む）呼設定データパケットを受信側システムに送信することを伴う。電話ネットワーク内の交換機は、ＣＬＩの伝送中に、エンドツーエンド接続を確立するように構成されている。呼設定データの形式は、システムによって異なるが、おおむね相互運用可能である。

ＧＳＭ、ＣＤＭＡ、またはＵＭＴＳシステムに基づくような携帯電話ネットワークは、固定回線と同じＣＬＩ形式を使用する。しかしながら、無線接続の確立に必要な技術のゆえに、携帯電話は、固定回線電話より格段に、技術的に高度である傾向がある。携帯電話の１つの使い方は、たとえば、ある発信者からの呼が、別の発信者からの呼と異なる着信音によって通知されるように、受信者が特定の通知タイプを１つまたは複数の発信者のＣＬＩに関連付けることを可能にすることである。

ＶｏＩＰシステムは、実装のされ方が非常に様々であるが、一般的なアプローチにおける開始フェーズでは、発信側システムと受信側システムとが、多くの場合は、標準化されたセッション開始プロトコル（ＳＩＰ）を用いて、ルールセットで定義されたフォーマットの、少量のデータを交換する。

ＩＰ技術により、テキストベースのチャット、テレビ電話、および共用グラフィカル環境の使用が可能である。セッション開始に関しては、これらはすべて、ＶｏＩＰの場合と同様に実装される。

本発明の目的は、受信側システムの呼通知の態様が、発信側システムにより制御可能な呼通知システムを提供することである。

本発明は、上記した目的を達成するために、基本的には、以下に記載されたような技術構成を採用するものである。

即ち、本発明に係わる呼通知システムの態様は、
発信側システムからの呼の開始データの受信に応答して、受信側システムにおいて、呼通知を生成するように構成した呼通知システムにおいて、
前記開始データは、前記受信側システムをトリガするように構成され、前記発信側システムとの別個のピアツーピア接続を開き、前記呼通知を生成するために用いられる呼通知データを前記発信側システムから取得し、
これにより、少なくとも前記呼通知の態様が、前記発信側システムにより制御可能であり、
前記受信側システムは、前記発信側システムに対して、前記呼通知のステータスに関するフィードバックデータを供給するように構成し、
前記フィードバックデータは、前記受信側システムにより、前記呼通知データが受信されたか否かに関し、前記発信側システムに示すように構成したことを特徴とするものである。

又、本発明に係わる呼通知の方法の態様は、
呼通知の生成方法であって、該呼通知の生成方法は、
受信側システムが、発信側システムからの呼の開始データを受信するステップと、
前記受信側システムから前記発信側システムへの別個のピアツーピア接続を開くステップと、
前記発信側システムから呼通知データを取得するステップと、
通信フェーズを確立する前に、呼通知の状態に関するフィードバックデータを前記発信側システムに供給するステップとを含み、前記フィードバックデータは、前記受信側システムにより前記呼通知が受信されたか受信されないかを、前記発信側システムに表示するものであり、更に
前記受信側システムにおいて、受信した呼通知データに基づいて呼通知を生成するステップとを含み、
少なくとも前記呼通知の態様は、前記発信側システムにより予め決められていることを特徴とするものである。

上記したように、本発明の態様によれば、受信側システムにおいて、発信側システムからの呼の開始データの受信に応答して呼通知を生成するように構成された呼通知システムが提供され、呼通知の少なくとも複数の態様が発信側システムによって制御可能である。

発信側システムおよび受信側システムのそれぞれは、
携帯電話、コンピュータで実行されるアプリケーション、ＩＰ電話通信クライアント、固定回線電話、テレビ電話、またはテレビ会議システムのいずれかであってよい。

開始データは、呼通知の生成に用いられる呼通知データを取得するよう、受信側システムをトリガするように構成されることが可能である。
受信側システムは、発信側システムから呼通知データを取得するために、発信側システムとの別個の接続を開くよう構成されることが可能である。

本システムはさらに、発信側システムに関連付けられた呼通知データを保存するよう構成されたリモートリポジトリを含むことが可能であり、受信側システムおよび発信側システムのうちの少なくとも一方が、発信側システムに関連付けられた呼通知データをリモートリポジトリから取得して呼通知データを生成するように構成される。

リモートリポジトリはさらに、発信側システムのユーザからの呼通知データおよび／または選択を受け付け、発信側システムに関連付けられた呼通知データおよび／または選択を保存するよう、動作するユーザインターフェースを含むことが可能である。

発信側システムは、開始された呼ごとのリモートリポジトリに呼通知データを提供するよう構成されることが可能である。
開始データは、呼通知データ、エンコードされた呼通知データ、呼通知データへのリンク、または所定ロケーションに保存された呼データを参照する一意識別子のうちの１つまたは複数を含んでよく、受信側システムは、呼通知データに基づいて呼通知を生成するよう構成される。

呼通知データは、着信音、呼通知データへのリンク、受信側システムにおいて生成されるべき呼通知の定義、画像連絡先データ、受信側システムによって行われるべきアクションに関する指示、データが取得されるべきソースへの参照、呼通知の少なくとも複数の態様を生成する方法に関する指示、または出力前に受信側システムによるエンコード、デコード、変換、またはレンダリングが必要なデータのうちの１つまたは複数を含んでよい。

受信側システムは、呼通知の少なくとも複数の態様をオンデマンドで保存するよう構成されることが可能である。
本発明の別の態様によれば、呼通知を生成する方法が提供され、この方法は、
受信側システムにおいて、発信側システムからの呼の開始データを受信するステップと、
受信側システムにおいて呼通知を生成するステップと、を含み、呼通知の少なくとも複数の態様は、発信側システムによってあらかじめ決められている。

本方法はさらに、受信側システムにおいて、呼通知の生成に用いられる呼通知データを取得するステップを含んでよい。
本方法はさらに、受信側システムから発信側システムへの別個の接続を開いて、発信側システムから呼通知データを取得するステップを含んでよい。

本方法はさらに、呼通知データをリモートリポジトリに保存するステップと、
受信側システムおよび発信側システムのうちの少なくとも一方が、発信側システムに関連付けられた呼通知データをリモートリポジトリから取得するステップと、を含んでよい。

本方法はさらに、開始される呼ごとに、発信側システムからリモートリポジトリに呼通知データを渡すステップを含んでよい。
本方法はさらに、受信側システムにおいて、呼通知の少なくとも複数の態様をオンデマンドで保存するステップを含んでよい。

本発明の実施形態は、ソフトウェア、ファームウェア、ハードウェア、またはこれらの何らかの組み合わせの形で実装されることが可能である。実施形態は、システムにプリインストールおよび／または統合されるか、インストール可能なアドオンとして用意されることが可能である。

本発明のいくつかの実施形態は、通知、および他の、着信情報に関連付けられたデータが、その通信を開始するパーティによってカスタマイズ可能である、通信通知システムを対象とする。

本発明の実施形態を使用すると、忙しいミーティング中に呼を受けた人に、その呼が緊急性のあるものかどうかを伝える付加手段（たとえば、緊急フラグ、着信音、またはマナーモードの無効化）を提供することが可能である。

本発明の実施形態は、ユーザが、ワールドワイドウェブ、携帯電話ネットワーク、または他の任意の通信システムに対するユーザインターフェースを用いて、プロファイルデータを保存および更新することを可能にすることが好ましい。プロファイルデータは、呼通知データとして使用されることが可能であり、
着信音（または着信音へのリンク、または着信音の定義）と、
ユーザに関連付けられた画像と、
ユーザのアドレス／連絡先データと、
受信ハードウェアによって行われるべきアクション（たとえば、ＰＣは、特定のプログラムを実行するよう指示されることが可能である）と、を含んでよい。

たとえば、呼通知データは、
ハンドシェークまたは呼設定データのヘッダまたはボディに付加されるか、その中でエンコードされることと、
ハンドシェーク／呼設定データのヘッダまたはボディの中のリンクを介してアクセス可能であることと、
ハンドシェーク／呼設定データのヘッダまたはボディの中の、互換性のある受信機が用いて呼通知データを取得することが可能な、一意ＩＤに関連付けられることと、が可能である。

受信側システムにおけるユーザアプリケーション（ソフトウェア、ハードウェア、ファームウェア、またはこれらの何らかの組み合わせであってよい）は、通信のタイプに関係なく、供給された、かつ／または取得された呼通知データを解釈し、それを表示するか、実行する。さらに、受信側システムは、さらなるデータを取得するために（たとえば、アドレス情報をグラブ／更新するために）発信側システムまたはリモートデータソースに接続されるよう構成されることが可能である。

通知のスタイルおよび内容は、受信側システムのいかなる事前構成にも依存しないため、発信者（送信者）は、自分の通信を完全に個人化できる。このことには多くの利点があり、たとえば、次のような利点がある。

企業は、呼または電子メールが受信されたときに必ず特定の着信音またはグラフィックが提示されるようにすることで、企業のブランド／スタイルを主張することが可能である。

携帯電話のユーザは、多彩なデータを用いてアドレス帳を更新することが可能であり、任意で更新を自動化しておくことも可能である。
緊急フラグは、携帯電話呼の受信者が、その着信呼に応答することが本当に必要かどうか、あるいは誰かがおしゃべりの相手を求めているだけなのかどうか、などを知ることを可能にすることができる。

携帯電話システム上の通知データは、呼の意図されたトピックの概要を表示することが可能である。
帯域幅の使用にはコストがかかるため、システムは、一般に、開始フェーズでは、呼を確立して通信フェーズを開始するのに絶対に必要なデータ以外のデータを交換しない。この段階でユーザ定義データが送信される可能性は、発信者の識別、または小さなテキスト専用フィールドに限定される。

本発明の実施形態は、発信者が、受信者に渡されるべき呼の通知の属性を定義することを、可能にする。呼の初期設定の間、受信側システムは、データを与えられるか、データを取得するようトリガされ、そのデータと、発信者によって定義された属性とに基づいて、通知を生成する。

定義されることが可能な通知の態様の例として、着信音、個人連絡先情報、写真画像などがある。
本発明の実施形態は、任意の形態のデータが、発信者によって送信され、通信フェーズが開始される前に呼通知の一部として使用されることを可能にする。

簡単にするために、本文書の大部分は２パーティ通信について述べているが、記載された原理および実施例は、マルチパーティ通信にも応用されることが可能であることを理解されたい。

本発明の好ましい実施形態では、開始フェーズの間に呼通知データが取得され、それによって、受信者に対して生成される通知の態様が定義される。開始フェーズ中に受信側システムによって受信されるデータは、発信側システムまたは他の何らかの媒介物から呼通知データを取得することを受信側システムに行わせるトリガであることが可能である。

開始フェーズ中に、受信側システムが呼通知データにアクセスするための第２の通信チャネルが開かれることが可能であり、開始フェーズは、呼通知データが受信されるまで通知を遅延させるために延長される。

これにより、たとえば、着信音を、発信者が提供する音声アラートに置き換えたり、発信者の画像、または呼に特に関係する画像を表示したりするデータを通知に用いることが可能になる。

本発明の実施形態は、呼通知メカニズムの中で重要な通信を実行することを可能にするので、いくつかの実施形態では、呼につながる通知を有しない呼通知を伝達することが可能である。

本発明の好ましい実施形態では、商品またはサービスを広告する方法が、
受信側システムにおいて、発信側システムからの呼の開始データの受信に応答して、呼通知を生成するステップであって、呼通知の少なくとも複数の態様が商品またはサービスを広告する、ステップと、
受信側システムにおいて呼通知が受け入れられた場合に、商品またはサービスの販売代理人からの呼を受信側システムに接続するステップと、を含む。

本発明によれば、上記のように構成したので、受信側システムの呼通知の態様が、発信側システムにより制御可能になった。

本発明の実施形態を組み込んだ通信システムの概略図である。 本発明の実施形態におけるデータの流れを示す図である。 本発明の実施形態を組み込んだ通信システムの概略図である。 本発明の実施形態におけるデータの流れの態様を示す図である。 本発明の実施形態におけるデータの流れの態様を示す図である。 本発明の実施形態におけるデータの流れの態様を示す図である。 本発明の実施形態におけるデータの流れの態様を示す図である。 本発明の実施形態におけるデータの流れの態様を示す図である。 本発明の実施形態におけるデータの流れの態様を示す図である。 本発明の実施形態におけるデータの流れの態様を示す図である。 本発明の実施形態におけるデータの流れの態様を示す図である。 本発明の実施形態におけるデータの流れの態様を示す図である。 本発明の実施形態を用いる応用を示す図である。 本発明の実施形態を用いる応用を示す図である。

図１は、本発明の実施形態を組み込んだ通信システムの概略図である。
この通信システムは、ネットワーク４で相互接続された、発信側システム３と、受信側システム２とを含む。
一般に、発信側システム３は、受信側システム２との接続の要求をネットワーク４に対して発行することによって、呼の開始フェーズをトリガする。

ネットワークは、発信側システム３から渡された識別情報に基づいて、受信側システム２についての識別情報データを設定する。この識別情報データは、受信側システム２の、ロケーション、識別情報、および／または他の必要な情報を含むことが可能である。携帯電話通信の場合、この識別情報データは、一般には電話番号と呼ばれるＭＳＩＤＮを含む。これは、インスタントメッセージングまたは他のサービスの場合には、より汎用的なＩＰアドレスおよび／または「ユーザＩＤ」であってよい。

ネットワーク４が受信側システム２の識別情報データを設定した後、ネットワーク４は、セッション開始データを受信側システム２に送信する。セッション開始データは、その通信セッションの技術的詳細（映像呼または音声呼のためのコーデック情報や、テキスト通信のためのコードページなど）を含む。

開始フェーズ中のある時点で（または開始フェーズの終了時に）、受信側システム２において呼通知が生成される。以下では本発明の様々な実施形態について詳細に説明するが、共通するのは、受信側システム２において生成された呼通知の少なくとも複数の属性が発信者によって制御可能である点である。

いくつかの実施形態では、受信側システムは、呼通知の生成に用いられる呼通知データを取得するようトリガされる。代替として（または追加で）、呼通知データは、直接または間接的に受信側システム２に渡されることが可能である。一実施形態では、呼通知データは、発呼回線識別子に付加されるか、発呼回線識別子内にエンコードされることが可能である。

この点は、受信側システム２において生成された呼通知の属性を発信者が制御できない（受信者が制御する）、前述のシステムのような先行システムと異なることを理解されたい。

開始フェーズは、受信側システム２のユーザが呼を受け入れることに同意して初めて正常終了したと見なされるのが一般的であり、その時点から通信フェーズが開始される。しかしながら、本発明のいくつかの実施形態では、開始フェーズは、より早い段階で終了したと見なされうる。そのような実施形態では、開始フェーズと通信フェーズとの間に通知フェーズが導入され、開始フェーズが終了した後に通知フェーズが開始され、通知フェーズが終了して呼が受け入れられた後にのみ、通信フェーズが開始される。

呼通知は、受信側システム２に既に存在するリソースを用いて（たとえば、特定の既存の着信音を選択するか、受信側システム２にある着信音発生器を用いてカスタム着信音を鳴らすことによって）生成されることが可能である。

本発明の実施形態では、発信側システム３は、カスタム呼通知（たとえば、特殊な着信音、ビデオ画像、または短いメッセージの表示など）を受信側システム２において生成するために用いられるデータを、直接または間接的に受信側システム２に導入する。

発信側システムと受信側システムとは、同じタイプでなくてもよいことを理解されたい。本発明の実施形態は、使用される下層通信メカニズムが両方のシステムと互換でありさえすれば、適用可能である。たとえば、携帯電話は、固定回線電話において、発信者制御の呼通知をトリガすることが可能であり、また、コンピュータ上のＶＯＩＰクライアントにおいて、発信者制御の呼通知をトリガすることが可能であってもよい。この状況では、携帯電話の呼は、標準的な電話呼として処理されることが可能であり、携帯電話ネットワークとＶＯＩＰネットワークとの間のＶＯＩＰゲートウェイによって処理されることが可能である。代替として、電話がＶＯＩＰをネイティブサポートすることが可能であれば、ゲートウェイは不要になる。呼がゲートウェイを通る場合は、開始データ内の、発信者制御の呼通知データが、受信側システムの要求どおりのフォーマットに変換されることを可能にする機能を、ゲートウェイが含むことが好ましい。

呼通知データは、自己完結している（または出力の準備ができている）必要はなく、
データの取得先となるべき他のソースへの参照と、
（受信側システムのリソースを用いるか、別の場所から取得される）呼通知をどのように生成するかについての命令と、
出力の前に、受信側システムによるエンコード、レンダリングなどが必要なデータと、を含むことが可能である。

記載の実施形態のうちの高度なものでは、本明細書に記載のメカニズムのいずれかを用いて、通信フェーズに進むことなく通信通知を送信するオプションが、発信側システムに与えられることが可能である。

他の実施形態では、呼通知は、最初から単一の発信者に関連付けられなくてもよく、その代わりに、受信側システムのユーザが呼通知を受け入れた場合に接続される多数のコールセンターに関連付けられてもよい。このようにして、ユーザの関心を照会する多彩な広告呼通知を送信することが可能である。ユーザがその呼通知を受け入れた場合のみ、呼が発信側システムに接続される。したがって、ほとんどの標準呼がそうであるように、発信者対受信者のマッピングが１：１である必要はなく、発信者は、潜在的に一度に複数の受信者に照会し、呼通知を明確に受け入れた受信者にのみ接続することが可能である。

図２は、本発明の実施形態におけるデータの流れを示す図である。
ネットワーク４が受信側システム２の識別情報データを設定した後、開始要求１０が、発信側システム３から受信側システム２へ送信される。

受信側システム２では、開始要求１０が受信者された後、ただちに、ステップ２０において、発信者が生成した呼通知がサポートされていて有効かどうかを立証するためのチェックが実行される。

呼が、発信者の生成した呼通知をサポートしていることの検出は、発信者またはセッションの識別情報をリストまたはデータベースでルックアップすることによって達成されることが可能であり、そのリストまたはデータベースは、受信側システムまたは任意のリモート装置に格納されることが可能である。

発信者が生成した呼通知がサポートされていて有効である場合は、ステップ３０において、開始要求にあるデータが受信側システム２によって使用され、呼通知の生成に必要なデータが取得される。

ステップ４０において、そのデータが受信側システム２によって取得された後、ステップ５０において、呼通知が、受信側システム２によって生成および出力される。
受信者２が呼を受け入れると、呼通知が終了し、通信フェーズ６０が開始される。

受信側システム２が自己チェックを行って、発信者が生成した呼通知がサポートされているかどうかを判定することの代替として、受信側システム２は、開始要求１０が受信側システム２に配信される前にチェックされる、ネットワーク４内のエンティティに、受け入れを登録することが可能である。このエンティティが、識別された受信側システム２の受け入れの登録を有しない場合は、標準の開始要求が受信側システム２に伝送され、それによって、発信者が生成した呼通知ではなく、受信側システムの標準の呼通知がトリガされる。

図３に示すように、一実施形態では、サーバ１の形のリモートリポジトリを配置して、データと、任意で発信側システム３の通知属性とを、格納させることが可能である。そのような実施形態では、受信側システム２は、ステップ４０において、サーバと通信してデータと発信側システム３の属性設定（あれば）とを取得するようトリガされることが可能である。発信側システム３の識別情報は、開始要求に含まれるＣＬＩまたは同様の識別子から取得されることが可能である。サーバ１の識別子、ＩＰ、またはＷｅｂアドレスも、開始要求に含まれることが可能である。

サーバ１は、発信側システム３のユーザが、自身を登録し、呼通知に用いられるデータを格納または選択し、任意の通知属性を設定することを可能にするインターフェースを含むことが好ましい。

開始要求は、発信者が生成した呼通知をサポートする呼を、発信側システムが識別するために用いる特殊情報を含むことが可能である。これは、標準の電話通信の場合には、発呼回線ＩＤに対する拡張であることが可能であり、ＳＩＰの場合には、件名欄における特殊コードであることが可能であり、これは、他のセッション開始メカニズムの場合と同様のアプローチである。

サーバ１は、ネットワークプロキシまたはサーバの一部であってよい。発信側システム３は、呼よりずっと前にデータをアップロードまたは選択することの代わりに（またはこれに追加して）、開始フェーズの前に（または開始フェーズ中に）データをサーバ１にアップロードするか、呼通知に用いられるデータをサーバ１に指示することが可能である。

代替実施形態では、受信側システム２は、データと任意で任意の通知属性とを、発信側システム３から直接取得することが可能である。これは、ピアツーピア接続、または他の任意の形の接続を通して可能である。

本発明の実施形態は、様々な方法で、かつ／または様々な時点で呼通知データを取得する受信側システムを扱うことが可能である。以下では様々な例示的実施形態について説明するが、他の変形形態も可能である。

図４に示した一実施形態では、受信側システムは、呼通知データが使用可能であるという通知を受信し、通信フェーズ１２０が開始される前の標準の開始フェーズ１１０の間に、呼通知データにアクセスする。

開始フェーズ１１０は、受信側システム２によって、呼通知データが受信され、それが適切である場合に、出力または処理されて初めて、通信フェーズ１２０が開始されるように、延長される。

開始ハンドシェーク１００には、受信側システム２がピアツーピア通信によってアクセスすることが可能な呼通知データを発信側システム３が有する、という通知が含まれる。ステップ１０５で開始ハンドシェークが終了した後であって、通信フェーズ１２０が開始される前に、ステップ１３０において、呼通知データが発信側システム３から受信側システム２に送信される。これは、「延長された開始フェーズ」１４０と称され、このフェーズの間はユーザ間の完全同期通信が許可されず、呼通知のための呼通知データの転送だけが許可されるという点で、通信フェーズ１２０と区別される。

「延長された開始フェーズ」の代替として、図５の実施形態では、２つの装置の間に、別個の通信セッション２００が設定される。受信側システム２は、ステップ２０５において、呼通知データの転送を要求し、これはその後、ステップ２１０において、発信側システム３によって送信される。一度だけこれが実行され、呼通知がユーザに提示された後、システムは、開始ハンドシェーク１００が終了したと見なし、通信フェーズ１２０の開始を許可する。

図６の実施形態では、発信側システム３は、別個の通信セッション２５０の一環として、呼通知データが使用可能であることをサーバ１に通知する。その後、通常の開始ハンドシェーク１００が発信側システム３によって開始され、受信側システム２は、さらに別個の通常セッション２６０を作成して、呼通知データが使用可能かどうかをサーバ１に確認する。呼通知データが使用可能であることが確定すると、受信側システム２は、ステップ１０５において開始ハンドシェークを閉じ、発信側システム３との通信セッション２７０を開くが、通信フェーズの開始は許可しない。このフェーズ２７０の間に、呼通知データが発信側システム３から受信側システム２に転送される。このフェーズ２７０は、受信者が呼を受け入れた時点でのみ終了し、この時点で通信フェーズ１２０が開始される。

図７の実施形態において示されるように、受信側システム２は、新たなセッションを開始する代わりに、現在のセッションを用いて、呼通知データを発信側システム３に要求することが可能である。

図８に示された実施形態では、開始ハンドシェーク１００が発信側システム３から受信側システム２に渡された後、発信側システム３が、別個の通信セッション３００を開き、ステップ３１０において、呼通知データが使用可能であることを、独立したサーバ１に登録する。同様に、受信側システム２が、ハンドシェーク１００の受信後ただちに別個の通信セッションを開き、ステップ３２０において、呼通知データが使用可能かどうかをチェックする。呼通知データが使用可能であることが確定すると、受信側システム２は、開始ハンドシェーク１００を閉じ、発信側システム３との通信セッション３３０を開くが、通信フェーズの開始は許可しない。その後、延長された開始フェーズ３４０が開始され、その中で、呼通知データが発信側システム３から受信側システム２に転送される。このフェーズ３４０は、受信者が呼を受け入れた時点でのみ終了し、この時点で通信フェーズ１２０が開始される。

図９に示された別の実施形態では、開始ハンドシェーク１００が発信側システム３から受信側システム２に渡された後、開始フェーズ１１０が開始される。発信側システム３は、別個の通信セッション４００を開き、呼通知データが使用可能であることを、独立したサーバ１に登録する。同様に、受信側システム２が、ハンドシェーク１００の受信後ただちに別個の通信セッションを開き、ステップ４１０において、呼通知データが使用可能かどうかをチェックする。呼通知データが使用可能であることが確定すると、受信側システム２は、ステップ４２０において、現在のセッションを用いて、呼通知データを発信側システム３に要求する。その後、ステップ４３０において、発信側システム３がこのデータを受信側システム２に送信し、受信側システム２が呼通知を出力する。受信者２がその呼を受け入れると、ハンドシェーク１００が終了し、通信フェーズ１２０が開始される。

図１０の実施形態では、開始ハンドシェーク１００が発信側システム３から受信側システム２に渡された後、開始フェーズ１１０が開始される。発信側システム３は、別個の通信セッション４００を開き、ステップ５１０において、独立したサーバ１に呼通知データをアップロードする。同様に、受信側システム２は、別個の通信セッションを開き、ステップ５２０において、しかるべき呼通知データをサーバ１に要求する。呼通知データが使用可能であれば、ステップ５３０において、呼通知データがサーバから受信側システム２にダウンロードされ、その後、受信側システム２が呼通知を出力する。受信者２がその呼を受け入れると、ハンドシェーク１００が終了し、通信フェーズ１２０の開始が許可される。

図１１は、図１０に示された実施形態の代替を示し、ここでは、データ５１０のアップロードが、セッション開始ハンドシェーク１００の前に行われる。
一実施形態では、呼通知データが存在することをサーバに通知することと、データをサーバにアップロードすることとが、任意で別々に（図１２に示されるように、開始ハンドシェーク１００の、それぞれ、前と後に）実行されることが可能である。

携帯電話実装の場合、発信側携帯電話は、発信者制御の呼通知トリガを、呼設定の間に、受信側携帯電話に送信する。受信側携帯電話は、そのトリガを処理し、それによって呼通知データを取得させられて、受信側ユーザに対して出力される呼通知を生成し、その後、受信側ユーザがその呼を取るかどうかを決定する。

呼通知データは、多数の様々なタイプのデータを含むことが可能であり、たとえば、発信者が定義した着信音、発信者が録音した着信音、優先度フラグ、テキストメッセージ、写真などを含むことが可能である。呼通知データは、一般に、発信者によって、選択、作成、または提供されて、受信者携帯電話がダウンロードして使用できるようになり、その後、受信者がその呼を受け入れるかどうかを決定する。

発信側携帯電話においては、発信側ユーザは、送信されるべき情報、受信者の識別情報を定義して、通信会社との呼を開始することが可能である。
発信側ユーザは、自分の電話のデフォルトパラメータの中にプリファレンスを追加設定できることが好ましい。このプリファレンスが有効の場合、その電話から発せられるすべての呼が、あらかじめ定義された、発信者制御の呼通知をその呼にリンクし、互換性のある受信側携帯電話において、呼の受信後ただちに、発信者が生成した呼通知を引き起こす。デフォルトの、発信者制御の呼通知は、メッセージや優先度フラグのような呼固有アイテムではなく、写真や着信音のようなユーザ固有アイテムを含む可能性が高い。

代替として、または追加で、ユーザは、呼が作成される前に、呼にリンクされるべき、呼固有の、発信者制御の呼通知を指定できることが好ましい。これは、代替呼ボタンまたはキーの組み合わせを選択することにより、なされることが可能である。ユーザは、場合ごとに、呼が作成される前に、適切な呼通知内容を選択しなければならない。

呼固有情報の場合も、ユーザ固有情報の場合も、発信者制御の呼通知が呼にリンクされてからの呼の作成プロセスは、既存の発呼機能と同一である。呼がダイヤルされた後、発信者には、受信者が呼に応答するまで、着信音または呼び出し音（構成されている場合）が聞こえている。発信者には、受信者が付加情報を受け取っているかどうかの何らかの表示を任意で提供されることが可能である。

発信者制御の呼通知は、呼通知または呼通知タイプのあらかじめ定義されたリストから選択されることが可能であり、それらの呼通知または呼通知タイプは、優先度、感情アイコン（顔文字）などの場合には携帯電話にプリインストールされ、着信音、写真などの場合には、携帯電話とは別のサーバでホストされる可能性が高い。

発信者は、呼通知が受信側携帯電話によって生成される前に受信者に送信されることが可能な個人情報を、任意で生成することが可能である。この個人情報は、短いテキストメッセージ（ＳＭＳメッセージとは異なる）、写真、着信音、映像、さらに自分で記録した音声または映像を含むことが可能である。

発信側または受信側のシステムで使用可能な帯域幅がごく限られている場合には、発信側システムまたはネットワークは、受信側システムが呼通知の生成のためにダウンロードするデータを縮小できることが好ましい。これは、データのキャッシュされたローカルコピー、解像度を下げられた写真または映像、ダウンサンプリングされた音声などの形であってよい。

好ましくは、発信者が受信者に対して自分の電話番号を表示しないことを選択した場合には、発信者が、発信者制御の呼通知を有する呼を送信することが可能であってはならない。

受信者は、自分の携帯電話が発信者制御の呼通知を受け入れるか拒否するかを構成できることが好ましい。ほとんどの携帯電話は複数のプロファイルが可能なので、プロファイルは、好ましくは、発信者制御の呼通知を認識するよう作成され、特定の発信者制御の呼通知がプロファイル設定に優先することを可能にする設定を含む。たとえば、発信者制御の呼通知が「高優先度」タグを含む場合は、「静穏」プロファイルの間であっても、標準の着信音を鳴らすことが可能である。

受信側携帯電話は、発信者制御の呼通知を定義する呼設定ハンドシェークを受信するとただちに、自身の現在の構成をチェックして、その発信者制御の呼通知をユーザに提示することが可能かどうかを確定する。可能であれば、受信側携帯電話は、必要な通知データを取得し、その呼通知をユーザに対して出力する。受信側携帯電話はさらに、呼通知が正常に受信および出力されたことを通信会社に通知することも可能である。音声の場合は、標準の着信音に代わるものでなければならない。

ユーザが呼を受け入れるか拒否すると、呼通知はそれ以上出力されない。
呼通知に、ストリーミングされたデータ（着信音や映像など）が含まれる場合、その残りの情報は受信者に送信されない。

受信側携帯電話は、受信者が呼通知の態様を保存することを可能にするオプションを含むことが好ましい。優先度フラグ、短いテキストメッセージ、写真などの、呼通知のシンプルな態様は、受信側携帯電話のメモリに保存され、呼履歴に表示されることが可能である。より大きな形態のデータは、受信者の要求により（おそらくは、サービスプロバイダまたは通信会社に料金を支払うと）保存されることが可能である。携帯電話は、すべての形式の呼通知データがローカルに保存され、呼履歴からアクセスされることを可能にするように、変更されることが可能である。

既に呼の処理中である受信側携帯電話には、可能な限り多くの、発信者制御の呼通知が与えられなければならないことが好ましい。コールウェイティングに関して技術的に何が可能であるかは、ネットワークによって異なる。既存の呼の処理中である受信側携帯電話には、少なくとも優先度フラグ、短いメッセージ、および写真が与えられることが好ましい。

迷惑呼（たとえば、不適切または脅迫的な付加情報の送信）が目的である人による呼通知の悪用を防ぐために、ユーザは、特定の発信者をブラックリストに載せて、その発信者から付加情報を二度と受け取らないようにすることが可能でなければならない。

本発明の実施形態の利用が可能である潜在的応用が多く存在することを理解されたい。
潜在的応用の１つは、本発明の実施形態の、広告への利用である。呼通知は、広告または売り込みを含むことが可能である。受信側システムのユーザは、その売り込みを受け入れたり、広告の商品またはサービスについて人間のオペレータまたは自動システムとさらに話をしたりする場合には、その呼を受け入れるだけでよい。これにより、ユーザは、担当者または担当の自動システムに接続される。

ユーザは、興味がない場合には、通知を無視するだけでよい。
たとえば、ユーザは、商品として提示される、携帯電話の着信音または壁紙の通知を受けることを選択することが可能である。この通知は、ユーザによるプレビューのための１つまたは複数の着信音または壁紙のサンプルを含むことが可能である（たとえば、これらは、単独で、またはスライドショーなどのように提示されることが可能である）。ユーザは、特定の着信音または壁紙を購入する場合には、呼に応答して、販売担当者または販売担当の自動システムに接続され、購入手続きを進める。

同様に、音楽トラックや映像などのダウンサンプリングまたは短縮されたものを通知として送信し、ユーザが内容をプレビューし、呼を受け入れることによって購入することが可能であるような方法も可能である。
本発明の一実施形態の応用を、図１３に示す。図示された応用では、コールセンター環境が、本発明の実施形態を、電話による販売に利用する。

コールセンター１０００は、データネットワーク１０４０で相互リンクされた、多数のオペレータ端末１０１０と、センター管理者端末１０２０と、通知サーバ１０３０とを含む。通知サーバ１０３０は、電話による販売の売り込みを受けることを選択した受信側システム２についてのデータを保持するデータベース１０５０にアクセスするよう構成されている。

センター管理者端末１０２０は、オペレータ端末１０１０および通知サーバ１０３０と通信して、コールセンター１０００の稼動データを取得するよう構成される。通知サーバ１０３０は、センター管理者端末１０２０を介して、所定数の受信側システム２への呼通知の送信をトリガされることが可能である。各呼通知は、電話による販売の売り込みの詳細を含む。通知は、受信側システム２において受信されるとすぐに、前述の方法のいずれにより（たとえば、グラフィックファイル、映像ファイル、または音声ファイルのいずれか、または組み合わせの形で）ユーザに対して出力される。受信側システム２のユーザが呼を受け入れた場合には、その呼が空きオペレータ端末１０１０に接続されるように、通知サーバが構成される。

このようにして、コールセンターの能力は、コールセンター管理者端末によって管理されることが可能であり、発行される通知の数は、稼働中のオペレータ端末１０１０の数と釣り合わされることが可能である。ダイレクトメールマーケティングおよびＳＭＳベースのマーケティングと異なり、通知は、次のように制御されることが可能である。

ユーザは、コールセンターの稼動時間中にのみ、売り込み（通知）を受け入れる機会を与えられる。

数量に制限がある売り込み（たとえば、飛行機の座席、休日など）は、売り込みに対する申し込みが制限を超えないように、適切な受信者数と整合されることが可能である。
従来型の商店は、前述のシステムを縮小したものを運用して、目前の可用性（レストランのテーブルなど）に基づく「ジャストインタイム」の売り込みを行うことが可能である。

任意で、ユーザは、特定のタイプのみの広告の受け入れ／拒否が可能になるプリファレンスプロファイルを登録する機能を与えられることが可能である。さらに、または代替として、受け入れられた広告のタイプを監視し、それに合わせて後続の広告をあつらえるシステムが提供されることが可能である。
他のイベントドリブン応用も考えられる。

たとえば、ホテルでは、そのアラームコール機能をそのルームサービス機能にリンクさせることが可能であり、この場合、通知は、前日の夜に予約され、アラームコールとして動作する。ユーザは、起床することを決心して呼通知に応答すると、ルームサービスに接続され、朝食を注文することが可能になる。あるいは、ユーザが遅くまで寝ることを決定した場合は、システムが、所定時間後にさらなる通知を発行するよう構成されることが可能である。このように、ユーザは、いつ起きることにしても、温かくフレッシュな朝食を受け取ることが可能になる。

同様のシナリオで、通勤者などについても、通勤情報会社から、受信契約をしている受信側システム２にアラームコールを提供することが可能である。アラームコールが受け入れられると、ユーザのロケーションまたは事前設定されたプロファイルに適合する通勤情報を、所定の料金レートで提供することが可能である。
別の例を図１４に示す。この例では、受信側システム２のユーザに検索機能が提供される。

ユーザは、受信側システム２のユーザインターフェースを介して、適切なキーワードを入力し、これがリモート検索エンジン１２００によって処理される。検索エンジン１２００は、キーワードに適合するものを、契約サプライヤのデータベースで検索する。キーワードに適合するサプライヤの広告が通知と結合され、その通知が受信側システム２に送信される。受信側システム２は、通知を受信するとすぐに、その通知を広告のスライドショー１２１０として出力し、ユーザは、受信側システム２の適切なキー１２１０を用いてスライドショー１２１０を自由に見てまわることが可能である。ユーザは、広告を選択したら、受信側システム２のコールキーを押す。これにより、当該サプライヤ１２３０への呼が空いていれば呼がトリガされ、空いていない場合は、当該サプライヤ１２３０へのコールバック要求がトリガされる。

受信側システム２の検出されたロケーションに基づくロケーションベースの応用も考えられる。検出は、ＧＰＳのようなシステム、セルベースのロケーション検出、または他のそのような技術によって行われることが可能である。たとえば、交際相手紹介所は、本発明の実施形態を用いて契約ベースのサービスを提供することが可能である。そのような応用では、ユーザの事前同意されたプロファイルと一致する契約者がユーザの携帯電話の所定レンジ内に入ると、その一致する契約者の詳細、写真などを含む通知をユーザの携帯電話に送信することが可能である。その通知によって送られた情報に基づいてユーザが関心を持った場合、ユーザは、その呼を受け取ることを選択し、その一致する契約者に接続されることが可能である。この場合、どのユーザも呼通知の開始を決定していないことに注意されたい。システムの構成次第であるが、第３のパーティが他の２つのパーティの間の呼通知を開始する場合には、両方のパーティが、相手のパーティに関する呼通知を受け取り、両方のパーティが受け入れることを、呼を通信フェーズに進めるための前提条件とすることが適切であろう。

特に、売り込みベースの呼通知の場合は（他の呼通知も当てはまる場合があるが）、通知がすぐには受け入れられない場合に備えて、通知が所定時間だけ受信側システム２上に存続することが適切であろう。呼通知が存続する間に、いくつかのプリプログラムされたフェーズを含め、それぞれのフェーズで呼通知自体を異なるものにすることが可能である。

たとえば、呼通知は、受信直後には、音声プロンプトおよび画像または映像が受信側システム２によって出力されることを求めることが可能である（前提は、受信側システム２が、それを行うのに適切なモードであることと、そのような通知タイプが受信側システムにおいて現在禁止されていないことである）。所定時間内（たとえば、１０秒以内）に通知が受け入れられない場合、通知は、画像または映像が音声なしで出力されることが可能な第２のフェーズに入ることが可能である。通知がさらなる所定時間内にも受け入れられない場合、通知を、受信側システムのスクリーンから除去して、最近の通知のリストに記録することが可能である。所定時間後、通知を、期限切れにし、受信側システム２から削除するか、呼の受け入れができなくなるように構成することが可能である。

好ましくは、各受信側システム２は、受信した通知を拒否することを可能にするキーを含み、拒否した場合は、通知を停止し、受信側システム２から削除する。
任意で、通知の全体または少なくとも所定部分が受信側システムにおいて出力されるまで、受信側システム２のユーザが呼を受け入れることができないように受信側システムを制御するよう、通知を構成することが可能であり、このようにして、ユーザが重要な情報（発信者が受信者に告知することが法律で義務づけられている契約条件など）をスキップしてしまうのを防ぐことが可能である。前述のように、通知の拒否はいつでも可能である。

任意で、フィードバックデータを発信側システム３に提供して、発信者が通知のステータスを監視することを可能にすることができる。たとえば、異なる着信音を用いて、通知がどこで準備されていて、どこで受信側システム２に送信されるかを示すことが可能である。標準のネットワーク着信音は、一般に、通知が受信側システム２において出力されていることを発信者に知らせるために用いられる。

容量的な理由から、呼通知によって確立されている通信チャネルは、通知の開始フェーズの間だけ開かれている可能性が高い。その間に通知が受け入れられない場合、通信チャネルはリサイクルされる可能性が高い。そのような状況では、関連付けられた通信チャネルがもはやない状態で通知が受け入れられた場合、受信側システム２は、発信側システム３を呼び出すか、代替としてコールバックを要求するよう構成されることが可能である。

さらに別の実施形態では、受信側システム２にＲＦＩＤタグを組み込むことが可能である。タグがＲＦＩＤタグリーダのレンジ内を通過したときに、受信側システムに対して呼通知が開始されることが可能である。ＲＦＩＤタグは、ＲＦＩＤタグリーダによる受信側システム２の識別を可能にするために、受信側システム（あるいは受信者の携帯電話）の識別子（悪用を防ぐためにエンコードされていることが好ましい）を含むことが可能である。そのような構成の一応用は、タグリーダに広告を埋め込むか、タグリーダを広告に関連付けることである。このようにすると、ある広告の前に所定時間いたことが検出されたユーザに、さらに情報を入手したり、チケットを購入したりするための呼を有する、その広告の続報バージョンを含む呼通知を送信することが可能になる。代替として、通知は、広告されているものに関連付けられた売り込みを含むことが可能である。

様々な料金構造を考えることができる。たとえば、広告ベースの通知を受けることを選択したユーザに無料通話を提供することが可能である。代替として、広告呼通知を受けたユーザに礼金を支払うか、何らかの謝礼を渡すことが可能である。さらに別の変形形態では、発信者／受信者が、通知の前または後に広告が表示されること（または通知にバナーが含まれること）を許可した場合に、通知機能が無料または低価格で提供されることが可能である。コールセンターのような業務ユーザに対しては、後続呼に対して優先レートが適用される、通知の大口割引を用意することが可能である。用途にもよるが、受信者が通知の後の呼を取ることには料金がかかってもかからなくてもよく、個人的に開始された呼通知および広告呼の場合は、受信者は課金されないのが普通である。情報商品または情報サービスが呼を介して提供された場合には、受信者は課金されるのが普通である。

スポンサー付きコンテンツを考えることもできる。たとえば、広告主を呼び出して、提供される商品またはサービスを受け入れるオプションを有する、広告付きの毎日の通勤情報または気象情報を契約者に提供することが可能である。そのような場合は、広告収入があるので、受信者に対する課金が低減されたり、放棄されたりするであろう。

好ましくは、通信会社は、発信者が生成または送信した通知データが、技術的に正当であって、有害なソフトウェア（ウィルスなど）を含まないことを確認するために、通知内で使用される前のそれらの通知データに対して、しかるべきアクティビティを実行しなければならない
呼の開始フェーズの間、通信会社は、呼の受信者の識別子と、発信者制御の呼通知の表示またはそれへのリンクとを受け取る。通信会社は、受信者システムがローカルネットワーク上に存在することを立証し、受信者がそのサービスを使用するよう登録されていることを確認する。

受信者がそのサービスを使用するよう登録されている場合、通信会社は、その呼を、ネットワーク上の該当する着呼側ＩＤにルーティングし、発呼側ＩＤと、発信者制御の呼通知の表示またはそれへのリンクとの両方を、受信者に供給する。受信者が呼を受け入れた場合、通信会社は、発信者と受信者との間に呼を開く。

外部（非ローカル）ネットワークをベースとする受信者の場合、通信会社は、その受信者が外部ネットワーク上に存在することを立証した後、その外部ネットワークが発信者制御の呼通知をサポートしていることを確認することが可能である。通信会社間の実装および同意次第であるが、受信者によるアクセスを簡略化するために、必要な通知データを、発信者のネットワークにあるサーバまたはリソースから外部ネットワークにあるサーバまたはリソースに転送することが可能である。

発信者または受信者がローミングネットワーク上または外国にいる場合は発信者制御の呼通知をさせないようにする制御を導入することが可能である。発信者制御の呼通知は、発信者または受信者またはその両方への呼の料金に上乗せする料金を伴う場合がある。携帯電話の場合、いくつかの無料の発信者制御の呼通知を含むサービス契約は、無料の通話時間またはＳＭＳメッセージを現在提供している契約の場合と同様に考えることができる。料金は、呼通知自体（たとえば、受信者に送信される呼通知データの量）に依存してよい。受信者が呼に応答しない発信者制御の呼通知の無料通信使用を防ぐために、呼通知に含まれる呼通知データの量に関係なく、発信者制御の呼通知の使用に課金することも可能である。課金は、通信会社の既存の課金システムによって行われることが可能であり、ほとんどの場合は、後払い顧客に対して追加のＣＤＲ（呼データレコード）を生成することによって可能である。

転用呼は、普通呼とまったく同様に処理され、付加情報の受信に関して、外部またはローカルネットワークとユーザプロビジョニングとが完全にチェックされる。多くの携帯電話ネットワークにおける実用的な検討によれば、転用呼に対してはサービスを無効にしなければならないことになりそうであるが、これはネットワークによって様々である。

規格は継続的に収束に向かい、システムは様々なデータフォーマットをサポートするために拡大するが、それでも非常に可能性が高いのは、いくつかのデータタイプのフォーマットを、受信側システムによる出力に適するように変更する必要があることである。たとえば、音楽、写真、または映像のエンコードフォーマットを、受信側システムに適したフォーマット（および／またはサイズ）に変更しなければならない場合がある。本発明の実施形態は、呼通知データが受信者に送信される前にプロキシされるトランスコードシステムを含む。

前述の様々な実施形態は、所望の実装に応じて様々な形で任意に組み合わされることが可能な特徴を開示している。記載の特徴はモジュール的なので、特徴の別の組み合わせに基づく他の実施形態も可能である。
記載の特徴は、どれもが互いに排他的ではないので、任意の組み合わせを導入して前述の機能を達成することが可能である。

２ 受信側システム
３ 発信側システム
４ ネットワーク
１００ 開始ハンドシェーク
１１０ 開始フェーズ
１２０ 通信フェーズ
１４０ 延長された開始フェーズ

Claims (10)

1. 発信側システムからの呼の開始データの受信に応答して、受信側システムにおいて、呼通知を生成するように構成した呼通知システムにおいて、
   前記開始データは、前記受信側システムをトリガするように構成され、前記発信側システムとの別個のピアツーピア接続を開き、前記呼通知を生成するために用いられる呼通知データを前記発信側システムから取得し、
   これにより、少なくとも前記呼通知の態様が、前記発信側システムにより制御可能であり、
   前記受信側システムは、前記発信側システムに対して、前記呼通知のステータスに関するフィードバックデータを供給するように構成し、
   前記フィードバックデータは、前記受信側システムで前記呼通知データが受信されたか否かを、前記発信側システムに示すデータであることを特徴とする呼通知システム。
2. 呼通知システムであって、該呼通知システムが、
   呼が発信される発信側システムであって、前記発信側システムが、呼通知を生成するために用いられる呼通知データを有し、呼を開始し、前記呼通知データを供給するように構成した発信側システムと、
   呼が受信される受信側システムとからなり、前記受信側システムは、呼の開始データの受信に応答して、
   前記発信側システムとの別個のピアツーピア接続を開き、前記呼通知を生成するために用いられる呼通知データを前記発信側システムから取得し、
   呼通知を生成し、
   前記受信側システムで前記呼通知データが受信されたか否かの表示を含む前記呼通知のステータスに関するフィードバックデータを、前記発信側システムに対して供給し、且つ
   前記受信側システムにおける少なくとも呼通知の態様を、前記発信側システムにより制御可能にしたことを特徴とする呼通知システム。
3. 前記フィードバックデータは、前記呼通知に関しての前記受信側システムのステータスを示す着信音を含むことを特徴とする請求項１又は２に記載の呼通知システム。
4. 前記受信側システムが、前記呼通知が正常に受信され、出力されたことを通信会社に通知するように構成したことを特徴とする請求項１〜３の何れかに記載の呼通知システム。
5. 前記受信側システムは、前記発信側システムから取得したアドレス情報に基づき、アドレス帳を更新するように構成したことを特徴とする請求項１〜４の何れかに記載の呼通知システム。
6. 前記発信側システムにより制御可能な前記呼通知の態様が、前記受信側システムで呼通知を無効化する操作を含むことを特徴とする請求項１〜５の何れかに記載の呼通知システム。
7. 前記受信側システムでの呼通知の無効化操作は、マナーモードの無効化を含むことを特徴とする請求項６に記載の呼通知システム。
8. 前記受信側システムでの呼通知の無効化操作は、少なくとも呼通知の所定部分が出力される迄に、受信側システムで呼通知の受信を受け入れないように構成したことを特徴とする請求項６に記載の呼通知システム。
9. 呼通知の生成方法であって、該呼通知の生成方法は、
   受信側システムで、発信側システムからの呼の開始データを受信するステップと、
   前記受信側システムから前記発信側システムへの別個のピアツーピア接続を開くステップと、
   前記発信側システムから呼通知データを取得するステップと、
   通信フェーズを確立する前に、呼通知の状態に関するフィードバックデータを前記発信側システムに供給するステップとを含み、前記フィードバックデータは、前記受信側システムで前記呼通知データが受信されたか否かを、前記発信側システムに表示するデータであり、更に
   前記受信側システムにおいて、前記受信した呼通知データに基づいて呼通知を生成するステップとを含み、
   少なくとも前記呼通知の態様が、前記発信側システムにより予め決められていることを特徴とする呼通知の生成方法。
10. 前記フィードバックデータを供給するステップは、前記呼通知に関しての前記受信側システムでの呼通知のステータスを示す着信音を前記発信側システムに出力させることを特徴とする請求項９に記載の呼通知の生成方法。

Images