JP6694785B2

JP6694785B2 - モバイルマネジメントシステム、およびモバイルマネジメント方法

Info

Publication number: JP6694785B2
Application number: JP2016168667A
Authority: JP
Inventors: 田中　秀司; 秀司田中
Original assignee: Hitachi Omron Terminal Solutions Corp
Current assignee: Hitachi Omron Terminal Solutions Corp
Priority date: 2016-08-31
Filing date: 2016-08-31
Publication date: 2020-05-20
Anticipated expiration: 2036-08-31
Also published as: JP2018036806A

Description

本発明は、モバイルマネジメントシステム、および、モバイルマネジメント方法に関する。

ＡＴＭ（Automated Teller Machine）などの自動取引装置は、銀行の店舗だけでなく、デパート、コンビニエンスストアまたは駅構内などに幅広く設置されている。自動取引装置の利用取引については、今日までに様々な取引が海外を含めて増加傾向にある。また、今日フィンテックなどの技術発展によりさらモバイルと連携したＡＴＭの多機能化が重要となってきている。また、フィンテックの発展により銀行の口座がなくとも個人の携帯やコンビニなどでの一時的な口座を持つことでさらに利便性を増した現金などの取引が可能となってきている（例えば、特許文献１）。

ＣＮ１０３２８２９２９Ａ

モバイルを用いた現金の入出金取引において、現在では２Ｇ（第２世代移動通信システム）や３Ｇ（第３世代移動通信システム）を利用して取引が出来るような試行運用が海外を中心に広がりはじめている。その中で個人が日常処理している公共料金の支払い方法についてはまだ銀行などの窓口などで処理されていることが非常に多く顧客の待ち時間が多い。このことから取引方法についてＡＴＭでも公共料金の支払いを可能として、顧客の利便性向上を目的とする。

本課題を解決し、目的を達成するために、本発明にかかるモバイルマネジメントシステムは、ユーザ端末と、前記ユーザ端末を管理する端末管理サーバと、前記料金の支払を管理する支払管理サーバと、前記料金を支払うための自動取引装置とがネットワークを介して接続されたモバイルマネジメントシステムであって、前記支払管理サーバは、あらかじめ定められた前記ユーザ端末を利用するユーザが支払うべき料金を示す支払情報を端末管理サーバに送信し、更新支払情報を端末管理サーバに送信する支払管理サーバ通信部と、前記端末管理サーバから受信した前記支払うべき料金に対する残金と現実に支払われた額と前記支払情報とに基づいて、前記残金について新たな支払期限を設定した前記更新支払情報を生成する支払管理サーバ制御部と、を備え、前記端末管理サーバは、前記支払管理サーバから受信した前記支払情報を前記ユーザ端末に送信し、前記自動取引装置から前記現実に支払われた金額を受信し、残金と前記現実に支払われた金額とを前記支払管理サーバに送信し、前記支払管理サーバから受信した前記更新支払情報をユーザ端末に送信する支払管理サーバ通信部と、受信した前記現実に支払われた金額と前記支払情報とに基づいて未払いとなっている前記残金を計算する端末管理サーバ制御部と、を備え、前記ユーザ端末は、前記支払情報または前記更新支払情報を前記端末管理サーバから受信するユーザ端末通信部と、前記端末管理サーバから受信した前記支払情報からコード情報を生成するユーザ端末制御部と、前記自動取引装置は、前記コード情報を読み取る読取部と、前記コード情報に基づいて取引を実行する取引部と、前記取引の結果として前記現実に支払われた金額を前記端末管理サーバに送信する取引装置通信部と、を備えることを特徴とするモバイルマネジメントシステムとして構成される。

本発明によれば、エンドユーザの取引を円滑にすることで業種ごとの管理コストの削減を図ることができ、さらに自動取引装置の多機能化を図る事が可能となる。

コンピュータネットワークシステムを示す構成図である。モバイルマネジメントサーバを示す構成図である。支払事業会社管理サーバを示す構成図である。銀行ユーザ端末を示す構成図である。モバイルユーザ端末を示す構成図である。取引ログファイルデータを示す構成図である。ＡＴＭ−ＩＤマスタを示すテーブルである。モバイルＩＤマスタを示す画面図である。口座ＩＤマスタを示す構成図である。各業種ＩＤマスタを示す構成図である。ステータスマスタを示す構成図である。各業種取引管理表を示す構成図である。ＡＴＭ取引管理表を示す構成図である。ＡＴＭを示す構成図である。取引処理の処理手順を示すフローチャートである。入金処理の処理手順を示すフローチャートである。出金処理の処理手順を示すフローチャートである。入金処理の処理手順を示すフローチャートである（変形例）。後日残金分通知処理の処理手順を示すフローチャートである。本システムで行われる取引処理を示すイメージ図である。

以下、本発明の一実施形態を、図面を参照して詳細に説明する。但し、図面はもっぱら解説のためのものであって本発明の範囲を限定するものではない。
また、以下の説明は最大構成の内容について記載する。

図１は、コンピュータネットワークシステム（モバイルマネジメントシステム）１００の構成図である。コンピュータネットワークシステム１００は、モバイルユーザ端末を管理する端末管理サーバであるモバイルマネジメントサーバ１０１と、銀行端末１０３と、モバイルユーザ端末１０４、１０５と、ユーザが現実に料金を支払うための各銀行ＡＴＭ１０７と、料金の支払を管理する支払管理サーバである支払事業会社管理サーバ１０８がネットワーク１０２に接続されて構成される。本例では、１台の銀行端末と２台のモバイルユーザ端末を示しているが、その台数は任意である。

