JP2024118112A - 情報処理装置、情報処理方法、プログラム、および情報処理システム - Google Patents

Abstract

【課題】十分なセキュリティ性を確保しつつ手続きに要する負荷を効果的に低減する。【解決手段】ユーザ端末から受け付けた手続きに関する入力情報に基づき、前記手続きの特定に用いられる識別番号と、前記ユーザ端末から受け付けたユーザの認証情報に基づくユーザ認証が成立した場合に生成されるトークン情報と、をコード化した情報コードを含む前記手続きに係る帳票データを生成する帳票生成部、を備える、情報処理装置が提供される。【選択図】図１

Description

本発明は、情報処理装置、情報処理方法、プログラム、および情報処理システムに関する。

金融機関において行われる取引に関し、行員および顧客の負荷を低減するための技術が開発されている。例えば、特許文献１には、本人確認後に生成されるＱＲコード（登録商標）をＡＴＭ（Automatic Teller Machine）に読み取らせることで、設定された限度額を超えた取引を可能とする技術が開示されている。

特開２０２２－７２６６３号公報

しかし、特許文献１に開示されるように、窓口に来店する人物の本人確認を行うのみでは、十分なセキュリティ性を確保することが困難な場合がある。

そこで、本発明は、上記問題に鑑みてなされたものであり、本発明の目的とするところは、十分なセキュリティ性を確保しつつ手続きに要する負荷を効果的に低減することにある。

上記課題を解決するために、本発明のある観点によれば、ユーザ端末から受け付けた手続きに関する入力情報に基づき、前記手続きの特定に用いられる識別番号と、前記ユーザ端末から受け付けたユーザの認証情報に基づくユーザ認証が成立した場合に生成されるトークン情報と、をコード化した情報コードを含む前記手続きに係る帳票データを生成する帳票生成部、を備える、情報処理装置が提供される。

前記帳票生成部は、前記ユーザ端末から受け付けた前記手続きに関する入力情報に基づき、前記手続きの内容をさらにコード化した情報コードを含む前記帳票データを生成してもよい。

前記手続きは、出金取引を含んでもよい。

前記手続きの内容は、口座情報または金額のうち少なくともいずれかを含んでもよい。

前記ユーザ認証は、インターネットバンキングにより実施されてもよい。

トークン情報は、乱数またはハッシュ値を含んでもよい。

前記情報コードは、二次元コードを含んでもよい。

前記情報処理装置は、前記トークン情報を生成するトークン生成部、をさらに備えてもよい。

また、上記課題を解決するために、本発明の別の観点によれば、プロセッサが、ユーザ端末から受け付けた手続きに関する入力情報に基づき、前記手続きの特定に用いられる識別番号と、前記ユーザ端末から受け付けたユーザの認証情報に基づくユーザ認証が成立した場合に生成されるトークン情報と、をコード化した情報コードを含む前記手続きに係る帳票データを生成すること、を含む、情報処理方法が提供される。

また、上記課題を解決するために、本発明の別の観点によれば、コンピュータを、ユーザ端末から受け付けた手続きに関する入力情報に基づき、前記手続きの特定に用いられる識別番号と、前記ユーザ端末から受け付けたユーザの認証情報に基づくユーザ認証が成立した場合に生成されるトークン情報と、をコード化した情報コードを含む前記手続きに係る帳票データを生成する帳票生成部、を備える、情報処理装置、として機能させるプログラムが提供される。

また、上記課題を解決するために、本発明の別の観点によれば、ユーザ端末から受け付けた手続きに関する入力情報に基づき、前記手続きの特定に用いられる識別番号と、前記ユーザ端末から受け付けたユーザの認証情報に基づくユーザ認証が成立した場合に生成されるトークン情報と、をコード化した情報コードを含む前記手続きに係る帳票データを生成する帳票生成部と、前記情報コードに基づき前記手続きの正当性を認証する認証部と、を備える、情報処理システムが提供される。

以上説明したように本発明によれば、十分なセキュリティ性を確保しつつ手続きに要する負荷を効果的に低減することが可能となる。

本発明の第１の実施形態に係る情報処理システム１の機能構成例を示すブロック図である。 同実施形態に係るＷＥＢ伝票Ｓが含む情報の一例について説明するための図である。 同実施形態に係るユーザ端末１０の機能構成例を示すブロック図である。 同実施形態に係るＷＥＢ伝票生成サーバ２０の機能構成例を示すブロック図である。 同実施形態に係るインターネットバンキングサーバ３０の機能構成例を示すブロック図である。 同実施形態に係るタブレット４０の機能構成例を示すブロック図である。 同実施形態に係る行員端末５０の機能構成例を示すブロック図である。 同実施形態に係るコード認証サーバ６０の機能構成例を示すブロック図である。 同実施形態に係るＡＴＭ７０の機能構成例を示すブロック図である。 同実施形態に係る情報処理システム１を用いたＷＥＢ伝票Ｓの生成の流れの一例を示す図である。 同実施形態に係る情報処理システム１を用いたＷＥＢ伝票Ｓの生成の流れの一例を示す図である。 同実施形態に係る情報処理システム１を用いたＷＥＢ伝票Ｓの生成の流れの一例を示す図である。 同実施形態に係る情報処理システム１を用いた営業店における処理の流れの一例を示す図である。 同実施形態に係る情報処理システム１を用いた営業店における処理の流れの一例を示す図である。 本発明の第２の実施形態に係る情報処理システム２の機能構成例を示すブロック図である。 同実施形態に係る情報処理システム２を用いた営業店における処理の流れの一例を示す図である。 同実施形態に係る情報処理システム２を用いた営業店における処理の流れの一例を示す図である。 本発明の一実施形態に係る情報処理装置９００のハードウェア構成を示す図である。

