JP7063963B2 - 支払支援システム、支払支援方法及び支払支援プログラム - Google Patents

Description

本発明は、的確な支払を支援するための支払支援システム、支払支援方法及び支払支援プログラムに関する。

商品購入等の取引において送金を行なう場合、詐欺や不正な送金を検知し、注意喚起するための技術が検討されている（例えば、特許文献１～３）。
特許文献１に記載された技術では、振込先情報を受け付け、振込先情報に含まれる振込先口座の取引履歴に基づき、振込先口座が振り込め詐欺に利用されている預金口座である可能性が高いかどうかを判断する。

特許文献２に記載された技術では、ホストコンピュータに、振り込め詐欺に用いられた口座情報とその被害内容からなる被害情報を記した被害情報ファイルを格納した詐欺情報データベースを接続する。

特許文献３に記載された技術では、顧客と、振込先の口座の情報を示す口座情報と、この口座における取引の履歴とを対応付けた取引情報に基づき、取引情報における振込先の口座情報が示す口座が疑わしい口座であるか否かを判定する。

特開２００７－２７２４１０号公報 特開２００９－１５７５９４号公報 特開２０１４－２０６７７１号公報

しかしながら、取引を行なう場合、見積り、納品、請求等といったプロセスを経て、支払が行なわれる。このようなプロセスで用いられる複数の取引帳票を管理して、支払を行なう場合には手間がかかる。

上記課題を解決する支払支援システムは、帳票を用いた取引に関する情報を記憶する取引情報記憶部と、利用者端末に接続される制御部とを備える。そして、前記制御部が、支払に用いる取引帳票の帳票画像を取得し、前記帳票画像の文字認識により、前記取引帳票の帳票種別及び取引内容を含む帳票記載情報を取得し、前記取引情報記憶部から、前記帳票記載情報に基づいて、取引帳票に関連する関連帳票を特定し、前記取引帳票の帳票記載情報と前記関連帳票の帳票記載情報との比較に基づいて、前記取引帳票を用いた支払の可否を判定し、前記取引帳票を用いた取引結果を前記取引情報記憶部に記録する。

本発明によれば、支払に用いる帳票を的確かつ効率的に管理しながら取引を支援することができる。

第１実施形態の支払支援システムの説明図。 第１実施形態のハードウェア構成の説明図。 第１実施形態の記憶部の説明図であって、（ａ）は利用者情報記憶部、（ｂ）は取引情報記憶部の説明図。 第１実施形態の処理手順の説明図。 第２実施形態の帳票情報記憶部の説明図。 第２の実施形態の処理手順の説明図。 他の実施形態の処理手順の説明図。

（第１実施形態）
以下、図１～図４に従って、支払支援システム、支払支援方法及び支払支援プログラムを具体化した一実施形態を説明する。本実施形態では、利用者の支払を支援する場合を想定する。
この支払を支援するサービスでは、図１に示すように、ネットワーク（インターネット）を介して接続された利用者端末１０、支援サーバ２０、ホストシステム３０を用いる。

（ハードウェア構成例）
図２は、利用者端末１０、支援サーバ２０、ホストシステム３０等として機能する情報処理装置Ｈ１０のハードウェア構成例である。

情報処理装置Ｈ１０は、通信装置Ｈ１１、入力装置Ｈ１２、表示装置Ｈ１３、記憶装置Ｈ１４、プロセッサＨ１５を有する。なお、このハードウェア構成は一例であり、他のハードウェアを有していてもよい。

通信装置Ｈ１１は、他の装置との間で通信経路を確立して、データの送受信を実行するインタフェースであり、例えばネットワークインタフェースカードや無線インタフェース等である。

入力装置Ｈ１２は、利用者等からの入力を受け付ける装置であり、例えばマウスやキーボード等である。表示装置Ｈ１３は、各種情報を表示するディスプレイやタッチパネル等である。

記憶装置Ｈ１４は、利用者端末１０、支援サーバ２０、ホストシステム３０の各種機能を実行するためのデータや各種プログラムを格納する記憶装置（例えば、後述する利用者情報記憶部２２、取引情報記憶部２３等）である。記憶装置Ｈ１４の一例としては、ＲＯＭ、ＲＡＭ、ハードディスク等がある。

プロセッサＨ１５は、記憶装置Ｈ１４に記憶されるプログラムやデータを用いて、利用者端末１０、支援サーバ２０、ホストシステム３０における各処理を制御する。プロセッサＨ１５の一例としては、例えばＣＰＵやＭＰＵ等がある。このプロセッサＨ１５は、ＲＯＭ等に記憶されるプログラムをＲＡＭに展開して、各種処理に対応する各種プロセスを実行する。例えば、プロセッサＨ１５は、利用者端末１０、支援サーバ２０、ホストシステム３０のアプリケーションプログラムが起動された場合、後述する各処理を実行するプロセスを動作させる。