モバイルマネジメントサーバ１０１は、モバイルユーザ端末１０４、１０５を管理するサーバであり、データセンタなどの屋内に設置される。銀行ユーザ端末１０３と、モバイルユーザ端末１０４および１０５は、それぞれユーザが業務に使用する端末である。例えば、銀行ユーザ端末１０３は、銀行の係員が操作して窓口業務を行う端末である。また、例えば、モバイルユーザ端末１０４および１０５は、当該銀行等の金融機関と取引のあるユーザが操作して取引処理を行う端末である。窓口業務の例としては、窓口での振込み取引がある。また、取引処理の例としては、公共料金の支払い処理がある。

銀行ユーザ端末１０３と、モバイルユーザ端末１０４および１０５は、モバイルマネジメントサーバ１０１が処理した出力情報に基づいて端末側の処理を実行する。支払事業会社管理サーバ１０８は、ユーザの個人取引情報を管理するサーバである。支払事業会社管理サーバ１０８は、ユーザ端末１０６（銀行ユーザ端末１０３と、モバイルユーザ端末１０４、１０５）および各銀行ＡＴＭ１０７に対し、ステータス情報や管理情報などを伝送する。ホストコンピュータ１０９は、銀行等の金融機関が管理するサーバであり、当該金融機関が行う各種取引に関する処理（例えば、利用者との間で行われる入金処理）を実行する。図２は、モバイルマネジメントサーバ１０１を示す構成図である。モバイルマネジメントサーバ１０１は、記憶部３０１と、コントローラ（ＣＰＵなどの制御部）３０２と、メモリ３０３と、表示部３０４と、通信制御部３０５とを具備する。記憶部３０１には、取引ログファイルデータ３１０（図６）と、ＡＴＭ−ＩＤマスタ３１１（図７）と、モバイルＩＤマスタ３１２（図８）と、口座ＩＤマスタ３１３（図９）と、ＡＴＭ−ＩＤ、モバイルＩＤ、口座ＩＤ管理テーブル（以下、ＩＤ管理テーブルとする。図１０）３１４と、各種取引管理マスタ３１５（図１１〜１３）と、個人ＩＤマスタ３１６、ログ分析部３０００と、管理表示部(ＢＲ管理マネージャ・取引履歴)４１００が格納される。モバイルマネジメントサーバ１０１が実行する処理や格納されるデータについては後述する。個人ＩＤマスタ３１６は、特に図示していないが、ユーザを認証するための認証情報（例えば、指静脈や指紋等、ユーザの生体情報）が、ユーザを識別するための個人ＩＤに対応付けて記憶されている。

図３は、支払事業会社管理サーバ１０８を示す構成図である。支払事業会社管理サーバ１０１は、記憶部３０１と、コントローラ（ＣＰＵなどの制御部）３０２と、メモリ３０３と、通信制御部３０４と、表示部３０５とを具備する。記憶部３０１には、取引ログファイルデータ３１０と、ＡＴＭ−ＩＤマスタ３１１と、モバイルＩＤマスタ３１２と、口座ＩＤマスタ３１３と、ＡＴＭ−ＩＤ、モバイルＩＤ、口座ＩＤ管理テーブル３１４と、各種取引管理マスタ３１５と個人ＩＤマスタ３１６、ログ分析部３０００と、管理表示部(ＢＲ管理マネージャ・取引履歴)４１００が格納される。支払事業会社管理サーバ１０８に記憶されるデータについては図２と同様であるため、ここではその説明を省略する。

図４は、銀行ユーザ端末１０３の概略構成を機能ブロック化して示す説明図、図５はモバイルユーザ端末１０４、１０５の概略構成を機能ブロック化して示す説明図である。これら図に示すように、各ユーザ端末は、同じ構成を備えるので、以下、銀行ユーザ端末１０３を例に採り、説明する。銀行ユーザ端末１０３は、記憶部４０１と、コントローラ（ＣＰＵなどの制御部）４０２と、メモリ４０３と、表示部４０４と、通信制御部４０５とを具備する。記憶部４０１には、ログ分析部３０００と、管理表示部４１００とが格納される。なお、処理部（ログ分析部３０００、管理表示部４１００）は、どの端末（モバイルマネジメントサーバ１０１、銀行ユーザ端末１０３、モバイルユーザ端末１０４、１０５）も有しているが、これらの処理部は、どの装置でも同じ処理内容が実行される。以下で、自装置内の処理部の処理対象のデータが自装置内に存在しないときには、他装置から処理対象のデータを受信したり、送信したりする。例えば、銀行ユーザ端末１０３と、保守会社ユーザ端末１０４のログ分析部３０００が、取引ログファイルデータ３１０を読み込むときには、モバイルマネジメントサーバ１０１のログ分析部３０００から当該ログ分析部の分析結果を受信する。