以下に添付図面を参照しながら、本発明の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。

＜１．第１の実施形態＞
＜＜１．１．概要＞＞
上述したように、近年、金融機関において行われる取引に関し、行員および顧客の負荷を低減するための技術が開発されている。

例えば、特許文献１に開示される技術によれば、行員の負荷を低減し、ＡＴＭに設定された限度額を超えた入手金業務を効率化することができる。

しかし、取引が出金、振込、振替等の場合、特許文献１に記載される本人確認のみではセキュリティ性の確保が十分とはいえない。上記のような取引において十分なセキュリティ性を確保するためには、金融機関への届出印（以下、単に、印鑑、とも称する）の照合が求められる。

また、取引に要する負荷を低減する別の手法としては、ユーザが自宅や企業等において予めインターネットサービスを利用して取引情報が埋め込まれたＱＲコード付きのＷＥＢ伝票を生成し、当該ＱＲコードを営業店端末に読み取らせることで、取引情報を営業店端末に引き継ぐ手法も想定される。

上記の手法によれば、行員による営業店端末を用いた取引内容の入力（打鍵）の負荷を効果的に低減することが可能である。

しかし、上記の手法であっても、取引が出金、振込、振替等の場合には、印鑑の照合によるセキュリティ性の確保が重要となる。

一方、印鑑の照合業務は、行員にとって非常に負荷の高い業務であり、改善が求められている。

本発明の技術思想は、上記のような点に着目して発想されたものであり、印鑑照合なしに十分なセキュリティ性を確保しつつ手続きに要する負荷を効果的に低減することを可能とする。

以下、上記の効果を実現する本発明の第１の実施形態に係るシステム構成例について詳細に説明する。

＜＜１．２．システム構成例＞＞
まず、本発明の第１の実施形態に係るシステム構成例について述べる。図１は、本発明の一実施形態に係る情報処理システム１の機能構成例を示すブロック図である。

なお、本実施形態では、近年金融機関の営業店において導入が行われているタブレットを用いた顧客（以下、ユーザ、とも称する）によるセルフ取引が行われる場合を想定する。

図１に示すように、本実施形態に係る情報処理システム１は、ユーザ端末１０、ＷＥＢ伝票生成サーバ２０、インターネットバンキングサーバ３０、タブレット４０、行員端末５０、コード認証サーバ６０、およびＡＴＭ７０等を備える。

（ユーザ端末１０）
本実施形態に係るユーザ端末１０はユーザにより用いられるＰＣ（Personal Computer）等の情報処理装置である。ユーザ端末１０は、例えば、ユーザの自宅・勤務先等のユーザ拠点に設置されてもよい。

本実施形態に係るユーザ端末１０は、インターネット８０を介してＷＥＢ伝票生成サーバ２０との通信を行い、ＷＥＢ伝票生成サーバ２０により提供されるＷＥＢアプリケーションを用いて生成されたＷＥＢ伝票Ｓを印刷する機能を有する。

（ＷＥＢ伝票生成サーバ２０）
本実施形態に係るＷＥＢ伝票生成サーバ２０は、ユーザ端末１０から受け付けた手続きに関する入力情報に基づき、当該手続きの特定に用いられる識別番号と、ユーザ端末１０から受け付けたユーザの認証情報に基づくユーザ認証が成立した場合に生成されるトークン情報と、をコード化した情報コードを含む手続きに係る帳票データを生成する。

本実施形態に係るＷＥＢ伝票Ｓは、上記帳票データの一例である。

また、上記手続きの一例としては、口座からの出金取引が挙げられる。

ここで、図２を参照して、本実施形態に係るＷＥＢ伝票Ｓが含む情報の一例について説明する。

本実施形態に係るＷＥＢ伝票Ｓは、取引の種別、口座番号等の口座情報、取引金額等を示す文字情報に加え、二次元コードＣを含む。

二次元コードＣは、マトリックスコードであってもよいし、スタックコードであってもよい。二次元コードＣの一例としては、ＱＲコードが挙げられる。

本実施形態に係る二次元コードＣは、上記情報コードの一例である。すなわち、本実施形態に係る二次元コードＣは、少なくとも手続きの特定に用いられる識別番号とトークン情報とがコード化されたものであってよい。

図２の右側には、本実施形態に係る二次元コードＣに記録される情報の一例が示される。

二次元コードＣに記録される情報は、例えば、ユーザ端末１０から受け付けた手続きに関する入力情報に依存しない共通項目と、入力情報に基づき生成される各種情報とを含んでもよい。

入力情報に基づき生成される各種情報には、例えば、ＷＥＢ伝票生成番号、トークン情報の他、店番・口座番号等を含む口座情報、取引金額、通帳摘要、金種指定等の取引の内容を示す情報が含まれてもよい。

なお、本実施形態に係るＷＥＢ伝票生成番号は、手続きの特定に用いられる識別番号の一例である。

本実施形態に係るＷＥＢ伝票生成サーバ２０は、ユーザ端末１０から受け付けたユーザの認証情報に基づくユーザ認証が成立した場合に、二次元コードＣを含むＷＥＢ伝票Ｓを生成し、ＷＥＢ伝票Ｓをユーザ端末１０に送信する。

