(57)【要約】      （修正有）【課題】共同口座の運営に際して参加者による口座支出の時機の幅を広げ、支出に対する必要性や妥当性の判断が参加者によって適切に行われる口座管理技術を提供する。【解決手段】口座管理装置は、共同口座の開設をユーザから受け付ける開設受付部と、共同口座の情報と、ユーザおよび共同口座をユーザと共に保有する複数の他のユーザとを対応付けて記憶する記憶部と、ユーザまたは複数の他のユーザの少なくとも１人から共同口座への出資を受け付ける出資受付部と、ユーザまたは複数の他のユーザのうち１人の申請者から共同口座の残高の少なくとも一部の支出申請を受け付ける申請受付部と、ユーザおよび複数の他のユーザのうち申請者ではないユーザから支出申請に対する複数の支出可否情報を受け付ける可否受付部と、ユーザおよび複数の他のユーザの支出可否情報の一部を元に支出申請を許可するか否認するかを判定する判定部と、を含む。【選択図】図９
2019197512.tif 000002
【特許請求の範囲】
【請求項１】
共同口座の開設をユーザから受け付ける開設受付部と、
前記共同口座の情報と、前記ユーザおよび前記共同口座を前記ユーザと共に保有する複数の他のユーザとを対応付けて記憶する記憶部と、
前記ユーザまたは複数の他のユーザの少なくとも１人から前記共同口座への出資を受け付ける出資受付部と、
前記ユーザまたは複数の他のユーザのうち１人の申請者から前記共同口座の残高の少なくとも一部の支出申請を受け付ける申請受付部と、
前記ユーザおよび複数の他のユーザのうち前記申請者ではないユーザから前記支出申請に対する複数の支出可否情報を受け付ける可否受付部と、
前記ユーザおよび複数の他のユーザの前記支出可否情報の一部を元に前記支出申請を許可するか否認するかを判定する判定部と、
前記判定部が前記支出可否情報を元に前記支出申請を許可する支出許可情報を生成する生成部と、を含み、
前記生成部が前記支出許可情報を生成した場合に、前記申請者が前記支出申請をした額を前記申請者が支出可能な金額として前記記憶部に記憶する
ことを特徴とする口座管理装置。
【請求項２】
前記判定部は、前記可否受付部が受け付けた前記支出可否情報の一部のみを考慮して支出申請を許可するか否認するかを判定する
ことを特徴とする請求項１に記載の口座管理装置。
【請求項３】
前記可否受付部は、前記ユーザおよび複数の他のユーザの一部のみから前記支出可否情報を受け付け、
前記判定部は、前記可否受付部が受け付けた支出可否情報を全て考慮して支出申請を許可するか否認するかを判定する
ことを特徴とする請求項１に記載の口座管理装置。
【請求項４】
前記判定部は、前記可否受付部が受け付けた前記複数の前記支出可否情報を点数化し、当該点数に基づいて前記支出申請を許可するか否認するかを判定する
ことを特徴とする請求項１〜３のいずれか一項に記載の口座管理装置。
【請求項５】
前記判定部は、前記点数に基づいて許可する支出額を判定する
ことを特徴とする請求項４に記載の口座管理装置。
【請求項６】
前記判定部は、前記共同口座における前記ユーザおよび／または前記他のユーザの貢献度であるレピュテーションスコアに応じて前記一部の支出可否情報を決定する
ことを特徴とする請求項１〜５のいずれか一項に記載の口座管理装置。
【請求項７】
前記レピュテーションスコアは、前記ユーザおよび／または前記他のユーザの前記口座への出資額、支出申請回数、および支出可否情報の発信回数の少なくとも１つに基づいて算出される
ことを特徴とする請求項６に記載の口座管理装置。
【請求項８】
前記判定部は、前記複数の前記支出可否情報の各々の投票の重みを決定し、前記決定した投票の重みを考慮した前記複数の前記支出可否情報を元に前記支出許可情報を生成する
ことを特徴とする請求項１〜７のいずれか一項に記載の口座管理装置。
【請求項９】
前記投票の重みは、前記ユーザおよび複数の他のユーザの個々が前記共同口座以外の他の共同口座の運営の状況に応じて決定される
ことを特徴とする請求項８に記載の口座管理装置。
【請求項１０】
前記判定部は、前記ユーザおよび複数の他のユーザの前記支出可否情報の前記申請受付部が受け付けた前記支出申請の申請額が高ければ高いほど、または前記共同口座の残高に対する割合が高いほど前記支出申請に対して前記許可をする判定をしにくくする
ことを特徴とする請求項１〜９のいずれか一項に記載の口座管理装置。
【請求項１１】
共同口座の開設をユーザから受け付けるステップと、
前記共同口座の情報と、前記ユーザおよび前記共同口座を前記ユーザと共に保有する複数の他のユーザとを対応付けて記憶するステップと、
前記ユーザまたは複数の他のユーザの少なくとも１人から前記共同口座への出資を受け付けるステップと、
前記ユーザまたは複数の他のユーザのうち１人の申請者から前記共同口座の残高の少なくとも一部の支出申請を受け付けるステップと、
前記ユーザおよび複数の他のユーザのうち前記申請者ではないユーザから前記支出申請に対する複数の支出可否情報を受け付けるステップと、
前記ユーザおよび複数の他のユーザの前記支出可否情報の一部を元に前記支出申請を許可するか否認するかを判定するステップと、
前記支出可否情報を元に前記支出申請を許可する支出許可情報を生成するステップと、
前記支出許可情報が生成された場合に、前記申請者が前記支出申請をした額を前記申請者が支出可能な金額として記憶するステップと、
を含むことを特徴とする口座管理方法。
【請求項１２】
コンピュータに、
共同口座の開設をユーザから受け付ける機能と、
前記共同口座の情報と、前記ユーザおよび前記共同口座を前記ユーザと共に保有する複数の他のユーザとを対応付けて記憶する機能と、
前記ユーザまたは複数の他のユーザの少なくとも１人から前記共同口座への出資を受け付ける機能と、
前記ユーザまたは複数の他のユーザのうち１人の申請者から前記共同口座の残高の少なくとも一部の支出申請を受け付ける機能と、
前記ユーザおよび複数の他のユーザのうち前記申請者ではないユーザから前記支出申請に対する複数の支出可否情報を受け付ける機能と、
前記ユーザおよび複数の他のユーザの前記支出可否情報の一部を元に前記支出申請を許可するか否認するかを判定する機能と、
前記支出可否情報を元に前記支出申請を許可する支出許可情報を生成する機能と、
前記支出許可情報が生成された場合に、前記申請者が前記支出申請をした額を前記申請者が支出可能な金額として記憶する機能と、
を実現させることを特徴とする口座管理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、口座管理装置、口座管理方法、および口座管理プログラムに関する。
【背景技術】
【０００２】
複数人によって管理される共同管理口座はよく知られている。共同管理口座は、同じ目的を持った複数人によって管理されることが通常であり、その口座の資金の運用や支出についても当該複数人によって行われる。
【０００３】
例えば、特許文献１には、各参加者が搬出した資産をファンドとして運用する場合に、ファンドの運用案件についての提案情報を各参加者に通知し、その提案情報を閲覧した各参加者による投票により、その運用の実施の可否と運用額を決定する構成が開示されている。また、この構成が分譲マンションの購入や物品などの共同購入に支出できる点についても記載されている。
【０００４】
より具体的には、共同口座にある資産の支出や運用について、提案者が各参加者に提案情報として通知し、その提案情報を閲覧した各参加者による投票により、その支出や運用の実施の可否を決定することが行なわれため、参加者の協議や意思統一がスムーズに行なうことができ、共同口座の資産運用を効率的に行なうことができる。
【０００５】
更に、特許文献２には、夫婦などで管理する共同口座を設けて、家計として必要な支払いを管理したり、夫婦として得た収入について管理したりする構成が開示されている。また、口座から出金を行う場合などには、当該出金にコメントを履歴として残すことで資産形成や処分等に係る意思疎通を図ることもできる。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００３−０２２３６９号公報
【特許文献２】特開２０１７−２２４０３９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、特許文献１に開示された技術は、参加者全員が同一の目的のために出資を行うことで共同口座を運営しており、口座からの支出や運用も共同の目的のために行われており、全員共通の目的のみに限定される。よって、共同口座からの支出が限定されてしまう。更に、特許文献１では、共同出資者が平等に共同口座を運営しており、出資額や運営に対する積極性などは全く考慮されていない。これに起因して、活発な資金運営が阻害されたり、正しい判断がされずに支出のタイミングを逃してしまったりする可能性がある。
【０００８】
また、特許文献２においては、共同口座からの支出は、コメントを記載することのみで管理されており、支出の必要性や妥当性の判断を、支出を希望する者以外がすることができない。よって、共同口座の運営としては最適なものとは言えない。
【０００９】
そこで、本発明は上記事情に鑑みてなされたものであり、共同口座の運営に際して参加者による口座支出の時機の幅を広げ、支出に対する必要性や妥当性の判断が参加者によって適切に行われる口座管理装置、口座管理方法、および口座管理プログラムを提供することを目的とする。
【課題を解決するための手段】
【００１０】
（１）本発明の第１態様は、共同口座の開設をユーザから受け付ける開設受付部と、共同口座の情報と、ユーザおよび共同口座をユーザと共に保有する複数の他のユーザとを対応付けて記憶する記憶部と、ユーザまたは複数の他のユーザの少なくとも１人から共同口座への出資を受け付ける出資受付部と、ユーザまたは複数の他のユーザのうち１人の申請者から共同口座の残高の少なくとも一部の支出申請を受け付ける申請受付部と、ユーザおよび複数の他のユーザのうち申請者ではないユーザから支出申請に対する複数の支出可否情報を受け付ける可否受付部と、ユーザおよび複数の他のユーザの支出可否情報の一部を元に支出申請を許可するか否認するかを判定する判定部と、判定部が支出可否情報を元に支出申請を許可する支出許可情報を生成する生成部と、を含み、生成部が支出許可情報を生成した場合に、申請者が支出申請をした額を申請者が支出可能な金額として記憶部に記憶する、口座管理装置に関する。
【００１１】
（２）上記（１）において、判定部は、可否受付部が受け付けた支出可否情報の一部のみを考慮して支出申請を許可するか否認するかを判定してもよい。
【００１２】
（３）上記（１）において、可否受付部は、ユーザおよび複数の他のユーザの一部のみから支出可否情報を受け付け、判定部は、可否受付部が受け付けた支出可否情報を全て考慮して支出申請を許可するか否認するかを判定してもよい。
【００１３】
（４）上記（１）〜（３）のいずれかにおいて、判定部は、可否受付部が受け付けた複数の支出可否情報を点数化し、当該点数に基づいて支出申請を許可するか否認するかを判定してもよい。
【００１４】
（５）上記（４）において、判定部は、点数に基づいて許可する支出額を判定してもよい。
【００１５】
（６）上記（１）〜（５）において、判定部は、共同口座におけるユーザおよび／または他のユーザの貢献度であるレピュテーションスコアに応じて一部の支出可否情報を決定してもよい。
【００１６】
（７）上記（６）において、レピュテーションスコアは、ユーザおよび／または他のユーザの口座への出資額、支出申請回数、および支出可否情報の発信回数の少なくとも１つに基づいて算出されてもよい。
【００１７】
（８）上記（１）〜（７）において、判定部は、複数の支出可否情報の各々の投票の重みを決定し、決定した投票の重みを考慮した複数の支出可否情報を元に支出許可情報を生成してもよい。
【００１８】
（９）上記（８）において、投票の重みは、ユーザおよび複数の他のユーザの個々が共同口座以外の他の共同口座の運営の状況に応じて決定されてもよい。
【００１９】
（１０）上記（１）〜（９）において、判定部は、ユーザおよび複数の他のユーザの支出可否情報の申請受付部が受け付けた支出申請の申請額が高ければ高いほど、または共同口座の残高に対する割合が高いほど支出申請に対して許可をする判定をしにくくしてもよい。
【００２０】
（１１）本発明の第２態様は、共同口座の開設をユーザから受け付けるステップと、共同口座の情報と、ユーザおよび共同口座をユーザと共に保有する複数の他のユーザとを対応付けて記憶するステップと、ユーザまたは複数の他のユーザの少なくとも１人から共同口座への出資を受け付けるステップと、ユーザまたは複数の他のユーザのうち１人の申請者から共同口座の残高の少なくとも一部の支出申請を受け付けるステップと、ユーザおよび複数の他のユーザのうち申請者ではないユーザから支出申請に対する複数の支出可否情報を受け付けるステップと、ユーザおよび複数の他のユーザの支出可否情報の一部を元に支出申請を許可するか否認するかを判定するステップと、支出可否情報を元に支出申請を許可する支出許可情報を生成するステップと、支出許可情報が生成された場合に、申請者が支出申請をした額を申請者が支出可能な金額として記憶するステップと、を含む口座管理方法に関する。
【００２１】
（１２）本発明の第３態様は、コンピュータに、共同口座の開設をユーザから受け付ける機能と、共同口座の情報と、ユーザおよび共同口座をユーザと共に保有する複数の他のユーザとを対応付けて記憶する機能と、ユーザまたは複数の他のユーザの少なくとも１人から共同口座への出資を受け付ける機能と、ユーザまたは複数の他のユーザのうち１人の申請者から共同口座の残高の少なくとも一部の支出申請を受け付ける機能と、ユーザおよび複数の他のユーザのうち申請者ではないユーザから支出申請に対する複数の支出可否情報を受け付ける機能と、ユーザおよび複数の他のユーザの支出可否情報の一部を元に支出申請を許可するか否認するかを判定する機能と、支出可否情報を元に支出申請を許可する支出許可情報を生成する機能と、支出許可情報が生成された場合に、申請者が支出申請をした額を申請者が支出可能な金額として記憶する機能と、を実現させる口座管理プログラムに関する。
【発明の効果】
【００２２】
本発明によると、共同口座からの支出の内容が共同口座を共に保有するユーザの共同利益の獲得に制限されず、共同口座の運営や支出の方針をユーザの積極性などの貢献度を考慮した上で判断する口座管理装置、口座管理方法、および口座管理プログラムを提供することができる。
【図面の簡単な説明】
【００２３】
【図１】口座管理システムによる処理の一例を説明するための模式図である。
【図２】口座管理システムの概略構成の一例を示す図である。
【図３】ユーザの端末装置の概略構成の一例を示す図である。
【図４】サーバの概略構成の一例を示す図である。
【図５Ａ】ユーザテーブルの構造の一例を説明する表である。
【図５Ｂ】共同口座テーブルの構造の一例を説明する表である。
【図６】共同口座詳細テーブルの構造の一例を示す図である。
【図７】ユーザの端末装置に表示される共同口座情報表示画面の一例を示す図である。
【図８】ユーザの端末装置に表示される共同口座情報表示画面の一例を示す図である。
【図９】口座管理システムによる共同口座の開設から共同口座の出資額の支出申請を許可するまでの一連の流れの動作シーケンスの一例を示す図である。
【発明を実施するための形態】
【００２４】
以下、本開示の一側面に係る口座管理装置、口座管理方法、および口座管理プログラムについて図を参照しつつ説明する。但し、本開示の技術的範囲はそれらの実施の形態に限定されず、特許請求の範囲に記載された発明とその均等物に及ぶ点に留意されたい。
【００２５】
（口座管理システム１による処理の概要）
図１は、口座管理システム１による処理の一例を説明するための模式図である。
【００２６】
口座管理システム１は、複数のユーザの端末装置２を含み、これらの複数のユーザの端末装置２と相互に通信されるサーバ３を有する。サーバ３は、複数のユーザの端末装置２から受信したユーザ情報を記憶するユーザテーブル３１１および複数のユーザによって所有される共同口座情報を記憶する共同口座テーブル３１２を有する。
【００２７】
ユーザテーブル３１１には、ユーザの情報がユーザ識別情報（ユーザＩＤ）と共に記憶されており、共同口座テーブル３１２には、共同口座を所有するユーザ識別情報および共同口座の残高などが共同口座識別情報（口座ＩＤ）と共に記憶されている。これらのユーザテーブル３１１および共同口座テーブル３１２は、同一の記憶部からなってもよく、複数の記憶部からなってもよく、更には口座管理システム１の外部に存在してもよい。ユーザテーブル３１１および共同口座テーブル３１２が本発明における記憶部に相当することができる。
【００２８】
複数のユーザは、複数のユーザの端末装置２を介してサーバ３にユーザの情報を送信したり、共同口座を作成したり、既存の共同口座の共同所有者となるべく希望を送信したりできる。また、サーバ３は、複数のユーザの端末装置２から送信されたユーザの情報をユーザテーブルに記憶させ、共同口座情報をユーザ識別情報と共に共同口座テーブルに記憶させる。サーバ３は、複数のユーザの端末装置２からの要求に応じて出資を受け付けたり、共同口座の利用を受け付けたりする。
【００２９】
なお、上述した図１の説明は、本発明の内容への理解を深めるための説明にすぎない。本発明は、具体的には、次に説明する各実施の形態において実施され、且つ、本発明の原則を実質的に超えずに、さまざまな変形例によって実施されてもよい。このような変形例はすべて、本発明および本明細書の開示範囲に含まれる。
【００３０】
（口座管理システム１の概略構成）
図２は、口座管理システム１の概略構成の一例を示す図である。
【００３１】
口座管理システム１は、複数のユーザの端末装置２、２、２・・・と、サーバ３と、を有する。以下では、複数のユーザの端末装置２を単にユーザの端末装置２と称する場合がある。ユーザの端末装置２、２、２・・・およびサーバ３は、例えば、インターネット４などの通信ネットワークを介してそれぞれ相互に接続される。また、ここではインターネット４が１つ例示されているが、インターネット４が複数のネットワークからなる場合は、それぞれのネットワーク間にゲートウェイ（図示しない）を適宜設けてもよい。サーバ３で実行されるプログラム（例えば、管理プログラム）とは、ハイパーテキスト転送プロトコル（ＨＴＴＰ）などの通信プロトコルを用いて通信を行う。
【００３２】
（ユーザの端末装置２の概略構成）
図３は、ユーザの端末装置２の概略構成の一例を示す図である。
【００３３】
端末装置２は、無線通信ネットワークへの接続、Ｗｅｂアクセスなどを実行する。そのために、端末装置２は、端末通信部２１１と、端末記憶部２１２と、端末操作部２１３と、端末表示部２１４と、端末処理部２１５とを備える。
【００３４】
なお、端末装置２としては、多機能携帯電話（所謂「スマートフォン」）を想定するが、本発明はこれに限定されない。端末装置２は、本発明が適用可能であればよく、例えば、タブレットＰＣやノートＰＣ、携帯電話（所謂「フィーチャーフォン」）、携帯情報端末（ＰＤＡ）、携帯ゲーム機、携帯音楽プレイヤ、タブレット端末、などでもよい。
【００３５】
端末通信部２１１は、通信インターフェース回路を備え、端末装置２をインターネット４に接続する。端末通信部２１１は、ネットワークを介して端末処理部２１５から供給されたデータをサーバ３などに送信する。また、端末通信部２１１は、ネットワークを介してサーバ３などから受信したデータを端末処理部２１５に供給する。
【００３６】
端末記憶部２１２は、例えば、半導体メモリ装置を備える。端末記憶部２１２は、端末処理部２１５での処理に用いられるオペレーティングシステムプログラム、ドライバプログラム、アプリケーションプログラム、データなどを記憶する。例えば、端末記憶部２１２は、ドライバプログラムとして、端末操作部２１３を制御する入力デバイスドライバプログラム、端末表示部２１４を制御する出力デバイスドライバプログラムなどを記憶する。また、端末記憶部２１２は、アプリケーションプログラムとして、店舗関係者が端末操作部２１３を操作することによって入力された検索条件、特徴情報および特徴画像などをサーバ３に登録するための登録画面を表示する閲覧プログラムなどを記憶する。各種プログラムは、例えばＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭなどのコンピュータ読み取り可能な可搬型記録媒体から、公知のセットアッププログラムなどを用いて端末記憶部２１２にインストールされてもよい。また、端末記憶部２１２は、所定の処理に係る一時的なデータを一時的に記憶してもよい。
【００３７】
端末操作部２１３は、端末装置２の操作が可能であればどのようなデバイスでもよく、例えば、タッチパネルであるが、マウス、またはキーボタンなどを端末装置２の外部に接続してもよい。ユーザは、端末操作部２１３を用いて、情報の選択や解除、文字や数字などを入力することができる。端末操作部２１３は、ユーザにより操作されると、その操作に対応する信号を発生する。そして、発生した信号は、端末処理部２１５に送信される。
【００３８】
端末表示部２１４も、映像や画像などの表示が可能であればどのようなデバイスでもよく、例えば、液晶ディスプレイや有機ＥＬ（Electro−Luminescence）ディスプレイなどである。端末表示部２１４は、端末処理部２１５から供給された映像データに応じた映像や、画像データに応じた画像などを表示する。
【００３９】
端末処理部２１５は、一または複数個のプロセッサおよびその周辺回路を備える。端末処理部２１５は、端末装置２の全体的な動作を統括的に制御するものであり、例えば、ＣＰＵである。端末処理部２１５は、端末装置２の各種処理が端末記憶部２１２に記憶されているプログラムや端末操作部２１３の操作などに基づいて適切な手順で実行されるように、端末通信部２１１や端末表示部２１４などの動作を制御する。端末処理部２１５は、端末記憶部２１２に記憶されているプログラム（オペレーティングシステムプログラムやドライバプログラム、アプリケーションプログラムなど）に基づいて処理を実行する。また、端末処理部２１５は、複数のプログラム（アプリケーションプログラムなど）を並列に実行することができる。
【００４０】
端末処理部２１５は、端末装置２の外部から受信した画面表示情報をユーザに閲覧可能な画面表示として処理をする機能や、ユーザからの端末操作部２１３の操作内容に基づく処理を端末装置２の外部に送信可能な信号に変換して端末通信部２１１に送る機能を備える。これらの機能は、端末処理部２１５が備えるプロセッサで実行されるプログラムにより実現される機能モジュールである。あるいは、これらの各部は、独立した集積回路、マイクロプロセッサ、またはファームウェアとして端末装置２に実装されてもよい。
【００４１】
（サーバ３の概略構成）
図４は、サーバ３の概略構成の一例を示す図である。
【００４２】
サーバ３は、ユーザの情報を記憶するユーザテーブル３１１および複数のユーザが保有する共同口座の情報を記憶する共同口座テーブルを含むサーバ記憶部３１３を備える。そして、サーバ３は、複数のユーザの端末装置２からの要求に応じてこれらのユーザテーブル３１１および共同口座テーブル３１２を参照して複数のユーザの端末装置２に所望の情報を送信する。以上のような機能を実現するために、サーバ３は、記憶部３１３の他に、受付部３１４、判定部３１５、および生成部３１６を含むサーバ処理部３１８、およびサーバ通信部３１９を更に備える。
【００４３】
ユーザテーブル３１１は、ユーザ識別情報にユーザ名、メールアドレス、アカウントの認証用のパスワード、電話番号、ユーザの個人的な口座情報などを対応付けて記憶している。ユーザテーブル３１１は、更にユーザのランク情報をユーザ識別情報に対応付けて記憶している。
【００４４】
共同口座テーブル３１２は、共同口座識別情報に共同口座を所有するユーザ識別情報および共同口座の残高などを対応付けて記憶している。共同口座テーブル３１２は、図示しないが、更に複数のユーザの出資額、共同口座から支出を希望した申請額、当該支出申請が許可または否認されたか、どのユーザが支出申請の可否情報を、端末装置２を介して送信したか、などを記憶している。なお、これらの情報は、共同口座テーブル３１２ではなく、ユーザテーブル３１１が記憶してもよく、サーバ記憶部３１３の少なくとも一部が記憶していればよい。
【００４５】
サーバ記憶部３１３は、例えば、半導体メモリ、磁気ディスク装置および光ディスク装置の内の少なくとも一つを有し、バスを介してサーバ３と接続される。サーバ記憶部３１３は、サーバ処理部３１８による処理に用いられるドライバプログラム、オペレーティングシステムプログラム、アプリケーションプログラム、データなどを記憶する。例えば、サーバ記憶部３１３は、ドライバプログラムとして、サーバ通信部３１９を制御する通信デバイスドライバプログラムなどを記憶する。コンピュータプログラムは、例えばＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭなどのコンピュータ読み取り可能な可搬型記録媒体から、公知のセットアッププログラムなどを用いてサーバ記憶部３１３にインストールされてもよい。また、サーバ記憶部３１３は、ユーザテーブル３１１および共同口座テーブル３１２などを記憶する。
【００４６】
サーバ処理部３１８は、受付部３１４、判定部３１５、および生成部３１６を含む。  サーバ処理部３１８による機能は、サーバ処理部３１８が備えるプロセッサで実行されるプログラムにより実現される機能モジュールである。あるいは、これらの各部は、独立した集積回路、マイクロプロセッサ、またはファームウェアとしてサーバ３に実装されてもよい。なお、サーバ処理部３１８の処理内容は後述する。また、サーバ処理部３１８の構成要素の切り分けは、一例であって、どの構成要素がどの処理を行うかは、本実施形態の記載に限定されない。
【００４７】
受付部３１４は、後述するサーバ通信部３１９を介して複数のユーザの端末装置２から受信した様々な情報を一括に受け付ける。具体的に受付部３１４は、ユーザからの新規の口座開設要望を受け付ける。そして、他のユーザから既存の共同口座の共同所有に関する要望も受け付ける。また、複数のユーザの少なくとも１人から共同口座への出資を受け付ける。すなわち、共同口座への出資（入金）を受け付ける。更に、受付部３１４は、共同口座の残高の少なくとも一部の支出申請を受け付ける。すなわち、ユーザから共同口座に貯蓄された金額の少なくとも一部の利用申請を受け付ける。そして、受け付けた支出申請の可否について当該申請者以外のユーザから受け付ける。本発明において、受付部３１４は、開設受付部、出資受付部、申請受付部、および可否受付部に相当することができる。なお、サーバ記憶部３１３は、これらの各種受付部の受け付けた情報をユーザ識別情報や共同口座識別情報と共に記憶する。どの情報を記憶するかは、本発明において任意であり、特に本発明を限定する事項ではない。
【００４８】
判定部３１５は、複数のユーザの１人から発信された支出申請を端末装置２から受付部３１４が受け付けた後、当該申請者とは異なるユーザから当該支出申請に対する支出申請の可否情報を元に支出申請の可否を判定する。判定方法については、後述するが、判定部は、受付部３１４が受け付けた複数の支出可否情報を元に、支出申請の可否を判定する。
【００４９】
生成部３１６は、判定部３１５が判定した支出申請の可否結果を元に支出許可情報または支出否認情報を生成する。すなわち、判定部３１５が支出申請を許可した場合に、生成部３１６は、支出許可情報を生成する。また、判定部３１５が支出申請を否認した場合に、生成部３１６は、支出否認情報を生成する。
【００５０】
これらの支出許可情報または支出否認情報は、サーバ記憶部３１３にユーザ識別情報や共同口座識別情報と共に記憶される。支出許可情報または支出否認情報は、判定部３１５が支出可否情報を元に支出申請の許可判定または否認判定を行った際にサーバ記憶部３１３に記憶されてもよく、生成部３１６が支出許可情報または支出否認情報を生成した際にサーバ記憶部３１３に記憶されてもよい。
【００５１】
また、生成部３１６は、支出許可情報または支出否認情報を生成する以外にも、ユーザの端末装置２に表示するための画面データを生成したり、ユーザテーブル３１１に記憶されるユーザ情報を生成したり、共同口座テーブル３１２に記憶される共同口座情報を生成したりする。
【００５２】
算出部３１７は、後述するユーザのランク情報、レピュテーションスコア、および投票の重みを複数のユーザの情報や複数の共同口座の情報から算出する。算出結果は、サーバ記憶部３１３のユーザテーブル３１１または共同口座テーブル３１２に適宜記憶される。もちろん、ユーザテーブル３１１または共同口座テーブル３１２のいずれかにまとめて記憶していてもよい。また、算出部３１７による算出のタイミングは、ユーザが共同口座において出資、支出申請、コメント、参加申請、口座開設などを行ったタイミングで随時行われてもよい。また、算出部３１７による算出は、所定期間毎に実施されるようにしてもよい。
【００５３】
サーバ通信部３１９は、サーバ３をインターネット４に接続するための通信インターフェース回路を有する。サーバ通信部３１９は、複数のユーザの端末装置２から要求を受け付けてユーザの所望の口座情報や取り引き情報を端末装置２に送信する。更に、サーバ通信部３１９は、複数の共同口座の中からユーザの希望する取り引き内容を有する口座を検索するための検索条件をユーザの端末装置２から受信し、検索結果をユーザの端末装置２送信する。
【００５４】
（テーブルのデータ構造）
図５Ａおよび５Ｂは、ユーザテーブル３１１および共同口座テーブル３１２の構造の一例を示す図である。
【００５５】
なお、サーバ記憶部３１３がこれらのテーブルを記憶するのではなく、サーバ３と接続可能な記憶部を有する他の装置（データベースなど）がこれらの各種テーブルを記憶してもよい。この場合、サーバ３は、これらの各種テーブルに記憶された情報を使用する際に、当該テーブルを記憶する他の装置にアクセスして、当該テーブルに記憶された情報を取得する。また、各テーブルに含まれる各情報は、テーブル以外の形式で記憶されてもよく、例えばそれぞれ独立して記憶されてもよい。
【００５６】
図５Ａは、ユーザテーブル３１１の構造の一例を説明する表である。ユーザテーブル３１１は、ユーザ識別情報にユーザ名、メールアドレス、電話番号、アカウントの認証用のパスワード、ユーザの個人的な口座情報、ユーザのランク情報などが対応付けられて記憶されている。ここでユーザランク情報とは、サーバ３で管理される１つ以上の共同口座の運営においてユーザの活動のレベルをスコア化したものである。すなわち、複数の共同口座の運営において共通のランク情報となる。このランク情報基づいて支出可否情報の発信の権利が与えられたり、支出可否情報の支出許可情報への反映の度合いが決定されたりする。このユーザランク情報は、後述する特定の共同口座の運営におけるレピュテーションスコアとは異なる指標となる。
【００５７】
図５Ａには、ユーザＩＤが０００１、０００２、０００３、０００４のユーザが例示されており、ランク情報として５段階評価の数値が、４．５、２．０、３．５、１．０とそれぞれに付与されている。後述する通り、ユーザＩＤが０００３のユーザのランク情報が、口座管理システム１が提供するウェブサイトにおける活動が活発であるため、高く算出されていることがわかる。
【００５８】
ここで本実施形態におけるサーバ処理部３１８によるユーザのランク情報の算出方法を説明する。ユーザのランク情報は、口座管理システム１が提供するウェブサイトが管理する共同口座への出資額や出資口座数を元に算出部３１７が算出する。すなわち、サーバ３は、ユーザのランク情報をユーザの絶対的な共同口座の運営に対する貢献度に応じて付与する。具体的に算出部３１７は、口座管理システム１が提供するウェブサイトにおいて、どの程度の貢献したのかを予め定められた基準に基づいて算出する。算出部３１７は、ユーザのランク情報をユーザの絶対的な共同口座の運営に対する貢献度に応じて付与する。または、算出部３１７は、ユーザのランク情報をユーザの相対的な共同口座の運営に対する貢献度に応じて付与してもよい。すなわち、算出部３１７は、特定のユーザの絶対的な貢献度を算出した上で他のユーザとの比較によってユーザのランク情報を決定してもよい。
【００５９】
ユーザのランク情報は、後述する投票の重みの算出に使用される他、ユーザの共同口座の運営のモチベーションを上げるための評価点ともなる。すなわち、口座管理システム１において活発なユーザほど高いユーザランクとなるため、サイト全体の活発化に繋がる。更に、ユーザのランク情報は、算出された数値がユーザや他のユーザに表示されるようにしてもよく、例えば５段階評価に変換した後で表示してもよい。
【００６０】
次に図５Ｂは、複数のユーザによって共同保有される共同口座情報を共同口座識別情報に対応付けて記憶している共同口座テーブル３１２の構造の一例を説明する表である。共同口座テーブル３１２は、共同口座識別情報に口座を共同保有する複数のユーザ識別情報、口座残高、および共同口座を共同保有するために求められる最低ユーザランク情報などを対応付けて記憶している。なお、複数のユーザ識別情報は、共同口座を開設したユーザ識別情報として開設者ユーザＩＤおよび共同口座を一緒に保有する共同保有者ユーザＩＤを含み、それぞれを区別して記憶されている。ここで、共同口座を共同保有するために求められる最低ユーザランク情報とは、共同口座の開設者が任意に設定できる共同口座の共同保有のために求められる個々のユーザのユーザランク情報である。また、図５Ｂには示されていないが、複数のユーザによる共同口座との取り引き（出資および支出）の履歴が記憶されている。
【００６１】
図５Ｂの例では、ユーザＩＤが０００２のユーザが、２つの共同口座を開設していることがわかる。また、ユーザＩＤが０００３のユーザが開設した共同口座である、Ｋ０００４は、参加（共同保有）可能なユーザランクが３．０に設定されており、ユーザＩＤが０００２および０００４のユーザは、参加が許可されない。また、ユーザＩＤが０００４のユーザは、ユーザランク情報が低いため、共同口座ＩＤがＫ０００２の共同口座のみ共同保有が可能である。
【００６２】
（共同口座詳細テーブルの構造）
図６は、共同口座詳細テーブルの構造の一例を示す図である。
【００６３】
図６は、個々の共同口座における口座を共同で保有するユーザの出資金額やユーザ識別情報に対応付けてユーザのレピュテーションスコアを記憶した共同口座詳細テーブルの構造の一例を示す図である。なお、この図６の共同口座詳細テーブルは、図５Ｂに示す共同口座テーブル３１２の一部であり、サーバ記憶部３１３の一部に記憶されている。
【００６４】
図６に示すように、個々の共同口座は、口座を共同で保有するユーザのユーザ識別情報および個々のユーザの出資額に加えて個々のユーザのレピュテーションスコアを対応付けて記憶している。レピュテーションスコアは、個々の共同口座ごとに複数のユーザごとに設定されるスコアであり、前述のユーザランク情報とは異なる指標である。個々のユーザの出資金額とは、特定の口座ごとに各ユーザが当該特定の口座に出資した金額である。また、レピュテーションスコアは、判定部３１５が判定に使用する支出可否情報を決定するために使用される。判定部３１５は、本実施形態のように支出可否情報を受信するユーザをレピュテーションスコアに応じて限定してもよく、支出可否情報を支出の申請を行ったユーザ以外の全ユーザから受信した後でレピュテーションスコアに応じて考慮する支出可否情報を選択してもよい。すなわち、レピュテーションスコアの高いユーザの支出可否情報を元に判定部３１５は、支出申請の可否を判定することができる。もちろん、この共同口座詳細テーブルは、共同口座テーブル３１２と別に設けたれてもよい。
【００６５】
レピュテーションスコアは、特定の共同口座における貢献度を示す値である。レピュテーションスコアは、特定の共同口座における個々のユーザの口座への出資額（入金額）、支出申請回数、および支出可否情報の発信回数などに基づいて算出部３１７が算出する。すなわち、同一のユーザであっても異なる共同口座ごとにレピュテーションスコアが異なることがある。
【００６６】
本実施形態においてレピュテーションスコアは、特定の共同口座において特定のユーザが支出申請に対して得られた支出許可の回数（以降、許可回数）、特定のユーザが特定の共同口座に出資した金額から当該共同口座から支出した額を減算した金額（以降、出資額）、および支出申請回数および支出可否情報の発信回数の合計数（以降、参加数）を用いて算出される。具体的に算出部３１７は、許可回数、出資額に第１ファクターを乗じた値、および参加数に第２ファクターを乗じた値の全てを乗算する。この算出結果をそのまま特定の口座における特定のユーザのレピュテーションスコアとしてもよいが、ファクター１およびファクター２を特定の共同口座ごとに適宜設定することで１から５までの段階評価とすることもできる。この場合、上記の乗算結果が１より小さい場合は、レピュテーションスコアを１として表示することができる。すなわち、乗算結果と数値「１」を比較して大きい数値を採用して、四捨五入などによって１から５までの数値を算出結果とする。ファクター１およびファクター２は、共同口座ごとに適宜共同口座の運営状況によって変動する値であってもよく、全ての共同口座に共通の値とすることができる。共同口座ごとにファクターの値が変動する場合は、共同口座を共同保有するユーザが相対的に評価されるため、特定の共同口座における貢献度が算出される。
【００６７】
更にレピュテーションスコアは、許可回数、出資額に第１ファクターを乗じた値、および参加数に第２ファクターを乗じた値の他に、共同口座を保有するユーザ間のコメント投稿内容において他のユーザから良い評価を得た数に第３ファクターを乗じた値を更に乗じてもよい。また、参加数もコメントの投稿数やアクセス数などを含んでもよい。また、共同口座への出資を行った順番を考慮することもできる。例えば、図６においては、共同口座ＩＤがＫ０００３において、開設者のユーザＩＤが０００２であり、その後の共同保有者となった順序が０００１そして０００３であることがわかる。更には、開設者のレピュテーションスコアを高くするようにしてもよい。例えば、図６のユーザＩＤの後に「＊」が表示されているユーザが特定の口座における開設者であり、これらのユーザのレピュテーションスコアを同一条件の他の共同保有者のレピュテーションスコアよりも高くなるようにしてもよい。なお、レピュテーションスコアの算出方法は、様々なユーザ評価方法を採用することができ、上記構成には限定されない。
【００６８】
図６の例では、ユーザＩＤ０００３のユーザが共同口座識別ＩＤがＫ０００１、Ｋ０００２、Ｋ０００３、Ｋ０００４、およびＫ０００５を保有している。しかし、それぞれの共同口座においてレピュテーションスコアが異なることがわかる。これは、各共同口座における出資金額の割合が寄与しているためである。また、共同口座識別ＩＤがＫ０００２においてユーザＩＤが０００４および０００１のユーザが同額の出資をしている状態であるが、それぞれのユーザのレピュテーションスコアが異なる。これは、ユーザＩＤが０００４の本口座における貢献度がユーザＩＤが０００１のユーザと比較して少ないからである。更に、ユーザＩＤが０００１のユーザの方が後に本口座の共同保有者として参加していることにも起因する。
【００６９】
また、図６に示す通り、共同口座テーブル３１２は、個々のユーザ識別情報に個々のユーザの投票の重みを併せて記憶している。この投票の重みとは、判定部３１５が支出可否情報を元に支出申請の可否を判定する際に使われる数値である。すなわち、支出可否に対して支出許可をするか否か決定するために用いられる支出可否情報の反映の度合い（重み）をこの数値によって決定する。
【００７０】
次に投票の重みの算出方法について説明する。投票の重みは、レピュテーションスコア同様に特定の共同口座における個々のユーザの口座への出資額、支出申請回数、および支出可否情報の発信回数などに基づいて個別に算出部３１７が算出する。または、算出部３１７が既に算出したレピュテーションスコアを元に算出されてもよい。すなわち、これらの場合は、算出部３１７が特定の共同口座における貢献度に基づいて投票の重みを算出する。具体的には、レピュテーションスコアが５段階評価である場合には、冪指数を２としてレピュテーションスコアの冪演算を行い、満点である２５で除算を行う。そして、得られた商を加点分として、１に加算することで投票の重みが得られる。投票の重みの算出方法をこれに限定されず、１に加算をせずに減点方式で求めてもよい。
【００７１】
図６の例では、共同口座ＩＤがＫ０００２のユーザＩＤが０００４および０００１のユーザが、共に同一の出資額を有するにも関わらず、投票の重みが異なるのは、ユーザＩＤが０００４のユーザと比較してユーザＩＤが０００１のユーザの方が、全ての共同口座において出資額が大きいことが理由の１つである。
【００７２】
また、投票の重みは、口座管理システム１が提供するウェブサイトが管理する共同口座の全てを元に算出部３１７が算出してもよい。例えば、前述のレピュテーションスコアを元に算出された特定の口座ごとの投票の重みの平均値としてもよい。または、前述のユーザランクを特定の共同口座のレピュテーションスコアに乗じることで算出されてもよい。更には、全ての共同口座において同一ユーザに、共通の投票の重みを付与する構成としてもよい。このように、口座管理システム１が提供するウェブサイトが管理する共同口座の全てを元に投票の重みが決定されることで、特定の共同口座における貢献度だけでなく、全ての共同口座の運営において、ユーザがどのような評価であるかを考慮して、出資の許可情報に反映できるため、判定部３１５は、正確な判定を行うことができる。本実施形態では、このように全ての共同口座の貢献度に基づいて算出された投票の重みを使用する場合について記載する。
【００７３】
（ユーザテーブル３１１の作成方法）
図５Ａに示されるユーザテーブル３１１の作成方法について説明する。ユーザは、サーバ通信部３１９を介してサーバ３と通信をする。サーバ３は、ユーザの個人情報などを要求して、更にそれらの情報を認証するためのパスワードを要求する。ユーザの個人情報は、ユーザ名、メールアドレス、アカウントの認証用のパスワード、電話番号、ユーザの個人的な口座情報などを含む。ユーザテーブル３１１は、ユーザの個人情報以外にユーザのランク情報をユーザ識別情報に対応付けて記憶する。また、サーバ３は、ユーザの本人認証を行うために、ユーザの端末装置２にＳＭＳなどを送信する。なお、本人認証の手法は、ＳＭＳ送信だけに限らず、書留郵便などの郵送による確認や電話による口頭による認証であってもよい。
【００７４】
ユーザテーブル３１１に含まれる情報のうちユーザ自身によって入力される情報については、ユーザが端末装置２からサーバ３にアクセスすることで変更が可能である。例えば、口座管理システム１が提供するウェブサイトにログインした状態で「マイページ」などの個人の情報を表示する画面に情報の更新（変更）ボタンを設けることでユーザの情報の更新をユーザに提供することができる。
【００７５】
サーバ記憶部３１３は、ユーザごとにユーザ識別情報を付与して、当該ユーザ識別情報にユーザの情報として前述の個人情報やユーザのランク情報を対応付けて記憶する。この際、ユーザの個人情報が重複していないかをユーザテーブル３１１を参照して確認することを行ってもよい。例えば、ユーザのメールアドレスが既にユーザテーブル３１１に記憶されている場合には、ユーザの端末装置２にエラーを表示することで、当該ユーザが既に共同口座の口座管理システム１が提供するウェブサイトにログインしたことがあり、既にＩＤを保有していることをユーザに知らせる。
【００７６】
（共同口座テーブル３１２の作成方法）
次に図５Ｂに示される共同口座テーブル３１２および図６に示す特定の共同口座の共同口座詳細テーブルの作成方法について説明する。ユーザは、サーバ通信部３１９を介してサーバ３と通信をする。ユーザが共同口座を開設または共同保有するための情報をサーバに送信することによって、共同口座情報が新設または更新される。この情報を共同口座テーブル３１２は記憶する。また、これらの新設または更新されるタイミングで算出部３１７が算出したレピュテーションスコアや投票の重みを共同口座テーブル３１２は併せて記憶する。更新される情報としては、共同保有の申請（参加申請）、支出申請、支出可否情報、コメント投稿などが含まれてもよい。
【００７７】
（端末装置２の機能）
図７は、ユーザの端末装置２に表示される共同口座情報表示画面７００の一例を示す図である。
【００７８】
図７は、ユーザの端末装置２に表示される共同口座情報表示画面７００の一例を示す図である。この画面は、ユーザとしてログインした後に、口座検索を行った際に抽出された共同口座を選択した際に表示される画面である。共同口座情報表示画面７００は、特定の共同口座の内容を伝え易くするために提示される画像表示領域７０１、この共同口座を共に保有したい際に参加申請を行うための参加申請ボタン７０２、および新規に共同口座を開設するための新規開設ボタン７０３を含む。共同口座情報表示画面７００は、共同口座のタイトル、現在の出資総額、共同保有者の総数、および共同口座の詳細説明などを表示する。
【００７９】
画像表示領域７０１は、共同口座を開設するユーザが他のユーザの共同保有を促すために共同口座の保有の意図が伝わるような画像を表示する。この画像は、複数の画像であってもよく、動画や音声のみによるファイルであってもよい。画像は、開設者以外のユーザであっても選択や変更ができるようになっていてもよい。
【００８０】
参加申請ボタン７０２がユーザに押されると、サーバ通信部３１９を介してサーバ処理部３１８は、共同口座の開設者または既存の共同保有者の端末装置２に参加申請があった旨を送信する。この参加申請は、少なくとも１人の既存の共同保有者が承認する構成としてもよく、共同保有者全員の承諾を必要とする構成としてもよい。もちろん、口座開設者が単独で参加の可否を判断する構成としてもよい。
【００８１】
ユーザは、ユーザは、新規に共同口座を開設する場合に、新規開設ボタン７０３を選択し、その後の遷移先の画面で共同口座のタイトル（名称）、詳細説明、初期の出資額（開設者の出資は任意）、共同保有に必要なユーザランクの情報、および参加可能人数などを入力する。参加可能人数とは、共同口座を開設者と共に保有できるユーザの最大人数のことである。共同口座を新規に開設するためのボタンは、新規開設ボタン７０３以外にも口座管理システム１が提供するウェブサイト内であれば、どのページに配置されていてもよい。例えば、口座管理システム１が提供するウェブサイトにログインした後のトップページに相当するページに表示されていてもよい。
【００８２】
（端末装置２の機能）
図８は、ユーザの端末装置２に表示される共同口座情報表示画面８００の一例を示す図である。
【００８３】
図８は、ユーザが特定の共同口座を共同保有しており、当該特定の共同口座の画面を開いている際のユーザの端末装置２に表示される共同口座情報表示画面８００の一例を示す図である。共同口座情報表示画面８００は、共同口座情報表示画面７００の画像表示領域７０１と同様に画像を表示する画像表示領域８０１を含む。この画像は、画像表示領域７０１と同一でもよく、別の画像であってもよい。また、共同口座情報表示画面８００は、共同口座に出資をするための出資ボタン８０２、共同口座より支出を申請するための支出申請ボタン８０３、共同口座情報を編集するための編集ボタン８０４、共同口座への出資、共同口座からの支出申請やそれに対する許可または否認、共同口座からの実際の支出、および共同保有者の追加や削除の過去の履歴情報を表示する履歴ボタン８０５、他のユーザからの支出申請の可否を登録するための支出可否ボタン８０６、および共同口座を共に保有するユーザ同士のコメントや会話を参照するためのコメントボタン８０７などを含む。
【００８４】
画像表示領域８０１は、共同口座情報表示画面７００の画像表示領域７０１と同様の構成であるため、詳細な説明は繰り返さない。ただし、画像表示領域８０１に表示される画像と画像表示領域７０１に表示される画像とを別の画像にすることも可能である。更に、共同口座情報表示画面８００では、この画像表示領域８０１を割愛するような構成とすることもできる。
【００８５】
支出申請ボタン８０３は、ユーザによって共同口座の残高の一部または全額を支出する申請を行う際に選択される。この支出申請ボタン８０３が選択されると、サーバ通信部３１９は、端末装置２にログインしているユーザの識別情報に対応付けて当該ユーザの支出希望金額および支出の理由や必要性について説明したテキストを端末装置２から受信する。
【００８６】
編集ボタン８０４は、共同口座の開設者のみに表示されることが望ましいが、開設者の設定や要求によって共同編集者を追加することもできる。共同口座の編集内容としては、共同口座のタイトル、詳細説明、共同保有に必要なユーザランクの情報、および参加可能人数などが含まれる。
【００８７】
履歴ボタン８０５を押すことでユーザは、他の共同保有者の出資した金額や支出した金額の一覧が見られる。他のユーザの情報は、この履歴ボタン８０５を選択する構成以外にも共同口座情報表示画面８００に表示されている「共同出資額」のテキストを選択する構成や履歴ボタン８０５の他に出資内訳を表示させるための出資内訳ボタン（図示しない）を設ける構成であってもよい。
【００８８】
支出可否ボタン８０６は、他の申請者からの支出申請に対して可否情報を入力できる。支出可否情報は、同意および反対の選択であってもよく、５段階評価であってもよい。例えば、１：とても非同意、２：非同意、３：どちらでもない、４：同意、および５：とても同意などの評価であってもよい。この場合、可否情報として判定部３１５は、複数のユーザから受信した可否情報である数値を元に支出申請の可否を判定する。なお、支出可否ボタン８０６は、支出可否を入力していない支出申請が存在する場合のみに、支出可否を入力していないユーザの端末装置２に表示されるようにしてもよい。
【００８９】
コメントボタン８０７は、特定の共同口座ごとに設けられるコメントスペースである。ここで特定の共同口座を共同保有するユーザ同士の会話や意見交換がされる。例えば、共同口座の支出を希望するユーザの意見を述べたり、可否情報を生成するユーザによる申請者への質問をしたりすることができる。なお、支出に関するコメントの記載は、支出申請ボタン８０３を選択した際にユーザが記載することができ、このコメントへの返信などは、支出可否ボタン８０６を選択した際にできるようにしてもよい。その場合、コメントは、特定の共同口座の運営全般にかかるユーザ同士の会話の場として設けてもよい。
【００９０】
（口座管理システム１による処理）
図９は、本実施形態にかかる口座管理システム１による共同口座の開設から共同口座の出資額の支出申請を許可するまでの一連の流れの動作シーケンスの一例を示す図である。
【００９１】
以下に説明する動作シーケンスは、予めサーバ記憶部３１３に記憶されているプログラムに基づいて、主にサーバ処理部３１８により、サーバ３の各要素と協働して実行される。また、以下に説明する動作シーケンスは、予め端末装置２の端末記憶部２１２に記憶されているプログラムに基づいて、主に端末装置２の端末処理部２１５により、端末装置２の各要素と協働して実行される。また、以下に説明する動作シーケンスにおいて、サーバ３は、サーバ通信部３１９を介して端末装置２と各種の情報を送受信する。
【００９２】
最初にサーバ３の受付部３１４は、ユーザの端末装置２から共同口座の開設するために必要な情報を受信する（Ｓ１０１）。必要な情報とは、ユーザのユーザ識別情報、共同口座のタイトル、詳細説明、初期の出資額、共同保有に必要なユーザランクの情報、および参加可能人数などである。口座の新規開設が完了すると、共同口座は、共同口座の管理システム１が提供するウェブサイト内で公開され、ログインしている他のユーザにも閲覧可能となり、共同保有のための参加申請ができるようになる。
【００９３】
次に、受付部３１４は、Ｓ１０１で新規に開設された共同口座の共同保有を希望するユーザからの参加申請を受け付ける（Ｓ１０２）。参加申請は、共同口座を開設したユーザのみに送信されてもよく、他の共同保有者に送信されてもよい。
【００９４】
続いて、受付部３１４は、参加申請に対して許可をするか否かの情報を受け付ける（Ｓ１０３）。参加申請が許可されない場合、本処理は終了して、他のユーザからの参加申請を受け付ける（Ｓ１０３がＮＯ）。
【００９５】
一方、参加申請が許可された場合（Ｓ１０３がＹＥＳ）、受付部３１４は、参加が許可されたユーザの情報をサーバ記憶部３１３に送信し、サーバ記憶部３１３は、ユーザの情報をユーザテーブル３１１に記憶する。
【００９６】
共同口座の開設者は、随時共同口座に出資を行うことができる。また、共同口座の共同保有者は、参加申請が許可された後であれば、随時共同口座に出資を行うことができる。出資情報は、共同口座３１２にユーザごとの出資金額として記憶される。なお、本実施形態では、共同保有者は、参加申請と共に初期出資額を決定した上で参加申請をサーバ３に送信するため、参加の許可がされた後に更に出資を行わないこともできる。
【００９７】
次に受付部３１４は、共同口座の開設者または共同保有者から支出の申請を受け付ける（Ｓ１０４）。支出申請に含まれる情報は、ユーザ識別情報および支出希望金額が含まれる。また、支出希望金額は、共同口座の残高が最高金額となり、当該最高金額以下の金額しか指定できないようサーバ処理部３１８が適宜エラーをユーザの端末装置２にサーバ通信部３１９を介して送信する。なお、受付部３１４が支出の申請を受け付けていない場合（Ｓ１０４がＮＯ）は、この処理が続けられる。
【００９８】
受付部３１４が支出申請を受け付けると、判定部３１５は、支出可否情報を支出申請者以外のユーザから受け付けるためにユーザの端末装置２の共同口座情報表示画面８００の支出可否ボタン８０６が選択可能な状態となるように生成部３１６を制御する。支出可否ボタン８０６が選択可能な状態となるユーザは、レピュテーションスコアが高い一部のユーザであってもよく、まずは申請者以外の全てのユーザに選択可能な状態としてもよい。一部のユーザのみに支出可否ボタン８０６が選択可能な状態とするために、共同口座テーブル３１２は、特定の共同口座における複数のユーザのレピュテーションスコアを記憶しており、判定部３１５は、レピュテーションスコアの高いユーザを上位から選択して、上位から所定数のユーザまたは所定割合のユーザに支出可否ボタン８０６を選択可能な状態とする。
【００９９】
本発明では、共同口座の開設者および共同保有者が３人以上となるまでは、開設者は開設者の出資額、共同保有者は共同保有者の出資額のみ支出許可情報なしに支出可能な状態となる。２人以上の共同保有者が集まった場合に、本発明の特徴が有効な状態となる。すなわち、本発明は、共同口座の開設者および共同保有者が３人以上であり、支出申請に対して申請者以外のユーザの一部の支出可否情報を考慮することで特定の共同口座において貢献度が高いユーザのみの支出可否情報を元に支出許可情報または支出否認情報を生成することができる。更に、共同口座の共同保有者が２人以上の場合であっても開設者は開設者の出資額、共同保有者は共同保有者の出資額は支出許可情報なしに支出可能である。本発明では、自身の出資額を超えて支出を希望する場合に支出可否情報を送信する構成となっている。
【０１００】
例えば、図６の共同口座ＩＤがＫ０００２の口座において、支出の申請を口座開設者であるユーザＩＤが０００２が行った場合に、支出可否情報を必要とするユーザ数が２人であれば、リピュテーションスコアの高い２人であるユーザＩＤが０００３および０００１のユーザに支出可否情報をサーバ３に送信可能とする。また、支出可否情報を必要とするユーザ数が７０％以上であると設定されている場合には、共同口座の保有者４人のうち３人（７５％）の支出可否情報が必要となる。よって、ユーザＩＤが０００３、０００１、０００４のユーザに支出可否情報をサーバ３に送信可能とする。
【０１０１】
受付部３１４が、支出の申請を受け付けた場合（Ｓ１０４がＹＥＳ）、判定部３１５は、支出可否情報を受け付ける（Ｓ１０５）。そして、判定部３１５は、所定時間が経過したか、または所定数または所定割合の支出可否情報が集まったかを判定する（Ｓ１０６）。支出可否情報の受け付けは、所定時間が経過するまで、または所定数または所定割合の支出可否情報が集まるまで係属される（Ｓ１０６がＮＯ）。
【０１０２】
判定部３１５は、所定時間が経過した場合、または所定数または所定割合の支出可否情報が集まった場合（Ｓ１０６がＹＥＳ）、レピュテーションスコアおよび投票の重みに基づいて支出申請を許可するか否かを判定する（Ｓ１０７）。
【０１０３】
具体的に判定部３１５は、レピュテーションスコアの高いユーザの所定数または所定割合から支出可否情報を受け取れる状態とする。そして、サーバ通信部３１９が受信した支出可否情報に投票の重みを乗じた値の平均値を元に判定部３１５が支出申請を許可するか否認するかを判定する。判定部は、平均値が所定の値を超えたか否かに応じて支出申請を許可するか否認するかを判定する。なお、この所定の値は、支出可否情報に含まれる支出希望額が大きければ大きいほど高くなるように判定部３１５が設定してもよい。このような構成とすることで、判定部３１５は、支出可否情報に含まれる支出希望額が高ければ高いほど、または共同口座の残高に対する割合が高いほど支出申請に対して許可する判定をしにくくする。
【０１０４】
判定部３１５は、支出可否情報が同意または反対のいずれかである場合は、同意を「１」として反対を「０」などの値（点数）として判定を行う。支出可否情報が５段階評価などの数値情報を予め含む場合は、投票の重みを５段階評価の値（点数）に乗じて判定部３１５は、支出申請を許可するか否認するかを判定する。また、判定部３１５は、全てのユーザから支出可否情報を受信している場合には、レピュテーションスコアに応じて、レピュテーションスコアの高いユーザの所定人数または所定割合の支出可否情報を元に支出申請を許可または否認の判定を行う。
【０１０５】
判定部３１５が支出申請を許可すると判定した場合（Ｓ１０７がＹＥＳ）、生成部３１６は、支出許可情報を生成する（Ｓ１０８）。また、判定部３１５が支出申請を否認すると判定した場合（Ｓ１０７がＮＯ）、生成部３１６は、支出否認情報を生成する（Ｓ１０９）。
【０１０６】
生成部３１６が支出許可情報を生成した場合（Ｓ１０８）、判定部３１５は、支出申請に含まれる申請者のユーザ識別情報に申請された支出額を対応付けて記憶部３１３に記憶する（Ｓ１１０）。具体的には、共同口座テーブル３１２に記録されて、処理が終了される。この支出額は、支出申請をしたユーザの支出可能額として共同口座テーブル３１２に記録されてもよく、ユーザの個人の口座に振り込んでもよい。一方、生成部３１６が支出否認情報を生成した場合（Ｓ１０９）、処理が終了される。あるいは、共同口座テーブル３１２に否認された情報を記憶してもよい。
【０１０７】
以上説明したように、本実施形態にかかる口座管理システム１は、複数のユーザによって共同保有されている共同口座からの支出申請の可否をレピュテーションスコアおよび投票の重みを使用して適切に判定することができる。すなわち、口座管理システム１は、特定の共同口座において、貢献度の高いユーザの可否情報を多く考慮して支出申請の可否を判定することができる。また、口座管理システム１で管理する全ての共同口座でのユーザの貢献度を元に共同口座からの支出申請の可否の情報を重み付けできるため、共同口座の運用に熟練したユーザの意見の重みを大きくすることができる。
【０１０８】
当業者は、本発明の精神および範囲から外れることなく、様々な変更、置換および修正をこれに加えることが可能であることを理解されたい。
【０１０９】
（変形例１）
本実施形態において判定部３１５は、所定時間が経過したか、または所定数または所定割合の支出可否情報が集まったかを判定したが、所定時間が経過した場合に所定数または所定割合の支出可否情報が集まっていない場合には、所定時間を延長する構成としてもよい。
【０１１０】
（変形例２）
本実施形態において判定部３１５は、Ｓ１０７において、レピュテーションスコアおよび投票の重みに基づいて支出申請を許可するか否認かを判定したが、レピュテーションスコアのみによって、一部のユーザからの支出可否情報を元に支出申請を許可するか否認するかを判定してもよい。本構成によると、算出部３１７は、投票の重みを算出しなくてよいため、処理を軽くすることができる。
【０１１１】
（変形例３）
一方、判定部３１５は、Ｓ１０７において、投票の重みのみによって、支出可否情報を元に支出申請を許可するか否認するかを判定してもよい。投票の重みのみによって支出申請を許可するか否認する場合、全ての支出申請者以外のユーザから支出可否情報を受信して、投票の重みを支出可否情報に乗じることで判定部３１５が判定を行う。この場合の投票の重みは、特定の口座における貢献度のみによって算出されてもよく、他の共同口座の全てを元に投票の重みが決定されてもよい。本構成によると、算出部３１７は、レピュテーションスコアを算出しなくてよいため、処理を軽くすることができる。
（変形例４）
本実施形態において判定部３１５は、支出可否情報を元に支出申請を許可するか否認するかを判定したが、判定部３１５は、支出可否情報を元に支出申請に含まれる支出希望額のうちどの程度まで許可をするかを判定してもよい。すなわち、支出可否情報に支出申請に同意する情報が多く含まれれば含まれるほど、支出希望額に近い額が支出可能額として判定される。この場合、生成部３１６は、支出許可額が含まれる情報を許可情報として生成する。
【０１１２】
（本発明の適用範囲）
本発明の適法範囲は、セーフティネット、クラウドファンディング、ファンクラブ、共同財布、マーケティングツールなど、あらゆる共同口座を含む。セーフティネットに本発明を適用した場合、共同口座の保有者は、あるリスクに対して金額を出資しあって、リスクに遭遇したユーザが共同口座から支出をする。既存の保険ではカバーできないニッチな分野にも本発明を適用することができる。本発明の共同口座は、既存のクラウドファンディングとは異なり、期限が存在しないため、コミュニティ（共同保有者）として継続的に出資および支出を繰り返すことができる。ファンクラブに本発明を適用した場合、メンバー（共同保有者）がフラットに発言できるため、１対１のコミュニケーションが可能となる。すなわち、ファン活動の企画案をファンから収集して、実行を共同口座の出資額から支出できるため、シームレスにファンクラブの運営ができる。共同財布に本発明を適用した場合、不透明な支出や細かいやりとりを削減できるため、共同口座の管理や運営が容易になる。マーケティングツールとして本発明を適用した場合、会社の理念に基づくキャンペーン企画やＣＳＲ活動を、共同口座を保有するユーザにアウトソースすることができる。これによってユーザ（顧客）のロイヤリティを向上することができる。
【符号の説明】
【０１１３】
１        口座管理システム
２        端末装置
２１１    端末通信部
２１２    端末記憶部
２１３    端末操作部
２１４    端末表示部
２１５    端末処理部
３        サーバ
３１１    ユーザテーブル
３１２    共同口座テーブル
３１３    サーバ記憶部
３１４    受付部
３１５    判定部
３１６    生成部
３１７    算出部
３１８    サーバ処理部
３１９    サーバ通信部
【図１】
2019197512.tif 000003
【図２】
2019197512.tif 000004
【図３】
2019197512.tif 000005
【図４】
2019197512.tif 000006
【図５Ａ】
2019197512.tif 000007
【図５Ｂ】
2019197512.tif 000008
【図６】
2019197512.tif 000009
【図７】
2019197512.tif 000010
【図８】
2019197512.tif 000011
【図９】
2019197512.tif 000012