特許 6234539 データ構造、情報処理装置、プログラム、情報処理方法及びトランザクションシステム

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

(12)【公報種別】特許公報(B1)

(11)【特許番号】6234539

(24)【登録日】2017年11月2日

(45)【発行日】2017年11月22日

(54)【発明の名称】データ構造、情報処理装置、プログラム、情報処理方法及びトランザクションシステム

(51)【国際特許分類】

   G06Q 40/02 20120101AFI20171113BHJP

【ＦＩ】

   G06Q40/02

【請求項の数】15

【全頁数】78

(21)【出願番号】特願2016-223458(P2016-223458)

(22)【出願日】2016年11月16日

【審査請求日】2017年7月5日

【早期審査対象出願】

(73)【特許権者】

【識別番号】516344878

【氏名又は名称】ＰｗＣあらた有限責任監査法人

(74)【代理人】

【識別番号】100114188

【弁理士】

【氏名又は名称】小野 誠

(74)【代理人】

【識別番号】100119253

【弁理士】

【氏名又は名称】金山 賢教

(74)【代理人】

【識別番号】100124855

【弁理士】

【氏名又は名称】坪倉 道明

(74)【代理人】

【識別番号】100129713

【弁理士】

【氏名又は名称】重森 一輝

(74)【代理人】

【識別番号】100137213

【弁理士】

【氏名又は名称】安藤 健司

(74)【代理人】

【識別番号】100143823

【弁理士】

【氏名又は名称】市川 英彦

(74)【代理人】

【識別番号】100151448

【弁理士】

【氏名又は名称】青木 孝博

(74)【代理人】

【識別番号】100183519

【弁理士】

【氏名又は名称】櫻田 芳恵

(74)【代理人】

【識別番号】100196483

【弁理士】

【氏名又は名称】川嵜 洋祐

(74)【代理人】

【識別番号】100203035

【弁理士】

【氏名又は名称】五味渕 琢也

(74)【代理人】

【識別番号】100185959

【弁理士】

【氏名又は名称】今藤 敏和

(74)【代理人】

【識別番号】100160749

【弁理士】

【氏名又は名称】飯野 陽一

(74)【代理人】

【識別番号】100160255

【弁理士】

【氏名又は名称】市川 祐輔

(74)【代理人】

【識別番号】100202267

【弁理士】

【氏名又は名称】森山 正浩

(74)【代理人】

【識別番号】100146318

【弁理士】

【氏名又は名称】岩瀬 吉和

(74)【代理人】

【識別番号】100127812

【弁理士】

【氏名又は名称】城山 康文

(72)【発明者】

【氏名】田中 宗英

【審査官】 田付 徳雄

(56)【参考文献】

【文献】 特開２０１６−００４３０４（ＪＰ，Ａ）

【文献】 特開２０１６−１７０５３０（ＪＰ，Ａ）

【文献】 特開２０１６−２１９０１４（ＪＰ，Ａ）

【文献】 米国特許出願公開第２０１５／０３６３７６９（ＵＳ，Ａ１）

【文献】 淵田 康之，金融ＩＴ・イノベーションの進展，野村資本市場クォータリー ２０１６年冬号，日本，株式会社野村資本市場研究所，２０１６年 ２月 １日，第19巻,第3号，第5-19頁

【文献】 森岡 剛，ビットコインを支えるブロックチェーン革新的技術による新サービス創造の動向，ＣａｒｄＷａｖｅ ２０１５年９・１０月号，日本，株式会社カード・ウェーブ，２０１５年１０月２５日，第28巻,第5号，第29-33頁

【文献】 ベイジアコイン関西取引所，スマートコントラクトとブロックチェーンの融合（ベイジアコイン），日本，２０１６年 ２月２０日，ＵＲＬ，https://www.kansaijpy.com/2016/02/20/スマートコントラクトとブロックチェーンの融合/

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｑ １０／００ − ９９／００

(57)【特許請求の範囲】

【請求項1】

ブロックチェーンを用いたトランザクションシステムにおいて、
第１債務に係る第１トランザクションデータを検索する手段と、
前記検索されたトランザクションデータに係る情報を表示する手段と、
前記表示された情報を用いるかどうかを選択する選択手段と、
前記表示された情報が選択された場合に、
前記第１債務の債権者が負う第２債務に係る金額を示す第２債務金額データと、
前記第２債務の債権者を示す債権者データと、
前記第１トランザクションデータを特定するデータ又は前記第１トランザクションデータの一部を特定するデータと、
を有する前記第２債務に係る第２トランザクションデータを生成する手段と、
前記第１トランザクションに係る原債務者データを、前記第２トランザクションデータに係る原債務者データとして、ブロックチェーンの外のアプリデータに設定する手段と、
を有することを特徴とする、トランザクションシステム。

【請求項2】

前記第２トランザクションデータは、前記第１債務の債務者が、前記第２債務の債権者に対して有する債務を示すことを特徴とする、請求項１に記載のトランザクションシステム。

【請求項3】

前記トランザクションシステムは、更に、前記原債務者の利用者アプリに流通の可否を問い合わせるかどうかを判断する判断部を有し、
前記第１トランザクションデータを生成する生成手段は、前記問い合わせをしないと判断した場合において流通が可能であるとの事前の情報を確認した場合、又は前記問い合わせをすると判断した場合において流通が可能であるとの回答を得た場合に、前記第２トランザクションデータを生成することを特徴とする、請求項１又は２に記載のトランザクションシステム。

【請求項4】

前記トランザクションシステムは、情報処理装置を有することを特徴とする、請求項１乃至３のいずれか一項に記載のトランザクションシステム。

【請求項5】

前記トランザクションシステムは、記憶装置を有することを特徴とする、請求項１乃至４のいずれか一項に記載のトランザクションシステム。

【請求項6】

コンピュータが、
ブロックチェーンを用いたトランザクションシステムにおいて、
第１債務に係る第１トランザクションデータを検索するステップと、
前記検索されたトランザクションデータに係る情報を表示するステップと、
前記表示された情報を用いるかどうかの選択された情報を取得するステップと、
前記表示された情報が選択された場合に、
前記第１債務の債権者が負う第２債務に係る金額を示す第２債務金額データと、
前記第２債務の債権者を示す債権者データと、
前記第１トランザクションデータを特定するデータ又は前記第１トランザクションデータの一部を特定するデータと、
を有する前記第２債務に係る第２トランザクションデータを生成するステップと、
前記第１トランザクションに係る原債務者データを、前記第２トランザクションデータに係る原債務者データとして、ブロックチェーンの外のアプリデータに設定するステップと、
を有することを特徴とする、トランザクション方法。

【請求項7】

前記第２トランザクションデータは、前記第１債務の債務者が、前記第２債務の債権者に対して有する債務を示すことを特徴とする、請求項６に記載のトランザクション方法。

【請求項8】

更に、前記原債務者の利用者アプリに流通の可否を問い合わせるかどうかを判断するステップと、
前記第１トランザクションデータを生成する生成手段は、前記問い合わせをしないと判断した場合において流通が可能であるとの事前の情報を確認した場合、又は前記問い合わせをすると判断した場合において流通が可能であるとの回答を得た場合に、前記第２トランザクションデータを生成するステップと、
を含むことを特徴とする、請求項６又は７に記載のトランザクション方法。

【請求項9】

前記コンピュータは、情報処理装置を有することを特徴とする、請求項６乃至８のいずれか一項に記載のトランザクション方法。

【請求項10】

前記コンピュータは、記憶装置を有することを特徴とする、請求項６乃至９のいずれか一項に記載のトランザクション方法。

【請求項11】

コンピュータを、
ブロックチェーンを用いたトランザクションシステムにおいて、
第１債務に係る第１トランザクションデータを検索する手段、
前記検索されたトランザクションデータに係る情報を表示する手段、
前記表示された情報を用いるかどうかを選択された情報を取得する手段、
前記表示された情報が選択された場合に、
前記第１債務の債権者が負う第２債務に係る金額を示す第２債務金額データと、
前記第２債務の債権者を示す債権者データと、
前記第１トランザクションデータを特定するデータ又は前記第１トランザクションデータの一部を特定するデータと、
を有する前記第２債務に係る第２トランザクションデータを生成する手段、
前記第１トランザクションに係る原債務者データを、前記第２トランザクションデータに係る原債務者データとして、ブロックチェーンの外のアプリデータに設定する手段、
として動作させることを特徴とする、トランザクションプログラム。

【請求項12】

前記第２トランザクションデータは、前記第１債務の債務者が、前記第２債務の債権者に対して有する債務を示すことを特徴とする、請求項１１に記載のトランザクションプログラム。

【請求項13】

更に、前記原債務者の利用者アプリに流通の可否を問い合わせるかどうかを判断する手段、
前記第１トランザクションデータを生成する生成手段は、前記問い合わせをしないと判断した場合において流通が可能であるとの事前の情報を確認した場合、又は前記問い合わせをすると判断した場合において流通が可能であるとの回答を得た場合に、前記第２トランザクションデータを生成する手段、
を含むことを特徴とする、請求項１１又は１２に記載のトランザクションプログラム。

【請求項14】

前記コンピュータは、情報処理装置を有することを特徴とする、請求項１１乃至１３のいずれか一項に記載のトランザクションプログラム。

【請求項15】

前記コンピュータは、記憶装置を有することを特徴とする、請求項１１乃至１４のいずれか一項に記載のトランザクションプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本出願において開示された技術は、債務取引に関連したデータ構造又は当該債務取引に関連した情報処理を実行する情報処理装置、プログラム、情報処理方法及びトランザクションシステムに関する。

【背景技術】

【0002】

金融取引は、多数の情報を扱うことから、金融取引をコンピュータで処理させる技術が開発されている。しかし、コンピュータで処理される電子情報は改ざん等が容易であることから、金融取引に関する情報を扱う際には、セキュリティに対して強固にする必要がある。例えば、特許第５８７１３４７号公報（特許文献１）のように暗号を用いた手段がある。また、特開２０１４−９９１９８号公報（特許文献２）のように金融取引の債務を処理する技術が提案されている。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】特許第５８７１３４７号公報

【特許文献2】特開２０１４−９９１９８号公報

【発明の概要】

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

【0004】

しかしながら、上記技術文献に記載された従来技術によっても、所望の債務取引が実現されていない。
そこで、本発明の様々な実施形態により、利用者が利用しやすい債務取引に係るデータ構造、情報処理装置、プログラム又は方法を提供する。

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

【0005】

本願発明の一実施例は、債務に係る金額を示す債務金額データ及び前記債務の債権者を示す債権者データを有する第１トランザクションデータを有する情報処理装置又はトランザクションシステムであって、前記第１トランザクションデータは、ブロックチェーンを用いたトランザクションシステムに係り、前記トランザクションシステムは、前記第１トランザクションデータと前記債務の原債務者に係る情報を関連付けるデータである原債務者データを扱うことを特徴とする、前記情報処理装置又はトランザクションシステム。

【0006】

本願発明の一実施例は、前記債務の原債務者に係る情報を有する第２トランザクションデータと、を更に有する情報処理装置又はトランザクションシステム。

【0007】

本願発明の一実施例は、ブロックチェーンに係るトランザクションデータであって、債務に係る金額を示す債務金額データ及び前記債務の債権者を示す債権者データを有する、前記トランザクションデータを有する情報処理装置又はトランザクションシステム。

【0008】

本願発明の一実施例は、債務に係る金額を示す債務金額データ及び前記債務の債権者を示す債権者データを有する第１トランザクションデータと、前記債務の原債務者に係る情報を有する第２トランザクションデータと、を有する情報処理装置又はトランザクションシステムであって、前記第１トランザクションデータと前記第２トランザクションデータは、ブロックチェーンに係ることを特徴とする、情報処理装置又はトランザクションシステム。

【0009】

本願発明の一実施例は、債務に係る金額を示す債務金額データ及び前記債務の債権者を示す債権者データを有する第１トランザクションデータと、前記債務の原債務者に係る情報を有する第２トランザクションデータと、を有する情報処理装置又はトランザクションシステムであって、前記第１トランザクションデータと前記第２トランザクションデータは、ブロックチェーンを用いたトランザクションシステムに係ることを特徴とする、情報処理装置又はトランザクションシステム。

【0010】

本願発明の一実施例は、前記トランザクションシステムは、前記第１トランザクションデータと前記債務の原債務者に係る情報を関連付けるデータである原債務者データを扱うことを特徴とする、情報処理装置又はトランザクションシステム。

【0011】

本願発明に係る一実施例は、債務に係る金額を示す債務金額データ及び前記債務の債権者を示す債権者データを有する第１トランザクションデータを有する情報処理装置又はトランザクションシステムであって、
前記第１トランザクションデータは、ブロックチェーンを用いたトランザクションシステムに係り、前記トランザクションシステムは、前記第１トランザクションデータと前記債務の原債務者に係る情報を関連付けるデータである原債務者データを扱うことを特徴とする、前記情報処理装置又はトランザクションシステム。

【0012】

本願発明の一実施例は、前記トランザクションシステム内の前記債務金額データの合計が、前記第１トランザクションデータの生成に伴って、前記トランザクションシステム内で定められたルールに基づく値とは異なる値で増加することを特徴とする、情報処理装置又はトランザクションシステム。
前記債務の原債務者に係る情報は、トランザクションデータの一部でもよい。
また、前記債務の原債務者に係る情報とは、原債務者を直接的又は間接的に特定できる情報であればよい。例えば、原債務者の公開鍵、当該公開鍵の一部、当該公開鍵にハッシュ関数を適用した値、原債務者が発行したＴデータ若しくは当該Ｔデータの一部、などでもよい。
また、本願明細書において、当事者を示すデータ、第三者を示すデータも同様に、公開鍵、当該公開鍵の一部、当該公開鍵にハッシュ関数を適用した値、当該当事者又は第三者が発行したＴデータ若しくは当該Ｔデータの一部、などでもよい。また、第三者は、実在する者、法人などでもよいし、存在しない架空の者、システム上設定された者でもよい。

【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】

前記トランザクションの少なくとも一部とは、複数のトランザクションの一部を表示できることを示す。
本願発明の一実施例は、トランザクションを示すデータ構造における、債務の取引に係る日に係る情報を取得するステップと、所定の条件を満たす前記日を有する前記データ構造又は前記データ構造に係る情報を特定するステップと、前記データ構造に係る情報を、所定の当事者に提供するステップと、を有する方法。

【0093】

前記マルチラテラルネッティングの当事者とは異なる第三者とは、マルチラテラルネッティングを使用する債務の保有者である当事者以外の者であり、例えば、他の法人、統括会社などを示す。統括会社は、法人、銀行、投資会社、郵便局などの金融機関であってもよい。

【0094】

前記第１当事者と前記第三者の間の複数の債務額の合計額を示すデータとは、第１当事者と第三者の間の複数の債務を合算して、相殺した額を示すデータである。第１当事者と第三者の間の複数の債務は、債務者が、第１当事者の場合もあれば、第三者の場合もあるため、これらの間の相殺の結果、正負はどちらにでもなりえる。但し、データ構造として、債権者と債務者を入れ替えることにより、合計額を常に正の数としてもよい。

【0095】

異なる金額とは、本来の債務に係る金額と比較して、増えた金額であっても、減った金額であってもよい。なお、第１当事者と第２当事者の間に直接の債務が無く、第三者を介する債務の場合は、第１当事者又は第２当事者のいずれかを当事者としない債務であることから、債務の金額が０の場合であり、異なる金額の一つの例である。

【0096】

本願発明の一実施例は、債務に係る金額を示す第１債務金額データと、前記債務の債権者を示す債権者データとを有するトランザクションデータを生成する生成手段と、を有する情報処理装置又はトランザクションシステムであってもよい。

【0097】

本願発明の一実施例は、債務に係る金額を示す第１債務金額データと、前記債務の債権者を示す債権者データとを有する第１トランザクションデータに基づき、前記第１トランザクションデータを特定する特定データ又は前記第１トランザクションデータの一部を特定する特定データと、前記第１債務金額データと、を有する第２トランザクションデータを生成する流通手段と、を有する情報処理装置又はトランザクションシステムであってもよい。

【0098】

本願発明の一実施例は、債務に係る金額を示す第１債務金額データと、前記債務の債権者を示す債権者データとを有する第１トランザクションデータに基づき、前記第１トランザクションデータを特定する特定データ又は前記第１トランザクションデータの一部を特定する特定データと、金額を示す複数のデータと、を有する第２トランザクションデータを生成する流通手段と、を有する情報処理装置又はトランザクションシステムであって、前記金額を示す複数のデータの合計が前記第１債務金額と一致することを特徴とする、前記流通手段と、を有する情報処理装置又はトランザクションシステムであってもよい。

【0099】

本願発明の一実施例は、債務に係る金額を示す第１債務金額データと、前記債務の債権者を示す第１債権者データとを有する第１トランザクションデータに基づき、前記第２債務金額データと、前記債権者データとを有する第２トランザクションデータを生成する更改手段と、を有する情報処理装置又はトランザクションシステムであってもよい。

【0100】

本願発明の一実施例は、債務に係る金額を示す第１債務金額データと、前記債務の債権者を示す第１債権者データとを有するトランザクションデータにおいて、複数の前記トランザクションデータに基づき、債務に係る金額を示す第２債務金額データと、前記債務の債権者を示す第２債権者データとを有する第２トランザクションデータを生成する更改手段であって、前記複数の前記トランザクションデータに係る前記第１債務金額データの合計が前記第２債務金額データに一致することを特徴とする、前記更改手段を有する情報処理装置又はトランザクションシステムであってもよい。

【0101】

本願発明の一実施例は、債務に係る金額を示す第１債務金額データと、前記債務の債権者を示す第１債権者データとを有するトランザクションデータにおいて、複数の前記トランザクションデータに基づき、債務に係る金額を示す第２債務金額データと、前記債務の債権者を示す第２債権者データとを有する第２トランザクションデータを生成する更改手段であって、前記複数の前記トランザクションデータに係る前記第１債権者データと前記第２債権者データが一致することを特徴とする、前記更改手段を有する情報処理装置又はトランザクションシステムであってもよい。

【0102】

本願発明の一実施例は、債務に係る金額を示す第１債務金額データと、前記債務の債権者を示す第１債権者データとを有するトランザクションデータにおいて、複数の前記トランザクションデータに基づき、債務に係る金額を示す第２債務金額データと、前記債務の債権者を示す第２債権者データとを有する第２トランザクションデータを生成する更改手段であって、前記複数の前記トランザクションデータに係る前記第１債務金額のデータの合計が前記第２債務金額データに一致し、かつ、前記複数の前記トランザクションデータに係る前記第１債権者データと前記第２債権者データが一致することを特徴とする、前記更改手段を有する情報処理装置又はトランザクションシステムであってもよい。

【0103】

本願発明の一実施例は、第１債務に係る金額を示す第１債務金額データと前記第１債務の債権者を示す第１債権者データとを有する第１トランザクションデータ、前記第１債務に係る金額より大きい第２債務に係る金額を示す第２債務金額データと前記第２債務の債権者を示す第２債権者データとを有する第２トランザクションデータ、を備えるトランザクションシステムにおいて、前記第２債務金額から前記第１債務金額を控除した金額データと、前記第２債権者データとを有する第３トランザクションデータと、を生成する相殺手段と、有する情報処理装置又はトランザクションシステムであってもよい。

【0104】

本願発明の一実施例は、第１債務に係る金額を示す第１債務金額データと前記第１債務の債権者を示す第１債権者データとを有する第１トランザクションデータ、前記第１債務に係る金額より大きい第２債務に係る金額を示す第２債務金額データと前記第２債務の債権者を示す第２債権者データとを有する第２トランザクションデータ、前記第１債務に係る第１債務者を特定するデータ、及び前記第２債務に係る第２債務者を特定するデータを備えるトランザクションシステムにおいて、前記第１債務者を特定するデータと前記第２債権者データが実質的に同じ場合又は、前記第２債務者を特定するデータと前記第１債権者データが実質的に同じ場合、前記第２債務金額から前記第１債務金額を控除した金額データと、前記第２債権者データとを有する第３トランザクションデータと、を生成する相殺手段と、有する情報処理装置又はトランザクションシステムであってもよい。

【0105】

ここで、前記第１債務者を特定するデータと前記第２債権者データが実質的に同じ場合とは、前記第１債務者を特定するデータと前記第２債権者データが一致する場合の他、前記第１債務者を特定するデータと前記第２債権者データを関連付けるデータがあってもよい。

【発明の効果】

【0106】

本発明の一実施形態により、債務取引に係る利用者の便宜を向上させることができる。

【図面の簡単な説明】

【0107】

【図1】図１は、本発明の一実施形態の一部に係る情報処理システムの構成を示すブロック図である。

【図2】図２は、本発明の他の実施形態の一部に係る情報処理システムの構成を示すブロック図である。

【図3】図３は、本発明の他の実施形態の一部に係る情報処理システムの構成を示すブロック図である。

【図4】図４は、本発明の一実施形態の一部に係る情報処理システムの構成を示すブロック図である。

【図5】図５は、本発明の一実施形態の一部に係るデータ構造の例である。

【図6】図６は、本発明の一実施形態の一部に係るデータ構造の例である。

【図7】図７は、本発明の一実施形態の一部に係るデータ構造の例である。

【図8】図８は、本発明の一実施形態の一部に係るデータ構造の例である。

【図9】図９は、本発明の一実施形態の一部に係る機能の例を示すブロック図である。

【図10】図１０は、本発明の一実施形態の一部に係る動作の例を示すフロー図である。

【図11】図１１は、本発明の一実施形態の一部に係る情報処理装置を含む情報処理システムの一状況を示すブロック図である。

【図12】図１２は、本発明の一実施形態の一部に係る機能の例を示すブロック図である。

【図13】図１３は、本発明の一実施形態の一部に係るデータ構造の例である。

【図14】図１４は、本発明の一実施形態の一部に係る動作の例を示すフロー図である。

【図15】図１５は、本発明の一実施形態の一部に係る機能の例を示すブロック図である。

【図16】図１６は、本発明の一実施形態の一部に係るデータ構造の例である。

【図17】図１７は、本発明の一実施形態の一部に係るデータ構造の例である。

【図18】図１８は、本発明の一実施形態の一部に係るデータ構造の例である。

【図19】図１９は、本発明の一実施形態の一部に係る動作の例を示すフロー図である。

【図20】図２０は、本発明の一実施形態の一部に係る機能の例を示すブロック図である。

【図21】図２１は、本発明の一実施形態の一部に係る動作の例を示すフロー図である。

【図22】図２２は、本発明の一実施形態の一部に係るデータ構造の例である。

【図23】図２３は、本発明の一実施形態の一部に係る動作の例を示すフロー図である。

【図24】図２４は、本発明の一実施形態の一部に係る動作の例を示すフロー図である。

【図25】図２５は、本発明の一実施形態の一部に係る動作の例を示すフロー図である。

【図26】図２６は、本発明の一実施形態の一部に係る動作の例を示すフロー図である。

【図27】図２７は、本発明の一実施形態の一部に係る動作の例を示すフロー図である。

【図28】図２８は、本発明の一実施形態の一部に係る動作の例を示すフロー図である。

【図29】図２９は、本発明の一実施形態の一部に係る動作の例を示すフロー図である。

【図30】図３０は、本発明の一実施形態の一部に係る動作の例を示すフロー図である。

【図31】図３１は、本発明の一実施形態の一部に係る動作の例を示すフロー図である。

【図32】図３２は、本発明の一実施形態の一部に係る動作の例を示すフロー図である。

【図33】図３３は、本発明の一実施形態の一部に係る情報処理装置を含む情報処理システムの一状況を示すブロック図である。

【図34】図３４は、本発明の一実施形態の一部に係るアプリケーションの画面例を示す図である。

【図35】図３５は、本発明の一実施形態の一部に係るアプリケーションの画面例を示す図である。

【図36】図３６は、本発明の一実施形態の一部に係るアプリケーションの画面例を示す図である。

【図37】図３７は、本発明の一実施形態の一部に係るアプリケーションの画面例を示す図である。

【図38】図３８は、本発明の一実施形態の一部に係る動作の例を示すフロー図である。

【図39】図３８は、本発明の一実施形態の一部に係る記憶テーブルの例を示す図である。

【図40】図４０は、本発明の一実施形態の一部に係る動作の例を示すフロー図である。

【図41】図４１は、本発明の一実施形態の一部に係る機能の例を示すブロック図である。