ここで、上記のユーザ認証は、既存のインターネットバンキングにより実施されてもよい。

再び図１を参照して、本実施形態に係る情報処理システム１の機能構成例についての説明を続ける。

本実施形態に係るＷＥＢ伝票生成サーバ２０は、インターネット８０を介してインターネットバンキングサーバ３０と接続される。

本実施形態に係るＷＥＢ伝票生成サーバ２０は、ユーザ端末１０から受け付けたユーザの認証情報（例えば、ＩＤ／パスワード等のログイン情報）を用いてインターネットバンキングへのログインを試みる。

ここで、インターネットバンキングへのログインが成功した場合（ユーザ認証が成立した場合）、ＷＥＢ伝票生成サーバ２０は、ＷＥＢ伝票Ｓを生成してもよい。

また、ＷＥＢ伝票生成サーバ２０は、生成したＷＥＢ伝票Ｓに付与した二次元コードＣに含まれるＷＥＢ伝票生成番号とトークン情報とをコード認証サーバ６０に連携する。

（インターネットバンキングサーバ３０）
本実施形態に係るインターネットバンキングサーバ３０は、インターネットバンキングサービスを提供する。

本実施形態に係るインターネットバンキングサービスは、ユーザ認証情報に基づき、店番・科目・口座番号等の口座情報の表示、口座残高照会、入出金明細照会、振込、振替等が可能なサービスであってもよい。

本実施形態においては、インターネットバンキングサーバ３０は、ＷＥＢ伝票生成サーバ２０からのリクエストに基づくユーザ認証、および口座情報の表示に用いられる。

なお、一般的に、インターネットバンキングは、振込や振替等の資金移動を可能とするものと、資金移動を伴わない口座残高照会や入出金明細照会等の照会のみを可能とするものがある。本実施形態に係るインターネットバンキングは、ユーザ認証機能および口座情報の表示機能を有していればよいため、上記のいずれであってもよい。

資金移動可能なインターネットバンキングは月額などの有料で、照会のみのインターネットバンキングは無料提供されていることが多い。ついては、後者のインターネットバンキングを利用することで、ユーザの利用障壁を下げることができる。

なお、インターネットバンキングサーバ３０とＷＥＢ伝票生成サーバ２０との連携は、スクリーンスクレイピング方式により実現されてもよい。一方、インターネットバンキングサーバ３０とＷＥＢ伝票生成サーバ２０との連携は、インターネットバンキングサーバ３０が予め発行したアクセストークンをリクエスト（OAuth認証等）するとユーザの口座情報がレスポンスされるようなＡＰＩにより実現されてもよい。

（タブレット４０）
本実施形態に係るタブレット４０は、金融機関の営業店等に設置される端末である。

本実施形態に係るタブレット４０は、例えば、ユーザによる取引内容の入力、本人確認書類の撮影、通帳・キャッシュカードの読み取り、ＷＥＢ伝票Ｓに含まれる二次元コードＣの読み取り等の機能を有する。

（行員端末５０）
本実施形態に係る行員端末５０は、金融機関の営業店等に設置され、金融機関の行員が用いるＰＣ等の情報処理装置である。

行員は、行員端末５０を用いてユーザが入力した取引情報や、取引の状態を確認することができてよい。

本実施形態では、行員端末５０は、ＡＴＭ７０での現金引き出しの可否の確認とＡＴＭ７０での現金引き出しの完了を登録することに利用される。

（コード認証サーバ６０）
本実施形態に係るコード認証サーバ６０は、タブレット４０および行員端末５０に表示させるＷＥＢアプリケーションを提供するとともに、ＷＥＢ伝票生成サーバ２０から連携されたＷＥＢ伝票生成番号とトークン情報とを紐づけて管理する。

また、本実施形態に係るコード認証サーバ６０は、ＷＥＢ伝票生成サーバ２０から連携されたＷＥＢ伝票生成番号・トークン情報と、タブレット４０による二次元コードＣの読み取りにより取得されたＷＥＢ伝票生成番号・トークン情報との一致に基づく認証を行う。

本実施形態に係るコード認証サーバ６０は、両者が一致した場合、該当する手続きが正当なものであると判定し、ユーザの口座から金融機関が所有する入出金用の集中口座に指定された金額（取引金額）を移動することで、行員が印鑑照合なしに当該金額をＡＴＭ７０から出金可能な状態とする。なお、資金移動の指示は、勘定系システムが提供するＡＰＩを用いて行われてもよい。

上記のような各機能を実現するために、コード認証サーバ６０は、ＷＥＢ伝票生成サーバ２０と専用線ネットワーク８２を介して接続される。また、コード認証サーバ６０は、タブレット４０および行員端末５０と行内ネットワーク８４を介して接続される。専用線ネットワーク８２および行内ネットワーク８４は、金融機関等において構築される閉域網であり得る。

（ＡＴＭ７０）
本実施形態に係るＡＴＭは、金融機関が所有する入出金用の集中口座からの入集金を行う専用のＡＴＭであってもよい。

上記集中口座のキャッシュカードは行員が所持し、当該キャッシュカードの暗証番号は行員のみが知り得る。

行員は、ＡＴＭ７０に対し、上記キャッシュカードの挿入、暗証番号の入力、出金金額の入力を行い、集中口座に移動されたユーザの資金を現金として引き出す。