プロセッサＨ１５は、自身が実行するすべての処理についてソフトウェア処理を行なうものに限られない。例えば、プロセッサＨ１５は、自身が実行する処理の少なくとも一部についてハードウェア処理を行なう専用のハードウェア回路（例えば、特定用途向け集積回路：ＡＳＩＣ）を備えてもよい。すなわち、プロセッサＨ１５は、（１）コンピュータプログラム（ソフトウェア）に従って動作する１つ以上のプロセッサ、（２）各種処理のうち少なくとも一部の処理を実行する１つ以上の専用のハードウェア回路、或いは（３）それらの組み合わせ、を含む回路（circuitry）として構成し得る。プロセッサは、ＣＰＵ並びに、ＲＡＭ及びＲＯＭ等のメモリを含み、メモリは、処理をＣＰＵに実行させるように構成されたプログラムコード又は指令を格納している。メモリすなわちコンピュータ可読媒体は、汎用又は専用のコンピュータでアクセスできるあらゆる利用可能な媒体を含む。

（支払支援システムの機能）
次に、図１を用いて、支払支援システムの機能を説明する。
利用者端末１０は、本サービスを利用する利用者が用いるコンピュータ端末である。

支援サーバ２０は、請求書等の取引帳票に基づいた支払を支援するコンピュータシステムである。この支援サーバ２０は、制御部２１、利用者情報記憶部２２、取引情報記憶部２３を備えている。

制御部２１は、後述する処理（支払支援段階、解析段階、評価段階等の各処理等）を行なう。そのための支払支援プログラムを実行することにより、制御部２１は、支払支援部２１１、解析部２１２、評価部２１３として機能する。

支払支援部２１１は、支払先に対する支払を支援する処理を実行する。
解析部２１２は、帳票画像を用いて文字認識処理を実行する。そして、解析部２１２は、文字認識処理により帳票画像から帳票記載情報（帳票種別、発行日、取引先、取引内容等）を取得する処理を実行する。

評価部２１３は、文字認識結果や関連帳票に基づいて、取引の正当性を確認する処理を実行する。この評価部２１３は、取引内容に応じて、支払に必要な関連帳票の帳票種別が記録された必要帳票情報を保持している。この必要帳票情報には、例えば、取引内容に含まれる支払対象商品の商品名や商品コードに応じて、必要な帳票種別（「見積書、請求書」、「見積書、納品書、請求書」、「請求書のみ」等）が記録される。

図３（ａ）に示すように、利用者情報記憶部２２には、金融機関の利用者についての利用者管理レコード２２０が記録されている。利用者管理レコード２２０は、利用者が金融機関に口座を開設した場合に記録される。利用者管理レコード２２０には、利用者コード、利用者名、パスワード、口座識別子、連絡先に関するデータが記録されている。

利用者コードデータ領域には、金融機関の各利用者を特定するための識別子に関するデータが記録されている。
利用者名データ領域には、この利用者の氏名、名称に関するデータが記録されている。

パスワードデータ領域には、支援サーバ２０へのログイン時に、本人認証に用いる認証用情報（パスワード）が記録されている。
口座識別子データ領域には、この利用者が保有する口座を特定するための識別子（本支店コード、種別コード、口座番号等）に関するデータが記録されている。
連絡先データ領域には、この利用者の連絡先（例えば、メールアドレス）に関するデータが記録されている。

図３（ｂ）に示すように、取引情報記憶部２３には、利用者から取得した帳票画像を管理するための取引管理レコード２３０が記録される。取引管理レコード２３０は、利用者端末１０から帳票画像を取得した場合に記録される。この取引管理レコード２３０には、登録日、利用者コード、帳票画像、帳票記載情報（帳票種別、発行日、取引先、取引内容）、ステータスに関するデータが記録されている。

登録日データ領域には、帳票画像を取得した日時（年月日及び時刻）に関するデータが記録される。
利用者コードデータ領域には、帳票画像を送信した利用者を特定するための識別子に関するデータが記録される。

帳票画像データ領域には、利用者端末１０から取得した支払関連帳票の画像が記録される。この画像の文字認識により、帳票種別、発行日、取引先、取引内容に関する情報を取得することができる。

