JP5160084B2 - 発呼側を検証するための方法、コンピュータ・プログラム、およびシステム - Google Patents

Description

本発明は、発呼側の検証に関し、より詳細にはスパムおよび応答不要呼を判定するためのシステムおよび方法に関する。

インターネット・プロトコル（ＩＰ）・ユーザの匿名性は、インターネットを介してサービスを提供する際の主要な問題である。これは、ボイスオーバーＩＰ（ＶｏＩＰ）ベースのサービスを含むすべてのサービスに悪影響を与える。既に電話による詐欺が常時における問題となっているが、詐欺の自動化がさらに容易になっているので、インターネットによって上記の問題はさらに深刻化している。したがって、サービス・プロバイダとユーザのどちらにとっても、ＩＰを介して配信される自動化された攻撃を止めさせることが重要である。

セッション開始プロトコルすなわちＳＩＰは、インターネット会議、テレフォニー、イベント通知およびインスタント・メッセージのための信号送受プロトコルである。ＳＩＰおよびＶｏＩＰネットワークでは、未承諾メッセージおよび呼を、電話網よりも安価かつ高速に自動生成して電話に配信することができる。

次の２種類のスパムが考えられる。（１）コール・スパム。コール・スパムとは、発呼側がダイアログを成功裏に開始することを希望しており、媒体セッションを有するものである。例えば、今日のテレマーケティング・コールに類似した「事前記録された」ストリームを使用するソフトウェアによって自動的に開始され実行され、実行される未承諾呼である。（２）呼開始スパム。呼開始スパムは、発呼側がダイアログを成功裏に開始することを希望せず、媒体セッションを有さないものである。例えば、複数の偽のＳＩＰ ＵＲＩまたはＩＰアドレスによる要求されていないＩＮＶＩＴＥ スパムである。

電話網スパム（テレマーケティング）は法規により解決することができるが、国境のないＩＰネットワークおよびスパマーは、特定の法律が適用される法域にない場合がある。電子メール・スパムの問題は、個々の電子メール・メッセージに含まれるヘッダーおよび内容を受動的に解析するスパム・フィルタを使用して解決することができる場合がある。ヘッダーが偽造または偽装される可能性があるので、これは効果的である保証はない。さらに、呼が既に確立してその内容の送信が始まるまではその内容を解析することはできないので、ＶｏＩＰスパムに対して内容解析が効果的である保証はない。

発呼側を検証するために、反復システムや同意ベース通信などの第三者インフラストラクチャ・サービスを使用することができる。しかし、第三者インフラストラクチャ・サービスは、発呼側と着呼側の両方がそのようなシステムに参加することを要求する。

本発明は、いくつかの問題に対処するものである。これらの問題は、例えば、提供されたサービスに誰かがアクセスしており、それが何らかの自動化された攻撃スクリプトでないことを保証することをサービス・プロバイダが希望する場合、または電話サービスのユーザが自動化された電話スパムを防ぐことを希望する場合として、説明することができる。技術がまだ比較的新しく、ＩＰを介した攻撃が完全に自動化されていないので、これらの問題に対する周知の商業的解決策はない。

発呼側を検証するためのシステムおよび方法は、呼を受諾する前にその呼の発呼側からの応答を要求する、発呼側に送信されるチャレンジの生成を含む。発呼側からの前記チャレンジに対する応答の有無が判定され、その応答は、発呼側が通信相手として受諾可能か否かを判定するための、予め定めておいた受諾可能な応答と比較して解析される。発呼側が受諾可能である場合、その呼を受諾することができる。

発呼側を検証するためのシステムは、発呼側による通信の開始に応答して、その発呼側に送信され、応答を要求するチャレンジを生成するチャレンジ・ジェネレータを含む。判定モジュールは、前記チャレンジに対する応答が受信されたか否かを判定し、その発呼側からの応答を受信する。解析デバイスは、その発呼側が通信相手として受諾可能であるか否かを判定するために、予め定めておいた受諾可能な応答と比較してその応答が受諾可能であるか否かを判定する。

これらおよび他の目的、特徴、および利点は、添付の図面と併せ読むべき、説明のための実施形態に関する以下の詳細な説明から明らかになろう。

本開示は、以下の図面を参照して、好ましい実施形態の以下の説明に詳細を提供する。

