JP2017211866A - プログラム、情報処理方法および情報処理装置 - Google Patents

Abstract

【課題】需要者からの未収金の発生時に、仲介者の損失を低減することが可能なプログラム等を提供すること。【解決手段】プログラムは、需要者５０に対してユーザ１０が有する支払期限が過ぎた債権の金額を取得し、前記債権の支払いが遅延した理由を取得し、前記理由が所定の遅延理由に該当するか否かを判定し、該当すると判定した場合には、前記ユーザ１０に対して前記債権に対応する金額を支払う処理をコンピュータに実行させる。【選択図】図１

Description

本発明は、プログラム、情報処理方法および情報処理装置に関する。

電力自由化に伴い、電力の需要者は、料金体系の異なる複数の電気事業者のなかから契約相手を選択することが可能である。需要者と電気事業者との間を仲介し、需要者から使用量に応じた料金を徴収するとともに、電気事業者には定額料金を支払う仲介者の収支を安定させることができる監視装置等が提案されている（特許文献１）。

特開２０１６−９３９０号公報

特許文献１の監視装置は、需要者が過去に支払った料金の履歴から予測した使用量に基づいて、各需要者に電力を供給する電気事業者を設定する。しかし、需要者の破産等による未収金の発生に対応することはできない。

一つの側面では、需要者からの未収金の発生時に、仲介者の損失を低減することが可能なプログラム等を提供する。

プログラムは、需要者に対してユーザが有する支払期限が過ぎた債権の金額を取得し、前記債権の支払いが遅延した理由を取得し、前記理由が所定の遅延理由に該当するか否かを判定し、該当すると判定した場合には、前記ユーザに対して前記債権に対応する金額を支払う処理をコンピュータに実行させる。

一つの側面では、需要者からの未収金の発生時に、仲介者の損失を低減することが可能になる。

金銭等の流れの概要を示す説明図である。 情報処理システムの構成を示す説明図である。 仲介契約ＤＢのレコードレイアウトを示す説明図である。 主請求情報ＤＢのレコードレイアウトを示す説明図である。 副請求情報ＤＢのレコードレイアウトを示す説明図である。 主請求情報ＤＢの別のサブセットを示す説明図である。 振込結果ＤＢのレコードレイアウトを示す説明図である。 料金ＤＢのレコードレイアウトを示す説明図である。 滞留記録ＤＢのレコードレイアウトを示す説明図である。 プログラムの処理の流れを示すフローチャートである。 プログラムの処理の流れを示すフローチャートである。 債権保証処理のサブルーチンの処理の流れを示すフローチャートである。 実施の形態２の付帯保証金額ＤＢのレコードレイアウトを示す説明図である。 実施の形態２の免除実績ＤＢのレコードレイアウトを示す説明図である。 実施の形態２の必要書類ＤＢのレコードレイアウトを示す説明図である。 実施の形態２のプログラムの処理の流れを示すフローチャートである。 実施の形態２の支払額算定のサブルーチンの処理の流れを示すフローチャートである。 実施の形態３の情報処理装置の動作を示す機能ブロック図である。 実施の形態４の情報処理システムの構成を示す説明図である。

［実施の形態１］
図１は、金銭等の流れの概要を示す説明図である。供給者３０は、電力小売事業者である。需要者５０は、一般家庭または法人等である。仲介者１０は、供給者３０と需要者５０との間の取引を仲介する事業者である。仲介者１０は、たとえばＬＰ（Liquefied Petroleum）ガスを需要者に供給するＬＰガス販売事業者である。

図示を省略するが、供給者３０、需要者５０および仲介者１０は、それぞれ複数である。原則として、一人の需要者５０は、一つの仲介者１０との間で契約を締結する。一つの仲介者１０は、複数の需要者５０と契約を締結する。また、一つの仲介者１０は、一つまたは複数の供給者３０と契約を締結する。一つの供給者３０は、一つまたは複数の仲介者１０と契約を締結する。

組合２０は、複数の仲介者１０が加盟する団体である。組合２０は、たとえば協同組合または共済組合である。

一人の需要者５０は、原則として一つの供給者３０から電力の供給を受ける。需要者５０の電力使用量は、スマートメータにより自動的に供給者３０に通知される。供給者３０は、通知された電力使用量に基づいて、電気料金を定める。

需要者５０は、電力使用量に応じた電気料金を仲介者１０に支払う。仲介者１０は、需要者５０からの電気料金の支払いの有無にかかわらず、需要者５０の電力使用量に応じた電気料金を供給者３０に支払う。仮に、需要者５０が仲介者１０に電気料金を支払わなかった場合には、仲介者１０は需要者５０に対して電気料金を請求する債権を有する。仲介者１０は、組合２０に組合費を支払う。

供給者３０は、需要者５０との間の契約を仲介したことに対する仲介手数料を仲介者１０に支払う。供給者３０は、仲介者１０を斡旋したことに対する斡旋手数料を組合２０に支払う。仲介手数料および斡旋手数料は、定額または電気料金に応じた金額等である。

いずれの金銭も銀行または信販会社等の金融機関を介した電子決済により決済することが可能である。供給者３０と仲介者１０との間では、電気料金と仲介手数料とを相殺して、差額の金額のみを決済しても良い。なお、以下の説明では需要者５０は、金融機関による自動支払いサービスを使用して料金を支払う場合を例にして説明を行う。

以下の説明においては、需要者５０が支払う電気料金と仲介者１０が支払う電気料金は同一であり、仲介者１０は仲介手数料により収益を得る場合を例にして説明する。なお、需要者５０が支払う電気料金は、仲介者１０が支払う電気料金に比べて高く設定されていても良い。このようにする場合には、仲介者１０は電気料金の差額により収益を得ることたできるので、仲介手数料をゼロにしても良い。

ＬＰガス販売事業者は、ガスボンベの定期的な交換等を行うことにより地域に密着した活動を長年行っている。ＬＰガス販売事業者が仲介者１０の役割を担うことにより、地縁の薄い新興の供給者３０等であっても、電力小売市場への新規参入を果たしやすい。

一方、ＬＰガス販売事業者は比較的小規模の事業者が多い。そのため、たとえば需要者５０の死亡、破産等により料金の支払いが焦げ付いた場合には、経営的なダメージを受けやすい。以下に説明するように、組合２０は、本件のプログラム等によりこのようなダメージを軽減する。

組合２０は小額短期保険業者等の保険業者であっても良い。組合２０が保険業者であり、仲介者１０が保険の契約者である場合には、仲介者１０は組合２０に組合費の代わりに保険料を支払う。

供給者３０は、都市ガスを需要者５０に供給する都市ガス供給業者、または水を需要者５０に供給する水道業者等、電気以外を提供する業者であっても良い。いずれの場合も、需要者５０が消費した量については、スマートメータにより自動的に供給者３０に通知される。

仲介者１０は、コンビニエンスストア、ガソリンスタンド、バス運行会社等の業者であっても良い。いずれの場合も、地域に店舗等の営業基盤を有することが望ましい。

図２は、情報処理システム７０の構成を示す説明図である。情報処理システム７０は、サーバ２１、仲介者クライアント１１、供給者クライアント３１、金融機関クライアント６１、メータ５１およびこれらを接続するネットワーク２９を備える。

