特開 2024-130187 銀行システム、銀行システムによって実行される方法、及びプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024130187

(43)【公開日】2024-09-30

(54)【発明の名称】銀行システム、銀行システムによって実行される方法、及びプログラム

(51)【国際特許分類】

   G06Q 40/02 20230101AFI20240920BHJP

【ＦＩ】

G06Q40/02

【審査請求】有

【請求項の数】9

【出願形態】ＯＬ

(21)【出願番号】P 2023039767

(22)【出願日】2023-03-14

(71)【出願人】

【識別番号】397077955

【氏名又は名称】株式会社三井住友銀行

(74)【代理人】

【識別番号】110001243

【氏名又は名称】弁理士法人谷・阿部特許事務所

(72)【発明者】

【氏名】中井 瞳

(72)【発明者】

【氏名】渋江 直樹

(72)【発明者】

【氏名】山本 高久

【テーマコード（参考）】

5L040

5L055

【Ｆターム（参考）】

5L040BB39

5L055BB39

(57)【要約】

【課題】支払データの内容に基づいて複数の支払処理フローの中から適切なものを選択し、振込や口座振替などの資金移動処理を実行する。
【解決手段】銀行システムは、読みだした支払データが管理組合の支払承認を必要とするデータであるのかどうかを判定し、支払データに含まれる出金元口座が自行の口座を示すか、または他行の口座を示すかを判定する。銀行システムは、この２つの判定処理の結果に基づき４種類の支払処理の実行を制御する。４種類の支払処理は、（１）自行の保管口座からの支払処理、（２）他行の保管口座からの支払処理、（３）自行の収納口座からの支払処理、及び（４）他行の収納口座からの支払処理を含む。（１）と（２）の支払処理の際、管理組合の承認者に対して支払承認を依頼し、（３）と（４）の支払処理の際、管理組合の承認者に対して支払実行を通知する。
【選択図】図６

【特許請求の範囲】

【請求項1】

区分所有建物の管理会社向けのＥＢサービスを実行する銀行システムであって、
記憶部及び制御部を備え、
前記制御部が、
前記記憶部から読みだした支払データが管理組合の支払承認を必要とするデータであるのかどうかを判定するステップと、
前記支払データに含まれる出金元口座が自行の口座を示すか、または他行の口座を示すかを判定するステップと、
前記支払データが管理組合の支払承認を必要とするデータであると判定され、かつ前記支払データに含まれる出金元口座が自行の口座を示すと判定されたことに応答して、自行の保管口座からの支払処理を選択して実行するステップと、
前記支払データが管理組合の支払承認を必要とするデータであると判定され、かつ前記支払データに含まれる出金元口座が他行の口座を示すと判定されたことに応答して、他行の保管口座からの支払処理を選択して実行するステップと、
前記支払データが管理組合の支払承認を必要としないデータであると判定され、かつ前記支払データに含まれる出金元口座が自行の口座を示すと判定されたことに応答して、自行の収納口座からの支払処理を選択して実行するステップと、
前記支払データが管理組合の支払承認を必要としないデータであると判定され、かつ前記支払データに含まれる出金元口座が他行の口座を示すと判定されたことに応答して、他行の収納口座からの支払処理を選択して実行するステップと
を実行する銀行システム。

【請求項2】

前記自行の保管口座からの支払処理を選択して実行するステップは、
前記制御部が、
前記管理組合に関連付けられる承認者に対して前記支払データに対する支払依頼を実行することと、
全ての前記承認者が前記支払依頼に対して支払承認したという条件で、前記支払データに基づいて振込電文を生成して振込処理を実行することと
を実行することを含む、請求項１に記載の銀行システム。

【請求項3】

前記銀行システムは、外部ネットワークと通信するための通信部をさらに備え、
前記他行の保管口座からの支払処理を選択して実行するステップは、
前記制御部が、
前記管理組合に関連付けられる承認者に対して前記支払データに対する支払依頼を実行することと、
全ての前記承認者が前記支払依頼に対して支払承認したという条件で、前記支払データに基づいて口座振替電文を生成し、前記通信部を介して前記口座振替電文の出金元口座に関連付けられる金融機関システムに対して前記口座振替電文を送信することと、
前記口座振替電文に基づく処理が成功裏に完了したことを示す電文を前記通信部を介して前記金融機関システムから受信したことに応答して、前記支払データに基づいて振込電文を生成して振込処理を実行することと
を実行することを含む、請求項１に記載の銀行システム。

【請求項4】

前記口座振替電文の入金先口座は、前記銀行システムに関連付けられるプール口座である、請求項３に記載の銀行システム。

【請求項5】

前記自行の収納口座からの支払処理を選択して実行するステップは、
前記制御部が、
前記管理組合に関連付けられる承認者に対して前記支払データに基づく支払が行われることを通知することと、
前記支払データに基づいて振込電文を生成して振込処理を実行することと
を実行することを含む、請求項１に記載の銀行システム。

【請求項6】

前記銀行システムは、外部ネットワークと通信するための通信部をさらに備え、
前記他行の収納口座からの支払処理を選択して実行するステップは、
前記制御部が、
前記管理組合に関連付けられる承認者に対して前記支払データに基づく支払が行われることを通知することと、
前記支払データに基づいて口座振替電文を生成し、前記通信部を介して前記口座振替電文の出金元口座に関連付けられる金融機関システムに対して前記口座振替電文を送信することと、
前記口座振替電文に基づく処理が成功裏に完了したことを示す電文を前記通信部を介して前記金融機関システムから受信したことに応答して、前記支払データに基づいて振込電文を生成して振込処理を実行することと
を実行することを含む、請求項１に記載の銀行システム。

【請求項7】

前記口座振替電文の入金先口座は、前記銀行システムに関連付けられるプール口座である、請求項６に記載の銀行システム。

【請求項8】

