JP6706596B2 - 通信システム、通信装置および通信方法 - Google Patents

Description

本発明は、暗号化された宛先情報を用いて、発信端末と宛先装置とを接続する通信システム、通信装置および通信方法に関する。

QRコード（登録商標）に宛先情報を設定し、ユーザがQRコードを読み取ることで、宛先情報で指定されたサーバにアクセスし、サーバは、アクセスしたユーザにサービスを提供することが行われている。

また、特許文献１には、名刺に印刷されたQRコードに公開暗号鍵を設定することで、名刺交換した相手以外には非公開情報を秘匿する名刺情報取得システムが記載されている。

特開2008-282238号公報

個人が、特定の相手（例えば名刺交換した相手、あるいは自分の宛先（連絡先）を教えた相手）からのみ連絡を受けたい場合がある。また、サービス提供者が集客したい場合、ターゲット層あるいは見込み顧客にだけ、サービス窓口の宛先を知らせて集客したい場合がある。

このような場合に、宛先を平文のままで相手に提供すると、第３者の目に触れて漏れる可能性がある。このような事態を回避するために、暗号化（符号化）した宛先を提供することが考えられる。しかしながら、宛先情報が判読できないように暗号化されていたとしても、許可された正当な発信者が発信するに当たっては、当該暗号化された宛先を一旦解読して元の宛先を取り出す必要があり、解読された宛先が当該発信者だけでなく、第３者の目に触れる危険性がある。

また、解読した宛先をアクセス制限付きでリスト管理したとしても、相手へ発信する際には、端末画面に宛先が表示され、また、解読した宛先を紙で印刷をすることなどにより、第３者が宛先を見ることができる状態が生じてしまう。

本発明は、上記事情に鑑みてなされたものであり、本発明の目的は、宛先情報を判読困難な形式で利用者に提供する場合において、利用者が当該宛先情報を判読することなく当該宛先情報の宛先との通信を行うことにある。

上記目的を達成するため、本発明は、発信端末と通信装置とを備える通信システムであって、前記発信端末は、コードを読み取り、暗号化された宛先情報と、復号鍵を取得するための識別情報とを取得するコード読取部と、前記暗号化された宛先情報と前記識別情報とを含む接続要求を、前記通信装置に送信する送信部とを備え、前記通信装置は、前記発信端末から前記接続要求を受信する受信部と、前記接続要求に含まれる前記識別情報に対応する復号鍵を取得し、前記暗号化された宛先情報を復号する復号部と、前記復号した宛先情報を前記発信端末に通知することなく、前記発信端末と、前記復号した宛先情報を有する宛先装置とを接続する通信接続部と、を備える。

本発明は、通信装置であって、コードを読み取り、暗号化された宛先情報と、復号鍵を取得するための識別情報とを取得する発信端末から、前記暗号化された宛先情報と前記復号鍵とを含む接続要求を受信する受信部と、前記接続要求に含まれる前記識別情報に対応する復号鍵を取得し、前記暗号化された宛先情報を復号する復号部と、前記復号した宛先情報を前記発信端末に通知することなく、前記発信端末と、前記復号した宛先情報を有する宛先装置とを接続する通信接続部と、を備える。

本発明は、通信方法であって、発信端末は、コードを読み取り、暗号化された宛先情報と、復号鍵を取得するための識別情報とを取得するコード読取ステップと、前記暗号化された宛先情報と前記識別情報とを含む接続要求を、通信装置に送信する送信ステップとを行い、前記通信装置は、前記発信端末から前記接続要求を受信する受信ステップと、前記接続要求に含まれる前記識別情報に対応する復号鍵を取得し、前記暗号化された宛先情報を復号する復号ステップと、前記復号した宛先情報を前記発信端末に通知することなく、前記発信端末と、前記復号した宛先情報を有する宛先装置とを接続する通信接続ステップと、を行う。

本発明によれば、宛先情報を判読困難な形式で利用者に提供する場合において、利用者が当該宛先情報を判読することなく当該宛先情報の宛先との通信を行うことができる。

本発明の第１の実施形態に係る通信システムのシステム構成を示す図である。 本発明の第２の実施形態に係る通信システムのシステム構成を示す図である。 本発明の第２の実施形態の動作を示すシーケンス図である。 本発明の第３の実施形態の動作を示すシーケンス図である。

以下、本発明の実施の形態について、図面を参照して説明する。

＜第１の実施形態＞
１．システム構成
図１は、本発明の第１の実施形態に係る通信システムの全体を示すシステム構成例である。図１に示す通信システムは、発信端末１と、宛先端末２（宛先装置）と、通信サーバ３と、DBサーバ４とを備える。なお、宛先端末２は、発信端末１に所定のサービスを提供するサーバなどであってもよい。