サーバ２１は、サーバＣＰＵ（Central Processing Unit）２２、主記憶装置２３、補助記憶装置２４、入力部２５、表示部２６および通信部２７を備える。サーバ２１は、汎用のパーソナルコンピュータ、汎用のサーバマシン等の情報処理装置である。サーバ２１は、組合２０により所有または管理される。サーバ２１は、本実施の形態の情報処理システム７０の情報処理装置の一例である。

サーバＣＰＵ２２は、本実施の形態に係るプログラムを実行する演算制御装置である。サーバＣＰＵ２２には、一または複数のＣＰＵまたはマルチコアＣＰＵ等が使用される。主記憶装置２３は、ＳＲＡＭ（Static Random Access Memory）、ＤＲＡＭ（Dynamic Random Access Memory）、フラッシュメモリ等の記憶装置である。主記憶装置２３には、サーバＣＰＵ２２が行う処理の途中で必要な情報およびサーバＣＰＵ２２で実行中のプログラムが一時的に保存される。

補助記憶装置２４は、ＳＲＡＭ、フラッシュメモリ、ハードディスクまたは磁気テープ等の記憶装置である。補助記憶装置２４には、サーバＣＰＵ２２に実行させるプログラムおよび仲介契約ＤＢ（DataBase）４１、主請求情報ＤＢ４２、滞留記録ＤＢ４６およびプログラムの実行に必要な各種情報が保存される。

入力部２５は、マウス、キーボード、タッチパネル、ペンタブレット、マイク等の機器であり、ユーザによる操作をサーバＣＰＵ２２が受け付ける際に使用する。表示部２６は、ディスプレイ、プリンタ、プロッタ等の機器であり、サーバＣＰＵ２２が行った情報処理の結果等を表示する。通信部２７は、ネットワーク２９との通信を行うインターフェイスである。

なお、サーバ２１は一つまたは複数の大型計算機上で動作する仮想マシンであっても良い。仲介契約ＤＢ４１および主請求情報ＤＢ４２は、ネットワーク２９を介してサーバ２１に接続されたデータサーバ等の記憶装置に記憶されていても良い。各ＤＢは、別々の記憶装置に記憶されていても良い。

仲介者クライアント１１は、仲介者１０が使用するクライアントである。仲介者クライアント１１は、仲介者ＣＰＵ１２、主記憶装置１３、補助記憶装置１４、入力部１５、表示部１６および通信部１７を備える。仲介者クライアント１１は、汎用のパーソナルコンピュータ、タブレット、スマートフォン等の情報機器である。

仲介者ＣＰＵ１２は、サーバＣＰＵ２２と協調して本実施の形態に係るプログラムを実行する演算制御装置である。仲介者ＣＰＵ１２には、一または複数のＣＰＵまたはマルチコアＣＰＵ等が使用される。仲介者ＣＰＵ１２は、バスを介して仲介者クライアント１１を構成するハードウェア各部と接続されている。

補助記憶装置１４は、ＳＲＡＭ、フラッシュメモリ、ハードディスクまたは磁気テープ等の記憶装置である。補助記憶装置１４には、仲介者ＣＰＵ１２に実行させるプログラム、副請求情報ＤＢ４３、料金ＤＢ４４およびプログラムの実行に必要な各種情報が保存される。

主記憶装置１３、入力部１５、表示部１６および通信部１７は、サーバ２１の対応する各装置と同様であるので説明を省略する。

供給者クライアント３１は、供給者３０が使用するクライアントである。金融機関クライアント６１は、決済を媒介する金融機関が使用するクライアントである。供給者クライアント３１および金融機関クライアント６１は、汎用のパーソナルコンピュータ、汎用のサーバマシン等の情報処理装置である。これらの構成は、サーバ２１と同様であるので、図示および説明を省略する。供給者クライアント３１は、供給者ＣＰＵを有する。金融機関クライアント６１は、金融機関ＣＰＵを有する。

メータ５１は、各需要者５０に設置され、消費電力を測定するスマートメータである。メータ５１は、たとえば３０分ごとに供給者クライアント３１に消費電力を送信する。メータ５１には、固有のメータＩＤ（IDentification）が付与されている。すなわち、メータＩＤは、メータ５１を介して需要者５０と対応付けられる。

図３は、仲介契約ＤＢ４１のレコードレイアウトを示す説明図である。仲介契約ＤＢ４１は、仲介契約ＩＤ、仲介者１０および供給者３０を関連づけるＤＢである。仲介契約ＤＢ４１は、仲介契約ＩＤフィールド、仲介者フィールドおよび供給者フィールドを有する。

仲介契約ＩＤフィールドには、仲介者１０と供給者３０とが締結した仲介契約のＩＤ番号が記録されている。仲介者フィールドには、仲介契約の一方の当事者である仲介者１０の名称が記録されている。供給者フィールドには、仲介契約の他方の当事者である供給者３０の名称が記録されている。仲介契約ＤＢ４１は、一つの仲介契約について、一つのレコードを有する。

図４は、主請求情報ＤＢ４２のレコードレイアウトを示す説明図である。主請求情報ＤＢ４２は、仲介契約のＩＤ番号、供給者３０の名称、仲介者１０の名称、メータＩＤ、需要者５０の口座番号および料金の請求月と金額を関連づけるＤＢである。

主契約情報ＤＢ４２は、供給者フィールド、仲介契約ＩＤフィールド、仲介者フィールド、メータＩＤフィールド、口座番号フィールド、請求月フィールドおよび金額フィールドを有する。

供給者フィールドには、供給者３０の名称が記録されている。仲介契約ＩＤフィールドには、仲介契約のＩＤ番号が記録されている。仲介者フィールドには、仲介者１０の名称が記録されている。メータＩＤフィールドには、メータＩＤが記録されている。口座番号フィールドには、需要者５０が料金の支払いに使用する口座等の情報が記録されている。請求月フィールドには、電気料金の請求月が記録されている。金額フィールドには、電気料金の金額が記録されている。主契約情報ＤＢ４２は、１回の料金請求について、一つのレコードを有する。

図５は、副請求情報ＤＢ４３のレコードレイアウトを示す説明図である。副請求情報ＤＢ４３は、主請求情報ＤＢ４２のサブセットである。副請求情報ＤＢ４３は、図４を使用して説明した主請求情報ＤＢ４２と同一のフィールドを有する。副請求情報ＤＢ４３は、主請求情報ＤＢ４２に記録されたレコードのうち、仲介者クライアント１１を管理する仲介者１０の名称が仲介者フィールドに記録されたレコードと同一のレコードを有する。

図６は、主請求情報ＤＢ４２の別のサブセットを示す説明図である。図６に示すサブセットには、主請求情報ＤＢ４２に記録されたレコードのうち、特定の供給者３０の名称および特定の条件の口座情報が記録されたレコードのみが含まれている。

図７は、振込結果ＤＢのレコードレイアウトを示す説明図である。振込結果ＤＢは、需要者５０に対して請求した電気料金と需要者５０からの入金状況とを関連づけるＤＢである。

振込結果ＤＢは、供給者フィールド、仲介契約ＩＤフィールド、仲介者フィールド、メータＩＤフィールド、口座番号フィールド、請求月フィールド、金額フィールドおよび入金日フィールドを有する。