区分所有建物の管理会社向けのＥＢサービスを提供する銀行システムによって実行される方法であって、
記憶部及び制御部を備え、
前記制御部が、
前記記憶部から読みだした支払データが管理組合の支払承認を必要とするデータであるのかどうかを判定するステップと、
前記支払データに含まれる出金元口座が自行の口座を示すか、または他行の口座を示すかを判定するステップと、
前記支払データが管理組合の支払承認を必要とするデータであると判定され、かつ前記支払データに含まれる出金元口座が自行の口座を示すと判定されたことに応答して、自行の保管口座からの支払処理を選択して実行するステップと、
前記支払データが管理組合の支払承認を必要とするデータであると判定され、かつ前記支払データに含まれる出金元口座が他行の口座を示すと判定されたことに応答して、他行の保管口座からの支払処理を選択して実行するステップと、
前記支払データが管理組合の支払承認を必要としないデータであると判定され、かつ前記支払データに含まれる出金元口座が自行の口座を示すと判定されたことに応答して、自行の収納口座からの支払処理を選択して実行するステップと、
前記支払データが管理組合の支払承認を必要としないデータであると判定され、かつ前記支払データに含まれる出金元口座が他行の口座を示すと判定されたことに応答して、他行の収納口座からの支払処理を選択して実行するステップと
を備える方法。

【請求項9】

請求項８に記載の方法をコンピュータに実行させるためのプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、区分所有建物管理会社向けのＥＢ（エレクトロニックバンキング）サービスの支払スキームを実行する銀行システム、銀行システムによって実行される方法、及びプログラムに関する。

【背景技術】

【0002】

分譲マンションや商業ビルなどの区分所有建物では、区分所有者が建物および敷地等の管理を行うために管理組合が結成されており、管理組合の理事会が組合業務を執行している。管理組合は、区分所有建物の管理業務を管理会社に委託しており、管理会社は、区分所有建物の管理業務、例えば、設備の保守・点検、防火・警備などの作業実施、あるいは、管理費や修繕積立金の徴収、諸料金の支払いなどの支払事務を行っている。

【0003】

管理会社は、管理組合の資金を管理の目的に応じて「収納口座」及び「保管口座」の２種類の口座に分けて管理している。「収納口座」は、受領した資金を一時的に管理するための口座であり、毎月の管理事務費の支払は収納口座から支払われる。収納口座からの支払は管理組合による都度の支払承認は不要であり、毎月の支払後の収納口座の残高は、翌月内に保管口座に資金移動される。「保管口座」は、区分所有者から受領した修繕積立金及び収納口座から資金移動された資金を預貯金として管理するための口座であり、その支出には管理組合の承認が必要となる。

【0004】

保管口座からの支払には理事会の承認が必要となるが、これらの手続きをサポートする仕組みとして特許文献１のような技術が知られている。このようなサービスを利用しない場合には、口座種別に基づいてそれぞれの口座の金融機関が提供するＥＢサービスなどを利用して個別に支払いを行っていた。

【先行技術文献】

【特許文献】

【0005】

【特許文献1】特許５８５２６３６号公報

【発明の概要】

【発明が解決しようとする課題】

【0006】

しかしながら、特許文献１に記載されている技術は、信託口座を利用するスキームに対応しており、汎用的な仕組みではなかった。信託口座を利用すると、管理会社に信託指図等の事務コストが発生してしまうため事務コストが大きくなってしまい、金融機関の側でも信託関連の事務コストが過大となっていた。

【0007】

従来は、管理組合が保有する口座ごとに個別のＥＢサービスを利用していたため、管理会社及び管理組合の作業や手続きが煩雑であった。また、それぞれの支払処理に対して必要となる管理組合の承認を受ける機能についても個別に対応せざるを得なかった。

【0008】

従来のＥＢサービスには、管理組合の口座がどの金融機関のものであっても支払対応できる機能がなく、かつ支払承認の要否により管理組合の承認を受けられる機能がなかった。管理会社によっては、支払承認を得るために管理組合の承認者まで伝票等を持参して承認を得ていた。このため、同一のＥＢサービス内で複数の支払フローを制御する機能がなかった。

【0009】

本発明は、このような課題を解決するためになされたものであり、支払データの内容に基づいて複数の支払処理フローの中から適切なものを選択し、振込や口座振替などの資金移動処理の実行を制御する統一されたシステムインターフェースを提供する、区分所有建物の管理会社向けのＥＢサービスを実行する銀行システム、銀行システムによって実行される方法、及びプログラムを提供することを目的とする。

【課題を解決するための手段】

【0010】

本発明の一態様である銀行システムは、区分所有建物の管理会社向けのＥＢサービスを実行する銀行システムであって、
記憶部及び制御部を備え、
前記制御部が、
前記記憶部から読みだした支払データが管理組合の支払承認を必要とするデータであるのかどうかを判定するステップと、
前記支払データに含まれる出金元口座が自行の口座を示すか、または他行の口座を示すかを判定するステップと、
前記支払データが管理組合の支払承認を必要とするデータであると判定され、かつ前記支払データに含まれる出金元口座が自行の口座を示すと判定されたことに応答して、自行の保管口座からの支払処理を選択して実行するステップと、
前記支払データが管理組合の支払承認を必要とするデータであると判定され、かつ前記支払データに含まれる出金元口座が他行の口座を示すと判定されたことに応答して、他行の保管口座からの支払処理を選択して実行するステップと、
前記支払データが管理組合の支払承認を必要としないデータであると判定され、かつ前記支払データに含まれる出金元口座が自行の口座を示すと判定されたことに応答して、自行の収納口座からの支払処理を選択して実行するステップと、
前記支払データが管理組合の支払承認を必要としないデータであると判定され、かつ前記支払データに含まれる出金元口座が他行の口座を示すと判定されたことに応答して、他行の収納口座からの支払処理を選択して実行するステップと
を実行する。

【発明の効果】

【0011】

管理組合がどの金融機関の口座を保有していたとしても、管理会社は、支払データの内容に基づいて複数の支払処理フローの中から適切なものを選択し、振込や口座振替などの資金移動処理の実行を制御する統一されたシステムインターフェースを利用できるようになる。また、管理会社は、統一されたシステムインターフェースを利用して管理組合の承認を容易に得られるようになる。

【図面の簡単な説明】

【0012】

本明細書において開示される実施形態の詳細な理解は、添付図面に関連して例示される以下の説明から得ることができる。

