JP2019148939A - 認証情報生成装置、認証情報生成方法、および認証情報生成プログラム - Google Patents

Abstract

【課題】取引の利便性が低下することを抑えつつ、簡単にセキュリティを向上させること。【解決手段】銀行サーバ１１１は、取引履歴取得部５０６と、認証情報生成部５０７と、記憶制御部５１３とを有する。取引履歴取得部５０６は、利用者が閲覧可能な取引に関する履歴（たとえば、預金通帳１２３に記帳された残額の情報）を取得する。認証情報生成部５０７は、取引履歴取得部５０６によって取得された履歴に基づいて、以降の取引において用いられる認証情報（暗証番号）を生成する。たとえば、認証情報生成部５０７は、預金通帳１２３に記帳された残額の下４桁を、以降の取引において用いられる認証情報として生成する。また、記憶制御部５１３は、認証情報生成部５０７によって生成された認証情報を認証情報記憶部５０９に記憶させる。【選択図】図５

Description

この発明は、クレジットカードやキャッシュカードなどの各種カードに用いられる認証情報を生成する、認証情報生成装置、認証情報生成方法、および認証情報生成プログラムに関する。

従来、クレジットカードやキャッシュカードなど各種カードを用いて、取引がおこなわれている。各種カードを用いて取引をおこなう際には、暗証番号やパスワードといった認証情報が用いられる。たとえば、クレジットカードを用いて、利用者が商品を購入した場合やサービスの提供を受けた際に、暗証番号を入力して支払がおこなわれる。また、たとえば、キャッシュカードを用いて、利用者が銀行の口座から所望の額を引き出す際に、暗証番号を入力して出金がおこなわれる。

関連する技術として、たとえば、プリペイドカードに付与された識別コードと、取引ごとに使用される認証情報と、残高情報と、を対応付けて記憶するデータベースを参照し、取引の際に利用者から識別コードとともに受け付けた認証情報がデータベースに記憶される認証情報に合致する場合、当該識別コードに対応する残高情報を取引金額に基づいて更新する、取引方法が開示されている（たとえば、下記特許文献１参照。）。

特開２００２−１６３５８３号公報

しかしながら、従来におけるキャッシュカードやクレジットカードの認証情報は固定化されることが多く、セキュリティが高いとは言えなかった。ここで、セキュリティを高めるために認証情報を変更する場合、利用者が銀行の窓口に出向いたり、利用者とカード会社との間で各種書類や各種情報をやり取りしたりするため、利用者や各社のスタッフにとって手間がかかるという問題があった。

また、セキュリティを高めるために認証情報を適宜変更したとすると、利用者が認証情報を失念する可能性が高くなり、認証情報を失念した場合には、取引をおこなうことができず、取引にかかる利便性が低下するといった問題があった。特に、高齢化社会において、高齢な利用者ほど、認証情報を失念する可能性は高くなるため、認証情報を適宜変更したとすると、このような問題が生じやすくなる。

この発明は、上述した従来技術による問題点を解消するため、取引の利便性が低下することを抑えつつ、セキュリティを簡単に向上させることができる、認証情報生成装置、認証情報生成方法、および認証情報生成プログラムを提供することを目的とする。

上述した課題を解決し、目的を達成するため、この発明にかかる認証情報生成装置は、利用者が閲覧可能な取引に関する履歴を取得する取得手段と、前記取得手段によって取得された履歴に基づいて、以降の取引において用いられる認証情報を生成する生成手段と、を有することを特徴とする。

また、この発明にかかる認証情報生成装置は、上記発明において、前記履歴は、金融機関が発行する預金通帳に印字された情報を含み、前記生成手段は、前記預金通帳に印字された情報に基づいて、前記金融機関における以降の取引において用いられる認証情報を生成することを特徴とする。

また、この発明にかかる認証情報生成装置は、上記発明において、前記取得手段は、前記預金通帳に印字された直近の情報を取得し、前記生成手段は、前記取得手段によって取得された前記直近の情報に基づいて、前記認証情報を生成することを特徴とする。

また、この発明にかかる認証情報生成装置は、上記発明において、前記生成手段は、前記預金通帳に印字された情報が示す金額の中から、予め設定された複数の桁に該当する数字をそれぞれ選択して前記認証情報を生成することを特徴とする。

また、この発明にかかる認証情報生成装置は、上記発明において、前記履歴は、前記預金通帳に印字されていない情報を含み、前記預金通帳に印字された情報と、前記預金通帳に印字されていない情報とを区別させる付加情報を、前記履歴とともに所定の端末に表示可能にするための制御をおこなう出力制御手段を有することを特徴とする。

また、この発明にかかる認証情報生成装置は、上記発明において、前記生成手段は、前記利用者による設定に応じて、前記履歴に基づく認証情報の生成をおこなうことを特徴とする。

また、この発明にかかる認証情報生成装置は、上記発明において、前記履歴は、カード会社が発行した決済に関する通知に印字された情報を含み、前記生成手段は、前記通知に印字された情報に基づいて、前記カード会社が発行したクレジットカードを用いた以降の取引において用いられる認証情報を生成することを特徴とする。

また、この発明にかかる認証情報生成方法は、利用者が閲覧可能な取引に関する履歴を取得し、取得した前記履歴に基づいて、以降の取引において用いられる認証情報を生成し、生成した認証情報を記憶部に記憶させる処理をコンピュータが実行することを特徴とする。

また、この発明にかかる認証情報生成プログラムは、利用者が閲覧可能な取引に関する履歴を取得し、取得した前記履歴に基づいて、以降の取引において用いられる認証情報を生成し、生成した認証情報を記憶部に記憶させる処理をコンピュータに実行させることを特徴とする。

この発明にかかる認証情報生成装置、認証情報生成方法、および認証情報生成プログラムによれば、取引の利便性が低下することを抑えつつ、セキュリティを簡単に向上させることができる、という効果を奏する。

図１は、実施の形態１にかかる認証情報生成システム１００のシステム構成例を示す説明図である。 図２Ａは、銀行サーバ１１１のハードウエア構成の一例を示すブロック図である。 図２Ｂは、利用者端末１２１およびＡＴＭ１３１のハードウエア構成の一例を示すブロック図である。 図３Ａは、口座情報データベース（ＤＢ）１１２の記憶内容の一例を示す説明図である。 図３Ｂは、実施の形態１にかかる取引情報データベース（ＤＢ）１１３の記憶内容の一例を示す説明図である。 図４は、実施の形態１にかかる認証情報の生成例を示す図である。 図５は、実施の形態１にかかる認証情報生成システム１００の機能的構成を示す説明図である。 図６Ａは、利用者端末１２１に表示される取引履歴の表示例を示す説明図である。 図６Ｂは、利用者端末１２１がＳＮＳにより取得した直近の記帳情報の表示例を示す説明図である。 図７は、銀行サーバ１１１がおこなう認証情報生成処理手順の一例を示すフローチャートである。 図８は、銀行サーバ１１１がおこなう取引履歴の出力処理手順の一例を示すフローチャートである。 図９Ａは、認証情報の生成の他の例を示す図（その１）である。 図９Ｂは、認証情報の生成の他の例を示す図（その２）である。 図１０は、実施の形態２にかかる認証情報生成システム１０００のシステム構成例を示す説明図である。 図１１Ａは、カード情報データベース（ＤＢ）１０１２の記憶内容の一例を示す説明図である。 図１１Ｂは、実施の形態２にかかる取引情報データベース（ＤＢ）１０１３の記憶内容の一例を示す説明図である。 図１２は、実施の形態２にかかる認証情報の生成例を示す図である。 図１３は、実施の形態２にかかる認証情報生成システム１０００の機能的構成を示す説明図である。 図１４は、カード会社サーバ１０１１がおこなう認証情報生成処理手順の一例を示すフローチャートである。

以下に添付図面を参照して、この発明にかかる認証情報生成装置、認証情報生成方法、および認証情報生成プログラムの好適な実施の形態（実施の形態１および実施の形態２）を詳細に説明する。

（実施の形態１）
（認証情報生成システムのシステム構成）
まず、実施の形態１にかかる認証情報生成システム１００のシステム構成例について説明する。図１は、実施の形態１にかかる認証情報生成システム１００のシステム構成例を示す説明図である。図１において、認証情報生成システム１００は、銀行サーバ１１１と、利用者端末１２１と、カード１２２と、預金通帳１２３と、ＡＴＭ（Ａｕｔｏｍａｔｅｄ Ｔｅｌｌｅｒ Ｍａｃｈｉｎｅ：現金自動預け払い機）１３１と、を有する。

銀行サーバ１１１は、この発明にかかる認証情報生成装置の一例である。銀行サーバ１１１は、銀行１１０に設けられるサーバである。具体的には、銀行サーバ１１１は、利用者ごとの口座の預金額等を管理する汎用的なコンピュータ装置である。銀行サーバ１１１は、たとえば、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）やメモリやインタフェースなどを有するパーソナルコンピュータである。また、銀行サーバ１１１は、口座情報データベース（ＤＢ）１１２と、取引情報ＤＢ１１３とを有する。各種ＤＢ１１２，１１３の記憶内容については、図３Ａおよび図３Ｂを用いて後述する。

利用者端末１２１は、たとえば、カード１２２の利用者が有するコンピュータ装置である。利用者端末１２１には、たとえば、スマートフォンやタブレット型ＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）といったコンピュータ装置が用いられる。利用者端末１２１は、ＣＰＵやメモリやインタフェースなどを有する。

ただし、利用者端末１２１は、スマートフォンやタブレット型ＰＣに限らず、デスクトップ型ＰＣ、ノート型ＰＣなどの各種ＰＣ、携帯電話機、ＰＨＳ（Ｐｅｒｓｏｎａｌ Ｈａｎｄｙｐｈｏｎｅ Ｓｙｓｔｅｍ）とすることも可能である。

カード１２２は、銀行１１０が発行したキャッシュカードである。預金通帳１２３は、利用者の預金口座に対応する、銀行１１０が発行した冊子であり、預金の受け入れ額や、払い戻し額が記帳される。

ＡＴＭ１３１は、銀行１１０の店舗やコンビニエンスストアなどに設けられ、インターネットなどのネットワーク１４０に接続されている。ＡＴＭ１３１は、カード１２２や預金通帳１２３が挿入されて、利用者によって所定の取引情報が入力されることにより、入出金や振込などにかかる各種の処理をおこなう。ＡＴＭ１３１は、入出金や振込などにかかる各種の処理の実行に際して、銀行サーバ１１１との間で通信をおこなう。

また、ＡＴＭ１３１は、利用者と銀行サーバ１１１とのインタフェースをつかさどり、出金や振込などにかかる取引情報を利用者に通知する。また、ＡＴＭ１３１は、預金通帳１２３が挿入されて、取引をおこなった場合、預金通帳１２３に取引の内容を記帳（印字）する。また、ＡＴＭ１３１は、預金通帳１２３が挿入されずに、カード１２２のみが挿入されて、取引をおこなった場合、取引情報を示す利用明細書を印字出力する。

認証情報生成システム１００において、銀行サーバ１１１と、利用者端末１２１と、ＡＴＭ１３１とは、有線または無線のネットワーク１４０を介して接続される。ネットワーク１４０は、たとえば、インターネット、移動体通信網などである。ただし、ネットワーク１４０は、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）などであってもよい。