本発明の実施形態は、呼および他の通信をスクリーニングしてその通信が例えばセールス・コール、スパムなどの、未承諾かつ望まれざる通信であると判定する、自動エコー・テストまたは発呼者テストを含むことができる。

ＳＩＰトランザクションでは、メッセージ（要求または応答）が、ユーザ・データグラム・プロトコル（ＵＤＰ）または伝送制御プロトコル（ＴＣＰ）または他の転送プロトコルを使用するデバイス間で送信される。ＵＤＰは、インターネット・プロトコル（ＩＰ）を使用するネットワークにおいて複数のコンピュータ間でメッセージが交換される場合に、限定された分量のサービスを提供する通信プロトコルである。ＵＤＰは、ＴＣＰと選択可能であり、またＩＰと共にＵＤＰ／ＩＰと呼ばれる場合がある。これらの要求または応答は、一組のヘッダーおよび１つまたは複数のメッセージ・ボディというように、２つの部分で構成することができる。

ＳＩＰ要求（またはＩＮＶＩＴＥ）が送信される場合、ＳＩＰ要求（またはＩＮＶＩＴＥ）は対象パーティ（またはユーザ・エージェント（ＵＡ））のＳＩＰアドレスに送信される。ＳＩＰアドレスは、実際にはＵＲＬであり、電子メールのアドレスに類似している。あるメッセージが受信側ユーザ・エージェント（ＵＡ）に配信される前に、まずそのメッセージを受信側ＵＡにルーティングし配信するプロキシ・サーバに送信される。そして、受信側ＵＡからの応答は、プロキシ・サーバを介して開始ＵＡに返送される。

ＳＩＰは、セッションが何かを実際には定義しないが、ユーザが招待されているそのセッションの説明は提供する。一実施形態では、ＩＮＶＩＴＥを受信する際、発呼側ＵＡは自動テストに携わり、そのテスト結果に基づいて正当なスパムまたは怪しいスパムであるというラベルをその呼に付ける。そのラベルに基づいて、その呼を処理するために別の行動（ドロップ、フィルタリング、着信音を鳴らす、ボイスメール転送）をとることができる。このテストは、着呼側の代わりに、その着呼側のＵＡ、プロキシ・サーバ、ハードウェア・エージェントまたはソフトウェア・エージェントが実行することができる。

本発明の実施形態は、あるスパマーが偽のＩＰアドレスおよびＳＩＰ ＵＲＩを使用する場合でさえ、望まれざる呼の効果的な検出を提供する。効果的な検出は、確立されるべき呼および配信されるべき内容を許可する前にも提供される。実施形態は、着呼側によって実施されるだけでよく、ＳＩＰプロトコルと完全に相互的に運用可能である。

本発明の実施形態は、完全なハードウェア実施形態、完全なソフトウェア実施形態、またはハードウェアとソフトウェアの両方の要素を含む実施形態をとることができる。好ましい実施形態では、本発明は、ファームウェア、常駐ソフトウェア、マイクロコードなどを含むが、これらに限定されないソフトウェア形式で実施される。

さらに本発明は、コンピュータまたは命令実行システムにより実行され、またはコンピュータまたは命令実行システムと関連して実行されるプログラム・コードまたは、かかるプログラム・コードを提供するコンピュータ使用可能な、またはコンピュータ可読の媒体の形態をとることができる。本説明のために、コンピュータ使用可能な、またはコンピュータ可読の媒体は、命令実行システム、装置またはデバイスにより、またはこれらと関連して使用するためのプログラムを含むか、格納するか、通信するか、伝播するか、または伝送するいかなる装置であってもよい。その媒体は、電子、磁気、光学、電磁気、赤外線または半導体システム（または装置またはデバイス）または伝播媒体であってもよい。コンピュータ可読媒体の例としては、半導体または固体メモリ、磁気テープ、取り外し可能なコンピュータ・ディスケット、ランダム・アクセス・メモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、固定磁気ディスクおよび光学ディスクが含まれる。現在の光学ディスクの例としては、コンパクト・ディスク（読み取り専用メモリ（ＣＤ−ＲＯＭ））、コンパクト・ディスク（読み取り／書き込み（ＣＤ−Ｒ／Ｗ））、およびＤＶＤが含まれる。