以上、本実施形態に係る情報処理システム１の機能構成例について説明した。以下、情報処理システム１が備える各装置の機能構成例についてより詳細に説明する。なお、以下においては、本実施形態に特徴的な機能構成を代表的に示す。情報処理システム１が備える各装置は、各図において示す以外の機能構成をさらに備え得る。

（ユーザ端末１０の機能構成例）
図３は、本実施形態に係るユーザ端末１０の機能構成例を示すブロック図である。図３に示すように、本実施形態に係るユーザ端末１０は、ブラウジング部１１０および印刷部１２０を少なくとも備える。

ブラウジング部１１０は、ＷＥＢ伝票生成サーバ２０により提供されるＷＥＢアプリケーションを動作させる機能である。ブラウジング部１１０は、各種のブラウザにより実現される。

印刷部１２０は、ＷＥＢ伝票生成サーバ２０により生成されたＷＥＢ伝票Ｓを印刷する。印刷部１２０は、各種のプリンタにより実現される。

（ＷＥＢ伝票生成サーバ２０の機能構成例）
図４は、本実施形態に係るＷＥＢ伝票生成サーバ２０の機能構成例を示すブロック図である。図４に示すように、本実施形態に係るＷＥＢ伝票生成サーバ２０は、ＷＥＢ伝票生成部２１０、認証連携部２２０、画面遷移部２３０、口座情報比較部２４０、トークン情報生成部２５０、コード生成部２６０、および情報連携部２７０等を備える。

ＷＥＢ伝票生成部２１０は、入金、出金、振込、および振替等の取引に応じた伝票の入力フォームを生成し、ユーザ端末１０上による取引に応じた伝票項目の入力を可能とする。例えば、出金であれば、ユーザは、上記入力フォームに対して、出金対象の店番や科目、口座番号、出金金額を入力できる。

ＷＥＢ伝票生成部２１０は、コード生成部２６０が生成した二次元コードＣを含むＷＥＢ伝票Ｓを生成し、ＷＥＢ伝票Ｓをユーザ端末１０に送信する。

認証連携部２２０は、インターネットバンキングサーバ３０にアクセスし、ユーザ認証をリクエストする。

画面遷移部２３０は、上記ユーザ認証の成立後、インターネットバンキングサーバ３０が提供する口座情報の表示画面への遷移をリクエストする。

なお、画面遷移部２３０は、スクリーンスクレイピング方式が採用される場合に必要な機能構成であり、専用ＡＰＩが具備される場合は、不要である。

口座情報比較部２４０は、インターネットバンキングに表示された口座情報とユーザ端末１０から受け付けた口座情報との一致を確認する。

トークン情報生成部２５０は、口座情報比較部２４０による口座情報の一致が確認された場合、トークン情報を生成する。

なお、本実施形態に係るトークン情報は、暗号学的に所定の強度を有する乱数、ハッシュ値であってもよい。

コード生成部２６０は、ユーザ端末１０から受け付けた手続きに関する入力情報に基づき、当該手続きの特定に用いられる識別番号（例えば、ＷＥＢ伝票生成番号）と、トークン情報と、をコード化した情報コード（例えば、二次元コードＣ）を生成する。

情報連携部２７０は、ＷＥＢ伝票生成番号およびトークン情報をコード認証サーバ６０に連携する。

（インターネットバンキングサーバ３０の機能構成例）
図５は、本実施形態に係るインターネットバンキングサーバ３０の機能構成例を示すブロック図である。図５に示すように、本実施形態に係るインターネットバンキングサーバ３０は、認証部３１０および口座情報表示部３２０を少なくとも備える。

認証部３１０は、認証情報に基づきユーザ認証を行う。認証部３１０は、例えば、ＩＤ／パスワードのような認証情報に基づきユーザ認証を行ってもよいし、予め発行したアクセストークンに基づきユーザ認証を行ってもよい。

口座情報表示部３２０は、ユーザ認証の成立後、口座情報の照会が可能な画面を表示する。

（タブレット４０の機能構成例）
図６は、本実施形態に係るタブレット４０の機能構成例を示すブロック図である。図６に示すように、本実施形態に係るタブレット４０は、ブラウジング部４１０およびコード読取部４２０を少なくとも備える。

ブラウジング部４１０は、コード認証サーバ６０により提供されるＷＥＢアプリケーションを動作させる機能である。ブラウジング部４１０は、各種のブラウザにより実現される。

コード読取部４２０は、ＷＥＢ伝票Ｓに含まれる二次元コードＣを読み取る機能である。

（行員端末５０の機能構成例）
図７は、本実施形態に係る行員端末５０の機能構成例を示すブロック図である。図７に示すように、本実施形態に係る行員端末５０は、ブラウジング部５１０を少なくとも備える。

ブラウジング部５１０は、コード認証サーバ６０により提供されるＷＥＢアプリケーションを動作させる機能である。ブラウジング部５１０は、各種のブラウザにより実現される。

（コード認証サーバ６０の機能構成例）
図８は、本実施形態にコード認証サーバ６０の機能構成例を示すブロック図である。図８に示すように、本実施形態に係るコード認証サーバ６０は、連携情報取得部６１０、コード情報取得部６２０、認証部６３０、資金移動部６４０、取引内容確認部６５０、および連携情報管理部６６０等を備える。