（銀行サーバ１１１のハードウエア構成の一例）
つぎに、銀行サーバ１１１について、その具体的な構成の一例を説明する。図２Ａは、銀行サーバ１１１のハードウエア構成の一例を示すブロック図である。

図２Ａにおいて、銀行サーバ１１１を実現するコンピュータ装置は、ＣＰＵ２１１と、メモリ２１２と、通信ＩＦ（Ｉｎｔｅｒｆａｃｅ）２１３と、を備える。コンピュータ装置が備える各部２１１〜２１３は、バス２１０によってそれぞれ接続されている。ＣＰＵ２１１は、コンピュータ装置の全体の制御をつかさどる。

メモリ２１２は、ブートプログラムなどのプログラムや、各種のデータベースのデータなどを記憶する。また、メモリ２１２は、認証情報生成プログラムや各種データベースの一部のデータなど、実施の形態１の認証情報生成方法にかかる各種のプログラムやデータを記憶する。

また、メモリ２１２は、ＣＰＵ２１１のワークエリアとして使用される。メモリ２１２は、たとえば、ＲＯＭ（Ｒｅａｄ−Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、ＨＤＤ（Ｈａｒｄ Ｄｉｓｃ Ｄｒｉｖｅ）およびＨＤ（Ｈａｒｄ Ｄｉｓｃ）などによって実現することができる。

通信ＩＦ２１３は、ネットワーク１４０に接続され、コンピュータ装置の内部と、利用者端末１２１やＡＴＭ１３１などの外部装置とのインタフェースをつかさどる。具体的には、通信ＩＦ２１３は、コンピュータ装置の内部と外部装置との間におけるデータの入出力を制御する。

（利用者端末１２１およびＡＴＭ１３１のハードウエア構成の一例）
つぎに、利用者端末１２１およびＡＴＭ１３１について、その具体的な構成の一例を説明する。図２Ｂは、利用者端末１２１およびＡＴＭ１３１のハードウエア構成の一例を示すブロック図である。なお、以下においては、利用者端末１２１について説明することとし、ＡＴＭ１３１については適宜補足して説明することとする。

図２Ｂにおいて、利用者端末１２１を実現するコンピュータ装置は、ＣＰＵ２２１と、メモリ２２２と、出力デバイス２２３と、入力デバイス２２４と、通信ＩＦ２２５と、を備える。コンピュータ装置が備える各部２２１〜２２５は、バス２２０によってそれぞれ接続されている。ＣＰＵ２２１は、コンピュータ装置の全体の制御をつかさどる。

メモリ２２２は、ブートプログラムなどのプログラムや、各種のデータベースのデータなどを記憶する。また、メモリ２２２は、ＣＰＵ２２１のワークエリアとして使用される。メモリ２２２は、たとえば、ＲＯＭ、ＲＡＭ、ＨＤＤ、およびＨＤなどによって実現することができる。

出力デバイス２２３は、たとえば、ディスプレイ、スピーカ、音声出力端子などを含む。ディスプレイは、操作内容や、利用者に対する案内情報などを表示する。ディスプレイは、認証サービスにかかる各種の操作画面を表示する。ディスプレイは、たとえば、主に液晶ディスプレイや有機ＥＬ（Ｅｌｅｃｔｒｏ−Ｌｕｍｉｎｅｓｃｅｎｃｅ）ディスプレイなどによって実現することができる。

また、スピーカは、音声、アラーム音などを出力する。音声出力端子は、ヘッドフォーンなどを接続する端子であり、スピーカと同様に、音声、アラーム音などを接続されたヘッドフォーンなどに出力する。

入力デバイス２２４は、文字、数値、各種指示などの入力のためのキーを備え、データ入力をおこなう。入力デバイス２２４は、たとえば、タッチパネルやキーボードなどを含む。タッチパネルやキーボードは、入力操作に応じた信号をＣＰＵ２２１に対して出力する。

タッチパネルは、ディスプレイの表示面側に積層される。タッチパネルは、指やペンなどの筆記部材が接触したことを検出した場合に、タッチパネルに対する筆記部材の接触位置に応じた電気信号を出力する。タッチパネルは、たとえば抵抗膜方式や静電容量方式、音響パルス認識方式、超音波表面弾性波方式、赤外遮光方式、画像認識方式など公知の各種の方式のものを用いることができる。

また、入力デバイス２２４は、カメラなどの撮像装置を含む。カメラは、静止画や動画を撮像する。具体的には、たとえば、カメラは、ＣＰＵ２２１によって制御されて撮像対象を撮像し、画像データを生成する。また、カメラは、バーコードやＱＲコード（登録商標）といった二次元コードを撮影して入力する。また、カメラは、ＯＣＲ（Ｏｐｔｉｃａｌ Ｃｈａｒａｃｔｅｒ Ｒｅａｄｅｒ）機能を用いて撮影した文字をデータ化して入力する。

また、入力デバイス２２４は、マイクなどの録音装置を含む。マイクは、アナログデータとして入力された話者の声をアナログ／デジタル変換し、デジタル形式の音声データを生成する。入力デバイス２２４としてマイクを用いることによって、利用者は、利用者端末１２１を介して、タッチパネルやキーボードを用いる代わりに、文字などのテキスト入力をおこなうことができる。したがって、マイクは、いわゆる「ＡＩ（Ａｒｔｉｆｉｃｉａｌ Ｉｎｔｅｌｌｉｇｅｎｃｅ人工知能）スピーカー」などを含めるようにしてもよい。この「ＡＩスピーカー」を用いることによって、対話型の音声操作に対応したＡＩアシスタントが利用可能となる。

通信ＩＦ２２５は、ネットワーク１４０に接続され、コンピュータ装置の内部と、銀行サーバ１１１や、ＡＴＭ１３１などの外部装置とのインタフェースをつかさどる。具体的には、通信ＩＦ２２５は、コンピュータ装置の内部と外部装置との間におけるデータの入出力を制御する。

ここで、ＡＴＭ１３１の場合、上述した出力デバイス２２３や入力デバイス２２４には、以下のデバイスを含む。

たとえば、ＡＴＭ１３１の場合、出力デバイス２２３は、プリンタを含む。プリンタは、取引結果を印字する。たとえば、プリンタは、預金通帳１２３の記帳や、利用明細書の印字をおこなう。ＡＴＭ１３１の場合、入力デバイス２２４は、カードリーダを含む。カードリーダは、カード１２２の識別情報などのカード情報を読み取る。

（各種ＤＢ１１２，１１３の記憶内容）
つぎに、図３Ａおよび図３Ｂを用いて、図１に示した銀行サーバ１１１が有する口座情報データベース（ＤＢ）１１２および取引情報データベース（ＤＢ）１１３の記憶内容について説明する。各種ＤＢ１１２，１１３は、たとえば、メモリ２１２などの記憶部により実現される。

図３Ａは、口座情報データベース（ＤＢ）１１２の記憶内容の一例を示す説明図である。図３Ａにおいて、口座情報データベース１１２は、口座ＩＤ（Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）、氏名、住所、端末情報、金融機関コード、支店番号、口座番号、および残額のフィールドを有する。各フィールドに情報を設定することで、口座情報（たとえば、口座情報３００−１，３００−２）のレコードが記憶される。

口座ＩＤは、口座情報３００を識別する識別情報を示す。氏名は、銀行口座の名義人（利用者）の氏名を示す。住所は、銀行口座の名義人の住所を示す。端末情報は、銀行口座の名義人が有する端末装置（利用者端末１２１）のアドレスである。金融機関コードは、金融機関ごとに割り当てられたコードである。支店番号は、金融機関の支店に割り当てられた番号である。口座番号は、口座に割り当てられた番号である。残額は、口座内の残額である。

たとえば、口座情報３００−１は、口座ＩＤ「Ｕ００１」、氏名「総研総太郎」、住所「東京都…」、端末情報「ａａａ・・・＠ｘｘｘ」、金融機関コード「００００」、支店番号「３４５」、口座番号「１２３…」、残額「￥９６，３９０」を示す。また、口座情報３００−２についても、同様に、口座情報ＤＢ１１２に記憶される。

図３Ｂは、実施の形態１にかかる取引情報データベース（ＤＢ）１１３の記憶内容の一例を示す説明図である。図３Ｂにおいて、取引情報ＤＢ１１３は、取引ＩＤ、口座ＩＤ、氏名、取引日時、取引内容、取引金額、残額、記帳の有無、認証情報の生成方式、および認証情報のフィールドを有する。各フィールドに情報を設定することで、取引情報（たとえば、取引情報３１０−１〜３１０−６）のレコードが記憶される。

取引ＩＤは、取引を識別する識別情報を示す。口座ＩＤは、口座を識別する識別情報を示し、口座情報ＤＢ１１２（図３Ａを参照）に記憶される口座ＩＤと同一である。このため、口座情報ＤＢ１１２の口座情報３００と取引情報３１０とは、口座ＩＤによって対応付けられている。

また、取引情報ＤＢ１１３において、氏名は、口座情報ＤＢ１１２の口座情報３００に含まれる氏名と同一である。取引日時は、取引をおこなった日付を示す。取引内容は、出金、入金、振込といった取引の種別を示す。取引金額は、取引をおこなった金額を示す。残額は、取引後の口座の預金額である。記帳の有無は、預金通帳１２３に取引内容や残額等の記帳をおこなったか否かを示す。

認証情報の生成方式は、残額を用いて４桁の認証情報（暗証番号）を生成する際の方式を示す。認証情報の生成方式は、たとえば、残額の「下４桁」や「上４桁」などを設定することが可能である。

認証情報は、残額と、認証情報の生成方式とに基づいて生成される。認証情報の生成について、取引情報３１０−１を例に挙げて説明すると、認証情報は、残額が「￥１０１，０００」であり、認証情報の生成方式が「下４桁」であるため、残額「￥１０１，０００」の「下４桁」である「１０００」となる。すなわち、次回の取引において用いられる認証情報は、「１０００」となる。

認証情報の生成方式は、利用者によって、残額に応じた認証情報の生成を設定することが可能であり、残額に応じた認証情報の生成をおこなわない設定（認証情報が固定の設定）を「−」で示す。また、残額の「下４桁」とするか、「上４桁」とするかについても、利用者によって設定される。利用者による各設定は、たとえば、預金口座の初期登録時におこなわれてもよいし、預金口座が利用可能になってから利用者からの登録操作に応じておこなわれてもよい。認証情報は、次回の取引において用いられる認証情報（暗証番号）を示す。

ここで、たとえば、取引情報３１０−１は、取引ＩＤ「Ｔ００１」、口座ＩＤ「Ｋ００１」、氏名「総研総太郎」、取引日時「２０１７年１２月１日」、取引内容「入金」、残額「￥１０１，０００」、記帳の有無「有り」、認証情報の生成方式「下４桁」、認証情報「１０００」を示す。また、取引情報３１０−１以外の取引情報３１０−２〜３１０−６についても、同様に、取引情報ＤＢ１１３に記憶される。

（実施の形態１にかかる認証情報の生成例）
つぎに、図４を用いて、実施の形態１にかかる認証情報の生成例について説明する。図４は、実施の形態１にかかる認証情報の生成例を示す図である。以下に示す括弧書きの番号は、図４に示す括弧書きの番号と対応する。

