JP2002304522A

JP2002304522A - 認証方法、取引者側システム、コンピュータプログラムおよびそれを記録した記録媒体

Info

Publication number: JP2002304522A
Application number: JP2001107471A
Authority: JP
Inventors: Tomoharu Ogura; 知治小倉
Original assignee: UFJ Bank Ltd
Current assignee: MUFG Bank Ltd
Priority date: 2001-04-05
Filing date: 2001-04-05
Publication date: 2002-10-18

Abstract

(57)【要約】【課題】個々の取引内容に合致したレベルの認証を行う
ことで、顧客の利便性の向上とセキュリティレベルとの
両立を図るとともに、認証プロセスにおいて、顧客が不
正な取引きが申し入れられた事実を知った場合、自己の
取引契約を迅速かつタイムリーに停止可能にする。【解決手段】デリバリーチャネル１０を介して申し入れ
られた取引きに関する認証を銀行側システム３０が行う
認証方法において、まず、顧客が予め設定した取引条件
に基づいて、申し入れられた取引きの取引内容が取引条
件に合致するか否かを判断する。つぎに、申し入れられ
た取引内容が取引条件に合致すると判断した場合、申し
入れられた取引きを行うのに必要な所定の認証を行うた
めに、顧客が予め指定した顧客端末２０であって、銀行
側システム３０との間でネットワークを介した情報伝達
可能な顧客端末２０にアクセスする。そして、顧客に関
する取引契約の停止を指示する旨の取引対応指示コード
を顧客端末２０側より受信した場合、この顧客に関し
て、今回の取引き以後の取引きを拒絶する取引停止処理
を行う。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、認証方法、取引者
側システム、コンピュータプログラムおよびそれを記録
した記録媒体に係り、特に、顧客から取引きを申し入れ
られた取引者側において行われる認証手法に関する。

【０００２】

【従来の技術】一般に、「デリバリーチャネル」、すな
わち、金融機関等の取引者が顧客に対してサービスを提
供する際の顧客接点を大別すると、顧客来店型と顧客在
宅型とに分類される。顧客来店型のデリバリーチャネル
としては、金融機関の窓口または金融機関に設置された
ＡＴＭ等が挙げられるが、利用者にとっては、その都度
そこに出向かなければならないという場所的制限がある
他、時間的な負担も生じる。そこで、顧客利便性の一層
の向上を図るために、ホームバンキングに代表されるよ
うに、携帯電話やパソコン等を用いた顧客在宅型チャネ
ルが注目・実用化されている。本明細書では、「デリバ
リーチャネル」という用語を、取引者（金融機関に限定
されない）が顧客に対して某かのサービスを提供する際
に顧客接点となり得るすべてのものを含む広義の意味で
用いている。

【０００３】従来より、取引者側は、取引きの申し入れ
を受ける度に、取引きを開始する条件として、その顧客
に関する認証を行っている。この認証は、通常、認証ツ
ール（例えばキャッシュカード）、ＩＤまたは暗証番号
等を用いて行われる。例えば、特開平８−２２１４８２
号公報には、顧客から請求された取引物を後で引渡すと
いう取引形態において、認証ツールとして携帯用無線端
末を用いる認証手法が開示されている。具体的には、顧
客から取引きの請求があった場合、取引物の引渡し側で
ある取引者は、この顧客が所有する携帯端末（携帯電
話）の呼出し番号を自己のシステムに登録・記憶する。
その後、顧客が取引物を引取りに来た時に、第１段階の
認証として、顧客が持参している携帯端末の呼出し番号
を読み出して、それが登録された呼出し番号と一致する
か否かを確認する。第１段階の認証が得られた場合、呼
出し番号に対応する携帯端末を呼び出して、その携帯端
末にキーワードを送信する。第２段階の認証は、顧客が
持参してきた携帯端末がそのキーワードを受信するか否
かを確認することにより行う。さらに、顧客に暗証番号
の入力を促すことにより、第３段階の認証である本人確
認を行う。この公報に開示された認証手法は、複数の認
証を組み合わせた画一的な認証形態を、取引内容に拘わ
らず一律に適用するものであり、取引内容に応じて認証
形態を変える点については開示されていない。

【０００４】この点に関して、特開２００１−６０２８
号公報には、取引内容に応じて認証形態を変える認証手
法が開示されている。具体的には、預金者または金融機
関は、即時決済可能な利用条件、例えば、利用限度額に
関する条件を予め設定しておく。預金者またはその者の
許可を受けた利用者が即時決済サービスを希望する場
合、その決済が利用条件に合致するならば（利用限度を
超えているならば）、預金者本人に対して決済の是非を
リアルタイムで問い合わせる。これは、預金者本人が所
有する予め登録された携帯端末に対して、自動合成した
音声（確認内容）を送信することで可能となる。受信者
は、即時決済を許可するならば所定の操作を行うととも
に暗証番号を入力して、金融機関側に送信する。そし
て、金融機関は、携帯端末側からの受信データに基づき
適切な認証が得られたならば、即時決済処理を行う。

【０００５】

【発明が解決しようとする課題】ところで、昨今、バン
クカードや証券カード等の盗難時に暗証番号までもが盗
用されて金品が引き出される被害、或いは、ホームバン
キング等における「本人なりすまし」による被害が生じ
ている。このような不正な取引きによる被害を抑制する
ためには、顧客との都度取引きにおいて行われる認証の
セキュリティレベルを高くすることが有効である。しか
しながら、その反面、セキュリティレベルを上げるほど
顧客に要求される手続や手順が煩雑になり易いので、顧
客の利便性を損うおそれがある。そのため、取引内容に
拘わらず、画一的な認証形態を一律に適用する手法で
は、認証のセキュリティレベルと顧客利便性との両立を
図ることは容易ではない。