供給者フィールドには、供給者３０の名称が記録されている。仲介契約ＩＤフィールドには、仲介契約のＩＤ番号が記録されている。仲介者フィールドには、仲介者１０の名称が記録されている。メータＩＤフィールドには、メータＩＤが記録されている。口座番号フィールドには、需要者５０が料金の支払いに使用する口座等の情報が記録されている。請求月フィールドには、電気料金の請求月が記録されている。金額フィールドには、電気料金の金額が記録されている。入金日フィールドには、仲介者１０に対して電気料金の入金が行われた日付が記録されている。入金が行われていない場合には、入金日フィールドは空欄である。

振込結果ＤＢは、１回の料金請求について、一つのレコードを有する。振込結果ＤＢは、金融機関ＣＰＵが作成し、金融機関クライアント６１の補助記憶装置に記憶される。

図８は、料金ＤＢ４４のレコードレイアウトを示す説明図である。料金ＤＢ４４は、需要者５０の電気料金、支払日、未払理由および回収不能報告の有無とを関連づけるＤＢである。

料金ＤＢ４４は、仲介者フィールド、仲介契約ＩＤフィールド、供給者フィールド、メータＩＤフィールド、口座番号フィールド、請求月フィールド、金額フィールド、支払日フィールド、未払理由フィールドおよび回収不能報告フィールドを有する。

仲介者フィールドには、仲介者１０の名称が記録されている。仲介契約ＩＤフィールドには、仲介契約のＩＤ番号が記録されている。供給者フィールドには、供給者３０の名称が記録されている。メータＩＤフィールドには、メータＩＤが記録されている。口座番号フィールドには、需要者５０が料金の支払いに使用する口座等の情報が記録されている。請求月フィールドには、電気料金の請求月が記録されている。金額フィールドには、電気料金の金額が記録されている。支払日フィールドには、仲介者１０に対して電気料金の支払いが行われた日付が記録されている。支払いが行われていない場合には、支払日フィールドは空欄である。

未払理由フィールドには、支払いが行われていない理由が記録されている。理由が不明である場合および支払期日内に支払いが行われた場合は、未払理由フィールドは空欄である。回収不能報告フィールドには、電気料金に関する債権の回収が不能であるという報告の有無が記録されている。債権の回収が不能である場合とは、たとえば需要者５０の死亡、行方不明または、破産等の理由により、電気料金を回収することができない場合である。料金ＤＢ４４は、１回の料金請求について、一つのレコードを有する。

図９は、滞留記録ＤＢ４６のレコードレイアウトを示す説明図である。滞留記録ＤＢ４６は、仲介者１０が需要者５０に対して有する債権のうち、支払いが滞った債権の内容、未払理由、回収不能判定の有無、債権保証の可否判定結果および債権保証による支払金額を関連づけるＤＢである。

滞留記録ＤＢ４６は、仲介契約ＩＤフィールド、仲介者フィールド、供給者フィールド、メータＩＤフィールド、請求月フィールド、金額フィールド、未払理由フィールド、回収不能フィールド、保証判定フィールドおよび支払済額フィールドを有する。

仲介契約ＩＤフィールドには、仲介契約のＩＤ番号が記録されている。仲介者フィールドには、仲介者１０の名称が記録されている。供給者フィールドには、供給者３０の名称が記録されている。メータＩＤフィールドには、メータＩＤが記録されている。請求月フィールドには、電気料金の請求月が記録されている。金額フィールドには、電気料金の金額が記録されている。

未払理由フィールドには、支払いが滞留した理由が記録されている。理由が不明である場合は、未払理由フィールドは空欄である。回収不能報告フィールドには、債権の回収が不能であるという報告の有無が記録されている。保証判定フィールドは、組合２０が債権の支払いを保証する条件が満たされているか否かが記録されている。支払済額フィールドには、組合２０が保証のために仲介者１０に支払った金額が記録されている。滞留記録ＤＢ４６は、１件の滞留している支払いについて、一つのレコードを有する。

図１から図９を使用して、データおよび金銭の流れの概要を説明する。供給者ＣＰＵ１２は、メータ５１から取得した電力使用量に基づいて、各需要者５０の電気料金を算出する。供給者ＣＰＵ１２は、需要者５０が利用する金融機関ごとに分けて、料金自動支払いサービスによる支払いを請求する。

図６を使用して、供給者ＣＰＵ１２が金融機関ＣＰＵに対して送信するデータの例を説明する。図６は、「ＳＳＳ」という名称の供給者３０が管理する供給者ＣＰＵ１２が、「第１銀行ＧＧ支店」という名称の金融機関が管理する金融機関ＣＰＵに送信する、「２０１６年３月」分のデータの例を示す。図６に示すように、供給者ＣＰＵ１２は、複数の仲介者１０がそれぞれ仲介した需要者５０の電気料金を、金融機関ＣＰＵに送信する。

供給者ＣＰＵ１２は、仲介者１０ごとに分けて、仲介者ＣＰＵ１２に電気料金データを通知する。仲介者ＣＰＵ１２は、受信した電気料金データを副請求情報ＤＢ４３に記録する。

図５を使用して、供給者ＣＰＵ１２が仲介者ＣＰＵ１２に対して送信するデータの例を説明する。図５は、「ＳＳＳ」という名称の供給者３０が管理する供給者ＣＰＵ１２が、「ＡＡＡ」という名称の仲介者１０が管理する仲介者ＣＰＵ１２に対して送信する、「２０１６年３月」分のデータの例を示す。図５に示すように、供給者ＣＰＵ１２は、一つの仲介者１０が仲介した需要者５０の電気料金を仲介者ＣＰＵ１２に送信する。仲介者ＣＰＵ１２は、複数の供給者ＣＰＵ１２から受信したデータを、副請求情報ＤＢ４３に記録する。すなわち、副請求情報ＤＢ４３には、供給者フィールドに記録された供給者３０の名称が異なる複数のシートが記録される。

供給者ＣＰＵ１２は、サーバＣＰＵ２２に、電気料金データを送信する。サーバＣＰＵ２２は、受信した電気料金データを主請求情報ＤＢ４２に記録する。サーバＣＰＵ２２は、受信した電気料金データに基づいて斡旋手数料を算出し、供給者ＣＰＵ１２に請求データを送信する。

図４を使用して、供給者ＣＰＵ１２がサーバＣＰＵ２２に対して送信するデータの例を説明する。図４は、「ＳＳＳ」という名称の供給者３０が、サーバＣＰＵ２２に対して送信する、「２０１６年３月」分のデータを示す。図４に示すように、供給者ＣＰＵ１２は、すべての仲介者１０および金融機関に関するデータを、一括してサーバＣＰＵ２２に送信する。サーバＣＰＵ２２は、複数の供給者ＣＰＵ１２から受信したデータを、主請求情報ＤＢ４２に記録する。すなわち、主請求情報ＤＢ４２には、供給者フィールドに記録された供給者３０の名称が異なる複数のシートが記録される。

各金融機関ＣＰＵは、請求に基づいて各需要者５０の電気料金を仲介者１０の口座に振り込む。公共料金の自動支払処理は従来から行われているので、詳細については説明を省略する。金融機関ＣＰＵは、図７を使用して説明した振込結果ＤＢに振込の結果を記録する。金融機関ＣＰＵは、振込結果ＤＢに記録したデータを、仲介者ＣＰＵ１２に送信する。