帳票種別データ領域には、この支払関連帳票の種別（例えば、見積書、注文書、納品書、請求書等）に関するデータが記録される。
発行日データ領域には、この支払関連帳票の発行日に関するデータが記録される。

取引先データ領域には、この支払関連帳票の発行者（取引先）を特定するためのデータが記録される。
取引内容データ領域には、取引内容を特定するためのデータが記録される。取引内容としては、取引番号、商品名、商品コード、取引数、金額等を用いることができる。

ステータスデータ領域には、この支払関連帳票の取引の状況（取引結果）を特定するためのデータが記録される。この取引について、支払を完了した場合には、終了フラグが記録される。

支援サーバ２０には、金融機関のホストシステム３０が接続されている。このホストシステム３０は、銀行に開設された口座を管理し、支払サービスを提供する銀行のコンピュータシステムである。このため、ホストシステム３０は、管理する口座に関する情報を記憶した口座記憶部を備える。

（支払支援処理）
次に、図４を用いて、この支払支援システムにおける支払支援処理の処理手順を説明する。

まず、帳票に基づいて支払を行なう利用者は、利用者端末１０を用いて、ネットワークを介して、支援サーバ２０にアクセスする。
この場合、支援サーバ２０の制御部２１は、ログイン処理を実行する（ステップＳ１－１）。具体的には、制御部２１の支払支援部２１１は、利用者端末１０にログイン画面を出力する。このログイン画面には、利用者コード、パスワードの入力欄が設けられている。支払支援部２１１は、ログイン画面に入力された利用者コード、パスワードを利用者端末１０から取得し、利用者情報記憶部２２に登録があるかどうかを確認する。利用者情報記憶部２２に登録がない場合には、支払支援部２１１はログインを拒否する。

次に、利用者コード、パスワードの登録を確認できた場合には、支援サーバ２０の制御部２１は、帳票画像の取得処理を実行する（ステップＳ１－２）。具体的には、制御部２１の支払支援部２１１は、利用者端末１０に帳票アップロード画面を出力する。この場合、利用者は、支払対象の取引帳票（例えば、見積書、注文書、納品書、請求書等）を撮影やスキャンした帳票画像を利用者端末１０に取り込む。そして、取り込んだ帳票画像を、帳票アップロード画面において指定する。この場合、支払支援部２１１は、利用者端末１０から、帳票アップロード画面において指定された帳票画像（処理対象帳票）を取得する。そして、支払支援部２１１は、処理対象帳票について、登録日（画像の取得日）、利用者コード、帳票画像を記録した取引管理レコード２３０を生成し、取引情報記憶部２３に記録する。

次に、支援サーバ２０の制御部２１は、画像解析処理を実行する（ステップＳ１－３）。具体的には、制御部２１の解析部２１２は、利用者端末１０から取得した帳票画像に含まれる文字の文字認識を行なう。次に、解析部２１２は、文字認識結果に基づいて、帳票記載情報（帳票種別、発行日、取引先、取引内容）を取得する。そして、解析部２１２は、取引管理レコード２３０の帳票画像に関連付けて、帳票記載情報（帳票種別、発行日、取引先、取引内容）を記録する。

次に、支援サーバ２０の制御部２１は、関連帳票の検索処理を実行する（ステップＳ１－４）。具体的には、制御部２１の評価部２１３は、取引情報記憶部２３において、ステータスデータ領域に、終了フラグが記録されていない取引管理レコード２３０を特定する。更に、評価部２１３は、処理対象帳票と取引先が共通する取引管理レコード２３０を抽出する。この場合、処理対象帳票の発行日以前の日付が発行日として記録された取引管理レコード２３０が抽出される。

次に、支援サーバ２０の制御部２１は、整合性の確認処理を実行する（ステップＳ１－５）。具体的には、制御部２１の評価部２１３は、複数の関連帳票を特定した場合、処理対象帳票の取引内容と、他の関連帳票の取引内容とを比較する。例えば、処理対象帳票が納品書の場合であって、他の関連帳票が注文書の場合には、取引番号、商品名、商品コード、取引数の一致を確認する。また、処理対象帳票が請求書の場合であって、他の関連帳票が見積書の場合、取引番号、商品名、商品コード、取引数、金額の一致を確認する。

なお、関連帳票の検索処理（ステップＳ１－４）において、他の関連帳票を抽出しなかった場合には、支援サーバ２０の制御部２１は、整合性の確認処理（ステップＳ１－５）をスキップする。

次に、支援サーバ２０の制御部２１は、支払対象かどうかについての判定処理を実行する（ステップＳ１－６）。具体的には、制御部２１の評価部２１３は、処理対象帳票の取引管理レコード２３０の帳票種別を確認する。帳票種別として「請求書」が記録されている場合には、支払対象と判定する。