プログラム・コードを格納または実行あるいはその両方を行うために適したデータ処理システムは、メモリ素子にシステム・バスを介して直接または間接に結合された、少なくとも１つのプロセッサを含むことができる。メモリ素子は、実行中に大量記憶装置からコードが取り出される回数を減らすために、プログラム・コードの実際の実行中に使用されるローカル・メモリ、大量記憶装置、および少なくとも一部のプログラム・コードの一時記憶を提供するキャッシュ・メモリを含むことができる。入力または出力あるいはその両方またはＩ／Ｏデバイス（キーボード、ディスプレイ、ポインティング・デバイスなどに限定はしないがこれらを含む）は、介在するＩ／Ｏコントローラに直接に、またはＩ／Ｏコントローラを介して当該システムに結合することができる。

ネットワーク・アダプタは、データ処理システムが、介在する専用ネットワークまたは公共ネットワークを介して他のデータ処理システムまたは遠隔プリンタまたは記憶デバイスに結合するように、システムに結合することもできる。モデム、ケーブル・モデムおよびＥｔｈｅｒｎｅｔカードは、数個の現在使用可能なタイプのネットワーク・アダプタにすぎない。

類似の参照番号が同一または類似の要素を表す複数の図面を参照する。まず、ネットワーク電話システム用の、スパムまたは望まれざる呼を検出するためのシステムまたは方法を説明するためのブロック図／流れ図である図１を参照する。このシステムまたは方法は、ＳＩＰコールイン（ＩＮＶＩＴＥ）に応答するためのＳＩＰプロトコルのリダイレクト機能を使用する。

人間が文書を読んでいることを立証する多くの既存の機構がある。例えば光学文字認識（ＯＣＲ）をほぼ不可能にする画素ノイズのある文字である。類似の技術を、チャレンジ・メッセージの音声レンダリングに、例えばノイズを音声信号にミキシングするなどにより適用することができる。この際、人間の音声周波数帯を網羅する周波数要素を有するノイズは、音声認識ソフトウェアを狂わせる際に特に効果的である。

本発明の実施形態は、広範囲に配置されたプロトコルへの変更を必要とせずに、ＳＩＰプロトコル上にチャレンジ応答の統合を提供する点で有利である。この技術は、ＳＩＰまたはＶｏＩＰに対する自動化された発呼側検出回路を達成する。本発明は電話の適用例には限定されないが、以下では、電話呼に対するＳＩＰ交換を説明する。

典型的な電話交換は、インターネットまたはいかなる他のネットワークまたは通信リンクなどのネットワークを介して、発呼側が着呼側にＳＩＰ ＩＮＶＩＴＥを送信することを含む。着呼側は、（例えば、プロキシまたはエージェントから）ＣＯＮＮＥＣＴＩＯＮ ＩＮ ＰＲＯＧＲＥＳＳを受信する、すなわち着呼側のハンドセットのベルがなる。着呼側は、その電話に出る、すなわちその呼の受信を承諾し、その発呼側は肯定応答（ＡＣＫ）する。

本発明によると、ブロック１０２で、発呼側はＳＩＰ ＩＮＶＩＴＥメッセージを使用してＳＩＰ呼を開始する。ブロック１０４で、発呼側のＦｒｏｍアドレスまたはＦｒｏｍアドレスとＩＰアドレスの組合せが見つかったどうか、着呼側の周知のアドレス・ベースを確認し、そのプロトコルは、変更されないＳＩＰ経路を継続する。ブロック１０６で、着呼側のハンドセットまたはプロキシが、ランダム・チャレンジ文字（または単語または記号）を選択する。ブロック１０８で、ディスプレイ・チャレンジが発呼側に送信される。このディスプレイ・チャレンジは、ＯＣＲによる処理が困難な、人間に可読の文字セットを、発呼側のＳＩＰエンドポイントに含めることができる。

ブロック１１０で、発呼側に対する人間に可聴な文字のレンダリングが再生される。このレンダリングは、音声認識による解読を困難にしておくことが好ましい。ブロック１１２で、発呼側は、（発呼側が人間の場合）自分の通信機器のマイクロフォンまたはキーパッドを使用して、そのチャレンジに対する応答を転送し、着呼側が正確な応答を受信した場合には、ＳＩＰプロトコルＩＮＶＩＴＥが成功することになる。