【図42】図４２は、本発明の一実施形態の一部に係る機能の決済方法の選択肢の例を示す図である。

【図43】図４３は、本発明の一実施形態の一部に係る記憶テーブルの例を示す図である。

【図44】図４４は、本発明の一実施形態の一部に係る記憶テーブルの例を示す図である。

【図45】図４５は、本発明の一実施形態の一部に係る記憶テーブルの例を示す図である。

【図46】図４６は、本発明の一実施形態の一部の例を示した図である。

【図47】図４７は、本発明の一実施形態の一部に関するイメージを示すグラフである。

【図48】図４８は、従来技術の一例である。

【図49】図４９は、本発明の一実施形態の一部であるマルチラテラルネッティングのグループに関する一例である。

【図50】図５０は、本発明の一実施形態の一部であるマルチラテラルネッティングのグループに関する一例である。

【図51】図５１は、本発明の一実施形態の一部であるＴデータの流通とサプライチェーンの関係を示す一例である。

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

【0108】

以下、添付図面を参照して本発明の様々な実施形態を説明する。なお、図面における共通する構成要素には同一の参照符号が付されている。

【0109】

１．情報処理装置の各構成とアプリケーション
１−１．情報処理装置上のアプリケーション例
情報処理装置上のアプリケーションは、ブロックチェーンを主に扱うアプリケーションを、ＢＣ（ＢｌｏｃｋＣｈａｉｎ）アプリ、周辺の管理者的な役割を果すアプリケーションを、管理者アプリ、利用者が使用する情報処理装置に関連する機能を有するアプリケーションを、利用者アプリ、と分類ができる。

【0110】

これらのアプリケーションのうち、ＢＣアプリが、ブロックチェーンの情報を保有するアプリケーションである。利用者アプリと管理者アプリは、本願発明の一実施例に係るブロックチェーンを、利用者側でサポートするか、管理者側でサポートするかの違いにすぎない。

【0111】

例えば、ネットワーク上の情報は、ＢＣアプリから、直接管理者アプリに伝達される場合もあれば、利用者アプリを介して、管理者アプリに伝達される場合もあり、情報が最終的に伝達される点において、これらに違いはない。すなわち、利用者アプリと管理者アプリの内容は、お互いに入れ替え可能でもある。

【0112】

また、本願発明の一実施例に係るブロックチェーンの情報を、利用者の情報処理装置内で管理すれば、ＢＣアプリと利用者アプリは同じ情報処理装置内で実行されてもよい。また、本願発明の一実施例に係るブロックチェーンの情報を、管理者の情報処理装置内で管理すれば、ＢＣアプリと管理者アプリは同じ情報処理装置内で実行されてもよい。さらに、本願発明の一実施例に係るブロックチェーンの情報を、利用者と管理者の双方の情報処理装置内で管理すれば、ＢＣアプリ、利用者アプリ及び管理者アプリは同じ情報処理装置内で実行されてもよい。

【0113】

このような趣旨において、以下では、その一例として、各情報処理装置の構成とそれらで実行されるアプリケーションを説明し、上記の各アプリが有する内容は、以降において適宜説明する。

【0114】

１−１．情報処理装置例１
本願発明の一実施例に係るシステム１は、図１のように、バス１１、演算部１２、記憶部１３、入力部１４、表示部１５及び通信ＩＦ１６を備えることができる情報処理装置１０と、ネットワーク２０と、バス３１、演算部３２、記憶部３３、入力部３４、表示部３５及び通信ＩＦ３６を備えることができる情報処理装置３０と、を有することができる。システム１は、情報処理装置１０及び３０以外にも情報処理装置を有してもよい。当該情報処理装置の台数は、数台から数十台、又は数百台から数千台等の台数でもよい。場合によっては、数万台以上の台数でもよい。

【0115】

バス１１は、演算部１２、記憶部１３、入力部１４、表示部１５及び通信ＩＦ１６の間の情報を伝達する機能を有し、バス３１は、演算部３２、記憶部３３、入力部３４、表示部３５及び通信ＩＦ３６の間の情報を伝達する機能を有する。

【0116】

利用者アプリ又はＢＣアプリは、主に、バス１１を用いて、演算部１２、記憶部１３、入力部１４、表示部１５及び通信ＩＦ１６の間で情報が伝達され、管理者アプリは、主に、バス３１を用いて、演算部３２、記憶部３３、入力部３４、表示部３５及び通信ＩＦ３６の間で情報が伝達される。

【0117】

演算部１２又は演算部３２は、例えばプロセッサが挙げられる。これは、ＣＰＵであってもよいし、ＭＰＵであってもよい。また、グラフィックスプロセッシングユニット、デジタルシグナルプロセッサなどを有してもよい。要するに、演算部１２又は演算部３２は、プログラムの命令を実行できる機能を有すればよい。

【0118】

利用者アプリ又はＢＣアプリは、主に、演算部１２を用いて実行され、管理者アプリは、主に、演算部３２を用いて実行される。

【0119】

記憶部１３又は記憶部３３は、情報を記録する機能を有する。これは、外部メモリと内部メモリのいずれでもよく、主記憶装置と補助記憶装置のいずれでもよい。また、磁気ディスク（ハードディスク）、光ディスク、磁気テープ、半導体メモリなどでもよい。また、ネットワークを介した記憶装置、クラウド上の記憶装置などでもよい。

【0120】

なお、演算装置に近い位置で情報を記憶する、レジスタ、Ｌ１キャッシュ、Ｌ２キャッシュなどは、図１の模式図においては、バスを介していない点で演算部１２（又は演算部３２）内に含まれる場合もあるが、計算機アーキテクチャのデザインにおいて、情報を記録する装置としては、記憶部１３（又は記憶部３３）がこれらを含んでもよい。要するに、演算部１２（又は演算部３２）、記憶部１３（又は記憶部３３）及びバス１１（又はバス３１）が協調して、情報処理を実行できればよい。

【0121】

また、上記は、演算部１２（又は演算部３２）が、記憶部１３（又は記憶部３３）に備えられたプログラムに基づいて実行される場合を記載したが、上記のバス１１（又はバス３１）、演算部１２（又は演算部３２）と記憶部１３（又は記憶部３３）が組み合わされた形式の一つとして、本件システムに係る情報処理を、ハードウェア回路自体を変更することができるプログラマブルロジックデバイス又は実行する情報処理が決まっている専用回路で実現されてもよい。

【0122】

利用者アプリ又はＢＣアプリは、主に、記憶部１３が用いられ、管理者アプリは、主に、記憶部３３が用いられる。

【0123】

入力部１４又は入力部３４は、情報を入力する機能を有する。入力部１４又は入力部３４としては、キーボード、マウス、タッチパネル、又はペン型の指示装置などの指示装置が挙げられる。

【0124】

表示部１５又は表示部３５は、例えば、ディスプレイがある。また、表示部１５又は表示部３５は、液晶ディスプレイ、プラズマディスプレイ、有機ＥＬディスプレイなどでもよい。要するに、情報を表示できる装置であればよい。また、タッチパネルのように入力部１４又は入力部３４を一部に備えてもよい。

【0125】

利用者アプリ又はＢＣアプリは、主に、入力部１４が用いられるが、通信ＩＦ１６が用いられてもよく、管理者アプリは、主に、入力部３４が用いられるが、通信ＩＦ３６が用いられてもよい。

【0126】

利用者アプリ又はＢＣアプリは、主に、出力部１５が用いられ、管理者アプリは、主に、出力部３５が用いられる。

【0127】

ネットワーク３０は、通信ＩＦ１６及び３６と共に、情報を伝達する機能を有する。すなわち、情報処理装置である２０の情報を、ネットワークを介して他の情報処理装置３０に伝達できるようにする機能を有する。通信ＩＦ１６又は３７は、シリアル接続及びパラレル接続のいずれでもよく、ＵＳＢ、ＩＥＥＥ１３９４、イーサネット（登録商標）、ＰＣＩ、ＳＣＳＩなどでもよい。また、ネットワーク３０は、有線と無線のいずれでもよく、光ファイバ、同軸ケーブル、イーサネット（登録商標）ケーブルなどを用いてもよい。

【0128】

本願発明の一実施例に係るシステムを構成するハードウェアは、汎用電子計算機であってもよいし、専用電子計算機であってもよい。また、当該ハードウェアは、ワークステーション、デスクトップパソコン、ラップトップパソコン、ノートパソコン、ＰＤＡ、携帯電話、スマートフォンなどでもよい。

【0129】

図２は、図１の情報処理装置１０及び３０が、複数存在する場合を示す例である。情報処理装置１０Ａ乃至１０Ｃが、情報処理装置１０に対応し、情報処理装置３０Ａ乃至３０Ｃが、情報処理装置３０に対応する。以降では、図２を用いて、他のハードウェアシステム形態の例を説明する。
１−２．情報処理装置例２

【0130】

本願発明の一実施例は、クライアントサーバ型のシステムであってもよい。
本願発明の一実施例に係るクライアントサーバ型のシステムは、端末である情報処理装置１０Ａ、１０Ｂ及び１０Ｃに対して、サーバである情報処理装置３０Ａ、３０Ｂ及び３０Ｃを備えることができる。
各１０Ａ乃至１０Ｃ及び各３０Ａ乃至３０Ｃは、演算部、記憶部、入出力部又は通信ＩＦを備えることができる。

【0131】

なお、シンクライアント又はＳＢＣ方式などの、端末である情報処理装置が主要な記憶媒体を備えない形式であってもよい。この場合、端末である情報処理装置１０Ａ乃至１０Ｃは、本願発明の一実施例に係るデータを扱う場合は、サーバである情報処理装置３０Ａ乃至３０Ｃに問い合わせることで、対応可能である。

【0132】

１０Ａ乃至１０Ｃと３つの端末の例を示したが、端末の数は３つに限られず、１つ又は２つでもよいし、４つ以上でもよい。
同様に、３０Ａ乃至３０Ｃと３つのサーバの例を示したが、サーバの数は３つに限られず、１つ又は２つでもよいし、４つ以上でもよい。

【0133】

利用者アプリ又はＢＣアプリは、主に、端末である情報処理装置１０Ａ、１０Ｂ及び１０Ｃ上で実行され、管理者アプリは、主に、サーバである情報処理装置３０Ａ、３０Ｂ及び３０Ｃ上で実行される。

【0134】

本願発明の一実施例に係るシステムは、上述の１０Ａ乃至１０Ｃ及び３０Ａ乃至３０Ｃの一部又は全てが、協調して、実現されることができる。

【0135】

１−３．情報処理装置例３
本願発明の一実施例に係るシステムは、Ｐ２Ｐ（Ｐｅｅｒ ｔｏ Ｐｅｅｒ）のシステムであってもよい。本願発明の一実施例に係るシステムは、端末である情報処理装置１０Ａ乃至１０Ｃ及び３０Ａ乃至３０Ｃを備えることができる。なお、Ｐ２Ｐであるから、１０Ａ乃至１０Ｃの機能と、３０Ａ乃至３０Ｃの機能は同じであってもよい。しかし、Ｐ２Ｐは、個々の端末の機能を特定しない態様もあることから、１０Ａ乃至１０Ｃの機能と、３０Ａ乃至３０Ｃの機能が異なっていてもよい。

【0136】

各１０Ａ乃至１０Ｃ及び各３０Ａ乃至３０Ｃは、演算部、記憶部、入出力部又は通信ＩＦを備えることができる。
上述同様に、１０Ａ乃至１０Ｃ、及び３０Ａ乃至３０Ｃと各３つの例を示したが、これらの数は３つに限られず、１つ又は２つでもよいし、４つ以上でもよい。

【0137】

利用者アプリ又はＢＣアプリは、主に、端末である情報処理装置１０Ａ、１０Ｂ及び１０Ｃ上で実行され、管理者アプリは、主に、他の端末である情報処理装置３０Ａ、３０Ｂ及び３０Ｃ上で実行される。

【0138】

本願発明に関わる一実施例は、上述の１０Ａ乃至１０Ｃ及び３０Ａ乃至３０Ｃの一部又は全てが、協調して、実現されることができる。

【0139】

１−４．情報処理装置例４
本願発明の一実施例に係るシステムは、クラウドシステムであってもよい。本願発明の一実施例に係るシステムは、端末である情報処理装置１０Ａ乃至１０Ｃ及びクラウド上の情報処理装置３０Ａ乃至３０Ｃを備えることができる。

【0140】

各１０Ａ乃至１０Ｃ及び各３０Ａ乃至３０Ｃは、演算部、記憶部、入出力部又は通信ＩＦを備えることができる。
上述同様に、１０Ａ乃至１０Ｃ、及び３０Ａ乃至３０Ｃと各３つの例を示したが、これらの数は３つに限られず、１つ又は２つでもよいし、４つ以上でもよい。

【0141】

情報処理装置１０Ａ乃至１０Ｃは、ＳａａＳ（Ｓｏｆｔｗａｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ）を備え、情報処理装置３０Ａ乃至３０Ｃは、ＰａａＳ（Ｐｌａｔｆｏｒｍ ａｓ ａ Ｓｅｒｖｉｃｅ）を備えることもできるが、この場合に限るものではない。

【0142】

利用者アプリ又はＢＣアプリは、主に、端末である情報処理装置１０Ａ、１０Ｂ及び１０Ｃ上で実行され、管理者アプリは、主に、クラウド上の情報処理装置３０Ａ、３０Ｂ及び３０Ｃ上で実行される。

【0143】

本願発明に関わる一実施例は、上述の１０Ａ乃至１０Ｃ及び３０Ａ乃至３０Ｃの一部又は全てが、協調して、実現されることができる。

【0144】

また、そのほか、本願発明に関わる一実施例は、グリッドシステム、フォグコンピューティングなどの形態であってもよい。

【0145】

１−５．情報処理装置例５
本願発明の一実施例に係るシステムは、上述のシステムの混合のシステムであってもよい。例えば、本願発明の一実施例に係るシステムは、Ｐ２Ｐの端末として、情報処理装置１０Ａ乃至１０Ｃ及びサーバの情報処理装置３０Ａ乃至３０Ｃを備えることができる。

【0146】

各１０Ａ乃至１０Ｃ及び各３０Ａ乃至３０Ｃは、演算部、記憶部、入出力部又は通信ＩＦを備えることができる。
上述同様に、１０Ａ乃至１０Ｃ、及び３０Ａ乃至３０Ｃと各３つの例を示したが、これらの数は３つに限られず、１つ又は２つでもよいし、４つ以上でもよい。

【0147】

利用者アプリ又はＢＣアプリは、主に、端末である情報処理装置１０Ａ、１０Ｂ及び１０Ｃ上で実行され、管理者アプリは、主に、サーバ上の情報処理装置３０Ａ、３０Ｂ及び３０Ｃ上で実行される。

【0148】

本願発明に関わる一実施例は、上述の１０Ａ乃至１０Ｃ及び３０Ａ乃至３０Ｃの一部又は全てが、協調して、実現されることができる。

【0149】

１−６．情報処理装置例６
本願発明の一実施例に係るシステムは、上述のシステムの混合のシステムであってもよい。一例について、図３を用いて説明する。例えば、本願発明の一実施例に係るシステムは、端末として情報処理装置１０Ａ乃至１０Ｃ、クラウド上のサーバとして、情報処理装置３０ＸＡ乃至３０ＸＣ及び３０ＹＡ乃至３０ＹＤを備えることができる。図３に係る本例は、特に、クラウド上のサーバとして、３０ＸＡ乃至３０Ｃのサーバと、３０ＹＡ乃至３０ＹＤのサーバの特性に異なる場合のハードウェア構成を示すものである。

【0150】

図１の情報処理装置１０及び３０との関係においては、情報処理装置１０Ａ乃至１０Ｃが、情報処理装置１０に対応し、情報処理装置３０ＸＡ乃至３０ＸＣ及び３０ＹＡ乃至３０ＹＤが、情報処理装置３０に対応する。
そのため、各１０Ａ乃至１０Ｃ、各３０ＸＡ乃至３０ＸＣ及び３０ＹＡ乃至３０ＹＤは、演算部、記憶部、入出力部又は通信ＩＦを備えることができる。

【0151】

上述同様に、１０Ａ乃至１０Ｃ、及び３０ＸＡ乃至３０ＸＣと各３つの例を示したが、これらの数は３つに限られず、１つ又は２つでもよいし、４つ以上でもよい。
また、３０ＹＡ乃至３０ＹＤを４つの例を示したが、これらの数は４つに限られず、１乃至３又は５以上でもよい。

【0152】

利用者アプリは、主に、端末である情報処理装置１０Ａ、１０Ｂ及び１０Ｃ上で実行され、ＢＣアプリは、主に、サーバ上の情報処理装置１０Ａ、１０Ｂ及び１０Ｃ上で実行され、管理者アプリは、主に、サーバ上の情報処理装置３０Ａ、３０Ｂ及び３０Ｃ上で実行される。

【0153】

本願発明に関わる一実施例は、上述の１０Ａ乃至１０Ｃ、３０Ａ乃至３０Ｃの一部又は全てが、協調して、実現されることができる。

【0154】

本件出願に係る発明の一形態は、以下で述べるいずれかのソフトウェア的機能を実現できるハードウェアシステムであれば、上述した種々のハードウェアシステムのいずれにおいても適用することができる。

【0155】

２．ブロックチェーンシステム
２−１．ブロックチェーンの構成
本願発明の一実施例に係るシステムは、ブロックチェーンのシステム４０を備える。当該ブロックチェーンは、周知のビットコインに使用されるブロックチェーンを使用することもできる。但し、ブロックチェーンにも複数のバージョンがあることから、ここでは、一例として、本願発明の一実施例に係るブロックチェーンシステムを説明するが、本願発明が適用可能なシステムは、以下で説明されるシステムに限られないことはいうまでもない。本願発明の一実施例に係るブロックチェーンシステム４０は、ブロックヘッディング４１Ａ乃至４３Ａと、ブロックボディ４１Ｂ乃至４３Ｂを備える。

【0156】

ブロックヘッディング４１Ａは、各ブロックヘッディングＩＤ４１ＡＡと、ブロックヘッディング参照ＩＤ４１ＡＢと、ブロックボディ参照ＩＤ４１ＡＣと、ナンス値４１ＡＤと、を備えてもよい。

【0157】

ブロックヘッディングＩＤ４１ＡＡは、ブロックヘッディングのＩＤを示すものである。ブロックヘッディング参照ＩＤ４１ＡＢは、数珠つなぎ上に構成されたブロックチェーンにおける前のブロックヘッディングを参照するＩＤを備える。これは、前のブロックヘッディングを指し示せる構成であればいかなる構成でもよく、間接的に当該前のブロックヘッディングを指し示せる情報を有しても良いし、当該前のブロックヘッディングの記録媒体上の番地を直接指し示してもよい。

【0158】

また、ブロックヘッディング参照ＩＤ４１ＡＢは、前のブロックヘッディング（前のブロックヘッディング又は前のブロック自体）に対してハッシュ関数を適用した結果であるハッシュ値によって参照できる形式を含んでもよい。このようなハッシュ値を備えた場合、前のブロックの値を変更すると、このハッシュ値も変更してしまうことから、データの改ざんを発見できることとなる。また、このようなブロックチェーンは、図４のように、数珠つなぎに構成されていくことから、前方に位置づけられるブロックのデータ情報を改ざんした場合に、このハッシュ値の値も含めて改ざんしていないかのような外観を作出することは困難であることは、周知のビットコインに使用されるブロックチェーンの構成と同様である。

【0159】

ブロックボディ参照ＩＤ４１ＡＣは、当該ブロックヘッディングが指し示すブロックボディを指し示す。これは、ブロックボディを指し示せる構成であればいかなる構成でもよく、間接的に当該ブロックボディを指し示せる情報を有しても良いし、当該ブロックボディの記録媒体上の番地を直接指し示してもよい。また、当該ブロックボディに間接的にでもたどり着ける構成であればよいので、例えば、ブロックボディを構成する個々のトランザクションを葉とするツリー上のデータ構造の根に対応する部分の情報を間接的に有する構成としてもよい。

【0160】

ブロックボディ４１Ｂは、複数のトランザクション４１Ｂ１乃至４１ＢＮを有してもよい（Ｎは、自然数である）。各トランザクションの構成については、次の節において述べる。

【0161】

ナンス値４１ＡＤは、ハッシュ値を計算するに当たり、プルーフオブワークとして働く数値であり、周知のビットコインにおけるブロックチェーンが備えるものと同じでも良い。すなわち、ナンスの値を変更してハッシュ関数によりハッシュ値を計算し、一定の条件を成立する値になるまで計算するようにする。一定の条件とは、例えば、ハッシュ値の先頭に一定の数以上の０が並ぶこと等が挙げられるが、これに限られない。この条件を変更することによって、正しいブロックとして認められるのに必要な負担が変更する。本願に係るシステムにおいては、一般的なブロックチェーンと比較して、その負担を緩和しても良い。例えば、一定の条件として、上記０が並ぶ数値を小さくする、又は０以外の値も許容する等が挙げられる。

【0162】

具体的には、本願情報処理システムの一形態は、取引に関するデータを有するデータ構造体（ブロックとも呼ばれる）が、数珠つなぎの構成になっている。各ブロックは、複数のトランザクションを有するよう作成される。

【0163】

トランザクションに係るデータは、周知のブロックチェーンと同様に、多数の情報処理装置により、保有される。これは、新しいトランザクションが発生した場合に、各情報処理装置により、トランザクションが生成される。当該ブロックの正当性は、情報処理装置が、ナンスを確認することで実施される。

【0164】

但し、本願に係る情報処理システムの一形態は、周知のビットコインに係るブロックチェーンと異なり、プルーフオブワークと呼ばれるブロックのハッシュ関数を見出す計算はなくてもよく、又は当該計算が１０分などのように必要な計算ではなく、その計算負荷を小さくする又は負荷計算をなしにして、容易に計算が終了するようにしてもよい。

【0165】

また、本願に係る情報処理システムの一形態は、周知のビットコインに係るブロックチェーンと異なり、ネットワーク上の情報処理装置は、誰でもセットアップできない（本件ブロックチェーンの情報共有ができない）ようにしてもよい。また、本願に係る情報処理システムの一形態に係るトランザクションのデータの共有は、管理又は許可処理としてもよい。

【0166】

さらに、本願に係る情報処理システムの一形態は、周知のビットコインに係るブロックチェーンと異なり、インセンティブに係る処理をしないよう構成してもよい。
また、本願に係る情報処理システムの一形態は、周知のビットコインに係るブロックチェーンと異なり、トランザクションごとの手数料に係る処理をしないよう構成してもよい。
また、本願に係る情報処理システムの一形態は、周知のビットコインに係るブロックチェーンと異なり、インフレーションレートに係る処理をしないよう構成してもよい。

【0167】

３．トランザクションのデータ構造
３−１．トランザクションのデータ構造の要素例
次に、図４のトランザクション４１Ｂ等に係るデータ構造例を、図５乃至８を用いて、説明する。なお、本願明細書では、トランザクション４１Ｂ等に係るデータ構造例を、Ｔデータ（トランザクションデータを意味する。）又は債務証書（当初生成時に債務を意味することのみに由来する。）と呼ぶこともある。

【0168】

本願発明に関わる一実施例において、Ｔデータは、トランザクションＩＤ、タイムスタンプ、送付者名のＩＤ、受取者名のＩＤ、金額、通貨種別、期日、決済方法、元の取引を示すＩＤ、トランザクションＩＤの履歴、原債務者などを有してよい。

【0169】

トランザクションＩＤとは、トランザクションを一意的に特定するためのＩＤである。当該ＩＤを一意的に定める方法は、周知な方法であってよい。

【0170】

タイムスタンプは、トランザクションが作成された時点のタイムスタンプである。

【0171】

送付者名（ＩＤ）とは、トランザクションに係る債務取引の債務者に係る情報又は当該債務者を債権者として生成されたＴデータに係る情報である。債務者に係る情報とは、そのシステム内で債務者を特定する情報であればよく、債務者の公開鍵、債務者の公開鍵の短縮版、債務者の公開鍵に対してハッシュ関数を適用したものなどであってもよい。また当該Ｔデータに係る情報とは、当該Ｔデータに係る情報であればよく、当該Ｔデータを特定もしくは参照する情報、又は当該Ｔデータの一部を特定もしくは参照する情報、であればよい。例えば、ＴデータのＩＤであるトランザクションＩＤ、またはトランザクションＩＤに付記情報が付されたもの、などが挙げられる。