図７を使用して、金融機関ＣＰＵが仲介者ＣＰＵ１２に送信するデータの例を説明する。図７は、「第１銀行ＧＧ支店」という名称の金融機関が管理する金融機関ＣＰＵが、「ＡＡＡ」という名称の仲介者１０が管理する仲介者ＣＰＵ１２に対して送信する料金振込の結果を示す。図７に示すように、金融機関ＣＰＵは、それぞれの供給者ＣＰＵ１２から受信したデータに基づいて行った振込処理のうち、仲介者１０「ＡＡＡ」に対する振込処理のデータを抽出して、送信する。なお、振込を行えた場合には、金融機関ＣＰＵは、入金日フィールドに入金日を記録する。残高不足等の理由により、振込処理を行えなかった場合には、金融機関ＣＰＵは、入金日フィールドを空欄のままにする。

仲介者ＣＰＵ１２は、金融機関ＣＰＵからデータに基づいて、図８を使用して説明した料金ＤＢ４４にレコードを追加する。料金ＤＢ４４に記録したレコードを参照して、仲介者ＣＰＵ１２は、入金日フィールドに入金日が記録されているレコードについては、金額フィールドに記録されている金額に対応する電気料金を供給者３０に支払う処理を行う。

仲介者ＣＰＵ１２は、入金日フィールドに入金日が記録されていないレコードについては、金額フィールドに記録されている金額に対応する電気料金を立て替えて供給者３０に支払う処理を行う。仲介者ＣＰＵ１２は、立替払いを行ったレコードをサーバＣＰＵ２２に送信する。滞留記録ＤＢ４６に記録する。サーバＣＰＵ２２は、受信したレコードに基づいて滞留記録ＤＢ４６にレコードを追加する。

需要者５０から仲介者１０に対する電気料金の支払状況が、各仲介者クライアント１１の料金ＤＢ４４に記録される。各仲介者１０が立替処理を行った電気料金に関する情報が、まとめて滞留記録ＤＢ４６に記録される。

以上に説明した処理は、供給者３１の電気料金請求日ごとに行われる。なお、供給者ＣＰＵ１２は、一人の需要者５０の電気料金を算出するごとに、金融機関ＣＰＵに自動振込処理の請求を行っても良い。

仲介者１０は、地域に密着して営業している利点を生かして、料金ＤＢ４４に未払い金の存在が記録されている需要者５０を訪問し、未払料金を回収するとともに、回収が困難な場合には未払理由、今後の回収見込みの有無等を判断する。訪問は、たとえばＬＰガスボンベの交換の際に行うことができる。

仲介者１０は、料金を回収した場合には、入力部１５を介して料金ＤＢ４４に支払日を入力する。仲介者１０は、未払理由が判明した場合には、未払理由報告書を作成する。仲介者１０は、所定の回収不能事象に該当すると思われる場合には、回収不能報告書を作成する。所定の回収不能事象は、たとえば需要者５０の世帯主の死亡、行方不明または破産である。

仲介者ＣＰＵ１２は、仲介者１０から料金の支払日、未払理由報告書および回収不能報告書を取得し、料金ＤＢ４４の支払日フィールド、未払理由フィールドおよび回収不能報告フィールドに記録する。

サーバＣＰＵ２２は、滞留記録ＤＢ４６の支払日フィールドを参照して、未払いのレコードを抽出する。サーバＣＰＵ２２は、抽出したレコードの供給者フィールドを参照して、対応する供給者ＣＰＵ１２に未払理由および回収不能報告の有無を問い合わせる。

供給者ＣＰＵ１２は、料金ＤＢ４４を参照して対応するレコードの未払理由フィールドおよび回収不能報告フィールドに記録されているデータの有無およびデータが記録されている場合にはそのデータをサーバＣＰＵ２２に送信する。サーバＣＰＵ２２は、受信したデータを用いて滞留記録ＤＢ４６を更新する。

供給者ＣＰＵ１２は、所定の条件を満たす場合に、債権保証処理を行ない、未払いとなっている最大３ヶ月分の電気料金のうち９０パーセントを仲介者１０に支払う。これにより需要者５０の死亡等に起因する、仲介者１０の経営的なダメージが軽減される。

なお、債権保証処理による支払金額の割合は例示である。９０パーセント以外の任意の割合にすることができる。未払いとなっている料金から所定の金額を差し引いた金額としても良い。未払いとなっている料金に、さらに所定の利息をつけた金額としても良い。債権保証処理の対象とする未払い料金の最大月数は３ヶ月分よりも多くしても少なくしても良い。

図１０は、プログラムの処理の流れを示すフローチャートである。図１０には、供給者３０が電力使用量に基づいて定めた電気料金を徴収する処理の流れを、仲介者ＣＰＵ１２が行う処理を中心として示す。図１０を使用して、プログラムの処理の流れを説明する。

供給者ＣＰＵ１２は、メータ５１から取得した電力使用量に基づいて、各需要者５０の電気料金を算出する（ステップＳ５０１）。供給者ＣＰＵ１２は、ステップＳ５０１で算出した料金を需要者５０が利用する金融機関ごとに分けて、料金自動支払いサービスによる支払請求データを送信する（ステップＳ５０２）。

金融機関ＣＰＵは、支払請求データを受信し、請求処理を行う（ステップＳ５８１）。具体的には、金融機関ＣＰＵは、口座番号フィールドに記録されたそれぞれの需要者５０の口座から、仲介者フィールドに記録された仲介者１０の口座に、金額フィールドに記録された金額を移動させる。

供給者ＣＰＵ１２は、ステップＳ５０１で算出した料金を仲介者１０ごとに分けて、仲介者ＣＰＵ１２に送信する（ステップＳ５０３）。仲介者ＣＰＵ１２は、受信したデータを副請求情報ＤＢ４３に記録する（ステップＳ５６１）。

供給者ＣＰＵ１２は、ステップＳ５０１で算出した料金をまとめてサーバＣＰＵ２２に送信する（ステップＳ５０４）。サーバＣＰＵ２２は、受信したデータを主請求情報ＤＢ４２に記録する（ステップＳ５２１）。

ステップＳ５８１の処理の終了後、金融機関ＣＰＵは請求処理の結果を仲介者ＣＰＵ１２に送信する（ステップＳ５８２）。仲介者ＣＰＵ１２は、受信したデータを料金ＤＢ４４に記録する（ステップＳ５６２）。

仲介者ＣＰＵ１２は、カウンタＩを初期値１に設定する（ステップＳ５６３）。仲介者ＣＰＵ１２は、ステップＳ５６２で料金ＤＢ４４に記録したレコードからＩ番目のレコードを取得する。仲介者ＣＰＵ１２は、取得したレコードの支払日フィールドを参照して需要者５０から仲介者１０への入金が行われているか否かを判定する（ステップＳ５６４）。Ｉ番目のレコードの支払日フィールドに支払日の記録があり、需要者５０からの入金が行われている場合（ステップＳ５６４でＹＥＳ）、仲介者ＣＰＵ１２は供給者３０に対し電気料金を出金する処理を行う（ステップＳ５６５）。

