JP7041088B2 - 情報処理装置及びプログラム - Google Patents

Description

本発明は情報処理装置及びプログラムに関する。特に、本発明は、電子記録債権処理に用いられる情報処理装置及びプログラムに関する。

近年、従来の紙媒体による債権に代わり、電子債権記録機関の記録原簿への電子記録をその発生及び譲渡等の要件とする電子記録債権が普及している。電子記録債権では、取引によって電子記録債権が発生したことを電子債権記録機関に知らせ、記録原簿に記録することによって債権が発生する。電子記録債権として、全国銀行協会が提供する電子債権記録機関（以下、「でんさいネット（登録商標）」という）で用いられる電子記録債権（以下、「でんさい」という）が普及している。

でんさいネットにおいて、債務者がでんさいの発生記録請求を行う債務者請求方式と、債権者が「でんさい」の発生記録請求を行う債権者請求方式とがある。債権者請求方式の場合、請求を行う債権者及び対象となる債務者などの情報を債権者が特定して取引先の銀行に債権回収の要求を行い、当該銀行がでんさいネットに対して発生記録請求を行う。この際、でんさいネットに発生記録請求を行う際のフォーマットに規制があるため、でんさいネットの標準フォーマットに準じた形式で発生記録請求を行う必要がある。具体的には、でんさいネットでは、１つの発生記録請求ファイルについて１つのヘッダレコードが指定された形式（シングルヘッダ形式）で発生記録請求を行うことが要求されており、１つのファイルについて複数のヘッダレコードが指定された形式（マルチヘッダ形式）で発生記録請求を行うことはできない。

一方で、債権者が発生記録請求を行う形式がシングルヘッダ形式に限定されると、債権者の作業負担が増し、作業効率が低下するという問題があった。そこで、債権者がマルチヘッダ形式で入力した発生記録請求ファイルをシングルヘッダ形式のファイルに分割してでんさいネットに送信する技術が開示されている（例えば、特許文献１）。

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

しかしながら、特許文献１の電子記録債権処理システムでは、決済口座情報が債務者ごとに固有に割り当てられているため、債権者の代表（例えば、債権者の本社）が一括して全ての債務者を管理しなければならなかった。債務者の管理責任が本社に集中すると、本社における作業負担が増加するため、従来のシステムでは作業の効率化が著しく低下するという問題が生じていた。

本発明の一実施形態は、上記の課題に鑑みてなされたものであって、債務者の管理責任が一部の機関に集中することを抑制し、作業効率の著しい低下を抑制することができるシステムを提供することを課題とする。

本発明の一実施形態にかかる情報処理装置は、第１ユーザによって請求された、マルチヘッダ形式の発生記録請求ファイルを、ヘッダレコード毎に分割する分割部を有し、各々の前記ヘッダレコードは、債務者とは異なる複数の第２ユーザに割り当てられた異なる第１口座の各々の情報を含む。

各々の前記第１口座は、複数の前記第２ユーザのそれぞれに一対一で対応してもよい。

分割された前記発生記録請求ファイルの各々は、１つの前記ヘッダレコードと、それぞれ異なる前記債務者の情報を有する複数のデータレコードとを含んでもよい。

分割された前記発生記録請求ファイルを電子債権記録機関システムに送信する送信部をさらに有してもよい。

前記電子債権記録機関システムからの通知を受信する受信部と、前記通知に基づいて、分割された前記発生記録請求ファイルの各々に含まれる複数の前記データレコードの各々に関連する前記債務者の第２口座から、分割された前記発生記録請求ファイルの各々に含まれる１つの前記ヘッダレコードに関連する前記第１口座の情報に基づいて、前記第１ユーザの第３口座への入金を行う実行部と、をさらに有してもよい。

前記第１口座として、可変的に前記第２ユーザに関連付けられた仮想口座を設定する口座設定部をさらに有してもよい。

前記第１ユーザ以外のユーザが、前記第１口座にアクセスする権限を管理する管理部をさらに有してもよい。

前記第１ユーザは、金融機関の本社であり、前記第２ユーザは、前記金融機関の支社であり、前記支社が、分割された前記発生記録請求ファイルのうち、前記支社に割り当てられた前記第１口座にアクセスする権限を管理する管理部をさらに有してもよい。

本発明の一実施形態にかかるプログラムは、第１ユーザによって請求された、マルチヘッダ形式の発生記録請求ファイルを、ヘッダレコード毎に分割することをコンピュータに実行させるプログラムであって、各々の前記ヘッダレコードは、債務者とは異なる複数の第２ユーザに割り当てられた異なる第１口座の各々の情報を含む。

分割された前記発生記録請求ファイルを電子債権記録機関システムに送信することをコンピュータに実行させてもよい。

前記電子債権記録機関システムからの通知に基づき、分割された前記発生記録請求ファイルの各々に含まれる複数のデータレコードの各々に関連する前記債務者の第２口座から、分割された前記発生記録請求ファイルの各々に含まれる１つの前記ヘッダレコードに関連する前記第１口座の情報に基づいて、前記第１ユーザの第３口座への入金を行うことをコンピュータに実行させてもよい。

本発明の一実施形態によれば、債務者の管理責任が一部の機関に集中することを抑制し、作業効率の著しい低下を抑制することができるシステムを提供することができる。

本発明の一実施形態に係る電子記録債権処理に用いられるシステムの概要を示す図である。 本発明の一実施形態に係る電子記録債権処理システムの特徴を説明するための概念図である。 本発明の一実施形態に係る電子記録債権処理システムに用いられるサーバのハードウェア構成を示す概略図である。 本発明の一実施形態に係る電子記録債権処理システムにおいて銀行のサーバの機能構成を示す概略図である。 本発明の一実施形態に係る電子記録債権処理システムにおいて、でんさいの発生及び決済の動作を示すフローチャートである。 本発明の一実施形態に係る電子記録債権処理システムにおいて、債権者によって作成されたマルチヘッダ形式の発生記録請求ファイルの一例を示す図である。 図６に示す発生記録請求ファイルがシングルヘッダ形式に分割されたファイルの一例を示す図である。 発生記録請求ファイルのヘッダレコードの内容を示す図である。 発生記録請求ファイルのデータレコードの内容を示す図である。 発生記録請求ファイルのトレーラレコードの内容を示す図である。 発生記録請求ファイルのエンドレコードの内容を示す図である。 本発明の一実施形態に係る電子記録債権処理システムで用いられる発生記録請求ファイルの一例を示す図である。 本発明の一実施形態に係る電子記録債権処理システムにおけるアクセス権限の一例を示す図である。 本発明の一実施形態に係る電子記録債権処理システムにおける送金フローの一例を示す図である。 本発明の一実施形態に係る電子記録債権処理システムの特徴を説明するための概念図である。 本発明の一実施形態に係る電子記録債権処理システムにおけるアクセス権限の一例を示す図である。 本発明の一実施形態に係る電子記録債権処理システムの特徴を説明するための概念図である。 本発明の一実施形態に係る電子記録債権処理システムにおけるアクセス権限の一例を示す図である。