発信端末１は、コード読取部１１と、通信部１２とを備える。コード読取部１１は、QRコード（登録商標）などのコードを読み取り、当該コードをデコード（解釈）して、暗号化された宛先情報（以下、「暗号化宛先情報」）と、復号鍵を取得するためのID情報（識別情報）とを取得する。宛先情報は、例えば、電話番号、メールアドレス、URLなどである。

通信部１２（送信部）は、暗号化された宛先情報と識別情報とを含む接続要求を、通信サーバ３に送信する。具体的には、通信部１２は、コード読取部１１が取得した暗号化宛先情報とID情報とを用いて発信し、宛先端末２との通信を確立するため処理を行う。

宛先端末２は、発信端末１からの通信確立の相手側となる装置であり、サービス処理部２１と、通信部２２とを備える。サービス処理部２１は、通信部２２による通信確立後に、発信端末１に対して所定のサービスを提供する処理を行う。通信部２２は、発信端末１との通信を確立するとともに、通信確立後に例えば通話などの通信を行う。

通信サーバ３は、発信端末１からの接続要求（発信要求）を受け付けて、発信端末１と宛先端末２とを接続するサーバであり、通信接続部３１と問合せ処理部３２とを備える。

通信接続部３１（受信部を含む）は、発信端末１から前記接続要求を受信する。通信接続部３１は、宛先端末２の宛先情報を発信端末１に通知することなく、発信端末１と、宛先情報を有する宛先端末２とを接続する。すなわち、通信接続部３１は、発信端末１と宛先端末２との間の通信を確立し、その際に、宛先端末２の宛先情報を発信端末１に非通知とする。

問合せ処理部３２（復号部）は、発信端末１から受信した接続要求に含まれるID情報に対応する復号鍵を取得し、接続要求に含まれる暗号化宛先情報を復号する。具体的には、問合せ処理部３２は、ID情報を用いて、暗号化宛先情報を復号（解読）するための復号鍵をDBサーバ４へ問合せる。そして、問合せ処理部３２は、DBサーバ４から取得した復号鍵を用いて暗号化宛先情報を復号し、復号した宛先情報を用いて宛先端末２と発信端末１との接続処理を行う。

また、問合せ処理部３２は、宛先端末２が提供するサービスの形態に応じて、発信端末１の発信元情報（例えば、電話番号、メールアドレスなどの）が、宛先端末２に接続可能か否かをDBサーバ4に問合せることとしてもよい。この場合、DBサーバ４から取得した問合せ結果に応じて、通信接続部３１は、発信端末１と宛先端末２との間の接続処理を進める、あるいは、発信端末１へ接続不可を送信する。接続処理を進める場合は、通信接続部３１は、復号鍵により暗号化宛先情報を復号した宛先情報を用いて宛先端末２へ接続する。

DBサーバ４は、暗号化宛先情報の復号鍵を保持するサーバであって、受付け処理部４１（判定部）と、DB４２とを備える。受付け処理部４１は、通信サーバ３からの問合せを受けて、暗号化宛先情報を解読する復号鍵をDB４２から検索し、通信サーバ３に送信する。また、受付け処理部４１は、宛先端末２が提供するサービスの形態に応じて、通信サーバ３からの問合せを受け付けて、発信端末１の接続要求を許可するか否かを、DB４２に記憶されたホワイトリストまたはブラックリストを用いて判定し、判定結果を通信サーバ３に送信してもよい。

DB４２は、暗号化宛先情報を解読するための復号鍵を管理する。DB４２には、宛先端末２を識別する宛先ID（宛先識別子）と、復号鍵とが対応付けて記憶される。宛先端末２が複数ある場合は、DB４２には、宛先端末２毎に、宛先IDと復号鍵とを対応付けた対応情報（例えば、対応テーブル等）が保持される。

また、DB４２は、宛先端末２への接続を許可する発信端末１の発信元情報が設定されたホワイトリスト（許可リスト）、または、宛先端末２への接続を禁止する発信元情報が設定されたブラックリスト（禁止リスト）を保持することとしてもよい。宛先端末２が複数ある場合は、DB４２には、宛先端末２毎に、ホワイトリストまたはブラックリストを保持してもよい。