頻繁な、または信頼のある発呼側に対する手順を簡約化するために、ＳＩＰ可能ハンドセットに、既知の発呼側に対する認証手順をディセーブルする高速呼ボタンを提供することができる。ＳＩＰ ＵＲＩまたは指紋のような既知の発呼側のＳＩＰプロファイルを、着呼側の電話に記憶することができる。例えば、ＳＩＰハンドセット上のＬＥＤ（または、ディスプレイ・メッセージ）は、発呼側が既に“既知の発呼側”の組に入っているか否か、また既知の発呼側が“許可”されているか否かを示す。

ブロック１０８および１１０では、宛先（着呼側）は、設定された長さのランダム・ストリングを生成し、そのストリングをイメージ、音声メッセージのどちらか、あるいはその両方に翻訳することができる。ブロック１１２で、宛先（プロキシまたはハンドセット）は、そのボディにメッセージ・チャレンジを含み、その添付としてランダムに生成されたイメージまたは音声メッセージあるいはその両方を含むリダイレクト・メッセージで応答する。電話またはプロキシがチャレンジ応答機構に気付くと、着呼側はイメージまたは音声メッセージあるいはその両方を発呼側のハンドセットにレンダリングする。ブロック１１４において、宛先は、そのリダイレクトされた呼に対する、そのリダイレクトまたは呼ＩＤを記憶する。

ブロック１１２で、発呼側はストリング（チャレンジ）に応答する。例えば、発呼側は、メッセージを聞くか、着呼側がレンダリングした指示を閲覧することができる。この応答は、そのストリングを読むことによりまたは１つまたは複数のキーを押すことにより（例えば、“＃”を押すか、またはそのイメージに応答する）、当該キーパッドに数字または単語を入力することを含むことができる。ブロック１１６で、応答が正確な場合、この応答はハンドセットを発呼側に接続／再接続させる。発呼側のハンドセットまたはプロキシは、チャレンジに対する回答と共にＩＮＶＩＴＥを、接続メッセージの本文に含めて送信する。

発呼側の電話またはプロキシがそのチャレンジ応答に気付かない場合、次にリダイレクトが続けられ、ＲＥＤＩＲＥＣＴメッセージは提起されたチャレンジに対して正確な回答を含まない。ブロック１１８で、着呼側の電話は、拒絶メッセージとともに、その招待をドロップするように構成することができる。着呼側の電話またはプロキシはメッセージ（例えば、ｌｘｘ）で回答することができるが、その電話は異なる着信音を鳴らすか、着呼側に警告するために失敗したチャレンジの何らかの指摘を提供することができる。ブロック１２０では、例えば、ＯＫメッセージによって受諾されるなどの条件付きで呼を受諾することができるが、着呼側のハンドセットはチャレンジの失敗の結果として着信音を鳴らさないように設定することができる。

ブロック１１０で、ランダム・ストリングの可聴レンダリングによって着呼側を促し、着呼側のキーパッドを使用してそのストリングを入力するように着呼側に求めることができる。そのチャレンジに対して正確に回答がなされた場合、着呼側のハンドセットは通常の着信音を鳴らす。その着信音が時間切れになると、上記のようにそのハンドセットはデータ接続を閉じ、切断イベントを発呼側に送信する。