図４に示すように、（１）２０１７年１２月１日に、利用者がＡＴＭ１３１に預金通帳１２３を挿入し、所定の暗証番号を入力し、￥１０，０００の入金をおこなったことにより、残額が￥１０１，０００となったとする。この場合、預金通帳１２３には、その旨を示す取引履歴が印字される。そして、残額が￥１０１，０００であることから、たとえば、下４桁の認証情報である「１０００」が次回の認証情報（暗証番号）となる。

また、（２）２０１７年１２月１１日に、利用者がＡＴＭ１３１に預金通帳１２３を挿入し、前回の取引で更新された暗証番号「１０００」を入力し、￥４，５００の出金をおこなったことにより、残額が￥９６，５００となったとする。この場合、預金通帳１２３には、その旨を示す取引履歴が印字される。そして、残額が￥９６，５００であることから、たとえば、下４桁の認証情報である「６５００」が次回の認証情報（暗証番号）となる。

さらに（３）２０１７年１２月２２日に、利用者がＡＴＭ１３１に預金通帳１２３を挿入し、前回の取引で更新された暗証番号「６５００」を入力し、￥１０の出金をおこなったことにより、残額が￥９６，４９０となったとする。この場合、預金通帳１２３には、その旨を示す取引履歴が印字される。そして、残額が￥９６，４９０であることから、たとえば、下４桁の認証情報である「６４９０」が次回の認証情報（暗証番号）となる。

そして、（４）２０１７年１２月２５日に、利用者がＡＴＭ１３１に預金通帳１２３を挿入せずに、カード１２２を挿入し、前回の取引で更新された暗証番号「６４９０」を入力し、￥１００の出金をおこなったことにより、残額が￥９６，３９０となったとする。この場合、利用明細書４００に、その旨を示す取引履歴が印字される。そして、残額が￥９６，３９０であるものの、預金通帳１２３に記帳された残額は￥９６，４９０であることから、認証情報に変更はなく、すなわち、認証情報である「６４９０」を保持する。

なお、（４）においては、カード１２２のみで取引をおこなっていることから、利用者が預金通帳１２３を所持していないこともある。この場合、利用者は、前回の取引で更新された暗証番号「６４９０」がわからないことがある。そこで、詳細については図６Ａおよび図６Ｂを用いて後述するが、利用者端末１２１には、取引履歴を表示することが可能となっている。

図４に説明したように、実施の形態１では、預金通帳１２３に記帳された残額と、所定の認証情報の生成方式とに基づいて、以降の取引に用いられる認証情報が生成される。このため、認証情報を随時更新することができるとともに、利用者が認証情報を覚えていなくても、預金通帳１２３を見るだけで、認証情報を容易に把握することができる。したがって、取引の利便性が低下することを抑えつつ、カード１２２を用いた取引のセキュリティを簡単に高めることができる。

（実施の形態１にかかる認証情報生成システム１００の機能的構成）
図５は、実施の形態１にかかる認証情報生成システム１００の機能的構成を示す説明図である。図５において、認証情報生成システム１００は、銀行サーバ１１１と、利用者端末１２１と、ＡＴＭ１３１とを備える。

銀行サーバ１１１は、取引情報受信部５０１と、取引制御部５０２と、取引結果送信部５０３と、取引履歴受信部５０４と、取引履歴記憶部５０５と、取引履歴取得部５０６と、認証情報生成部５０７と、生成方式記憶部５０８と、認証情報記憶部５０９と、口座情報記憶部５１０と、出力制御部５１１と、端末通信部５１２と、記憶制御部５１３とを備える。

ＡＴＭ１３１は、取引情報入力部５２１と、取引情報送信部５２２と、取引結果受信部５２３と、取引処理部５２４と、処理結果出力部５２５とを備える。

ここで、利用者が、ＡＴＭ１３１を介して、各種取引を開始させる場合について説明する。ＡＴＭ１３１の取引情報入力部５２１は、取引情報を入力する。取引情報は、挿入されたカード１２２から読み取ったカード情報や、挿入された預金通帳１２３に記載される内容や、利用者から入力される認証情報（暗証番号）や取引内容である。認証情報は、たとえば、４桁の数字であるが、これに限らず、４桁以外の数字であってもよいし、また、文字や記号を含んでもよい。

ここで、詳細については、後述するが、認証情報は、たとえば、預金通帳１２３に記載された、前回の取引における残額に基づいて生成される。このため、利用者は、預金通帳１２３に記載された、前回の取引における残額を閲覧して、所定の生成方式で生成される認証情報を確認してから、今回の取引における認証情報を入力する。取引情報入力部５２１は、ＡＴＭ１３１の入力デバイス２２４によって実現される。

取引情報送信部５２２は、取引情報入力部５２１に入力された取引情報を銀行サーバ１１１へ送信する。取引情報送信部５２２は、ＡＴＭ１３１の通信ＩＦ２２５によって実現される。

取引情報送信部５２２から取引情報が銀行サーバ１１１へ送信されると、銀行サーバ１１１の取引情報受信部５０１は、取引情報を受信する。取引情報受信部５０１は、ＡＴＭ１３１から受信した取引情報を取引制御部５０２へ出力する。取引情報受信部５０１は、銀行サーバ１１１の通信ＩＦ２１３によって実現される。

取引制御部５０２は、取引情報受信部５０１から取引情報が入力されると、当該取引情報に含まれる、利用者から受け付けた認証情報が、各利用者の認証情報を記憶する認証情報記憶部５０９に記憶されているか否かの一致判定（認証）をおこなう。当該一致判定において、否定の判定結果が得られた場合（認証に失敗した場合）、取引制御部５０２は、認証に失敗した旨を示す取引結果を取引結果送信部５０３へ出力する。

一方、一致判定において、肯定の判定結果が得られた場合（認証に成功した場合）、取引制御部５０２は、取引情報に含まれる、利用者から受け付けた取引内容での取引を可能にする。具体的には、たとえば、取引内容が出金や振込である場合、取引制御部５０２は、預金額等を記憶する口座情報記憶部５１０を参照し、利用者から受け付けた金額分の残額が口座情報記憶部５１０に記憶されているか否かの金額判定をおこなう。

当該金額判定において、否定の判定結果が得られた場合（残金がない場合）、取引制御部５０２は、その旨を示す取引結果を取引結果送信部５０３へ出力する。一方、当該金額判定において、肯定の判定結果が得られた場合（残金がある場合）、取引制御部５０２は、取引情報に含まれる、利用者から受け付けた取引内容の取引をおこなうとともに、その旨を示す取引結果を取引結果送信部５０３へ出力する。

取引制御部５０２は、銀行サーバ１１１のメモリ２１２に記憶されたプログラムをＣＰＵ２１１に実行させることにより、その機能を実現する。認証情報記憶部５０９および口座情報記憶部５１０は、銀行サーバ１１１のメモリ２１２によって実現される。具体的には、認証情報記憶部５０９は、取引情報ＤＢ１１３（図３Ｂを参照）によって実現される。また、口座情報記憶部５１０は、口座情報ＤＢ１１２（図３Ａを参照）によって実現される。ただし、認証情報記憶部５０９および口座情報記憶部５１０は、銀行サーバ１１１に設けられずに、外部の他の装置に設けられていてもよい。

取引結果送信部５０３は、取引制御部５０２から取引結果が入力されると、入力された取引結果をＡＴＭ１３１へ送信する。取引結果送信部５０３から取引結果がＡＴＭ１３１へ送信されると、ＡＴＭ１３１の取引結果受信部５２３は、取引結果を受信する。取引結果受信部５２３は、銀行サーバ１１１から受信した取引結果を取引処理部５２４へ出力する。取引結果受信部５２３は、ＡＴＭ１３１の通信ＩＦ２２５によって実現される。

取引処理部５２４は、取引結果受信部５２３から受信した取引結果に応じた取引処理をおこなう。具体的には、たとえば、取引内容が出金である場合には、取引結果に応じて、所定の払出口から所定の金額を払い出したり、取引結果を示す通知を音声や表示によりおこなったりする。また、たとえば、認証に失敗した場合や取引をおこなえない旨を示す取引結果である場合、取引処理部５２４は、その旨を示す通知を音声や表示によりおこなう。

また、取引処理部５２４は、取引結果に応じた取引処理をおこなうと、取引処理の処理結果を処理結果出力部５２５へ出力する。取引処理部５２４は、ＡＴＭ１３１のメモリ２２２に記憶されたプログラムをＣＰＵ２２１に実行させることにより、その機能を実現する。

処理結果出力部５２５は、取引処理部５２４から取引処理の処理結果が入力されると、処理結果を銀行サーバ１１１へ送信する。また、処理結果出力部５２５は、取引がおこなわれた場合であり、且つ預金通帳１２３が挿入されている場合には、処理結果を預金通帳１２３に記帳（印字）する。さらに、処理結果出力部５２５は、預金通帳１２３に記帳すると、記帳したことを示す記帳情報を含む取引履歴を銀行サーバ１１１へ送信する。処理結果出力部５２５は、ＡＴＭ１３１の出力デバイス２２３（プリンタ）や通信ＩＦ２２５によって実現される。

処理結果出力部５２５から取引履歴が銀行サーバ１１１へ送信されると、銀行サーバ１１１の取引履歴受信部５０４は、取引履歴を受信する。取引履歴受信部５０４は、ＡＴＭ１３１から受信した取引履歴を取引履歴記憶部５０５へ出力する。取引履歴記憶部５０５は、取引履歴受信部５０４から入力した取引履歴を記憶する。上述したように、取引履歴には、記帳したことを示す記帳情報が含まれているため、取引履歴記憶部５０５は、取引ごとに記帳されているか否かを記憶することができる。

取引履歴受信部５０４は、銀行サーバ１１１の通信ＩＦ２１３によって実現される。取引履歴記憶部５０５は、銀行サーバ１１１のメモリ２１２によって実現される。具体的には、取引履歴記憶部５０５は、取引情報ＤＢ１１３（図３Ｂを参照）によって実現される。

取引履歴取得部５０６は、取引履歴記憶部５０５から、取引履歴を取得する。取引履歴は、利用者が閲覧可能な取引に関する履歴である。利用者が閲覧可能とは、預金通帳１２３に記載されることによって閲覧可能であることや、利用者端末１２１に表示されることによって閲覧可能であることである。

取引履歴は、金融機関が発行する預金通帳１２３に印字された情報（以下「記帳情報」という）や、印字されていない情報を含む。金融機関は、たとえば銀行１１０であるが、郵便局や信用金庫などであってもよい。記帳情報は、たとえば、日付、出金額や入金額といった取引の額、残額、振込先、といった情報を含む。

認証情報生成部５０７は、取引履歴取得部５０６によって取得された取引履歴に基づいて、以降の取引において用いられる認証情報を生成する。取引履歴に基づく認証情報の生成は、利用者によって設定される。利用者による設定は、利用者が自らおこなう設定でもよいし、利用者の申告に基づいて銀行１１０のスタッフがおこなう設定でもよい。

取引履歴に基づく認証情報の生成をおこなわない設定となっている場合、認証情報は、固定されたままとなる。一方で、取引履歴に基づく認証情報の生成をおこなう設定となっている場合、認証情報は、取引履歴に基づいて更新される。

