(57)【要約】      （修正有）【課題】ＰＯＳレジ端末システムを修正することなく、二重に支払われるリスクを軽減させる情報処理端末、情報処理方法及びプログラムを提供する。【解決手段】データベースから請求書情報を取得し、その情報に紐付く識別記号とを送信可能なＷｅｂサーバと接続可能な情報処理端末であってＷｅｂサーバから送信された請求書情報及びその情報と紐付く識別記号を受信し、支払状態が未払い状態の請求書情報を識別可能に表示する。表示された請求書情報に対するユーザの指示により、指示された請求書情報と紐付く識別記号を表示する。表示される識別記号に紐付く請求書情報の振込金額と同じ出金額の証跡がある場合に出金の証跡があると判断し、表示される識別記号に紐付く請求書情報の出金の証跡があると判断された場合、Ｗｅｂサーバに、該請求書情報の支払状態を未払い状態から変更させる指示を送信する。【選択図】図１
2019109555.tif 000002
【特許請求の範囲】
【請求項１】
データベースから請求書情報を取得し、取得した請求書情報と前記請求書情報に紐付く識別記号とを送信可能なＷｅｂサーバと接続可能な情報処理端末であって、
前記Ｗｅｂサーバから送信された請求書情報及び前記請求書情報と紐付く識別記号を受信する受信手段と、
前記受信手段で受信した請求書情報の内、支払状態が未払い状態の請求書情報を識別可能に表示する第１の表示手段と、
前記第１の表示手段で表示された請求書情報に対するユーザの指示により、該ユーザにより指示された請求書情報と紐付く識別記号を表示する第２の表示手段と、
前記第２の表示手段で表示される識別記号に紐付く請求書情報の振込金額と同じ出金額の証跡がある場合に出金の証跡があると判断する出金証跡判断手段と、
前記出金証跡判断手段により、前記第２の表示手段で表示される識別記号に紐付く請求書情報の出金の証跡があると判断された場合、前記Ｗｅｂサーバに、該請求書情報の支払状態を未払い状態から変更させる指示を送信する未払い状態変更指示送信手段と、
を有することを特徴とする情報処理端末。
【請求項２】
前記情報処理端末は、電子決済を受け付ける決済受付端末と非接触通信を介して送信することにより電子決済を実施する電子決済手段を備え、
前記出金証跡判断手段は、前記電子決済手段による出金額が前記第２の表示手段で表示される識別記号に紐付く請求書情報の振込金額と同じである場合に出金の証跡があると判断することを特徴とする請求項１に記載の情報処理端末。
【請求項３】
前記情報処理端末は、撮像手段を備え、
前記出金証跡判断手段は、前記撮像手段により撮像された証憑情報から抽出した金額情報が前記第２の表示手段で表示される識別記号に紐付く請求書情報の振込金額と同じである場合に出金の証跡があると判断することを特徴とする請求項１又は２に記載の情報処理端末。
【請求項４】
前記情報処理端末は、光学文字認識手段を備え、
前記光学文字認識手段は、前記撮像手段により撮像された証憑情報から金額情報を読み取り、
前記出金証跡判断手段は、前記光学文字認識手段により読み取られた金額情報が前記第２の表示手段で表示される識別記号に紐付く請求書情報の振込金額と同じである場合に出金の証跡があると判断することを特徴とする請求項３に記載の情報処理端末。
【請求項５】
前記情報処理端末は、前記撮像手段により撮像された証憑情報から、支払日情報を取得する支払日取得手段を有し、
前記出金証跡判断手段は、前記撮像手段により撮像された証憑情報から抽出した金額情報が前記第２の表示手段で表示される識別記号に紐付く請求書情報の振込金額と同じで、かつ、前記支払日取得手段により取得された支払日情報が、前記第２の表示手段で表示された日である場合に出金の証跡があると判断することを特徴とする請求項３又は４に記載の情報処理端末。
【請求項６】
データベースから請求書情報を取得し、取得した請求書情報と前記請求書情報に紐付く識別記号とを送信可能なＷｅｂサーバと接続可能な情報処理端末における情報処理方法であって、
前記Ｗｅｂサーバから送信された請求書情報及び前記請求書情報と紐付く識別記号を受信する受信工程と、
前記受信工程で受信した請求書情報の内、支払状態が未払い状態の請求書情報を識別可能に表示する第１の表示工程と、
前記第１の表示工程で表示された請求書情報に対するユーザの指示により、該ユーザにより指示された請求書情報と紐付く識別記号を表示する第２の表示工程と、
前記第２の表示工程で表示される識別記号に紐付く請求書情報の振込金額と同じ出金額の証跡がある場合に出金の証跡があると判断する出金証跡判断工程と、
前記出金証跡判断工程により、前記第２の表示工程で表示される識別記号に紐付く請求書情報の出金の証跡があると判断された場合、前記Ｗｅｂサーバに、該請求書情報の支払状態を未払い状態から変更させる指示を送信する未払い状態変更指示送信工程と、
を有することを特徴とする情報処理方法。
【請求項７】
データベースから請求書情報を取得し、取得した請求書情報と前記請求書情報に紐付く識別記号とを送信可能なＷｅｂサーバと接続可能な情報処理端末におけるプログラムであって、
前記情報処理端末を
前記Ｗｅｂサーバから送信された請求書情報及び前記請求書情報と紐付く識別記号を受信する受信手段と、
前記受信手段で受信した請求書情報の内、支払状態が未払い状態の請求書情報を識別可能に表示する第１の表示手段と、
前記第１の表示手段で表示された請求書情報に対するユーザの指示により、該ユーザにより指示された請求書情報と紐付く識別記号を表示する第２の表示手段と、
前記第２の表示手段で表示される識別記号に紐付く請求書情報の振込金額と同じ出金額の証跡がある場合に出金の証跡があると判断する出金証跡判断手段と、
前記出金証跡判断手段により、前記第２の表示手段で表示される識別記号に紐付く請求書情報の出金の証跡があると判断された場合、前記Ｗｅｂサーバに、該請求書情報の支払状態を未払い状態から変更させる指示を送信する未払い状態変更指示送信手段として動作させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、Ｗｅｂ精算を行う際に利用する情報処理端末、情報処理方法及びプログラムに関する。
【背景技術】
【０００２】
現在、コンビニエンスストア（コンビニ）にてＰＯＳレジ端末によるバーコード読み取りを使用した請求書支払い方法が広く普及している。顧客が金融機関に行かなくても自由な時間に気軽に支払を行うことができるため、活用範囲が広まったいる。
【０００３】
特許文献１には、コンビニエンスストアにおいて、振込ユーザがコンビニエンスストアに設置されたマルチメディア端末から振込情報が登録されたバーコードを出力し、出力されたバーコードの用紙と共にコンビニエンスストアのＰＯＳレジ端末にて、振込金を支払うことができる技術が開示されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００６−２５２３７７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
特許文献１の技術では、コンビニエンスストアを経由して金融機関（振込先の口座）に支払われることになるため、請求会社に入金されるまでの時間が数日かかることもある。そのため、その数日間に別のユーザが、同じ振込予約情報（振込情報と紐付けられたマルチメディア端末に入力するＩＤ）をマルチメディア端末に入力してバーコードを出力し、再度振込金を支払うことが起こり得る。
【０００６】
このような二重支払いが発生すると、請求会社は振込ユーザへの返金、別請求との相殺などの処理を行う必要があり、業務コストが発生する課題が発生する。また、振込ユーザ側も、請求会社に二重支払いすることになり、そのまま受領されると余分に支払った分をロスしてしまう。
【０００７】
一方、情報処理端末（スマートフォンなど）にＷＥＢ請求画面を表示して、請求画面に表示されたバーコードをＰＯＳレジ端末に読ませることで、振込金を支払う技術もあるが、この場合も請求会社に入金されるまでの時間が数日かかることがあるため、その数日間に別のユーザがまた、ＷＥＢ請求画面を表示して振込金を支払う可能性が生じる。
【０００８】
これらの課題を解決するためには、コンビニエンスストアのＰＯＳレジ端末を、振込されるたびに請求会社に入金通知するようにシステム改良し、通知を受けた請求会社がＷｅｂ請求画面を表示しないようにすれば解決すると考えられるが、全国のコンビニエンスストアのＰＯＳレジ端末を様々な会社と通信できるようにシステムを改良することはコストがかかり過ぎて現実的ではない。
【０００９】
そこで本発明は、ＷＥＢ請求画面を表示している情報処理端末から、振込をした請求会社に支払情報を送信することにより、ＷＥＢ請求画面の表示を一旦停止（仮支払済）させ、入金確認後に正式に支払済とすることで、ＰＯＳレジ端末システムを修正することなく、二重に支払われるリスクを軽減させることを課題とする。
【課題を解決するための手段】
【００１０】
本発明は、データベースから請求書情報を取得し、取得した請求書情報と前記請求書情報に紐付く識別記号とを送信可能なＷｅｂサーバと接続可能な情報処理端末であって、前記Ｗｅｂサーバから送信された請求書情報及び前記請求書情報と紐付く識別記号を受信する受信手段と、前記受信手段で受信した請求書情報の内、支払状態が未払い状態の請求書情報を識別可能に表示する第１の表示手段と、前記第１の表示手段で表示された請求書情報に対するユーザの指示により、該ユーザにより指示された請求書情報と紐付く識別記号を表示する第２の表示手段と、前記第２の表示手段で表示される識別記号に紐付く請求書情報の振込金額と同じ出金額の証跡がある場合に出金の証跡があると判断する出金証跡判断手段と、前記出金証跡判断手段により、前記第２の表示手段で表示される識別記号に紐付く請求書情報の出金の証跡があると判断された場合、前記Ｗｅｂサーバに、該請求書情報の支払状態を未払い状態から変更させる指示を送信する未払い状態変更指示送信手段と、を有することを特徴とする。
【発明の効果】
【００１１】
本発明によれば、ＰＯＳレジ端末システムを修正することなく、ＷＥＢ請求画面を表示している情報処理端末から、振込をした請求会社に支払情報を送信することにより、ＷＥＢ請求画面の表示を一旦停止（仮支払済）させ、入金確認後に正式に支払済とすることで、二重に支払われるリスクを軽減させることを可能とする。
【図面の簡単な説明】
【００１２】
【図１】本発明の実施形態における、システム構成の一例を示すブロック図である。
【図２】本発明の実施形態における、情報処理装置に適応されるハードウェア構成の一例を示すブロック図である。
【図３】本発明の実施形態における、請求会社Ｗｅｂサーバ２００と情報処理端末１００とのデータの処理の流れを示す第１のフローチャートである。
【図４】本発明の実施形態における、請求会社Ｗｅｂサーバ２００と情報処理端末１００、ＰＯＳレジ端末３００とのデータの処理の流れを示す第２のフローチャートである。
【図５】本発明の実施形態における、情報処理端末１００の処理の流れを示す第３のフローチャートである。
【図６】本発明の実施形態における、請求会社Ｗｅｂサーバ２００の処理の流れを示す第４のフローチャートである。
【図７】本発明の実施形態における、情報処理端末１００のディスプレイ部に表示される画面イメージの一例を示す模式図である。
【発明を実施するための形態】
【００１３】
以下、図面を参照して、本発明の実施形態を詳細に説明する。
【００１４】
図１は、本発明の実施形態における、システム構成の一例を示すブロック図である。
【００１５】
図１の請求会社Ｗｅｂサーバ（請求会社Ｗｅｂ請求システム）２００は、顧客の情報処理端末（顧客携帯端末）１００からの依頼により、情報処理端末に請求書情報を送信する機能を有するサーバであり、未払いの案件や仮支払済の請求書の状況を送信することができる。仮支払済の請求書とは、コンビニエンスストアには支払済と考えられるが、請求会社にはまだ入金されていない状態の請求書を意味する。
【００１６】
また、請求会社Ｗｅｂサーバ２００は、顧客がコンビニエンスストアなどで振込金を振り込む際に、振込先口座番号や振り込む金額などを特定するための情報（振込バーコード）を情報処理端末１００に表示させる機能を有する。
【００１７】
顧客の情報処理端末１００は、請求会社Ｗｅｂサーバ２００から支払う必要のある振込請求書を受信し、ディスプレイ部２１０（後述する）に表示する。またコンビニエンスストアなどで振り込むための振込バーコードを受信し、振込バーコードもディスプレイ部２１０に表示する。
【００１８】
情報処理端末１００は、電子マネーアプリを有していてもよく、電子マネーアプリにより、コンビニエンスストアなどに設置されているＰＯＳレジ端末３００の非接触タグ認識部により、顧客の振込金を支払うことができる。
【００１９】
また、情報処理端末１００は、撮像部を有していてもよく、現金で支払った請求書分の領収書が撮像部で撮像され、ＯＣＲ（光学文字認識）処理を行い、領収書の支払金額と振込バーコードに登録されている振込金額とが一致しているかどうかの判断を行う。
【００２０】
コンビニエンスストアのＰＯＳレジ端末３００は、情報処理端末１００のディスプレイ部２１０に表示される振込バーコードを読み込み、振込先口座番号や振込金額などを取得する。
【００２１】
ＰＯＳレジ端末３００は、他に電子マネーによる入金を受け付ける仕様でもよく、情報処理端末１００がＰＯＳレジ端末３００の非接触タグ認識部に近づけられると、情報処理端末１００に保持されている電子マネーから出金させることができる。
【００２２】
以上の処理により、ＰＯＳレジ端末システムを修正することなく、ＷＥＢ請求画面を表示している情報処理端末から、振込をした場合に請求会社に支払情報を送信することにより、二重に支払われるリスクを軽減させることができる。詳細な処理は図３以降のフローチャートで説明する。
【００２３】
図２は、本発明の実施形態における情報処理端末１００、請求会社Ｗｅｂサーバ２００などに適応される情報処理装置のハードウェア構成の一例を示すブロック図である。
【００２４】
図２に示すように、情報処理装置は、システムバス２０４を介してＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）２０１、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）２０２、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）２０３、入力コントローラ２０５、ビデオコントローラ２０６、メモリコントローラ２０７、よび通信Ｉ／Ｆコントローラ２０８が接続される。
【００２５】
ＣＰＵ２０１は、システムバス２０４に接続される各デバイスやコントローラを統括的に制御する。
【００２６】
ＲＯＭ２０２あるいは外部メモリ２１１は、ＣＰＵ２０１が実行する制御プログラムであるＢＩＯＳ（Ｂａｓｉｃ  Ｉｎｐｕｔ／Ｏｕｔｐｕｔ  Ｓｙｓｔｅｍ）やＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）や、本情報処理方法を実現するためのコンピュータ読み取り実行可能なプログラムおよび必要な各種データ（データテーブルを含む）を保持している。
【００２７】
ＲＡＭ２０３は、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。ＣＰＵ２０１は、処理の実行に際して必要なプログラム等をＲＯＭ２０２あるいは外部メモリ２１１からＲＡＭ２０３にロードし、ロードしたプログラムを実行することで各種動作を実現する。
【００２８】
入力コントローラ２０５は、キーボード２０９や不図示のマウス等のポインティングデバイス等の入力装置からの入力を制御する。入力装置がタッチパネルの場合、ユーザがタッチパネルに表示されたアイコンやカーソルやボタンに合わせて押下（指等でタッチ）することにより、各種の指示を行うことができることとする。
【００２９】
また、タッチパネルは、マルチタッチスクリーンなどの、複数の指でタッチされた位置を検出することが可能なタッチパネルであってもよい。
【００３０】
ビデオコントローラ２０６は、ディスプレイ２１０などの外部出力装置への表示を制御する。ディスプレイは本体と一体になったノート型パソコンのディスプレイも含まれるものとする。なお、外部出力装置はディスプレイに限ったものははく、例えばプロジェクタであってもよい。また、前述のタッチ操作を受け付け可能な装置については、入力装置も提供する。
【００３１】
なおビデオコントローラ２０６は、表示制御を行うためのビデオメモリ（ＶＲＡＭ）を制御することが可能で、ビデオメモリ領域としてＲＡＭ２０３の一部を利用することもできるし、別途専用のビデオメモリを設けることも可能である。
【００３２】
メモリコントローラ２０７は、外部メモリ２１１へのアクセスを制御する。外部メモリとしては、ブートプログラム、各種アプリケーション、フォントデータ、ユーザファイル、編集ファイル、および各種データ等を記憶する外部記憶装置（ハードディスク）、フレキシブルディスク（ＦＤ）、或いはＰＣＭＣＩＡカードスロットにアダプタを介して接続されるコンパクトフラッシュ（登録商標）メモリ等を利用可能である。
【００３３】
通信Ｉ／Ｆコントローラ２０８は、ネットワークを介して外部機器と接続・通信するものであり、ネットワークでの通信制御処理を実行する。例えば、ＴＣＰ／ＩＰを用いた通信やＩＳＤＮなどの電話回線、および携帯電話の３Ｇ回線を用いた通信が可能である。
【００３４】
尚、ＣＰＵ２０１は、例えばＲＡＭ２０３内の表示情報用領域へアウトラインフォントの展開（ラスタライズ）処理を実行することにより、ディスプレイ２１０上での表示を可能としている。
【００３５】
ハードウェア上で動作する各種プログラムは、外部メモリ２１１に記録されており、必要に応じてＲＡＭ２０３にロードされることによりＣＰＵ２０１によって実行されるものである。
【００３６】
情報処理端末１００は、撮像部２１２も有していて、この撮像部で撮像したデータをＯＣＲ（光学文字認識）処理できる機能を有していても良い。ＯＣＲ処理の機能を有している場合、文字が認識された領収書上の支払金額と、振込金額とが等しいかを判断するプログラムをも有している。文字情報だけではなく、領収書に記載されている支払金額が埋め込まれたバーコード情報などを読み込むことが出来ても良い。
【００３７】
なお、全ての装置がこれらの構成を備えているわけではなく、必要なものを夫々備えていればよい。
【００３８】
次に、図３のフローチャートを参照して、本発明の実施形態におけるコンビニエンスストアでの支払い処理について説明する。
【００３９】
図３は、本発明の実施形態における、請求会社Ｗｅｂサーバ２００と情報処理端末１００とのデータの処理の流れを示す第１のフローチャートであり、図中のＳ３０１〜Ｓ３０８は各ステップを示す。各ステップの処理は、それぞれのシステムの外部メモリ２１１に格納されたアプリケーションプログラムを、それぞれのシステムのＣＰＵ２０１がＲＡＭ２０３上にロードして実行することにより実現される。
【００４０】
図３のフローチャートは、ユーザがコンビニエンスストアなどで情報処理端末１００（支払いユーザ端末）を利用して請求書の振込金を振り込もうとする際に開始される処理の流れである。なお、ステップＳ３０１の前に、請求会社Ｗｅｂサーバ２００（請求会社システム）へのユーザ認証処理などを行い、情報処理端末１００を個人認証（ログイン）しておくと良い。認証処理については、既知の技術であるため説明を省略する。
【００４１】
まず、ステップＳ３０１において、情報処理端末１００のＣＰＵ２０１は、ログインしている請求会社Ｗｅｂサーバ２００からＷｅｂ請求画面を取得するために、請求会社Ｗｅｂサーバ２００にＷｅｂ請求画面取得命令を送信する。
【００４２】
次に、ステップＳ３０２において、請求会社Ｗｅｂサーバ２００のＣＰＵ２０１は、ステップＳ３０１で送信されたＷｅｂ請求画面取得命令を受信すると、ログインされている顧客の情報から仮支払済を含む請求書一覧を請求会社Ｗｅｂサーバ２００が備えるデータベースなどから取得する。なお、前記データベースは請求会社Ｗｅｂサーバ２００が備えていても良いし、他のデータベースサーバなどから取得してもよい。以降では、請求会社Ｗｅｂサーバ２００が取得する請求書情報には、仮支払済の情報を含む例で示しているが、仮支払済の情報は必ず含む必要はなく、未払いの請求情報を取得するだけでもよく、また支払済の請求情報（請求会社に入金済みの請求情報）を含んでいても良い。
【００４３】
請求会社Ｗｅｂサーバ２００のＣＰＵ２０１は、取得した請求書一覧情報を情報処理端末１００に送信する。
【００４４】
次に、ステップＳ３０３において、情報処理端末１００のＣＰＵ２０１は、請求会社Ｗｅｂサーバ２００から送信された請求書一覧情報を受信し、請求書一覧をディスプレイ部２１０に表示する。請求章一覧を表示している画面イメージを図７を参照して説明する。
【００４５】
図７は、本発明の実施形態における情報処理端末１００のディスプレイ部２１０に表示される画面イメージの一例を示す模式図である。
【００４６】
図７の７００は、ステップＳ３０３において、情報処理端末１００のディスプレイ部２１０に表示される画面イメージであり、７０１行が未払い請求書の一覧、７０２行が仮支払済の請求書の一覧である。
【００４７】
未払い請求書の一覧７０１行の請求書選択ボタン７０３はアクティブになっており、７０３の何れかのボタンを押すと、次のステップＳ３０４へと処理を遷移する。一方、仮支払済の請求書一覧７０２行の請求書選択ボタン７０４は、当初は非アクティブになっており、ユーザが選択できないようになっている。この画面表示により、仮支払済の請求書にさらに入金するミスを防ぎ、振込ユーザは、二重に支払うことになる前に気付くことができる。また、請求会社は入金された振込ユーザへの返金、別請求との相殺などの処理を防ぐことができる。なお、振込ユーザのミスなどで振り込んでいないのに振り込んだことになった（仮支払済）場合などを考慮し、仮支払済のボタン７０４を２回目のタップにより、アクティブ状態に戻るようにしても良い。図３のフローチャートの説明に戻る。
【００４８】
次に、情報処理端末１００のＣＰＵ２０１は、７００の請求書選択ボタン７０３のどれかの選択を受け付ける（ステップＳ３０４）と、次にステップＳ３０５へと処理を遷移し、ステップＳ３０３で受信したデータの内、ステップＳ３０５で選択された請求書の明細情報をディスプレイ部２１０に表示する。図７を参照して、請求書の明細情報のイメージを説明する。
【００４９】
図７の７１０は、ステップＳ３０５において、情報処理端末１００のディスプレイ部２１０に表示される画面イメージであり、７１０の画面内には、請求書の明細情報が表示されている。７１１にある、『振込バーコード表示』が押下されると、次のステップＳ３０６へと処理を遷移する。振込バーコードとは、コンビニエンスストアで支払う際にＰＯＳレジ端末３００に読み込ませる、振込先口座番号や振り込む金額などが登録された情報である。図３のフローチャートの説明に戻る。
【００５０】
ステップＳ３０６へと処理が遷移すると、情報処理端末１００のＣＰＵ２０１は、請求会社Ｗｅｂサーバ２００に、振込バーコード（識別記号）を表示する情報を送信させる命令を発する。
【００５１】
次に、ステップＳ３０７において、請求会社Ｗｅｂサーバ２００のＣＰＵ２０１は、情報処理端末１００から受信した請求書に関する振込バーコードを表示するための情報生成し、情報処理端末１００に送信する。
【００５２】
次に、ステップＳ３０８において、情報処理端末１００のＣＰＵ２０１は、請求会社Ｗｅｂサーバ２００から送信された振込バーコード情報を受信し、次のステップＳ４０１へと処理をすすめる。以降、図４を参照して説明する。
【００５３】
図４は、本発明の実施形態における、請求会社Ｗｅｂサーバ２００と情報処理端末１００とのデータの処理の流れを示す第２のフローチャートであり、図中のＳ４０１〜Ｓ４２０は各ステップを示す。各ステップの処理は、それぞれのシステムの外部メモリ２１１に格納されたアプリケーションプログラムを、それぞれのシステムのＣＰＵ２０１がＲＡＭ２０３上にロードして実行することにより実現される。
【００５４】
図４のフローチャートは、図３のステップＳ３０８へと遷移した後で開始される処理の流れである。
【００５５】
まず、ステップＳ４０１において、情報処理端末１００のＣＰＵ２０１は、ディスプレイ部２１０に、ステップＳ３０８で受信した振込バーコード情報を表示する。同時に、領収書撮影ボタンと支払い終了ボタンも表示する。振込バーコード情報や領収書撮影ボタン、支払い終了ボタンを表示しているイメージを図７を参照して説明する。
【００５６】
図７の７２０は、ステップＳ４０１において、情報処理端末１００のディスプレイ部２１０に表示される画面イメージあり、７２０には、振込バーコード情報７２１、領収書撮影ボタン（『レシート読込』ボタン）７２３、支払い終了ボタン（『閉じる』ボタン）７２２が表示されている。振込ユーザは７２０に表示された振込バーコード情報をコンビニエンスストアのＰＯＳレジ端末３００などに読み込ませ、現金もしくは電子マネーで振込口座に支払うことができる。図４のフローチャートの説明に戻る。
【００５７】
７２０のような画面を情報処理端末１００のディスプレイ部２１０に表示すると、振込ユーザは、７２０に表示されている振込バーコード情報をコンビニエンスストアなどのＰＯＳレジ端末３００の読取部に読み込ませる（ステップＳ４０２）。この処理により、コンビニエンスストアのＰＯＳレジ端末３００は、振込ユーザがこれから振り込む振込口座番号や振込金額などを取得する。
【００５８】
次に、ステップＳ４０３において、ＰＯＳレジ端末３００は、ディスプレイ部に入金すべき金額を表示する（不図示）。
【００５９】
次からの処理は、情報処理端末１００に非接触型の電子マネーを保持する機能がある場合の処理である。電子マネーを保持する機能がなければ、ステップＳ４１１まで処理をスキップする。
【００６０】
次に、ユーザが非接触型の電子マネー（電子決済）で支払う意志がある場合、ユーザが情報処理端末１００をＰＯＳレジ端末３００に近づけ、情報処理端末１００のＣＰＵ２０１は、ステップＳ４０４において、情報処理端末１００の電子マネーから出金する処理を開始する。
【００６１】
電子マネーの出金を確認したＰＯＳレジ端末３００は、ステップＳ４０５において、電子マネーでの入金を受け付け、次のステップＳ４０６において、支払い処理を終了する。
【００６２】
一方、ステップＳ４０４において、電子マネーで支払われるかを監視するため、ステップＳ４０７とステップＳ４０８において、情報処理端末１００のＣＰＵ２０１は、電子マネー金額が変化したかをポーリングなどで監視する。電子マネー金額に変化があった場合（ステップＳ４０８でＹＥＳの場合）、ステップＳ４０９へと処理を遷移する。電子マネー金額に変化がなかった場合（ステップＳ４０８でＮＯの場合）、ステップＳ４１１へと処理を遷移し、ユーザから指示がなければ、所定時間はステップＳ４０７へと処理を戻す。ステップＳ４１１の処理は後述する。
【００６３】
ステップＳ４０９へと処理を遷移すると、情報処理端末１００のＣＰＵ２０１は、ステップＳ４０７で取得した電子マネーの支払額（出金額）を取得（証跡取得）する。
【００６４】
次に、ステップＳ４１０において、情報処理端末１００のＣＰＵ２０１は、ステップＳ３０４で選択され、取得された請求額と電子マネーの支払額が等しいかどうかを判断する。この判断は、もし支払額が請求額と異なれば、請求書の支払いとは別の会計で支払った可能性があるため、仮支払済としないための処理である。支払額が請求額と等しい場合は、ステップＳ４１７へと処理を遷移し、当該請求を仮支払済とするように請求会社Ｗｅｂサーバ２００に指示する。詳細は後述する。支払額が請求額と異なる場合は、ステップＳ４１１へと処理を遷移し、電子マネーでの支払いでは仮支払済とはしない処理へと移行する。
【００６５】
ステップＳ４１１へと処理を移行すると、情報処理端末１００のＣＰＵ２０１は、図７の７２０に表示されている領収書撮影ボタン（『レシート読込』ボタン）７２３か、支払い終了ボタン（『閉じる』ボタン）７２２が押下されたかを判断する。押下されていなければ（ステップＳ４１１でＮＯの場合）、次のステップＳ４１２へと処理を遷移し、情報処理端末１００のＣＰＵ２０１は、所定時間（例えば３０分など）の間、ステップＳ４０７からステップＳ４１２を繰り返す処理を行う。
【００６６】
領収書撮影ボタン（『レシート読込』ボタン）７２３か、支払い終了ボタン（『閉じる』ボタン）７２２がユーザにより押下された場合（ステップＳ４１１でＹＥＳの場合）は、ステップＳ４１３へと処理を遷移する。
【００６７】
ステップＳ４１３において、情報処理端末１００のＣＰＵ２０１は、押下されたボタンが領収書撮影ボタン（『レシート読込』ボタン）７２３かどうかを判断する。領収書撮影ボタン７２３が押下されている場合（ステップＳ４１３でＹＥＳの場合）は、ステップＳ４１４へと処理を遷移し、領収書撮影ボタン７２３が押下されていない場合、すなわち支払い終了ボタン７２２が押下された場合（ステップＳ４１３でＮＯの場合）は、本発明の処理を終了する（ステップＳ４１６の処理へ以降）。
【００６８】
ステップＳ４１４へと処理を遷移すると、情報処理端末１００のＣＰＵ２０１は、領収書の取込処理へと遷移する。領収書取込処理を図５を参照して説明する。
【００６９】
図５は、本発明の実施形態における、情報処理端末１００の処理の流れを示す第３のフローチャートであり、図中のＳ５０１〜Ｓ５０６は各ステップを示す。各ステップの処理は、それぞれのシステムの外部メモリ２１１に格納されたアプリケーションプログラムを、情報処理端末１００のＣＰＵ２０１がＲＡＭ２０３上にロードして実行することにより実現される。
【００７０】
図５のフローチャートは、図４のステップＳ４１４の処理へ遷移すると開始される処理の流れである。
【００７１】
まず、ステップＳ５０１において、情報処理端末１００のＣＰＵ２０１は、情報処理端末１００が有する撮像部を使用して、ユーザの操作により領収書（証憑情報）の画像を取り込む処理（領収書撮像処理）を実行する。撮像された画像はＲＡＭ２０３上に保存しても良いし、外部メモリ２１１に保存しても良い。
【００７２】
次に、ステップＳ５０２において、情報処理端末１００のＣＰＵ２０１は、ＲＡＭ２０３または外部メモリ２１１に保存された撮像画像をＯＣＲ（光学文字認識）処理し、領収書（レシート）内に記載されている文字列を抽出する。
【００７３】
次に、ステップＳ５０３において、情報処理端末１００のＣＰＵ２０１は、抽出された文字列から、支払金額情報（出金額）と支払日情報を取得する。金額情報の取得や支払日情報の取得処理は既存の技術なので、説明を省略する。
【００７４】
次に、ステップＳ５０４において、ステップＳ５０３で取得した支払金額と支払日が、ステップＳ３０４で選択され取得された請求額及びバーコードの生成日とそれぞれ一致しているかの判断を行う。支払金額と支払日が、請求額及びバーコードの生成日とそれぞれ一致している場合（ステップＳ５０４でＹＥＳの場合）は、ステップＳ５０６へと処理を遷移し、撮像された領収書が該当する請求書の支払いである旨を請求会社に返すための設定を行う。詳細は後述する。一方、支払金額か支払日が、請求額及びバーコードの生成日と一致しない場合（ステップＳ５０４でＮＯの場合）は、ステップＳ５０５へと処理を遷移する。
【００７５】
ステップＳ５０５へと処理を移行すると、支払金額と振込金額が異なるか、支払日がバーコード生成日と異なる場合なので、情報処理端末１００のＣＰＵ２０１は、情報処理端末１００のディスプレイ部２１０に領収書読込エラーを表示する。また、請求会社に送信する領収書フラグを「ＮＧ」と登録して、本フローチャートの処理を終える。この領収書フラグが、「ＮＧ」であれば撮影された領収書は振り込まれた領収書ではないことを意味する。
【００７６】
ステップＳ５０６へと処理を移行すると、支払金額と振込金額が等しく、支払日もバーコード生成日と等しい場合なので、情報処理端末１００のＣＰＵ２０１は、請求会社に送信する領収書フラグを「ＯＫ」と登録して、本フローチャートの処理を終える。この領収書フラグが、「ＯＫ」であれば撮影された領収書は振り込まれた領収書である可能性が高いことを意味する。図４のフローチャートの説明に戻る。
【００７７】
ステップＳ４１４において、領収書情報を取り込む処理を終えると、次にステップＳ４１５へと処理を遷移する。
【００７８】
ステップＳ４１５において、情報処理端末１００のＣＰＵ２０１は、ステップＳ４１４で取得した領収書フラグを参照し、「ＯＫ」か「ＮＧ」かによって処理を分ける。領収書フラグが「ＯＫ」の場合は、請求会社Ｗｅｂサーバ２００に振込が行われたことを通知するため、ステップＳ４１７の処理へと遷移する。一方、領収書フラグが「ＮＧ」の場合は、請求会社Ｗｅｂサーバ２００には通知をしないで、本フローチャートの処理を終える（ステップＳ４１６）。
【００７９】
ステップＳ４１７へと処理を移行すると、情報処理端末１００のＣＰＵ２０１は、請求会社Ｗｅｂサーバ２００がステップＳ３０７で生成した対象請求情報の支払い状態を、「仮支払済」という状態にするため、請求会社Ｗｅｂサーバ２００に仮支払済フラグを指示し、送信する（状態変更指示送信）。
【００８０】
次に、ステップＳ４１８において、請求会社Ｗｅｂサーバ２００のＣＰＵ２０１は、情報処理端末１００から仮支払済フラグを受信し、次のステップＳ４１９において、ステップＳ３０７で生成した対象請求情報の支払い状態を、「仮支払済」という状態に変更して本フローチャートの処理を終える（ステップＳ４２０）。
【００８１】
ステップＳ４１６で処理を終了した場合は、振込ユーザが支払ったか支払っていないかにかかわらず、請求会社Ｗｅｂサーバ２００の該当の請求書は「未払い」の状態のままである。一方、ステップＳ４２０で処理を終了した場合は、振込ユーザが支払った可能性が高いので、請求会社Ｗｅｂサーバ２００の該当の請求書は「仮支払済」の状態へ変更されている。
【００８２】
以上の処理のように、情報処理端末１００側で振り込みが終了したかそうでないかを判断し、請求会社Ｗｅｂサーバ２００に通知することにより、請求会社Ｗｅｂサーバ２００はいち早く仮支払済かどうかを判断できるため、ステップＳ３０２で請求書一覧の表示を求められても、ステップＳ３０４のように仮支払済の請求書は選択できない様にして、Ｗｅｂ請求書による二重支払いを防ぐことが出来る。
【００８３】
なお、ステップＳ４２０へと遷移して終了し、該当する請求書が仮支払済となった場合でも、電子マネーなどで請求額と同じ金額の別の買い物（精算）をした場合もある。その場合は、金融機関からの入金時などに再チェックを行い、仮支払済状態から未払い状態に変更する処理を行うことで、必要であれば入金を催促するなどの処理を行うことが出来る。金融機関からの入金確認後の処理を図６を参照して説明する。
【００８４】
図６は、本発明の実施形態における、請求会社Ｗｅｂサーバ２００の処理の流れを示す第４のフローチャートであり、図中のＳ６０１〜Ｓ６０５は各ステップを示す。各ステップの処理は、請求会社Ｗｅｂサーバ２００の外部メモリ２１１に格納されたアプリケーションプログラムを、情報処理端末１００のＣＰＵ２０１がＲＡＭ２０３上にロードして実行することにより実現される。
【００８５】
図６のフローチャートは、請求会社Ｗｅｂサーバ２００が金融機関からの入金を確認すると開始される処理の流れである。
【００８６】
まず、図６のステップＳ６０１において、請求会社Ｗｅｂサーバ２００のＣＰＵ２０１は、金融機関から請求会社に入金がされたかを判断する。入金がされた場合（ステップＳ６０１でＹＥＳの場合）はステップＳ６０２へと処理を遷移する。一方、入金がされていない場合（ステップＳ６０１でＮＯの場合）は、ステップＳ６０４へと処理を遷移し、一定期間（たとえば、コンビニエンスストアから金融機関に入金される平均時間もしくは最大時間等）だけ、ステップＳ６０１へ戻る処理を繰り返す。
【００８７】
ステップＳ６０２へと処理を移行すると、請求会社Ｗｅｂサーバ２００のＣＰＵ２０１は、金融機関からの情報から、仮支払済として設定された請求書と入金とが紐付け可能かどうかの判断を行う。紐付け可能な場合は、ステップＳ６０３へと処理を遷移する。一方、紐付けが出来ない入金の場合は、ステップＳ６０４へと処理を遷移し、一定期間だけ、ステップＳ６０１へ戻る処理を繰り返す。
【００８８】
ステップＳ６０３へと処理を遷移すると、請求会社Ｗｅｂサーバ２００のＣＰＵ２０１は、仮支払済として設定された該当の請求書の支払状態を支払済と登録して本フローチャートを終了する。この支払状態は、請求書の金額が正式に入金された状態を意味する。
【００８９】
一方、ステップＳ６０４において、一定期間（たとえば、コンビニエンスストアから金融機関に入金される平均時間もしくは最大時間等）を経過した場合（ステップＳ６０４でＹＥＳの場合）は、仮支払済として設定された該当の請求書の支払がなされていなかったと判断されるので、ステップＳ６０５へと処理を遷移し、請求会社Ｗｅｂサーバ２００のＣＰＵ２０１は、仮支払済として設定された該当の請求書の支払状態を未払いへと戻して登録して、本フローチャートの処理を終了する。
【００９０】
以上、図６の処理により、誤って仮支払済と登録されてしまった請求書でも入金されない場合は、未払い状態の戻すことにより、請求会社Ｗｅｂサーバ２００は再度、振込バーコード情報を情報処理端末１００に送信できるようになる。
【００９１】
なお、上述した各種データの構成及びその内容はこれに限定されるものではなく、用途や目的に応じて、様々な構成や内容で構成されることは言うまでもない。
【００９２】
また、本発明におけるプログラムは、図３〜６の処理をコンピュータに実行させるプログラムである。なお、本発明におけるプログラムは、図３〜６の各処理ごとのプログラムであってもよい。
【００９３】
以上のように、前述した実施形態の機能を実現するプログラムを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に格納されたプログラムを読み出し、実行することによっても本発明の目的が達成されることは言うまでもない。
【００９４】
この場合、記録媒体から読み出されたプログラム自体が本発明の新規な機能を実現することになり、そのプログラムを記録した記録媒体は本発明を構成することになる。
【００９５】
プログラムを供給するための記録媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＤＶＤ−ＲＯＭ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＥＥＰＲＯＭ、シリコンディスク等を用いることが出来る。
【００９６】
また、コンピュータが読み出したプログラムを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【００９７】
さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【００９８】
また、本発明は、複数の機器から構成されるシステムに適用しても、ひとつの機器から成る装置に適用しても良い。また、本発明は、システムあるいは装置にプログラムを供給することによって達成される場合にも適応できることは言うまでもない。この場合、本発明を達成するためのプログラムを格納した記録媒体を該システムあるいは装置に読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。
【００９９】
さらに、本発明を達成するためのプログラムをネットワーク上のサーバ、データベース等から通信プログラムによりダウンロードして読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。なお、上述した各実施形態およびその変形例を組み合わせた構成も全て本発明に含まれるものである。
【符号の説明】
【０１００】
１００  情報処理端末
２００  請求会社Ｗｅｂサーバ
２０１  ＣＰＵ
２０２  ＲＯＭ
２０３  ＲＡＭ
２０４  システムバス
２０５  入力コントローラ
２０６  ビデオコントローラ
２０７  メモリコントローラ
２０８  通信Ｉ／Ｆ（インタフェース）コントローラ
２０９  入力装置
２１０  ディスプレイ装置
２１１  外部メモリ
３００  コンビニエンスストアＰＯＳレジ端末
４００  インターネット
【図１】
2019109555.tif 000003
【図２】
2019109555.tif 000004
【図３】
2019109555.tif 000005
【図４】
2019109555.tif 000006
【図５】
2019109555.tif 000007
【図６】
2019109555.tif 000008
【図７】
2019109555.tif 000009