JP7243056B2 - 購入監視プログラム、購入監視方法及び情報管理装置 - Google Patents

Description

本発明は、購入監視プログラム、購入監視方法及び情報管理装置に関する。

会社においては、社員が利用する通勤区間の定期代や有効期限を把握しているため、社員が定期券を購入する前に、会社から社員の銀行口座に対して定期代を振り込んでいる。

また、出張、交通費用等の小口経費の処理を自動化するための技術が知られている（例えば、特許文献１等参照）。

特開２０００－３４８０９９号公報

しかしながら、振り込まれた定期代を利用せずに、自転車や徒歩で通勤することで、定期代を不正受給する社員がいることもある。このため、各社員が定期代を正当に利用しているかを確認する必要があるが、これまでは購入済みの定期券や領収書等を人手で確認しており、手間がかかっていた。

１つの側面では、本発明は、手間を掛けずに交通費の利用を監視することが可能な購入監視プログラム、購入監視方法及び情報管理装置を提供することを目的とする。

一つの態様では、購入監視プログラムは、金融機関の各口座に対する入金及び出金を管理するコンピュータに、支払元から支払先の口座へ入金があった場合に、前記入金の種別情報と、前記支払先の識別情報と、入金された金額の情報と、を対応付けて記憶部に記憶し、ユーザの識別情報と該ユーザによる交通機関での購入履歴とを対応付けて記憶する記憶装置に対して、前記記憶部に記憶された前記入金の種別情報が交通費である第１の支払先の識別情報と、前記第１の支払先の識別情報に対応する入金された金額の情報とを送信して、前記第１の支払先の識別情報に対応する入金された金額に相当する購入履歴があるかを問い合わせ、前記記憶装置から受信した前記問い合わせに対する回答結果を出力する、処理を実行させるための購入監視プログラムである。

手間を掛けずに交通費の利用を監視することができる。

一実施形態に係る購入監視システムの構成を概略的に示す図である。 図２（ａ）は、金融情報処理サーバ及び交通機関サーバのハードウェア構成を示す図であり、図２（ｂ）は、会社用端末及び社員用端末のハードウェア構成を示す図である。 金融情報処理サーバ及び交通機関サーバの機能ブロック図である。 金融情報処理サーバの処理の一例を示すフローチャートである。 交通機関サーバの処理の一例を示すフローチャートである。 図６（ａ）は、取引ＤＢのデータ構造の一例を示す図であり、図６（ｂ）は、購入履歴ＤＢのデータ構造の一例を示す図である。 図７（ａ）、図７（ｂ）は、入金画面の一例を示す図である。 図８（ａ）、図８（ｂ）は、定期券購入画面の一例を示す図である。 図９（ａ）、図９（ｂ）は、「定期券購入情報」の画面を示す図であり、図９（ｃ）は、「定期券について」の画面を示す図であり、図９（ｄ）は、「定期券について」の画面の別例を示す図である。

以下、購入監視システムの一実施形態について、図１～図９に基づいて詳細に説明する。図１には、一実施形態に係る購入監視システム１００の構成が概略的に示されている。図１の購入監視システム１００は、会社から社員の銀行口座に対して定期代の入金（支払い）があった場合に、適正に定期券が購入されたかを監視し、監視結果に基づいて会社や社員に対して通知を行うシステムである。

購入監視システム１００は、図１に示すように、金融情報処理サーバ１０、交通機関サーバ２０、券売機２２、窓口端末２４、会社用端末６０、社員用端末７０、を備える。購入監視装置としての金融情報処理サーバ１０、記憶装置としての交通機関サーバ２０、会社用端末６０、社員用端末７０は、インターネットやＶＰＮ（Virtual Private Network）などのネットワーク８０に接続されている。また、交通機関サーバ２０、券売機２２、窓口端末２４は、ＬＡＮ（Local Area Network）などのネットワーク８１に接続されている。

金融情報処理サーバ１０は、例えば、銀行などの金融機関が利用するサーバであり、銀行口座に対する入金や出金を管理する。また、金融情報処理サーバ１０は、交通機関サーバ２０に対して、銀行口座に入金された定期代が適正に利用されたかを問い合わせ、問い合わせ結果に基づいて社員用端末７０や会社用端末６０に対して通知を行う。