【0172】

なお、本願明細書において、債務者又は債権者は、法人、団体（法人格のない団体を含む）、私人、又は個人であってもよい。

【0173】

受取者名（ＩＤ）とは、トランザクションに係る債務取引の債権者に係る情報である。当該情報は、送付者名における債務者に係る情報と同じである。なお、本願発明の実施例において、マルチラテラルネッティングの際に生成されるトランザクションデータ又はトランザクションを示すデータにおいて、移行の際に生じる債権者データは、債務者又は債権者の関係を経過的に示す場合もあるため、必ずしも債権者を示すとは限らない。

【0174】

金額とは、債務に係る金額である。原通貨建ての金額でもよいし、変更後の通貨の金額でもよい。また、仮想通貨の金額でもよい。原通貨建てで情報を保持する場合は、一定の通貨（たとえば、円、ドル、ユーロなど）に基づいて行われるが、この通貨建てを特に変更なく、この情報を入れることができる利点がある。また、通貨建てを変更する場合は、当事者の合意等によって、通貨建てを変更してもよい。また、仮想通貨の通貨規格（satoshiなど）で情報を保持してもよい。

【0175】

通貨種別とは、上述の使用した通貨建てである。円、ドル、ユーロなどの通貨に係る情報を有する。これは、通貨の種類であっても、通貨の単位でもよい。また、仮想通貨の場合は、その仮想通貨の種類又は単位でもよい。

【0176】

期日とは、債務取引に係る期日である。例えば、取引を行った日、契約に合意した日、契約に係る商品の譲渡、貸渡しなどが履行される日、又は決済の予定日などが挙げられる。これらは、当事者で何を入力するかを決めてもよいし、システム全体として決めてもよい。

【0177】

決済方法とは、債務取引の終了方法である。例えば、銀行振り込み、更改、流動性賃借、期限付き賃借などが考えられる。これらを示す情報が設定される。これらの設定された情報は、後で変更されてもよい。

【0178】

特記事項とは、債務取引に係る任意の事項である。ここでは、任意の事項について、記載されていてもよい。特記事項は、上記の各記載事項に関する取り決めを有してもよい。例えば、期日について、どのような値を入れるか、という当事者の決め事が具体的に設定されてもよい。

【0179】

各トランザクションは、上述した情報以外の情報を保有してもよいし、以下の例が示すとおり、上述した情報の一部を保有してもよい。

【0180】

元の取引を示すＩＤとは、いわゆる現実世界の具体的な取引を示すＩＤを意味し、具体的な取引に関してどのように形式でＩＤを定めてもよい。

【0181】

トランザクションＩＤの履歴とは、従前のトランザクションに関する情報の一部の情報である。あるトランザクションと他のトランザクションとは、以降で説明する債務の流通によって、トランザクション同士が関連性を有する場合がある。具体的には、あるトランザクションの前に、他のトランザクションが存在する場合がある。かかる場合、当該他のトランザクションに関する少なくとも一部の情報を、履歴として保有することができる。

【0182】

原債務者を示す情報における原債務者とは、上記のトランザクションに係る履歴が存在する場合において、履歴における最初のトランザクションに係る債務者をさす。かかる情報は、原債務者を特定する情報であれば、どのような情報でもよい。

【0183】

図５は、本願発明に関わる一実施例におけるトランザクションに係るデータ構造である。
各トランザクションは、トランザクション内５０１のとおり、トランザクションＩＤ５０３、タイムスタンプ５０４、送付者名（ＩＤ）５０５、受取者名（ＩＤ）５０６、金額５０７、通貨種別５０８、期日５０９、又は決済方法５１０、特記事項５１１などを有することができる。

【0184】

各トランザクションが、上述のとおり規定された実施例においては、トランザクション外５０２のとおり、原取引ＩＤ５１２、トランザクションＩＤの履歴５１３、原債務者５１４、通貨種別５１５、決済方法５１６は、トランザクション外で管理されてもよい。また、上述以外にも、当事者に関連する情報、契約に関連する情報、付随的な情報は全て、トランザクション外の情報としてもよい。本願では、トランザクション外の情報をアプリデータと称する。当該アプリデータは、本願発明の一実施例に係る情報処理装置において、記録される。

【0185】

３−１−１．データ構造の代替例１
図６は、本願に係る情報処理システムの他の一形態におけるトランザクションに係るデータ構造である。トランザクション内６０１とトランザクション外６０２に記憶される一例として、各項目が図示されている。

【0186】

各記載事項の説明は、図５と同じである。なお、金額（原通貨建て）と記載されているのは、金額の値が、原通貨建てで情報を保持することを示す。

【0187】

通貨種別及び決済法方法が、アプリデータとなっているため、これらの情報を失った場合には、必要あれば、他の方法で修復する必要がある。

【0188】

なお、金額が原価通貨建てであることから、通貨ごとにサーバを準備して対応しても良い。すなわち、円、ドル、ユーロなどの各通貨のサーバを用意し、各通貨に対応する各サーバが、各通貨で処理するＴデータを保有するように構成してもよい。

【0189】

なお、通貨種別の情報を使用しないその他の方方法として、ＴデータのＩＤの付与方法を、各通貨を示す形式（例えば、円は一桁目が１、ドルは一桁目が２等）とすることにより、各ＴデータのＩＤが、実質的には通貨種別の情報を保有できる形式としてもよい。

【0190】

図６に示したデータ構造は、特にビットコインのソースコードを利用する場合に使用できる可能性がある。また、ビットコインのソースコードを利用する場合、ビットコインのサイドチェーンとなれる可能性もある。

【0191】

３−１−２．データ構造の代替例２
図７は、本願に係る情報処理システムの他の一形態におけるトランザクションに係るデータ構造である。トランザクション内７０１とトランザクション外７０２に記憶される一例として、各項目が図示されている。

【0192】

図７では、オプショナルデータとして、通貨種別、期日、原債務者名を有してもよい。原債務者名は、トランザクションを伝達することで判明する情報ではあるが、債権の保有者が利用しうる情報の一つであることから、原債務者の情報を容易にアクセス可能とするために、各トランザクションが保有することとした形式である。

【0193】

図７に示したデータ構造は、特にＥｔｈｅｒｉｕｍのソースコードを利用する場合に使用できる可能性がある。また、Ｅｔｈｅｒｉｕｍのソースコードを利用する場合、Ｅｔｈｅｒｉｕｍのサイドチェーンとなれる可能性もある。

【0194】

３−１−３．データ構造の代替例３
図８は、本願に係る情報処理システムの他の一形態におけるトランザクションに係るデータ構造である。トランザクション内８０１とトランザクション外８０２に記憶される一例として、各項目が図示されている。

【0195】

図８では、アプリデータ及びトランザクションに係るデータとしては、図６に示したものと類似している。但し、債務に係る金額として、図６では、金額（原価通貨建て）であったが、図８では、金額（Ｓａｔｏｓｈｉ）となっている。これは、仮想通貨として各トランザクションに係る金額の通貨が統一されている。しかし、これでは、現実世界で行われる取引との関係性が不明のため、アプリテーブルとして、原通貨と仮想通貨の間の為替テーブルが用意される。当該テーブルに基づき、現実世界の取引が、仮想通貨に変換されて、情報が保持される。

【0196】

図８に示したデータ構造も、図６に示したデータ構造と同様に、ビットコインのソースコードを利用する場合に使用できる可能性がある。また、ビットコインのソースコードを利用する場合、ビットコインのサイドチェーンとなれる可能性もある。

【0197】

以上のトランザクションに係るデータ構造に示される具体的なＴデータにより、債務の情報が示される。但し、当該Ｔデータの存在が、現実の債務の有無を示すかどうかは、各国の法律に従うことはいうまでもない。本願発明の一実施例に係るＴデータは、債務が存在しているとしたときの処理を容易にするものである。

【0198】

また、当該システムは、ブロックチェーン類似の性質で、ナンス及びハッシュ値の計算を行うことから、仮に管理されたサーバであるとしても、それらのデータの保全性は高い。

【0199】

なお、データは債務であることから、当該データが存在する場合、送付者Ａは債務を負い、受取者Ｂは、Ａに対して債権を有しているが、Ａは、実際の商取引的な価値を有する金額は有していない。すなわち、債務である以上、債権を回収できない危険があり、かつ上記債務も法的に認められるかどうかは各国の法制度に依存する。

【0200】

３−２．トランザクションの記載方法
次に、図５乃至図８等の種々のトランザクションに係るデータ構造を、本明細書で参照する場合の記載方法を説明する。

【0201】

データ構造に係る情報であるＩＤ、送付者、受取者、金額などの情報を含む簡易的な記載法として、次のとおりとする。

【0202】

［ＩＤ：＊＊１、送付者：＊＊２、受取者：“（＊＊３、＊＊４、＊＊５）”＋、期日：＊＊６］

【0203】

上記において、「＊＊」で始まる文字列が、各具体的な情報が入力される位置を示す。「＊＊１」には、ＩＤが入る。「＊＊２」には、送付者が入る。「＊＊３」には、受取者が入る。「＊＊４」には、債務の額が入る。「＊＊５」には、債務額の通貨種別が入る。但し、「＊＊５」は省略される場合もある。「＊＊６」には、債務の期日が入る。

【0204】

また、「“”＋」は、二重引用符（“”）で囲まれたものが、一つ以上繰り返すことを示す。従って、“（＊＊、＊＊、＊＊）”＋は、「（＊＊、＊＊、＊＊）」を含んでもよいし、「（＊＊、＊＊、＊＊）、（＊＊、＊＊、＊＊）」を含んでもよい。

【0205】

例えば、ＩＤがＩＤ１、送付者がＡ、受取者がＢ、金額がＸ、通貨が円、期日がＤ１の場合のＴデータは、本件記載方法に基づくと、次のとおり記載される。

【0206】

［ＩＤ：ＩＤ１、送付者：Ａ、受取者：（Ｂ、Ｘ、円）、期日：Ｄ１］

【0207】

また、Ｔデータは、複数人を債権者として生成することも可能である。ＩＤがＩＤ２、送付者がＡ、円建ての金額Ｘ１がＢを債権者とし、円建ての金額Ｘ２はＣを債権者として、期日がＤ２の場合におけるＴデータは、本件記載方法に基づくと、次のとおり記載される。

【0208】

［ＩＤ：ＩＤ２、送付者：Ａ、受取者：（Ｂ、Ｘ１、円）（Ｃ、Ｘ２、円）、期日：Ｄ２］

【0209】

なお、ここでは、期日を一つのＤ２として記載した。しかし、複数人の債権者に対応して、複数の期日を設定してもよい。例えば、この場合は、Ｄ２Ｂ、Ｄ２Ｃなどと、受取者に対応して、複数の期日としてもよい。

【0210】

また、送付者名は、上述のとおり、送付者自身に係る情報に加えて、送付者を債権者とする情報も許容する。そのため、上述のＩＤ１を、下記で述べる流通をさせた場合は、次のとおりとなる。

【0211】

［ＩＤ：ＩＤ３、送付者：ＩＤ１、受取者：（Ｃ、Ｘ１、円）、期日：Ｄ３］

【0212】

送付者として、Ｂに送付されたＴデータのＩＤ１が参照され、Ｃに対してＴデータが生成されている。

【0213】

また、Ｔデータを流通させた場合も、複数人を債権者として生成してもよい。例えば、次のＴデータが可能である。

【0214】

［ＩＤ：ＩＤ４、送付者：ＩＤ３、受取者：（Ｄ、Ｘ１、円）、（Ｃ、Ｘ２、円）、期日：Ｄ４］

【0215】

ここでは、Ｃに流通されたＴデータＩＤ３を、Ｄに対するＴデータと、Ｃに対するＴデータと、の二つのＴデータを生成している。そして、送付者はＩＤ３の債権者であるＣであるから、Ｃは、Ｃ自身に向けてＸ２円のＴデータを生成している。

【0216】

３−４．トランザクションの安全性
トランザクションは、債務を示し、トランザクションの生成は、債務者が債務を負担することを意味するため、トランザクションの生成は、債務を負担する債務者のみが生成できるもの（債務を負担する債務者の指示のみに基づいて生成できるもの）である。すなわち、トランザクションは、債務者又はこれに類する者の指示に基づいた場合にのみ、生成される。ここで、債務者又はこれに類する者であることを判断するために、成りすまし防止の技術を用いてもよい。

【0217】

成りすまし防止技術は、公開鍵暗号方式を用いてもよい。すなわち、債務者は、公開鍵暗号方式における公開鍵と暗号鍵の二つの鍵を有し、公開鍵を公開し、暗号鍵を秘密に保持しているものとする。そして、債務者は、対象であるトランザクションを暗号鍵によって暗号化する。第三者は、公開鍵によって暗号鍵を復元することができるとき、当該公開鍵と対応する暗号鍵を保有する債務者が、当該暗号化を実現したことが分かる。これにより、債務者以外の者による成りすましを防止することができる。

【0218】

また、トランザクションは、上述のとおり、ハッシュ関数により、ハッシュかされた数値が、次のトランザクション内に保持される。かかるトランザクションは、時間の経過と共に増加する。そのため、トランザクションが改ざんされた場合は、当該ハッシュ値も変更することになるため、当該トランザクションの改ざんを隠蔽するものは、ハッシュ値も変更する必要がある。しかし、トランザクションは、一定時間ごとに増えていくことから、全てのトランザクションのハッシュ値を変更していくことの実現が難しくなる。他の実施例においては、トランザクションの増加は、一定の限られたサーバ等により作成されるとしても、かかるサーバを攻撃し、乗っ取るなどによって、当該トランザクション間の関係に齟齬のないよう作成しなければいけないため、

【0219】

上記では、現在のブロックチェーンの実装に基づき、公開鍵暗号方式を紹介したが、当該公開鍵暗号方式に代えて、他のシステムを用いてもよい。すなわち、ブロックチェーンにおいて使用されている、トランザクションの生成をする債務者又はこれに類する者が使用するための解除条件及び条件を解くスクリプトから構成されるロッキングシステムを用いてもよい。これによれば、公開鍵暗号方式以外の方式によっても、債務を生成する債務者の条件を特定することができる。

【0220】

３−５．ブロックチェーンアプリ（ＢＣアプリ）の機能例
ブロックチェーンのフローは、周知のブロックチェーンシステムと同じであるが、種々の実装手段も存在することから、本願発明の一実施例として、以下にブロックチェーンシステムを簡単に説明する。ここでは、ＢＣアプリの一部の一例を、図９を用いて以下で説明される。

【0221】

３−５−１．Ｔデータ構成手段９０２
Ｔデータ構成手段９０２は、Ｔデータを構成する機能を有する。例えば、Ｔデータ構成手段９０２は、Ｔデータに関する情報として、トランザクションＩＤ、タイムスタンプ、送付者名のＩＤ、受取者名のＩＤ、金額、通貨種別、期日、決済方法、などの情報を取得し、Ｔデータを構成することができる。当該情報は、ＢＣアプリ内の記憶部に記録される。当該情報は、データベース内に記録されてもよい。

【0222】

Ｔデータ構成手段９０２は、Ｔデータの構成に必要な情報を、ＢＣアプリの情報処理装置の入力部から得られた情報を取得してもよいし、ＢＣアプリ内の情報処理装置の記憶部に他の目的で格納された上記情報に基づき取得してもよい。さらに、Ｔデータ構成手段９０２は、Ｔデータの構成に必要な情報を、他の情報処理装置から取得してもよい。また、Ｔデータ構成手段９０２は、上記の組み合わせにより、Ｔデータの構成に必要な情報を構成してもよい。例えば、Ｔデータ構成手段９０２は、Ｔデータの構成に必要な情報の一部を、ＢＣアプリの情報処理装置の入力部から得てもよいし、Ｔデータの構成に必要な情報の他の一部を、ＢＣアプリ内の情報処理装置の記憶部に他の目的で格納された情報に基づき得てもよいし、又は、Ｔデータの構成に必要な情報の他の一部を、他の情報処理装置から取得してもよい。

【0223】

当該手段は、ＢＣアプリ内で実行されるが、管理者アプリ内で実行されてもよい。

【0224】

３−５−２．ブロック生成手段９０３
ブロック生成手段９０３は、ブロックを生成する機能を有する。ブロック生成手段９０３は、情報入力手段によって得られた情報に基づき、複数のトランザクションの情報を使用して、ブロックを生成する。ブロック生成手段９０３は、生成されたブロックを、ブロック確定手段９０４を有する他のＢＣアプリを有する情報処理装置に伝達してもよい。

【0225】

当該手段は、ＢＣアプリ内で実行されるが、管理者アプリ内で実行されてもよい。

【0226】

３−５−３．ブロック確定手段９０４
ブロック確定手段９０４は、生成されたブロックを確定する機能を有する。これは、ネットワーク上のＢＣアプリ内のブロック生成手段９０３がブロックを生成することができるため、生成された各ブロックの候補の中から、一意的に順序が定まっているブロックチェーンにおける次に連結されるべきブロックを確定するために、ブロック確定手段９０４が、ブロックの順番を決定する。

【0227】

ブロック確定手段９０４は、複数の候補の中から次に連結されるべきブロックを確定する手段であれば、どのような手段でもよい。
例えば、ＢＣアプリ又はＢＣアプリを実行する情報処理装置に優先順位をつけてもよいし、ネットワーク上に一つのトークンを発生させて、当該トークンを有しているＢＣアプリのブロックを優先させるという方法でもよい。また、演算部と記憶部が協働して、上述のナンスの値を変更し、記憶部に備えられたハッシュ関数を用いて規定の値になるまでハッシュ値を計算して、最初に規定の値のハッシュ値を見つけた情報処理装置のブロックを次のブロックと確定してもよい。
ブロック確定手段９０４が、ブロックを確定した後は、当該情報を他のＢＣアプリのブロック確定手段９０４に連絡してもよい。

【0228】

３−６．ブロックチェーン生成のフローチャートの例
本願発明の一実施例に係るブロックチェーンのフローチャートは、周知のブロックチェーンシステムと同じであるが、種々の実装手段も存在することから、本願発明の一実施例として、図１０を用いて、以下にブロックチェーンシステムのフローチャートを簡単に説明する。

【0229】

まず、ＳＴ１００１において、Ｔデータ構成手段９０２が、Ｔデータを構成する。

【0230】

ＳＴ１００２において、Ｔデータ構成手段９０２は、ブロック生成手段９０３に、当該情報を伝達する。

【0231】

ＳＴ１００３において、ブロック生成手段９０３は、ブロックを構成できる所定の個数のＴデータをＴデータ生成手段から取得した場合は、ブロックを構成する。

【0232】

ＳＴ１００４において、ブロック生成手段９０３は、ブロック確定手段９０４及び他のＢＣアプリのブロック確定手段９０４に、当該ブロックの情報を伝達する。

【0233】

ＳＴ１００５において、ブロック確定手段９０４は、所定の手段で、ブロックを確定する。

【0234】

ＳＴ１００６において、ブロック確定手段９０４は、他のＢＣアプリのブロック確定手段９０４に、当該確定されたブロックの情報を伝達する。

【0235】

３−７．ハードウェアの地理的特性
図１１は、上記で述べたＴデータとアプリデータのデータの地理的分布の一例を示す図である。図１１においては、情報処理装置１１０１の数が、情報処理装置１１０２の数に比べて多く描かれている。

【0236】

上述の本願発明の一実施例に係る種々のシステムとの関係を以下に述べる
本願発明の一実施例に係るクライアントサーバ型システムにおいて、情報処理装置１１０１が、クライアントに相当し、情報処理装置１１０２が、サーバに相当する。

【0237】

本願発明の一実施例に係るＰ２Ｐシステムにおいては、各ＰＣに大きな差はないものの、Ｐ２Ｐシステムにおいても、その一部の情報処理装置が管理機能を備えるよう構成することができるため、そのような場合は、情報処理装置１１０１が、Ｐ２Ｐの通常の端末に相当し、情報処理装置１１０２が、Ｐ２Ｐにおける管理機能を備える情報処理装置に相当する。

【0238】

本願発明の一実施例に係るクラウドシステムにおいて、情報処理装置１１０１が、クラウドを利用する端末に相当し、情報処理装置１１０２が、クラウド上の情報処理装置に相当する。
本願発明の一実施例に係る他のクラウドシステムにおいては、情報処理装置１１０１が、クラウド上の一の情報処理装置に相当し、情報処理装置１１０２が、クラウド上の他の情報処理装置に相当する。

【0239】

本願発明の一実施例に係るフォグコンピューティングシステムにおいて、情報処理装置１１０１が、フォグコンピューティングシステムを利用する端末に相当し、情報処理装置１１０２が、フォグコンピューティングシステム上の情報処理装置に相当する。

【0240】

要するに、情報処理装置１１０１が、本願発明の一実施例に係るシステムの利用者が利用する情報処理装置であり、情報処理装置１１０２が、本願発明の一実施例に係るシステムの管理者的立場に係る情報処理装置である。

【0241】

情報処理装置１１０１は、Ｔデータを有し、情報処理装置１１０２は、アプリデータを有する。
また、各情報処理装置１１０１が備えるＴデータは、完全に同じものでなくてもよい。例えば、各情報処理装置１１０１が備えるＴデータは、ブロックが作成される過程においてＴデータが同じでないという意味で、同じデータでない場合がある。但し、この意味では、過半数の情報処理装置１１０１は、同じＴデータを備えるものである。また、各情報処理装置１１０１が備えるＴデータは、ブロックチェーンの一部を省略などすることによって、同じＴデータを備えなくてもよい。

【0242】

情報処理装置１１０１はアプリデータを備えてもよい。但し、情報処理装置１１０１と情報処理装置１１０２は、アプリデータの管理方法に違いがあってもよい。例えば、情報処理装置１１０１の有するアプリデータは、情報処理装置１１０２の有するアプリデータよりも、コストのかからない方式で、管理されてもよい。

【0243】

情報処理装置１１０２が備えるアプリデータは、情報に対する信用性を向上する対策により、管理されてもよい。例えば、情報処理装置１１０２は、無提言電源装置を備え、停電時にアプリデータが失われないようにしてもよい。また、情報処理装置１１０２は、ミラーサーバなどのＲＡＩＤ技術、複数の異なる地域に設置するなどの方策が用いられて、アプリデータの保全を高めてもよい。さらに、アプリデータの改ざん防止の為に、ファイアウォールなどを設け、情報処理装置１１０２に対するアクセス制限を高めるなどの周知のセキュリティ対策を施してもよい。情報処理装置１１０２は、Ｔデータを有してもよい。

【0244】

図１１は、一例であるが、トランザクションに係るデータとアプリデータの特徴の一つを示す。すなわち、トランザクションに係るデータは、多数の情報処理装置により同じものが保持されている一方、アプリデータは、トランザクションに係るデータと比較すると少ない数の情報処理装置により保持されている。そのため、トランザクションに係るデータは、上述の信用性を向上する対策を取ることができるとしても、サーバの建物の破壊、地震、その他の破壊活動により、情報の信用性が低下する可能性は、アプリデータに比べると少ない。

【0245】

また、Ｔデータとアプリデータの情報の信用性が同一程度、あるいはアプリデータのほうが高いとしても、アプリデータの信用性向上には上述の対策が必要であることからコストが必要となるものであり、Ｔデータの情報記録方式では、かかるコストが低い利点がある。

【0246】

なお、元の取引を示すＩＤ、トランザクションＩＤの履歴、原債務者を示す情報は、他の手法によって収集できる情報でもある。具体的には、次のとおりである。
元の取引を示すＩＤは、要するにトランザクションの根拠となる取引を特定するものである。債務者、債権者、金額、期日及び時期が分かれば、取引を特定できる。また、その他の取引に関する内容が異なるのであれば、特記事項でデータを保有することができるから、これらの情報に基づき、特定することができるものである。

【0247】

また、トランザクションＩＤの履歴は、各トランザクションから、従前のトランザクションを実際に辿ることによって、特定することができる。
さらに、原債務者を示す情報は、各トランザクションから、実際に前のトランザクションを辿ることによって、こちらも特定することができる。

【0248】

トランザクションに係るデータとアプリデータの整理の方法は、他の方法であってもよい。これは、利用するソフトウェアの再利用の観点、又は他のシステムとの融合性などの観点などによって、トランザクションに係るデータとアプリデータをどのように分類してもよい。なお、アプリデータとして情報を保有すると、上述のとおり、データの損壊の可能性又は危険性があるが、上述のとおり他の情報に基づいて導出できる情報もあるし、あるいはそもそも情報の重要性が低いものとして扱うこともできる。