Ｉ番目のレコードの支払日フィールドに支払日の記録がなく、需要者５０からの入金が行われていない場合（ステップＳ５６４でＮＯ）、仲介者ＣＰＵ１２は供給者３０に対し電気料金を立替払いする処理を行う（ステップＳ５６６）。仲介者ＣＰＵ１２は、Ｉ番目のレコードをサーバＣＰＵ２２に送信する（ステップＳ５６７）。サーバＣＰＵ２２は、受信したレコードに基づいて滞留記録ＤＢ４６にレコードを作成して、記録する（ステップＳ５２２）。

なお、図１０では図示を省略するが、仲介者１０と供給者３０との間の決済は、金融機関ＣＰＵを介して行う。この際、金融機関は需要者５０が支払いに使用している金融機関と同一の金融機関でも、異なる金融機関でも良い。

ステップＳ５６５またはステップＳ５６７の終了後、仲介者ＣＰＵ１２はステップＳ５６２で料金ＤＢ４４に記録したすべてのレコードの処理が終了したか否かを判定する（ステップＳ５６８）。終了したと判定した場合（ステップＳ５６８でＹＥＳ）、仲介者ＣＰＵ１２は処理を終了する。終了していないと判定した場合、仲介者ＣＰＵ１２はカウンタＩに１を加算する（ステップＳ５６９）。仲介者ＣＰＵ１２はステップＳ５６４に戻る。

図１１は、プログラムの処理の流れを示すフローチャートである。図１０には、たとえば夜間等に定期的に実行する処理の流れを、サーバＣＰＵ２２が行う処理を中心として示す。図１１を使用して、プログラムの処理の流れを説明する。

サーバＣＰＵ２２は、カウンタＩに初期値１を設定する（ステップＳ６０１）。サーバＣＰＵ２２は、滞留記録ＤＢ４６からＩ番目のレコードを取得する（ステップＳ６０２）。サーバＣＰＵ２２は、取得したレコードの支払済額フィールドを参照して、債権保証の支払いが済んでいるか否かを判定する（ステップＳ６０３）。

支払済ではないと判定した場合（ステップＳ６０３でＮＯ）、サーバＣＰＵ２２は、取得したレコードを対応する仲介者ＣＰＵ１２に送信する（ステップＳ６０４）。

仲介者ＣＰＵ１２はレコードを受信する（ステップＳ６２１）。仲介者ＣＰＵ１２は、受信したレコードのメータＩＤフィールドおよび請求月フィールドをキーとして料金ＤＢ４４を検索し、対応するレコードを抽出する。仲介者ＣＰＵ１２は、抽出した料金レコードをサーバＣＰＵ２２に送信する（ステップＳ６２２）。

サーバＣＰＵ２２は料金レコードを受信する（ステップＳ６０５）。サーバＣＰＵ２２は、受信した料金レコードの支払日フィールドに支払日が記録されているか否かを判定する（ステップＳ６０６）。支払日が記録されていると判定した場合（ステップＳ６０６でＹＥＳ）、サーバＣＰＵ２２はステップＳ６０２で取得したレコードを滞留記録ＤＢ４６から削除する（ステップＳ６０７）。

支払日が記録されていないと判定した場合（ステップＳ６０６でＮＯ）、サーバＣＰＵ２２は、受信した料金レコードの未払理由フィールドに未払理由が記録されているか否かを判定する（ステップＳ６０８）。未払理由が記録されていると判定した場合（ステップＳ６０８でＹＥＳ）、サーバＣＰＵ２２は処理中の滞留記録レコードの未払理由フィールドに未払理由を記録する。サーバＣＰＵ２２は、受信した料金レコードの回収不能報告フィールドに回収不能報告が記録されているか否かを判定する（ステップＳ６０９）。

回収不能報告が記録されていると判定した場合（ステップＳ６０９でＹＥＳ）、サーバＣＰＵ２２は処理中の滞留記録レコードの回収不能フィールドに回収不能報告を記録する。サーバＣＰＵ２２は、債権保証処理のサブルーチンを起動する（ステップＳ６１０）。債権保証処理のサブルーチンは、所定の条件を満たす場合に仲介者１０が需要者５０に対して有する債権に対応する金額を、仲介者１０に支払う処理を行うサブルーチンである。債権保証処理のサブルーチンの処理の流れは後述する。

債権保証の支払済であると判定した場合（ステップＳ６０３でＹＥＳ）、ステップＳ６０７の終了後、未払理由が記録されていないと判定した場合（ステップＳ６０８でＮＯ）、回収不能報告が記録されていないと判定した場合（ステップＳ６０９でＮＯ）またはステップＳ６１０の終了後、サーバＣＰＵ２２は滞留記録ＤＢ４６のすべてのレコードの処理が終了したか否かを判定する（ステップＳ６１１）。

終了していないと判定した場合（ステップＳ６１１でＮＯ）、サーバＣＰＵ２２はカウンタＩに１を加算する（ステップＳ６１２）。サーバＣＰＵ２２はステップＳ６０２に戻る。終了したと判定した場合（ステップＳ６１１でＹＥＳ）、サーバＣＰＵ２２は処理を終了する。

図１２は、債権保証処理のサブルーチンの処理の流れを示すフローチャートである。債権保証処理のサブルーチンは、所定の条件を満たす場合に仲介者１０が需要者５０に対して有する債権に対応する金額を、仲介者１０に支払う処理を行うサブルーチンである。図１２を使用して、債権保証処理のサブルーチンの処理の流れを説明する。

サーバＣＰＵ２２は、処理中の滞留記録レコードの未払理由フィールドを参照して、債権保証理由に該当するか否かを判定する（ステップＳ６４１）。債権保証理由は、たとえば需要者５０の世帯主の死亡、行方不明または破産である。

保証理由に該当すると判定した場合（ステップＳ６４１でＹＥＳ）、サーバＣＰＵ２２は債権を抽出する（ステップＳ６４２）。具体的には、サーバＣＰＵ２２は、処理中のレコードのメータＩＤフィールドに記録されたメータＩＤをキーとして滞留記録ＤＢ４６を検索してレコードを抽出する。サーバＣＰＵ２２は、抽出したレコードのうち、支払済額フィールドに金額が記録されていないレコードを再抽出する。サーバＣＰＵ２２は、再抽出したレコードのうち、古いほうからたとえば３ヶ月分のレコードを再々抽出する。

サーバＣＰＵ２２は、仲介者１０への支払額を算出する（ステップＳ６４３）。具体的には、サーバＣＰＵ２２はステップＳ６４２で再々抽出したレコードの金額フィールドに記録されている金額に係数０．９を乗じた金額を算出する。サーバＣＰＵ２２は、各レコードの支払済額フィールドに金額額を記録する。

サーバＣＰＵ２２は、ステップＳ６４３で算出した支払額の合計を仲介者１０に支払う処理を行う（ステップＳ６４４）。サーバＣＰＵ２２は、その後処理を終了する。

保証理由に該当しないと判定した場合（ステップＳ６４１でＮＯ）、サーバＣＰＵ２２は処理中のレコードを滞留記録ＤＢ４６から削除する（ステップＳ６４５）。サーバＣＰＵ２２は、その後処理を終了する。

