取引支援システム、取引支援方法及び取引支援プログラム
【課題】資金の移動を伴う取引において、返金事由が生じた場合に、的確な返金処理を支援するための取引支援システム、取引支援方法及び取引支援プログラムを提供する。
【解決手段】取引支援サーバ２０の制御部２１は、クライアント端末１０からのアクセスに応じてユーザ認証処理を実行し、このユーザの返金情報を抽出する。そして、企業において複数の返金方法を許容している場合、制御部２１は、ユーザに相殺又は振込のいずれかの返金方法を選択させる。ここで、振込が選択された場合、制御部２１は、クライアント端末１０から振込先口座情報を取得する。そして、制御部２１は、仕向金融機関との一致、口座存在チェック、名義人チェックを行ない、エラー毎に評価値を加算する。そして、合計値が管理レベル値を超えた場合、制御部２１は、この企業におけるエラー対応種別を取得し、エラー対応処理を実行する。
【解決手段】取引支援サーバ２０の制御部２１は、クライアント端末１０からのアクセスに応じてユーザ認証処理を実行し、このユーザの返金情報を抽出する。そして、企業において複数の返金方法を許容している場合、制御部２１は、ユーザに相殺又は振込のいずれかの返金方法を選択させる。ここで、振込が選択された場合、制御部２１は、クライアント端末１０から振込先口座情報を取得する。そして、制御部２１は、仕向金融機関との一致、口座存在チェック、名義人チェックを行ない、エラー毎に評価値を加算する。そして、合計値が管理レベル値を超えた場合、制御部２１は、この企業におけるエラー対応種別を取得し、エラー対応処理を実行する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、資金の移動を伴う取引において、返金事由が生じた場合に、的確な返金処理を支援する取引支援システム、取引支援方法及び取引支援プログラムに関する。
【背景技術】
【０００２】
今日、企業と顧客との間での取引において、代金の支払後に返金事由が生じることがある。このような場合には、企業から顧客に対して、支払われた代金の返金を行なう。このような返金事由が生じた場合に、振込手数料等の経済的負担を軽減しながら返金するための技術が検討されている（例えば、特許文献１参照。）。この文献に記載された技術では、返金額及び返金すべき顧客を特定する顧客特定情報を含む返金代行依頼を受け付ける。そして、返金を受けるためにアクセスすべきサイトの所在を含む電子メールを、顧客のメールアドレスを宛先として配信する。顧客がサイトにアクセスしたときに、電子貨幣に価値を付与する電子貨幣事業体に対して、顧客が商取引の支払に使用できる電子貨幣に、返金額に相当する価値を付与するよう指示する。
【０００３】
また、通信販売アイテムの代金を既に支払った利用者が、当該通信販売アイテムの購入を取り消した場合に、新たな支払金額と返金予定額とを相殺するための技術も検討されている（例えば、特許文献２参照。）。この文献に記載された技術では、通信販売アイテムの代金を既に支払った利用者が購入を取り消した場合、返金情報テーブルに返金予定額を記録する。更に、利用者により、新たな購入を希望する通信販売アイテムを受付け、その支払金額を記録する際には、そのテーブルに利用者の返金予定額が記録されていれば、その支払金額はその返金予定額分を自動的に減算する。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００３−１０８９０４号公報（第１頁、図１）
【特許文献２】特開２００５−３１６７５３号公報（第１頁、図１）
【発明の概要】
【発明が解決しようとする課題】
【０００５】
この特許文献１においては、電子貨幣により返金を行なう。しかし、この電子貨幣は、所定の目的の商取引にしか利用できないため、ユーザにとって不便な場合がある。このため、ユーザの預金口座等への振込等による返金を希望することもある。
【０００６】
一方、引用文献２には、返金のための相殺処理について開示されている。しかし、相殺の場合には、新たな取引が必要となる。ここで、新たな取引の予定がない場合には、円滑に返金することができない。
【０００７】
また、振込等により現金の返金を行なう場合には、本人に成りすました他人が受取側として返金金額を受け取る場合や、送金側が誤った口座への振込を抑制する必要がある。更に、取引を行なった企業においても返金方法や返金条件を指定したい場合もある。このような返金方法や返金条件は、返金を行なう企業によって異なる。
【０００８】
本発明は、上記課題を解決するためになされたものであり、その目的は、資金の移動を伴う取引において、返金事由が生じた場合に、的確な返金処理を支援するための取引支援システム、取引支援方法及び取引支援プログラムを提供することにある。
【課題を解決するための手段】
【０００９】
上記問題点を解決するために、請求項１に記載の発明は、第１利用者と第２利用者との間で行なわれる取引について、第２利用者から第１利用者に対して支払われた金額のうち、前記第２利用者に対する返金金額情報を蓄積した取引情報記憶手段と、第１利用者毎に返金条件を記録した返金条件情報記憶手段と、金融機関システムに接続される制御手段を備えた取引支援システムであって、前記制御手段が、前記第２利用者のクライアント端末からのアクセスを受信した場合、第１利用者から前記第２利用者に対する返金情報を取得する手段と、前記第１利用者の返金条件を前記返金条件情報記憶手段から取得する手段と、前記第２利用者のクライアント端末から返金先口座に関する情報を取得する手段と、前記返金先口座について前記返金条件を満足するかどうか判定し、前記返金条件を満足する場合には、前記返金情報についての振込実行指示を前記金融機関システムに対して送信する手段とを備えたことを要旨とする。
【００１０】
請求項２に記載の発明は、請求項１に記載の取引支援システムにおいて、前記返金条件情報記憶手段には、返金条件として、返金先口座を評価するための評価値が記録されており、前記制御手段が、前記第２利用者のクライアント端末から返金先口座についての評価値の合計値を算出する手段と、前記合計値が予め設定された基準値を超えた場合には、エラー対応処理を実行する手段とを更に備えたことを要旨とする。
【００１１】
請求項３に記載の発明は、請求項１又は２に記載の取引支援システムにおいて、前記返金条件情報記憶手段に記録された返金条件は、振込について複数の項目から構成されており、各項目に対して返金条件の満足を評価するための評価値が設定されており、前記制御手段が、各項目の評価値の合計値を算出し、前記合計値が予め設定された基準値を超えた場合には、エラー対応処理を実行する手段を更に備えたことを要旨とする。
【００１２】
請求項４に記載の発明は、請求項１〜３のいずれか一つに記載の取引支援システムにおいて、前記返金条件情報記憶手段には、前記返金条件として、口座の存在を確認できない場合の評価値が記録されており、前記制御手段が、前記返金先口座の存在情報を金融機関システムから取得し、口座の存在を確認できない場合には、前記評価値を加算した合計値を算出することを要旨とする。
【００１３】
請求項５に記載の発明は、請求項１〜４のいずれか一つに記載の取引支援システムにおいて、前記取引支援システムは、前記第２利用者が支払に用いた口座がある仕向金融機関情報を記録した利用者情報記憶手段を更に備え、前記返金条件情報記憶手段には、前記返金条件として、返金先口座と仕向金融機関情報との不一致を評価するための評価値が記録されており、前記制御手段が、前記返金先口座と仕向金融機関情報とが不一致の場合には、前記評価値を加算した合計値を算出することを要旨とする。
【００１４】
請求項６に記載の発明は、請求項４又は５に記載の取引支援システムにおいて、前記返金条件情報記憶手段には、前記返金条件として、返金先口座の名義人名と第２利用者の名前との不一致を評価するための評価値が記録されており、前記制御手段が、口座の存在の確認情報において取得した名義人名と前記第２利用者の利用者の名前とを比較し、不一致の場合には、前記評価値を加算した合計値を算出することを要旨とする。
【００１５】
請求項７に記載の発明は、請求項１〜６のいずれか一つに記載の取引支援システムにおいて、前記返金条件情報記憶手段において、前記返金条件として返金額範囲に対応して評価値が記録されており、前記制御手段が、第１利用者から前記第２利用者に対する返金情報における返金予定金額が含まれる返金額範囲に対応する評価値を取得し、前記評価値を加算した合計値を算出することを要旨とする。
【００１６】
請求項８に記載の発明は、前記取引情報記憶手段には、第２利用者から第１利用者に対する未入金の請求金額に関する情報が更に記録されており、前記制御手段が、前記第２利用者に対して、前記請求金額と返金金額との相殺希望の有無を確認するためのメッセージを出力する手段を更に備えたことを要旨とする。
【００１７】
請求項９に記載の発明は、請求項１〜８のいずれか一つに記載の取引支援システムにおいて、前記取引情報記憶手段には、返金を許容する返金期限に関する情報が更に記録されており、前記制御手段が、前記返金期限を過ぎた返金金額情報が残っている場合には、前記第２利用者に対して通知する手段を更に備えたことを要旨とする。
【００１８】
請求項１０に記載の発明は、 第１利用者と第２利用者との間で行なわれる取引について、第２利用者から第１利用者に対して支払われた金額のうち、前記第２利用者に対する返金金額情報を蓄積した取引情報記憶手段と、第１利用者毎に返金条件を記録した返金条件情報記憶手段と、金融機関システムに接続される制御手段を備えた取引支援システムを用いて、取引の支援処理を行なう方法であって、前記制御手段が、前記第２利用者のクライアント端末からのアクセスを受信した場合、第１利用者から前記第２利用者に対する返金情報を取得する段階と、前記第１利用者の返金条件を前記返金条件情報記憶手段から取得する段階と、前記第２利用者のクライアント端末から返金先口座に関する情報を取得する段階と、前記返金先口座について前記返金条件を満足するかどうか判定し、前記返金条件を満足する場合には、前記返金情報についての振込実行指示を前記金融機関システムに対して送信する段階とを実行することを要旨とする。
【００１９】
請求項１１に記載の発明は、第１利用者と第２利用者との間で行なわれる取引について、第２利用者から第１利用者に対して支払われた金額のうち、前記第２利用者に対する返金金額情報を蓄積した取引情報記憶手段と、第１利用者毎に返金条件を記録した返金条件情報記憶手段と、金融機関システムに接続される制御手段を備えた取引支援システムを用いて、取引の支援処理を行なうプログラムであって、前記制御手段を、前記第２利用者のクライアント端末からのアクセスを受信した場合、第１利用者から前記第２利用者に対する返金情報を取得する手段、前記第１利用者の返金条件を前記返金条件情報記憶手段から取得する手段、前記第２利用者のクライアント端末から返金先口座に関する情報を取得する手段、前記返金先口座について前記返金条件を満足するかどうか判定し、前記返金条件を満足する場合には、前記返金情報についての振込実行指示を前記金融機関システムに対して送信する手段として機能させることを要旨とする。
【００２０】
（作用）
請求項１、１０又は１１に記載の発明によれば、制御手段が、第２利用者のクライアント端末からのアクセスを受信した場合、第１利用者から第２利用者に対する返金情報を取得する。次に、第１利用者の返金条件を返金条件情報記憶手段から取得し、第２利用者のクライアント端末から返金先口座に関する情報を取得する。そして、返金先口座について返金条件を満足するかどうか判定し、返金条件を満足する場合には、返金情報についての振込実行指示を金融機関システムに対して送信する。これにより、第２利用者が設定した返金先口座について、第１利用者の返金条件に応じて返金を行なうことができる。
【００２１】
請求項２に記載の発明によれば、第２利用者のクライアント端末から返金先口座についての評価値の合計値を算出し、合計値が予め設定された基準値を超えた場合には、エラー対応処理を実行する。これにより、評価値の合計値を用いて、返金条件の満足を判定することができる。
【００２２】
請求項３に記載の発明によれば、制御手段が、各項目の評価値の合計値を算出し、合計値が予め設定された基準値を超えた場合には、エラー対応処理を実行する。これにより、
複数の項目において問題がある場合にも一元的に評価することができる。
【００２３】
請求項４に記載の発明によれば、制御手段が、返金先口座の存在情報を金融機関システムから取得し、口座の存在を確認できない場合には、評価値を加算した合計値を算出する。これにより、口座の存在を確認できない場合に問題を検知することができる。
【００２４】
請求項５に記載の発明によれば、制御手段が、返金先口座と仕向金融機関情報とが不一致の場合には、評価値を加算した合計値を算出する。これにより、仕向金融機関への振込を条件としている場合にも、評価値を用いて返金条件の満足を判定することができる。
【００２５】
請求項６に記載の発明によれば、制御手段が、口座の存在の確認情報において取得した名義人名と第２利用者の利用者の名前とを比較し、不一致の場合には、評価値を加算した合計値を算出する。これにより、本人名義の口座への振込を条件としている場合にも、評価値を用いて返金条件の満足を判定することができる。
【００２６】
請求項７に記載の発明によれば、制御手段が、第１利用者から第２利用者に対する返金情報における返金予定金額が含まれる返金額範囲に対応する評価値を取得し、評価値を加算した合計値を算出する。これにより、返金予定金額に応じて、エラー対応を変更することができる。
【００２７】
請求項８に記載の発明によれば、制御手段が、第２利用者に対して、請求金額と返金金額との相殺希望の有無を確認するためのメッセージを出力する。これにより、請求金額との相殺により返金を行なうことができる。
【００２８】
請求項９に記載の発明によれば、制御手段が、返金期限を過ぎた返金金額情報が残っている場合には、第２利用者に対して通知する。これにより、長期に亘って返金が残っている状態を抑制することができる。
【発明の効果】
【００２９】
本発明によれば、資金の移動を伴う取引において、返金事由が生じた場合に、的確な返金処理を支援することができる。
【図面の簡単な説明】
【００３０】
【図１】本発明の実施形態のシステム概略図。
【図２】本実施形態で用いるデータの説明図であって、（ａ）企業管理データ記憶部、（ｂ）ユーザ管理データ記憶部、（ｃ）請求管理データ記憶部、（ｄ）返金管理データ記憶部に記録されたデータの説明図。
【図３】本実施形態の処理手順の説明図。
【図４】本実施形態の処理手順の説明図。
【図５】本実施形態の処理手順の説明図。
【図６】本実施形態の処理手順の説明図。
【図７】本実施形態の処理手順の説明図。
【図８】本実施形態の処理手順の説明図。
【発明を実施するための形態】
【００３１】
以下、本発明を具体化した一実施形態を、図１〜図８に従って説明する。本実施形態では、ユーザと企業とが取引を行ない、この取引に関する資金を移動させる場合に用いる取引支援システム、取引支援方法及び取引支援プログラムとして説明する。この場合、企業（第１利用者）はユーザ（第２利用者）に対して取引商品を提供し、この取引に関する請求を行なう。一方、ユーザが取引商品を返品した場合には、企業はユーザに対して返金を
行なう。
【００３２】
本実施形態では、ユーザと企業との間の取引を支援するサービスを提供するために、図１に示す取引支援サーバ２０を用いる。この取引支援サーバ２０は、インターネットを介して、クライアント端末１０や企業サーバ３０、金融機関システム４０に接続される。
【００３３】
クライアント端末１０は、企業と取引を行なうユーザが用いるコンピュータ端末である。このクライアント端末１０は、ディスプレイ等から構成された表示部や、キーボードやポインティングデバイス等から構成された入力部を備える。
【００３４】
取引支援サーバ２０は、ユーザと企業との間で行なわれた取引を支援するためのサーバコンピュータである。この取引支援サーバ２０は、ＣＰＵ、ＲＡＭ、ＲＯＭ等から構成された制御手段としての制御部２１、企業管理データ記憶部２２、ユーザ管理データ記憶部２３、請求管理データ記憶部２４、返金管理データ記憶部２５を備えている。ここで、企業管理データ記憶部２２は返金条件情報記憶手段として機能し、ユーザ管理データ記憶部２３は利用者情報記憶手段として機能する。更に、請求管理データ記憶部２４、返金管理データ記憶部２５は、取引情報記憶手段として機能する。
【００３５】
ここで、制御部２１は、後述する処理（企業管理段階、返金管理段階、振込管理段階、期限管理段階等の各処理）を行なう。そして、制御部２１は、図１に示すように、取引支援プログラムにより、企業管理手段２１１、取引情報管理手段２１２、ユーザ認証手段２１３、返金管理手段２１５、振込管理手段２１６、期限管理手段２１７等として機能する。
【００３６】
企業管理手段２１１は、企業サーバ３０や企業の担当者端末からのアクセスに応じて、ログイン認証を行なう。
取引情報管理手段２１２は、企業サーバ３０から取引情報を取得し、請求情報や返金情報を記録する。また、企業の担当者端末からの請求状況の照会や返金状況の照会に応じて請求や返金のステータス情報を提供する。また、企業の担当者端末から、ユーザ管理コードのロック解除の指示を受けた場合には、ユーザ管理コードのロックを解除する。
【００３７】
ユーザ認証手段２１３は、クライアント端末１０からのアクセスに応じて、ユーザ認証を行なう。
返金管理手段２１５は、企業からユーザに対する返金情報を取得する処理を実行する。具体的には、返金管理手段２１５は、各企業によって指定された返金方法に応じて相殺又は振込の管理処理を実行する。
【００３８】
振込管理手段２１６は、返金条件、返金先口座に関する情報を取得し、返金先口座が返金条件を満足するかどうかを判定する処理を実行する。そして、条件を満足する場合、振込管理手段２１６は、返金のための振込処理を実行する。この処理を行なうために、振込管理手段２１６は、金融機関システム４０を利用できる口座確認サービス提供時間帯、振込サービス提供時間帯に関するデータや、各企業の口座識別子に関するデータを保持している。そして、この振込管理手段２１６は、合計値メモリを備えており、返金振込処理において生じたエラーの評価値の合計値を記憶する。
【００３９】
期限管理手段２１７は、ユーザに対する返金を許容する期限を管理する。具体的には、この期限が到来しても返金が未払い状態で残っている場合、期限管理手段２１７は、この返金を行なう企業サーバ３０に通知を行なう。この場合、企業の担当者が状況を確認し、必要に応じて、ユーザに連絡を取る等の措置を行なう。
【００４０】
企業管理データ記憶部２２には、図２（ａ）に示すように、本サービスを利用する各企業についての企業管理レコード２２０が記録される。この企業管理レコード２２０は、企業が取引支援サービスを利用する場合に登録される。この企業管理レコード２２０は、企業管理コード、パスワード、連絡先、返金方法、返金条件、エラー対応種別に関するデータを含んで構成される。
【００４１】
企業管理コードデータ領域には、本サービスを利用する企業を特定するための識別子に関するデータが記録される。
パスワードデータ領域には、この企業を認証するためのパスワードに関するデータが記録される。
【００４２】
連絡先データ領域には、この企業に通知を送信するための連絡先（ここではメールアドレス）に関するデータが記録される。
返金方法データ領域には、この企業からユーザに対して返金を行なう場合の返金方法を特定するためのフラグが記録される。本実施形態においては、「振込」や「相殺」を特定するフラグが記録される。ここで、複数の返金方法フラグが記録されている場合には、ユーザは返金方法を選択することができる。
【００４３】
返金条件データ領域には、返金を許容する場合の条件に関するデータが記録される。例えば、返金条件として、返金先の口座として、ユーザが支払に利用した仕向金融機関の口座に制限されている場合には、仕向金融機関制限フラグが記録される。また、振込先口座の名義人名とユーザ名とが一致が返金条件となっている場合には、振込先名義人制限フラグが記録される。
【００４４】
また、返金条件データ領域には、仕向金融機関不一致や口座存在確認不可、名義人名不一致等の振込について複数の項目（エラー種別）に対応させて、企業によって指定された重み付け値（返金先口座を評価するための評価値）に関するデータが記録される。
【００４５】
更に、返金条件データ領域には、エラー状況に応じて、後述するエラー対応の実施の要否を判定するための基準値（管理レベル値）に関するデータが記録される。
エラー対応種別データ領域には、返金振込処理において生じたエラーの評価値の合計値に応じた対応方法を特定するためのフラグが記録される。本実施形態においては、「企業に通知のみ」又は「ユーザ管理コードロック」のいずれかのフラグが記録される。
【００４６】
ユーザ管理データ記憶部２３には、図２（ｂ）に示すように、本サービスを利用する各ユーザについてのユーザ管理レコード２３０が記録される。このユーザ管理レコード２３０は、取引支援サービスを利用するユーザに関する情報を取得した場合に登録される。このユーザ管理レコード２３０は、ユーザ管理コード、パスワード、ユーザ名、連絡先、仕向金融機関情報、取引停止フラグを含んで構成される。
【００４７】
ユーザ管理コードデータ領域には、各ユーザを特定するための識別子に関するデータが記録される。
パスワードデータ領域には、このユーザを認証するためのパスワードに関するデータが記録される。
【００４８】
ユーザ名データ領域には、このユーザの氏名や名称に関するデータが記録される。
連絡先データ領域には、このユーザに通知を送信するための連絡先（ここではメールアドレス）に関するデータが記録される。
【００４９】
仕向金融機関情報データ領域には、このユーザが請求金額の支払を行なう場合に用いた
仕向金融機関に関するデータが記録される。本実施形態では、仕向金融機関の金融機関コードや本支店コードに関するデータが記録される。この仕向金融機関情報は、ユーザの支払毎に更新される。
【００５０】
取引停止フラグデータ領域には、このユーザとの取引の可否を判定するためのフラグが記録される。本実施形態では、このデータ領域に取引停止フラグが記録されている場合、このユーザに対する返金を停止する。
【００５１】
請求管理データ記憶部２４には、図２（ｃ）に示すように、企業からユーザに対して行なわれる請求についての請求管理レコード２４０が記録される。この請求管理レコード２４０は、企業サーバ３０から請求情報を取得した場合に登録される。この請求管理レコード２４０は、企業管理コード、ユーザ管理コード、取引管理コード、請求金額、入金ステータスに関するデータを含んで構成される。
【００５２】
企業管理コードデータ領域には、請求企業を特定するための識別子に関するデータが記録される。
ユーザ管理コードデータ領域には、請求先であるユーザを特定するための識別子に関するデータが記録される。
【００５３】
取引管理コードデータ領域には、各取引を特定するための識別子に関するデータが記録される。
請求金額データ領域には、企業からユーザに対する請求の金額に関するデータが記録される。
【００５４】
入金ステータスデータ領域には、この請求についての支払状況を特定するためのフラグが記録される。本実施形態では、このデータ領域には、「未入金」、「入金済」、「返金」を特定するフラグが記録される。
【００５５】
返金管理データ記憶部２５には、図２（ｄ）に示すように、企業からユーザに対して支払われる返金についての返金管理レコード２５０が記録される。この返金管理レコード２５０は、企業サーバ３０から返金情報を取得した場合に登録される。この返金管理レコード２５０は、企業管理コード、ユーザ管理コード、返金予定金額、期限、振込先口座、返金ステータスに関するデータを含んで構成される。
【００５６】
企業管理コードデータ領域には、返金を行なう請求企業を特定するための識別子に関するデータが記録される。
ユーザ管理コードデータ領域には、返金を受けるユーザを特定するための識別子に関するデータが記録される。
【００５７】
返金予定金額データ領域には、このユーザに対して支払われる返金金額に関するデータが記録される。
期限データ領域には、返金を許容する期限に関するデータが記録される。このデータ領域には、返品を確認してから所定期間後の年月日が設定される。
【００５８】
振込先口座データ領域には、返金先の口座を特定するための振込先口座識別子（金融機関コード、本支店コード、預金種目、口座番号等）や口座名義人情報に関するデータが記録される。
【００５９】
返金ステータスデータ領域には、この返金についての支払状況を特定するためのフラグが記録される。本実施形態では、このデータ領域には、「未返金」、「返金済」、「返金
済（エラー）」の各状況を特定するフラグが記録される。「未返金」フラグは、未だ返金されていないことを示す。「返金済」フラグは、エラーが発生することなく返金されたことを示し、「返金済（エラー）」フラグは、一部にエラーが発生したが返金されたことを示す。
【００６０】
企業サーバ３０は、企業において、ユーザとの間で行なわれる取引を管理するためのサーバコンピュータである。この企業サーバ３０は、顧客管理データ記憶部、商品管理データ記憶部、取引管理データ記憶部を備える。
【００６１】
顧客管理データ記憶部には、この企業と取引を行なうユーザを管理するための顧客管理レコードが記憶されている。この顧客管理レコードは、この企業と取引を行なうユーザのユーザ管理コード及びパスワードに関するデータを含んで構成される。
【００６２】
ユーザ管理コードデータ領域には、この企業と取引を行なう各ユーザを特定するための識別子に関するデータが記録される。
パスワードデータ領域には、このユーザを認証するためのパスワードに関するデータが記録される。
【００６３】
商品管理データ記憶部には、この企業が販売する商品を管理するための商品管理レコードが記憶されている。この商品管理レコードは、取引対象となる商品の商品管理コードや商品価格に関するデータを含んで構成される。
【００６４】
商品管理コードデータ領域には、各商品を特定するための識別子に関するデータが記録される。
商品価格データ領域には、この商品の販売価格に関するデータが記録される。
【００６５】
取引管理データ記憶部には、この企業と顧客との取引を管理するための取引管理レコードが記憶される。この取引管理レコードは、取引管理コード、商品管理コード、ユーザ管理コード、請求金額、取引ステータスに関するデータを含んで構成される。
【００６６】
取引管理コードデータ領域には、各取引を特定するための識別子に関するデータが記録される。
商品管理コードデータ領域には、この取引において取引対象の商品を特定するための識別子に関するデータが記録される。
【００６７】
ユーザ管理コードデータ領域には、この取引を行なったユーザを特定するための識別子に関するデータが記録される。
請求金額データ領域には、この取引において、ユーザに対して請求を行なった金額に関するデータが記録される。
【００６８】
取引ステータスデータ領域には、この取引の状況を特定するためのフラグが記録される。本実施形態では、このデータ領域には、「未入金」、「入金済」、「返品受付」、「返品確認」を特定するフラグが記録される。
【００６９】
金融機関システム４０は、各金融機関において開設された口座の口座名義人や口座残高に関するデータを管理する金融機関のコンピュータシステムである。この金融機関システム４０は、預金口座データベースを備えている。この預金口座データベースには、金融機関において開設された預金口座に関しての口座データが記録されている。この口座データは、金融機関に口座が開設された場合に登録される。口座データは、口座識別子、口座名義人情報、口座残高等に関するデータを含んで構成されている。
【００７０】
口座識別子データ領域には、開設された口座を特定するための識別子（金融機関コード、本支店コード、預金種目、口座番号等）に関するデータが記録されている。
口座名義人データ領域には、この口座に関する口座名義人（口座名義人名や顧客コード等）を特定するためのデータが記録されている。
口座残高データ領域には、この口座の残高を特定するためのデータが記録されている。
【００７１】
上記のように構成されたシステムを用いて、ユーザと企業との間で行なわれた取引についての資金移動を支援する場合の処理手順について、図３〜図８を用いて説明する。
【００７２】
（請求処理）
まず、図３を用いて、ユーザが購入した商品についての請求処理を説明する。
ここでは、クライアント端末１０は、企業サーバ３０に対してアクセス処理を実行する（ステップＳ１−１）。具体的には、商品を購入する場合、ユーザはクライアント端末１０を用いて企業サーバ３０にアクセスする。
【００７３】
次に、企業サーバ３０は、ユーザ認証処理を実行する（ステップＳ１−２）。具体的には、企業サーバ３０は、クライアント端末１０に対して、ユーザ認証画面を提供する。このユーザ認証画面には、ユーザ管理コード及びパスワードの入力欄や送信実行アイコンが設けられている。ここで、ユーザは、ユーザ管理コード及びパスワードを入力欄に設定し、送信実行アイコンを選択する。この場合、クライアント端末１０は、ユーザ管理コード及びパスワードを含めたログイン要求を企業サーバ３０に送信する。
【００７４】
ログイン要求を受信した企業サーバ３０は、取得したユーザ管理コード及びパスワードを用いて、ユーザ認証を行なう。ユーザ認証を完了した場合、企業サーバ３０は、取引管理データ記憶部において、このユーザ管理コードが記録されている取引管理レコードを検索する。そして、取引ステータスとして「返品確認」が記録された取引管理レコードの有無を判定する。ここでは、「返品確認」が記録された取引管理レコードがない場合、企業サーバ３０は、通常のメニュー画面をクライアント端末１０に送信する。このメニュー画面においては、商品カタログアイコンや返品依頼アイコンが設けられている。
【００７５】
次に、クライアント端末１０は、取引依頼を企業サーバ３０に送信する（ステップＳ１−３）。ここで、商品の購入を希望する場合には、商品購入アイコンを選択する。この場合、クライアント端末１０は、商品カタログ要求を企業サーバ３０に送信する。
【００７６】
次に、クライアント端末１０及び企業サーバ３０は、取引処理を実行する。具体的には、商品カタログ要求を受信した企業サーバ３０は、商品管理データ記憶部に記憶された商品についての商品カタログ画面をクライアント端末１０に提供する。この商品カタログ画面には、各商品を選択するために、商品管理コードが設定された商品アイコンが設けられている。ユーザは、クライアント端末１０のディスプレイに表示された商品カタログ画面を確認し、所望の商品の商品アイコンを選択する。この場合、クライアント端末１０は、商品購入の取引要求を企業サーバ３０に送信する。この取引要求には、購入対象の商品管理コードを含める。
【００７７】
次に、企業サーバ３０は、取引受付処理を実行する（ステップＳ１−４）。具体的には、取引要求を受信した企業サーバ３０は、購入対象の商品管理コードに関連付けられた商品価格に基いて請求金額を算出する。そして、企業サーバ３０は、この取引要求に対して、取引管理コードを付与し、取引管理コード、商品管理コード、ユーザ管理コード、請求金額を記録した取引管理レコードを生成する。
【００７８】
更に、企業サーバ３０は、請求情報登録処理を実行する（ステップＳ１−５）。具体的には、企業サーバ３０は、請求情報を取引支援サーバ２０に提供する。この請求情報には、企業管理コード、パスワード、ユーザ管理コード、取引管理コード及び請求金額に関するデータを含める。更に、企業サーバ３０は、クライアント端末１０に対して、商品代金（請求金額）の支払要求についてのメッセージを出力する。このメッセージには、入金時に用いる取引管理コードを含める。
【００７９】
次に、取引支援サーバ２０の制御部２１は、請求情報の蓄積処理を実行する（ステップＳ１−６）。具体的には、制御部２１の企業管理手段２１１は、取得した企業管理コード及びパスワードを用いてログイン認証を実行する。ログイン認証を完了した場合、取引情報管理手段２１２は、請求情報に含まれる企業管理コード、ユーザ管理コード、取引管理コード及び請求金額に関するデータを含めた請求管理レコード２４０を生成し、請求管理データ記憶部２４に登録する。この段階では、取引情報管理手段２１２は、この請求管理レコード２４０の入金ステータスとして「未入金」フラグを記録する。
【００８０】
そして、ユーザは支払処理を実行する（ステップＳ１−７）。本実施形態においては、クライアント端末１０を用いて金融機関システム４０にアクセスし、取引を行なった企業の口座に対して、商品代金の振込処理を行なう。この場合、企業サーバ３０から取得した取引管理コードを設定して振込処理を行なう。
【００８１】
次に、企業サーバ３０は、入金確認処理を実行する（ステップＳ１−８）。具体的には、企業サーバ３０は、金融機関システム４０に定期的にアクセスする。そして、企業サーバ３０は、企業口座への入金を確認する。入金を確認した企業サーバ３０は、入金情報に含まれる取引管理コードを特定する。そして、企業サーバ３０は、取得した取引管理コードが記録された取引管理レコードに「入金済」フラグを記録する。次に、企業サーバ３０は、特定した取引管理コードの購入商品をユーザに発送する指示を出力する。
【００８２】
次に、企業サーバ３０は、入金情報登録処理を実行する（ステップＳ１−９）。具体的には、企業サーバ３０は、取引支援サーバ２０に対して入金情報を提供する。この入金情報には、企業管理コード、パスワード、特定した取引管理コード、支払に用いられた仕向金融機関情報に関するデータを含める。
【００８３】
この場合、取引支援サーバ２０は、入金情報の蓄積処理を実行する（ステップＳ１−１０）。具体的には、制御部２１の企業管理手段２１１は、取得した企業管理コード及びパスワード及び企業管理データ記憶部２２を用いてログイン認証を実行する。ログイン認証を完了した場合、取引情報管理手段２１２は、取得した取引管理コードが記録された請求管理レコード２４０を、請求管理データ記憶部２４から抽出する。そして、取引情報管理手段２１２は、この請求管理レコード２４０の入金ステータスとして「入金済」フラグを記録する。更に、取引情報管理手段２１２は、仕向金融機関情報を、このユーザのユーザ管理レコード２３０に記録する。
【００８４】
（返金手続）
次に、購入商品を取得したユーザが、商品を返品する場合の返金手続を説明する。この場合には、企業はユーザから取得した商品代金を返金する。
【００８５】
まず、ステップＳ１−１と同様に、クライアント端末１０は、企業サーバ３０に対してアクセス処理を実行する（ステップＳ２−１）。そして、ステップＳ１−２と同様に、企業サーバ３０は、ユーザ認証処理を実行する（ステップＳ２−２）。ユーザ認証を完了した場合、企業サーバ３０は、メニュー画面をクライアント端末１０に送信する。このメニュー画面においては、商品カタログアイコンや返品依頼アイコンが設けられている。
【００８６】
次に、クライアント端末１０を用いて、返品依頼処理を実行する（ステップＳ２−３）。ここで、商品の返品を希望する場合には、返品依頼アイコンを選択する。この場合、クライアント端末１０は、返品手続要求を企業サーバ３０に送信する。
【００８７】
この場合、企業サーバ３０は、返品依頼受付処理を実行する（ステップＳ２−４）。具体的には、企業サーバ３０は、取引管理データ記憶部から、このユーザが購入した商品の中で、返品可能な商品を特定する。そして、企業サーバ３０は、返品可能な商品についての返品画面をクライアント端末１０に提供する。この返品画面には、返品対象の取引を選択するために、取引管理コードが設定された商品アイコンが設けられている。ユーザは、クライアント端末１０のディスプレイに表示された返品画面を確認し、所望の商品の商品アイコンを選択する。この場合、クライアント端末１０は、返品特定情報を企業サーバ３０に送信する。この返品特定情報には、返品対象の取引管理コードを含める。
【００８８】
そして、ユーザは商品の返品を行なう（ステップＳ２−５）。具体的には、ユーザは企業に対して、購入商品を返送する。そして、企業においては、返品された商品の確認を行なう（ステップＳ２−６）。具体的には、返品された商品を確認した企業の担当者は、企業サーバ３０の取引管理データ記憶部に記録された取引管理レコードを特定し、取引ステータスとして「返品確認」を設定する。
【００８９】
この場合、企業サーバ３０は、返金情報登録処理を実行する（ステップＳ２−７）。具体的には、企業サーバ３０は、返金情報を取引支援サーバ２０に送信する。この返金情報には、企業管理コード、パスワード、返品が行なわれた取引管理コードに関するデータを含める。
【００９０】
次に、取引支援サーバ２０の制御部２１は、返金情報の蓄積処理を実行する（ステップＳ２−８）。具体的には、制御部２１の企業管理手段２１１は、取得した企業管理コード及びパスワードを用いてログイン認証を実行する。ログイン認証を完了した場合、取引情報管理手段２１２は、請求管理データ記憶部２４から、取引管理コードが記録された請求管理レコード２４０を抽出する。そして、取引情報管理手段２１２は、請求管理レコード２４０の入金ステータスに「返金」フラグを記録する。更に、取引情報管理手段２１２は、企業管理コード、ユーザ管理コード、返金予定金額に関するデータを含めた返金管理レコード２５０を生成し、返金管理データ記憶部２５に登録する。更に、取引情報管理手段２１２は、現在日付に予め定められた返金期間を加算した期限を算出し、この返金管理レコード２５０の期限データ領域に記録する。また、この段階では、返金ステータスデータ領域には、「未返金」フラグを記録する。
【００９１】
（再度のアクセス処理）
次に、ユーザが再度、企業サーバ３０にアクセスした場合の処理を、図４を用いて説明する。
【００９２】
まず、ステップＳ１−１と同様に、クライアント端末１０は、企業サーバ３０に対してアクセス処理を実行する（ステップＳ３−１）。そして、ステップＳ１−２と同様に、企業サーバ３０は、ユーザ認証処理を実行する（ステップＳ３−２）。ユーザ認証を完了した場合、企業サーバ３０は、取引管理データ記憶部において、このユーザ管理コードが記録されている取引管理レコードを検索する。そして、取引ステータスとして「返品確認」が記録された取引管理レコードの有無を判定する。ここで、「返品確認」が記録された取引管理レコードがある場合、企業サーバ３０は、返金情報の取得処理を実行する（ステップＳ３−３）。具体的には、企業サーバ３０は、「返品確認」が記録された取引管理レコードから、取引管理コードや商品管理コードを取得する。
【００９３】
そして、企業サーバ３０は、返金案内画面の出力処理を実行する（ステップＳ３−４）。具体的には、企業サーバ３０は、クライアント端末１０に送信するメニュー画面に、返金があることを示すメッセージを含めた返金案内画面を生成する。このメッセージには、取引管理レコードから取得した取引管理コードや商品管理コードを含めるとともに、取引支援サーバ２０にアクセスするためのリンクアイコンを含める。そして、企業サーバ３０は、クライアント端末１０のディスプレイに返金案内画面を送信する。
【００９４】
次に、クライアント端末１０は、リンク処理を実行する（ステップＳ３−５）。具体的には、ユーザが返金を受ける場合、クライアント端末１０のディスプレイに表示された返金案内画面に含まれるリンクアイコンを選択する。この場合、クライアント端末１０は、取引支援サーバ２０に返金依頼を送信する。
そして、取引支援サーバ２０は、後述する返金処理を実行する（ステップＳ３−６）。
【００９５】
（返金処理）
次に、取引支援サーバ２０における返金処理を、図５を用いて説明する。
【００９６】
取引支援サーバ２０の制御部２１は、ユーザ認証処理を実行する（ステップＳ４−１）。具体的には、制御部２１のユーザ認証手段２１３は、クライアント端末１０に対してユーザ認証画面を提供する。このユーザ認証画面には、ユーザ管理コードの入力欄を含める。この入力欄にユーザ管理コードが設定された場合、クライアント端末１０は、ユーザ管理コードを取引支援サーバ２０に送信する。
【００９７】
この場合、ユーザ認証手段２１３は、取得したユーザ管理コードやパスワードが、ユーザ管理データ記憶部に記録されているかどうかを判定する。取得したユーザ管理コードやパスワードが記録されているユーザ管理レコード２３０を抽出できた場合、ユーザ認証手段２１３は、このユーザ管理レコード２３０に取引停止フラグが記録されていないかどうかを確認する。取引停止フラグが記録されている場合には、このユーザのアクセスを拒否する。
【００９８】
次に、取引支援サーバ２０の制御部２１は、返金情報の抽出処理を実行する（ステップＳ４−２）。具体的には、制御部２１の返金管理手段２１５は、返金管理データ記憶部２５から、取得したユーザ管理コードが記録された返金管理レコード２５０であって、返金ステータスデータ領域に「未返金」フラグが記録されたレコードを取得する。
【００９９】
次に、取引支援サーバ２０の制御部２１は、企業指定の返金方法の特定処理を実行する（ステップＳ４−３）。具体的には、制御部２１の返金管理手段２１５は、返金管理レコード２５０に記録された企業管理コードを特定し、この企業管理コードが記録された企業管理レコード２２０を企業管理データ記憶部２２から取得する。そして、企業管理レコード２２０に記録された返金方法データ領域に記録されたフラグに基づいて特定する。
【０１００】
次に、取引支援サーバ２０の制御部２１は、返金方法を選択できるかどうかについての判定処理を実行する（ステップＳ４−４）。具体的には、制御部２１の返金管理手段２１５は、返金方法データ領域に複数の返金方法フラグが記録されているかどうかにより判定する。更に、返金管理手段２１５は、請求管理データ記憶部２４から、企業管理コード及びユーザ管理コードが記録された請求管理レコード２４０を抽出する。そして、返金管理手段２１５は、「未入金」フラグが記録されている請求管理レコード２４０の有無を判定する。
【０１０１】
企業管理レコード２２０において複数の返金方法フラグが記録されており、このユーザ
について未入金の請求管理レコード２４０を抽出した場合には、相殺又は振込を選択することができる。一方、この企業管理レコード２２０において唯一の返金方法が定められている場合や、相殺対象となる未入金の請求管理レコード２４０を抽出できない場合には、返金方法は選択できない。未入金の請求管理レコード２４０がない場合には、振込による返金のみとなる。
【０１０２】
返金方法を選択できる場合（ステップＳ４−４において「ＹＥＳ」の場合）には、取引支援サーバ２０の制御部２１は、返金方法の選択画面の出力処理を実行する（ステップＳ４−５）。具体的には、制御部２１の返金管理手段２１５は、クライアント端末１０のディスプレイに返金方法の選択画面を出力する。この選択画面においては、相殺又は振込を選択するためのラジオボタンが設けられている。そして、返金管理手段２１５は、この選択画面において選択された返金方法を取得する。
【０１０３】
一方、返金方法が選択できない場合（ステップＳ４−４において「ＮＯ」の場合）には、取引支援サーバ２０の制御部２１は、返金方法の特定処理を実行する（ステップＳ４−６）。具体的には、制御部２１の返金管理手段２１５は、クライアント端末１０のディスプレイに特定された返金方法により返金を行なうことを示したメッセージを出力する。
【０１０４】
次に、取引支援サーバ２０の制御部２１は、振込又は相殺の判定処理を実行する（ステップＳ４−７）。具体的には、制御部２１の返金管理手段２１５は、先のステップで選択又は特定された返金方法を特定する。
【０１０５】
振込による返金が選択又は特定されている場合（ステップＳ４−７において「振込」の場合）、取引支援サーバ２０の制御部２１は、後述する返金振込処理を実行する（ステップＳ４−８）。
【０１０６】
一方、相殺による返金が選択又は特定されている場合（ステップＳ４−７において「相殺」の場合）、取引支援サーバ２０の制御部２１は、請求金額が返金予定金額以上かどうかについての判定処理を実行する（ステップＳ４−９）。具体的には、制御部２１の返金管理手段２１５は、請求管理レコード２４０に記録された請求金額と、返金管理レコード２５０に記録された返金予定金額とを比較する。
【０１０７】
請求金額が返金予定金額以上の場合（ステップＳ４−９において「ＹＥＳ」の場合）、取引支援サーバ２０の制御部２１は、相殺後の請求額の算出処理を実行する（ステップＳ４−１０）。具体的には、制御部２１の返金管理手段２１５は、請求金額から返金予定金額を差し引いた残金額を算出する。そして、返金管理手段２１５は、この残金額を用いて、請求管理レコード２４０の請求金額を更新する。更に、返金管理手段２１５は、返金管理レコード２５０の返金ステータスデータ領域に「返金済」フラグを記録する。
【０１０８】
次に、取引支援サーバ２０の制御部２１は、相殺後請求額の出力処理を実行する（ステップＳ４−１１）。具体的には、制御部２１の返金管理手段２１５は、クライアント端末１０のディスプレイに、内容確認画面を出力する。この内容確認画面には、相殺後の請求金額に関する情報を含める。
【０１０９】
一方、返金予定金額が請求金額未満の場合（ステップＳ４−９において「ＮＯ」の場合）、取引支援サーバ２０の制御部２１は、返金予定金額の更新処理を実行する（ステップＳ４−１２）。具体的には、制御部２１の返金管理手段２１５は、返金予定金額から請求金額を差し引いた残金額を用いて、返金管理レコード２５０の返金予定金額を更新する。
【０１１０】
次に、取引支援サーバ２０の制御部２１は、相殺内容の確認処理を実行する（ステップ
Ｓ４−１３）。具体的には、制御部２１の返金管理手段２１５は、返金予定金額情報画面を、クライアント端末１０のディスプレイに出力する。この返金予定金額情報画面には、残っている返金予定金額に関する情報を含める。そして、残っている返金予定金額について、ステップＳ４−４以降の処理を繰り返す。
【０１１１】
（返金振込処理）
次に、図６を用いて、返金振込処理（ステップＳ４−８）を説明する。
ここでは、取引支援サーバ２０の制御部２１は、企業管理データの取得処理を実行する（ステップＳ５−１）。具体的には、制御部２１の振込管理手段２１６は、企業管理データ記憶部２２に記録されている返金条件及びエラー対応種別に関するデータを取得する。
【０１１２】
次に、取引支援サーバ２０の制御部２１は、振込先設定画面の出力処理を実行する（ステップＳ５−２）。具体的には、制御部２１の振込管理手段２１６は、クライアント端末１０のディスプレイに振込先設定画面を出力する。この振込先設定画面においては、返金金額の振込先である預金口座を設定するための入力欄や送信実行アイコンが設けられている。
【０１１３】
次に、取引支援サーバ２０の制御部２１は、振込先情報の取得処理を実行する（ステップＳ５−３）。具体的には、ユーザは、入金先の預金口座情報を設定し、送信アイコンを選択する。この場合、クライアント端末１０は、設定された預金口座情報を取引支援サーバ２０に送信する。そして、制御部２１の振込管理手段２１６は、クライアント端末１０から振込先の預金口座情報を取得する。
【０１１４】
次に、取引支援サーバ２０の制御部２１は、金融機関の制限があるかどうかについての判定処理を実行する（ステップＳ５−４）。具体的には、制御部２１の振込管理手段２１６は、企業管理レコード２２０において、仕向金融機関への振込が返金条件になっているかどうかについて判定する。
【０１１５】
企業管理レコード２２０に仕向金融機関制限フラグが記録されており、振込先が仕向金融機関に制限されている場合（ステップＳ５−４において「ＹＥＳ」の場合）、取引支援サーバ２０の制御部２１は、仕向金融機関情報の取得処理を実行する（ステップＳ５−５）。具体的には、制御部２１の振込管理手段２１６は、ユーザ管理レコード２３０に記録された仕向金融機関情報を取得する。
【０１１６】
そして、取引支援サーバ２０の制御部２１は、振込先が仕向金融機関と一致しているかどうかについての判定処理を実行する（ステップＳ５−６）。具体的には、制御部２１の振込管理手段２１６は、振込先口座の口座情報と仕向金融機関情報とを比較する。本実施形態では、金融機関コード、本支店コードの一致を確認する。
【０１１７】
振込先口座情報と仕向金融機関情報とが一致していない場合（ステップＳ５−６において「ＮＯ」の場合）、取引支援サーバ２０の制御部２１は、評価値の加算処理を実行する（ステップＳ５−７）。具体的には、制御部２１の振込管理手段２１６は、この企業の企業管理レコード２２０から、「仕向金融機関不一致」に対応する評価値を取得する。そして、振込管理手段２１６は、合計値メモリに、この評価値を加算する。
【０１１８】
一方、仕向金融機関についての制限がない場合（ステップＳ５−４において「ＮＯ」の場合）や、振込先口座情報と仕向金融機関情報とが一致する場合（ステップＳ５−６において「ＹＥＳ」の場合）には、ステップＳ５−７の処理をスキップする。
【０１１９】
次に、取引支援サーバ２０の制御部２１は、口座確認サービス提供時間内かどうかにつ
いての判定処理を実行する（ステップＳ５−８）。具体的には、制御部２１の振込管理手段２１６は、システムタイマから現在日時を取得する。そして、この日時と金融機関システム４０において提供されている口座確認サービス提供時間帯とを比較する。
【０１２０】
口座確認サービス提供時間内でない場合（ステップＳ５−８において「ＮＯ」の場合）、後述する受付メールの送信処理（ステップＳ６−１５）を実行する。
一方、口座確認サービス提供時間内の場合（ステップＳ５−８において「ＹＥＳ」の場合）、取引支援サーバ２０の制御部２１は、口座存在チェック処理を実行する（ステップＳ５−９）。具体的には、制御部２１の振込管理手段２１６は、金融機関システム４０にアクセスする。そして、振込管理手段２１６は、金融機関システム４０に口座の存在確認依頼を送信する。この確認依頼には、クライアント端末１０から取得した振込先口座情報を含める。
【０１２１】
次に、図７に示すように、取引支援サーバ２０の制御部２１は、エラーかどうかについての判定処理を実行する（ステップＳ６−１）。具体的には、制御部２１の振込管理手段２１６は、金融機関システム４０から取得した口座存在確認結果に基づいて、この口座が存在するかどうかを判定する。
【０１２２】
口座存在確認結果において口座の存在を確認できず、エラーとなった場合（ステップＳ６−１において「ＹＥＳ」の場合）、取引支援サーバ２０の制御部２１は、評価値の加算処理を実行する（ステップＳ６−２）。具体的には、制御部２１の振込管理手段２１６は、この企業の企業管理レコード２２０から、「口座存在確認不可」に対応する評価値を取得する。そして、振込管理手段２１６は、合計値メモリに、この評価値を加算する。
【０１２３】
口座存在確認結果において口座の存在を確認でき、エラーとならなかった場合（ステップＳ６−１において「ＮＯ」の場合）、取引支援サーバ２０の制御部２１は、名義人名チェック処理を実行する（ステップＳ６−３）。具体的には、制御部２１の振込管理手段２１６は、口座存在確認結果において取得した振込先口座の名義人名を特定する。
【０１２４】
次に、取引支援サーバ２０の制御部２１は、名義人名が一致するかどうかについての判定処理を実行する（ステップＳ６−４）。具体的には、制御部２１の振込管理手段２１６は、口座存在確認結果において取得した振込先口座の名義人名と、ユーザ管理レコード２３０に記録されたユーザ名とを比較する。
【０１２５】
振込先口座の名義人名とユーザ名とが一致しない場合（ステップＳ６−４において「ＮＯ」の場合）、取引支援サーバ２０の制御部２１は、エラー扱いかどうかについての判定処理を実行する（ステップＳ６−５）。具体的には、制御部２１の振込管理手段２１６は、企業管理レコード２２０の送金条件において、振込先名義人制限フラグが記録されているかどうかにより判定する。
【０１２６】
振込先名義人制限フラグが記録されており、エラー扱いになっている場合（ステップＳ６−５において「ＹＥＳ」の場合）、取引支援サーバ２０の制御部２１は、評価値の加算処理を実行する（ステップＳ６−２）。ここでは、具体的には、制御部２１の振込管理手段２１６は、この企業の企業管理レコード２２０から、「名義人名不一致」に対応する評価値を取得する。そして、振込管理手段２１６は、合計値メモリに、この評価値を加算する。
【０１２７】
そして、取引支援サーバ２０の制御部２１は、評価値の合計値が管理レベル値を超えたかどうかについての判定処理を実行する（ステップＳ６−６）。具体的には、制御部２１の振込管理手段２１６は、企業管理レコード２２０に記録された管理レベル値を取得する
。そして、振込管理手段２１６は、合計値メモリに記録された値と、企業管理レコード２２０に記録された管理レベル値とを比較する。
【０１２８】
合計値が管理レベル値以下の場合（ステップＳ６−６において「ＮＯ」の場合）、取引支援サーバ２０の制御部２１は、振込先設定画面の出力処理（ステップＳ５−２）から繰り返す。一方、合計値が管理レベル値を超えた場合（ステップＳ６−６において「ＹＥＳ」の場合）、取引支援サーバ２０の制御部２１は、エラー対応種別の取得処理を実行する（ステップＳ６−７）。具体的には、制御部２１の振込管理手段２１６は、企業管理レコード２２０に記録されたエラー対応種別を取得する。
【０１２９】
次に、取引支援サーバ２０の制御部２１は、取引停止かどうかについての判定処理を実行する（ステップＳ６−８）。具体的には、制御部２１の振込管理手段２１６は、取得したエラー対応種別に「取引停止」フラグが記録の有無に基づいて判定する。
【０１３０】
エラー対応種別として「取引停止」フラグが記録されており、取引停止が必要である場合（ステップＳ６−８において「ＹＥＳ」の場合）、取引支援サーバ２０の制御部２１は、ユーザ管理コードのロック処理を実行する（ステップＳ６−９）。具体的には、制御部２１の振込管理手段２１６は、ユーザ管理レコード２３０に取引停止フラグを記録する。そして、企業の担当者は、取引支援サーバ２０にアクセスし、返金管理データ記憶部２５に蓄積された返金管理レコード２５０の取引停止フラグを確認することにより、このユーザについての取引停止状況を把握することができる。
【０１３１】
次に、取引支援サーバ２０の制御部２１は、ユーザ管理コードのロックの連絡処理を実行する（ステップＳ６−１０）。具体的には、制御部２１の振込管理手段２１６は、ユーザ管理データ記憶部２３から、このユーザのメールアドレスを取得する。そして、振込管理手段２１６は、このメールアドレスに対して、ユーザ管理コードをロックしたことを通知する。
【０１３２】
エラー対応種別として「取引停止」フラグが記録されておらず、取引停止が必要でない場合（ステップＳ６−８において「ＮＯ」の場合）、取引支援サーバ２０の制御部２１は、エラー記録処理を実行する（ステップＳ６−１１）。具体的には、制御部２１の振込管理手段２１６は、返金管理レコード２５０の返金ステータスデータ領域に「返金済（エラー）」フラグを記録する。そして、企業の担当者は、取引支援サーバ２０し、返金管理データ記憶部２５に蓄積された返金管理レコード２５０の「返金済（エラー）」フラグを確認することにより、このユーザについてのエラー状況を把握することができる。
【０１３３】
次に、取引支援サーバ２０の制御部２１は、確認画面の出力処理を実行する（ステップＳ６−１２）。具体的には、制御部２１の振込管理手段２１６は、クライアント端末１０に、振込を行なうことを知らせるメッセージを出力する。なお、振込先口座の名義人名とユーザ名とが一致する場合（ステップＳ６−４において「ＹＥＳ」の場合）、振込先名義人制限フラグが記録されておらず、エラー扱いになっていない場合（ステップＳ６−５において「ＮＯ」の場合）も、この確認画面の出力処理を実行する。
【０１３４】
そして、取引支援サーバ２０の制御部２１は、振込サービス提供時間内かどうかについての判定処理を実行する（ステップＳ６−１３）。具体的には、制御部２１の振込管理手段２１６は、現在日時と振込サービス提供時間帯とを比較する。
【０１３５】
現在日時が振込サービス提供時間内の場合（ステップＳ６−１３において「ＹＥＳ」の場合）、取引支援サーバ２０の制御部２１は、振込依頼処理を実行する（ステップＳ６−１４）。具体的には、制御部２１の振込管理手段２１６は、金融機関システム４０に対し
て振込依頼を送信する。この振込依頼には、企業の口座から振込先口座に、返金予定金額を入金する指示を含める。更に、振込管理手段２１６は、返金管理レコード２５０の返金ステータスデータ領域に「返金済」フラグを記録する。
【０１３６】
一方、現在日時が振込サービス提供時間内でない場合（ステップＳ６−１３において「ＮＯ」の場合）、取引支援サーバ２０の制御部２１は、受付メールの送信処理を実行する（ステップＳ６−１５）。具体的には、制御部２１の振込管理手段２１６は、クライアント端末１０に対して、振込サービス提供時間に振込を行なうことを示したメールを送信する。
【０１３７】
次に、取引支援サーバ２０の制御部２１は、振込サービス提供時間内になった場合に振込依頼処理を実行する（ステップＳ６−１６）。この処理を、図８を用いて説明する。
制御部２１の振込管理手段２１６は、ステップＳ５−９と同様に、口座存在チェック処理を実行する（ステップＳ７−１）。この口座存在確認結果において口座の存在を確認でき、エラーとならなかった場合（ステップＳ７−２において「ＮＯ」の場合）、取引支援サーバ２０の制御部２１は、ステップＳ６−３と同様に、名義人名チェック処理を実行する（ステップＳ７−３）。そして、振込先口座の名義人名とユーザ名とが一致する場合（ステップＳ７−４において「ＹＥＳ」の場合）には、振込管理手段２１６は、ステップＳ６−１４と同様に、振込依頼処理を実行する（ステップＳ７−５）。一方、振込先口座の名義人名とユーザ名とが一致しない場合（ステップＳ７−４において「ＮＯ」の場合）には、振込管理手段２１６は、ステップＳ６−５と同様に、エラー扱いかどうかについての判定処理を実行する（ステップＳ７−６）。エラー扱いになっていない場合（ステップＳ７−６において「ＮＯ」の場合）にも、振込依頼処理を実行する（ステップＳ７−５）。
【０１３８】
一方、エラー扱いになっている場合（ステップＳ７−６において「ＹＥＳ」の場合）には、取引支援サーバ２０の制御部２１は、企業管理レコード２２０から、「名義人名不一致」に対応する評価値の取得処理を実行する（ステップＳ７−７）。更に、ステップＳ６−７と同様に、この評価値に対応するエラー対応種別の取得処理を実行する（ステップＳ７−８）。ここで、エラー対応種別として「取引停止」フラグが記録されておらず、取引停止が必要でない場合（ステップＳ７−９において「ＮＯ」の場合）には、振込管理手段２１６は、ステップＳ６−１１，Ｓ６−１４と同様に、エラー記録処理（ステップＳ７−１０）、振込依頼処理（ステップＳ７−５）を実行する。そして、振込依頼を送信した場合には、振込管理手段２１６は、返金管理レコード２５０の返金ステータスデータ領域に「返金済」フラグを記録する。
【０１３９】
一方、口座存在確認結果において口座の存在を確認できず、エラーとなった場合（ステップＳ７−２において「ＹＥＳ」の場合）、取引支援サーバ２０の制御部２１は、振込不能通知処理を実行する（ステップＳ７−１１）。具体的には、制御部２１の振込管理手段２１６は、ユーザ管理データ記憶部２３から、このユーザのメールアドレスを取得し、このメールアドレスに対して、振込ができなかったことを通知する。また、エラー対応種別として「取引停止」フラグが記録されており、取引停止が必要である場合（ステップＳ７−９において「ＹＥＳ」の場合）にも、振込管理手段２１６は、振込不能通知処理を実行する（ステップＳ７−１１）。
【０１４０】
本実施形態によれば、以下のような効果を得ることができる。
（１） 本実施形態においては、企業管理データ記憶部２２には、本サービスを利用する各企業についての企業管理レコード２２０が記録される。この企業管理レコード２２０は、企業管理コード、パスワード、連絡先、返金方法、返金条件、エラー対応種別に関するデータを含んで構成される。そして、取引支援サーバ２０の制御部２１は、企業指定の返金方法の特定処理を実行する（ステップＳ４−３）。返金方法を選択できる場合（ステ
ップＳ４−４において「ＹＥＳ」の場合）には、取引支援サーバ２０の制御部２１は、返金方法の選択画面の出力処理を実行する（ステップＳ４−５）。これにより、企業に応じて返金方法や返金条件を設定することができる。
【０１４１】
（２） 本実施形態においては、取引支援サーバ２０の制御部２１は、振込先情報の取得処理を実行する（ステップＳ５−３）。そして、取引支援サーバ２０の制御部２１は、金融機関の制限があるかどうかについての判定処理を実行する（ステップＳ５−４）。企業管理レコード２２０に仕向金融機関制限フラグが記録されており、振込先が仕向金融機関に制限されている場合（ステップＳ５−４において「ＹＥＳ」の場合）、取引支援サーバ２０の制御部２１は、仕向金融機関情報の取得処理を実行する（ステップＳ５−５）。振込先口座情報と仕向金融機関情報とが一致していない場合（ステップＳ５−６において「ＮＯ」の場合）、取引支援サーバ２０の制御部２１は、評価値の加算処理を実行する（ステップＳ５−７）。これにより、ユーザが支払に用いた口座が開設された金融機関への振込を返金条件として、この条件を評価値により評価し、的確な返金を行なうことができる。
【０１４２】
（３） 本実施形態においては、取引支援サーバ２０の制御部２１は、口座存在チェック処理を実行する（ステップＳ５−９）。口座存在確認結果において口座の存在を確認できず、エラーとなった場合（ステップＳ６−１において「ＹＥＳ」の場合）、取引支援サーバ２０の制御部２１は、評価値の加算処理を実行する（ステップＳ６−２）。これにより、エラー毎に評価値を繰り返して加算するため、評価値の合計値が大きくなる。従って、振込先口座の確認や名義人名チェックにおいて繰り返しエラーとなった場合（ステップＳ６−１，Ｓ６−５において「ＹＥＳ」の場合）、エラー対応処理を実行することができる。
【０１４３】
（４） 本実施形態においては、口座存在確認結果において口座の存在を確認できた場合（ステップＳ６−１において「ＮＯ」の場合）、取引支援サーバ２０の制御部２１は、名義人名チェック処理を実行する（ステップＳ６−３）。振込先口座の名義人名とユーザ名とが一致しない場合（ステップＳ６−４において「ＮＯ」の場合）、取引支援サーバ２０の制御部２１は、エラー扱いかどうかについての判定処理を実行する（ステップＳ６−５）。これにより、支払人と同一人への返金を返金条件として、この条件を評価値により評価し、的確な返金を行なうことができる。
【０１４４】
振込先名義人制限フラグが記録されている場合（ステップＳ６−５において「ＹＥＳ」の場合）、取引支援サーバ２０の制御部２１は、評価値の加算処理を実行する（ステップＳ６−２）。これにより、名義人が異なる場合には、評価値の加算により注意を喚起することができる。
【０１４５】
（５） 本実施形態においては、取引支援サーバ２０の制御部２１は、評価値の合計値が管理レベル値を超えたかどうかについての判定処理を実行する（ステップＳ６−６）。合計値が管理レベル値を超えた場合（ステップＳ６−６において「ＹＥＳ」の場合）、取引支援サーバ２０の制御部２１は、エラー対応種別の取得処理を実行する（ステップＳ６−７）。これにより、企業により多様なエラー対応を実施することができる。
【０１４６】
更に、エラー対応種別として「取引停止」フラグが記録されている場合（ステップＳ６−８において「ＹＥＳ」の場合）、取引支援サーバ２０の制御部２１は、ユーザ管理コードのロック処理を実行する（ステップＳ６−９）。これにより、このユーザに対する返金を停止することができる。
【０１４７】
なお、上記各実施形態は以下のように変更してもよい。
・ 上記実施形態では、取引支援サーバ２０は、請求管理データ記憶部２４、返金管理データ記憶部２５を備えている。請求管理データ記憶部２４には、企業からユーザに対して行なわれる請求についての請求管理レコード２４０が記録される。返金管理データ記憶部２５には、企業からユーザに対して支払われる返金についての返金管理レコード２５０が記録される。そして、返金処理において、取引支援サーバ２０は請求管理レコード２４０や返金管理レコード２５０を利用する。この場合、企業サーバ３０にアクセスして、請求管理レコード２４０や返金管理レコード２５０を個別に取得するようにしてもよい。
【０１４８】
・ 上記実施形態では、企業サーバ３０は、請求情報登録処理（ステップＳ１−５）、入金情報登録処理（ステップＳ１−９）、返金情報登録処理（ステップＳ２−７）を実行する。そして、企業サーバ３０が、取引支援サーバ２０に対して、請求情報や入金情報、返金情報の提供を行なう。これに代えて、企業の担当者が、クライアント端末１０を用いて、取引支援サーバ２０に請求情報や入金情報、返金情報を提供するようにしてもよい。
【０１４９】
・ 上記実施形態では、企業サーバ３０は、入金確認処理を実行する（ステップＳ１−８）。これに代えて、取引支援サーバ２０が金融機関システム４０に定期的にアクセスし、企業の口座への入金を確認するようにしてもよい。そして、入金を確認した取引支援サーバ２０の制御部２１が、入金情報に含まれる取引管理コードを特定し、取引管理コードが記録された請求管理レコード２４０を、請求管理データ記憶部２４から抽出する。これにより、企業サーバ３０の処理負荷を軽減することができる。
【０１５０】
・ 上記実施形態では、返金条件データ領域には、エラー状況に応じて、エラー対応の実施の要否を判定するための管理レベル値に関するデータが記録される。この管理レベル値は、返金予定金額の範囲（返金額範囲）に応じて変更するようにしてもよい。具体的には、返金条件データ領域には、返金予定金額を変数として、管理レベル値を算出するためのテーブルや関数を記憶させておく。これにより、返金予定金額に応じてエラー対応の実施の要否を決定することができる。例えば、返金予定金額が高い場合には慎重な返金処理を実行し、返金予定金額が低い場合には簡易な返金処理を実行することができる。
【符号の説明】
【０１５１】
１０…クライアント端末、２０…取引支援サーバ、２１…制御部、２１１…企業管理手段、２１２…取引情報管理手段、２１３…ユーザ認証手段、２１５…返金管理手段、２１６…振込管理手段、２１７…期限管理手段、２２…企業管理データ記憶部、２３…ユーザ管理データ記憶部、２４…請求管理データ記憶部、２５…返金管理データ記憶部、３０…企業サーバ、４０…金融機関システム。
【技術分野】
【０００１】
本発明は、資金の移動を伴う取引において、返金事由が生じた場合に、的確な返金処理を支援する取引支援システム、取引支援方法及び取引支援プログラムに関する。
【背景技術】
【０００２】
今日、企業と顧客との間での取引において、代金の支払後に返金事由が生じることがある。このような場合には、企業から顧客に対して、支払われた代金の返金を行なう。このような返金事由が生じた場合に、振込手数料等の経済的負担を軽減しながら返金するための技術が検討されている（例えば、特許文献１参照。）。この文献に記載された技術では、返金額及び返金すべき顧客を特定する顧客特定情報を含む返金代行依頼を受け付ける。そして、返金を受けるためにアクセスすべきサイトの所在を含む電子メールを、顧客のメールアドレスを宛先として配信する。顧客がサイトにアクセスしたときに、電子貨幣に価値を付与する電子貨幣事業体に対して、顧客が商取引の支払に使用できる電子貨幣に、返金額に相当する価値を付与するよう指示する。
【０００３】
また、通信販売アイテムの代金を既に支払った利用者が、当該通信販売アイテムの購入を取り消した場合に、新たな支払金額と返金予定額とを相殺するための技術も検討されている（例えば、特許文献２参照。）。この文献に記載された技術では、通信販売アイテムの代金を既に支払った利用者が購入を取り消した場合、返金情報テーブルに返金予定額を記録する。更に、利用者により、新たな購入を希望する通信販売アイテムを受付け、その支払金額を記録する際には、そのテーブルに利用者の返金予定額が記録されていれば、その支払金額はその返金予定額分を自動的に減算する。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００３−１０８９０４号公報（第１頁、図１）
【特許文献２】特開２００５−３１６７５３号公報（第１頁、図１）
【発明の概要】
【発明が解決しようとする課題】
【０００５】
この特許文献１においては、電子貨幣により返金を行なう。しかし、この電子貨幣は、所定の目的の商取引にしか利用できないため、ユーザにとって不便な場合がある。このため、ユーザの預金口座等への振込等による返金を希望することもある。
【０００６】
一方、引用文献２には、返金のための相殺処理について開示されている。しかし、相殺の場合には、新たな取引が必要となる。ここで、新たな取引の予定がない場合には、円滑に返金することができない。
【０００７】
また、振込等により現金の返金を行なう場合には、本人に成りすました他人が受取側として返金金額を受け取る場合や、送金側が誤った口座への振込を抑制する必要がある。更に、取引を行なった企業においても返金方法や返金条件を指定したい場合もある。このような返金方法や返金条件は、返金を行なう企業によって異なる。
【０００８】
本発明は、上記課題を解決するためになされたものであり、その目的は、資金の移動を伴う取引において、返金事由が生じた場合に、的確な返金処理を支援するための取引支援システム、取引支援方法及び取引支援プログラムを提供することにある。
【課題を解決するための手段】
【０００９】
上記問題点を解決するために、請求項１に記載の発明は、第１利用者と第２利用者との間で行なわれる取引について、第２利用者から第１利用者に対して支払われた金額のうち、前記第２利用者に対する返金金額情報を蓄積した取引情報記憶手段と、第１利用者毎に返金条件を記録した返金条件情報記憶手段と、金融機関システムに接続される制御手段を備えた取引支援システムであって、前記制御手段が、前記第２利用者のクライアント端末からのアクセスを受信した場合、第１利用者から前記第２利用者に対する返金情報を取得する手段と、前記第１利用者の返金条件を前記返金条件情報記憶手段から取得する手段と、前記第２利用者のクライアント端末から返金先口座に関する情報を取得する手段と、前記返金先口座について前記返金条件を満足するかどうか判定し、前記返金条件を満足する場合には、前記返金情報についての振込実行指示を前記金融機関システムに対して送信する手段とを備えたことを要旨とする。
【００１０】
請求項２に記載の発明は、請求項１に記載の取引支援システムにおいて、前記返金条件情報記憶手段には、返金条件として、返金先口座を評価するための評価値が記録されており、前記制御手段が、前記第２利用者のクライアント端末から返金先口座についての評価値の合計値を算出する手段と、前記合計値が予め設定された基準値を超えた場合には、エラー対応処理を実行する手段とを更に備えたことを要旨とする。
【００１１】
請求項３に記載の発明は、請求項１又は２に記載の取引支援システムにおいて、前記返金条件情報記憶手段に記録された返金条件は、振込について複数の項目から構成されており、各項目に対して返金条件の満足を評価するための評価値が設定されており、前記制御手段が、各項目の評価値の合計値を算出し、前記合計値が予め設定された基準値を超えた場合には、エラー対応処理を実行する手段を更に備えたことを要旨とする。
【００１２】
請求項４に記載の発明は、請求項１〜３のいずれか一つに記載の取引支援システムにおいて、前記返金条件情報記憶手段には、前記返金条件として、口座の存在を確認できない場合の評価値が記録されており、前記制御手段が、前記返金先口座の存在情報を金融機関システムから取得し、口座の存在を確認できない場合には、前記評価値を加算した合計値を算出することを要旨とする。
【００１３】
請求項５に記載の発明は、請求項１〜４のいずれか一つに記載の取引支援システムにおいて、前記取引支援システムは、前記第２利用者が支払に用いた口座がある仕向金融機関情報を記録した利用者情報記憶手段を更に備え、前記返金条件情報記憶手段には、前記返金条件として、返金先口座と仕向金融機関情報との不一致を評価するための評価値が記録されており、前記制御手段が、前記返金先口座と仕向金融機関情報とが不一致の場合には、前記評価値を加算した合計値を算出することを要旨とする。
【００１４】
請求項６に記載の発明は、請求項４又は５に記載の取引支援システムにおいて、前記返金条件情報記憶手段には、前記返金条件として、返金先口座の名義人名と第２利用者の名前との不一致を評価するための評価値が記録されており、前記制御手段が、口座の存在の確認情報において取得した名義人名と前記第２利用者の利用者の名前とを比較し、不一致の場合には、前記評価値を加算した合計値を算出することを要旨とする。
【００１５】
請求項７に記載の発明は、請求項１〜６のいずれか一つに記載の取引支援システムにおいて、前記返金条件情報記憶手段において、前記返金条件として返金額範囲に対応して評価値が記録されており、前記制御手段が、第１利用者から前記第２利用者に対する返金情報における返金予定金額が含まれる返金額範囲に対応する評価値を取得し、前記評価値を加算した合計値を算出することを要旨とする。
【００１６】
請求項８に記載の発明は、前記取引情報記憶手段には、第２利用者から第１利用者に対する未入金の請求金額に関する情報が更に記録されており、前記制御手段が、前記第２利用者に対して、前記請求金額と返金金額との相殺希望の有無を確認するためのメッセージを出力する手段を更に備えたことを要旨とする。
【００１７】
請求項９に記載の発明は、請求項１〜８のいずれか一つに記載の取引支援システムにおいて、前記取引情報記憶手段には、返金を許容する返金期限に関する情報が更に記録されており、前記制御手段が、前記返金期限を過ぎた返金金額情報が残っている場合には、前記第２利用者に対して通知する手段を更に備えたことを要旨とする。
【００１８】
請求項１０に記載の発明は、 第１利用者と第２利用者との間で行なわれる取引について、第２利用者から第１利用者に対して支払われた金額のうち、前記第２利用者に対する返金金額情報を蓄積した取引情報記憶手段と、第１利用者毎に返金条件を記録した返金条件情報記憶手段と、金融機関システムに接続される制御手段を備えた取引支援システムを用いて、取引の支援処理を行なう方法であって、前記制御手段が、前記第２利用者のクライアント端末からのアクセスを受信した場合、第１利用者から前記第２利用者に対する返金情報を取得する段階と、前記第１利用者の返金条件を前記返金条件情報記憶手段から取得する段階と、前記第２利用者のクライアント端末から返金先口座に関する情報を取得する段階と、前記返金先口座について前記返金条件を満足するかどうか判定し、前記返金条件を満足する場合には、前記返金情報についての振込実行指示を前記金融機関システムに対して送信する段階とを実行することを要旨とする。
【００１９】
請求項１１に記載の発明は、第１利用者と第２利用者との間で行なわれる取引について、第２利用者から第１利用者に対して支払われた金額のうち、前記第２利用者に対する返金金額情報を蓄積した取引情報記憶手段と、第１利用者毎に返金条件を記録した返金条件情報記憶手段と、金融機関システムに接続される制御手段を備えた取引支援システムを用いて、取引の支援処理を行なうプログラムであって、前記制御手段を、前記第２利用者のクライアント端末からのアクセスを受信した場合、第１利用者から前記第２利用者に対する返金情報を取得する手段、前記第１利用者の返金条件を前記返金条件情報記憶手段から取得する手段、前記第２利用者のクライアント端末から返金先口座に関する情報を取得する手段、前記返金先口座について前記返金条件を満足するかどうか判定し、前記返金条件を満足する場合には、前記返金情報についての振込実行指示を前記金融機関システムに対して送信する手段として機能させることを要旨とする。
【００２０】
（作用）
請求項１、１０又は１１に記載の発明によれば、制御手段が、第２利用者のクライアント端末からのアクセスを受信した場合、第１利用者から第２利用者に対する返金情報を取得する。次に、第１利用者の返金条件を返金条件情報記憶手段から取得し、第２利用者のクライアント端末から返金先口座に関する情報を取得する。そして、返金先口座について返金条件を満足するかどうか判定し、返金条件を満足する場合には、返金情報についての振込実行指示を金融機関システムに対して送信する。これにより、第２利用者が設定した返金先口座について、第１利用者の返金条件に応じて返金を行なうことができる。
【００２１】
請求項２に記載の発明によれば、第２利用者のクライアント端末から返金先口座についての評価値の合計値を算出し、合計値が予め設定された基準値を超えた場合には、エラー対応処理を実行する。これにより、評価値の合計値を用いて、返金条件の満足を判定することができる。
【００２２】
請求項３に記載の発明によれば、制御手段が、各項目の評価値の合計値を算出し、合計値が予め設定された基準値を超えた場合には、エラー対応処理を実行する。これにより、
複数の項目において問題がある場合にも一元的に評価することができる。
【００２３】
請求項４に記載の発明によれば、制御手段が、返金先口座の存在情報を金融機関システムから取得し、口座の存在を確認できない場合には、評価値を加算した合計値を算出する。これにより、口座の存在を確認できない場合に問題を検知することができる。
【００２４】
請求項５に記載の発明によれば、制御手段が、返金先口座と仕向金融機関情報とが不一致の場合には、評価値を加算した合計値を算出する。これにより、仕向金融機関への振込を条件としている場合にも、評価値を用いて返金条件の満足を判定することができる。
【００２５】
請求項６に記載の発明によれば、制御手段が、口座の存在の確認情報において取得した名義人名と第２利用者の利用者の名前とを比較し、不一致の場合には、評価値を加算した合計値を算出する。これにより、本人名義の口座への振込を条件としている場合にも、評価値を用いて返金条件の満足を判定することができる。
【００２６】
請求項７に記載の発明によれば、制御手段が、第１利用者から第２利用者に対する返金情報における返金予定金額が含まれる返金額範囲に対応する評価値を取得し、評価値を加算した合計値を算出する。これにより、返金予定金額に応じて、エラー対応を変更することができる。
【００２７】
請求項８に記載の発明によれば、制御手段が、第２利用者に対して、請求金額と返金金額との相殺希望の有無を確認するためのメッセージを出力する。これにより、請求金額との相殺により返金を行なうことができる。
【００２８】
請求項９に記載の発明によれば、制御手段が、返金期限を過ぎた返金金額情報が残っている場合には、第２利用者に対して通知する。これにより、長期に亘って返金が残っている状態を抑制することができる。
【発明の効果】
【００２９】
本発明によれば、資金の移動を伴う取引において、返金事由が生じた場合に、的確な返金処理を支援することができる。
【図面の簡単な説明】
【００３０】
【図１】本発明の実施形態のシステム概略図。
【図２】本実施形態で用いるデータの説明図であって、（ａ）企業管理データ記憶部、（ｂ）ユーザ管理データ記憶部、（ｃ）請求管理データ記憶部、（ｄ）返金管理データ記憶部に記録されたデータの説明図。
【図３】本実施形態の処理手順の説明図。
【図４】本実施形態の処理手順の説明図。
【図５】本実施形態の処理手順の説明図。
【図６】本実施形態の処理手順の説明図。
【図７】本実施形態の処理手順の説明図。
【図８】本実施形態の処理手順の説明図。
【発明を実施するための形態】
【００３１】
以下、本発明を具体化した一実施形態を、図１〜図８に従って説明する。本実施形態では、ユーザと企業とが取引を行ない、この取引に関する資金を移動させる場合に用いる取引支援システム、取引支援方法及び取引支援プログラムとして説明する。この場合、企業（第１利用者）はユーザ（第２利用者）に対して取引商品を提供し、この取引に関する請求を行なう。一方、ユーザが取引商品を返品した場合には、企業はユーザに対して返金を
行なう。
【００３２】
本実施形態では、ユーザと企業との間の取引を支援するサービスを提供するために、図１に示す取引支援サーバ２０を用いる。この取引支援サーバ２０は、インターネットを介して、クライアント端末１０や企業サーバ３０、金融機関システム４０に接続される。
【００３３】
クライアント端末１０は、企業と取引を行なうユーザが用いるコンピュータ端末である。このクライアント端末１０は、ディスプレイ等から構成された表示部や、キーボードやポインティングデバイス等から構成された入力部を備える。
【００３４】
取引支援サーバ２０は、ユーザと企業との間で行なわれた取引を支援するためのサーバコンピュータである。この取引支援サーバ２０は、ＣＰＵ、ＲＡＭ、ＲＯＭ等から構成された制御手段としての制御部２１、企業管理データ記憶部２２、ユーザ管理データ記憶部２３、請求管理データ記憶部２４、返金管理データ記憶部２５を備えている。ここで、企業管理データ記憶部２２は返金条件情報記憶手段として機能し、ユーザ管理データ記憶部２３は利用者情報記憶手段として機能する。更に、請求管理データ記憶部２４、返金管理データ記憶部２５は、取引情報記憶手段として機能する。
【００３５】
ここで、制御部２１は、後述する処理（企業管理段階、返金管理段階、振込管理段階、期限管理段階等の各処理）を行なう。そして、制御部２１は、図１に示すように、取引支援プログラムにより、企業管理手段２１１、取引情報管理手段２１２、ユーザ認証手段２１３、返金管理手段２１５、振込管理手段２１６、期限管理手段２１７等として機能する。
【００３６】
企業管理手段２１１は、企業サーバ３０や企業の担当者端末からのアクセスに応じて、ログイン認証を行なう。
取引情報管理手段２１２は、企業サーバ３０から取引情報を取得し、請求情報や返金情報を記録する。また、企業の担当者端末からの請求状況の照会や返金状況の照会に応じて請求や返金のステータス情報を提供する。また、企業の担当者端末から、ユーザ管理コードのロック解除の指示を受けた場合には、ユーザ管理コードのロックを解除する。
【００３７】
ユーザ認証手段２１３は、クライアント端末１０からのアクセスに応じて、ユーザ認証を行なう。
返金管理手段２１５は、企業からユーザに対する返金情報を取得する処理を実行する。具体的には、返金管理手段２１５は、各企業によって指定された返金方法に応じて相殺又は振込の管理処理を実行する。
【００３８】
振込管理手段２１６は、返金条件、返金先口座に関する情報を取得し、返金先口座が返金条件を満足するかどうかを判定する処理を実行する。そして、条件を満足する場合、振込管理手段２１６は、返金のための振込処理を実行する。この処理を行なうために、振込管理手段２１６は、金融機関システム４０を利用できる口座確認サービス提供時間帯、振込サービス提供時間帯に関するデータや、各企業の口座識別子に関するデータを保持している。そして、この振込管理手段２１６は、合計値メモリを備えており、返金振込処理において生じたエラーの評価値の合計値を記憶する。
【００３９】
期限管理手段２１７は、ユーザに対する返金を許容する期限を管理する。具体的には、この期限が到来しても返金が未払い状態で残っている場合、期限管理手段２１７は、この返金を行なう企業サーバ３０に通知を行なう。この場合、企業の担当者が状況を確認し、必要に応じて、ユーザに連絡を取る等の措置を行なう。
【００４０】
企業管理データ記憶部２２には、図２（ａ）に示すように、本サービスを利用する各企業についての企業管理レコード２２０が記録される。この企業管理レコード２２０は、企業が取引支援サービスを利用する場合に登録される。この企業管理レコード２２０は、企業管理コード、パスワード、連絡先、返金方法、返金条件、エラー対応種別に関するデータを含んで構成される。
【００４１】
企業管理コードデータ領域には、本サービスを利用する企業を特定するための識別子に関するデータが記録される。
パスワードデータ領域には、この企業を認証するためのパスワードに関するデータが記録される。
【００４２】
連絡先データ領域には、この企業に通知を送信するための連絡先（ここではメールアドレス）に関するデータが記録される。
返金方法データ領域には、この企業からユーザに対して返金を行なう場合の返金方法を特定するためのフラグが記録される。本実施形態においては、「振込」や「相殺」を特定するフラグが記録される。ここで、複数の返金方法フラグが記録されている場合には、ユーザは返金方法を選択することができる。
【００４３】
返金条件データ領域には、返金を許容する場合の条件に関するデータが記録される。例えば、返金条件として、返金先の口座として、ユーザが支払に利用した仕向金融機関の口座に制限されている場合には、仕向金融機関制限フラグが記録される。また、振込先口座の名義人名とユーザ名とが一致が返金条件となっている場合には、振込先名義人制限フラグが記録される。
【００４４】
また、返金条件データ領域には、仕向金融機関不一致や口座存在確認不可、名義人名不一致等の振込について複数の項目（エラー種別）に対応させて、企業によって指定された重み付け値（返金先口座を評価するための評価値）に関するデータが記録される。
【００４５】
更に、返金条件データ領域には、エラー状況に応じて、後述するエラー対応の実施の要否を判定するための基準値（管理レベル値）に関するデータが記録される。
エラー対応種別データ領域には、返金振込処理において生じたエラーの評価値の合計値に応じた対応方法を特定するためのフラグが記録される。本実施形態においては、「企業に通知のみ」又は「ユーザ管理コードロック」のいずれかのフラグが記録される。
【００４６】
ユーザ管理データ記憶部２３には、図２（ｂ）に示すように、本サービスを利用する各ユーザについてのユーザ管理レコード２３０が記録される。このユーザ管理レコード２３０は、取引支援サービスを利用するユーザに関する情報を取得した場合に登録される。このユーザ管理レコード２３０は、ユーザ管理コード、パスワード、ユーザ名、連絡先、仕向金融機関情報、取引停止フラグを含んで構成される。
【００４７】
ユーザ管理コードデータ領域には、各ユーザを特定するための識別子に関するデータが記録される。
パスワードデータ領域には、このユーザを認証するためのパスワードに関するデータが記録される。
【００４８】
ユーザ名データ領域には、このユーザの氏名や名称に関するデータが記録される。
連絡先データ領域には、このユーザに通知を送信するための連絡先（ここではメールアドレス）に関するデータが記録される。
【００４９】
仕向金融機関情報データ領域には、このユーザが請求金額の支払を行なう場合に用いた
仕向金融機関に関するデータが記録される。本実施形態では、仕向金融機関の金融機関コードや本支店コードに関するデータが記録される。この仕向金融機関情報は、ユーザの支払毎に更新される。
【００５０】
取引停止フラグデータ領域には、このユーザとの取引の可否を判定するためのフラグが記録される。本実施形態では、このデータ領域に取引停止フラグが記録されている場合、このユーザに対する返金を停止する。
【００５１】
請求管理データ記憶部２４には、図２（ｃ）に示すように、企業からユーザに対して行なわれる請求についての請求管理レコード２４０が記録される。この請求管理レコード２４０は、企業サーバ３０から請求情報を取得した場合に登録される。この請求管理レコード２４０は、企業管理コード、ユーザ管理コード、取引管理コード、請求金額、入金ステータスに関するデータを含んで構成される。
【００５２】
企業管理コードデータ領域には、請求企業を特定するための識別子に関するデータが記録される。
ユーザ管理コードデータ領域には、請求先であるユーザを特定するための識別子に関するデータが記録される。
【００５３】
取引管理コードデータ領域には、各取引を特定するための識別子に関するデータが記録される。
請求金額データ領域には、企業からユーザに対する請求の金額に関するデータが記録される。
【００５４】
入金ステータスデータ領域には、この請求についての支払状況を特定するためのフラグが記録される。本実施形態では、このデータ領域には、「未入金」、「入金済」、「返金」を特定するフラグが記録される。
【００５５】
返金管理データ記憶部２５には、図２（ｄ）に示すように、企業からユーザに対して支払われる返金についての返金管理レコード２５０が記録される。この返金管理レコード２５０は、企業サーバ３０から返金情報を取得した場合に登録される。この返金管理レコード２５０は、企業管理コード、ユーザ管理コード、返金予定金額、期限、振込先口座、返金ステータスに関するデータを含んで構成される。
【００５６】
企業管理コードデータ領域には、返金を行なう請求企業を特定するための識別子に関するデータが記録される。
ユーザ管理コードデータ領域には、返金を受けるユーザを特定するための識別子に関するデータが記録される。
【００５７】
返金予定金額データ領域には、このユーザに対して支払われる返金金額に関するデータが記録される。
期限データ領域には、返金を許容する期限に関するデータが記録される。このデータ領域には、返品を確認してから所定期間後の年月日が設定される。
【００５８】
振込先口座データ領域には、返金先の口座を特定するための振込先口座識別子（金融機関コード、本支店コード、預金種目、口座番号等）や口座名義人情報に関するデータが記録される。
【００５９】
返金ステータスデータ領域には、この返金についての支払状況を特定するためのフラグが記録される。本実施形態では、このデータ領域には、「未返金」、「返金済」、「返金
済（エラー）」の各状況を特定するフラグが記録される。「未返金」フラグは、未だ返金されていないことを示す。「返金済」フラグは、エラーが発生することなく返金されたことを示し、「返金済（エラー）」フラグは、一部にエラーが発生したが返金されたことを示す。
【００６０】
企業サーバ３０は、企業において、ユーザとの間で行なわれる取引を管理するためのサーバコンピュータである。この企業サーバ３０は、顧客管理データ記憶部、商品管理データ記憶部、取引管理データ記憶部を備える。
【００６１】
顧客管理データ記憶部には、この企業と取引を行なうユーザを管理するための顧客管理レコードが記憶されている。この顧客管理レコードは、この企業と取引を行なうユーザのユーザ管理コード及びパスワードに関するデータを含んで構成される。
【００６２】
ユーザ管理コードデータ領域には、この企業と取引を行なう各ユーザを特定するための識別子に関するデータが記録される。
パスワードデータ領域には、このユーザを認証するためのパスワードに関するデータが記録される。
【００６３】
商品管理データ記憶部には、この企業が販売する商品を管理するための商品管理レコードが記憶されている。この商品管理レコードは、取引対象となる商品の商品管理コードや商品価格に関するデータを含んで構成される。
【００６４】
商品管理コードデータ領域には、各商品を特定するための識別子に関するデータが記録される。
商品価格データ領域には、この商品の販売価格に関するデータが記録される。
【００６５】
取引管理データ記憶部には、この企業と顧客との取引を管理するための取引管理レコードが記憶される。この取引管理レコードは、取引管理コード、商品管理コード、ユーザ管理コード、請求金額、取引ステータスに関するデータを含んで構成される。
【００６６】
取引管理コードデータ領域には、各取引を特定するための識別子に関するデータが記録される。
商品管理コードデータ領域には、この取引において取引対象の商品を特定するための識別子に関するデータが記録される。
【００６７】
ユーザ管理コードデータ領域には、この取引を行なったユーザを特定するための識別子に関するデータが記録される。
請求金額データ領域には、この取引において、ユーザに対して請求を行なった金額に関するデータが記録される。
【００６８】
取引ステータスデータ領域には、この取引の状況を特定するためのフラグが記録される。本実施形態では、このデータ領域には、「未入金」、「入金済」、「返品受付」、「返品確認」を特定するフラグが記録される。
【００６９】
金融機関システム４０は、各金融機関において開設された口座の口座名義人や口座残高に関するデータを管理する金融機関のコンピュータシステムである。この金融機関システム４０は、預金口座データベースを備えている。この預金口座データベースには、金融機関において開設された預金口座に関しての口座データが記録されている。この口座データは、金融機関に口座が開設された場合に登録される。口座データは、口座識別子、口座名義人情報、口座残高等に関するデータを含んで構成されている。
【００７０】
口座識別子データ領域には、開設された口座を特定するための識別子（金融機関コード、本支店コード、預金種目、口座番号等）に関するデータが記録されている。
口座名義人データ領域には、この口座に関する口座名義人（口座名義人名や顧客コード等）を特定するためのデータが記録されている。
口座残高データ領域には、この口座の残高を特定するためのデータが記録されている。
【００７１】
上記のように構成されたシステムを用いて、ユーザと企業との間で行なわれた取引についての資金移動を支援する場合の処理手順について、図３〜図８を用いて説明する。
【００７２】
（請求処理）
まず、図３を用いて、ユーザが購入した商品についての請求処理を説明する。
ここでは、クライアント端末１０は、企業サーバ３０に対してアクセス処理を実行する（ステップＳ１−１）。具体的には、商品を購入する場合、ユーザはクライアント端末１０を用いて企業サーバ３０にアクセスする。
【００７３】
次に、企業サーバ３０は、ユーザ認証処理を実行する（ステップＳ１−２）。具体的には、企業サーバ３０は、クライアント端末１０に対して、ユーザ認証画面を提供する。このユーザ認証画面には、ユーザ管理コード及びパスワードの入力欄や送信実行アイコンが設けられている。ここで、ユーザは、ユーザ管理コード及びパスワードを入力欄に設定し、送信実行アイコンを選択する。この場合、クライアント端末１０は、ユーザ管理コード及びパスワードを含めたログイン要求を企業サーバ３０に送信する。
【００７４】
ログイン要求を受信した企業サーバ３０は、取得したユーザ管理コード及びパスワードを用いて、ユーザ認証を行なう。ユーザ認証を完了した場合、企業サーバ３０は、取引管理データ記憶部において、このユーザ管理コードが記録されている取引管理レコードを検索する。そして、取引ステータスとして「返品確認」が記録された取引管理レコードの有無を判定する。ここでは、「返品確認」が記録された取引管理レコードがない場合、企業サーバ３０は、通常のメニュー画面をクライアント端末１０に送信する。このメニュー画面においては、商品カタログアイコンや返品依頼アイコンが設けられている。
【００７５】
次に、クライアント端末１０は、取引依頼を企業サーバ３０に送信する（ステップＳ１−３）。ここで、商品の購入を希望する場合には、商品購入アイコンを選択する。この場合、クライアント端末１０は、商品カタログ要求を企業サーバ３０に送信する。
【００７６】
次に、クライアント端末１０及び企業サーバ３０は、取引処理を実行する。具体的には、商品カタログ要求を受信した企業サーバ３０は、商品管理データ記憶部に記憶された商品についての商品カタログ画面をクライアント端末１０に提供する。この商品カタログ画面には、各商品を選択するために、商品管理コードが設定された商品アイコンが設けられている。ユーザは、クライアント端末１０のディスプレイに表示された商品カタログ画面を確認し、所望の商品の商品アイコンを選択する。この場合、クライアント端末１０は、商品購入の取引要求を企業サーバ３０に送信する。この取引要求には、購入対象の商品管理コードを含める。
【００７７】
次に、企業サーバ３０は、取引受付処理を実行する（ステップＳ１−４）。具体的には、取引要求を受信した企業サーバ３０は、購入対象の商品管理コードに関連付けられた商品価格に基いて請求金額を算出する。そして、企業サーバ３０は、この取引要求に対して、取引管理コードを付与し、取引管理コード、商品管理コード、ユーザ管理コード、請求金額を記録した取引管理レコードを生成する。
【００７８】
更に、企業サーバ３０は、請求情報登録処理を実行する（ステップＳ１−５）。具体的には、企業サーバ３０は、請求情報を取引支援サーバ２０に提供する。この請求情報には、企業管理コード、パスワード、ユーザ管理コード、取引管理コード及び請求金額に関するデータを含める。更に、企業サーバ３０は、クライアント端末１０に対して、商品代金（請求金額）の支払要求についてのメッセージを出力する。このメッセージには、入金時に用いる取引管理コードを含める。
【００７９】
次に、取引支援サーバ２０の制御部２１は、請求情報の蓄積処理を実行する（ステップＳ１−６）。具体的には、制御部２１の企業管理手段２１１は、取得した企業管理コード及びパスワードを用いてログイン認証を実行する。ログイン認証を完了した場合、取引情報管理手段２１２は、請求情報に含まれる企業管理コード、ユーザ管理コード、取引管理コード及び請求金額に関するデータを含めた請求管理レコード２４０を生成し、請求管理データ記憶部２４に登録する。この段階では、取引情報管理手段２１２は、この請求管理レコード２４０の入金ステータスとして「未入金」フラグを記録する。
【００８０】
そして、ユーザは支払処理を実行する（ステップＳ１−７）。本実施形態においては、クライアント端末１０を用いて金融機関システム４０にアクセスし、取引を行なった企業の口座に対して、商品代金の振込処理を行なう。この場合、企業サーバ３０から取得した取引管理コードを設定して振込処理を行なう。
【００８１】
次に、企業サーバ３０は、入金確認処理を実行する（ステップＳ１−８）。具体的には、企業サーバ３０は、金融機関システム４０に定期的にアクセスする。そして、企業サーバ３０は、企業口座への入金を確認する。入金を確認した企業サーバ３０は、入金情報に含まれる取引管理コードを特定する。そして、企業サーバ３０は、取得した取引管理コードが記録された取引管理レコードに「入金済」フラグを記録する。次に、企業サーバ３０は、特定した取引管理コードの購入商品をユーザに発送する指示を出力する。
【００８２】
次に、企業サーバ３０は、入金情報登録処理を実行する（ステップＳ１−９）。具体的には、企業サーバ３０は、取引支援サーバ２０に対して入金情報を提供する。この入金情報には、企業管理コード、パスワード、特定した取引管理コード、支払に用いられた仕向金融機関情報に関するデータを含める。
【００８３】
この場合、取引支援サーバ２０は、入金情報の蓄積処理を実行する（ステップＳ１−１０）。具体的には、制御部２１の企業管理手段２１１は、取得した企業管理コード及びパスワード及び企業管理データ記憶部２２を用いてログイン認証を実行する。ログイン認証を完了した場合、取引情報管理手段２１２は、取得した取引管理コードが記録された請求管理レコード２４０を、請求管理データ記憶部２４から抽出する。そして、取引情報管理手段２１２は、この請求管理レコード２４０の入金ステータスとして「入金済」フラグを記録する。更に、取引情報管理手段２１２は、仕向金融機関情報を、このユーザのユーザ管理レコード２３０に記録する。
【００８４】
（返金手続）
次に、購入商品を取得したユーザが、商品を返品する場合の返金手続を説明する。この場合には、企業はユーザから取得した商品代金を返金する。
【００８５】
まず、ステップＳ１−１と同様に、クライアント端末１０は、企業サーバ３０に対してアクセス処理を実行する（ステップＳ２−１）。そして、ステップＳ１−２と同様に、企業サーバ３０は、ユーザ認証処理を実行する（ステップＳ２−２）。ユーザ認証を完了した場合、企業サーバ３０は、メニュー画面をクライアント端末１０に送信する。このメニュー画面においては、商品カタログアイコンや返品依頼アイコンが設けられている。
【００８６】
次に、クライアント端末１０を用いて、返品依頼処理を実行する（ステップＳ２−３）。ここで、商品の返品を希望する場合には、返品依頼アイコンを選択する。この場合、クライアント端末１０は、返品手続要求を企業サーバ３０に送信する。
【００８７】
この場合、企業サーバ３０は、返品依頼受付処理を実行する（ステップＳ２−４）。具体的には、企業サーバ３０は、取引管理データ記憶部から、このユーザが購入した商品の中で、返品可能な商品を特定する。そして、企業サーバ３０は、返品可能な商品についての返品画面をクライアント端末１０に提供する。この返品画面には、返品対象の取引を選択するために、取引管理コードが設定された商品アイコンが設けられている。ユーザは、クライアント端末１０のディスプレイに表示された返品画面を確認し、所望の商品の商品アイコンを選択する。この場合、クライアント端末１０は、返品特定情報を企業サーバ３０に送信する。この返品特定情報には、返品対象の取引管理コードを含める。
【００８８】
そして、ユーザは商品の返品を行なう（ステップＳ２−５）。具体的には、ユーザは企業に対して、購入商品を返送する。そして、企業においては、返品された商品の確認を行なう（ステップＳ２−６）。具体的には、返品された商品を確認した企業の担当者は、企業サーバ３０の取引管理データ記憶部に記録された取引管理レコードを特定し、取引ステータスとして「返品確認」を設定する。
【００８９】
この場合、企業サーバ３０は、返金情報登録処理を実行する（ステップＳ２−７）。具体的には、企業サーバ３０は、返金情報を取引支援サーバ２０に送信する。この返金情報には、企業管理コード、パスワード、返品が行なわれた取引管理コードに関するデータを含める。
【００９０】
次に、取引支援サーバ２０の制御部２１は、返金情報の蓄積処理を実行する（ステップＳ２−８）。具体的には、制御部２１の企業管理手段２１１は、取得した企業管理コード及びパスワードを用いてログイン認証を実行する。ログイン認証を完了した場合、取引情報管理手段２１２は、請求管理データ記憶部２４から、取引管理コードが記録された請求管理レコード２４０を抽出する。そして、取引情報管理手段２１２は、請求管理レコード２４０の入金ステータスに「返金」フラグを記録する。更に、取引情報管理手段２１２は、企業管理コード、ユーザ管理コード、返金予定金額に関するデータを含めた返金管理レコード２５０を生成し、返金管理データ記憶部２５に登録する。更に、取引情報管理手段２１２は、現在日付に予め定められた返金期間を加算した期限を算出し、この返金管理レコード２５０の期限データ領域に記録する。また、この段階では、返金ステータスデータ領域には、「未返金」フラグを記録する。
【００９１】
（再度のアクセス処理）
次に、ユーザが再度、企業サーバ３０にアクセスした場合の処理を、図４を用いて説明する。
【００９２】
まず、ステップＳ１−１と同様に、クライアント端末１０は、企業サーバ３０に対してアクセス処理を実行する（ステップＳ３−１）。そして、ステップＳ１−２と同様に、企業サーバ３０は、ユーザ認証処理を実行する（ステップＳ３−２）。ユーザ認証を完了した場合、企業サーバ３０は、取引管理データ記憶部において、このユーザ管理コードが記録されている取引管理レコードを検索する。そして、取引ステータスとして「返品確認」が記録された取引管理レコードの有無を判定する。ここで、「返品確認」が記録された取引管理レコードがある場合、企業サーバ３０は、返金情報の取得処理を実行する（ステップＳ３−３）。具体的には、企業サーバ３０は、「返品確認」が記録された取引管理レコードから、取引管理コードや商品管理コードを取得する。
【００９３】
そして、企業サーバ３０は、返金案内画面の出力処理を実行する（ステップＳ３−４）。具体的には、企業サーバ３０は、クライアント端末１０に送信するメニュー画面に、返金があることを示すメッセージを含めた返金案内画面を生成する。このメッセージには、取引管理レコードから取得した取引管理コードや商品管理コードを含めるとともに、取引支援サーバ２０にアクセスするためのリンクアイコンを含める。そして、企業サーバ３０は、クライアント端末１０のディスプレイに返金案内画面を送信する。
【００９４】
次に、クライアント端末１０は、リンク処理を実行する（ステップＳ３−５）。具体的には、ユーザが返金を受ける場合、クライアント端末１０のディスプレイに表示された返金案内画面に含まれるリンクアイコンを選択する。この場合、クライアント端末１０は、取引支援サーバ２０に返金依頼を送信する。
そして、取引支援サーバ２０は、後述する返金処理を実行する（ステップＳ３−６）。
【００９５】
（返金処理）
次に、取引支援サーバ２０における返金処理を、図５を用いて説明する。
【００９６】
取引支援サーバ２０の制御部２１は、ユーザ認証処理を実行する（ステップＳ４−１）。具体的には、制御部２１のユーザ認証手段２１３は、クライアント端末１０に対してユーザ認証画面を提供する。このユーザ認証画面には、ユーザ管理コードの入力欄を含める。この入力欄にユーザ管理コードが設定された場合、クライアント端末１０は、ユーザ管理コードを取引支援サーバ２０に送信する。
【００９７】
この場合、ユーザ認証手段２１３は、取得したユーザ管理コードやパスワードが、ユーザ管理データ記憶部に記録されているかどうかを判定する。取得したユーザ管理コードやパスワードが記録されているユーザ管理レコード２３０を抽出できた場合、ユーザ認証手段２１３は、このユーザ管理レコード２３０に取引停止フラグが記録されていないかどうかを確認する。取引停止フラグが記録されている場合には、このユーザのアクセスを拒否する。
【００９８】
次に、取引支援サーバ２０の制御部２１は、返金情報の抽出処理を実行する（ステップＳ４−２）。具体的には、制御部２１の返金管理手段２１５は、返金管理データ記憶部２５から、取得したユーザ管理コードが記録された返金管理レコード２５０であって、返金ステータスデータ領域に「未返金」フラグが記録されたレコードを取得する。
【００９９】
次に、取引支援サーバ２０の制御部２１は、企業指定の返金方法の特定処理を実行する（ステップＳ４−３）。具体的には、制御部２１の返金管理手段２１５は、返金管理レコード２５０に記録された企業管理コードを特定し、この企業管理コードが記録された企業管理レコード２２０を企業管理データ記憶部２２から取得する。そして、企業管理レコード２２０に記録された返金方法データ領域に記録されたフラグに基づいて特定する。
【０１００】
次に、取引支援サーバ２０の制御部２１は、返金方法を選択できるかどうかについての判定処理を実行する（ステップＳ４−４）。具体的には、制御部２１の返金管理手段２１５は、返金方法データ領域に複数の返金方法フラグが記録されているかどうかにより判定する。更に、返金管理手段２１５は、請求管理データ記憶部２４から、企業管理コード及びユーザ管理コードが記録された請求管理レコード２４０を抽出する。そして、返金管理手段２１５は、「未入金」フラグが記録されている請求管理レコード２４０の有無を判定する。
【０１０１】
企業管理レコード２２０において複数の返金方法フラグが記録されており、このユーザ
について未入金の請求管理レコード２４０を抽出した場合には、相殺又は振込を選択することができる。一方、この企業管理レコード２２０において唯一の返金方法が定められている場合や、相殺対象となる未入金の請求管理レコード２４０を抽出できない場合には、返金方法は選択できない。未入金の請求管理レコード２４０がない場合には、振込による返金のみとなる。
【０１０２】
返金方法を選択できる場合（ステップＳ４−４において「ＹＥＳ」の場合）には、取引支援サーバ２０の制御部２１は、返金方法の選択画面の出力処理を実行する（ステップＳ４−５）。具体的には、制御部２１の返金管理手段２１５は、クライアント端末１０のディスプレイに返金方法の選択画面を出力する。この選択画面においては、相殺又は振込を選択するためのラジオボタンが設けられている。そして、返金管理手段２１５は、この選択画面において選択された返金方法を取得する。
【０１０３】
一方、返金方法が選択できない場合（ステップＳ４−４において「ＮＯ」の場合）には、取引支援サーバ２０の制御部２１は、返金方法の特定処理を実行する（ステップＳ４−６）。具体的には、制御部２１の返金管理手段２１５は、クライアント端末１０のディスプレイに特定された返金方法により返金を行なうことを示したメッセージを出力する。
【０１０４】
次に、取引支援サーバ２０の制御部２１は、振込又は相殺の判定処理を実行する（ステップＳ４−７）。具体的には、制御部２１の返金管理手段２１５は、先のステップで選択又は特定された返金方法を特定する。
【０１０５】
振込による返金が選択又は特定されている場合（ステップＳ４−７において「振込」の場合）、取引支援サーバ２０の制御部２１は、後述する返金振込処理を実行する（ステップＳ４−８）。
【０１０６】
一方、相殺による返金が選択又は特定されている場合（ステップＳ４−７において「相殺」の場合）、取引支援サーバ２０の制御部２１は、請求金額が返金予定金額以上かどうかについての判定処理を実行する（ステップＳ４−９）。具体的には、制御部２１の返金管理手段２１５は、請求管理レコード２４０に記録された請求金額と、返金管理レコード２５０に記録された返金予定金額とを比較する。
【０１０７】
請求金額が返金予定金額以上の場合（ステップＳ４−９において「ＹＥＳ」の場合）、取引支援サーバ２０の制御部２１は、相殺後の請求額の算出処理を実行する（ステップＳ４−１０）。具体的には、制御部２１の返金管理手段２１５は、請求金額から返金予定金額を差し引いた残金額を算出する。そして、返金管理手段２１５は、この残金額を用いて、請求管理レコード２４０の請求金額を更新する。更に、返金管理手段２１５は、返金管理レコード２５０の返金ステータスデータ領域に「返金済」フラグを記録する。
【０１０８】
次に、取引支援サーバ２０の制御部２１は、相殺後請求額の出力処理を実行する（ステップＳ４−１１）。具体的には、制御部２１の返金管理手段２１５は、クライアント端末１０のディスプレイに、内容確認画面を出力する。この内容確認画面には、相殺後の請求金額に関する情報を含める。
【０１０９】
一方、返金予定金額が請求金額未満の場合（ステップＳ４−９において「ＮＯ」の場合）、取引支援サーバ２０の制御部２１は、返金予定金額の更新処理を実行する（ステップＳ４−１２）。具体的には、制御部２１の返金管理手段２１５は、返金予定金額から請求金額を差し引いた残金額を用いて、返金管理レコード２５０の返金予定金額を更新する。
【０１１０】
次に、取引支援サーバ２０の制御部２１は、相殺内容の確認処理を実行する（ステップ
Ｓ４−１３）。具体的には、制御部２１の返金管理手段２１５は、返金予定金額情報画面を、クライアント端末１０のディスプレイに出力する。この返金予定金額情報画面には、残っている返金予定金額に関する情報を含める。そして、残っている返金予定金額について、ステップＳ４−４以降の処理を繰り返す。
【０１１１】
（返金振込処理）
次に、図６を用いて、返金振込処理（ステップＳ４−８）を説明する。
ここでは、取引支援サーバ２０の制御部２１は、企業管理データの取得処理を実行する（ステップＳ５−１）。具体的には、制御部２１の振込管理手段２１６は、企業管理データ記憶部２２に記録されている返金条件及びエラー対応種別に関するデータを取得する。
【０１１２】
次に、取引支援サーバ２０の制御部２１は、振込先設定画面の出力処理を実行する（ステップＳ５−２）。具体的には、制御部２１の振込管理手段２１６は、クライアント端末１０のディスプレイに振込先設定画面を出力する。この振込先設定画面においては、返金金額の振込先である預金口座を設定するための入力欄や送信実行アイコンが設けられている。
【０１１３】
次に、取引支援サーバ２０の制御部２１は、振込先情報の取得処理を実行する（ステップＳ５−３）。具体的には、ユーザは、入金先の預金口座情報を設定し、送信アイコンを選択する。この場合、クライアント端末１０は、設定された預金口座情報を取引支援サーバ２０に送信する。そして、制御部２１の振込管理手段２１６は、クライアント端末１０から振込先の預金口座情報を取得する。
【０１１４】
次に、取引支援サーバ２０の制御部２１は、金融機関の制限があるかどうかについての判定処理を実行する（ステップＳ５−４）。具体的には、制御部２１の振込管理手段２１６は、企業管理レコード２２０において、仕向金融機関への振込が返金条件になっているかどうかについて判定する。
【０１１５】
企業管理レコード２２０に仕向金融機関制限フラグが記録されており、振込先が仕向金融機関に制限されている場合（ステップＳ５−４において「ＹＥＳ」の場合）、取引支援サーバ２０の制御部２１は、仕向金融機関情報の取得処理を実行する（ステップＳ５−５）。具体的には、制御部２１の振込管理手段２１６は、ユーザ管理レコード２３０に記録された仕向金融機関情報を取得する。
【０１１６】
そして、取引支援サーバ２０の制御部２１は、振込先が仕向金融機関と一致しているかどうかについての判定処理を実行する（ステップＳ５−６）。具体的には、制御部２１の振込管理手段２１６は、振込先口座の口座情報と仕向金融機関情報とを比較する。本実施形態では、金融機関コード、本支店コードの一致を確認する。
【０１１７】
振込先口座情報と仕向金融機関情報とが一致していない場合（ステップＳ５−６において「ＮＯ」の場合）、取引支援サーバ２０の制御部２１は、評価値の加算処理を実行する（ステップＳ５−７）。具体的には、制御部２１の振込管理手段２１６は、この企業の企業管理レコード２２０から、「仕向金融機関不一致」に対応する評価値を取得する。そして、振込管理手段２１６は、合計値メモリに、この評価値を加算する。
【０１１８】
一方、仕向金融機関についての制限がない場合（ステップＳ５−４において「ＮＯ」の場合）や、振込先口座情報と仕向金融機関情報とが一致する場合（ステップＳ５−６において「ＹＥＳ」の場合）には、ステップＳ５−７の処理をスキップする。
【０１１９】
次に、取引支援サーバ２０の制御部２１は、口座確認サービス提供時間内かどうかにつ
いての判定処理を実行する（ステップＳ５−８）。具体的には、制御部２１の振込管理手段２１６は、システムタイマから現在日時を取得する。そして、この日時と金融機関システム４０において提供されている口座確認サービス提供時間帯とを比較する。
【０１２０】
口座確認サービス提供時間内でない場合（ステップＳ５−８において「ＮＯ」の場合）、後述する受付メールの送信処理（ステップＳ６−１５）を実行する。
一方、口座確認サービス提供時間内の場合（ステップＳ５−８において「ＹＥＳ」の場合）、取引支援サーバ２０の制御部２１は、口座存在チェック処理を実行する（ステップＳ５−９）。具体的には、制御部２１の振込管理手段２１６は、金融機関システム４０にアクセスする。そして、振込管理手段２１６は、金融機関システム４０に口座の存在確認依頼を送信する。この確認依頼には、クライアント端末１０から取得した振込先口座情報を含める。
【０１２１】
次に、図７に示すように、取引支援サーバ２０の制御部２１は、エラーかどうかについての判定処理を実行する（ステップＳ６−１）。具体的には、制御部２１の振込管理手段２１６は、金融機関システム４０から取得した口座存在確認結果に基づいて、この口座が存在するかどうかを判定する。
【０１２２】
口座存在確認結果において口座の存在を確認できず、エラーとなった場合（ステップＳ６−１において「ＹＥＳ」の場合）、取引支援サーバ２０の制御部２１は、評価値の加算処理を実行する（ステップＳ６−２）。具体的には、制御部２１の振込管理手段２１６は、この企業の企業管理レコード２２０から、「口座存在確認不可」に対応する評価値を取得する。そして、振込管理手段２１６は、合計値メモリに、この評価値を加算する。
【０１２３】
口座存在確認結果において口座の存在を確認でき、エラーとならなかった場合（ステップＳ６−１において「ＮＯ」の場合）、取引支援サーバ２０の制御部２１は、名義人名チェック処理を実行する（ステップＳ６−３）。具体的には、制御部２１の振込管理手段２１６は、口座存在確認結果において取得した振込先口座の名義人名を特定する。
【０１２４】
次に、取引支援サーバ２０の制御部２１は、名義人名が一致するかどうかについての判定処理を実行する（ステップＳ６−４）。具体的には、制御部２１の振込管理手段２１６は、口座存在確認結果において取得した振込先口座の名義人名と、ユーザ管理レコード２３０に記録されたユーザ名とを比較する。
【０１２５】
振込先口座の名義人名とユーザ名とが一致しない場合（ステップＳ６−４において「ＮＯ」の場合）、取引支援サーバ２０の制御部２１は、エラー扱いかどうかについての判定処理を実行する（ステップＳ６−５）。具体的には、制御部２１の振込管理手段２１６は、企業管理レコード２２０の送金条件において、振込先名義人制限フラグが記録されているかどうかにより判定する。
【０１２６】
振込先名義人制限フラグが記録されており、エラー扱いになっている場合（ステップＳ６−５において「ＹＥＳ」の場合）、取引支援サーバ２０の制御部２１は、評価値の加算処理を実行する（ステップＳ６−２）。ここでは、具体的には、制御部２１の振込管理手段２１６は、この企業の企業管理レコード２２０から、「名義人名不一致」に対応する評価値を取得する。そして、振込管理手段２１６は、合計値メモリに、この評価値を加算する。
【０１２７】
そして、取引支援サーバ２０の制御部２１は、評価値の合計値が管理レベル値を超えたかどうかについての判定処理を実行する（ステップＳ６−６）。具体的には、制御部２１の振込管理手段２１６は、企業管理レコード２２０に記録された管理レベル値を取得する
。そして、振込管理手段２１６は、合計値メモリに記録された値と、企業管理レコード２２０に記録された管理レベル値とを比較する。
【０１２８】
合計値が管理レベル値以下の場合（ステップＳ６−６において「ＮＯ」の場合）、取引支援サーバ２０の制御部２１は、振込先設定画面の出力処理（ステップＳ５−２）から繰り返す。一方、合計値が管理レベル値を超えた場合（ステップＳ６−６において「ＹＥＳ」の場合）、取引支援サーバ２０の制御部２１は、エラー対応種別の取得処理を実行する（ステップＳ６−７）。具体的には、制御部２１の振込管理手段２１６は、企業管理レコード２２０に記録されたエラー対応種別を取得する。
【０１２９】
次に、取引支援サーバ２０の制御部２１は、取引停止かどうかについての判定処理を実行する（ステップＳ６−８）。具体的には、制御部２１の振込管理手段２１６は、取得したエラー対応種別に「取引停止」フラグが記録の有無に基づいて判定する。
【０１３０】
エラー対応種別として「取引停止」フラグが記録されており、取引停止が必要である場合（ステップＳ６−８において「ＹＥＳ」の場合）、取引支援サーバ２０の制御部２１は、ユーザ管理コードのロック処理を実行する（ステップＳ６−９）。具体的には、制御部２１の振込管理手段２１６は、ユーザ管理レコード２３０に取引停止フラグを記録する。そして、企業の担当者は、取引支援サーバ２０にアクセスし、返金管理データ記憶部２５に蓄積された返金管理レコード２５０の取引停止フラグを確認することにより、このユーザについての取引停止状況を把握することができる。
【０１３１】
次に、取引支援サーバ２０の制御部２１は、ユーザ管理コードのロックの連絡処理を実行する（ステップＳ６−１０）。具体的には、制御部２１の振込管理手段２１６は、ユーザ管理データ記憶部２３から、このユーザのメールアドレスを取得する。そして、振込管理手段２１６は、このメールアドレスに対して、ユーザ管理コードをロックしたことを通知する。
【０１３２】
エラー対応種別として「取引停止」フラグが記録されておらず、取引停止が必要でない場合（ステップＳ６−８において「ＮＯ」の場合）、取引支援サーバ２０の制御部２１は、エラー記録処理を実行する（ステップＳ６−１１）。具体的には、制御部２１の振込管理手段２１６は、返金管理レコード２５０の返金ステータスデータ領域に「返金済（エラー）」フラグを記録する。そして、企業の担当者は、取引支援サーバ２０し、返金管理データ記憶部２５に蓄積された返金管理レコード２５０の「返金済（エラー）」フラグを確認することにより、このユーザについてのエラー状況を把握することができる。
【０１３３】
次に、取引支援サーバ２０の制御部２１は、確認画面の出力処理を実行する（ステップＳ６−１２）。具体的には、制御部２１の振込管理手段２１６は、クライアント端末１０に、振込を行なうことを知らせるメッセージを出力する。なお、振込先口座の名義人名とユーザ名とが一致する場合（ステップＳ６−４において「ＹＥＳ」の場合）、振込先名義人制限フラグが記録されておらず、エラー扱いになっていない場合（ステップＳ６−５において「ＮＯ」の場合）も、この確認画面の出力処理を実行する。
【０１３４】
そして、取引支援サーバ２０の制御部２１は、振込サービス提供時間内かどうかについての判定処理を実行する（ステップＳ６−１３）。具体的には、制御部２１の振込管理手段２１６は、現在日時と振込サービス提供時間帯とを比較する。
【０１３５】
現在日時が振込サービス提供時間内の場合（ステップＳ６−１３において「ＹＥＳ」の場合）、取引支援サーバ２０の制御部２１は、振込依頼処理を実行する（ステップＳ６−１４）。具体的には、制御部２１の振込管理手段２１６は、金融機関システム４０に対し
て振込依頼を送信する。この振込依頼には、企業の口座から振込先口座に、返金予定金額を入金する指示を含める。更に、振込管理手段２１６は、返金管理レコード２５０の返金ステータスデータ領域に「返金済」フラグを記録する。
【０１３６】
一方、現在日時が振込サービス提供時間内でない場合（ステップＳ６−１３において「ＮＯ」の場合）、取引支援サーバ２０の制御部２１は、受付メールの送信処理を実行する（ステップＳ６−１５）。具体的には、制御部２１の振込管理手段２１６は、クライアント端末１０に対して、振込サービス提供時間に振込を行なうことを示したメールを送信する。
【０１３７】
次に、取引支援サーバ２０の制御部２１は、振込サービス提供時間内になった場合に振込依頼処理を実行する（ステップＳ６−１６）。この処理を、図８を用いて説明する。
制御部２１の振込管理手段２１６は、ステップＳ５−９と同様に、口座存在チェック処理を実行する（ステップＳ７−１）。この口座存在確認結果において口座の存在を確認でき、エラーとならなかった場合（ステップＳ７−２において「ＮＯ」の場合）、取引支援サーバ２０の制御部２１は、ステップＳ６−３と同様に、名義人名チェック処理を実行する（ステップＳ７−３）。そして、振込先口座の名義人名とユーザ名とが一致する場合（ステップＳ７−４において「ＹＥＳ」の場合）には、振込管理手段２１６は、ステップＳ６−１４と同様に、振込依頼処理を実行する（ステップＳ７−５）。一方、振込先口座の名義人名とユーザ名とが一致しない場合（ステップＳ７−４において「ＮＯ」の場合）には、振込管理手段２１６は、ステップＳ６−５と同様に、エラー扱いかどうかについての判定処理を実行する（ステップＳ７−６）。エラー扱いになっていない場合（ステップＳ７−６において「ＮＯ」の場合）にも、振込依頼処理を実行する（ステップＳ７−５）。
【０１３８】
一方、エラー扱いになっている場合（ステップＳ７−６において「ＹＥＳ」の場合）には、取引支援サーバ２０の制御部２１は、企業管理レコード２２０から、「名義人名不一致」に対応する評価値の取得処理を実行する（ステップＳ７−７）。更に、ステップＳ６−７と同様に、この評価値に対応するエラー対応種別の取得処理を実行する（ステップＳ７−８）。ここで、エラー対応種別として「取引停止」フラグが記録されておらず、取引停止が必要でない場合（ステップＳ７−９において「ＮＯ」の場合）には、振込管理手段２１６は、ステップＳ６−１１，Ｓ６−１４と同様に、エラー記録処理（ステップＳ７−１０）、振込依頼処理（ステップＳ７−５）を実行する。そして、振込依頼を送信した場合には、振込管理手段２１６は、返金管理レコード２５０の返金ステータスデータ領域に「返金済」フラグを記録する。
【０１３９】
一方、口座存在確認結果において口座の存在を確認できず、エラーとなった場合（ステップＳ７−２において「ＹＥＳ」の場合）、取引支援サーバ２０の制御部２１は、振込不能通知処理を実行する（ステップＳ７−１１）。具体的には、制御部２１の振込管理手段２１６は、ユーザ管理データ記憶部２３から、このユーザのメールアドレスを取得し、このメールアドレスに対して、振込ができなかったことを通知する。また、エラー対応種別として「取引停止」フラグが記録されており、取引停止が必要である場合（ステップＳ７−９において「ＹＥＳ」の場合）にも、振込管理手段２１６は、振込不能通知処理を実行する（ステップＳ７−１１）。
【０１４０】
本実施形態によれば、以下のような効果を得ることができる。
（１） 本実施形態においては、企業管理データ記憶部２２には、本サービスを利用する各企業についての企業管理レコード２２０が記録される。この企業管理レコード２２０は、企業管理コード、パスワード、連絡先、返金方法、返金条件、エラー対応種別に関するデータを含んで構成される。そして、取引支援サーバ２０の制御部２１は、企業指定の返金方法の特定処理を実行する（ステップＳ４−３）。返金方法を選択できる場合（ステ
ップＳ４−４において「ＹＥＳ」の場合）には、取引支援サーバ２０の制御部２１は、返金方法の選択画面の出力処理を実行する（ステップＳ４−５）。これにより、企業に応じて返金方法や返金条件を設定することができる。
【０１４１】
（２） 本実施形態においては、取引支援サーバ２０の制御部２１は、振込先情報の取得処理を実行する（ステップＳ５−３）。そして、取引支援サーバ２０の制御部２１は、金融機関の制限があるかどうかについての判定処理を実行する（ステップＳ５−４）。企業管理レコード２２０に仕向金融機関制限フラグが記録されており、振込先が仕向金融機関に制限されている場合（ステップＳ５−４において「ＹＥＳ」の場合）、取引支援サーバ２０の制御部２１は、仕向金融機関情報の取得処理を実行する（ステップＳ５−５）。振込先口座情報と仕向金融機関情報とが一致していない場合（ステップＳ５−６において「ＮＯ」の場合）、取引支援サーバ２０の制御部２１は、評価値の加算処理を実行する（ステップＳ５−７）。これにより、ユーザが支払に用いた口座が開設された金融機関への振込を返金条件として、この条件を評価値により評価し、的確な返金を行なうことができる。
【０１４２】
（３） 本実施形態においては、取引支援サーバ２０の制御部２１は、口座存在チェック処理を実行する（ステップＳ５−９）。口座存在確認結果において口座の存在を確認できず、エラーとなった場合（ステップＳ６−１において「ＹＥＳ」の場合）、取引支援サーバ２０の制御部２１は、評価値の加算処理を実行する（ステップＳ６−２）。これにより、エラー毎に評価値を繰り返して加算するため、評価値の合計値が大きくなる。従って、振込先口座の確認や名義人名チェックにおいて繰り返しエラーとなった場合（ステップＳ６−１，Ｓ６−５において「ＹＥＳ」の場合）、エラー対応処理を実行することができる。
【０１４３】
（４） 本実施形態においては、口座存在確認結果において口座の存在を確認できた場合（ステップＳ６−１において「ＮＯ」の場合）、取引支援サーバ２０の制御部２１は、名義人名チェック処理を実行する（ステップＳ６−３）。振込先口座の名義人名とユーザ名とが一致しない場合（ステップＳ６−４において「ＮＯ」の場合）、取引支援サーバ２０の制御部２１は、エラー扱いかどうかについての判定処理を実行する（ステップＳ６−５）。これにより、支払人と同一人への返金を返金条件として、この条件を評価値により評価し、的確な返金を行なうことができる。
【０１４４】
振込先名義人制限フラグが記録されている場合（ステップＳ６−５において「ＹＥＳ」の場合）、取引支援サーバ２０の制御部２１は、評価値の加算処理を実行する（ステップＳ６−２）。これにより、名義人が異なる場合には、評価値の加算により注意を喚起することができる。
【０１４５】
（５） 本実施形態においては、取引支援サーバ２０の制御部２１は、評価値の合計値が管理レベル値を超えたかどうかについての判定処理を実行する（ステップＳ６−６）。合計値が管理レベル値を超えた場合（ステップＳ６−６において「ＹＥＳ」の場合）、取引支援サーバ２０の制御部２１は、エラー対応種別の取得処理を実行する（ステップＳ６−７）。これにより、企業により多様なエラー対応を実施することができる。
【０１４６】
更に、エラー対応種別として「取引停止」フラグが記録されている場合（ステップＳ６−８において「ＹＥＳ」の場合）、取引支援サーバ２０の制御部２１は、ユーザ管理コードのロック処理を実行する（ステップＳ６−９）。これにより、このユーザに対する返金を停止することができる。
【０１４７】
なお、上記各実施形態は以下のように変更してもよい。
・ 上記実施形態では、取引支援サーバ２０は、請求管理データ記憶部２４、返金管理データ記憶部２５を備えている。請求管理データ記憶部２４には、企業からユーザに対して行なわれる請求についての請求管理レコード２４０が記録される。返金管理データ記憶部２５には、企業からユーザに対して支払われる返金についての返金管理レコード２５０が記録される。そして、返金処理において、取引支援サーバ２０は請求管理レコード２４０や返金管理レコード２５０を利用する。この場合、企業サーバ３０にアクセスして、請求管理レコード２４０や返金管理レコード２５０を個別に取得するようにしてもよい。
【０１４８】
・ 上記実施形態では、企業サーバ３０は、請求情報登録処理（ステップＳ１−５）、入金情報登録処理（ステップＳ１−９）、返金情報登録処理（ステップＳ２−７）を実行する。そして、企業サーバ３０が、取引支援サーバ２０に対して、請求情報や入金情報、返金情報の提供を行なう。これに代えて、企業の担当者が、クライアント端末１０を用いて、取引支援サーバ２０に請求情報や入金情報、返金情報を提供するようにしてもよい。
【０１４９】
・ 上記実施形態では、企業サーバ３０は、入金確認処理を実行する（ステップＳ１−８）。これに代えて、取引支援サーバ２０が金融機関システム４０に定期的にアクセスし、企業の口座への入金を確認するようにしてもよい。そして、入金を確認した取引支援サーバ２０の制御部２１が、入金情報に含まれる取引管理コードを特定し、取引管理コードが記録された請求管理レコード２４０を、請求管理データ記憶部２４から抽出する。これにより、企業サーバ３０の処理負荷を軽減することができる。
【０１５０】
・ 上記実施形態では、返金条件データ領域には、エラー状況に応じて、エラー対応の実施の要否を判定するための管理レベル値に関するデータが記録される。この管理レベル値は、返金予定金額の範囲（返金額範囲）に応じて変更するようにしてもよい。具体的には、返金条件データ領域には、返金予定金額を変数として、管理レベル値を算出するためのテーブルや関数を記憶させておく。これにより、返金予定金額に応じてエラー対応の実施の要否を決定することができる。例えば、返金予定金額が高い場合には慎重な返金処理を実行し、返金予定金額が低い場合には簡易な返金処理を実行することができる。
【符号の説明】
【０１５１】
１０…クライアント端末、２０…取引支援サーバ、２１…制御部、２１１…企業管理手段、２１２…取引情報管理手段、２１３…ユーザ認証手段、２１５…返金管理手段、２１６…振込管理手段、２１７…期限管理手段、２２…企業管理データ記憶部、２３…ユーザ管理データ記憶部、２４…請求管理データ記憶部、２５…返金管理データ記憶部、３０…企業サーバ、４０…金融機関システム。
【特許請求の範囲】
【請求項１】
第１利用者と第２利用者との間で行なわれる取引について、
第２利用者から第１利用者に対して支払われた金額のうち、前記第２利用者に対する返金金額情報を蓄積した取引情報記憶手段と、
第１利用者毎に返金条件を記録した返金条件情報記憶手段と、
金融機関システムに接続される制御手段を備えた取引支援システムであって、
前記制御手段が、
前記第２利用者のクライアント端末からのアクセスを受信した場合、第１利用者から前記第２利用者に対する返金情報を取得する手段と、
前記第１利用者の返金条件を前記返金条件情報記憶手段から取得する手段と、
前記第２利用者のクライアント端末から返金先口座に関する情報を取得する手段と、
前記返金先口座について前記返金条件を満足するかどうか判定し、前記返金条件を満足する場合には、前記返金情報についての振込実行指示を前記金融機関システムに対して送信する手段と
を備えたことを特徴とする取引支援システム。
【請求項２】
前記返金条件情報記憶手段には、返金条件として、返金先口座を評価するための評価値が記録されており、
前記制御手段が、
前記第２利用者のクライアント端末から返金先口座についての評価値の合計値を算出する手段と、
前記合計値が予め設定された基準値を超えた場合には、エラー対応処理を実行する手段とを更に備えたことを特徴とする請求項１に記載の取引支援システム。
【請求項３】
前記返金条件情報記憶手段に記録された返金条件は、振込について複数の項目から構成されており、
各項目に対して返金条件の満足を評価するための評価値が設定されており、
前記制御手段が、各項目の評価値の合計値を算出し、前記合計値が予め設定された基準値を超えた場合には、エラー対応処理を実行する手段を更に備えたことを特徴とする請求項１又は２に記載の取引支援システム。
【請求項４】
前記返金条件情報記憶手段には、前記返金条件として、口座の存在を確認できない場合の評価値が記録されており、
前記制御手段が、前記返金先口座の存在情報を金融機関システムから取得し、口座の存在を確認できない場合には、前記評価値を加算した合計値を算出することを特徴とする請求項１〜３のいずれか一つに記載の取引支援システム。
【請求項５】
前記取引支援システムは、前記第２利用者が支払に用いた口座がある仕向金融機関情報を記録した利用者情報記憶手段を更に備え、
前記返金条件情報記憶手段には、前記返金条件として、返金先口座と仕向金融機関情報との不一致を評価するための評価値が記録されており、
前記制御手段が、前記返金先口座と仕向金融機関情報とが不一致の場合には、前記評価値を加算した合計値を算出することを特徴とする請求項１〜４のいずれか一つに記載の取引支援システム。
【請求項６】
前記返金条件情報記憶手段には、前記返金条件として、返金先口座の名義人名と第２利用者の名前との不一致を評価するための評価値が記録されており、
前記制御手段が、口座の存在の確認情報において取得した名義人名と前記第２利用者の利用者の名前とを比較し、不一致の場合には、前記評価値を加算した合計値を算出するこ
とを特徴とすることを特徴とする請求項４又は５に記載の取引支援システム。
【請求項７】
前記返金条件情報記憶手段において、前記返金条件として返金額範囲に対応して評価値が記録されており、
前記制御手段が、第１利用者から前記第２利用者に対する返金情報における返金予定金額が含まれる返金額範囲に対応する評価値を取得し、前記評価値を加算した合計値を算出することを特徴とする請求項１〜６のいずれか一つに記載の取引支援システム。
【請求項８】
前記取引情報記憶手段には、第２利用者から第１利用者に対する未入金の請求金額に関する情報が更に記録されており、
前記制御手段が、前記第２利用者に対して、前記請求金額と返金金額との相殺希望の有無を確認するためのメッセージを出力する手段を更に備えたことを特徴とする請求項１〜７のいずれか一つに記載の取引支援システム。
【請求項９】
前記取引情報記憶手段には、返金を許容する返金期限に関する情報が更に記録されており、
前記制御手段が、前記返金期限を過ぎた返金金額情報が残っている場合には、前記第２利用者に対して通知する手段を更に備えたことを特徴とする請求項１〜８のいずれか一つに記載の取引支援システム。
【請求項１０】
第１利用者と第２利用者との間で行なわれる取引について、
第２利用者から第１利用者に対して支払われた金額のうち、前記第２利用者に対する返金金額情報を蓄積した取引情報記憶手段と、
第１利用者毎に返金条件を記録した返金条件情報記憶手段と、
金融機関システムに接続される制御手段を備えた取引支援システムを用いて、取引の支援処理を行なう方法であって、
前記制御手段が、
前記第２利用者のクライアント端末からのアクセスを受信した場合、第１利用者から前記第２利用者に対する返金情報を取得する段階と、
前記第１利用者の返金条件を前記返金条件情報記憶手段から取得する段階と、
前記第２利用者のクライアント端末から返金先口座に関する情報を取得する段階と、
前記返金先口座について前記返金条件を満足するかどうか判定し、前記返金条件を満足する場合には、前記返金情報についての振込実行指示を前記金融機関システムに対して送信する段階と
を実行することを特徴とする取引支援方法。
【請求項１１】
第１利用者と第２利用者との間で行なわれる取引について、
第２利用者から第１利用者に対して支払われた金額のうち、前記第２利用者に対する返金金額情報を蓄積した取引情報記憶手段と、
第１利用者毎に返金条件を記録した返金条件情報記憶手段と、
金融機関システムに接続される制御手段を備えた取引支援システムを用いて、取引の支援処理を行なうプログラムであって、
前記制御手段を、
前記第２利用者のクライアント端末からのアクセスを受信した場合、第１利用者から前記第２利用者に対する返金情報を取得する手段、
前記第１利用者の返金条件を前記返金条件情報記憶手段から取得する手段、
前記第２利用者のクライアント端末から返金先口座に関する情報を取得する手段、
前記返金先口座について前記返金条件を満足するかどうか判定し、前記返金条件を満足する場合には、前記返金情報についての振込実行指示を前記金融機関システムに対して送信する手段
として機能させることを特徴とする取引支援プログラム。
【請求項１】
第１利用者と第２利用者との間で行なわれる取引について、
第２利用者から第１利用者に対して支払われた金額のうち、前記第２利用者に対する返金金額情報を蓄積した取引情報記憶手段と、
第１利用者毎に返金条件を記録した返金条件情報記憶手段と、
金融機関システムに接続される制御手段を備えた取引支援システムであって、
前記制御手段が、
前記第２利用者のクライアント端末からのアクセスを受信した場合、第１利用者から前記第２利用者に対する返金情報を取得する手段と、
前記第１利用者の返金条件を前記返金条件情報記憶手段から取得する手段と、
前記第２利用者のクライアント端末から返金先口座に関する情報を取得する手段と、
前記返金先口座について前記返金条件を満足するかどうか判定し、前記返金条件を満足する場合には、前記返金情報についての振込実行指示を前記金融機関システムに対して送信する手段と
を備えたことを特徴とする取引支援システム。
【請求項２】
前記返金条件情報記憶手段には、返金条件として、返金先口座を評価するための評価値が記録されており、
前記制御手段が、
前記第２利用者のクライアント端末から返金先口座についての評価値の合計値を算出する手段と、
前記合計値が予め設定された基準値を超えた場合には、エラー対応処理を実行する手段とを更に備えたことを特徴とする請求項１に記載の取引支援システム。
【請求項３】
前記返金条件情報記憶手段に記録された返金条件は、振込について複数の項目から構成されており、
各項目に対して返金条件の満足を評価するための評価値が設定されており、
前記制御手段が、各項目の評価値の合計値を算出し、前記合計値が予め設定された基準値を超えた場合には、エラー対応処理を実行する手段を更に備えたことを特徴とする請求項１又は２に記載の取引支援システム。
【請求項４】
前記返金条件情報記憶手段には、前記返金条件として、口座の存在を確認できない場合の評価値が記録されており、
前記制御手段が、前記返金先口座の存在情報を金融機関システムから取得し、口座の存在を確認できない場合には、前記評価値を加算した合計値を算出することを特徴とする請求項１〜３のいずれか一つに記載の取引支援システム。
【請求項５】
前記取引支援システムは、前記第２利用者が支払に用いた口座がある仕向金融機関情報を記録した利用者情報記憶手段を更に備え、
前記返金条件情報記憶手段には、前記返金条件として、返金先口座と仕向金融機関情報との不一致を評価するための評価値が記録されており、
前記制御手段が、前記返金先口座と仕向金融機関情報とが不一致の場合には、前記評価値を加算した合計値を算出することを特徴とする請求項１〜４のいずれか一つに記載の取引支援システム。
【請求項６】
前記返金条件情報記憶手段には、前記返金条件として、返金先口座の名義人名と第２利用者の名前との不一致を評価するための評価値が記録されており、
前記制御手段が、口座の存在の確認情報において取得した名義人名と前記第２利用者の利用者の名前とを比較し、不一致の場合には、前記評価値を加算した合計値を算出するこ
とを特徴とすることを特徴とする請求項４又は５に記載の取引支援システム。
【請求項７】
前記返金条件情報記憶手段において、前記返金条件として返金額範囲に対応して評価値が記録されており、
前記制御手段が、第１利用者から前記第２利用者に対する返金情報における返金予定金額が含まれる返金額範囲に対応する評価値を取得し、前記評価値を加算した合計値を算出することを特徴とする請求項１〜６のいずれか一つに記載の取引支援システム。
【請求項８】
前記取引情報記憶手段には、第２利用者から第１利用者に対する未入金の請求金額に関する情報が更に記録されており、
前記制御手段が、前記第２利用者に対して、前記請求金額と返金金額との相殺希望の有無を確認するためのメッセージを出力する手段を更に備えたことを特徴とする請求項１〜７のいずれか一つに記載の取引支援システム。
【請求項９】
前記取引情報記憶手段には、返金を許容する返金期限に関する情報が更に記録されており、
前記制御手段が、前記返金期限を過ぎた返金金額情報が残っている場合には、前記第２利用者に対して通知する手段を更に備えたことを特徴とする請求項１〜８のいずれか一つに記載の取引支援システム。
【請求項１０】
第１利用者と第２利用者との間で行なわれる取引について、
第２利用者から第１利用者に対して支払われた金額のうち、前記第２利用者に対する返金金額情報を蓄積した取引情報記憶手段と、
第１利用者毎に返金条件を記録した返金条件情報記憶手段と、
金融機関システムに接続される制御手段を備えた取引支援システムを用いて、取引の支援処理を行なう方法であって、
前記制御手段が、
前記第２利用者のクライアント端末からのアクセスを受信した場合、第１利用者から前記第２利用者に対する返金情報を取得する段階と、
前記第１利用者の返金条件を前記返金条件情報記憶手段から取得する段階と、
前記第２利用者のクライアント端末から返金先口座に関する情報を取得する段階と、
前記返金先口座について前記返金条件を満足するかどうか判定し、前記返金条件を満足する場合には、前記返金情報についての振込実行指示を前記金融機関システムに対して送信する段階と
を実行することを特徴とする取引支援方法。
【請求項１１】
第１利用者と第２利用者との間で行なわれる取引について、
第２利用者から第１利用者に対して支払われた金額のうち、前記第２利用者に対する返金金額情報を蓄積した取引情報記憶手段と、
第１利用者毎に返金条件を記録した返金条件情報記憶手段と、
金融機関システムに接続される制御手段を備えた取引支援システムを用いて、取引の支援処理を行なうプログラムであって、
前記制御手段を、
前記第２利用者のクライアント端末からのアクセスを受信した場合、第１利用者から前記第２利用者に対する返金情報を取得する手段、
前記第１利用者の返金条件を前記返金条件情報記憶手段から取得する手段、
前記第２利用者のクライアント端末から返金先口座に関する情報を取得する手段、
前記返金先口座について前記返金条件を満足するかどうか判定し、前記返金条件を満足する場合には、前記返金情報についての振込実行指示を前記金融機関システムに対して送信する手段
として機能させることを特徴とする取引支援プログラム。
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図１】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図１】
【公開番号】特開２０１１−３９７１１（Ｐ２０１１−３９７１１Ａ）
【公開日】平成２３年２月２４日（２０１１．２．２４）
【国際特許分類】
【出願番号】特願２００９−１８５２３１（Ｐ２００９−１８５２３１）
【出願日】平成２１年８月７日（２００９．８．７）
【出願人】（５９２１３１９０６）みずほ情報総研株式会社 (187)
【出願人】（５９２２５９９７８）株式会社みずほ銀行 (117)
【公開日】平成２３年２月２４日（２０１１．２．２４）
【国際特許分類】
【出願日】平成２１年８月７日（２００９．８．７）
【出願人】（５９２１３１９０６）みずほ情報総研株式会社 (187)
【出願人】（５９２２５９９７８）株式会社みずほ銀行 (117)
[ Back to top ]