(57)【要約】【課題】  信頼性が確認されている電話発信者の属性情報を電話受信者に知らせる【解決手段】  発信者の電話端末から、受信者の電話番号を含む通話発信と、発信者の電話番号と、を受け付け、受け付けた発信者の電話番号を取得し、当該電話番号に基づいて発信者の属性情報を取得し、電話交換部が、受信者の電話番号に基づいて、通話発信と、発信者の電話番号と、発信者の属性情報とを、受信者の電話端末に送付することによって、電話受信者は発信者の信頼された情報を得て安心して通話することができる。【選択図】  図１
2016019069.tif 000002
【特許請求の範囲】
【請求項１】
電話交換部が、発信者の電話端末から、受信者の電話番号を含む通話発信と、前記発信者の電話番号と、を受け付ける通話発信受付工程と、
電話番号検証部が、前記電話交換部が受け付けた発信者の電話番号を取得し、当該電話番号に基づいて、前記発信者の属性情報を取得する属性情報取得工程と、
前記電話交換部が、前記受信者の電話番号に基づいて、前記通話発信と、前記発信者の電話番号と、前記発信者の属性情報とを、前記受信者の電話端末に送付する通話発信交換工程と、
を含む電話番号検証方法。
【請求項２】
請求項１において、
前記電話交換部は、発信者側の電話交換部であり、前記通話発信交換工程では、受信者側の電話交換部を介して前記受信者側の端末に送付することを特徴とする電話番号検証方法。
【請求項３】
請求項１または２において、
前記発信者情報取得工程では、前記属性情報とともにその証明書を取得し、
前記通話発信交換工程では、前記属性情報とともに、前記証明書または当該証明書が有効であることを送付することを特徴とする電話番号検証方法。
【請求項４】
請求項１乃至３のいずれかにおいて、
前記電話番号を、前記発信者の代表電話番号に変換する工程を含み、
前記属性情報取得工程では、当該代表電話番号に基づいて、発信者の属性情報を取得することを特徴とする電話番号検証方法。
【請求項５】
請求項３において、
前記取得した証明書を検証する証明書検証工程を含み、
前記証明書の検証に成功した場合には、前記証明書または当該証明書が有効であることを送付し、
前記証明書の検証に失敗した場合に、新しい証明書を取得して、前記検証した証明書が記憶されていた記憶部に格納することを特徴とする電話番号検証方法。
【請求項６】
請求項１乃至５のいずれかにおいて、
前記通話発信と、前記発信者の電話番号を送付し、その後に前記発信者の属性情報を送付する電話番号検証方法。
【請求項７】
請求項１乃至５のいずれかにおいて、
前記電話交換部は、前記発信者の属性情報を取得した後に、前記受信者の電話番号に基づいて前記通話発信と、前記発信者の電話番号と、前記発信者の属性情報とを送付することを特徴とする電話番号検証方法。
【請求項８】
請求項１乃至７のいずれかにおいて、
前記発明者の属性情報を、SMS Message、またはWebにより、前記受信者の端末に送信することを特徴とする電話番号検証方法。
【請求項９】
発信者の電話端末から、受信者の電話番号を含む通話発信と、前記発信者の電話番号と、を受け付ける電話交換部と、
前記電話交換部が受け付けた発信者の電話番号を取得し、当該電話番号に基づいて、前記発信者の属性情報を取得する電話番号検証部と、
を備え、
前記電話交換部が、前記受信者の電話番号に基づいて、前記通話発信と、前記発信者の電話番号と、前記発信者の属性情報とを、前記受信者の電話端末に送付する、
ことを電話番号検証システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、電話発信者の保証された情報を受信者に知らせる技術に関するものである。
【背景技術】
【０００２】
金融機関や警察署からの電話と信じ込ませ、多額の現金を騙し取る、いわゆる「振り込め詐欺」が近年多発している。例えば警察署からの電話を装う場合、犯人は詐欺被害者(以下、「被害者」と記述する)に口頭で警察からの電話であると申告し、被害者に警察署からの通話と信じ込ませるという手口がある。
【０００３】
このような「なりすまし」は、電話の発信者の身元(法人名等)を受信者に通知することで、ある程度回避できる。
【０００４】
例えば、通信事業者が提供する発信者電話番号の通知サービスにより、電話の着信時に、受信者の電話機に発信者の電話番号を表示できる。また、電話機自身が有する電話帳機能(以下、「ローカル電話帳」と記述する)により、あらかじめ当該ローカル電話帳に登録された、法人等の名称を表示することもできる。
【０００５】
また、番号非通知の呼び出しを、通信会社または電話端末により遮断する機能もある。非通知の通話をすべて遮断すると詐欺犯以外からの通話も遮断してしまうため、呼び出しを遮断する電話番号の一覧(以下「ブラックリスト」という)を、あらかじめ通信事業者の側で準備し、発信者の電話番号が、当該ブラックリストに含まれる場合にのみ通信を遮断する技術が、特許文献１で開示されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２０１３−００５２０５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、受信者側の電話帳に、最新の全国の電話番号を事前にすべて登録しておくことは、実現が困難である。また、ブラックリストにより通話を遮断する場合、詐欺犯は次々と新たな電話番号を使用すればこれを回避でき、解決とはならない。
【０００８】
本発明は、上記課題を考慮し、発信者の身元を受信者に知らせ、受信者がより適正に対処できるようにすることを目的とする。
【課題を解決するための手段】
【０００９】
上記課題を解決するために、本発明では、発信者の電話端末から、受信者の電話番号を含む通話発信と、発信者の電話番号と、を受け付け、受け付けた発信者の電話番号を取得し、当該電話番号に基づいて発信者の属性情報を取得し、電話交換部が、受信者の電話番号に基づいて、通話発信と、発信者の電話番号と、発信者の属性情報とを、受信者の電話端末に送付する。
【発明の効果】
【００１０】
本発明によれば、発信者の属性情報を受信者に知らせることができ、受信者がより適正に発信者の身元を認識することが可能となる。
【図面の簡単な説明】
【００１１】
【図１】本発明の実施の形態にかかる電話番号検証システムの一構成例を示す機能ブロック図である。
【図２】図１中の通信事業者Ａ Ｓｙｓｔｅｍの構成例を示す図である。
【図３】図１中のＶｅｒｉｆｙ Ｓｙｓｔｅｍの構成例を示す図である。
【図４】図１中の法人台帳 Ｓｙｓｔｅｍの構成例を示す図である。
【図５】図１中の通信事業者Ｂ Ｓｙｓｔｅｍの構成例を示す図である。
【図６】図１中の番号変換ＤＢの構成例を示す図である。
【図７】図１中の契約者属性ＤＢの構成例を示す図である。
【図８】図１中の法人台帳ＤＢの構成例を示す図である。
【図９】図１の電話検証システムの動作例を示すシーケンス図である。
【図１０】図１の電話検証システムの動作例を示すシーケンス図である。
【図１１】図１の電話検証システムの動作例を示すシーケンス図である。
【発明を実施するための形態】
【００１２】
以下、本発明の実施の形態を、図面を参照して説明する。なお、以下の説明において参照する各図では、他の図と同等部分は同一符号によって示されている。
【００１３】
（システム構成）
図１は、本発明の実施形態による電話検証システムや関連する機器の構成を示すブロック図である。
【００１４】
図１において、発信者が電話加入している通信事業者Ａのシステム１と、法人台帳システム３と、認証局システム７と、受信者が電話加入している通信事業者Ｂのシステム４を記載している。本例の通信事業者Ａシステム１は、発信者端末５から発信された場合に、発信者端末５の電話番号を基に発信者の属性情報を検索し、検索結果を受信者端末６に通知する機能を有している。図１を参照すると、本例の通信事業者Ａ Ｓｙｓｔｅｍ１は、Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ（以下、ＷＷＷという。）サーバであるＷＷＷ１１と、Ｓｈｏｒｔ Ｍｅｓｓａｇｅ Ｓｅｒｖｉｃｅ Ｇａｔｅｗａｙ（以下、ＳＭＳ ＧＷという。）であるＳＭＳ ＧＷ１２と、電話交換機１３と、番号変換ＤＢ１４と、Ｖｅｒｉｆｙ Ｓｙｓｔｅｍ２と、を備えている。Ｖｅｒｉｆｙ Ｓｙｓｔｅｍ２は、電話番号検証サーバ２１と、契約者属性ＤＢ２２と、ＣＶＳ２３と、を備えている。
【００１５】
また、本実施例の法人台帳 Ｓｙｓｔｅｍ３は、法人検索サーバ３１と、法人台帳ＤＢ３２と、を備えている。通信事業者Ｂ Ｓｙｓｔｅｍ４は、ＳＭＳ ＧＷ４１と、電話交換機４２と、を備えている。認証局システム７は、ＣＲＬ（Ｃｅｒｔｉｆｉｃａｔｅ Ｒｅｖｏｃａｔｉｏｎ Ｌｉｓｔ）７２と、ＣＡ（Ｃｅｒｔｉｆｉｃａｔｅ Ａｕｔｈｏｒｉｔｙ）７１と、証明書ＤＢ７３とを備えている。
【００１６】
これら各構成装置については、後述する各機能を実現するためのプログラムをそれぞれのＣＰＵが実行することによって実現できる。
【００１７】
以下、各構成について説明する。
【００１８】
（ＷＷＷ）
ＷＷＷ１１は、発信者端末５から発信があった場合に、電話番号検証サーバ２１が発信者の属性情報を登録し、その発信にかかる電話の受信者端末６が、後述するＳＭＳ Ｍｅｓｓａｇｅに記載されたＵｎｉｆｏｒｍｅｄ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ（以下、「ＵＲＩ」と記述する）に基づき当該属性情報を取得可能な状態で公開する。なお、発信者の属性情報の通知方法は、ＷＷＷ１１を経由する方法の他、当該属性情報を、直接ＳＭＳ Ｍｅｓｓａｇｅに記載し、後述するＳＭＳＧＷ１２およびＳＭＳ ＧＷ４１を経由して受信者の端末に送信する手段、もしくは電話交換機１３から電話交換機４２に対する発呼電文に文字列として格納し、通知することも可能である。
【００１９】
（ＳＭＳ ＧＷ：Ｓｈｏｒｔ Ｍｅｓｓａｇｅ Ｓｅｒｖｉｃｅ Ｇａｔｅｗａｙ）
ＳＭＳ ＧＷ１２は、発信者端末５から発信があった場合に、電話番号検証サーバ２１がＳＭＳ ＧＷ１２およびＳＭＳ ＧＷ４１を経由して発信者の属性情報を受信者に通知する。なお、発信者の属性情報の通知方法は、ＳＭＳ ＧＷ１２およびＳＭＳ ＧＷ４１を経由する方法とは別に、前記ＷＷＷ１１もしくは電話交換機１３および電話交換機４２を経由して通知することも可能である。
【００２０】
（電話交換機）
電話交換機１３は、発信者端末５からの発信を受信し、電話交換機４２を経由して受信者端末６に発信動作を行う。また、電話交換機１３は、電話番号検証サーバ２１から送られてきた発信者の属性情報を、電話交換機４２を経由して、受信者に通知する。発信者と受信者が同じ通信事業者に加入している場合、電話交換機１３が電話交換機４２の役割も果たす。
【００２１】
（電話番号検証サーバ）
電話番号検証サーバ２１は、電話交換機１３からの検証Ｑｕｅｒｙを受け付け、後述する契約者属性ＤＢ２２において発信者の属性情報を検索し、検索の結果、発信者の属性情報が存在する場合に、発信者の属性情報を受信者に通知する。検索の結果、発信者の属性情報が存在しない場合に、後述する法人台帳 Ｓｙｓｔｅｍ３の法人検索サーバ３１に検証Ｑｕｅｒｙを送信し、後述する法人台帳 Ｓｙｓｔｅｍ３側に発信者の属性情報がないか検索する。法人検索サーバ３１は、通信事業者Ａ Ｓｙｓｔｅｍ側に発信者の属性情報がない場合に、電話番号検証サーバ２１から検証Ｑｕｅｒｙを受け付け、後述する法人台帳ＤＢ３２に発信者の属性情報がないか検索する。検索の結果、発信者の属性情報が存在する場合に、発信者の属性情報を電話番号検証サーバ２１に返信する。検索の結果、発信者の属性情報が存在しない場合に、その旨を電話番号検証サーバ２１に返信する。
【００２２】
（番号変換ＤＢ）
番号変換ＤＢ１４の構成例が図６に示されている。同図において、本例の番号変換ＤＢ１４は、契約者電話番号、代表電話番号、の各項目によって構成されている。音声通話のために契約によって設定された電話番号である。この電話番号は、携帯電話のものに限定されず、固定電話のものであってもよい。通信事業者Aは、発信者となる自社の契約者の電話番号を記憶しておけばよく、自社契約者の契約書等から番号変換DBを構築可能である。番号変換ＤＢ１４は、発信者の携帯電話番号と発信者の所属する組織の代表電話番号を変換する処理を受け付ける。例えば、電話番号検証サーバ２１は、発信者の携帯電話番号をキーとして、番号変換ＤＢ１４に検証Ｑｕｅｒｙを送信する。その結果、その携帯電話番号に紐付く代表電話番号が存在する場合に、その代表電話番号が電話番号検証サーバ２１に返信される。なお、後述の契約者属性DBが、各電話番号ごとに属性などを記憶していれば、番号変換は省略できる。
【００２３】
（契約者属性ＤＢ）
契約者属性ＤＢ２２の構成例が図７に示されている。同図において、本例の契約者属性ＤＢ２２は、代表電話番号、属性、名称、証明書の各項目によって構成されている。音声通話のために契約によって設定された電話番号である。この電話番号は、携帯電話のものに限定されず、固定電話のものであってもよい。契約者属性ＤＢ２２は、電話番号検証サーバ２１から検証Ｑｕｅｒｙを受け付け、発信者の属性情報を検索し、検索の結果、発信者の属性情報が存在する場合に、発信者の属性情報および証明書を電話番号検証サーバ２１に返信する。検索の結果、発信者の属性情報が存在しない場合に、その旨を電話番号検証サーバ２１に返信する。ここで、属性とは、公証人や銀行の他、警察、市役所、○○学校、○○店などの業種などが含まれている。また、弁護士、警察官など、職業としてもよいし、所属と職業などを組み合わせてもよい。名称には、個人名でもよいし、法人でもよい。また、会社内の部署名でもよい。
【００２４】
契約者属性情報は、通信事業者が、自社契約者のうち希望者に対して、通信事業者または専門の保証機関が身分確認を行い、身元を保証する証明書を格納することで作成する。自社契約者であり希望者のみであるので、他通信事業者も含む電話保有者全員に対して行う必要はなく、作成に困難性は小さい。ここで希望者として、公的機関や企業など、営業のために身元保証が有用な者を想定している。証明書は、名称にかかる組織・法人や個人の者であってもよいし、個人の属する組織・法人の者であってもよい。
【００２５】
（ＣＶＳ：Ｃｅｒｔｉｆｉｃａｔｅ Ｖａｌｉｄａｔｉｏｎ Ｓｅｒｖｅｒ）
ＣＶＳ２３は、電話番号検証サーバ２１が契約者属性ＤＢ２２もしくは法人検索サーバ３１から発信者の属性情報および証明書を受信した後に、後述するＣＲＬ７２を参照し、RFC5280(6章)で規定される手順にて、その証明書が有効であるかを確認（以下、証明書検証という）する。その結果、有効でない場合はその旨を電話番号検証サーバ２１に返信する。
【００２６】
（法人台帳ＤＢ）
法人台帳ＤＢ３２の構成例が図８に示されている。同図において、本実施例の法人台帳ＤＢ３２は、契約者電話番号、属性、名称、住所、証明書、の各項目によって構成されている。契約者電話番号は、音声通話のために契約によって設定された電話番号である。この電話番号は、携帯電話のものに限定されず、固定電話のものであってもよい。これらの情報は、当該法人台帳DB３２の運営組織によって所定の手続きを経て当該組織・法人等が適正に運営されていることを確認されたり、個人が本人確認された場合に、法人台帳DB３２に格納される。確認の条件に、運営の健全性、経済状況、など、本DBに登録するに値する適格性を課してもよい。そして、証明書は、所定の期間ごとに更新されその有効性が保たれ、組織・法人や個人の確認ができなくなった場合には、更新されずに失効する。また、本DBから他の記憶装置にコピーされた証明書も、更新を行わない場合には同様に失効する。本実施例では、契約者属性DB２２にも証明書が保存されている。契約者属性DB２２は、通信事業者が保有しており、電話番号検証サーバ２１など通信事業者のノードからのアクセスが速い代わりに、証明書の正当性が不十分であったり、正当性の高い証明書は更新できなかったりする。対して法人台帳DBでは、その運営組織によって厳格に審査や確認された証明書を、定時的に更新しながら保存しており、信頼性が高い。
【００２７】
法人台帳ＤＢ３２は、法人検索サーバ３１から検証Ｑｕｅｒｙを受け付け、発信者の属性情報を検索し、検索の結果、発信者の属性情報が存在する場合に、発信者の属性情報を法人検索サーバ３１に返信する。検索の結果、発信者の属性情報が存在しない場合に、その旨を法人検索サーバ３１に返信する。また、法人台帳ＤＢ３２に登録されている属性情報は、当該法人等（府省、銀行等）が後述するＣｅｒｔｉｆｉｃａｔｅ Ａｕｔｈｏｒｉｔｙ（以下、「ＣＡ」と記述する）であるＣＡ７１から取得した、証明書７３とともに提供されており、当該属性情報が真正であることは、法人台帳ＤＢの運営組織によって確認されている。
【００２８】
（発信者端末および受信者端末）
発信者端末５は、本例では、振り込め詐欺犯を含む電話の発信者が使用する電話端末である。受信者端末６は、本例では、振り込め詐欺犯のターゲットとなる電話の受信者が使用する電話端末である。発信者端末５および受信者端末６は、電話番号が定められており、音声通話が可能な装置であり、通常の携帯電話端末のほか、スマートフォンも含まれる。また、SMS,Web閲覧など所定の情報処理が可能であれば、固定電話であってもよい。
【００２９】
（ＣＡ：Ｃｅｒｔｉｆｉｃａｔｅ Ａｕｔｈｏｒｉｔｙ）
ＣＡ７１は、外部組織が前記法人台帳ＤＢ３２に提供する証明書７３もしくは、後述するＣｅｒｔｉｆｉｃａｔｅ Ｒｅｖｏｃａｔｉｏｎ Ｌｉｓｔ（以下、ＣＲＬという。）７２を発行する認証局である。
【００３０】
（ＣＲＬ：Ｃｅｒｔｉｆｉｃａｔｅ Ｒｅｖｏｃａｔｉｏｎ Ｌｉｓｔ）
ＣＲＬ７２は、ＣＶＳ２３が電話番号検証サーバ２１から受信した発信者の属性情報が失効していないかを確認する際に参照するＸ．５０９証明書失効リストであり、ＣＡ７１から発行される。本システムでは、失効リストとして、ＣＲＬ７２を読み取り可能とする。
【００３１】
（電話検証システムの動作シーケンス例）
以下、本システムによる動作の概要について説明する。本システムでは、契約者の通話中（発信、着信は問わない）に、発信者の属性情報を取得し、通話終了とともに、発信者の属性情報をＨｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ Ｓｅｃｕｒｅ（以下、ＨＴＴＰＳという。）、ＳＭＳ、もしくは電話交換機経由で受信者に通知する。発信者の属性情報が契約者属性ＤＢ２２もしくは法人台帳ＤＢ３２に登録されていない場合は、通話終了とともに、登録が無い旨を受信者に通知する。
【００３２】
図９は、電話検証システムの動作を示す動作シーケンス例である。同図において、発信者端末５は、自端末の電話番号とともに、受信者に向けた通話要求を、電話交換機１３に対し発信する（ステップＳ１）。電話交換機１３は、発信先の電話番号に基づいて受信者側の電話交換機４２に発呼するとともに、電話番号検証サーバ２１に対し、発信者の契約者電話番号を送信する（ステップＳ２）。
【００３３】
電話番号検証サーバ２１は、番号変換ＤＢ１４に対し、受信した発信者の契約者電話番号を送信する（ステップＳ３）。番号変換ＤＢ１４は、受信した発信者の契約者電話番号に紐付く代表電話番号が存在する場合に、その契約者電話番号を代表電話番号に変換し（ステップS４）、その代表電話番号を電話番号検証サーバ２１に返信する（ステップＳ５）。契約者電話番号と代表者電話番号とが同じ場合、その旨返信するか、契約者電話番号を代表者電話番号として返信する。なお、契約者属性DB22が、代表者電話番号のみならず各契約者電話番号について属性等を記憶している場合、ステップS3〜5は不要になる。
【００３４】
電話番号検証サーバ２１は、契約者属性ＤＢ２２に、受信した代表電話番号を送信する（ステップＳ６）。契約者属性ＤＢ２２は、受信した代表電話番号をキーに属性情報および証明書を検索し、当該DBに格納されている場合には返信する（ステップＳ７）。属性情報および証明書が見つからなかった場合には、その旨返信し、次のステップS８〜１０を省略する。
【００３５】
電話番号検証サーバ２１は、受信した証明書をＣＶＳ２３に送信し（ステップS８）、ＣＶＳ２３は証明書検証を行う（ステップＳ９）。ＣＶＳ２３は電話番号検証サーバ２１に証明書検証結果を返信する（ステップＳ１０）。ここで、属性情報があり、かつ、証明書が失効していない場合、ステップＳ１２〜１４を省略し、電話番号検証サーバ２１は電話交換機１３経由で発信者の属性情報を受信者に通知する（ステップＳ１５〜１６）。
【００３６】
属性情報や証明書が無かったり、あっても証明書が失効している場合、電話番号検証サーバ２１は、法人台帳Ｓｙｓｔｅｍ３において発信者の属性情報を検索するため、法人検索サーバ３１に発信者の代表電話番号を送信する（ステップＳ１１）。法人検索サーバ３１は、受信した代表電話番号をキーに、法人台帳ＤＢ３２において、発信者の属性を検索する（ステップＳ１２）。ここで、法人台帳ＤＢ３２に発信者の属性情報が存在しない場合、その旨を法人検索サーバ３１に返信し、法人台帳ＤＢ３２に属性情報が存在する場合、法人台帳ＤＢ３２は、法人検索サーバ３１に対し、発信者の属性情報および証明書を返信する（ステップＳ１３）。法人検索サーバ３１は、受信した発信者の属性情報および証明書を電話番号検証サーバ２１に送信する（ステップＳ１４）。
【００３７】
電話番号検証サーバ２１は、受信した発信者の属性情報および証明書を、電話交換機１３経由で受信者が契約している通信事業者に送信する（ステップＳ１５→Ｓ１６）。また、電話検証サーバ２１は、受信した属性情報および証明書を契約者属性ＤＢ２２に送信する（ステップＳ１７）。契約者属性ＤＢ２２は受信した属性情報および証明書を登録する（ステップＳ１８）。
【００３８】
図１０は、電話検証システムにおける受信者側の動作を示す動作シーケンス例である。同図において、発信側の電話交換機１３は、受信側の電話交換機４２に通話開始のための発呼電文を送り、電話交換機４２はさらに受信者端末６に送信する（ステップS２１）。受信者が端末６の通話ボタンを押せば、送信者との通話が開始される。その後、発信者の属性情報を取得した電話交換機１３は、それ含む発呼電文を送信する（ステップＳ２２）。電話交換機４２は、受信した発信者の属性情報を含む発呼電文を受信者端末６に送信する（ステップＳ２３）。本実施例では、通話開始のための発呼電文と属性情報送信のための発呼電文とを別々に送信しているが、電話交換機１３が属性情報を取得する時間が短ければ、一緒に送信してもよい。また、前者は後者を待って一緒に発信するようにしてもよい。
【００３９】
図１１は、属性情報をSMSまたはWebにて送信する電話検証システムにおける受信者側の動作を示す動作シーケンス例である。同図において、発信者側のＳＭＳ ＧＷ１２は、発信者の電話番号と属性情報を含むＳＭＳ Ｍｅｓｓａｇｅを送信する（ステップＳ２４）。SMS Messageのあて先は、SMS GW12が、電話発信から受信者の電話番号を取得して指定する。受信者側のＳＭＳ ＧＷ４１は、受信した発信者の電話番号及び属性情報を含むＳＭＳ Ｍｅｓｓａｇｅを受信者端末６に送信する（ステップＳ２５）。ＳＭＳ Ｍｅｓｓａｇｅを受信した受信者は、ＳＭＳ Ｍｅｓｓａｇｅ上に含まれているＵＲＩに基づき、ＷＷＷサーバにアクセスすることで、Ｗｅｂ（ＨＴＴＰＳ）で発信者の属性情報を確認することができる（ステップＳ２６→Ｓ２７）。
【００４０】
いずれの例においても、属性情報とともに証明書や、当該証明書が有効である旨を送付してもよい。属性情報を受け取った受信者端末は、それを受信履歴情報（受信した電話番号と受信日時等を記憶）内に当該受信に対応付けて保存してもよいし、アドレス帳（氏名・名称、電話番号等を記憶）内の発信者の情報に対応付けて記憶してもよい。また、発信者の信用できるプロフィール（企業であれば、会社概要、経歴、事業内容など）を送信してもよい。
【００４１】
発信者の属性が、信用できる機関や企業のものだった場合、受信者は安心して通話をすることができる。受信者端末６の電話帳に記憶されている電話番号であった場合、受信者端末６はその名前を電話番号とともに表示し、受信者の知っている相手なので安心して通話ができる。属性情報が無く端末の電話帳にも登録が無い場合、身元を保証されない相手からの電話なので、受信者は用心して電話に出る、または電話に出ないので、詐欺等にあう可能性が低くなる。
【００４２】
以上、本発明によると、電話の発信とともに発信者の信頼性を示す情報を送信するので、信頼できる機関等からの電話を保証し、詐欺等にあう可能性を小さくできる。
【符号の説明】
【００４３】
１  通信事業者Ａ Ｓｙｓｔｅｍ
１１  ＷＷＷ
１２  ＳＭＳ ＧＷ
１３  電話交換機
１４  番号変換ＤＢ
２  Ｖｅｒｉｆｙ Ｓｙｓｔｅｍ
２１  電話番号検証サーバ
２２  契約者属性ＤＢ
２３  ＣＶＳ
３  法人台帳 Ｓｙｓｔｅｍ
３１  法人検索サーバ
３２  法人台帳ＤＢ
４  通信事業者Ｂ Ｓｙｓｔｅｍ
５  発信者端末
６  受信者端末
７  認証局
７１  ＣＡ
７２  ＣＲＬ
７３  証明書
【図１】
2016019069.tif 000003
【図２】
2016019069.tif 000004
【図３】
2016019069.tif 000005
【図４】
2016019069.tif 000006
【図５】
2016019069.tif 000007
【図６】
2016019069.tif 000008
【図７】
2016019069.tif 000009
【図８】
2016019069.tif 000010
【図９】
2016019069.tif 000011
【図１０】
2016019069.tif 000012
【図１１】
2016019069.tif 000013