本実施の形態によると、需要者５０からの未収金の発生時に、仲介者１０の損失を低減することが可能になる。また、供給者３０は需要者５０の状況によらず供給した電力に対する料金を確実に回収することができる。そのため、地縁の薄い新興の供給者３０等であっても、電力小売市場への新規参入を果たしやすい。

［実施の形態２]
本実施の形態は、需要者５０に所定の事由が生じた場合に、電気料金の支払免除および見舞金の支給を行う情報処理システム７０等に関する。以後の説明では、支払免除および見舞金の支給を行うサービスを、付帯保証サービスと記載する。実施の形態１と共通する部分については、説明を省略する。

図１３は、実施の形態２の付帯保証金額ＤＢのレコードレイアウトを示す説明図である。付帯保証金額ＤＢは、本情報処理システム７０により電気料金を支払う需要者５０に対して電気料金を免除する条件と、免除する電気料金の上限額とを関連づけるＤＢである。付帯保証金額ＤＢは、理由フィールド、条件フィールド、免除金額上限フィールド、対象月数フィールドおよび見舞金額フィールドを有する。

理由フィールドには、支払免除または見舞金支給を行う理由が記録されている。条件フィールドには、支払免除または見舞金支給を行う条件が記録されている。免除金額上限フィールドには、条件が満たされた場合に免除する電気料金の上限が記録されている。対象月数フィールドには、条件が満たされた場合に免除する電気料金の月数が記録されている。見舞金額フィールドには、条件が満たされた場合に支給する見舞金の金額が記録されている。

具体例を挙げて説明する。たとえば、需要者５０が２０日以上４０日未満の入院をした場合、１５０００円を上限として１ヶ月分の電気料金を免除する。また、需要者５０が被災者生活再建支援法の対象になった場合には、４００００円の見舞金を支給する。

図１４は、実施の形態２の免除実績ＤＢのレコードレイアウトを示す説明図である。免除実績ＤＢは、需要者５０のメータＩＤと、電気料金免除理由、免除対象月および免除金額を記録するＤＢである。免除実績ＤＢは、年度フィールド、仲介契約ＩＤフィールド、仲介者フィールド、供給者フィールド、メータＩＤフィールド、理由フィールド、対象月フィールドおよび金額フィールドを有する。

年度フィールドには、記録対象の保証年度が記録されている。保証年度は、電気料金の免除を決定した日付を基準に定める。なお、免除した電気料金の請求日または支払期日を基準に保証年度を定めても良い。

仲介契約ＩＤフィールドには、仲介契約のＩＤ番号が記録されている。仲介者フィールドには、仲介者１０の名称が記録されている。供給者フィールドには、供給者３０の名称が記録されている。メータＩＤフィールドには、メータＩＤが記録されている。理由フィールドには、電気料金を免除した理由が記録されている。対象月フィールドには、免除した電気料金の対象月が記録されている。金額フィールドには免除した電気料金の金額が記録されている。免除実績ＤＢは一人の需要者５０の１ヶ月の電気料金の免除について、一つのレコードを有する。

図１５は、実施の形態２の必要書類ＤＢのレコードレイアウトを示す説明図である。必要書類ＤＢは、電気料金の支払免除および見舞金支給の理由と、それぞれに必要な書類とを関連づけるＤＢである。必要書類ＤＢは、理由フィールドと必要書類フィールドを有する。理由フィールドには、支払免除および見舞金支給の理由が記録されている。必要書類フィールドには、必要書類のリストが記録されている。

図１、図４および図１３から図１５を使用して、データおよび金銭の流れの概要を説明する。地域に密着して営業している仲介者１０は、需要者５０の入院、失業等に関する情報を入手することができる。また、仲介者１０は、営業地域で発生した自然災害に関する情報も、入手することができる。以後の説明では、入院、失業、自然災害等をまとめて事故と記載する。仲介者１０は、入力部１５を介して仲介者ＣＰＵ１２に事故に関する情報および必要な書類等を入力する。

仲介者ＣＰＵ１２は、サーバＣＰＵ２２に事故の発生を通知する。サーバＣＰＵ２２は、事故の内容を判定する。事故が条件を満たす自然災害である場合には、サーバＣＰＵ２２は図１３を使用して説明した付帯保証金額ＤＢに基づいて見舞金を支払うと判定する。

事故が需要者５０の入院または失業である場合には、サーバＣＰＵ２２は付帯保証金額ＤＢに示された上限金額および月数の範囲内かつ所定の年度内上限金額の範囲内で、需要者５０の電気料金を免除する処理を行う。所定の年度内上限金額は、たとえば４００００円である。

具体的には、需要者５０が免除対象の電気料金を支払済である場合には、サーバＣＰＵ２２は需要者５０に電気料金を返金する処理を行う。需要者５０が電気料金を支払わず、仲介者１０が立替処理を行っていない場合には、サーバＣＰＵ２２は需要者５０の電気料金の支払いを免除し、以後の請求を取りやめる処理を行う。需要者５０が電気料金を支払わず、仲介者１０が立替済である場合には、サーバＣＰＵ２２は仲介者１０に電気料金を返金する処理を行う。サーバＣＰＵ２２は、免除した電気料金を免除実績ＤＢに記録する。

図１６は、実施の形態２のプログラムの処理の流れを示すフローチャートである。図１６を使用して、プログラムの処理の流れを説明する。

仲介者ＣＰＵ１２は、入力部１５を介して取得した情報に基づいて、サーバＣＰＵ２２に事故の発生を通知する（ステップＳ６６１）。サーバＣＰＵ２２は、通知を受信する（ステップＳ６７１）。

サーバＣＰＵ２２は、事故が自然災害であるか否かを判定する（ステップＳ６７２）。自然災害であると判定した場合（ステップＳ６７２でＹＥＳ）、サーバＣＰＵ２２は事故が見舞金支給対象の自然災害であるか否かを判定する（ステップＳ６７３）。具体的には、サーバＣＰＵ２２は仲介者ＣＰＵ１２から取得した情報が、付帯保証金額ＤＢの条件フィールドに記録された「被災者生活再建支援法対象」の条件を満たすか否かを判定する。

なお、サーバＣＰＵ２２は需要者５０の住所等に基づいて、需要者５０が「被災者生活再建支援法対象」であるか否かを判定しても良い。このようにすることにより、広域かつ甚大な災害である場合にも速やかに需要者５０に対する見舞金の支払処理を行うことができる。

サーバＣＰＵ２２は、見舞金を仲介者１０の口座に振り込む処理をしても良い。たとえばＬＰガスボンベの点検のために仲介者１０が需要者５０を訪問する際に、現金で見舞金を持参する。このようにすることにより、需要者５０と仲介者１０との間の信頼関係の構築に寄与することができる。

支給対象であると判定した場合（ステップＳ６７３でＹＥＳ）、サーバＣＰＵ２２は付帯保証金額ＤＢの見舞金フィールドに記録された金額を、需要者５０の口座に振り込む処理を行う（ステップＳ６７４）。支給対象でないと判定した場合（ステップＳ６７３でＮＯ）およびステップＳ６７４の終了後、サーバＣＰＵ２２は処理を終了する。