図２（ａ）には、金融情報処理サーバ１０のハードウェア構成が示されている。図２（ａ）に示すように、金融情報処理サーバ１０は、ＣＰＵ（Central Processing Unit）９０、ＲＯＭ（Read Only Memory）９２、ＲＡＭ（Random Access Memory）９４、記憶部（ここではＨＤＤ（Hard Disk Drive））９６、ネットワークインタフェース９７、及び可搬型記憶媒体用ドライブ９９等を備えている。これら金融情報処理サーバ１０の構成各部は、バス９８に接続されている。サーバ１０では、ＲＯＭ９２あるいはＨＤＤ９６に格納されているプログラム（購入監視プログラムを含む）、或いは可搬型記憶媒体用ドライブ９９が可搬型記憶媒体９１から読み取ったプログラム（購入監視プログラムを含む）をＣＰＵ９０が実行することにより、図３の各部の機能が実現されている。なお、図３の各部の機能は、例えば、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）等の集積回路により実現されてもよい。なお、図３の各部の詳細については後述する。

交通機関サーバ２０は、鉄道会社などの交通機関ごとに用意されたサーバである。交通機関サーバ２０は、定期券の購入情報を券売機２２や窓口端末２４から取得して、管理する。また、交通機関サーバ２０は、金融情報処理サーバ１０からの問い合わせに基づいて、適正な定期券購入が行われたかを確認し、確認結果を金融情報処理サーバ１０に送信する。交通機関サーバ２０は、金融情報処理サーバ１０と同様のハードウェア構成（図２（ａ）参照）を有している。交通機関サーバ２０では、ＣＰＵ９０がＲＯＭ９２あるいはＨＤＤ９６に格納されているプログラム、或いは可搬型記憶媒体用ドライブ９９が可搬型記憶媒体９１から読み取ったプログラムを実行することにより、図３の各部の機能が実現されている。なお、図３の各部の機能は、例えば、ＡＳＩＣやＦＰＧＡ等の集積回路により実現されてもよい。なお、図３の各部の詳細については後述する。

券売機２２は、交通機関の駅等に設置され、乗車券や指定席券の他、定期券を購入するために購入者が操作する装置である。券売機２２における定期券の購入履歴情報は、交通機関サーバ２０に送信される。

窓口端末２４は、交通機関の窓口に設置され、乗客が乗車券や指定席券、定期券を購入する際に、窓口業務員が操作する装置である。窓口端末２４における定期券の購入履歴情報についても、交通機関サーバ２０に送信される。

会社用端末６０は、会社の人事部等が利用するＰＣ（Personal Computer）などの端末である。会社用端末６０は、例えば社員の銀行口座に対する定期代の入金に利用したり、金融情報処理サーバ１０から受けた通知の確認に利用したりする。会社用端末６０は、図２（ｂ）に示すようなハードウェア構成を有する。会社用端末６０は、ＣＰＵ１９０、ＲＯＭ１９２、ＲＡＭ１９４、記憶部（ここではＨＤＤ）１９６、ネットワークインタフェース１９７、表示部１９３、入力部１９５、及び可搬型記憶媒体１９１に記憶されている情報を読み取り可能な可搬型記憶媒体用ドライブ１９９等を備えている。表示部１９３は、液晶ディスプレイ等を含み、入力部１９５は、キーボードやマウス、タッチパネル等を含むこれら会社用端末６０の構成各部は、バス１９８に接続されている。

社員用端末７０は、会社の社員が利用するＰＣやスマートフォンなどの端末である。社員用端末７０は、一例として、会社用端末６０と同様のハードウェア構成（図２（ｂ）参照）を有する。

次に、金融情報処理サーバ１０と交通機関サーバ２０の機能について、図３に基づいて説明する。

（金融情報処理サーバ１０について）
金融情報処理サーバ１０は、ＣＰＵ９０がプログラムを実行することにより、図３に示す検知部としての入金情報検知部３０、問い合わせ部３２、出力部としての通知部３４、として機能する。

入金情報検知部３０は、会社用端末６０において入金画面（図７（ａ）参照）から社員の銀行口座への入金処理がされた場合に、入金画面に入力された情報を取引ＤＢ５２に格納する。ここで、取引ＤＢ５２は、銀行における入金や出金に関する情報を格納するデータベースである。図６（ａ）には、取引ＤＢ５２のうち、入金に関する情報のみが示されている。なお、取引ＤＢ５２の詳細については、後述する。

問い合わせ部３２は、所定の問い合わせタイミング（例えば１日１回）が到来した場合に、交通機関サーバ２０に対して、定期代が入金されている社員が適正に定期券を購入したかを問い合わせる。