支払対象でないと判定した場合（ステップＳ１－６において「ＮＯ」の場合）、支払支援処理を終了する。
一方、支払対象と判定した場合（ステップＳ１－６において「ＹＥＳ」の場合）、支援サーバ２０の制御部２１は、請求対象に応じて必要帳票の種類の特定処理を実行する（ステップＳ１－７）。具体的には、制御部２１の評価部２１３は、取引管理レコード２３０の取引内容（商品名、商品コード）及び必要帳票情報を用いて、必要な関連帳票を特定する。

次に、支援サーバ２０の制御部２１は、不足帳票があるかどうかについての判定処理を実行する（ステップＳ１－８）。具体的には、制御部２１の評価部２１３は、処理対象帳票が請求書の場合、必要な関連帳票を特定できているかどうかを確認する。ここで、必要な関連帳票を特定できていない場合には、不足帳票があると判定する。一方、必要な他の関連帳票を特定できている場合には、不足帳票はないと判定する。

不足帳票がないと判定した場合（ステップＳ１－８において「ＮＯ」の場合）、支援サーバ２０の制御部２１は、ステータス記録処理を実行する（ステップＳ１－９）。具体的には、制御部２１の評価部２１３は、取引管理レコード２３０に、ステータスとして、関連帳票確認済みフラグを記録する。

一方、不足帳票があると判定した場合（ステップＳ１－８において「ＹＥＳ」の場合）、支援サーバ２０の制御部２１は、注意喚起処理を実行する（ステップＳ１－１０）。具体的には、制御部２１の支払支援部２１１は、利用者端末１０に、注意喚起画面を出力する。この注意喚起画面には、不足帳票があることを示すメッセージ、不足帳票の帳票種別に関する情報を含める。この場合、利用者は、不足帳票を確認する。例えば、不足帳票を登録し忘れている場合には、注意喚起画面において、不足帳票の帳票画像を指定する。この場合、制御部２１は、帳票画像の取得処理（ステップＳ１－２）、画像解析処理（ステップＳ１－３）により、不足帳票を取引情報記憶部２３に記録する。そして、評価部２１３は、取引管理レコード２３０に、ステータスとして、関連帳票確認済みフラグを記録する。

また、不足帳票が不要な場合には、注意喚起画面に、関連帳票は不要であることを示す確認入力を行なう。この場合も、支払支援部２１１は、取引管理レコード２３０に、ステータスとして、関連帳票確認済みフラグを記録する。

次に、支援サーバ２０の制御部２１は、確認済みかどうかについての判定処理を実行する（ステップＳ１－１１）。具体的には、制御部２１の評価部２１３は、取引管理レコード２３０に、ステータスとして、関連帳票確認済みフラグが記録されている場合に確認済みと判定する。

確認済みと判定した場合（ステップＳ１－１１において「ＹＥＳ」の場合）、支援サーバ２０の制御部２１は、支払処理を実行する（ステップＳ１－１２）。具体的には、制御部２１の支払支援部２１１は、請求書の帳票記載情報に基づいて、支払先、支払金額（請求金額）を設定した支払データを生成する。この場合、支払元には、利用者管理レコード２２０の口座識別子を設定する。そして、支払支援部２１１は、支払データをホストシステム３０に提供する。この場合、ホストシステム３０は、支払データに基づいて、支払元口座から支払金額を引き落とし、支払先口座への送金を行なう。そして、支払支援部２１１は、処理対象帳票及びすべての関連帳票の取引管理レコード２３０に、ステータスとして、終了フラグを記録する。

一方、確認済みでないと判定した場合（ステップＳ１－１１において「ＮＯ」の場合）、支払支援処理を終了する。

以上、本実施形態によれば、以下に示す効果を得ることができる。
（１－１）本実施形態では、支援サーバ２０の制御部２１は、帳票画像の取得処理（ステップＳ１－２）、画像解析処理（ステップＳ１－３）を実行する。これにより、帳票画像に含まれる内容を用いて、支払を行なうことができる。

（１－２）本実施形態では、支援サーバ２０の制御部２１は、関連帳票の検索処理を実行する（ステップＳ１－４）。これにより、処理対象帳票に関連する他の帳票を特定することができる。

（１－３）本実施形態では、支援サーバ２０の制御部２１は、整合性の確認処理（ステップＳ１－５）、請求対象に応じて必要帳票の種類の特定処理（ステップＳ１－７）を実行する。これにより、商慣行などにより、予め定められた必要帳票の不足を判定することができる。