認証情報の生成について具体的に説明すると、認証情報生成部５０７は、預金通帳１２３に印字された記帳情報に基づいて、金融機関における以降の取引において用いられる認証情報を生成する。特に、記帳情報は、直近の記帳情報である。この場合、取引履歴取得部５０６は、預金通帳１２３に印字された直近の記帳情報を取得する。直近の記帳情報は、預金通帳に最後に記帳された情報である。認証情報生成部５０７は、取引履歴取得部５０６によって取得された直近の記帳情報に基づいて、認証情報を生成する。

認証情報生成部５０７は、生成方式記憶部５０８に記憶される、予め設定される生成方式により認証情報を生成する。具体的には、認証情報生成部５０７は、預金通帳１２３に印字された記帳情報が示す金額（たとえば残額）の中から、予め設定された複数の桁に該当する数字をそれぞれ選択して認証情報を生成する。

具体的には、認証情報生成部５０７は、最後に記帳された残額のうち、予め設定された複数の桁（認証情報の桁）に該当する数字をそれぞれ選択して認証情報を生成する。たとえば、認証情報が４桁の数字であれば、認証情報生成部５０７は、下４桁や上４桁といった数字を選択して認証情報を生成する。

ただし、認証情報生成部５０７は、下４桁や上４桁といった数字を選択することに限らず、たとえば、５桁目と、４桁目と、２桁目と、１桁目などのように、特定の桁の数字を選択してもよい。また、下４桁とするか、上４桁とするかといった、選択の対象となる桁は、利用者によって設定されてもよい。

たとえば、認証情報生成部５０７は、最後に記帳された残額が「￥９６，４９０」であり、下４桁を選択する設定となっている場合には、下４桁に該当する「６」、「４」、「９」、「０」を選択する。認証情報生成部５０７は、選択した数字を、予め設定した所定の並べ方で並べて認証情報を生成する。

所定の並べ方は、たとえば、左から並べる並べ方であり、この場合、上記の例では「６４９０」が認証情報となる。ただし、所定の並べ方は、これに限らず、たとえば、右から並べる並べ方としてもよく、この場合、上記の例では「０９４６」が認証情報となる。また、所定の並べ方は、利用者によって設定されてもよい。

同様に、たとえば、上４桁を選択する設定となっており、最後に記帳された残額が「￥９６，４９０」である場合には、認証情報生成部５０７は、上４桁に該当する「９」、「６」、「４」、「９」を選択し、所定の並べ方で並べて認証情報を生成すればよい。

なお、預金通帳１２３に記帳された残額が、認証情報に該当する複数の桁（４桁）に満たない場合、具体的には、たとえば、認証情報が４桁であるものの、残額が「￥１，０００」未満（たとえば「￥５１２」）の場合、記帳のない位（千の位）については、所定の数字（たとえば「０」）を補って、認証情報を「０５１２」とすればよい。記帳のない桁がある場合に補う所定の数字は、利用者によって設定されてもよい。

また、詳細については図９Ａを用いて後述するが、認証情報生成部５０７は、預金通帳１２３に記帳された数字を、横方向に選択して認証情報を生成するのではなく、縦方向に選択して認証情報を生成してもよい。たとえば、預金通帳１２３に４回以上の取引をおこなったことにより、記帳された段数が４段以上ある場合、特定の桁（たとえば１桁目）に該当する数字を縦方向に選択して認証情報とすることも可能である。

また、認証情報生成部５０７は、預金通帳１２３に記載された残額の中から数字を選択することに限らず、たとえば、預金通帳１２３に記帳された、入金額や出金額の中から数字を選択して、認証情報を生成してもよい。

さらに、認証情報生成部５０７は、預金通帳１２３に記載された金額の中から数字を選択することに限らない。詳細については、図９Ｂを用いて後述するが、認証情報生成部５０７は、たとえば、預金通帳１２３に記帳された日付の情報を選択して、認証情報を生成してもよい。

また、認証情報生成部５０７は、ガス料金、電気料金、水道料金などの公共料金の支払のように、特定の支払先が定められており、且つ、定期的に引き落とされる記帳情報が得られる場合には、当該引き落としの額を用いて認証情報を生成してもよい。具体的には、たとえば、引き落としの対象がガス料金に設定されているとすると、認証情報生成部５０７は、ガス料金の引き落としがある都度、その引き落としの額に応じて、認証情報を生成してもよい。

これにより、予め設定された特定の引き落としがあった場合に、認証情報を更新することができる。また、特定の引き落としをいずれにするかの指定は、利用者によって設定されてもよい。これにより、第三者に預金通帳１２３が盗まれたり、紛失したりしたとしても、第三者が認証情報の生成方式を把握することをより困難にすることができるため、認証情報生成システム１００にかかるセキュリティをより向上させることができる。

また、認証情報は、直近の記帳情報に基づいて生成されることに限らず、予め設定した特定の時期の記帳情報に基づいて生成されてもよい。たとえば、特定の時期を年末としたとすると、年末の最後に記帳された記帳情報に基づいて生成された認証情報を、翌年の１年間の認証情報とすることも可能である。このように、特定の時期を設定することにより、認証情報を更新する期間を定めることができる。

記憶制御部５１３は、認証情報生成部５０７によって生成された認証情報を認証情報記憶部５０９に記憶させる。認証情報生成部５０７および記憶制御部５１３は、銀行サーバ１１１のメモリ２１２に記憶されたプログラムをＣＰＵ２１１に実行させることにより、その機能を実現する。生成方式記憶部５０８は、銀行サーバ１１１のメモリ２１２によって実現される。具体的には、生成方式記憶部５０８は、取引情報ＤＢ１１３（図３Ｂを参照）によって実現される。ただし、生成方式記憶部５０８は、銀行サーバ１１１に設けられずに、外部の他の装置に設けられていてもよい。

このように、認証情報は、認証情報生成部５０７が、予め生成しておいて、記憶制御部５１３が、認証情報生成部５０７によって生成された認証情報を認証情報記憶部５０９に記憶させておく。そして、認証要求を受信した際には、認証情報記憶部５０９に記憶されている認証情報を抽出して、抽出された認証情報に基づいて認証をおこなうようにする。このようにすることによって、認証要求があるごとに、認証情報を生成しておく必要がない。

あるいは、認証情報生成部５０７は、認証情報を予め生成しない。したがって、記憶制御部５１３は、認証情報を認証情報記憶部５０９に記憶させない。そして、認証要求を受信した際に、はじめて、認証情報の生成方式に基づいて認証情報を生成して、生成した認証情報に基づいて認証をおこなうようにしてもよい。

このように、認証情報は、予め生成して記憶手段に記憶させておいても良いが、認証要求を受信したときに定められた認証情報の生成方式に基づいて認証情報を生成する（予め記憶しない）ようにしてもよい。したがって、そのように構成する場合には、認証情報記憶部５０９は設けなくてもよい。

つぎに、利用者によっては、取引の際に、預金通帳１２３を所持しないことが想定される。このようなことに鑑み、取引において預金通帳１２３を用いたか否かにかかわらず、取引履歴を利用者端末１２１に記憶可能にすることについて説明する。

具体的には、ＡＴＭ１３１において、利用者が取引を終える際に、出力制御部５１１は、預金通帳１２３に印字された情報と、預金通帳１２３に印字されていない情報とを区別させるための付加情報を、取引履歴とともに所定の端末に表示可能にするための制御をおこなえばよい。

付加情報は、預金通帳１２３に印字された情報に対して、「記帳済」の文字を付す旨の情報や、記帳済を示すマークを付す旨の情報であってもよい。また、付加情報は、預金通帳１２３に印字された情報と、預金通帳１２３に印字されていない情報とを異なる表示態様とする旨の情報であってもよい。所定の端末は、たとえば、利用者端末１２１である。

出力制御部５１１は、付加情報と取引履歴とを、たとえば、利用者端末１２１が読取可能なＱＲコードによって出力してもよい。利用者端末１２１は、ディスプレイに表示されたＱＲコードを、利用者端末１２１が備えるリーダ（カメラ）で読み取ることにより、付加情報と取引履歴とを、利用者端末１２１のメモリ２２２に記憶すればよい。そして、利用者端末１２１は、メモリ２２２に記憶した付加情報と取引履歴とを用いて、預金通帳１２３に印字された情報と、預金通帳１２３に印字されていない情報とを区別して表示すればよい。

これにより、利用者は、ＡＴＭ１３１において取引をおこなった際に、取引履歴を利用者端末１２１に記憶させることができる。このため、利用者は、以降に取引をおこなう際に、預金通帳１２３を所持していなくても、利用者端末１２１に記憶された取引履歴を閲覧して、認証情報を容易に把握することができる。

また、出力制御部５１１は、付加情報と取引履歴とを、ＱＲコードによって出力することに限らず、予め登録された利用者端末１２１へ電子メールやＳＮＳ（Ｓｏｃｉａｌ Ｎｅｔｗｏｒｋｉｎｇ Ｓｅｒｖｉｃｅ）等で送信してもよい。具体的には、出力制御部５１１は、端末通信部５１２を制御して、予め登録された利用者端末１２１へ付加情報と取引履歴とを送信させる制御をおこなえばよい。

この場合、利用者端末１２１は、銀行サーバ１１１から受信した付加情報と取引履歴とをメモリ２２２に記憶すればよい。また、利用者端末１２１は、メモリ２２２に記憶した付加情報と取引履歴とを用いて、預金通帳１２３に印字された情報と、預金通帳１２３に印字されていない情報とを区別して表示すればよい。

これにより、利用者は、ＡＴＭ１３１において取引をおこなった際に、取引履歴を利用者端末１２１に記憶させることができる。このため、利用者は、以降に取引をおこなう際に、預金通帳１２３を所持していなくても、利用者端末１２１に記憶された取引履歴を閲覧して、認証情報を容易に把握することができる。

つぎに、銀行サーバ１１１は、利用者端末１２１から送信要求に応じて取引履歴を利用者端末１２１へ送信する場合について説明する。まず、利用者の操作により、利用者端末１２１が、銀行サーバ１１１へ取引履歴の送信要求をおこなう。送信要求は、たとえば、ＳＮＳでおこなわれる。このＳＮＳは、たとえば、本認証情報生成システム１００の利用にかかる登録時に、利用者端末１２１および銀行サーバ１１１の双方の認証がおこなわれている。このため、利用者は、ＳＮＳを利用する際に、ログインやパスワードの入力などを要しない。

端末通信部５１２は、利用者端末１２１から取引履歴の送信要求を受信する。出力制御部５１１は、端末通信部５１２によって取引履歴の送信要求が受信された場合に、取引履歴を利用者端末１２１に送信する制御をおこなう。利用者端末１２１に送信する取引履歴は、直近の記帳情報を含む。

また、利用者端末１２１に送信する取引履歴は、直近の記帳情報のほかに、他の記帳情報を含んでもよいし、預金通帳１２３に印字されていない情報を含んでもよい。ただし、取引履歴に、預金通帳１２３に印字されていない情報が含まれる場合、出力制御部５１１は、取引履歴と付加情報とを利用者端末１２１に送信すればよい。