【図1】銀行システム１０、他行システム１１、管理会社端末１２、管理組合端末１３、及び請求業者サーバ１４を含むシステム全体の構成図である。

【図2】銀行システム１０のシステム構成図である。

【図3】管理会社マスタ１０６のデータ構造の一例を示す図である。

【図4】管理組合マスタ１０７のデータ構造の一例を示す図である。

【図5】支払データ１０８のデータ構造の一例を示す図である。

【図6】銀行システム１０によって実行される４種類の処理フローの選択処理を概説する図である。

【図7】業者からの請求に対して自行の保管口座から支払いを実行する第１の処理フローを説明する図である。

【図8】業者からの請求に対して他行の保管口座からの支払いを実行する第２の処理フローを説明する図である。

【図9】業者からの請求に対して自行の収納口座から支払いを実行する第３の処理フローを説明する図である。

【図10】業者からの請求に対して他行の収納口座からの支払いを実行する第４の処理フローを説明する図である。

【図11】銀行システム１０によって提供される支払承認画面の一例を示す図である。

【発明を実施するための形態】

【0013】

（全体構成）
図１は、本発明の実施形態に係る銀行システム１０、他行システム１１、管理会社端末１２、管理組合端末１３及び請求業者サーバ１４を含むシステム全体の構成図である。銀行システム１０は、ネットワーク１５を介して管理会社端末１２及び管理組合端末１３と相互に通信可能に接続されており、ネットワーク１６を介して他行システム１１と相互に通信可能に接続されている。図１では、管理会社端末１２と請求業者サーバ１４がネットワークを介して接続される構成を点線で示しているが、これは管理会社端末１２が、必ずしも請求業者サーバ１４とネットワークを介して接続される必要はないことを示している。図１では、説明の簡便化のため、他行システム１１、管理会社端末１２、管理組合端末１３及び請求業者サーバ１４は１つずつしか示されていないが、これらは複数存在し得る。ネットワーク１５、１６はインターネットなどの既知の通信網であってよい。

【0014】

本明細書では、銀行システム１０を１つのシステムあるいは装置として説明するが、銀行システム１０によって実行される様々な処理機能を複数のシステムあるいは装置で分散して実行するように構成してもよい。

【0015】

銀行システム１０は、その内部に口座情報を保有し、資金移動処理、例えば、振込処理、口座振替処理を実行する。口座振替処理を実行する際、銀行システム１０は、収納代行サービス会社のシステムと連携して口座振替に関する一連の処理を実行することができる。銀行システム１０が保有する口座には、管理組合名義の口座及び銀行自身の一時保管口座が含まれており、銀行システム１０は、資金移動依頼電文、例えば、振込依頼電文、口座振替依頼電文に基づいて処理対象口座に対する入金処理及び出金処理を行い、処理結果を依頼元に送信することができる。銀行システム１０は、入金処理及び出金処理の結果、口座残高のアップデートを行うとともに、入出金情報を登録する。

【0016】

銀行システム１０は、区分所有建物に対して設置された管理組合の情報、及び管理組合から区分所有建物の管理業務を受託している管理会社の情報を保有している。管理組合の情報には、保管口座や収納口座の情報、費用支出の際の承認者、承認人数、承認フローの情報、他行から口座振替処理で引き落として資金移動した資金をプールするための一時保管口座の情報、及び委託している管理会社の情報などが含まれている。管理会社の情報には、管理会社の名称、所在地、連絡先などの情報が含まれている。

【0017】

銀行システム１０は、管理会社端末１２によって登録された支払データの内容に基づいて以下の支払処理のうちいずれか１つを当該支払データに対して実行することができる。
（１）自行の保管口座（承認要）からの支払処理
（２）他行の保管口座（承認要）からの支払処理
（３）自行の収納口座（承認不要）からの支払処理
（４）他行の収納口座（承認不要）からの支払処理
このような支払処理の実行を銀行システム１０が制御することが可能になることにより、管理組合がどの金融機関の口座を保有していたとしても、管理会社は、支払データの内容に基づいて複数の支払処理フローの中から適切なものを選択し、振込や口座振替などの資金移動処理の実行を制御する統一されたシステムインターフェースを利用できるようになる。

【0018】

他行システム１１は、その内部に口座情報を保有し、資金移動処理、例えば、振込処理、口座振替処理を実行することができる。他行システム１１が保有する口座には、管理組合名義の口座が含まれており、他行システム１１は、資金移動依頼電文、例えば、振込依頼電文、口座振替依頼電文に基づいて処理対象口座に対する入金処理及び出金処理を行い、処理結果を依頼元に送信することができる。他行システム１１は、入金処理及び出金処理の結果、口座残高のアップデートを行うとともに、入出金情報を登録する。

【0019】

管理会社端末１２は、請求業者から受領した請求書、あるいは請求業者サーバ１４から受信した請求書データに基づいて入力した請求書情報を銀行システム１０に送信する。管理会社端末１２は、管理会社によって使用される端末であり、パーソナルコンピュータ（ＰＣ）やタブレット型端末などの通信機能を備えたコンピュータとすることができるが、特定の装置やデバイスに限定されることはない。

【0020】

管理組合端末１３は、支払承認が必要な支払データを受信し、支払についての承認可否を登録することにより、銀行システム１０に格納されている支払データをアップデートする。管理組合端末１３は、管理組合によって使用される端末であり、パーソナルコンピュータ（ＰＣ）やタブレット型端末などの通信機能を備えたコンピュータとすることができるが、特定の装置やデバイスに限定されることはない。

【0021】

請求業者サーバ１４は、管理組合に対する請求書を発行し、あるいは、管理組合に対する請求書データを生成して管理会社端末１２に送信することができる。発行された請求書は、郵送などの任意の手段によって管理会社に送付されてよい。

【0022】

（銀行システム１０の機能構成）
銀行システム１０は、区分所有建物の管理会社向けのＥＢサービスを実行する。銀行システム１０によって提供される本サービスの様々な処理機能、すなわち、
・請求書情報の登録処理、支払データ生成処理
・承認要の支払データの承認処理
・出金元口座が他行である場合の口座振替及び振込処理
・出金元口座が自行である場合の振込処理
を概説する。