そして、不足帳票があると判定した場合（ステップＳ１－８において「ＹＥＳ」の場合）、支援サーバ２０の制御部２１は、注意喚起処理を実行する（ステップＳ１－１０）。これにより、必要帳票が不足している場合には、確認を促すことができる。

（１－４）本実施形態では、支払対象と判定し、かつ確認済みと判定した場合（ステップＳ１－６，Ｓ１－１１において「ＹＥＳ」の場合）、支援サーバ２０の制御部２１は、支払処理を実行する（ステップＳ１－１２）。これにより、一連の帳票の存在を確認して、的確に支払を行なうことができる。

（第２実施形態）
次に、図５及び図６を用いて、帳票形態に基づいて適正性を判定する第２実施形態について説明する。上記第１実施形態では、支援サーバ２０の制御部２１は、整合性の確認処理を実行する（ステップＳ１－５）。第２実施形態では、整合性の確認処理（ステップＳ１－５）に加えて、処理対象帳票の帳票形態を用いた形態確認処理を実行する。

図５に示すように、支援サーバ２０に、帳票情報記憶部２４を設ける。この帳票情報記憶部２４には、支払を行なうための支払関連帳票の形態的特徴に関する帳票管理レコード２４０が記録される。帳票管理レコード２４０は、新たな取引先が登録された場合に記録され、帳票画像の解析処理が行なわれた場合に更新される。この帳票管理レコード２４０には、取引先コード、取引先名、帳票種別、帳票特徴情報に関するデータが記録されている。ここで、帳票特徴情報には、フォント情報（フォント種類やフォントサイズ）、形状特徴情報（印影、帳票レイアウト）等が含まれる。

取引先コードデータ領域には、支払を行なう取引先を特定するための識別子に関するデータが記録される。
取引先名データ領域には、この取引先の名称に関するデータが記録される。

帳票種別データ領域には、この取引先で用いられる支払関連帳票の種別に関するデータが記録される。
フォント種類データ領域、フォントサイズデータ領域には、それぞれ、この帳票で用いられているフォント種類に関するデータ、フォントのサイズに関するデータが記録される。

印影データ領域には、帳票に押印されている印影形状の特徴量に関するデータが記録される。
帳票レイアウトデータ領域には、帳票のレイアウト（配置形状）の特徴量に関するデータが記録される。ここでは、支払関連帳票において、取引に応じて記載が変更される内容を除いた利用者名欄、商品名欄、金額欄、請求人欄等の配置に関する特徴量が記録される。取引に応じて記載が変更される内容には、例えば、請求書番号や宛名、請求日、件名、支払期限、商品名、数量・単位、単価、請求金額等がある。

（形態確認処理）
図６に示すように、支援サーバ２０の制御部２１は、帳票形態の特定処理を実行する（ステップＳ２－１）。具体的には、制御部２１の解析部２１２は、帳票画像において、フォント情報を特定する。ここでは、文字認識時に、文字の形状に基づいて、フォント種類やフォントサイズを特定する。

更に、解析部２１２は、形状特徴情報として、帳票画像のパターン認識により印影を特定し、この印影形状の特徴量を算出する。
更に、解析部２１２は、形状特徴情報として、パターン認識により、帳票のレイアウトを特定する。具体的には、帳票における請求者欄、支払先欄、商品欄、金額欄等の記載位置や記載形状、各欄の位置関係（配置形状）を表わす特徴量を算出する。なお、ここでは、取引に応じて記載が変更される内容の画像を無視する。

そして、支援サーバ２０の制御部２１は、帳票形態の照合処理を実行する（ステップＳ２－２）。具体的には、制御部２１の解析部２１２は、支払先情報における請求者が、取引先名として記録されている帳票管理レコード２４０を抽出する。そして、解析部２１２は、帳票管理レコード２４０に記録されている帳票特徴情報（フォント種類やフォントサイズ等のフォント情報、印影やレイアウト等の形状特徴量）と、画像に基づいて算出した帳票特徴情報とを比較する。

次に、支援サーバ２０の制御部２１は、要確認かどうかについての判定処理を実行する（ステップＳ２－３）。具体的には、制御部２１の支払支援部２１１は、帳票管理レコード２４０の帳票特徴情報と帳票画像の帳票特徴情報との相違が大きい場合には、要確認と判定する。例えば、フォント種類やフォントサイズが異なる場合には、要確認と判定する。また、印影特徴量やレイアウト特徴量が確認基準値以上の差がある場合にも要確認と判定する。