事故が自然災害ではないと判定した場合（ステップＳ６７２でＮＯ）、サーバＣＰＵ２２は需要者５０のメータＩＤをキーとして、支払実績ＤＢから当該年度の支払実績レコードを抽出する。サーバＣＰＵ２２は、抽出したレコードの金額フィールドに記録されている支払済の金額の合計を算出し、年度内上限金額に達しているか否かを判定する（ステップＳ６８１）。上限金額に達していると判定した場合（ステップＳ６８１でＹＥＳ）、サーバＣＰＵ２２は処理を終了する。

上限金額に達していないと判定した場合（ステップＳ６８１でＮＯ）、サーバＣＰＵ２２は事故の理由をキーとして必要書類ＤＢを検索してレコードを抽出する。サーバＣＰＵ２２は必要書類フィールドに記録されているリストを取得する（ステップＳ６８２）。

サーバＣＰＵ２２は、リストに記載された書類を仲介者ＣＰＵ１２に要求する（ステップＳ６８３）。仲介者ＣＰＵ１２は、要求を受信する（ステップＳ６６２）。仲介者ＣＰＵ１２は、事前に仲介者１０により入力された書類のデータを取得し、サーバＣＰＵ２２に送信する（ステップＳ６６３）。

サーバＣＰＵ２２は、書類を受信する（ステップＳ６８４）。サーバＣＰＵ２２は、受信した書類の書式および記載事項を審査する（ステップＳ６８５）。サーバＣＰＵ２２は、電気料金免除の対象であるか否かを判定する（ステップＳ６８６）。具体的には、サーバＣＰＵ２２は、事故が付帯保証金額ＤＢの条件フィールドの条件に該当する場合に、電気料金免除の対象であると判定する。

対象ではないと判定した場合（ステップＳ６８６でＮＯ）、サーバＣＰＵ２２は処理を終了する。対象であると判定した場合（ステップＳ６８６でＹＥＳ）、サーバＣＰＵ２２は支払額算定のサブルーチンを起動する（ステップＳ６８７）。支払額算定のサブルーチンは、需要者５０の電気料金を免除するために、組合２０が支払う金額を算定するサブルーチンである。支払額算定のサブルーチンの処理の流れは後述する。

サーバＣＰＵ２２は、需要者５０が未払いの電気料金があるか否かを判定する（ステップＳ６８８）。具体的には、需要者５０のメータＩＤをキーとして滞留記録ＤＢ４６を検索してレコードを抽出する。レコードが抽出されない場合、サーバＣＰＵ２２は未払いの電気料金がないと判定する。

未払いの電気料金がないと判定した場合（ステップＳ６８８でＮＯ）、サーバＣＰＵ２２は支払額を需要者５０の口座に振り込む処理を行う（ステップＳ６８９）。未払いの電気料金があると判定した場合（ステップＳ６８８でＹＥＳ）、サーバＣＰＵ２２はその料金に対して実施の形態１で説明した債権保証済であるか否を判定する（ステップＳ６９０）。具体的には、抽出したレコードの支払済額フィールドに金額が記録されている場合には、サーバＣＰＵ２２は債権保証済であると判定する。

債権保証済でないと判定した場合（ステップＳ６９０でＮＯ）、仲介者１０が立替払いを行っている状態である。サーバＣＰＵ２２は、支払額を仲介者１０の口座に振り込む処理を行う（ステップＳ６９１）。

債権保証済であると判定した場合（ステップＳ６９０でＹＥＳ）、サーバＣＰＵ２２は電気料金と債権保証額との差額を仲介者１０に支払う処理を行う（ステップＳ６９２）。具体的には、サーバＣＰＵ２２は抽出したレコードの金額フィールドに記録されている金額と支払済額フィールドに記録されている金額との差額を仲介者１０の口座に振り込む処理を行う。

ステップＳ６８９、ステップＳ６９１またはステップＳ６９２の終了後、サーバＣＰＵ２２は免除実績ＤＢに支払額を記録する（ステップＳ６９３）。サーバＣＰＵ２２は、その後処理を終了する。

図１７は、実施の形態２の支払額算定のサブルーチンの処理の流れを示すフローチャートである。支払額算定のサブルーチンは、需要者５０の電気料金を免除するために、組合２０が支払う金額を算定するサブルーチンである。図１７を使用して、支払額算定のサブルーチンの処理の流れを説明する。

サーバＣＰＵ２２は、図１３を使用して説明した付帯保証金額ＤＢより検討中の事故に対応するレコードを取得する。サーバＣＰＵ２２は取得したレコードの免除金額上限フィールドおよび対象月数フィールドより、１回の事故で免除する電気料金の上限額および免除する月数を取得する（ステップＳ７０１）。

サーバＣＰＵ２２は、需要者５０のメータＩＤをキーとして図４を使用して説明した主請求情報ＤＢ４２を検索して、需要者５０の電気料金が記録されたレコードを抽出する。サーバＣＰＵ２２は、抽出したレコードから事故の発生した月から免除月数分のレコードを再抽出する。サーバＣＰＵ２２は、再抽出したレコードの金額フィールドから、需要者５０の免除対象月の電気料金を取得する（ステップＳ７０２）。

サーバＣＰＵ２２は、免除対象月の電気料金の合計額を算出する（ステップＳ７０３）。サーバＣＰＵ２２は、合計額がステップＳ７０１で取得した上限額以下であるか否かを判定する（ステップＳ７０４）。上限額以下である場合（ステップＳ７０４でＹＥＳ）、サーバＣＰＵ２２は、支払額はステップＳ７０３で算出した合計額であると判定する（ステップＳ７０５）。上限額を超える場合（ステップＳ７０４でＮＯ）、サーバＣＰＵ２２は、支払額はステップＳ７０１で取得した上限額であると判定する（ステップＳ７０６）。

サーバＣＰＵ２２は、需要者５０のメータＩＤおよび年度をキーとして図１４を使用して説明した免除実績ＤＢからレコードを抽出する。抽出されたレコードが存在する場合は、同じ需要者５０が同じ年度内に既に電気料金の免除を受けている。サーバＣＰＵ２２は、抽出したレコードの金額フィールドに記録された金額を合計して、同一年度の免除済額を算出する（ステップＳ７０７）。

サーバＣＰＵ２２は、ステップＳ７０５またはステップＳ７０６で判定した支払額と、ステップＳ７０７で算出した免除済額の合計値を算出する（ステップＳ７０８）。サーバＣＰＵ２２は、合計値が所定の年度内上限金額以下であるか否かを判定する（ステップＳ７０９）。

年度内上限金額以下であると判定した場合（ステップＳ７０９でＹＥＳ）、サーバＣＰＵ２２は処理を終了する。年度内上限金額を超えると判定した場合（ステップＳ７０９でＮＯ）、サーバＣＰＵ２２は、年度内上限金額からステップＳ７０７で算出した免除済額を減算した金額が支払額であると判定する（ステップＳ７１０）。その後、サーバＣＰＵ２２は処理を終了する。

本実施の形態によると、需要者５０に入院、失業等の事故が生じた場合に電気料金を免除し、自動振込等により支払済である場合には返金処理を行う情報処理システム７０を提供することができる。さらに、需要者５０が大きな自然災害の被災者となった場合に、見舞金を支給する処理を行う情報処理システム７０を提供することができる。

なお、図１３に示す電気料金免除の理由、条件等および図１５に示す必要書類はいずれも例示である。