出力制御部５１１の制御により、端末通信部５１２は、取引履歴を利用者端末１２１へ送信する。端末通信部５１２は、たとえば、ＳＮＳで取引履歴を利用者端末１２１へ送信する。利用者端末１２１は、銀行サーバ１１１から受信した取引履歴を表示する。取引履歴に、預金通帳１２３に印字されていない情報が含まれる場合、利用者端末１２１は、預金通帳１２３に印字された情報と、預金通帳１２３に印字されていない情報とを区別して表示すればよい。

これにより、利用者は、預金通帳１２３を所持していなくても、銀行サーバ１１１から受信した取引履歴を閲覧して、認証情報を容易に把握することができる。

なお、ＳＮＳに限らず、利用者が銀行サーバ１１１の所定のサイトにアクセスすることにより、取引履歴を閲覧することも可能である。具体的には、利用者端末１２１は、所定のサイトにアクセスし、利用者から受け付けたログインＩＤやログインパスワードを銀行サーバ１１１に送信し、銀行サーバ１１１における認証に成功することにより、取引履歴を受信することができる。これにより、利用者端末１２１は、銀行サーバ１１１から受信した取引履歴を、利用者端末１２１のメモリ２２２に記憶させることも可能である。

端末通信部５１２は、銀行サーバ１１１の通信ＩＦ２１３によって実現される。出力制御部５１１は、銀行サーバ１１１のメモリ２１２に記憶されたプログラムをＣＰＵ２１１に実行させることにより、その機能を実現する。

（利用者端末１２１に記憶される取引履歴の表示例）
つぎに、図６Ａを用いて、利用者端末１２１に表示される取引履歴の表示例について説明する。図６Ａは、利用者端末１２１に表示される取引履歴の表示例を示す説明図である。図６Ａの表示画面６００は、取引履歴６０１〜６０４の一覧を示す。各取引履歴６０１〜６０４は、それぞれ、取引をおこなった日時と、取引の内容と、記帳の有無と、取引額と、残額とを示す。

取引履歴６０１〜６０４は、たとえば、利用者端末１２１のメモリ２１２に記憶された情報である。取引履歴６０１〜６０４は、たとえば、取引終了時にＡＴＭ１３１のディスプレイに表示されるＱＲコードを利用者端末１２１に読み取られたり、取引終了時に銀行サーバ１１１から利用者端末１２１に送信されたりすることにより、利用者端末１２１のメモリ２１２に記憶された情報である。

認証情報を残額の下４桁とする設定となっていたとすると、利用者は、直近に記帳した内容である取引履歴６０３を閲覧することにより、残額「￥９６，４９０」の下４桁「６４９０」が認証情報であることを把握することができる。

（利用者端末１２１がＳＮＳにより取得した直近の記帳情報の表示例）
つぎに、図６Ｂを用いて、利用者端末１２１がＳＮＳにより取得した直近の記帳情報の表示例について説明する。図６Ｂは、利用者端末１２１がＳＮＳにより取得した直近の記帳情報の表示例を示す説明図である。図６Ｂの表示画面６１０は、ＳＮＳのメッセージを示す。

メッセージ６１１は、利用者から銀行サーバ１１１への、記帳情報の送信要求を示す。メッセージ６１１は、たとえば、予め複数の定型文が用意されており、利用者がいずれか一つを選択可能であってもよい。メッセージ６１２は、メッセージ６１１に対する銀行サーバ１１１の回答である。メッセージ６１１を定型文とした場合、銀行サーバ１１１は、受信した定型文に応じた回答を利用者ごとにおこなえばよい。

認証情報を残額の下４桁とする設定となっていたとすると、利用者は、メッセージ６１２を閲覧することにより、残額「￥９６，４９０」の下４桁「６４９０」が認証情報であることを把握することができる。

（銀行サーバ１１１がおこなう認証情報生成処理手順の一例）
つぎに、図７を用いて、銀行サーバ１１１がおこなう認証情報生成処理手順の一例について説明する。図７は、銀行サーバ１１１がおこなう認証情報生成処理手順の一例を示すフローチャートである。

図７において、銀行サーバ１１１は、預金通帳１２３が記帳されたか否かを判断する（ステップＳ７０１）。預金通帳１２３が記帳されたとは、ＡＴＭ１３１において預金通帳１２３への記帳がおこなわれて、記帳したことを示す記帳情報を、ＡＴＭ１３１から受信することである。銀行サーバ１１１は、預金通帳１２３が記帳されるまで待つ（ステップＳ７０１：Ｎｏ）。

銀行サーバ１１１は、預金通帳１２３が記帳された場合（ステップＳ７０１：Ｙｅｓ）、取引情報ＤＢ１１３（図３Ｂを参照）に記憶される、認証情報の生成方式を参照する（ステップＳ７０２）。そして、銀行サーバ１１１は認証情報を生成する設定となっているか否かを判断する（ステップＳ７０３）。

銀行サーバ１１１は、認証情報を生成する設定となっていない場合（ステップＳ７０３：Ｎｏ）、具体的には、取引情報ＤＢ１１３に記憶される「認証情報の生成方式」が記憶されていない場合、そのまま一連の処理を終了する。

一方、銀行サーバ１１１は、認証情報を生成する設定となっている場合（ステップＳ７０３：Ｙｅｓ）、具体的には、取引情報ＤＢ１１３の「認証情報の生成方式」のフィールドに「下４桁」や「上４桁」等が記憶されている場合、記帳された残額と、参照した生成方式とに基づいて、以降の取引に用いられる認証情報を生成する（ステップＳ７０４）。

つぎに、銀行サーバ１１１は、取引情報ＤＢ１１３に、生成した認証情報を記憶し（ステップＳ７０５）、一連の処理を終了する。取引情報ＤＢ１１３に記憶された認証情報は、次回以降の取引において用いられる。

上述した処理によれば、預金通帳１２３が記帳されるたびに、残額に応じた認証情報に、認証情報を更新することができる。これにより、カード１２２を用いた取引のセキュリティを向上させることができる。

（銀行サーバ１１１がおこなう取引履歴の出力処理手順の一例）
つぎに、図８を用いて、銀行サーバ１１１がおこなう取引履歴の出力処理手順の一例について説明する。図８は、銀行サーバ１１１がおこなう取引履歴の出力処理手順の一例を示すフローチャートである。

図８において、銀行サーバ１１１は、取引履歴を出力するタイミングであるか否かを判断する（ステップＳ８０１）。取引履歴を出力するタイミングとは、たとえば、利用者端末１２１からの取引履歴の送信要求を受信したタイミングである。ただし、取引履歴を出力するタイミングとは、これに限らず、取引終了時に取引履歴をＱＲコードで出力するタイミングや、取引終了時に利用者端末１２１に取引履歴を送信するタイミングなどであってもよい。

銀行サーバ１１１は、取引履歴を出力するタイミングとなるまで待つ（ステップＳ８０１：Ｎｏ）。銀行サーバ１１１は、取引履歴を出力するタイミングとなった場合（ステップＳ８０１：Ｙｅｓ）、取引情報ＤＢ１１３（図３Ｂを参照）に記憶される、取引日時、取引内容、取引金額、残額を含む、取引履歴を取得する（ステップＳ８０２）。

そして、銀行サーバ１１１は、取引履歴を出力し（ステップＳ８０３）、一連の処理を終了する。取引履歴の出力は、利用者端末１２１へ取引履歴を送信することである。ただし、取引履歴の出力は、これに限らず、取引終了時においてＱＲコードで取引履歴を出力することとしてもよいし、取引終了時に利用者端末１２１に取引履歴を送信することとしてもよい。

（認証情報の生成の他の例）
つぎに、図９Ａおよび図９Ｂを用いて、認証情報の生成の他の例について説明する。図９Ａは、認証情報の生成の他の例を示す図（その１）である。

図９Ａに示すように、取引一覧９００は、預金通帳１２３に記帳された取引履歴９０１〜９０５を示す。取引履歴９０１〜９０５は、５回の取引があったことを示す。取引一覧９００は、記帳された段数が４段以上ある。このため、たとえば、特定の桁に該当する数字を縦方向に選択して認証情報とすることも可能である。

具体的には、たとえば、４段の取引履歴９０２〜９０５について説明すると、上段から下段にかけて「￥８６，０７９」、「￥８２，８１１」、「￥７７，８１１」、「￥７５，３８０」の残額の記帳がある。また、たとえば、１桁目を下段から上段に向けて選択するものとする。この場合、認証情報は、各残額の１桁目を下段から上段に向けて選択した「０１１９」とすればよい。

また、特定の桁に該当する数字を縦方向に選択して認証情報とする場合、預金通帳１２３において、最後に記帳が埋まったページ（改ページをおこなう前のページ）の最下段から下４段目までに記載された数字を用いることとしてもよい。これにより、数字を縦方向に選択することとする場合、利用者が参照するページが複数のページに跨がることがないため、利用者にとって、認証情報が把握しにくくなることを抑えることができる。

また、認証情報の更新の頻度を、改ページとなる頻度に応じた頻度とすることができ、具体的には、１ページ内の段数（たとえば２０段）に相当する取引回数（２０回）に応じた頻度（２０回に１回）とすることができる。

図９Ｂは、認証情報の生成の他の例を示す図（その２）である。なお、図９Ｂにおいて、図９Ａと同様の内容については同様の符号を付し、説明を省略する。図９Ｂにおいては、預金通帳１２３に記帳された日付の情報を選択して、認証情報を生成する場合について説明する。

具体的には、預金通帳１２３に記帳された直近の取引履歴９０５が示すように、日付が「１７年１２月２９日」である場合には、月に該当する数字「１２」と、日に該当する数字「２９」とを選択し、「１２２９」を認証情報としてもよい。また、取引履歴９０５の日付から生成される認証情報は、これに限らず、年に該当する数字「１７」と、月に該当する数字「１２」とを選択し、「１７１２」としてもよい。また、選択した数字の並べ方は予め設定した任意の並べ方としてもよい。

以上説明したように、実施の形態１にかかる銀行サーバ１１１によれば、利用者が閲覧可能な取引履歴に基づいて、以降の取引において用いられる認証情報を生成して、記憶するため、取引履歴に応じて認証情報を更新することができる。これにより、利用者は、認証情報を覚えていなくても、取引履歴を見るだけで、認証情報を容易に把握することができる。

ここで、セキュリティを向上させる手法として、生体情報を用いて認証をおこなう手法もある。生体情報を用いた認証をおこなう場合には、ＡＴＭ１３１が生体情報に対応している必要がある。仮に、ＡＴＭ１３１が生体情報に対応していない場合には、ＡＴＭ１３１に生体情報を読み取る機能を付加させたり、ＡＴＭ１３１自体を取り替えたりする必要があるため、手間やコストがかかる。また、生体情報が盗まれてしまうと、第三者による不正な取引がおこなわれる懸念もある。

これに対して、実施の形態１にかかる銀行サーバ１１１によれば、生体情報を用いないため、生体情報が盗まれるおそれがなく、また、生体情報に対応していないＡＴＭ１３１を用いることができる。また、実施の形態１にかかる銀行サーバ１１１によれば、利用者が銀行１１０の店舗に出向かずに、認証情報を随時更新することができるため、利用者や銀行１１０のスタッフの手間を抑え、迅速且つ簡単に、認証情報を変更することができる。