確認不要と判定した場合（ステップＳ２－３において「ＮＯ」の場合）、支援サーバ２０の制御部２１は、ステータス更新処理を実行する（ステップＳ２－４）。具体的には、制御部２１の評価部２１３は、取引管理レコード２３０に、ステータスとして、形態確認済みフラグを記録する。そして、形態確認済みフラグが記録されている場合に、支援サーバ２０の制御部２１は、支払処理を実行する（ステップＳ１－１２）。

一方、要確認と判定した場合（ステップＳ２－３において「ＹＥＳ」の場合）、支援サーバ２０の制御部２１は、注意喚起処理を実行する（ステップＳ２－５）。具体的には、制御部２１の支払支援部２１１は、利用者端末１０に、注意喚起画面を出力する。この注意喚起画面には、帳票が取引先のパターンとは異なることを示すメッセージを含める。

次に、支援サーバ２０の制御部２１は、確認済みかどうかについての判定処理を実行する（ステップＳ２－６）。具体的には、利用者は、利用者端末１０を用いて、取引内容を確認して、注意喚起画面において確認結果を入力する。懸念がある場合には、支払中止ボタンを選択し、懸念がない場合には、確認完了ボタンを選択する。制御部２１の支払支援部２１１は、選択されたボタンに基づいて、確認結果を取得する。

確認済みと判定した場合（ステップＳ２－６において「ＹＥＳ」の場合）、支援サーバ２０の制御部２１は、データ更新処理を実行する（ステップＳ２－７）。具体的には、制御部２１の解析部２１２は、取引情報記憶部２３から、同じ取引先名、帳票種別に関する取引管理レコード２３０であって、直近から所定期間（評価対象期間）に含まれる登録日が記録されたレコードを抽出する。そして、解析部２１２は、各取引管理レコード２３０に記録されているフォント情報、形状特徴情報の統計値（例えば平均値）を算出し、帳票情報記憶部２４に記録されている帳票管理レコード２４０を更新する。
一方、確認済みでないと判定した場合（ステップＳ２－６において「ＮＯ」の場合）、支援サーバ２０の制御部２１は、支払中止処理を実行する（ステップＳ２－８）。具体的には、制御部２１の評価部２１３は、取引管理レコード２３０に、ステータスとして、支払不可フラグを記録する。

以上、第２実施形態によれば、第１実施形態の効果に加え、以下に示す効果を得ることができる。
（２－１）第２実施形態では、支援サーバ２０の制御部２１は、帳票形態の特定処理（ステップＳ２－１）、帳票形態の照合処理（ステップＳ２－２）を実行する。これにより、帳票の画像情報を用いて、不正懸念等があるため、確認が必要な帳票を検出し、注意喚起を行なうことができる。

本実施形態は、以下のように変更して実施することができる。本実施形態及び以下の変更例は、技術的に矛盾しない範囲で互いに組み合わせて実施することができる。
・上記各実施形態では、支援サーバ２０とホストシステム３０とを分けた例を示しているが、ハードウェア構成はこれに限定されるものではなく、両者を一体として構成することも可能である。

・上記第１実施形態では、支援サーバ２０の制御部２１は、請求対象に応じて必要帳票の種類の特定処理を実行する（ステップＳ１－７）。ここでは、必要帳票情報を用いて、商品名や商品コードに応じて、必要な他の関連帳票を特定する。必要帳票の特定は、商品名や商品コードを用いる場合に限定されるものではない。例えば、金額に応じて、必要帳票の帳票種別を特定するようにしてもよい。ここでは、支払額が所定金額以上の場合には、「見積書、納品書、請求書」を必要帳票として設定し、所定金額未満の場合よりも必要帳票を多くする。

また、取引頻度に応じて、必要帳票を特定するようにしてもよい。例えば、取引頻度が高い場合には、必要帳票の帳票種別を少なくするようにしてもよい。
更に、取引履歴に応じて、必要帳票を特定するようにしてもよい。例えば、取引履歴において、利用した帳票を記録しておく。そして、取引履歴において利用された帳票種別を必要帳票として特定する。

・上記第２実施形態では、支援サーバ２０の制御部２１は、帳票形態の特定処理を実行する（ステップＳ２－１）。帳票形態は、特徴情報の統計値に限定されるものではない。例えば、画像そのものを利用して、ディープラーニングを行なうようにしてもよい。この場合には、支払が中止された帳票画像や、不正が行なわれた帳票画像（異常画像）と、問題がなかった帳票画像（正常画像）等を教師情報として用いて、ディープラーニングを行なう。これにより、不正の有無の確からしさを予測する学習済みモデルを生成する。そして、処理対象帳票の帳票画像を学習済みモデルに入力して、不正の有無の確からしさを予測する。