図６は、取引ログファイルデータ３１０のデータ構成を示す説明図である。図６に示すログファイルデータ３１０は、本システムで管理される全てのＡＴＭ１０７において、それぞれのＡＴＭ１０７で発生した全ての取引ログを登録するためのテーブルである。図６に示すように、取引ログファイルデータ３１０は、年月日時コード７０１と、銀行を識別する銀行コード７０２と、支店を識別する支店／営業所コード７０３と、ＡＴＭを識別し、各取引を判定するＡＴＭ−ＩＤ７０４と、そのＡＴＭで取引されたときのログを識別するバーコードＮｏ７０５と、その取引を実行した業種を識別する業種コード７０６と、その取引で処理された取引金額７０７と、その取引後の残金を示す差額７０８とをそれぞれ対応づけて構成され、支払事業会社管理サーバ１０８に格納されている。取引ログファイルデータ３１０は、それぞれのＡＴＭ１０７における取引が実行され、その取引結果である取引ログファイルが各ＡＴＭ１０７から送信された際に、更新される。年月日時コード７０１は、ＡＴＭ１０７が取引を実行したときの時間である。銀行コード７０２は、その取引が完了したＡＴＭ１０７を運用する銀行の銀行コードが格納される。支店／営業店コード７０３は、その取引が完了したＡＴＭ１０７を運用する銀行の支店／営業店のコードが格納される。ＡＴＭ−ＩＤ７０４は、その取引が完了したＡＴＭ１０７の製造番号等が格納される。バーコードＮＯ７０５は、ＡＴＭ１０７での取引が完了したときのログのコードが格納される。業種コード７０６は、ＡＴＭで行われた取引の業種が格納される。取引金額７０７は、ＡＴＭで行われた取引の金額が格納される。差額７０８は、ＡＴＭで取引が行われた後の残高が格納される。

図７は、ＡＴＭ−ＩＤマスタ３１１のデータ構成を示す説明図である。ＡＴＭ−ＩＤマスタ３１１は、フィールドで稼動しているＡＴＭを識別するための情報（製造番号など）をあらかじめ格納するテーブルである。図７に示すように、ＡＴＭ−ＩＤマスタ３１１は、銀行コード８０１、支店／営業店コード８０２、エリアコード８０３、ＡＴＭ−ＩＤ８０４を関連付けて格納する。銀行コード８０１は、登録対照とする銀行のコードを格納する。支店／営業店コード８０２は、本システムの登録対象とする支店／営業店のコードを格納する。エリアコード８０３は、その支店や営業点があるエリアを格納する。ＡＴＭ−ＩＤ８０４は、前記支店／営業店コードの支店／営業店に設置されているＡＴＭ１０７のＡＴＭ−ＩＤを格納する。これらのほか、ＡＴＭ１０７のハードウェアの構成情報を格納してもよい。ＡＴＭ−ＩＤマスタ３１１は、支店や営業店等でのＡＴＭ１０７の追加や変更が発生したときに、データの入力を受けて更新されるが、データの入力・更新は、銀行本店や支店の管理コンピュータや銀行ユーザ端末１０３からのデータの入力・更新に限られる。つまり、モバイルユーザ端末１０４、或いはＡＴＭ１０７における保守管理用操作部のデータの入力操作では、ＡＴＭ−ＩＤマスタ３１１のデータ書き換えは不可とされる。なお、上記ハードウェアの構成情報は、個々のＡＴＭに特有のハード的な機器情報の他、ＡＴＭでの運用が想定されている複数のモバイルごとのモバイルＩＤの組み合わせ情報も含まれ、このモバイル組合せ情報にあっても、その更新は、銀行本店や支店の管理コンピュータや銀行ユーザ端末１０３からのデータ更新に限られる。

図８は、モバイルＩＤマスタ３１２のデータ構成例である。モバイルＩＤマスタ３１２は、フィールドで稼動しているモバイルユーザ端末１０４、１０５を識別するための情報をあらかじめ格納するテーブルである。図８に示すように、モバイルＩＤマスタ３１２は、業種コード９０１、モバイルＩＤ９０２を関連付けて格納する。業種コード９０１は、本システムに登録して鳥非違を実行する業種のコードを格納する。モバイルＩＤ９０２は、銀行の資産管理部門において登録される。例えば、上記業種の取引を金融機関を介して実行するモバイルユーザ端末１０４、１０５の識別情報が、当該金融機関の資産管理部門のコンピュータから登録される。モバイルＩＤマスタ３１２は、モバイルユーザ端末の追加や変更が発生したときに更新される。例えば、ユーザがある業種の取引を実行する際に利用する金融機関を業種コード９０１、モバイルＩＤ９０２とともに申込書に記入し、その業種の企業から当該金融機関にその申込書が送付され、当該金融機関の行員が、資産管理部門のコンピュータから上記申込書に記入された業種コード９０１、モバイルＩＤ９０２を入力する際に更新される。実際には、モバイルＩＤ９０２とともに、その個人の携帯電話番号およびメールアドレスが登録される。

図９は、口座ＩＤマスタ３１３のデータ構成を示す説明図である。口座ＩＤマスタ３１３は、ユーザが利用する銀行の口座ＩＤを格納するテーブルである。図９に示すように、口座ＩＤマスタ３１３は、銀行コード１００１と、口座ＩＤ１００２と、個人ＩＤ１００３とを関連付けて格納する。銀行コード１００１は、図７における銀行コードと同様のコードである。口座ＩＤ１００２は、ユーザが取引で使用する口座番号を格納する。個人ＩＤ１００３は、ユーザ自身を識別するためのＩＤを格納する。口座ＩＤマスタ３１３は、口座や、個人ＩＤなどの追加や変更が発生したときに更新される。例えば、ユーザが取引に利用する口座が、転居等によりある支店から別の支店に移った場合に、そのユーザからの住所変更届に基づいて更新される。