上記説明した、発信端末１、宛先端末２、通信サーバ３およびDBサーバ４は、例えば、ＣＰＵ（プロセッサ）と、メモリと、ハードディスク等の外部記憶装置と、入力装置と、出力装置とを備えた汎用的なコンピュータシステムを用いることができる。このコンピュータシステムにおいて、ＣＰＵがメモリ上にロードされた所定のプログラムを実行することにより、各装置の各機能が実現される。例えば、発信端末１、宛先端末２、通信サーバ３およびDBサーバ４の各機能は、発信端末１用のプログラムの場合は発信端末１のＣＰＵが、宛先端末２用のプログラムの場合は宛先端末２のＣＰＵが、通信サーバ３用のプログラムの場合は通信サーバ３のＣＰＵが、そして、DBサーバ４用のプログラムの場合はDBサーバ４のＣＰＵがそれぞれ実行することにより実現される。

また、発信端末１用のプログラム、宛先端末２用のプログラム、通信サーバ３用のプログラムおよびDBサーバ４用のプログラムは、ハードディスク、半導体メモリ（例えば、ＵＳＢメモリ）、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、ＭＯなどのコンピュータ読取り可能な記録媒体に記憶することも、ネットワークを介して配信することもできる。

２．コードの構成
次に、本実施形態で用いるコードについて説明する。

本実施形態のコードは、マトリックス型、スタック型などの２次元コードである。本実施形態では、２次元コードの１つであるQRコード（登録商標）を用いる。なお、本実施形態のコードは、バーコードなどの１次元コードであってもよく、特定の構成に限定されるものではない。

また、本実施形態のコードには、「暗号化宛先情報」および「ID情報」が付与されている。「暗号化宛先情報」は、宛先端末２の宛先情報を、宛先端末２のユーザ（例えば、サービス提供者）が所有する暗号鍵（例えば秘密鍵）によって暗号化した情報である。

「ID情報」は、暗号化宛先情報を復号するための復号鍵（例えば公開鍵）を取得するための情報である。本実施形態では、ID情報には、宛先端末２（または宛先端末２のユーザ）を識別する宛先IDと、復号鍵を管理するDBサーバ４のドメイン情報とを含む。

３．通信システムの動作
次に、本実施形態の通信システムの動作例を、図１を参照して説明する。

発信端末１のコード読取部１１は、紙などのシートまたは画面などに表示されるコードを読み取り、デコードして、当該コードに付与されたID情報と暗号化宛先情報とを取得する（Ｓ１）。

発信端末１の通信部１２は、取得したID情報と暗号化宛先情報とを含む接続要求を、通信サーバ３に送信する（Ｓ２）。接続要求には、発信端末１の発信元情報も含まれていてもよい。

通信サーバ３の通信接続部３１は、接続要求を受信する。そして、通信サーバ３の問合せ処理部３２は、接続要求に含まれるID情報を用いて、DBサーバ４へ復号鍵を要求する（Ｓ３）。具体的には、問合せ処理部３２は、ID情報に含まれるDBサーバ４のドメイン情報を用いてDBサーバ４にアクセスし、ID情報に含まれる宛先IDに対応する復号鍵を取得する。

また、宛先端末２のサービスの形態に応じて、問合せ処理部３２は、DBサーバ４に発信端末１の発信元情報を送信し、発信端末１が宛先端末２への接続が許可されているか否かを問合せてもよい。

DBサーバ４の受付け処理部４１は、宛先ID に対応する復号鍵をDB４２から検索し、検索した復号鍵を通信サーバ３へ送信する（Ｓ４）。また、宛先端末２のサービスの形態に応じて、受付け処理部４１は、受信した宛先IDに対応するホワイトリストあるいはブラックリストをDB４２から特定し、特定したホワイトリストあるいはブラックリストに通信サーバ３から送信された発信元情報が存在するか（含まれるか）否かに応じて宛先端末２への接続可否を判定してもよい。

例えば、DB４２にホワイトリストが記憶されている場合、受付け処理部４１は、ホワイトリストに発信元情報が存在する場合は接続可能と判定し、ホワイトリストに発信元情報が存在しない場合は接続不可と判定する。また、DB４２にブラックリストが記憶されている場合、受付け処理部４１は、ブラックリストに発信元情報が存在しない場合は接続可能と判定し、ブラックリストに発信元情報が存在する場合は接続不可と判定する。なお、本実施形態では、受付け処理部４１は、接続可能と判定した場合に復号鍵を通信サーバ３に送信し、接続不可と判定した場合は接続不可の判定結果を通信サーバ３に送信する。

通信サーバ３の問合せ処理部３２は、DBサーバ４から復号鍵を受信した場合（接続可能と判定された場合）、DBサーバ４から受信した復号鍵を用いて、Ｓ２で受信した接続要求に含まれる暗号化宛先情報を復号する。そして、通信接続部３１は、復号した宛先情報を用いて、発信端末１と宛先端末２とを接続する（Ｓ５−１）。具体的には、通信接続部３１は、接続要求を宛先端末２に送信する際に、接続要求の宛先を復号した宛先情報に書き換えて送信する。