【0249】

４．債務の生成
本願発明の一実施例に係るシステムは、Ｔデータを任意に生成するようにしてもよい。Ｔデータは、債務に係る金額を、債権者に対して、支払うことに関するものであるから、債務者自身が資金を有する必要はない。特に、自己がコインを有している場合に限り他者に対してコインを提供できるビットコインと異なり、本願発明の一実施例に係るＴデータは、自己が何らの権利を有していない場合にも生成できる。
なお、自由にＴデータを生成できる利点は、以下の７章で述べるとおり、決済手段としての仕組みに多大な影響を与えるものである。

【0250】

また、本願発明の一実施例に係るＴデータは、他の者（本願発明の一実施例に係るシステムの管理者、金融機関、親会社、又はグループ会社など）の許可を得た上で、債務を生成するように構成してもよい。

【0251】

４−１．当事者によるトランザクションの生成
まず、当事者が、任意にトランザクションに係るデータを生成する場合を説明する。
例えば、ＩＤがＩＤ１、債務者がＡ、債権者がＢ、金額がＸ、通貨が円、期日がＤ１の場合のＴデータは、記載法によれば、次のとおり記載される。

【0252】

［ＩＤ：ＩＤ１、送付者：Ａ、受取者：（Ｂ、Ｘ、円）、期日：Ｄ１］

【0253】

この場合、後述する生成手段１２０５が適用されて、上記トランザクションに係るデータが生成される。本願明細書における「原債務者」とは、この場合は、債務者Ａである。
４−２．債務センターによるトランザクションの生成
債務センターが、任意にトランザクションに係るデータを生成する場合を説明する。
ここで、債務センターは、ＤＣ（Ｄｅｂｔ Ｃｅｎｔｅｒ）とする。例えば、ＩＤがＩＤ１、債務者がＡ、債権者がＢ、金額がＸ、通貨が円、期日がＤ１の場合におけるＴデータは、次のとおり記載される。

【0254】

［ＩＤ：ＩＤ１、送付者：ＤＣ、受取者：（Ａ、Ｘ、円）、期日：Ｄ１］
［ＩＤ：ＩＤ２、送付者：ＩＤ１、受取者：（Ｂ、Ｘ、円）、期日：Ｄ１］

【0255】

このとおり、債務センターが生成する場合は、まず債務者が、いわば債務センターに対する債権者のようにＴデータが生成され、当該債権が、実際の債権者であるＢに生成されるＴデータが生成されるというステップを取る。特にＩＤ２のＴデータにおいては、送付者が、ＩＤ１として、債務センターが生成したトランザクションを送付者としている（流通）していることを表示している。このトランザクションを送付者とする流通については、次に説明する。
ただし、債務センターが生成手段１２０５を適用して、トランザクションに係るデータを生成する場合においては、本願明細書の「原債務者」とは、債務者Ａを指し、債務センターは原債務者ではない。後述する流通手段１５０５は、債務センターから生成されたＴデータを流通する場合に限り、アプリデータ内のＴデータに関する原債務者の情報を、上記の債務者Ａに関する情報、すなわち、債務センターから生成されたＴデータを最初に流通する場合の債務者に関する情報、で設定する。

【0256】

４−３．Ｔデータ生成に関する機能例
Ｔデータ生成に関連する機能には、図１２に示すとおり、生成取得手段１２０２、生成通信手段１２０３、生成記録手段１２０４、生成手段１２０５がある。Ｔデータ生成に係るＢＣアプリは、これらの一部又は全てを有することができる。

【0257】

４−３−１．生成取得手段１２０２
生成取得手段１２０２は、情報を取得できる機能を有する。前記取得する情報としては、Ｔデータに関する情報、又はアプリデータに関する情報などが挙げられる。

【0258】

具体的には、生成取得手段１２０２は、債権者、債務者、債務に関連する日、債務の金額、通貨、その他の関連情報を取得できるようになっている。また、生成取得手段１２０２は、アプリデータとして、従前のＴデータに関する情報、例えばＴデータ内の情報、Ｔデータ間の関係の情報、Ｔデータに関連する契約に関する情報、システムに登録された当事者に関する情報などの情報を取得してもよい。

【0259】

かかる情報は、入力部を介して取得してもよいし、生成通信手段１２０３を介して、利用者アプリ、ＢＣアプリ、又は管理者アプリから取得してもよい。利用者アプリからは、利用者からの入力に基づいて取得する場合や、利用者アプリ内に記憶されている情報を取得できる場合があり、利用者から新しい情報を取得できる利点がある。他方、ＢＣアプリ又は管理者アプリから情報を取得する場合は、従前の情報を再利用し、利用者の負担を軽減できる利点がある。さらに、ＢＣアプリと管理者アプリの間の通信回路の速度が、利用者アプリとＢＣアプリ又は管理者アプリの間の通信回路の速度と比較して、高速な場合には、高速に情報を取得できる利点もある。

【0260】

取得した情報は、生成通信手段１２０３を介して、他のアプリに情報を伝達してもよい。例えば、生成取得手段１２０２がＢＣアプリ上で実行されている場合は、利用者アプリに情報を伝達してもよいし、管理者アプリに情報を伝達してもよい。かかる伝達により、当該利用者アプリ又は管理者アプリで次に関連する情報を使用する際に、通信量を減らしつつ、情報を利用できる利点がある。

【0261】

４−３−２．生成通信手段１２０３
生成通信手段１２０３は、他のアプリの通信手段と通信をする機能を有する。

【0262】

４−３−３．生成記録手段１２０４
生成記録手段１２０４は、Ｔデータ又はアプリデータを記録する機能を有する。

【0263】

４−３−４．生成手段１２０５
生成手段１２０５は、債務に係るＴデータを生成する手段を有する。３−５−１のＴデータ構成手段９０２に対応するものであるが、ここではより具体的に述べる。

【0264】

生成手段１２０５は、生成取得手段１２０２によって得られた債権者、債務者、債務に関連する日、債務の金額、通貨、その他の関連情報に基づいて、Ｔデータを作成する。作成されたＴデータは、生成記録手段１２０４により、記録される。
当該Ｔデータの設定は、Ｔデータ構造として、例えば図５乃至８で定められた各項目に合わせて、生成取得手段１２０２により取得された情報が設定される。

【0265】

まず、トランザクションＩＤとして、一意的なＩＤを設定する。一意的なＩＤの設定方法は、周知な手法でもよい。

【0266】

タイムスタンプとして、Ｔデータが生成された日時が設定される。当該タイムスタンプは、他のサーバなどと連携して設定されてよい。タイムスタンプの生成は、周知な方法でよい。

【0267】

送付者名として、債務者の情報が設定される。債務者の情報は、債務者を示す情報として、アプリデータとして事前に設定された債務者のＩＤ、債務者を示す公開鍵、債務者を示す公開鍵をハッシュ関数で加工した情報などを用いる。債務者の情報は、以下で述べるマスター登録により、既に登録済み情報を用いてもよい。

【0268】

受取者名として、債権者の情報が設定される。債権者の情報も債務者の情報と同様である。当該受取者名は、複数であってもよい。これは、Ｔデータが流通されるときに生成される新しいＴデータに複数の受取者が設定される場合だけでなく、Ｔデータが最初に生成される場合に複数の受取者が設定されてもよいし、更改の場合に生成されるＴデータに複数の受取者が設定されてもよい。この場合、以下の設定される金額の数も、受取者名と同じ数となる。なお、通貨種別、又は期日について、同じ数が設定されてもよい。

【0269】

金額として、債務の金額が設定される。なお、通貨を変更されてもよい。通貨の変更の可否又はその変更方法は、アプリデータに記録されてもよい。通貨を変更する場合は、他のサーバと連携して、変更後の通貨における金額が設定されてもよい。通貨額を変更する場合における通貨レートは、当事者が事前に決定されたレートでもよいし、当事者が事前に決定した通貨レート日時の指定方法に沿って決定してもよい。当事者間において、このような特殊な取り決めが存在する場合は、かかる取り決めに基づく計算方法が、アプリデータとして、記憶部に記憶され、かかる記憶部の計算に基づき、特定の通貨の額に設定される。

【0270】

通貨種別として、通貨が設定される。上記の当事者の取り決め等により、通貨が変更し、債務の金額が変更した場合は、変更後の債務の金額の通貨が設定される。

【0271】

その他、当該債務の発生に関する特記事項があれば、関連事項として設定される。

【0272】

新規のＴデータの生成又は更改における新規なＴデータの生成の場合、生成手段１２０５は、生成通信手段１２０３を用いて、上記情報の一部又は全部を、管理者アプリに伝達し、管理者アプリに当該情報を記録させてもよい。

【0273】

一例としては、図１３にあるように、原取引のＩＤ、通貨種別、原債務者、決済予定日又は予定される決済方法などのレコードの一部又は全部が、アプリデータ内に設定されてもよい。なお、他のレコードの形式としては、図５乃至図８で述べた形式でもよい。すなわち、Ｔデータの具体的な中身であるトランザクションＩＤ、タイムスタンプ、送付者名、受取者名、金額、通貨種別、期日、決済方法、特記事項が、Ｔデータに関連するデータとして、アプリデータに設定されていてもよい。

【0274】

また、ＴデータＩＤも、当該情報と関連付けて設定されていてもよい。これにより、ＴデータとＴデータに関連する契約の情報が、アプリデータを介して、検索できるようになる。また、各Ｔデータの原債務者も設定された場合、以下で述べるＴデータの流通が生じた場合も、Ｔデータの原債務者を、ブロックチェーン内のＴデータの履歴を辿る必要なく、判明する。

【0275】

決済予定日、又は、予定される決済方法は、図１３においては不変と記載されているが、これは一例に過ぎず、当事者の設定、又は関係する当事者の同意により、変更されてもよい。

【0276】

なお、図１３において、（トランザクションごとに書き換え）とある箇所は、その履歴の情報が保有されていてもよい。これによって、過去の履歴が必要になる場合には、調べることも可能となる。

【0277】

本願明細書では、Ｔデータを上記で述べた記載方法に基づいて記載しているが、当該記載方法で説明されるＴデータは、生成手段１２０５で生成できる。

【0278】

上述の生成手段１２０５は、債務を示すＴデータを容易に生成し、ひいては債務取引活動の円滑化を促進できるコンピュータシステムをサポートするデータ構造である。そして、上記データ構造を用いた方法、端末、サーバ、情報処理装置、又はシステムは、かかる債務取引活動の円滑化を技術的に促進しえるものである。

【0279】

４−３−５．生成関連機能を実行する情報処理装置
Ｔデータの生成に関連する機能は、上述ではＢＣアプリ内にあるものとして説明したが、アプリケーションアーキテクチャーに応じて、管理者アプリ又は利用者アプリ内に設定されてもよい。例えば、生成取得手段１２０２は、利用者の入力、アプリデータ、又は管理者アプリから情報を取得するため、その一部の機能が、利用者アプリ又は管理者アプリにあってもよい。生成手段１２０５を指示する機能としての一部が管理者アプリ又は利用者アプリにあってもよい。また、Ｔデータを記録する生成記録手段１２０４は、ＢＣアプリ内にあるが、アプリデータを記録する生成記録手段１２０４は、ＢＣアプリ又は管理者アプリに存在してもよい。管理者アプリがアプリデータを記録する場合は、３−４で述べた改ざん防止などのためのセキュリティ対策が取られてもよい。

【0280】

４−４．Ｔデータ生成のフロー例
ＳＴ１４０１において、生成取得手段１２０２は、Ｔデータに関する情報を取得する。

【0281】

ＳＴ１４０２において、Ｔデータ生成手段１２０５は、生成取得手段１２０２又はＢＣアプリから得たＴデータの情報に基づき、Ｔデータを生成する。ここで、ＢＣアプリから得る情報としては、トランザクションＩＤ、タイムスタンプの情報、通貨の情報などが挙げられる。

【0282】

ＳＴ１４０３において、生成通信手段１２０３は、Ｔデータ生成に伴う情報を、管理者アプリ又は利用者アプリに伝達する。なお、Ｔデータ生成に伴う情報として、例えばアプリデータとなる情報は、確定手段９０４によりブロックが確定し後に、アプリデータが確定するよう処理されても良い。これは、ブロックが確定するまでは、トランザクションは未定であり、対応するＴデータ生成に伴う情報であるアプリデータを構成することとなる情報も未定であるためである。そこで、例えば、Ｔデータ生成に伴う情報は、管理者アプリ又は利用者アプリに伝達された後、そこで保持され、確定手段９０４によってブロックが確定された情報が同様に管理者アプリ又は利用者アプリに伝達された後、当該情報がアプリデータとして確定するよう処理してもよい。以下においても、アプリデータ又はアプリデータとなる情報は、拡大手段９０４によってブロックが確定された後に、アプリデータとして確定するよう処理してよい。

【0283】

５．債務の流通
５−１．債務の流通の趣旨
複数の当事者が債権債務関係を有する場合、例えば、次のようなケースが考えられる。当事者であるＡ、Ｂ、Ｃにおいて、ＡがＢに債務Ｘを負うとする。この段階で、本願発明に関わる一実施例を用いると、当該債務について、トランザクションに係るデータＩＤ１が生成されている。
（［ＩＤ：ＩＤ１、送付者：Ａ、受取者：（Ｂ、Ｘ）］）。

【0284】

その後、ＣがＢに債務Ｘを負うかどうかが問題になっているとする。このとき、本願に係る情報処理システムの一形態を用いて、ＢがＣに対して負う債務Ｘを示す新規のトランザクションに係るデータを生成してもよい。

【0285】

［ＩＤ：ＩＤ２、送付者：Ｂ、受取者：（Ｃ、Ｘ）］。

【0286】

しかし、このＩＤ２は、ＩＤ１とは全く無関係の債務となる。仮に、Ｂと比べて、Ａの方に資金力があり、破産する可能性が極めて低い場合、Ｃとしては、Ｂよりも、Ａに対して債権を有したいと考える。このとき、Ｃが、Ｂに対してではなく、Ａに対して債権を有することを示すトランザクションに係るデータとして、既に作成されたトランザクションに係るデータＩＤ１を活用した債務の流通を次に示す。この場合、ＡＢ間の債務においてＢはＡの債務を免除し、ＡがＢのＣに対する債務を引き受けると考えて、次のとおり、ＡＣ間で債務関係を生じたことを示すＴデータが生成されることとする。

【0287】

［ＩＤ：ＩＤ２’、送付者：ＩＤ１、受取者：（Ｃ、Ｘ）］

【0288】

このとおり、送付者は、Ｂではない。ＢＣ間において、Ｃは、Ｂに対する債務がないためである。代わりに、Ａが債務を引き受けており、これを前の取引データであるＩＤ１を用いることから、送付者という当事者を示すデータ構造ではあっても、当事者に代えて、Ｔデータが示されている。上記のデータ構造を用いることで、Ｃは、Ｂよりも資金力のあるＡに対する債権を有することができるから、より取引が活発になるという利点がある。
すなわち、本願発明の一実施例に係るシステムにおける流通に関連する機能は、債務の取引を促進するという技術的効果を有する。

【0289】

なお、仮に、ＢよりもＡに資金力がなく、あえて、ＣがＡに対して債権を有する必要はなくて、ＣがＢに対して債権を有すれば十分の場合は、ＣはＢに対する債権を有することを示すデータとして、Ｂは、単に、新たなトランザクションに係るデータを生成すればよい。
すなわち、本願発明の一実施例に係るシステムにおける流通に関連する機能の使用有無の選択肢を提供する機能により、関連する当事者の状況を考慮した上などで、債務の取引を促進するという技術的効果を有する。

【0290】

上述の方法によって、ＢがＡの債務を免除し、ＡがＣの債務を引き受けて、上記ＩＤ２’のように、ＩＤ１の情報を参照することを、本願書類では、ＩＤ１の債務（又はＩＤ１のＴデータ）が「流通する」との表現を使うこととする。

【0291】

また、上述の債務の流通は、金額が一致しない場合も考えられる。すなわち、自己が負う予定の債務の金額以上の金額について、流通可能な債務の債権者となっている場合において、当該債務の一部を流通させることも可能である。このように債務の一部を分けて扱うことを、分割という。具体的には、次のようになる。

【0292】

［ＩＤ：ＩＤ１、送付者：Ａ、受取者：（Ｂ、１００）］
［ＩＤ：ＩＤ２、送付者：ＩＤ１、受取者：（Ｃ、３０）］
［ＩＤ：ＩＤ３、送付者：ＩＤ１、受取者：（Ｂ、７０）］

【0293】

ＩＤ１では、Ａが、Ｂに対して、債務１００の金額で、Ｔデータを生成している。ＩＤ２
において、Ｂが、Ｃに対して、債務３０の金額で、ＩＤ１を流通させている。ＩＤ３では、債務１００の金額のうち、流通に使用された債務３０の金額の残りの債務７０の金額に対して、自己であるＢに対して、Ｔデータを生成している。

【0294】

すなわち、本願発明の一実施例に係るシステムにおける２人以上の債権者（受取者）を許容するデータ構造は、流通される債務の金額と、受取者の金額が一致しない場合にも流通を可能とさせ、債務取引活動を広く円滑化することを促進するという技術的効果を有する。

【0295】

以上見たとおり、上述の債務を流通できるようにするデータ構造は、上記におけるＣが、資金力のあるＡに対して、より積極的に債権を有することを促進し、ひいては債務取引活動の円滑化を促進できるコンピュータシステムをサポートするデータ構造である。
同様に、上記データ構造を用いた方法、端末、サーバ、情報処理装置、又はシステムは、かかる債務取引活動の円滑化を技術的に促進しえるものである。

【0296】

また、上記データ構造は、上述の債務生成において、送付者を示すデータに代えて、送付者が債権者として有するＴデータとして整合させ、債務の生成と債務の流通を共通のデータ構造により統一したシステムとして実現できるという技術的効果を有する。

【0297】

５−２．債務の流通の機能例
Ｔデータの流通に関連する機能には、図１５のとおり、流通原債務者確認手段１５０１、流通アプリデータ作成手段１５０２、流通生成手段１５０３、流通取得手段１５０４、流通手段１５０５、流通通信手段１５０６がある。流通生成手段１５０３、流通取得手段１５０４、流通通信手段１５０６は、それぞれ、生成手段１２０５、生成取得手段１２０２、生成通信手段１２０３で述べた類似の機能、すなわち、それぞれ、Ｔデータの生成機能、Ｔデータに関する情報の取得機能、他のアプリと情報を通信する機能を有する。

【0298】

５−２−１．流通原債務者確認手段１５０１
流通原債務者確認手段１５０１は、Ｔデータを流通させる場合に、Ｔデータの流通の可否を、確認する機能を持つ。

【0299】

ＢＣアプリ内の流通原債務者確認手段１５０１は、Ｔデータの流通の可否を、利用者アプリに直接問い合わせてもよいし、管理者アプリを介して利用者アプリに問い合わせてもよい。当該問い合わせるときに、流通原債務者確認手段１５０１は、Ｔデータに関連する契約の情報を、利用者アプリに伝達してもよい。
ＢＣアプリが原債務者の情報を保有していれば、当該情報に基づき、流通原債務者確認手段１５０１が、当該原債務者の利用者アプリに対して、直接問い合わせる方式は、手続きが簡易である利点がある。

【0300】

他方、ＢＣアプリが原債務者の情報を保有していない場合、流通原債務者確認手段１５０１は、利用者アプリのアプリデータに問い合わせて、原債務者の情報を取得し、それに基づき、原債務者の利用者アプリに問い合わせてもよい。当該問い合わせるときに、流通原債務者確認手段１５０１は、Ｔデータに関連する契約の情報を、管理者アプリに伝達してもよい。

【0301】

また、ＢＣアプリが原債務者の情報を保有していない場合、流通原債務者確認手段１５０１は、管理者アプリのアプリデータに問い合わせ、管理者アプリが、原債務者の利用者アプリに問い合わせてもよい。当該問い合わせるときにも、流通原債務者確認手段１５０１は、Ｔデータに関連する契約の情報を、管理者アプリに伝達してもよい。そして、管理者アプリが、利用者アプリに問い合わせるときに、Ｔデータに関連する契約の情報を、利用者アプリに伝達してもよい。

【0302】

上述では、ＢＣアプリ内に流通原債務者確認手段１５０１があるものとして説明したが、当該手段が、管理者アプリ内にある場合も同様な問い合わせにより、原債務者を確定することができる。
得に、管理者アプリが有するアプリデータに原債務者の情報がある場合は、流通原債務者確認手段１５０１は、当該アプリデータに基づき原債務者を特定し、原債務者に問い合わせてよい。

【0303】

問い合わされた原債務者の利用者アプリは、利用者に対して、Ｔデータの流通の可否を問う。このとき、Ｔデータに関連する契約の情報を、利用者アプリは、表示手段を介して表示してもよい。

【0304】

また、Ｔデータ流通可否について、事前に判断された可否の情報を確認する形式でもよい。当該事前に判断された可否の情報は、利用者アプリ、ＢＣアプリ又は管理者アプリが保有していてもよい。当該情報は、事前に、利用者アプリが、ＢＣアプリ又は管理者アプリに伝達しておく。流通原債務者確認手段１５０１が、この情報を確認するよう構成してもよい。
上述の流通原債務者確認手段１５０１は、流通されるＴデータについて、原債務者の確認取得をサポートし、債務取引活動の円滑化を促進できる効果を有する。

【0305】

５−２−２．流通アプリデータ作成手段１５０２
流通アプリデータ作成手段１５０２は、Ｔデータの流通に伴うアプリデータを作成する機能を有する。

【0306】

Ｔデータの流通に伴うアプリデータとは、例えば、Ｔデータの流通に関する原債務者の了解の有無、従前のＴデータと新たに生成されるＴデータの関係性、などの情報である。

【0307】

流通アプリデータ作成手段１５０２は、Ｔデータの流通に伴う情報を、取得手段を介して、取得する。

【0308】

流通アプリデータ作成手段１５０２は、Ｔデータの流通に伴う情報に基づき、Ｔデータの流通を許可する原債務者の情報、債務が免除される債務者の情報、当該Ｔデータの情報を関連付けた情報、の一部又は全部を作成してもよい。例えば、図１６は、新Ｔデータ１６００、元Ｔデータ（流通される対象となるＴデータ）１６０１、債務が免除される債務者の情報１６０２、原債務者１６０３、当該Ｔデータに関連する契約の情報１６０４のテーブルである。原債務者１６０３は、元Ｔデータにおける原債務者の情報に基づき、設定される。これにより、新Ｔデータが、その後、流通される場合も、原債務者情報が判明する。これにより、各Ｔデータに対して、原債務者の情報が記録テーブルに記載されることとなる。免除債務者１６０２は、流通されるＴデータの債務者であるから、新Ｔデータと元ＴデータでＴデータの履歴を辿る際の免除債務者を列挙すると、Ｔデータの流通する際の債務者が判明する。なお、債務センターで生成されたＴデータが、流通手段１５０５により流通した場合、原債務者は、上述したとおり、債務センターから最初に流通させた債務者であり、この場合、免除債務者１６０２は、空欄としても、債務センターを特定する情報を設定しても、いずれでもよい。なお、当該契約の情報は、より詳細に記載されていてもよい。

【0309】

また、当該流通アプリデータ作成手段１５０２は、当該Ｔデータに係る債務が終了した際に、当該債務の終了に係る情報１６０５が記載されてもよい。

【0310】

また、流通アプリデータ作成手段１５０２は、Ｔデータの流通に伴う情報に基づき、従前のＴデータの情報と新たに生成されるＴデータの情報を関連付けた情報を作成してもよい。例えば、新たに生成されるＴデータの履歴として、従前のＴデータのＩＤを作成してもよい。このときに、従前のＴデータが流通されていれば、当該従前のＴデータに係る履歴を、新たに生成されるＴデータの履歴として、付加してもよい。例えば、図１７は、従前のＴデータＩＤの履歴の記録１７０１の例である。なお、図においては、履歴の最大値が、例として６４が挙げられているが、リスト又は他のデータ構造形式を取ることにより、Ｔデータが任意の回数流通できるように設定してもよい。

【0311】

流通されるＴデータと流通時に生成されるＴデータを関連付けるアプリデータは、上記迅速な流通をサポートし、債務取引活動の円滑化を促進できる効果を有する。