【０００６】また、不正な取引きが申し入れられた事実
が発覚した場合、顧客は、今回申し入れられた取引きの
みならず以後の取引きも禁止するために、取引契約自体
を停止したいと考えることがある。このようなケースで
は、被害を未然に防止するために、極力迅速かつタイム
リーな対応が要求される。しかしながら、上述した特開
２００１−６０２８号公報に開示された技術では、携帯
端末を介して、個々の取引きの申し入れに関する許可／
不許可の指示はできても、取引契約の停止を直接指示す
ることはできない。その結果、不正事実が発覚してから
取引契約の停止が執行されるまでにタイムラグが生じ、
その間に被害が発生するおそれがある。

【０００７】本発明は、かかる事情に鑑みてなされたも
のであり、その目的は、個々の取引内容に合致したレベ
ルの認証を行うことで、顧客の利便性の向上とセキュリ
ティレベルとの両立を図ることである。

【０００８】また、本発明の別の目的は、認証プロセス
において、顧客が不正な取引きが申し入れられた事実を
知った場合、自己の取引契約を迅速かつタイムリーに停
止可能にすることである。

【０００９】

【課題を解決するための手段】かかる課題を解決するた
めに、第１の発明は、デリバリーチャネルを介して申し
入れられた取引きに関する認証を取引者側システムが行
う認証方法において、取引者側システムは、顧客が予め
設定した取引条件に基づいて、申し入れられた取引きの
取引内容が取引条件に合致するか否かを判断する第１の
ステップと、取引者側システムは、申し入れられた取引
内容が取引条件に合致すると判断した場合、申し入れら
れた取引きに関する所定の認証を行うのに必要な情報の
入力を顧客に促すために、顧客が予め指定した顧客端末
であって、取引者側システムとの間でネットワークを介
した情報伝達可能な顧客端末にアクセスする第２のステ
ップと、取引者側システムは、顧客に関する取引契約の
停止を指示する旨の取引対応指示コードを顧客端末側よ
り受信した場合、この顧客に関して、今回の取引き以後
の取引きを拒絶する取引停止処理を行う第３のステップ
とを有する。

【００１０】第２の発明は、デリバリーチャネルを介し
て取引きが申し入れられた際に、この取引きの申し入れ
に関する認証をコンピュータに実行させるためのコンピ
ュータプログラムにおいて、コンピュータが、顧客が予
め設定した取引条件に基づいて、申し入れられた取引き
の取引内容が取引条件に合致するか否かを判断する第１
のステップと、コンピュータが、申し入れられた取引内
容が取引条件に合致すると判断した場合、申し入れられ
た取引きに関する所定の認証を行うのに必要な情報の入
力を顧客に促すために、顧客が予め指定した顧客端末で
あって、取引者側システムとの間でネットワークを介し
た情報伝達可能な顧客端末にアクセスする第２のステッ
プと、コンピュータが、顧客に関する取引契約の停止を
指示する旨の取引対応指示コードを顧客端末側より受信
した場合、この顧客に関して、今回の取引き以後の取引
きを拒絶する取引停止処理を行う第３のステップとを有
する認証方法をコンピュータに実行させるためのコンピ
ュータプログラムを提供する。

【００１１】第３の発明は、デリバリーチャネルを介し
て取引きが申し入れられた際に、この取引きの申し入れ
に関する認証をコンピュータに実行させるためのコンピ
ュータプログラムが記録された記録媒体において、コン
ピュータが、顧客が予め設定した取引条件に基づいて、
申し入れられた取引きの取引内容が取引条件に合致する
か否かを判断する第１のステップと、コンピュータが、
申し入れられた取引内容が取引条件に合致すると判断し
た場合、申し入れられた取引きに関する所定の認証を行
うのに必要な情報の入力を顧客に促すために、顧客が予
め指定した顧客端末であって、取引者側システムとの間
でネットワークを介した情報伝達可能な顧客端末にアク
セスする第２のステップと、コンピュータが、顧客に関
する取引契約の停止を指示する旨の取引対応指示コード
を顧客端末側より受信した場合、この顧客に関して、今
回の取引き以後の取引きを拒絶する取引停止処理を行う
第３のステップとを有する認証方法をコンピュータに実
行させるためのコンピュータプログラムが記録された記
録媒体を提供する。

【００１２】ここで、第１から第３のいずれかの発明に
おいて、上記第３のステップは、顧客端末側より受信し
た認証パスワードが、顧客が予め設定した認証パスワー
ドと同一であることを前提に行われることが好ましく、
また、顧客に関する取引契約停止の指示を受け付けた旨
を顧客端末側に通知するステップを含むことが望まし
い。また、上記所定の認証は、顧客がデリバリーチャネ
ルを介して取引きを申し入れる度に行われる通常認証に
続いて行われる追加認証であってもよい。この通常認証
は、個々の顧客に対して発行されたカードまたはユーザ
ＩＤに基づき行われる。この場合、上記第３のステップ
は、カードまたはユーザＩＤの使用を禁止するステップ
を含むことが好ましい。

【００１３】また、第１から第３のいずれかの発明にお
いて、申し入れられた取引きを承認する旨の取引対応指
示コードを顧客端末側より受信した場合、申し入れられ
た取引きを許可する取引処理を行う第４のステップと、
申し入れられた取引きを承認しない旨の取引対応指示コ
ードを顧客端末側より受信した場合、申し入れられた取
引きを許可しない認証エラー処理を行う第５のステップ
とをさらに有していてもよい。また、顧客端末との間に
おける情報伝達経路を確立できなかった場合、申し入れ
られた取引きを許可しない認証エラー処理を行う第６の
ステップをさらに有していてもよい。さらに、上記第２
のステップは、申し入れられた取引きを特定可能な情報
と、認証パスワードの入力を促す情報と、取引対応指示
コードの入力を促す情報とを顧客端末側に送信するステ
ップを含むことが望ましい。

