以下、本発明の実施形態を、図面を参照して説明する。なお、以下の説明において、略又は実質的に同一の機能及び構成要素については、同一符号を付し、必要な場合にのみ説明を行う。
[第1の実施形態]
本実施形態においては、カード決済機能に加えて他の機能を含む多機能カードについて説明する。多機能カードは、生体データを記憶する。
本実施形態において、識別情報はIDと称する。
図1は、本実施形態に係る多機能カードの構成の一例を示すブロック図である。
多機能カード1は、例えば、カード形状のカード本体1Aと、カード本体1Aに備えられる集積回路2とを含む。集積回路2は、例えば、IC(Integrated Circuit)チップでもよい。この集積回路2は、通信部3、プロセッサ4、メモリ5A〜5Cを含む。
多機能カード1は、情報処理装置8又は生体認証装置9と連携して動作する。
情報処理装置8は、例えば、カード・ライタ8Aにより、信号、コマンド、ソフトウェア、プログラム、データ、設定情報、利用者ID、ソフトウェアID、データID、その他の各種情報、などを送信する。
生体認証装置9は、カード・リーダ/ライタ9A、生体センサ9B、照合部9Cを含む。カード・リーダ/ライタ9Aは、多機能カード1から信号、コマンド、データ、情報などを受信し、又は、多機能カード1へ信号、コマンド、データ、情報などを送信する。生体センサ9Bは、多機能カード1の利用者の生体データを取得する。照合部9Cは、生体センサ9Bによって取得された生体データと、多機能カード1からカード・リーダ/ライタ9A経由で受信された生体データとを照合し、生体認証を実行する。そして、照合部9Cは、生体認証結果を、カード・リーダ/ライタ9A経由で、多機能カード1へ送信する。
生体認証装置9は、例えば、店舗に備えられるカード決済端末でもよく、各種の情報処理装置でもよい。情報処理装置としては、例えば、パーソナルコンピュータ、スマートフォンなどの携帯電話、タブレット型コンピュータなどでもよい。
多機能カード1は、例えば、クレジットカードとしての機能、デビッドカードとしての機能、プリペイトカードとしての機能のうちの、少なくとも1つのカード決済機能61を含むとしてもよい。本実施形態では、説明を簡略化するため、カード決済機能61はクレジットカードとしての機能である場合を例として説明する。
本実施形態において、多機能カード1は、複数の利用者のそれぞれに対応する複数の生体データ71〜7Nを含むとする。このように、多機能カード1に複数の生体データ71〜7Nが含まれている場合、例えば、家族、社員などの任意のグループに所属する複数の利用者で多機能カード1を共用することが可能になる。しかしながら、本実施形態において、多機能カード1をクレジットカードとして用いることが許可される利用者は一人であるとする。なお、複数の利用者が多機能カード1をクレジットカードとして利用可能でもよい。
多機能カード1が一人の利用者にのみ専属的に使用されることを前提とする場合、多機能カード1に含まれる生体データは一人の利用者に対応するとしてもよい。多機能カード1に含まれるカード決済機能61ではない他の機能62〜6Mは、例えば、ポイントカード、乗車券(定期券)、社会保障カード、住民カード、印鑑カード、開錠カード、免許証、保険証、パスポート、自動車のキー、マイナンバーカード、ソーシャルセキュリティカード、又は、診察カードなどとしての機能でもよい。本実施形態において、例えば、カード決済機能61では特定の一人の利用者について生体認証が成功した場合に多機能カード1を利用可能とする。ポイントカードなどのような第2の機能では生体認証を行うことなく多機能カード1を利用可能とする。自動車のキー又は開錠カードなどのような第3の機能では多機能カード1に記憶されている複数の生体データのうちのいずれかについて生体認証が成功した場合に多機能カード1を利用可能とする。
多機能カード1は、カード・ライタ8A又はカード・リーダ/ライタ9Aなどの装置から発せられる電波(電磁界)を通信部3のアンテナ回路3Aで受け、この受けた電波を電気に変換し、集積回路2の電力として用いる。しかしながら、多機能カード1は、電源を備えるとしてもよい。
通信部3は、多機能カード1の設定時に、情報処理装置8に備えられるカード・ライタ8Aから、接触又は非接触で、又は、有線又は無線で、信号、コマンド、ソフトウェア、プログラム、データ、設定情報、利用者ID、ソフトウェアID、データID、その他の各種情報、などを受信する。
通信部3は、多機能カード1の利用時に、カード・リーダ/ライタ9Aと、接触又は非接触で、又は、有線又は無線で、信号、コマンド、データ、情報などを送信、又は、受信する。
プロセッサ4は、通信部3を制御し、メモリ5A〜5Cをアクセスする。より具体的には、プロセッサ4は、メモリ5Aに記憶されている制御ソフトウェア10を実行する。また、プロセッサ4は、メモリ5Bに記憶されている各種機能を実現するためのソフトウェア111〜11Kを実行可能である。プロセッサ4は、メモリ5Cを作業メモリとして利用可能である。プロセッサ4は、メモリ5Aに記憶されている制御ソフトウェア10を実行し、制御ソフトウェア10に基づく制御にしたがって、メモリ5Bに記憶されている複数のソフトウェア111〜11Kのそれぞれを実行可能である。また、プロセッサ4は、メモリ5Bに新規のソフトウェアが追加された場合に、新規のソフトウェアを実行可能である。例えば、制御ソフトウェア10はオペレーティング・システム(OS)としてもよい。例えば、ソフトウェア111〜11Kはアプリケーションとしてもよい。
例えば、メモリ5A,5Bは、不揮発性メモリである。より具体的には、例えば、メモリ5Aはリード・オンリー・メモリ(ROM)としてもよく、メモリ5BはEPROM(Erasable Programmable Read-Only Memory)又はEEPROM(Electrically Erasable Programmable Read-Only Memory)としてもよい。
メモリ5Bは、ソフトウェアIDと関連付けられているソフトウェア111〜11K、利用者IDと関連付けられている生体データ71〜7N、設定情報12、履歴情報13を記憶する。
ソフトウェア111〜11Kは、それぞれ各種の機能を実現するためのプログラムと当該プログラムに関する情報を含む。ソフトウェア111〜11Kを実行可能とすることにより、多機能カード1は、カード決済機能61に加えて他の機能62〜6Mを実現可能である。例えば、ソフトウェア111はクレジットカードとしてのカード決済機能61を実現し、ソフトウェア112〜11Kはカード決済機能61ではない他の機能62〜6Mを実現可能とする。
生体データ71〜7Nは、例えば指紋データ、静脈データ、動脈データ、掌形データ、網膜データ、虹彩データ、顔データ、血管データ、音声データ、声紋データ、又は、耳型データでもよい。
設定情報12は、多機能カード1の制御ソフトウェア10及びソフトウェア111〜11Kの動作で必要になる各種の情報を含む。例えば、設定情報12は、多機能カード1のメモリ5Bに記憶されたソフトウェア111〜11Kを示すソフトウェアIDと、生体認証候補(対象)の利用者を示す利用者IDとを関連付けて管理する情報である。これにより、例えば、多機能カード1は、一人の利用者に対してカード決済機能61を許可し、例えば、ポイントカード機能を誰でも利用可能(生体認証不要)とし、例えば、複数の利用者に対して自動車のキーとしての機能を許可するなど、多機能カード1の機能に応じてセキュリティのレベルを設定可能である。
なお、多機能カード1が共用されることなく、特定の一人の利用者のみに利用されることを想定している場合、設定情報12は、ソフトウェアIDと、生体認証が必要か否かを示す情報とを関連付けて管理するとしてもよい。
履歴情報13は、例えば、多機能カード1が利用されるごとに、時間情報、利用対象のソフトウェアを示すソフトウェアID、生体認証が成功したか否かを示す情報、生体認証が成功した場合の認証された利用者を示す利用者ID、を関連付けて管理する情報である。
なお、多機能カード1が共用されることなく、特定の一人の利用者のみに利用されることを想定している場合、履歴情報13に含まれる情報のうち、利用者IDを省略してもよい。
各ソフトウェア111〜11Kは、制御ソフトウェア10による制御にしたがって実行される。
ソフトウェア111は、例えば、プロセッサ4によって実行されることにより、カード側におけるカード決済機能61を実現する。
ソフトウェア112は、例えば、プロセッサ4によって実行されることにより、カード側におけるポイントカード機能62を実現する。
ソフトウェア113は、例えば、プロセッサ4によって実行されることにより、カード側における自動車キーの機能63を実現する。
制御部41は、プロセッサ4が制御ソフトウェア10を実行することにより実現される。
制御部41は、多機能カード1の設定時に、カード・ライタ8Aから通信部3経由でソフトウェア111〜11K、ソフトウェアID、生体認証候補(対象)の利用者を示す利用者ID、生体データ71〜7N、生体データ71〜7Nに対応する利用者を示す利用者IDを受信する。そして、制御部41は、受信されたソフトウェアとソフトウェアIDとを関連付けてメモリ5Bに記憶する。制御部41は、受信されたソフトウェアIDと生体認証候補の利用者を示す利用者IDとを関連付けて設定情報12を更新する。制御部41は、受信された生体データ71〜7Nと対応する利用者IDとを関連付けてメモリ5Bに記憶する。
制御ソフトウェア10は、例えば、OSに含まれるとしてもよい。より具体的な例として、制御ソフトウェア10は、マルチアプリケーションOSに含まれるとしてもよく、又は、仮想マシン(Virtual Machine)と呼ばれる汎用OSに含まれるとしてもよい。しかしながら、制御ソフトウェア10は、OSに含まれるのではなく、OSの制御にしたがって動作するソフトウェアでもよい。
制御部41は、通信部3経由で受けたコマンドに基づいて、複数のソフトウェア111〜11Kのうちのどのソフトウェアを実行するか決定する。
制御部41は、設定情報12に基づいて、決定されたソフトウェアが生体認証を必要とするか否か判断する。
制御部41は、決定されたソフトウェアが生体認証を必要としない場合に、決定されたソフトウェアを実行する。
制御部41は、決定されたソフトウェアが生体認証を必要とする場合に、認証成功を示す認証結果を受けるまで、又は、設定情報12において、決定されたソフトウェアに対して生体認証候補として設定されている全ての生体データに対する生体認証が終了するまで、順次、生体データを通信部3経由で、生体認証装置9へ送信する。そして、制御部41は、生体認証装置9に備えられるカード・リーダ/ライタ9Aから、通信部3経由で、認証結果を受信する。
制御部41は、受信された認証結果が認証成功を示す場合に、決定されたソフトウェアを実行し、時間情報と、決定されたソフトウェアを示すソフトウェアIDと生体認証が成功であったことを示す認証結果と、生体認証の成功した利用者を示す利用者IDとを関連付けてメモリ5Bの履歴情報13を更新する。
制御部41は、設定情報12において、決定されたソフトウェアに対して生体認証候補として設定されている全ての生体データに対する生体認証が終了し、当該全ての生体認証候補の生体データに対する受信された認証結果が認証失敗を示す場合に、時間情報と、決定されたソフトウェアを示すソフトウェアIDと、生体認証が失敗であったことを示す認証結果とを関連付けてメモリ5Bの履歴情報13を更新する。
制御部41は、設定情報12において、決定されたソフトウェアに対して生体認証候補として設定されている全ての生体データに対する生体認証が終了し、受信された認証結果の全てが認証失敗を示す場合に、多機能カード1のメモリ5Bの各種データを読み出し不可とし、これにより多機能カード1を保護してもよい。
制御部41は、設定情報12に基づいて、生体認証が失敗であると判断されたソフトウェアに基づく用途において、多機能カード1を使用可能状態から使用禁止状態へ変更してもよい。または、制御部41は、設定情報12に基づいて、生体認証が失敗であると判断されたソフトウェアが1つ以上存在する場合は、多機能カード1の全ての機能について使用可能状態から使用禁止状態へ変更してもよい。
図2は、本実施形態に係る多機能カード1に備えられる複数の機能を例示するブロック図である。
多機能カード1は、上述のように、カード決済機能61、ポイントカード機能62、自動車キーの機能63、免許証の機能64などを実現するためのソフトウェア111〜11Kを記憶する。ソフトウェア111〜11Kは、対応する機能を実現するために必要とされるデータを含む。
また、多機能カード1は、生体データ71を記憶する。生体データ71は、複数の機能で共有されてもよい。
例えば、生体センサ9Bを含むカード決済端末などのような生体認証装置9は、多機能カード1から生体データ71を受信し、生体データ71と生体センサ9Bによって取得された生体データとを照合し、認証結果を多機能カード1に送信する。
多機能カード1は、生体認証に成功した場合に、機能に対応するデータを生体認証装置9へ送信する。
図3は、本実施形態に係る設定情報12の一例を示すデータ構造図である。
設定情報12は、多機能カード1にインストールされたソフトウェアを示すソフトウェアIDと、生体認証が成功の場合に当該ソフトウェアの利用を許可する利用者を示す利用者IDとを関連付ける。例えば、設定情報12において、ソフトウェアIDに対して利用者IDが関連付けられていない場合、当該ソフトウェアIDで示されるソフトウェアは、誰でも利用可能であり、生体認証が不要であることを示す。
図4は、本実施形態に係る履歴情報13の一例を示すデータ構造図である。
履歴情報13は、コマンドを受信した時間情報と、コマンドに対応するソフトウェアを示すソフトウェアIDと、生体認証結果と、生体認証が成功した場合の認証された利用者を示す利用者IDと、を関連付けている。
図5は、本実施形態に係る多機能カード1の設定処理の一例を示すフローチャートである。
ステップS1において、通信部3は、情報処理装置8のカード・リーダ8Aから、ソフトウェア、ソフトウェアID、生体認証候補の利用者を示す利用者ID、生体認証候補の利用者の生体データを受信する。このステップS1で受信されるソフトウェア、情報、データは、複数回に分けて受信されてもよい。
ステップS2において、制御部41は、受信されたソフトウェアとソフトウェアIDとを関連付けてメモリ5Bに記憶する。
ステップS3において、制御部41は、受信されたソフトウェアIDと生体認証候補の利用者を示す利用者IDとを関連付けて設定情報12を更新する。
ステップS4において、制御部41は、受信された生体データと利用者IDとを関連付けてメモリ5Bに記憶する。
なお、上記のステップS2からステップS4までに関しては、順序を自由に入れ替えてもよく、同時に実行されてもよい。
図6は、本実施形態に係る多機能カード1の利用処理の一例を示すフローチャートである。
ステップT1において、通信部3は、生体認証装置9のカード・リーダ/ライタ9Aから、コマンドを受信する。
ステップT2において、制御部41は、生体認証が必要か否か判断する。具体的には、制御部41は、設定情報41において、コマンドの示すソフトウェアIDが利用者IDと関係付けられているか否か判断する。
生体認証が不要な場合、処理はステップT8Aに移る。
生体認証が必要な場合、ステップT3において、制御部41は、生体認証候補の生体データをメモリ5Bから読み出す。具体的には、制御部41は、設定情報12において、コマンドの示すソフトウェアIDと関連付けられている利用者IDを選択し、当該選択された利用者IDと関連付けられている生体データをメモリ5Bから読み出す。
ステップT4において、通信部3は、読み出された生体データを、生体認証装置9へ送信する。
ステップT5において、通信部3は、生体認証装置9から生体認証結果を受信する。
ステップT6において、制御部41は、生体認証結果が成功か又は失敗かを判断する。
生体認証結果が成功の場合、処理はステップT8Bに移る。
生体認証結果が失敗の場合、ステップT7において、制御部41は、全ての生体認証候補の生体データに対して生体認証が実行されたか否か判断する。具体的には、制御部41は、設定情報12において、コマンドの示すソフトウェアIDと関連付けられている利用者IDを生体認証候補の利用者IDとし、生体認証候補の利用者IDと関連付けられている生体データを生体認証候補の生体データとし、全ての生体認証候補の生体データに対して生体認証が実行されたか否か判断する。
全ての生体認証候補の生体データに対して生体認証が実行されたが、生体認証結果が成功ではない場合、処理はステップT8Cに移る。
全ての生体認証候補の生体データに対して生体認証が実行されていない場合、処理は、ステップT3に戻り、次の生体認証候補の生体データに対して同様の処理を実行する。
上記ステップT2において生体認証が不要と判断された場合、ステップT8Aにおいて、制御部41は、履歴情報13に、時間情報とコマンドの示すソフトウェアIDとを関連付けて記憶する。
そして、ステップT9Aにおいて、制御部41は、コマンドの示すソフトウェアIDに関連付けられているソフトウェアを実行し、外部の装置で使用されるデータを通信部3経由で送信する。これにより、生体認証の必要ない用途に対して、多機能カード1を利用することができる。
上記ステップT6において生体認証が成功の場合、ステップT8Bにおいて、制御部41は、履歴情報13に、時間情報、ソフトウェアID、生体認証が成功であることを示す認証結果、認証された利用者IDを関連付けて記憶する。
そして、ステップT9Bにおいて、制御部41は、上記ステップT9Aと同様に、コマンドの示すソフトウェアIDに関連付けられているソフトウェアを実行し、外部の装置で使用されるデータを通信部3経由で送信する。例えば、コマンドが決済コマンドの場合、制御部41は、カード決済機能61を実行し、カード決済端末のカード・リーダ/ライタ9Aへ、生体認証の成功した利用者を示す利用者IDと、当該利用者IDに対応するカード番号、有効期限、氏名、住所、電話番号などを含む決済のためのデータを送信する。
上記ステップT7において全ての生体認証候補の生体データに対して生体認証が実行されたが生体認証結果が成功ではない場合、ステップT8Cにおいて、制御部41は、履歴情報13に、時間情報、ソフトウェアID、生体認証が失敗であることを示す認証結果を関連付けて記憶する。そして、ステップT8Cの後、処理は終了する。
以上説明した本実施形態においては、生体データ71〜7Nを含む多機能カード1を、様々な目的、機能、用途、又は、サービスで利用することができる。生体データ71〜7Nは、カード決済機能61のみではなく、他の機能でも生体認証のために利用可能である。
本実施形態においては、多機能カード1の目的、機能、用途、又は、サービスに応じて、生体認証を行うか否かを設定することができる。
本実施形態においては、設定情報12を用いることで、少なくとも一人の特定の利用者に対して生体認証が成功した場合に、例えば多機能カード1から生体認証装置9へデータの送信などの各種のサービスを提供することができる。
本実施形態においては、履歴情報13に基づいて、多機能カード1の利用履歴を管理することができ、不正な使用を抑制することができる。
本実施形態においては、複数のカードの機能を1枚の多機能カード1に集約することができ、利用者のカードの管理負担を軽減することができ、利用者の利便性を増すことができ、利用者の不正使用を防止することができる。
本実施形態においては、例えば多機能カード1をカード決済に用いる場合には1人の利用者のみが利用可能とし、例えば多機能カード1を自動車のキーとして用いる場合には複数の利用者で共用可能とすることができる。
本実施形態において、例えば、パスワードに代えて生体データを用いることで、利用者はパスワードの管理及び変更の負担を解消することができる。
本実施形態において、生体認証が失敗した場合に、生体認証が失敗であると判断された機能または多機能カード1の全ての機能についてカードを使用禁止状態とすることで、多機能カード1のセキュリティを高めることができる。
[第2の実施形態]
以下、第2の実施形態に係るカード決済端末の実施形態を、図面を用いて説明する。
本実施形態においては、生体認証に用いられる生体データを記憶しているカードがクレジットカードの場合を例として説明する。しかしながら、生体データを記憶しているカードとしては、決済に用いられるものであれば、例えばデビッドカード、電子マネーカードなど各種のカードであってもよい。例えば、生体認証に用いられる生体データを記憶しているカードは、上記第1の実施形態に係る多機能カード1でもよい。
図7は、本実施形態に係るカード決済端末と周辺機器の構成の一例を示すブロック図である。
本実施形態において、利用者UのカードCは、カード形状のカード本体C1と、カード本体C1に備えられる集積回路Tとを含む。集積回路Tは、例えば、カードIDの一例であるカード番号201、有効期限202、利用者IDの一例である氏名203、生体認証結果の一例である認証失敗フラグ204、生体データ205などを含むカードデータDを記憶する。カードデータDは、例えばカード発行時に既にカードCに記憶されている。生体データ205としては、例えば、上記の生体データ71〜7Nと同様に、指紋パターン、虹彩パターン、静脈パターンなどが用いられ、生体認証において決済時に取得された利用者Uの生体データ206と照合される。また、1枚のカードを複数の契約者で利用することができるようにするため、生体データ205及び氏名203には複数の契約者のデータを含むことができる。利用者の識別方法については、後述する。
カード決済端末200は、サイン入力装置207、生体センサ9Bの一例である生体データ取得装置208、カード端末209を備える。カード端末209は、カード・リーダ/ライタ9Aの一例であるカードデータ読み書き装置210、決済受付装置211、照合部9Cの一例である処理装置212、通信装置213を備える。
カードデータ読み書き装置210は、利用者UのカードCに記憶されているカードデータDを読み取り、カードデータDを処理装置212に送る。また、カードデータ読み書き装置210は、処理装置212の指示により、カードCに記憶されているカードデータDを書き換えることができる。
さらに、カードデータ読み書き装置210は、カードCに備えられている磁気記憶媒体T1に記憶されているカードデータD1を読み出し可能である。例えば、カードデータD1は、利用者IDとカードIDとのうちの少なくとも一方の情報を含む。
決済受付装置211は、例えば加盟店の店員の操作に基づいて支払金額、支払方法(例えば一括払い、分割払い)などを受け付け、支払金額、支払方法を処理装置212に送る。
サイン入力装置207は、利用者Uのカード決済時のサインデータ214を取得し、サインデータ214をカード端末209の処理装置212に送る。なお、サイン入力装置207は、利用者Uが手書きでサインを入力でき、それを電子データとして処理装置212へ送ることができるものであればよい。例えば、サイン入力装置207はタッチペンによる電子サインが可能な装置であってもよいし、利用者Uによる紙媒体に対するサインを電子化する例えばスキャナまたはカメラなどのような装置であってもよい。
さらにサイン入力装置207は、カードC裏面のサイン領域Aに記載されている利用者UのサインD3を、電子データ(カードC上のサインデータ227)として取得可能である。サインD3の読み取り方法は、例えば利用者Uがサイン入力装置207に備えられているスキャナまたはカメラを用いてカードCをスキャンするとしてもよい。
サイン入力装置207は、カードC上のサインデータ227を処理装置212へ送る。
生体データ取得装置208は、利用者Uのカード決済時の生体データ206を電子データとして取得し、生体データ206をカード端末209の処理装置212に送る。
なお、本実施形態において、サイン入力装置207と生体データ取得装置208は別々の装置である必要はなく、一つの装置として実現されてもよい。この場合、処理装置212に送るデータは、生体データであるかサインデータであるかが区別されていなくてもよい。
処理装置212は、生体データ取得装置208によって決済時の利用者Uの生体データ206が読み取られたか否か、さらにサイン入力装置207によって利用者Uのサインデータ214が読み取られたか否かを自動で判別する。
処理装置212は、決済データ215を作成し、決済データ215を通信装置213へ送る。決済データ215については、図8乃至図10を用いて後述する。
なお、処理装置212はカード端末209における一連のカード認証処理を制御する。処理装置212によって実行される各種認証処理の詳細については、図12を用いて後述する。
処理装置212は、生体データ取得装置208によって生体データ206が取得されない場合に、カードCの磁気記憶媒体T1から読み取られた利用者IDとカードIDとのうちの少なくとも一方の情報と、サインデータ214と、支払金額とを関連付けてデータベースDBに格納してもよい。
通信装置213は、ネットワーク経由で、アクワイアラのサーバ216に決済データ215を送信する。その後、決済データ215は、例えば、アクワイアラのサーバ216からカードブランドのサーバ217へ送信され、カードブランドのサーバ217からイシュアのサーバ218へ送信される。例えば、通信装置213は、決済データ215を、イシュアのサーバを宛先として送信する。なお、通信装置213は、アクワイアラのサーバ216とカードブランドのサーバ217とのうちの一方を経由して、イシュアのサーバ218へ決済データ215を送信してもよい。
また、通信装置213は、イシュアのサーバ218から、カードブランドのサーバ217、アクワイアラ216を経由して、与信結果データ219を受信し、受信した与信結果データ219を処理装置212へ送る。例えば、イシュアのサーバ218は、与信結果データ219を、カード決済端末200を宛先として送信する。なお、イシュアのサーバ218は、アクワイアラのサーバ216とカードブランドのサーバ217とのうちの一方を経由して、カード決済端末200へ与信結果データ219を送信してもよい。処理装置212は、与信結果データ219に基づいて、決済完了または決済不成立を判定する。与信結果データ219の詳細については、図11を用いて後述する。
データベースDBは、例えば加盟店に設置される端末に含まれており、加盟店が顧客との過去の取引の際に使用したデータを記憶する。このデータは、例えば顧客との取引毎に、取引ID220を付して記憶され、顧客ID221、品物名と金額となどを含む取引データ222、品物の発送先と日時などを含む発送データ223、カードに関する情報と支払金額などを含む決済・認証データ224、などを含む。決済・認証データ224は、カード情報225、支払金額226、生体認証の場合であれば被認証者(認証対象の利用者)ID228を含む。
カード情報225は、カードデータ読み書き装置210によって取得されたカードデータDに含まれる各データのうち、加盟店側で必要な情報が記憶される。
なお、決済・認証データ224は、被認証者ID228を除く部分については、カード端末209からサーバ216へ送信される決済データ215と同等の内容を含むが、両者は一致しなくともよい。また、取引データ222、発送データ223、決済・認証データ224は、上記で説明した情報と異なる他の情報を含んでいてもよい。
データベースDBは、カード端末209と接続されており、例えばカード端末209の処理装置212に設けられたデータベースインタフェースを介してカード端末209との間でデータの送受信を行うことができる。
図8は、本実施形態に係る決済データ215の第1の例を示すデータ構造図である。決済データ215aは、カード端末209とサーバ216との間で通信が行われる際に作成される。決済データ215aは、図8の決済データ215aを基本とするが、状況に応じて図9の決済データ215b、図10の決済データ215cのいずれかとなる場合もある。
決済データ215aは、カード番号201、有効期限202、氏名203、支払金額226、支払方法229、加盟店情報230などを含むが、他の情報を含むとしてもよい。
加盟店情報230は、加盟店の名称、住所、又は、業態など、加盟店を特定する情報を含む。
図9は、本実施形態に係る決済データ215の第2の例を示すデータ構造図である。
利用者Uの生体データ206の取得は完了したがカードデータDに生体データ205が含まれていない場合は、サーバ216〜218のいずれかで生体認証を実行するために、カード端末209は、決済データ215aに生体データ206を加えた決済データ215bを作成し、決済データ5bをサーバ216へ送信する。
サーバ216又はサーバ217が決済データ215bを受信すると、サーバ216又はサーバ217は、生体データ206と照合するための生体データを記憶しているか否か判断する。サーバ216又はサーバ217が生体データ206と照合するための生体データを記憶している場合、サーバ216又はサーバ217は、決済データ215bに含まれる生体データ215bと記憶している生体データとに基づいて照合を行う。サーバ216又はサーバ217が生体データ206と照合するための生体データを記憶していない場合、サーバ216又はサーバ217は、決済データ215bをサーバ217又はサーバ218へ送信する。
図10は、本実施形態に係る決済データ215の第3の例を示すデータ構造図である。
カード端末209、サーバ216、又は、サーバ217は、カードCに記憶されている生体データ205、サーバ216に記憶されている生体データ、又は、サーバ217に記憶されている生体データと、生体データ206とを照合し、生体認証成功の場合に、上記図9の決済データ215bの生体データ206に代えて、認証成功通知231を含む決済データ215cを作成する。そして、カード端末209、サーバ216、又は、サーバ217は、決済データ215cを、サーバ216、サーバ217、又は、サーバ218に送信する。
認証成功通知231は、生体認証を実行した者を特定する認証実行者ID232と、生体認証された者を特定する被認証者ID233を含む。
処理装置212で生体認証が成功した場合、認証実行者ID232は、例えば、カード決済端末200を利用する加盟店のID、カード決済端末200のID、加盟店の口座情報などとしてもよい。
サーバ216又はサーバ217で生体認証が成功した場合、認証実行者ID232は、例えば、サーバ216を管理・運営するアクワイアラID又はサーバ217を管理・運営するカードブランドIDでもよい。
被認証者ID233は、認証された人物を特定可能であれば、例えば固有のIDであってもよいし、氏名でもよい。
なお、カード決済端末200で、生体データ206と生体データ205との照合による
生体認証が失敗した場合は、この時点で決済不成立となり、サーバ216、サーバ217、又は、サーバ218との通信が不要であり、決済データ215は作成されなくてもよい。
図11は、本実施形態に係る与信結果データ219の一例を示す図である。
与信結果データ219は、与信結果234、生体認証実行フラグ235を含む。与信結果データ219は、生体認証が実行され、生体認証が成功した場合に、さらに被認証者ID236を含む。
与信結果234は、与信結果がOKであるかNGであるかを示し、例えば1ビットのフラグで表現されていてもよい。
生体認証実行フラグ235は、生体認証が行われたか否かを示し、例えば1ビットのフラグで表現されてもよい。
被認証者ID236は、与信結果データ219がどの被認証者に対応する情報であるかを示す。また、被認証者ID236により、与信結果データ219がどの決済データ215に対応するか関連付けることが可能である。
図12は、カード決済端末200の処理を例示するフローチャートである。
ステップS1201において、加盟店でカード決済端末200の電源がONされ、生体データ取得装置208、サイン入力装置207及びカード端末209が入力待ちとなる。
ステップS1202において、カード端末209は、決済受付装置211を用いた決済受付処理を実行する。例えば、決済受付処理では、商品又はサービスの支払金額と支払方法とが受け付けられる。
ステップS1203において、カード端末209は、カードデータ読み書き装置210を用い、カードデータ読み取り処理を実行する。例えば、カードデータ読み取り処理では、カードデータD用のデータ記憶領域が初期化され、カードデータDの読み取りが実行される。カードデータDが読み取られた場合には、カードデータDがカードデータD用のデータ記憶領域に記憶される。例えば3回などの所定の回数、カードデータDの読み取りが失敗した場合には、エラーが表示される。
ステップS1204において、カード端末209は、サイン入力装置207または生体データ取得装置208を用いてサインデータ214または生体データ206の取得処理を実行する。例えば、サインデータ214または生体データ206用に確保されているデータ記憶領域が初期化され、データ記憶領域に取得したデータが記憶される。
ステップS1205において、カード端末209は、取得データがサインデータであるか生体データであるかの自動判別処理を行う。判別処理は、例えば各データの特徴またはパターンを認識することにより行われてもよい。例えば、指紋データであれば、取得データは画像データであり、画像上に層状の線が多数存在する特徴を有する。例えば、指静脈データであれば、時間と振幅に関する2次元データが取得され、振幅は一定間隔で拍動を示す特徴を有する。また、例えばサインデータであれば、取得データは画像データであり、線状の文字または図形で表現される特徴を有する。
上記のステップS1205において、取得データがサインデータであると判定された場合、ステップS1206において、カード端末209は、サインデータ照合処理を行う。サインデータ照合処理の詳細については、図13を用いて後述する。
上記のステップS1205において、取得データが生体データであると判定された場合、ステップS1207においてカード端末209は生体認証処理を行う。
ステップS1208において、カード端末209は、決済データ215の作成、サーバ216への決済データ215の送信、およびサーバ216からの与信結果データ219の受信を行う。与信結果データ219により、決済不成立と判断された場合は、取引の中止が実行される。
なお、上記のステップS1207にて生体認証を行う際、カード端末209は、取得済のカードデータDに生体データ205が含まれているかどうかをチェックする。
カードデータDに生体データ205が含まれていない場合には、カード端末209での生体認証を行うことができない。この場合は、上記のステップS1208においてサーバ216に生体データ取得装置208が取得した生体データ206を含んだ決済データ215bを送付した後、上述のようにサーバ216乃至サーバ218のいずれかのサーバにおいて生体認証が実行される。
カードデータDに生体データ205が含まれている場合、カード端末209は、生体認証を実行する。カード端末209における生体認証が失敗となった場合は、この時点で決済不成立となる。従って、この場合は上記のステップS1208において決済データ215の作成、サーバ216に対する決済データ215の送信、およびサーバ216からの与信結果データ219の受信は行われなくてもよい。
カードデータDに記憶されている生体データ205が複数人数分である場合には、カード端末209またはサーバ216乃至サーバ218のいずれかのサーバは、生体データ取得装置208が取得した生体データ206と照合完了するか、又は、複数人数分の生体データの全てに対して照合が実行されるまで、複数人数分の生体データのうちの照合候補の生体データについて順番に照合を行う。照合完了した場合には、カード端末209またはサーバ216乃至サーバ218のいずれかのサーバは、照合被認証者IDを得る。
ステップ1209において、カード端末209は、取引ID220、取引データ222、発送データ223、決済・認証データ224をデータベースDBへ登録する。
上記のステップS1207またはステップS1208において生体認証が行われた場合は、カード端末209は、カード端末209またはサーバ216乃至サーバ218のいずれかのサーバで生体認証が成功となった場合に、処理装置212を経由してデータベースDBに被認証者IDを格納する。
なお、サーバ216乃至サーバ218のいずれかのサーバにおける生体認証結果は、処理装置212が与信結果データ219に基づいて判定することができる。処理装置212は、生体認証が実行済であるか否かを、与信結果データ219に含まれる生体認証実行フラグ235により判定する。処理装置212は、生体認証が実行済であると判定した場合は、被認証者IDの有無を確認する。被認証者IDがない場合は、生体認証が失敗したと判定し、被認証者IDがある場合は、生体認証が成功したと判定する。
ステップ1210において、カード端末209は、生体認証またはサインデータ照合が失敗した場合、その旨を通知する。例えば、カード端末209は、カード決済端末200が備えるディスプレイまたはスピーカより、生体認証失敗またはサインデータ照合失敗を表示又は音声出力してもよい。
また、カード端末209は、通信手段を用いて利用者Uへ通知してもよい。例えば予めデータベースDBに利用者Uのメールアドレスを登録しておき、処理装置23は、データベースDBにおけるメールアドレスを参照し、通信装置213を用いて利用者U宛のメールを送信してもよい。
サーバ216乃至サーバ218のいずれかのサーバで生体認証が行われ、生体認証が失敗となった場合は、利用者Uへの通知は、生体認証が失敗となったサーバにより行われてもよい。
また、カード端末209は、生体認証またはサインデータ照合が成功した場合においても、成功の旨を表示又は音声出力するとしてもよい。
ステップ1211において、カード端末209は、生体認証が失敗であると判定した場合、処理装置212によりカードデータ読み書き装置210に対して認証失敗フラグ204の書き込み指示を送信する。カードデータ読み書き装置210は、カードCに対して認証失敗フラグ204を書き込む。
生体認証に失敗した場合、第三者がカードを不正利用している可能性が高い。そのため、本実施形態においてカード端末209は、例えば認証失敗フラグ204を書き込まれたカードCは次回カード端末209で読み込まれる際に使用不可と判定することで、カードのセキュリティを高めることができる。
ステップS1212において、カード端末209は、継続使用の場合にステップS1202に戻る。継続使用されない場合、ステップS1213において、カード決済端末200は、電源をOFFする。
図13は、サインデータ照合処理を例示するフローチャートである。
ステップS1301において、サイン入力装置207は、カードCのサインD3を読み取り、読み取りに成功した場合、カードC上のサインデータ227として保持する。
サイン入力装置207はサインD3の読み取りに失敗した場合(ステップS1302)、ステップ1301に戻り再度カードC上のサインデータ227の読み取りを行う。規定回数以上サインD3の読み取りに失敗した場合は(ステップS1303)、サインデータの照合失敗となり、処理を終了するとしてもよい。サインD3の読み取り失敗および成功の判定は、例えばカードC上のサイン領域Aを画像処理等により自動判別し、サイン領域Aが正常に取得できているか否かを判定基準としてもよい。なお、カードC上のサインデータ227の読み取り失敗および成功の判定は、処理装置212が行うとしてもよい。
ステップS1302において、カードC上のサインデータ227の読み取りが成功した場合、処理装置212は、カードC上のサインデータ227と、ユーザUが入力したサインデータ214を照合する(ステップS1304)。
カードC上のサインデータ227と、ユーザUが入力したサインデータ214とが類似していると判定され、照合成功の場合は、本人確認が行われたことになり、照合処理は完了する。カードC上のサインデータ227と、ユーザUが入力したサインデータ214とが非類似と判定された場合、またはステップS1302においてカードC上のサインデータ227が取得できなかった場合は、照合失敗となり、上述のステップS1210において、利用者への通知が行われる。
なお、サインデータの照合処理は、例えばパターンマッチング等の画像照合技術により自動的に行われることが望ましいが、カード決済端末200を操作している店員などの目視による確認などのように、その他の方法により行われてもよい。
複数人の生体データを記憶したカード、すなわち複数人が使用可能なカードでは、複数人がサイン入力を使用するとサインデータは毎回変化することとなる。このため、複数人のうちの特定の一人のみが、サイン入力を許可されるとしてもよい。また、複数人が使用可能なカードでは、サイン入力は使用不可としてもよい。例えば、複数人が使用可能なカードでは、上記図12のステップS1205において取得データがサインデータであると判定された時点で、取引を停止してもよく、カード決済端末200を操作している店員へ取引不可を通知してもよく、利用者Uへの通知または警告を行ってもよい。
なお、サインデータを生体データと同様にカード内に記憶しておくことが可能であれば、サインデータ入力の場合でも、後述する生体データ認証の場合と同様に認証を行うことができ、複数人によって使用可能なカードであってもサイン照合を適用可能である。
本実施形態において、カード決済端末200は、カード決済サービスの加盟店に設置される場合を例として説明したが、カード決済端末200は利用者Uの生体データ206もしくはサインデータ214、カードCのカードデータDを取得可能な他の装置でもよい。例えば、カード決済端末200は、生体データ取得機能、カードデータ読み取り機能、決済受付機能、生体認証機能、通信機能を備えた情報処理装置でもよい。情報処理装置の各機能は、ソフトウェアで実現されてもよく、ハードウェアで実現されてもよく、ソフトウェアとハードウェアとの協働により実現されてもよい。情報処理装置の各機能を実現するために必要なハードウェアは、情報処理装置に内蔵されていてもよく、情報処理装置に外付けされてもよい。本実施形態に係る商品又はサービスの購入は、店舗で行われてもよく、ネットワーク上の電子商取引サイト又はサービス提供サイトで行われてもよい。情報処理装置としては、例えば、携帯電話機、パーソナルコンピュータ、タブレット型コンピュータなどが用いられる。
本実施形態において、データベースDBに格納されているデータは顧客毎のデータであるとして説明したが、格納されているデータが取引毎のデータであってもよい。この場合、取引毎に例えば顧客の氏名又は顧客ID等、顧客を特定する情報の格納も必要となる。
本実施形態において、カード決済時に利用者Uより取得するデータがサインデータもしくは生体データのみである場合を例として説明したが、これに加え、カード決済の一般的な認証方法である暗証番号入力が選択可能であってもよい。
上記の図12及び図13のフローチャートにおいて、各ステップの順序は、処理結果に影響を及ぼさない範囲で適宜変更されてもよい。
本実施形態において、決済データ215,215a〜215cは、複数に分割されてもよい。
以下、具体的に本実施形態の効果について説明する。
本実施形態において、カード決済端末200は、複数のカード認証方法に対応する。例えば、利用者Uより取得するデータがサインデータであるか、生体データであるかを自動的に判別する。これにより、決済端末209の操作者である加盟店の店員は、取得するデータの種類を意識することなく、自動的にカード決済処理を進めることが可能となるため、カード決済者側の利便性を向上させることができる。
また、第1の実施形態に示すように、1枚のカードを複数人で利用する場合が想定される。本実施形態において、カード端末209またはサーバ216乃至サーバ218のいずれかのサーバで生体認証が実行される場合で、カードデータDに含まれる生体データ205が複数存在する場合には、取得データと照合完了するまで各生体データについて順番に照合が行われる。照合完了した場合は、照合結果をデータベースDBに保存する。これにより、カードを複数人で共有して使用しても、カードを使用した人物を特定することが可能となる。さらに、認証失敗時には、利用者への通知を行い、かつカードへの認証失敗情報の書き込みによりカードを使用不可とすることで、カード決済の不正利用を予防することができる。
また、カードCが第三者により不正に利用された場合、生体認証であれば契約者本人以外のカード使用により認証成功することは考えにくいが、それ以外の暗証番号認証またはサイン入力の場合であれば、本人以外によりカードが不正利用される可能性がある。または不正利用でなくとも、詐欺等により、本人の意図しないカード利用がされる可能性がある。本実施形態において、カード決済端末200は、利用者Uよりサインデータ214を取得した場合、サインデータ214とカードC上のサインデータ227が類似するかどうかの照合を行うことにより、取得したサインデータ214の有効性を判定する。さらに、照合失敗時には、利用者Uへその旨を通知することにより、カードCの不正利用を通知する。これにより、サイン認証が行われる場合でも、カードCのセキュリティを高めることができる。
本実施形態において、カード決済端末200によりサインデータの照合が行われる場合、サイン入力装置207がカードC上のサインデータ227を読み取るとした。しかしながら、カードデータ読み書き装置210がカードC上のサインデータ227を読み取る機能を備えている場合は、カードデータ読み書き装置210がカードC上のサインデータ227を読み取るとしてもよい。
本実施形態においては、カード決済に関するデータがデータベー
スDBに蓄えられる。これにより、店舗は、対面で顧客がサインした紙媒体のカード決済書類を長期間管理する必要がなく、店舗の管理コスト及び労力を大幅に低減することができる。
[第3の実施形態]
第3の実施形態においては、第2の実施形態に示したカード決済端末200およびサーバ218を用いてカード決済システムを構成する。本カード決済システムでは、例えば高齢者、障碍者、未成年者といったユーザに対して、意図しないカード決済を未然に防ぐセキュリティサービスを提供することを目的とする。
第3の実施形態は、上記第1の実施形態で説明された多機能カード1を利用する場合にも適用可能である。
以下、第3の実施形態に係るカード決済システムの実施形態を、図面を用いて説明する。
図14は、本実施形態に係るカード決済システムの構成の一例を示すブロック図である。本実施形態においては、第2の実施形態に示したカード決済端末200およびサーバ218に加え、さらにオペレータ301、サーバ218に接続されるデータベース302を備えるカード決済システム300を構成する。サーバ218は、以下ではイシュアのサーバ218であるとして説明するが、アクワイアラのサーバ216、またはカードブランドのサーバ217であってもよい。
カード決済端末200とサーバ218との通信には、決済データ215と与信結果データ219が用いられ、これらの動作および構成は第2の実施形態で示した通りである。
サーバ218は、データベース302に記憶されたデータの読み出し、およびデータの書き込みが可能である。
データベース302は、カード決済に必要なユーザUの個人情報302a、過去の異常な決済データのパターンを示す異常パターン情報302b、およびユーザUの過去のカード決済に用いられた決済データ215に含まれる任意の情報を記憶する。
オペレータ301は、ユーザUがデータベース302に対して個人情報302aを設定する際に利用するインタフェースであり、例えば設定を代行するイシュア側の電話口のオペレータであってもよいし、イシュアのサーバ218上に設けられたユーザU専用の登録フォームであってもよい。
なお、オペレータ301はサーバ218に含まれていてもよいし、ユーザUがデータベース302に直接アクセスできる手段がある場合は、オペレータ301はなくてもよい。
図15は、本実施形態に係る個人情報302aの設定処理を例示するフローチャートである。
ユーザUは、カード決済に関する利用限度額、決済地域といった個人情報(カード利用条件情報)302aをあらかじめデータベース302に登録しておくことで、サーバ218はカード決済があった際、ユーザUの意図したカード決済であるかどうかを登録された個人情報302aを用いて判定することが可能となる。
ユーザUは、オペレータ301に対し、カード決済の利用回数、利用限度額、または決済地域といった個人情報302aの設定を依頼する(ステップS1501)。決済地域の設定は、生活圏外でのカード利用を防ぐことを目的とする。例えば、不正請求、消費者被害、詐欺被害等(以下、詐欺被害等と称する)の課金会社は一部の地域に偏る傾向がある。したがって、決済地域を監視することは、詐欺被害等を防ぐために有効である。
なお、ユーザUは、オペレータ301に対し、必要に応じてさらに追加の個人情報302aの設定を依頼してもよい。
オペレータ301は、ユーザUによる個人情報302aの設定依頼を受信すると、サーバ218に対し、ユーザ情報の設定指令を送信する(ステップS1502)。
サーバ218は、オペレータ301よりユーザ情報の設定指令を受信すると、データベース302にユーザ情報を設定する(ステップS1503)。
図16は、本実施形態に係るセキュリティサービスにおける処理を例示するフローチャートである。なお、ユーザUの個人情報302aは、図15の手順によりデータベース302に設定されているとする。
ユーザUは、加盟店に設置されているカード決済端末200を使用してカード決済による物品またはサービスの購入を行うと(ステップS1601)、カード決済端末200は、決済データ215を作成し、決済データ215をサーバ218へ送信する(ステップS1602)。
サーバ218は、データベース302に設定されたユーザUの個人情報302aである利用回数を参照し、データベース302内部を検索することにより得られたユーザUの実際の利用回数と比較する(ステップS1603)。サーバ218は、ユーザUの利用回数が設定された回数を超えている場合、カードは利用不可すなわち与信結果をNGと判定し、ステップS1608の処理に移る。そうでない場合は、ステップS1604の処理に移る。
サーバ218は、データベース302に設定されたユーザUの個人情報302aである決済地域を参照し、決済データ215に含まれる加盟店情報230の住所と比較する(ステップS1604)。
サーバ218は、加盟店情報230の住所がデータベース302に設定された決済地域に含まれてない場合、詐欺被害等の疑いがあるか否かを判定する(ステップS1605)。例えば、データベース302に過去の詐欺被害等の決済データが記憶されている場合は、異常パターン情報302bとしての過去の詐欺被害等の決済データを読み出し、決済データ215の加盟店情報230および支払金額226と比較することにより詐欺被害等の疑いがあるか否かを判定してもよい。また、例えば支払金額226とユーザUによりデータベース302に設定された利用限度額とを比較し、支払金額226が一定基準以上の高額であれば、詐欺被害等の疑いがあると判定してもよい。
ステップS1605において、詐欺被害等の疑いがないと判定された場合は、ステップS1608の処理に移る。詐欺被害等の疑いがあると判定された場合は、サーバ218は、ユーザの安否確認を実施する(ステップS1606)。ユーザUは、安否確認サービスを受信する(ステップS1607)。安否確認サービスの受信方法は、ユーザがデータベース302に事前に設定した連絡先へ自動音声連絡を行うとしてもよく、自動でメールを送信してもよく、または、その他の手段による連絡でもよい。さらに、安否確認が取れない場合は、サーバ218は、例えばデータベース302において記憶されているユーザUの緊急連絡先、成年後見人、または警察警備会社等へ、自動音声連絡、自動メール送信、またはその他の手段による連絡を行ってもよい。
ステップS1608において、サーバ218は、与信結果をNGとする与信結果データ7を作成し、カード決済端末200へ送信する。また、ステップS1605において詐欺被害等であると判定された場合は、決済データ215のうちその取引に関する情報、すなわち支払金額226、加盟店情報230、およびこれらに加えて他に必要な情報をデータベース302に記憶する。カード決済端末200は、与信結果NGデータを受信し、決済不成立となる(ステップS1609)。
ステップS1604において、サーバ218により加盟店情報230の住所がデータベース302に設定された決済地域内であると判定された場合、サーバ218は、現在の決済データ215のユーザUの支払金額226を足し合わせた、データベース302に保存されているユーザUの過去一定期間の支払金額の累積額と、ユーザUによりデータベース302に設定された利用限度額とを比較する(ステップS1610)。累積額が利用限度額内である場合、与信結果をOKと判定し、ステップS1615の処理に移る。累積額が利用限度額内ではない場合は、サーバ218は、ユーザUに対し、利用限度額制限を解除するか否か確認を行う(ステップS1611)。
ユーザUは、利用限度額制限を解除の通知を受け取った場合、オペレータ301に対し利用限度額制限の解除可否の設定を依頼する(ステップS1612)。
ステップS1613において、オペレータ301は、ユーザUより利用限度額制限を解除する旨の設定依頼を受信した場合、かつユーザUの利用限度額が支払金額226を超えるよう設定可能であると判定した場合、サーバ218に対しユーザUの利用限度額制限の解除を行うよう指示する。利用限度額制限を解除する旨の設定依頼を受信しない場合、または、利用限度額が支払金額226を超えるよう設定不可の場合、オペレータ301は、与信結果はNGと判定し、サーバ218に対し上述のステップS1608の処理に移るよう指示する。
サーバ218は、オペレータ301より利用限度額制限の解除指令を受信すると、ユーザUの利用限度額を、設定可能な金額かつ支払金額226を超える金額になるように設定する(ステップS1614)。
ステップS1615において、サーバ218は、与信結果をOKとする与信結果データ219を作成し、カード決済端末200へ送信する。また、決済データ215のうちユーザUの取引であることおよびその金額を特定する情報、すなわちカード番号201、氏名203、支払金額226、支払方法およびこれらに加えて他に必要な情報をデータベース302に記憶する。カード決済端末200は、与信結果OKデータを受信し、決済成立となる(ステップS1616)。
本実施形態においては、データベース302に対し、利用回数、限度額、決済地域といった個人情報302aを設定し、サーバ218において、データベース302に記憶されている個人情報302aまたは過去のカード決済情報と現在の決済データ215とを比較照合して与信可否を決定することにより、ユーザUの意図しないカード利用や、詐欺被害等のようなカード被害を防ぐことができる。
本実施形態において、ユーザ毎に行うカードの利用回数の設定は、月単位であってもよいし、日単位であってもよい。また、従来一般のクレジットカードの利用限度額は利用枠全体に対してのみ設定でき、またデビットカードまたはキャッシュカードでの利用限度額は銀行口座残高全部となっているが、本実施形態においては、利用限度額をカードの使用目的に応じて細かく設定できるとしてもよい。例えば、現金払い戻しは2万円以下で1日1回まで、振り込みは3万円以下で1日2回まで、通常買い物は1万円以下で3回までといった設定が可能であるとしてもよい。
本実施形態において、データベース302に設定される利用回数、限度額、決済地域といったユーザUの個人情報302aは、サーバ218によるユーザUのカード利用内容のパターン化に基づいて、または、サーバ218によるユーザUのカードの利用回数、利用間隔、利用店舗、利用目的、与信残高などに基づくスコアリングにより、サーバ218が自動的に設定してもよい。
上記の図16のフローチャートにおいて、各ステップの順序は、例えばサーバ218においてデータベース302に記憶されている個人情報302aまたは過去のカード決済情報と現在の決済データ215との比較照合処理が実現できる範囲であれば、適宜変更されてもよいし、1つの処理モジュールで一括して複数ステップの処理が行われてもよい。
本実施形態においては、ユーザUが事前に設定した利用限度額以上の金額を決済しようとした場合、サーバ218はユーザUに対し、利用限度額制限の解除確認を行う。これにより、ユーザU本人ではない他人による利用限度枠の解除を禁止するとともに、ユーザUの意図しない高額なカード決済を防ぐことができる。
さらに、本実施形態において、詐欺被害等の疑いがあると判定された場合は、本人の安否確認を行うことにより、例えば高齢者、障碍者、未成年者といったユーザUの保護を強化することができる。
上記の各実施形態は、例示であり、発明の範囲を限定することは意図していない。上記の各実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で種々の省略、置き換え、変更を行うことができる。上記の各実施形態やその変形は、発明の範囲や要旨に含まれると同様に、特許請求の範囲に記載された発明とその均等の範囲に含まれるものである。