連携情報取得部６１０は、ＷＥＢ伝票生成サーバ２０から連携されるＷＥＢ伝票生成番号およびトークン情報を取得する。

コード情報取得部６２０は、タブレット４０により読み取られた二次元コードＣに記録される情報を取得する。上述したように、二次元コードＣに記録される情報には、少なくともＷＥＢ伝票生成番号およびトークン情報が含まれる。

認証部６３０は、ＷＥＢ伝票生成サーバ２０から連携されたＷＥＢ伝票生成番号・トークン情報と、タブレット４０による二次元コードＣの読み取りにより取得されたＷＥＢ伝票生成番号・トークン情報との一致に基づく認証を行う。

資金移動部６４０は、認証部６３０による認証が成立した場合、該当する手続きが正当なものであると判定し、ユーザの口座から金融機関が所有する入出金用の集中口座に指定された金額（取引金額）を移動する。

取引内容確認部６５０は、ＡＴＭ７０からの現金の引き出しが完了した場合、行員端末５０からの取引の消込を可能とする機能である。この際、行員は、残高照会を行い、集中口座に資金が残っていないことを確認することで出金漏れを防ぐことが可能である。

連携情報管理部６６０は、ＷＥＢ伝票生成サーバ２０から連携されたＷＥＢ伝票生成番号とトークン情報とを紐づけて記憶・管理する。

（ＡＴＭ７０の機能構成例）
図９は、本実施形態にＡＴＭ７０の機能構成例を示すブロック図である。図９に示すように、本実施形態に係るＡＴＭ７０は、現金引出部７１０を少なくとも備える。

現金引出部７１０は、ユーザ口座から集中口座への資金移動が行われた後、行員が所持するキャッシュカードおよび行員のみ知り得る暗証番号により現金を引き出すことを可能とする機能である。

＜＜１．３．処理の流れ＞＞
次に、本実施形態に係る情報処理システム１を用いた処理の流れについて具体例を挙げて説明する。

まず、図１０～図１２を参照して、本実施形態に係る情報処理システム１を用いたＷＥＢ伝票Ｓの生成の流れについて述べる。図１０～図１２は、本実施形態に係る情報処理システム１を用いたＷＥＢ伝票Ｓの生成の流れの一例を示す図である。

図１０～図１２に示す一例の場合、まず、ユーザがユーザ端末１０を用いて、ＷＥＢ伝票生成サーバ２０により提供されるＷＥＢアプリケーション上でＷＥＢ伝票生成メニューを選択する（Ｓ１０１）。

ＷＥＢ伝票生成サーバ２０は、ステップＳ１０１における選択に基づき取引メニューを生成する（Ｓ１０２）。

ユーザは、ステップ１０２において生成された取引メニューから「口座からの引き出し」を選択する（Ｓ１０３）。

ＷＥＢ伝票生成サーバ２０は、ステップＳ１０３における選択に基づき口座情報（店番、科目、口座番号）と引き出し金額を入力するための入力フォームを生成する（Ｓ１０４）。

ユーザは、ステップ１０４において生成された入力フォームに口座情報および引き出し金額を入力する（Ｓ１０５）。

ＷＥＢ伝票生成サーバ２０は、ステップＳ１０３における入力に基づきインターネットバンキングのログイン情報を入力するための入力フォームを生成する（Ｓ１０６）。

ユーザは、ステップ１０６において生成された入力フォームにログイン情報（例えば、ＩＤ／パスワード）を入力する（Ｓ１０７）。

ＷＥＢ伝票生成サーバ２０は、ステップＳ１０７において入力されたログイン情報を用いてインターネットバンキングにログインする（Ｓ１０８）。

インターネットバンキングサーバ３０は、ログインが成立した場合、ログイン後の画面を表示する（Ｓ１０９）。

ＷＥＢ伝票生成サーバ２０は、インターネットバンキングサーバ３０に対し、口座情報表示画面への遷移をリクエストする（Ｓ１１０）。

インターネットバンキングサーバ３０は、ステップＳ１１０におけるリクエストに基づき口座情報表示画面に遷移する（Ｓ１１１）。

ＷＥＢ伝票生成サーバ２０は、ステップＳ１１１において表示された画面から口座情報を取得する（Ｓ１１２）。

なお、ステップＳ１０７～Ｓ１１３に示す流れとは異なり、口座情報は、インターネットバンキングサーバ３０により提供されるＡＰＩを利用しても取得されてもよい。

次に、ＷＥＢ伝票生成サーバ２０は、ユーザ端末１０から入力された口座情報とインターネットバンキングサーバ３０から取得された口座情報との一致を確認する（Ｓ１１３）。ここでは、両者が一致した場合を想定する。

続いて、ＷＥＢ伝票生成サーバ２０は、インターネットバンキングからのログアウトをリクエストする（Ｓ１１４）。

インターネットバンキングサーバ３０は、ステップＳ１１４におけるリクエストに基づきログアウト処理を実行する（Ｓ１１５）。

ステップＳ１１４およびＳ１１５における処理により、セッションが残らないようにログアウトを行うことで、インターネットバンキングサーバ３０の負荷が軽減される。

次に、ＷＥＢ伝票生成サーバ２０は、トークン情報を生成する（Ｓ１１６）。

次に、ＷＥＢ伝票生成サーバ２０は、ステップＳ１１６において生成したトークン情報と、ＷＥＢ伝票生成番号とをコード認証サーバ６０に通知（連携）する（Ｓ１１７）。

