(第1実施形態)
以下、本発明に係るスパムデータを発信する端末の判定方法、判定装置、及び判定プログラムの第1実施形態について、図面を参照して具体的に説明する。以下の説明では、インターネットに接続している複数の端末の中から、VoIP(Voice over Internet Protocol)を利用して、不特定多数の他のユーザの端末に対して、不要な音声データ(以下、「VoIPスパム」という。)を発信する端末のSIP URI(Session Initiation Protocol Uniform Resource Identifier)を判定する判定方法、同判定方法を実施する判定装置、同判定方法を実現するためにコンピュータに実行させる判定プログラムに対して、本発明を適用した場合を例に挙げて説明するが、本発明は、これに限定されるものではなく、VoIPスパム以外の任意のスパムデータを発信する端末を判定する判定方法、判定装置、及び判定プログラムに対して適用することができるものである。
以下、VoIPスパムを発信する端末をVoIPスパマーと称し、VoIPスパマー以外の端末を通常ユーザと称する。なお、VoIPスパマーと通常ユーザとを区別しない場合には、これらを総称して単に端末と称する。
図1に示すように、本実施形態に係る判定装置1は、通常ユーザ3とVoIPスパマー5とが接続されているインターネット2と、SIPサーバ4との間に接続され、インターネット2を介して、各端末間で送受信されるデータパケットを監視して、通常ユーザ3へVoIPスパムを発信するVoIPスパマー5のSIP URIを判定する。
このように、本実施形態に係る判定装置1は、SIPサーバ4と、通常ユーザ3やVoIPスパマー5等のSIPクライアントとの間にIn-line接続することができるので、既存のシステムに付加的に挿入することが可能である。そして、この判定装置1に特定のSIP URIから発信されたデータパケットを破棄する処理機能を設けることによって、判定したVoIPスパマー5のSIP URIから発信されたデータパケットを破棄させ、VoIPスパマー5から発信されるVoIPスパムを通常ユーザ3に受信させなくすることができる。
インターネット2に接続されている通常ユーザ3及びVoIPスパマー5は、いずれもIP電話機能を備えた装置であり、SIPサーバ4は、ある端末から発信されたデータパケットに含まれる各種データに基づいて、そのデータパケットの発信元の端末と発信先の端末との接続に関する各種処理を実行する装置である。なお、以下、データパケットの発信元の端末を発信元端末、発信先の端末を発信先端末という。
本実施形態の判定装置1は、各ユーザ間の通話履歴に基づいて、その端末がVoIPスパマー5であることの信頼度を示すスコア(指標)を各端末のSIP URI毎に計算し、その結果得られるスコアが所定の閾値より高い端末をVoIPスパマー5であると判定するように構成している。スコアの具体的な算出方法については、後に詳述する。
この判定装置1は、図2の右下部に示すように、各端末がVoIPスパマー5であるか否かを判定するためのテーブルを備えている。本実施形態では、このテーブルに示すように、端末のスコアが0〜29の範囲内であれば、その端末を通常ユーザ3、端末のスコアが30〜79の範囲内であれば、その端末をVoIPスパマー5であるか否かが疑わしい端末、端末のスコアが80〜100の範囲内であれば、その端末をVoIPスパマー5と判定する。
そして、この判定装置1は、図2の右上部に示すように、各端末のSIP URIと、その端末のスコアと、その端末が通常ユーザ3なのか、VoIPスパマー5であるか否かが疑わしい端末なのか、VoIPスパマー5なのかを示すアラートとを、所定の表示装置に表示させる。
特に、この判定装置1では、各端末の通話履歴に基づいて、同一の端末から発信されたデータパケットの各発信先端末間の関係度合いを評価して、その関係度合いが強いほど高い値をとるクラスター係数を求め、このクラスター計数を用いて、発信元端末のスコアを計算し、このスコアを用いて発信元端末がVoIPスパマー5であるか否かを判定することによって、VoIPスパマー5がVoIPスパムを発信する時間間隔を長くした場合であっても、その端末を的確にVoIPスパマー5であると判定可能としている。
すなわち、VoIPスパマー5は、無作為に選択したSIP URIの端末に対して、VoIPスパムを発信するため、VoIPスパムの発信先として選択された複数の発信先端末の各ユーザ間には、知人関係等の人間関係がない可能性が高い。一方、通常ユーザ3であれば、データパケットを発信する際、発信先端末として知人等の人間関係があるユーザの端末を選択するので、発信先端末の各ユーザ間には知人等の人間関係がある可能性が高い。そのため、発信先端末のユーザ間に人間関係が存在していれば、そのユーザ間で過去にデータパケットの送受信が行われている可能性も高くなる。
この特徴を利用して、本実施形態の判定装置1では、各端末の通話履歴であるデータパケットの送受信に関する履歴情報から、同一の端末から発信されたデータパケットの発信先端末間における関係度合いを示すクラスター計数を求め、そのクラスター計数を用いて、データパケットの発信元端末がVoIPスパマー5である信頼度を示すスコアを計算し、その結果得られるスコアが所定の閾値より高い場合に、その送信元端末をVoIPスパマー5と判定するように構成している。
上記のように、VoIPスパマー5は、無作為にVoIPスパムの発信先端末を選択するので、VoIPスパムの発信先端末のユーザ間に関する人間関係までを考慮してVoIPスパムを発信することができない。この判定装置1では、このVoIPスパマー5が介入することが困難な、VoIPスパムの発信先端末間における関係度合いを考慮して、データパケットの発信元端末がVoIPスパマー5であるか否かを判定するので、データパケットの発信元端末がVoIPスパマー5であるか否かを的確に判定することができる。
ここで、判定装置1が各端末のスコアを計算する際に用いるクラスター係数について、図3を参照して説明する。図3に示す「●」はデータパケットの発信元端末を、「○」はデータパケットの発信先端末を、「−」は発信元端末と発信先端末との間のリンクを表している。ここでリンクとは、発信元端末から発信先端末へ過去にデータパケットが発信されたことを表している。
図3に示すように、発信先端末間にリンクが存在していた場合、それら発信先端末のユーザ間に知人関係等の人間関係があると考えられ、その発信元端末が通常ユーザ3であると判定することができる。一方、発信元端末と発信先端末との間にはリンクが存在するが、発信先端末間には存在しない場合、発信先端末のユーザ間に人間関係がないと考えられ、その発信元端末はVoIPスパマー5と判定することができる。この場合、クラスター係数は、通常ユーザ3の方がVoIPスパマー5よりも高い数値をとる。
クラスター係数は、発信元端末と、その発信元端末との間でリンクが構成されたことのある2つ発信先端末とによって構成される三角形によって求められる。クラスター係数を求めたいユーザxと、任意の発信先端末y、zで三角形が構成されるかどうかは、ユーザx、y間にリンクが存在するかどうかをLxyとした場合に、
という数式1を用いて表すことができる。ここで、Δは、スコア算出対象となる発信元端末のユーザxと、その発信元端末が過去にデータパケットを発信した発信先端末のうちの2つの端末のユーザy、zとの関係を考えた場合に、これらユーザx、y、zの間に、共通の知人関係等という人間関係が存在するか否かを表している。
本実施形態では、2者間で通話が行われたことを知人であるとしている。上記式1におけるLxyは、ユーザx、y間で過去に通話が行われていたか否かを表す。ユーザx、y間で通話が行われていた場合、Lxy=1、通話が行われていなかった場合、Lxy=0となる。Lyz、Lzxについても同様の意味を表す。
これら、Lxy、Lyz、Lzxを掛け合わせた値がΔとなる。すなわち、このΔは、ユーザxとユーザyとの間に、過去に通話履歴があり、且つ、ユーザyとユーザzとの間に、過去に通話履歴があり、且つ、ユーザzとユーザxとの間に、過去に通話履歴があった場合に、Δ=1となる。ここで、ユーザy、zは、ユーザxの過去の通話履歴から選択された発信先端末であるため、Lxy、Lzxの値は常に1となる。このΔにおいては、発信先端末同士であるユーザyとユーザzとの間に過去に通話履歴があったか否かが重要となる。
つまり、ユーザyとユーザzとの間に過去に通話履歴があったということは、ユーザx、y、zの間には、共通の知人関係等といった所定の人間関係が存在するということになる。そして、ユーザxに関して、Δ=1となるユーザy、xの組み合わせの数が多いほど、ユーザxが過去に人間関係に沿ったデータパケットの発信を行っていたということになり、そのユーザxの端末がVoIPスパマー5である可能性が低いと判定することができる。
本実施形態におけるクラスター係数は、このΔ=1となるユーザy、zの組み合わせの多さを表している。ここで、クラスター係数Cxを算出する具体的な計算方法について説明する。
クラスター係数Cxを求める際には、まず、上記Δの総和であるNΔを求める。このNΔは、クラスター係数Cxの算出対象となるユーザxの端末(発信元端末)がリンク先の端末(発信元端末との間にリンクが存在する発信先端末)と構成する三角形の総和を表す。このNΔは、
という数式2を用いて表すことができる。そして、ユーザxの端末が過去にデータパケットを発信した全ての発信先端末の数をkとしたとき、ユーザxの端末のクラスター係数Cxは、
という数式3で表すことができる。このクラスター係数は、ユーザxの端末と、このユーザxの端末が過去にデータパケットを発信した全ての発信先端末とで、リンクによる三角形が構成されたと仮定した場合に、その三角形の数中に、実際に構成された三角形が何個存在したかを表している。
そのため、全ての発信先端末のユーザ間に人間関係が全くない場合には、クラスター係数Cx=0となり、発信先端末のユーザ間に人間関係が十分ある場合には、クラスター係数は、「1」に近くなる。このクラスター係数Cxは、上記のように発信元端末の過去の通信履歴により決定されるものであり、発信先端末のSIP URIを無作為に選択するVoIPスパマー5からは、意図的に変更することができない。本実施形態の判定装置1では、このクラスター係数Cxを用いて、発信元端末のスコアを算出する。
本実施形態では、スコアをScとした場合、Sc=100−100×Cxという式によりスコアScを算出する。なお、スコアScを算出する方法は、これに限定するものではなく、クラスター係数Cxを用いて、発信元端末がVoIPスパマー5であることの信頼度の高さを求めることができる方法であれば、他の任意の方法により求めてもよい。たとえば、ベイジアンネットワークを利用して、クラスター係数Cxの値からVoIPスパマー5である確率を算出し、その確率を100倍したものをスコアScとして用いてもよい。
そして、判定装置1は、上記のようにして算出した発信元端末のスコアScと予め決定した閾値とを比較し、この閾値よりも高いスコアScの発信元端末をVoIPスパマー5と判定する。この閾値は、複数のVoIPスパマー5のサンプルを用意し、そのサンプルのスコアScの平均値とする。
なお、この閾値の決定方法についても、上記方法に限定するものではなく、スコアScから精度よくVoIPスパマー5を判定できるものであれば、他の任意の決定方法により決定してもよい。たとえば、通常ユーザ3のサンプルを用意し、そのサンプルのスコアScの標準偏差を求め、この標準偏差から閾値を求めてもよい。また、閾値として、「80」等、経験則から所定の値を閾値として固定してもよい。
そして、本実施形態では、こうして算出したスコアSc及び閾値を用いて、通常ユーザ3に対して、VoIPスパム対策を目的としたサービスを提供するようにしている。ここで、本実施形態により提供可能なサービスの一例について図4を参照して説明する。
サービス(1)
本実施形態によれば、図4に示すように、スコア情報を利用した迷惑電話ふりわけサービスを提供することができる。このサービス(1)は、予め通常ユーザ3に、VoIPスパムだけを振り分けて着信させる留守番電話(留守電)6を設け、判定装置1によりVoIPスパムと判定されたデータパケットをこの留守電に着信させる。これにより、VoIPスパムが送りつけられても通常ユーザ3の着信音が鳴らないので、通常ユーザ3をVoIPスパムの被害から守ることができる。
サービス(2)
また、本実施形態によれば、図4に示すように、スコア提供サービスを提供することができる。このサービス(2)では、通常ユーザ3にVoIPスパマー5を判断させるためのスコアの範囲を予め設定しておく。判定装置1は、通常ユーザ3へ発信されたデータパケットのシグナリング情報中に、そのデータパケットの発信元端末のスコアScを挿入する。そして、通常ユーザ3は、受信したシグナリング情報に挿入された発信元端末のスコアScと、予め設定されたスコアの範囲とから、VoIPスパムと判定した場合に、着信を拒否する。
ここでは、シグナリング情報に挿入されているスコアScが0〜29の範囲内であれば着信を許可し、スコアScが30〜100の範囲内であった場合に着信を拒否するように設定している。なお、この通常ユーザ3に設定するスコアScの範囲は、各ユーザが任意に設定変更可能に構成する。
次に、本実施形態における判定装置1の具体的構成について、図5を参照して説明する。図5は、判定装置1の構成を示す機能ブロック図である。この図5に示すように、判定装置1は、パケット処理部100と、制御部110と、記憶部120とを備えている。
パケット処理部100は、発信元端末から発信先端末へ送信されるデータパケットの内容を監視する。パケット監視部101と、パケット監視部101の監視結果に基づいて、データパケットからスコアScの算出に必要な特定の情報を抽出して取得するパケット情報取得部102とを備えている。これらパケット監視部101及びパケット取得部102は、制御部110により所定の判定プログラムが実行されることによって、所定の動作を行う。
パケット監視部101は、スコアScを求めるために必要なユーザ統計情報を抽出するためのSIPパケットが来るかどうかを監視する。SIPパケットは、INVITE、BYE、CANCEL、200OK、である。
パケット情報取得部102は、パケット監視部101によりSIPパケットが来たことが検知されると、そのSIPパケットを取得して、後述のユーザ統計情報抽出部111へ送信する。
制御部110は、CPU(Central Processing Unit)とROM(Read Only Memory)とRAM(Random Access Memory)とを備えたコンピュータにより構成しており、CPUがROMに記憶している判定プログラムを読み出して、RAMを作業領域として使用し実行することによって、パケット情報取得部102から受信したSIPパケットから、データパケットの送受信に関するユーザ統計情報を抽出して取得するユーザ統計情報抽出部111、スコアScを算出するスコア計算部112、各SIP URIに対応する発信元端末のスコアScに基づいて、その発信元端末がVoIPスパマー5であるか否かを判定するVoIPスパマー判定部113等として機能する。
ユーザ統計情報抽出部111は、パケット情報取得部102から受信したSIPパケットのSIPヘッダ、IPヘッダ、の情報を参考にユーザ統計情報を抽出する。そして、このユーザ統計情報抽出部111は、ユーザ統計情報を抽出する際、SIPパケットのSIPヘッダのFrom URI、To URI、Method、Call_ID、Status Code、Reason Phrase、Cseqとパケット取得時間(時刻)とから、後述のコールテーブルにおける各項目(発信元、発信先、Call_ID、通話開始時間(時刻)、通話終了時間(時刻))を抽出する。なおユーザ統計情報抽出部111は、それ以外のSIPパケットではユーザ統計情報を抽出しない。
本実施形態では、発信元のINVITEに対する200OKが発信元から返ってきた時間(時刻)を通話開始時間(時刻)としている。このとき、ユーザ統計情報抽出部111は、発信元、発信先、Call_ID、通話開始時間(時刻)をコールテーブルに書き込む。また、ユーザ統計情報抽出部111は、BYEが送られてきた場合には、そのCall_ID、発信元、発信先に対応するデータをコールテーブルから探し(発信元、発信先はコールテーブルのデータと逆になっている場合がある。)、そのBYEが届いた時間(時刻)を通話終了時間(時刻)として書き込む。
また、ユーザ統計情報抽出部111は、CANCELが送られてきた場合には、その発信先、発信元、Call_IDに対応するコールテーブルのデータに、CANCELが届いた時間(時刻)を通話開始時間(時刻)、通話終了時間(時刻)として書き込む。
そして、ユーザ統計情報抽出部111は、このコールテーブルを基にして、後に詳述するユーザ間コールテーブルを作成する。ユーザ間コールテーブルは、発信元、発信先のペアでユニークなものである。ユーザ統計情報抽出部111は、コールテーブルの発信元、発信先と同じペアを、ユーザ間コールテーブルから探し、そのレコードを更新する。同じペアがない場合、ユーザ統計情報抽出部111は、新たに、そのペアをユーザ間コールテーブルに作成する。
また、ユーザ統計情報抽出部111は、コールテーブルの通話開始時間(時刻)、通側終了時間(時刻)、発信元と発信先との間の通話時間を求め、ユーザ間コールテーブルにその通話時間と、通話回数に加え、総通話時間を更新する。なお、スコアScを算出するためのユーザ間コールテーブルのために、コールテーブル相当のものを端末のメモリ上で一時的に保持し、直接ユーザ間コールテーブルに書き込んでもよい。
スコア計算部112は、各発信元端末のSIP URI毎に、上記式1を用いてΔを算出した後、上記式2を用いてΔの総和であるNΔを算出し、その後、上記式3を用いて、スコアScを算出して、その結果得られるスコアScを後述のユーザスコア情報記憶部122に記憶させる。
このスコア計算部112が算出するΔは、前述のように、スコアの算出対象の端末とその発信先端末のうち2つの発信先との人間関係の程度を表すものである。ここで、Δの算出方法の具体的一例を説明する。
スコア計算部112は、スコアの算出対象の端末に関する全ての発信先端末の中から、2つの発信先端末を選択してΔを算出する。このとき、スコア計算部112は、全ての2つの発信先端末の組み合わせ分計算する。
たとえば、ある発信元端末xがスコアの算出対象、a、b、c、dが端末xの発信先端末とすると、これらの全ての組み合わせは、(x,a,b)、(x,a,c)、(x,a,d)、(x,b,a)、(x,b,c)、(x,b,d)、(x,c,a)、(x,c,b)、(x,c,d)、(x,d,a)、(x,d,b)、(x,d,c)となる。そして、スコア計算部112は、これら全ての組み合わせについてΔを計算する。なお、(x,a,b)、(x,b,a)など順序を入れ替えれば同じ組み合わせとなる組み合わせに関しては、計算手順を少なくするために、(x,b,a)のΔは、(x,a,b)のΔの結果を用いてもよい。Lxyは、ユーザ間コールテーブルの発信元x、発信先y、もしくは、発信元y、発信先xというレコードがあれば1となり、なければ0となる。
VoIPスパマー判定部113は、予め設定された閾値と、スコア計算部112により計算したスコアScとを比較して、閾値以上のスコアScに対応する端末のSIP URIをVoIPスパマー5と判定する。そして、このVoIPスパマー判定部113は、VoIPスパマー5と判定した端末のSIP URIを後述のVoIPスパマー記憶部124に書き込んで記憶させる。
記憶部120は、ユーザ統計情報記憶部121と、ユーザスコア情報記憶部122と、スコア閾値記憶部123と、VoIPスパマー記憶部124とを備えている。この記憶部120は、大容量の不揮発性メモリにより構成している。
ユーザ統計情報記憶部121は、図6(a)に示すコールテーブルと、図6(b)に示すユーザ間コールテーブルとを記憶している。図6(a)に示すように、コールテーブルは、発信元として、各発信元端末のSIP URI、その発信元端末からデータパケットが発信された発信先として、発信先端末のSIP URI、そのときの通話におけるCall_ID、そのときの通話における通話開始時刻、そのときの通話における通話終了時刻がそれぞれ記憶されている。
また、ユーザ間コールテーブルには、発信元端末のSIP URIと、そのSIP URIから発信されたデータパケットの発信先端末のSIP URIとが対(ペア)で記憶されており、各発信元端末と発信先端末との間で行われた通話の総通話時間と、総通話回数とが記憶されている。
ユーザスコア情報記憶部122には、スコア計算部112により算出された各発信元端末のスコアScが各発信元端末のSIP URIに対応して記憶されている。また、スコア閾値記憶部123には、スコアScと比較する前述した閾値が記憶されている。
VoIPスパマー記憶部124には、VoIPスパマー判定部113によりVoIPスパマー5と判定された発信元端末のSIP URIが記憶されている。
次に、制御部110のCPUが本実施形態に係る判定プログラムを実行する際の情報処理について説明する。まず、ユーザ統計情報を抽出する際に、制御部110で実行されるユーザ統計情報の抽出フロー(1)について説明する。
判定装置1により、ユーザ統計情報の抽出を行う際に、制御部110では、図7に示すように、パケット処理部100にパケットを取得させる処理が実行され(ステップS100)、その後、取得したパケットがINVITE、BYE、CANCEL、200OKか否かの判断が行われる(ステップS101)。
そして、制御部110では、取得したパケットがINVITE、BYE、CANCEL、200OKであると判断された場合(ステップS101:Yes)、ユーザ統計情報抽出部111にSIPヘッダとパケットの取得時間(時刻)からユーザ統計情報を抽出させる処理が実行され、取得したパケットがINVITE、BYE、CANCEL、200OKでないと判断された場合(ステップS101:No)、処理が終了される。
そして、制御部110では、ステップS102で抽出されたユーザ統計情報を記憶部120のユーザ統計情報記憶部121に記憶させる。このとき、ユーザ統計情報における発信元(発信元端末のSIP URI)、発信先(発信先端末のSIP URI)、Call_ID、通話開始時間(時刻)、通話終了時間(時刻)をコールテーブルに書き込ませる処理が実行される(ステップS103)。
その後、制御部110では、ユーザ統計情報記憶部121へ、コールテーブルを利用して、ユーザ間コールテーブルの発信元、発信先、総通話時間、総通話回数を上書きさせる処理が実行され、処理が終了される。
ここでは、コールテーブルとユーザ間コールテーブルとがいずれも記憶部120に記憶されている場合について説明したが、コールテーブルとユーザ間コールテーブルとを判定装置1の記憶部120とは別体のデータベースに記憶可能に構成した場合には、コールテーブルの作成と、ユーザ間コールテーブルとを、それぞれ別々の処理フローにより作成することができる。
この場合、制御部110では、図8に示すユーザ統計情報の抽出フロー(2)に示す処理が実行される。このユーザ統計情報の抽出フロー(2)に示す処理が開始されると、制御部110では、ステップS200〜ステップS203の処理が実行されて、コールテーブルが作成される。また、制御部110では、図8に示すステップS204の処理が実行されて、ユーザ間コールテーブルが作成される。このステップS200〜ステップS203で実行される処理は、図7に示したステップS100〜ステップS103で実行される処理と同一の処理であり、ステップS204で実行される処理は、図7で示したステップS104で実行される処理と同一の処理であるため、ここでは、その説明を省略する。
次に、判定装置1がオフラインでスコアScを算出し、その結果得られるスコアScからVoIPスパマー5を判定する際に、制御部110実行される処理について、図9を参照して説明する。このオフラインでのスコアScの算出を開始するタイミングは、1日ごと、2日ごと等、任意のタイミングで設定したタイミングで算出することができるように構成している。
オフラインでスコアScを算出する際、制御部110では、図9に示すように、まず、ユーザ間コールテーブルからスコア算出対象のk(スコア算出対象の発信元端末が過去に通話した発信先端末の数)を計算する処理を行う(ステップS300)。このとき、スコア算出対象の端末のSIP URIは、全てのSIP URIや、前回のスコアSc算出時より10回以上発信を行っている端末のSIP URI等、任意の条件で設定できるように構成している。
その後、制御部110では、ユーザ間コールテーブルからΔを計算させる処理が実行される(ステップS301)。このΔを計算させる処理については、後に図10を参照して具体的に説明する。
次に、制御部110では、ステップS300で計算したkと、ステップS301で計算したΔとからクラスター係数Cxを計算させる処理が実行される(ステップS303)。この処理では、前述した式3を用いて計算される。
次に、制御部110では、ステップS303で計算したクラスター係数CxからスコアScを計算させる処理が実行される(ステップS304)。ここでは、前述のように、Sc=100−100×Cxという式を用いて計算される。
次に、制御部110では、ステップS303で計算したスコアScと、スコア閾値記憶部123に記憶している閾値とを比較して、スコアScが閾値以上のユーザのSIP URIをVoIPスパマー5と判定する処理が行われ(ステップS304)、その後、ステップS304でVoIPスパマー5と判定されたSIP URIをVoIPスパマー記憶部124に書き込ませる処理が実行された後(ステップS305)、処理が終了される。
次に、図9に示したフローチャートのステップS301で実行されるΔの算出処理を行うことによって、Δを算出する際の具体的一例について説明する。ここでは、判定装置1が図10の右表に示すようなユーザ間コールテーブルが記憶されている場合に、Δを算出する際の一例について説明する。
Δを求める際には、まず、ユーザ間コールテーブルを参照して、スコア算出対象の端末xの過去の発信先を調べる。ここで端末xのSIP URIが050-XXXX-5697であった場合、発信先端末のSIP URIは、050-XXXX-1111、050-XXXX-2222、050-XXXX-3333、050-XXXX-4444、050-XXXX-5555となる。
次に、発信先の中からyとして未選択のyを選ぶ。このとき、上記4つの発信先の中からyを選択する。ここでは、発信先端末のyとして、SIP URIが050-XXXX-1111の端末を選んだとする。
次に、発信先の中から、zとして未選択のzを選ぶ。このとき、zはyと異なるSIP URIの端末を選択する。ここでは、他の発信先端末のzとして、SIP URIが050-XXXX-2222の端末を選んだとする。この場合、ユーザ間コールテーブルからy-z間で過去に通話が行われていることが分かるため、このx、y、zでの組み合わせでΔ≠0となる。
次に、x、yは前回と同じままで、zとして未選択のzを選ぶ。ここでzとしてSIP URIが050-XXXX-3333の端末を選んだとする。この場合、ユーザ間コールテーブルからy-z間で過去に通話が行われていないことが分かるため、Δ=0となる。その後、zの選択を繰り返し行う。
そして、未選択のzがなくなれば、次に未選択のyを選び、yを固定したまま、同様に未選択のzを選んでΔの計算を繰り返す。SIP URIが050-XXXX-5697の端末の発信先の5つの端末について、全ての組み合わせでΔを求める。
ここで、上記のように全ての組み合わせでΔを求める際に、制御部110で実行されるΔの算出処理について、図10の左フローチャートを参照して具体的に説明する。判定装置1でΔを算出する際に、制御部110では、図10に示すように、まず、Δの算出対象となるユーザxの過去の発信先をユーザ間コールテーブルから調べさせる処理が実行される(ステップS400)。
続いて、制御部110では、未選択の発信先yがあるか否かが判定され(ステップS401)、未選択の発信先yがあると判断された場合(ステップS401:Yes)、その発信先の中から一つの発信先yを選ぶ処理が実行され(ステップS402)、未選択の発信先yがないと判断された場合(ステップS401:No)、処理が終了される。
ステップS402において一つの発信先yが選択されると、制御部110では、ユーザ間コールテーブルから未選択の発信先zがあるか否かが判断され(ステップS403)、未選択の発信先zがあると判断された場合(ステップS403:Yes)、未選択の発信先zから一つの発信先zを選択する処理が実行され(ステップS404)、未選択の発信先がないと判断された場合(ステップS403:No)、処理がステップS401へ移行する。
ステップS404において一つの発信先zが選択されると、x、y、zのΔを算出させる処理が実行される(ステップS405)。このとき、前述の式1を用いてΔが算出され、その後、処理がステップS403へ移行する。
また、本実施形態の判定装置1では、図9のフローチャートを用いて説明したオフライン処理によるスコアScの算出及びVoIPスパマー5の判定に関する処理をオンライン時のリアルタイム処理として実行することもできるように構成している。
このリアルタイム処理は、ユーザ統計情報を取得しつつスコアScを計算する処理である。本実施形態では、INVITEを取得したときに、そのINVITEの発信元端末に関して、前回スコアScを計算した時点から、その端末が規定回数(例えば、10回)発信していた場合に、その端末のスコアScを計算する。なお、スコアScの計算については、判定装置1がINVITEを取得する度に毎回行うように構成してもよい。
次に、スコアScの算出及びVoIPスパマー5の判定に関するリアルタイム処理について、図11を参照して説明する。このリアルタイム処理において、制御部110では、図11に示すように、まず、パケット処理部100にパケットを取得させるパケット処理が実行され(ステップS500)、その後、ステップS500で取得したパケットからユーザ統計情報を抽出する処理が実行される(ステップS501)。
その後、制御部110では、ステップS501で抽出したパケットがINVITEか否かの判断が行われ(ステップS502)、INVITEでないと判断された場合(ステップS502:No)、処理が終了され、INVITEであると判断された場合(ステップS502:Yes)、INVITEを送った端末のSIP URIを抽出する処理が実行される(ステップS503)。
その後、制御部110では、ステップS503で抽出したSIP URIの端末に関して、前回スコアScを計算したときから、その端末が規定回数発信を行ったか否かが判断され(ステップS504)、規定回数発信を行っていないと判断された場合(ステップS504:No)、処理が終了され、規定回数発信を行ったと判断された場合(ステップS504:Yes)、INVITEを送ったSIP URIのスコアScを計算する処理が実行される(ステップS505)。なお、ステップS504における規定回数については、任意の回数を設定可能に構成している。
そして、制御部110では、ステップS505で算出したスコアScをユーザスコア情報記憶部122に書き込みを行わせる処理が実行され(ステップS506)、次に、そのスコアScが閾値以上であるか否かが判断される(ステップS507)。
ここで、制御部110により、スコアScが閾値未満であると判断された場合(ステップS507:No)、処理が終了される。一方、制御部110では、スコアScが閾値以上であると判断された場合(ステップS507:Yes)、そのスコアScに対応するSIP URIをVoIPスパマー5を行うユーザのSIP URIと判定して(ステップS508)、そのSIP URIをVoIPスパマー記憶部124に書き込ませる処理が実行され(ステップS509)、その後、処理が終了される。
上記のように、第1実施形態の判定装置1では、インターネット2等の通信ネットワークに接続している複数の端末の中から、他の端末へスパムデータ(たとえば、VoIPスパム)を発信するスパム発信端末(VoIPスパマー5)を判定する際に、各端末間で送受信されるデータパケットから、そのデータパケットの送受信に関する送受信情報(たとえば、INVITE等)を取得し、当該取得した送受信情報を各データパケットの送受信履歴情報(たとえば、ユーザ統計情報)としてユーザ統計情報記憶部121に記憶させる。
そして、判定装置1では、記憶した送受信履歴情報に基づいて、同一の前記端末から発信されたデータパケットの発信先となっている複数の各発信先端末間の関係度合いを評価し、その関係度合いに基づいて、データパケットの送信元となっている発信元端末がスパム発信端末であることの信頼度を示すスコアScを計算する。
その後、判定装置1では、計算した発信元端末のスコアScと、予め設定した所定の閾値とを比較して、スコアScが所定の閾値より高い、又は、閾値以上の発信元端末をスパム発信端末と判定する。
このように、本実施形態の判定装置1では、VoIPスパマー5がVoIPスパムの発信先端末としてランダムに選択した発信先端末のユーザ間に人間関係が存在する可能性が低いことに着目し、過去にデータパケットを発信した発信元端末の中で、データパケットの発信先端末間の関係度合いが低い場合に、その発信元端末をVoIPスパマー5である可能性が高いと判定するので、仮に、VoIPスパマー5がVoIPスパムの発信間隔を長く設定した場合であっても、精度よくVoIPスパマー5を特定することができる。
さらに、この判定装置1では、各端末のスコアScを計算する際に、発信先端末間でデータパケットの送受信が行われていた場合に、当該発信先端末間の前記関係度合いが高いと評価し、関係度合いが高いと評価した発信先端末の対が少ないほど、発信元端末のスコアScとして高いスコアScを算出する。つまり、この判定装置1では、発信先端末間で行われた通信履歴に基づいて、発信先端末のユーザ間の人間関係を間接的に評価している。
VoIPスパマー5は、VoIPスパムの発信先端末のユーザに関する人間関係までを考慮してVoIPスパムを発信することができない。本実施形態の判定装置1では、このようにVoIPスパマー5が介入することのできない発信先端末のユーザ間における人間関係を評価して、人間関係がないと評価したユーザの端末へデータパケットを発信し続けている発信元端末をVoIPスパマー5と判定するため、VoIPスパマー5がVoIPスパムの発信タイミングを変更しても、的確にそのVoIPスパマー5を判定することができる。
(第2実施形態)
次に、本発明の第2実施形態について説明する。第2実施形態では、VoIPスパマー5と通常ユーザ3とのクラスター係数を拡張して、両クラスター係数の間に、より大きな差を生じさせてスコアの差を大きくすることによって、VoIPスパマー5の誤判定や、VoIPスパマー5の特定漏れを防止するVoIPスパマー5の判定方法について説明する。なお、以下の説明において、第1実施形態と同様のものには、同一の符号を付して説明する。
VoIPスパマー5が無作為に選択した不特定多数の発信先端末へVoIPスパムを発信した場合であっても、その宛先(SIP URI)によっては、偶然にVoIPスパマー5と2つの発信先端末によって、リンクの三角形が構成されることが予想される。
この場合、偶然に構成されたリンクによる三角形の数が多いと、実際にはVoIPスパムを発信しているにもかかわらず、その端末を通常ユーザ3と誤判定する可能性もある。そこで、この第2実施形態では、VoIPスパマー5が2つの発信先端末とリンクによる三角形を構成しても、その三角形がクラスター係数をあまり大きくしないように、リンクによる三角形に強度の違いを設ける。
三角形に設ける強度は、三角形を構成する格端末のユーザ間における人間関係の強さを表すために用いる。これは、VoIPスパマー5は、発信先端末からデータパケットを受信する可能性が低く、また、VoIPスパムは、不要な内容の音声データであるため通話時間が短いという特徴があり、これらのことから、VoIPスパマー5と通常ユーザ3とでは、三角形を構成する発信先端末との間の人間関係に差が生じると考えられるからである。
図12に、強度の異なる三角形と、その三角形におけるスコア算出対象の発信元端末に関するクラスター係数とを示している。
図12では、スコア算出対象の発信元端末を「●」、この発信元端末が過去にデータパケットを発信した発信先端末を「○」で示しており、第1実施形態のクラスター係数をCx、第2実施形態における拡張したクラスタ係数をCx´で示している。いずれのクラスター係数Cx、Cx´も、その数値が1に近いほど、発信元端末が通常ユーザ3である可能性が高いことを示している。
図12のVoIPスパマーの欄に示すように、発信元端末がVoIPスパマー5であり、その2つの発信先端末間に偶然にリンクが存在していた場合、すなわち、VoIPスパムを受信した端末のユーザ同士が、たまたま知人同士であった場合、第1実施形態の方法では、発信元端末と2つの発信先端末とによって三角形が構成されているため、VoIPスパマー5を通常ユーザ3であると誤判定するおそれがある。
そのため、第2実施形態では、3つの端末でリンクによる三角形が構成されている場合に、スコア算出対象の発信元端末が、発信先端末からデータパケットを受信したことがあれば、その三角形の強度が高く、データパケットを受信したことがなければ、その三角形の強度が低いと評価する。
図12に示す例では、スコア算出対象の端末が通常ユーザ3の三角形の場合は、発信元端末が発信先端末から受信も行っているので、三角形の強度が高く、クラスター係数Cx´も最大の1と高い値をとっている。
一方、スコア算出対象の端末がVoIPスパマー5の三角形の場合は、発信元端末が発信先端末から受信をしたことがないので、三角形の強度が低く、クラスター係数Cx´も0.1と低い値をとっている。
リンクの方向性は、発信元端末と発信先端末とで決める。第1実施形態では、ユーザx、y間のリンクをLxyとしていたのを、第2実施形態では、ユーザxからユーザyへのリンクをLxyと、ユーザyからユーザxへのリンクをLyxとに分けるようにしている。
具体的には、第1実施形態では、リンクの有無をLxyが「1」か「0」かであらわしていたものを、第2実施形態では、ユーザxからユーザyへのリンクの重みをWxyとし、0〜1で表す。リンクの重みは、各端末間の総通話時間によって決定する。
本実施形態では、総通話時間が0〜60secのときはWxy=0.1、60〜120secのときはWxy=0.2、・・・、総通話時間が600sec以上のときはWxy=1.0というように、通話時間を区切ってWxyを決定する。なお、リンクの重みWxyに関しては、各端末間の総通話回数によって決定してもよい。また、スコア算出対象の発信元端末が受信した方向での通話に重みを起きたい場合、その重みWyxに係数α(1、2、・・・)をかける。この場合、2以上の値を選択する。
すなわち、受信によるリンクを重視するため、Wyx、Wzxにαの係数(α≧1)を儲け、通常ユーザ3とVoIPスパマー5とで、リンクによる三角形の強度に差を生じさせる。リンクの方向性、重みを導入後のΔ´は、
という数式4により算出する。
また、このΔ´を用いて拡張したクラスター係数Cx´は、
という数式5により算出する。そして、このようにして算出したクラスター係数Cx´を用いて、第1実施形態と同様の式により各端末のスコアScを算出し、スコアScが所定の閾値を超えた端末をVoIPスパマー5と判定する。
上記のように、第2実施形態におけるVoIPスパマー5の判定方法では、スコアScを算出する際に、発信元端末へデータパケットを送信した発信先端末の数が少ないほど、発信元端末のスコアとして高いスコアを算出するようにしている。すなわち、発信元端末と発信先端末とのユーザ間の人間関係に基づいて、VoIPスパマー5を判定している。
これにより、VoIPスパマー5からVoIPスパムを受信した発信先端末のユーザ間に、偶然に人間関係があったとしても、VoIPスパマー5と発信先端末とのユーザ間に人間関係が存在する可能性が低いと判断した場合には、その発信元端末をVoIPスパマー5であると的確に判定することができる。
また、第2実施形態におけるVoIPスパマー5の判定方法では、発信先端末と発信元端末との間でのデータパケットの通信時間が短いほど、及び/又は、通信回数が少ないほど、発信元端末と発信先端末との間のリンクが弱いと判定して、発信元端末のスコアとして高いスコアを算出する。
これにより、VoIPスパマー5からVoIPスパムを受信した発信先端末間に、偶然にリンクが存在した場合であっても、そのリンクが弱ければ、その発信元端末をVoIPスパマー5であると的確に判定することができる。
(第3実施形態)
次に、本発明の第3実施形態について説明する。ここでも、第1実施形態と同様のものには、同一の符号を付して説明する。上記した第1実施形態においてクラスター係数Cxを求める式(式3)では、数式の特性上、通常ユーザ3であっても多くの発信先端末へ発信するほどクラスター係数が小さくなる傾向がある。
そのため、上記した式3を用いた場合、クラスター係数が最大の1.0の値をとるためには、全ての発信先端末間にリンクが存在していなければならない。発信先端末のユーザ同士に知合い関係等の人間関係があった場合であっても、それらの発信先端末間にリンクが存在しないことが想定される。
そのため、第3実施形態では、スコアScを算出際に用いるNΔと、Cxをさらに拡張し、その拡張したNΔ´´とCx´´とを用いてスコアScを算出して、VoIPスパマー5を判定する。第1実施形態のクラスター係数Cxは、スコア算出対象の端末がリンク先の端末と構成する三角形の数をカウントし、正規化には、全てのリンク先の端末間にリンクが存在した場合のリンクによる三角形の数を用いていた。
これに対して、第3実施形態では、スコア算出対象の端末のリンク先となった発信先端末のうち、いくつの発信先端末がリンクによる三角形を構成するかに着目し、クラスター係数Cx´´を求める式の分子は、各リンク先の発信先端末が構成する三角形のうちの最も強度が高い三角形の強度の和とする。リンクによる三角形が構成されない発信先端末の最も強度が高い三角形の強度は「0」となる。また、正規化するためには、リンク先の端末数を用いる。
これにより、たとえば、図13の右部分に示すように、スコア算出対象の端末(図13中に示す「●」)が、リンク先の発信先端末(図13中に示す「○」)とリンクにより構成する三角形の数が、図13左部分に示すスコア算出対象の端末より少なくても、リンク先の発信先端末と1つでもリンクによる三角形を構成している状態であれば、クラスター係数Cx´´が1.0になる。
スコアSc算出対象の端末が、一つの発信先端末と、他の複数の発信先端末とによって、リンクによる複数の三角形を構成していた場合、その中で、最も強度の高い三角形を選択して、スコアSc算出対象の端末が、前述の一つの発信先端末と構成するリンクによる三角形とする。第3実施形態のCx´´は、
という数式6により算出する。そして、このようにして算出したクラスター係数Cx´´を用いて、第1実施形態と同様の式により各端末のスコアScを算出し、スコアScが所定の閾値を超えた端末をVoIPスパマー5と判定する。
第1実施形態に記載したクラスター係数Cxを用いた場合、通常ユーザ3であっても、発信した発信先端末の数が増えると、クラスター係数Cxが小さくなり、非常に小さくなった場合、VoIPスパマー5と誤判定される可能性がある。
クラスター係数Cxが小さくなる理由は、第1実施形態の場合、スコア算出対象の端末について、全ての発信先端末同士間で通話が行われていないと、クラスター係数Cxが発信先端末数の2乗に反比例して小さくなるためである。
スコア算出対象の端末が通常ユーザ3であっても、発信先端末数が非常に多い場合には、それら全ての発信先端末同士において通話が行われている可能性は低い。しかし、発信先端末同士全てにおいて通話が行われてはいないが、1つか2つの発信先端末となら通話がなされている可能性は高い。
そのため、第3実施形態では、その点を考慮し、発信先端末のうち、いくつの端末がスコア算出対象の端末とリンクによる三角形を構成するかを求めることによって、発信先端末数が多い通常ユーザ3のクラスター係数Cx´´が小さくなることを防止して、通常ユーザ3をVoIPスパマー5であると判定する誤判定の発生を抑制している。
ここで、第3実施形態におけるクラスター係数Cx´´の算出手順の一例について、図14を参照して説明する。図14では、クラスター係数を求める端末に符号1、この端末の発信先でクラスター係数を求める複数の端末にそれぞれ符号2、3、4、5、6を付しており、「●」は、クラスター係数Cx´´を求めるユーザ、「○」は、クラスター係数Cx´´を求めるユーザの発信先を示している。図14において、符号1の端末のユーザをx、符号2の端末のユーザをyとすると、ユーザzの候補は他のユーザ(符号3〜6の端末)となる。
クラスター係数Cx´´を計算する際に、このzを符号3〜6の端末に順次代えた場合、各組み合わせの三角形のうち、最も強度の高い三角形を選択する。このとき、ユーザx、yの端末は固定し、ユーザzの端末を入れ替えた場合の組み合わせは、各端末に付した符号で表すと(1,2,3)、(1,2,4)、(1,2,5)、(1,2,6)となる。
この中から最も三角形におけるリンクの強度が高い三角形を選択することが、式6におけるΣの中の意味である。強度は、式6におけるmaxの中の式で求められる。例えば、1−2間、1−4間、2−4間の通話時間が、他のユーザ間との通話時間よりも非常に長かった場合、(1,2,4)の組み合わせが選択される。これにより、符号2の端末にとっての、リンクの強度が最も高い三角形が求められ、式の和として求められる。
次は、ユーザyを符号3の端末とした場合に、zを符号2、4、5、6の端末に代えて、同様にリンクの強度が最も高い三角形を選択する。また、同様にyを4、5、6の端末とした場合についても、それぞれのyについて、リンクの強度が最も高い三角形を選択する。
符号5の端末のように、リンクによる三角形が構成されない端末の場合、つまり符号5の端末は、他の発信先端末と通話を行っていない場合は、全てのzにおいて、リンクの強度Wyz、Wzyが「0」なので、リンクの強度が最も高い三角形の強度は「0」となる。
符号2、3、4、5、6の端末のそれぞれについて、リンクの強度が最大の三角形が選択されれば、拡張したクラスター係数Cx´´を求めることができる。そして、こうして算出したクラスター係数Cx´´を用いて、第1実施形態と同様の式により各端末のスコアScを算出し、スコアScが所定の閾値を超えた端末をVoIPスパマー5と判定する。
上記のように、第3実施形態におけるVoIPスパマー5の判定方法では、スコアScを算出する際に、各発信先端末が複数の発信先端末との間でデータパケットの送受信を行っていた場合、各発信先端末間の通信時間、及び/又は、通信回数に応じた各発信先端末間の関係度合いの強度値を算出し、各発信先端末に関する最も高い前記強度値同士の総和値が低いほど、発信元端末のスコアとして高い前記スコアを算出する。
これにより、スコア算出対象の通常ユーザ3が、非常に多くの発信先端末と過去に通話していた場合、いくつかの発信先端末間で過去に通話が行われていなくても、それ以外の発信先端末間で通話が行われ、その通話による発信先端末間のリンクの強度が高かった場合には、クラスター係数Cx´´が小さくならず、スコアScが低くなるので、その通常ユーザ3を誤ってVoIPスパマー5と判定し難くなる。
上記した第1〜第3実施形態では、図1に示したように、通常ユーザ3とVoIPスパマー5とが接続されているインターネット2と、SIPサーバ4との間に判定装置1を接続して、各端末間で送受信されるデータパケットを監視し、通常ユーザ3へVoIPスパムを発信するVoIPスパマー5のSIP URIを判定する場合を例に挙げて説明したが、判定装置1の接続位置はこれに限定するものではない。
例えば、図15に示すように、本実施形態の判定装置1は、インターネット2において、SIPサーバ4と、通常ユーザ3やVoIPスパマー5等のSIPクライアントとの中間にTAP7等のターミナルアダプタを介して、Out-line接続することもできる。このように判定装置1をOut-line接続する場合においても、既存のシステムに付加的に判定装置1を接続することができる。
また、本実施形態に係るVoIPスパマー5の判定方法を実現するためには、必ずしも判定装置1を設ける必要はなく、たとえば、図16に示すように、既存のSIPサーバ4の内部に、本実施形態に係るVoIPスパマー5の判定方法をコンピュータに実現させるVoIPスパマー5のSIP URI判定プログラム(ソフト)8を組み込むことによっても実現することができる。
かかる構成とする場合、VoIPスパマー5のSIP URI判定プログラム8は、SIPサーバ用ソフトとは別のプロセスとして動作させる。そして、SIPサーバ4は、このVoIPスパマー5のSIP URI判定プログラム8を実行して、ネットワークインターフェース9から、データパケットを取得する。
このように、SIPサーバ4内に、SIPサーバ用ソフトとは別のプロセスで動作するVoIPスパマー5のSIP URI判定プログラム8を設けることによって、VoIPスパマー5のSIP URIを特定した際に、SIPサーバ用ソフトにより実行中の対象となるプロセスにおいて、そのユーザからのデータパケットを破棄する処理を即座に通知できるので、VoIPスパマー5から発信されるVoIPスパムを通常ユーザ3に受信させなくすることができる。