具体的対象保証型バーコードシステムおよび具体的対象保証型バーコード処理方法
【課題】二次元バーコードで示されたサービス提供装置のＵＲＬが正しい関係のものであることを直感的に分かるようにする。
【解決手段】認証装置６はサービス提供装置４からの申請が正当であれば、装置４のＵＲＬとその企業名ＳおよびサービスＡを署名し、ＵＲＬ、署名、Ｓ、Ａ、装置６へのリンクの二次元バーコードデータを生成し、公開鍵を含む検証アプリケーションＤを生成し、上記データを装置４へ送信する。装置６は装置４又はユーザ端末８からＤが要求されると、要求元に、Ｄを送付し、受信した装置は、Ｄにより上記データを署名検証し、検証に成功すると、復号されたＳとＡを表示し、装置４は、上記データにより、媒体に、二次元バーコードを印刷し、端末８では、取り込んだバーコードより、装置４のＵＲＬへアクセスする。
【解決手段】認証装置６はサービス提供装置４からの申請が正当であれば、装置４のＵＲＬとその企業名ＳおよびサービスＡを署名し、ＵＲＬ、署名、Ｓ、Ａ、装置６へのリンクの二次元バーコードデータを生成し、公開鍵を含む検証アプリケーションＤを生成し、上記データを装置４へ送信する。装置６は装置４又はユーザ端末８からＤが要求されると、要求元に、Ｄを送付し、受信した装置は、Ｄにより上記データを署名検証し、検証に成功すると、復号されたＳとＡを表示し、装置４は、上記データにより、媒体に、二次元バーコードを印刷し、端末８では、取り込んだバーコードより、装置４のＵＲＬへアクセスする。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、例えば、ウェブサイトのアドレス、住所、個人の保険証番号など二次元バーコードとして、供給する処理システムおよび処理方法に関するものである。
【背景技術】
【０００２】
携帯電話でウェブサイトのアドレスを入力することは大変な手間である。この問題を解決するためには２種類の技術があり、一般的には両方とも併用されている。
（１）携帯電話のアドレスとして、短く覚えやすいユニークなアドレスを公開することによって入力の負担を軽減する方法。
（２）非特許文献１に記されているように、ウェブアドレスが、ＱＲコード（商標登録）のような二次元バーコードとして、例えば、チラシや広告の隅に印刷されており、その二次元バーコードをカメラつき携帯電話機のカメラで撮影すると、携帯電話機内で、その二次元バーコードを解析して、二次元バーコードが示すウェブアドレスに自動的に接続する。このようにして、ウェブアドレス入力の手間を軽減している方法がある。
【０００３】
また非特許文献２に記されているような二次元バーコードに署名を入れて、バーコードが改ざんされていないかどうかを検証する電子切手の技術も存在する。
【非特許文献１】ｈｔｔｐ：／／ｍｏｂｉｌｅ．ｇｏｏ．ｎｅ．ｊｐ／ｂａｒｃｏｄｅ．ｈｔｍｌ
【非特許文献２】郵政研究所月報１９９９．５ ５９頁〜６６頁
【発明の開示】
【発明が解決しようとする課題】
【０００４】
二次元バーコードからアドレスを取得する場合、そのバーコードを解析するまではどこへのアクセス先なのか分からないため、一般的には、アクセス先のＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）を傍らに分かるように表示する。しかし、上記で示した技術の問題点として２つ存在する。
１点目は、短いアドレスにすればするほど、一見して、そのアドレスが、本当にユーザがアクセスしたい企業や事業のアドレスなのかが判別がつきにくいという問題がある。例えば、株式会社ＡＢＣＤＥＦＧの携帯電話用のアドレスは入力効率を重視して、ｈｔｔｐ：／／１２３．ｊｐというアドレスになっているが、パソコン用のアドレス（本来のＵＲＬ）はｈｔｔｐ：／／ＡＢＣＤＥＦＧ．ｎｅ．ｊｐ／となっている場合がある。どちらも、結局同じサーバに繋がるが、１２３．ｊｐにアクセスしろ、といわれて、すぐに株式会社ＡＢＣＤＥＦＧのサーバに接続する、と認識するのは困難である。
【０００５】
２点目は、その解析したアドレスが傍らに表示されているアドレスと一致しているとも限らないからである。そのため、ユーザが意図しない接続先に誘導するフィッシング詐欺の温床となりうる。
前記従来技術の頁で、最後に紹介した電子切手の技術においては、「偽造」を防ぐために署名を付けているため、例えば、宛先が何らかのミスで誤っていても、それに対する署名が正しければ、正しいものと判別される。つまり、異なっているものと、正しいものを判別できるようにするためのものではない。
【０００６】
ＵＲＬのみならず、電子メールアドレス、企業や個人の住所、個人の保険証番号や住基番号などの具体的対象を、二次元バーコードとして、提供することが考えられる。この場合、その具体的対象がどのようなものに対するかが直感的にわかるもの（直感的対象）を表示でき、しかも、それら具体的対象と直感的対象との関係が正しいことが保証されていれば頗る便利である。
この発明の目的は、具体的対象と直感的対象が正しい関係のものであることを保証する二次元バーコード処理システムおよび、処理方法を提供することにある。
【課題を解決するための手段】
【０００７】
この発明によれば、具体的対象提供装置と認証装置とがネットワークに接続され、認証装置は、入力された直感的対象と具体的対象に対し、署名鍵で署名し、これら両対象とその署名を二次元バーコードデータとして生成し、また公開鍵を含み、上記署名を検証する検証アプリケーションを生成し、具体的対象提供装置は認証装置とリンク接続し、検証アプリケーションを要求し、認証装置から受信した検証アプリケーションにより、二次元バーコードを署名検証し、その検証に合格すれば、二次元バーコードデータを二次元バーコードとして媒体に付加する。
【発明の効果】
【０００８】
以上の構成によれば、信頼できる認証装置が直感的対象と具体的対象に対し、署名を行っており、これら両対象と署名が二次元バーコードにされているため、ユーザ端末がこの二次元バーコードを解析し、具体的対象のみならず、その直感的対象も取得することができ、直感的対象を表示すれば、例えば、具体的対象がＵＲＬでその直感的対象がＳ社のサービスＡと表示され、両者の関係が、ユーザの希望するものか否かを直ちに知ることが出来、しかも、これら両対象に対する署名検証にして合格しているから、両対象の関係が正しいものである。従って、前記例では、フィッシング詐欺などが防止される。
【発明を実施するための最良の形態】
【０００９】
実施例１
以下に実施例１を説明する。なお、ここでは、具体的対象提供装置をサービス提供装置とし直接的対象を企業Ｓとそのサービス名Ａとし、具体的対象を企業ＳのウェブサイトのアドレスＴとする。
図１にこの発明装置の実施形態のシステム構成例を示す。電子的なネットワーク２にサービス提供装置４と信頼できる機関の装置６（以下、認証装置又は、ＣＡ（Ｃｅｒｔｉｆｉｃａｔｅ Ａｕｔｈｏｒｉｔｙという））が繋がっている。サービス提供装置４とＣＡ６はネットワーク２を通じてデータのやり取りを行うことができる。
【００１０】
図２、図３にサービス提供装置４とＣＡ６の機能構成例をそれぞれ示す。まず企業Ｓがサービス提供装置４を通じて、例えば、インターネット上でウェブサイトのアドレスＴとして新たなサービス名Ｓの提供を始めることをＣＡ６に申請する。この申請は、企業Ｓの担当者が直接ＣＡに出向いて申請書類をＣＡの担当者に手渡し、あるいは、申請書類をＣＡ６に郵送することも可能である。ＣＡ６では、この申請書を受け取ると、このリンクして欲しい情報をアドレスＴとの組み合わせが正当かどうか、リンクして欲しい情報と申請者との関係は正当かどうかの検査をする。なお、この申請は、電子的に行ってもよい。つまりサービス提供装置４の入力部４０に企業名ＳとウェブサイトのアドレスＴ、サービス名Ａ、その他、前記正当性の判断に必要なデータを入力し、サービス提供装置４は、これら入力された情報を含む具体的対象要求信号を具体的対象保証要求生成部５４で生成し、通信部４１中の送信部４２により、ネットワーク２を介して、ＣＡ６に送信する。ＣＡ６は、通信部６０中の受信部６１により受信した申請書データを、受信情報判定部６３により、受信データを申請書データと判断して、このデータを正当性確認部６４に入力し、具体的対象保証要求記憶部７８に一旦、記憶して、正当性確認部６４で前記正当性の判断を行う。
【００１１】
ＣＡ６は鍵生成部６５により、署名鍵と公開鍵の組を作成する。そして、署名鍵は署名鍵保管部６６に秘密に保管する。申請者が適正なものと判断されると、入力部７１に企業名Ｓ、サービス名Ａ、企業ＳのウェブサイトのアドレスＴなどを入力する。認証装置６は入力されたこれらの情報を記憶部７２に一旦、記憶し、署名部６７に入力する。署名部６７は、署名鍵を使用して、企業名Ｓ及び、サービス名ＡとウェブサイトのアドレスＴの組み合わせに対して、署名処理をして署名を生成する。
【００１２】
また公開鍵は検証アプリケーション生成部６８に入力されて、公開鍵を含む検証アプリケーションが生成される。ここで、検証アプリケーションとは、署名部６７による署名を検証するためのアプリケーションを意味する。この検証アプリケーションは、検証アプリケーション記憶部６９に記憶される。正当性の得られた企業名Ｓ、サービス名Ａ、企業ＳのウェブサイトのアドレスＴと同様に検証アプリケーションへのリンク（検証アプリケーションのＵＲＬ）が入力部７１により入力され、検証アプリケーションへのリンク記憶部７０に記憶される。
【００１３】
次に、バーコード生成部７３により、二次元バーコードデータが生成される。この実施形態では、二次元バーコードデータに含まれるのは、（１）企業名Ｓ及びサービス名Ａ、（２）企業ＳのウェブサイトのアドレスＴ、（３）企業名Ｓ、およびサービス名Ａと企業ＳのウェブサイトのアドレスＴの組に対する署名、（４）検証アプリケーションへのリンク、の４つである。従って、バーコード生成部７３にはこれらの４つの情報が入力され、バーコード生成部７３はこれらの４つの情報を含むＱＲコードなどの二次元バーコードのデータを生成する。
【００１４】
次に、生成された二次元バーコードのデータを通信部６０中の送信部６２により、サービス提供装置４に、送信する。サービス提供装置４は、受信部４３にした情報が二次元バーコードのデータと、受信情報判定部４４により、判定されると、その受信した二次元バーコードのデータはバーコード記憶部４５に記憶される。このデータにより得られた検証アプリケーションのリンクが検証アプリケーション要求信号生成部４７に入力され、入力されたリンク（ＵＲＬ）に対する検証アプリケーション要求信号が生成される。この検証アプリケーション要求信号は、送信部４２を介して、ＣＡ６に送信される。
【００１５】
この送信された検証アプリケーション要求信号はＣＡ６の受信部６１に受信され、受信情報判定部６３により、受信した情報が検証アプリケーション要求信号と判定され、この要求信号に基づき、検証アプリケーション記憶部６９から検証アプリケーションが読み出される。読み出された検証アプリケーションは送信部６２を経て、ＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔｓ Ｌａｙｅｒ）などの暗号通信方法によりネットワークを介して、サービス提供装置４に送信される。
【００１６】
送信された検証アプリケーションはサービス提供装置４の受信部４３にて受信される。この受信信号は、受信情報判定部４４で、検証アプリケーションと判定され、検証アプリケーション記憶部４８に記憶される。検証アプリケーション記憶部４８に記憶されていた検証アプリケーションとバーコード記憶部４５に記憶されていた二次元バーコードのデータが署名検証部４９に、入力される。
【００１７】
署名検証部４９は、検証アプリケーションを用いて、当該二次元バーコードのデータが正しく署名されているか否か、つまり、検証アプリケーションに含まれる公開鍵を用いて、ＣＡ６の署名鍵による署名であるか否かを検証する。もしこの検証が成功すれば、二次元バーコードのデータと、署名検証部４９よりの検証成功信号とが、表示部５０に入力され、バーコードの解析結果、つまり少なくとも、企業名Ｓ、サービス名Ａが必要に応じて、企業Ｓのサイトアドレス（ＵＲＬ）Ｔも表示され、サービス提供者は、この表示を見て、申請した企業名Ｓ、サービス名Ａ、企業ＳのサイトアドレスＴに対し、正しく署名されたものであることが確認できる。この確認に基づき、入力部４０から媒体付加命令が入力されると、バーコード記憶部４５に保存されていた二次元バーコードのデータが媒体付加部５１に入力され、様々な媒体に、二次元バーコードが付加される。ここで、様々な媒体に付加するというのは、チラシ、ポスター、雑誌などに印刷の他、Ｗｅｂの画像の一部に二次元バーコード画像として挿入するなどが考えられる。そして、これらを、企業Ｓの宣伝と共に、二次元バーコードを配布する。二次元バーコードの媒体付加は、署名検証成功信号に基づき、自動的に行ってよい。
【００１８】
実施例２
次に、生成された二次元バーコードをユーザが使用する場合を説明する。ユーザ端末８の機能構成例を図４に示す。この場合は、図１中に破線で示しているように、ユーザ端末８を、ネットワーク２に繋げる。ユーザは携帯電話機に内蔵されているカメラなどのバーコード取り込み部８０で、二次元バーコードを取り込むと、その二次元バーコード画像データは、バーコード記憶部８１に記憶される。記憶された二次元バーコードの画像データがバーコード解析部８２に入力され、解析され、二次元バーコードのデータが得られ、バーコード解析部８２内に、一時記憶される。この解析の結果中の検証アプリケーションのリンク（ＣＡ６のＵＲＬ）が、検証アプリケーション要求信号生成部８３に入力され、検証アプリケーション要求信号が生成され、通信部８４中の送信部８５より、検証アプリケーション要求信号がＣＡ６に送信され、つまり、ＣＡ６に対して、検証アプリケーションの要求が行われる。
【００１９】
上述と同様の動作により、この検証アプリケーション要求信号がＣＡ６に受信されると、ＣＡ６は、検証アプリケーションをユーザ端末８に送信する。ユーザ端末８に、受信された検証アプリケーションは検証アプリケーション記憶部８７に記憶される。バーコード解析部８２よりの二次元バーコードのデータと、検証アプリケーション記憶部８７に記憶されていた検証アプリケーションが署名検証部８８に入力される。署名検証部８８で、検証アプリケーションを用いて、入力された二次元バーコードのデータの署名を検証する。検証が成功すると、当該検証成功信号とバーコード解析部８２により解析した二次元バーコードのデータとが、表示部８９に入力され、少なくとも企業名Ｓおよびサービス名Ａ、必要に応じて、企業ＳのウェブサイトのアドレスＴが表示部８９に表示される。よってユーザは所望であるならば、企業Ｓのウェブサイトにアクセスしたい旨を入力部９０に入力すると、アクセス要求信号生成部９１より、アクセス要求信号を生成し、送信部８５を通じて、バーコード生成部８２より得られる企業ＳのウェブサイトのアドレスＴに送信し、サービス提供装置４と繋がり、企業Ｓのウェブサイトにアクセスすることが出来、ユーザは、サービスＡを利用部９２で、利用する。
【００２０】
以上により、ユーザは企業Ｓが表示部８９に表示されるため、入力した二次元バーコードのウェブサイトアドレスＴが、企業ＳのサービスＡに対するものであること、つまり、ユーザが所望しているものであるかを、直ちに知ることが出来る。また、ユーザが所望していない（悪意のある第三者の）ホームページにアクセスしてしまうことを気にすることなく正しいアクセス先にユーザ端末８に接続することが出来る。
【００２１】
実施例３
実施例３として、二次元バーコードをＱＲコードＶｅｒ９誤り訂正Ｍに、ＩＳＯ／ＩＥＣ１５９４６−４で規格化されている署名方式ＥＣＡＯを利用した場合について説明する。この場合の二次元バーコードデータの構造を図５に示す。ここでＱＲコードＶｅｒ９誤り訂正ＭはＪＩＳ（ＪＩＳ−Ｘ−０５１０ タイトル：二次元コードシンボル（ＱＲコード基本仕様））やＩＳＯ（ＩＳＯ／ＩＥＣ１８００４）などで規格化されている。また、署名方式ＥＣＡＯとは、メッセージリカバリー部分を持つ署名方式であり、メッセージリカバリーとは、署名が正しいと検証できたときに、メッセージの一部が自動的に復号できる仕組みのことである。
【００２２】
図５記載の（ａ）署名識別子欄には署名方式（楕円曲線のパラメータなどを含む）を表す識別子が記入され、（ｂ）アプリケーション識別子欄には、どの検証アプリケーションがどの提供対象に対応しているかを識別する識別子が記入される。この点については詳しくは後に述べる。
（ｃ）公開鍵番号欄は、検証アプリケーションに含まれている公開鍵の通し番号が記入される。
（ｄ）署名欄は企業名ＳとそのサイトアドレスＴに対する署名が記入される。この署名のうち（ｄ１）欄に記入された部分が、メッセージリカバリーされ、この例では、企業名Ｓ及びサービス名Ａのデータが復号される。（ｄ）署名欄のほかの部分（欄（ｄ２））を署名Ｓという。
（ｅ）平文長欄は（ｆ）メッセージ欄に記入されるメッセージの長さがバイト単位で記入される。
（ｇ）検証アプリケーションのリンク欄は、上述したとおり、検証アプリケーションが設けられている認証装置２のＵＲＬを表す検証アプリケーションへのリンクのデータが記入される。
【００２３】
この例では、署名方式として、メッセージリカバリー部分を持っているため、例えば、前述したように、企業名Ｓとサービス名Ａのデータがリカバリーされるように、署名しておけば、図２中に破線で示すように署名検証部６から復号された企業名Ｓ及びサービス名Ａが表示部５０に入力、表示され、ユーザ端末８において、図４中に破線で示すように、同時に、署名検証部８８から、企業名Ｓ及びサービス名Ａのデータが表示部８９に入力、表示される。
【００２４】
二次元バーコードのように、一般的な電子記憶媒体に比べて、記憶容量が大変少ない状況で、動作する場合が多いため、上述した実施例３に記載した構成例のように、署名長が短く、かつメッセージリカバリー部分を持つ署名方式（例えばＥＣＡＯ署名）を使うことが望ましい。なぜならば、メッセージリカバリー部分を持たない署名方式の場合は、署名は署名が正しいか否かのみに使用され、何らかのメッセージを持つものではなく、従来においては、（ｆ）メッセージ欄には、ＵＲＬのみが記入されていた、また、多くのデータを記入する余裕があまりなかった。しかし、メッセージリカバリー部分を持つ署名方式の場合は、署名Ｒ部分で、企業名Ｓおよびサービス名Ａのデータが復号されるようにしておくと、署名検証を行った際に、企業名Ｓおよびサービス名Ａのデータがリカバリーされ、企業名Ｓおよびサービス名Ａが表示される。そのため、実質的に、メッセージとして使える容量が増えるという効果を得ることが出来る。記憶容量が小さい場合、この差が１割〜２割といった大きなものになるので、より有効である。
【００２５】
また、企業名を表示するのに、リカバリー部分の長さが足りない場合は、例えば、以下のようにすればよい。企業名であるＡＢＣＤＥＦ株式会社の名前が、長すぎてリカバリー部分に入らない場合は、事前に、例えば、図６に示すように、企業識別子テーブルを作成しておき、各企業名に企業名ＩＤ、例えば、「００００１」との関係を付けておき、ＣＡ６において企業識別子テーブルを参照して入力された企業名Ｓの代わりに、企業名ＩＤをリカバリー部分に入れる。ユーザ端末８においては、署名検証部８８から復号された署名検証部８８から復号された企業名ＩＤを企業識別子テーブル９３を参照して、企業名、例えば、ＡＢＣＤＥＦ株式会社に変換して表示部８９へ供給するようにすればよい。このような処理をするように、検証アプリケーションを作成しておく。
【００２６】
また、二次元バーコードのデータ構造が図５の場合、検証アプリケーションに対応していないプラットフォームで利用する場合、つまり、二次元バーコードを解析することは出来るが、署名を検証することが出来ない場合であっても、二次元バーコードを解析すると、メッセージ部分、つまり、企業ＳのウェブサイトのアドレスＴをユーザは読み取ることは出来る。よって、検証アプリケーションに対応していないプラットフォーム用に二次元バーコードのデータを作り変える必要はない。その場合、メッセージリカバリーの部分に署名の有効期限を付した場合でも、署名を検証できないプラットフォームであれば、有効期限が必要でないので、署名検証できないプラットフォーム用に二次元コードを作ることも不要である。
【００２７】
実施例４
以上の説明では、直感的対象を企業名、具体的対象を企業のウェブサイトのアドレスということで説明してきた。しかし本発明は、これに限られず、様々な直感的対象と具体的対象の組み合わせが想定される。直感的対象、具体的対象もデータとしては単なる数字、記号。文字などの配列であるため、直感的対象がどのようなもの（種類）、その具体的対象がどのようなもの（種類）であるかの組み合わせを示すアプリケーション識別子テーブルを用意する。直感的対象が表力するものをＸ、具体的対象が表力するものをＹとし、これらの組み合わせを（Ｘ、Ｙ）と表す。図７に示す例では、アプリケーション識別子「１」は（企業名、電子メールアドレス）、アプリケーション識別子「２」は（団体名、電話番号）、アプリケーション識別子「３」（人名、住基番号）などである。アプリケーション識別子「１」、「２」の提供対象は実施例１〜３のように、二次元バーコードを媒体に付して配布される状況が考えられる。アプリケーション識別子「３」のような提供対象の利用状況は以下の通りである。
【００２８】
アプリケーション識別子「３」のような、つまり、直感的対象を人名、具体的対象を住基番号とした場合の利用例を説明する。例えば、甲が乙の住基番号を乙にたずね、電子メールなどで、乙が甲に送る時に、悪意のある第三者が、乙に成りすまして、甲に不当な住基番号を送ることがある。しかし、この発明の二次元バーコード処理を利用すると、署名されているので、悪意のある第三者の成りすましを防ぐことが出来る。
【００２９】
またこの発明では、ユーザにとって二回目以降、このシステムを利用する場合には、検証アプリケーションが既にダウンロード（検証アプリケーション記憶部８７に記憶）されているので、ユーザは、ＣＡ６に検証アプリケーションを要求する手間が省ける。よって、ユーザは、検証アプリケーションをダウンロードする時は細心の注意を払わないといけないが、その一回のみを注意すれば、後は安心して、利用できる。このことは、時間面においても安全面、通信費面においても効果がある。なお、当然のことであるが、同一のＣＡ６が作成した二次元バーコードデータに対してもこの効果が得られる。
【００３０】
そして、このことは、同じ提供対象を何度も利用する時は当然に該当するが、違う二次元バーコードからそれぞれの二次元バーコードに対応する異なる提供対象を受けようとした場合でも該当する。つまり、異なる申請者に基づく二次元バーコードであっても、同一ＣＡ６で作成された二次元バーコードであれば、その提供対象、例えば、サービス提供装置のＵＲＬを正しく入取できる。つまり、同じＣＡがその（１つの）署名鍵で署名を行う場合は、異なる二次元バーコードに対しても同じ検証アプリケーションを使用して、検証することにより表示される直感的対象で、具体的対象を確認することができる。なお具体的対象がＵＲＬのような場合は、ユーザが意図したアクセス先に接続することが出来る。従って、フィッシング詐欺などを防止することができる。実施例３の説明で述べた図５中の（ｂ）アプリケーション識別子欄にアプリケーション識別子を組み込むことにより、複数の提供対象をアプリケーション識別子という形で区別して、複数の提供対象を汎用的署名、検証アプリケーションを利用することも出来る。この場合は、あらかじめ、アプリケーション識別テーブルを作成しておき、このテーブルをＣＡ６が保持しておく。またＣＡ６の検証アプリケーション生成部６８で、生成する検証アプリケーションにアプリケーション識別子テーブルを組み込む。例えば、ユーザ端末８では、最初に、検証アプリケーションをダウンロードする際に、アプリケーション識別子テーブルが検証アプリケーション記憶部内の領域８７ａ内に格納されている。
【００３１】
例えば、直感的対象が企業名ａ、具体的対象がメールアドレスｂに対しては、そのＣＡ６では、図５中の（ｂ）アプリケーション識別子欄に、Ａ欄のアプリケーション識別子「１」を記入し、企業名ａ、メールアドレスｂのみならず、アプリケーション識別子に対し、署名し、この署名を図５中の（ｄ）欄に記入する。この例では、アプリケーション識別子は検証処理において、メッセージリカバリーされるようにしておく。ユーザ端末８の署名検証部８８で得られたアプリケーション識別子「１」により、領域８７ａ内のアプリケーション識別子テーブルを参照して、直感的対象は企業名として、具体的対象はメールアドレスとして、表示部８９に表示される。
【００３２】
このように単なるデータ（番号、記号、文字など）の配列がアプリケーション識別子テーブルを参照することによりどのような種類の直感的対象、どのような種類の具体的対象であるかが、表示され、各種の対象提供に対し、同一の検証アプリケーションを用いることが出来る。
なお、署名としては、データリカバリー署名方式のみならず、汎用の署名方式、例えば、楕円曲線を使ったＥＣＤＳＡ署名でもよい。この場合は図５中の（ｇ）メッセージ欄に直感的対象データも記入される。
【００３３】
上述したアプリケーション識別子テーブル７４は、図３中に破線で示しており、提供対象の種類の組み合わせが記憶部７２に記憶される。
次に、全体の流れを図８により説明する。ＣＡが署名鍵とそれに対応する公開鍵を鍵生成部６５により生成し（Ｓ８００）、検証アプリケーション生成部６８により公開鍵を含んだ検証アプリケーションを生成する（Ｓ８０２）。そして、具体的対象提供装置４の担当者が企業名Ｓと企業ＳのウェブサイトのアドレスＴである必要書類をＣＡに提出すると（Ｓ８０４）、企業名Ｓと企業ＳのウェブサイトのアドレスＴの関係等を正当性確認部６４により確認し（Ｓ８０６）、企業名Ｓと企業ＳのウェブサイトのアドレスＴの組み合わせを署名鍵により署名部６７で署名を生成する（Ｓ８０８）。検証アプリケーションのリンクと署名と企業名Ｓと企業ＳのウェブサイトのアドレスＴの４つに対する二次元バーコードをバーコード生成部７３で、生成する（Ｓ８１０）。そして具体的対象提供装置４に二次元バーコードのデータを送信し（Ｓ８１２）、検証アプリケーションのリンクを基にＣＡに検証アプリケーションを要求する（Ｓ８１６）。ＣＡは検証アプリケーションを具体的対象提供装置４に送付して（Ｓ８１８）、具体的対象提供装置４は受信した検証アプリケーションを使用して、二次元バーコードの署名が正当であるか否かを署名検証部４６で検証する（Ｓ８２０）。検証が成功であれば、媒体付加部５１で、チラシやウェブサイトの画像などに、二次元バーコードを付加して（Ｓ８２２）、宣伝、広告共に、配布する（Ｓ８２４）。
【００３４】
一方、ユーザが二次元バーコードをバーコード取り込み部８０で取り込むと、
バーコード解析部８２で解析して（Ｓ８２６）、検証アプリケーションのリンクを基にＣＡに検証アプリケーションを要求する（Ｓ８２８）。ＣＡは検証アプリケーションをユーザに送付すると（Ｓ８３０）、ユーザは検証アプリケーションを使用して、二次元バーコードの署名が正当であるか否かを署名検証部８８で検証する（Ｓ８３２）。検証成功であれば、企業名Ｓ、アドレスＴを確認して（Ｓ８３４）、具体的対象提供装置４にアクセス要求を行い（Ｓ８３６）、具体的対象提供装置４は企業Ｓのサイトを公開する（Ｓ８３８）。
【００３５】
次に、ユーザが検証アプリケーションをダウンロードした後、２回目以降の流れを図９を使用して、説明する。尚、この具体的対象提供装置は１回目に二次元バーコードを配布した具体的対象提供装置４と違うもので、提供対象内容が１回目と違っていても、同一のＣＡが作成した二次元バーコードであれば良い。ここでは具体的対象提供装置が１回目と異なり、前回とは異なる二次元バーコードが配布され（Ｓ９００）、この二次元バーコードをユーザは取り込んで（Ｓ９０２）、１回目と同様、二次元バーコードを解析し（Ｓ９０４）、署名を検証する（Ｓ９０６）。ここでの署名の検証に検証アプリケーションが使用されるのであるが、１回目に用いた検証アプリケーションを使用する。これだけで、直感的対象と具体的対象を確認することができ（Ｓ９０８）、１回目と同じ安全性を得ることができる。
なお、具体的対象提供装置４、認証装置６、ユーザ端末８は、それぞれ、コンピュータにより機能させても良い。
【図面の簡単な説明】
【００３６】
【図１】この発明のシステムの構成例を示すブロック図。
【図２】具体的対象提供装置（サービス提供者装置）４の機能構成例を示すブロック図。
【図３】認証装置６の機能構成例を示すブロック図。
【図４】ユーザ端末８の機能構成例を示すブロック図。
【図５】二次元バーコードのデータ構造の例を示す図。
【図６】企業識別子テーブルの例を示す図。
【図７】アプリケーション識別子テーブルの例を示す図。
【図８】検証アプリケーションの１回目のダウンロードの際の全体の流れを示すフローチャート図。
【図９】検証アプリケーションを１回、ダウンロードした後ユーザ端末８と具体的対象提供端末４との間の流れを示すフローチャート図。
【技術分野】
【０００１】
この発明は、例えば、ウェブサイトのアドレス、住所、個人の保険証番号など二次元バーコードとして、供給する処理システムおよび処理方法に関するものである。
【背景技術】
【０００２】
携帯電話でウェブサイトのアドレスを入力することは大変な手間である。この問題を解決するためには２種類の技術があり、一般的には両方とも併用されている。
（１）携帯電話のアドレスとして、短く覚えやすいユニークなアドレスを公開することによって入力の負担を軽減する方法。
（２）非特許文献１に記されているように、ウェブアドレスが、ＱＲコード（商標登録）のような二次元バーコードとして、例えば、チラシや広告の隅に印刷されており、その二次元バーコードをカメラつき携帯電話機のカメラで撮影すると、携帯電話機内で、その二次元バーコードを解析して、二次元バーコードが示すウェブアドレスに自動的に接続する。このようにして、ウェブアドレス入力の手間を軽減している方法がある。
【０００３】
また非特許文献２に記されているような二次元バーコードに署名を入れて、バーコードが改ざんされていないかどうかを検証する電子切手の技術も存在する。
【非特許文献１】ｈｔｔｐ：／／ｍｏｂｉｌｅ．ｇｏｏ．ｎｅ．ｊｐ／ｂａｒｃｏｄｅ．ｈｔｍｌ
【非特許文献２】郵政研究所月報１９９９．５ ５９頁〜６６頁
【発明の開示】
【発明が解決しようとする課題】
【０００４】
二次元バーコードからアドレスを取得する場合、そのバーコードを解析するまではどこへのアクセス先なのか分からないため、一般的には、アクセス先のＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）を傍らに分かるように表示する。しかし、上記で示した技術の問題点として２つ存在する。
１点目は、短いアドレスにすればするほど、一見して、そのアドレスが、本当にユーザがアクセスしたい企業や事業のアドレスなのかが判別がつきにくいという問題がある。例えば、株式会社ＡＢＣＤＥＦＧの携帯電話用のアドレスは入力効率を重視して、ｈｔｔｐ：／／１２３．ｊｐというアドレスになっているが、パソコン用のアドレス（本来のＵＲＬ）はｈｔｔｐ：／／ＡＢＣＤＥＦＧ．ｎｅ．ｊｐ／となっている場合がある。どちらも、結局同じサーバに繋がるが、１２３．ｊｐにアクセスしろ、といわれて、すぐに株式会社ＡＢＣＤＥＦＧのサーバに接続する、と認識するのは困難である。
【０００５】
２点目は、その解析したアドレスが傍らに表示されているアドレスと一致しているとも限らないからである。そのため、ユーザが意図しない接続先に誘導するフィッシング詐欺の温床となりうる。
前記従来技術の頁で、最後に紹介した電子切手の技術においては、「偽造」を防ぐために署名を付けているため、例えば、宛先が何らかのミスで誤っていても、それに対する署名が正しければ、正しいものと判別される。つまり、異なっているものと、正しいものを判別できるようにするためのものではない。
【０００６】
ＵＲＬのみならず、電子メールアドレス、企業や個人の住所、個人の保険証番号や住基番号などの具体的対象を、二次元バーコードとして、提供することが考えられる。この場合、その具体的対象がどのようなものに対するかが直感的にわかるもの（直感的対象）を表示でき、しかも、それら具体的対象と直感的対象との関係が正しいことが保証されていれば頗る便利である。
この発明の目的は、具体的対象と直感的対象が正しい関係のものであることを保証する二次元バーコード処理システムおよび、処理方法を提供することにある。
【課題を解決するための手段】
【０００７】
この発明によれば、具体的対象提供装置と認証装置とがネットワークに接続され、認証装置は、入力された直感的対象と具体的対象に対し、署名鍵で署名し、これら両対象とその署名を二次元バーコードデータとして生成し、また公開鍵を含み、上記署名を検証する検証アプリケーションを生成し、具体的対象提供装置は認証装置とリンク接続し、検証アプリケーションを要求し、認証装置から受信した検証アプリケーションにより、二次元バーコードを署名検証し、その検証に合格すれば、二次元バーコードデータを二次元バーコードとして媒体に付加する。
【発明の効果】
【０００８】
以上の構成によれば、信頼できる認証装置が直感的対象と具体的対象に対し、署名を行っており、これら両対象と署名が二次元バーコードにされているため、ユーザ端末がこの二次元バーコードを解析し、具体的対象のみならず、その直感的対象も取得することができ、直感的対象を表示すれば、例えば、具体的対象がＵＲＬでその直感的対象がＳ社のサービスＡと表示され、両者の関係が、ユーザの希望するものか否かを直ちに知ることが出来、しかも、これら両対象に対する署名検証にして合格しているから、両対象の関係が正しいものである。従って、前記例では、フィッシング詐欺などが防止される。
【発明を実施するための最良の形態】
【０００９】
実施例１
以下に実施例１を説明する。なお、ここでは、具体的対象提供装置をサービス提供装置とし直接的対象を企業Ｓとそのサービス名Ａとし、具体的対象を企業ＳのウェブサイトのアドレスＴとする。
図１にこの発明装置の実施形態のシステム構成例を示す。電子的なネットワーク２にサービス提供装置４と信頼できる機関の装置６（以下、認証装置又は、ＣＡ（Ｃｅｒｔｉｆｉｃａｔｅ Ａｕｔｈｏｒｉｔｙという））が繋がっている。サービス提供装置４とＣＡ６はネットワーク２を通じてデータのやり取りを行うことができる。
【００１０】
図２、図３にサービス提供装置４とＣＡ６の機能構成例をそれぞれ示す。まず企業Ｓがサービス提供装置４を通じて、例えば、インターネット上でウェブサイトのアドレスＴとして新たなサービス名Ｓの提供を始めることをＣＡ６に申請する。この申請は、企業Ｓの担当者が直接ＣＡに出向いて申請書類をＣＡの担当者に手渡し、あるいは、申請書類をＣＡ６に郵送することも可能である。ＣＡ６では、この申請書を受け取ると、このリンクして欲しい情報をアドレスＴとの組み合わせが正当かどうか、リンクして欲しい情報と申請者との関係は正当かどうかの検査をする。なお、この申請は、電子的に行ってもよい。つまりサービス提供装置４の入力部４０に企業名ＳとウェブサイトのアドレスＴ、サービス名Ａ、その他、前記正当性の判断に必要なデータを入力し、サービス提供装置４は、これら入力された情報を含む具体的対象要求信号を具体的対象保証要求生成部５４で生成し、通信部４１中の送信部４２により、ネットワーク２を介して、ＣＡ６に送信する。ＣＡ６は、通信部６０中の受信部６１により受信した申請書データを、受信情報判定部６３により、受信データを申請書データと判断して、このデータを正当性確認部６４に入力し、具体的対象保証要求記憶部７８に一旦、記憶して、正当性確認部６４で前記正当性の判断を行う。
【００１１】
ＣＡ６は鍵生成部６５により、署名鍵と公開鍵の組を作成する。そして、署名鍵は署名鍵保管部６６に秘密に保管する。申請者が適正なものと判断されると、入力部７１に企業名Ｓ、サービス名Ａ、企業ＳのウェブサイトのアドレスＴなどを入力する。認証装置６は入力されたこれらの情報を記憶部７２に一旦、記憶し、署名部６７に入力する。署名部６７は、署名鍵を使用して、企業名Ｓ及び、サービス名ＡとウェブサイトのアドレスＴの組み合わせに対して、署名処理をして署名を生成する。
【００１２】
また公開鍵は検証アプリケーション生成部６８に入力されて、公開鍵を含む検証アプリケーションが生成される。ここで、検証アプリケーションとは、署名部６７による署名を検証するためのアプリケーションを意味する。この検証アプリケーションは、検証アプリケーション記憶部６９に記憶される。正当性の得られた企業名Ｓ、サービス名Ａ、企業ＳのウェブサイトのアドレスＴと同様に検証アプリケーションへのリンク（検証アプリケーションのＵＲＬ）が入力部７１により入力され、検証アプリケーションへのリンク記憶部７０に記憶される。
【００１３】
次に、バーコード生成部７３により、二次元バーコードデータが生成される。この実施形態では、二次元バーコードデータに含まれるのは、（１）企業名Ｓ及びサービス名Ａ、（２）企業ＳのウェブサイトのアドレスＴ、（３）企業名Ｓ、およびサービス名Ａと企業ＳのウェブサイトのアドレスＴの組に対する署名、（４）検証アプリケーションへのリンク、の４つである。従って、バーコード生成部７３にはこれらの４つの情報が入力され、バーコード生成部７３はこれらの４つの情報を含むＱＲコードなどの二次元バーコードのデータを生成する。
【００１４】
次に、生成された二次元バーコードのデータを通信部６０中の送信部６２により、サービス提供装置４に、送信する。サービス提供装置４は、受信部４３にした情報が二次元バーコードのデータと、受信情報判定部４４により、判定されると、その受信した二次元バーコードのデータはバーコード記憶部４５に記憶される。このデータにより得られた検証アプリケーションのリンクが検証アプリケーション要求信号生成部４７に入力され、入力されたリンク（ＵＲＬ）に対する検証アプリケーション要求信号が生成される。この検証アプリケーション要求信号は、送信部４２を介して、ＣＡ６に送信される。
【００１５】
この送信された検証アプリケーション要求信号はＣＡ６の受信部６１に受信され、受信情報判定部６３により、受信した情報が検証アプリケーション要求信号と判定され、この要求信号に基づき、検証アプリケーション記憶部６９から検証アプリケーションが読み出される。読み出された検証アプリケーションは送信部６２を経て、ＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔｓ Ｌａｙｅｒ）などの暗号通信方法によりネットワークを介して、サービス提供装置４に送信される。
【００１６】
送信された検証アプリケーションはサービス提供装置４の受信部４３にて受信される。この受信信号は、受信情報判定部４４で、検証アプリケーションと判定され、検証アプリケーション記憶部４８に記憶される。検証アプリケーション記憶部４８に記憶されていた検証アプリケーションとバーコード記憶部４５に記憶されていた二次元バーコードのデータが署名検証部４９に、入力される。
【００１７】
署名検証部４９は、検証アプリケーションを用いて、当該二次元バーコードのデータが正しく署名されているか否か、つまり、検証アプリケーションに含まれる公開鍵を用いて、ＣＡ６の署名鍵による署名であるか否かを検証する。もしこの検証が成功すれば、二次元バーコードのデータと、署名検証部４９よりの検証成功信号とが、表示部５０に入力され、バーコードの解析結果、つまり少なくとも、企業名Ｓ、サービス名Ａが必要に応じて、企業Ｓのサイトアドレス（ＵＲＬ）Ｔも表示され、サービス提供者は、この表示を見て、申請した企業名Ｓ、サービス名Ａ、企業ＳのサイトアドレスＴに対し、正しく署名されたものであることが確認できる。この確認に基づき、入力部４０から媒体付加命令が入力されると、バーコード記憶部４５に保存されていた二次元バーコードのデータが媒体付加部５１に入力され、様々な媒体に、二次元バーコードが付加される。ここで、様々な媒体に付加するというのは、チラシ、ポスター、雑誌などに印刷の他、Ｗｅｂの画像の一部に二次元バーコード画像として挿入するなどが考えられる。そして、これらを、企業Ｓの宣伝と共に、二次元バーコードを配布する。二次元バーコードの媒体付加は、署名検証成功信号に基づき、自動的に行ってよい。
【００１８】
実施例２
次に、生成された二次元バーコードをユーザが使用する場合を説明する。ユーザ端末８の機能構成例を図４に示す。この場合は、図１中に破線で示しているように、ユーザ端末８を、ネットワーク２に繋げる。ユーザは携帯電話機に内蔵されているカメラなどのバーコード取り込み部８０で、二次元バーコードを取り込むと、その二次元バーコード画像データは、バーコード記憶部８１に記憶される。記憶された二次元バーコードの画像データがバーコード解析部８２に入力され、解析され、二次元バーコードのデータが得られ、バーコード解析部８２内に、一時記憶される。この解析の結果中の検証アプリケーションのリンク（ＣＡ６のＵＲＬ）が、検証アプリケーション要求信号生成部８３に入力され、検証アプリケーション要求信号が生成され、通信部８４中の送信部８５より、検証アプリケーション要求信号がＣＡ６に送信され、つまり、ＣＡ６に対して、検証アプリケーションの要求が行われる。
【００１９】
上述と同様の動作により、この検証アプリケーション要求信号がＣＡ６に受信されると、ＣＡ６は、検証アプリケーションをユーザ端末８に送信する。ユーザ端末８に、受信された検証アプリケーションは検証アプリケーション記憶部８７に記憶される。バーコード解析部８２よりの二次元バーコードのデータと、検証アプリケーション記憶部８７に記憶されていた検証アプリケーションが署名検証部８８に入力される。署名検証部８８で、検証アプリケーションを用いて、入力された二次元バーコードのデータの署名を検証する。検証が成功すると、当該検証成功信号とバーコード解析部８２により解析した二次元バーコードのデータとが、表示部８９に入力され、少なくとも企業名Ｓおよびサービス名Ａ、必要に応じて、企業ＳのウェブサイトのアドレスＴが表示部８９に表示される。よってユーザは所望であるならば、企業Ｓのウェブサイトにアクセスしたい旨を入力部９０に入力すると、アクセス要求信号生成部９１より、アクセス要求信号を生成し、送信部８５を通じて、バーコード生成部８２より得られる企業ＳのウェブサイトのアドレスＴに送信し、サービス提供装置４と繋がり、企業Ｓのウェブサイトにアクセスすることが出来、ユーザは、サービスＡを利用部９２で、利用する。
【００２０】
以上により、ユーザは企業Ｓが表示部８９に表示されるため、入力した二次元バーコードのウェブサイトアドレスＴが、企業ＳのサービスＡに対するものであること、つまり、ユーザが所望しているものであるかを、直ちに知ることが出来る。また、ユーザが所望していない（悪意のある第三者の）ホームページにアクセスしてしまうことを気にすることなく正しいアクセス先にユーザ端末８に接続することが出来る。
【００２１】
実施例３
実施例３として、二次元バーコードをＱＲコードＶｅｒ９誤り訂正Ｍに、ＩＳＯ／ＩＥＣ１５９４６−４で規格化されている署名方式ＥＣＡＯを利用した場合について説明する。この場合の二次元バーコードデータの構造を図５に示す。ここでＱＲコードＶｅｒ９誤り訂正ＭはＪＩＳ（ＪＩＳ−Ｘ−０５１０ タイトル：二次元コードシンボル（ＱＲコード基本仕様））やＩＳＯ（ＩＳＯ／ＩＥＣ１８００４）などで規格化されている。また、署名方式ＥＣＡＯとは、メッセージリカバリー部分を持つ署名方式であり、メッセージリカバリーとは、署名が正しいと検証できたときに、メッセージの一部が自動的に復号できる仕組みのことである。
【００２２】
図５記載の（ａ）署名識別子欄には署名方式（楕円曲線のパラメータなどを含む）を表す識別子が記入され、（ｂ）アプリケーション識別子欄には、どの検証アプリケーションがどの提供対象に対応しているかを識別する識別子が記入される。この点については詳しくは後に述べる。
（ｃ）公開鍵番号欄は、検証アプリケーションに含まれている公開鍵の通し番号が記入される。
（ｄ）署名欄は企業名ＳとそのサイトアドレスＴに対する署名が記入される。この署名のうち（ｄ１）欄に記入された部分が、メッセージリカバリーされ、この例では、企業名Ｓ及びサービス名Ａのデータが復号される。（ｄ）署名欄のほかの部分（欄（ｄ２））を署名Ｓという。
（ｅ）平文長欄は（ｆ）メッセージ欄に記入されるメッセージの長さがバイト単位で記入される。
（ｇ）検証アプリケーションのリンク欄は、上述したとおり、検証アプリケーションが設けられている認証装置２のＵＲＬを表す検証アプリケーションへのリンクのデータが記入される。
【００２３】
この例では、署名方式として、メッセージリカバリー部分を持っているため、例えば、前述したように、企業名Ｓとサービス名Ａのデータがリカバリーされるように、署名しておけば、図２中に破線で示すように署名検証部６から復号された企業名Ｓ及びサービス名Ａが表示部５０に入力、表示され、ユーザ端末８において、図４中に破線で示すように、同時に、署名検証部８８から、企業名Ｓ及びサービス名Ａのデータが表示部８９に入力、表示される。
【００２４】
二次元バーコードのように、一般的な電子記憶媒体に比べて、記憶容量が大変少ない状況で、動作する場合が多いため、上述した実施例３に記載した構成例のように、署名長が短く、かつメッセージリカバリー部分を持つ署名方式（例えばＥＣＡＯ署名）を使うことが望ましい。なぜならば、メッセージリカバリー部分を持たない署名方式の場合は、署名は署名が正しいか否かのみに使用され、何らかのメッセージを持つものではなく、従来においては、（ｆ）メッセージ欄には、ＵＲＬのみが記入されていた、また、多くのデータを記入する余裕があまりなかった。しかし、メッセージリカバリー部分を持つ署名方式の場合は、署名Ｒ部分で、企業名Ｓおよびサービス名Ａのデータが復号されるようにしておくと、署名検証を行った際に、企業名Ｓおよびサービス名Ａのデータがリカバリーされ、企業名Ｓおよびサービス名Ａが表示される。そのため、実質的に、メッセージとして使える容量が増えるという効果を得ることが出来る。記憶容量が小さい場合、この差が１割〜２割といった大きなものになるので、より有効である。
【００２５】
また、企業名を表示するのに、リカバリー部分の長さが足りない場合は、例えば、以下のようにすればよい。企業名であるＡＢＣＤＥＦ株式会社の名前が、長すぎてリカバリー部分に入らない場合は、事前に、例えば、図６に示すように、企業識別子テーブルを作成しておき、各企業名に企業名ＩＤ、例えば、「００００１」との関係を付けておき、ＣＡ６において企業識別子テーブルを参照して入力された企業名Ｓの代わりに、企業名ＩＤをリカバリー部分に入れる。ユーザ端末８においては、署名検証部８８から復号された署名検証部８８から復号された企業名ＩＤを企業識別子テーブル９３を参照して、企業名、例えば、ＡＢＣＤＥＦ株式会社に変換して表示部８９へ供給するようにすればよい。このような処理をするように、検証アプリケーションを作成しておく。
【００２６】
また、二次元バーコードのデータ構造が図５の場合、検証アプリケーションに対応していないプラットフォームで利用する場合、つまり、二次元バーコードを解析することは出来るが、署名を検証することが出来ない場合であっても、二次元バーコードを解析すると、メッセージ部分、つまり、企業ＳのウェブサイトのアドレスＴをユーザは読み取ることは出来る。よって、検証アプリケーションに対応していないプラットフォーム用に二次元バーコードのデータを作り変える必要はない。その場合、メッセージリカバリーの部分に署名の有効期限を付した場合でも、署名を検証できないプラットフォームであれば、有効期限が必要でないので、署名検証できないプラットフォーム用に二次元コードを作ることも不要である。
【００２７】
実施例４
以上の説明では、直感的対象を企業名、具体的対象を企業のウェブサイトのアドレスということで説明してきた。しかし本発明は、これに限られず、様々な直感的対象と具体的対象の組み合わせが想定される。直感的対象、具体的対象もデータとしては単なる数字、記号。文字などの配列であるため、直感的対象がどのようなもの（種類）、その具体的対象がどのようなもの（種類）であるかの組み合わせを示すアプリケーション識別子テーブルを用意する。直感的対象が表力するものをＸ、具体的対象が表力するものをＹとし、これらの組み合わせを（Ｘ、Ｙ）と表す。図７に示す例では、アプリケーション識別子「１」は（企業名、電子メールアドレス）、アプリケーション識別子「２」は（団体名、電話番号）、アプリケーション識別子「３」（人名、住基番号）などである。アプリケーション識別子「１」、「２」の提供対象は実施例１〜３のように、二次元バーコードを媒体に付して配布される状況が考えられる。アプリケーション識別子「３」のような提供対象の利用状況は以下の通りである。
【００２８】
アプリケーション識別子「３」のような、つまり、直感的対象を人名、具体的対象を住基番号とした場合の利用例を説明する。例えば、甲が乙の住基番号を乙にたずね、電子メールなどで、乙が甲に送る時に、悪意のある第三者が、乙に成りすまして、甲に不当な住基番号を送ることがある。しかし、この発明の二次元バーコード処理を利用すると、署名されているので、悪意のある第三者の成りすましを防ぐことが出来る。
【００２９】
またこの発明では、ユーザにとって二回目以降、このシステムを利用する場合には、検証アプリケーションが既にダウンロード（検証アプリケーション記憶部８７に記憶）されているので、ユーザは、ＣＡ６に検証アプリケーションを要求する手間が省ける。よって、ユーザは、検証アプリケーションをダウンロードする時は細心の注意を払わないといけないが、その一回のみを注意すれば、後は安心して、利用できる。このことは、時間面においても安全面、通信費面においても効果がある。なお、当然のことであるが、同一のＣＡ６が作成した二次元バーコードデータに対してもこの効果が得られる。
【００３０】
そして、このことは、同じ提供対象を何度も利用する時は当然に該当するが、違う二次元バーコードからそれぞれの二次元バーコードに対応する異なる提供対象を受けようとした場合でも該当する。つまり、異なる申請者に基づく二次元バーコードであっても、同一ＣＡ６で作成された二次元バーコードであれば、その提供対象、例えば、サービス提供装置のＵＲＬを正しく入取できる。つまり、同じＣＡがその（１つの）署名鍵で署名を行う場合は、異なる二次元バーコードに対しても同じ検証アプリケーションを使用して、検証することにより表示される直感的対象で、具体的対象を確認することができる。なお具体的対象がＵＲＬのような場合は、ユーザが意図したアクセス先に接続することが出来る。従って、フィッシング詐欺などを防止することができる。実施例３の説明で述べた図５中の（ｂ）アプリケーション識別子欄にアプリケーション識別子を組み込むことにより、複数の提供対象をアプリケーション識別子という形で区別して、複数の提供対象を汎用的署名、検証アプリケーションを利用することも出来る。この場合は、あらかじめ、アプリケーション識別テーブルを作成しておき、このテーブルをＣＡ６が保持しておく。またＣＡ６の検証アプリケーション生成部６８で、生成する検証アプリケーションにアプリケーション識別子テーブルを組み込む。例えば、ユーザ端末８では、最初に、検証アプリケーションをダウンロードする際に、アプリケーション識別子テーブルが検証アプリケーション記憶部内の領域８７ａ内に格納されている。
【００３１】
例えば、直感的対象が企業名ａ、具体的対象がメールアドレスｂに対しては、そのＣＡ６では、図５中の（ｂ）アプリケーション識別子欄に、Ａ欄のアプリケーション識別子「１」を記入し、企業名ａ、メールアドレスｂのみならず、アプリケーション識別子に対し、署名し、この署名を図５中の（ｄ）欄に記入する。この例では、アプリケーション識別子は検証処理において、メッセージリカバリーされるようにしておく。ユーザ端末８の署名検証部８８で得られたアプリケーション識別子「１」により、領域８７ａ内のアプリケーション識別子テーブルを参照して、直感的対象は企業名として、具体的対象はメールアドレスとして、表示部８９に表示される。
【００３２】
このように単なるデータ（番号、記号、文字など）の配列がアプリケーション識別子テーブルを参照することによりどのような種類の直感的対象、どのような種類の具体的対象であるかが、表示され、各種の対象提供に対し、同一の検証アプリケーションを用いることが出来る。
なお、署名としては、データリカバリー署名方式のみならず、汎用の署名方式、例えば、楕円曲線を使ったＥＣＤＳＡ署名でもよい。この場合は図５中の（ｇ）メッセージ欄に直感的対象データも記入される。
【００３３】
上述したアプリケーション識別子テーブル７４は、図３中に破線で示しており、提供対象の種類の組み合わせが記憶部７２に記憶される。
次に、全体の流れを図８により説明する。ＣＡが署名鍵とそれに対応する公開鍵を鍵生成部６５により生成し（Ｓ８００）、検証アプリケーション生成部６８により公開鍵を含んだ検証アプリケーションを生成する（Ｓ８０２）。そして、具体的対象提供装置４の担当者が企業名Ｓと企業ＳのウェブサイトのアドレスＴである必要書類をＣＡに提出すると（Ｓ８０４）、企業名Ｓと企業ＳのウェブサイトのアドレスＴの関係等を正当性確認部６４により確認し（Ｓ８０６）、企業名Ｓと企業ＳのウェブサイトのアドレスＴの組み合わせを署名鍵により署名部６７で署名を生成する（Ｓ８０８）。検証アプリケーションのリンクと署名と企業名Ｓと企業ＳのウェブサイトのアドレスＴの４つに対する二次元バーコードをバーコード生成部７３で、生成する（Ｓ８１０）。そして具体的対象提供装置４に二次元バーコードのデータを送信し（Ｓ８１２）、検証アプリケーションのリンクを基にＣＡに検証アプリケーションを要求する（Ｓ８１６）。ＣＡは検証アプリケーションを具体的対象提供装置４に送付して（Ｓ８１８）、具体的対象提供装置４は受信した検証アプリケーションを使用して、二次元バーコードの署名が正当であるか否かを署名検証部４６で検証する（Ｓ８２０）。検証が成功であれば、媒体付加部５１で、チラシやウェブサイトの画像などに、二次元バーコードを付加して（Ｓ８２２）、宣伝、広告共に、配布する（Ｓ８２４）。
【００３４】
一方、ユーザが二次元バーコードをバーコード取り込み部８０で取り込むと、
バーコード解析部８２で解析して（Ｓ８２６）、検証アプリケーションのリンクを基にＣＡに検証アプリケーションを要求する（Ｓ８２８）。ＣＡは検証アプリケーションをユーザに送付すると（Ｓ８３０）、ユーザは検証アプリケーションを使用して、二次元バーコードの署名が正当であるか否かを署名検証部８８で検証する（Ｓ８３２）。検証成功であれば、企業名Ｓ、アドレスＴを確認して（Ｓ８３４）、具体的対象提供装置４にアクセス要求を行い（Ｓ８３６）、具体的対象提供装置４は企業Ｓのサイトを公開する（Ｓ８３８）。
【００３５】
次に、ユーザが検証アプリケーションをダウンロードした後、２回目以降の流れを図９を使用して、説明する。尚、この具体的対象提供装置は１回目に二次元バーコードを配布した具体的対象提供装置４と違うもので、提供対象内容が１回目と違っていても、同一のＣＡが作成した二次元バーコードであれば良い。ここでは具体的対象提供装置が１回目と異なり、前回とは異なる二次元バーコードが配布され（Ｓ９００）、この二次元バーコードをユーザは取り込んで（Ｓ９０２）、１回目と同様、二次元バーコードを解析し（Ｓ９０４）、署名を検証する（Ｓ９０６）。ここでの署名の検証に検証アプリケーションが使用されるのであるが、１回目に用いた検証アプリケーションを使用する。これだけで、直感的対象と具体的対象を確認することができ（Ｓ９０８）、１回目と同じ安全性を得ることができる。
なお、具体的対象提供装置４、認証装置６、ユーザ端末８は、それぞれ、コンピュータにより機能させても良い。
【図面の簡単な説明】
【００３６】
【図１】この発明のシステムの構成例を示すブロック図。
【図２】具体的対象提供装置（サービス提供者装置）４の機能構成例を示すブロック図。
【図３】認証装置６の機能構成例を示すブロック図。
【図４】ユーザ端末８の機能構成例を示すブロック図。
【図５】二次元バーコードのデータ構造の例を示す図。
【図６】企業識別子テーブルの例を示す図。
【図７】アプリケーション識別子テーブルの例を示す図。
【図８】検証アプリケーションの１回目のダウンロードの際の全体の流れを示すフローチャート図。
【図９】検証アプリケーションを１回、ダウンロードした後ユーザ端末８と具体的対象提供端末４との間の流れを示すフローチャート図。
【特許請求の範囲】
【請求項１】
具体的対象提供装置と認証装置とがネットワークを通じて接続されるシステムにおいて、
上記認証装置は、署名鍵とこれに対応する公開鍵とを生成する鍵生成部と、
入力された直感的対象及び具体的対象に対する上記署名鍵で署名を生成する署名部と、
上記直感的対象と上記具体的対象と上記署名と上記認証装置の接続リンク（アドレス）を二次元バーコードデータとして生成するバーコード生成部と、
上記公開鍵を含み、上記署名の検証を行う検証アプリケーションを生成する検証アプリケーション生成部と、
上記検証アプリケーションを記憶する検証アプリケーション記憶部と、
上記二次元バーコードデータを上記具体的対象提供装置へ送信し、検証アプリケーション要求を受信し、受信した検証アプリケーションを要求元へ上記検証アプリケーションを送付する通信部を具備し、
上記具体的対象提供装置は、上記認証装置から送られてきた上記二次元バーコードデータを記憶するバーコード記憶部と、
上記二次元バーコードデータからの上記接続リンクに基づき、上記認証装置に、上記検証アプリケーション要求信号を生成する検証アプリケーション要求信号生成部と、
上記通信部により受信した検証アプリケーションを記憶する検証アプリケーション記憶部と、
上記検証アプリケーションを使用して、上記二次元バーコードデータに含まれる上記署名を検証する署名検証部と、
上記署名検証が成功すれば、上記二次元バーコードを媒体に付加する媒体付加部と、
上記二次元バーコードデータを受信し、上記検証アプリケーション要求信号を上記認証装置へ送信し、上記認証装置からの検証アプリケーションを受信する通信部と
を具備することを特徴とする具体的対象保証型バーコードシステム。
【請求項２】
具体的対象提供装置と認証装置とがネットワークを通じて接続されるシステムにおいて、
上記認証装置は、署名鍵とこれに対応する公開鍵とを生成する鍵生成部と、
入力された直感的対象と具体的対象に対し、署名検証に成功すると、上記直感的対象が、自動的に復号されるメッセージリカバリー部分を持つ署名方式による署名を生成する署名部と、
上記具体的対象と上記署名と上記認証装置の接続リンク（アドレス）を二次元バーコードデータとして生成するバーコード生成部と、
上記公開鍵を含み、上記署名の検証を行う検証アプリケーションを生成する検証アプリケーション生成部と、
上記検証アプリケーションを記憶する検証アプリケーション記憶部と、
上記二次元バーコードデータを上記具体的対象提供装置へ送信し、検証アプリケーション要求を受信し、受信した検証アプリケーションを要求元へ上記検証アプリケーションを送付する通信部を具備し、
上記具体的対象提供装置は、上記認証装置から送られてきた上記二次元バーコードデータを記憶するバーコード記憶部と、
上記二次元バーコードデータからの上記接続リンクに基づき、上記認証装置に、上記検証アプリケーション要求信号を生成する検証アプリケーション要求信号生成部と、
上記通信部により受信した検証アプリケーションを記憶する検証アプリケーション記憶部と、
上記検証アプリケーションを使用して、上記二次元バーコードデータに含まれる上記署名を検証する署名検証部と、
上記署名検証が成功すれば、上記二次元バーコードを媒体に付加する媒体付加部と、
上記二次元バーコードデータを受信し、上記検証アプリケーション要求信号を上記認証装置へ送信し、上記認証装置からの検証アプリケーションを受信する通信部と
を具備することを特徴とする具体的対象保証型バーコードシステム。
【請求項３】
請求項１又は２に記載のシステムにおいて、
上記ネットワークにユーザ端末が接続され、
上記ユーザ端末は、媒体に付加されている二次元バーコードを二次元バーコードデータとして取り込むバーコード取り込み部と、
上記取り込んだ二次元バーコードをデータとして記憶するバーコード記憶部と、
上記二次元バーコードデータを解析するバーコード解析部と、
上記解析されたバーコードデータから、上記認証装置に対し、上記検証アプリケーションを要求する検証アプリケーション要求信号生成部と、
受信した上記検証アプリケーションを記憶する検証アプリケーション記憶部と、
上記検証アプリケーションを使用して、上記二次元バーコードデータに含まれる上記署名を検証する署名検証部と、
上記署名検証が成功であれば、上記バーコードシステム解析部からの具体的対象を利用する利用部と、
上記バーコード解析部又は、上記署名検証部から得られる上記直感的対象と上記具体的対象を表示する表示部と、
上記検証アプリケーション生成信号を上記認証装置へ送信し、上記認証装置からの検証アプリケーションを受信する通信部と、
を具備することを特徴とする具体的対象保証型バーコードシステム。
【請求項４】
請求項１〜３のいずれかに記載のシステムにおいて、
上記バーコード生成部は、上記直感的対象と具体的対象との組ごとのアプリケーション識別子が入力され、上記二次元バーコードデータにアプリケーション識別子を組み込むものである
ことを特徴とする具体的対象保証型バーコードシステム。
【請求項５】
請求項１〜４の何れかに記載のシステムにおいて、
上記具体的対象提供装置は、上記署名に成功すれば、上記バーコード解析部又はこれに加え、上記署名検証部からのデータにより、上記直感的対象と上記具体的対象を表示する表示部を備える
ことを特徴とする具体的対象保証型バーコードシステム。
【請求項６】
具体的対象提供装置と認証装置がネットワークに接続されたシステムによる具体的対象保証型バーコード処理方法であって、
上記認証装置は、入力された直感的対象と具体的対象の組に対し、署名鍵で署名処理をして署名を生成し、
上記直感的対象と上記具体的対象と上記署名と上記認証装置の接続リンク（アドレス）とを二次元バーコードデータとして生成し、
上記二次元バーコードデータを上記具体的対象提供装置へ送信し、
上記署名鍵と対応する公開鍵を含み、上記署名を検証するための検証アプリケーションを生成し、記憶し、
上記二次元バーコードデータより得た上記接続リンクに基づき、上記認証装置に、検証アプリケーションを要求し、
上記認証装置は上記検証アプリケーション要求を受信すると、上記検証アプリケーションを上記具体的対象提供装置へ送信し、
上記具体的対象提供装置は受信した上記検証アプリケーションを用いて、上記二次元バーコードデータに対し、署名検証処理を行い、
上記検証処理が成功すれば、上記二次元バーコードを媒体に付加する
ことを特徴とする具体的対象保証型バーコード処理方法。
【請求項７】
具体的対象提供装置と認証装置がネットワークに接続されたシステムによる具体的対象保証型バーコード処理方法であって、
上記認証装置は、入力された直感的対象と具体的対象の組に対し、署名検証に成功すると、上記直感的対象が、自動的に復号されるメッセージリカバリー部分を持つ署名方式による署名を生成し、
上記具体的対象と上記署名と上記認証装置の接続リンク（アドレス）とを二次元バーコードデータとして生成し、
上記二次元バーコードデータを上記具体的対象提供装置へ送信し、
上記署名鍵と対応する公開鍵を含み、上記署名を検証するための検証アプリケーションを生成し、記憶し、
上記二次元バーコードデータより得た上記接続リンクに基づき、上記認証装置に、検証アプリケーションを要求し、
上記認証装置は上記検証アプリケーション要求を受信すると、上記検証アプリケーションを上記具体的対象提供装置へ送信し、
上記具体的対象提供装置は受信した上記検証アプリケーションを用いて、上記二次元バーコードデータに対し、署名検証処理を行い、
上記検証処理が成功すれば、上記二次元バーコードを媒体に付加する
ことを特徴とする具体的対象保証型バーコード処理方法。
【請求項８】
請求項６又は７記載の方法において、
上記ネットワークにユーザ端末が接続され、
上記ユーザ端末は、媒体に付加されている二次元バーコードを二次元バーコードデータとして取り込み、
上記取り込んだ二次元バーコードをデータとして記憶し、解析し、
上記解析されたバーコードデータから、上記認証装置に対し、上記検証アプリケーションを要求し、
上記認証装置は上記検証アプリケーション要求を受信すると、上記検証アプリケーションを上記ユーザ端末へ送信し、
上記ユーザ端末は、受信した上記検証アプリケーションを用いて、上記二次元バーコードに対して、署名検証処理を行い、
上記署名検証処理が成功すれば、上記具体的対象を利用し、かつ上記直感的対象と上記具体的対象を表示する
ことを特徴とする具体的対象保証型バーコード処理方法。
【請求項９】
請求項６〜８のいずれかに記載の方法において、
上記二次元バーコードの生成は、上記直感的対象と具体的対象との組ごとのアプリケーション識別子が入力され、上記二次元バーコードデータにアプリケーション識別子を組み込む
ことを特徴とする具体的対象保証型バーコード処理方法。
【請求項１０】
請求項６〜９の何れかに記載の方法において、
上記具体的対象提供装置は、上記署名に成功すれば、上記署名検証からのデータにより、上記直感的対象と上記具体的対象を表示する
ことを特徴とする具体的対象保証型バーコード処理方法。
【請求項１】
具体的対象提供装置と認証装置とがネットワークを通じて接続されるシステムにおいて、
上記認証装置は、署名鍵とこれに対応する公開鍵とを生成する鍵生成部と、
入力された直感的対象及び具体的対象に対する上記署名鍵で署名を生成する署名部と、
上記直感的対象と上記具体的対象と上記署名と上記認証装置の接続リンク（アドレス）を二次元バーコードデータとして生成するバーコード生成部と、
上記公開鍵を含み、上記署名の検証を行う検証アプリケーションを生成する検証アプリケーション生成部と、
上記検証アプリケーションを記憶する検証アプリケーション記憶部と、
上記二次元バーコードデータを上記具体的対象提供装置へ送信し、検証アプリケーション要求を受信し、受信した検証アプリケーションを要求元へ上記検証アプリケーションを送付する通信部を具備し、
上記具体的対象提供装置は、上記認証装置から送られてきた上記二次元バーコードデータを記憶するバーコード記憶部と、
上記二次元バーコードデータからの上記接続リンクに基づき、上記認証装置に、上記検証アプリケーション要求信号を生成する検証アプリケーション要求信号生成部と、
上記通信部により受信した検証アプリケーションを記憶する検証アプリケーション記憶部と、
上記検証アプリケーションを使用して、上記二次元バーコードデータに含まれる上記署名を検証する署名検証部と、
上記署名検証が成功すれば、上記二次元バーコードを媒体に付加する媒体付加部と、
上記二次元バーコードデータを受信し、上記検証アプリケーション要求信号を上記認証装置へ送信し、上記認証装置からの検証アプリケーションを受信する通信部と
を具備することを特徴とする具体的対象保証型バーコードシステム。
【請求項２】
具体的対象提供装置と認証装置とがネットワークを通じて接続されるシステムにおいて、
上記認証装置は、署名鍵とこれに対応する公開鍵とを生成する鍵生成部と、
入力された直感的対象と具体的対象に対し、署名検証に成功すると、上記直感的対象が、自動的に復号されるメッセージリカバリー部分を持つ署名方式による署名を生成する署名部と、
上記具体的対象と上記署名と上記認証装置の接続リンク（アドレス）を二次元バーコードデータとして生成するバーコード生成部と、
上記公開鍵を含み、上記署名の検証を行う検証アプリケーションを生成する検証アプリケーション生成部と、
上記検証アプリケーションを記憶する検証アプリケーション記憶部と、
上記二次元バーコードデータを上記具体的対象提供装置へ送信し、検証アプリケーション要求を受信し、受信した検証アプリケーションを要求元へ上記検証アプリケーションを送付する通信部を具備し、
上記具体的対象提供装置は、上記認証装置から送られてきた上記二次元バーコードデータを記憶するバーコード記憶部と、
上記二次元バーコードデータからの上記接続リンクに基づき、上記認証装置に、上記検証アプリケーション要求信号を生成する検証アプリケーション要求信号生成部と、
上記通信部により受信した検証アプリケーションを記憶する検証アプリケーション記憶部と、
上記検証アプリケーションを使用して、上記二次元バーコードデータに含まれる上記署名を検証する署名検証部と、
上記署名検証が成功すれば、上記二次元バーコードを媒体に付加する媒体付加部と、
上記二次元バーコードデータを受信し、上記検証アプリケーション要求信号を上記認証装置へ送信し、上記認証装置からの検証アプリケーションを受信する通信部と
を具備することを特徴とする具体的対象保証型バーコードシステム。
【請求項３】
請求項１又は２に記載のシステムにおいて、
上記ネットワークにユーザ端末が接続され、
上記ユーザ端末は、媒体に付加されている二次元バーコードを二次元バーコードデータとして取り込むバーコード取り込み部と、
上記取り込んだ二次元バーコードをデータとして記憶するバーコード記憶部と、
上記二次元バーコードデータを解析するバーコード解析部と、
上記解析されたバーコードデータから、上記認証装置に対し、上記検証アプリケーションを要求する検証アプリケーション要求信号生成部と、
受信した上記検証アプリケーションを記憶する検証アプリケーション記憶部と、
上記検証アプリケーションを使用して、上記二次元バーコードデータに含まれる上記署名を検証する署名検証部と、
上記署名検証が成功であれば、上記バーコードシステム解析部からの具体的対象を利用する利用部と、
上記バーコード解析部又は、上記署名検証部から得られる上記直感的対象と上記具体的対象を表示する表示部と、
上記検証アプリケーション生成信号を上記認証装置へ送信し、上記認証装置からの検証アプリケーションを受信する通信部と、
を具備することを特徴とする具体的対象保証型バーコードシステム。
【請求項４】
請求項１〜３のいずれかに記載のシステムにおいて、
上記バーコード生成部は、上記直感的対象と具体的対象との組ごとのアプリケーション識別子が入力され、上記二次元バーコードデータにアプリケーション識別子を組み込むものである
ことを特徴とする具体的対象保証型バーコードシステム。
【請求項５】
請求項１〜４の何れかに記載のシステムにおいて、
上記具体的対象提供装置は、上記署名に成功すれば、上記バーコード解析部又はこれに加え、上記署名検証部からのデータにより、上記直感的対象と上記具体的対象を表示する表示部を備える
ことを特徴とする具体的対象保証型バーコードシステム。
【請求項６】
具体的対象提供装置と認証装置がネットワークに接続されたシステムによる具体的対象保証型バーコード処理方法であって、
上記認証装置は、入力された直感的対象と具体的対象の組に対し、署名鍵で署名処理をして署名を生成し、
上記直感的対象と上記具体的対象と上記署名と上記認証装置の接続リンク（アドレス）とを二次元バーコードデータとして生成し、
上記二次元バーコードデータを上記具体的対象提供装置へ送信し、
上記署名鍵と対応する公開鍵を含み、上記署名を検証するための検証アプリケーションを生成し、記憶し、
上記二次元バーコードデータより得た上記接続リンクに基づき、上記認証装置に、検証アプリケーションを要求し、
上記認証装置は上記検証アプリケーション要求を受信すると、上記検証アプリケーションを上記具体的対象提供装置へ送信し、
上記具体的対象提供装置は受信した上記検証アプリケーションを用いて、上記二次元バーコードデータに対し、署名検証処理を行い、
上記検証処理が成功すれば、上記二次元バーコードを媒体に付加する
ことを特徴とする具体的対象保証型バーコード処理方法。
【請求項７】
具体的対象提供装置と認証装置がネットワークに接続されたシステムによる具体的対象保証型バーコード処理方法であって、
上記認証装置は、入力された直感的対象と具体的対象の組に対し、署名検証に成功すると、上記直感的対象が、自動的に復号されるメッセージリカバリー部分を持つ署名方式による署名を生成し、
上記具体的対象と上記署名と上記認証装置の接続リンク（アドレス）とを二次元バーコードデータとして生成し、
上記二次元バーコードデータを上記具体的対象提供装置へ送信し、
上記署名鍵と対応する公開鍵を含み、上記署名を検証するための検証アプリケーションを生成し、記憶し、
上記二次元バーコードデータより得た上記接続リンクに基づき、上記認証装置に、検証アプリケーションを要求し、
上記認証装置は上記検証アプリケーション要求を受信すると、上記検証アプリケーションを上記具体的対象提供装置へ送信し、
上記具体的対象提供装置は受信した上記検証アプリケーションを用いて、上記二次元バーコードデータに対し、署名検証処理を行い、
上記検証処理が成功すれば、上記二次元バーコードを媒体に付加する
ことを特徴とする具体的対象保証型バーコード処理方法。
【請求項８】
請求項６又は７記載の方法において、
上記ネットワークにユーザ端末が接続され、
上記ユーザ端末は、媒体に付加されている二次元バーコードを二次元バーコードデータとして取り込み、
上記取り込んだ二次元バーコードをデータとして記憶し、解析し、
上記解析されたバーコードデータから、上記認証装置に対し、上記検証アプリケーションを要求し、
上記認証装置は上記検証アプリケーション要求を受信すると、上記検証アプリケーションを上記ユーザ端末へ送信し、
上記ユーザ端末は、受信した上記検証アプリケーションを用いて、上記二次元バーコードに対して、署名検証処理を行い、
上記署名検証処理が成功すれば、上記具体的対象を利用し、かつ上記直感的対象と上記具体的対象を表示する
ことを特徴とする具体的対象保証型バーコード処理方法。
【請求項９】
請求項６〜８のいずれかに記載の方法において、
上記二次元バーコードの生成は、上記直感的対象と具体的対象との組ごとのアプリケーション識別子が入力され、上記二次元バーコードデータにアプリケーション識別子を組み込む
ことを特徴とする具体的対象保証型バーコード処理方法。
【請求項１０】
請求項６〜９の何れかに記載の方法において、
上記具体的対象提供装置は、上記署名に成功すれば、上記署名検証からのデータにより、上記直感的対象と上記具体的対象を表示する
ことを特徴とする具体的対象保証型バーコード処理方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【公開番号】特開２００７−１８８４３０（Ｐ２００７−１８８４３０Ａ）
【公開日】平成１９年７月２６日（２００７．７．２６）
【国際特許分類】
【出願番号】特願２００６−７７２５（Ｐ２００６−７７２５）
【出願日】平成１８年１月１６日（２００６．１．１６）
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】
【公開日】平成１９年７月２６日（２００７．７．２６）
【国際特許分類】
【出願日】平成１８年１月１６日（２００６．１．１６）
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】
[ Back to top ]