【0312】

流通アプリデータ作成手段１５０２は、管理者アプリ内に存在する場合、管理者アプリ内にアプリデータを容易に作成できる利点がある。他方、流通アプリデータ作成手段１５０２が、ＢＣアプリ内に存在する場合、流通手段１５０５がＢＣアプリ内にあることから、ＢＣアプリとの連携が容易である利点がある。

【0313】

５−２−３．流通手段１５０５
流通手段１５０５は、Ｔデータを流通しつつ、上述の各手段を、必要に応じて使用し、コントロールする機能を有する。

【0314】

流通手段１５０５は、流通取得手段１５０４に基づき、流通させる対象となるＴデータの情報、流通において生成するＴデータの情報を取得する。

【0315】

流通手段１５０５は、原債務者確認手段を用いて、原債務者の確認を行ってもよい。ただし、原債務者の確認が不要であれば、当該手段を使用しなくてもよい。この場合、原債務者の確認の要否は、管理者データのアプリデータに基づき、流通手段１５０５が判断するようにしてもよい。

【0316】

流通手段１５０５は、流通生成手段１５０３を用いて、新しいＴデータを生成する。
新しいＴデータは、流通後の、原債務者と債権者の間の情報が、当該Ｔデータに設定される。具体的に設定される情報は、生成手段で述べたことと同様に、Ｔデータ構造に応じて、対応した情報が設定される。
ただし、流通においては、新しいＴデータの送付者名として、流通されるＴデータの情報が設定される。例えば、流通されるＴデータの債権者に関する情報の一部が、新しいＴデータの送付者名として設定される。また、流通されるＴデータのＩＤ、当該Ｔデータを特定する情報、当該Ｔデータの一部、又は流通されるＴデータの債権者に関する情報が、新しいＴデータの送付者名として、設定されてもよい。

【0317】

他方、アプリデータの作成は、新規なＴデータの生成と異なる。例えば、Ｔデータとアプリデータが図１３の場合は、アプリデータとして設定されている原債務者、通貨種別、決済予定日、予定される決済方法を変更しない。
但し、原取引のＩＤは、流通に係る契約が存在しうるため、流通に係る契約の情報で、アップデートしてもよい。これにより、Ｔデータの情報から、流通に係る契約の情報にアクセスが容易となる。

【0318】

なお、分割の場合において、流通生成手段１５０３は、債権者（受取者）として、分割する数である複数の当事者の情報を、各複数の当事者に対する金額と共に、Ｔデータに設定する。
例えば、図１８は、２分割の例である。分割に伴い、Ｔデータに関するアプリデータがコピーされている。

【0319】

流通手段１５０５は、流通アプリデータ作成手段１５０２を用いて、Ｔデータ生成時のアプリデータとは異なるアプリデータを作成してもよい。
なお、分割の場合において、流通アプリデータ作成手段１５０２は、分割の数分、アプリデータを複製してもよい。例えば、図１８は、２分割の例である。分割に伴い、ＴデータのＩＤの履歴がコピーされている。

【0320】

５−２−４．流通関連機能を実行する情報処理装置
流通に関連する機能は、Ｔデータに関連の深い機能と、アプリデータに関連の深い機能、また利用者に関連の深い機能がある。そのため、当該機能がＢＣアプリと同じ情報処理装置に存在した場合、生成手段１２０５を有するＢＣアプリと高速に情報交換可能な利点がある。当該機能がアプリデータの存在する管理者アプリと同じ情報処理装置に存在する場合、アプリデータと高速に情報交換が可能な利点がある。当該機能が、利用者と直接情報交換を行う利用者アプリにある場合、利用者から新しい情報を取得する又は利用者から取得して保持された情報を利用できる利点がある。

【0321】

なお、上記利点がないとしても、当該機能は、ＢＣアプリと同じ情報処理装置内に存在してもよいし、管理者アプリと同じ情報処理装置内に存在してもよいし、利用者アプリと同じ情報処理装置内に存在してもよい。

【0322】

５−３．債務の流通のフロー例
債務の流通のフローを、図１９を参照して、次に説明する。以下では、利用者アプリ内のＴデータ流通確認手段が、管理者アプリ内のアプリデータに基づき、利用者アプリに問い合わせた手続きを、一例として、説明する。

【0323】

ＳＴ１９０１において、流通手段１５０５が、取得手段を介して、債務の流通について「はい」との情報、及び新たに生成するＴデータに関する情報（債権者、支払い日、通貨、金額、又はその他関連情報など）を取得し、これを流通原債務者確認手段１５０１に伝達する。

【0324】

ＳＴ１９０２において、流通原債務者確認手段１５０１が、少なくとも当該契約に関する情報（債権者、支払い日、通貨、金額、その他関連事項）の情報と共に、管理者アプリに、当該Ｔデータの原債務者の情報を問い合わせる。

【0325】

ＳＴ１９０３において、管理者アプリは、当該Ｔデータの原債務者情報を、記憶部のアプリデータに基づき、特定し、利用者アプリに回答する。

【0326】

ＳＴ１９０４において、流通原債務者確認手段１５０１は、少なくとも当該契約に関する情報（債権者、支払い日、通貨、金額又はその他関連事項など）の情報と共に、原債務者の利用者アプリに問い合わせる。

【0327】

ＳＴ１９０５において、原債務者の利用者アプリは、Ｔデータの流通の可否を確認する。当該確認は、表示画面によって、利用者に確認してもよい。また、このとき、利用者アプリは、当該契約に関する情報を、原債務者の表示手段に表示させてもよい。

【0328】

ＳＴ１９０６において、利用者アプリが、原債務者の利用者アプリから、Ｔデータの流通が不可である情報を取得すると、流通手段１５０５は、１つのＴデータの生成であるか、複数のＴデータの生成であるか判断する。

【0329】

一つのＴデータの生成であれば、利用者アプリは、生成手段１２０５を用いて、Ｔデータを生成する。複数のＴデータの生成であれば、利用者アプリは、生成手段１２０５を複数回用いて、複数のＴデータを生成してもよい。

【0330】

なお、利用者アプリが、原債務者の利用者アプリから、Ｔデータの流通が不可である情報を取得すると、利用者アプリは、表示手段を介して、利用者に、原債務者がＴデータの流通が許可されなかったことを表示してもよい。

【0331】

ＳＴ１９０７において、流通許可情報が「了承する」の場合は、利用者アプリは、表示手段を介して、Ｔデータが生成されたこと又は当該Ｔデータの生成に係る情報を表示してもよい。

【0332】

６．債務の終了
債務には、期限があるものと期限がないものがあるが、商取引上で用いられる債務は、一般的には、契約時などに期限を特定し、当該期限の到来によって、債務が履行される。

【0333】

本願発明に関わる一実施例におけるＴデータが期日に関するデータ構造を有している場合は、Ｔデータと期日との関係の処理が可能である。
債務の終了時には、１）更改（債務の生成）、２）銀行振り込みの処理、３）債権の放棄の選択肢がある。
ここで、更改とは、従前のＴデータに代えて、新たなＴデータを生成することである。

【0334】

銀行振り込みの処理とは、現実に、銀行処理として、債権債務関係を解消させ、かつ新しい債権の発生がない場合である。
また、諸事情により、債権の放棄とすることもよい。

【0335】

上記の組み合わせを実施してもよい。具体的には、債務額の一部に対して、銀行振り込み処理を実施し、残りに対して債権債務関係を発生させることとしてもよい。また、債権債務関係は、複数の債権債務を発生させてもよい。これは、異なる期限を設定する複数の債権債務を発生させる場合等が考えられる。

【0336】

６−１．債務の終了に係る機能の例
債務の終了に係る機能は、図２０に示すとおり、相殺手段２００１、更改手段２００２、支払い準備手段２００３、通信手段がある。通信手段は、他の通信手段と通信する機能を有し、上述と同様の機能を有する。

【0337】

６−１−１．相殺手段２００１
相殺手段２００１は、二つのＴデータの債務の金額を変更させる機能である。２つのＴデータは、当該Ｔデータに係る債権者及び債務者の数の合計が２であればよい。同じ法人かつ同じ拠点又は支店であれば、１と数えてもよい。同じ法人であるが、拠点又は支店が異なる場合、これを１と数えるかどうかは、当事者が決定してもよい。２つのＴデータに係る債務の金額は、同一である必要はない。

【0338】

あるＴデータと他のＴデータが、債権者と債務者が逆であり、金額が同一であれば、双方のＴデータが消滅しうる。当該Ｔデータは、いずれも廃棄手段２００４により廃棄されてもよい。

【0339】

あるＴデータの金額が、他のＴデータの金額よりも高い場合、当該他のＴデータの金額を控除した当該あるＴデータの金額（差額の債務）については、通常の債務の消滅手段を用いてよい。すなわち、当該差額の債務に対して、更改手段２００２が適用されてもよいし、又は支払い準備手段２００３が適用されてもよい。なお、複数の当事者が係る相殺については、後述する。

【0340】

図２１は相殺の場合のステップを示す一例に係る図である。まず、図２１における当事者は、ＸとＹであり、２当事者のため、相殺が可能である。ＸとＹの間の矢印は、債務を示し、矢印の元が債務者、矢印の先が債権者、矢印に付記された数が債務額である。すなわち、矢印は、その矢印に付記された数の金額を支払う必要があることを意味する。数字の正は、債務額を示す。例えば、２１０１のＸとＹの間では、複数の債務（３、１０、―４、１０）がある。４を負としているのは、３及び１０の債務においてＸが債務者であるのに対して、４の債務においてはＸが債権者であり、債務者と債権者が、他の債務と逆であるためである。また、これらの債務は、期限なし債務とするが、期限がある債務としても同様に考えることができる。本願における以降の類似の図面においては、上記のルールが適用される。

【0341】

これらを合算すると、２１０３にあるとおり、１９となる。当該１９は、２１０２にあるとおり、銀行において支払い処理してもよいし、２１０４にあるように流動性賃借の記帳をしてもよい。また、更改手段２００２が適用されてり、Ｔデータが生成されてもよい。

【0342】

なお、上記では、ＸとＹの間の全ての債務について計算しているが、一部の計算でもよい。これは、債務の状況に応じて、相殺すべき場合と相殺すべきでない場合があるためである。
なお、本願明細書における統括会社とは、企業の親会社、地域拠点子会社、企業グループ内のインハウス銀行、銀行、銀行子会社、投資会社、郵便局、金融機関などを示す。

【0343】

Ｔデータの金額が仮想通貨、例えばｓａｔｏｓｈｉ、で記録されている場合、金額が共通であることから各金額の数の差額を計算することでよい。これは、原取引が、他の通貨である場合も、Ｔデータの入力時点で、共通の通貨にすることの利点の一つである。差額分は、金額を受け取る側の指定通貨としてもよいし、支払う側と受け取る側の両者で同意に至った通貨で支払うこととしてもよい。

【0344】

相殺手段２００１が２当事者間の複数の多数の債務に対して適用されて金額を減らした場合、債務に関するデータ処理量を減少させる技術的意義がある。また、高額の手数料が必要な高額な債務に対して相殺手段２００１が適用された場合、金額が減少することで、手数料を減少させる利点がある。これは、手数料なく関連会社間において金銭取引が可能であることを意味する。

【0345】

６−１−２．更改手段２００２
更改手段２００２は、従前のＴデータと新たなＴデータの情報に基づき、新たなＴデータを生成する。新たなＴデータを生成する際は、生成手段１２０５を用いてもよい。従前のＴデータの情報は、従前のＴデータを特定する情報に基づいて取得できる。例えば、ＴデータＩＤやＴデータに関する契約を特定する情報が挙げられる。

【0346】

当該情報は、利用者アプリから取得してもよいし、ＢＣアプリ自体から取得してもよいし、管理者アプリから取得してもよい。
また、新たなＴデータの情報は、新たに取得したＴデータの情報でもよいし、Ｔデータの構成要素のうち、従前のＴデータと比較して異なる部分のデータに基づき、新たなＴデータの情報を構成してもよい。

【0347】

更改手段２００２は、新たなＴデータの情報に基づき、又は新たなＴデータの情報では欠けた情報を従前のＴデータの情報に基づき、生成取得手段１２０２、生成手段１２０５を用いて、新たなＴデータを生成する。当該従前のＴデータの情報、当該新たなＴデータの情報は、具体的には、Ｔデータを生成するのであるから、生成手段１２０５に関して述べた情報の一部又は全部である。

【0348】

また、更改手段２００２は、複数の既存の債務を示すＴデータを対象として、新たな一つ又は複数のＴデータを生成してもよい。例えば、複数の既存の債務として、債務金額が、３０、５０、７０（通貨種別を省略した）であって、いずれも、債務者Ａから債権者Ｂに対するＴデータであるとする。この場合、生成手段１２０５は、債務者Ａから債権者Ｂへの債務を示すＴデータであって、債務金額が１５０のＴデータを生成する。当該複数の債務は、当事者が同一でもよいし、異なってもよい。また、債務の期限は、同一であっても、異なってもよい。生成されるＴデータは、一つであってもよいし、複数であってもよいし。一つである場合は、上述の例のとおり、更改手段２００２内において、生成手段１２０５が一回適用される。複数のＴデータが生成される場合は、更改手段２００２内において、生成手段１２０５が複数回適用される。この場合は、複数の生成されるＴデータ分の債務者、債権者、債務金額などの情報は必要であるが、これは、生成手段１２０５が複数回適用されるのに対応して、生成取得手段１２０２が複数回適用されてもよいし、又は複数のＴデータを生成する分の情報を取得可能な生成取得手段１２０２が１回適用されてもよい。

【0349】

また、更改手段２００２は、新たに生成したＴデータ又は従前のＴデータと新たに生成されたＴデータの関係に関する情報を、生成通信手段１２０３を介して、管理者アプリ又は利用者アプリに伝達してもよい。例えば、図２２は、更改前のＴデータと更改後のＴデータの関連付けを示すテーブルの一例である。当該テーブルにより、更改前のＴデータのＩＤがＩＤＡであるものが、更改後のＴデータのＩＤがＩＤＸと関係付けられていることが分かる。また、当該テーブルにより、更改前のＴデータのＩＤがＩＤＢであるものが、更改後のＴデータのＩＤがＩＤＹと関係付けられていることが分かる。なお、上記のテーブルでは、更改前のＴデータと更改後のＴデータが、一対一の関係のテーブルの例を示したが、これに限られない。例えば、更改前の複数のＴデータに対して、更改後の１つの新たなＴデータを対応させる、一対多の関係のテーブルでもよいし、更改前の一つのＴデータに対して、更改後の複数の新たなＴデータを対応させる多対一の関係のテーブルでもよいし、更改前の複数のＴデータに対して、更改後の複数の新たなＴデータを対応させる多対多の関係のテーブルでもよい。要するに、対象とされた更改前のＴデータと、新たに作成された更改後のＴデータとを、関連付けるデータであればよい。当該データは、一般的には管理者アプリに記録されているが、ＢＣアプリ又は利用者アプリに記録されていてもよい。

【0350】

更改手段２００２は、期限が到来した多数の債務に対して適用された場合、複数の債務を纏めることが可能であり、債務に係るＴデータを減少できる利点がある。すなわち、システムに係る当事者のＴデータに関する管理負担が減少できる利点がある。また、当該債務の支払いに金融機関で手数料が必要な場合、期限が到来した債務であるＴデータに対して更改手段２００２を適用することで、新たなＴデータを生成させ、当該手数料の支払が不要となる利点がある。

【0351】

６−１−３．支払い準備手段２００３
支払い準備手段２００３は、支払いのための準備を行う機能を有する。例えば、支払い準備手段２００３は、Ｔデータに関連する契約の情報に基づいて、当該契約の支払いをするための金融機関処理用の資料を生成してもよい。また、支払い準備手段２００３は、統括会社、他の当事者、又は他の関連会社との流動性賃借に関する資料を生成してもよい。当該支払い準備手段２００３は、本願発明の一実施例に係るシステムのデータを、他のシステムと連携させる場合に、情報の流通を促進させる技術的意義を有する。

【0352】

支払い準備手段２００３は、債務に関連する情報、例えば、原債務者、債務金額、債権者、支払期限、通貨種類、などの情報を入力とすることができる。また、支払い準備手段２００３は、Ｔデータを入力としてもよいし、Ｔデータの情報に関連するアプリデータを入力としてもよい。

【0353】

また、支払い準備手段２００３は、当該支払いに関する情報を、通信手段２００５を介して、他の当事者、企業の親会社、地域拠点子会社、企業グループ内のインハウス銀行、銀行、銀行子会社、投資会社、郵便局、などの金融機関などに対して、連絡してもよい。

【0354】

６−１−４．廃棄手段２００４
廃棄手段２００４は、Ｔデータを廃棄する機能を有する。
廃棄手段２００４は、Ｔデータに係る受取者として、廃棄を意図される情報を設定したＴデータを生成してもよい。廃棄を意図される情報としては、本願発明の一実施例に係るシステムが廃棄として特定できればどのような情報であってもよく、例えば、廃棄アドレス、廃棄公開鍵、廃棄秘密鍵など、を設定してもよい。当該情報は、廃棄を意図されるＴデータ内であればどこでもよく、例えば、受取者のデータ欄、金額欄、などに設定されてよい。また、廃棄手段２００４が適用されて生成されたＴデータは、当該情報が設定された以外のデータは、どのような情報が設定されても良い。
廃棄手段２００４は、既存Ｔデータ内に設定された情報は変更され得ないことから、Ｔデータを現在存在する債務を示さないことを明確にするために、適用されてよい。ただし、廃棄手段２００４をＴデータに適用する代わり、又は、廃棄手段２００４を適用することと合わせて、アプリデータ内の当該Ｔデータを特定するデータに、当該データが示す債務が有効ではないことを示す情報を設定してもよい。
廃棄手段２００４は、流通手段１５０５、相殺手段２００１、更改手段２００２、支払い準備手段２００３、又は廃棄手段２００４などによって適用されてもよい。いずれの手段であっても、対象とされるＴデータを廃棄する意図であれば、廃棄手段２００４が適用されてよい。

【0355】

廃棄手段２００４は、上述の相殺手段２００１、更改手段２００２、支払い準備手段２００３を適用した後に、不要なＴデータの後処理として、廃棄することに用いられてもよい。

【0356】

廃棄手段２００４は、管理者アプリのアプリデータにＴデータの記録がある場合において、当該Ｔデータに廃棄の記録を付記してもよい。Ｔデータが廃棄手段２００４によって廃棄されることで、当該Ｔデータが債務を表していないことが明確になる。

【0357】

６−１−５．債務の終了関連機能を実行するアプリケーション
債務の終了に関連する機能は、Ｔデータに関連の深い機能と、アプリデータに関連の深い機能、また利用者に関連の深い機能がある。そのため、当該機能がＢＣアプリと同じ情報処理装置に存在した場合、生成手段１２０５を有するＢＣアプリと高速に情報交換可能な利点がある。当該機能がアプリデータの存在する管理者アプリと同じ情報処理装置に存在する場合、アプリデータと高速に情報交換が可能な利点がある。当該機能が、利用者と直接情報交換を行う利用者アプリにある場合、利用者から新しい情報を取得する又は利用者から取得して保持された情報を利用できる利点がある。
但し、上記利点がないとしても、当該機能は、ＢＣアプリと同じ情報処理装置内に存在してもよいし、管理者アプリと同じ情報処理装置内に存在してもよいし、利用者アプリと同じ情報処理装置内に存在してもよい。

【0358】

６−２．債務の終了に係るフロー例
６−２−１．相殺に関わるフロー例
次に、相殺に係るフローを、図２３を用いて、説明する。

【0359】

ＳＴ２３０１において、相殺手段２００１が、２つのＴデータの情報を取得する。

【0360】

ＳＴ２３０２において、相殺手段２００１は、あるＴデータの債権者と、他のＴデータの債務者が同一であり、かつ、当該あるＴデータの債務者と、当該他のＴデータの債権者が同一の場合であるか判断し、そうであれば、次に進む。

【0361】

ＳＴ２３０３において、相殺手段２００１は、２つのＴデータの金額を比較し、同じであれば、両方のＴデータに対して、廃棄手段２００４を適用する。

【0362】

ＳＴ２３０４において、相殺手段２００１は、２つのＴデータの金額が異なる場合、高い金額から低い金額を控除し、当該残余の金額について、当該高い金額のＴデータの債権者・債務者の情報と共に、更改手段２００２又は支払い準備手段２００３を適用する。

【0363】

６−２−２．更改に関わるフロー例
次に、更改のフローを、図２４を用いて、説明する。

【0364】

ＳＴ２４０１において、生成取得手段１２０２が、情報を取得する。

【0365】

ＳＴ２４０２において、生成取得手段１２０２は、取得した情報の中に、Ｔデータの更改を行う指示があれば、更改手段２００２に、従前のＴデータの情報と新たなＴデータの情報を伝達する。

【0366】

ＳＴ２４０３において、更改手段２００２は、生成手段１２０５を適用して、新たなＴデータを生成する。

【0367】

ＳＴ２４０４において、生成手段１２０５が、関連する情報を、更改手段２００２に伝達する。

【0368】

ＳＴ２４０５において、更改手段２００２は、従前のＴデータと新たに生成されたＴデータに関する情報を、管理者アプリに伝達する。

【0369】

７．マルチラテラルネッティング
当事者間の債務の相殺において、３以上の当事者間で相殺する場合、相殺の間の関係が複雑になる。このような３以上の当事者間における相殺は、マルチラテラルネッティングとよばれ、その具体的な処理が複雑であるとされてきた。より具体的に述べれば、債務は、債務者と債権者が特定される２当事者間のものであるが、マルチラテラルネッティングによれば、各当事者の第三者に対する債務又は債権を計算式で計算するだけであることから、債務者又は債権者が不明となる問題があった。

【0370】

本節では、上述のマルチラテラルネッティングにおける債務の当事者が明確にされた本願発明に関わる一実施例におけるマルチラテラルネッティングの実現方法を説明する。なお、Ｔデータの作成、Ｔデータの流通、Ｔデータの更改、Ｔデータの消滅は、例えば、上述した各手段により実現されるものである。

【0371】

また、マルチラテラルネッティングは、相殺する３以上の当事者を設定するグループが必要となる。マルチラテラルネッティングでは、グループ内の当事者間の債務の相殺を行う。ある当事者は、複数のグループに属していてもよい。但し、複数のものが、複数の重複するグループに属する場合は、どうちらのグループの債務として相殺をするかを決定する必要がある。グループの情報、又は当該どちらのグループの債務として相殺するかの情報は、事前に、アプリデータに登録されているものとする。なお、利用者アプリが、当該情報を保有していてもよい。

【0372】

７−１．統括会社のあるマルチラテラルネッティング
７−１−１．実施例
図２５は、マルチラテラルネッティングのプロセスを示す図である。この図では、当事者Ａ、Ｂ、Ｃ、及びＤが、マルチラテラルネッティングのグループとする。以下の、７−２及び７−３で述べる統括会社のないマルチラテラルネッティングにおいても同様である。

【0373】

２５０１では、各債務が相殺されずに記載されているが、複数当事者内のある２者間で相殺が容易に実行できるのであれば、当該２者間で相殺が事前にされてもよい。

【0374】

２５０１における、ＡがＢに対して負う債務は、次のとおり、表記される。なお、２５０１で表れる全ての矢印に対して、Ｔデータが存在するが、ここでは、その記載を省略する。

【0375】

［ＩＤ：ＩＤ１、送付者：Ａ、受取者：（Ｂ、３）］

【0376】

２５０２では、各債務が、各当事者と統括会社を当事者とするものに、変更される。
例えば、上記のＩＤ１は、以下の２つのＴデータが発生する。

【0377】

［ＩＤ：ＩＤ２、送付者：ＩＤ１、受取者：（統括会社、３）］（Ａと統括会社間）
［ＩＤ：ＩＤ３、送付者：統括会社、受取者：（Ｂ、３）］（Ｂと統括会社間）

【0378】

ここで、ＴデータＩＤ１は流通されて、当該ＴデータＩＤ１の債権者であるＡと統括会社間のＴデータＩＤ２が生成される。すなわち、ＩＤ１に対して、Ａと統括会社を当事者として、流通手段１５０５が適用される。

【0379】

他方、債権者である統括会社と債務者であるＢとの間では、新たなＴデータＩＤ３が生成される。すなわち、ＩＤ１に対して、Ｂと統括会社を当事者として、更改手段２００２が適用される。