図１０は、各業種ＩＤマスタ３１４のデータ構成を示す説明図である。各業種ＩＤマスタ３１４は、各銀行と取引のある各業種のＩＤを格納するテーブルである。図１０に示すように、各業種ＩＤマスタ３１４は、銀行コード１１０１、支店／営業店コード１１０２、業種コード１１０３を関連付けて格納する。銀行コード１１０１は、登録対象とする銀行のコードを格納する。支店／営業店コー１１０２は、登録対象とする支店／営業店のコードを格納する。業種コード１１０３は、銀行と取引のある業種のコードを格納する。各業種ＩＤマスタ３１４は、銀行との取引の追加や変更が発生したときに、データの入力を受けて更新されるが、データの入力・更新は、銀行本店や支店の管理コンピュータや銀行ユーザ端末１０３からのデータの入力・更新に限られる。つまり、モバイルユーザ端末１０４や１０５では、各業種ＩＤマスタ３１４のデータ書き換えは不可とされる。これらの各項目についてはすでに述べたとおりであるため、ここではその説明を省略する。

図１１は、各種取引管理マスタ３１５に記憶されるステータスマスタ３１７のデータ構成例である。ステータス情報マスタ３１７は、取引記録のステータス情報を格納する。取引ステータスの追加や変更が発生したときに、ステータスマスタ３１７が読み取られ、取引ステータスが更新される。

図１２は、各種取引管理マスタ３１５に記憶される各業種取引管理表３１８のデータ構成例である。各業種取引管理表３１８は、フィールドで取引される取引記録を格納するテーブルである。各業種取引管理表３１８は、バーコードＮＯ１２０１、業種コード１２０２、取引先口座１２０３、銀行コード１２０４、支店／営業店コード１２０５、銀行口座ＩＤ１２０６、取引金額１２０７を関連付けて格納する。バーコードＮＯ１２０１、業種コード１２０２は、図６に示したものと同様であり、取引先口座１２０３は図９に示した口座ＩＤと同様であるためここではその説明を省略する。

銀行コード１５０４は、登録対象とする銀行のコードを格納する。支店／営業店コード１５０５は、登録対象とする支店／営業店のコードを格納する。モバイル内金種１５０６はモバイルＩＤと関連付けてモバイル内金種１５０６を格納する。モバイルＩＤマスタ３１２は、支店や営業店、モバイルの追加や変更が発生したときに更新される。ここでは、モバイル内金種を複数持たせることも可能である。

図１３は、各種取引管理マスタ３１５に記憶されるＡＴＭ取引管理表３１９のデータ構成例である。ＡＴＭ取引管理表３１９は、フィールドで稼動しているＡＴＭ１０７の取引記録を格納するテーブルである。銀行コード１３０１、支店／営業店コード１３０２、エリアコード１３０３、ＡＴＭ−ＩＤ１３０４、年月日時１３０５、取引金額１３０６を関連付けて格納する。銀行コード１３０１、支店／営業店コード１３０２、エリアコード１３０３、ＡＴＭ−ＩＤ１３０４は、図７に示した銀行コード、支店／営業店コード、エリアコード、ＡＴＭ−ＩＤと同様であるためここではその説明を省略する。年月日時１３０５は、実際に取引が行われた日時であり、取引金額１３０６は、そのときに取引された金額である。

次に、図１４を参照して、ＡＴＭ１０７の構成について説明する。図１４は、ＡＴＭ１０７の機能構成を示すブロック図である。ＡＴＭ１０７は、表示入力部１１、明細書発行部１２、紙幣部１３及びカード部１４の他に、ネットワーク３を経由してホストコンピュータと接続された通信制御部１５と、ＡＴＭ１の制御プログラム、取引記録、ＡＴＭ１内の紙幣情報などを記憶する記憶部１６と、これらの部位を制御する制御部２０とを備える。なお、表示入力部１１は、取引操作を受け付けたり、取引結果を表示するタッチパネルのほか、後述するバーコードやＱＲコード（登録商標）を読み取るための読取部であるリーダを含む。

また、紙幣部１３は、入金処理時に利用者により投入された紙幣（入金紙幣）の受け付けと出金処理時に利用者に対して出金される紙幣（出金紙幣）の払い出しを行う入出金部１８と、入金処理時、出金処理時及び精査処理時に紙幣の金種、正損、真偽、折れ・破れなどの紙幣状態などを判別する紙幣判別部１９と、紙幣判別部１９で読み取った入金紙幣の金種、枚数、合計金額などを利用者により確認され、ホストコンピュータ１０９にて入金処理が確定するまでの間、紙幣を一時的に収納する一時保留部２０と、紙幣の収納を行う収納部４０と、紙幣を各部に搬送する紙幣搬送部３０と、これらの部位を制御する紙幣制御部１７とを備える。本例では、紙幣に関する処理部について示しているが、実際には、紙幣と同様の機能を有した硬貨部を有し、紙幣部および硬貨部を含む取引部を構成している。

図１５は、ＡＴＭ１０７での取引情報を読取り、ステータスの更新をする取引処理の処理手順を示すフローチャートである。この処理は、モバイルユーザ端末１０４、１０５のコントローラ５０２により実行される。モバイルユーザ端末１０４、１０５は、タッチパネルから構成される表示部５０４から入金取引操作が受け付けられたか否かを判定する（Ｓ１５０１）。入金取引操作は、例えば、あらかじめ上記端末にインストールされたアプリケーションを起動してメニュー画面に含まれる入金取引ボタンの押下を受け付けることにより判定することができる。