以下、図面を参照して本発明の一実施形態における電子記録債権処理システム、並びに、当該システムに用いられる銀行のサーバ、当該システムの動作フロー、及び発生記録請求ファイルの形式について説明する。但し、本発明の一実施形態における電子記録債権処理システムは多くの異なる態様で実施することが可能であり、以下に示す例の記載内容に限定して解釈されない。なお、本実施の形態で参照する図面において、同一部分または同様な機能を有する部分には同一の符号又は同一の符号の後にアルファベットを付し、その繰り返しの説明は省略する。

以下の実施形態では、電子記録債権処理システムに用いられる電子債権記録機関としてでんさいネットを例示し、当該電子債権記録機関において用いられる電子記録債権として「でんさい」を例示するが、この構成に限定されない。例えば、本発明の実施形態は、でんさいネット以外の電子債権記録機関や、「でんさい」以外の電子記録債権が用いられる電子記録債権処理システムに適用することもできる。また、特に技術的な矛盾が生じない限り、異なる実施形態間の技術を組み合わせることができる。

〈第１実施形態〉
図１～図１４を用いて、本発明の第１実施形態に係る電子記録債権処理システム１０、並びに、電子記録債権処理システム１０の一部を構成する銀行サーバ１００、でんさいネットサーバ２００、第１ユーザ３００、第２ユーザ４００、及び債務者５００について説明する。なお、以下の実施形態において、第１ユーザ３００は債権者の本社であり、第２ユーザ４００は債権者の支社である構成を例示する。ただし、本実施形態は上記の構成に限定されない。

［電子記録債権処理システム１０の概要］
図１は、本発明の一実施形態に係る電子記録債権処理に用いられるシステムの概要を示す図である。図１に示すように、本発明に係る電子記録債権処理システム１０は、銀行サーバ１００、でんさいネットサーバ２００、第１ユーザ３００、第２ユーザ４００、及び債務者５００を有する。銀行サーバ１００及びでんさいネットサーバ２００は情報処理装置である。第１ユーザ３００、第２ユーザ４００、及び債務者５００は通信端末である。

銀行サーバ１００は、第１ネットワーク６００を介して第１ユーザ３００、第２ユーザ４００、及び債務者５００と通信可能に接続されている。でんさいネットサーバ２００は、第２ネットワーク６１０を介して銀行サーバ１００と通信可能に接続されている。銀行サーバ１００はデータベース１０１に接続されている。でんさいネットサーバ２００はデータベース２０１に接続されている。

本実施形態において、銀行サーバ１００は、電子記録債権処理システム１０の基本的な機能、つまり、第１ユーザ３００によって作成された発生記録請求ファイルの形式をでんさいネットサーバ２００の標準フォーマットに準じた形式に変換する機能を備えている。詳細は後述するが、第１ユーザ３００によって作成された発生記録請求ファイルの形式は、複数のヘッダレコードを含んだマルチヘッダ形式である（図６参照）。各々のヘッダレコードには、第２ユーザ４００毎に割り当てられた口座情報（第１口座）が含まれている。各々のヘッダレコードに含まれる当該口座情報は、ヘッダレコード毎に異なる。なお、発生記録請求ファイルには、各々のヘッダレコードに対応するデータレコードが含まれている。当該データレコードには、債務者５００の情報が含まれている。

銀行サーバ１００は、上記のように、複数のヘッダレコードを含む発生記録請求ファイルを、ヘッダレコード毎に分割することで、当該発生記録請求ファイルの形式をでんさいネットサーバ２００の標準フォーマットに準じたシングルヘッダ形式に変換する。そして、銀行サーバ１００は、分割された発生記録請求ファイルをでんさいネットサーバ２００に送信する。

でんさいネットサーバ２００は、シングルヘッダ形式に変換された発生記録請求ファイルを銀行サーバ１００から受信し、当該ファイルに記載された発生記録請求の内容に応じて、銀行サーバ１００を介して債務者５００に発生記録請求の通知を行う。また、でんさいネットサーバ２００は、当該発生記録請求に対する債務者５００の諾否に関する情報を債務者５００から受信し、銀行サーバ１００を介して第１ユーザ３００及び第２ユーザ４００に当該諾否の結果を通知する。

本実施形態において、第１ユーザ３００及び第２ユーザ４００は債権者である。第１ユーザ３００は本社としての位置付けにあるユーザである。第２ユーザ４００は、当該本社に対して支社としての位置付けにあるユーザである。換言すると、第１ユーザ３００は第２ユーザ４００を管理するユーザであり、第２ユーザ４００は債務者５００を管理するユーザである。債務者５００は、第１ユーザ３００に対して支払い義務を有する者である。

なお、本実施形態では、第１ユーザ３００が本社であり、第２ユーザ４００が支社である構成を例示したが、この構成に限定されない。例えば、第１ユーザ３００は、少なくとも債務者５００に対する債権者であればよい。又は、第１ユーザ３００及び第２ユーザ４００がそれぞれ債権者の従業員（債権回収業務の担当者）であってもよい。例えば、第１ユーザ３００が統括担当者であり、第２ユーザ４００が各債務者５００に対する営業担当であってもよい。また、第２ユーザ４００は、債務者５００を管理する役割を有するユーザであればよく、債務者でなくてもよい。

データベース１０１は、第１ユーザ３００及び債務者５００のでんさいネットの利用者番号、金融機関コード、支店コード、預金種目、預金口座、及び仮想口座番号を、それぞれ関連付けて保存している。データベース１０１が第２ユーザ４００の上記項目の情報を保存していてもよい。また、データベース１０１は、第２ユーザ４００の利用者番号と第２ユーザ４００が閲覧可能な仮想口座番号とを互いに関連付けて保存している。

データベース２０１は、第１ユーザ３００がでんさいネットサーバ２００に対して行った「でんさい」の発生及び譲渡等の各種記録請求の結果を保存している。

図１では、データベース１０１が銀行サーバ１００に直接接続された構成、及びデータベース２０１がでんさいネットサーバ２００に直接接続された構成を例示したが、この構成に限定されない。例えば、データベース１０１、２０１が直接第２ネットワーク６１０に接続され、銀行サーバ１００とデータベース１０１との間のデータの送受信、及びでんさいネットサーバ２００とデータベース２０１との間のデータの送受信が第２ネットワーク６１０を介して行われていてもよい。

第１ネットワーク６００は、一般的なＷｏｒｌｄ Ｗｉｄｅ Ｗｅｂ（ＷＷＷ）サービスによって提供されるインターネット、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）、又は社内ＬＡＮなどのＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）である。第１ユーザ３００、第２ユーザ４００、及び債務者５００は、第１ネットワーク６００を介して銀行サーバ１００と通信する。