【0023】

（請求書情報の登録処理、支払データ生成処理）
銀行システム１０は、管理会社端末１２からのアクセスに応答して、請求書情報登録画面（不図示）を管理会社端末１２に提供する。管理会社は、請求業者から受領した請求書の記載内容に基づいて、請求書情報登録画面を介して、管理組合の出金元口座、業者の入金先口座、支払金額、支払内容、出金予定日、入金予定日、及び（必要に応じて）承認フラグ、承認期限などの請求書情報を入力する。出金元口座が管理組合にとって保管口座として登録されている場合には、銀行システム１０は、自動的に承認フラグに値をセットし、承認期限などの情報入力を管理会社端末１２に要求する。入力作業完了後、銀行システム１０は、請求書情報を管理会社端末１２から受信する。

【0024】

請求書データが請求業者サーバ１４から電子的に受信している場合、管理会社端末１２は、請求書データの情報を読み込み、読み込んだ情報を請求書情報登録画面に反映させ、請求書情報を銀行システム１０に送信する。

【0025】

銀行システム１０は、受信した請求書情報に基づいて支払いデータを生成し、支払データ１０８に格納する。

【0026】

（承認要の支払データの承認処理）
銀行システム１０は、支払データの承認フラグの値が「要」になっているかどうかを判定する。承認フラグの値が「要」になっている場合、銀行システム１０は、管理組合の承認人数と承認フロー情報を参照して、管理組合端末１３に対して未承認の支払データが存在していることを通知し、当該支払データを管理組合端末１３に提供する。支払データの提供は、管理組合端末１３が銀行システム１０にアクセスしたことに応答して提供される支払承認画面（図１１）を通じて行ってよい。管理組合端末１３は、支払承認画面上で支払データに対する承認処理を行う（例えば、対象の支払データを選択して承認ボタン押下、など）。承認処理が完了すると、銀行システム１０は完了通知を管理組合端末１３から受信する。これらの承認処理は、管理組合が設定した承認人数分行われ、管理組合によって設定された承認者の順番で承認処理が行われてもよいし、管理組合によって設定された承認者に対して同時に承認依頼が行われて承認処理が行われてもよい。

【0027】

銀行システム１０は、支払データに対する承認処理が完了した通知を受信すると、当該支払データの承認フラグを「済」にアップデートする。

【0028】

（出金元口座が他行である場合の口座振替及び振込処理）
銀行システム１０は、支払データの出金元口座が他行口座を示す場合、出金日のＮ日前（Ｎは任意の自然数）に支払データに含まれている出金元口座、一時保管口座、及び支払金額の情報に基づいて口座振替電文を生成する。銀行システム１０は、出金元口座の銀行コードに関連付けられる他行システム１１に対して口座振替電文を送信する。口座振替処理は、収納代行業者を介して行われてよい。

【0029】

他行システム１１は、受信した口座振替電文に基づいて出金元口座から支払金額を引き落とす口座振替処理を実行する。他行システム１１は、口座振替処理が成功裏に完了したか否かを示す電文を銀行システム１０に送信する。銀行システム１０は、口座振替処理が成功裏に完了した場合、一時保管口座に支払金額を入金処理する。

【0030】

銀行システム１０は、入金日のＮ日前（Ｎは任意の自然数）に支払データに含まれている一時保管口座、入金先口座、及び支払金額の情報に基づいて振込電文を生成する。銀行システム１０は、振込電文に基づいて振込処理を実行する。

【0031】

銀行システム１０は、振込処理が成功裏に完了した場合には、振込依頼人に対して処理完了を示す電文を送信し、一方、振込処理が成功しなかった場合には、処理ができなかった理由を含む電文を送信する。

【0032】

（出金元口座が自行である場合の振込処理）
銀行システム１０は、支払データの出金元口座が自行口座を示す場合、出金日のＮ日前（Ｎは任意の自然数）に支払データに含まれている出金元口座、入金先口座、及び支払金額の情報に基づいて振込電文を生成する。銀行システム１０は、振込電文に基づいて振込処理を実行する。

【0033】

銀行システム１０は、振込処理が成功裏に完了した場合には、振込依頼人に対して処理完了を示す電文を送信し、一方、振込処理が成功しなかった場合には、処理ができなかった理由を含む電文を送信する。

【0034】

なお、本明細書において「Ｎ」という文字を、例えば「出金日のＮ日前」「入金日のＮ日前」のような表現で使用しているが、これらの「Ｎ」は同じ数字を示す必要はないことを了解されたい。この「Ｎ」は任意の値を示すに過ぎない。

【0035】

（銀行システム１０のシステム構成）
次に、銀行システム１０のシステム構成を説明する。図２は、本発明の実施形態に係る銀行システム１０のシステム構成図である。図２に示すように、銀行システム１０は、一般的なコンピュータと同様に、バス１２０などによって相互に接続された制御部１０１、主記憶部１０２、補助記憶部１０３、インターフェース（ＩＦ）部１０４、及び出力部１０５を備える。補助記憶部１０３は、銀行システム１０の各機能を実装するプログラム、及び当該プログラムで取り扱うデータを格納する。

【0036】

補助記憶部１０３は、ファイル／データベースなどの形式で、管理会社マスタ１０６、管理組合マスタ１０７、支払データ１０８、口座情報１０９及び入出金情報１１０を備える。銀行システム１０は、管理会社マスタ１０６、管理組合マスタ１０７、支払データ１０８、口座情報１０９及び入出金情報１１０に格納されている情報を読み出し、及び／または更新できる。補助記憶部１０３に格納されている各プログラムは、銀行システム１０によって実行される。

【0037】

制御部１０１は、中央処理装置（ＣＰＵ）とも呼ばれ、銀行システム１０の各構成要素の制御やデータの演算を行い、また、補助記憶部１０３に格納されている各種プログラムを主記憶部１０２に読み出して実行する。主記憶部１０２は、メインメモリとも呼ばれ、受信した各種データ、コンピュータ実行可能な命令及び当該命令による演算処理後のデータなどを記憶する。補助記憶部１０３は、ハードディスク（ＨＤＤ）などに代表される記憶装置であり、データやプログラムを長期的に保存する際に使用される。

