説明

フィルタリング装置

【課題】各人がフィルタしたいメールアドレスや電話番号、URLを設定する必要があるため、各人、毎回設定する必要があり、非常に煩雑な作業になっている。
【解決手段】システム内に蓄積されているフィルタ対象のメールアドレスやドメインを集合知として利用して、メールフィルタリングをする。

【発明の詳細な説明】
【技術分野】
【0001】
本発明は、フィルタリング装置に係り、特に迷惑メール、迷惑電話、インターネット接続のフィルタリング装置に関する。
【背景技術】
【0002】
従来、一方的に送りつけられる宣伝メール等の迷惑メールの受信拒否をするために、迷惑メールが送信される毎に受信拒否メールとして対象のメールアドレス、またはドメインを設定する必要があった。
【0003】
特許文献1の技術は、利用者宛に届いた電子メールを利用者が迷惑メールと判断し、そのメールを電子メールサービス提供者へフィルタリング対象の電子メールとして転送する。電子メールサービス提供者は、メールの受信者が受信を拒否したいメールの内容文からURL、電話番号等の情報を記憶装置に蓄積する。次回以降、その受信宛のメール内容に同一URL、同一電話番号が含まれる場合、電子メールサービス提供者は当該受信者へ送信しない。
【先行技術文献】
【特許文献】
【0004】
【特許文献1】特開2003−263391号公報
【発明の概要】
【発明が解決しようとする課題】
【0005】
昨今、1日当りの迷惑メールの受信回数は増加している。しかも、迷惑メールの送信者は、ドメイン名を巧妙に変化させて送信している。このため、各人にて1件ずつ受信拒否設定し、迷惑メールを回避する事が非常に困難になってきている。また、その問題は、電子メールだけにとどまらず、電話、インターネットによる詐欺行為など多岐に渡っている。
【課題を解決するための手段】
【0006】
受信拒否対象として各人が設定したメールアドレス、ドメイン、電話番号、URLは、フィルタリング装置内に蓄積する。蓄積されたフィルタリング情報について、フィルタリング装置は、集合知として集計する。ここで、集合知は、多くの人による大量のフィルタリング情報の寄せ集めである。
【0007】
集計した情報を用いることで、多数の他者がフィルタリング設定した電子メール(迷惑メール)を受信した場合、かつ登録したドメインと類似したドメインのとき、フィルタリングする。電話の場合においても、本人以外の大多数の人が通話拒否としている番号からの通話を拒否する。さらに、特定のURLへのアクセスの際にも接続可否判定を行なう。
【0008】
上述した課題は、複数のユーザ装置と配信装置とに接続され、この配信装置からのデータをユーザ装置の一つに送信するか否かを、配信装置またはユーザ装置からの要求に基づいて判定し、複数のユーザ装置から受信したフィルタリング情報について、そのドメインを第1のカテゴリに分割して、この第1のカテゴリごとにフィルタリング情報について、集合知データベースに重複集積し、要求に添付された問合せ情報について、そのドメインを第2のカテゴリに分割して、この第2のカテゴリをキーとして集合知データベースを検索し、検索においてヒットしたとき、そのヒット件数の割合に基づいて、データの送信の可否を配信装置またはユーザ装置に応答するフィルタリング装置により、達成できる。
【発明の効果】
【0009】
集合知を利用することで、他者が登録した迷惑先のメールアドレス、電話番号、URL等をフィルタリングに利用できる。
【図面の簡単な説明】
【0010】
【図1】フィルタリングシステムのブロック図である。
【図2】携帯電話の画面である。
【図3】フィルタリングシステムの動作を説明するシーケンス図である。
【図4】集合知データベースの更新を説明する図である。
【図5】集合知データベースの更新処理のフローチャートである。
【図6】集合知データベースである。
【図7】集合知データベースの検索処理のフローチャートである。
【発明を実施するための形態】
【0011】
以下、本発明の実施の形態について、実施例を用い図面を参照しながら説明する。なお、実質同一部位には同じ参照番号を振り、説明は繰り返さない。また、以下の実施例では、迷惑メールのフィルタリングを説明するが、これに限らない。
【0012】
図1を参照して、フィルタリングシステムを説明する。図1において、フィルタリングシステム500は、ネットワーク400に接続されたn台の携帯電話200と、メールサーバ300と、フィルタリング装置100とから、構成される。また、フィルタリング装置100は、バス180に接続されたネットワークI/F110、メモリコントローラ130、ディスクコントローラ150、メモリコントローラ130に接続されたCPU120とメインメモリ140、ディスクコントローラ150に接続されたユーザ情報データベース160と集合知データベース170から構成される。
【0013】
メインメモリ140は、集計機能部141、条件判定部142、メモリバッファ部143、ディスクスケジューラ部144を保持する。集計機能部141および条件判定部142は、プログラムであり、メインメモリ140のプログラムをCPU130が実行することにより、集計機能部141および条件判定部142を実現する。ネットワークI/F110は、フィルタリング装置100をネットワーク400に接続する。
【0014】
集計機能部141は、携帯電話200から、ユーザ情報(電子メールアドレス)、各人が携帯電話200に設定した集合知条件情報およびフィルタリング(受信拒否)対象のメールアドレスまたはドメイン情報を受信する。集計機能部141は、各人のユーザ情報(電子メールアドレス)について、ユーザ情報データベース160に書込む。集計機能部141は、また集合知条件情報について、ユーザ情報データベース160へ書き込む。
【0015】
集合知条件情報とは、当該フィルタリングシステム内に蓄積されている集合知情報(各人が設定したフィルタリング対象のメールアドレス・ドメイン情報群)のうち、上位何%以上のメールアドレス・ドメインを、自身が受信する電子メールのフィルタリング対象とするかの割合を定義している情報である。
条件判定部142は、メールサーバ300にて受信した携帯電話200宛の電子メールの送信可否を判定する。
【0016】
フィルタリング装置100は、メールサーバ300から携帯電話200宛の電子メール107を受信した場合、ユーザ情報データベース160から、ユーザ情報(受信した電子メールの送信先メールアドレス)をキーとして、フィルタリング情報および集合知条件情報を取得する。フィルタリング装置100は、受信した電子メールの送信元電子メールアドレス情報をキーとして、集合知データベース170より集合知情報を取得する。取得したフィルタリング情報、集合知条件情報および集合知情報を元に、携帯電話200への送信可否を決定し、送信可否判定結果をメールサーバ300へ送信する。
【0017】
図2を参照して、携帯電話の画面を説明する。図2において、携帯電話200の画面は、フィルタ情報入力部201、集合知条件選択部202、送信ボタン203を表示する。フィルタ情報入力部201は、携帯電話利用者によるフィルタリングを行ないたい電子メールアドレスまたはドメインの入力を受ける。集合知条件選択部202は、プルダウン形式となっており、割合を選択する。送信ボタン203は、押下を受け付けることで、当該情報がフィルタリングシステム500へ送信する。
【0018】
図3を参照して、フィルタリングシステムの処理シーケンスを説明する。図3において、携帯電話200は、集計処理部141に、ユーザ情報、フィルタリング(受信拒否)対象のメールアドレス・ドメイン情報であるフィルタリング情報、集合知条件情報を送信する(S32)。集計処理部141は、受信したユーザ情報に基づいてユーザ情報データベースを更新する(S33)。集計処理部141は、受信した集合知条件情報に基づいて集合知データベースを更新する(S34)。
【0019】
ここで、ネットワーク400に接続され、図1に図示しないメール送信機は、メールサーバ300に携帯電話200宛のメールを送信する(S41)。メールサーバ300は、条件判定部142にフィルタ判定検索要求を送信する(S42)。条件判定部142は、集計処理部141に集合知検索要求を送信する(S43)。集計処理部141は、集合知データベースを検索する(S44)。集計処理部141は、条件判定部142に集合知検索結果応答を送信する(S46)。条件判定部142は、集計処理部141にカテゴリ検索要求を送信する(S47)。集計処理部141は、集合知データベースを検索する(S48)。集計処理部141は、条件判定部142にカテゴリ検索結果応答を送信する(S49)。条件判定部142は、メールサーバ300に判定結果応答を送信する(S51)。ここでは、判定結果が「フィルタリングしない」だったので、メール送信機は、携帯電話200にメールを送信する(S52)。
【0020】
ステップ34の集合知データベースの更新に伴ない、集計機能部141は、フィルタリング情報のカテゴリ分けを実施する。
なお、ここではメールサーバ(情報配信装置)からフィルタ判定検索要求を送信したが、WEB閲覧の場合、携帯電話機からフィルタ判定検索要求を送信し、フィルタリング装置がフィルタリング要否を、携帯電話に応答してもよい。これは、他のフローチャートでも同様である。
【0021】
このカテゴリ分けについて、図4を参照して、説明する。図4において、図4(a)は更新前の集合知データベース170A、図4(b)は更新後の集合知データベース170Bである。本実施例において、カテゴリとは、フィルタリング情報として受信したメールアドレスのドメイン部をドット毎で分割した単位である。受信したフィルタリング対象情報がドメイン情報の場合も同様である。ただし、com、jpなどの予約語は非該当とする。
【0022】
以下、新たに受信したフィルタリング対象情報は、メールアドレスであるaaaaa@abc.def.co.jpとする。図4(a)において、更新前の集合知データベース170Aは、abcカテゴリとyyyyカテゴリからなる。abcカテゴリは、2件のメールアドレスがそれぞれ2件および1件登録されている。一方、yyyyカテゴリも、2件のメールアドレスがそれぞれ2件および1件登録されている。
【0023】
受信したメールアドレスは、aaaaa@abc.def.co.jpなので、カテゴリは、abcカテゴリとdefカテゴリである。集合知データベース170Aには、abcカテゴリが存在し、しかもメールアドレスaaaaa@abc.def.co.jpが存在する。そこで、集計機能部141は、更新後の集合知データベース170Bについて、abcカテゴリのメールアドレスaaaaa@abc.def.co.jpの登録件数をインクリメントする。また、集合知データベース170Aには、defカテゴリが存在しないので、集計機能部141は、defカテゴリを新規追加する。さらに、集計機能部141は、defカテゴリに、メールアドレスaaaaa@abc.def.co.jpを、1件登録する。すなわち、メールアドレスaaaaa@abc.def.co.jpは、2つのカテゴリで重複して、登録される。この結果、集合知データベース170Bの登録件数は、集合知データベース170Aの登録件数(6件)から、2件増えた8件となる。
【0024】
図5において、集計機能部141は、フィルタリング情報について、カテゴリ分割を実施する(S11)。集計機能部141は、集合知データベースについて、一致するカテゴリを検索する(S12)。集計機能部141は、一致するカテゴリが存在するか判定する(S13)。YESのとき、集計機能部141は、該当するカテゴリにフィルタリング情報を追加または更新する(S14)。集計機能部141は、登録したフィルタリング情報の全体に占める割合を計算する(S16)。集計機能部141は、再計算結果を集合知データベースに登録する(S17)。ステップ13において、集計機能部141は、新規カテゴリを作成し(S18)、ステップ14に遷移する。
なお、ステップ12からステップ14までは、カテゴリの数だけ繰り返す。
【0025】
図6および図7を参照して、カテゴリ検索処理を説明する。図6において、集合知データベース170Cは、abcカテゴリ、cdeカテゴリ、cde1カテゴリ、fghカテゴリを含んでいる。各カテゴリは、登録されたメールアドレスと、そのメールアドレスが全体に占める割合を登録する。
【0026】
図7において、集計機能部141は、カテゴリ分けを実行する(S21)。集計機能部141は、集合知データベースからカテゴリを前方一致検索する(S22)。集計機能部141は、すべてのカテゴリについて、検索を実行したか判定する(S23)。NOのとき、集計機能部141は、ステップ22に戻る。ステップ23でYESのとき、集計機能部141は、該当のカテゴリに対して該当メールアドレスの割合を検索する(S24)。集計機能部141は、すべてのカテゴリについて検索を実施したか判定する(S26)。NOのとき、集計機能部141は、ステップ24に戻る。ステップ26でYESのとき、集計機能部141は、検索結果を条件判定部142に送信する(S27)。
【0027】
図6および図7を参照して、さらに具体的な動作を説明する。ここで、フィルタリング情報は、メールアドレスabc@cde.fgh.co.jp、集合知条件情報は10%以上とする。また、集合知データベースは、図6の集合知データベース170Cとする。
【0028】
図7のステップ21において、取得されるカテゴリはcdeおよびfghである。ステップ22において、検索キーは、cde*およびfgh*である。ここで、「*」は、前方一致を意味する正規表現である。また、ステップ22において、検索結果は、cde*に対してcdeおよびcde1である。一方、fgh*に対してfghである。ステップ24において、検索キーは、cde、cde1およびfghである。ステップ24において、検索結果は、cdeに対して5%、cde1に対して15%およびfghに対して1%である。ステップ27において、検索結果は10%以上を含んでいるので、メールアドレスabc@cde.fgh.ne.jpは、フィルタリング対象とする応答となる。
【0029】
ステップ22での検索方法として、完全一致のみならず正規表現を用いた前方一致にて検索を行なう。前方一致にてカテゴリを検索することで、似通ったカテゴリ(ドメイン)もフィルタリング判定の材料とすることを可能となる。なお、ステップ24において、検索するメールアドレスは、前方一致で検索されたカテゴリに関しては、送信元メールアドレスの当該部分を変更して検索する。つまり、cde1カテゴリについては、メールアドレスabc@cde1.fgh.co.jpで検索する。
【0030】
上述した実施例に依れば、送信元メールアドレスでフィルタリング対象とならない場合でも、似通ったメールアドレスでフィルタリング対象となった場合、当該メールについて、メールサーバはフィルタリングを実行し、携帯電話へ送信しないことができる。正規表現を用いれば、排他的な検索等細かい条件下の検索を実行できる。
【0031】
なお、上述した実施例では、フィルタリング対象は、メールとしたが、これに限らず送信元電話番号、URL等、任意の情報に基づいて、フィルタリングを行なうことができる。
【符号の説明】
【0032】
100…フィルタリング装置、110…ネットワークI/F、120…CPU、130…メモリコントローラ、140…メインメモリ、141…集計処理部、142…条件判定部、143…メモリバッファ、144…ディスクスケジューラ、150…ディスクコントローラ、160…ユーザ情報データベース、170…集合知データベース、180…内部バス、200…携帯電話、300…メールサーバ、400…ネットワーク、500…フィルタリングシステム。