第２ネットワーク６１０は、第１ネットワーク６００とは異なり、銀行サーバ１００及びでんさいネットサーバ２００の専用のネットワークである。つまり、第２ネットワーク６１０は、第１ユーザ３００、第２ユーザ４００、及び債務者５００がアクセスすることができないネットワークである。したがって、でんさいネットサーバ２００と第１ユーザ３００、第２ユーザ４００、及び債務者５００との通信は、全て銀行サーバ１００を介して行われる。

なお、銀行サーバ１００とでんさいネットサーバ２００との通信においてセキュリティが確保されていれば、両者が第１ネットワーク６００を介して接続されていてもよい。ただし、このような場合であっても、第１ユーザ３００、第２ユーザ４００、及び債務者５００は、銀行サーバ１００を介してでんさいネットサーバ２００と通信する。

また、図１では、第１ユーザ３００、第２ユーザ４００、及び債務者５００のそれぞれが同一の銀行サーバ１００と通信をする構成を例示したが、この構成に限定されない。例えば、第１ユーザ３００、第２ユーザ４００、及び債務者５００のそれぞれが異なる銀行サーバと通信を行ってもよい。

上記の情報処理装置は、１つのコンピュータによってその機能が実現されてもよく、複数のコンピュータが協働することでその機能が実現されてもよい。上記の通信端末は、モバイル用の通信端末であってもよく、据え置き型の通信端末であってもよい。

図２は、本発明の一実施形態に係る電子記録債権処理システムの特徴を説明するための概念図である。図２に示すように、第１ユーザ３００は第３口座３０１を有する。なお本実施形態では、第３口座３０１は、銀行サーバ１００が管理する実態のある口座（実口座）である。銀行サーバ１００は複数の第１口座４０１（４０１Ａ、４０１Ｂ、・・・、４０１Ｚ）を有している。複数の第１口座４０１は第３口座３０１に関連付けられている。

複数の第１口座４０１には、それぞれ異なる口座番号が付与されている。具体的には、第１口座４０１Ａ、４０１Ｂ、・・・、４０１Ｚの口座番号には、それぞれ「９９９９００１」、「９９９９００２」、・・・、「９９９９０２６」の口座番号が付与されている。第１口座４０１のそれぞれの口座番号は、各第２ユーザ４００（４００Ａ、４００Ｂ、・・・、４００Ｚ）に対して割り当てられている。つまり、第１口座４０１と第２ユーザ４００とは一対一で対応している。換言すると、第１口座４０１は第２ユーザ４００に対して固有の情報を有している。したがって、第１口座４０１を特定することで、特定された第１口座４０１に関連付けられた第２ユーザ４００を特定することができる。

なお、本実施形態では、第１口座４０１は、第２ユーザ４００の実口座ではなく、第３口座３０１及び第２ユーザ４００に関連付けられた仮想口座であって、第２ユーザ４００を特定可能な仮想口座である。

第２ユーザ４００の各々は、複数の第１口座４０１のうち自らに関連付けられた第１口座４０１にアクセスする権限を有する。換言すると、第１ユーザ３００以外のユーザが、第１口座４０１にアクセスする権限を有する。当該アクセスする権限は、例えば、第２ユーザ４００が第１口座４０１を閲覧する権限又は操作する権限である。当該操作する権限には、例えば、でんさいの譲渡を実行する権限が含まれる。第２ユーザ４００が第１口座４０１を閲覧する権限を有するということは、例えば、第２ユーザ４００Ａが、少なくとも第１口座４０１Ａの情報を見ることができることを意味する。なお、本実施形態では、第２ユーザ４００が、複数の第１口座４０１のうち当該第２ユーザ４００に関連付けられた第１口座４０１のみを閲覧する権限を有する。つまり、第２ユーザ４００Ａは、第１口座４０１Ａの情報を見ることができるが、他の第１口座４０１Ｂ、・・・、４０１Ｚの情報を見ることはできない。

銀行サーバ１００は、第１口座４０１Ａ、第１口座４０１Ｂ、・・・、第１口座４０１Ｚの各々がヘッダレコードに含まれた発生記録請求ファイルであって、複数のシングルヘッダ形式の発生記録請求ファイルをでんさいネットサーバ２００に送信する。当該発生記録請求ファイルにおいて、債務者５００Ａ～５００Ｃに対して指定された口座番号は第１口座４０１Ａであり、債務者５００Ｄ～５００Ｆに対して指定された口座番号は第１口座４０１Ｂであり、債務者５００Ｘ～５００Ｚに対して指定された口座番号は第１口座４０１Ｚである。なお、債務者５００Ａ～５００Ｃは、第２ユーザ４００Ａによって管理される債務者である。債務者５００Ｄ～５００Ｆは、第２ユーザ４００Ｂによって管理される債務者である。債務者５００Ｘ～５００Ｚは、第２ユーザ４００Ｚによって管理される債務者である。換言すると、例えば債務者５００Ａ～５００Ｃは、第２ユーザ４００Ａと直接取引がある債務者である。

でんさいネットサーバ２００が各債務者５００から応諾を示す情報を受信すると、「でんさい」が発生し、支払期日になると「でんさい」の決済が実行される。この「でんさい」の決済に応じて、債務者５００Ａ～５００Ｃの口座（第２口座）から第１口座４０１Ａを介して第３口座３０１に、「でんさい」に基づく入金が行われる。同様に、債務者５００Ｄ～５００Ｆの口座（第２口座）から第１口座４０１Ｂを介して第３口座３０１に、「でんさい」に基づく入金が行われる。同様に、債務者５００Ｘ～５００Ｚの口座（第２口座）から第１口座４０１Ｚを介して第３口座３０１に、「でんさい」に基づく入金が行われる。

詳細は後述するが、本実施形態では、第１口座４０１が仮想口座であるため、債務者５００の口座（第２口座）から、第１口座４０１の情報に基づいて、第３口座３０１に入金される。つまり、「でんさい」の決済は、債務者５００の第２口座から、第２ユーザ４００の実口座を経ることなく、第３口座３０１に入金される口座間送金決済である。

［銀行サーバ１００のハードウェア構成］
本発明の一実施形態に係る電子記録債権処理システムに用いられる銀行サーバのハードウェア構成を示す概略図である。図３に示すように、銀行サーバ１００は、サーバ制御部１０３、サーバ記憶部１０５、およびサーバ通信部１０７を有する。なお、これらの機能部は図３に示す位置に設けられた構成に限定されず、情報処理装置のどこに設けられていてもよい。