【0380】

また、図２５０１において、ＡＢ間で上記と逆方向の債務であるＢがＡに対して負う債務は、次のとおり、表記される。

【0381】

［ＩＤ：ＩＤ４、送付者：Ｂ、受取者：（Ａ、２）］

【0382】

上記３の債務と同様に、図２５０２に移り、上記の２の債務は、次の２つのトランザクションに係るデータが生成される。

【0383】

［ＩＤ：ＩＤ５、送付者：ＩＤ４、受取者：（統括会社、２）］（Ａと統括会社間）
［ＩＤ：ＩＤ６、送付者：統括会社、受取者：（Ｂ、２）］（Ｂと統括会社間）

【0384】

すなわち、ＩＤ４に対して、Ａと統括会社を当事者として、流通手段１５０５が適用される。また、ＩＤ４に対して、Ｂと統括会社を当事者として、更改手段２００２が適用される。

【0385】

同様に、他のトランザクションに係るデータについても、このようなＴデータが作成される。

【0386】

この２５０２の段階において、Ａと統括会社の間においては、複数のＴデータが存在する。その値を列挙すると、図の左側から、２、３、５、３、７及び８に係るデータがある。

【0387】

これらは、２者間の債務であるから、計算により、相殺することができる。すなわち、これらの債務に係るＴデータに対して、相殺手段２００１が適用される。具体的には、２−３＋５−３＋７−８であり、その計算式の値は、−２となる。ここでは、統括会社がＡに対する債務を正の値として計算したため、上述したとおり、負の値である−２という趣旨は、Ａが統括会社に対して２の債務を負うことを意味する。これが、２５０３に表示されているＡと統括会社の間において、矢印がＡから統括会社に対して２と記載されていることの意味である。なお、計算式は、債務の当事者を逆に考えて、正負を逆に計算してもよい。

【0388】

同様に、Ｂ、Ｃ、又はＤと統括会社の間のトランザクションについても計算がされる。すなわち、相殺手段２００１が適用される。その結果、１２、５、９との値が計算されている。

【0389】

この後、統括会社と各当事者の間の債務は、６．債務の終了で述べたような、幾つかの選択肢が選択されることとなる。なお、統括会社との債務があるため、統括会社との間の流動性賃借としての処理も可能である。統括会社との間では、与信を設定することもできる。

【0390】

７−１−２．フローチャート例
次に、統括会社がある場合のマルチラテラルネッティングのフローチャートを、図２６を用いて、説明する。

【0391】

２６０１において、各当事者間のＴデータに基づき、各当事者と統括会社の間のＴデータが作成される。ここで、各当事者間のＴデータを、流通手段１５０５を用いて、流通させて、当該Ｔデータの債務者側の当事者と統括会社の間にＴデータを生成してもよい。また、各当事者間のＴデータに基づき、更改手段２００２を用いて、当該Ｔデータの債権者側の当事者と統括会社の間にＴデータを生成してもよい。

【0392】

２６０２において、各当事者と統括会社の間のＴデータの一部又は全部は、相殺手段２００１を用いて、相殺される。

【0393】

２６０３において、各当事者と統括会社の間のＴデータの一部又は全部に対して、支払い準備手段２００３が適用される。

【0394】

７−１−３．最終処理のフローチャート例
図２７は、統括会社を含むマルチラテラルネッティングの最終的な処理を示すフローチャートである。

【0395】

最終的な処理２７０１は、事前に登録されている。当該情報は、利用者アプリに記録されていてもよいし、ＢＣアプリ又は管理者アプリに記録されていてもよい。

【0396】

統括会社との流動性賃借２７０２とする場合には、与信枠が定められていてもよい。当該与信枠の情報は、利用者アプリに記録されていてもよいし、管理者アプリに記録されていてもよい。

【0397】

決済日２７０３の段階で、流動性賃借２７０４、新債務証書へ更改２７０７、銀行振り込み２７０８の選択肢が決定される。流動性賃借２７０４の場合は、与信枠内２７０５であれば、流動性賃借２７０６の扱いとして終了する。他方、与信枠を超えた債務である場合は、債務額の扱いについて、本願発明の一実施例に係るシステム外で相談などがされることとし、本願発明の一実施例に係るシステムは、新債務証書への更改２７０７又は、銀行振り込み２７０８のサポートを行う。具体的には、新債務証書への生成が選択された場合は、更改手段２００２が適用されてＴデータを生成し、銀行振り込みが選択された場合は、支払い準備手段２００３が適用される。

【0398】

３者以上の複数の当事者間における債務関係を処理するマルチラテラルネッティングにおいては、現実に存在する統括会社を含ませることで、各当事者が現実に負う債務を超えずに債務取引を実施できる利点がある。また、与信枠が設定された場合、統括会社と共に安全に債務の運用が可能な利点がある。さらに、当事者と統括会社である金融機関の間に債務が残る場合、速やかに、債務処理を実現できる利点がある。

【0399】

図２７を、上記では、統括会社があるマルチラテラルネッティングの場合として説明したが、図２７の手法は、上記のケースに限られない。例えば、統括会社がない、仮親又は親のあるマルチラテラルネッティングに適用することもできる。この場合、統括会社はいないため、新債務証書への更改（更改手段２００２が適用）、又は、銀行振り込みへの処理（支払い準備手段２００３が適用）などの処理でもよい。
また、図２７の手法は、２者間のマルチラテラルネッティングにおいても適用できる。この場合も、統括会社はいないため、新債務証書への更改（更改手段２００２が適用）、又は、銀行振り込みへの処理（支払い準備手段２００３が適用）などの処理でもよい。

【0400】

なお、上記では、２７０１の情報が事前に登録されているものとしたが、利用者アプリ又は管理者アプリからの指令などにより、当該情報は、変更されてもよい。

【0401】

７−２．統括会社なしのマルチラテラルネッティング
次に、統括会社のないマルチラテラルネッティングを説明する。本願に係る情報処理システムの一形態である統括会社のないマルチラテラルネッティングは、システム上、統括会社を介さない分、統括会社との関係で必要な手数料が不要であるという利点があるため、債務取引を促進できるシステムである。
本実施例は、図２８を用いて、７−１の数値例と同じ債務関係を用いて説明する。すなわち、複数の当事者であるＡ、Ｂ、Ｃ及びＤとの間の債務関係は、２８０１から２８０３までは、７−１で述べたことと同様に、処理が進む。但し、統括会社に代えて、仮親との間で、処理を進む。すなわち、トランザクションに係るデータは、ＩＤ１は、上述と同じであるが、ＩＤ２及びＩＤ３に代えて、次のＩＤ２’及びＩＤ３’の構成となる。ここで、仮親を当事者として特定又は参照する情報は、システム上仮親を示す任意の情報でよい。実在する当事者を示す情報でなくてよい。

【0402】

［ＩＤ：ＩＤ１、送付者：Ａ、受取者：（Ｂ、３）］
［ＩＤ：ＩＤ２’、送付者：ＩＤ１、受取者：（仮親、３）］（Ａと仮親間）
［ＩＤ：ＩＤ３’、送付者：仮親、受取者：（Ｂ、３）］（Ｂと仮親間）

【0403】

ここで、ＴデータＩＤ１は流通されて、当該ＴデータＩＤ１の債権者であるＡと仮親間のＴデータＩＤ２’が生成される。すなわち、ＩＤ１に対して、Ａと仮親を当事者として、流通手段１５０５が適用される。

【0404】

他方、債権者である仮親と債務者であるＢとの間では、新たなＴデータＩＤ３’が生成される。すなわち、ＩＤ１に対して、Ｂと仮親を当事者として、更改手段２００２が適用される。

【0405】

次に、上述と同じように、仮親と各当事者の間の債務が、相殺される。すなわち、これらの債務に係るＴデータに対して、相殺手段２００１が適用される。この例においては、上述と同じように、２、１２、５、９との値が計算されている。

【0406】

次に、仮親に係るＴデータに基づき、仮親を除いた当事者間のＴデータを作成する。当該Ｔデータは、流通手段１５０５、更改手段２００２が適用されて作成される。
また、当該Ｔデータは、当事者間のＴデータは、仮親への債務が大きい順であって、かつ、仮親の有する債務が大きい順に、流通手段１５０５又は更改手段２００２が適用されてもよい。

【0407】

一例を、図２９及び図３０を参照しつつ、説明する。

【0408】

まず、２９０１の段階で、作成されているＴデータを以下に示す。
［ＩＤ：ＩＤ１、送付者：Ａ、受取者：（仮親・２）］
［ＩＤ：ＩＤ２、送付者：Ｂ、受取者：（仮親・１２）］
［ＩＤ：ＩＤ３、送付者：仮親、受取者：（Ｄ・９）］
［ＩＤ：ＩＤ４、送付者：仮親、受取者：（Ｃ・５）］

【0409】

これらのＴデータに対して、流通手段１５０５、廃棄手段２００４、更改手段２００２などを適用することで、次のＴデータが生成される。

【0410】

［ＩＤ：ＩＤ５、送付者：ＩＤ２、受取者：（Ｄ・９）、（仮親・３）］
［ＩＤ：ＩＤ６、送付者：ＩＤ３、受取者：（廃棄アドレス・９）］
［ＩＤ：ＩＤ７、送付者：ＩＤ５、受取者：（Ｃ・３）］
［ＩＤ：ＩＤ８、送付者：ＩＤ４、受取者：（廃棄アドレス・３）（Ｃ・２）］
［ＩＤ：ＩＤ９、送付者：ＩＤ１、受取者：（Ｃ・２）］
［ＩＤ：ＩＤ１０、送付者：ＩＤ８、受取者：（廃棄アドレス・２）］

【0411】

具体的に説明する。まず、仮親への債務額としては、Ｂ−仮親間の１２と、Ａ−仮親間の２がある。債務額は、Ｂ−仮親間の１２が、Ａ−仮親間の２と比較して大きいことから、Ｂ−仮親間のＴデータを、支払側最大金額証書として特定される。また、仮親が有する債務額は、仮親−Ｄ間の９と、仮親−Ｃ間の５を比較すると、仮親−Ｃ間の９が大きいことから、仮親―Ｃ間の９のＴデータが受取側最大金額証書として、特定される。

【0412】

そして、債務額は、支払側最大金額証書の１２と、受取側最大金額証書の９を比較すると、支払側最大金額証書の１２が大きい。よって、Ｔデータの１２のうち、受取側最大金額証書の債務額分である９を、仮親からＤに流通させる。また、支払側最大金額証書Ｔデータの１２から、受取側最大金額証書Ｔデータの債務額分である９を控除した額は、仮親宛に、分割を用いて、流通させる。すなわち、支払側最大金額証書の１２に対して、流通手段１５０５が適用され、流通生成手段１５０３により、金額９と金額３のＴデータが生成される。当該手段で作成されたデータは、ＩＤ５である。

【0413】

また、受取側最大金額証書に係る債務者であるＤは、仮親に対する受取側最大金額証書の債務を免除するため、ＩＤ３は、廃棄アドレスへ送られる。すなわち、ＩＤ３に対して、廃棄手段２００４が適用され、ＩＤ６が作成される。

【0414】

次に、仮親への債務額として、Ａ−仮親間の２と、Ｂ−仮親間の３があるため、最大の債務額であるＢ−仮親間の３が支払側最大金額証書となる。
また、仮親の当事者に対する債務額として、仮親−Ｃ間の５が受取側最大金額証書となる。
Ｂ−仮親間の３と、仮親−Ｃ間の５を比較すると、仮親−Ｃ間の５が大きいため、受取側最大金額証書が大きくなる。

【0415】

そうすると、支払側最大金額証書を、受取側最大金額証書に係る債務者であるＣに流通させる。すなわち、支払側最大金額証書であるＢ−仮親間の３のＴデータに対して、流通手段１５０５が適用され、流通生成手段１５０３により、金額３のＴデータが生成される。当該Ｔデータが、ＩＤ７である。

【0416】

また、受取側最大金額証書に係る債務者であるＣは、支払側最大金額証書の債務額分の仮親の受取側最大金額証書の金額である３を免除するため、当該Ｔデータは、分割されて、３の分が廃棄され、残りの２については、債務者であるＣ宛に流通させる。すなわち、ＩＤ４に対して、流通手段１５０５が適用され、ＩＤ８が作成される。

【0417】

最後に、仮親への債務額として、Ａ−仮親間の２があるため、最大の債務額として、Ａ−仮親間の２が支払側最大金額証書となる。
また、仮親の当事者に対する債務額として、仮親−Ｃ間の２が受取側最大金額証書となる。

【0418】

Ｂ−仮親間の２と、仮親−Ｃ間の２を比較すると、同じ債務額である。そこで、支払側最大金額証書を、受取側最大金額証書に係る債務者であるＣに流通させる。すなわち、支払側最大金額証書の２に対して、流通手段１５０５が適用され、流通生成手段１５０３により、金額２のＴデータであるＩＤ９が生成される。

【0419】

また、受取側最大金額証書に係る債務者であるＣは、支払側最大金額証書の債務額分の仮親の受取側最大金額証書である２を免除するため、当該Ｔデータは、廃棄される。
すなわち、ＩＤ８に対して、廃棄手段２００４が適用され、ＩＤ１０が作成される。

【0420】

以上のように、債務が大きい順に計算をする利点の一つは、債務が大きい順に計算した場合、一般的には債務が大きい当事者が本願発明の一実施例に係るシステムを多く利用することである。この場合、本願発明の一実施例に係るシステムの利用代金として、債務が大きい当事者が、手数料を多く負担する合理的理由が発生する。また、大きな債務の処理を優先して処理できる利点もある。

【0421】

なお、上記では債務が大きい順に処理をしたが、受取側債務証書又は支払側債務証書の債務が小さい順に処理をしてもよい。また、流通手段１５０５、廃棄手段２００４を、それぞれ適切に適用すれば、処理順序はどのような順序でもよい。すなわち、図２９において、支払側最大金額証書と受取側最大金額証書は一例であり、要するに仮親に対するＴデータと仮親が有するＴデータを特定した上で、図２９のフローチャートを適用すれば、原債務者が明確となる。

【0422】

上記の実施例で説明すると、まず、Ｄへの債務額９は、ＩＤ５のＴデータで示されており、当該ＩＤ５は、ＩＤ２を流通したものであるから、ＩＤ２の送付者であるＢが原債務者であることが分かる。
また、Ｃへの債務額３は、ＩＤ１１のＴデータで示されており、当該ＩＤ１１は、ＩＤ５を流通させたものであり、そして当該ＩＤ５は、ＩＤ２を流通させたものであることから、当該ＩＤ２の送付者であるＢが原債務者であることが分かる。
最後に、Ｃへの債務額２は、ＩＤ１３のＴデータで示されており、当該ＩＤ１３は、ＩＤ１を流通させたものであることから、当該ＩＤ１の送付者であるＡが原債務者であることが分かる。

【0423】

上記手段は、マルチラテラルネッティングにおける原債務者の不透明さを、マルチラテラルネッティングの計算過程の明確性により、解消する技術的効果を有する。

【0424】

以上のように、仮親への最大債務額に係るＴデータと、仮親が有する最大債務額に係るＴデータを優先するなど、処理する対象Ｔデータを特定した上で、流通手段１５０５、又は廃棄手段２００４を用いるプロセスは、原債務者を明確にする。

【0425】

上述のように、マルチラテラルネッティングにおいてＴデータを流通させることによって、当事者間の当初の債務を表すＴデータが、仮親を一時的に債権者としつつも、その後、他の当事者に流通されることから、原債務者が変わらずに、当事者間の当初の債務を引き継いだ形で、マルチラテラルネッティングの後の当事者が債務関係を有することを示すことができている。

【0426】

７−３．統括会社なしのマルチラテラルネッティング
次に、統括会社がなく、当事者の一人が親となるタイプのマルチラテラルネッティングを説明する。これは、上記と異なり、仮親を設けないため、計算ステップが短い利点がある。但し、当事者の一人が、親又は統括会社の役割を果すことから、他の当事者の支払い不能又は支払い延期のリスクを被る。

【0427】

まず、親が設定される。図３１の３１０１においては、当事者のＡが親となった。当該親の決め方は、どのようなものでもよい。マルチラテラルネッティングの当事者の間の取り決め等によって親を定めておいてもよいし、当事者の間で順番に親を設定してもよいし、情報処理装置内の乱数によって特定の当事者を決定する方法等でもよい。要するに、マルチラテラルネッティングを実行する段階で、マルチラテラルネッティングの当事者のいずれかを親と決定する方法であれば、どのようなものでもよい。親に関するデータは、アプリデータとして設定されてよい。

【0428】

次に、各当事者間のＴデータに基づき、全て各当事者と親の間のＴデータが生成される。例えば、３１０１においては、ＢがＤに対して負っている債務１０は、Ｂが親Ａに負う債務１０と、親ＡがＤに負う債務１０に変更される。この場合、ＢがＤに対して負っている債務１０を流通させて、Ｂが親Ａに負う債務１０とし、新たに親ＡがＤに負う債務１０を作成する。

【0429】

［ＩＤ：ＩＤ１、送付者：Ｂ、受取者：（Ｄ・１０）］
［ＩＤ：ＩＤ２、送付者：ＩＤ１、受取者：（Ａ・１０）］
［ＩＤ：ＩＤ３、送付者：Ａ、受取者：（Ｄ・１０）］

【0430】

具体的には、ＩＤ１に対して、流通手段１５０５を適用して、ＩＤ１を流通させてＢが親Ａに負う債務１０であるＴデータのＩＤ２を作成する。また、ＩＤ１に対して、更改手段２００２を適用して、新たに親ＡがＤに負う債務１０であるＴデータＩＤ３を作成する。
このようにして、親を当事者としないＴデータに基づき、親及び当事者に係るＴデータを生成する。

【0431】

次に、親及び各当事者に係る複数のＴデータの一部又は全部に対して、相殺手段２００１を適用する。図３１においては、各当事者間の３１０２の複数のＴデータに対して、相殺手段２００１が適用されて、親Ａと各当事者の間のＴデータが作成される。

【0432】

上記では、Ａを親として説明したが、マルチラテラルネッティングの当業者を順に親に設定してもよい。例えば、各月で、順番に、マルチラテラルネッティングの当業者が親になってもよいし、２ヶ月毎に、順番にマルチラテラルネッティングの当業者の親が変更してもよい。
以下の８−１で説明すると、多数の企業グループが参加する本願発明の一実施例に係るシステムにおいては、各企業グループの親会社が、親となる場合がある。大規模な企業グループ同士が、決済システムを使用してマルチラテラルネッティングをする場合、親を誰にするかという問題が生じることもあるが、本願発明の一実施例に係るシステムの７−３で説明したマルチラテラルネッティングを使用して、親を定期的に変更することにより、このような親の設定に関する問題を、技術的に解決する。

【0433】

フローチャート例
次に、上述のフローチャート例を、図３２を用いて説明する。

【0434】

まず、ＳＴ３２０１において、親が設定される。

【0435】

ＳＴ３２０２において、各当事者間のＴデータに基づき、全て各当事者と親の間のＴデータが生成される。

【0436】

ＳＴ３２０３において、親と各当事者の間の複数のＴデータを、相殺する。

【0437】

７−４．マルチラテラルネッティングにおける処理
マルチラテラルネッティング及び２者間で相殺するバイラテラルネッティングの選択肢としては、図４２が一例として挙げられる。Ａにバイラテラルネッティングとマルチラテラルネッティングが挙げられ、Ｂに決済の処理方法が挙げられている。Ｂ１の統括会社との流動性賃借は、当事者と統括会社との間でＴデータが作成されることとなる。Ｂ２の新債務証書へ更改は、新たにＴデータが生成されることとなる。なお、図４２では、決済予定日付と記載されているが、これは一例であり、決済予定日がなくてもよい。Ｂ３の銀行振り込みは、支払い準備手段２００３を使用して、銀行処理などのための準備をすることでもよい。

【0438】

図４２の下段には、ＡとＢの各選択肢における説明が記載されている。

【0439】

図４３乃至図４５は、マルチラテラルネッティングに関するアプリデータの一例である。当該アプリデータを、管理者アプリが有することで、マルチラテラルネッティングの指示を出すことができるが、他のＢＣアプリ又は利用者アプリがこれらのアプリデータを有していてもよい。

【0440】

図４３は、各ネッティンググループに関する情報を記憶するテーブルの一例が描かれている。ネッティンググループの例として、グループＡからグループＦが記録されている。さらに多数のグループが記録されてよいことは当然である。マルチラテラルネッティングは、上述のとおり、統括会社あり（７−１）、統括会社のない仮親のタイプ（７−２）、親のタイプ（７−３）がある。図４３のテーブルでは、これらに合わせて、統括会社、仮親、親の列が記載されている。各列は、ネッティングの各グループに対応して、具体的な情報が記録されている。

【0441】

例えば、グループＡの行には、統括会社として企業Ａが記録されている。これは、グループＡのマルチラテラルネッティングにおいて、企業Ａが統括会社の役割を果すことを意味する。また、グループＢの行には、仮親として、管理者と記録されている。これは、グループＢのマルチラテラルネッティングにおいて、管理者が仮親の役割を果すことを意味する。また、グループＣの行には、仮親として、仮想主体Ａと記録されている。これは、グループＣのマルチラテラルネッティングにおいて、仮想主体Ａが仮親の役割を果すことを意味する。

【0442】

同様に、グループＤの行には、仮親として当事者Ｘが記録されている。これは、グループＤのマルチラテラルネッティングにおいて、当事者Ｘが仮親の役割を果すことを意味する。
また、グループＥの行には、親として当事者Ｙが記録されている。これは、グループＤのマルチラテラルネッティングにおいて、当事者Ｙが統括会社の役割を果すことを意味する。
更に、グループＦの行には、統括会社として企業Ｂが記録されている。これは、グループＦのマルチラテラルネッティングにおいて、企業Ｂが統括会社の役割を果すことを意味する。

【0443】

図４４は、各ネッティンググループの参加者又は構成者が記録されたテーブルの一例である。ネッティンググループの各グループに対して、参加者が記録されている。例えば、グループＡは、企業Ａ乃至Ｅが参加している。グループＢは、企業Ｘ乃至Ｚが参加している。このように、各グループの参加者数は異なってよい。また、グループＣは、Ｘ及びＹ、並びに、Ｂ、が参加している。企業Ｘ及びＹは、グループＢ及びＣの双方に参加している。また、企業Ｂは、グループＡ及びＣに参加している。

【0444】

図４５は、ネッティンググループの情報を記憶する他のテーブルの例を示している。当事者Ｘは、グループＡに属し、かつ、Ｚとの間ではバイラテラルの関係を有している。当事者Ｙは、グループＢ及びグループＣに属している。このように、当事者は、複数のグループに属することができる。当事者Ｚは、グループＢに属し、かつ、Ｘとの間でバイラテラルの関係を有している。

【0445】

上述のマルチラテラルネッティングを実施する際は、管理者アプリは、当該図４４、図４５又はこれらに類するテーブルを参照して、各グループに属する当事者の情報を取得した上で、マルチラテラルネッティングを実行する。また、そのとき、管理者アプリは、図４３又はこれに類するテーブルを参照して、グループ毎にマルチラテラルネッティングの種類を特定し、対応するマルチラテラルネッティングを実行する。すなわち、統括会社の存在するタイプであれば、７−１で記載した例のようなマルチラテラルネッティングを実行し、統括会社がなく仮親が存在するタイプであれば、７−２で記載した例のようなマルチラテラルネッティングを実行し、統括会社がなく親が存在するタイプであれば、７−３で記載した例のようなマルチラテラルネッティングを実行する。

【0446】

なお、図４３乃至図４５及び上記に記載した企業Ａ乃至Ｅ、Ｘ乃至Ｚ、管理者、仮想主体Ａ、当事者Ｘ乃至Ｚは、これらを示す情報であれば、どのような情報でもよい。例えば、これらを示す公開鍵、当該公開鍵の一部、又はこれらにハッシュ関数を適用したもの、などでもよい。

【0447】

７−５．マルチラテラルネッティングのグループ
マルチラテラルネッティングのグループは、上述のとおり、ＩＤで設定されうるが、この点をより詳細に説明する。グループは、マルチラテラルネッティング（２当事者も含めれば、バイラテラルネッティングも含まれる）を実施可能な集団であり、本願発明の一実施例に係るシステムにおいては、ＩＤを設定できることで、当事者を自由に設定できる。