Ｓ１５０１で入金取引操作が受け付けられたと判定された場合（Ｓ１５０１；Ｙｅｓ）、次に、モバイルユーザ端末１０４、１０５の表示部５０４は、ユーザから入金額の仮登録操作を受け付け、コントローラ５０２は、受け付けた入金額をメモリ５０３に記憶する（Ｓ１５０２）。仮登録される入金額としては、例えば、ユーザが毎月の公共料金として少なくとも１，０００円の支払いをする場合には、その金額が入力される。Ｓ１５０２では、上記金額のほか、図１２に示した各業種取引管理表３１８の各項目の情報が入力される。

続いて、モバイルユーザ端末１０４、１０５のコントローラ５０２は、取引情報を読込み、適切な取引であるか否かを判定する（Ｓ１５０３）。取引情報とは、例えば、図９に示した口座ＩＤマスタ３１３を参照して、あらかじめシステムに登録されたユーザであるかといった本人認証や、あらかじめ登録されている銀行の口座であるかといった口座確認に関する処理結果であり、これらの処理結果が肯定的な結果（例えば、本人認証された旨、口座が登録されている旨）を支払事業会社管理サーバ１０８に問い合わせることにより得られる情報である。

コントローラ５０２は、上記判定の結果、適切な取引の場合（Ｓ１５０３；Ｙｅｓ）、Ｓ１５０２で仮登録した金額と、そのユーザの個人ＩＤと、その個人ＩＤに対応する銀行コードと口座ＩＤとを図９に示した口座マスタ３１３を参照して取得するとともに、これらの情報とＳ１５０２で入力された図１２に示した各業種取引管理表３１８の各項目とをバーコード化し、メモリ５０３に記憶する（Ｓ１５０４）。バーコード化の手法については、従来から知られている様々な手法を用いることができる。本例ではバーコードについて説明しているが、ＱＲコード等の他の形態により構成される様々なコード情報についても同様に適用することができる。モバイルユーザ端末１０４、１０５のコントローラ５０２は、バーコードを生成すると、その旨を支払事業会社管理サーバ１０８に通知するとともに、生成したバーコードを送信し、支払事業会社管理サーバ１０８のコントローラ３０２は、ステータスマスタ３１７のステータスを更新するとともに、送信されたバーコードを、図１２に示した各業種取引管理表３１８の各項目を含むレコードに対応付けて記憶する（Ｓ１５０５）。例えば、コントローラ３０２は、上記通知を受けると、初期値（例えばスペース）から、バーコードが登録され取引実行前の状態を示す「取引待ち」に更新する。ステータスは、個人ごとの取引を特定するため、実際には、上記個人ＩＤや日時に対応付けて記憶される。

Ｓ１５０１の過程で入金取引操作以外の取引操作が受け付けられたと判定された場合（Ｓ１５０１；Ｎｏ）、モバイルユーザ端末１０４、１０５のコントローラ５０２は、入力された金額が出金に関する金額であると判断し、入金額の場合と同様に、その出金額を仮登録する（Ｓ１５０６）。続いて、モバイルユーザ端末１０４、１０５のコントローラ５０２は、Ｓ１５０３と同様、取引情報を読込み、適切な取引であるか否かを判定する（Ｓ１５０７）。コントローラ５０２は、上記判定の結果、適切な取引の場合（Ｓ１５０７；Ｙｅｓ）、Ｓ１５０４と同様、Ｓ１５０６で仮登録した金額と、そのユーザの個人ＩＤと、その個人ＩＤに対応する銀行コードと口座ＩＤとを図９に示した口座マスタ３１３を参照して取得するとともに、これらの情報とＳ１５０６で入力された図１２に示した各業種取引管理表３１８の各項目とをバーコード化し、メモリ５０３に記憶する（Ｓ１５０８）。モバイルユーザ端末１０４、１０５のコントローラ５０２は、バーコードを生成すると、その旨を支払事業会社管理サーバ１０８に通知するとともに、生成したバーコードを送信し、支払事業会社管理サーバ１０８のコントローラ３０２は、ステータスマスタ３１７のステータスを更新するとともに、送信されたバーコードを、図１２に示した各業種取引管理表３１８の各項目を含むレコードに対応付けて記憶する（Ｓ１５０９）。

一方、コントローラ５０２は、Ｓ１５０７で適切な取引でないと判定した場合（Ｓ１５０７；Ｎｏ）、その旨を支払事業会社管理サーバ１０８に通知し、支払事業会社管理サーバ１０８のコントローラ３０２は、例えば、ステータスマスタ３１７のステータスを上記初期値から取引不可であることを示す「取引否」に更新して取引を終了する（Ｓ１５１０）。本処理が終了すると、適切な取引と判断された場合には、ユーザのバーコードが生成される。バーコードの生成は、ユーザ所望のタイミングで、金額を変更することができる。例えば、上記例では入金金額を１，０００円である前提で説明したが、ある任意の月の支払いを２，０００円とすることができる。

図１６は、図１５の処理においてバーコードが生成された場合の入金処理の処理手順を示すフローチャートである。まず、ＡＴＭ１０７の表示入力部１１の読取部は、モバイルユーザ端末１０４、１０５で生成されたバーコードを読み取り、登録されているバーコードであるか否かを判定する。（Ｓ１６０１）。実際には、ユーザがモバイルユーザ端末１０４、１０５のコントローラ５０２が、図１５の処理でメモリ５０３に記憶したバーコードを読み出して表示部５０４に表示し、そのバーコードをＡＴＭ１０７の表示入力部１１にかざすことにより、読み取られる。ＡＴＭ１０７の制御部２０は、読み取られたバーコードを支払事業会社管理サーバ１０８に送信し、あらかじめ登録されているバーコードと比較して一致するか否かを判定することにより、正しいバーコードであるか否かを判定する。そして、正しいバーコードと判定された場合（Ｓ１６０１；Ｙｅｓ）、次に、ＡＴＭ１０７の制御部２０は、ホストコンピュータ１０９に問い合わせる等してそのユーザの本人認証を行う。本人認証は、例えば、静脈認証等の生体認証により行われる（Ｓ１６０２）。本人認証については、従来から知られている様々な技術を利用することができる。