サーバ制御部１０３は、中央演算処理装置（ＣＰＵ：Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、当該ＣＰＵに接続されたレジスタやメモリなどの記憶装置を含む。サーバ制御部１０３は、メモリに一時的に記憶されたプログラムをＣＰＵによって実行し、第１ユーザ３００、第２ユーザ４００、及び債務者５００からの各種要請信号に応じて演算処理を行い、これらの通信端末に電子記録債権処理システム１０のサービスを提供する。

サーバ記憶部１０５は大容量のデータを記憶することができる記憶装置である。サーバ記憶部１０５には、演算処理に必要なプログラム及びコンテンツデータなどが記憶されている。サーバ記憶部１０５に記憶されているプログラムは、サーバ制御部１０３によって読み出しされ、サーバ制御部１０３の記憶装置に一時的に記憶される。サーバ記憶部１０５はハードディスクであってもよく、揮発性または不揮発性のメモリであってもよい。なお、上記のサーバ記憶部１０５に記憶される情報は、サーバ記憶部１０５の代わりにデータベース１０１に記憶されてもよい。

サーバ通信部１０７は、外部機器に対してデータを送受信可能に接続することができる制御装置であり、それぞれ第１ネットワーク６００及び第２ネットワーク６１０に対するデータの送受信を制御する。

［銀行サーバ１００の機能構成］
図４は、本発明の一実施形態に係る電子記録債権処理システムにおいて銀行のサーバの機能構成を示す概略図である。図４に示すように、銀行サーバ１００は、分割部１１０、受信部１２０、送信部１３０、実行部１４０、口座設定部１５０、管理部１６０、及び通知部１７０を有する。これらの機能部は、例えばバスを介して互いに通信可能に接続されている。

分割部１１０は、マルチヘッダ形式の発生記録請求ファイルをシングルヘッダ形式の発生記録請求ファイルに分割する。第１ユーザ３００から送られてくるマルチヘッダ形式の発生記録請求ファイルは、複数のヘッダレコードを含んでいる。分割部１１０は、マルチヘッダ形式の発生記録請求ファイルをデータ解析し、ヘッダレコード、データレコード、トレーラレコード、及びエンドレコードを抽出する。詳細は後述するが、ヘッダレコードとトレーラレコードとは一対一で対応しているため、マルチヘッダ形式の発生記録請求ファイルには、ヘッダレコード及びトレーラレコードの対が複数存在する。分割部１１０は、対となるヘッダレコード及びトレーラレコード、並びに、これらのレコードの間のデータレコードを抽出し、当該トレーラレコードの後にエンドレコードを追加することで、新たにシングルヘッダ形式の発生記録請求ファイルを生成する。この動作を順次繰り返すことで、発生記録請求ファイルをマルチヘッダ形式からシングルヘッダ形式に変換する。

受信部１２０は、発生記録請求ファイル受信部１２１及び応諾結果受信部１２３を有する。発生記録請求ファイル受信部１２１は、第１ユーザ３００によって送信された発生記録請求ファイルを受信する。上記のように、発生記録請求ファイル受信部１２１が受信する発生記録請求ファイルは、マルチヘッダ形式の発生記録請求ファイルである。応諾結果受信部１２３は、でんさいネットサーバ２００によって通知された債務者５００の応諾を示す情報を受信する。

送信部１３０は、発生記録請求ファイル送信部１３１及びユーザインターフェース（ＵＩＦ）送信部１３３を有する。発生記録請求ファイル送信部１３１は、発生記録請求ファイル受信部１２１によって受信され、分割部１１０によって分割された発生記録請求ファイルをでんさいネットサーバ２００に送信する。ＵＩＦ送信部１３３は、第１ユーザ３００が発生記録請求ファイルを登録可能なＵＩＦを第１ユーザ３００に送信する。また、ＵＩＦ送信部１３３は、債務者５００の応諾結果、及び「でんさい」の支払い（債務者５００と第１ユーザ３００との間の実口座間の入金処理）の実行が完了した旨の通知を、第１ユーザ３００及び第２ユーザ４００が視認可能なＵＩＦとしてこれらのユーザに送信する。

実行部１４０は、発生記録請求及び債務者５００の応諾によって発生し、記録原簿に記録された「でんさい」の支払期日になると、「でんさい」の決済を実行する。具体的には、「でんさい」として記録された情報に基づいて、上記の実口座間の入金処理を行う。

口座設定部１５０は、第１口座４０１として、第２ユーザ４００に関連付けられた仮想口座を設定する。仮想口座とは、第２ユーザ４００に対して固定的に割り当てられた口座ではなく、第２ユーザ４００に対して可変的に割り当てられた口座である。つまり、取引の度に、第２ユーザ４００に対して割り当てられた仮想口座は異なり得る。ただし、仮想口座は第２ユーザ４００に対して固定的に割り当てられてもよい。

管理部１６０は、第２ユーザ４００の第１口座４０１へのアクセス権限を管理する。本実施形態では、複数の第１口座４０１が設定されており、各々の第１口座４０１に対して異なる第２ユーザ４００が関連付けられている。そして、第２ユーザ４００は自らに関連付けられた第１口座４０１のみにアクセスする権限を有している。各第１口座４０１に対するアクセス権限は、各第２ユーザ４００に対して予め設定されている。第２ユーザ４００が第１口座４０１にアクセスすることを要求した場合に、管理部１６０は、当該第２ユーザ４００が当該第１口座４０１に対してアクセス権限を有するユーザか否かを判断する。

なお、本実施形態では、第２ユーザ４００が自らに関連付けられた第１口座４０１のみにアクセスする権限を有する構成を例示したが、この構成に限定されない。つまり、第１口座４０１と第２ユーザ４００とは一対一で関連付けられていなくてもよい。例えば、１つの第１口座４０１に対して複数の第２ユーザ４００がアクセス権限を有していてもよい。具体的な例を挙げると、ある都市に拠点を有する支店である第２ユーザ４００Ａに対して第１口座４０１Ａが関連付けられている場合、当該都市の近隣に拠点を有する支店である第２ユーザ４００Ｂであって、第１口座４０１Ａではなく第１口座４０１Ｂが関連付けられている第２ユーザ４００Ｂが、当該第１口座４０１Ａにアクセスする権限を有していてもよい。

また、本実施形態では、第１口座４０１にアクセスする権限を有する第２ユーザ４００が債権者の支社である構成を例示したが、この構成に限定されない。例えば、債権者である第１ユーザ３００から業務委託を受けて、債務者５００から債権回収をする責務を負うユーザが、第１口座４０１にアクセスする権限を有していてもよい。