【0038】

図２の実施形態は、制御部１０１、主記憶部１０２及び補助記憶部１０３を同一のコンピュータの内部に設ける実施形態について説明するが、他の実施形態として、銀行システム１０は、制御部１０１、主記憶部１０２及び補助記憶部１０３を複数個使用することにより、複数のコンピュータによる並列分散処理を実現するように構成することもできる。また、他の実施形態として、銀行システム１０のための複数のサーバを設置し、複数のサーバが一つの補助記憶部１０３を共有する実施形態にすることも可能である。

【0039】

ＩＦ部１０４は、他のシステムや装置との間でデータを送受信する際のインターフェースの役割を果たし、また、システムオペレータから各種コマンドや入力データ（各種マスタ、テーブルなど）を受け付けるインターフェースを提供する。出力部１０５は、処理されたデータを表示する表示画面や当該データを印刷するための印刷手段などを提供する。

【0040】

管理会社マスタ１０６は、区分所有建物の管理組合から業務委託されている管理会社の情報を格納する。図３は、本発明の実施形態に係る管理会社マスタ１０６のデータ構造の一例を示す図である。管理会社マスタ１０６は、管理会社ＩＤ３０１、管理会社名称３０２、及び管理会社情報３０３を含むことができるが、これらのデータ項目に限定されることはなく他のデータ項目も含むことができる。

【0041】

管理会社ＩＤ３０１は、管理会社を識別する識別子である。管理会社名称３０２は、管理会社の名称を示す。管理会社情報３０３は、管理会社の所在地、連絡先などの情報を示す。

【0042】

図２に戻って説明すると、管理組合マスタ１０７は、区分所有建物に対して設置されている管理組合の情報を格納する。図４は、本発明の実施形態に係る管理組合マスタ１０７のデータ構造の一例を示す図である。管理組合マスタ１０７は、管理組合ＩＤ４０１、管理組合名称４０２、保管口座４０３、収納口座４０４、一時保管口座４０５、承認人数４０６、承認フロー情報４０７、及び管理会社ＩＤ３０１を含むことができるが、これらのデータ項目に限定されることはなく他のデータ項目も含むことができる。

【0043】

管理組合ＩＤ４０１は、管理組合を識別する識別子である。管理組合名称４０２は、管理組合の名称を示す。保管口座４０３は、管理組合が利用する銀行口座のうちの保管口座の情報を示し、具体的には、銀行コード、支店コード、科目、口座番号、口座名称を示す。収納口座４０４は、管理組合が利用する銀行口座のうちの収納口座を示し、具体的には、銀行コード、支店コード、科目、口座番号、口座名称を示す。

【0044】

一時保管口座４０５は、他行に存在する管理組合名義の銀行口座から口座振替した資金を銀行システム１０内で一時保管する口座の情報を示す。承認人数４０６は、支払内容が管理組合の承認を必要とする場合に、管理組合内で承認を必要とする人数を示す。承認フロー情報４０７は、管理組合内で承認をする順番及び承認者の連絡先情報を示す。例えば、承認フロー情報４０７は、「１：Ａさんのメールアドレス」「２：Ｂさんのメールアドレス」などの情報を含み、数値が承認順序を示す。管理会社ＩＤ３０１は、管理組合が業務を委託している管理会社の識別子を示す。

【0045】

図２に戻って説明すると、支払データ１０８は、業者から受領した請求書あるいは受信した請求書データに基づいて生成された支払データを格納する。図５は、本発明の実施形態に係る支払データ１０８のデータ構造の一例を示す図である。支払データ１０８は、管理会社ＩＤ３０１、管理組合ＩＤ４０１、支払ＩＤ５０１、出金日５０２、入金日５０３、出金元口座５０４、入金先口座５０５、支払金額５０６、支払内容５０７、承認フラグ５０８、承認期限５０９、請求書５１０、及び一時保管口座４０５を含むことができるが、これらのデータ項目に限定されることはなく他のデータ項目も含むことができる。

【0046】

管理会社ＩＤ３０１および管理組合ＩＤ４０１は、支払データに関連付けられる管理会社及び管理組合の識別子である。支払ＩＤ５０１は、支払データを識別する識別子である。出金日５０２は、出金元口座から出金処理を行う予定日を示す。入金日５０３は、入金先口座に対して入金処理を行う予定日を示す。資金移動処理の内容に応じて、出金日５０２及び入金日５０３の日付は同じ場合もあるし、異なる場合もある。

【0047】

出金元口座５０４は、業者などからの請求に対する支払を行う口座の情報を示す。入金先口座５０５は、業者などからの請求書に記載されている業者などの口座情報を示す。出金元口座５０４及び入金先口座５０５はともに、銀行コード、支店コード、科目、口座番号、口座名称の情報を含む。支払金額５０６は、請求書に記載されている支払金額及び（必要な場合）振込手数料を示す。支払内容５０７は、支払の対象となった取引の詳細を示す。

【0048】

承認フラグ５０８は、支払に対して管理組合の承認が必要かどうか、および承認処理が完了したかどうかを示すフラグである。例えば、承認フラグ５０８の値は「要」「承認中」「済」などであってよい。承認期限５０９は、管理組合による支払内容の承認完了の期限を示す。請求書５１０は、業者から受領した請求書の電子データ（例えば、ＰＤＦデータ）を示す。一時保管口座４０５は、上述したように、他行に存在する管理組合名義の銀行口座から口座振替した資金を一時保管する口座情報を示す。一時保管口座４０５は、管理会社及び管理組合の組み合わせごとに異なる口座を利用してもよいし、どの管理会社及び管理組合の組み合わせでも同一の口座を利用してもよい。

【0049】

図２に戻って説明すると、口座情報１０９は、銀行システム１０を保有する銀行等によって維持される口座であり、具体的には、銀行コード、支店コード、科目、口座番号、口座名称、残高情報などを含むことができるが、これらのデータ項目に限定されることはなく他のデータ項目も含むことができる。入出金情報１１０は、口座に対して行われる入出金取引の情報を格納する。銀行システム１０が入金処理及び／または出金処理を行う度に、銀行システム１０は、口座情報１０９及び入出金情報１１０に対してデータを登録し、あるいはアップデートする。