【００１４】第４の発明は、デリバリーチャネルを介し
て、顧客との間で取引きを行う取引者側システムにおい
て、顧客が予め設定した、取引条件、ネットワークに接
続可能な顧客端末のアドレスおよび認証パスワードを、
個々の顧客に対応付けて管理するデータベースと、ネッ
トワークを介して情報伝達可能なデリバリーチャネルよ
り、取引きの申し入れを受信する受信手段と、申し入れ
られた取引きの取引内容が、データベースより特定され
る取引条件に合致するか否かを判断する判断手段と、取
引内容が取引条件に合致すると判断された場合、申し入
れられた取引きに関する所定の認証を行うのに必要な情
報の入力を顧客に促すために、データベースより特定さ
れる顧客端末にアクセスするアクセス手段と、顧客に関
する取引契約の停止を指示する旨の取引対応指示コード
を顧客端末側より受信した場合、この顧客に関して、今
回の取引き以後の取引きを拒絶する取引停止処理を行う
処理手段とを有する取引者側システムを提供する。

【００１５】ここで、第４の発明において、顧客端末側
より受信した認証パスワードと、データベースより特定
される認証パスワードとを比較することにより、取引き
を行うために必要な認証を行う認証手段をさらに有して
いてもよい。この場合、上記処理手段は、認証手段によ
り認証が得られたことを前提として取引停止処理を行う
ことが好ましい。また、上記処理手段は、取引契約停止
の指示を受け付けた旨を顧客端末側に通知する処理を行
うことが好ましい。また、上記認証手段は、デリバリー
チャネルを介して取引きが申し入れられる度に行われる
通常認証の結果が認証一致の場合に、所定の認証として
追加認証を行うことが好ましい。この通常認証は、個々
の顧客に対して発行されたカードまたはユーザＩＤとに
基づき行われる。この場合、上記処理手段は、取引停止
処理を行う場合、カードまたはユーザＩＤの使用を禁止
することが望ましい。また、上記処理手段は、申し入れ
られた取引きを承認する旨の取引対応指示コードを顧客
端末側より受信した場合、申し入れられた取引きを許可
する取引処理を行うとともに、申し入れられた取引きを
承認しない旨の取引対応指示コードを顧客端末側より受
信した場合、申し入れられた取引きを許可しない認証エ
ラー処理を行ってもよい。また、上記処理手段は、顧客
端末との間における情報伝達経路が確立できなかった場
合、申し入れられた取引きを許可しない認証エラー処理
を行ってもよい。さらに、上記アクセス手段は、申し入
れられた取引きを特定可能な情報と、認証パスワードの
入力を促す情報と、取引対応指示コードの入力を促す情
報とを顧客端末側に送信することが望ましい。

【００１６】

【発明の実施の形態】以下、顧客と取引きを行う取引者
の一形態である銀行（金融機関）を例に、本実施形態に
係る認証スキームを説明する。図１は、この認証スキー
ムを実現するネットワークを用いた認証システムの全体
構成図である。銀行に口座を開設している顧客は、デリ
バリーチャネル１０より、銀行に対して取引き（例え
ば、口座出金等）の申し入れを行う。ここで、デリバリ
ーチャネル１０は上述した顧客接点であり、典型的に
は、顧客来店型のＡＴＭが挙げられ、顧客在宅型として
は、有線または無線のネットワーク環境を有し、銀行が
運営するインターネット上の所定のＷｅｂサイト（銀行
サイト）にアクセス可能なパーソナルコンピュータ（Ｐ
Ｃ），携帯型情報機器（ＰＤＡ），携帯電話，家庭用ゲ
ーム機等が挙げられる。

【００１７】顧客端末２０は、有線または無線のネット
ワーク環境を有するとともに、顧客が保有している端末
であり、例えば、携帯電話，電話，ＰＣ，ＰＤＡ等を用
いることができる。本実施形態において、この顧客端末
２０は、後述する追加認証を行う際の認証ツールとして
用いられため、特に顧客来店型のデリバリーチャネルに
よる取引きを想定する場合には、その場で対応できるよ
うな携帯性を有することが好ましい。

【００１８】銀行側システム３０は、相互に情報伝達可
能な取引システム３１と認証システム３２とを含み、そ
れぞれのシステム３１，３２は、ＣＰＵ，ＲＯＭ，ＲＡ
Ｍ，記憶装置，通信装置等を主体に構成された一般的な
コンピュータである。取引システム３１は、デリバリー
チャネル１０との間でネットワークを介した情報伝達が
可能であり、例えば、顧客来店型チャネルであるＡＴＭ
とは専用回線を介して、顧客在宅型チャネルであるＰＣ
等とはインターネットを介してそれぞれ接続されてい
る。また、取引システム３１がアクセス可能な磁気ディ
スク装置（ＨＤＤ）等の記憶装置３３には、個々の顧客
との取引きを一元的に管理するため取引元帳データベー
スが格納されている。なお、取引元帳データベースは、
単一のデータベースで実現してもよいが、互いに関連付
けられた（リンクした）複数のデータベースで実現して
もよい。一方、認証システム３２は、顧客端末２０との
間でネットワークを介した情報伝達が可能であり、追加
認証を行う際に顧客端末２０へのアクセス処理を行う。
なお、認証システム３２を別システムとして設けること
なく、取引システム３１自体でこの処理を行ってもよ
い。

【００１９】図２は、取引元帳データベースの概略的な
構造を示す図である。このデータベースは、顧客毎に個
別の顧客ＩＤが付与されたレコード群で構成されてお
り、個々のレコードには、「口座情報」，「預金者情
報」，「暗証番号」，「取引条件」，「顧客端末情
報」，「認証パスワード」等が記述されている。ここ
で、「口座情報」は、取引支店の店舗番号に相当する支
店番号，預金種目等を区別する業務コード，口座番号等
を含む。「預金者情報」は、個々の預金者を特定する情
報であり、預金者の氏名や住所等を含む。「暗証番号」
は、都度取引きが申し入れられた際の必須認証である通
常認証を行うのに必要なパスワードである。