ＡＴＭ１０７の制御部２０は、上記生体認証で本人確認が出来た場合（Ｓ１６０２；Ｙｅｓ）、さらにそのユーザの個人ＩＤを確認する（Ｓ１６０３）。例えば、ＡＴＭ１０７の制御部２０は、あらかじめ登録されているバーコードに含まれる個人ＩＤと、読み取られたバーコードに含まれる個人ＩＤとを比較して一致するか否かを判定することにより、正しいバーコードであるか否かを判定する。ＡＴＭ１０７の制御部２０は、個人ＩＤを確認できた場合に入金取引を開始する（Ｓ１６０４）。

さらに、ＡＴＭ１０７の制御部２０は、紙幣部１３の入出金部１８から入金を受け付けて、入金された金額が適正額か否かを判定する（Ｓ１６０５）。例えば、制御部２０は、入出金部１８から入金された紙幣を紙幣識別部１９が識別した結果得られた金額と、上記バーコードに含まれる金額（図１２に示した各業種取引管理表３１８の取引金額１２０７）とが一致しているか否かを判定することにより、上記適正額を判定する。

ＡＴＭ１０７の制御部２０は、上記金額が一致して適性額であると判定した場合（Ｓ１６０５；Ｙｅｓ）、その後、紙幣搬送部３０が入金された金額分の紙幣を収納部４０まで搬送して収納し、入金取引を終了させる（Ｓ１６０６）。

ＡＴＭ１０７の制御部２０は、入金取引を終了させると、その旨を支払事業会社管理サーバ１０８に通知し、支払事業会社管理サーバ１０８のコントローラ３０２は、ステータスマスタ３１７のステータスを更新する（Ｓ１６０７）。例えば、コントローラ３０２は、上記通知を受けると、「取引中」から、入金取引の終了を示す「完了」に更新する。ステータスは、個人ごとの取引を特定するため、実際には、上記個人ＩＤや日時に対応付けて記憶される。

一方、ＡＴＭ１０７の制御部２０は、上記金額が一致せず適性額でないと判定した場合（Ｓ１６０５；Ｎｏ）、後日残金分通知処理を実行する（Ｓ１６０８）。後日残金分通知処理については、図１９を用いて後述する。

図１７は、図１５の処理においてバーコードが生成された場合の出金処理の処理手順を示すフローチャートである図１６の場合と同様、まず、ＡＴＭ１０７の表示入力部１１は、モバイルユーザ端末１０４、１０５で生成されたバーコードを読み取り、登録されているバーコードであるか否かを判定する（Ｓ１７０１）。そして、正しいバーコードと判定された場合（Ｓ１７０１；Ｙｅｓ）、次に、ＡＴＭ１０７の制御部２０は、図１６の場合と同様、ユーザの本人認証を行う（Ｓ１７０２）。

ＡＴＭ１０７の制御部２０は、上記生体認証で本人確認が出来た場合（Ｓ１７０２；Ｙｅｓ）、図１６の場合と同様、さらにそのユーザの個人ＩＤを確認する（Ｓ１７０３）。ＡＴＭ１０７の制御部２０は、個人ＩＤを確認できた場合に出金取引を開始する（Ｓ１７０４）。

さらに、ＡＴＭ１０７の制御部２０は、紙幣部１３の収納部４０から紙幣を繰出して、出金された金額が適正額か否かを判定する（Ｓ１７０５）。例えば、制御部２０は、収納部４０から繰出された紙幣を紙幣判別部１９が判別し、その結果得られた金額と、上記バーコードに含まれる金額（図１２に示した各業種取引管理表３１８の取引金額１２０７）とが一致しているか否かを判定することにより、上記適正額を判定する。

ＡＴＭ１０７の制御部２０は、上記金額が一致して適性額であると判定した場合（Ｓ１７０５；Ｙｅｓ）、その後、紙幣搬送部３０が繰出された金額分の紙幣を入出金部１８まで搬送し、不図示のシャッタを開けて出金取引を終了させる（Ｓ１７０６）。

ＡＴＭ１０７の制御部２０は、出金取引を終了させると、その旨を支払事業会社管理サーバ１０８に通知し、支払事業会社管理サーバ１０８のコントローラ３０２は、ステータスマスタ３１７のステータスを更新する（Ｓ１７０７）。例えば、コントローラ３０２は、上記通知を受けると、「取引中」から、入金取引の終了を示す「完了」に更新する。ステータスは、個人ごとの取引を特定するため、実際には、上記個人ＩＤや日時に対応付けて記憶される。

なお、本例では、出金については入金の場合のように一部の金額の紙幣を出金する場合について示していないが、入金の場合と同様、上記金額が一致せず適性額でないと判定した場合（Ｓ１７０５；Ｎｏ）、後日残金分通知処理を実行してもよい。