一方、通信サーバ３の通信接続部３１は、接続可否の場合であって、DBサーバ４から接続不可の判定結果を受信した場合、発信端末１に接続不可のメッセージを送信し、処理を終了する（Ｓ５−２）。

Ｓ５−１の場合、宛先端末２の通信部２２は、接続要求を受信し、当該接続要求に対する応答を通信サーバ３に送信する（Ｓ６）。なお、通信部２２は、必要に応じて、発信端末１へサービス提供を行うか否かをサービス処理部２１に問合せ、サービス提供を行う場合に接続を受け入れる応答を通信サーバ３に送信し、サービス提供を行わない場合に接続を拒否する応答を通信サーバ３に送信してもよい。

通信サーバ３の通信接続部３１は、宛先端末２から接続を受け入れる応答を受信すると、当該応答に宛先端末２の宛先情報が付加されている場合は、当該宛先情報を発信端末１へ通知することなく、発信端末１と宛先端末２とを接続する（Ｓ７）。具体的には、通信接続部３１は、接続要求に対する応答を発信端末１に送信する際に、前記応答に含まれる宛先端末２の宛先情報を、他の情報（本実施形態では、ID情報）に書き換えて送信する。これにより、通信接続部３１は、宛先端末２の宛先情報を発信端末１に通知することなく、発信端末１と、宛先端末２とを接続することができる。

発信端末１と宛先端末２との間で通信の接続が確立した後に、発信端末１と宛先端末２との間で通信が可能となる。例えば、宛先端末２のサービス処理部２１は、発信端末１に所定のサービスを提供してもよい（Ｓ８）。

＜第２の実施形態＞
本発明の第２の実施形態について説明する。本実施形態では、IP電話等のサービスに使われるSIPプロトコルを適用した実施形態である。

図２は、本実施形態に係る通信システムの全体を示すシステム構成例である。図２に示す通信システムは、発信端末１と、宛先端末２と、第１のSIPサーバ３Ａと、第２のSIPサーバ３Ｂと、ENUMサーバ４Ａとを備える。発信端末１および宛先端末２は、図１に示す第１の実施形態の発信端末１および宛先端末２と同様である。

第１のSIPサーバ３Ａおよび第２のSIPサーバ３Ｂは、図１の通信サーバ３に相当し、通信接続部３１と、問合せ処理部３２とを備える。第１のSIPサーバ３Ａは、発信端末１を収容するSIPプロキシサーバである。第２のSIPサーバ３Ｂは、宛先端末２を収容するSIPプロキシサーバである。

ENUM（E.164 NUmber Mapping）サーバ４Ａは、図１のDBサーバ４に相当し、受付け処理部４１とDB４２とを備える。ENUMサーバ４Ａは、IPネットワークでの番号解決に用いられるサーバである。

本実施形態のSIPサーバ３Ａは、発信端末１の接続可否をENUMサーバ４Ａに問い合わせることなく、暗号化宛先情報を復号する復号鍵をENUMサーバ４Ａから取得して通信確立を行う基本的な実施形態である。

図３は、本実施形態の通信処理を示すシーケンス図である。以下に、本実施形態の通信処理を説明する。図示するシーケンスは、SIPプロトコルを用いる。

初期処理として、例えばシステム管理者などが、ENUMサーバ４ＡのDB４２に、宛先端末２の宛先ID（図３では、「ID」）と、復号鍵とを対応付けて登録する（Ｓ１１）。なお、宛先端末２が複数存在する場合は、DB４２には、宛先端末２毎に、宛先IDと復号鍵とを対応付けた対応情報が登録される。

発信端末１は、コードを読取り、読取ったコードをデコードして、コードデータ（ID情報および暗号化宛先情報）を取得する。そして、発信端末１は、取得したコードデータ含むINVITEをSIPサーバ３Ａに送信する（Ｓ１２）。INVITEは、接続要求（発信、発呼）するためのSIPメッセージである。

ここで、発信端末１は、INVITEにおいて、宛先を示すSIP-URIにID情報を設定し、セッション記述部SDP（session description protocol）に、属性種類として暗号化宛先情報を設定する。ID情報は、宛先端末２を識別するための宛先ID、および、ENUMサーバ４Ａのドメイン情報である。図３に示す例では、「宛先ID 」と「ENUMサーバ４Ａのドメイン情報」とを＠で接続した「宛先ID＠ENUMサーバ４Ａのドメイン情報」を、宛先としてSIP-URIに設定している。