コード認証サーバ６０は、ステップＳ１１７において通知されたトークン情報とＷＥＢ伝票生成番号と受け付け、両者を紐づけて記憶する（Ｓ１１８）。

次に、ＷＥＢ伝票生成サーバ２０は、少なくともトークン情報およびＷＥＢ生成番号を記録した二次元コードＣを生成する（Ｓ１１９）。

次いで、ＷＥＢ伝票生成サーバ２０は、ステップＳ１１９において生成した二次元コードＣを含むＷＥＢ伝票Ｓを生成する（Ｓ１２０）。

ユーザ端末１０は、ステップＳ１２１において生成されたＷＥＢ伝票Ｓを表示する（Ｓ１２１）。

次いで、ユーザ端末１０は、ＷＥＢ伝票Ｓを印刷する（Ｓ１２２）。

以上、本実施形態に係る情報処理システム１を用いたＷＥＢ伝票Ｓの生成の流れについて具体例を挙げて説明した。

次に、図１３および図１４を参照して、本実施形態に係る情報処理システム１を用いた営業店における処理の流れについて具体例を挙げて説明する。図１３および図１４は、本実施形態に係る情報処理システム１を用いた営業店における処理の流れの一例を示す図である。

図１３および図１４に示す一例の場合、まず、ユーザがタブレット４０を用いて、コード認証サーバ６０により提供されるＷＥＢアプリケーション上で「ＷＥＢ伝票による取引」を選択する（Ｓ２０１）。

コード認証サーバ６０は、ステップＳ２０１における選択に基づき二次元コード読み取り画面を生成する（Ｓ２０２）。

タブレット４０は、ステップＳ２０２において生成された二次元コード読み取り画面を表示し、ユーザは、当該画面に従いＷＥＢ伝票Ｓに含まれる二次元コードＣをタブレット４０に読み取らせる（Ｓ２０３）。

次に、コード認証サーバ６０は、ステップＳ２０３において読み取られたトークン情報・ＷＥＢ伝票生成番号と、ＷＥＢ伝票生成サーバ２０から連携されたトークン情報・ＷＥＢ伝票生成番号とが一致するか否かを確認する（Ｓ２０４）。ここでは、両者が一致した場合を想定する。

次いで、コード認証サーバ６０は、取引内容の確認画面を生成する（Ｓ２０５）。

タブレット４０は、ステップＳ２０５において生成された取引内容の確認画面を表示し、ユーザが当該画面において実行ボタンの押下等の確認操作を行う（Ｓ２０６）。

コード認証サーバ６０は、ステップＳ２０６において確認操作が行われたことに基づいてユーザの出金口座から入出金用の集中口座に資金を移動する（Ｓ２０７）。

次いで、コード認証サーバ６０は、集中口座から現金の引き出しが可能になった旨を示す画面を生成する（Ｓ２０８）。

行員端末５０は、ステップＳ２０８において生成された集中口座から現金の引き出しが可能になった旨を示す画面を表示する（Ｓ２０９）。

行員は、ステップＳ２０９において表示される画面を確認し、ＡＴＭ７０を操作し、集中口座から現金を引き出し、ユーザに受け渡す（Ｓ２１０）。

その後、行員は、行員端末５０を用いて集中口座からの現金引き出し完了に係る入力を行う（Ｓ２１１）。

コード認証サーバ６０は、ステップＳ２１１における入力に基づき、集中口座からの手巾済みの登録、すなわち取引の消込処理を行う（Ｓ２１２）。

以上、本実施形態に係る情報処理システム１を用いた営業店における処理の流れについて具体例を挙げて説明した。本実施形態に係る情報処理システム１によれば、インターネットバンキングのユーザ認証機能を利用して、認証済みのトークン情報が記録された二次元コードＣを含むＷＥＢ伝票Ｓを発行し、二次元コードＣに記録されるトークン情報と連携されたトークン情報との一致を確認することで、取引時の印鑑照合が不要となり、タブレットによる取引を完全セルフ化できる。

＜２．第２の実施形態＞
＜＜２．１．システム構成例＞＞
次に、本発明の第２の実施形態について説明する。上記第１の実施形態では、タブレットを用いたユーザによるセルフ取引が行われる場合を想定した。一方、本発明の第２の実施形態では、行員がＷＥＢ伝票Ｓを営業店端末を用いて処理する場合を想定する。

なお、以下においては、第１の実施形態と第２の実施形態の差異を中心に説明を行い、第１の実施形態と第２の実施形態とで共通する機能・効果等については詳細な説明を省略する。

図１５は、本発明の第２の実施形態に係る情報処理システム２の機能構成例を示すブロック図である。

第２の実施形態に係る情報処理システム２は、第１の実施形態に係る情報処理システム１と同様に、ユーザ端末１０、ＷＥＢ伝票生成サーバ２０、インターネットバンキングサーバ３０、およびコード認証サーバ６０を備える。

一方、第２の実施形態に係る情報処理システム２は、第１の実施形態に係る情報処理システム１とは異なり、タブレット４０、行員端末５０、およびＡＴＭ７０に代えて営業店端末５５を備える。

営業店端末５５は、行員が、ＷＥＢ伝票Ｓに含まれる二次元コードＣの読み取りを始めとするＷＥＢ伝票Ｓに関する一例の処理を実施する端末である。営業店端末５５は、行内ネットワーク８４を介してコード認証サーバ６０と接続される。