図１８は、図１５の処理においてバーコードが生成された場合の公共料金などの入金処理の変形例の処理手順を示すフローチャートである。図１６に示した例では、あらかじめ登録されているバーコードであることや、本人確認のための認証を行った上で入金取引を開始することとした。しかし、あらかじめこのような確認が事前になされている場合には、これらの確認を行うことなく処理を実行するほうが処理時間を短縮することができ、ユーザにとって利便性が高くなる。そのため、図１８に示すように、ＡＴＭ１０７の表示入力部１１の読取部は、モバイルユーザ端末１０４、１０５で生成されたバーコードを読み取り（Ｓ１８０１）、次に、図１６のＳ１６０４と同様に入金取引を開始し、以降、図１６のＳ１６０５〜Ｓ１６０８までと同様の処理を実行する（Ｓ１８０３〜Ｓ１８０６）。なお、図１８では入金処理について説明したが、出金処理の場合も同様に考えることができる。

図１９は、残金が発生した場合の処理（後日残金分通知処理）の処理手順を示すフローチャートである。本処理では、図１６、１８で残金が発生した場合に全支払い額と入金額の差額について確認する（Ｓ２１０１）。例えば、ＡＴＭ１０７の制御部２０は、入出金部１８から入金された紙幣を紙幣識別部１９が識別した結果得られた金額と、上記バーコードに含まれる金額（図１２に示した各業種取引管理表３１８の取引金額１２０７）との差額を算出する。そして、ＡＴＭ１０７の制御部２０は、上記バーコードに含まれる個人データ（例えば、ユーザの個人ＩＤ、その個人ＩＤに対応する銀行コードと口座ＩＤ）をキーにして、ユーザの取引状況を示すデータを収集する（Ｓ２１０２）。

ＡＴＭ１０７の制御部２０は、収集したデータと算出した差額を元に帳票を作成する（Ｓ２１０３）。例えば、ＡＴＭ１０７の制御部２０は、個人ＩＤごとに、上記差額である支払いの残額を記載した帳票データを出力する。ＡＴＭ１０７の制御部２０は、モバイルＩＤ９０２に対応するメールアドレスに、上記帳票データを送信して通知する
（Ｓ２１０４）。ユーザは、このような通知を受け取ることにより、未払い残高があることを容易に把握することができる。

図２０は、本システムで行われる取引処理を示すイメージ図である。図２０に示すように、まず、支払事業者管理サーバ１０８がモバイルＩＤマスタ３１２、口座ＩＤマスタ３１３、各業種ＩＤマスタ３１４、個人ＩＤマスタ３１６、各業種取引管理表３１８、ＡＴＭ取引管理表３１９を参照して支払情報（支払ｉｎｆｏ）を生成し、モバイルマネジメントサーバ１０１に送信する（１）。支払情報は、例えば、あらかじめ定められた毎月支払うべき公共料金の金額、契約や支払い方法に応じた取引種類（口座引き落とし、振り込み等）、支払先口座、モバイルユーザ端末１０４、１０５のモバイルＩＤ、メールアドレスなど、ユーザやモバイルユーザ端末を識別するための情報を含む。

モバイルマネジメントサーバ１０１は、支払事業者管理サーバ１０８から受信した支払情報をモバイルユーザ端末１０４、１０５に送信して通知する（２）。ユーザは、このタイミングで、支払うべき金額を把握することができる。モバイルユーザ端末１０４、１０５は、仮登録された金額を含む支払情報からバーコードやＱＲコード等のコード情報を生成し（３）、ＡＴＭ１０７が、コード情報を読み取って取引を実行し、現実に支払われた額と支払情報との差額をチェックし、その結果をモバイルマネジメントサーバ１０１に通知する（４）。

モバイルマネジメントサーバ１０１は、現実に支払われた額と支払情報との差額から残金を計算し（５）、支払情報のほか現実に支払われた額および上記差額を示す残金情報（残金ｉｎｆｏ）を支払事業者管理サーバ１０８に通知する（６）。支払事業者管理サーバ１０８は、通知された残金情報に含まれる残金をチェックして未回収となっている金額を確認し、その金額に応じて支払期限を計算して新たな支払期限として再設定し、支払情報を参照して上記新たな支払期限および残金情報を含む更新支払情報（更新支払ｉｎｆｏ）を生成する（７）。例えば、現実に支払われた額が本来支払うべき額の１０％（閾値）に満たない場合には、次回に残金を全額回収することは困難であると判断して支払期限を延期するなど、残金の大きさに応じて支払期限を変更して再設定し、現在から変更後の期限までの期間で残金を均等割りした更新支払情報を生成する。更新支払情報には、上記支払情報の内容を含む。

支払事業者管理サーバ１０８は、生成した更新支払情報をモバイルマネジメントサーバ１０１に送信し（８）、モバイルマネジメントサーバ１０１は、支払事業者管理サーバ１０８から受信した更新支払情報を、支払情報により示されたモバイルユーザ端末１０４、１０５に送信して通知する（９）。ユーザは、このタイミングで、支払うべき残金や支払期限を把握することができる。以降、上記（３）〜（９）と同様の処理が、残金支払が完了するまでくりかえし実行され、残金がなくなるまでくりかえしユーザに通知される。

なお、本発明は前記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、前記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。また、上記の各構成、機能、処理部、処理手段などは、それらの一部または全部を、例えば集積回路で設計するなどによりハードウェアで実現してもよい。また、前記の各構成、機能などは、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。