図２を参照して、本発明の別の実施形態による非スパム呼の処理を説明するために、本発明の適用例を説明する。この例は、スパマーを検出するための自動エコー・テストであって、多数のＩＶＩＴＥを多くのＳＩＰ ＵＲＩに送信する自動エコー・テストを含むチャレンジを提供する。電話２０２で表される発呼側は、電話２０４で表される着呼側にＩＮＶＩＴＥ ２０６を送信する。これに応えて、着呼側２０４は、暫定ＡＣＫ（ＰＲＡＣＫ）２１０を引き出すために、例えば“１８３セッション進行中”応答などのチャレンジをあるパターンで発呼側２０２に送信する。ＰＲＡＣＫは暫定応答に対するＡＣＫだが、この場合はセッション進行中メッセージに対するＡＣＫである。このパターンは、通常の発呼側に対して負荷をあまり作らないように工夫されているが、他のユーザからのメッセージと組み合わされた場合にはスパマーに深刻な負荷を作ることができる。例えば、このパターンは、ある範囲（１０−５０パケットなど）からバースト・サイズがランダムに導き出されるバック・ツー・バック“１８３セッション進行中”のメッセージをバーストすることができる。工夫されたパターンの別の例は、ある範囲（１０−５００ミリ秒）からグループ間スペーシングもランダムに導き出すことができる場合の、複数のバースト・グループである。例えば、電話２０２がスパマーでない場合、その電話２０２はＰＲＡＣＫ２１０で応答する。プラック・パターンはテストされ、あるいは発呼側２０４から送信されたパターンと
される。その送信されたパターンが元の“１８３セッション進行中”パターン（すなわち、粗類似したグループ間スペーシング挙動を保有する）と類似している場合、ＯＫ信号が発呼側２０２に送信され、発呼側２０２は承認する（ＡＣＫ ２１４）。その呼が終了するまで（ＢＹＥ ２１８）、ある会話２１６または他の通信（データ交換など）を行うことができる。

図３を参照すると、最初の例、すなわちスパム呼が例証的に説明される。発呼側２２０がスパマーであり、完全なＳＩＰスタックを実行しない場合、電話２０４は、セッション進捗状況２０８に対する発呼側の応答または応答を引き出す他の信号の中に規則違反を観察することができる（例えば、ＰＲＡＣＫまたは不正確にフォーマットされたＰＲＡＣＫ）。電話２０２がスパマーであり完全なＳＩＰスタックを実行する場合、“１８３セッション進行中”プロービング・パターン２０８は、発呼側のシステムを交互にまたは付加的に圧倒する危険性があり（例えば、発呼側のネットワーク・リンク、パケット処理に関する発呼側のＳＩＰ実施態様内のバッファ、発呼側のメモリ利用、または発呼側のＣＰＵ利用）、これによってＰＲＡＣＫ応答にドロップまたは遅延を招くことになる。

いずれの場合でも、応答信号の比較が、規則違反、例えば不正確な応答パターンまたは応答なし（図４）を示す場合、着呼側２０４は、例えば、その呼を終了する（禁止２２２）またはその発呼側を発呼禁止リストに入れるなど、その呼に対して否定的に応答する。

初期ステップを取らない限り、場合によっては正当な呼の問題が発生する場合がある。例えば、降雪により会社は休みであるというような全従業員に対する自動告知は、そのメッセージの送信者が認証され、ホワイト・リストに入れられて、その呼がエコー・テストの前に自動的に終了可能となることを必要とする場合がある。

図５および６を参照すると、人間の発呼側をテストするための本発明の例証的な実施形態により、システム／方法３００が示されている。図５および６に示す例証的な実施形態では、チャレンジ・ジェネレータ３０２は、発呼側に対してチャレンジ３２２を生成する。チャレンジ３２２はランダムに生成することができ、複数のチャレンジ・タイプおよびアイテムと比較される乱数を含むことができる。例えば、このチャレンジは、一連の数字または記号または１つの音声クリップを含むことができ、ジェネレータ３０２によって生成された乱数に応じて複数の記号または音声クリップから選択することができる。このチャレンジの生成およびレンダリング（ブロック３０２および３０４）は、１つの呼が受信される前または後に実行することができる。

チャレンジ３２２がディスプレイ・タイプ３０７の場合には機械不可読のチャレンジをレンダリングするレンダリング・デバイス３０４にそのチャレンジが入力され、音声３０５の場合には音声認識またはスピーチ認識あるいはその両方が不可能なようにレンダリングされる。ディスプレイ・タイプ３０７の場合、ＯＣＲがその記号を正確に解読できないようにアレンジされた文字のイメージに、ノイズまたは無関係なピクセルを追加することができる。図６に示すように、数個の様々なフォントとサイズを有し、風変わりにアレンジされたグリッドをディスプレイ３０７に使用することができる。別の例として、ディスプレイまたは音声メッセージは、様々なフォントとサイズを有し、風変わりにアレンジされた文字で書かれた“タイプ２”であってよい。音声チャレンジ信号３１５（図６）は、（発呼側のスピーカ３１３に）解読不可能な音声信号をレンダリングするために音声信号を出力するようミキサー３０３を使用してノイズ３０９とミキシングすることができる。