通知部３４は、問い合わせ部３２が交通機関サーバ２０に対して問い合わせを行った後、交通機関サーバ２０から送信されてくる回答（問い合わせ結果）を受信する。そして、通知部３４は、回答に基づいて、会社用端末６０や社員用端末７０に対して通知を行う。通知部３４は、社員が期限までに定期券を購入していなければ、当該社員が利用する社員用端末７０に対して購入を促す通知を行う。また、通知部３４は、社員が適正に定期券を購入しなかった場合や適正に定期券を購入した場合には、会社用端末６０に対してその旨を通知する。なお、通知部３４は、定期代の入金元の会社用端末６０のアドレスや、入金先の社員の社員用端末７０のアドレスの情報をリスト化して保持しているものとする。

（交通機関サーバ２０について）
交通機関サーバ２０は、ＣＰＵ９０がプログラムを実行することにより、図３に示す購入情報取得部４０、確認部４２、確認結果回答部４４としての機能が実現されている。

購入情報取得部４０は、券売機２２や窓口端末２４から定期券の購入情報が送信されてきた場合に、購入情報を購入履歴ＤＢ６２に格納する。図６（ｂ）には、購入履歴ＤＢ６２のデータ構造の一例が示されている。なお、図６（ｂ）の購入履歴ＤＢ６２は、鉄道会社ＩＤ＝「０１」の交通機関サーバ２０が有する購入履歴ＤＢ６２であるものとする。なお、購入履歴ＤＢ６２の詳細については、後述する。

確認部４２は、金融情報処理サーバ１０の問い合わせ部３２からの問い合わせに応じて、購入履歴ＤＢ６２を検索し、社員によって定期券が購入されたか否か、定期券購入が適正であったか否かを確認する。

確認結果回答部４４は、確認部４２による確認結果を金融情報処理サーバ１０の通知部３４に対して送信する。

（金融情報処理サーバ１０及び交通機関サーバ２０の処理について）
以下、金融情報処理サーバ１０及び交通機関サーバ２０の処理について、図４、図５のフローチャートに沿って、その他図面を参照しつつ詳細に説明する。なお、図４の処理は、金融情報処理サーバ１０の処理であり、図５の処理は、交通機関サーバ２０において図４の処理と同時並行的に行われる処理である。

図４の処理では、入金情報検知部３０は、ステップＳ１０において、入金情報が入力されたか否かを判断する。このステップＳ１０の判断が否定された場合には、ステップＳ１４に移行し、問い合わせ部３２は、監視タイミングか否かを判断する。なお、監視タイミングは、１日１回到来する所定時刻とすることができる。このステップＳ１４の判断が否定された場合には、ステップＳ１０に戻る。すなわち、入金情報が入力されるか、監視タイミングになるまでの間は、ステップＳ１０、Ｓ１４の判断が繰り返し実行され、待機状態となる。

ステップＳ１０の判断が肯定された場合、入金情報検知部３０は、ステップＳ１２に移行する。ここで、ステップＳ１０の判断が肯定される場合とは、会社用端末６０において、図７（ａ）に示す入金画面に対する入力が行われ、「入金処理実行」ボタンが押された場合を意味する。図７（ａ）の入金画面は、会社の人事部員等が社員の口座に対して定期代を入金する場合に入力する画面であり、「社員（ユーザＩＤ）」、「通勤区間」、「期間」、「定期券購入チェック実行」の各項目の入力欄を有する。項目「社員（ユーザＩＤ）」の入力欄には、例えば、社員のユーザＩＤとして、マイナンバーを入力することができる。項目「通勤区間」入力欄には、社員が会社に対して申請している通勤区間（乗車駅と降車駅）の情報を入力することができる。なお、項目「通勤区間」の入力欄の右側の矢印ボタンを押した場合、当該通勤区間の定期券を購入することが可能な交通機関の情報（鉄道会社ＩＤ）が自動的に表示されるようになっている。また、項目「期間」の入力欄には、購入すべき定期券の期間（例えば前回購入した定期券の有効期限の次の日から６か月間など）の情報を入力することができる。なお、項目「期間」の入力欄の右側の矢印ボタンを押した場合、当該機関の定期券の金額が自動的に表示されるようになっている。更に、項目「定期券購入チェック実行」の入力欄には、社員が適正に定期券を購入したか否かをチェックする場合に「ＯＮ」を入力し、チェックしない場合に「ＯＦＦ」を入力する。本実施形態では、人事部員等が会社用端末６０から図７（ｂ）に示すような入力を行った後、「入金処理実行」ボタンを押したものとする。なお、「入金処理実行」ボタンを押すことで、入金画面に表示されている情報が金融情報処理サーバ１０に送信される。