通知部１７０は、でんさい発生通知部１７１及び実行完了通知部１７３を有する。でんさい発生通知部１７１は、債務者５００の応諾によって「でんさい」が発生し、当該「でんさい」が記録原簿に記録されたことを第１ユーザ３００及び第２ユーザ４００に通知する。でんさい発生通知部１７１は、第１ユーザ３００及び第２ユーザ４００が銀行サーバ１００にアクセスしたときに、これらのユーザに対して上記の内容を参照可能に提供することで通知する。実行完了通知部１７３は、「でんさい」の決済が実行されたことを、上記と同様の方法で第１ユーザ３００及び第２ユーザ４００に通知する。なお、これらの通知は、上記の方法に限定されず、例えばプッシュ通知などの方法によって通知されてもよい。

通知部１７０は、上記の通知の他に、発生記録請求が銀行サーバ１００からでんさいネットサーバ２００に送信され、でんさいネットサーバ２００において仮登録された場合、又は、支払期日の数日前（例えば２営業日前）になった場合に、これらの事項を第１ユーザ３００及び第２ユーザ４００に通知する。

なお、本実施形態では、１つの銀行サーバ１００に上記の全ての機能部が含まれる構成を例示したが、この構成に限定されない。例えば、これらの機能部が異なるサーバに設けられ、これらのサーバが協働することで電子記録債権処理システム１０の機能が実現されてもよい。

［電子記録債権処理システム１０の動作］
図５を用いて、電子記録債権処理システム１０の動作について説明する。図５は、本発明の一実施形態に係る電子記録債権処理システムにおいて、でんさいの発生及び支払いの動作を示すフローチャートである。以下のフローチャートは、上記で説明した、銀行サーバ１００の各機能部によって実現される。

まず、債権者の支社である第２ユーザ４００が債権者の本社である第１ユーザ３００に対して債権回収を要求する（ステップＳ７２１）。ステップＳ７２１の債権回収要求において、第２ユーザ４００は、第２ユーザ４００が管理する債務者５００に対して債権回収要求を行う。図２を参照して説明すると、第２ユーザ４００Ａは、債務者５００Ａ～Ｃに対して債権回収要求を行う。

第１ユーザ３００は、第２ユーザ４００から債権回収要求を受信すると、発生記録請求ファイルを作成し、銀行サーバ１００に対して発生記録請求ファイルを送信する（ステップＳ７０１）。このとき、第１ユーザ３００から銀行サーバ１００に送信される発生記録請求ファイルは、例えば図６に示すようなマルチヘッダ形式の発生記録請求ファイル２１０である。

図６では、図２に示した第２ユーザ４００Ａが債務者５００Ａ～Ｂに対して債権回収を要求し、第２ユーザ４００Ｂが債務者５００Ｄ～Ｆに対して債権回収を要求し、第２ユーザ４００Ｚが債務者Ｚに対して債権回収を要求した場合の発生記録請求ファイルについて説明する。図６に示すように、発生記録請求ファイルには、ヘッダレコード及びトレーラレコードの対が複数設けられている。対をなすヘッダレコードとトレーラレコードとの間にデータレコードが設けられている。データレコードは複数であってもよく、単数であってもよい。各データレコードには、データレコードに対応するヘッダレコードに含まれる第１口座４０１に関連付けられた債務者５００の情報が含まれている。

銀行サーバ１００は、ステップＳ７０１で送信された発生記録請求ファイルを受信し、マルチヘッダ形式からシングルヘッダ形式に分割する（ステップＳ７４１）。具体的には、銀行サーバ１００の分割部１１０によって上記の分割処理が行われ、図６に示すマルチヘッダ形式から図７に示すような複数のシングルヘッダ形式の発生記録請求ファイル２２０（２２０Ａ、２２０Ｂ、・・・、２２０Ｚ）が生成される。図７に示すように、各々のシングルヘッダ形式の発生記録請求ファイルは、発生記録請求ファイル２２０Ａ、２２０Ｂのように、複数のデータレコードを含むマルチデータ形式のファイルであってもよく、発生記録請求ファイル２２０Ｃのようにシングルデータ形式のファイルであってもよい。発生記録請求ファイルがマルチデータ形式である場合、分割された発生記録請求ファイル２２０Ａは、１つのヘッダレコードと、それぞれ異なる債務者５００Ａ、５００Ｂの情報を有する複数のデータレコード１－１及び１－２）と、を含む。

銀行サーバ１００は、ステップＳ７４１で分割されたシングルヘッダ形式の発生記録請求ファイルをでんさいネットサーバ２００に送信する（ステップＳ７４３）。

でんさいネットサーバ２００は、発生記録請求ファイルを受信すると、当該ファイルに記載された内容に基づいて債務者５００へ通知し、債務者５００の諾否確認を行う（ステップＳ７６１）。当該諾否確認に対して債務者５００が応諾する意思を示すと（ステップＳ７８１）、でんさいネットサーバ２００は「でんさい」を発生する（ステップＳ７６３）。でんさいネットサーバ２００は、債権金額、支払期日、債権者情報、及び債務者情報を含む「でんさい」を記録原簿に記録する（ステップＳ７６５）。「でんさい」が発生し、記録原簿への記録が完了すると、でんさいネットサーバ２００はこれらの処理が完了したことを銀行サーバ１００に通知する（ステップＳ７６７）。

銀行サーバ１００は、ステップＳ７６７の通知を受けると、当該通知の内容を第１ユーザ３００及び第２ユーザ４００に対して通知する（ステップＳ７４５）。上記のように、この通知は、第１ユーザ３００及び第２ユーザ４００が銀行サーバ１００にアクセスしたときに、これらのユーザに対して上記の内容を参照可能に提供することで行われる。

銀行サーバ１００は、支払期日になると「でんさい」の決済処理を実行する（ステップＳ７４７）。そして、当該決済処理が完了すると、決済処理が完了したことを第１ユーザ３００及び第２ユーザ４００に対して通知する（ステップＳ７４９）。ステップＳ７４９の通知も、ステップＳ７４５の通知と同様の方法で行われる。

図５に示す動作フローにおいて、第２ユーザ４００は、ステップＳ７２１で債権回収要求を第１ユーザ３００に送信した後、銀行サーバ１００にアクセスして、第２ユーザ４００にアクセス権限が付与された第１口座４０１の入出金履歴を閲覧することができる。第２ユーザ４００によって第１口座４０１の入出金履歴の閲覧が可能になるタイミングは、ステップＳ７２１の後、第１ユーザ３００において債権回収要求に対する承認が行われた後であってもよく、ステップＳ７０１の発生記録請求を行った後であってもよい。

［発生記録請求ファイルのデータ構成］
図８～図１１を用いて、発生記録請求ファイルのデータ構成について説明する。また、図１２を用いて、発生記録請求ファイルの具体的な例について説明する。下記のデータ構成の説明において、各項目は「項番」の順に並んでいる。「項目名」は各項目の値が意味するものを示す。「桁数」のＮは、値が半角数字で構成されることを意味する。「桁数」のＣは、値が半角文字（カナ、数字、英大文字、記号）で構成されることを意味する。「桁数」のＮ又はＣの後の括弧内の数字は、各項目における値の桁数を意味する。「備考」は、各項目の値の意味を示す。