このチャレンジは、ブロック３１０で次いで発呼側に返送される。その発呼側は次いで、そのチャレンジに応答できるならばそのチャレンジに応答する。“タイプ２”のチャレンジ例は、ある人間によってノイズを超えて判定されるほどに容易に可読である。その人間は、自分の電話機のキーパッド上にある数字２を押せばよいことを知っているので、そのチャレンジに対する適切な応答を提供する。

着呼側は、メッセージ・ボディに埋め込まれたこの応答を待つか、あるいはブロック３１２で、この応答を、元のチャレンジ３２２または異なる値を含んでよい、予め定めておいた受諾可能な応答と比較する。この応答が正確である場合、その発呼側が人間であるとみなされるので、その呼は接続される。

図７を参照すると、自動エコー・システムまたは自動エコー方法あるいはその両方が、例証的な実施形態によって例証的に説明されている。ブロック３５０で、ある呼が受信される。ブロック３５２では、その発呼側の指紋を取得することができる。一実施形態では、ＳＩＰ指紋が取得される。ＳＩＰ指紋は、測定されたＳＩＰプロトコル実施態様応答時間またはＳＩＰデバイスの挙動という１つの特性付けである。周知のＳＩＰデバイスのＳＩＰ指紋は、着呼側がアクセス可能なデータベースに維持することができる。方法は、図７で説明または図示あるいはその両方をしたように、他の複数のエコー・テスト方法とは別個に、またはこれらと連携して使用することができる。発呼側の指紋を取得することによって、着呼側は、その発呼側がコンピュータか、あるいは他の望まれざる発呼側であるかを容易に判定することができる。この方法は、すべてのデバイスを列挙できないなどの場合があるので、便利でない場合がある。

ブロック３５４で、発呼側に対して１つまたは複数の応答を要求するテスト・パターンを生成することができる。このテスト・パターンには、ＰＲＡＣＫおよびＯＰＴＩＯＮＳのような周知のＳＩＰ機能を含めることができる。このパターンは、チャレンジ・ジェネレータ３０２を使用してランダムに生成することができる（図６）。ブロック３５６で、このパターンがその発呼側に送信され、ブロック３５８で、その発呼側の応答がモニタされる。

ブロック３６０で、この応答は、受諾可能なエコー・パターンが存在するか否かを判定するために解析される。この解析には、その応答パターン（例えば、パケット間スペーシング、応答オーダリング）が元のテスト・パターンと相互に関連付けられること、または他の規則違反が判定されること、あるいはこれらの両方が行われることを示す正確なヘッダーを有することを確認するために、応答パケットをチェックすることを含むことができる。応答がない場合、またはそのパターンが不規則な場合、ブロック３６２で、その発呼側は機械またはスパマーであることが明示され、ブロック３６４で、その呼は終了される。それ以外の場合、その呼は続行することが許可され、その電話または他のデバイスは着信音を鳴らすことが許可される。

以上、（限定のためでなく、説明を目的とした）スパム検出のためのシステムおよび方法の好ましい実施形態を説明したが、当業者が上記の複数の教示に照らして複数の修正および変更を加えることができるということに留意されたい。したがって、添付の請求項で概要を示したように、本発明の範囲および趣旨の範囲内にある、開示された複数の特定の実施形態に変更を加えることができるということが理解されよう。以上、特許法により要求される細目および詳細事項により本発明の態様を説明したが、特許証により保護される、請求され、望まれる事項が、添付の請求項に記述されている。

本発明の一実施形態による、受諾可能なユーザの検証またはヒューマン・テストにおけるスパム検出あるいはその両方に関するブロック図／流れ図である。 本発明の一実施形態による、発呼側がスパマーでない場合の、受諾可能なユーザの検証またはエコー・テストにおけるスパム検出あるいはその両方を示す図である。 本発明の一実施形態による、不規則応答の受信により発呼側がスパマーであることが判定された場合の、受諾可能なユーザの検証またはエコー・テストにおけるスパムの検出あるいはその両方を示す図である。 本発明の一実施形態による、応答が受信されないことにより発呼側がスパマーであることが判定された場合の、受諾可能なユーザの検証またはエコー・テストにおけるスパム検出あるいはその両方を示す図である。 本発明の一実施形態による、受諾可能なユーザの検証またはヒューマン・テストに関するスパムの検出あるいはその両方を示すブロック図／流れ図を示す図である。 本発明の一実施形態による、受諾可能なユーザの検証またはスパムの検出あるいはその両方のためのシステムを示すブロック図である。 本発明の別の実施形態による、受諾可能なユーザの検証またはエコー・テストに関するスパムの検出あるいはその両方を示すブロック図／流れ図である。