SIPサーバ３Ａは、発信端末１からINVITEを受信し、SIP-URIに設定されたID情報を用いて、ENUMサーバ４Ａへ復号鍵を要求する（Ｓ１３）。具体的には、SIPサーバ３Ａは、ENUMサーバ４Ａのドメイン情報を宛先とし、宛先IDを検索キーとして設定したDNS（Domain Name System）クエリを送信する。

ENUMサーバ４Ａは、DNSクエリに設定されたユーザIDに対応する公開鍵をDB４２から検索し、取得する（Ｓ１４）。そして、ENUMサーバ４Ａは、DNSクエリの応答であるDNSレスポンスに検索結果の公開鍵を設定し、SIPサーバ３Ａへ送信する（Ｓ１５）。

SIPサーバ３Ａは、ENUMサーバ4Ａから受信した公開鍵を用いて、Ｓ１２で受信したINVITEのSDPに設定された暗号化宛先情報を復号（解読）する（Ｓ１６）。SIPサーバ３Ａは、復号した宛先情報を用いて、接続要求であるINVITEをSIPサーバ３Ｂへ送信する（Ｓ１７）。具体的には、SIPサーバ３Ａは、Ｓ１２で受信したINVITEのSIP-URIを復号した宛先情報（ここでは、宛先端末２の宛先情報）に書き換えて、SIPサーバ３Ｂに送信する。

SIPサーバ３Ａは、INVITEを実行中であることを通知する暫定応答100Tryingを発信端末１に送信する（Ｓ１８）。このとき、SIPサーバ３Ａは、宛先端末２の宛先情報を非通知とするために、SIP-URIにID情報（宛先IDおよびENUMサーバ４Ａのドメイン情報）を設定した100Tryingを発信端末１に送信する。SIPサーバ３Ａは、Ｓ１２で受信したID情報と、Ｓ１６で復号した宛先端末２の宛先情報とを、対応付けてメモリなどの記憶部に保持しておく。

SIPサーバ３Ｂは、受信したINVITEを配下の宛先端末２に送信するとともに、INVITEを実行中であることを通知する100TryingをSIPサーバ３Ａに送信する（Ｓ１９、Ｓ２０）。

宛先端末２は、INVITEを受信すると、発信端末１に呼出し中であることを通知する暫定応答180RingingをSIPサーバ３Ｂに送信する（Ｓ２１）。SIPサーバ３Ｂは、180RingingをSIPサーバ３Ａに転送する（Ｓ２２）。

SIPサーバ３Ａは、180Ringing を発信端末１に送信する。このとき、SIPサーバ３Ａは、宛先端末２の宛先情報を発信端末１に非通知とするために、Ｓ１８と同様に、SIP-URIにID情報を設定した180Ringing を発信端末１に送信する（Ｓ２３）。具体的には、SIPサーバ３Ａは、180RingingのSIP-URIを宛先端末２の宛先情報からID情報に書き換えて、180Ringingを発信端末１に送信する。

宛先端末２は、オフフックなどにより通信（セッション）を確立できる状態になると、通信確立に成功したことを示す成功応答200OKを、SIPサーバ３Ｂに送信する（Ｓ２４）。SIPサーバ３Ｂは、200OKをSIPサーバ３Ａに転送する（Ｓ２５）。

SIPサーバ３Ａは、200OK を発信端末１に送信して通信を確立する。このとき、SIPサーバ３Ａは、宛先端末２の宛先情報を発信端末１に非通知とするために、Ｓ１８と同様に、SIP-URIにID情報を設定した200OK を発信端末１に送信する（Ｓ２６）。具体的には、SIPサーバ３Ａは、200OKのSIP-URIを宛先端末２の宛先情報からID情報に書き換えて、200OKを発信端末１に送信する。

以上述べたとおり、本実施形態では、SIPサーバ３Ａが発信端末１に送信するSIPメッセージ（Ｓ１８、Ｓ２３、Ｓ２６）には、宛先端末２の宛先情報は設定されていない。すなわち、発信端末１には宛先端末２の宛先情報が非通知のまま、発信端末１と宛先端末２との接続を確立することができる。したがって、本実施形態では、宛先端末２の宛先情報を発信端末１に秘匿することができる。

＜第３の実施形態＞
本発明の第３の実施形態について説明する。本実施形態は、第２の実施形態と同様に、SIPプロトコルを適用した実施形態である。本実施形態では、ENUMサーバ4Ａ（DBサーバ）が、ホワイトリストを保持し、発信端末１がホワイトリストに含まれるか否かに応じて接続の可否を判断する点において、第２の実施形態と異なる。