ステップＳ１２に移行すると、入金情報検知部３０は、取引ＤＢ５２に対して入金情報（入金画面に表示されている情報）を格納する。ここで、取引ＤＢ５２は、図６（ａ）に示すように、「取引ＩＤ」、「取引名」、「入金元」、「入金先」、「金額」、「取引日」、「備考１」、「備考２」、「実行フラグ」のフィールドを有する。「取引ＩＤ」のフィールドには、取引の識別番号（例えば、「ＴＲ－００１」）が格納される。「取引名」のフィールドには、取引の名称（例えば、「定期券更新」）が格納される。「入金元」のフィールドには、入金元の会社の識別情報（例えば法人番号）が格納され、「入金先」のフィールドには、入金先の社員の識別情報（例えばマイナンバー）が格納される。また、「金額」のフィールドには、入金額が格納され、「取引日」のフィールドには、入金のあった日の日付が格納される。また、「備考１」のフィールドには、通勤区間と鉄道会社ＩＤが格納され、「備考２」のフィールドには、更新期限として入金画面の「期間」の前日の日付が格納される。また、「実行フラグ」のフィールドには、入金画面に入力された「ＯＮ」又は「ＯＦＦ」が格納される。

ステップＳ１２の後は、監視タイミングが到来するまでの間（ステップＳ１４の判断が肯定されるまでの間）、入金情報が入力されるたびに、取引ＤＢ５２に入金情報が格納される（Ｓ１２）ようになっている。そして、監視タイミングが到来すると、ステップＳ１４の判断が肯定され、問い合わせ部３２は、ステップＳ１６の処理を実行する。

ステップＳ１６では、問い合わせ部３２は、実行フラグ＝ＯＮの入金履歴を１つ特定する。ここでは、例えば、図６（ａ）の取引ＤＢ５２の取引ＩＤ＝「ＴＲ－００１」の行の入金履歴が特定されたものとする。

次いで、ステップＳ１８では、問い合わせ部３２が、特定した入金履歴から入金先の社員が定期券を購入する交通機関を特定する。取引ＩＤ＝「ＴＲ－００１」の例では、問い合わせ部３２は、鉄道会社ＩＤ＝「０１」の交通機関を特定する。

次いで、ステップＳ２０では、問い合わせ部３２が、特定した交通機関の交通機関サーバ２０に対して、入金先の識別情報（マイナンバー）、金額、区間を送信して入金先の社員により適正な定期券購入が行われたか否かの問い合わせを実行する。その後は、ステップＳ２２において、通知部３４が、交通機関サーバ２０から確認結果を受信するまで待機する。

（図５の処理について）
ここで、図５に基づいて、交通機関サーバ２０の処理について説明する。

図５の処理においては、購入情報取得部４０が定期券購入情報が入力されたと判断するまで（ステップＳ５０の判断が肯定されるまで）、又は確認部４２が問い合わせがあったと判断するまで（ステップＳ５４が肯定されるまで）、待機している。

したがって、社員が例えば券売機２２において定期券を購入した場合には、ステップＳ５０の判断が肯定され、ステップＳ５２に移行する。ここで、券売機２２においては、図８（ａ）に示すような定期券購入画面が表示されるようになっている。例えば定期券を更新で購入する場合、購入者は、券売機２２に使用中の定期券を投入し、定期券購入画面において、図８（ｂ）に示すように、購入者のユーザＩＤ（マイナンバー）や、定期券の種別（通勤又は通学）、期間（１か月、３か月、６か月）、新規・継続の別を入力する。これにより、定期券購入画面には、使用中の定期券の情報と入力情報とに基づいて、区間（ＪＲ蒲田～ＪＲ新宿）や、使用期限（２０１８／９／１６まで）や金額（４３４３０円）が自動的に表示される。なお、購入者は、券売機２２に自治体が発行したマイナンバーカードを投入することとしてもよい。この場合、券売機２２では、マイナンバーカードからマイナンバーを取得することができる。これにより、購入者によるマイナンバーの手入力を省略することができる。なお、新規で定期券を購入する場合には、区間や使用期限についても手入力する必要がある。

図８（ｂ）に示すように定期券購入画面に情報が入力された状態で、「定期券購入」ボタンが押されると、券売機２２は定期代の支払いを条件に定期券を発行する。この場合、券売機２２は、定期券購入画面上に表示されている情報（定期券購入情報）を交通機関サーバ２０に送信するようになっている。なお、定期券を駅の窓口で購入した場合にも、窓口端末２４からは、定期券購入画面上に表示されている情報（定期券購入情報）が交通機関サーバ２０に送信される。