【００２０】また、「取引条件」は、通常認証に続いて
更に追加認証を行う必要がある取引きの条件、換言すれ
ば、追加認証の実行条件を規定している。顧客は、自己
の意志によって、取引金額や取引種類といった条件種別
と、この条件種別に応じた条件内容とを事前に設定・登
録しておく。例えば、「１００万円以上の出金」のよう
に取引金額（出金金額）の上限が設定されているなら
ば、１００万円以上の金額の出金が申し入れられた場合
に追加認証が行われる。また、デリバリーチャネル１０
の種別も「取引条件」として設定しておくことも可能で
ある。例えば、「ＡＴＭによる１００万円以上の出金」
という取引条件を設定してもよい。この場合、１００万
円以上の金額の口座出金がＡＴＭによって申し入れられ
た場合に追加認証が行われるが、ＡＴＭ以外のチャネル
が利用されている場合、追加認証は行われない。さら
に、所定期間内（例えば１日）の取引総額（出金総額）
に関する上限を「取引条件」として設定できるようにし
てもよい。「取引条件」としては、出金以外にも口座振
込等を含め様々な取引形態に関して設定可能にすること
ができる。どのような取引形態（の申し入れ）を追加認
証の対象とするか、或いは、各取引形態（の申し入れ）
に対してどのような取引条件の設定を認めるかは、顧客
のニーズを考慮した上で銀行側が設計的事項として取り
決める。顧客は、銀行が許容する範囲内において、自己
の取引条件を任意に設定・指定することができる。

【００２１】「顧客端末情報」は、追加認証における認
証ツールとして用いられる顧客端末２０の種別（電話、
ＰＣ等）と、そのアドレス（電話番号やe-mailアドレス
等）とを含む。さらに、「認証パスワード」は、追加認
証の際に使用されるパスワードであり、通常認証に必要
な「暗証番号」とは別個のものである。上述した「取引
条件」と同様、追加認証を希望する顧客は、「顧客端末
情報」と「認証レコード」とを事前に登録・設定してお
く。

【００２２】なお、追加認証をオプションサービスとし
て行う形態では、追加認証サービスの適用可否も取引元
帳データベースで管理しておくことが好ましい。また、
追加認証は、コレクトコールや手数料課金をするなどし
て、この認証が行われる取引きを、高レベルな認証を行
う必要があると顧客が考える取引きに限定することが望
ましい。

【００２３】つぎに、顧客と銀行との間における取引き
の流れについて説明する。銀行との取引きを希望する顧
客は、デリバリーチャネル１０より、取引内容と暗証番
号とを入力する。これらの入力情報は、顧客の識別情報
とともに、ネットワーク接続されたデリバリーチャネル
１０から銀行側システム３０に送信される（図１の矢印
Ａ）。

【００２４】図３は、銀行側システム３０側において実
行される取引処理のフローチャートである。銀行側シス
テム３０は、図５の条件別処理に関する一覧表に示すよ
うに、７つのケース（＃１〜＃７）に応じて異なる処理
を行う。

【００２５】まず、デリバリーチャネル１０側から情報
を受信した取引システム３１は、ステップ１において、
今回申し入れられた取引内容に拘わらずに、通常認証を
一律に行う。この認証処理では、まず、顧客の識別情報
に基づいて、記憶装置３３に格納された取引元帳データ
ベースを検索して、その顧客に関するレコードを「対象
レコード」として抽出する。つぎに、この対象レコード
に記述された「暗証番号」と、取引きの申し入れに際し
て顧客が入力した暗証番号とを比較して、認証の一致／
不一致を判断する。両者が一致した場合（認証結果＝
「認証一致」）、取引きを申し入れた者が真正な顧客と
みなして、ステップ２の判断に従いステップ３に進む。
これに対して、入力された暗証番号が対象レコード中の
「暗証番号」と相違する場合（認証結果＝「認証不一
致」）、ステップ２の判断に従いステップ９に進む。ス
テップ２からステップ９に進むケースは、図５のケース
＃７に相当し、認証エラー処理が行われる。このエラー
処理では、図１の矢印Ｂに示すように、取引システム３
１がデリバリーチャネル１０に対して指示信号を送信
し、顧客に対して暗証番号の再入力を促す。

【００２６】ステップ３において、取引システム３１
は、今回申し入れられた取引きに関して、追加認証が必
要な取引内容であるか否かを判断する。この判断は、対
象レコードに記述された「取引条件」と今回申し入れら
れた取引内容とを比較することにより行われる。例え
ば、顧客が「１００万円以上の出金」という取引条件が
事前設定されている場合、今回の取引内容がこの条件に
合致するならば、ステップ３の判断に従いステップ４に
進み、後述する追加認証処理が行われる。一方、今回の
取引内容が取引条件に合致しないならば、ステップ７に
進む。ステップ３からステップ７に進むケースは、図５
のケース＃１に相当し、今回申し入れられた取引きを許
可する取引処理、すなわち、取引履歴の追加・更新、Ａ
ＴＭ等に対する指示（例えば出金許可）といった処理が
行われる（図１の矢印Ｂ）。

【００２７】図４は、ステップ４における追加認証処理
の詳細な手順を示すフローチャートである。まず、ステ
ップ１０において、取引システム３１は、認証システム
３２に対して、対象レコードにおける「顧客端末情報」
として指定されたアドレスを送信して追加認証を依頼す
る。この依頼を受けた認証システム３２は、ステップ１
１において、追加認証に必要な認証パスワード等の入力
を顧客に促すために、顧客が事前登録した顧客端末２０
にアクセスする（図１の矢印Ｃ）。例えば、顧客端末２
０として、デリバリーチャネル１０とは異なる情報伝達
経路（ネットワーク）で情報が伝達される電話や携帯電
話を指定している場合、認証システム３２は、顧客が今
回申し入れられた取引きを特定する音声メッセージと、
認証パスワードの入力を促す音声メッセージと、取引対
応指示コードの入力を促す音声メッセージとを、電話回
線を通じて送信する。ここで、申し入れられた取引きを
特定する内容としては、内容が簡単なＡＴＭでは取引内
容そのものであってもよいが、内容が複雑なホームバン
キングでは取引番号等のコードを用いることが好まし
い。また、顧客端末２０としてインターネットに接続可
能な携帯電話やノート型ＰＣ等を指定している場合に
は、顧客端末２０に電子メールを送信し、認証パスワー
ドの入力を促してもよい。なお、顧客端末２０へのアク
セスは、認証パスワードの入力を顧客に促し得るもので
あれば、上述した音声や電子メールに限定されるもので
はなく、顧客端末２０の特性等に応じた適宜の手法を採
用する。