また、本実施形態に係るコード認証サーバ６０は、タブレット４０および行員端末５０に表示させるＷＥＢアプリケーションの提供に代えて、営業店端末５５に表示されるＷＥＢアプリケーションの提供を行う。

＜＜２．２．処理の流れ＞＞
第２の実施形態に係るＷＥＢ伝票Ｓの生成の流れは、第１の実施形態に係るＷＥＢ伝票Ｓの生成の流れと同一であるため、説明を省略する。

一方、第２の実施形態に係る営業店における処理の流れは第１の実施形態とは異なる。

図１６および図１７は、本発明の第２の実施形態に係る情報処理システム２を用いた営業店における処理の流れの一例を示す図である。

図１６および図１７に示す一例の場合、まず、行員がユーザからＷＥＢ伝票Ｓを受け取る（Ｓ３０１）。

行員は、営業店端末５５を操作し、二次元コードＣの読み取り画面を表示させ、ステップＳ３０１において受け取ったＷＥＢ伝票Ｓに含まれる二次元コードＣの読み取りを行う（Ｓ３０２）。

コード認証サーバ６０は、ステップＳ３０２における二次元コードＣの読み取りにより取得されたＷＥＢ伝票生成番号に基づき、同一の伝票番号に紐づいた取引が行われていないかをチェックする（Ｓ３０３）。ここでは、上記取引が行われていない場合を想定する。

次いで、コード認証サーバ６０は、ステップＳ３０２における二次元コードＣの読み取りにより取得されたトークン情報・ＷＥＢ伝票生成番号と、ＷＥＢ伝票生成サーバ２０から連携されたトークン情報・ＷＥＢ伝票生成番号とが一致するか否かを確認する（Ｓ３０４）。ここでは、両者が一致した場合を想定する。

次に、コード認証サーバ６０は、印鑑照合なしに取引可能な旨を営業店端末５５に表示させる（Ｓ３０５）。

営業店端末５５は、ステップＳ３０２における二次元コードＣの読み取りにより取得された取引内容を画面に反映する（Ｓ３０６）。

次いで、営業店端末５５は、ステップＳ３０６において画面に反映された取引内容で取引を実行する（Ｓ３０７）。

コード認証サーバ６０は、ステップＳ３０７における取引の実行に基づき勘定系取引を実行する（Ｓ３０８）。

行員は、ステップＳ３０８における勘定系取引の実行に伴いキャッシューから放出される現金をユーザに引き渡す（Ｓ３０９）。

以上、本実施形態に係る情報処理システム２を用いた営業店における処理の流れについて具体例を挙げて説明した。本実施形態に係る情報処理システム２によれば、インターネットバンキングのユーザ認証機能を利用して、認証済みのトークン情報が記録された二次元コードＣを含むＷＥＢ伝票Ｓを発行し、二次元コードＣに記録されるトークン情報と連携されたトークン情報との一致を確認することで、取引時の印鑑照合が不要となり、営業店端末５５を用いた事務処理を簡略化できる。

＜３．ハードウェア構成＞
続いて、本発明の一実施形態に係る情報処理装置９００のハードウェア構成例について説明する。情報処理装置９００は、ユーザ端末１０、ＷＥＢ伝票生成サーバ２０、インターネットバンキングサーバ３０、タブレット４０、行員端末５０、営業店端末５５、およびコード認証サーバ６０と同等のハードウェア構成を備える装置である。

なお、以下に説明する情報処理装置９００のハードウェア構成例は、一例に過ぎない。したがって、ユーザ端末１０、ＷＥＢ伝票生成サーバ２０、インターネットバンキングサーバ３０、タブレット４０、行員端末５０、営業店端末５５、およびコード認証サーバ６０のハードウェア構成は、以下に説明する情報処理装置９００のハードウェア構成から不要な構成が削除されてもよいし、新たな構成が追加されてもよい。

図１８は、本発明の一実施形態に係る情報処理装置９００のハードウェア構成を示す図である。情報処理装置９００は、プロセッサ９０１と、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）９０２と、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）９０３と、ホストバス９０４と、ブリッジ９０５と、外部バス９０６と、インタフェース９０７と、入力装置９０８と、出力装置９０９と、ストレージ装置９１０と、通信装置９１１と、を備える。

プロセッサ９０１は、演算処理装置および制御装置として機能し、各種プログラムに従って情報処理装置９００内の動作全般を制御する。ＲＯＭ９０２は、プロセッサ９０１が使用するプログラムや演算パラメータ等を記憶する。ＲＡＭ９０３は、プロセッサ９０１の実行において使用するプログラムや、その実行において適宜変化するパラメータ等を一時記憶する。これらはＣＰＵバス等から構成されるホストバス９０４により相互に接続されている。

ホストバス９０４は、ブリッジ９０５を介して、ＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ／Ｉｎｔｅｒｆａｃｅ）バス等の外部バス９０６に接続されている。なお、必ずしもホストバス９０４、ブリッジ９０５および外部バス９０６を分離構成する必要はなく、１つのバスにこれらの機能を実装してもよい。

入力装置９０８は、マウス、キーボード、タッチパネル、ボタン、マイクロフォン、スイッチおよびレバー等ユーザが情報を入力するための入力手段と、ユーザによる入力に基づいて入力信号を生成し、プロセッサ９０１に出力する入力制御回路等から構成されている。情報処理装置９００を操作するユーザは、この入力装置９０８を操作することにより、情報処理装置９００に対して各種のデータを入力したり処理動作を指示したりすることができる。