本実施形態のシステム構成は、図２に示す第２の実施形態と同じである。なお、本実施形態のENUMサーバ４Ａは、暗号化宛先情報の復号鍵を保持するとともに、ホワイトリストを保持する。ホワイトリストは、宛先端末２へ接続を許可する発信端末１の発信元情報（例えば、発信端末の電話番号）が設定されたリストである。

図４は、本実施形態の通信処理を示すシーケンス図である。以下に、本実施形態の通信処理を説明する。

初期処理として、図３のＳ１１と同様に、システム管理者などが、ENUMサーバ４ＡのDB４２に、宛先端末２の宛先ID（図４では、「ID」）と、復号鍵とを対応付けて登録する。さらに、本実施形態では、システム管理者などが、宛先端末２へ接続を許可する発信端末１の発信元情報が設定されたホワイトリストを、ENUMサーバ４ＡのDB４２に登録する（Ｓ３１）。

発信端末１は、図３のＳ１２と同様に、コードを読取り、読取ったコードをデコードして、コードデータ（ID情報および暗号化宛先情報）を取得する。そして、発信端末１は、取得したコードデータ含むINVITEをSIPサーバ３Ａに送信する（Ｓ３２）。なお、INVITEには、送信元を示す発信端末１の発信元情報が設定される。

SIPサーバ３Ａは、発信端末１からINVITEを受信し、SIP-URIに設定されたID情報および発信元情報を用いて、ENUMサーバ４Ａへ復号鍵を要求する（Ｓ３３）。ID情報は、宛先端末２を識別するための宛先ID、および、ENUMサーバ４Ａのドメイン情報である。具体的には、SIPサーバ３Ａは、ENUMサーバ４Ａのドメイン情報を宛先とし、宛先IDおよび発信元情報を検索キーとして設定したDNS（Domain Name System）クエリを送信する。

ENUMサーバ４Ａは、DNSクエリに設定された発信元情報と、DB42に記憶されたホワイトリストとを照合し、発信元情報がホワイトリストに存在する否かを判定する。発信元情報がホワイトリストに存在する場合、ENUMサーバ４Ａは、接続可能であると判定し、DNSクエリに設定された宛先IDに対応する公開鍵をDB４２から検索し、取得する（Ｓ３４）。一方、発信元情報がホワイトリストに存在しない場合、ENUMサーバ４Ａは、発信端末１は接続不可であると判定する。

そして、ENUMサーバ４Ａは、DNSクエリの応答であるDNSレスポンスをSIPサーバ３Ａへ送信する（Ｓ３５）。すなわち、ENUMサーバ４Ａは、接続可能と判定した場合は、公開鍵を設定したDNSレスポンスをSIPサーバ３Ａへ送信する。一方、ENUMサーバ４Ａは、接続不可と判定した場合は、接続不可を設定したDNSレスポンスをSIPサーバ３Ａへ送信する。

SIPサーバ３Ａは、ENUMサーバ4Ａから接続不可が設定されたDNSレスポンスを受信した場合、接続不可を示す403Forbiddenを発信端末１に送信して、処理を終了する（Ｓ３６）。

一方、SIPサーバ３Ａは、ENUMサーバ4Ａから復号鍵が設定されたDNSレスポンスを受信した場合、当該公開鍵を用いて、Ｓ３２で受信したINVITEのSDPに設定された暗号化宛先情報を復号（解読）する（Ｓ３６）。

Ｓ３７からＳ４６は、図３のＳ１７からＳ２６の処理と同じであるため、ここでは説明を省略する。

＜第３の実施形態の変形例＞
第２の実施形態では、ENUMサーバ４Ａ（DBサーバ）にホワイトリストを保持することとしたが、ホワイトリストではなくブラックリストを保持することとしてもよい。

この場合、図４のＳ３４で、ENUMサーバ４Ａは、DNSクエリに設定された発信元情報と、DB42に記憶されたブラックリストとを照合し、発信元情報がブラックリストに存在する否かを判定する。発信元情報がブラックリストに存在しない場合、ENUMサーバ４Ａは、接続可能であると判定し、DNSクエリに設定された宛先IDに対応する公開鍵をDB４２から検索し、取得する。一方、発信元情報がブラックリストに存在する場合、ENUMサーバ４Ａは、発信端末１は接続不可であると判定する。

このように、ENUMサーバ４Ａがブラックリストを保持する場合、宛先端末２は、ブラックリストを利用したサービスを提供することができる。例えば、発信端末１は、宛先端末２に１回しか接続（アクセス）させないという仕組みのサービスを導入することができる。具体的には、ENUMサーバ４Ａは、図４のＳ３４で発信元情報とブラックリストの照合時に、ブラックリストに発信元情報が含まれていない場合は、公開鍵を取得し、公開鍵を含む応答を送信すると共に、当該発信元情報をブラックリストに新たに追加する。このようにすれば、当該発信元情報の発信端末１から２回目の接続要求（INVITE）を受信した場合には、当該発信元情報はブラックリストに含まれるため、２回目以降の接続を不可とすることができる。すなわち、宛先端末２への接続を、１回のみに制限することができる。