したがって、実施の形態１にかかる銀行サーバ１１１によれば、取引の利便性が低下することを抑えつつ、カード１２２を用いた取引のセキュリティを簡単に向上させることができる。特に、実施の形態１にかかる銀行サーバ１１１によれば、利用者が認証情報を覚える必要がないため、認証情報を失念しやすい高齢者などの利用者に効果的である。

また、実施の形態１にかかる銀行サーバ１１１は、預金通帳１２３に印字された情報に基づいて、銀行１１０における以降の取引において用いられる認証情報を生成することとした。

これにより、利用者は、認証情報を覚えていなくても、利用者が所持する預金通帳１２３を見るだけで、認証情報を容易に把握することができる。たとえば高齢者など、利用者端末１２１を所有していない利用者や、利用者端末１２１に取引履歴を表示させることが煩雑であると感じる利用者でも、預金通帳１２３を見るだけで、認証情報を容易に把握することができる。

また、実施の形態１にかかる銀行サーバ１１１は、預金通帳１２３に印字された直近の記帳情報に基づいて、認証情報を生成することとした。これにより、銀行サーバ１１１は、預金通帳１２３への記帳がおこなわれるごとに認証情報を更新することができる。したがって、利用者は、直近の記帳情報だけを閲覧すればよいため、認証情報を容易に把握することができる。また、認証情報の更新の頻度を高めることができるため、セキュリティをより向上させることができる。

また、実施の形態１にかかる銀行サーバ１１１は、預金通帳１２３に印字された記帳情報が示す金額の中から、予め設定された複数の桁に該当する数字をそれぞれ選択して認証情報を生成することとした。これにより、銀行サーバ１１１は、たとえば、下４桁や上４桁といった利用者にとって把握しやすい数字の列を認証情報とすることができる。このため、利用者は、認証情報を容易に把握することができる。

また、実施の形態１にかかる銀行サーバ１１１は、利用者による設定に応じて、取引履歴に基づく認証情報の生成をおこなうこととした。このため、銀行サーバ１１１は、利用者ごとに、取引履歴に基づく認証情報の生成をおこなったり、おこなわないようにしたりすることができる。

また、実施の形態１にかかる銀行サーバ１１１は、利用者による設定に応じた認証情報の生成方式とした。このため、利用者が所望する生成方式を設定することができるため、預金通帳１２３やカード１２２が盗まれたり、紛失したりしたとしても、第三者が認証情報の生成方式を把握することをより困難にすることができる。したがって、銀行サーバ１１１によれば、セキュリティをより向上させることができる。

また、実施の形態１にかかる銀行サーバ１１１は、預金通帳１２３に印字された記帳情報と、預金通帳１２３に印字されていない情報とを区別させるための付加情報を、取引履歴とともに利用者端末１２１に表示可能にするための制御をおこなうこととした。これにより、利用者は、預金通帳１２３を所持していなくても、利用者端末１２１に表示される取引履歴を閲覧することができる。また、利用者は、どこまでの取引が記帳されているのかを容易に把握することができるため、認証情報を覚えていなくても、認証情報を容易に把握することができる。

（実施の形態２）
つぎに、この発明にかかる認証情報生成装置、認証情報生成方法、および認証情報生成プログラムの実施の形態２について、説明する。実施の形態１では、銀行のキャッシュカードの認証情報（暗証番号）を生成する場合について説明した。実施の形態２では、クレジットカードの認証情報（暗証番号）を生成する場合について説明する。なお、以下の説明において、実施の形態１で説明した内容と同様の内容については同様の符号を付し、説明を省略する。

（認証情報生成システムのシステム構成）
実施の形態２にかかる認証情報生成システム１０００のシステム構成例について説明する。図１０は、実施の形態２にかかる認証情報生成システム１０００のシステム構成例を示す説明図である。図１０において、認証情報生成システム１０００は、カード会社サーバ１０１１と、利用者端末１２１と、カード１０２２と、利用明細書１０２３と、店舗端末１０３１と、を有する。

カード会社サーバ１０１１は、この発明にかかる認証情報生成装置の一例である。カード会社サーバ１０１１は、カード会社１０１０に設けられるサーバである。具体的には、カード会社サーバ１０１１は、利用者ごとのクレジットカードの利用限度額や現在の利用額等を管理する汎用的なコンピュータ装置である。カード会社サーバ１０１１は、たとえば、ＣＰＵやメモリやインタフェースなどを有するパーソナルコンピュータである。また、カード会社サーバ１０１１は、カード情報ＤＢ１０１２と、取引情報ＤＢ１０１３とを有する。各種ＤＢ１０１２，１０１３の記憶内容については、図１１Ａおよび図１１Ｂを用いて後述する。

カード１０２２は、カード会社１０１０が発行したクレジットカードである。利用明細書１０２３は、所定期間（たとえば１ヶ月）に１回、カード会社１０１０によって発行される。利用明細書１０２３は、クレジットカードを用いた決済（以下「カード決済」という）がおこなわれた１ヶ月の明細書である。

店舗端末１０３１は、クレジットカードの決済機能を備え、決済用のネットワークを介して、インターネットなどのネットワーク１４０に接続されている。店舗端末１０３１は、カード決済にかかる各種の処理をおこなう。店舗端末１０３１は、カード決済にかかる各種の処理の実行に際して、カード会社サーバ１０１１との間で通信をおこなう。

また、店舗端末１０３１は、利用者とカード会社サーバ１０１１とのインタフェースをつかさどり、カード１０２２の利用状況を利用者に通知する。また、たとえば、店舗端末１０３１は、カード決済をおこなうごとにカード１０２２の利用状況を利用者に通知する。

店舗端末１０３１は、購入する商品についての会計をおこなうレジスタや、カード１０２２のカード情報を読み取るカードリーダや、カード会社サーバ１０１１に対してカード情報等を送受信する通信部などを備える。店舗端末１０３１は、具体的には、たとえばＣＡＴ（Ｃｒｅｄｉｔ Ａｕｔｈｏｒｉｚａｔｉｏｎ Ｔｅｒｍｉｎａｌ）端末やＰＯＳ（Ｐｏｉｎｔ Ｏｆ Ｓａｌｅｓｓｙｓｔｅｍ）端末などのクレジットカードの信用照会端末などによって実現することができる。

認証情報生成システム１０００において、カード会社サーバ１０１１と、利用者端末１２１と、店舗端末１０３１とは、有線または無線のネットワーク１４０を介して接続される。

（各種ＤＢ１０１２，１０１３の記憶内容）
つぎに、図１１Ａおよび図１１Ｂを用いて、図１０に示したカード会社サーバ１０１１が有するカード情報ＤＢ１０１２および取引情報ＤＢ１０１３の記憶内容について説明する。各種ＤＢ１０１２，１０１３は、たとえば、メモリなどの記憶部により実現される。

図１１Ａは、カード情報データベース（ＤＢ）１０１２の記憶内容の一例を示す説明図である。図１１Ａにおいて、カード情報ＤＢ１０１２は、カード番号、名義人、利用者端末情報、有効期限、セキュリティコード、限度額、および現在までの利用額のフィールドを有する。各フィールドに情報を設定することで、カード情報（たとえば、カード情報１１００−１，１１００−２）のレコードが記憶される。

カード番号は、カード１０２２に記載される、たとえば１６桁の数字である。名義人は、カード１０２２の名義人を示す。利用者端末情報は、たとえば、名義人が有する利用者端末１２１のアドレス情報である。有効期限は、カード１０２２の利用可能な期限を示す。セキュリティコードは、たとえば、カード１０２２の裏面に記載される３桁の数字である。

限度額は、一定期間内（たとえば１ヶ月間）においてカード１０２２を用いて支払をおこなうことのできる上限額を示す。また、現在までの利用額は、一定期間の開始（たとえば月初）から現在までの間にカード１０２２を用いて支払をおこなった額の総額を示す。現在までの利用額は、カード１０２２を用いて支払をおこなうたびに更新される。

たとえば、カード情報１１００−１は、カード番号「１２３４…」、名義人「総研総太郎」、利用者端末情報「ＸＸＸ・・・＠ｘｘｘ」、有効期限「○○年○○月」、セキュリティコード「○○○」、限度額「￥○○万」、現在までの利用額「￥○○○○」を示す。なお、不図示であるが、現金を融資するキャッシングの利用が可能である場合には、キャッシングについての情報（限度額や現在までの利用額）もカード情報ＤＢ１０１２に記憶される。

カード情報ＤＢ１０１２に示す、カード番号、名義人、利用者端末情報、有効期限、セキュリティコード、および限度額については、カード１０２２を新規に作成する際に、利用者の申告やカード会社の審査結果に応じて設定される。なお、カード情報ＤＢ１０１２において、図示したフィールドのほかにも、名義人の住所、電話番号、生年月日等のフィールドを設けてもよい。

図１１Ｂは、実施の形態２にかかる取引情報データベース（ＤＢ）１０１３の記憶内容の一例を示す説明図である。図１１Ｂにおいて、取引情報ＤＢ１０１３は、カード番号、氏名、取引日時、前月度の請求金額、認証情報の生成方式、および翌月の認証情報のフィールドを有する。各フィールドに情報を設定することで、取引情報（たとえば、取引情報１１１０−１〜１１１０−４）のレコードが記憶される。

カード番号は、カード１０２２に記載される、たとえば１６桁の数字であり、カード情報ＤＢ１０１２（図１１Ａを参照）に記憶されるカード番号と同一である。このため、カード情報ＤＢ１０１２のカード情報１１００と取引情報１１１０とは、カード番号によって対応付けられている。

また、取引情報ＤＢ１０１３において、氏名は、カード情報ＤＢ１０１２のカード情報１１００に含まれる名義人と同一である。取引日時は、カード１０２２を用いてカード決済をおこなった日付を示す。前月度の請求金額は、前月度にカード決済をおこなった金額を示す。

認証情報の生成方式は、前月度の請求金額を用いて４桁の認証情報（暗証番号）を生成する際の方式を示す。認証情報の生成方式は、たとえば、前月度の請求金額の「下４桁」や「上４桁」などを設定することが可能である。翌月の認証情報は、翌月の取引において用いられる認証情報（暗証番号）を示す。

翌月の認証情報は、前月度の請求金額と、認証情報の生成方式とに基づいて生成される。翌月の認証情報の生成について、取引情報１１１０−１を例に挙げて説明すると、翌月の認証情報は、前月度の請求金額が「￥１１３，４３１」であり、認証情報の生成方式が「下４桁」であるため、前月度の請求金額「￥１１３，４３１」の「下４桁」である「３４３１」となる。すなわち、翌月の取引において用いられる認証情報は、「３４３１」となる。

ここで、たとえば、取引情報１１１０−１は、カード番号「１２３４…」、氏名「総研総太郎」、取引日時「２０１７年９月」、前月度の請求金額「￥１１３，４３１」、認証情報の生成方式「下４桁」、認証情報「３４３１」を示す。また、取引情報１１１０−１以外の取引情報１１１０−２〜１１１０−４についても、同様に、取引情報ＤＢ１０１３に記憶される。

（実施の形態２にかかる認証情報の生成例）
つぎに、図１２を用いて、実施の形態２にかかる認証情報の生成例について説明する。図１２は、実施の形態２にかかる認証情報の生成例を示す図である。以下に示す括弧書きの番号は、図１２に示す括弧書きの番号と対応する。