【0050】

（各種フローについての説明）
図６～図１０を参照しながら、請求書情報の登録から支払処理完了までの４種類の処理フローを説明する。まず、図６を参照しながら４種類の処理フローの選択を制御する処理を概説し、その後、図７～図１０の処理フローを参照しながら銀行システム１０によって実行される処理を説明する。

【0051】

（４種類の処理フローの選択処理の概説）
図６は、銀行システム１０によって実行される４種類の処理フローの選択処理を概説する図である。本発明では、銀行システム１０が、以下の４種類のケースの支払処理を統一されたシステムインターフェースで実行することができる。
・第１の処理フロー：自行の保管口座（承認要）からの支払処理
・第２の処理フロー：他行の保管口座（承認要）からの支払処理
・第３の処理フロー：自行の収納口座（承認不要）からの支払処理
・第４の処理フロー：他行の収納口座（承認不要）からの支払処理
４種類の処理フローを実施する前提となる支払データの生成処理、並びに承認の有無及び出金元口座の判定処理（Ｓ６０１～Ｓ６０４、Ｓ６０７の処理）は共通であるので、図６を参照しながらそれらの処理を説明し、それ以降の処理については図７～図１０の処理フローを参照しながら説明する。

【0052】

Ｓ６０１にて、管理会社端末１２からのアクセスに応答して、銀行システム１０は、請求書情報登録画面（不図示）を管理会社端末１２に提供する。請求書情報登録画面は、請求書の情報が登録された所定のフォーマットのファイルをアップロードして必要な情報をそれぞれの項目にセットするように構成されていてもいいし、画面上に請求書の情報を登録するそれぞれの項目が設けられていて画面上で情報を直接入力するように構成されていてもよい。

【0053】

請求業者と管理会社の請求書のやり取りは、電子データで行われる場合もあれば、紙ベースで行われる場合もある。前者の場合であれば、請求業者サーバ１４が所定のフォーマットに従って請求書データを生成して管理会社端末１２に送信しておけば、管理会社端末１２は、請求書情報登録画面でファイルをアップロードすることにより請求書の情報を登録することができる。後者の場合であれば、管理会社の担当者は、紙ベースの請求書を参照しながら請求書情報登録画面のそれぞれの項目に請求書の情報を登録することができる。

【0054】

請求書の情報を登録する際、管理会社の担当者は、支払内容に応じて管理組合の承認が必要な支払かどうかを判断し、保管口座（承認要）から支出するか、あるいは収納口座（承認不要）から支出するかを判断して請求書情報登録画面上で管理組合に関連付けられた支払口座を選択することができる。詳細に言えば、管理会社端末１２が所定の操作をすることにより、銀行システム１０は、管理組合マスタ１０７に問い合わせを行い、請求書の宛先である管理組合に関連付けられる保管口座及び収納口座の一覧を画面上に表示させる。管理会社の担当者は、表示されている口座の一覧から適切な口座を選択することができる。請求書の情報登録が完了して登録ボタンが押下されると、銀行システム１０は、管理会社端末１２によって入力された請求書情報を受信する。

【0055】

なお、管理組合によっては、複数の保管口座及び収納口座（例えば、保管口座について自行口座と他行口座を１つずつ、収納口座について自行口座と他行口座を１つずつ、など）を有しているところもあるので、銀行システム１０は、いずれか１つの金融機関の口座を選択できるように請求書情報登録画面を構成することもできる。

【0056】

Ｓ６０２にて、銀行システム１０は、受信した請求書情報に基づいて支払ＩＤを生成して支払データを生成する。支払データには、受信した請求書情報に含まれていた出金予定日、入金予定日、出金元口座、入金先口座（すなわち、業者の口座）、支払金額、支払内容が含まれ得る。出金元口座が保管口座である場合、支払データには、承認フラグ（例えば、値「要」）、承認期限の情報が含まれる。承認期限は、出金予定日の所定の日数前に自動で設定されてよい。銀行システム１０は、生成した支払データを支払データ１０８に格納する。銀行システム１０は、受信した請求書情報の全てについて上述した処理を行い、生成した支払データを支払データ１０８に格納する。

【0057】

Ｓ６０３にて、銀行システム１０は、支払データ１０８から１件の支払データを読み出し、承認フラグの値が「要」になっているかどうかを判定する。承認フラグの値が「要」になっている場合には、Ｓ６０４に処理が進み、一方、承認フラグの値がＮＵＬＬの場合には、Ｓ６０７に処理が進む。

【0058】

Ｓ６０４にて、銀行システム１０は、Ｓ６０３にて読みだした支払データの出金元口座の銀行コードが自行を示すか、あるいは他行を示すかを判定する。自行とは、銀行システム１０を制御する金融機関自身を意味し、他行とは、自行以外の金融機関を意味する。出金元口座の銀行コードが自行を示す場合には、Ｓ６０５に処理が進み、一方、出金元口座の銀行コードが他行を示す場合には、Ｓ６０６に処理が進む。

【0059】

Ｓ６０５で実行される第１の処理フローは、自行の保管口座（承認要）から出金して支払を行う処理を示し、その詳細は図７を参照しながら説明する。Ｓ６０６で実行される第２の処理フローは、他行の保管口座（承認要）から出金して支払を行う処理を示し、その詳細は図８を参照しながら説明する。

【0060】

Ｓ６０７にて、銀行システム１０は、Ｓ６０３にて読みだした支払データの出金元口座の銀行コードが自行を示すか、あるいは他行を示すかを判定する。出金元口座の銀行コードが自行を示す場合には、Ｓ６０８に処理が進み、一方、出金元口座の銀行コードが他行を示す場合には、Ｓ６０９に処理が進む。

【0061】

Ｓ６０８で実行される第３の処理フローは、自行の収納口座（承認不要）から出金して支払を行う処理を示し、その詳細は図９を参照しながら説明する。Ｓ６０９で実行される第４の処理フローは、他行の収納口座（承認不要）から出金して支払を行う処理を示し、その詳細は図１０を参照しながら説明する。