【００２８】ステップ１２において、認証システム３２
から情報の入力を促された「顧客」は、顧客端末２０を
操作して、認証パスワードを入力するとともに、それに
続いて、所定の取引対応指示コードの内のいずれかを選
択して入力する。この「顧客」は、顧客端末２０の受信
者であって、デリバリーチャネル１０の操作者とは異な
るかもしれない。顧客端末２０として電話回線に接続可
能な携帯電話や電話が設定されている場合、顧客は、事
前登録した「認証パスワード」に相当する番号のボタン
を押して、認証パスワードを入力する。また、取引対応
指示コードには、下記に示す３つの指示内容が存在し、
各コードに適宜の番号が対応付けられている。なお、
「取引契約停止」は、他の２つよりも影響度・重要度が
大きいため、暗証番号的な意味合いを持たせるために、
その番号を顧客が任意に設定できるようにしてもよい。
この場合、取引元帳データベースに「取引契約停止コー
ド」を追加し、このデータベースで個々の顧客が設定し
たコード番号を一元的に管理する。（取引対応指示コード）指示内容意味番号「取引承認」今回申し入れられた取引きを許可「1」「取引不承認」今回申し入れられた取引きを許可しない「0」「取引契約停止」自己の取引契約の停止「9999」

【００２９】ここで、「取引契約停止」とは、今回申し
込まれた取引き、およびそれ以降の取引きを含めて、取
引契約の全面停止を指示するものである。この指示を受
けた場合、その顧客のバンクカードやユーザＩＤ等は無
効とされ、適切な手続が採られるまでは、今回の取引き
以後（今回申し入れられた取引きも含む）の使用が拒絶
・禁止される。

【００３０】入力された認証パスワードおよび取引対応
指示コードは、顧客端末２０から認証システム３２側に
送信される（図１の矢印Ｄ）。なお、インターネットに
接続された携帯電話やノート型ＰＣ等を顧客端末２０と
している場合、顧客が入力した認証パスワード等は返信
メールの形態で認証システム３２側に送信される。電話
回線やインターネット等のネットワークを介して認証パ
スワード等を受信した認証システム３２は、認証パスワ
ード等を取引システム３１側に転送する（ステップ１
３）。

【００３１】認証パスワードおよび取引対応指示コード
を受信した取引システム３１は、入力された認証パスワ
ードが、対象レコードに記述された「認証パスワード」
とを照会し、追加認証の一致／不一致を判断するととも
に、追加認証結果を出力する（ステップ１４）。

【００３２】図３のステップ５において、追加認証結果
が「認証一致」または「その他」のどちらであるかが判
断される。ここで、「その他」に該当するケースとして
は、図５のケース＃５とケース＃６とがあるが、どちら
のケースでも認証エラー処理が行われる（ステップ
９）。ケース＃５の場合、すなわち、追加認証結果が
「認証不一致」の場合、デリバリーチャネル１０側で
は、通常認証での認証不一致と同じ処理が行われる。ま
た、顧客端末２０側では、認証パスワードが一致しない
旨が表示画面上に文字表示され、或いは、それが音声で
出力され、認証パスワードの入力エラーが通知される。
一方、ケース＃６の場合、顧客端末２０との間における
情報伝達経路を確立できなかった場合には、例えば、顧
客端末２０が話中であったり、電話が途中で中断された
ケース等が挙げられる。このケース＃６において、デリ
バリーチャネル１０側では通常認証での認証不一致と同
じ処理が行われるが、顧客端末２０との情報伝達経路が
確立不能なため、顧客端末２０側にはいかなる情報も表
示・通知されない。なお、このケース＃６では、通常の
認証エラー処理とは異なり、認証パスワード等を無効と
させる手順を踏まないことも考えられる。

【００３３】これに対して、ステップ５における追加認
証結果が「認証一致」の場合は、ステップ６に進み、上
述した取引対応指示コードが「取引承認」、「取引不承
認」または「取引契約停止」のいずれであるかが判断さ
れる。また、その指示に対する受付結果は、顧客端末２
０を介して指示を与えた者に対して通知される。

【００３４】まず、「取引承認」の場合は、図５のケー
ス＃２に相当し、今回申し入れられた取引きを許可する
取引処理が行われる（ステップ７）。この場合、デリバ
リーチャネル１０側では、正常な取引処理と同じ処理が
行われ、追加認証の事実を表示することなく、正常な取
引きと同一の表示を行う。また、顧客端末２０側では、
取引承認を受け付けた旨が表示・通知される。顧客端末
２０よりコードを入力した者は、顧客端末２０を通じ
て、取引認証が適切に受け付けられたことを知ることが
できる。

【００３５】また、「取引不承認」の場合は、図５のケ
ース＃４に相当し、今回の取引きを許可しない認証エラ
ー処理が行われる（ステップ９）。この場合、デリバリ
ーチャネル１０側では通常認証での認証不一致と同じ処
理が行われ、通常認証でエラーとなった取引きと同一の
表示を行う。その理由は、通常認証エラーと同じ表示を
行えば、追加認証で拒絶されたこと、つまり通常認証が
突破されたことを悟られないようにするためである。換
言すれば、追加認証エラーになったことを表示するの
は、通常認証が突破されたことを示すことになり、好ま
しくないからである。また、顧客端末２０側では、取引
きの不承認を受け付けた旨が表示・通知される。顧客端
末２０よりコードを入力した者は、顧客端末２０を通じ
て、取引不承認が適切に受け付けられたことを知ること
ができる。なお、この場合、今回申し入れられた取引き
がエラーになることを顧客端末２０に表示してもよい
が、取決めによってエラーになることが理解されている
ならば表示しなくてもよい。