図１２に示すように、（１）２０１７年１０月のカード決済による請求金額が￥８４，５０２であったとする。このため、利用明細書１０２３には、￥８４，５０２が印字されている。請求金額が￥８４，５０２であることから、たとえば、下４桁の認証情報である「４５０２」が翌月の認証情報（暗証番号）となる。

また、（２）２０１７年１１月のカード決済による請求金額が￥９０，６８３であったとする。このため、利用明細書１０２３には、￥９０，６８３が印字されている。請求金額が￥９０，６８３であることから、たとえば、下４桁の認証情報である「０６８３」が翌月の認証情報（暗証番号）となる。

図１２に説明したように、実施の形態２では、利用明細書１０２３に印字された請求金額と、所定の認証情報の生成方式とに基づいて、翌月の取引に用いられる認証情報が生成される。このため、認証情報を随時更新することができるとともに、利用者が認証情報を覚えていなくても、利用明細書１０２３を見るだけで、認証情報を容易に把握することができる。したがって、取引の利便性が低下することを抑えつつ、カード１０２２を用いた取引のセキュリティを簡単に高めることができる。

（認証情報生成システム１０００の機能的構成）
図１３は、実施の形態２にかかる認証情報生成システム１０００の機能的構成を示す説明図である。図１３において、認証情報生成システム１０００は、カード会社サーバ１０１１と、利用者端末１２１と、店舗端末１０３１とを備える。

カード会社サーバ１０１１は、取引情報通信部１３０１と、取引制御部１３０２と、認証情報記憶部１３０３と、カード情報記憶部１３０４と、取引履歴記憶部１３０５と、取引履歴取得部１３０６と、認証情報生成部１３０７と、生成方式記憶部１３０８と、出力制御部１３０９と、端末通信部１３１０と、記憶制御部１３１１とを備える。

店舗端末１０３１は、取引情報入力部１３２１と、取引情報通信部１３２２とを備える。ここで、利用者が、店舗において、カード１０２２を用いてカード決済をおこなう場合について説明する。店舗端末１０３１の取引情報入力部１３２１は、取引情報を入力する。取引情報は、挿入されたカード１０２２から読み取ったカード情報や、店員から入力される支払額の情報および支払方法に関する情報や、利用者から入力される認証情報（暗証番号）などである。

ここで、詳細については、後述するが、認証情報は、たとえば、利用明細書１０２３に記載された、前月度の請求金額に基づいて生成される。このため、利用者は、利用明細書１０２３に記載された、前月度の請求金額を閲覧して、所定の生成方式で生成される認証情報を確認してから、今回の取引における認証情報を入力する。

ここで、図示を省略するが、店舗端末１０３１のハードウエア構成は、図２Ｂに示したＡＴＭ１３１のハードウエア構成と同様である。ただし、店舗端末１０３１の場合、上述した入力デバイス２２４は、バーコードリーダを含む。バーコードリーダは、商品名や商品番号や価格などの商品に関する情報がコード化されたバーコードを読み取る。上述した取引情報入力部１３２１は、店舗端末１０３１の入力デバイスによって実現される。

取引情報通信部１３２２は、取引情報入力部１３２１に入力された取引情報をカード会社サーバ１０１１へ送信する。取引情報通信部１３２２は、店舗端末１０３１の通信ＩＦによって実現される。

取引情報通信部１３２２から取引情報がカード会社サーバ１０１１へ送信されると、カード会社サーバ１０１１の取引情報通信部１３０１は、取引情報を受信する。取引情報通信部１３０１は、店舗端末１０３１から受信した取引情報を取引制御部１３０２へ出力する。

ここで、図示を省略するが、カード会社サーバ１０１１のハードウエア構成は、図２Ａに示した銀行サーバ１１１のハードウエア構成と同様である。取引情報通信部１３０１は、カード会社サーバ１０１１の通信ＩＦによって実現される。

取引制御部１３０２は、取引情報通信部１３０１から取引情報が入力されると、当該取引情報に含まれる、利用者から受け付けた認証情報が、各利用者の認証情報を記憶する認証情報記憶部１３０３に記憶されているか否かの一致判定（認証）をおこなう。当該一致判定において、否定の判定結果が得られた場合（認証に失敗した場合）、取引制御部１３０２は、認証に失敗した旨を示す取引結果を取引情報通信部１３０１へ出力する。

一方、一致判定において、肯定の判定結果が得られた場合（認証に成功した場合）、取引制御部１３０２は、与信照会をおこなう。与信照会は、カード情報記憶部１３０４に記憶されるカード情報を参照して、クレジットカードの月々の利用可能な金額を示す与信枠のうち、支払額分の空きがあるか否かの照会である。

与信照会において、与信枠に支払額分の空きがない場合、取引制御部１３０２は、その旨を示す取引結果を取引情報通信部１３０１へ出力する。一方、与信照会において、与信枠に支払額分の空きがある場合、取引制御部１３０２は、支払額分を確保して、支払方法に関する情報が示す支払方法により、カード決済を完了させる。そして、取引制御部１３０２は、カード決済を完了させた旨を示す取引結果を取引情報通信部１３０１へ出力する。

取引制御部１３０２は、カード会社サーバ１０１１のメモリに記憶されたプログラムをＣＰＵに実行させることにより、その機能を実現する。認証情報記憶部１３０３およびカード情報記憶部１３０４は、カード会社サーバ１０１１のメモリによって実現される。具体的には、認証情報記憶部１３０３は、取引情報ＤＢ１０１３（図１１Ｂを参照）によって実現される。また、カード情報記憶部１３０４は、カード情報ＤＢ１０１２（図１１Ａを参照）によって実現される。ただし、認証情報記憶部１３０３およびカード情報記憶部１３０４は、カード会社サーバ１０００に設けられずに、外部の他の装置に設けられていてもよい。

取引情報通信部１３０１は、取引制御部１３０２から取引結果が入力されると、入力された取引結果を店舗端末１０３１へ送信する。取引情報通信部１３０１から取引結果が店舗端末１０３１へ送信されると、店舗端末１０３１の取引情報通信部１３２２は、取引結果を受信する。取引情報通信部１３２２によって取引結果が受信されると、店舗端末１０３１は、当該取引結果をディスプレイに表示したり、印字出力をおこなったりする。

また、取引制御部１３０２は、カード情報記憶部１３０４を参照して、毎月のクレジットカードの利用金額（請求金額）を取引履歴記憶部１３０５に記憶させる。取引履歴記憶部１３０５は、カード会社サーバ１０１１のメモリによって実現される。具体的には、取引履歴記憶部１３０５は、取引情報ＤＢ１０１３（図１１Ｂを参照）によって実現される。

取引履歴取得部１３０６は、取引履歴記憶部１３０５から、取引履歴を取得する。取引履歴は、利用者が閲覧可能な取引に関する履歴である。利用者が閲覧可能とは、利用明細書１０２３に記載されることによって閲覧可能であることや、利用者端末１２１に表示されることによって閲覧可能であることである。取引履歴は、利用明細書１０２３に印字された情報を含む。具体的には、取引履歴は、たとえば、日付、前月度の請求金額、購入先、といった情報を含む。

認証情報生成部１３０７は、取引履歴取得部１３０６によって取得された取引履歴に基づいて、翌月の取引において用いられる認証情報を生成する。取引履歴取得部１３０６によって取得された取引履歴は、たとえば、利用明細書１０２３に印字された情報（以下「記載情報」という）である。特に、記載情報は、前月度の利用明細書１０２３に印字された記載情報である。

この場合、取引履歴取得部１３０６は、前月度の記載情報を取得する。たとえば、取引履歴取得部１３０６は、利用者が前月度の利用明細書１０２３を受領した以降の、予め設定した所定の期日（認証情報を変更する期日）に取引履歴を取得してもよい。認証情報生成部１３０７は、取引履歴取得部１３０６によって取得された前月度の記載情報に基づいて、認証情報を生成する。

認証情報生成部１３０７は、生成方式記憶部１３０８に記憶される、予め設定された生成方式により認証情報を生成する。具体的には、認証情報生成部１３０７は、利用明細書１０２３に印字された記載情報が示す請求金額の中から、予め設定された複数の桁に該当する数字をそれぞれ選択して認証情報を生成する。

具体的には、認証情報生成部１３０７は、請求金額のうち、予め設定された複数の桁（認証情報の桁）に該当する数字をそれぞれ選択して認証情報を生成する。たとえば、認証情報が４桁の数字であれば、認証情報生成部１３０７は、下４桁や上４桁といった数字を選択して認証情報を生成する。

記憶制御部１３１１は、認証情報生成部１３０７によって生成された認証情報を認証情報記憶部１３０３に記憶させる。また、ある月において利用者がカード決済を一度もおこなわず、請求金額がない場合、認証情報生成部１３０７は、認証情報を生成しないでもよい。この場合、認証情報記憶部１３０３に記憶される認証情報が変更されないため、翌月も前月の認証情報を引き継ぐこととしてもよい。

また、認証情報生成部１３０７によって生成された認証情報に切り替える時期は、利用者が取引履歴を閲覧可能となった後であり、たとえば、利用明細書１０２３を受領した後とすればよい。具体的には、たとえば、認証情報を切り替える時期は、利用者が利用明細書１０２３を受領することが想定される日以降の、任意の日を設定しておけばよい。また、カード会社サーバ１０１１は、認証情報を切り替える時期を、利用者に通知してもよく、たとえば、利用明細書１０２３へ記載したり、利用者端末１２１へ送信したりしてもよい。

認証情報生成部１３０７および記憶制御部１３１１は、カード会社サーバ１０１１のメモリに記憶されたプログラムをＣＰＵに実行させることにより、その機能を実現する。生成方式記憶部１３０８は、カード会社サーバ１０１１のメモリによって実現される。具体的には、生成方式記憶部１３０８は、取引情報ＤＢ１０１３（図１１Ｂを参照）によって実現される。ただし、生成方式記憶部１３０８は、カード会社サーバ１０００に設けられずに、外部の他の装置に設けられていてもよい。

このように、認証情報は、認証情報生成部１３０７が、予め生成しておいて、記憶制御部１３１１が、認証情報生成部１３０７によって生成された認証情報を認証情報記憶部１３０３に記憶させておく。そして、認証要求を受信した際には、認証情報記憶部１３０３に記憶されている認証情報を抽出して、抽出された認証情報に基づいて認証をおこなうようにする。このようにすることによって、認証要求があるごとに、認証情報を生成しておく必要がない。

あるいは、認証情報生成部１３０７は、認証情報を予め生成しない。したがって、記憶制御部１３１１は、認証情報を認証情報記憶部１３０３に記憶させない。そして、認証要求を受信した際に、はじめて、認証情報の生成方式に基づいて認証情報を生成して、生成した認証情報に基づいて認証をおこなうようにしてもよい。

このように、認証情報は、予め生成して記憶手段に記憶させておいても良いが、認証要求を受信したときに定められた認証情報の生成方式に基づいて認証情報を生成する（予め記憶しない）ようにしてもよい。したがって、そのように構成する場合には、認証情報記憶部１３０３は設けなくてもよい。

つぎに、利用者によっては、カード１０２２を利用する際に、利用明細書１０２３を所持しないことが想定される。このようなことに鑑み、利用明細書１０２３に記載される取引履歴を利用者端末１２１に記憶可能にすることについて説明する。

