以下、本発明の実施の形態に係る認証装置、認証システム、認証方法及びプログラムについて、図面を参照しながら詳細に説明する。その際、図中同一又は相当部分には同一符号を付す。
(実施の形態1)
理解を容易にするため、以下、実施の形態1に係る認証装置100を図1に示す認証システム1に適用した場合を例にして説明する。認証システム1は、図1に示すように、認証装置100と、携帯端末200と、決済端末300と、を備える。また、認証装置100は、認証システム1の外部に存在するカード発行サーバ400とネットワークを介して相互に通信可能になっている。認証装置100は、携帯端末200と決済端末300との間の決済処理の正当性を認証する装置である。携帯端末200は、ユーザが携帯する携帯電話、スマートフォン、タブレット等である。決済端末300は、店頭に設置され、商品等の販売時に店員が操作するレジスタ等であり、NFC(Near Field Communication:近距離無線通信)リーダライタを備える。カード発行サーバ400は、ユーザが決済の際に用いるクレジットカード等のカード番号を発行し、このカード番号を用いた決済処理を行う。
決済端末300は、店頭に複数設置されている場合もある。その場合、それぞれの決済端末300が、NFCリーダライタを備える。商品等を購入するユーザは、その取引(商品等の購入)の際に、決済端末300の備えるNFCリーダライタに携帯端末200をかざして決済処理を行う。ここで、決済処理とは、売買取引の代金を支払う処理のことを言い、後述する携帯端末決済処理及び決済端末決済処理によって実施される。なお、決済端末300は、少なくとも店頭に1台以上設置されていればよい。通常は、店頭に設置されている各レジスタ自体がそれぞれ決済端末300であるが、決済端末300は、レジスタとは別に設置されていてもよく、例えば複数のレジスタが設置されている店頭に決済端末300が1台のみ設置されている形態も考えられる。この場合には、NFCリーダライタを備える複数のレジスタと該1台の決済端末300とが通信可能に接続され、各レジスタからの情報を該1台の決済端末300が集中管理すればよい。
認証装置100と携帯端末200とは、携帯電話網又は無線LAN(Local Area Network)等による無線通信を介して、通信可能である。認証装置100と決済端末300とは、専用線等によって通信可能である。携帯端末200と決済端末300とは、NFCによって通信可能である。また、認証装置100とカード発行サーバ400とは専用線等によって通信可能である。これらの通信に用いる通信路はすべて暗号化されており、盗聴等により情報が盗まれることがないようになっている。なお、カード発行サーバ400の提供する機能(詳しくは後述する)を認証装置100が備えていても良く、この場合は、認証装置100とカード発行サーバ400との間の通信は不要である。
認証装置100は、当該認証装置100が生成するトークンを用いて、携帯端末200と決済端末300との間の決済処理の正当性を認証する。具体的には、決済処理に先立って、携帯端末200は携帯端末用のトークン(携帯トークン)を、決済端末300は決済端末用のトークン(決済トークン)を、それぞれ認証装置100から取得しておく。そして、決済処理の際には、携帯端末200は、認証装置100から取得した携帯トークンを決済端末300に送信し、決済端末300は受信した携帯トークンを認証装置100に送信する。また、決済端末300は、認証装置100から取得した決済トークンを携帯端末200に送信し、携帯端末200は受信した決済トークンを認証装置100に送信する。これにより、認証装置100は、決済端末300から受信した携帯トークン及び携帯端末200から受信した決済トークンが、事前に配付したトークンと同じものであることを確認することによって、決済処理の正当性を認証し、正当な決済処理である場合に当該決済処理を進行させる。ここで、トークンとは、例えば8桁や10桁など(桁数は任意であってよい)の数値または文字列であり、一種のパスワードのようなものである。なお、トークンには使用期限(1ヶ月間、3日間等)及び使用上限回数(3回、1回等)が設定されている。
このような認証により決済処理を行うため、携帯トークンを決済処理に先立って取得していない携帯端末200や決済トークンを決済処理に先立って取得していない決済端末300では、決済処理をすることができない。したがって他人になりすまして決済処理が行われることを防止できる。また、決済処理の際に、取引内容に関する取引情報と合わせて携帯トークンを決済端末300が認証装置100に送信する。したがって、携帯トークンが取引内容に関する取引情報と合わせて認証装置100に送信されるため、別途携帯トークンを携帯端末200側で送信する必要がなくなり、処理を効率化することができる。また、決済処理の際に、携帯端末200が決済トークンを認証装置100に送信するため、当該決済端末300との間で決済処理を行った携帯端末200以外は当該決済端末300の決済トークンを取得することができず、セキュリティを強化することができる。
続いて各装置の構成について、まず認証装置100から順に説明する。認証装置100は、図2に示すように、制御部110と、記憶部120と、入出力部130と、を備え、これらが内部バスを介して接続されている。
制御部110は、CPU(Central Processing Unit)、ASIC(Application Specific Integrated Circuit)等を備える。制御部110は、記憶部120に記憶されたプログラムに従って動作する。制御部110は、記憶部120に記憶されたプログラムにより提供される主要な機能部として、携帯トークン生成部111と、決済トークン生成部112と、認証部113と、を備える。
携帯トークン生成部111は、決済処理に先立って事前に携帯端末200に送付する携帯トークンを生成する。決済トークン生成部112は、決済処理に先だって事前に決済端末300に送付する決済トークンを生成する。認証部113は、携帯端末200から受信した決済トークン及び決済端末300から受信した携帯トークンが、それぞれ事前に配付していた決済トークン及び携帯トークンと同じ内容であるか否かを判定することによって、決済処理の正当性を認証し、正当であると認証した場合に当該決済処理を進行させる。なお、正当でない場合には、決済処理が行えない旨の情報を携帯端末200および決済端末300に送信する。これらの処理の詳細については後述する。
記憶部120は、ROM(Read Only Memory)、RAM(Random Access Memory)等を備える。ROMは制御部110のCPUが実行するプログラム及び、プログラムを実行する上で予め必要なデータを記憶する。RAMは、プログラム実行中に作成されたり変更されたりするデータを記憶する。記憶部120は、制御部110が実行するプログラムが用いる主要な情報として、携帯端末情報一覧121、ユーザ情報一覧122、携帯トークン情報一覧123、決済端末情報一覧124、決済識別情報一覧125及び決済トークン情報一覧126を記憶する。
携帯端末情報一覧121は、ユーザが所持する携帯端末200及びそのユーザを識別する情報である。当該携帯端末情報一覧121は、後述するユーザ登録処理により記憶部120に記憶される。携帯端末情報一覧121は、図3に示すように、少なくとも、携帯端末ID、ユーザID、ユーザ暗証番号の各情報を含む。携帯端末IDは、携帯端末200を一意に識別できる個体識別情報である。ユーザIDは、携帯端末IDで示される携帯端末200のユーザを一意に識別できる情報である。ユーザ暗証番号は、携帯端末IDで示される携帯端末200を用いた決済時に、ユーザIDで示されるユーザが入力する暗証番号の情報であり、予めユーザにより設定されている。認証装置100は、この暗証番号により、そのユーザがユーザIDで示される正しいユーザであるか否かを判定する。
ユーザ情報一覧122は、登録された各ユーザのカード情報や個人情報であり、後述するユーザ登録処理により記憶部120に記憶される。ユーザ情報一覧122は、図4に示すように、少なくとも、ユーザID、氏名、住所、カード枚数、カード番号の各情報を含む。ユーザ情報一覧122は、ユーザの個人情報として、氏名、住所の情報を含んでいる。なお、この実施の形態では、以下、個人情報といった場合には氏名、住所の情報をいうものとする。ユーザIDは、上述したように、ユーザを一意に識別できる情報である。カード枚数は、ユーザIDで示されるユーザが決済時に選択可能(使用可能)なクレジットカード、デビットカード等(以下、クレジットカード等)のカードの枚数である。カード番号は、ユーザIDで示されるユーザが選択可能(使用可能)なクレジットカード等のカード番号である。また、図4に示されている氏名及び住所(個人情報)は、ユーザIDで示されるユーザの氏名及び住所の情報である。ユーザ情報一覧122は、図4に示す個人情報の他にも、上記以外の情報(例えば、電話番号、年齢、趣味等)を含んでいても良い。なお、個人情報についてはユーザ情報一覧122に含めず、後述する発行側ユーザ情報421(カード発行サーバ400の記憶部420に記憶される、各ユーザのカード情報や個人情報)にのみ含めるようにしても良い。
携帯トークン情報一覧123は、携帯トークンに関する情報並びに、該携帯トークンに紐付けられた携帯端末ID及びカード番号を示す情報である。当該携帯トークン情報一覧123は、後述する携帯トークン生成処理により記憶部120に記憶される。携帯トークン情報一覧123は、図5に示すように、少なくとも、携帯トークン、携帯端末ID、カード番号、有効期限、有効回数の各情報を含む。携帯トークンは、後述する携帯トークン生成処理によって生成され、携帯端末200の正当性を証明するために用いられる数値または文字列である。この携帯トークンは、例えば、携帯端末ID、ユーザ暗証番号及びトークン生成時の時刻データを入力値として、ハッシュ関数を適用することで生成される。携帯端末ID及びカード番号は、上述した説明の通りである。有効期限は、携帯トークンの有効期限を示す情報である。有効回数は、携帯トークンの有効回数(使用上限回数)を示す情報である。
決済端末情報一覧124は、決済端末300及びその決済端末300を使用する店員を識別するための情報である。当該決済端末情報一覧124は、後述する決済端末登録処理により記憶部120に記憶される。決済端末情報一覧124は、図6に示すように、少なくとも、決済端末ID、店員数、店員ID、店員暗証番号の各情報を含む。決済端末IDは、決済端末300を一意に識別できる情報である。例えば、決済端末IDは、決済端末300のMAC(Media Access Control)アドレスである。店員数は、決済端末IDで示される決済端末300を使用することのできる店員の人数を示す情報である。店員IDは、決済端末IDで示される決済端末300を使用することのできる各店員をそれぞれ一意に識別できる情報である。店員暗証番号は、決済端末IDで示される決済端末300を用いた決済時に、店員IDで示される店員が入力する暗証番号の情報であり、店舗の責任者などにより予め設定されている。
決済識別情報一覧125は、決済端末300を使用する各店員に付与される決済先識別番号などの情報である。当該決済識別情報一覧125は、後述する決済端末登録処理により記憶部120に記憶される。決済識別情報一覧125は、図7に示すように、少なくとも、決済端末ID、店員数、店員ID、使用可能決済先識別番号数、決済先識別番号の各情報を含む。決済端末IDは、上述したように、決済端末300を一意に識別できる情報である。店員数は、上述したように、決済端末IDで示される決済端末300を使用することのできる店員の人数を示す情報である。店員IDは、上述したように、決済端末IDで示される決済端末300を使用することのできる各店員をそれぞれ一意に識別できる情報である。使用可能決済先識別番号数は、決済端末IDで示される決済端末300を用いた決済時に、店員IDで示される店員が選択可能な決済先識別番号の個数を示す情報である。換言すると、使用可能決済先識別番号数は、決済端末300を用いた決済時に店員が選択可能なカード会社の数を示す情報である。決済先識別番号は、決済端末IDで示される決済端末300を用いた決済時に、店員IDで示される店員が選択可能な決済先識別番号の情報である。換言すると、決済先識別番号は、クレジットカード等のカードを発行する会社(カード会社)を識別するための番号である。決済先識別番号は、店員が商品を販売する際の決済時に選択される。これによりユーザの使用するカードの発行会社に合わせて決済を行うことが可能となる。
決済トークン情報一覧126は、決済トークンに関する情報並びに、該決済トークンに紐付けられた決済端末ID、店員ID及び決済先識別番号を示す情報である。当該決済トークン情報一覧126は、後述する決済トークン生成処理により記憶部120に記憶される。決済トークン情報一覧126は、図8に示すように、少なくとも、決済トークン、決済端末ID、店員ID、決済先識別番号、有効期限、有効回数の各情報を含む。決済トークンは、後述する決済トークン生成処理によって生成され、決済端末300の正当性を証明するために用いられる数値または文字列である。この決済トークンは、例えば、決済端末ID、店員ID、店員暗証番号及びトークン生成時の時刻データを入力値として、ハッシュ関数を適用することで生成される。決済端末ID、店員ID及び決済先識別番号は、上述した説明の通りである。有効期限は、決済トークンの有効期限を示す情報である。有効回数は、決済トークンの使用上限回数を示す情報である。
図2に戻り、入出力部130は、認証装置100が情報を入出力するためのデバイスである。入出力部130は、本実施の形態における主要なデバイスとして、携帯通信部131と、決済通信部132と、通信部133と、を備える。
携帯通信部131は、携帯端末200と通信するためのデバイスである。携帯通信部131は、例えば、インターネットなどのネットワークを介して、携帯端末200と情報の送受信を行う。
決済通信部132は、決済端末300と通信するためのデバイスである。決済通信部132は、例えば、専用線を介して決済端末300と情報の送受信を行う。
通信部133は、カード発行サーバ400と通信するためのデバイスである。通信部133は、例えば、専用線を介してカード発行サーバ400と情報の送受信を行う。
以上が、認証装置100の構成である。続いて、携帯端末200の構成について説明する。
携帯端末200は、図9に示すように、制御部210と、記憶部220と、入出力部230と、を備え、これらが内部バスを介して接続されている。
制御部210は、CPU、ASIC等を備える。制御部210は、記憶部220に記憶されたプログラムに従って動作するが、本実施の形態における主要な機能は、決済用携帯アプリ221によって提供される。決済用携帯アプリ221は、カード発行サーバ400が提供する携帯端末200用のアプリケーションプログラムであり、インターネットなどのネットワークを介して記憶部220にダウンロードすることができる。制御部210は、決済用携帯アプリ221により提供される主要な機能部として、携帯トークン依頼部211と、携帯側決済処理部212と、を備える。
携帯トークン依頼部211は、携帯端末200を使用するユーザの情報、ユーザ暗証番号等を認証装置100に送信して、認証装置100に携帯トークンの生成を依頼する。携帯側決済処理部212は、決済端末300と協働して、携帯端末決済処理を行う。なお、決済処理は、上述したように売買取引の代金を支払う処理であり、携帯端末決済処理及び決済端末決済処理によって実施される。携帯側決済処理部212では、携帯端末200による決済処理である携帯端末決済処理を行う。
記憶部220は、ROM、RAM等を備える。ROMは制御部210のCPUが実行するプログラム及び、プログラムを実行する上で予め必要なデータを記憶する。RAMは、インターネット等からダウンロードするプログラム及び、プログラム実行中に作成されたり変更されたりするデータを記憶する。上述したように、記憶部220は、制御部210が実行する決済用携帯アプリ221を記憶する。また、記憶部220は、制御部210が実行する決済用携帯アプリ221が用いる主要な情報として、携帯端末情報222、携帯トークン情報223及び携帯側決済情報224を記憶する。
携帯端末情報222は、携帯端末200及び携帯端末200を使用するユーザを識別するための情報である。当該携帯端末情報222は、後述するユーザ登録処理により記憶部220に記憶される。携帯端末情報222は、図10に示すように、携帯端末ID、ユーザID、ユーザ暗証番号の各情報を含む。携帯端末IDは、携帯端末200を一意に識別できる個体識別情報であり、携帯端末200の製造時に記憶される。ユーザIDは、携帯端末200のユーザを一意に識別できる情報であり、後述するユーザ登録処理において認証装置100により発行された値が記憶される。ユーザ暗証番号は、携帯端末200を用いた決済時に、ユーザが入力する暗証番号の情報であり、後述するユーザ登録処理時においてユーザにより入力された情報が記憶される。
携帯トークン情報223は、後述する携帯トークン生成処理によって認証装置100から送信された携帯トークンに関する情報である。携帯トークン情報223は、図11に示すように、携帯トークン並びに、その有効期限及び有効回数の情報であり、各情報については上述したとおりである。有効回数は、携帯端末決済処理が行われるたびに1ずつ減算される。携帯トークンの有効回数が0になると、その携帯トークンは無効となり、決済処理に用いることができなくなる。すなわち、携帯トークンが無効になると、決済処理を行うことができなくなる。
携帯側決済情報224は、後述する携帯端末決済処理時に決済端末300から携帯側近距離通信部231を介して受信する取引内容通知パケットの情報である。携帯側決済情報224は、図12に示すように、決済トークン、決済端末ID、店員ID、店員暗証番号、取引内容、の各情報を含む。決済トークン、決済端末ID、店員ID、店員暗証番号については上述したとおりである。取引内容は、決済処理の際にNFCによって決済端末300から取得する、その決済処理の内容を示す情報であり、具体的には購入商品、購入金額等の情報である。なお、決済端末300が携帯端末200のユーザの過去の商品購入履歴等を取得可能な場合は、その情報を取引内容に含めても良い。取引内容を示す情報を取引情報とも言う。
図9に戻り、入出力部230は、携帯端末200が情報を入出力するためのデバイスである。入出力部230は、本実施の形態における主要なデバイスとして、携帯側近距離通信部231と、携帯側通信部232と、携帯側入力部233と、携帯側表示部234と、を備える。
携帯側近距離通信部231は、NFC(近距離通信)によって決済端末300と通信するためのデバイスである。具体的には、携帯側近距離通信部231は、決済端末300が備えるNFCリーダライタによって決済端末300と通信可能な、非接触型ICカードを備える。
携帯側通信部232は、認証装置100と通信するためのデバイスである。携帯側通信部232は、例えば、インターネット等のネットワークを介して、認証装置100と情報の送受信を行う。
携帯側入力部233は、タッチパネル、ボタン等を備え、ユーザによる入力操作を受け付ける。
携帯側表示部234は、液晶ディスプレイ、有機EL(Electoro−Luminescence)ディスプレイ等を備え、携帯電話の機能を提供する操作画面、決済用携帯アプリが生成する操作画面等を表示する。
以上が、携帯端末200の構成である。続いて、決済端末300の構成について説明する。
決済端末300は、図13に示すように、制御部310と、記憶部320と、入出力部330と、を備え、これらが内部バスを介して接続されている。
制御部310は、CPU、ASIC等を備える。制御部310は、記憶部320に記憶されたプログラムに従って動作する。制御部310は、記憶部320に記憶されたプログラムにより提供される主要な機能部として、決済トークン依頼部311と、決済側決済処理部312と、を備える。
決済トークン依頼部311は、決済端末300の情報、決済端末300を使用する店員の情報、店員暗証番号等を認証装置100に送信して、認証装置100に決済トークンの生成を依頼する。決済側決済処理部312は、携帯端末200と協働して、決済端末決済処理を行う。なお、決済処理は、上述したように売買取引の代金を支払う処理であり、携帯端末決済処理及び決済端末決済処理によって実施される。決済側決済処理部312では、決済端末300による決済処理である決済端末決済処理を行う。
記憶部320は、ROM、RAM等を備える。ROMは制御部310のCPUが実行するプログラム及び、プログラムを実行する上で予め必要なデータを記憶する。RAMは、プログラム実行中に作成されたり変更されたりするデータを記憶する。記憶部320は、制御部310が実行するプログラムが用いる主要な情報として、決済端末情報321、決済トークン情報322及び決済側決済情報323を記憶する。
決済端末情報321は、決済端末300及び決済端末300を使用する店員を識別するための情報である。当該決済端末情報321は、後述する決済端末登録処理により記憶部320に記憶される。決済端末情報321は、図14に示すように、決済端末ID、店員数、店員ID、店員暗証番号の各情報を含む。決済端末IDは、決済端末300を一意に識別できる情報であり、上述したように、例えば、MACアドレスである。決済端末IDは、決済端末300の製造時に記憶される。店員数は、決済端末300を使用する店員の人数を示す情報であり、後述する決済端末登録時に店員が入力した値が記憶される。店員IDは、決済端末300を使用する各店員をそれぞれ一意に識別できる情報であり、後述する決済端末登録時に店員が入力した値が記憶される。店員暗証番号は、決済端末300を用いた決済時に、店員IDで示される店員が入力する暗証番号の情報であり、後述する決済端末登録時に店員が入力した値が記憶される。
決済トークン情報322は、後述する決済トークン生成処理によって認証装置100から送信された決済トークンの情報である。決済トークン情報322は、図15に示すように、店員ID、決済トークン並びに、その有効期限及び有効回数の情報であり、各情報については上述したとおりである。有効回数は、決済端末決済処理が行われるたびに1ずつ減算される。決済トークンの有効回数が0になると、その決済トークンは無効となり、決済処理に用いることができなくなる。すなわち、決済トークンが無効になると、決済処理を行うことができなくなる。
決済側決済情報323は、後述する決済端末決済処理時に携帯端末200から決済側近距離通信部332を介して受信する情報である。決済側決済情報323は、図16に示すように、携帯トークン、携帯端末ID、ユーザ暗証番号、の各情報を含む。これら各情報の説明は上述した通りである。
図13に戻り、入出力部330は、決済端末300が情報を入出力するためのデバイスである。入出力部330は、本実施の形態における主要なデバイスとして、決済側通信部331と、決済側近距離通信部332と、決済側入力部333と、決済側表示部334と、を備える。
決済側通信部331は、認証装置100と通信するためのデバイスである。決済側通信部331は、例えば、専用線によって、認証装置100と情報の送受信を行う。
決済側近距離通信部332は、NFC(近距離通信)によって携帯端末200と通信するためのデバイスである。具体的には、決済側近距離通信部332は、NFCリーダライタである。決済端末300は、決済側近距離通信部332(NFCリーダライタ)によって、携帯端末200とNFCによる情報の送受信を行うことができる。
決済側入力部333は、タッチパネル、ボタン等を備え、店員による入力操作を受け付ける。
決済側表示部334は、液晶ディスプレイ、有機ELディスプレイ等を備え、UI(User Interface)画面、取引結果を通知する画面等を表示する。
以上が、決済端末300の構成である。続いて、この実施の形態に係る認証装置100とネットワークを介して相互に通信可能に接続されたカード発行サーバ400の構成について説明する。カード発行サーバ400は、上述した認証システム1における決済処理を実現するために必要な情報を事前に各種装置に設定する機能(事前設定機能)と、認証システム1で認証された決済処理に基づいて実際に金銭の支払いを行う機能(支払い処理機能)を有する。具体的に、カード発行サーバ400は、事前設定機能として、後述するように、携帯端末200を所持するユーザにカード番号を発行する機能、決済端末300を使用する店員に決済先識別番号を発行する機能を有する。また、カード発行サーバ400は、支払い処理機能として、認証システム1で認証された決済処理で使用されたカード番号のユーザの口座から決済先識別番号で示されるカード会社へ金銭を支払う処理(支払い処理)を行う機能を有する。
カード発行サーバ400は、図17に示すように、制御部410と、記憶部420と、入出力部430と、を備え、これらが内部バスを介して接続されている。
制御部410は、CPU、ASIC等を備える。制御部410は、記憶部420に記憶されたプログラムに従って動作する。制御部410は、記憶部420に記憶されたプログラムにより提供される主要な機能部として、カード番号発行部411と、決済先識別番号発行部412と、支払い処理部413と、を備える。
カード番号発行部411は、決済処理に先立って事前に携帯端末200に送付しておくクレジットカード等のカード番号を発行する。決済先識別番号発行部412は、決済処理に先立って事前に決済端末300に送付しておく決済先識別番号を発行する。支払い処理部413は、認証装置100から送信された取引内容、カード番号及び決済先識別番号の各情報に基づいて、該取引内容の代金を、該カード番号で支払う手続を実施する処理(上述した支払い処理)を行う。
記憶部420は、ROM、RAM等を備える。ROMは制御部410のCPUが実行するプログラム及び、プログラムを実行する上で予め必要なデータを記憶する。RAMは、プログラム実行中に作成されたり変更されたりするデータを記憶する。記憶部420は、制御部410が実行するプログラムが用いる主要な情報として、発行側ユーザ情報421及び発行側決済識別情報422を記憶する。
発行側ユーザ情報421は、後述するユーザ登録処理で登録されるユーザの個人情報であり、認証装置100が記憶するユーザ情報一覧122と同様の情報である。発行側ユーザ情報421は、図4に示すように、少なくとも、ユーザID、カード枚数、カード番号の各情報を含む。
ユーザIDは、後述するユーザ登録処理の際にカード番号発行部411により、ユーザを一意に識別できる値として発行される。カード枚数は、ユーザIDで示されるユーザが決済時に選択可能なカードの枚数を示す情報であり、カード番号発行部411が発行したカード番号の個数である。カード番号は、ユーザIDで示されるユーザが選択可能なカード、つまり、カード番号発行部411が発行したカード番号の情報である。図4に示されている氏名及び住所は、ユーザIDで示されるユーザの氏名及び住所の情報である。発行側ユーザ情報421は、ユーザの個人情報として、これら以外の情報(例えば、電話番号、年齢、趣味等)を含んでいても良い。後述するユーザ登録処理時に、携帯端末200のユーザの個人情報を、カード発行サーバ400が認証装置100から受け取ることにより、カード番号発行部411によりカード番号及びユーザIDが発行される。そして、これらカード番号及びユーザIDが個人情報と対応付けられて、発行側ユーザ情報421として記憶部420に記憶される。
発行側決済識別情報422は、後述する決済端末登録処理で登録される決済端末300を、使用する各店員に付与される決済先識別番号の情報であり、認証装置100が記憶する決済識別情報一覧125と同様の情報である。発行側決済識別情報422は、図7に示すように、少なくとも、決済端末ID、店員数、店員ID、使用可能決済先識別番号数、決済先識別番号の各情報を含む。
決済端末IDは、後述する決済端末登録処理の際に決済端末300から認証装置100を介して受け取る、決済端末300を一意に識別できる情報である。店員数は、決済端末IDで示される決済端末300を使用する店員の人数を示す情報であり、後述する決済端末登録処理の際に店員が決済端末300に入力した値を認証装置100を介して受け取った値である。店員IDは、決済端末IDで示される決済端末300を使用する各店員をそれぞれ一意に識別できる情報であり、後述する決済端末登録処理の際に店員が決済端末300に入力した値を認証装置100を介して受け取った値である。使用可能決済先識別番号数は、決済端末IDで示される決済端末300を用いた決済時に、店員IDで示される店員が選択可能な決済先識別番号の個数を示す情報であり、決済先識別番号発行部412が発行した決済先識別番号の種類の合計の値である。決済先識別番号は、決済端末IDで示される決済端末300を用いた決済時に、店員IDで示される店員が選択可能な決済先識別番号の情報、つまり、決済先識別番号発行部412が発行した決済先識別番号の情報である。後述する決済端末登録処理時に、決済端末300の決済端末ID及び決済端末300を使用する店員の情報を、カード発行サーバ400が認証装置100から受け取ることにより、決済先識別番号発行部412により決済先識別番号が発行される。そして、該決済先識別番号が、決済端末ID及び店員IDと対応付けられて、発行側決済識別情報422として記憶部420に記憶される。
図17に戻り、入出力部430は、カード発行サーバ400が情報を入出力するためのデバイスである。入出力部430は、本実施の形態における主要なデバイスとして、発行側通信部431を備える。
発行側通信部431は、認証装置100と通信するためのデバイスである。発行側通信部431は、例えば、専用線を介して認証装置100と情報の送受信を行う。
以上が、カード発行サーバ400の構成である。なお、カード発行サーバ400が複数存在する場合も考えられる。この場合は、認証装置100は、各カード発行サーバ400と通信するために、各カード発行サーバのアドレス情報を記憶する必要がある。認証装置100は、このアドレス情報を予め記憶部120に記憶しておくようにしても良いし、アクセスする必要があるカード発行サーバ400のアドレス情報を個別に後から設定可能にしても良い。そして、認証装置100は、カード番号及び決済先識別番号を、それらの番号がどのカード発行サーバ400で発行されたのかを示す情報(例えば、カード発行サーバのアドレス、カード発行サーバのID等)と紐付けて記憶するようにする。このようにすることにより、認証装置100は、後述する認証処理の際に、通信すべきカード発行サーバ400に対してアクセスすることができるようになる(すなわち、後述する図24のステップS508の処理を行うことが可能となる)。
続いて、認証装置100が、携帯端末200のユーザを登録してカード番号を取得するユーザ登録処理について、図18を参照して説明する。この処理は、携帯端末200及び決済端末300による決済処理に先立ち、携帯端末200から認証装置100に、ユーザ登録依頼パケットが送信されると実行される。なお、図示は省略するが、理解を容易にするため、ユーザ登録処理の説明の前に、携帯端末200が認証装置100にユーザ登録依頼パケットを送信するまでの認証システム1全体の動作について説明する。まず、携帯端末200のユーザが決済用携帯アプリ221を起動すると、決済用携帯アプリ221は、記憶部220に携帯端末情報222が記憶されている(認証装置100へのユーザ登録済み)か否かを確認し、携帯端末情報222がまだ記憶されていないなら、携帯端末200のユーザに、個人情報及びユーザ暗証番号の入力を促す。そして、携帯端末200は、ユーザによる個人情報及びユーザ暗証番号の入力が完了すると、認証装置100にユーザ登録依頼パケットを送信する。ユーザ登録依頼パケットとは、携帯端末200のユーザの個人情報、ユーザ暗証番号及び携帯端末IDの各情報を含み、送信先である認証装置100にユーザ登録を依頼するパケットである。認証装置100は、このユーザ登録依頼パケットを受信すると、以下で説明するユーザ登録処理を開始する。
なお、携帯端末情報222が既に記憶されている場合でも、ユーザが決済用形態アプリ221にユーザ登録の開始を指示することによって、ユーザ登録依頼パケットを送信させることが可能である。例えば、携帯端末200のユーザが、既に取得済みのカード番号とは別のカード番号を決済に使用したい場合がある。この場合、ユーザはユーザ登録の際の、個人情報及びユーザ暗証番号入力時に、別のカード番号を使用したい旨の情報も入力し、携帯端末200は、それらをユーザ登録依頼パケットの中に含めて認証装置100に送信する。そして、認証装置100は、ユーザ登録依頼パケットの中に、別のカード番号を使用したい旨の情報が含まれていた場合は、ユーザの信用情報に問題がなければ別のカード番号を追加で発行してユーザ登録を行う。このようにすることによって、ユーザは使用可能なカード番号を増やすことができる。では、ユーザ登録処理について、図18を参照して説明する。
まず、制御部110は、携帯通信部131を介して受信したユーザ登録依頼パケットに含まれる、携帯端末200のユーザの個人情報及びユーザ暗証番号並びに携帯端末200の携帯端末IDを取得し、記憶部120に記憶する(ステップS101)。
次に、制御部110は、通信部133を介してカード発行サーバ400に接続し、個人情報及び携帯端末IDに基づく信用情報を取得する(ステップS102)。信用情報とは、その人の過去の代金の支払い状況等を示す情報であり、いわゆるブラックリストの情報である。過去に代金の支払いを怠る等の事故を起こした人はブラックリストに登録され、信用情報に問題がある人であると判断される。そして、制御部110は、信用情報に問題があるか否かを判定する(ステップS103)。具体的に、ステップS103では、ステップS101にて取得したユーザの個人情報などの少なくとも一部が、ステップS102で取得した信用情報(ブラックリスト)に含まれているか否かを判定し、含まれている場合には問題があるとする。信用情報に問題がある場合(ステップS103;No)、制御部110は携帯通信部131を介して、ユーザ登録できない旨を携帯端末200に送信し(ステップS104)、処理を終了する。この場合、携帯端末200の携帯側表示部234に、ユーザ登録できない旨が表示される。
信用情報に問題がない場合(ステップS103;Yes)、制御部110は、通信部133を介してカード発行サーバ400に、カード番号発行依頼パケットを送信する(ステップS105)。カード番号発行依頼パケットとは、上述したユーザ登録依頼パケットに含まれる各情報(携帯端末200のユーザの個人情報及びユーザ暗証番号並びに携帯端末ID)を含み、カード発行サーバ400にクレジットカード等のカードのカード番号の発行を依頼するパケットである。該カード番号発行依頼パケットを受信したカード発行サーバ400は、カード番号及びユーザIDを発行し、携帯端末ID及びユーザ暗証番号とともに認証装置100に返信する。
なお、信用情報の取得及び信用情報に問題があるか否かの判定を、認証装置100ではなくカード発行サーバ400が行ってもよい。この場合、認証装置100の処理としては、ステップS101の次にステップS105に進む。そして、カード発行サーバ400は、カード番号発行の際に、まず信用情報の判定を行い、信用情報に問題がない場合にカード番号を発行する。信用情報に問題がある場合にはカード番号を発行せず、ユーザ登録できない旨を認証装置100に通知する。この通知を受けた認証装置はステップS104の処理に進むことになる。なお、ユーザ情報一覧122に個人情報を含めない場合、認証装置100ではユーザの信用情報に問題があるか否かの判定ができない。この場合、認証装置100は、カード発行サーバ400にユーザの信用情報に問題があるか否かを問い合わせるか、又は、上述したように、ステップS101の次にステップS105に進み、カード発行サーバ400が発行側ユーザ情報421に含まれる個人情報を用いて、ユーザの信用情報に問題があるか否かの判定を行う。
また、カード番号発行依頼パケットにクレジットカードの発行枚数又はクレジットカードの発行会社の種類の情報を含ませることにより、カード発行サーバ400がクレジットカード番号を複数発行することも可能である。例えば、図4は、ユーザID=50001001のユーザに、クレジットカード番号を2つ発行している例を示している。
また、ユーザ登録依頼パケットの中に、別のカード番号を使用したい旨の情報が含まれていた場合には、認証装置100は、この別のカード番号を使用したい旨の情報をカード番号依頼パケットに含めてカード発行サーバ400に送信する。カード発行サーバ400は、受信したカード番号依頼パケットに別のカード番号を使用したい旨の情報が含まれていた場合には、過去に発行したカード番号とは別のカード番号を発行して認証装置100に返信する。このようにすることによって、携帯端末200のユーザは、既に取得済みのカード番号とは異なるカード番号のカードを決済に使用することが可能になる。
図18に戻り、次に、制御部110は、通信部133を介して、カード発行サーバ400からクレジットカード番号、ユーザID、ユーザ暗証番号及び携帯端末IDを受信する(ステップS106)。そして、個人情報にユーザID及びクレジットカード番号を紐付けてユーザ情報一覧122(図4)として、記憶部120に記憶する(ステップS107)。また、携帯端末IDにユーザID及びユーザ暗証番号を紐付けて携帯端末情報一覧121(図3)として、記憶部120に記憶する(ステップS108)。
次に、制御部110は、携帯通信部131を介して、ユーザ登録完了パケットを携帯端末200に送信し(ステップS109)、処理を終了する。ユーザ登録完了パケットとは、携帯端末情報一覧121として記憶部120に記憶されている携帯端末ID、ユーザID及びユーザ暗証番号の各情報を含み、携帯端末200に、ユーザ登録が完了したことを通知するパケットである。携帯端末200の制御部210は、携帯側通信部232を介してユーザ登録完了パケットを受信すると、ユーザ登録完了パケットに含まれる携帯端末ID、ユーザID及びユーザ暗証番号を携帯端末情報222(図10)として記憶部220に記憶する。以上説明したユーザ登録処理によって、携帯端末200は、カード番号を付与されて、認証装置100に登録される。
以上がユーザ登録処理の説明であるが、ユーザ登録完了パケットを受信した携帯端末200は、引き続いて、携帯トークンの生成を認証装置100に依頼するために、携帯トークン依頼部211が、認証装置100に携帯トークン依頼パケットを送信する。携帯トークン依頼パケットとは、少なくとも携帯端末200の携帯端末ID及びユーザ暗証番号を含み、認証装置100に携帯トークンの生成を依頼するパケットである。なお、携帯端末200を複数のユーザが共有する場合を考慮して、携帯トークン依頼パケットに、携帯端末ID及びユーザ暗証番号に加えて、ユーザIDを含めても良い。認証装置100は、この携帯トークン依頼パケットを受信すると、携帯トークン生成処理を開始する。なお、携帯端末200は、ユーザ登録完了パケットを受信してもすぐには携帯トークン依頼パケットを送信せず、ユーザが携帯トークン生成を指示(例えば携帯トークン生成ボタンを押下)した後に携帯トークン依頼パケットを送信するようにしても良い。ただし、携帯端末200は、後述する携帯端末決済処理を行う前に、携帯トークン生成処理によって生成された携帯トークンを取得している必要がある。この携帯トークン生成処理について、図19を参照して説明する。
まず、携帯トークン生成部111は、携帯通信部131を介して、携帯端末200が送信した携帯トークン依頼パケットを受信すると、該パケットに含まれる携帯端末ID及びユーザ暗証番号を取得する(ステップS111)。そして、携帯トークン生成部111は、記憶部120に記憶されている携帯端末情報一覧121に含まれる携帯端末ID及びユーザ暗証番号と、ステップS111で取得した携帯端末ID及びユーザ暗証番号とを照合し、問題があるか否かを判定する(ステップS112)。この判定は、ステップS111で取得した携帯端末IDが、携帯端末情報一覧121に含まれており、携帯端末情報一覧121中のその携帯端末IDに対応するユーザ暗証番号が、ステップS111で取得したユーザ暗証番号と一致すれば、問題ないと判定する。また、ステップS111で取得した携帯端末IDが、携帯端末情報一覧121に含まれていないか、又は、含まれていても、対応するユーザ暗証番号が一致しない場合は、問題があると判定する。さらに、携帯トークン生成部111がカード発行サーバ400にユーザの信用情報を問い合わせ、ユーザの信用情報に問題がある場合には、携帯トークン生成部111はステップS112において、問題があると判定するようにしても良い。
携帯トークン生成部111は、この照合の結果、問題ありと判定された場合は(ステップS112;No)、携帯トークンを生成できない旨を、携帯通信部131を介して携帯端末200に送信し(ステップS113)、処理を終了する。照合の結果、問題なしと判定された場合は(ステップS112;Yes)、携帯トークン生成部111は、携帯トークンを生成し、有効期限及び有効回数を設定する(ステップS114)。このステップS114は、携帯トークン生成ステップと言うことができる。携帯トークンの生成方法は任意であるが、例えば、携帯トークン依頼パケットに含まれる情報(携帯端末ID及びユーザ暗証番号)並びにトークン生成時の時刻データを入力値として、ハッシュ関数を適用することによって得られた値を携帯トークンとすることができる。有効期限をどのように設定するかは任意であるが、例えば現在日時の1週間後、3日後等を設定することができる。また、有効回数をどのように設定するかも任意であるが、例えば3回、1回等を設定することができる。また、携帯トークン生成部111がカード発行サーバ400にユーザの信用情報を問い合わせている場合は、その時点におけるユーザの信用情報の内容に応じて、携帯トークンの有効期限及び有効回数を変更しても良い。
次に、携帯トークン生成部111は、ステップS111で取得した携帯端末IDに対応するユーザIDを、携帯端末情報一覧121を参照して取得するとともに、ユーザ情報一覧122を参照して、該ユーザIDに対応するカード番号を取得する。そして、生成した携帯トークン並びに設定した有効期限及び有効回数とカード番号とを紐付けて携帯トークン情報一覧123(図5)として、記憶部120に記憶する(ステップS115)。ステップS115で記憶された携帯トークン情報一覧123は、後述するように、認証の際の判定基準として使用される。
そして、携帯トークン生成部111は、生成した携帯トークン並びに設定した有効期限及び有効回数を、携帯通信部131を介して携帯端末200に送信し(ステップS116)、処理を終了する。このステップS116は、携帯トークン送信ステップと言うことができる。上記の携帯トークン生成処理によって、携帯端末200は、携帯トークンを取得し、携帯トークン情報223(図11)として、記憶部220に記憶する。なお、上記は各携帯端末200に、カード番号が1つだけ割り当てられている場合で説明した。もし複数のカード番号が割り当てられている場合には、携帯トークン依頼パケットにカード番号又はカード番号に対応するカード会社の情報を含める。そして、携帯トークン生成部111は、携帯端末IDが同じでも、カード番号が異なる場合には、異なる値の携帯トークンを生成するようにする。例えば、携帯トークン生成部111は、携帯端末ID、ユーザ暗証番号及びトークン生成時の時刻データに加えてカード番号の情報も入力値にしてハッシュ関数を適用して、携帯トークンを生成する。
次に、認証装置100が、決済端末300を登録して決済先識別番号を取得する決済端末登録処理について、図20を参照して説明する。この処理は、携帯端末200及び決済端末300による決済処理に先立ち、決済端末300が初期設定動作を開始して、決済端末300から認証装置100に、決済端末登録依頼パケットが送信されると実行される。なお、図示は省略するが、理解を容易にするために、決済端末登録処理の説明の前に、決済端末300が認証装置100に決済端末登録パケットを送信するまでの認証システム1全体の動作について説明する。まず、決済端末300は、店舗に設置されて電源が投入され、初期設定動作を開始すると、店員にその店舗の店員数並びに該店員数分の店員ID及び店員暗証番号の入力を促す。そして、決済端末300は、店員による店員数並びに該店員数分の店員ID及び店員暗証番号の入力が完了すると、認証装置100に決済端末登録依頼パケットを送信する。決済端末登録依頼パケットとは、決済端末300の決済端末ID、決済端末300が設置された店舗の店員数並びに店員数分の店員ID及び店員暗証番号の各情報を含み、送信先である認証装置100に決済端末登録を依頼するパケットである。認証装置100は、この決済端末登録依頼パケット受信すると、以下で説明する決済端末登録処理を開始する。
なお、決済端末300の初期設定が既に完了済みの場合でも、店員が決済端末300に、決済端末登録処理の開始を指示することによって、決済端末登録依頼パケットを送信させることが可能である。例えば、店員が、既に取得済み決済先識別番号とは別の決済先識別番号を取得したい場合がある。この場合、店員は決済端末登録処理の前の、店員数及び該店員数分の店員暗証番号の入力時に、別の決済先識別番号を使用したい旨の情報も入力し、決済端末300は、それらを決済端末登録依頼パケットの中に含めて認証装置100に送信する。そして、認証装置100は、決済端末登録依頼パケットの中に、別の決済先識別番号を使用したい旨の情報が含まれていた場合は、決済端末及び店員の信用情報に問題がなければ別の決済先識別番号を追加で発行して決済端末登録を行う。このようにすることによって、店員は使用可能な決済先識別番号を増やすことができる。では、決済端末登録処理について、図20を参照して説明する。
まず、制御部110は、決済通信部132を介して、受信した決済端末登録依頼パケットに含まれる、決済端末ID、店員数並びに、店員数分の店員ID及び店員暗証番号を取得し、記憶部120に記憶する(ステップS201)。
次に、制御部110は、通信部133を介してカード発行サーバ400に接続し、決済端末ID及び店員IDに基づく信用情報を取得する(ステップS202)。この信用情報は上述したユーザの信用情報と同様、その決済端末及び店員が過去に代金の授受等で問題を起こしていないか否かを示す、いわゆるブラックリストの情報である。過去に問題を起こしている場合は、信用情報に問題がある決済端末及び店員であると判断される。そして、制御部110は、信用情報に問題があるか否かを判定する(ステップS203)。具体的に、ステップS303では、ステップS201にて取得した決済端末ID、店員IDなどの情報の少なくとも一部が、ステップS202で取得した信用情報(ブラックリスト)に含まれているか否かを判定し、含まれている場合には問題があるとする。信用情報に問題がある場合(ステップS203;No)、制御部110は決済通信部132を介して、決済端末登録できない旨を決済端末300に送信し(ステップS204)、処理を終了する。この場合、決済端末300の決済側表示部334に、決済端末登録できない旨が表示される。
信用情報に問題がない場合(ステップS203;Yes)、制御部110は、通信部133を介してカード発行サーバ400に、決済先識別番号発行依頼パケットを送信する(ステップS205)。決済先識別番号発行依頼パケットとは、上述した決済端末登録依頼パケットに含まれる各情報(決済端末300の決済端末ID、決済端末300が設置された店舗の店員数並びに店員数分の店員ID及び店員暗証番号)を含み、カード発行サーバ400に決済先識別番号の発行を依頼するパケットである。該決済先識別番号発行依頼パケットを受信したカード発行サーバ400は、決済先識別番号を発行し、決済端末ID、店員ID及び店員暗証番号とともに認証装置100に返信する。なお、ユーザ登録処理と同様に、信用情報の取得及び信用情報に問題があるか否かの判定を、認証装置100ではなく、カード発行サーバ400が行っても良い。この場合の処理は、図18のステップS105の説明の次の段落に書いたとおりである。
また、決済先識別番号発行依頼パケットに決済先識別番号の発行数の情報を含ませることにより、カード発行サーバ400が決済先識別番号を複数発行することも可能である。例えば、図7は、決済端末ID=80000002の決済端末300が設置されている店の店員ID=60001001の店員及び店員ID=61100123の店員に、それぞれ決済先識別番号を2つ発行している例を示している。
また、決済端末登録依頼パケットの中に、別の決済先識別番号を使用したい旨の情報が含まれていた場合には、認証装置100は、この別の決済先識別番号を使用したい旨の情報を決済先識別番号依頼パケットの中に含めてカード発行サーバ400に送信する。カード発行サーバ400は、受信した決済先識別番号依頼パケットに別の決済先識別番号を使用したい旨の情報が含まれていた場合には、過去に発行した決済先識別番号とは別の決済先識別番号を発行して認証装置100に返信する。このようにすることによって、決済端末300を使用する店員は、既に取得済みの決済先識別番号とは異なる決済先識別番号を決済に使用することが可能になる。
図20に戻り、次に、制御部110は、通信部133を介して、カード発行サーバ400から店員ID、決済先識別番号、店員暗証番号及び決済端末IDを受信する(ステップS206)。そして、決済端末IDに、店員数並びに該店員数分の店員ID及び決済先識別番号を紐付けて決済識別情報一覧125(図7)として、記憶部120に記憶する(ステップS207)。また、決済端末IDに店員数並びに該店員数分の店員ID及び店員暗証番号を紐付けて決済端末情報一覧124(図6)として、記憶部120に記憶する(ステップS208)。
次に、制御部110は、決済通信部132を介して、決済端末登録完了パケットを決済端末300に送信し(ステップS209)、処理を終了する。決済端末登録完了パケットとは、決済端末情報一覧124として記憶部120に記憶されている決済端末ID、店員数並びに該店員数分の店員ID及び店員暗証番号の各情報を含み、決済端末300に、決済端末登録が完了したことを通知するパケットである。決済端末300の制御部310は、決済側通信部331を介して決済端末登録完了パケットを受信すると、決済端末登録完了パケットに含まれる決済端末ID、店員数並びに該店員数分の店員ID及び店員暗証番号を決済端末情報321(図14)として記憶部320に記憶する。以上説明した決済端末登録処理によって、決済端末300は、決済先識別番号を付与されて、認証装置100に登録される。
以上が決済端末登録処理の説明であるが、決済端末登録完了パケットを受信した決済端末300は、引き続いて、決済トークンの生成を認証装置100に依頼するために、決済トークン依頼部311が、認証装置に決済トークン依頼パケットを送信する。決済トークン依頼パケットとは、決済端末300の決済端末ID、店員ID及び店員暗証番号を含み、認証装置100に決済トークンの生成を依頼するパケットである。認証装置100は、この決済トークン依頼パケットを受信すると、決済トークン生成処理を開始する。なお、決済端末300は、決済端末登録完了パケットを受信してもすぐには決済トークン依頼パケットを送信せず、店員が決済トークン生成を指示(例えば決済トークン生成ボタンを押下)した後に決済トークン依頼パケットを送信するようにしても良い。ただし、決済端末300は、後述する決済端末決済処理を行う前に、決済トークン生成処理によって生成された決済トークンを取得している必要がある。この決済トークン生成処理について、図21を参照して説明する。
まず、決済トークン生成部112は、決済通信部132を介して、決済端末300が送信した決済トークン依頼パケットを受信すると、該パケットに含まれる決済端末ID、店員ID及び店員暗証番号を取得する(ステップS211)。そして、決済トークン生成部112は、記憶部120に記憶されている決済端末情報一覧124に含まれる決済端末ID、店員ID及び店員暗証番号と、ステップS211で取得した決済端末ID、店員ID及び店員暗証番号とを照合し、問題があるか否かを判定する(ステップS212)。この判定は、ステップS211で取得した決済端末ID及び店員IDが、決済端末情報一覧124に含まれており、決済端末情報一覧124中のその決済端末ID及び店員IDに対応する店員暗証番号が、ステップS211で取得した店員暗証番号と一致すれば、問題ないと判定する。また、ステップS211で取得した決済端末ID又は店員IDが、決済端末情報一覧124に含まれていないか、又は、含まれていても、対応する店員暗証番号が一致しない場合は、問題があると判定する。さらに、決済トークン生成部112がカード発行サーバ400に決済端末及び店員の信用情報を問い合わせ、これらの信用情報に問題がある場合には、決済トークン生成部112はステップS212において、問題があると判定するようにしても良い。
決済トークン生成部112は、この照合の結果、問題ありと判定された場合は(ステップS112;No)、決済トークンを生成できない旨を、決済通信部132を介して決済端末300に送信し(ステップS213)、処理を終了する。照合の結果、問題なしと判定された場合は(ステップS212;Yes)、決済トークン生成部112は、決済トークンを生成し、有効期限及び有効回数を設定する(ステップS214)。このステップS214は、決済トークン生成ステップと言うことができる。決済トークンの生成方法は任意であるが、例えば、決済トークン依頼パケットに含まれる情報(決済端末ID、店員ID及び店員暗証番号)並びにトークン生成時の時刻データを入力値として、ハッシュ関数を適用することによって得られた値を決済トークンとすることができる。有効期限をどのように設定するかは任意であるが、例えば現在日時の1週間後、1ヶ月後等を設定することができる。また、有効回数をどのように設定するかも任意であるが、例えば3回、10回等を設定することができる。また、決済トークン生成部112がカード発行サーバ400に決済端末及び店員の信用情報を問い合わせている場合は、その時点における決済端末及び店員の信用情報の内容に応じて、決済トークンの有効期限及び有効回数を変更しても良い。
次に、決済トークン生成部112は、決済識別情報一覧125を参照して、決済端末ID及び店員IDに対応する決済先識別番号を取得する。そして、生成した決済トークン並びに設定した有効期限及び有効回数と決済先識別番号とを紐付けて決済トークン情報一覧126(図8)として、記憶部120に記憶する(ステップS215)。ステップS215で記憶された決済トークン情報一覧126は、後述するように、認証の際の判定基準として使用される。
そして、決済トークン生成部112は、生成した決済トークン並びに設定した有効期限及び有効回数を、決済通信部132を介して決済端末300に送信し(ステップS216)、処理を終了する。このステップS216は、決済トークン送信ステップと言うことができる。上記の決済トークン生成処理によって、決済端末300は、決済トークンを取得し、決済トークン情報322(図15)として、記憶部320に記憶する。なお、上記は各店員に、決済先識別番号が1つだけ割り当てられている場合で説明した。もし複数の決済先識別番号が割り当てられている場合には、決済トークン依頼パケットに決済先識別番号の情報を含める。そして、決済トークン生成部112は、決済端末ID及び店員IDが同じでも、決済先識別番号が異なる場合には、異なる値の決済トークンを生成するようにする。例えば、決済トークン生成部112は、決済端末ID、店員ID、店員暗証番号及びトークン生成時の時刻データに加えて決済先識別番号の情報も入力値にしてハッシュ関数を適用して、決済トークンを生成する。
以上で、決済処理に先立って必要なユーザ登録処理、携帯トークン生成処理、決済端末登録処理及び決済トークン生成処理の説明を終えた。続いて、携帯端末200及び決済端末300による決済処理と、認証装置100による認証処理について、図22〜図24を参照して順を追って説明する。
決済端末300による決済端末決済処理(図22)と携帯端末200による携帯端末決済処理(図23)とは、以下で説明するように同様のタイミングで開始されるため、以下では並行して説明する。まず、これらの処理が開始されるタイミングについて説明する。この決済端末300による決済端末決済処理は、店員がユーザ(商品購入者)に商品を販売する際に、店員からの指示で開始される。具体的には、店員は、商品を販売する際、決済に先立って、決済端末300の決済側入力部333から店員ID及び店員暗証番号を入力する。そして、決済端末300は、店員が入力した店員ID及び店員暗証番号を、記憶部320に記憶されている決済端末情報321と照合して、入力された店員暗証番号が一致しない場合は、正しい店員暗証番号が入力されるまで、店員暗証番号の入力を店員に繰り返し行わせる。店員は、正しい店員暗証番号を入力したら、決済端末300に取引内容を入力する。取引内容とは、ユーザが購入する商品の種類及び金額を示す情報である。すると決済端末300は、取引内容に基づいて決済金額を計算して決済側表示部334に表示する。そして店員は、ユーザに、ユーザの所持する携帯端末200を、決済端末300が備えるNFCリーダライタにかざすように促すとともに、決済端末300に、決済処理を行うように指示を出す。すると、決済端末300は、以下に説明する決済端末決済処理を開始する。なお、上記の説明では、店員は店員暗証番号を入力後に、取引内容の入力を行っていたが、この順番は任意であり、取引内容を入力してから、決済処理の指示を出す際に店員暗証番号を入力することにしても良い。
また、この時、ユーザ(商品購入者)は、店員に、携帯端末200を決済端末300が備えるNFCリーダライタにかざすように促されるので、携帯端末200で決済用携帯アプリ221を起動してユーザ暗証番号を入力した後に、NFCリーダライタにかざす。決済用携帯アプリ221が起動してユーザ暗証番号が入力されると、携帯端末200は、以下に説明する携帯端末決済処理を開始する。ただし、ユーザ暗証番号の入力は任意であり、決済用携帯アプリ221の設定等により、ユーザ暗証番号の入力無しで、携帯端末200は携帯端末決済処理を開始しても良い。
なお、決済用携帯アプリ221で、ユーザが決済に使用するカードのカード会社を選択可能になっている場合は、ユーザは、使用するカードのカード会社を決済前に店員に伝え、そのカード会社に対応するカード番号で決済処理をすることを、決済用携帯アプリ221に指示しておく。この場合、携帯端末200は、ユーザから指示されたカード番号を使用して決済処理を行う。これに対応し、決済端末300の方も、ユーザが決済に使用するカードのカード会社を選択可能にしている場合(店員がそのカード会社に対応する決済先識別番号を取得している場合)は、店員がユーザが使用するカードのカード会社を決済前に確認し、そのカード会社に対応する決済先識別番号で決済処理をするように、決済端末300に指示しておく。店員が複数の決済先識別番号を選択可能な場合、決済端末300は、ここで店員から指示された決済先識別番号を使用して決済処理を行う。
では、決済端末決済処理及び携帯端末決済処理について、図22及び図23を参照して説明する。
まず、図22に示すように、決済側決済処理部312は、決済側入力部333から入力された取引内容(商品の種類及び金額)を取得し、記憶部320に記憶する(ステップS301)。次に、決済側決済処理部312は、決済側近距離通信部332を介して、携帯端末200に携帯トークン要求パケットを送信する(ステップS302,A)。携帯トークン要求パケットとは、携帯端末200に、携帯トークン、携帯端末ID及びユーザ暗証番号の各情報の送信を要求するパケットである。
携帯端末200の方は、携帯端末決済処理が開始されると、まず、図23に示すように、携帯側決済処理部212が、携帯側近距離通信部231を介して、決済端末300からの携帯トークン要求パケットの送信があるか否かを判定する(ステップS401,A)。携帯トークン要求パケットの送信がなければ(ステップS401;No)、ステップS401に戻って、携帯トークン要求パケットの送信を待つ。
携帯トークン要求パケットの送信があれば(ステップS401;Yes)、携帯側決済処理部212は、携帯側近距離通信部231を介して、携帯トークン、携帯端末ID及びユーザ暗証番号の各情報を決済端末300に送信する(ステップS402,B)。
すると、図22に示すように、決済側決済処理部312は、決済側近距離通信部332を介して、携帯端末200から携帯トークン、携帯端末ID及びユーザ暗証番号を取得し、取得した携帯トークン、携帯端末ID及びユーザ暗証番号を決済側決済情報323(図16)として、記憶部320に記憶する(ステップS303,B)。
次に、決済側決済処理部312はステップS301及びステップS303で記憶部320に記憶した取引内容及び決済側決済情報323と、記憶部320に記憶されている決済端末情報321とから、決済開始依頼パケットを生成し、決済側通信部331を介して、認証装置100に送信する(ステップS304,C)。決済開始依頼パケットとは、携帯トークン、携帯端末ID、ユーザ暗証番号、決済端末ID、店員ID、店員暗証番号及び取引内容の各情報を含み、認証装置100に、決済処理の開始を依頼するパケットである。したがって、携帯トークンが取引内容等の情報と合わせて認証装置100に送信されるため、別途携帯トークンを携帯端末200側で送信する必要がなくなり、処理を効率化することができる。
認証装置100が決済端末300から決済開始依頼パケットを受信すると、認証装置100による認証処理が開始される。この認証処理について、図24を参照して、決済端末決済処理(図22)及び携帯端末決済処理(図23)と並行して説明する。
図24に示すように、まず、認証装置100の制御部110は、決済通信部132を介して受信した決済開始依頼パケットに含まれる携帯トークン、携帯端末ID、ユーザ暗証番号、決済端末ID、店員ID、店員暗証番号及び取引内容の各情報を取得し、記憶部120に記憶する(ステップS501,C)。このステップS501は、携帯トークン受信ステップと言うことができる。
そして、認証部113は、受信した決済開始依頼パケットに含まれる各情報に問題があるか否かを判定する(ステップS502)。ここで、認証部113が該各情報に問題があると判定する条件について具体的に説明する。認証部113は、決済開始依頼パケットに含まれる決済端末ID、店員ID及び店員暗証番号が、記憶部120に記憶されている決済端末情報一覧124に含まれている情報と一致しない場合は問題があると判定する。また、決済開始依頼パケットに含まれる携帯端末ID及びユーザ暗証番号が、記憶部120に記憶されている携帯端末情報一覧121に含まれている情報と一致しない場合は問題があると判定する。また、記憶部120に記憶されている携帯トークン情報一覧123の中から、決済開始依頼パケットに含まれる携帯端末IDに対応する携帯トークンを検索し、見つからない場合は問題があると判定する。見つかった場合でも、該携帯トークンが、決済開始依頼パケットに含まれる携帯トークンと一致しない場合又は、該携帯トークンの有効期限が切れている若しくは有効回数が0以下になっている場合は問題があると判定する。これらすべての条件をクリアした場合は、認証部113は、決済開始依頼パケットに含まれる各情報に問題はないと判定する。
認証部113が、決済開始依頼パケットに含まれる各情報に問題があると判定したら(ステップS502;No)、制御部110は、決済通信部132を介して、決済端末300に、決済開始依頼パケットに含まれる情報に問題があるという判定結果を返信し(ステップS503,D)、支払い処理をカード発行サーバ400に依頼せずに、認証処理を終了する。
認証部113が、決済開始依頼パケットに含まれる各情報に問題がないと判定したら(ステップS502;Yes)、制御部110は、決済通信部132を介して、決済端末300に、決済開始依頼パケットに含まれる情報は問題無しであるという判定結果を返信し(ステップS504,D)、携帯端末200からの決済依頼パケットを待つ。図示しないが、ここで所定の時間(例えば5秒)待っても携帯端末200からの決済依頼パケットが送られてこなければ、タイムアウトエラーとなり、制御部110は、ステップS507からの処理を行う。
そして、図22に示すように、決済側決済処理部312は、認証装置100から返信された判定結果を、決済側通信部331を介して受信する(ステップS305,D)。続いて決済側決済処理部312は、該判定結果が問題無しであったか否かを判定する(ステップS306)。該判定結果が問題無しではなかった場合(ステップS306;No)、決済処理はできず、決済側決済処理部312は、決済処理ができない旨を決済側表示部334に表示し(ステップS310)、決済端末決済処理を終了する。
該確認結果が問題無しだった場合(ステップS306;Yes)、決済側決済処理部312は、決済側近距離通信部332を介して、携帯端末200に、取引内容通知パケットを送信する(ステップS307,E)。取引内容通知パケットとは、決済トークン、決済端末ID、店員ID、店員暗証番号及び取引内容の各情報を含むパケットである。
携帯端末200の携帯側決済処理部212は、図23に示すように、決済端末300が送信した取引内容通知パケットを、携帯側近距離通信部231を介して受信する(ステップS403,E)。図示しないが、このステップでは携帯側決済処理部212は、取引内容通知パケットが受信できるまで所定時間(例えば5秒)待ち、該所定時間待っても取引内容通知パケットが受信できなかった場合はタイムアウトエラーとなり、決済処理を完了せずに、携帯端末決済処理を終了する。
取引内容通知パケットを受信できたら、携帯側決済処理部212は、該取引内容通知パケットに含まれる各情報を携帯側決済情報224(図12)として、記憶部220に記憶する(ステップS404)。そして携帯側決済処理部212は、携帯側決済情報224と、記憶部220に記憶されている携帯端末情報222とから、決済依頼パケットを生成し、生成した決済依頼パケットを、携帯側通信部232を介して、認証装置100に送信する(ステップS405,F)。決済依頼パケットとは、決済トークン、決済端末ID、店員ID、店員暗証番号、取引内容、携帯端末ID及びユーザ暗証番号の各情報を含み、認証装置100に決済処理を依頼するパケットである。
携帯端末200から決済依頼パケットが送信されたら、認証装置100の制御部110は、図24に示すように該決済依頼パケットを、携帯通信部131を介して受信する(ステップS505,F)。そして制御部110は、該決済依頼パケットに含まれる決済トークン、決済端末ID、店員ID、店員暗証番号、取引内容、携帯端末ID及びユーザ暗証番号の各情報を取得し、記憶部120に記憶する。このステップS505は、決済トークン受信ステップと言うことができる。
そして、認証部113は、受信した決済依頼パケットに含まれる各情報に問題があるか否かを判定する(ステップS506)。このステップS506は、認証ステップと言うことができる。ここで、認証部113が該各情報に問題があると判定する条件について具体的に説明する。
認証部113は、決済依頼パケットに含まれる決済端末ID、店員ID及び店員暗証番号が、記憶部120に記憶されている決済端末情報一覧124に含まれている情報と一致しない場合は問題があると判定する。また、決済依頼パケットに含まれる携帯端末ID及びユーザ暗証番号が、記憶部120に記憶されている携帯端末情報一覧121に含まれている情報と一致しない場合は問題があると判定する。また、記憶部120に記憶されている決済トークン情報一覧126の中から、決済依頼パケットに含まれる決済端末ID及び店員IDに対応する決済トークンを検索し、見つからない場合は問題があると判定する。見つかった場合でも、該決済トークンが、決済依頼パケットに含まれる決済トークンと一致しない場合又は、該決済トークンの有効期限が切れている若しくは有効回数が0以下になっている場合は問題があると判定する。また、決済依頼パケットに含まれる取引内容と、ステップS501で取得した決済開始依頼パケットに含まれる取引内容とが一致しない場合は問題があると判定する。これらすべての条件をクリアした場合は、認証部113は、決済依頼パケットに含まれる各情報に問題はないと判定する。
認証部113が、決済依頼パケットに含まれる各情報に問題があると判定したら(ステップS506;No)、制御部110は、携帯通信部131及び決済通信部132を介して、携帯端末200及び決済端末300にそれぞれ、決済処理を完了できない旨を送信し(ステップS507,G)、支払い処理をカード発行サーバ400に依頼せずに、認証処理を終了する。
認証部113が、決済依頼パケットに含まれる各情報に問題がないと判定したら(ステップS506;Yes)、制御部110は、カード支払依頼パケットを生成し、生成したカード支払依頼パケットを、通信部133を介してカード発行サーバ400に送信して、支払い処理を依頼する(ステップS508)。カード支払依頼パケットとは、ユーザのカード番号、店員の決済端末識別番号、取引内容の各情報を含み、カード発行サーバ400に支払い処理を依頼するパケットである。支払い処理は、上述したように、決済処理で使用されたカード番号のユーザの口座から決済先識別番号で示されるカード会社へ取引内容の代金を支払う処理をいう。制御部110は、携帯トークンの値と携帯トークン情報一覧123とからユーザのカード番号を取得でき、決済トークンの値と決済トークン情報一覧126とから店員の決済先識別番号を取得できるので、これらの情報に基づいて、カード支払依頼パケットを生成することができる。
なお、図示は省略するが、カード支払依頼パケットがカード発行サーバ400に送信されると、カード発行サーバ400の支払い処理部413は、発行側通信部431を介して、カード支払依頼パケットを受信し、カード支払依頼パケットに含まれるカード番号、決済先識別番号及び取引内容に基づいて支払い処理を実行する。そして、支払い処理部413は、支払い処理の結果の情報(支払い処理が正常に完了したか否かを示す情報)を、発行側通信部431を介して認証装置100に送信する。
認証装置100の制御部110は、カード発行サーバ400から送信された支払い処理の結果の情報を、通信部133を介して受信する(ステップS509)。そして認証部113は、制御部110が受信した情報に基づき、支払い処理が正常に完了したか否かを判定する(ステップS510)。認証部113が、支払い処理が正常に完了しなかったと判定したら(ステップS510;No)、制御部110は、携帯通信部131及び決済通信部132を介して、携帯端末200及び決済端末300にそれぞれ、支払い処理が行えなかったこと、すなわち決済処理を正常に完了できなかった旨を送信し(ステップS507,G)、認証処理を終了する。
認証部113が、支払い処理が正常に完了したと判定したら(ステップS510;Yes)、制御部110は、携帯通信部131及び決済通信部132を介して、携帯端末200及び決済端末300にそれぞれ、支払い処理が正常に行われたこと、すなわち決済処理が正常に完了した旨を送信する(ステップS511,G)。そして、制御部110は、記憶部120に記憶されている携帯トークン情報一覧123及び決済トークン情報一覧126それぞれに含まれる有効回数を1減らし(ステップS512)、認証処理を終了する。
認証装置100は、支払い処理が正常に完了したか否かを示す支払い処理の結果の情報を携帯端末200と決済端末300にそれぞれ送信するため、該情報を受信した携帯端末200及び決済端末300のそれぞれの処理を順に説明する。
まず、携帯端末200の処理を、図23を参照して説明する。携帯端末200の携帯側決済処理部212は、携帯側通信部232を介して、認証装置100が送信した支払い処理の結果の情報(すなわち決済処理が正常に完了したか否かを示す情報)を受信し(ステップS406,G)、決済処理が正常に完了したか否かを判定する(ステップS407)。決済処理が正常に完了しなかったなら(ステップS407;No)、携帯端末決済処理を終了する。その際、携帯側決済処理部212は、決済が完了しなかった旨を携帯側表示部234に表示しても良い。
決済処理が正常に完了したなら(ステップS407;Yes)、携帯側決済処理部212は、記憶部220に記憶されている携帯トークン情報223に含まれる携帯トークンの有効回数を1減らす(ステップS408)。そして、携帯端末決済処理を終了する。
なお、図示しないが、ステップS408で携帯トークンの有効回数を1減らした結果、有効回数が0になった場合は、新たな携帯トークンを取得するために、携帯トークン依頼部211が、認証装置100に携帯トークン依頼パケットを送信する処理を行っても良い(すなわち、有効回数を確認し、0である場合には、認証装置100に図19に示す携帯トークン生成処理を行わせても良い)。このようにすると、認証装置100で携帯トークン生成処理が実行され、携帯端末200は、有効期限及び有効回数が更新された新たな携帯トークンを取得することができる。また、有効回数が0になったか否かにかかわらず、決済処理が完了するたびに携帯トークン生成処理を実行し、決済処理の度に取得した携帯トークンが更新されるようにしてもよい。これによれば、決済処理の度に携帯トークンの値が新たに更新されるため、セキュリティを強化することができる。また、決済処理後に自動的に携帯トークンを取得することによって、ユーザが携帯トークンを更新する手間を軽減することができる。これらの携帯トークン生成処理においては、上述したように、認証装置100は、その時点におけるユーザの信用情報の内容に応じて、携帯トークンの有効期限や有効回数を変更しても良い。そして、その際、認証装置100は、その時点におけるユーザの信用情報をカード発行サーバ400に問い合わせても良い。
続いて、決済端末300の処理を、図22を参照して説明する。決済端末300の決済側決済処理部312は、決済側通信部331を介して、認証装置100が送信した支払い処理の結果の情報(すなわち決済処理が正常に完了したか否かを示す情報)を受信し(ステップS308,G)、決済処理が正常に完了したか否かを判定する(ステップS309)。決済処理が正常に完了しなかったなら(ステップS309;No)、決済側決済処理部312は、決済処理ができない旨を決済側表示部334に表示して(ステップS310)、決済端末決済処理を終了する。
決済処理が正常に完了したなら(ステップS309;Yes)、決済側決済処理部312は、決済処理が完了した旨を決済側表示部334に表示する(ステップS311)。そして、決済側決済処理部312は、記憶部320に記憶されている決済トークン情報322に含まれる決済トークンの有効回数を1減らす(ステップS312)。そして決済端末決済処理を終了する。
なお、図示しないが、ステップS312で決済トークンの有効回数を1減らした結果、有効回数が0になった場合は、新たな決済トークンを取得するために、決済トークン依頼部311が、認証装置100に決済トークン依頼パケットを送信する処理を行っても良い(すなわち、有効回数を確認し、0である場合には認証装置100に図21に示す決済トークン生成処理を行わせても良い)。このようにすると、認証装置100で決済トークン生成処理が実行され、決済端末300は、有効期限及び有効回数が更新された新たな決済トークンを取得することができる。また、有効回数が0になったか否かにかかわらず、決済処理が完了するたびに決済トークン生成処理を実行し、決済処理の度に取得した決済トークンが更新されるようにしてもよい。これによれば、決済処理の度に決済トークンの値が新たに更新されるため、セキュリティを強化することができる。また、決済処理後に自動的に決済トークンを取得することによって、店員が決済トークンを更新する手間を軽減することができる。
以上、認証装置100による認証処理、携帯端末200による決済端末決済処理及び決済端末300による決済端末決済処理について説明した。認証装置100は、上述した仕組みにより、携帯端末200及び決済端末300と協働して、2種類のトークンを、それぞれ他方を介して受信することによって、ユーザに煩わしい操作をさせることなく、なりすましが困難な認証処理を行うことができる。
例えば、携帯端末200が、耐タンパー性を有するICチップを備えていない場合は、認証装置100から事前に取得した携帯トークンを他人に盗まれる可能性がある。しかし、認証装置100に、決済処理の正当性を認証してもらうためには、携帯トークンだけでなく、決済トークンも正しいトークンである必要がある。そして、正しい決済トークンを所持しているのは決済端末300なので、携帯端末200が正しい決済トークンを取得するためには、店頭で決済端末300とNFCによる通信を行う必要がある。よって、携帯トークンを盗んだとしても、店頭で決済端末300から決済トークンを取得しない限りは、なりすましの決済処理を行うことはできないのである。したがって、認証装置100は、携帯端末200が耐タンパー性を有するICチップを有していなくても、なりすましを防止することができる。また、トークンには有効期限及び有効回数を設定することができるので、有効期限を過ぎたトークン及び有効回数分使用したトークンを無効とすることによって、安全性をさらに高めることができる。
(変形例1)
実施の形態1では、決済端末300は、取引に先立って事前に決済トークンの生成を認証装置100に依頼し、取得した決済トークンの情報を決済トークン情報322として、記憶部320に記憶している。この場合、店員は、決済の都度、決済トークンの有効期限及び有効回数に基づいて決済トークンが有効であることを確認し、もし無効になっていたら、決済トークンを更新する必要がある。そこで、決済トークンを事前に取得するのではなく、決済処理の都度取得するようにする変形例1について説明する。
この変形例1に係る認証装置100、携帯端末200及び決済端末300の機能構成は実施の形態1に係る認証装置100、携帯端末200及び決済端末300の機能構成と同じである。また、変形例1に係る認証装置100による、ユーザ登録処理、携帯トークン生成処理及び決済端末登録処理は、実施の形態1に係る認証装置100による各処理と同じである。そして、変形例1に係る携帯端末決済処理は、実施の形態1に係る携帯端末決済処理と同じである。変形例1が実施の形態1と異なる点は、決済端末300が決済トークンを取得するタイミングが異なるのみである。実施の形態1では、決済トークン生成処理の際に認証装置100が決済端末300に決済トークンを送信している(図21のステップS216)。変形例1では、図21のステップS216の処理はスキップされ、決済トークン情報一覧126は認証装置100の記憶部120に記憶されるだけに留まる。そして、決済端末300は、決済端末決済処理(図22)のステップS305において、認証装置100から決済開始依頼の判定結果とともに決済トークンを受信する。
決済端末300が認証装置100から決済トークンを受信できるようにするために、認証装置100は、認証処理(図24)のステップS504において、決済端末300に決済トークンも送信する。ただし、認証装置100は、決済端末300に決済トークンを送信する前に、その決済トークンの有効期限及び有効回数を確認する。そして、認証装置100は、決済トークンの有効期限切れ又は有効回数が0であることを確認したら、決済開始依頼パケットに含まれる決済端末ID、店員ID及び店員暗証番号に基づき、決済トークン生成処理(図21。ただしステップS216を除く)を行う。そして、認証装置100は、新たに生成した決済トークンを認証処理(図24)のステップS504において、決済端末300に送信する。
変形例1では、上述のような処理を行うことにより、決済端末300側で、決済トークンの有効期限及び有効回数に基づいて決済トークンが有効であることを確認する必要がなくなる。したがって店員を決済トークンの有効性の確認及び決済トークンの更新という煩雑さから開放することができる。
(変形例2)
実施の形態1では、携帯端末200は、取引に先立って事前に携帯トークンの生成を認証装置100に依頼し、取得した携帯トークンの情報を携帯トークン情報223として、記憶部220に記憶している。この場合、ユーザは、決済の都度、携帯トークンの有効期限及び有効回数に基づいて携帯トークンが有効であることを確認し、もし無効になっていたら、携帯トークンを更新する必要がある。そこで、決済処理の際に、携帯端末200が携帯トークンを確認し、未取得又は無効の場合は、決済処理の直前に携帯トークンを取得するようにする変形例2について説明する。
この変形例2に係る認証装置100、携帯端末200及び決済端末300の機能構成は実施の形態1に係る認証装置100、携帯端末200及び決済端末300の機能構成と同じである。また、変形例2に係る認証装置100による、ユーザ登録処理、携帯トークン生成処理、決済端末登録処理及び決済トークン生成処理は、実施の形態1に係る認証装置100による各処理と同じである。そして、変形例2に係る決済端末決済処理及び認証処理は、実施の形態1に係る決済端末決済処理及び認証処理と同じである。変形例2が実施の形態1と異なる点は、携帯端末200が携帯トークンを取得するタイミングが異なるのみである。なお、実施の形態1では、ユーザ登録処理の直後に携帯トークン生成処理が行われていたが、変形例2では、ユーザ登録処理の後に携帯トークン生成処理を行わなくても良い。変形例2に係る携帯端末200は、決済時に携帯トークンが未取得の場合は、決済処理の直前に携帯トークンを取得する処理を行うからである。
変形例2に係る携帯端末200の携帯端末決済処理は、図25に示すように、実施の形態1に係る携帯端末200の携帯端末決済処理の最初の部分に、ステップS411〜ステップS413を追加した処理フローになっている。この追加された処理について図25を参照して説明する。
まず、携帯端末200の携帯側決済処理部212は、記憶部220に記憶されている携帯トークン情報223を参照し、携帯トークンが未取得か、又は有効期限が切れているか、又は有効回数が0になっているか、否かを判定する(ステップS411)。携帯トークンが取得済みで有効期限が切れておらず、かつ、有効回数も1以上であれば、携帯側決済処理部212は、その携帯トークンが有効であると判定し(ステップS411;Yes)、ステップS401に進む。
携帯トークンが未取得か、又は有効期限が切れているか、又は有効回数が0になっている場合は、携帯側決済処理部212は、携帯トークンが無効であると判定し(ステップS411;No)、携帯トークン依頼部211が、携帯トークン依頼パケットを認証装置100に送信する(ステップS412)。認証装置100は、携帯トークン依頼パケットを受信すると、図19に示す携帯トークン生成処理を行い、生成した携帯トークン、有効期限及び有効回数を、携帯通信部131を介して携帯端末200に送信する。そして、携帯端末200の携帯トークン依頼部211は、認証装置100から送信された携帯トークン、有効期限及び有効回数を受信して、記憶部220に携帯トークン情報223として記憶する(ステップS413)。そして、ステップS401に進む。これ以降の処理は、図23を参照して説明した実施の形態1に係る携帯端末200の携帯端末決済処理と同じである。
変形例2では、上述のような処理を行うことにより、ユーザが、携帯トークンの有効期限及び有効回数に基づいて携帯トークンが有効であることを確認する必要がなくなり、ユーザを携帯トークンの有効性の確認及び携帯トークンの更新という煩雑さから開放することができる。また、事前に携帯トークンを取得し忘れたユーザでも決済処理が可能となり、多くのユーザに対応することができる。
(実施の形態2)
実施の形態1では、決済処理の際に携帯端末200が、決済トークン等の情報を認証装置100に送信する。しかし、例えば地下にある店舗で決済する場合等、携帯電話の電波が届かず、携帯端末200と認証装置100とが通信できない場合も考えられる。また、飛行機内、病院等、意図的に携帯端末200をオフラインモードにしている場合も考えられる。このように携帯端末200と認証装置100とが通信不可能な状況である場合に、常に決済処理ができないのでは不便である。そこで、携帯端末200がオフラインになっていて、認証装置100と通信できない場合でも、例えば取引される代金が少額であるなど、所定の条件を満たすときには決済処理を行うことが可能な実施の形態2について説明する。
実施の形態2に係る認証装置101及び携帯端末201の機能構成は、実施の形態1に係る認証装置100及び携帯端末200の機能構成と同じである。実施の形態2に係る決済端末301は、図26及び図27に示すように、記憶部320に記憶される決済側決済情報324がオフライン情報を含んでいる点が、実施の形態1に係る決済端末300と異なる。オフライン情報とは、携帯端末201が現在オフライン状態であるか否かを示す情報であり、決済端末301は、NFCにより、携帯端末201から取得する。オフライン状態とは、携帯端末201が認証装置101と通信不可能な状態をいう。
また、実施の形態2に係る認証装置101による、ユーザ登録処理、携帯トークン生成処理、決済端末登録処理及び決済トークン生成処理は、実施の形態1に係る認証装置100による各処理と同じである。実施の形態2に係る決済端末決済処理、携帯端末決済処理及び認証処理は、実施の形態1に係る各処理と一部異なるので、図28〜図30を参照して異なる点を中心に説明する。
まず、決済端末301による決済端末決済処理について、図28を参照して説明する。この処理が開始されるタイミングは、図22を参照して説明した実施の形態1に係る決済端末決済処理と同じである。また、ステップS302〜S304が、ステップS320〜S322に置き換わる点と、ステップS306とS307の間にステップS323及びステップS324が挿入される点と、ステップS308とS309の間にステップS325及びステップS326が挿入される点以外は、図22を参照して説明した実施の形態1に係る決済端末決済処理と同じである。そこで、異なる点を中心に説明する。
ステップS320では、決済側決済処理部312は、決済側近距離通信部332を介して、携帯端末201に携帯トークン要求パケットを送信する(ステップS320,A)。携帯トークン要求パケットは、実施の形態1では、携帯端末200に、携帯トークン、携帯端末ID及びユーザ暗証番号の各情報の送信を要求するパケットであるが、実施の形態2では、これらに加えて、携帯端末201にオフライン情報の送信も要求するパケットである。そして、決済側決済処理部312は、携帯端末201から携帯トークン、携帯端末ID及びユーザ暗証番号に加えて、オフライン情報も取得し、取得した携帯トークン、携帯端末ID、ユーザ暗証番号及びオフライン情報を決済側決済情報324(図27)として、記憶部320に記憶する(ステップS321,B)。
そして、ステップS322では、ステップS301及びステップS321で記憶部320に記憶した取引内容及び決済側決済情報324と、記憶部320に記憶されている決済端末情報321とから、決済開始依頼パケットを生成し、決済側通信部331を介して、認証装置101に送信する(ステップS322,C)。実施の形態2の決済開始依頼パケットは、実施の形態1の決済開始依頼パケットに、オフライン情報が追加されたパケットである。すると、認証装置101は、後述する認証処理において、決済端末301から送信された決済開始依頼パケットに含まれる情報に問題が無いかを判定し、判定結果を決済端末301に返信する。
ステップS323では、決済側決済処理部312は、携帯端末201から受信したオフライン情報に基づいて、携帯端末201がオフライン状態か否かを判定する。携帯端末201がオフライン状態なら(ステップS323;Yes)、決済側決済処理部312は、決済依頼パケットを認証装置101に送信する(ステップS324,H)。決済依頼パケットは、上述したように、決済トークン、決済端末ID、店員ID、店員暗証番号、取引内容、携帯端末ID及びユーザ暗証番号を含み、認証装置101に決済処理を依頼するパケットである。ただし、これらの情報のうち決済トークン以外の情報は、決済開始依頼パケットで既に認証装置101に送信済みなので、ここでは、決済トークンのみを送信することにしても良い。携帯端末201がオフライン状態でないなら(ステップS323;No)、決済側決済処理部312は、ステップS307に処理を進める。
ステップS325では、決済側決済処理部312は、携帯端末201から受信したオフライン情報に基づいて、携帯端末201がオフライン状態か否かを判定する。携帯端末201がオフライン状態なら(ステップS325;Yes)、決済側決済処理部312は、認証装置101から受信した支払い処理の結果の情報(すなわち決済処理が正常に完了したか否かを示す情報)を、決済側近距離通信部332を介して、携帯端末201に送信する(ステップS326,I)。携帯端末201がオフライン状態でないなら(ステップS325;No)、決済側決済処理部312は、ステップS309に処理を進める。以降の処理は、図22を参照して説明した、実施の形態1に係る決済端末300の決済端末決済処理と同じである。
次に、携帯端末201による携帯端末決済処理について、図29を参照して説明する。この処理が開始されるタイミングは、図23を参照して説明した実施の形態1に係る携帯端末決済処理と同じである。また、ステップS402がステップS421及びステップS422に置き換わる点と、ステップS404とS407の間にステップS423及びステップS424が挿入される点以外は、図23を参照して説明した実施の形態1に係る携帯端末決済処理と同じである。そこで、異なる点を中心に説明する。
ステップS421では、携帯側決済処理部212は、携帯側通信部232を介して認証装置101と通信可能な状態か否かの情報(オフライン情報)を変数OFFLIに代入する。携帯端末201が認証装置101と通信不可能な状態のときは、変数OFFLIにTRUEを代入し、通信可能な状態のときは、変数OFFLIにFALSEを代入する。そして、ステップS422では、携帯側決済処理部212は、携帯側近距離通信部231を介して、決済端末301に、携帯トークン、携帯端末ID及びユーザ暗証番号に加えて、変数OFFLIの値を送信する(ステップS422,B)。
ステップS423では、携帯側決済処理部212は、変数OFFLIがTRUEであるか否かを判定する。変数OFFLIがFALSEなら(ステップS423;No)、携帯側決済処理部212は、ステップS405に処理を進める。変数OFFLIがTRUEなら(ステップS423;Yes)、携帯側決済処理部212は、認証装置101がカード発行サーバ400に依頼した支払い処理の結果の情報(すなわち決済処理が正常に完了したか否かを示す情報)を、携帯側近距離通信部231を介して、決済端末301から受信する(ステップS424,I)。以降の処理は、図23を参照して説明した、実施の形態1に係る携帯端末200の携帯端末決済処理と同じである。
次に、認証装置101による認証処理について、図30を参照して説明する。この処理が開始されるタイミングは、図24を参照して説明した実施の形態1に係る認証処理と同じである。また、ステップS501及びステップS502が、それぞれステップS521及びステップS522に置き換わる点と、ステップS504とS505の間にステップS523及びステップS524が挿入される点と、ステップS507及びステップS511が、それぞれステップS525及びステップS526に置き換わる点以外は、図24を参照して説明した実施の形態1に係る認証処理と同じである。そこで、異なる点を中心に説明する。
ステップS521では、制御部110は、決済通信部132を介して受信した決済開始依頼パケットに含まれる携帯トークン、携帯端末ID、ユーザ暗証番号、決済端末ID、店員ID、店員暗証番号、取引内容及びオフライン情報の各情報を取得し、記憶部120に記憶する(ステップS521,C)。この実施の形態2の決済開始依頼パケットは、上述したように、実施の形態1の決済開始依頼パケットに、オフライン情報が追加されたパケットである。
そして、ステップS522では、認証部113は、受信した決済開始依頼パケットに含まれる各情報に問題があるか否かを判定する。ここで、認証部113が該各情報に問題があると判定する条件は、実施の形態1の認証処理のステップS502での判定条件以外に、オフライン情報に関係する条件が加わる。オフライン情報に関する条件とは、携帯端末201がオフライン状態のまま、決済処理を行っても良いか否かを判断するための条件である。
もし、オフライン情報がFALSEであるなら(携帯端末201は認証装置101と通信可能)、ステップS522での判定条件は、実施の形態1の認証処理のステップS502での判定条件と同一になる。
もし、オフライン情報がTRUEであるなら(携帯端末201は認証装置101と通信不可能)、ステップS502での判定条件に、携帯端末201がオフライン状態のまま決済処理を行っても良いか否かを判断するための条件が加わる。この「オフライン状態のまま決済処理を行っても良いか否かを判断するための条件」とは、例えば、取引内容に含まれる決済金額が基準決済金額(例えば1000円)以下という条件である。
また、取引内容に含まれる決済金額が基準決済金額(例えば1000円)以下という条件の他に(条件に加えて)、携帯トークンの有効期限が基準有効期間(例えば3日間)以上残っているという条件、携帯トークンの有効回数が基準有効回数(例えば3回)以上残っているという条件、決済端末ID及び店員IDの信用情報が所定の基準(例えば、各IDで示される決済端末及び店員が今までに一度も信用を失う決済処理をしたことがなく、決済金額が基準決済金額以上の正しい取引を基準取引回数(例えば10回)以上している)を満たすという条件、過去の決済処理の回数が基準決済回数(例えば10回)以上であるといった条件等を一部または全部組み合わせて判断するようにしても良い。この場合、信用度を数値化し、この数値化した信用度が基準信用度以上なら、「オフライン状態のまま決済処理を行っても良い」と判定することにしても良い。
例えば、信用度の数値化の方法としては、以下の式(1)のように定義することができる。
信用度=((基準決済金額−決済金額)÷基準決済金額)×(携帯トークンの有効期間の残り日数÷基準有効期間)×(携帯トークンの有効回数÷基準有効回数)…(1)
この式(1)で、基準有効期間を携帯トークン生成処理における最長の有効期間とし、基準有効回数を携帯トークン生成処理における最大の有効回数とすれば、信用度の最大値は1となる。そして、式(1)で算出される信用度が基準信用度(例えば0.5)以上なら、「オフライン状態のまま決済処理を行っても良い」と判定することができる。
なお、決済端末301は取引内容を把握している。したがって、決済端末301が該取引内容に基づいて、(図28のステップS321とステップS322の間で)上述した条件を判定しても良い。この場合は「オフライン状態のまま決済処理を行っても良い」という条件を満たさない場合は、決済端末301は、ステップS322を行う前に、決済できない旨を表示して処理を終了することができる。
上述した条件に基づき、認証部113が、決済開始依頼パケットに含まれる各情報に問題があると判定したら(ステップS522;No)、制御部110は、処理をステップS503に進める。
そして、認証部113が、決済開始依頼パケットに含まれる各情報に問題がないと判定したら(ステップS522;Yes)、制御部110は、処理をステップS504に進める。
ステップS523では、制御部110は、受信した決済開始依頼パケットに含まれるオフライン情報に基づき、携帯端末201がオフライン状態か否かを判定する。携帯端末201がオフライン状態なら(ステップS523;Yes)、制御部110は、決済端末301が送信した決済依頼パケットを、決済通信部132を介して受信する(ステップS524,H)。そして制御部110は、該決済依頼パケットに含まれる決済トークン、決済端末ID、店員ID、店員暗証番号、取引内容、携帯端末ID、ユーザ暗証番号の各情報を取得し、記憶部120に記憶し、処理をステップS506に進める。ただし、該決済依頼パケットに含まれる情報のうち、決済端末ID、店員ID、店員暗証番号、取引内容、携帯端末ID及びユーザ暗証番号の各情報は、ステップS521で記憶部120に記憶済みなので、ここでは決済トークンのみを取得及び記憶することにしても良い。
携帯端末201がオフライン状態でないなら(ステップS523;No)、制御部110は、処理をステップS505に進める。
ステップS525では、制御部110は、決済通信部132を介して、決済端末301に、決済処理を完了できない旨を送信する(ステップS525,G)。ステップS507では、決済端末300だけでなく、携帯端末200にも送信したが、ステップS525では、決済端末301にのみ送信する点がステップS507と異なる。
ステップS526では、制御部110は、決済通信部132を介して、決済端末301に、支払い処理が正常に行われたこと、すなわち決済処理が正常に完了した旨を送信する(ステップS526,G)。ステップS511では、決済端末300だけでなく、携帯端末200にも送信したが、ステップS526では、決済端末301にのみ送信する点がステップS511と異なる。これ以降の処理は図24を参照して説明した、実施の形態1に係る認証処理と同じである。なお、ステップS525及びステップS526については、置き換えずに、ステップS507及びステップS511の処理のままでも良い。ステップS507及びステップS511の処理のままの場合、携帯端末201はオンラインになった時点で、支払い処理が正常に行われたか否かの情報を認証装置101からも受信できることになる。
以上説明した各処理によって、実施の形態2に係る携帯端末201は、認証装置101と通信できないオフライン状態の時にも、決済金額が基準決済金額以下等の所定の条件を満たせば決済処理を行うことができる。
なお、上述のステップS522の判定では、まずオフライン状態か否かによって判定条件を変えている。しかし、逆に、上述した所定の条件を満たすか否かを先に判定することにしても良い。つまり、決済金額が基準決済金額以下等の所定の条件を満たす場合には、オフラインか否かによらずに、決済依頼パケットを決済端末301から受信する(携帯端末201からは決済依頼パケットを受信しなくても良い)ようにしても良い。このような処理をするためには、認証装置101は、図30のステップS504で決済端末301に返信する情報に、所定の条件を満たすか否かの情報を含め、決済端末301は、図28のステップS323の判定を「所定の条件を満たすか」にすれば良い。これにより、所定の条件を満たす場合には、携帯端末201は認証装置101に決済依頼パケットを送信する必要がなくなり、認証装置101は決済端末301からのみ情報を受信すれば良くなる。したがって、携帯端末201と認証装置101の処理負担がそれぞれ軽減される。
(実施の形態3)
実施の形態1では携帯端末200及び決済端末300が近距離通信部を介して通信する。しかし、近距離通信部の有無によらず、携帯端末202及び決済端末302のいずれか、または両方において、QRコード(登録商標)等の二次元バーコードを利用することによって、認証装置102がトークンを用いて決済処理を行うことができる実施の形態3について説明する。
実施の形態3に係る携帯端末202は、図31に示すように、実施の形態1に係る携帯端末200と比較して、入出力部230に、携帯側画像入力部235を備える点が相違する。なお、図31では、携帯端末202は、携帯側近距離通信部231を備えていないが、備えるか否かは任意であり、どちらでも良い。携帯端末202は、決済端末302に送信したいデータを二次元バーコードに変換して、携帯側表示部234に表示する。また、携帯端末202は、決済端末の決済側表示部334に表示された二次元バーコードを復号することによって、決済端末302からデータを受信する。
また、実施の形態3に係る決済端末302は、図32に示すように、実施の形態1に係る決済端末300と比較して、入出力部330に、決済側画像入力部335を備える点が相違する。なお、図32では、決済端末302は、決済側近距離通信部332を備えていないが、備えるか否かは任意であり、どちらでも良い。決済端末302は、携帯端末202に送信したいデータを二次元バーコードに変換して、決済側表示部334に表示する。また、決済端末302は、携帯端末202の携帯側表示部234に表示された二次元バーコードを復号することによって、携帯端末202からデータを受信する。
実施の形態3に係る認証装置102の機能構成は、図2に示す、実施の形態1に係る認証装置100の機能構成と同じである。
実施の形態1における携帯端末200と決済端末300とは、NFCによってデータ通信を行う。このため、ユーザは、このNFCによる通信の際に、携帯端末200を決済端末300が備えるNFCリーダライタにかざす操作を行う。
これに対し、実施の形態3における携帯端末202と決済端末302とは、表示部に表示する二次元バーコードによってデータ通信を行う。このため、携帯端末202が決済端末302からデータを受信する際には、ユーザは、決済端末302の決済側表示部334に、携帯端末202の携帯側画像入力部235を向け、決済側表示部334に表示された二次元バーコードを携帯側画像入力部235から入力できるようにする。また、携帯端末202が決済端末302にデータを送信する際には、ユーザは、携帯端末202の携帯側表示部234を、決済端末302の決済側画像入力部335に向け、携帯側表示部234に表示された二次元バーコードを決済側画像入力部335から入力できるようにする。
ユーザが携帯端末202をどのように決済端末302に向ければ良いかについては、適宜決済端末302の決済側表示部334又は携帯端末202の携帯側表示部234に表示することができる。上述したように、携帯端末202と決済端末302の間の通信にNFCではなく、二次元バーコードを用いる点以外は、実施の形態3は、実施の形態1と同じである。
実施の形態3は、トークンを二次元バーコードで通信することにより、携帯端末202及び決済端末302のいずれか、または両方において二次元バーコードを使用する場合においても、認証装置102がこれら端末のなりすましを防止できる。また、実施の形態3では二次元バーコードの例としてQRコード(登録商標)を挙げたが、これに限られない。データを表示部に表示するバーコード的なものであれば、任意のものを使用することができる。
ただし、二次元バーコードは他人に読み取られて悪用される恐れがあるので、トークンの有効回数を1回のみとしたり、有効期間を数十分程度に短くしたりすることが望ましい。このように有効回数や有効期間を制限することによって、悪用される可能性を減らすことができる。
以上説明した実施の形態は、変形例も含め適宜組み合わせることが可能である。例えば、実施の形態2と実施の形態3とを組み合わせると、携帯端末202がオフライン状態の時に、決済トークンを携帯端末202が受信しなくても良くなる。この場合、決済トークンは携帯端末202を介さずに、決済端末302が認証装置102に送信するからである。つまり、この場合、携帯トークンの二次元バーコードを携帯端末202が携帯側表示部234に表示し、これを決済端末302が決済側画像入力部335によって取得するが、決済端末302は決済トークンの二次元バーコードを決済側表示部334に表示する必要はない。
また、決済端末300は、1つの決済端末IDに複数の店員IDを割り当てて、決済端末情報321として、記憶部320に記憶している。これと同様に、携帯端末200も、1つの携帯端末IDに複数のユーザIDを割り当てて、1つの携帯端末200を複数のユーザで共有することもできる。この場合、決済端末300の決済トークン情報322と同様に、携帯端末200の携帯トークン情報223も、その携帯端末200を利用するユーザ毎に複数の携帯トークンが記憶されることになる。また、決済用携帯アプリ221の起動時にはユーザは、ユーザIDとユーザ暗証番号とを入力することになる。
また、上述した実施の形態を、耐タンパー性を有するICチップを備える携帯端末等に適用しても良い。上述した実施の形態では、携帯トークンと決済トークンとを2つの方向で送信することによって、片方のトークンが盗まれたとしても、なりすましを防止できる仕組みを提供している。しかし、トークンを、耐タンパー性を有するメモリに記憶させることによって、トークン自体が盗まれる可能性を減らすことができ、さらに安全性を高めることができる。例えば、携帯電話の耐タンパー性を有するSIM(Subscriber Identity Module)カードに携帯トークンを記憶させれば、外部機器からこのトークンを読み取ることは困難になる。SIMカードにトークンを記憶させる場合、工場出荷時にトークンを記憶させるだけでなく、携帯電話網を使って後からトークンを配送することも可能である。上述した実施の形態1の変形例2と組み合わせることによって、決済時に、決済端末300の備えるNFCカードリーダライタに携帯端末(耐タンパー性を有するSIMに携帯トークンが記録されているものとする)をかざしている最中に、決済処理に続いて耐タンパー性を有するメモリに記録されている携帯トークンの書き換えまで実施することも可能である。
また、通常のICカードに記憶されている情報を読み書き可能な外部装置(ICカードリーダライタ)を携帯端末と通信で接続しておくことにより、携帯トークン情報223等を携帯端末ではなく、この通常のICカードに記憶するようにしても良い。このようにすうことで、情報が分散され、例えば携帯端末とICカードのどちらか一方を紛失したり、盗難されたりしても、他人による決済は不可能となり、セキュリティを強化することができる。
また、上述した実施の形態では、携帯端末200,201が携帯側近距離通信部231を備えており、決済時には、携帯側近距離通信部231と決済端末300,301の決済側近距離通信部332とが通信して、トークン情報等を交換している。この携帯側近距離通信部231は通常のICカードと同様の仕組みで決済側近距離通信部332と通信するため、通常の(携帯端末に内蔵されていない)ICカードを決済側近距離通信部332にかざして決済を行うことも可能である。このような決済を可能にするためには、外部装置(ICカードリーダライタ)を携帯端末と通信で接続しておく。すると、携帯端末は、該外部装置により、この通常のICカードに情報を書き込んだり、この通常のICカードから情報を取得したりできるようになる。したがって、決済用携帯アプリ221が、携帯側近距離通信部231を介して行っていた通信を、該外部装置を介しての通信に置き換えることによって、上述した実施の形態における各種処理と同等の処理が可能になる。この場合、携帯トークン情報223等を携帯端末ではなく、この通常のICカードに記憶するようにしても良い。
また、上述した実施の形態では、決済端末300,301は、決済側近距離通信部332を備えるが、これに代えて又はこれに加えて、接触型ICカードの情報を読み込んだり、該接触型ICカードに情報を書き込んだりすることができる接触型ICカードリーダライタを備えても良い。携帯端末の方も別途、接触型ICカードに対応した外部装置(決済端末が備える接触型ICカードリーダライタとは別個のICカードリーダライタ)を通信で接続しておけば、上述と同様の仕組みにより、通常の(通信端末に内蔵されていない)接触型ICカードを決済端末の備える接触型ICカードリーダライタにセットすることで決済を行うことが可能になる。
また、上述のいずれの実施の形態においても、各機能は、通常のコンピュータによっても実施することができる。具体的には、上記実施の形態では、制御部110が実行するプログラムが、記憶部120のROMに予め記憶されているものとして説明した。しかし、プログラムを、フレキシブルディスク、CD−ROM(Compact Disc Read Only Memory)、DVD(Digital Versatile Disc)及びMO(Magneto−Optical Disc)等のコンピュータ読み取り可能な記録媒体に格納して配布し、そのプログラムをコンピュータに読み込んでインストールすることにより、上述の各機能を実現することができるコンピュータを構成してもよい。そして、各機能をOS(Operating System)とアプリケーションとの分担、又はOSとアプリケーションとの協同により実現する場合等には、OS以外の部分のみを記録媒体に格納してもよい。
さらに、搬送波に各プログラムを重畳し、通信ネットワークを介して配信することも可能である。例えば、通信ネットワーク上の掲示板(BBS,Bulletin Board System)に当該プログラムを掲示し、ネットワークを介して当該プログラムを配信してもよい。そして、これらのプログラムを起動し、OSの制御下で、他のアプリケーションプログラムと同様に実行することにより、上述の処理を実行できるように構成してもよい。
本発明は、本発明の広義の精神と範囲を逸脱することなく、様々な実施の形態及び変形が可能とされるものである。また、上述した実施の形態は、この発明を説明するためのものであり、本発明の範囲を限定するものではない。すなわち、本発明の範囲は、実施の形態ではなく、特許請求の範囲によって示される。そして、特許請求の範囲内及びそれと同等の発明の意義の範囲内で施される様々な変形が、この発明の範囲内とみなされる。