JP6688420B2 - 取引管理装置、取引管理方法及びプログラム - Google Patents

取引管理装置、取引管理方法及びプログラム Download PDF

Info

Publication number
JP6688420B2
JP6688420B2 JP2019084198A JP2019084198A JP6688420B2 JP 6688420 B2 JP6688420 B2 JP 6688420B2 JP 2019084198 A JP2019084198 A JP 2019084198A JP 2019084198 A JP2019084198 A JP 2019084198A JP 6688420 B2 JP6688420 B2 JP 6688420B2
Authority
JP
Japan
Prior art keywords
transaction
value
entity
account
received
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2019084198A
Other languages
English (en)
Other versions
JP2019197544A (ja
Inventor
和宏 石原
和宏 石原
正宣 小山
正宣 小山
浩一 大熊
浩一 大熊
Original Assignee
アビームコンサルティング株式会社
凸版印刷株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority to JP2018089272 priority Critical
Priority to JP2018089272 priority
Application filed by アビームコンサルティング株式会社, 凸版印刷株式会社 filed Critical アビームコンサルティング株式会社
Publication of JP2019197544A publication Critical patent/JP2019197544A/ja
Application granted granted Critical
Publication of JP6688420B2 publication Critical patent/JP6688420B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Description

本発明は、取引管理装置、取引管理方法及びプログラムに関する。
現在、シェアリングエコノミー(Sharing economy)と呼ばれる、モノ(物)や人的リソース等を複数のユーザと共有することで、モノや人的リソースを必要になったときだけ使用することが可能なサービスが提供されている。また、シェアリングエコノミーの中でも、人的スキルや人的リソースを共有するサービスについてはクラウドソーシング(crowdsourcing)とも呼ばれている。
例えば特許文献1には、クラウドソーシングに関する技術として、プレ発注情報に対する返答に基づいて発注を依頼するユーザをスクリーニングした後に、実際に発注情報を送信して仕事を依頼することで成果物の信頼性を高めることが可能な技術が開示されている。
特開2016−134028号公報
しかしながら、クラウドソーシングに関するサービスでは、報酬の支払いは、発注者(又はサービス提供者)と受注者(又はサービス利用者)の間で銀行口座を介した金銭の支払いが行われることが一般的である。そのため、報酬が実際に受注者に支払われるまでの間に最低でも1日程度のタイムラグが生じてしまうという課題と、銀行口座間での資金移動の際に振込手数料等の手数料が生じてしまい、コスト増につながるという課題とが生じていた。なお、同様の課題は、クラウドソーシングやシェアリングエコノミーに限られず、取引主体の間で資金移動を行う場合全般に生じ得る。
本発明は、上記に鑑みてなされたものであって、取引主体の間で報酬の支払いを迅速かつ低コストで行うことが可能な技術を提供することを目的とする。
本発明の一態様に係る取引管理装置は、複数の取引主体の間で行われる取引を管理する取引管理装置であって、取引を依頼した取引主体から該取引を受けた取引主体に銀行の預金とは異なるバリューを移動させることを指示するバリュー移動情報を受け付ける受付部と、受付部で受け付けたバリュー移動情報に基づいて、取引を依頼した取引主体のバリュー残高から、取引を受けた取引主体のバリュー残高に、バリュー移動情報で指示される額のバリューを移動させる移動処理部と、を有する。
本発明によれば、取引主体の間で報酬の支払いを迅速かつ低コストで行うことが可能な技術を提供することができる。
第1実施形態に係るシェアリングエコノミー提供システムのシステム構成例を示す図である。 第1実施形態に係るシェアリングエコノミー提供システムが行う動作の概要を説明するための図である。 取引管理装置のハードウェア構成例を示す図である。 第1実施形態に係る取引管理装置の機能ブロック構成例を示す図である。 第1実施形態に係る内部ID情報の具体例を示す図である。 第1実施形態に係る外部ID情報の具体例を示す図である。 バリュー移動履歴の具体例を示す図である。 第1実施形態に係るシェアリングエコノミー提供システムが行う処理手順の一例を示すシーケンス図である。 第2実施形態に係るシェアリングエコノミー提供システムが行う動作の概要を説明するための図である。 第2実施形態に係るシェアリングエコノミー提供システムが行う動作の概要を説明するための図である。 第2実施形態に係る取引管理装置の機能ブロック構成例を示す図である。 第2実施形態に係る内部ID情報の一例を示す図である。 第2実施形態に係る外部ID情報の一例を示す図である。 第2実施形態に係る口座情報の一例を示す図である。 第2実施形態に係るシェアリングエコノミー提供システムが行う処理手順の一例を示すシーケンス図である。 第2実施形態に係るシェアリングエコノミー提供システムが行う処理手順の一例を示すシーケンス図である。 第2実施形態に係るシェアリングエコノミー提供システムが行う処理手順の一例を示すシーケンス図である。 第2実施形態に係るシェアリングエコノミー提供システムが行う処理手順の一例を示すシーケンス図である。 第2実施形態に係るシェアリングエコノミー提供システムが行う処理手順の一例を示すシーケンス図である。 第2実施形態に係るシェアリングエコノミー提供システムが行う動作の変形例を説明するための図である。 第2実施形態に係るシェアリングエコノミー提供システムが行う動作の変形例を説明するための図である。
添付図面を参照して、本発明の好適な実施形態について説明する。なお、各図において、同一の符号を付したものは、同一又は同様の構成を有する。以下の説明において、シェアリングエコノミーには、クラウドソーシングを含むあらゆるシェアリングエコノミーが含まれる。
<<第1実施形態>>
<システム構成>
図1は、第1実施形態に係るシェアリングエコノミー提供システム1のシステム構成例を示す図である。シェアリングエコノミー提供システム1は、取引管理装置10と、外部装置(法人Aシステム)20aと、外部装置(法人Bシステム)20bと、外部装置(法人Cシステム)20cと、外部装置(個人b端末)20dと、外部装置(個人c端末)20eと、外部装置(個人d端末)20fと、外部装置(個人e端末)20gと、外部装置(個人f端末)20hと、外部装置(個人a端末)20iと、外部装置(個人g端末)20jと、プリペイドシステム30とを含む。以下の説明において、外部装置(法人Aシステム)20aと、外部装置(法人Bシステム)20bと、外部装置(法人Cシステム)20cと、外部装置(個人b端末)20dと、外部装置(個人c端末)20eと、外部装置(個人d端末)20fと、外部装置(個人e端末)20gと、外部装置(個人f端末)20hと、外部装置(個人a端末)20iと、外部装置(個人g端末)20jとを区別しない場合は、「外部装置20」と記載する。
取引管理装置10は、複数の取引主体の間で行われる取引を管理するシステムであり、取引主体の間で取引が完了した際に行われる金銭の支払いを、金銭、商品及び/又はサービスと交換することが可能な価値を有しており、銀行の預金とは異なる“バリュー”を移動させることで行うシステムである。取引管理装置10は、取引主体を取引管理装置10の中で一意に特定するための識別子(以下、「内部ID(Identification)」と言う。)を用いて、取引管理装置10を利用する取引主体を管理する。取引管理装置10は、複数の情報処理装置から構成されていてもよいし、単体の情報処理装置から構成されていてもよい。また、クラウドサーバや仮想サーバにより構成されていてもよい。
バリューの具体例としては、電子マネー、プリペイドカードのチャージ額、仮想通貨、ポイントカード又はオンラインショッピングサイト等に蓄積されるポイント、マイレージ等が挙げられるが、これらに限られない。第1実施形態では、バリューとは、国際ブランドを付帯したプリペイドカード(以下、「プリペイドカード」と言う。)のチャージ額を意味するものとして説明する。取引管理装置10は、取引を依頼した取引主体から取引を受けた取引主体に所定のバリューを移動させることを指示する情報(以下「バリュー移動情報」と言う。)を外部装置20から受信し、当該所定のバリューの移動をプリペイドシステム30に指示する。つまり、実際のバリューの移動は、プリペイドカードを管理するプリペイドシステム30側で行われる。バリューの移動とは、具体的には、支払元の取引主体が所有するプリペイドカードのチャージ額から所定の金額を減算し、支払先の取引主体が所有するプリペイドカードのチャージ額に当該所定の金額を加算することである。
各々の取引主体は、法人、個人、又は、複数の個人を含むグループ(以下、「個人グループ」とも言う。)である。取引管理装置10は、法人対個人の取引、法人同士(法人対法人)の取引、個人同士(個人対個人)の取引、複数の個人を含むグループ対個人の取引、複数の個人を含むグループ対法人の取引、複数の個人を含むグループ同士の取引など、様々な組み合わせの取引に対応することができる。取引とは、どのような取引であってもよいが、例えば、所有物を貸し出す取引、商品又は労働力を提供する取引等が挙げられる。取引主体は、取引ごとに、同一であってもよいし、取引ごとに異なっていてもよい。同様に、個人グループについても、取引ごとに、当該取引を行う複数の個人が同一であってもよいし、異なっていてもよい。
第1実施形態において、「取引を依頼する取引主体」とは、例えば、労働力の提供を依頼する取引主体、所有物の貸し出しを依頼する取引主体など、支払いを行う側の取引主体を意味する。同様に、「取引を受ける取引主体」とは、例えば、労働力を提供する取引主体、所有物を貸し出す取引主体など、支払いを受ける取引主体を意味する。なお、以下の説明において、「取引を依頼する取引主体」を、便宜上、「発注者」や「支払元の取引主体」と呼ぶことがある。また、「取引を受ける取引主体」を、便宜上、「受注者」や「支払先の取引主体」と呼ぶことがある。
外部装置(法人Aシステム)20aは、法人Aがシェアリングエコノミーサービスを提供するためのシステムである。外部装置(法人Bシステム)20bは、法人Bがシェアリングエコノミーサービスを提供するためのシステムである。外部装置(法人Cシステム)20cは、法人Cがシェアリングエコノミーサービスを提供するためのシステムである。法人A、法人B及び法人Cが提供するシェアリングエコノミーサービスとは、例えば、個人や法人の所有物(自動車、自転車、部屋等)を一定期間、第3者に貸与するサービスや、業務を依頼する側と業務を請け負う側とをマッチングさせることで、人的スキルや人的リソースを共有するサービス(いわゆるクラウドソーシング)が挙げられる。法人A、法人B及び法人Cが提供するシェアリングエコノミーサービスでは、法人対個人、法人同士(法人対法人)、個人同士(個人対個人)、個人グループ対個人、個人グループ対法人、個人グループ同士(個人グループ対個人グループ)など、様々な取引主体をマッチングさせることができる。
外部装置(個人b端末)20dは、個人bが利用する端末である。外部装置(個人c端末)20eは、個人cが利用する端末である。外部装置(個人d端末)20fは、個人dが利用する端末である。外部装置(個人e端末)20gは、個人eが利用する端末である。外部装置(個人f端末)20hは、個人fが利用する端末である。外部装置(個人a端末)20i、は、個人aが利用する端末である。外部装置(個人g端末)20jは、個人gが利用する端末である。
外部装置20は、複数の情報処理装置から構成されていてもよいし、単体の情報処理装置から構成されていてもよい。単体の情報処理装置の場合、パーソナルコンピュータ、スマートフォン、タブレット端末、携帯電話等であってもよい。また、外部装置20は、クラウドサーバや仮想サーバにより構成されていてもよい。
すなわち、外部装置20には、シェアリングサービスを提供する装置(又はシステム)としての役割を有する外部装置20と、取引管理装置10にアクセスするための端末としての役割を有する外部装置20との両方が含まれる。前者の役割を有する外部装置20は、例えば、取引主体同士をマッチングさせる機能や、取引完了時に対価の支払いを取引管理装置10に依頼する機能等を提供する。後者の役割を有する外部装置20は、例えば、取引管理装置10にアクセスすることでバリュー残高を表示する機能等を提供する。なお、外部装置(法人Aシステム)20a、外部装置(法人Bシステム)20b及び外部装置(法人Cシステム)20cは、法人A、法人B及び法人C自身が取引主体となってシェアリングサービスを利用する場合に、法人A、法人B及び法人Cが自身のバリュー残高等を参照する際にも用いることができる。すなわち、外部装置20は、上述した前者の役割と後者の役割の両方を有することも可能である。
シェアリングエコノミーサービスを提供する外部装置20は、それぞれ、外部装置20の中で、取引主体を一意に特定するための識別子(ID)(以下、「外部ID」と言う。)を用いて、取引主体を管理する。外部IDは、具体的には、外部装置20が提供するシェアリングエコノミーサービスで利用されるIDである。外部IDは、外部装置20の中で取引主体を一意に特定できるものであればどのようなIDであってもよい。例えば、外部装置20が発行したIDであってもよいし、第三者より発行されたIDであってもよい。
特定の外部装置20で用いられる外部IDを有する取引主体のグループを、「サービスグループ」と呼ぶ。第1実施形態では、外部装置(法人Aシステム)20aで用いられる外部IDを有する取引主体のグループである“法人Aサービスグループ”と、外部装置(法人Bシステム)20bで用いられる外部IDを有する取引主体のグループである“法人Bサービスグループ”と、外部装置(法人Cシステム)20cで用いられる外部アカウントを有する取引主体のグループである“法人Cアカウントグループ”とが存在する。
1つの取引主体は、複数のサービスグループに属することができる。第1実施形態では、図1に示すように、個人b、個人c及び個人dが、法人Aサービスグループに属しているものとする。すなわち、個人b、個人c及び個人dが、法人Aにより提供されるシェアリングエコノミーサービスを利用できるものとする。また、個人c、個人d及び個人eが、法人Bサービスグループに属しているものとする。すなわち、個人c、個人d及び個人eが、法人Bにより提供されるシェアリングエコノミーサービスを利用できるものとする。また、個人a、個人e、個人f及び個人gが、法人Cアカウントグループに属しているものとする。すなわち、個人a、個人e及、個人f及び個人gは、法人Cにより提供されるシェアリングエコノミーサービスを利用できるものとする。
プリペイドシステム30は、プリペイドカードの管理を行う。具体的には、プリペイドシステム30は、プリペイドカードの発行、チャージ処理、減算処理等といった処理を行う。また、プリペイドシステム30は、取引管理装置10からの指示を受けて、2つのプリペイドカード間でチャージ額の移動を行う。第1実施形態では、取引管理装置10を利用する取引主体は、個人グループを除き、既にプリペイドシステム30が発行するプリペイドカードを所有している前提とする。
<動作概要>
図2は、第1実施形態に係るシェアリングエコノミー提供システム1が行う動作の概要を説明するための図である。例えば、個人bは、法人Aから業務の委託(法人Aのホームページ作成等)を受けて当該業務を完了させたとする(S11)。法人Aは、個人bが行った業務の検収を行った後、個人bが行った業務に対する対価を個人bに支払う。このとき、外部装置(法人Aシステム)20aは、取引管理装置10に対して、法人Aから個人bに所定の金額を支払うことを指示するバリュー移動情報を送信する(S12)。
当該バリュー移動情報を受信した取引管理装置10は、所定の金額を、法人Aに対応づけられているバリューから個人bに対応づけられているバリューに移動させる(S13)。具体的には、取引管理装置10は、所定の金額に該当するバリューを、法人Aのプリペイドカードから個人bのプリペイドカードに移動させることをプリペイドシステム30に指示する。法人A及び個人dとの間における業務の委託に関する一連の手順(S21、S22、S23)及び法人B及び個人eとの間における業務の委託に関する一連の手順は、それぞれ、法人A及び個人bの間における一連の手順(S11、S12、S13)と同一であるため説明は省略する。
取引管理装置10は、法人間でもバリューを移動させることができる。例えば、法人Bは、法人Aから業務の委託を受けて、当該業務を完了させたとする。この場合、外部装置(法人Aシステム)20aは、取引管理装置10に対して、法人Aから法人Bに所定の金額を支払うことを指示するバリュー移動情報を送信する(S31)。該バリュー移動情報を受信した取引管理装置10は、所定の金額を、法人Aに対応づけられているバリューから法人Bに対応づけられているバリューに移動させる(S32)。このような動作は、例えば、外部装置(法人Aシステム)20aの外部IDに、法人Bを登録しておくことで対応可能である。
取引管理装置10は、個人間でもバリューを移動させることができる。例えば、法人Bが提供するシェアリングエコノミーサービスでは、業務を依頼したい個人と、業務を受けたい個人との間でマッチングを行うサービスを提供していると仮定する。この場合において、例えば、個人cは個人dから業務の委託を受けて、当該業務を完了させたとする(S41)。この場合、外部装置(法人Bシステム)20bは、取引管理装置10に対して、個人dから個人cに所定の金額を支払うことを指示するバリュー移動情報を送信する(S42)。該バリュー移動情報を受信した取引管理装置10は、所定の金額を、個人dに対応づけられているバリューから個人cに対応づけられているバリューに移動させる(S43)。
取引管理装置10は、個人グループと個人との間でのバリューを移動させることができる。例えば、個人a及び個人gが共同で、個人fから業務を受託し、個人a及び個人gは共同当該業務を完了させたとする(S61)。この場合、外部装置(法人Cシステム)20cは、取引管理装置10に対して、個人fが個人a及び個人gに所定の金額を支払うことを指示するバリュー移動情報を送信する(S62)。該バリュー移動情報を受信した取引管理装置10は、所定の金額を、個人fに対応づけられているバリューから個人a及び個人gに共通に対応づけられているバリューに移動させる(S63)。
<ハードウェア構成>
図3は、取引管理装置10のハードウェア構成例を示す図である。図3に示すように、取引管理装置10は、CPU(Central Processing Unit)11、メモリ又はHDD(HardDisk)等の記憶装置12、通信ネットワークNと接続するために用いられる通信IF(Interface)13、キーボードやタッチパネル等の入力装置14及びディスプレイ等の出力装置15を含む。
<機能ブロック構成>
図4は、第1実施形態に係る取引管理装置10の機能ブロック構成例を示す図である。取引管理装置10は、受付部101と、特定部102と、判定部103と、移動処理部104と、記憶部105とを有する。
記憶部105は、取引管理装置10を利用する取引主体に払い出された内部ID等を管理する情報である内部ID情報と、内部IDと外部IDとを対応づける情報である外部ID情報と、バリューの支払元及び支払先並びに移動したバリューの額を管理するバリュー移動履歴とを記憶する。なお、内部ID情報と外部ID情報とをまとめて“管理情報”と呼んでもよい。
受付部101と、特定部102と、判定部103と、移動処理部104とは、CPU11が、記憶装置12に記憶されたプログラムを実行することで実現することができる。なお、当該プログラムは、例えば非一時的な記憶媒体に格納することができる。当該プログラムを格納した記憶媒体は、非一時的な記憶媒体であってもよい。非一時的な記憶媒体は特に限定されないが、例えば、USBメモリ又はCD−ROM等の記憶媒体であってもよい。また、記憶部105は、記憶装置12を用いて実現することができる。
受付部101は、取引を依頼した取引主体から取引を受けた取引主体に所定のバリューを移動させることを指示するバリュー移動情報を、外部装置20から受け付ける。バリュー移動情報には、取引を依頼した取引主体を示す外部IDと、取引を受けた取引主体を示す外部IDと、移動させる所定のバリューの額とが含まれる。
特定部102は、受付部101がバリュー移動情報を受け付けると、取引を依頼した取引主体の外部IDに対応する内部IDを外部ID情報から取得することで、取引を依頼した取引主体を一意に特定する。同様に、特定部102は、取引を受けた取引主体の外部IDに対応する内部IDを外部ID情報から取得することで、取引を受けた取引主体を一意に特定する。
判定部103は、受付部101がバリュー移動情報を受け付けた場合、取引を依頼した取引主体が、取引を受けた取引主体に移動させる所定のバリューを支払う能力があるか否かを判定する。具体的には、判定部103は、取引を依頼した取引主体が保有するバリュー残高が、取引を受けた取引主体に移動させる所定のバリューの額以上であるか否かを判定する。当該バリュー残高が所定のバリューの額以上である場合、取引を受けた取引主体に移動させる所定のバリューを支払う能力があると判定し、当該バリュー残高が所定のバリューの額未満である場合、取引を受けた取引主体に移動させる所定のバリューを支払う能力がないと判定する。
なお、内部ID情報にバリュー残高を格納しておき、判定部103は、当該内部ID情報アクセスすることで、取引を依頼した取引主体が保有するバリュー残高を把握するようにしてもよい。若しくは、判定部103は、プリペイドシステム30に問い合わせることで、取引を依頼した取引主体が保有するバリュー残高を把握するようにしてもよい。
移動処理部104は、受付部101がバリュー移動情報を受け付けた場合、特定部102で一意に特定された“取引を依頼した取引主体”のバリュー残高から、特定部102で一意に特定された“取引を受けた取引主体”のバリュー残高に、所定のバリューを移動させる。移動処理部104は、受付部101がバリュー移動情報を受け付けた場合であって、かつ、判定部103が、取引を受けた取引主体に移動させる所定のバリューを支払う能力があると判定した場合に、所定のバリューを移動させる処理を行うようにしてもよい。
前述の通り、所定のバリューの移動は、プリペイドカードにチャージされた額を移動させることで行われる。つまり、移動処理部104は、所定のバリューを、取引を依頼した取引主体が所有するプリペイドカード(第1プリペイドカード)から取引を受けた取引主体が所有するプリペイドカード(第2プリペイドカード)に移動させることを指示する情報をプリペイドシステム30に送信することで、所定のバリューを移動させる。 図5は、内部ID情報の具体例を示す図である。「内部ID」には、内部IDであるIDが格納される。内部IDは、取引主体ごとに一意になるように割り当てられる。「バリュー残高」には、取引主体が保有するバリューの残高が格納される。具体的には、取引主体の各々が所有するプリペイドカードの残高が格納される。なお、バリュー残高は、プリペイドシステム30に問い合わせることでも確認可能であることから、内部ID情報から「バリュー残高」は省略されていてもよい。「プリペイドカード番号」には、取引主体が所有するプリペイドカードの番号が格納される。なお、図5の例では、取引主体が個人グループの場合、プリペイドカード番号が格納されていない。これは、現在、個人グループとして保持可能なプリペイドカードが存在しないためである。しかしながら、将来個人グループがプリペイドカードを保持することが可能になった場合はこの限りではない。
「取引主体の属性情報」には、取引主体の名称及び区分(例えば法人、個人、個人グループのいずれか)が格納される。「取引主体の属性情報」には、更に、図5に示す属性情報以外の情報が格納されていてもよい。内部ID情報は、例えば、取引主体が取引管理装置10に利用登録を行う際に生成されることとしてもよい。
図6は、外部ID情報の具体例を示す図である。「外部ID」には外部IDが格納される。「内部ID」には、内部IDが格納される。「サービスグループ」には、外部IDが属するサービスグループが格納される。例えば図6の例では、N005である内部IDは、A003である外部IDとB002である外部IDの両方に対応づけられていることが示されている。ここで、外部IDは、サービスグループ内で取引主体を一意に特定するIDであることから、異なるサービスグループの間ではIDが重複する可能性がある。そのため、外部ID情報では、外部IDに加えてサービスグループを含めることで、仮に外部IDが重複する場合であっても正しく内部IDに変換することを可能にしている。
図7は、バリュー移動履歴の具体例を示す図である。「支払ID」には、バリューの移動が行われる度に付与されるIDが格納される。支払IDは、例えば、受付部101がバリュー移動情報を受け付けた際に払い出されるようにしてもよい。「日時」には、例えば、受付部101がバリュー移動情報を受け付けた際の日時、又は、移動処理部104がバリューの移動を行った際の日時が格納される。「支払元」には、バリューを支払う取引主体(すなわち取引を依頼した取引主体)の内部IDが格納される。「支払先」には、バリューを受け取る取引主体(すなわち取引を受けた取引主体)の内部IDが格納される。「バリュー」には、移動する(支払われる)バリューの額が格納される。
なお、以上説明した機能ブロック構成において、取引管理装置10は、内部ID情報を用いて各取引形態が所有するバリュー残高を記録するようにしたが、これは、取引管理装置10が、各取引形態が所有するバリューを管理するための口座を管理していることと同義である。従って、上述した移動処理部104が行う処理は、特定部102で一意に特定された“取引を依頼した取引主体”の口座のバリュー残高から、特定部102で一意に特定された“取引を受けた取引主体”の口座のバリュー残高に、所定のバリューを移動させることと表現するようにしてもよい。
<処理手順>
図8は、シェアリングエコノミー提供システム1が行う処理手順の一例を示すシーケンス図である。図8の例は、法人Aサービスグループに属する法人Aから、個人dに対して依頼された業務を個人dが行い、その結果、法人Aから個人dに対して支払いが行われる状況を想定している。また、内部ID情報及び外部ID情報には、それぞれ、図5及び図6に示す情報が格納されている前提とする。
まず、外部装置(法人Aシステム)20aは、取引管理装置10に対してバリュー移動情報を送信する(S101)。バリュー移動情報には、支払元である取引主体(法人A)の外部ID:A001と、支払先である取引主体(個人d)の外部ID:A004と、移動させるバリューの額(5,000円)が格納されている。取引管理装置10の受付部101は、送信されたバリュー移動情報を受け付ける。
取引管理装置10の特定部102は、外部ID情報を検索することで、バリュー移動情報に含まれる支払元である取引主体(法人A)の外部IDに対応する内部IDと、支払先である取引主体(個人d)の外部IDに対応する内部IDとを取得する(S102)。具体的には、特定部102は、支払元の外部IDであるA001に対応する内部IDとして“N001”を取得し、支払先の外部IDであるA004に対応する内部IDとして“N006”を取得する。
なお、前述した通り、外部IDは、サービスグループ内で一意であるIDであるため、サービスグループ間で外部IDが重複する場合が考えられる。そこで、外部装置(法人Aシステム)20aは、バリュー移動情報にサービスグループを示す情報を格納して取引管理装置10に送信するようにして、特定部102は、外部ID及びサービスグループの両方が一致する内部IDを外部ID情報から取得するようにしてもよい。
また、他の方法として、記憶部105に、外部装置20を識別可能なネットワーク情報(例えばIPアドレスやドメイン名等)とサービスグループとを対応づけた情報(データベース)を保持しておき、特定部102は、外部装置20からバリュー移動情報を受信する際に取得したネットワーク情報(例えばIPアドレスやドメイン名等)に対応するサービスグループを、当該情報(データベース)を検索することで取得するようにしてもよい。
続いて、取引管理装置10の判定部103は、内部ID情報のバリュー残高を参照することで、又は、プリペイドシステム30に問い合わせることで、支払元である取引主体(法人A)のバリュー残高が移動するバリューの額(5,000円)以上であるか否かを確認する(S103)。ここでは、法人Aのバリュー残高が5,000円以上であることが確認されたと仮定する。
続いて、取引管理装置10の移動処理部104は、支払先である取引主体(個人d)の外部装置(個人d端末)20fに、支払確認メッセージを送信する(S104)。支払確認通知には、支払元である取引主体の名称(法人A)と、支払われるバリュー(例えば5,000円)とが含まれており、外部装置(個人d端末)20fの画面には、法人Aから5,000円の支払いがあることが表示される。個人dは、外部装置(個人d端末)20fの画面にて、法人Aから支払われるバリューの額が正しいことを確認すると、当該画面にて確認完了のボタンを押下する。ボタンが押下されると、外部装置(個人d端末)20fは確認完了メッセージを取引管理装置10に送信する(S105)。なお、ステップS104及びステップS105の処理手順は省略されてもよい。
続いて、取引管理装置10の移動処理部104は、支払元である取引主体(法人A)が所有するプリペイドカードの番号と、支払先である取引主体(個人d)が所有するプリペイドカードのプリペイドカード番号とを内部ID情報から取得する。続いて、取引管理装置10の移動処理部104は、バリューの移動を依頼するメッセージをプリペイドシステム30に送信する(S106)。バリュー移動依頼メッセージには、支払元のプリペイドカード番号と、支払先のプリペイドカード番号と、移動させるバリューの額(5000円)とが含まれる。
プリペイドシステム30は、バリューの移動が完了すると、バリューの移動が完了したことを示すバリュー移動完了メッセージを取引管理装置10に送信する(S107)。取引管理装置10の移動処理部104は、バリュー移動完了メッセージを受信すると、支払元である取引主体(法人A)から、支払先である取引主体(個人d)に5,000円のバリューが移動したことをバリュー移動履歴に追加する(S108)。続いて、取引管理装置10の移動処理部104は、内部ID情報にバリュー残高が格納されている場合、当該バリュー残高を更新する(S109)。具体的には、移動処理部104は、法人Aのバリュー残高から5,000円を減算し、個人dのバリュー残高に5,000円を加算する。
<まとめ>
以上、第1実施形態について説明した。第1実施形態では、取引主体の間で行われる金銭の支払いを、各取引主体が所持するプリペイドカード間でバリューを移動させることで実現するようにした。これにより、銀行口座間で金銭の支払を行う場合と比較して、金銭を移動することで生じる振込手数料等の手数料の抑制や、銀行口座間で金銭を移動する際に生じるタイムラグ(例えば1営業日程度のタイムラグ)の抑制を図ることができる。
また、第1実施形態では、外部装置20から取引管理装置10に金銭の移動を依頼する場合、外部装置20から取引管理装置10には外部IDを伝えるようにして、取引管理装置10の中で外部IDから内部IDに変換するようにした。これにより、外部装置20の中で内部IDを使用する必要がないため、外部装置20が取引管理装置10に接続する際のシステム改修コストを抑制することが可能になる。
また、第1実施形態では、取引主体に個人グループを含めるようにしたことで、面識がないメンバー同士で受発注業務を行うグループを作成し、業務完了時の支払及びバリューの受領を行うことが可能になる。従来は、受発注業務に係る契約の問題や、支払いに利用する銀行口座を個人グループとして作成することができないといった問題で、取引毎に複数の個人がグループを組んで受発注業務を実施することが困難であった。つまり、第1実施形態によれは、従来は法人という枠で実施せざるを得なかった受発注業務を、受発注の取引毎に、個人のグループで自由に行うことが可能になる。
<<第2実施形態>>
続いて、第2実施形態について説明する。第1実施形態では、複数のサービスグループが存在する状態で取引管理装置10が行う処理を説明したが、第2実施形態では、説明の便宜上、すべての取引主体が法人Mにより提供されるサービスグループに属する前提で説明を行う。その他、第2実施形態において特に言及しない点については第1実施形態と同一でよい。
第1実施形態では、複数の取引主体の各々が所有するバリューは、各取引主体が所有するプリペイドカードのチャージ額であり、バリューの移動は、プリペイドカード間でチャージ額を移動させることであった。一方、第2実施形態に係る取引管理装置10は、複数の取引主体の各々が所有するバリューを管理するための口座を取引主体ごとに保持する。また、当該口座は、取引主体が所有するバリューのバリュー残高を格納するメイン口座と、取引を依頼した取引主体から仮払いされたバリューを格納するサブ口座とを含む。また、第2実施形態では、取引主体間で行われるバリューの移動を、“仮払いによるバリューのサブ口座への移動”と、仮払いされたバリューをサブ口座からメイン口座に移動する“バリューの支払い”の2段階の手順により行う。
メイン口座のバリュー残高はプリペイドカードのチャージ額と連動するが、サブ口座のバリューは、プリペイドカードのチャージ額とは連動しない。仮払いが行われることで、取引を依頼した取引主体のメイン口座から取引を受けた取引主体のサブ口座にバリューが移動する。つまり、取引を依頼した取引主体のプリペイドカードのチャージ額が減算される。また、バリューの支払いが行われることで、取引を受けた取引主体のサブ口座からメイン口座にバリューが移動する。つまり、取引を受けた取引主体のプリペイドカードのチャージ額にバリューが加算される。
図9を用いて処理の概要を説明する。外部装置20m(以下、外部装置20mと記載する。)は、法人Mがシェアリングエコノミーサービスを提供するためのシステムである。また、個人sは、個人tに対して業務を発注し、個人tは、個人sから発注を受けた業務を遂行するものとする。また、個人s及び個人tは共に取引管理装置10に利用登録されており、内部ID情報及び外部ID情報には、個人s及び個人tの内部ID及び外部IDが格納されているものとする。
まず、個人sは、外部装置20mを介して、個人tとの間で取引を行うことに関する契約を締結する(S201)。当該契約は、1つの契約の中で1回の取引のみが行われる契約と、1つの契約の中で複数の取引が行われる契約の両方を含む。後者の契約は、例えば、毎月月末に成果物を納品する取引を1年間行うといった契約等を意図している。
契約が締結されると、外部装置20mは、サブ口座の開設を指示する情報(以下、「サブ口座開設情報」と言う。)を取引管理装置10に送信する(S202)。サブ口座開設情報は、契約を締結した取引主体を示す契約IDを含む。契約IDはどのようなIDであってもよいが、第2実施形態では、契約IDは、取引を依頼した取引主体(個人s)の識別子(外部ID又は内部IDのいずれか)と、取引を受けた取引主体(個人t)の識別子(外部ID又は内部IDのいずれか)とを含むものとする。サブ口座開設情報を受信した取引管理装置10は、取引を受けた取引主体の口座に、当該契約IDに対応するサブ口座を開設する。つまり、サブ口座は、取引主体間で締結された契約ごとに1つ開設される。
続いて、個人sが外部装置20mを介して個人tに取引を依頼すると(S203)、外部装置20mは、取引管理装置10に対して、仮払いによるバリューの移動を指示する情報(以下、「仮払い指示情報」と言う。)を送信する(S204)。仮払い指示情報には、契約ID(xxx)と、取引ID(yyy)と、移動させるバリューの額(5、000円)とが含まれる。取引IDとは、契約の中で行われる1以上の取引の各々を一意に識別するIDである。取引管理装置10は、仮払い指示情報を受信すると、個人sのメイン口座から、個人tのサブ口座に5、000円分のバリューを移動させる(S205)。
続いて、個人tが取引を遂行したことを個人sが確認したこと(例えば検収が完了したこと等)が外部装置20mに通知されると(S206)、外部装置20mは、サブ口座からメイン口座にバリューを移動(入金)させることを指示する情報(以下、「支払い指示情報」と言う。)を取引管理装置10に送信する(S207)。支払い指示情報は、契約ID及び取引IDを含む。取引管理装置10は個人tにおける当該取引IDに対応するサブ口座から、個人tのメイン口座にバリューを移動させる(S208)。
なお、契約ID及び取引IDは、外部装置20が払い出すこととしてもよいし、外部装置20の要求に応じて取引管理装置10が払い出すこととしてもよい。
次に、個人グループに対して支払われたバリューを各個人に分配する機能について説明する。前述した通り、現状では個人グループに対してプリペイドカードの発行ができない。そのため、個人グループのメイン口座のバリュー残高を、そのままプリペイドカードのチャージ額とすることができない。そこで、第2実施形態に係る取引管理装置10は、個人グループに対して支払われたバリューを、各個人からの要求に応じて各個人のメイン口座に分配する機能を備える。当該機能により、個人グループに属する各個人は、個人グループに対して支払われたバリューを各個人のプリペイドカードにチャージすることで、店舗等での支払いに利用することが可能になる。以下、当該機能の概要を、図10を用いて説明する。
まず、外部装置(個人v端末)20vは、個人vの指示により、取引管理装置10にバリューの移動を申請する情報(以下、「バリュー移動申請」と言う。)を送信する(S251)。なお、バリュー移動申請には、個人グループ(v、w)がメイン口座に保有するバリューのうち20、000円を個人vに移動させることが示されているとする。続いて、取引管理装置10は、個人グループ(v、w)のうちバリューの移動を申請した個人以外の全ての個人(個人w)に対して、20、000円分のバリューを個人vに移動させることを許可するか否かを問い合わせる(S252)。問い合わせを受けた個人が許可した場合(S253)、取引管理装置10は、個人グループ(v、w)のメイン口座から、個人vのメイン口座に20、000円分のバリューを個人vに移動させる(S254)。
<機能ブロック構成>
図11は、第2実施形態に係る取引管理装置10の機能ブロック構成例を示す図である。第2実施形態に係る取引管理装置10は、受付部201と、特定部202と、判定部203と、口座開設部204と、移動処理部205と、記憶部206とを有する。各機能ブロックは、第1実施形態で説明した機能も備えている。
記憶部206は、内部ID情報と、外部ID情報と、各取引主体が所有する口座を取引主体ごとに管理する口座情報と、バリュー移動履歴とを記憶する。口座情報には、更に、メイン口座に関する情報を格納するメイン口座情報と、サブ口座に関する情報を格納するサブ口座情報とが含まれる。
受付部201は、外部装置20から、各種の指示を受け付ける。より具体的には、受付部201は、外部装置20から、取引を依頼した取引主体から取引を受けた取引主体に対して所定のバリューを仮払いすることを指示する仮払い指示(仮払い指示情報)を受け付ける。また、受付部201は、外部装置20から、取引を依頼した取引主体から取引を受けた取引主体に仮払いされた額のバリューを、取引を受けた取引主体に支払うことを指示する支払い指示(支払い指示情報)を受け付ける。また、受付部201は、外部装置20から、個人グループに含まれる個人(第1個人)から、取引を受けた取引主体のメイン口座に格納されるバリュー残高のうち所定のバリューを、当該個人(第1個人)のメイン口座に移動させることを指示するバリュー移動申請を受け付ける。
口座開設部204は、受付部201で受け付けたサブ口座開設情報に従い、取引を受けた取引主体の口座にサブ口座を開設する。
移動処理部205は、受付部201で受け付けた仮払い指示(仮払い指示情報)に基づいて、取引を依頼した取引主体のメイン口座に格納されるバリュー残高から、取引を受けた取引主体のサブ口座に、仮払い指示情報で指示される額のバリューを移動させる。
また、移動処理部205は、受付部201で受け付けた支払い指示情報に基づいて、仮払い指示で指示された額のバリューを、取引を受けた取引主体のサブ口座から取引を受けた取引主体のメイン口座に移動させる。
また、移動処理部205は、個人グループに含まれる複数の個人のうちバリュー移動申請を行った個人以外の個人の各々に対して、バリュー移動申請を許可するか否かの問い合わせを行う。移動処理部205は、問い合わせを行った各個人から受けた、バリュー移動申請を許可する(又はしない)との通知に基づいて、取引を受けた取引主体のメイン口座に格納されるバリュー残高のうち所定のバリューを、バリュー移動申請を行った個人のメイン口座に移動させるか否かを切り替える。
図12は、第2実施形態に係る内部ID情報の一例を示す図である。「口座ID」には、取引主体が所有するバリューを管理する各口座を一意に識別するIDが格納される。「グループ情報」には、個人グループに含まれる各取引主体の内部IDが格納される。
図13は、第2実施形態に係る外部ID情報の一例を示す図である。第2実施形態に係る外部ID情報は、第1実施形態に係る外部ID情報と同一であるため説明は省略する。
図14は、第2実施形態に係る口座情報の一例を示す図である。図14(a)は、メイン口座情報の一例を示している。「口座ID」は、内部ID情報で説明した口座IDと同一であるため説明は省略する。「バリュー残高」は、第1実施形態の内部ID情報で説明したバリュー残高と同一であるため説明は省略する。「サブ口座ID」には、サブ口座を一意に識別するためのIDが格納される。「契約ID」には、契約IDが格納される。なお、前述した通り、サブ口座は、締結された契約ごとに対応づけられていることから、メイン口座情報には、「サブ口座ID」及び「契約ID」のペアを複数格納することができる。例えば、個人aが個人b及び個人cとそれぞれ異なる契約を締結している場合、個人aのメイン口座情報には、個人a及び個人b間の契約に係るサブ口座ID及び契約IDのペアと、個人a及び個人c間の契約に係るサブ口座ID及び契約IDのペアとが格納される。「利用可否フラグ」は、メイン口座のバリュー残高を利用可能であるか否か(つまり、メイン口座がロックされているか否か)を示すフラグを示す。利用可否フラグが「利用不可」に設定されている場合、取引主体は、自身のメイン口座情報に記録されているバリューを利用することができなくなる(つまり、利用が凍結される)。
図14(b)は、サブ口座情報の一例を示している。「サブ口座ID」は、サブ口座を一意に識別するためのIDが格納される。「取引ID」には、依頼された取引に係る取引IDが格納される。取引IDはどのようなIDであってもよいが、第2実施形態では、取引IDは、契約IDと、当該契約内で行われる取引を示す番号とを結合したものとする。図14(b)の例では、取引ID(N103-N104-02)は、内部IDがN103である取引主体(個人s)から内部IDがN104である取引主体(個人t)に対して依頼した2回目の取引を示している。
図15は、第2実施形態に係るバリュー移動履歴の一例を示す図である。「取引ID」には、取引IDが格納される。「移動理由」には、バリューの移動具体的には、仮払いに伴うバリューの移動を示す「仮払い」、仮払いされたバリューを支払うことに伴うバリューの移動を示す「支払い」、個人グループのメイン口座にあるバリューを個人のメイン口座に移すことを示す「バリュー移動申請」のいずれかが格納される。
<処理手順>
図16〜図19は、第2実施形態に係るシェアリングエコノミー提供システム1が行う処理手順の一例を示すシーケンス図である。図16〜図19を用いて、第2実施形態に係る取引管理装置10が行う処理手順について説明する。なお、以下の説明では、内部ID情報、外部ID情報、メイン口座情報及びサブ口座情報には、それぞれ、図12、図13、図14(a)及び図14(b)に示すデータが格納されているものとする。また、各取引主体は取引管理装置10に利用登録されており、内部ID情報及び外部ID情報には、各取引主体の内部ID及び外部IDが格納されているものとする。
(サブ口座開設処理)
まず、取引主体間で契約が締結され、サブ口座の開設が行われる際の処理手順について図16を用いて説明する。外部装置20mは、サブ口座開設情報を取引管理装置10に送信する(S301)。サブ口座開設情報には、発注者の外部ID及び受注者の外部IDを含む契約IDが含まれる。取引管理装置10の特定部202は、サブ口座開設情報を受け付けると、外部ID情報を用いて、契約IDに含まれる発注者の外部ID及び受注者の外部IDを、それぞれ、発注者の内部ID及び受注者の内部IDに変換する。
続いて、取引管理装置10の口座開設部204は、受注者の内部IDをキーに内部ID情報を検索することで、受注者の口座IDを取得する。続いて、口座開設部204は、サブ口座IDを払い出し、払い出したサブ口座IDをメイン口座情報及びサブ口座情報に追加することでサブ口座を作成する(S302)。具体的には、口座開設部204は、メイン口座情報にアクセスし、受注者の口座IDを含むレコードに、新たに払い出したサブ口座IDと、発注者の内部ID及び受注者の内部IDを含む契約IDとを追加する。また、口座開設部204は、サブ口座情報に、新たに払い出したサブ口座IDに対応するレコードを追加する。
(仮払い処理)
次に、発注者から受注者に対してバリューの仮払いが行われる際の処理手順について図16を用いて説明する。外部装置20mは、契約ID、取引ID及び仮払いするバリューの額を含む仮払い指示情報を取引管理装置10に送信する(S351)。取引管理装置10の特定部202は、仮払い指示情報を受け付けると、外部ID情報を用いて、契約ID及び取引IDに含まれる外部IDを内部IDに変換する。
続いて、取引管理装置10の移動処理部205は、プリペイドシステム30に対して、プリペイドカードからバリュー分のチャージ額を減算することを依頼する情報(以下、「バリュー減算依頼」と言う。)を送信する(S352)。バリュー減算依頼には、発注者のプリペイドカード番号と、ステップS351の処理手順で取得した仮払いするバリューの額とが含まれる。プリペイドシステム30は、バリュー分のチャージ額の減算が完了したことを通知する情報を取引管理装置10に送信する(S353)。
移動処理部205は、発注者のメイン口座から受注者のサブ口座に、仮払いするバリューの額を移動する(S354)。具体的には、移動処理部205は、発注者のメイン口座の「バリュー残高」から、仮払いするバリューの額を減算する。続いて、移動処理部205は、サブ口座情報のうち、ステップS302の処理手順で新たに払い出されたサブ口座IDを含むレコードの「取引ID」及び「仮払いバリュー」に、それぞれ、内部ID変換後の取引ID及び仮払いバリューの額を格納する。
移動処理部205は、ステップS354の処理手順で行われたバリューの移動を、バリュー移動履歴に追加し(S355)、仮払い処理が完了したことを示す情報を外部装置20mに送信する(S356)。
以上説明した仮払い処理において、ステップS352及びステップS353の処理手順と、ステップS354の処理手順とは逆であってもよい。なお、発注者のプリペイドカードのチャージ額及びメイン口座情報のバリュー残高が、仮払いするバリューの額に満たないことが判明した場合、取引管理装置10の判定部203は、外部装置20mに対して、発注者は仮払いすることができないことを通知し、それ以後の処理を中止するようにしてもよい。若しくは、仮払いするバリューの額に満たない場合であっても、一旦バリュー残高及びチャージ額をマイナスにしておき、後日発注者に費用を請求することとしてもよい。
(仮払い取消処理)
発注者が受注者に取引を依頼した後、何らかの理由で取引が中止されることが想定される。この場合、受付部201は、発注者から受注者に仮払いされた額のバリューを、発注者に戻すことを指示する仮払い取消指示を外部装置20から受け付けるようにしてもよい。また、移動処理部205は、受付部で201受け付けた仮払い取消指示に基づいて、仮払いされた額のバリューを、受注者のサブ口座から発注者のメイン口座に移動させるようにしてもよい。以下、図16を用いて具体的な処理手順を説明する。
外部装置20mは、仮払いを取り消しすること指示する情報(以下、「仮払い取消情報」と言う。)を取引管理装置10に送信する。仮払い取消情報には、契約ID、取引ID及び仮払い済みバリューの額が含まれる(S401)。取引管理装置10の特定部202は、仮払い取消情報を受け付けると、外部ID情報を用いて、契約ID及び取引IDに含まれる外部IDを内部IDに変換する。
続いて、取引管理装置10の移動処理部205は、プリペイドシステム30に対して、プリペイドカードにバリュー分のチャージ額を加算することを依頼する情報(以下、「バリュー加算依頼」と言う。)を送信する(S402)。バリュー加算依頼には、発注者のプリペイドカード番号と、ステップS401の処理手順で取得した仮払い済みバリューの額とが含まれる。プリペイドシステム30は、バリュー分のチャージ額の加算が完了したことを通知する情報を取引管理装置10に送信する(S403)。
移動処理部205は、受注者のサブ口座から発注者のメイン口座に、バリューの額を移動する(S404)。具体的には、移動処理部205は、受注者のサブ口座の「仮払いバリュー」から、発注者のメイン口座に戻すバリューの額を減算する。続いて、移動処理部205は、発注者のメイン口座の「バリュー残高」に、受注者のサブ口座から減算したバリューの額を加算する。
移動処理部205は、ステップS404の処理手順で行われたバリューの移動を、バリュー移動履歴に追加し(S405)、仮払い処理が完了したことを示す情報を外部装置20mに送信する(S406)。
以上説明した仮払い処理において、ステップS402及びステップS403の処理手順と、ステップS404の処理手順とは逆であってもよい。
(仮払いバリュー移動処理)
発注者が受注者に取引を依頼した後、何らかの理由で受注者が変更になることが想定される。この場合、受付部201は、受注者に仮払いされた額のバリューを、新たな発注者に移動させることを指示する移動指示を外部装置20から受け付けるようにしてもよい。また、移動処理部205は、受付部で201受け付けた移動指示に基づいて、仮払いされた額のバリューを、受注者のサブ口座から新たな発注者のサブ口座に移動させるようにしてもよい。以下、図17を用いて具体的な処理手順を説明する。
外部装置20mは、仮払いバリューを移動させること指示する情報(以下、「仮払いバリュー移動指示」と言う。)を取引管理装置10に送信する。仮払いバリュー移動指示には、元の契約ID及び元の取引IDと、新たな契約ID及び取引IDとが含まれる(S451)。取引管理装置10の特定部202は、仮払いバリュー移動指示を受け付けると、外部ID情報を用いて、契約ID及び取引IDに含まれる外部IDを内部IDに変換する。
続いて、取引管理装置10の移動処理部205は、元の受注者のサブ口座から新たな受注者のサブ口座に、バリューの額を移動する(S452)。具体的には、口座開設部204は、前述した口座開設処理に従い、新たな受注者のサブ口座を作成する。また、移動処理部205は、元の受注者のサブ口座の「仮払いバリュー」に格納されているバリューの額と同一額のバリューを新たな発注者のサブ口座の「仮払いバリュー」に追加すると共に、元の受注者のサブ口座の「仮払いバリュー」をゼロにする。
移動処理部205は、ステップS452の処理手順で行われたバリューの移動を、バリュー移動履歴に追加し(S453)、仮払いバリューの移動が完了したことを示す情報を外部装置20mに送信する(S454)。
(支払い処理)
次に、取引が完了し、発注者から受注者に対してバリューの支払いが行われる際の処理手順について図17を用いて説明する。外部装置20mは、契約ID及び取引IDを含む支払い指示情報を取引管理装置10に送信する(S501)。取引管理装置10の特定部202は、支払い指示情報を受け付けると、外部ID情報を用いて、契約ID及び取引IDに含まれる外部IDを内部IDに変換する。
続いて、取引管理装置10の移動処理部205は、サブ口座情報にアクセスし、内部ID変換後の取引IDを含むレコードの「仮払いバリュー」に格納されている、仮払いされたバリューの額を取得する。また、移動処理部205は、契約IDに含まれる受注者の内部IDをキーとして内部ID情報を検索することで、受注者のプリペイドカード番号を取得する。続いて、移動処理部205は、プリペイドシステム30に対して、バリュー加算依頼を送信する(S502)。バリュー加算依頼には、受注者のプリペイドカード番号と、仮払いされたバリューの額とが含まれる。プリペイドシステム30は、バリュー分のチャージ額の加算が完了したことを通知する情報を取引管理装置10に送信する(S503)。なお、前述した通り、現状では個人グループに対してプリペイドカードの発行ができないことから、受注者が個人グループの場合、ステップS502及びステップS503の処理手順は省略される。
続いて、移動処理部205は、受注者のサブ口座から受注者のメイン口座に、仮払い済みのバリューの額を移動する(S504)。具体的には、移動処理部205は、受注者のサブ口座の「仮払いバリュー」に格納されているバリューの額を、受注者のメイン口座の「バリュー残高」に加算すると共に、受注者のサブ口座の「仮払いバリュー」に格納されているバリューの額をゼロにする。また、移動処理部205は、サブ口座情報から、内部IDに変換後の取引IDを含むレコード(つまり、受注者のサブ口座のレコード)を削除する。
続いて、移動処理部205は、ステップS504の処理手順で行われたバリューの移動を、バリュー移動履歴に追加し(S505)、仮払い処理が完了したことを示す情報を外部装置20mに送信する(S506)。
以上説明した仮払い処理において、ステップS502及びステップS503の処理手順と、ステップS504の処理手順とは逆であってもよい。
(バリュー移動申請処理)
続いて、個人グループに対して支払われたバリューを、各個人のメイン口座に分配する、バリュー移動申請処理について図18を用いて説明する。バリュー移動申請処理では、バリューの移動申請を行った個人(以下、「申請者」と言う。)と同一の個人グループに属する他の個人が、申請者へのバリュー移動を許可した場合にバリューの移動を行う。なお、以降の説明においては、個人グループ(v、w)に属する個人vがバリュー移動申請等を行うものとする。また、各外部装置20は、個人グループに属する各個人の内部IDを予め把握しているものとする。
外部装置(個人v)20vは、取引管理装置10に対してバリュー移動申請を送信する(S601)。バリュー移動申請には、バリューの移動元として、申請者(個人v)が属する個人グループ(v、w)の内部ID(N105)と、バリューの移動先として、申請者(個人v)の内部ID(N106)と、申請者が所望するバリューの額とが含まれる。取引管理装置10の受付部201がバリュー移動申請を受け付けると、判定部203は、個人グループ(v、w)のメイン口座の「バリュー残高」を参照し、個人グループ(v、w)のバリュー残高が、個人vが所望するバリューの額以上であることを確認する。個人グループ(v、w)のバリュー残高が、個人vが所望するバリューの額未満であると判定された場合、受付部201は、外部装置(個人v)20vに対して申請を拒否することを示す情報を送信する。続いて、取引管理装置10の移動処理部205は、内部ID情報の「グループ情報」にアクセスすることで、申請者(個人v)が属する個人グループ(v、w)に含まれる、申請者以外の個人を特定する(S602)。ここでは、個人wが特定されることになる。
続いて、取引管理装置10の移動処理部205は、外部装置(個人w)20wに対して、バリューの移動可否を問い合わせる情報を送信する(S603)。バリューの移動可否を問い合わせる情報には、バリュー移動元である個人グループ(v、w)の内部ID(N105)と、バリュー移動先である個人vの内部ID(N106)と、個人vが所望するバリューの額とが含まれる。個人wは、個人グループ(v、w)のメイン口座から個人vが所望する額のバリューを個人vのメイン口座に移動させることを許可するか又は拒否するかを、外部装置(個人w)20wの画面等を操作することで選択する(S604)。ここでは許可が選択されたと仮定する。外部装置(個人w)20wは、バリューの移動を許可するとの情報を取引管理装置10に送信する(S605)。
移動処理部205は、所定の条件(第1条件)を満たす場合はステップS606の処理手順に進み、所定の条件(第1条件)を満たさない場合は処理を終了する。所定の条件(第1条件)を満たす場合とは、個人グループに含まれる、申請者以外の全ての個人(又は所定の割合以上の個人)から、バリューの移動を許可するとの情報を受けた場合であってもよい。若しくは、個人グループの中で代表者を予め定めておき、当該代表者から、バリューの移動を許可するとの情報を受けた場合であってもよい。
若しくは、個人グループに属する各個人に予め投票権(議決権と称してもよい)を設定しておき、バリューの移動を許可するとの通知を受けた各個人が保持する投票権の合計が、少なくとも個人グループに属する全個人が保持する投票権の合計のうち所定の割合(例えば50%等)以上となる場合であってもよい。例えば、個人v、個人w、個人x及び個人yが属する個人グループにおいて、申請者は個人wであるとする。また、個人v、個人w、個人x及び個人yは、それぞれ投票権を1つずつ保持しているとする。また、所定の割合は50%であるとする。
例えば、個人w、個人x及び個人yのうち少なくとも2名がバリューの移動を許可したケースを想定する。この場合、当該2名が保有する投票権の合計「2」は、全個人が保有する投票権の合計「4」の50%以上になる。従って、このケースでは、個人wにバリューが移動することになる。一方、個人w、個人x及び個人yのうち1名のみがバリューの移動を許可したケースを想定する。この場合、当該1名が保有する投票権の合計「1」は、全個人が保有する投票権の合計「4」の50%未満である。従って、このケースでは、個人wにバリューが移動しないことになる。
移動処理部205は、内部ID情報にアクセスすることで個人wのプリペイドカード番号を取得し、プリペイドシステム30に対して、バリュー加算依頼を送信する(S606)。バリュー加算依頼には、個人wのプリペイドカード番号と、ステップS601の処理手順で受け付けたバリューの額とが含まれる。プリペイドシステム30は、バリュー分のチャージ額の加算が完了したことを通知する情報を取引管理装置10に送信する(S607)。
続いて、移動処理部205は、バリューの移動元である個人グループ(v、w)のメイン口座から申請者である個人vのメイン口座に、個人vが所望するバリューの額を移動する(S608)。具体的には、移動処理部205は、個人グループ(v、w)のメイン口座の「バリュー残高」から個人vが所望するバリューの額を減算し、個人vのメイン口座の「バリュー残高」に個人vが所望するバリューの額を加算する。続いて、移動処理部205は、ステップS608の処理手順で行われたバリューの移動を、バリュー移動履歴に追加し(S609)、個人グループ(v、w)に含まれる全個人の外部装置20(外部装置(個人v)20v及び外部装置(個人w)20w)に、バリューの移動が完了したことを示す情報を送信する(S610)。なお、移動処理部205は、バリューの移動が完了したことを示す情報に、バリューの移動を一意に特定する支払IDを含めて送信する。当該支払IDは、ステップS609の処理手順でバリュー移動履歴に格納された支払IDと同一であってもよい。
(バリュー移動取消処理:パターン1)
バリュー移動申請を行った申請者が、何らかの理由でバリューの移動申請の取り消しを希望することが想定される。この場合、受付部201は、申請者のメイン口座に移動させた所定のバリューを、個人グループのメイン口座に格納されるバリュー残高に戻すことを指示するバリュー移動取消申請を外部装置20から受け付けるようにしてもよい。また、移動処理部205は、受付部で201受け付けたバリュー移動取消申請に基づいて、移動したバリューを、申請者のメイン口座から個人グループのメイン口座に移動させるようにしてもよい。以下、図18を用いて具体的な処理手順を説明する。
外部装置(個人v)20vは、取引管理装置10に対して、ステップS610の処理手順で取引管理装置10から送信された支払IDを含むバリュー移動取消申請を送信する(S651)。取引管理装置10の移動処理部205は、バリュー移動取消申請を受け付けると、支払IDをキーにバリュー移動履歴を検索することで、支払元(個人グループ(v、w))と支払先(個人v)と移動済みのバリューの額とを取得する。
続いて、移動処理部205は、プリペイドシステム30に対して、バリュー減算依頼を送信する(S652)。バリュー減算依頼には、支払先(個人v)のプリペイドカード番号と、ステップS651の処理手順で取得したバリューの額とが含まれる。プリペイドシステム30は、バリュー分のチャージ額の減算が完了したことを通知する情報を取引管理装置10に送信する(S653)。
続いて、移動処理部205は、バリューの移動元である個人vのメイン口座からバリューの移動先である個人グループ(v、w)のメイン口座にバリューを移動する(S654)。具体的には、移動処理部205は、個人vのメイン口座の「バリュー残高」からステップS651の処理手順で取得したバリューの額を減算し、個人グループ(v、w)のメイン口座の「バリュー残高」に当該バリューの額を加算する。
続いて、移動処理部205は、ステップS654の処理手順で行われたバリューの移動を、バリュー移動履歴に追加し(S655)、個人グループ(v、w)に含まれる全個人の外部装置20(外部装置(個人v)20v及び外部装置(個人w)20w)に、バリューの移動が取り消されたことを示す情報を送信する(S656)。
(バリュー移動取消処理:パターン2)
バリュー移動申請を許可した各個人が、何らかの理由で、一旦許可したバリュー移動申請の取消を希望することが想定される。この場合、受付部201は、個人グループに含まれる申請者(第1個人)以外の各個人(第2個人)から、又は、各個人(第2個人)の中でバリュー移動申請を許可するとの通知を行った各個人(第3個人)から、申請者のメイン口座に移動させた所定のバリューを、個人グループのメイン口座に格納されるバリュー残高に戻すことを指示するバリュー移動取消申請を受け付けるようにしてもよい。また、移動処理部205は、各個人から受けたバリュー移動取消申請が所定の条件(第2条件)を満たす場合、申請者(第1個人)のメイン口座に格納される所定のバリューを、個人グループのメイン口座に移動させるようにしてもよい。
所定の条件(第2条件)を満たす場合とは、個人グループに含まれる、申請者以外の全ての個人(又は所定の割合以上の個人)から、又は、バリュー移動申請を許可するとの通知を行った全ての個人(又は所定の割合以上の個人)から、バリュー移動取消申請を受けた場合であってもよい。若しくは、個人グループ(v、w)の中で代表者を予め定めておき、当該代表者から、バリュー移動取消申請を受けた場合であってもよい。若しくは、個人グループに属する各個人に予め投票権を設定しておき、バリュー移動取消申請を行った各個人が保持する投票権の合計が、少なくとも個人グループに属する全個人が保持する投票権の合計のうち所定の割合(例えば50%等)以上となる場合であってもよい。以下、図19を用いて具体的な処理手順を説明する。
外部装置(個人w)20wは、取引管理装置10に対して、ステップS610の処理手順で取引管理装置10から送信された支払IDを含むバリュー移動取消申請を送信する(S701)。取引管理装置10の移動処理部205は、外部装置(個人w)20wからバリュー移動取消申請を受け付けると、支払IDをキーにバリュー移動履歴を検索することで、支払元(個人グループ(v、w))と支払先(個人v)と移動済みのバリューの額とを取得する。ステップS702乃至ステップS706の処理手順は、それぞれ、ステップS652乃至ステップS656の処理手順と同一であるため説明は省略する。
(口座のロックに関する処理)
第2実施形態では、バリュー移動取消処理により申請者から個人グループにバリューを移動させるのではなく、申請者のメイン口座をロックすることで申請者がバリューを利用できなくするようにしてもよい。この場合、受付部201は、個人グループに含まれる申請者(第1個人)以外の各個人(第2個人)から、又は、各個人(第2個人)の中でバリュー移動申請を許可するとの通知を行った各個人(第3個人)から、申請者(第1個人)のメイン口座を利用不可にすることを指示するロック申請を受け付けるようにしてもよい。
また、移動処理部205は、各個人から受けたロック申請が所定の条件(第3条件)を満たす場合、申請者(第1個人)のメイン口座を申請者が利用することができないロック状態に設定するようにしてもよい。
所定の条件(第3条件)を満たす場合とは、個人グループに含まれる、申請者以外の全ての個人(又は所定の割合以上の個人)から、又は、バリュー移動申請を許可するとの通知を行った全ての個人(又は所定の割合以上の個人)から、ロック申請を受けた場合であってもよい。若しくは、個人グループ(v、w)の中で代表者を予め定めておき、当該代表者から、ロック申請を受けた場合であってもよい。若しくは、個人グループに属する各個人に予め投票権を設定しておき、ロック申請を行った各個人が保持する投票権の合計が、少なくとも個人グループに属する全個人が保持する投票権の合計のうち所定の割合(例えば50%等)以上となる場合であってもよい。以下、図19を用いて具体的な処理手順を説明する。
外部装置(個人w)20wは、取引管理装置10に対して、ステップS610の処理手順で取引管理装置10から送信された支払IDを含むロック申請を送信する(S751)。取引管理装置10の移動処理部205は、外部装置(個人w)20wからロック申請を受け付けると、支払IDをキーにバリュー移動履歴を検索することで、支払先(個人v)の内部IDを取得する。続いて、移動処理部205は、取得した内部IDをキーに内部ID情報を検索することで個人vの口座IDを取得する。続いて、移動処理部205は、取得した個人vの口座IDをキーにメイン口座情報を検索し、検索された個人(個人v)のレコードの「利用可否フラグ」を利用不可に設定する(S752)。
続いて、移動処理部205は、個人グループ(v、w)に含まれる全個人の外部装置20(外部装置(個人v)20v及び外部装置(個人w)20w)に、個人vのメイン口座がロックされたことを示す情報を送信する(S753)。
<まとめ>
以上説明した第2実施形態によれば、取引が開始されてから取引が完了するまでの間、取引を受けた取引主体にバリューを仮払いすることを可能とした。これにより、取引を受けた取引主体は、取引完了時にバリューの支払を受けられないというリスクを回避することができ、安心して取引を遂行することが可能になる。一方、取引を依頼した取引主体は、取引が適切に完了するまでの間は、仮払いしたバリューを取り戻せるという安心感を得ることが可能になる。
また、第2実施形態によれば、個人グループとして受領したバリューを、各個人からの要求に応じて各個人の口座に移動できるようにした。これにより、プリペイドカードの発行ができない個人グループの単位で取引を受けることが可能になると共に、個人グループに属する各個人が、個人グループに対して支払われたバリューを利用することが可能になる。
また、第2実施形態によれば、個人グループとして受領したバリューを各個人の口座に移動する際、個人グループに属する各個人の間でコンセンサスが得られた場合にバリューを移動できるようにした。これにより、個人グループにおける各個人の業務負担の割合等に応じて、各個人にバリューを分配することが可能になる。
また、第2実施形態によれば、個人グループに属する各個人の間でコンセンサスが得られた場合にバリューの移動を取り消すことを可能とした。これにより、誤ってバリューの移動が行われた場合等にバリューを取り戻すことが可能になる。
<第2実施形態の変形例>
以上説明した第2実施形態では、仮払いが行われることで、取引を依頼した取引主体のメイン口座から取引を“受けた”取引主体のサブ口座にバリューを移動させるようにした。一方、第2実施形態の変形例では、仮払いが行われることで、取引を依頼した取引主体のメイン口座から取引を“依頼した”取引主体のサブ口座にバリューを移動させるようにする。また、支払い指示が行われることで、取引を依頼した取引主体のサブ口座から、取引を受けた取引主体のメイン口座にバリューを移動させるようにする。
取引を依頼した取引主体のメイン口座からサブ口座にバリューが移動すると、取引を依頼した取引主体は、サブ口座に移動したバリューを利用することはできなくなる。しかしながら、取引主体のサブ口座にバリューを移動させることで、第2実施形態と比較して、取引が完了するまでの間、バリューの所有者は取引主体であることを明確にすることができる。その他、特に言及しない点は第2実施形態と同一でよい。
図20を用いて本変形例の処理を説明する。図20において、図9と同一の処理手順である箇所については、図9と同一の符号を付して説明は省略する。
契約が締結されると、外部装置20mは、サブ口座開設情報を取引管理装置10に送信する(S1202)。サブ口座開設情報を受信した取引管理装置10は、取引を依頼した取引主体(個人s)の口座に、当該契約IDに対応するサブ口座を開設する。続いて、取引管理装置10の受付部201が、外部装置(法人Mシステム)20mから仮払い指示情報を受信すると(S204)、移動処理部205は、受付部201で受け付けた仮払い指示に基づいて、取引を依頼した取引主体(個人s)のメイン口座に格納されるバリュー残高から、取引を依頼した取引主体(個人s)のサブ口座に、仮払い指示で指示される額(5,000円)のバリューを移動させる(S1205)。
なお、取引管理装置10の受付部201が、外部装置(法人Mシステム)20mから仮払い取消情報を受信した場合、移動処理部205は、受付部201で受け付けた仮払い取消情報に基づいて、取引を依頼した取引主体(個人s)のサブ口座に格納されるバリュー(5,000円)を、取引を依頼した取引主体(個人s)のメイン口座に移動させる(戻す)ことになる。
続いて、取引管理装置10の受付部201が、外部装置(法人Mシステム)20mから支払い指示情報を受信すると(S207)、移動処理部205は、受付部201で受け付けた支払い指示に基づいて、取引を依頼した取引主体(個人s)のサブ口座に格納されている、当該仮払い指示で指示された額(5,000円)のバリューを、取引を受けた取引主体(個人t)のメイン口座又はサブ口座に移動させる(S1208−1)。
なお、本変形例では、支払い指示が行われることで、取引を依頼した取引主体(個人s)のサブ口座から、取引を受けた取引主体(個人t)の“サブ口座”にバリューを移動させるようにしてもよい。この場合の処理手順を図21に示す。図21の例では、取引管理装置10の受付部201が、外部装置(法人Mシステム)20mから支払い指示を受信すると(S207)、移動処理部205は、受付部201で受け付けた支払い指示に基づいて、取引を依頼した取引主体(個人s)のサブ口座に格納されている、当該仮払い指示で指示された額(5,000円)のバリューを、取引を受けた取引主体(個人t)のサブ口座に移動させる(S1208−2)。
続いて、移動処理部205は、取引を受けた取引主体(個人t)からの指示(口座内移動指示)を受けた場合(S1209、S1210)、当該指示に基づいて、取引を受けた取引主体(個人t)のサブ口座に格納されている、当該仮払い指示で指示された額(5,000円)のバリューを、取引を受けた取引主体(個人t)のメイン口座に移動させる(S1211)。
<<その他変形例>>
以上説明した各実施形態は、本発明の理解を容易にするためのものであり、本発明を限定して解釈するためのものではない。実施形態で説明したフローチャート、シーケンス、実施形態が備える各要素並びにその配置、材料、条件、形状及びサイズ等は、例示したものに限定されるわけではなく適宜変更することができる。また、異なる実施形態で示した構成同士を部分的に置換し又は組み合わせることが可能である。
各実施形態は、シェアリングエコノミーに限られず、取引の結果金銭の支払いが発生するサービスであれば、あらゆるサービスに適用することが可能である。
各実施形態では、個人グループのみならず、法人及び個人を含むグループ、法人同士のグループが取引主体となることもできる。従って、各実施形態では、「個人グループ」を、複数の取引主体を含む取引主体グループに置き換えることが可能である。同様に、第1個人、第2個人及び第3個人を、それぞれ、第1取引主体、第2取引主体及び第3取引主体に置き換えることも可能である。
第2実施形態において、プリペイドシステム30と取引管理装置10とは一体であってもよい。例えば、メイン口座情報の「バリュー残高」を用いてプリペイドカードのチャージ額が管理されることとしてもよい。この場合、図16乃至図19における、バリュー減算依頼、バリュー減算完了、バリュー加算依頼及びバリュー加算完了の各処理手順は省略されてもよい。
1…シェアリングエコノミー提供システム、10…取引管理装置、11…CPU、12…記憶装置、13…通信IF、14…入力装置、15…出力装置、20…外部装置、30…プリペイドシステム、101…受付部、102…特定部、103…判定部、104…移動処理部、105…記憶部、201…受付部、202…特定部、203…判定部、204…口座開設部、205…移動処理部、206…記憶部

Claims (19)

  1. 複数の取引主体の間で行われる取引を管理する取引管理装置であって、
    前記複数の取引主体の各々が所有するバリューを管理する口座を、該取引主体ごとに記憶する記憶部と、
    取引を依頼した取引主体から該取引を受けた取引主体に銀行の預金とは異なるバリューを移動させることを指示するバリュー移動情報を受け付ける受付部と、
    前記受付部で受け付けた前記バリュー移動情報に基づいて、前記取引を依頼した取引主体の口座のバリュー残高から、前記取引を受けた取引主体の口座のバリュー残高に、前記バリュー移動情報で指示される額のバリューを移動させる移動処理部と、
    を有し、
    前記記憶部に記憶される前記口座は、該口座に対応する取引主体が所有するバリューのバリュー残高を格納するメイン口座と、該口座に対応する取引主体に対して取引を依頼した取引主体から仮払いされたバリューを格納するサブ口座とを含み、
    前記受付部は、前記取引を依頼した取引主体から前記取引を受けた取引主体に仮払いされた額のバリューを、前記取引を受けた取引主体に支払うことを指示する支払い指示を受け付け、
    前記移動処理部は、前記受付部で受け付けた前記支払い指示に基づいて、前記取引を依頼した取引主体のサブ口座若しくは前記取引を受けた取引主体のサブ口座に格納されている前記仮払い指示で指示された額のバリューを、前記取引を受けた取引主体のメイン口座に移動させるか、又は、前記取引を依頼した取引主体のサブ口座に格納されている前記仮払い指示で指示された額のバリューを、前記取引を受けた取引主体のサブ口座に移動させる、取引管理装置。
  2. 前記バリュー残高は、前記複数の取引主体の各々が所有するプリペイドカードにチャージされた金額の残高である、
    請求項1に記載の取引管理装置。
  3. 前記複数の取引主体の各々は、法人、個人、及び、複数の個人を含む個人グループのうちいずれか一つである、
    請求項1又は2に記載の取引管理装置。
  4. 取引主体ごとに、該取引管理装置の内部で用いられるIDであって取引主体を該取引管理装置の内部で一意に特定する内部IDと、該取引主体が属するグループにより発行されたIDであって取引主体を該グループの中で一意に特定する外部IDとを対応づけて管理する管理情報を記憶する記憶部、を有し、
    前記バリュー移動情報には、前記取引を依頼した取引主体を示す情報として前記取引を依頼した取引主体の外部IDと、前記取引を受けた取引主体を示す情報として前記取引を受けた取引主体の外部IDとが含まれており、
    前記管理情報を用いて、前記取引を依頼した取引主体の外部IDから該取引主体の内部IDを取得することで、該取引を依頼した取引主体を一意に特定すると共に、前記取引を受けた取引主体の外部IDから該取引主体の内部IDを取得することで、該取引を受けた取引主体を一意に特定する特定部、を更に有し、
    前記移動処理部は、前記特定部で特定された前記取引を依頼した取引主体の口座のバリュー残高から、前記特定部で特定された前記取引を受けた取引主体の口座のバリュー残高に、前記バリュー移動情報で指示される額のバリューを移動させる、
    請求項1乃至3のいずれか一項に記載の取引管理装置。
  5. 前記移動処理部は、前記バリュー移動情報で指示される額のバリューを、前記取引を依頼した取引主体が所有する第1プリペイドカードから前記取引を受けた取引主体が所有する第2プリペイドカードに移動させることを指示する情報を、前記第1プリペイドカード及び前記第2プリペイドカードを管理するプリペイド管理システムに送信することで、前記バリュー移動情報で指示される額のバリューを移動させる、
    請求項1乃至4のいずれか一項に記載の取引管理装置。
  6. 記受付部は、前記取引を依頼した取引主体から前記取引を受けた取引主体に対してバリューを仮払いすることを指示する仮払い指示を受け付け、
    前記移動処理部は、前記受付部で受け付けた前記仮払い指示に基づいて、前記取引を依頼した取引主体のメイン口座に格納されるバリュー残高から、前記取引を依頼した取引主体のサブ口座又は前記取引を受けた取引主体のサブ口座に、前記仮払い指示で指示される額のバリューを移動させる、
    請求項1乃至5のいずれか一項に記載の取引管理装置。
  7. 前記移動処理部は、前記取引を依頼した取引主体のサブ口座に格納されている前記仮払い指示で指示された額のバリューを、前記取引を受けた取引主体のサブ口座に移動させた場合、更に、前記取引を受けた取引主体からの指示に基づいて、前記取引を受けた取引主体のサブ口座に格納されているバリューを、前記取引を受けた取引主体のメイン口座に移動させる、
    請求項1乃至6のいずれか一項に記載の取引管理装置。
  8. 前記受付部は、前記取引を依頼した取引主体から前記取引を受けた取引主体に仮払いされた額のバリューを、前記取引を依頼した取引主体に戻すことを指示する仮払い取消指示を受け付け、
    前記移動処理部は、前記受付部で受け付けた前記仮払い取消指示に基づいて、前記取引を依頼した取引主体のサブ口座又は前記取引を受けた取引主体のサブ口座に格納される、前記仮払い指示で指示された額のバリューを、前記取引を依頼した取引主体のメイン口座に移動させる、
    請求項1乃至7のいずれか一項に記載の取引管理装置。
  9. 前記取引を受けた取引主体は複数の取引主体を含む取引主体グループであり、
    前記記憶部は、前記取引主体グループに含まれる複数の取引主体の各々について、該複数の取引主体の各々が所有するバリューを管理するための前記口座を該取引主体ごとに記憶し、
    前記受付部は、前記取引主体グループに含まれる第1取引主体から、前記取引を受けた取引主体のメイン口座に格納されるバリュー残高のうち所定のバリューを、該第1取引主体のメイン口座に移動させることを指示するバリュー移動申請を受け付け、
    前記移動処理部は、
    前記取引主体グループに含まれる複数の取引主体のうち前記第1取引主体以外の第2取引主体の各々に対して、前記バリュー移動申請を許可するか否かの問い合わせを行い、
    前記第2取引主体から受けた前記バリュー移動申請を許可するとの通知が第1条件を満たす場合、前記所定のバリューを、該第1取引主体のメイン口座に移動させ、
    前記第2取引主体から受けた前記バリュー移動申請を許可するとの通知が前記第1条件を満たさない場合、前記所定のバリューを、該第1取引主体のメイン口座に移動させない、
    請求項1乃至8のいずれか一項に記載の取引管理装置。
  10. 前記第1条件を満たす場合とは、全ての前記第2取引主体又は所定の割合以上の前記第2取引主体から前記バリュー移動申請を許可するとの通知を受けた場合である、
    請求項に記載の取引管理装置。
  11. 前記第1条件を満たす場合とは、前記バリュー移動申請を許可するとの通知を受けた前記第2取引主体の各々が保持する投票権の合計が、少なくとも前記第2取引主体が保持する投票権の合計のうち所定の割合以上となる場合である、
    請求項に記載の取引管理装置。
  12. 前記受付部は、前記第2取引主体のうち前記バリュー移動申請を許可するとの通知を行った第3取引主体の各々から、前記第1取引主体のメイン口座に移動させた前記所定のバリューを、前記取引を受けた取引主体のメイン口座に格納されるバリュー残高に戻すことを指示するバリュー移動取消申請を受け付け、
    前記移動処理部は、前記第3取引主体から受けた前記バリュー移動取消申請が第2条件を満たす場合、前記第1取引主体のメイン口座に格納される前記所定のバリューを、前記取引を受けた取引主体のメイン口座に移動させる、
    請求項乃至11のいずれか一項に記載の取引管理装置。
  13. 前記第2条件を満たす場合とは、全ての前記第3取引主体又は所定の割合以上の前記第3取引主体から前記バリュー移動取消申請を許可するとの通知を受けた場合である、
    請求項12に記載の取引管理装置。
  14. 前記第2条件を満たす場合とは、前記バリュー移動取消申請を受けた前記第3取引主体の各々が保持する投票権の合計が、少なくとも前記第3取引主体が保持する投票権の合計の半数以上である所定の割合以上となる場合である、
    請求項12に記載の取引管理装置。
  15. 前記受付部は、前記第2取引主体のうち前記バリュー移動申請を許可するとの通知を行った第3取引主体の各々から、前記第1取引主体のメイン口座を利用不可にすることを指示するロック申請を受け付け、
    前記移動処理部は、前記第3取引主体から受けた前記ロック申請が第3条件を満たす場合、前記第1取引主体のメイン口座を前記第1取引主体が利用することができないロック状態に設定する、
    請求項乃至11のいずれか一項に取引管理装置。
  16. 前記第3条件を満たす場合とは、全ての前記第3取引主体又は所定の割合以上の前記第3取引主体から前記ロック申請を受けた場合である、
    請求項15に記載の取引管理装置。
  17. 前記第3条件を満たす場合とは、前記ロック申請を受けた前記第3取引主体の各々が保持する投票権の合計が、少なくとも前記第3取引主体が保持する投票権の合計の半数以上である所定の割合以上となる場合である、
    請求項15に記載の取引管理装置。
  18. 複数の取引主体の間で行われる取引を管理する取引管理装置が行う取引管理方法であって、
    前記複数の取引主体の各々が所有するバリューを管理する口座を、該取引主体ごとに記憶部に記憶するステップと、
    取引を依頼した取引主体から該取引を受けた取引主体に銀行の預金とは異なるバリューを移動させることを指示するバリュー移動情報を受け付けるステップと、
    受け付けた前記バリュー移動情報に基づいて、前記取引を依頼した取引主体のバリュー残高から、前記取引を受けた取引主体のバリュー残高に、前記バリュー移動情報で指示される額のバリューを移動させるステップと、
    を有し、
    前記記憶部に記憶される前記口座は、該口座に対応する取引主体が所有するバリューのバリュー残高を格納するメイン口座と、該口座に対応する取引主体に対して取引を依頼した取引主体から仮払いされたバリューを格納するサブ口座とを含み、
    前記受け付けるステップは、前記取引を依頼した取引主体から前記取引を受けた取引主体に仮払いされた額のバリューを、前記取引を受けた取引主体に支払うことを指示する支払い指示を受け付け、
    前記移動させるステップは、前記受け付けるステップで受け付けた前記支払い指示に基づいて、前記取引を依頼した取引主体のサブ口座若しくは前記取引を受けた取引主体のサブ口座に格納されている前記仮払い指示で指示された額のバリューを、前記取引を受けた取引主体のメイン口座に移動させるか、又は、前記取引を依頼した取引主体のサブ口座に格納されている前記仮払い指示で指示された額のバリューを、前記取引を受けた取引主体のサブ口座に移動させる、取引管理方法。
  19. 複数の取引主体の間で行われる取引を管理するプログラムであって、
    コンピュータを、
    前記複数の取引主体の各々が所有するバリューを管理する口座を、該取引主体ごとに記憶する記憶手段と、
    取引を依頼した取引主体から該取引を受けた取引主体に銀行の預金とは異なるバリューを移動させることを指示するバリュー移動情報を受け付ける受付手段と、
    前記受付手段で受け付けた前記バリュー移動情報に基づいて、前記取引を依頼した取引主体のバリュー残高から、前記取引を受けた取引主体のバリュー残高に、前記バリュー移動情報で指示される額のバリューを移動させる移動処理手段と、
    して実行させ
    前記記憶手段に記憶される前記口座は、該口座に対応する取引主体が所有するバリューのバリュー残高を格納するメイン口座と、該口座に対応する取引主体に対して取引を依頼した取引主体から仮払いされたバリューを格納するサブ口座とを含み、
    前記受付手段は、前記取引を依頼した取引主体から前記取引を受けた取引主体に仮払いされた額のバリューを、前記取引を受けた取引主体に支払うことを指示する支払い指示を受け付け、
    前記移動処理手段は、前記受付手段で受け付けた前記支払い指示に基づいて、前記取引を依頼した取引主体のサブ口座若しくは前記取引を受けた取引主体のサブ口座に格納されている前記仮払い指示で指示された額のバリューを、前記取引を受けた取引主体のメイン口座に移動させるか、又は、前記取引を依頼した取引主体のサブ口座に格納されている前記仮払い指示で指示された額のバリューを、前記取引を受けた取引主体のサブ口座に移動させる、プログラム。
JP2019084198A 2018-05-07 2019-04-25 取引管理装置、取引管理方法及びプログラム Active JP6688420B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2018089272 2018-05-07
JP2018089272 2018-05-07

Publications (2)

Publication Number Publication Date
JP2019197544A JP2019197544A (ja) 2019-11-14
JP6688420B2 true JP6688420B2 (ja) 2020-04-28

Family

ID=68537555

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2019084198A Active JP6688420B2 (ja) 2018-05-07 2019-04-25 取引管理装置、取引管理方法及びプログラム

Country Status (1)

Country Link
JP (1) JP6688420B2 (ja)

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3902151B2 (ja) * 1997-02-06 2007-04-04 富士通株式会社 取引管理装置、および、取引管理プログラムを格納する記憶媒体
JP2001357334A (ja) * 2000-06-12 2001-12-26 Canon Inc 予算管理システム、予算管理方法、電子マネー記録媒体、予算管理サーバ及び予算管理プログラムを記録した記録媒体
JP2008304977A (ja) * 2007-06-05 2008-12-18 Seiko Epson Corp 報酬支払いシステムおよびプログラム
JP2008305112A (ja) * 2007-06-07 2008-12-18 Actsystem Co Ltd 会員制Web電子マネーサイト管理システム
JP2009151692A (ja) * 2007-12-21 2009-07-09 Hitachi Ltd 電子マネーバンクシステムおよび端末
JP5848745B2 (ja) * 2013-12-25 2016-01-27 株式会社三井住友銀行 サプライチェーン向け新決済スキーム
JP2016224498A (ja) * 2015-05-27 2016-12-28 ベスカ株式会社 プリペイドカード管理システム及びプリペイドカード管理方法
WO2017056309A1 (ja) * 2015-10-02 2017-04-06 株式会社野村総合研究所 情報処理装置および情報処理方法

Also Published As

Publication number Publication date
JP2019197544A (ja) 2019-11-14

Similar Documents

Publication Publication Date Title
US20170330159A1 (en) Resource allocation and transfer in a distributed network
US20130346123A1 (en) Reservation method and system with improved pnr handling
CN102262767A (zh) 用于服务组的代理服务交付的服务交付管理
CN102262761A (zh) 用于代理服务交付的服务交付管理
KR101303300B1 (ko) 담보거래 서비스 방법
WO2020220746A1 (zh) 一种基于区块链的结算方法、装置以及电子设备
JP5139506B2 (ja) 賃金支払装置と賃金支払方法、及び賃金支払プログラム
JP6437155B1 (ja) 支払管理サーバ、支払管理システム、支払管理方法及び支払管理プログラム
JP4648929B2 (ja) 賃金支払装置と賃金支払方法、及び賃金支払プログラム
JP2004199525A (ja) 前払可能な支払方法及びサーバ装置、並びにプログラム
JP6688420B2 (ja) 取引管理装置、取引管理方法及びプログラム
US20200014632A1 (en) Resource path monitoring
JP4679048B2 (ja) 電子チケット管理・流通システム及び電子チケット流通サーバ
KR101984620B1 (ko) 직불전자지급 플랫폼을 이용한 전자 결제 시스템
JP4580970B2 (ja) 検索仲介システム
JP2006350679A (ja) 補助金支給システムとそれを実現するためのコンピュータプログラムとその方法
JP6062522B1 (ja) 賃金の支払をサポートするシステム、方法及びプログラム
JP2002015139A (ja) クレジットカード及びネット銀行用カードとして兼用可能な複合型カードの処理システム
US20130173472A1 (en) Transaction Management System
JP5871966B2 (ja) 電子記録債権管理システム
JP2019114242A (ja) 賃貸料決済システム及び賃貸料決済方法
JP6629908B2 (ja) 取引記録システムおよびプログラム
WO2021141083A1 (ja) 給与前払管理装置、給与前払管理方法およびプログラム
JP2020123211A (ja) 情報処理方法、情報処理装置、および情報処理プログラム
JP2021157478A (ja) ウォレットサーバ、ウォレットプログラムおよびウォレットシステム

Legal Events

Date Code Title Description
AA64 Notification of invalidation of claim of internal priority (with term)

Free format text: JAPANESE INTERMEDIATE CODE: A241764

Effective date: 20190614

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20190731

A871 Explanation of circumstances concerning accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A871

Effective date: 20190731

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20190719

A975 Report on accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A971005

Effective date: 20191008

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20200110

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20200303

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20200313

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20200403

R150 Certificate of patent or registration of utility model

Ref document number: 6688420

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150