図８は、発生記録請求ファイルのヘッダレコードの内容を示す図である。図８に示すように、ヘッダレコードは、データ区分、種別コード、文字コード区分、記録請求日、請求者＿利用者番号、請求者名、取引銀行番号、取引銀行名、取引支店番号、取引支店名、預金種目、口座番号、及びダミーを有する。データ区分の値、つまりレコードの先頭の値が「１」であるとき、そのレコードがヘッダレコードであることを意味する。また、種別コードの値、つまりレコードの２番目及び３番目の値が「１２」であるとき、そのレコードが債権者請求方式であることを意味する。

図９は、発生記録請求ファイルのデータレコードの内容を示す図である。図９に示すように、データレコードは、データ区分、取引相手＿利用者番号、取引相手＿銀行番号、取引相手＿銀行名、取引相手＿支店番号、取引相手＿支店名、取引相手＿預金種目、取引相手＿口座番号、債権金額、支払期日、譲渡制限有無フラグ、記録番号、保証随伴グラフ、依頼人Ｒｅｆ．Ｎｏ．、及びダミーを有する。データ区分の値が「２」であるとき、そのレコードがデータレコードであることを意味する。

図１０は、発生記録請求ファイルのトレーラレコードの内容を示す図である。図１０に示すように、トレーラレコードは、データ区分、合計件数、合計金額、及びダミーを有する。データ区分の値が「８」であるとき、そのレコードがデータレコードであることを意味する。

図１１は、発生記録請求ファイルのエンドレコードの内容を示す図である。図１１に示すように、エンドレコードは、データ区分及びダミーを有する。データ区分の値が「９」であるとき、そのレコードがデータレコードであることを意味する。

図１２は、本発明の一実施形態に係る電子記録債権処理システムで用いられる発生記録請求ファイルの一例を示す図である。図１２において、発生記録請求ファイル８００の左側に行番号８０１が付されている。発生記録請求ファイル８００の１行目には「１１２０２０１８０９３０００００８Ｘ９Ｙ２・・・９９９９００１」という値が記載されている。図８を参照すると、１列目の値が「１」なので、１行目のレコードはヘッダレコードである。１行目のレコードと同様に４行目及び７行目のレコードもヘッダレコードである。１、４、及び７行目の２～３列目の値が「１２」なので、発生記録請求ファイル８００は債権者請求方式の請求ファイルである。このように、１、４、及び７行目のレコードと図８とを対比することで、ヘッダレコード情報８１０が特定される。ヘッダレコード情報８１０に示すように、ヘッダレコードには、図２の第１口座の番号に相当する仮想口座番号などの債権者情報が含まれている。なお、仮想口座番号８１１、８１４、及び８１７は、それぞれ１、４、及び７行目のレコードに含まれる仮想口座番号を示す。

発生記録請求ファイル８００の２行目には「２Ａ１Ｂ２Ｃ３Ｄ４Ｅ０００１・・・」という値が記載されている。図９を参照すると、１列目の値が「２」なので、２行目のレコードはデータレコードである。２行目のレコードと同様に５行目及び８行目のレコードもデータレコードである。２、５、及び８行目のレコードと図９とを対比することで、データレコード情報８２０が特定される。データレコード情報８２０に示すように、データレコードには、債務者５００の口座番号（預金口座番号）などの債務者情報が含まれている。なお、債務者情報８２２、８２５、及び８２８は、それぞれ２、５、及び８行目のレコードに含まれる債務者情報を示す。

上記と同様に考えると、３、６、及び９行目はトレーラレコードであり、１０行目はエンドレコードである。

上記のように、図１２に示す発生記録請求ファイル８００の形式は、複数のヘッダレコードが含まれたマルチヘッダ形式である。マルチヘッダ形式をシングルヘッダ形式に分割するためには、まず１列目の値が「１」であるヘッダレコードを検出し、当該ヘッダレコードに対応して１列目の値が「８」であるトレーラレコードを検出する。対をなすヘッダレコード及びトレーラレコード、並びに、これらのレコードの間にあるデータレコードを抽出し、トレーラレコードの後にエンドレコードを追加することで新たなファイルを構成する。この動作を繰り返すことで、マルチヘッダ形式が複数のシングルヘッダ形式に分割される。

［第１口座４０１へのアクセス権限］
図１３を用いて、第１ユーザ３００及び第２ユーザ４００に対して付与された、第１口座４０１へのアクセス権限について説明する。図１３は、本発明の一実施形態に係る電子記録債権処理システムにおけるアクセス権限の一例を示す図である。図１３に示すように、第１ユーザ３００に対しては、全ての第１口座４０１へのアクセス権限が付与されている。第２ユーザ４００Ａに対しては、第２ユーザ４００Ａに割り当てられた第１口座４０１Ａ「９９９９００１」へのアクセス権限が付与されている。同様に、第２ユーザ４００Ｂ、４００Ｚの各々に対しては、それぞれに割り当てられた第１口座４０１Ｂ「９９９９００２」、４０１Ｚ「９９９９０２６」の各々へのアクセス権限が付与されている。図１３では、１つの第２ユーザ４００に対して１つの第１口座４０１へのアクセス権限が付与されて構成を例示したが、この構成に限定されない。例えば、１つの第２ユーザ４００に対して複数の第１口座４０１へのアクセス権限が付与されていてもよい。つまり、第２ユーザ４００に対して、自らに割り当てられた第１口座４０１以外の第１口座４０１へのアクセス権限が付与されていてもよい。

［債務者５００からの送金フロー］
図１４を用いて、債務者５００の口座から第１ユーザ３００の口座への送金の流れについて説明する。図１４は、本発明の一実施形態に係る電子記録債権処理システムにおける送金フローの一例を示す図である。図１４に示すように、債務者５００がでんさいネットサーバ２００からの通知に対して応諾を示す旨の返答をすると、債務者５００の第２口座５０１から、第１ユーザ３００の第３口座３０１への送金が行われる。ここで、第２口座５０１及び第３口座３０１はそれぞれ実口座である。

銀行サーバ１００からでんさいネットサーバ２００に送信される発生記録請求ファイル８００では、債務者５００の振込先として第１口座４０１が指定されている。しかし、本実施形態では第１口座４０１は仮想口座であるので、実際には債務者５００の実口座である第２口座５０１から第１口座４０１への送金は行われず、第１口座４０１の情報に基づいて第２口座５０１から第３口座３０１への送金が行われる。なお、各々の送金に付与された電文には、第１口座４０１の情報が含まれているので、第１ユーザ３００は第３口座３０１への送金に付与された電文に基づいて、どの債務者５００からどの第１口座４０１を経由して送金されたものかを特定することができる。