【００３６】さらに、「取引契約停止」の場合は、図５
のケース＃３に相当し、取引契約の停止、すなわち、今
回申し入れられた取引き以後の取引きを拒絶するための
取引契約停止処理が行われる（ステップ８）。すなわ
ち、バンクカード、またはユーザＩＤとパスワードとの
セットを盗用された「本人なりすまし」取引きを停止
し、バンクカードやユーザＩＤ等を無効にして、これを
使用した以後の取引きを拒絶・禁止する。デリバリーチ
ャネル１０側では、取引契約がなかった場合と同じ処理
が行われ、無効なバンクカード、或いは、無効になった
ユーザＩＤを使用した取引きと同一の表示を行う。ま
た、顧客端末２０側では、取引契約の停止を受け付けた
旨が表示・通知される。顧客端末２０よりコードを入力
した者は、顧客端末２０を通じて、取引契約の停止指示
が適切に受け付けられたことを知ることができる。

【００３７】このように、本実施形態によれば、セキュ
リティレベルが比較的高い追加認証（顧客の手続は煩雑
になるかもしれない）は、顧客より申し入れられた取引
内容が取引条件に合致することを前提に行われ、これに
合致しない取引きに関しては行われない。この追加認証
の実行条件を規定する取引条件は、銀行が許容する範囲
内において顧客が任意に設定可能である。これにより、
顧客は、不測の犯罪が発生した際に被るであろう被害の
程度を十分考慮した上で、自己が納得できるように、追
加認証の実行条件をカスタマイズするであろう。したが
って、不測の事態が生じても被害の程度が小さいと考え
る取引きでは、追加認証は行われないので、顧客が納得
する形で利便性を優先することができる。このように、
個々の顧客のニーズに合致した認証実行条件を個別に設
定することで、顧客の利便性を向上させることが可能と
なる。

【００３８】また、申し入れられた取引きの内容に応じ
て、認証のセキュリティレベル（通常認証のみ、また
は、通常認証と追加認証との組み合わせ）を変えてい
る。本実施形態では、取引きを申し入れた顧客が予め設
定した取引条件に基づいて、セキュリティレベルが異な
る複数の認証形態の内のいずれかを設定する。そして、
設定された認証形態に従い、顧客から申し入れられた取
引きに関する認証を行う。このような認証形態におい
て、不測の事態が生じても被害の程度が小さいと考える
取引きでは、通常認証による一般的なセキュリティレベ
ルが確保される。また、不測の事態が生じると被害の程
度が大きいと考える取引きでは、顧客の利便性は多少損
なわれるかもしれないが、通常認証と追加認証との組み
合わせにより、高次元のセキュリティレベルが確保され
る。この場合、追加認証に必要な認証ツールな顧客端末
２０を有さない者は、たとえキャッシュカードを所持し
暗証番号等を知っていたとしても取引きをすることはで
きない。以上のような理由により、取引内容に拘わらず
画一的な認証形態を一律に適用する従来の手法と比較し
て、顧客の利便性の向上と認証セキュリティレベルの向
上とを両立させることができる。なお、本実施形態で
は、２つの認証形態（通常認証、通常認証＋追加認証）
を採用しているが、３つ以上の認証形態を用意し、顧客
が事前設定した取引条件に応じて、これらの内のいずれ
かを択一的に適用することも当然可能である。

【００３９】また、本実施形態によれば、バンクカー
ド、またはユーザＩＤとパスワードとのセットを盗用さ
れた場合に起こり得る「本人なりすまし」による取引き
を迅速かつタイムリーに禁止・停止することができる。
すなわち、第三者による不正取引きの申し入れを、上述
した追加認証プロセスを通じて顧客が知った場合、その
顧客は、顧客端末２０を直接操作して「取引契約停止」
を指示する。この指示を受けた銀行側システム３０で
は、指示を受け付けた直後に遅滞なく、今回の取引きの
みならず以後の取引きも禁止する取引契約停止処理を行
う。このように、追加認証プロセスの一環において、取
引契約の停止を顧客端末２０を通じて直接指示できるた
め、非常時の対応を迅速かつタイムリーに行うことが可
能となる。その結果、不正事実が発覚してから取引契約
を停止するまでのタイムラグが殆ど生じないので、被害
の発生を一層有効かつ効果的に防止することができる。
また、顧客は、入力した取引対応指示コードによる指示
に対する結果（特に、取引契約の停止指示に対する結
果）を顧客端末２０を通じて知ることができるため、ユ
ーザフレンドリで、かつ顧客利便性に優れたシステムを
実現できる。

【００４０】また、特に顧客来店型チャネルを利用した
取引きを行う場合、顧客が普段携行している携帯性を有
する顧客端末２０（携帯電話等）を追加認証用のツール
として事前設定しておけば、追加認証に必要な認証パス
ワードの入力をその場で行うことができる。したがっ
て、追加認証が必要となる取引きにおいても、迅速に対
処することが可能となり、顧客の利便性を著しく損なう
ことはない。

【００４１】さらに、デリバリーチャネル１０とは異な
る情報伝達経路を介して情報伝達を行う顧客端末２０
（携帯電話や電話）を指定しておけば、追加認証のセキ
ュリティレベルを一層向上させることが可能となる。例
えば、通常はＡＴＭ（専用回線によって情報伝達が行わ
れる）で取引きを行う顧客は、電話回線に接続可能な携
帯電話や電話を顧客端末２０として指定しておくことが
好ましい。この場合、通常認証のみの認証形態は、ＡＴ
Ｍの情報伝達経路（専用回線）を用いて実現される。一
方、通常認証と追加認証との併用である認証形態は、少
なくとも、デリバリーチャネルとは異なる情報伝達経路
（電話回線）で情報伝達経路が行われる刑帯電話等を用
いて実現される。このように、高セキュリティレベルが
要求される認証形態では、通常認証とは別経路の認証ツ
ールが用いられ、通常認証と追加認証との経路が分離さ
れるため、不測の事態が生じると被害の程度が大きい取
引きに関するセキュリティレベルを一層向上できる。