・上記第２実施形態では、支援サーバ２０の制御部２１は、帳票形態の照合処理を実行する（ステップＳ２－２）。ここで、取引情報記憶部２３から、支払が中止された取引管理レコード２３０を抽出し、これらの帳票画像に基づいて、不正懸念がある帳票画像の特徴量を算出するようにしてもよい。この場合には、データ更新処理（ステップＳ２－７）において支払が中止された帳票画像の特徴情報を、帳票情報記憶部２４に記録しておく。そして、解析処理において、解析対象の帳票画像の特徴量が、問題がない帳票画像の特徴量と、不正懸念がある帳票の特徴量の何れかに近いかを判定する。

・上記第２実施形態では、支援サーバ２０の制御部２１は、帳票形態の照合処理を実行する（ステップＳ２－２）。ここで、処理対象帳票の帳票形態と、関連帳票の帳票形態とに基づいて真正性を判定してもよい。この場合、処理対象帳票及び関連帳票の帳票形態の形態特徴量（フォント情報、形状特徴情報）を比較し、一致度が基準値以上の場合には、適正と判定する。一方、一致度が基準値以上の場合には、要確認と判定し（ステップＳ２－３において「ＹＥＳ」）、支援サーバ２０の制御部２１は、注意喚起処理を実行する（ステップＳ２－５）。例えば、同一取引先であれば、一連の帳票（見積書～請求書）は、共通した形態を有すると想定されるので、この形態の共通性により、取引先の真正性を確認することができる。

・上記第１実施形態では、支援サーバ２０の制御部２１は、整合性の確認処理を実行する（ステップＳ１－５）。これに加えて、外部情報を用いて、各帳票の取引内容の適正性を判定するようにしてもよい。

例えば、支援サーバ２０を、インターネットを介して、取引サイトに接続できるようにしておく。この取引サイトは、利用者との間でのネット取引を管理するコンピュータシステムである。この取引サイトには、支払先の事業者だけではなく、同種類の商品を提供する他の事業者の取引サイトも含まれる。各取引サイトは、インターネットを介して、販売対象の商品や販売価格を公開している場合を想定する。

そして、図７に示すように、支援サーバ２０の制御部２１は、商品情報の検索処理を実行する（ステップＳ３－１）。具体的には、制御部２１の評価部２１３は、文字認識した請求者情報に基づいて、販売者の取引サイトを検索する。そして、請求者の取引サイトを特定できた場合、評価部２１３は、この取引サイトにおいて、文字認識した商品情報に基づいて、支払対象の商品を検索する。

次に、支援サーバ２０の制御部２１は、商品を確認可能かどうかについての判定処理を実行する（ステップＳ３－２）。具体的には、制御部２１の評価部２１３は、支払先の取引サイトにおいて、支払対象の商品を特定できた場合には、商品は実在し、商品を確認可能と判定する。

商品を確認可能と判定した場合（ステップＳ３－２において「ＹＥＳ」の場合）、支援サーバ２０の制御部２１は、価格は妥当かどうかについての判定処理を実行する（ステップＳ３－３）。具体的には、制御部２１の支払支援部２１１は、商品情報から取引対象の商品を扱っている取引サイトを検索し、各取引サイトにおける価格を取得する。次に、支払支援部２１１は、取得した価格の統計値（例えば平均値）を算出する。そして、支払支援部２１１は、取引サイトから算出した統計値と、請求書における請求金額とを比較する。算出した統計値と請求金額との差額が、判定基準額以上の場合には、価格は妥当でないと判定する。

価格は妥当と判定した場合（ステップＳ３－３において「ＹＥＳ」の場合）、支援サーバ２０の制御部２１は、ステータス更新処理を実行する（ステップＳ３－４）。具体的には、制御部２１の評価部２１３は、取引管理レコード２３０に、ステータスとして、外部確認済みフラグを記録する。そして、外部確認済みフラグが記録されている場合に、支援サーバ２０の制御部２１は、支払処理を実行する（ステップＳ１－１２）。

一方、商品を確認不可と判定した場合や、価格は妥当でないと判定した場合（ステップＳ３－２，Ｓ３－３において「ＮＯ」の場合）、支援サーバ２０の制御部２１は、注意喚起処理を実行する（ステップＳ３－５）。具体的には、制御部２１の支払支援部２１１は、利用者端末１０に、注意喚起画面を出力する。この注意喚起画面には、商品を確認できないことや、価格差が大きいことを示すメッセージが含まれる。