購入情報取得部４０は、ステップＳ５２に移行すると、購入履歴ＤＢ６２に定期券購入情報を格納する。ここで、購入履歴ＤＢ６２は、図６（ｂ）に示すようなデータ構造を有する。具体的には、購入履歴ＤＢ６２は、「日付」、「購入者情報」、「金額」、「区間」のフィールドを有する。購入情報取得部４０は、図８（ｂ）に示す定期券購入画面の情報（定期券購入情報）を２０１８年３月１２日に取得した場合には、図６（ｂ）において矢印で示す行の情報を購入履歴ＤＢ６２に格納する。その後は、定期券の購入がある度に（ステップＳ５０が肯定されるたびに）、ステップＳ５２において定期券購入情報が購入履歴ＤＢ６２に格納されるようになっている。

一方、前述したように、図４のステップＳ２０において問い合わせ部３２による問い合わせが行われた場合には、ステップＳ５４の判断が肯定されるため、確認部４２は、ステップＳ５６に移行する。

ステップＳ５６に移行すると、確認部４２は、問い合わせ部３２から受信した入金先の識別情報（社員のマイナンバー）に基づいて、購入履歴ＤＢ６２を検索する。すなわち、定期代が支払われた社員による定期券の購入があったか否かを判断する。なお、この場合には、確認部４２は、前回の問い合わせ以降に新たに購入履歴ＤＢ６２に格納された情報のみを検索するようにすればよい。すなわち、監視タイミングが１日１回であれば、確認部４２は、前日の監視タイミング以降に購入履歴ＤＢ６２に格納された情報（１日分の情報）のみを検索すればよい。

次いで、ステップＳ５８では、確認部４２が、入金先の識別情報に対応する購入履歴があったか否かを判断する。このステップＳ５８の判断が否定された場合には、ステップＳ６２に移行するが、肯定された場合には、ステップＳ６０に移行する。

ステップＳ６０に移行すると、確認部４２は、問い合わせの際に受信した金額、区間に基づいて、定期券購入が適正か否かを確認する。この場合、確認部４２は、例えば、定期券購入の金額が支払われた定期代よりも少なければ適正でないと判断する。また、確認部４２は、定期券購入の金額が支払われた定期代と同額又は支払われた定期代よりも多ければ、購入された定期券の区間を参照し、受信した区間（取引ＤＢ５２の備考１の区間）を含んでいれば適正と判断する。その後は、ステップＳ６２に移行する。なお、ステップＳ６０において、確認部４２は、金額と区間のいずれか一方に基づいて、適正な定期券購入が行われたかを確認することとしてもよい。例えば、確認部４２は、定期券購入の金額が支払われた定期代よりも少なければ適正でなく、同一又は多ければ適正であると判断してもよい。また、例えば、確認部４２は、購入した定期券の利用区間に受信した区間すべてが含まれていれば適正であると判断してもよい。

ステップＳ６２に移行した場合、確認結果回答部４４は、確認部４２による確認結果を金融情報処理サーバ１０（通知部３４）に送信する。この場合、確認結果回答部４４は、「定期券が未購入である」、「定期券が適正に購入された」、「定期券が適正に購入されなかった」のいずれかを通知部３４に対して送信する。その後は、ステップＳ５０に戻る。

上記のように、交通機関サーバ２０においてステップＳ６２の処理が実行されると、図４の処理においては、ステップＳ２２の判断が肯定されるため、通知部３４は、ステップＳ２４に移行する。

ステップＳ２４に移行すると、通知部３４は、定期券を購入済みであるか否かを判断する。このステップＳ２４の判断が肯定された場合には、ステップＳ２６に移行し、通知部３４は、購入が適正に行われたか否かを判断する。このステップＳ２６の判断が肯定された場合（購入が適正であった場合）には、ステップＳ２８に移行し、通知部３４は、適正に購入された旨を入金元の会社用端末６０に通知する。この場合、通知部３４は、例えば、図９（ａ）に示すような「定期券購入情報」の画面を生成し、入金元の会社用端末６０に送信する。一方、ステップＳ２６の判断が否定された場合（購入が適正でなかった場合）には、ステップＳ３０に移行し、通知部３４は、適正に購入されなかった旨を会社用端末６０に通知する。この場合、通知部３４は、例えば、図９（ｂ）に示すような「定期券購入情報」の画面を生成し、入金元の会社用端末６０に送信する。入金元の会社用端末６０では、図９（ａ）や図９（ｂ）の画面が表示されることで、人事部員等は、定期券の現物や領収証を確認しなくても、社員が適正に定期券を購入したか否かを確認することができる。

上記のようにステップＳ２８又はステップＳ３０の処理が実行されると、通知部３４はステップＳ３２に移行し、特定している入金履歴の実行フラグを「ＯＮ」から「ＯＦＦ」に変更する。その後は、ステップＳ３４に移行する。

ところで、ステップＳ２４の判断が否定された場合、すなわち、確認結果として「定期券が未購入である」を受信した場合には、通知部３４は、ステップＳ３６に移行する。