【0062】

上述したように、本発明に係る銀行システム１０は、支払データの内容に応じて第１～第４の処理フローのいずれかを選択して実行する制御処理が可能になり、従来のように別々のＥＢサービスを使い分けて支払処理を行っていた煩雑さが解消されるようになる。また、管理組合の承認が必要な支払についてもこの処理フローの中で承認を依頼できるようになる。さらに、管理組合がどの金融機関の口座を保有していたとしても、銀行システム１０が提供する統一されたシステムインターフェースを介して支払を適切に処理できるようになる。

【0063】

（第１の処理フロー：自行の保管口座（承認要）からの支払処理）
図７は、業者からの請求に対して自行の保管口座から支払いを実行する第１の処理フローを説明する図である。保管口座からの支払であるため、費用支出にあたって管理組合の承認が必要となる。

【0064】

Ｓ７０１にて、銀行システム１０は、Ｓ６０３にて読みだした支払データの管理組合ＩＤ４０１に基づいて管理組合マスタ１０７に問い合わせを行い、承認人数４０６及び承認フロー情報４０７を取得する。銀行システム１０は、本処理フローのための第１のカウンタに数値「１」をセットする。

【0065】

Ｓ７０２にて、銀行システム１０は、承認人数４０６によって示される人数が第１のカウンタの値以上であるかどうかを判定する。人数が第１のカウンタの値以上である場合、管理組合に支払承認を依頼するためのＳ７０３に処理が進み、人数が第１のカウンタの値未満である場合、Ｓ７０５に処理が進む。換言すれば、管理組合の全ての承認者が支払依頼に対して支払承認した場合、Ｓ７０５に処理が進む。

【0066】

Ｓ７０３にて、銀行システム１０は、承認フロー情報４０７に含まれている承認順序の通りに宛先情報を読み出し、管理組合の第Ｎ番目の承認者（Ｎは第１のカウンタの値）宛に支払承認が必要な支払データがあることを通知する。その後、第Ｎ番目の承認者は、管理組合端末１３を介して銀行システム１０にアクセスし、支払データの内容を確認して承認実行ボタンを押下する。

【0067】

Ｓ７０４にて、銀行システム１０は、支払データに対する承認が実行されたことに応答して第１のカウンタをインクリメントする。本処理フローはＳ７０２に戻る。

【0068】

Ｓ７０５にて、銀行システム１０は、支払データの内容に基づいて振込電文を生成する。振込電文には、支払実行日（＝入金日）、出金元口座、入金先口座、支払金額の情報が含まれる。

【0069】

Ｓ７０６にて、銀行システム１０は、振込電文に基づいて振込処理を実行する。振込処理が成功裏に完了すると、銀行システム１０は、入金先口座のある金融機関のシステム（例えば、他行システム１１）から処理完了の電文を受信する。あるいは、振込処理ができなかった場合には、入金先口座のある金融機関のシステム（例えば、他行システム１１）から処理未完了の電文（例えば、組み戻し電文、など）を受信する。

【0070】

第１の処理フローによれば、銀行システム１０は、業者からの請求書に対して自行の保管口座（承認要）からの支払処理を実行する機能を管理組合及び管理会社に提供することができるようになる。

【0071】

（第２の処理フロー：他行の保管口座（承認要）からの支払処理）
図８は、業者からの請求に対して他行の保管口座からの支払いを実行する第２の処理フローを説明する図である。保管口座からの支払であるため、費用支出にあたって管理組合の承認が必要となる。第１の処理フローとの相違点は、保管口座が他行口座である点である。

【0072】

Ｓ８０１にて、銀行システム１０は、Ｓ６０３にて読みだした支払データの管理組合ＩＤ４０１に基づいて管理組合マスタ１０７に問い合わせを行い、承認人数４０６及び承認フロー情報４０７を取得する。銀行システム１０は、本処理フローのための第２のカウンタに数値「１」をセットする。

【0073】

Ｓ８０２にて、銀行システム１０は、承認人数４０６によって示される人数が第２のカウンタの値以上であるかどうかを判定する。人数が第２のカウンタの値以上である場合、管理組合に支払承認を依頼するためのＳ８０３に処理が進み、人数が第２のカウンタの値未満である場合、Ｓ８０５に処理が進む。換言すれば、管理組合の全ての承認者が支払依頼に対して支払承認した場合、Ｓ８０５に処理が進む。

【0074】

Ｓ８０３にて、銀行システム１０は、承認フロー情報４０７に含まれている承認順序の通りに宛先情報を読み出し、管理組合の第Ｎ番目の承認者（Ｎは第２のカウンタの値）宛に支払承認が必要な支払データがあることを通知する。その後、第Ｎ番目の承認者は、管理組合端末１３を介して銀行システム１０にアクセスし、支払データの内容を確認して承認実行ボタンを押下する。

【0075】

Ｓ８０４にて、銀行システム１０は、支払データに対する承認が実行されたことに応答して第２のカウンタをインクリメントする。本処理フローはＳ８０２に戻る。

【0076】

Ｓ８０５にて、銀行システム１０は、支払データの内容に基づいて他行システム１１に送信するための口座振替電文を生成する。口座振替電文には、引落指定日（＝出金日）、出金元口座、入金先口座、支払金額の情報が含まれる。出金元口座は、他行が保有する管理組合名義の保管口座を示す。入金先口座は、銀行システム１０が保有する一時保管口座４０５の口座情報を示す。銀行システム１０は、生成した口座振替電文を出金元口座によって示される金融機関の他行システム１１に送信する。なお、口座振替電文は、周知の収納代行業者のシステムを経由して、他行システム１１に送信されてよい。他行システム１１は、受信した口座振替電文に基づいて口座振替処理を行い、それにより、支払金額に相当する資金が他行システム１１の出金元口座から銀行システム１０の一時保管口座４０５に移動する。口座振替処理が成功裏に完了した場合、他行システム１１は、成功裏に処理完了したことを示す電文を銀行システム１０に送信する。

【0077】