【0448】

従来は、ネッティングは、階層構造において、上流階層に対する信頼の元で、ネッティングがされていた。例えば、図４８には、従前のネッティングの例が示されている。図４８においては、ネッティングを行う子会社、孫会社に対して、まず、地域としてアジア統括会社、欧米統括会社が上流階層として存在し、さらに上流階層に、全世界統括会社として親又は金融子会社が存在していた。このため、決済をするグループを自由に設定することができず、決済をするグループ毎にこのような階層構造を設定することが必要であった。これに対して、本願発明の一実施例に係るシステムのマルチネッティングにおいては、このような階層構造は不要であり、マルチラテラルネッティングに参加する当事者を指定したグループを設定するだけで、マルチラテラルネッティングを実施できる利点がある。

【0449】

例えば、図４９は、様々なマルチラテラルネッティングのグループが設定された一例である。４９００と四角で囲まれているのは、各当事者を示している。子・孫とは、子会社又は孫会社を示し、四角で囲まれた当事者としては、親会社、Ｇ外他社（グループ外の他社）、社員、社内レストランなどが例示されている。４９０１、４９０３、４９０４又は４９０５の細い楕円状の円は、設定されるグループを示す。４９０２の太い円はそのグループの中の親を示す。４９０１の楕円の中には、人件費と記載されている。これは、３つの子・孫（の会社）の事件費及び親会社の人件費という費目に関して、マルチラテラルネッティングのグループを設定した例を示している。これは、例えば、親会社が子・孫会社の株式を有しているグループ会社において、人員を移動することがあり、この場合、人件費の観点でのみ、各子・孫会社及び親会社間で、マルチラテラルネッティングが要求されるケースがある。そのため、人件費という品目で、グループを設定したマルチラテラルネッティングの例である。当事者の一人である親会社が４９０２で親となっているため、７−３で述べた親のあるマルチラテラルネッティングの例であるが、仮親を設定する、又は、統括会社を別途設けてマルチラテラルネッティングをしてもよい。この例に背景は、人件費などグループ会社内部の情報は、グループ会社外の会社との間で、情報の交流が好ましくないとされていることにある。すなわち、人件費のような企業グループに関連する閉じた当事者のみで情報交換したい費目の場合、マルチラテラルネッティングのグループの当事者を、企業グループに関連する当事者に限定することで、当該要求を技術的に実現できる。

【0450】

同様に、４９０３では、物品又はサービスに関するマルチラテラルネッティングの例が示されている。これも、関連会社間での物品に特定の条件を付している場合など、グループ会社外の会社との間で、情報の交流が好ましくないとされている場合がある。すなわち、特定の物品・サービスに関する条件を、企業グループに関連する閉じた当事者のみにしたい費目の場合、マルチラテラルネッティングのグループの当事者を、企業グループに関連する当事者に限定することで、当該要求を技術的に実現できる。なお、４９０３のマルチラテラルネッティングのグループにおいては、当事者の一の子・孫が親として太い円で囲まれているが、上述同様に、親を設定せずに、仮親としたり、統括会社を設定してもよい。なお、仮に当該グループの一当事者として親会社が含まれていても、親会社が親になってもいし、他の子・孫が親になってもよい。

【0451】

４９０４は、親会社及び２つのＧ外他社を当事者とするマルチラテラルネッティングのグループである。関連企業外の取引における条件を設定した物品の場合、又は他社から購入する物品等で設定する例が考えられる。親については、上述と同様である。

【0452】

４９０５は、電子マネーに関する例である。これは、社員及び社内レストランが含まれている。例えば、企業における何らかの報償が電子マネーで支払われ、これが、社内レストランで利用できるようなケースである。すなわち、当該報償が、本願発明の一実施例に係るシステムにおいて、Ｔデータが生成され、このＴデータを、社内レストランで使用されることにより、社内的な電子マネーを安価に作出することが可能となる。

【0453】

費目毎のマルチラテラルネッティングを説明したが、当該費目は、一つであってもよいし、複数の費目でおこなってもよい。また、費目に代えて又は費目と共に、社内における本部、部、課又は社内のこれに類する呼び名の組織などによって分けても良い。また、カンパニー制であれば、社内カンパニー毎又は当該社内カンパニー内の本部、部、課、又は社内のこれに類する呼び名の組織などに応じて分けても良い。例えば、図５０は、一例である。

【0454】

図５０では、Ａ、Ｂ及びＣ会社に対して、５００１、５００２、５００３の３つのネッティンググループが設定されている。５００１では、Ａ１事業部、Ｂ１事業部、Ｂ１項倍部、Ｃ１事業部が入っている。これは、サプライチェーンにおけるマルチラテラルネッティングの一例である。Ｂ会社は、Ｂ１購買部が、Ａ１事業部から部品を購入し、Ｂ１事業部が当該部品に基づき製品を製造し、当該製品が、Ｃ１事業部に販売されること等が考えられ、これが一つのマルチラテラルネッティングのグループとされている例となっている。
５００２は、別の物品又はサービスに関して、Ａ２事業部、Ｂ２事業部とＣ２事業部が、マルチラテラルネッティングのグループを構成している例が開示されている。さらに、マルチラテラルネッティングの対象は、物品又はサービスに限られるものではなく、例えば、各社の財務部同士がマルチラテラルネッティングのグループに属して、財務関係の費目について、マルチラテラルネッティングを実施してもよい。

【0455】

なお、上記では、マルチラテラルネッティングのグループを自由に設定できると説明したが、当該グループの設定権限を有する者を、本願発明の一実施例に係るシステム上制約し、特定の者のみが可能としてもよい。例えば、本願発明の一実施例に係るシステムの管理者、親会社、又は複数の当事者の同意の下で特定の者、などがグループを設定するよう構成してもよい。

【0456】

８．複数当事者間の実施例
８−１．複数当事者間における債務処理の背景
債務関係を有する複数の当事者が、一定の関係を有している例を次に説明する。
例えば、図３３は、独立した当事者Ａ３３０１、Ｂ３３０２と、複数の組織の集合であるＣ３３０３、Ｄ３３０４及びＥ３３０５を示す。Ａ、Ｂは、独立した法人であり、これらは単独である。他方、Ｃ及びＤは、一定のグループを有する法人群である。Ｃ１が、Ｃグループの親会社であり、Ｃ２及びＣ３は子会社、Ｃ４及びＣ５は、孫会社である。また、法人内部においても、現実の経理処理は、地域的に分かれている場合もある。そこで、Ｃ４は、原法であるＣ４’と、支店であるＣ４’’を有してもよい。これらは海外拠点ともいえる。同様の構成を、法人Ｄにおいても、図示した。また、金融サービス会社Ｅも、法人がグループ会社を構成することと対応する構成を有してもよい。

【0457】

現実の企業グループは、例えば、上述のような構成になっており、企業グループ内の各法人、支店などが、独自に、その企業グループの内外の法人との間で、債権債務関係を有する。そして、その支払い場所についても、法人単位に限らず、支店単位で支払いを特定する場合もある。

【0458】

上記の当事者間で複雑に成立した債権債務関係は、多数の債権債務が発生する場合が存在し、かつ各債権債務に期限があるため、これらを適切に処理することが重要である。

【0459】

仮に、金融機関が上記債権債務関係を処理する場合、その手数料が増加し、かつ手続きが煩雑となる。情報処理装置を用いて当事者が簡易、安全、かつ低コストで債権債務関係の処理を実現できることが好ましい。

【0460】

本願発明の一実施例に係るシステムは、上記のような、複雑に階層化された企業グループを取り巻く債権債務関係処理を実現できる。すなわち、多数の債権債務関係を、マルチラテラルネッティング又は２者間のバイラテラルネッティングを通して、すなわち、上述の生成手段１２０５、流通手段１５０５、更改手段２００２、相殺手段２００１、支払い準備手段２００３、又は廃棄手段２００４などの各手段を適宜利用することで、債権債務の額を減少させることができる。

【0461】

例えば、更改手段２００２を用いることで、債権債務の個数を減少させることができる。これにより、最終的には、銀行処理として支払が必要であるとしても、処理回数が減少し、銀行処理負担が減少する。また、例えば、各組織間の契約の個数が数百、数千の数であるとしても、その数が減少することにより、これをサポートする情報処理装置の処理量を減少させることができる。また、例えば、相殺手段２００１を用いることで、債権債務の額を減少させた場合には、企業間取引における大きな金額の移動が減るため、これをサポートする情報処理装置における確認負担が減少し、又は銀行処理における手数料も減少する。

【0462】

また、本願発明の一実施例に係るシステムが、流通手段１５０５を備えた場合、債権債務関係を有した直接の当事者とは異なる、原債務者が支払うよう構成できる。その技術的な意味を説明すると、本願発明の一実施例に係るシステムが流通手段１５０５を備えた場合、Ｔデータを生成する原債務者が資金力のある信頼ある大企業であるとすると、その資金力を背景とした支払可能性に対する信頼のために、Ｔデータの流通が継続されることとなる。そのため、コストを低く、取引を促進させることがとなる。

【0463】

更に、本願発明の一実施例に係るシステムが更改手段２００２を備えた場合は、当該更改手段２００２によって期限が到来したＴデータが更改されるため、典型的な支払手段である銀行処理が不要となり、手数料が減少し、取引を促進させることができる。

【0464】

例においては、当事者とは、法人又は金融サービス会社において、単独の法人に加えて、法人グループ自体、親会社、子会社、孫会社、企業グループ内の傘下企業、又は関連会社であってもよい。また、また一法人における原法、支店、拠点などでもよいし、同一法人内の地理的に異なる部、又は、組織的に異なる部であってもよい。また、当事者は、ネッティングセンター、サブネッティングセンターでもよい。さらに、当事者は、上述のとおり、一私人又は一般個人であってもよい。

【0465】

図４６は、マルチラテラルネッティングを含めた本願発明の一実施例の一部を示したブロック図である。図４６には、利用者アプリ４６０１、ＢＣアプリ４６０２、管理者アプリ４６０３が開示され、各アプリが備える手段の一部が例示され、また以下に本願発明の一実施例に係るシステムの一例を説明する。利用者アプリ４６０１からは、利用者が種々の指示をＢＣアプリ又は管理者アプリに行う。利用者アプリの一部の一例が、次に説明される。ＢＣアプリ４６０２は、主にＴデータの生成を生成手段によって担当し、ブロックチェーンを生成して、それらを、記憶手段で記憶させる。管理者アプリ４６０３は、Ｔデータの生成に伴うアプリデータを記憶手段で記憶する。また、流通手段を適用して、Ｔデータを流通させる。また、更改手段を適用して、Ｔデータを更改する。さらに、相殺手段を適用して、Ｔデータを相殺する。これらの場合、ＢＣアプリ内の生成手段を適用して、新たなＴデータを生成してもよい。また、マルチラテラルネッティングにおいては、統括会社を設定する場合、仮親を設定する場合、又は、親を設定する場合に対応して、上記述べたように各手段を適用してよい。これらの場合、統括会社用マルチラテラルネッティング手段、仮親用マルチラテラルネッティング、親用マルチラテラルネッティングとして、上記各手段を適用してもよい。なお、図４６で示された各手段は、一部が省略されているものである。
８−２．複数当事者間のシステムの機能
上記で述べた生成手段１２０５、流通手段１５０５、更改手段２００２、相殺手段２００１、支払い準備手段２００３、又は廃棄手段２００４などの各手段が、本願発明の一実施例に係るシステムにおいて実行される。これらの各手段は、アプリケーションのトリガーによって実行されてもよい。そこで、管理者が利用するアプリケーション又は利用者が利用する利用者アプリケーションに関する機能、そして、かかる機能を利用する利用者アプリ又は管理者アプリの表示画面を説明する。当該機能は、図４１に開示されたとおりである。

【0466】

８−２−１．セットアップ手段４１００（マスター登録）
利用者アプリ又は管理者アプリは、関係する当事者をシステムに記録し、登録する機能を有してもよい。

【0467】

関係する当事者としては、上述したとおり、法人又は金融サービス会社において、単独の法人に加えて、法人グループ自体、親会社、子会社、孫会社、企業グループ内の傘下企業、又は関連会社であってもよい。また、また一法人における原法、支店、拠点などでもよいし、同一法人内の地理的に異なる部、又は、組織的に異なる部であってもよい。さらに、当事者は、ネッティングセンター、サブネッティングセンターでもよい。

【0468】

これらを特定する情報としては、名称、住所、電話番号などによって特定し、一意的に特定するためのＩＤが付与されてもよい。

【0469】

ネッティングセンターとは、上述の統括会社を意味する。従って、利用者アプリ又は管理者アプリは、銀行、投資会社、郵便局などの金融機関の情報を有してもよい。

【0470】

企業の拠点とは、本願発明の一実施例に係るシステムを利用する可能性がある場所であればよく、例えば、法人が経理、会計、又は発注等の処理を行う箇所が挙げられる。

【0471】

登録された当事者に関して、本願発明の一実施例に係るシステムにおいては、Ｔデータの生成手段１２０５、Ｔデータの流通手段１５０５、更改手段２００２などの上述の各手段における当事者として、本願発明の一実施例に係るシステムにおいて、利用される。

【0472】

８−２−２．フォーマット手段４１０１
フォーマット手段４１０１は、入力部を介して以前取得した情報又は他の情報源から取得した情報に基づいて、入力部の入力を受け付ける箇所に情報を表示するための情報を準備する機能を有する。

【0473】

フォーマット手段４１０１は、Ｔデータ又はアプリデータの入力画面において、何ら入力されていない段階から情報を表示してもよいし、又は、何らかの予備的情報が入力された後に当該情報に基づいて、情報を表示してもよい。後者の予備的情報としては、債権者、債務者、又は支払い日、金額又は通貨などが挙げられる。

【0474】

債務に関連するＴデータ又はアプリデータは、継続的契約又は従前の契約の更新などにより、従前の契約の内容と関連性が高い場合がある。このような場合は、従前の契約で入力した情報を再利用してもよい。例えば、支払い金額の特定又は支払期日の設定方法等についてルールがあれば、これを初期値として、表示画面に表示させてもよい。また、当該情報は、その債務に限定して変更した場合等は、変更してもよい。

【0475】

フォーマット手段４１０１は、利用者アプリ上で実行されうるが、管理者アプリ又はＢＣアプリで実行され、その結果が利用者アプリ上で表示されるよう構成してもよい。

【0476】

８−２−３．Ｔデータリスト表示手段４１０２
Ｔデータリスト表示手段４１０２は、所定の条件を備えるＴデータリストを表示する機能を有する。
当該情報は、管理者アプリ内のアプリデータに基づいて表示されてもよいし、ＢＣアプリ内のブロックチェーンに基づき取得された情報に基づいて表示してもよい。

【0477】

所定の条件は、Ｔデータの要素に係る条件であれば、どのようなものでもよい。例えば、債権者、債務者、金額、支払い日、通貨、バイラテラルの有無、マルチラテラルネッティングのグループ、又は契約等に係る条件でもよい。また、所定の条件は、これらの要素の組み合わせでもよい。また、対象となるＴデータは、債務を表示しているものに限ってもよい。例えば、Ｔデータが流通した場合は、流通後に生成されたＴデータを対象とし、流通されたＴデータは対象としなくてもよい。また、Ｔデータが更改された場合は、更改の後に作成されたＴデータを対象とし、更改前のＴデータを対象としなくてもよい。さらに、Ｔデータが廃棄されたことを意味する廃棄アドレスが、受取者データに設定されたＴデータも対象としなくてもよい。これによって、現在当事者間の具体的な債務を示すＴデータを対象として、検索又は表示が可能となる。

【0478】

上記において、Ｔデータの流通の有無は、管理者アプリが、ＢＣアプリ内のブロックチェーンを具体的に辿ってＴデータの流通の有無を判断してもよいし、図１６のテーブルを参照してＴデータの流通の有無を参照しても良い。具体的には、ＢＣアプリ内には、数珠繋ぎ上のブロック内のトランザクションを検索して、対象となるＴデータを検索した後、当該Ｔデータを流通させて生成された（当該ＴデータのＩＤ又は当該Ｔデータの一部を参照して生成された）新たなＴデータの有無を確認することで、新たなＴデータが存在すれば、流通の元となったＴデータを検索又は表示の対象としないとする判断をすることができる。また、図１６のテーブルの場合も、同様に、対象となるＴデータのＩＤが、「元Ｔデータ」の列内に存在するかどうかを検索し、これによって、対象となるＴデータを流通させて、新たなＴデータが生成されたかどうかの有無を判断し、新たなＴデータが生成されていれば、流通の元となったＴデータを検索又は表示の対象としないとする判断をすることができる。なお、ブロックチェーン（又はブロックチェーンに類する上述のデータ構造）内を利用する利点は、上述のとおり安全性が高いことであり、他方、図１６のようなアプリデータを利用する利点は、テーブル検索という簡易な方法で情報を取得できることである。

【0479】

上述では、流通の場合を説明したが、同様に、Ｔデータの更改においても、管理者アプリが、ブロックチェーン（又はブロックチェーンに類する上述のデータ構造）内を検索して判断してもよいし、アプリデータ内のテーブル（例えば、図２２）内を検索して判断しても良い。また、Ｔデータの廃棄に関しても、同様に、管理者アプリが、ブロックチェーン（又はブロックチェーンに類する上述のデータ構造）内を検索して判断もよいし、アプリデータ内のテーブル内を検索して判断しても良い。

【0480】

表示されるＴデータリストは、債権者、債務者、金額、支払い日、通貨、バイラテラルの有無、マルチラテラルネッティングのグループ、又は契約の一部又は全部から構成されてもよい。Ｔデータリストは、一つのＴデータであってもよい。
アプリデータに当該情報が記録されている場合、当該情報を記録又は取得する技術は、周知のデータベースに係る技術を用いてもよい。

【0481】

Ｔデータリスト表示手段４１０２は、利用者アプリの入力部の指示に基づき、表示画面に表示される情報を整列する機能を有してもよい。Ｔデータリスト表示手段４１０２は、表示画面に表示されている各項目に関して、何らかの指標に基づいて、整列する機能を有してもよい。表示画面に表示されている各個目としては、例えば、債権者、債務者、金額、支払い日、通貨、バイラテラルの有無又はマルチラテラルネッティングのグループ等の情報が挙げられる。また、整列するための指標としては、各項目に依存するが、例えば、債権者、債務者又は通貨であれば、文字の序列（五十音順、アルファベット順、登録順）又は使用頻度の高い順などの指標に基づき整列させる機能を有してもよい。金額又は支払い日は、上昇又は下降順で整列してもよい。

【0482】

８−３．利用者アプリの画面例
８−３−１．メイン画面例
図３４は、利用者アプリの表示画面の一例である。表示画面を介して、取得手段が、債権者３４０１、債務者３４０２、支払い日３４０３、債務の金額３４０４、通貨３４０５、その他３４０６の関連情報を取得できるようになっている。

【0483】

債権者３４０１、債務者３４０２において、当事者を入力できる。これらは、登録された当事者をリストボタンによって、選択できるようになっていてもよい。また、登録されていない当事者を選択する場合には、ここから図示しないスイッチにより当事者を登録する画面に移り、セットアップ手段４１００を適用して、当事者を登録させてもよい。

【0484】

通貨３４０６は、「円」が既に入力されている画面が表示されている。これは、フォーマット手段４１０１が、メイン画面に適用されている例の一つである。すなわち、フォーマット手段４１０１は、メイン画面が表示された段階から、特定の入力（例えばこの例であれば「円」）を表示するよう設定されていてもよい。
フォーマット手段４１０１は、債権者３４０１又は債務者３４０２の入力を受け付けることで、通貨３４０５に対して、特定の通貨、例えば「円」又は「ドル」を表示させてもよい。

【0485】

また、その他３４０６として、「基本契約」と表示がされている。これも基本フォーマットとして、このようなその他の事項を提示するよう設定することができる一例を示したものである。なお、その具体的内容が、３４０９に表示されている。これにより、その他の内容が容易に分かるようになっている。

【0486】

バイラテラルネッティング設定３４０７があり、債権者と債務者の債権を互いに相殺するバイラテラルネッティング設定を指定できる。この例では、バイラテラルネッティングは設定されていない。なお、次に示すマルチラテラルネッティングが設定された場合、バイラテラルネッティングを自動的に優先するようにしてもよいし、他の図示しないスイッチによって、バイラテラルネッティングとマルチラテラルネッティングのいずれを優先するかを規定するスイッチを設けてもよい。

【0487】

マルチラテラルネッティング設定３４０８に対しては、グループとして、Ａ、Ｂ、及びＣが表示されており、現在はグループＡに設定されている。これは、当事者が複数のマルチラテラルネッティングに属する場合に、複数のマルチラテラルネッティングを適用できるようにする例である。なお、画面上の指示装置が、マルチラテラルネッティングのグループを指示したときに、その具体的なグループに属する法人、拠点、金融機関が表示される、又は、その具体的なグループの説明が表示されるようにしてもよい。

【0488】

取引契約リスト３４１０は、関連する契約のリストを表示する。例えば、債権者又は債務者を入力した場合、当該債権者又は債務者のいずれかが、債権者又は債権者とする契約のリストを表示してもよい。これによって、債権者又は債務者を入力するだけで、関連する契約の情報を見ることができる。また、フォーマット手段４１０１は、当該取引契約リスト３４１０の中の対応する契約に関する情報を受け付けた場合に、関連する契約の具体的な内容である、金額、通貨、支払い日、等の情報を各入力箇所に表示されるようにしてよい。当該表示により、利用者は、情報の入力負担が軽減する。

【0489】

利用者は、過去のＴデータリスト３４１１に基づき、流通するＴデータを選択できる。自分を債権者とするＴデータを流通させる場合、過去のＴデータリスト３４１１に、過去のＴデータリストが表示される。この場合、Ｔデータリスト表示手段４１０２が、Ｔデータリスト３４１１に、Ｔデータの一部又は全部を、種々の観点で整列し、表示させてもよい。

【0490】

例えば、Ｔデータリスト表示手段４１０２は、流通を許可しやすい原債務者に係るＴデータを優先的に表示してもよい。Ｔデータリスト表示手段４１０２は、流通を許可しやすい原債務者として、過去に、流通を許可したＴデータの個数、流通を許可したＴデータに係る金額、又は流通を許可する確率、などに基づいて表示してもよい。

【0491】

例えば、流通を許可したＴデータの個数が多い順、流通を許可したＴデータに係る金額が高い順、又は流通を許可する確率が高い順、またはこれらの混合の基準などの順に表示してもよい。これらの基準で整列されて表示された場合、上位に来るＴデータは、流通される可能性が大きいためである。また、これらを優先的に表示する、例えば上位に表示する、又は、特定のマークを付加する、などがされてもよい。利用者の便宜のためである。

【0492】

利用者は、Ｔデータリスト３４１１の中の表示されたＴデータから、流通させるＴデータを選択できる。フォーマット手段４１０１は、当該選択されたＴデータに基づき、債権者、債務者、金額、通貨、支払い日、等の情報を各入力箇所に表示されるようにしてもよい。当該表示により、利用者は、情報の入力負担が軽減する利点がある。

【0493】

利用者は、過去のＴデータリスト３４１２の中からＴデータを選択して、Ｔデータの更改を指定することができる。この場合、Ｔデータリスト表示手段４１０２が、Ｔデータリスト３４１２に、Ｔデータの一部又は全部を、種々の観点で整列し、表示させてもよい。

【0494】

例えば、Ｔデータリスト表示手段４１０２は、更改の必要性があるＴデータを優先的に表示してもよい。Ｔデータリスト表示手段４１０２は、支払い日の近いＴデータ、同一当事者との間で今後発生しうる債務であって相殺が可能になりやすいＴデータ、などの基準で表示してもよい。

【0495】

利用者は、Ｔデータリスト３４１２の中の表示されたＴデータから、更改させるＴデータを選択できる。フォーマット手段４１０１は、当該選択されたＴデータに基づき、債権者、債務者、金額、通貨、支払い日、等の情報を各入力箇所に表示されるようにしてもよい。当該表示により、利用者には、情報の入力負担が軽減する利点がある。

【0496】

Ｔデータ生成３４１３は、Ｔデータを生成するためのボタンである。

【0497】