ステップＳ３６に移行すると、通知部３４は、特定している入金履歴の備考２に記載されている更新期限を過ぎているか否かを判断する。このステップＳ３６の判断が否定された場合、すなわち更新期限を過ぎていない場合には、通知部３４は通知を行わずに、ステップＳ３４に移行する。一方、ステップＳ３６の判断が肯定された場合には、ステップＳ３８に移行し、通知部３４は、購入を促す通知を入金先の社員用端末７０に対して送信する。この場合、通知部３４は、例えば、図９（ｃ）に示すような「定期券について」の画面を生成し、入金先の社員用端末７０に送信する。これにより、社員に対して定期券を購入すべきことを報知することができる。その後は、ステップＳ３４に移行する。

上述した処理を経て、ステップＳ３４に移行すると、問い合わせ部３２は、実行フラグが「ＯＮ」の入金履歴を全て特定し終えたか否かを判断する。このステップＳ３４の判断が否定された場合には、ステップ１６に戻り、実行フラグが「ＯＮ」の次の入金履歴に対する処理（Ｓ１６以降の処理）を繰り返し実行する。一方、ステップＳ３４の判断が肯定された場合には、ステップＳ１０に戻るため、上述した図４の処理が繰り返し実行されるようになっている。

以上、詳細に説明したように、本実施形態によると、入金情報検知部３０は、定期代の支払いが支払元（会社）から支払先（社員）の口座へあったことを検知した場合に、取引ＤＢ５２に入金情報を格納する。そして、問い合わせ部３２が、購入履歴ＤＢ６２を有する交通機関サーバ２０に対して、社員の識別情報（マイナンバー）を用いて、社員が定期券を適正に購入したか（金額や区間が正当かどうか）を問い合わせる。すなわち、問い合わせ部３２は、購入履歴ＤＢ６２に、社員のマイナンバーに対応する交通費に相当する購入履歴があるかを問い合わせる。また、通知部３４は、交通機関サーバ２０から受信した回答を会社用端末６０に対して出力する。これにより、人事部等が定期券の現物や領収書を確認しなくても、社員が定期券を適正に購入したか否かの情報を会社用端末６０に対して出力することができる。これにより、人事部等の確認作業の手間を省くことができる。

また、本実施形態では、異なる交通機関での購入履歴は、異なる交通機関サーバ２０の購入履歴ＤＢ６２に格納され、問い合わせ部３２は、入金画面に表示された鉄道会社ＩＤに対応する交通機関サーバ２０に対して問い合わせを行う。これにより、各交通機関での購入履歴がまとめて１つのサーバで管理される場合に比べ、問い合わせ時の処理の低減及び問い合わせに要する時間の削減を図ることが可能である。

また、本実施形態では、会社が入金した金額以上の定期券を購入した場合や、社員の利用区間を含む区間の定期券が購入された場合に、適正に購入されたとするので、社員が通勤区間を超えた区間の定期券を購入した場合（自腹で定期券の区間を拡張した場合）でも適正な購入として扱うことができる。

また、本実施形態では、通知部３４は、更新期限までに定期券を購入していない場合に、社員用端末７０に対して購入を促す通知を送信する。これにより、定期券の購入し忘れを抑制することができる。

なお、上記実施形態では、更新期限を長期間過ぎた場合に、定期代が不正取得された可能性がある旨を会社用端末６０に対して通知することとしてもよい。具体的には、図４のステップＳ３８の後に、更新期限から所定期間経過したか否かを判断し、判断が肯定された場合に、会社用端末６０に対して図９（ｄ）に示すような画面を送信することとしてもよい。

なお、上記実施形態では、更新期限を過ぎた場合（Ｓ３６：肯定）に、社員用端末７０に対して通知する場合について説明したが、これに限られるものではない。例えば、更新期限の数日前から、社員用端末７０に対して購入を促す通知を送信することとしてもよい。

なお、上記実施形態では、入金画面において、項目「定期券購入チェック実行」の入力欄にＯＮ又はＯＦＦを入力可能にすることで、人事部員等が図６（ａ）の実行フラグをＯＮ又はＯＦＦにすることができる場合について説明した。しかしながら、これに限られるものではなく、入金画面から入金処理を行った場合には、実行フラグが必ずＯＮになるようにしてもよい。すなわち、全社員に対して、定期券購入チェックを必ず実行するようにしてもよい。

なお、上記実施形態では、各社員の通勤区間の情報をデータベースで管理してもよい。この場合、会社用端末６０では、入金画面に社員の識別情報（マイナンバー）が入力された段階で、通勤区間の情報をデータベースから自動的に取得し、入金画面に自動的に入力するようにしてもよい。