Ｓ８０６にて、銀行システム１０は、口座振替処理が成功裏に完了したことを示す電文を受信したことに応答して、支払データの内容に基づいて振込電文を生成する。振込電文には、支払実行日（＝入金日）、出金元口座、入金先口座、支払金額の情報が含まれる。出金元口座は、一時保管口座４０５の口座を示し、入金先口座は、支払先の業者口座を示す。

【0078】

銀行システム１０は、振込電文に基づいて振込処理を実行する。振込処理が成功裏に完了すると、銀行システム１０は、入金先口座のある金融機関のシステム（例えば、他行システム１１）から処理完了の電文を受信する。あるいは、振込処理ができなかった場合には、入金先口座のある金融機関のシステム（例えば、他行システム１１）から処理未完了の電文（例えば、組み戻し電文、など）を受信する。

【0079】

第２の処理フローによれば、銀行システム１０は、業者からの請求書に対して他行の保管口座（承認要）からの支払処理を実行する機能を管理組合及び管理会社に提供することができるようになる。

【0080】

（第３の処理フロー：自行の収納口座（承認不要）からの支払処理）
図９は、業者からの請求に対して自行の収納口座から支払いを実行する第３の処理フローを説明する図である。収納口座からの支払であるため、費用支出にあたって管理組合の承認は不要である。

【0081】

Ｓ９０１にて、銀行システム１０は、Ｓ６０３にて読みだした支払データの管理組合ＩＤ４０１に基づいて管理組合マスタ１０７に問い合わせを行い、承認フロー情報４０７に含まれている承認者の連絡先情報を取得する。銀行システム１０は、取得した承認者の連絡先情報を使用して、支払データの内容に基づく支払が行われることを１又は複数の承認者に対して通知する。

【0082】

Ｓ９０２にて、銀行システム１０は、支払データの内容に基づいて振込電文を生成する。振込電文には、支払実行日（＝入金日）、出金元口座、入金先口座、支払金額の情報が含まれる。

【0083】

Ｓ９０３にて、銀行システム１０は、振込電文に基づいて振込処理を実行する。振込処理が成功裏に完了すると、銀行システム１０は、入金先口座のある金融機関のシステム（例えば、他行システム１１）から処理完了の電文を受信する。あるいは、振込処理ができなかった場合には、入金先口座のある金融機関のシステム（例えば、他行システム１１）から処理未完了の電文（例えば、組み戻し電文、など）を受信する。

【0084】

第３の処理フローによれば、銀行システム１０は、業者からの請求書に対して自行の収納口座（承認不要）からの支払処理を実行する機能を管理組合及び管理会社に提供することができるようになる。

【0085】

（第４の処理フロー：他行の収納口座（承認不要）からの支払処理）
図１０は、業者からの請求に対して他行の収納口座からの支払いを実行する第４の処理フローを説明する図である。収納口座からの支払であるため、費用支出にあたって管理組合の承認は不要である。第３の処理フローとの相違点は、収納口座が他行口座である点である。

【0086】

Ｓ１００１にて、銀行システム１０は、Ｓ６０３にて読みだした支払データの管理組合ＩＤ４０１に基づいて管理組合マスタ１０７に問い合わせを行い、承認フロー情報４０７に含まれている承認者の連絡先情報を取得する。銀行システム１０は、取得した承認者の連絡先情報を使用して、支払データの内容に基づく支払が行われることを１又は複数の承認者に対して通知する。

【0087】

Ｓ１００２にて、銀行システム１０は、支払データの内容に基づいて他行システム１１に送信するための口座振替電文を生成する。口座振替電文には、引落指定日（＝出金日）、出金元口座、入金先口座、支払金額の情報が含まれる。出金元口座は、他行が保有する管理組合名義の収納口座を示す。入金先口座は、銀行システム１０が保有する一時保管口座４０５の口座情報を示す。銀行システム１０は、生成した口座振替電文を出金元口座によって示される金融機関の他行システム１１に送信する。なお、口座振替電文は、周知の収納代行業者のシステムを経由して、他行システム１１に送信されてよい。他行システム１１は、受信した口座振替電文に基づいて口座振替処理を行い、それにより、支払金額に相当する資金が他行システム１１の出金元口座から銀行システム１０の一時保管口座４０５に移動する。口座振替処理が成功裏に完了した場合、他行システム１１は、成功裏に処理完了したことを示す電文を銀行システム１０に送信する。

【0088】

Ｓ１００３にて、銀行システム１０は、口座振替処理が成功裏に完了したことを示す電文を受信したことに応答して、支払データの内容に基づいて振込電文を生成する。振込電文には、支払実行日（＝入金日）、出金元口座、入金先口座、支払金額の情報が含まれる。出金元口座は、一時保管口座４０５の口座を示し、入金先口座は、支払先の業者口座を示す。

【0089】

銀行システム１０は、振込電文に基づいて振込処理を実行する。振込処理が成功裏に完了すると、銀行システム１０は、入金先口座のある金融機関のシステム（例えば、他行システム１１）から処理完了の電文を受信する。あるいは、振込処理ができなかった場合には、入金先口座のある金融機関のシステム（例えば、他行システム１１）から処理未完了の電文（例えば、組み戻し電文、など）を受信する。

【0090】

第４の処理フローによれば、銀行システム１０は、業者からの請求書に対して他行の収納口座（承認不要）からの支払処理を実行する機能を管理組合及び管理会社に提供することができるようになる。

【0091】

以上、例示的な実施形態を参照しながら本発明の原理を説明したが、本発明の要旨を逸脱することなく、構成及び細部において変更する様々な実施形態を実現可能であることを当業者は理解するだろう。すなわち、本発明は、例えば、システム、装置、方法、プログラムもしくは記憶媒体等としての実施態様をとることが可能である。

【符号の説明】

【0092】

１０ 銀行システム
１１ 他行システム
１２ 管理会社端末
１３ 管理組合端末
１４ 請求業者サーバ
１５、１６ ネットワーク
１０１ 制御部
１０２ 主記憶部
１０３ 補助記憶部
１０４ インターフェース（ＩＦ）部
１０５ 出力部
１０６ 管理会社マスタ
１０７ 管理組合マスタ
１０８ 支払データ
１０９ 口座情報
１１０ 入出金情報

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】