各機能を実現するプログラム、テーブル、ファイルなどの情報は、メモリや、ハードディスク、ＳＳＤ（Solid State Drive）などの記録装置、または、ＩＣ（Integrated Circuit）カード、ＳＤカード、ＤＶＤなどの記録媒体に置くことができる。また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際にはほとんど全ての構成が相互に接続されていると考えてもよい。

１０１モバイルマネジメントサーバ
１０２ネットワーク
１０６ユーザ端末郡
１０７各銀行ＡＴＭ
１０３銀行ユーザ端末
１０４、１０５、モバイルユーザ端末
３１０取引ログファイルデータ
３１１ＡＴＭ−ＩＤマスタ
３１２モバイルＩＤマスタ
３１３口座ＩＤマスタ
３１９ＡＴＭ取引管理表
３０００ログ分析部
４１００管理表示部(ＢＲ管理マネージャ)
管理表示部(取引履歴)。

Claims

ユーザ端末と、前記ユーザ端末を管理する端末管理サーバと、料金の支払を管理する支払管理サーバと、前記料金を支払うための自動取引装置とがネットワークを介して接続されたモバイルマネジメントシステムであって、
前記支払管理サーバは、
あらかじめ定められた前記ユーザ端末を利用するユーザが支払うべき料金を示す支払情報を端末管理サーバに送信し、更新支払情報を端末管理サーバに送信する支払管理サーバ通信部と、
前記端末管理サーバから受信した前記支払うべき料金に対する残金と現実に支払われた金額と前記支払情報とに基づいて、前記残金について新たな支払期限を設定した前記更新支払情報を生成する支払管理サーバ制御部と、を備え、
前記端末管理サーバは、
前記支払管理サーバから受信した前記支払情報を前記ユーザ端末に送信し、前記自動取引装置から前記現実に支払われた金額を受信し、残金と前記現実に支払われた金額とを前記支払管理サーバに送信し、前記支払管理サーバから受信した前記更新支払情報をユーザ端末に送信する端末管理サーバ通信部と、
受信した前記現実に支払われた金額と前記支払情報とに基づいて未払いとなっている前記残金を計算する端末管理サーバ制御部と、を備え、
前記ユーザ端末は、
前記支払情報または前記更新支払情報を前記端末管理サーバから受信するユーザ端末通信部と、
前記端末管理サーバから受信した前記支払情報または前記更新支払情報からコード情報を生成するユーザ端末制御部と、
前記自動取引装置は、
前記コード情報を読み取る読取部と、
前記コード情報に基づいて取引を実行する取引部と、
前記取引の結果として前記現実に支払われた金額を前記端末管理サーバに送信する取引装置通信部と、
を備えることを特徴とするモバイルマネジメントシステム。
前記端末管理サーバの前記支払管理サーバ制御部は、計算した前記残金と前記支払情報に含まれる前記支払うべき料金との差額の大きさに応じて、前記新たな支払期限を設定する、
ことを特徴とする請求項１に記載のモバイルマネジメントシステム。
前記支払管理サーバの前記支払管理サーバ制御部は、計算された前記残金がなくなるまでくりかえし前記更新支払情報を生成し、前記端末管理サーバの前記端末管理サーバ通信部は、前記残金を含む前記更新支払情報をくりかえし前記ユーザ端末に通知する、
ことを特徴とする請求項１に記載のモバイルマネジメントシステム。
ユーザ端末と、前記ユーザ端末を管理する端末管理サーバと、料金の支払を管理する支払管理サーバと、前記料金を支払うための自動取引装置とがネットワークを介して接続されたモバイルマネジメントシステムで行われるモバイルマネジメント方法であって、
前記支払管理サーバが、あらかじめ定められた前記ユーザ端末を利用するユーザが支払うべき料金を示す支払情報を端末管理サーバに送信し、
前記端末管理サーバが、前記支払管理サーバから受信した前記支払情報を前記ユーザ端末に送信し、
前記ユーザ端末が、前記端末管理サーバから受信した前記支払情報または前記端末管理サーバから受信した前記支払うべき料金に対する残金について新たな支払期限を設定した更新支払情報からコード情報を生成し、
前記自動取引装置が、前記コード情報を読み取り、前記コード情報に基づいて取引を実行し、前記取引の結果として現実に支払われた金額を前記端末管理サーバに送信し、
前記端末管理サーバが、前記自動取引装置から前記現実に支払われた金額を受信し、受信した前記現実に支払われた金額と前記支払情報とに基づいて未払いとなっている残金を計算し、前記残金と前記現実に支払われた金額とを前記支払管理サーバに送信し、
前記支払管理サーバが、前記端末管理サーバから受信した前記支払うべき料金に対する残金と現実に支払われた金額と前記支払情報とに基づいて、前記残金について新たな支払期限を設定した前記更新支払情報を生成し、前記更新支払情報を前記端末管理サーバに送信し、
前記端末管理サーバが、前記支払管理サーバから受信した前記更新支払情報をユーザ端末に送信する、
ことを特徴とするモバイルマネジメント方法。
前記端末管理サーバが、計算した前記残金と前記支払情報に含まれる前記支払うべき料金との差額の大きさに応じて、前記新たな支払期限を設定する、
ことを特徴とする請求項４に記載のモバイルマネジメント方法。
前記支払管理サーバが、計算された前記残金がなくなるまでくりかえし前記更新支払情報を生成し、前記端末管理サーバの端末管理サーバ通信部が、前記残金を含む前記更新支払情報をくりかえし前記ユーザ端末に通知する、
ことを特徴とする請求項４に記載のモバイルマネジメント方法。