なお、上記実施形態では、各鉄道会社での定期券の購入履歴を、鉄道会社ごとに用意された購入履歴ＤＢ６２で管理する場合について説明したが、これに限られるものではない。すなわち、各鉄道会社での定期券の購入履歴を、１つの購入履歴ＤＢで一括管理することとしてもよい。

なお、上記実施形態では、購入監視システム１００が、定期券の購入に関する監視を行う場合について説明したが、これに限られるものではない。購入監視システム１００は、例えば、出張前に会社から社員の口座に対して出張費（交通費）を入金した場合に、当該出張費を用いて乗車券等が適正に購入されたかを監視するシステムであってもよい。

なお、上記の処理機能は、コンピュータによって実現することができる。その場合、処理装置が有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記憶媒体（ただし、搬送波は除く）に記録しておくことができる。

プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ（Digital Versatile Disc）、ＣＤ－ＲＯＭ（Compact Disc Read Only Memory）などの可搬型記憶媒体の形態で販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。

プログラムを実行するコンピュータは、例えば、可搬型記憶媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記憶媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムに従った処理を実行することもできる。

上述した実施形態は本発明の好適な実施の例である。但し、これに限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変形実施可能である。

なお、以上の実施形態の説明に関して、更に以下の付記を開示する。
（付記１） 交通費の支払いが支払元から支払先の口座へあったことを検知し、
ユーザの識別情報と該ユーザによる交通機関での購入履歴とを対応付けて記憶する記憶装置に対して、前記支払先の口座に対応する第１ユーザの識別情報を用いて、前記第１ユーザの識別情報に対応する前記交通費に相当する購入履歴があるかを問い合わせ、
前記記憶装置から受信した前記問い合わせに対する回答結果を出力する、
処理をコンピュータに実行させるための購入監視プログラム。
（付記２） 異なる交通機関での購入履歴は、異なる記憶装置に記憶され、
前記問い合わせる処理では、前記交通費に対応する交通機関を特定し、特定した交通機関に対応する記憶装置に対して問い合わせを行う、
ことを特徴とする付記１に記載の購入監視プログラム。
（付記３） 前記交通費に対応する交通機関は、前記支払元が前記交通費の支払いの際に入力した情報から特定する、ことを特徴とする付記２に記載の購入監視プログラム。
（付記４） 前記問い合わせる処理では、前記交通費以上の金額の購入履歴があるかを問い合わせる、ことを特徴とする付記１～３のいずれかに記載の購入監視プログラム。
（付記５） 前記出力する処理では、予め定めた期限までに前記交通費に対応する購入がない場合に、前記第１ユーザに対応する端末に対して購入を促す情報を出力する、ことを特徴とする付記１～４のいずれかに記載の購入監視プログラム。
（付記６） 交通費の支払いが支払元から支払先の口座へあったことを検知し、
ユーザの識別情報と該ユーザによる交通機関での購入履歴とを対応付けて記憶する記憶装置に対して、前記支払先の口座に対応する第１ユーザの識別情報を用いて、前記第１ユーザの識別情報に対応する前記交通費に相当する購入履歴があるかを問い合わせ、
前記記憶装置から受信した前記問い合わせに対する回答結果を出力する、
処理をコンピュータが実行することを特徴とする購入監視方法。
（付記７） 交通費の支払いが支払元から支払先の口座へあったことを検知する検知部と、
ユーザの識別情報と該ユーザによる交通機関での購入履歴とを対応付けて記憶する記憶装置に対して、前記支払先の口座に対応する第１ユーザの識別情報を用いて、前記第１ユーザの識別情報に対応する前記交通費に相当する購入履歴があるかを問い合わせる問い合わせ部と、
前記記憶装置から受信した前記問い合わせに対する回答結果を出力する出力部と、
を備える購入監視装置。
（付記８） 異なる交通機関での購入履歴は、異なる記憶装置に記憶され、
前記問い合わせ部は、前記交通費に対応する交通機関を特定し、特定した交通機関に対応する記憶装置に対して問い合わせを行う、
ことを特徴とする付記７に記載の購入監視装置。
（付記９） 前記交通費に対応する交通機関は、前記支払元が前記交通費の支払いの際に入力した情報から特定する、ことを特徴とする付記８に記載の購入監視装置。
（付記１０） 前記問い合わせ部は、前記交通費以上の金額の購入履歴があるかを問い合わせる、ことを特徴とする付記７～９のいずれかに記載の購入監視装置。
（付記１１） 前記出力部は、予め定めた期限までに前記交通費に対応する購入がない場合に、前記第１ユーザに対応する端末に対して購入を促す情報を出力する、ことを特徴とする付記７～１０のいずれかに記載の購入監視装置。