［実施の形態３］
図１８は、実施の形態３の情報処理装置２１の動作を示す機能ブロック図である。情報処理装置２１は、サーバＣＰＵ２２による制御に基づいて以下のように動作する。

第１取得部９１は、需要者５０に対してユーザ１０が有する支払期限が過ぎた債権の金額を取得する。第２取得部９２は、債権の支払いが遅延した理由を取得する。判定部９３は、第２取得部９２が取得した理由が所定の遅延理由に該当するか否かを判定する。判定部９３が該当すると判定した場合には、支払部９４は、ユーザ１０に対して債権に対応する金額を支払う。

［実施の形態４］
実施の形態４は、汎用のコンピュータとプログラム４７とを組み合わせて動作させることにより、本実施の形態の情報処理システム７０を実現する形態に関する。図１９は、実施の形態４の情報処理システム７０の構成を示す説明図である。図１９を使用して、本実施の形態の構成を説明する。なお、実施の形態１と共通する部分の説明は省略する。

本実施の形態の情報処理システム７０は、サーバ２１、仲介者クライアント１１、供給者クライアント３１、金融機関クライアント６１、メータ５１およびこれらを接続するネットワーク２９を備える。

サーバ２１は、サーバＣＰＵ２２、主記憶装置２３、補助記憶装置２４、入力部２５、表示部２６、通信部２７および読取部２８を備える。読取部２８は、可搬型記録媒体４８を読み取る装置であり、具体的にはたとえばＳＤ（Secure Digital）カードスロット、光学ディスクドライブまたはＵＳＢ（Universal Serial Bus）ポート等である。

プログラム４７は、可搬型記録媒体４８に記録されている。サーバＣＰＵ２２は、読取部２８を介してプログラム４７を読み込み、補助記憶装置２４に保存する。またサーバＣＰＵ２２は、コンピュータ内に実装されたフラッシュメモリ等の半導体メモリ４９に記憶されたプログラム４７を読出しても良い。さらに、サーバＣＰＵ２２は、通信部２７およびネットワーク２９を介して接続される図示しない他のサーバコンピュータからプログラム４７をダウンロードして補助記憶装置２４に保存しても良い。

サーバＣＰＵ２２は、プログラム４７のうち仲介者ＣＰＵ１２が実行する部分を仲介者クライアント１１に送信する。サーバＣＰＵ２２は、プログラム４７のうち供給者ＣＰＵが実行する部分を供給者クライアント３１に送信する。サーバＣＰＵ２２は、プログラム４７のうち金融機関ＣＰＵが実行する部分を金融機関クライアント６１に送信する。

プログラム４７は、サーバ２１の制御プログラムとしてインストールされ、主記憶装置２３にロードして実行される。仲介者クライアント１１が受信したプログラム４７は、仲介者クライアント１１の制御プログラムとしてインストールされ、主記憶装置１３にロードして実行される。同様に、供給者クライアント３１および金融機関クライアント６１が受信したプログラム４７も、供給者クライアント３１のおよび金融機関クライアント６１の制御プログラムとしてインストールされ、図示しない主記憶装置にロードして実行される。これにより、サーバ２１、仲介者クライアント１１、供給者クライアント３１および金融機関クライアント６１は上述した情報処理システム７０として機能する。

各実施例で記載されている技術的特徴（構成要件）はお互いに組合せ可能であり、組み合わせすることにより、新しい技術的特徴を形成することができる。
今回開示された実施の形態はすべての点で例示であって、制限的なものではないと考えられるべきである。本発明の範囲は、上記した意味ではなく、特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。

１０ 仲介者（ユーザ）
１１ 仲介者クライアント
１２ 仲介者ＣＰＵ
１３ 主記憶装置
１４ 補助記憶装置
１５ 入力部
１６ 表示部
１７ 通信部
２０ 組合
２１ サーバ（情報処理装置）
２２ サーバＣＰＵ
２３ 主記憶装置
２４ 補助記憶装置
２５ 入力部
２６ 表示部
２７ 通信部
２８ 読取部
２９ ネットワーク
３０ 供給者
３１ 供給者クライアント
４１ 仲介契約ＤＢ
４２ 主請求情報ＤＢ
４３ 副請求情報ＤＢ
４４ 料金ＤＢ
４５ 入金情報ＤＢ
４６ 滞留記録ＤＢ
４７ プログラム
４８ 可搬型記憶媒体
４９ 半導体メモリ
５０ 需要者
５１ メータ
６１ 金融機関クライアント
７０ 情報処理システム

Claims (6)

1. 需要者に対してユーザが有する支払期限が過ぎた債権の金額を取得し、
   前記債権の支払いが遅延した理由を取得し、
   前記理由が所定の遅延理由に該当するか否かを判定し、
   該当すると判定した場合には、前記ユーザに対して前記債権に対応する金額を支払う
   処理をコンピュータに実行させるプログラム。
2. 前記債権は、前記需要者の電気料金に関する債権であり、
   前記所定の遅延理由は、前記需要者の死亡、行方不明または破産である
   請求項１に記載のプログラム。
3. 需要者に発生した事象を取得し、
   前記事象が前記需要者の入院または失業に該当するか否かを判定し、
   該当すると判定した場合に、前記需要者に対してユーザが有する債権の金額を取得し、
   前記需要者が前記債権を支払済であるか否かを判定し、
   支払済であると判定した場合には、需要者に対して前記債権に対応する金額を支払い、
   支払済でないと判定した場合には、ユーザに対して前記債権に対応する金額を支払う
   請求項１または請求項２に記載のプログラム。
4. 需要者に対してユーザが有する支払期限が過ぎた債権の金額を取得し、
   前記債権の支払いが遅延した理由を取得し、
   前記理由が所定の遅延理由に該当するか否かを判定し、
   該当すると判定した場合には、前記ユーザに対して前記債権に対応する金額を支払う
   処理をコンピュータに実行させる情報処理方法。
5. 需要者に対してユーザが有する支払期限が過ぎた債権の金額を取得する第１取得部と、
   前記債権の支払いが遅延した理由を取得する第２取得部と、
   前記理由が所定の遅延理由に該当するか否かを判定する判定部と、
   該当すると判定した場合に前記ユーザに対して前記債権に対応する金額を支払う支払部と
   を備える情報処理装置。
6. 需要者にインフラを供給する供給者、前記需要者と前記供給者との間の料金収受を仲介するユーザおよび複数の前記ユーザが加入する組合の各情報処理装置をネットワークを介して接続して行う情報処理方法において、
   前記供給者の情報処理装置は、前記需要者のインフラ使用状況に応じた料金情報を前記ユーザの各情報処理装置に送信し、
   前記ユーザの情報処理装置は、前記料金情報に基づいて前記供給者に対して料金を支払う処理を行うとともに、前記需要者からユーザに対する料金の支払状況を取得し、
   前記需要者から前記ユーザに対する料金の支払いが行われていない場合には、前記ユーザの情報処理装置は前記組合の情報処理装置に需要者に対する債権に関する情報を送信し、
   前記組合の情報処理装置は、前記債権の支払が遅延した理由を取得して、前記理由が所定の遅延理由に該当するか否かを判定し、
   該当すると判定した場合には、前記組合の情報処理装置は、前記ユーザに対して前記債権に対応する金額を支払う処理を実行する情報処理方法。

Images