【特許請求の範囲】
【請求項1】
複数のユーザ装置と配信装置とに接続され、この配信装置からのデータを前記ユーザ装置の一つに送信するか否かを、前記配信装置または前記ユーザ装置からの要求に基づいて判定するフィルタリング装置において、
複数の前記ユーザ装置から受信したフィルタリング情報について、そのドメインを第1のカテゴリに分割して、この第1のカテゴリごとに前記フィルタリング情報について、集合知データベースに重複集積し、
前記要求に添付された問合せ情報について、そのドメインを第2のカテゴリに分割して、この第2のカテゴリをキーとして前記集合知データベースを検索し、
検索においてヒットしたとき、そのヒット件数の割合に基づいて、前記データの送信の可否を前記配信装置または前記ユーザ装置に応答することを特徴とするフィルタリング装置。
【請求項2】
請求項1に記載のフィルタリング装置であって、
前記ドメインの分割は、ドットごとであることを特徴とするフィルタリング装置。
【請求項3】
請求項1または請求項に記載のフィルタリング装置であって、
前記第2のカテゴリに正規表現を付加したキーとして前記集合知データベースを検索することを特徴とするフィルタリング装置。

【図1】
image rotate

【図2】
image rotate

【図3】
image rotate

【図4】
image rotate

【図5】
image rotate

【図6】
image rotate

【図7】
image rotate


【公開番号】特開2010−286973(P2010−286973A)
【公開日】平成22年12月24日(2010.12.24)
【国際特許分類】
【出願番号】特願2009−139181(P2009−139181)
【出願日】平成21年6月10日(2009.6.10)
【出願人】(000005108)株式会社日立製作所 (27,607)
【Fターム(参考)】