１０ 金融情報処理サーバ（購入監視装置）
２０ 記憶装置（交通機関サーバ）
３０ 入金情報検知部（検知部）
３２ 問い合わせ部
３４ 通知部（出力部）

Claims (8)

1. 金融機関の各口座に対する入金及び出金を管理するコンピュータに、
   支払元から支払先の口座へ入金があった場合に、前記入金の種別情報と、前記支払先の識別情報と、入金された金額の情報と、を対応付けて記憶部に記憶し、
   ユーザの識別情報と該ユーザによる交通機関での購入履歴とを対応付けて記憶する記憶装置に対して、前記記憶部に記憶された前記入金の種別情報が交通費である第１の支払先の識別情報と、前記第１の支払先の識別情報に対応する入金された金額の情報とを送信して、前記第１の支払先の識別情報に対応する入金された金額に相当する購入履歴があるかを問い合わせ、
   前記記憶装置から受信した前記問い合わせに対する回答結果を出力する、
   処理を実行させるための購入監視プログラム。
2. 異なる交通機関での購入履歴は、異なる記憶装置に記憶され、
   前記記憶部に記憶する処理において、前記入金の種別が交通費である場合には、前記支払先の識別情報と対応付けて、前記交通費に対応する交通機関の情報を前記記憶部に記憶し、
   前記問い合わせる処理では、前記記憶部に記憶された前記第１の支払先の識別情報に対応付けられている交通機関に対応する記憶装置に対して問い合わせを行う、
   ことを特徴とする請求項１に記載の購入監視プログラム。
3. 前記交通費に対応する交通機関の情報は、前記支払元が前記交通費の支払いの際に入力した情報である、ことを特徴とする請求項２に記載の購入監視プログラム。
4. 前記問い合わせる処理では、前記入金された金額以上の金額の購入履歴があるかを問い合わせる、ことを特徴とする請求項１～３のいずれか一項に記載の購入監視プログラム。
5. 前記出力する処理では、予め定めた期限までに前記入金された金額に対応する購入履歴がない場合に、前記第１の支払先に対応する端末に対して購入を促す情報を出力する、ことを特徴とする請求項１～４のいずれか一項に記載の購入監視プログラム。
6. 前記記憶部に記憶する処理において、前記入金の種別が交通費である場合には、前記支払先の識別情報と対応付けて、前記交通費に対応する区間の情報を前記記憶部に記憶し、
   前記問い合わせる処理では、前記記憶装置に対して、前記記憶部に記憶された前記入金の種別情報が交通費である第１の支払先の識別情報と、前記第１の支払先の識別情報に対応する入金された金額の情報及び区間の情報と、を送信して、前記第１の支払先の識別情報に対応する入金された金額と区間に相当する購入履歴があるかを問い合わせる、ことを特徴とする請求項１～５のいずれか一項に記載の購入監視プログラム。
7. 金融機関の各口座に対する入金及び出金を管理するコンピュータが、
   支払元から支払先の口座へ入金があった場合に、前記入金の種別情報と、前記支払先の識別情報と、入金された金額の情報と、を対応付けて記憶部に記憶し、
   ユーザの識別情報と該ユーザによる交通機関での購入履歴とを対応付けて記憶する記憶装置に対して、前記記憶部に記憶された前記入金の種別情報が交通費である第１の支払先の識別情報と、前記第１の支払先の識別情報に対応する入金された金額の情報とを送信して、前記第１の支払先の識別情報に対応する入金された金額に相当する購入履歴があるかを問い合わせ、
   前記記憶装置から受信した前記問い合わせに対する回答結果を出力する、
   処理を実行することを特徴とする購入監視方法。
8. 金融機関の各口座に対する入金及び出金を管理する情報管理装置であって、
   支払元から支払先の口座へ入金があった場合に、前記入金の種別情報と、前記支払先の識別情報と、入金された金額の情報と、を対応付けて記憶部に記憶する処理部と、
   ユーザの識別情報と該ユーザによる交通機関での購入履歴とを対応付けて記憶する記憶装置に対して、前記記憶部に記憶された前記入金の種別情報が交通費である第１の支払先の識別情報と、前記第１の支払先の識別情報に対応する入金された金額の情報とを送信して、前記第１の支払先の識別情報に対応する入金された金額に相当する購入履歴があるかを問い合わせる問い合わせ部と、
   前記記憶装置から受信した前記問い合わせに対する回答結果を出力する出力部と、
   を備える情報管理装置。

Images