上記では、図３４の表示画面に基づいて説明したが、当該入力された情報が、利用者アプリ、ＢＣアプリ又は管理者アプリに伝達され、それらの情報に基づき、ＢＣアプリ内でＴデータが生成される、又は管理者アプリ内でアプリデータが生成される。この過程で、当該入力情報が、利用者アプリ、ＢＣアプリ又は管理者アプリのテーブル等に記録されてもよい。利用者アプリ内のテーブルに記録された場合、当該情報が再度必要となる場合に、再利用できる利点がある。

【0498】

上記では、本願発明の一実施例に係るシステム専用の入力画面として説明したが、本システムは、会計システム、販売管理システム、又は発注管理システムなどの他のシステムで入力された情報に基づいて、本願発明の一実施例に係るシステムの情報を入力するよう構成してもよい。

【0499】

例えば、会計システムにおいて入力された取引先、受発注番号又はインボイス番号、金額（当事者間の金利を含んでもよい）、通貨、契約発生日、又は支払期日などの情報を、本願発明の一実施例に係るシステムに入力して利用してもよい。会計システムにおいては、例えば、買掛金支払処理、売掛金請求処理、仕分情報入力がある。また、販売管理システム購買管理システム、売上管理システム、取引契約管理システム、発注管理システム、発注情報システム、売掛請求情報システム、仕分情報入力システムなどを用いてもよい。これらのシステムで入力された各情報を、本願発明の一実施例に係るシステムの生成取得手段１２０２、流通取得手段１５０４などの取得手段を用いて、情報を取得してもよい。これらの他のシステムと連携する場合、既存のシステムの情報を活用して、本願発明の一実施例に係るシステムを利用できる利点がある。すなわち、既存の債務の入力済みの情報に基づいて、本願発明の一実施例に係るシステムのＴデータを新たに生成することで、本願発明の一実施例に係るシステムの利点を享受できる。また、利用者も、案件の事情に応じて、利用するシステムを選択できる利点がある。例えば、取引相手が、本願発明の一実施例に係るシステムに当事者として登録されている相手又は既に本願発明の一実施例に係るシステムを導入している相手、であれば本願発明の一実施例に係るシステムを利用し、層でなければ他のシステムを利用する、という選択が可能となる。

【0500】

例えば、図５１は、他のシステムと連携する一つの例である。Ｔデータの構成の一例を示しつつ、既存の会計に関する情報が記録されているシステムとの連携を示す。ここで、５１０１乃至５１０４は、順に、生成されているＴデータを示す。また、Ａ乃至Ｄは、その当事者を示す。
まず、当事者ＡとＢの取引により、他のシステム内において、Ａの資産増加／買掛債務増加、Ｂの売掛債権増加／在庫減少との情報が記録される。これと前後して、Ｔデータ５１０１が生成される。
次に、当事者ＢとＣが取引を行ったとする。そうすると、他のシステム内に、Ｂの資産増加／買掛債務増加が記録され、Ｃの売掛債権増加／在庫減少が記録される。そして、本願発明の一実施例に係るシステム内で、Ｔデータ５１０１を流通させて、Ｔデータ５１０２が生成されると、これと対応して（前後して）、他システムでは、まずＡにおけるＢあて買掛減少／Ｃあて金銭債務増加、ＢにおけるＣあて買掛減少／Ａあて売掛減少、ＣにおけるＡあて金銭債権増加／Ｂあて売掛減少が処理される。特に、５１０５で示されているとおり、Ｔデータ５１０２が生成された後に、上記のＡにおけるＢあて買掛減少／Ｃあて金銭債務増加、ＢにおけるＣあて買掛減少／Ａあて売掛減少、ＣにおけるＡあて金銭債権増加／Ｂあて売掛減少に関する情報が、３つの矢印で示されているとおり、本願発明の一実施例に係るシステムから当該他のシステムに対して通知され、当該他のシステムにおいて当該処理が実行されるよう構成してよい。なお、ここでの法律上の構成は、受領者Ｂは送付者Ａの債務を免除し、受領者Ｂが送付者Ｂとなり、Ａは、次の受領者Ｃに対するＢの債務を引き受けとなる。
また、次に、当事者ＣとＤが取引を行ったとする。そうすると、同様に、他のシステム内に、Ｃの資産増加／買掛債務増加、Ｄの売掛債権増加／在庫減少が記録される。本願発明の一実施例に係るシステム内で、Ｔデータ５１０２を流通させてＴデータ５１０３が生成されると、これと対応して（前後して）、ＡにおけるＣあて金銭債務減少／Ｄあて金銭債務増加、ＣにおけるＤあて買掛減少／Ａあて金銭債権減少、ＤにおけるＡあて金銭債権増加／Ｃあて売掛減少が処理される。特に、５１０６で示されているとおり、Ｔデータ５１０３が生成された後に、上記のＡにおけるＣあて金銭債務減少／Ｄあて金銭債務増加、ＣにおけるＤあて買掛減少／Ａあて金銭債権減少、ＤにおけるＡあて金銭債権増加／Ｃあて売掛減少に関する情報が、３つの矢印で示されているとおり、本願発明の一実施例に係るシステムから当該他のシステムに対して通知され、当該他のシステムにおいて当該処理が実行されるよう構成してよい。なお、ここでの法律上の構成は、受領者Ｃは送付者Ｂの債務を免除し、受領者Ｃが送付者Ｃになり、Ａは、次の受領者Ｄに対するＣの債務を引き受けとなる。

【0501】

８−３−２．Ｔデータ検索表示画面
図３５は、Ｔデータ検索表示画面の一例である。
Ｔデータ検索表示画面は、過去のＴデータリスト３４１１に代えて、Ｔデータを流通させる場合における流通対象となるＴデータに係る情報を表示する機能を有する。また、Ｔデータ検索表示画面は、過去のＴデータリスト３４１２に代えて、Ｔデータを更改する場合における当該更改対象となるＴデータに係る情報を表示する機能を有する。

【0502】

Ｔデータ検索表示画面は、検索条件３５０１が設定される箇所と、表示３５０２箇所がある。検索条件３５０１においては、債権者、債務者、通貨、金額、支払い日、又はネッティングの条件などの検索項目により、検索をすることができる。また、例えば、金額は、上限又は／及び下限で検索することもできるし、特定の金額で検索することもできる。また、支払い日は、期間で設定することも出来るし、特定の支払い日で検索することもできる。ネッティングは、バイラテラルであるかどうか、又はマルチラテラルネッティングのグループで特定することもできる。

【0503】

当該情報に対して、Ｔデータリスト表示手段４１０２が適用され、表示３５０２に表示される。表示３５０２は、債権者、債務者、通貨、金額、支払い日又はネッティングなど、Ｔデータに係るデータが表示される。また、リスト内の一のＴデータが指示装置で示された場合、当該Ｔデータに関連する契約の内容が表示されるように構成してもよい。

【0504】

８−３−３．相殺画面
図３６は、相殺画面の一例である。相殺画面は、相殺されるＴデータに係る情報を表示する機能を有する。相殺画面を介して、相殺手段２００１に情報が伝達されてもよい。また、相殺表示手段は、相殺後の金額、及び当該金額の債務に関する情報、例えば、債権者、債務者、支払い日、通貨などを、支払い準備手段２００３に伝達してもよい。

【0505】

相殺の対象は、利用者及び他の当事者の合計２者であるから、他方当事者３６０１において、利用者以外の他の当事者を特定される。

【0506】

Ｔデータリスト３６０２は、利用者が債権者で他の当事者が債務者のＴデータ、又は、利用者が債務者で他の当事者が債権者のＴデータのＴデータのリストである。当該リストは、利用者が債権者で他の当事者が債務者のＴデータ、又は、利用者が債務者で他の当事者が債権者との条件に基づき、Ｔデータリスト表示手段４１０２を用いて、表示される。

【0507】

また、当該Ｔデータリスト作成手段は、一定金額より低い、という条件でＴデータリストが作成されてもよい。一定金額より低いＴデータは、小額の債務であることから、量が多く、かつ、当事者としても大きな注意を払うことないため、一律に相殺の対象とした方が当事者の便宜がある場合もあるためである。

【0508】

また、Ｔデータリスト３６０２は、Ｔデータリスト表示手段４１０２によって、種々の観点で、整列可能されてもよい。例えば、支払い日が近いという順序で整列した場合は、時期的に直近のＴデータを優先して、処理する利便性がある。また、金額が小さいという順序で整列した場合は、上述のとおり、一律に相殺の対象とする利便性がある。

【0509】

利用者は、Ｔデータリスト３６０２内のＴデータに対して、相殺対象とするかどうかを決定することができる。Ｔデータリスト３６０２において、相殺の対象とされたＴデータが何らかの手段で特定される。例えば、相殺の対象とされるＴデータにチェックが設定される、又は、相殺の対象とされないＴデータは当該リストから除外される、などの方法により、相殺の対象となるＴデータが特定されてもよい。

【0510】

処理後金額３６０３には、相殺を実行した場合における金額が表示される。当該金額は、正負を含む金額で表示されてもよい。正の場合は、債務者として支払う必要があり、負の場合は、債権者として金額を取得できるようになっている。また、その根拠となるＴデータに関する情報が表示されてもよい。

【0511】

対応リスト３６０４に関して、次のステップを特定できる表示がされてもよい。対応には、銀行処理、更改、統括会社がある。これらは、銀行などの金融機関における処理、Ｔデータの更改処理、統括会社での支払い処理、を行うものである。合計額が処理後金額３６０３となるように、各金額を調整し、各金額に対する対応を設定することができる。各金額の合計額が、処理後金額３６０３とならない場合は、その旨の表示がされてもよい。当該画面において入力された各金額及びその対応に対して、支払い準備手段２００３が適用されてよい。

【0512】

相殺の実行３６０５が押下げられることにより、相殺手段２００１が適用され、相殺される。

【0513】

なお、ネッティングの場合は、所定の時期（例えば、毎月１日０時、毎週月曜日０時、３ヶ月毎など）にネッティングしている場合もあり、この場合は、図３６のような画面を用いて対象となるＴデータを検索してもよいし、図３６のような画面を用いずに対象となるＴデータを検索してもよい。

【0514】

図３６の相殺画面においても、図３４のメイン画面同様に、当該入力された情報が、利用者アプリ、ＢＣアプリ又は管理者アプリに伝達され、それらの情報に基づき、ＢＣアプリ内でＴデータが生成される、又は管理者アプリ内でアプリデータが生成される。この過程で、当該入力情報が、利用者アプリ、ＢＣアプリ又は管理者アプリのテーブル等に記録されてもよい。利用者アプリ内のテーブルに記録された場合、当該情報が再度必要となる場合に、再利用できる利点がある。

【0515】

８−３−４．マルチラテラルネッティング画面
図３７は、図３６と類似であるが、マルチラテラルネッティング画面の一例である。
図３６と異なる箇所は、ネッティンググループ３７０１である。ここで、ネッティンググループを特定することができる。また、マルチラテラルネッティングの実行３７０５が異なる。その他、ネッティングの対象とするＴデータリストの特定３７０２、処理後金額３７０３、そして対応リスト３７０４は、相殺画面と同様である。また、当該入力された情報が、記憶などされることも、図３６又は図３４の画面と同様である。

【0516】

なお、ネッティングの場合は、所定の時期（例えば、毎月１日０時、毎週月曜日０時、３ヶ月毎など）にネッティングしている場合もあり、この場合は、図３７のような画面を用いて対象となるＴデータを検索してもよいし、図３７のような画面を用いずに対象となるＴデータを検索してもよい。

【0517】

８−４．Ｔデータの監視通知
８−４−１．監視通知手段４１０３
監視通知手段４１０３は、Ｔデータに関連する支払い日を監視し、所定の要件を満たすＴデータに関して、関係者に通知する機能を有する。監視通知手段４１０３は、Ｔデータに関連する支払い日として、ブロックチェーン内のＴデータの支払い日を定期的に監視してもよいし、アプリデータに記憶されたＴデータの支払い日を定期的に監視してもよい。当該定期的な監視に代えて又は加えて、利用者アプリから要求があった段階で、監視してもよい。

【0518】

監視通知手段４１０３は、所定の要件を満たすＴデータとして、Ｔデータの各項目に関する予め定められた条件を用いてよい。Ｔデータの各項目とは、例えば、債権者、債務者、金額、支払い日、通貨、バイラテラルの有無又はマルチラテラルネッティングのグループ等の情報が挙げられる。また、これらの項目に関する条件とは、支払い日が、判断時点から３日前であるＴデータ、１週間前であるＴデータ、又は２週間前であって金額が１００万円を超えるもの、などの各項目に関する条件がありうる。かかる条件は、事前に利用者が設定してもよい。すなわち、利用者アプリを介して、当該条件を管理者アプリに登録してもよい。

【0519】

監視通知手段４１０３は、関係者として、Ｔデータに関連する様々な者に通知してよい。かかる者は、事前に管理者アプリに登録されていてもよい。関係者としては、例えば、債務者、債務者の親会社、債務者のグループ会社、債務者の金融機関などの当事者が挙げられる。また、当事者として本願発明の一実施例に係るシステムを使用出来ない者であってもよい。

【0520】

また、これらの通知を行うに際し、関係者の同意が必要であるかを設定するよう構成してもよい。例えば、債務者の金融機関に通知するにあたり、債務者の親会社、グループ会社の同意が必要という設定をするよう構成してもよい。

【0521】

８−４−２．監視通知のフローチャート例１
図３８を用いて、監視通知のフローチャート例を説明する。
ＳＴ３８０１において、予め管理者アプリのアプリデータに、監視を希望する利用者アプリ、監視時期、及び監視対象が登録されている。監視時期は、毎日０時、毎週月曜日の０時、毎月１日の０時などが挙げられる。監視時期は複数規定されていてもよい。また、監視対象は、監視通知手段４１０３が対応可能な、監視の対象となる要件を定める。これらは、図３９にあるようにテーブルが、アプリデータとして記録されていてもよい。なお、上述の他に全ての基本フォーマットとして、一定時期に全利用者アプリに対して監視結果を報告するようなシステムでもよい。

【0522】

ＳＴ３８０２において、監視通知手段４１０３は、監視時期が来ると、監視対象を、検索する。監視対象として、アプリデータに記録されたＴデータに関する情報を対象として検索してもよいし、Ｔデータそのものを対象として検索してもよい。

【0523】

ＳＴ３８０３において、監視通知手段４１０３は、検索された当該監視対象を、監視を希望した利用者アプリに通知する。

【0524】

ＳＴ３８０４において、利用者アプリは、当該検索された監視対象を、表示画面を介して、表示する。

【0525】

８−４−３．監視通知のフローチャート例２
利用者アプリが、監視対象に係る条件を記憶し、管理者アプリに通知してもよい。この場合、利用者アプリが、監視時期になった場合に、監視対象を、管理者アプリに伝達し、これに対応する形で、管理者アプリが、監視対象を検索することとなる。なお、監視対象がＴデータの場合は、ＢＣアプリが監視対象を検索してもよい。図４０は、利用者アプリが監視時期に管理者アプリに通知する一例である。

【0526】

ＳＴ４００１において、利用者アプリには、監視時期及び監視対象が登録されている。

【0527】

ＳＴ４００２において、利用者アプリの監視通知手段４１０３は、監視時期であるか判断する。

【0528】

ＳＴ４００３において、監視時期の要件を満たせば、利用者アプリの監視通知手段４１０３は、当該監視時期に対応する監視対象を、管理者アプリに通知する。

【0529】

ＳＴ４００４において、管理者アプリは、当該監視対象を、アプリデータから検索し、利用者アプリの監視通知手段４１０３に伝達する。

【0530】

ＳＴ４００５において、利用者アプリの監視通知手段４１０３は、監視アプリから取得した当該監視対象を、表示画面を介して、表示する。

【0531】

８−５．Ｔデータに係る数の減少
８−５−１．特定時期の減少
現存する債務を示すＴデータの数は、減少することもある。例えば、相殺手段２００１、更改手段２００２、支払い準備手段２００３又は廃棄手段２００４がＴデータに適用された場合などである。
また、現存する債務を示すＴデータの債務金額に係るデータの合計数は、減少することもある。例えば、相殺手段２００１、廃棄手段２００４などがＴデータに適用された場合等である。

【0532】

このようなＴデータの数又はＴデータの債務金額に係るデータの合計数（Ｔデータに係る数）の減少は、特定の時期に急激に減少することもある。例えば、本願発明の一実施例に係るシステムが扱う債務取引が、その慣行として月末に債務の締めが来る場合、現存する債務を示すＴデータに係る数は、月末に大きく減少する。また、例えば、本願発明の一実施例に係るシステムが扱う債務取引が、その慣行として四半期に債務の締めが来る場合、現存する債務を示すＴデータに係る数は、四半期毎に大きく減少しえる。一例として、図４７が挙げられる。

【0533】

図４７は、債務合計残高の動きと債務証書の枚数の動きがほぼ等しいこと、及び、一定時期にその値が増加して減少すること、を前提として、描かれたグラフのイメージを示す。債務合計残高が生成によって増加し、一定時期に、急激に激増しかつ一気に減少する状況を示している。これは、例えば、マルチラテラルネッティングにおけるＴデータの生成と破棄を分かりやすく誇張して描いたものである。すなわち、マルチラテラルネッティングにおいては、その過程で多数のＴデータが生成され、破棄される。例えば、統括会社・仮親・親との間でＴデータを生成手段で生成し、その後、更改手段又は相殺手段で、更改又は相殺する。図４７は、この最初に多数のＴデータが生成され、その後に多数のＴデータが破棄される状態をイメージとして記載したものである。なお、月末に債務の期限が到来する慣習のあるビジネスの債務取引において、月末に多数の債務を相殺又は更改する場合は、図４７のようにＴデータが激増することはないが、当該期限の来る時期にＴデータが減少することはありえる。

【0534】

８−５−２．マルチラテラルネッティングにおけるＴデータに係る数の減少
マルチラテラルネッティングにおいては、Ｔデータの個数の推移について、次のような特徴がある。ここでは、Ｍ人の当事者から構成されるマルチラテラルネッティングにおいて、当該当事者間の契約・債務を示すＮ個のＴデータが存在するとする。また、ここでは、Ｔデータの廃棄のためだけに必要とされるＴデータの個数、すなわち廃棄手段２００４によって生成されるＴデータの個数は考えないものとする。

【0535】

まず、統括会社が存在するマルチラテラルネッティング（７−１）の場合。
この場合、統括会社は、マルチラテラルネッティングの当事者ではないとする（統括会社がマルチラテラルネッティングの当事者の場合は、後述の親のケースである。）。Ｎ個の元の各Ｔデータに対して、当該Ｔデータを引用することで新たに生成されるＴデータがＮ個と、当該元の各Ｔデータに対する当事者と統括会社間の新たなＮ個のＴデータが生成される。さらに各当事者と統括会社の間の債務が複数ある場合、必要があれば、更改する。例えば、統括会社とＭ人の当事者全てとの間に複数の債務が存在しかつこれらを更改する場合、新たに更改後のＭ個のデータが必要となる。そのため、新たなＴデータの生成個数は、２Ｎ＋Ｍ個となる。また、この場合、廃棄されるＴデータは、最初のＮ個のＴデータ及び途中に生成される２Ｎ個のＴデータが不要となるから、３Ｎ個のＴデータが廃棄される。他方、統括会社とＭ人の当事者全てとの間の債務が、全て一つの債務であれば、更改は不要である。よって、この過程では、２Ｎ個の新たなＴデータが生成される。また、最後の更改によって廃棄されるＴデータがないため、３Ｎ−Ｍ個が廃棄される。
以上の検討により、統括会社が存在するマルチラテラルネッティングでは、３Ｎ−Ｍ乃至３Ｎ個のデータが廃棄される。また、２Ｎ乃至２Ｎ＋Ｍ個のＴデータが新たに生成される。

【0536】

次に、仮親が存在するマルチラテラルネッティング（７−２）の場合。
この場合、仮親との間のＴデータの生成及び廃棄では、上記の計算と同じである。ここから、仮親を除く過程となるが、この場合、各当事者と仮親との間のＴデータの債務金額の大小関係に基づき、例えば図２９のプロセスに基づいてＴデータの生成及び廃棄がされる。そこでＴデータの最小の生成個数及び最小の廃棄個数を計算すると、仮親が存在するマルチラテラルネッティング（７−２）の場合、少なくとも３Ｎ−Ｍ個のデータが廃棄され、少なくとも２Ｎ個のＴデータが新たに生成される。

【0537】

最後に、親が存在するマルチラテラルネッティング（７−３）の場合。
統括会社となる当事者を、契約の当事者としない契約における債務を示すＴデータの個数をＮ’個とする。そうすると、このＮ’を上述のＮと同視して、まず、２Ｎ’個のＴデータが生成され、上記と同様に当事者間の債務の個数が単数であるか又は複数であるかに応じて更改の有無が判断されるから、最大Ｍ−１個の更改がされる。よって、２Ｎ’乃至２Ｎ’＋Ｍ−１個のＴデータが生成される。また、廃棄されるＴデータの個数も、上述と同じように考えて、３Ｎ’―Ｍ乃至３Ｎ’個のＴデータが廃棄される。

【0538】

本願明細書の実施例において述べた例は、種々の例に適用できることはいうまでもない。
また、本明細書で説明される処理及び手順は、実施形態において明示的に説明されたものによってのみならず、ソフトウェア、ハードウェア又はこれらの組み合わせによっても実現可能なものである。また、本明細書で説明される処理及び手順は、それらの処理・手順をコンピュータプログラムとして実装し、各種のコンピュータに実行させることが可能である。

【符号の説明】

【0539】

１ システム
１１ バス
１２ 演算部
１３ 記憶部
１４ 入力部
１５ 表示部
１６ 通信ＩＦ
１０ 情報処理装置
２０ ネットワーク
３０ 情報処理装置
３１ バス
３２ 演算部
３３ 記憶部
３４ 入力部
３５ 表示部
３６ 通信ＩＦ
４０ ブロックチェーンのシステム
４１Ａ乃至４３Ａ ブロックヘッディング
４１Ｂ乃至４３Ｂ ブロックボディ
４１Ｂ１乃至４１ＢＮ トランザクション
５０１ トランザクション内
５０２ トランザクション外
５０３ トランザクションＩＤ
５０４ タイムスタンプ
５０５ 送付者名（ＩＤ）
５０６ 受取者名（ＩＤ）
５０７ 金額
５０８ 通貨種別
５０９ 期日（受取日、決済予定日等）
５１０ 決済方法
５１１ 特記事項
５１２ 原取引ＩＤ
５１３ トランザクションＩＤの履歴
５１４ 原債務者
５１５ 通貨種別
５１６ 決済方法
９０２ Ｔデータ構成手段
９０３ ブロック生成手段
９０４ ブロック確定手段
１２０２ 生成取得手段
１２０３ 生成通信手段
１２０４ 生成記録手段
１２０５ 生成手段
１５０１ 流通原債務者確認手段
１５０２ 流通アプリデータ作成手段
１５０３ 流通生成手段
１５０４ 流通取得手段
１５０５ 流通手段
１５０６ 流通通信手段
１６００ 新Ｔデータ
１６０１ 元Ｔデータ
１６０２ 免除債務者
１６０３ 原債務者
１６０４ 関連契約
１６０５ 債務の終了
２００１ 相殺手段
２００２ 更改手段
２００３ 支払い準備手段
２００４ 廃棄手段
２００５ 通信手段
４１００ セットアップ手段
４１０１ フォーマット手段
４１０２ Ｔデータリスト表示手段
４１０３ 監視通知手段
４１０４ 通信手段

【要約】      （修正有）

【課題】利用者が利用しやすい債務取引に係るデータ構造、情報処理装置、プログラム又は方法を提供する。
【解決手段】情報処理装置は、ブロックチェーンを用いたトランザクションシステムにおいて、ブロックチェーンに係るトランザクションデータは、第１債務に係る金額を示す第１債務金額データと、第１債務の債権者を示す債権者データと、第１債務に係る第１債務者が有する第２債権を示すトランザクションを特定するデータ又は第２債権を示すトランザクションの一部を特定するデータと、を有する。
【選択図】図５

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23】

【図24】

【図25】

【図26】

【図27】

【図28】

【図29】

【図30】

【図31】

【図32】

【図33】

【図34】

【図35】

【図36】

【図37】

【図38】

【図39】

【図40】

【図41】

【図42】

【図43】

【図44】

【図45】

【図46】

【図47】

【図48】

【図49】

【図50】

【図51】