【００４２】なお、上述した実施形態の変形例として、
追加認証の要否に関する条件を設けることなく、全ての
取引きの申し入れに対して追加認証を行うようにしても
よい。また、通常認証の不一致についても、追加認証の
要否に関する条件によって、或いは、全ての取引きにつ
いて追加認証を行ってもよい。これにより、不正使用の
早期発見による取引契約の停止処理、ひいては不正使用
被害の防止が可能となる。

【００４３】上述した実施形態は、銀行と顧客との間で
行われる取引きに関する認証スキームに関して説明し
た。しかしながら、本発明は、これに限定されるもので
はなく、様々な取引形態に対して適用することが可能で
ある。例えば、取引者の一態様である証券会社に関する
証券売買取引を考えた場合、「所定株以上の注文取引」
を取引条件として事前設定しておく。これにより、上述
した実施形態と同様の認証スキームにより、取引内容に
応じた認証のセキュリティレベルを確保することができ
る。証券取引での信用取引に関しても同様である。ま
た、クレジットカードによる支払いに関して、「所定額
以上の支払い」に関しては、信販会社（取引者）が追加
認証を行うようにしてもよい。さらに、顧客に対して取
引物（例えば、チケット等）を販売する販売者が、所定
の金額以上の取引物を販売する場合に追加認証を行って
もよい。

【００４４】また、上述した実施形態では、通常認証を
必須の認証とし、これに追加認証を付加するか否かによ
って、セキュリティレベルが異なる複数の認証形態を設
定している。このように、通常認証と追加認証とを併用
した理由は、銀行等の金融機関と顧客との間の取引きの
大半は、キャッシュカードや暗証番号等に基づく通常認
証が前提となっているからである。しかしながら、取引
きの前提として通常認証の類が行われない取引形態で
は、通常認証に続いて追加認証を行うというアプローチ
をとる必要は必ずしもない。例えば、取引者側は、セキ
ュリティレベルの異なる別個の認証形態（例えば、パス
ワードによる第１の認証形態、指紋や音声照合による第
２の認証形態）を用意してもよい。顧客は、上述した実
施形態と同様に、それぞれの認証形態の実行条件を取引
条件として事前設定しておく。このケースでは、取引き
を申し入れた顧客が予め設定した取引条件に基づいて、
取引者側は、セキュリティレベルが異なる複数の認証形
態の内のいずれかを設定し、その認証形態に従い、顧客
から申し入れられた取引きに関する認証を行う。

【００４５】なお、上述した実施形態の機能を実現する
コンピュータプログラムを記録した記録媒体を、図１に
示した銀行側システム３０のコンピュータに対して供給
してもよい。この場合、このコンピュータにおいて、記
録媒体に格納されたコンピュータプログラムを読み取り
実行することによって、本発明の目的を達成することが
できる。したがって、記録媒体から読み取られたコンピ
ュータプログラム自体が本発明の新規な機能を実現する
ため、そのプログラムを記録した記録媒体が本発明を構
成する。コンピュータプログラムを記録した記録媒体と
しては、例えば、ＣＤ−ＲＯＭ、フロッピー（登録商
標）ディスク、ハードディスク、メモリカード、光ディ
スク、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ等が挙げられ
る。また、上述した実施形態の機能を実現するコンピュ
ータプログラム自体も新規な機能を有している。

【００４６】

【発明の効果】このように、本発明によれば、個々の顧
客のニーズに合致した認証実行条件を設定することがで
きるため、顧客の利便性の向上を図ることができる。ま
た、取引内容に応じて、認証のセキュリティレベルを変
えることにより、画一的な認証形態を一律に適用する従
来の手法と比較して、顧客の利便性の向上と認証セキュ
リティレベルの向上とを両立させることができる。さら
に、追加認証プロセスを通じて、不正事実が発覚してか
ら取引契約を停止するまでのタイムラグが殆ど生じない
ので、被害の発生を一層有効かつ一層効果的に防止する
ことが可能となる。

【図面の簡単な説明】

【図１】ネットワークを用いた認証システムの全体構成
図

【図２】取引元帳データベースの概略的な構造を示す図

【図３】銀行側システム側において実行される取引処理
のフローチャート

【図４】追加認証処理の詳細な手順を示すフローチャー
ト

【図５】条件別処理に関する一覧表

【符号の説明】

１０デリバリーチャネル、２０顧客端末、３０
銀行側システム、３１取引システム、３２認
証システム、３３記憶装置

Claims

【特許請求の範囲】