以上説明した第１〜第３の本実施形態では、発信端末１は、コードを読み取り、暗号化された宛先情報と、復号鍵を取得するための識別情報とを取得し、暗号化された宛先情報と識別情報とを含む接続要求を、通信サーバ３に送信する。通信サーバ３は、発信端末１から接続要求を受信し、接続要求に含まれる識別情報に対応する復号鍵を取得し、暗号化された宛先情報を復号し、復号した宛先情報を発信端末１に通知することなく、発信端末１と復号した宛先情報を有する宛先端末２とを接続する。

これにより、本実施形態では、宛先情報を判読困難な形式で利用者に提供する場合において、利用者が当該宛先情報を判読することなく、宛先情報を秘匿としたまま、当該宛先情報の宛先との通信を行うことができる。発信元の利用者が、宛先情報が設定されたコードを読み取ったとしても、当該コードに設定されているのは暗号化された宛先情報であるため、元の電話番号などの宛先情報よりも長大になる。そのため目視での複写が難しく、そもそも、コードから読み取った宛先情報は暗号化されているのでそのままでは元情報は判読できない。

また、本実施形態では、通信サーバ３は、接続要求を宛先端末２に送信する際に、接続要求の宛先を復号した宛先情報に書き換えて送信し、接続要求に対する応答を発信端末１に送信する際に、応答に含まれる宛先端末２の宛先情報を、ID情報に書き換えて送信する。これにより、本実施形態では、発信端末１に、復号された宛先情報が保持されることがなく宛先端末２へ発信し通信を確立することができる。

また、第１および第３の実施形態では、DBサーバ４のDB４２には、接続を許可する発信端末１の発信元情報が記憶されたホワイトリスト、または、接続を禁止する発信端末１の発信元情報が記憶されたブラックリストが記憶され、DBサーバ４の受付け処理部４１は、ホワイトリストまたはブラックリストを用いて、発信端末１の接続要求を許可するか否かを判定する。

これにより、本実施形態では、第三者のなりすましによる悪用を防止することができる。すなわち、コードを第三者が撮影して読み取った場合、当該コードに含まれる情報を使って、本来の許可された利用者のみが行うことができる発信処理を、当該第三者が行うことができでしまう。このような、なりすまし対策として、本実施形態では、接続を許可するホワイトリストあるいは接続を許可しないブラックリストをDBサーバ４に設け、接続要求を受けた際に当該DBサーバ４に問い合わせることにより、第三者からのなりすましの接続要求を拒否することができる。

また、本実施形態の通信システムは、名刺交換のような１対１での宛先情報の提供に限らず、各種形態の多様なサービスを実現することが可能である。サービス提供者は、提供するサービス、コンテンツ、あるいはイベントなどへの集客のため、宛先情報を付与したコードを特定の対象者へ提供することが行われている。このようなサービスに本実施形態の通信システムを適用することにより、宛先情報を秘匿するとともに、ホワイトリストあるいはブラックリストを設けることで第三者のなりすましの悪用を防止し、接続を許可する対象者（発信者）を、容易に制限することができる。

これにより、次のようなサービス提供形態が実現できる。例えば、DBサーバ４において、一度発呼し接続要求をしてきた電話番号に対し、２回目以降は接続拒否するようにブラックリストを設定するサービス形態が可能である。これは、コンテンツ利用権やイベント参加権を一回に限るサービス形態などに適用できる。

別の例として、DBサーバ４において、暗号化された宛先情報を解読する公開鍵に有効期限を設定するサービス形態が可能である。この場合、DBサーバ４のDB４２には、有効期限が復号鍵と対応付けて記憶されているものとする。DBサーバ４の受付け処理部４１は、通信サーバ３から復号鍵の問合せに応じて、現時点において有効期限内か否かを判定し、有効期限内であれば復号鍵を通信サーバ３に送信し、有効期限を過ぎている場合は、接続不可の判定結果を通信サーバ３に送信する。これにより、コンテンツ利用権やイベント参加権を得る期間を限定するサービス形態などに適用することができる。

また、本実施形態の宛先情報は、電話番号に限らず、メールアドレスや他の宛先情報形式など各種の宛先情報形式に適用可能である。本実施形態では、宛先情報として、電話番号を中心に説明しているが、宛先情報は電話番号に限られない。メールアドレス、あるいは他の形式の宛先情報であっても、当該宛先情報を暗号化してコードに付与することで、本実施形態の通信システムに適用することができる。