以上のように、本実施形態に係る電子記録債権処理システム１０によると、債務者５００毎ではなく、第２ユーザ４００毎に第１口座４０１が割り当てられており、第２ユーザ４００に対して第１口座４０１へのアクセス権限が付与されていることで、債務者５００の管理責任が第１ユーザ３００に集中することを抑制することができる。そのため、第１ユーザ３００の作業効率の著しい低下を抑制することができる。

〈第２実施形態〉
図１５及び図１６を用いて、本発明の第２実施形態に係る電子記録債権処理システム２０について説明する。図１５及び図１６に示す電子記録債権処理システム２０は、図１～図１４に示す電子記録債権処理システム１０と類似しているが、電子記録債権処理システム２０における各第２ユーザ４２０（４２０Ａ、４２０Ｂ、・・・、４２０Ｚ）に付与された第１口座４２１（４２１Ａ、４２１Ｂ、・・・、４２１Ｚ）へのアクセス権限が、電子記録債権処理システム１０におけるアクセス権限と相違する。以下の実施形態の説明において、第１実施形態と同様の構成については説明を省略し、両者の相違点について説明する。

図１５は、本発明の一実施形態に係る電子記録債権処理システムの特徴を説明するための概念図である。図１６は、本発明の一実施形態に係る電子記録債権処理システムにおけるアクセス権限の一例を示す図である。図１５及び図１６に示すように、第１口座４２１Ａは第２ユーザ４２０Ａに対して割り当てられた口座である。同様に、第１口座４２１Ｂは第２ユーザ４２０Ｂに対して割り当てられた口座である。第１実施形態では、各々の第２ユーザ４００は、自らに割り当てられた第１口座４０１だけにアクセスする権限を有していた。一方、第２実施形態では、各々の第２ユーザ４２０は、自らに割り当てられた第１口座４２１だけでなく、他の第２ユーザ４２０に対して割り当てられた第１口座４２１へのアクセス権限を有している。具体的には、第２ユーザ４２０Ａは、第２ユーザ４２０Ａに対して割り当てられた第１口座４２１Ａだけでなく、他の第２ユーザ４２０Ｂに対して割り当てられた第１口座４２１Ｂへのアクセス権限を有している。

なお、上記のアクセス権限は、例えば複数の第２ユーザ４２０間の距離や、それぞれの第２ユーザ４２０が管理する債務者５００に基づいて自動的に設定されてもよい。具体的には、ある第２ユーザ４２０Ａとの距離が近い順に、上位数件の他の第２ユーザ４２０（例えば４２０Ｂ）に対して、第２ユーザ４２０Ａに割り当てられた第１口座４２１Ａへのアクセス権限を自動的に設定してもよい。又は、第２ユーザ４２０Ａが管理する債務者５００と同一の（若しくは、同一の社名又は屋号の）債務者５００を管理する他の第２ユーザ４２０（例えば４２０Ｂ）に対して、第２ユーザ４２０Ａに割り当てられた第１口座４２１Ａへのアクセス権限を自動的に設定してもよい。

例えば、第２ユーザ４２０Ａが横浜支社であり、第２ユーザ４２０Ｂが川崎支社である場合、同じ神奈川県内の支社間で情報を共有することができる。又は、同じ神奈川県内で近隣の支社間で情報を共有することができる。例えば、横浜支社（第２ユーザ４２０Ａ）及び川崎支社（第２ユーザ４２０Ｂ）は、互いに割り当てられた第１口座４２１Ａ、４２１Ｂへのアクセス権限を有するが、神奈川県内であってもこれらの支社の近隣ではない小田原支社（第２ユーザ４２０Ｚ）に割り当てられた第１口座４２１Ｚへのアクセス権限を有しないようにしてもよい。

第２ユーザ４２０Ａに割り当てられた第１口座４２１Ａへのアクセス権限と、他の第２ユーザ４２０Ｂに対して割り当てられた第１口座４２１Ｂへのアクセス権限とが、異なる種類のアクセス権限であってもよい。例えば、第２ユーザ４２０Ａが、第１口座４２１Ａを閲覧する権限及び操作する権限を有するのに対して、第２ユーザ４２０Ｂが、第１口座４２１Ａを閲覧する権限だけを有し、第１口座４２１Ａを操作する権限を有しなくてもよい。

以上のように、本実施形態に係る電子記録債権処理システム２０によると、第１実施形態と同様の効果を得ることができる。また、第１口座４２１に対して複数の第２ユーザ４２０がアクセス権限を有していることで、例えば第２ユーザ４２０Ａが機能停止に陥った場合であっても、他の第２ユーザ４２０Ｂが第２ユーザ４２０Ａの機能を補助するなど、フレキシブルな体制をとることができる。

なお、第２実施形態では、第２ユーザ４２０が支社である構成を例示したが、第２ユーザ４２０が債権者の従業員であってもよい。つまり、第２ユーザ４２０が各債務者５００に対する営業担当であってもよい。

〈第３実施形態〉
図１７及び図１８を用いて、本発明の第３実施形態に係る電子記録債権処理システム３０について説明する。図１７及び図１８に示す電子記録債権処理システム３０は、図１～図１４に示す電子記録債権処理システム１０と類似しているが、電子記録債権処理システム３０では、第１口座４０１へのアクセス権限が第２ユーザ４００だけでなく、第３ユーザ４５０にも付与されている点において、電子記録債権処理システム１０と相違する。以下の実施形態の説明において、第１実施形態と同様の構成については説明を省略し、両者の相違点について説明する。

図１７は、本発明の一実施形態に係る電子記録債権処理システムの特徴を説明するための概念図である。図１８は、本発明の一実施形態に係る電子記録債権処理システムにおけるアクセス権限の一例を示す図である。図１７及び図１８に示すように、第３ユーザ４５０Ａは、第２ユーザ４００Ａに対して割り当てられた第１口座４０１Ａ、及び第２ユーザ４００Ｂに対して割れ当てられた第１口座４０１Ｂへのアクセス権限を有する。

なお、上記の第３ユーザ４５０Ａのアクセス権限は、予め第３ユーザ４５０Ａに設定された条件を満たす第２ユーザ４００に対して、自動的に設定されてもよい。例えば、以下に示すように、第３ユーザ４５０Ａには、ある特定のエリアに存在する第２ユーザ４００に割り当てられた第１口座４０１へのアクセス権限が自動的に設定されてもよい。

例えば、第２ユーザ４００Ａが横浜支社であり、第２ユーザ４００Ｂが川崎支社である場合、第３ユーザ４５０Ａは神奈川支社とすることができる。また、第２ユーザ４００Ｚが水戸支社である場合、第３ユーザ４５０Ｚは茨城支社とすることができる。つまり、神奈川支社（第３ユーザ４５０Ａ）は、横浜支社（第２ユーザ４００Ａ）、川崎支社（第２ユーザ４００Ｂ）、その他の神奈川県内の支社の各々の第１口座４０１Ａ、４０１Ｂ等へのアクセス権限を有する。一方、神奈川支社（第３ユーザ４５０Ａ）は、神奈川県外の水戸支社（第２ユーザ４００Ｚ）の第１口座４０１Ｚへのアクセス権限を有しない。