たとえば、出力制御部１３０９は、カード会社１０１０から利用者に毎月の利用明細書１０２３を発送する時期などの所定の期日に、予め登録された利用者端末１２１へ電子メールやＳＮＳ（Ｓｏｃｉａｌ Ｎｅｔｗｏｒｋｉｎｇ Ｓｅｒｖｉｃｅ）等で、利用明細書１０２３に記載される内容の取引履歴を送信してもよい。具体的には、出力制御部１３０９は、所定の期日に、端末通信部１３１０を制御して、予め登録された利用者端末１２１へ、１ヶ月分の取引履歴を送信させる制御をおこなえばよい。

この場合、利用者端末１２１は、カード会社サーバ１０１１から受信した取引履歴をメモリに記憶すればよい。また、利用者端末１２１は、メモリに記憶した取引履歴を表示すればよい。

これにより、利用者は、利用明細書１０２３に記載される取引履歴を利用者端末１２１に記憶させることができる。このため、利用者は、取引をおこなう際に、利用明細書１０２３を所持していなくても、利用者端末１２１に記憶された取引履歴を閲覧して、認証情報を容易に把握することができる。

端末通信部１３１０は、カード会社サーバ１０１１の通信ＩＦによって実現される。出力制御部１３０９は、カード会社サーバ１０１１のメモリに記憶されたプログラムをＣＰＵに実行させることにより、その機能を実現する。

（カード会社サーバ１０１１がおこなう認証情報生成処理手順の一例）
つぎに、図１４を用いて、カード会社サーバ１０１１がおこなう認証情報生成処理手順の一例について説明する。図１４は、カード会社サーバ１０１１がおこなう認証情報生成処理手順の一例を示すフローチャートである。

図１４において、カード会社サーバ１０１１は、認証情報を変更可能なタイミングであるか否かを判断する（ステップＳ１４０１）。認証情報を変更可能なタイミングは、利用者が利用明細書１０２３を閲覧可能となった後のタイミングであり、たとえば、予め定めた所定の期日である。カード会社サーバ１０１１は、認証情報を変更可能なタイミングとなるまで待つ（ステップＳ１４０１：Ｎｏ）。

カード会社サーバ１０１１は、認証情報を変更可能なタイミングになった場合（ステップＳ１４０１：Ｙｅｓ）、取引情報ＤＢ１０１３（図１１Ｂを参照）に記憶される、認証情報の生成方式を参照する（ステップＳ１４０２）。そして、カード会社サーバ１０１１は、認証情報を生成する設定となっているか否かを判断する（ステップＳ１４０３）。

カード会社サーバ１０１１は、認証情報を生成する設定となっていない場合（ステップＳ１４０３：Ｎｏ）、具体的には、取引情報ＤＢ１０１３の「認証情報の生成方式」のフィールドに情報が記憶されていない場合、そのまま一連の処理を終了する。

一方、カード会社サーバ１０１１は、認証情報を生成する設定となっている場合（ステップＳ１４０３：Ｙｅｓ）、具体的には、取引情報ＤＢ１０１３の「認証情報の生成方式」のフィールドに「下４桁」や「上４桁」等が記憶されている場合、請求金額と、参照した生成方式とに基づいて、翌月の取引に用いられる認証情報を生成する（ステップＳ１４０４）。

つぎに、カード会社サーバ１０１１は、取引情報ＤＢ１０１３に、生成した認証情報を記憶し（ステップＳ１４０５）、一連の処理を終了する。取引情報ＤＢ１０１３に記憶された認証情報は、たとえば、翌月の取引において用いられる。

上述した処理によれば、毎月、カード決済の請求をおこなう際に、請求金額に応じた認証情報に、認証情報を更新することができる。これにより、カード１０２２を用いた取引のセキュリティを向上させることができる。

以上説明したように、実施の形態２にかかるカード会社サーバ１０１１によれば、実施の形態１と同様の効果を奏する。特に、実施の形態２にかかるカード会社サーバ１０１１は、利用明細書１０２３に印字された情報に基づいて、クレジットカード（カード１０２２）を用いた翌月の取引において用いられる認証情報を生成することとした。

これにより、利用者は、認証情報を覚えていなくても、利用明細書１０２３を見るだけで、認証情報を容易に把握することができる。たとえば高齢者など、利用者端末１２１を所有していない利用者や、利用者端末１２１に取引履歴を表示させることが煩雑であると感じる利用者でも、利用明細書１０２３を見るだけで、認証情報を容易に把握することができる。

また、実施の形態２にかかるカード会社サーバ１０１１は、利用明細書１０２３に記載される内容の取引履歴を利用者端末１２１に送信することとした。これにより、利用者は、預金通帳１２３を所持していなくても、利用者端末１２１に表示される取引履歴を閲覧することができる。これにより、利用者は、認証情報を覚えていなくても、認証情報を容易に把握することができる。

また、実施の形態２にかかるカード会社サーバ１０１１によれば、利用者がカード会社１０１０と書類や情報のやり取りをせずに、認証情報を随時更新することができるため、利用者やカード会社１０１０のスタッフの手間を抑え、迅速且つ簡単に、認証情報を変更することができる。

したがって、実施の形態２にかかるカード会社サーバ１０１１は、クレジットカードの取引にかかる利便性が低下することを抑えつつ、クレジットカードを用いた取引のセキュリティを簡単に向上させることができる。特に、実施の形態２にかかるカード会社サーバ１０１１によれば、利用者が認証情報を覚える必要がないため、認証情報を失念しやすい高齢者などの利用者に効果的である。

また、実施の形態１，２では、この発明の認証情報生成装置を、銀行サーバ１１１やカード会社サーバ１０１１によって実現した場合について説明したが、これに限らない。たとえば、銀行サーバ１１１やカード会社サーバ１０１１以外の他の会社のサーバによっても、この発明の認証情報生成装置を実現することが可能である。また、各種カード１２２，１０２２のＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を用いて、異業種間でも各種情報を共有することが可能となる場合には、たとえば、保険会社のサーバによっても、この発明の認証情報生成装置を実現することが可能である。

なお、実施の形態１，２で説明した認証情報生成方法は、予め用意されたプログラムをパーソナルコンピュータやワークステーション等のコンピュータで実行することにより実現することができる。

また、実施の形態１，２で説明した認証情報生成プログラムは、ハードディスク、フレキシブルディスク、ＣＤ（Ｃｏｍｐａｃｔ Ｄｉｓｃ）−ＲＯＭ、ＭＯ（Ｍａｇｎｅｔｏ−Ｏｐｔｉｃａｌ ｄｉｓｋ）、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）メモリ等のコンピュータで読み取り可能な記憶媒体に記憶され、コンピュータによって記憶媒体から読み出されることによって実行される。また、認証情報生成プログラムは、インターネット等のネットワークを介して配布されてもよい。

以上のように、この発明にかかる認証情報生成装置、認証情報生成方法、および認証情報生成プログラムは、各種カードに用いられる認証情報を生成する、認証情報生成装置、認証情報生成方法、および認証情報生成プログラムに有用であり、特に、取引の利便性が低下することを抑えつつ、簡単にセキュリティを向上させる、認証情報生成装置、認証情報生成方法、および認証情報生成プログラムに適している。

１００，１０００ 認証情報生成システム
１１０ 銀行
１１１ 銀行サーバ
１１２ 口座情報ＤＢ
１１３，１０１３ 取引情報ＤＢ
１２１ 利用者端末
１２２，１０２２ カード
１２３ 預金通帳
１３１ ＡＴＭ
１４０ ネットワーク
２１０，２２０ バス
２１１，２２１ ＣＰＵ
２１２，２２２ メモリ
２１３，２２５ 通信ＩＦ
２２３ 出力デバイス
２２４ 入力デバイス
４００，１０２３ 利用明細書
５０１ 取引情報受信部
５０２，１３０２ 取引制御部
５０３ 取引結果送信部
５０４ 取引履歴受信部
５０５，１３０５ 取引履歴記憶部
５０６，１３０６ 取引履歴取得部
５０７，１３０７ 認証情報生成部
５０８，１３０８ 生成方式記憶部
５０９，１３０３ 認証情報記憶部
５１０ 口座情報記憶部
５１１，１３０９ 出力制御部
５１２，１３１０ 端末通信部
５１３，１３１１ 記憶制御部
５２１，１３２１ 取引情報入力部
５２２ 取引情報送信部
５２３ 取引結果受信部
５２４ 取引処理部
５２５ 処理結果出力部
１０１０ カード会社
１０１１ カード会社サーバ
１０１２ カード情報ＤＢ
１０３１ 店舗端末
１３０１ 取引情報通信部
１３０４ カード情報記憶部
１３２２ 取引情報通信部

Claims (9)

1. 利用者が閲覧可能な取引に関する履歴を取得する取得手段と、
   前記取得手段によって取得された前記履歴に基づいて、以降の取引において用いられる認証情報を生成する生成手段と、
   を有することを特徴とする認証情報生成装置。
2. 前記履歴は、金融機関が発行する預金通帳に印字された情報を含み、
   前記生成手段は、前記預金通帳に印字された情報に基づいて、前記金融機関における以降の取引において用いられる認証情報を生成する、
   ことを特徴とする請求項１に記載の認証情報生成装置。
3. 前記取得手段は、前記預金通帳に印字された直近の情報を取得し、
   前記生成手段は、前記取得手段によって取得された前記直近の情報に基づいて、前記認証情報を生成する、
   ことを特徴とする請求項２に記載の認証情報生成装置。
4. 前記生成手段は、前記預金通帳に印字された情報が示す金額の中から、予め設定された複数の桁に該当する数字をそれぞれ選択して前記認証情報を生成する、
   ことを特徴とする請求項２または３に記載の認証情報生成装置。
5. 前記履歴は、前記預金通帳に印字されていない情報を含み、
   前記預金通帳に印字された情報と、前記預金通帳に印字されていない情報とを区別させる付加情報を、前記履歴とともに所定の端末に表示可能にするための制御をおこなう出力制御手段を有する、
   ことを特徴とする請求項２〜４のいずれか一つに記載の認証情報生成装置。
6. 前記生成手段は、前記利用者による設定に応じて、前記履歴に基づく認証情報の生成をおこなう、
   ことを特徴とする請求項１〜５のいずれか一つに記載の認証情報生成装置。
7. 前記履歴は、カード会社が発行した決済に関する通知に印字された情報を含み、
   前記生成手段は、前記通知に印字された情報に基づいて、前記カード会社が発行したクレジットカードを用いた以降の取引において用いられる認証情報を生成する、
   ことを特徴とする請求項１に記載の認証情報生成装置。
8. 利用者が閲覧可能な取引に関する履歴を取得し、
   取得した前記履歴に基づいて、以降の取引において用いられる認証情報を生成し、
   生成した認証情報を記憶部に記憶させる、
   処理をコンピュータが実行することを特徴とする認証情報生成方法。
9. 利用者が閲覧可能な取引に関する履歴を取得し、
   取得した前記履歴に基づいて、以降の取引において用いられる認証情報を生成し、
   生成した認証情報を記憶部に記憶させる、
   処理をコンピュータに実行させることを特徴とする認証情報生成プログラム。

Images