これにより、商品の取扱の実体がない可能性を特定し、注意喚起を行なうことができる。また、請求金額が一般的な価格から遊離している状況を検出して、注意喚起を行なうことができる。

１０…利用者端末、２０…支援サーバ、２１…制御部、２１１…支払支援部、２１２…解析部、２１３…評価部、２２…利用者情報記憶部、２３…取引情報記憶部、３０…ホストシステム。

Claims (10)

1. 帳票を用いた取引に関する情報を記憶する取引情報記憶部と、
   利用者端末に接続される制御部とを備えた支払支援システムであって、
   前記制御部が、
   支払に用いる取引帳票の帳票画像を取得し、
   前記帳票画像の文字認識により、前記取引帳票の帳票種別及び取引内容を含む帳票記載情報を取得し、
   前記取引情報記憶部において、前記帳票記載情報に基づいて、前記取引帳票の取引における一連のプロセスで用いられる帳票であって、前記取引帳票に関連する関連帳票を特定し、
   前記取引帳票の帳票記載情報と前記関連帳票の帳票記載情報との比較に基づいて、前記取引帳票を用いた支払の可否を判定し、
   前記取引帳票を用いた取引結果を前記取引情報記憶部に記録することを特徴とする支払支援システム。
2. 前記制御部が、前記取引帳票の帳票種別及び取引内容に基づいて、必要な関連帳票を特定することを特徴とする請求項１に記載の支払支援システム。
3. 前記制御部が、
   前記取引帳票の形態特徴量を算出し、
   前記形態特徴量と、前記関連帳票の形態特徴量とに基づいて、支払の可否を判定することを特徴とする請求項１又は２に記載の支払支援システム。
4. 前記取引帳票の前記形態特徴量として、前記帳票画像に含まれるフォント情報を用いることを特徴とする請求項３に記載の支払支援システム。
5. 前記取引帳票の前記形態特徴量として、前記帳票画像に含まれるレイアウト情報を用いることを特徴とする請求項３又は４に記載の支払支援システム。
6. 前記取引帳票の前記形態特徴量として、前記帳票画像に含まれる印影を用いることを特徴とする請求項３～５の何れか一項に記載の支払支援システム。
7. 前記帳票画像の文字認識により、前記帳票画像に含まれる支払対象商品を特定し、
   前記支払対象商品についての公開情報を検索し、
   前記支払対象商品の公開情報を取得できない場合には、前記利用者端末に注意喚起を出力することを特徴とする請求項１～６の何れか一項に記載の支払支援システム。
8. 前記帳票画像の文字認識により、前記帳票画像に含まれる請求金額を特定し、
   前記支払対象商品について公開された価格情報を取得し、
   前記請求金額と価格情報の統計値との比較に基づいて、前記利用者端末に注意喚起を出力することを特徴とする請求項７に記載の支払支援システム。
9. 帳票を用いた取引に関する情報を記憶する取引情報記憶部と、
   利用者端末に接続される制御部とを備えた支払支援システムを用いて、支払支援を行なうための方法であって、
   前記制御部が、
   支払に用いる取引帳票の帳票画像を取得し、
   前記帳票画像の文字認識により、前記取引帳票の帳票種別及び取引内容を含む帳票記載情報を取得し、
   前記取引情報記憶部において、前記帳票記載情報に基づいて、前記取引帳票の取引における一連のプロセスで用いられる帳票であって、前記取引帳票に関連する関連帳票を特定し、
   前記取引帳票の帳票記載情報と前記関連帳票の帳票記載情報との比較に基づいて、前記取引帳票を用いた支払の可否を判定し、
   前記取引帳票を用いた取引結果を前記取引情報記憶部に記録することを特徴とする支払支援方法。
10. 帳票を用いた取引に関する情報を記憶する取引情報記憶部と、
    利用者端末に接続される制御部とを備えた支払支援システムを用いて、支払支援を行なうためのプログラムであって、
    前記制御部を、
    支払に用いる取引帳票の帳票画像を取得し、
    前記帳票画像の文字認識により、前記取引帳票の帳票種別及び取引内容を含む帳票記載情報を取得し、
    前記取引情報記憶部において、前記帳票記載情報に基づいて、前記取引帳票の取引における一連のプロセスで用いられる帳票であって、前記取引帳票に関連する関連帳票を特定し、
    前記取引帳票の帳票記載情報と前記関連帳票の帳票記載情報との比較に基づいて、前記取引帳票を用いた支払の可否を判定し、
    前記取引帳票を用いた取引結果を前記取引情報記憶部に記録する手段として機能させることを特徴とする支払支援プログラム。

Images