なお、本発明は上記実施形態に限定されるものではなく、その要旨の範囲内で数々の変形が可能である。例えば、上記実施形態では、通信サーバ３の他に、DBサーバ４を備えることとしたが、通信サーバ３とDBサーバとを統合し、通信サーバ３が、DB４２を備えることとしてもよい。

１ ：発信端末
１１：コード読取部
１２：通信部
２ ：宛先端末
２１：サービス処理部
１２：通信部
３ ：通信サーバ
３Ａ、３Ｂ：ＳＩＰサーバ
３１：通信接続部
３２：問合せ処理部
４ ：DBサーバ
４Ａ：ENUMサーバ４Ａ
４１：受付け処理部
４２：DB

Claims (8)

1. 発信端末と通信装置とを備える通信システムであって、
   前記発信端末は、
   コードを読み取り、暗号化された宛先情報と、復号鍵を取得するための識別情報とを取得するコード読取部と、
   前記暗号化された宛先情報と前記識別情報とを含む接続要求を、前記通信装置に送信する送信部とを備え、
   前記通信装置は、
   前記発信端末から前記接続要求を受信する受信部と、
   前記接続要求に含まれる前記識別情報に対応する復号鍵を取得し、前記暗号化された宛先情報を復号する復号部と、
   前記復号した宛先情報を前記発信端末に通知することなく、前記発信端末と、前記復号した宛先情報を有する宛先装置とを接続する通信接続部と、を備えること
   を特徴とする通信システム。
2. 請求項１記載の通信システムであって、
   前記通信接続部は、
   前記接続要求を前記宛先装置に送信する際に、前記接続要求の宛先を前記復号した宛先情報に書き換えて送信し、
   前記接続要求に対する応答を前記発信端末に送信する際に、前記応答に含まれる前記宛先装置の宛先情報を、前記識別情報に書き換えて送信すること
   を特徴とする通信システム。
3. 請求項１または２記載の通信システムであって、
   前記識別情報は、前記宛先装置の宛先識別子と、データベースのドメインとを含み、
   前記データベースには、前記宛先識別子と前記復号鍵とが対応付けて記憶され、
   前記復号部は、前記ドメインを用いて前記データベースにアクセスし、前記宛先識別子に対応する復号鍵を取得すること
   を特徴とする通信システム。
4. 請求項３記載の通信システムであって、
   前記データベースには、接続を許可する発信端末の発信元情報が記憶された許可リスト、または、接続を禁止する発信端末の発信元情報が記憶された禁止リストが記憶され、
   前記許可リストまたは前記禁止リストを用いて、前記発信端末の接続要求を許可するか否かを判定する判定部を備えること
   を特徴とする通信システム。
5. 請求項１から４のいずれか１項に記載の通信システムであって、
   前記通信装置は、SIPサーバであり
   前記通信接続部は、SIP-URIに前記識別情報が設定され、SDPに前記暗号化された宛先情報が設定された前記接続要求を、前記発信端末から受信すること
   を特徴とする通信システム。
6. 請求項１から５のいずれか１項に記載の通信システムであって、
   前記コードは２次元コードであること
   を特徴とする通信システム。
7. 通信装置であって、
   コードを読み取り、暗号化された宛先情報と、復号鍵を取得するための識別情報とを取得する発信端末から、前記暗号化された宛先情報と前記復号鍵とを含む接続要求を受信する受信部と、
   前記接続要求に含まれる前記識別情報に対応する復号鍵を取得し、前記暗号化された宛先情報を復号する復号部と、
   前記復号した宛先情報を前記発信端末に通知することなく、前記発信端末と、前記復号した宛先情報を有する宛先装置とを接続する通信接続部と、を備えること
   を特徴とする通信装置。
8. 通信方法であって、
   発信端末は、
   コードを読み取り、暗号化された宛先情報と、復号鍵を取得するための識別情報とを取得するコード読取ステップと、
   前記暗号化された宛先情報と前記識別情報とを含む接続要求を、通信装置に送信する送信ステップとを行い、
   前記通信装置は、
   前記発信端末から前記接続要求を受信する受信ステップと、
   前記接続要求に含まれる前記識別情報に対応する復号鍵を取得し、前記暗号化された宛先情報を復号する復号ステップと、
   前記復号した宛先情報を前記発信端末に通知することなく、前記発信端末と、前記復号した宛先情報を有する宛先装置とを接続する通信接続ステップと、を行うこと、
   を特徴とする通信方法。

Images