符号の説明

ＳＩＰ セッション開始プロトコル
２０２ 電話
２０４ 電話
２０６ ＩＮＶＩＴＥ
２０８ １８３セッション進行中
２１０ 暫定ＡＣＫ（ＰＲＡＣＫ）
２１６ 会話
２２０ 発呼側
２２２ 禁止
３０２ チャレンジ・ジェネレータ
３０３ ミキサー
３０４ レンダリング・デバイス
３０７ ディスプレイ・タイプ
３０９ ノイズ
３１３ 発呼側のスピーカ
３１５ 音声チャレンジ信号
３２２ チャレンジ

Claims (8)

1. 着呼側の又は着呼側にサービスするコンピュータにおける発呼側を検証するための方法であって
   前記コンピュータが、呼を受諾する前に発呼側からの応答を必要とする、前記発呼側に送信されるべきチャレンジであって、機械による解読が困難となるようにノイズを挿入された前記チャレンジを生成するステップと、
   前記コンピュータが、前記発呼側からの前記チャレンジに対する応答の有無を判定するステップと、
   前記コンピュータが、前記発呼側が通信相手として受諾可能か否かを判定するために、前記応答を、予め定めておいた受諾可能な応答と比較して解析するステップと、
   前記応答が受諾可能であると判定することを条件に 前記発呼側に前記着呼側のコンピュータを接続するステップと
   を含む方法。
2. 前記ノイズを挿入されたチャレンジは、人間によって解読可能な、ノイズを挿入されたイメージを含む、請求項１に記載の方法。
3. 前記イメージは指示を含み、応答を解析するステップは、前記発呼側が前記指示に適切に応答しているか否かを判定するステップを含む、請求項２に記載の方法。
4. 前記ノイズを挿入されたチャレンジが、人間によって解読可能な、ノイズを挿入された音声を含む、請求項１に記載の方法。
5. 前記音声は指示を含み、応答を解析するステップは、前記発呼側が前記指示令に適切に応答しているか否かを判定するステップを含む、請求項４に記載の方法。
6. 前記コンピュータが、前記発呼側が受諾可能か否かを判定するために、セッション開始プロトコル（ＳＩＰ）プロファイルを使用して前記発呼側の指紋を取得するステップをさらに含む、請求項１に記載の方法。
7. 呼を受諾する前または前記呼が着呼側で発信音を鳴らすことを許可する前に発呼側からの応答を必要とする、前記発呼側に送信されるべきチャレンジであって、機械による解読が困難となるようにノイズを挿入された前記チャレンジを生成するステップと、
   前記発呼側からの前記チャレンジに対する応答の有無を判定するステップと、
   前記発呼側が通信相手として受諾可能か否かを判定するために、前記応答を、予め定めておいた受諾可能な応答と比較して解析するステップと、
   前記応答が受諾可能であると判定することを条件に 前記発呼側に前記着呼側のコンピュータを接続するステップと
   をコンピュータに実行させる、発呼側を検証するためのコンピュータ・プログラム。
8. 発呼側による通信の開始に応答して、前記発呼側に送信され、応答を要求するチャレンジであって、機械による解読が困難となるようにノイズを挿入された前記チャレンジを生成するチャレンジ・ジェネレータと、
   前記発呼側から前記チャレンジに対する応答が受信されたか否かを判定する判定モジュールと、
   前記発呼側が通信相手として受諾可能か否かを判定するために、前記応答が受諾可能か否かを、予め定めておいた受諾可能な応答と比較して判定する解析デバイスと、
   前記応答が受諾可能であると判定することを条件に 前記発呼側に前記着呼側のコンピュータを接続する接続モジュールと
   を含む、発呼側を検証するためのシステム。

Images