第２ユーザ４００Ａに対する第１口座４０１Ａへのアクセス権限と、第３ユーザ４５０Ａに対する第１口座４０１Ａへのアクセス権限とが、異なる種類のアクセス権限であってもよい。例えば、第２ユーザ４００Ａが、第１口座４０１Ａを閲覧する権限及び操作する権限を有するのに対して、第３ユーザ４５０Ａが、第１口座４０１Ａを閲覧する権限だけを有し、第１口座４０１Ａを操作する権限を有しなくてもよい。

以上のように、本実施形態に係る電子記録債権処理システム３０によると、第１実施形態と同様の効果を得ることができる。また、第１口座４０１に対して第３ユーザ４５０がアクセス権限を有していることで、例えば第２ユーザ４００Ａが機能停止に陥った場合であっても、第３ユーザ４５０が第２ユーザ４００Ａの機能を補助するなど、フレキシブルな体制をとることができる。

なお、第３実施形態では、第２ユーザ４００及び第３ユーザ４５０が支社である構成を例示したが、第２ユーザ４００及び第３ユーザ４５０が債権者の従業員であってもよい。つまり、第３ユーザ４５０が統括担当者であり、第２ユーザ４００が各債務者５００に対する営業担当であってもよい。

以上、本発明の一実施形態について図面を参照しながら説明したが、本発明は上記の実施形態に限られるものではなく、本発明の趣旨を逸脱しない範囲で適宜変更することが可能である。例えば、本実施形態の電子記録債権処理システムを基にして、当業者が適宜構成要素の追加、削除もしくは設計変更を行ったものも、本発明の要旨を備えている限り、本発明の範囲に含まれる。さらに、上述した各実施形態は、相互に矛盾がない限り適宜組み合わせが可能であり、各実施形態に共通する技術事項については、明示の記載がなくても各実施形態に含まれる。

上述した各実施形態の態様によりもたらされる作用効果とは異なる他の作用効果であっても、本明細書の記載から明らかなもの、又は、当業者において容易に予測し得るものについては、当然に本発明によりもたらされるものと解される。

１０：電子記録債権処理システム、 １００：銀行サーバ、 １０１：データベース、 １０３：サーバ制御部、 １０５：サーバ記憶部、 １０７：サーバ通信部、 １１０：分割部、 １２０：受信部、 １２１：発生記録請求ファイル受信部、 １２３：応諾結果受信部、 １３０：送信部、 １３１：発生記録請求ファイル送信部、 １３３：ＵＩＦ送信部、 １４０：実行部、 １５０：口座設定部、 １６０：管理部、 １７０：通知部、 １７１：でんさい発生通知部、 １７３：実行完了通知部、 ２００：でんさいネットサーバ、 ２０１：データベース、 ２１０：発生記録請求ファイル、 ２２０Ａ～Ｚ：発生記録請求ファイル、 ３００：第１ユーザ、 ３０１：第３口座、 ４００、４２０：第２ユーザ、 ４０１、４２１：第１口座、 ４５０：第３ユーザ、 ５００：債務者、 ５０１：第２口座、 ６００：第１ネットワーク、 ６１０：第２ネットワーク、 ８００：発生記録請求ファイル、 ８１０：ヘッダレコード情報、 ８２０：データレコード情報、 ８２２：債務者情報、 ８２５：債務者情報

Claims (11)

1. 第１ユーザによって請求された、マルチヘッダ形式の発生記録請求ファイルを、複数の債務者を管理する複数の第２ユーザにそれぞれ割り当てられた異なる第１口座を含むヘッダレコード毎に分割する分割部を有し、
   各々の前記ヘッダレコードは、前記第１ユーザの利用者番号と、前記複数の債務者に対して指定された前記第１口座の各々の情報と、を含む情報処理装置。
2. 各々の前記第１口座は、複数の前記第２ユーザのそれぞれに一対一で対応する、請求項１に記載の情報処理装置。
3. 分割された前記発生記録請求ファイルの各々は、１つの前記ヘッダレコードと、それぞれ異なる前記債務者の情報を有する複数のデータレコードとを含む、請求項１又は２に記載の情報処理装置。
4. 分割された前記発生記録請求ファイルを電子債権記録機関システムに送信する送信部をさらに有する、請求項３に記載の情報処理装置。
5. 前記電子債権記録機関システムからの通知を受信する受信部と、
   前記通知に基づいて、分割された前記発生記録請求ファイルの各々に含まれる複数の前記データレコードの各々に関連する前記債務者の第２口座から、分割された前記発生記録請求ファイルの各々に含まれる１つの前記ヘッダレコードに関連する前記第１口座の情報に基づいて、前記第１ユーザの第３口座への入金を行う実行部と、
   をさらに有する請求項４に記載の情報処理装置。
6. 前記第１口座として、可変的に前記第２ユーザに関連付けられた仮想口座を設定する口座設定部をさらに有する、請求項１乃至５のいずれか一に記載の情報処理装置。
7. 前記第１ユーザ以外のユーザが、前記第１口座にアクセスする権限を管理する管理部をさらに有する、請求項１乃至６のいずれか一に記載の情報処理装置。
8. 前記第１ユーザは、金融機関の本社であり、
   前記第２ユーザは、前記金融機関の支社であり、
   前記支社が、分割された前記発生記録請求ファイルのうち、前記支社に割り当てられた前記第１口座にアクセスする権限を管理する管理部をさらに有する、請求項１乃至６のいずれか一に記載の情報処理装置。
9. 第１ユーザによって請求された、マルチヘッダ形式の発生記録請求ファイルを、複数の債務者を管理する複数の第２ユーザにそれぞれ割り当てられた異なる第１口座を含むヘッダレコード毎に分割することをコンピュータに実行させるプログラムであって、
   各々の前記ヘッダレコードは、前記第１ユーザの利用者番号と、前記複数の債務者に対して指定された前記第１口座の各々の情報と、を含むプログラム。
10. 分割された前記発生記録請求ファイルを電子債権記録機関システムに送信することをコンピュータに実行させる請求項９に記載のプログラム。
11. 前記電子債権記録機関システムからの通知に基づき、分割された前記発生記録請求ファイルの各々に含まれる複数のデータレコードの各々に関連する前記債務者の第２口座から、分割された前記発生記録請求ファイルの各々に含まれる１つの前記ヘッダレコードに関連する前記第１口座の情報に基づいて、前記第１ユーザの第３口座への入金を行うことをコンピュータに実行させる請求項１０に記載のプログラム。

Images