出力装置９０９は、例えば、ＣＲＴ（Ｃａｔｈｏｄｅ Ｒａｙ Ｔｕｂｅ）ディスプレイ装置、液晶ディスプレイ（ＬＣＤ）装置、ＯＬＥＤ（Ｏｒｇａｎｉｃ Ｌｉｇｈｔ Ｅｍｉｔｔｉｎｇ Ｄｉｏｄｅ）装置、ランプ等の表示装置およびスピーカ等の音声出力装置を含む。

ストレージ装置９１０は、データ格納用の装置である。ストレージ装置９１０は、記憶媒体、記憶媒体にデータを記録する記録装置、記憶媒体からデータを読み出す読出し装置および記憶媒体に記録されたデータを削除する削除装置等を含んでもよい。ストレージ装置９１０は、例えば、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）で構成される。このストレージ装置９１０は、ハードディスクを駆動し、プロセッサ９０１が実行するプログラムや各種データを格納する。

通信装置９１１は、例えば、ネットワークに接続するための通信デバイス等で構成された通信インタフェースである。また、通信装置９１１は、無線通信または有線通信のどちらに対応してもよい。

＜４．むすび＞
以上説明したように、本発明の一実施形態に係るＷＥＢ伝票生成サーバ２０は、ユーザ端末１０から受け付けた手続きに関する入力情報に基づき、当該手続きの特定に用いられる識別番号と、ユーザ端末１０から受け付けたユーザの認証情報に基づくユーザ認証が成立した場合に生成されるトークン情報と、をコード化した情報コードを含む手続きに係る帳票データを生成するＷＥＢ伝票生成部２１０を備える。

上記の構成によれば、十分なセキュリティ性を確保しつつ手続きに要する負荷を効果的に低減することが可能となる。

以上、添付図面を参照しながら本発明の好適な実施形態について詳細に説明したが、本発明はかかる例に限定されない。本発明の属する技術の分野における通常の知識を有する者であれば、特許請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本発明の技術的範囲に属するものと了解される。

例えば、上記実施形態では、手続きの例として金融機関における取引を挙げたが、本発明は、例えば、官庁手続き等におけるセキュリティ性の確保および負荷軽減にも適用可能である。

１０ ユーザ端末
２０ ＷＥＢ伝票生成サーバ
３０ インターネットバンキングサーバ
４０ タブレット
５０ 行員端末
５５ 営業店端末
６０ コード認証サーバ
２１０ ＷＥＢ伝票生成部
２２０ 認証連携部
２５０ トークン情報生成部
２６０ コード生成部
６１０ 連携情報取得部
６２０ コード情報取得部
６３０ 認証部
６４０ 資金移動部

Claims (11)

1. ユーザ端末から受け付けた手続きに関する入力情報に基づき、前記手続きの特定に用いられる識別番号と、前記ユーザ端末から受け付けたユーザの認証情報に基づくユーザ認証が成立した場合に生成されるトークン情報と、をコード化した情報コードを含む前記手続きに係る帳票データを生成する帳票生成部、
   を備える、
   情報処理装置。
2. 前記帳票生成部は、前記ユーザ端末から受け付けた前記手続きに関する入力情報に基づき、前記手続きの内容をさらにコード化した情報コードを含む前記帳票データを生成する、
   請求項１に記載の情報処理装置。
3. 前記手続きは、出金取引を含む、
   請求項２に記載の情報処理装置。
4. 前記手続きの内容は、口座情報または金額のうち少なくともいずれかを含む、
   請求項３に記載の情報処理装置。
5. 前記ユーザ認証は、インターネットバンキングにより実施される、
   請求項３に記載の情報処理装置。
6. 前記トークン情報は、乱数またはハッシュ値を含む、
   請求項１に記載の情報処理装置。
7. 前記情報コードは、二次元コードを含む、
   請求項１に記載の情報処理装置。
8. 前記トークン情報を生成するトークン生成部、
   をさらに備える、
   請求項１に記載の情報処理装置。
9. プロセッサが、ユーザ端末から受け付けた手続きに関する入力情報に基づき、前記手続きの特定に用いられる識別番号と、前記ユーザ端末から受け付けたユーザの認証情報に基づくユーザ認証が成立した場合に生成されるトークン情報と、をコード化した情報コードを含む前記手続きに係る帳票データを生成すること、
   を含む、
   情報処理方法。
10. コンピュータを、
    ユーザ端末から受け付けた手続きに関する入力情報に基づき、前記手続きの特定に用いられる識別番号と、前記ユーザ端末から受け付けたユーザの認証情報に基づくユーザ認証が成立した場合に生成されるトークン情報と、をコード化した情報コードを含む前記手続きに係る帳票データを生成する帳票生成部、
    を備える、情報処理装置、
    として機能させるプログラム。
11. ユーザ端末から受け付けた手続きに関する入力情報に基づき、前記手続きの特定に用いられる識別番号と、前記ユーザ端末から受け付けたユーザの認証情報に基づくユーザ認証が成立した場合に生成されるトークン情報と、をコード化した情報コードを含む前記手続きに係る帳票データを生成する帳票生成部と、
    前記情報コードに基づき前記手続きの正当性を認証する認証部と、
    を備える、
    情報処理システム。

Images