【請求項１】デリバリーチャネルを介して申し入れられ
た取引きに関する認証を取引者側システムが行う認証方
法において、前記取引者側システムは、顧客が予め設定した取引条件
に基づいて、申し入れられた取引きの取引内容が前記取
引条件に合致するか否かを判断する第１のステップと、前記取引者側システムは、申し入れられた取引内容が前
記取引条件に合致すると判断した場合、申し入れられた
取引きに関する所定の認証を行うのに必要な情報の入力
を前記顧客に促すために、前記顧客が予め指定した顧客
端末であって、前記取引者側システムとの間でネットワ
ークを介した情報伝達可能な顧客端末にアクセスする第
２のステップと、前記取引者側システムは、前記顧客に関する取引契約の
停止を指示する旨の取引対応指示コードを前記顧客端末
側より受信した場合、前記顧客に関する前記取引き以後
の取引きを拒絶する取引停止処理を行う第３のステップ
とを有することを特徴とする認証方法。
【請求項２】上記第３のステップは、前記顧客端末側よ
り受信し、前記顧客が入力した認証パスワードが、前記
顧客が予め設定した認証パスワードと同一であることを
前提に行われることを特徴とする請求項１に記載された
認証方法。
【請求項３】上記第３のステップは、前記顧客に関する
取引契約停止の指示を受け付けた旨を前記顧客端末側に
通知するステップを含むことを特徴とする請求項１に記
載された認証方法。
【請求項４】前記所定の認証は、前記顧客がデリバリー
チャネルを介して取引きを申し入れる度に行われる通常
認証に続いて行われる追加認証であり、前記通常認証は、個々の顧客に対して発行されたカード
またはユーザＩＤに基づき行われ、上記第３のステップは、前記カードまたは前記ユーザＩ
Ｄの使用を禁止するステップを含むことを特徴とする請
求項１から３のいずれかに記載された認証方法。
【請求項５】前記取引者側システムは、申し入れられた
取引きを承認する旨の取引対応指示コードを前記顧客端
末側より受信した場合、申し入れられた取引きを許可す
る取引処理を行う第４のステップと、前記取引者側システムは、申し入れられた取引きを承認
しない旨の取引対応指示コードを前記顧客端末側より受
信した場合、申し入れられた取引きを許可しない認証エ
ラー処理を行う第５のステップとをさらに有することを
特徴とする請求項１から４のいずれかに記載された認証
方法。
【請求項６】前記取引者システムは、前記取引者側シス
テムと前記顧客端末との間における情報伝達経路を確立
できなかった場合、申し入れられた取引きを許可しない
認証エラー処理を行う第６のステップをさらに有するこ
とを特徴とする請求項５に記載された認証方法。
【請求項７】上記第２のステップは、申し入れられた取
引きを特定可能な情報と、認証パスワードの入力を促す
情報と、取引対応指示コードの入力を促す情報とを前記
顧客端末側に送信するステップを含むことを特徴とする
請求項１から６のいずれかに記載された認証方法。
【請求項８】デリバリーチャネルを介して、顧客との間
で取引きを行う取引者側システムにおいて、顧客が予め設定した、取引条件、ネットワークに接続可
能な顧客端末のアドレスおよび認証パスワードを、個々
の顧客に対応付けて管理するデータベースと、ネットワークを介して情報伝達可能なデリバリーチャネ
ルより、取引きの申し入れを受信する受信手段と、申し入れられた取引きの取引内容が、前記データベース
より特定される取引条件に合致するか否かを判断する判
断手段と、前記取引内容が前記取引条件に合致すると判断された場
合、申し入れられた取引きに関する所定の認証を行うの
に必要な情報の入力を顧客に促すために、前記データベ
ースより特定される顧客端末にアクセスするアクセス手
段と、、前記顧客に関する取引契約の停止を指示する旨
の取引対応指示コードを前記顧客端末側より受信した場
合、前記顧客に関する前記取引き以後の取引きを拒絶す
る取引停止処理を行う処理手段とを有することを特徴と
する取引者側システム。
【請求項９】前記顧客端末側より受信した認証パスワー
ドと、前記データベースより特定される認証パスワード
とを比較することにより、前記取引きを行うために必要
な認証を行う認証手段をさらに有し、前記処理手段は、前記認証手段により認証が得られたこ
とを前提として取引停止処理を行うことを特徴とする請
求項８に記載された取引者側システム。
【請求項１０】前記処理手段は、取引契約停止の指示を
受け付けた旨を前記顧客端末側に通知する処理を行うこ
とを特徴とする請求項８に記載された取引者側システ
ム。
【請求項１１】前記認証手段は、デリバリーチャネルを
介して取引きが申し入れられる度に行われる通常認証の
結果が認証一致の場合に、前記所定の認証として追加認
証を行い、前記通常認証は、個々の顧客に対して発行されたカード
またはユーザＩＤとに基づき行われ、前記処理手段は、取引停止処理を行う場合、前記カード
または前記ユーザＩＤの使用を禁止することを特徴とす
る請求項８から１０のいずれかに記載された取引者側シ
ステム。
【請求項１２】前記処理手段は、申し入れられた取引き
を承認する旨の取引対応指示コードを前記顧客端末側よ
り受信した場合、申し入れられた取引きを許可する取引
処理を行うとともに、申し入れられた取引きを承認しな
い旨の取引対応指示コードを前記顧客端末側より受信し
た場合、申し入れられた取引きを許可しない認証エラー
処理を行うことを特徴とする請求項８から１１のいずれ
かに記載された取引者側システム。
【請求項１３】前記処理手段は、前記顧客端末との間に
おける情報伝達経路が確立できなかった場合、申し入れ
られた取引きを許可しない認証エラー処理を行うことを
特徴とする請求項１２に記載された取引者側システム。
【請求項１４】前記アクセス手段は、申し入れられた取
引きを特定可能な情報と、認証パスワードの入力を促す
情報と、取引対応指示コードの入力を促す情報とを前記
顧客端末側に送信することを特徴とする請求項８から１
３のいずれかに記載された取引者側システム。
【請求項１５】デリバリーチャネルを介して取引きが申
し入れられた際に、当該取引きの申し入れに関する認証
をコンピュータに実行させるためのコンピュータプログ
ラムにおいて、前記コンピュータが、顧客が予め設定した取引条件に基
づいて、申し入れられた取引きの取引内容が前記取引条
件に合致するか否かを判断する第１のステップと、前記コンピュータが、申し入れられた取引内容が前記取
引条件に合致すると判断した場合、申し入れられた取引
きに関する所定の認証を行うのに必要な情報の入力を顧
客に促すために、前記顧客が予め指定した顧客端末であ
って、前記取引者側システムとの間でネットワークを介
した情報伝達可能な顧客端末にアクセスする第２のステ
ップと、前記コンピュータが、前記顧客に関する取引契約の停止
を指示する旨の取引対応指示コードを前記顧客端末側よ
り受信した場合、前記顧客に関する前記取引き以後の取
引きを拒絶する取引停止処理を行う第３のステップとを
有する認証方法をコンピュータに実行させるためのコン
ピュータプログラム。
【請求項１６】請求項１５に記載されたコンピュータプ
ログラムが記録された記録媒体。