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

Abstract

【課題】利用者が利用しやすい債務取引に係るデータ構造、情報処理装置、プログラム又は方法を提供する。【解決手段】本発明の一態様に係る情報処理装置は、マルチラテラルネッティングを行うためのトランザクションを示す第１データが、前記マルチラテラルネッティングの当事者とは異なる第三者を示すデータを有し、前記第１データは、前記マルチラテラルネッティングの前記当事者間の債務に係るデータであることを特徴とする、前記第１データを有する情報処理装置である。また、前記第１データが、前記マルチラテラルネッティングの前記当事者間の前記一の債務に係るトランザクションを特定するデータと、をさらに有する情報処理装置。【選択図】 図２５

Description

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

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

特許第５８７１３４７号公報 特開２０１４−９９１９８号公報

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

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

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

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

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

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

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

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

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

前記トランザクションシステム内で定められたルールに基づく値とは、例えばビットコイ
ンにおけるマイニングに基づいて付与される報償というルールに基づく値（報償金額）を
示す。そのため、前記トランザクションシステム内で定められたルールに基づく値とは異
なる値とは、例えば、当事者間の契約に基づいて当事者の指示に基づき生成されるデータ
に係る金額、当該債務の債務金額、当該システム内の了承を得て生成される当該データに
係る金額、又は当該システムの管理者による了承に基づいて生成される当該データに係る
金額などがある。なお、債務に係るデータの発行の際に手数料が必要であるとしても、手
数料に加えて債務金額が加算されるため、当該債務金額及び手数料の合計金額は、前記ト
ランザクションシステム内で定められたルールに基づく値とは異なる値にあたる。

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

本願発明の一実施例は、トランザクションシステム内の前記債務金額データの合計が、前
記トランザクションデータの生成に伴って、増加することを特徴とする、前記トランザク
ションデータを有する情報処理装置。
本願発明の一実施例は、全ての前記トランザクションデータの前記債務金額データの合計
が、前記トランザクションデータの生成に伴って、増加することを特徴とする、
前記トランザクションデータを有する情報処理装置。なお、債務に係る金額を示すデータ
の合計は、前記トランザクションデータの生成に伴って前記トランザクションデータの債
務に係る金額を示すデータ分増加してもよい。

ここで、トランザクションシステム内の前記債務金額データの合計、又は全ての前記トラ
ンザクションデータの前記債務金額データの合計とは、ビットコインにおける使用済みの
トランザクションは含まない。本願発明の一実施例では、マイニングなどの発掘のみに起
因して増加するビットコインと異なり、前記トランザクションデータの生成に伴って、増
加するものである。

本願発明の一実施例は、前記トランザクションシステムは、第１トランザクションデータ
と、第３トランザクションデータと、を扱い、前記第１トランザクションデータ内の債権
者データと、前記第３トランザクションデータ内の債権者データが、同一当事者を示すこ
とを特徴とする、情報処理装置又はトランザクションシステム。ここで、前記第１トラン
ザクションデータ内の債権者データと、前記第３トランザクションデータ内の債権者デー
タが、同一当事者を示すことは、前記第１トランザクションデータ内の債権者データと前
記第３トランザクションデータ内の債権者データが同一である場合、又は、前記第１トラ
ンザクションデータ内の債権者データと前記第３トランザクションデータ内の債権者デー
タを同一の当事者を指すものとして関連付けるデータが存在する場合などが挙げられる。
当該データが同一であれば、これを比較することで判別され、当該関連付けるデータが存
在すれば、当該関連付けるデータの有無を判別することで、判断されうる。本願明細書に
おいて、当事者の同一性又は第三者の同一性を示す場合には、同様の手法を取ってもよい
。

本願発明の一実施例は、マルチラテラルネッティングの複数の当事者である第１当事者と
第２当事者において、債権者データとして前記第２当事者を示すデータを有する第４トラ
ンザクションデータに係る債務金額データが、前記第１当事者が前記第２当事者に対して
有する本来の債務に係る金額とは異なることを特徴とする、情報処理装置又はトランザク
ションシステム。

本願発明の一実施例は、トランザクションを示す第１データであって、債務に係る金額を
示す債務金額データと、前記債務の債権者を示す債権者データと、前記債務の債務者以外
の第三者による前記第１データの成りすましを防止するための成り済まし防止に係るデー
タと、を有する前記第１データであって、前記第１データを用いるトランザクションシス
テムは、前記第１データと前記債務の原債務者に係る情報を関連付けて有する原債務者デ
ータを扱うことを特徴とする、前記第１データを有する情報処理装置又はトランザクショ
ンシステム。

本願発明の一実施例は、債務に係る金額を示す債務金額データと、前記債務の債権者を示
す債権者データと、前記債務の債務者以外の第三者による前記第１データの成りすましを
防止するための成り済まし防止に係るデータと、を有するトランザクションを示す第１デ
ータと、前記債務の原債務者に係る情報を有するトランザクションを示す第２データと、
を有する情報処理装置又はトランザクションシステム。

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

本願発明の一実施例は、トランザクションシステム内の前記第１データの前記債務金額デ
ータの合計が、前記第１データの生成に伴って、前記トランザクションシステム内で定め
られたルールに基づく値とは異なる値で増加することを特徴とする、情報処理装置又はト
ランザクションシステム。

本願発明の一実施例は、全ての前記第１データの前記債務金額データの合計が、前記第１
データの生成に伴って、増加することを特徴とする、前記第１データを有する情報処理装
置又はトランザクションシステム。なお、債務に係る金額を示すデータの合計は、前記第
１データの生成に伴って前記第１データの債務に係る金額を示すデータ分増加してもよい
。

本願発明の一実施例は、前記トランザクションシステムは、一の第１データと、他の第１
データと、を扱い、前記一の第１データ内の債権者データと、前記他の第１データ内の債
権者データが、同一当事者を示すことを特徴とする、情報処理装置又はトランザクション
システム。

本願発明の一実施例は、マルチラテラルネッティングの複数の当事者である第１当事者と
第２当事者において、債権者データとして前記第２当事者を示すデータを有する第１デー
タに係る債務金額データが、前記第１当事者が前記第２当事者に対して有する本来の債務
に係る金額とは異なることを特徴とする、情報処理装置又はトランザクションシステム。

本願発明の一実施例は、コンピュータを、ブロックチェーンを用いたトランザクションシ
ステムにおいて、前記ブロックチェーンに係るトランザクションデータに、債務に係る金
額を示す債務金額データ及び前記債務の債権者を示す債権者データを設定する設定手段、
前記トランザクションデータと前記債務の原債務者に係る情報を関連付けて有する原債務
者データを扱う手段、として動作させることを特徴とするプログラム。

本願発明の一実施例は、ブロックチェーンを用いたトランザクションシステムにおいて、
コンピュータが、前記ブロックチェーンに係るトランザクションデータとして、債務に係
る金額を示す債務金額データ及び前記債務の債権者を示す債権者データを設定する設定ス
テップと、コンピュータが、前記トランザクションデータと前記債務の原債務者に係る情
報を関連付けて保持する原債務者保持ステップと、を備える方法。

本願発明の一実施例は、マルチラテラルネッティングにおける当事者である第１当事者と
前記第１当事者とは異なる第２当事者において、コンピュータが、第１当事者以外の前記
当事者から前記第１当事者に対する債務を示すトランザクションデータにおいて、前記第
１当事者を、前記債権者データに設定するステップと、コンピュータが、第２当事者以外
の前記当事者から前記第２当事者に対する債務を示すトランザクションデータにおいて、
前記第２当事者を、前記債権者データに設定するステップと、を備える方法。

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

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

本願発明の一実施例は、全ての前記トランザクションデータの前記債務金額データの合計
が、前記トランザクションデータの生成に伴って、増加することを特徴とする、前記トラ
ンザクションデータを有する情報処理装置又はトランザクションシステム。なお、債務に
係る金額を示すデータの合計は、前記トランザクションデータの生成に伴って前記トラン
ザクションデータの債務に係る金額を示すデータ分増加してもよい。

本願発明の一実施例は、前記トランザクションデータが有する債務金額の合計は、前記第
２債権を示すトランザクションデータを特定するデータ又は前記第２債権を示すトランザ
クションデータの一部を特定するデータに係る債務額と同一であることを特徴とする、情
報処理装置又はトランザクションシステム。

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

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

本願発明の一実施例は、全ての前記第１データの前記債務金額データの合計が、前記第１
データの生成に伴って、増加することを特徴とする、前記第１データを有する情報処理装
置。なお、債務に係る金額を示すデータの合計は、前記第１データの生成に伴って前記第
１データの債務に係る金額を示すデータ分増加してもよい。

本願発明の一実施例は、前記第１データが有する債務金額の合計は、前記第２債権を示す
第１データを特定するデータ又は前記第２債権を示す第１データの一部を特定するデータ
に係る債務額と同一であることを特徴とする、情報処理装置又はトランザクションシステ
ム。

本願発明の一実施例は、コンピュータを、ブロックチェーンを用いたトランザクションシ
ステムにおいて、前記ブロックチェーンに係る第１トランザクションデータ内に、第１債
務に係る金額を示す第１債務金額データを設定する債務金額データ設定手段、前記第１債
務の第１債権者を示す第１債権者データを設定する債権者データ設定手段、前記ブロック
チェーンに係る第２トランザクションデータ内に、前記第１債務金額データ及び前記第１
債権者が設定された前記第１トランザクションデータを特定するデータ又は前記第１トラ
ンザクションデータの一部を特定するデータを設定するトランザクション設定手段、とし
て動作させることを特徴とするプログラム。

本願発明の一実施例は、トランザクションを示すデータ構造であって、第１債務に関わる
少なくとも一つの金額を示すデータと、前記第１債務に係る第１債務者が有する債権を示
すトランザクションデータを特定するデータ又は前記債権を示すトランザクションデータ
の一部を特定するデータと 、を有するデータ構造であって、前記金額を示すデータの合
計は、前記債権を示すトランザクションデータに係る債権額と同一であること、を特徴と
するデータ構造。

本願発明の一実施例は、ブロックチェーンを用いたトランザクションシステムにおいて、
コンピュータが、前記ブロックチェーンに係る第１トランザクションデータ内に、第１債
務に係る金額を示す第１債務金額データを設定する債務金額データ設定ステップと、前記
第１債務の第１債権者を示す第１債権者データを設定する債権者データ設定ステップと、
コンピュータが、前記ブロックチェーンに係る第２トランザクションデータ内に、前記第
１債務金額データ及び前記第１債権者が設定された前記第１トランザクションデータを特
定するデータ又は前記第１トランザクションデータの一部を特定するデータを設定するト
ランザクション設定ステップと、を有する方法。

本願発明の一実施例は、ブロックチェーンを用いたトランザクションシステムにおけるト
ランザクションデータが、債務金額を示す金額データと、前記債務の取引に係る日を示す
取引日データと、を有する前記トランザクションデータを有する第１情報処理装置を備え
るトランザクションシステム。
本願発明の一実施例は、前記債務の取引に係る日は、前記債務の決済日であることを特徴
とする、トランザクションシステム。

本願発明の一実施例は、ブロックチェーンを用いたトランザクションシステムにおけるト
ランザクションデータが、債務金額を示す金額データと、前記債務の取引に係る日を示す
取引日データと、を有し、前記トランザクションデータは、前記取引に係る日を含む当該
日までに有効ではなくなることを特徴とする、前記トランザクションデータを有する第１
情報処理装置を備えるトランザクションシステム。

有効ではなくなるとは、対象となるトランザクションデータが、存在する債務に係る情報
、例えば、債務額、債務に係る当事者など、を示さないデータとなることをいう。例えば
、対象となるトランザクションデータに対して、流通手段が適用されて他のトランザクシ
ョンデータが生成された場合、更改手段が適用されて他のトランザクションデータが生成
された場合、廃棄手段が適用される場合、又は表示される対象ではないトランザクション
データとなる場合などを意味する。

本願発明の一実施例は、前記取引日データ又は前記取引日データに係るデータに基づき、
前記債務の債務者に係る第２情報処理装置又は前記債務の債権者に係る第３情報処理装置
に対して、提供する情報を生成する第４情報処理装置を有する、トランザクションシステ
ム。
本願発明の一実施例は、提供された前記情報に対して、前記債務の債務者に係る第２情報
処理装置又は前記債務の債権者に係る第３情報処理装置から取得した情報に基づき、トラ
ンザクションデータ又は第三者における前記債務に対応する処理を可能とする情報を生成
する第５情報処理装置を有する、トランザクションシステム。

本願発明の一実施例は、トランザクションデータに係る情報に基づき、トランザクション
データ又は第三者における前記債務に対応する処理を可能とする情報を生成する第６情報
処理装置を有することを特徴とする、トランザクションシステム。
ここで、上記第１乃至第６情報処理装置は、異なる情報処理装置であってもよいし、同一
の情報処理装置であってもよい。
本願発明の一実施例は、前記取引に係る日を示すデータに基づき、前記トランザクション
データの少なくとも一部を一覧表示するための情報を生成する生成手段と、を備えるトラ
ンザクションシステム。

本願発明の一実施例は、コンピュータを、ブロックチェーンを用いたトランザクションシ
ステムにおいて、債務金額を示す金額データと、前記債務の取引日に係るデータと、を設
定する設定手段、前記取引日データ又は前記取引日データに係るデータに基づき、前記債
務の債務者に係る情報処理装置又は前記債務の債権者に係る情報処理装置に対して、提供
する情報を生成する生成手段、として動作させることを特徴とするプログラム。

本願発明の一実施例は、コンピュータを、ブロックチェーンを用いたトランザクションシ
ステムにおいて、債務金額を示す金額データと、前記債務の取引日に係るデータと、を設
定する設定手段、前記取引日データ又は前記取引日データに係るデータに基づき、トラン
ザクションデータ又は第三者における前記債務に対応する処理を可能とする情報を生成す
る生成手段、として動作させることを特徴とするプログラム。

本願発明の一実施例は、ブロックチェーンを用いたトランザクションシステムにおいて、
コンピュータが、債務金額を示す金額データと、前記債務の取引日に係るデータと、を設
定する設定ステップと、コンピュータが、前記取引日データ又は前記取引日データに係る
データに基づき、前記債務の債務者に係る情報処理装置又は前記債務の債権者に係る情報
処理装置に対して、提供する情報を生成する生成ステップと、を有する方法。

本願発明の一実施例は、ブロックチェーンを用いたトランザクションシステムにおいて、
コンピュータが、債務金額を示す金額データと、前記債務の取引日に係るデータと、を設
定する設定ステップと、コンピュータが、前記取引日データ又は前記取引日データに係る
データに基づき、トランザクションデータ又は第三者における前記債務に対応する処理を
可能とする情報を生成する生成ステップと、を有する方法。

本願発明の一実施例は、トランザクションを示すデータ構造であって、債務金額を示す金
額データと、前記債務の取引に係る日を示す取引日データと、第三者による前記データ構
造の生成指令の成りすましを防止するための成り済まし防止に係るデータと、を有するデ
ータ構造。

本願発明の一実施例は、マルチラテラルネッティングを行うためのトランザクションを示
す第１データが、前記マルチラテラルネッティングの当事者とは異なる第三者を示すデー
タを有し、前記第１データは、前記マルチラテラルネッティングの前記当事者間の債務に
係るデータであることを特徴とする、前記第１データを有する情報処理装置又はトランザ
クションシステム。

本願発明の一実施例は、前記第１データが、前記マルチラテラルネッティングの前記当事
者間の前記一の債務に係るトランザクションを特定するデータと、をさらに有する情報処
理装置又はトランザクションシステム。

本願発明の一実施例は、前記第１データが、前記第１当事者が前記第１当事者以外の前記
マルチラテラルネッティングに係る当事者へ有する債務の額から、前記第１当事者以外の
前記マルチラテラルネッティングに係る当事者が前記第一当事者へ有する債務の額を控除
した金額を示すデータと、を更に有する情報処理装置又はトランザクションシステム。

本願発明の一実施例は、前記第１データは、前記第１当事者と、前記第１当事者以外の前
記マルチラテラルネッティングに係る当事者との間の、マルチラテラルネッティングを行
うためのトランザクションを示す第２データに基づき生成されたことを特徴とする、情報
処理装置又はトランザクションシステム。

本願発明の一実施例は、ブロックチェーンを用いたトランザクションシステムにおいて、
前記ブロックチェーンに係るマルチラテラルネッティングのためのトランザクションデー
タは、前記マルチラテラルネッティングの当事者とは異なる第三者を示すデータを有し、
前記トランザクションデータは、前記マルチラテラルネッティングの前記当事者間の一の
債務に係るデータであることを特徴とする、前記トランザクションデータを有する情報処
理装置又はトランザクションシステム。

本願発明の一実施例は、前記トランザクションデータが、前記マルチラテラルネッティン
グの前記当事者間の前記一の債務に係るトランザクションを特定するデータと、をさらに
有する情報処理装置又はトランザクションシステム。

本願発明の一実施例は、前記トランザクションデータが、前記債務に係る債権者である第
１当事者が前記第１当事者以外の前記マルチラテラルネッティングに係る当事者に対して
有する債務の額から、前記第１当事者以外の前記マルチラテラルネッティングに係る当事
者が前記第一当事者へ有する債務の額を控除した金額を示すデータと、を更に有する情報
処理装置又はトランザクションシステム。

本願発明の一実施例は、前記第１データは、前記第１当事者と、前記第１当事者以外の前
記マルチラテラルネッティングに係る当事者との間の、マルチラテラルネッティングを行
うためのトランザクションを示すトランザクションデータに基づき生成されたことを特徴
とする、情報処理装置又はトランザクションシステム。

本願発明の一実施例は、マルチラテラルネッティングを行うためのトランザクションを示
す第１データ構造が、前記マルチラテラルネッティングの当事者とは異なる第三者を示す
データを有し、前記第１データ構造は、前記マルチラテラルネッティングの前記当事者間
の債務に係るデータ構造であることを特徴とするデータ構造。

本願発明の一実施例は、前記第１データ構造が、前記マルチラテラルネッティングの前記
当事者間の前記一の債務に係るトランザクションを特定するデータと、をさらに有するデ
ータ構造。
本願発明の一実施例は、前記第１データ構造が、前記第１当事者が前記第１当事者以外の
前記マルチラテラルネッティングに係る当事者へ有する債務の額から、前記第１当事者以
外の前記マルチラテラルネッティングに係る当事者が前記第一当事者へ有する債務の額を
控除した金額を示すデータと、を更に有するデータ構造。

本願発明の一実施例は、マルチラテラルネッティングを行うためのトランザクションを示
す第１データに、前記マルチラテラルネッティングの前記当事者間の債務に係るデータと
して、前記マルチラテラルネッティングの当事者とは異なる第三者を示すデータを設定す
る第三者設定手段と、第１当事者に係る債務金額を設定する債務金額設定手段と、
を有する、情報処理装置又はトランザクションシステム。

本願発明の一実施例は、情報処理装置であって、更に、前記マルチラテラルネッティング
の前記当事者間の前記一の債務に係るトランザクションを特定するデータを設定するトラ
ンザクション情報設定手段と、を有する、情報処理装置又はトランザクションシステム。
本願発明の一実施例は、コンピュータを、マルチラテラルネッティングを行うためのトラ
ンザクションを示す第１データの債権者データとして、前記マルチラテラルネッティング
の当事者とは異なる第三者を示すデータを設定する第三者設定手段、前記第１データの債
務金額として、マルチラテラルネッティングに係る第１の当事者から第２の当事者への債
務金額を示すデータを設定する債務金額データ設定手段、として動作させることを特徴と
するプログラム。

本願発明の一実施例は、コンピュータを、更に、前記マルチラテラルネッティングの前記
当事者間の前記第１の当事者から第２の当事者の債務に係るトランザクションを示すデー
タを特定するデータを設定するトランザクション情報設定手段、として動作させることを
特徴とするプログラム。本願発明の一実施例は、マルチラテラルネッティングを行うため
の方法において、前記マルチラテラルネッティングの前記当事者間の債務に係るデータと
して、前記マルチラテラルネッティングの当事者とは異なる第三者を示すデータを設定す
る第三者設定ステップと、第１当事者に係る債務金額を設定する債務金額設定ステップと
、前記マルチラテラルネッティングの前記当事者間の前記一の債務に係るトランザクショ
ンを特定するデータを設定するトランザクション情報設定ステップと、を有する方法。

本願発明の一実施例は、マルチラテラルネッティングの当事者である第１当事者及び第２
当事者並びに前記当事者以外の第三者において、前記第三者を示すデータ及び第１債務金
額を示すデータを含む第１データと、前記第２当事者を示すデータ及び第２債務金額を示
すデータを含む第２データと、に基づき、コンピュータが、前記第２データに係る前記第
２当事者を示すデータを、第３データの債権者データに設定するステップと、コンピュー
タが、前記第１データの第１債務金額を示すデータと前記第２データの第２債務金額を示
すデータのうち小さいデータを、前記第３データの債務金額データに設定するステップと
、を備えるマルチラテラルネッティングを行う方法。

本願発明の一実施例は、前記第三者を示すデータ及び第４債務金額を示すデータを含む第
４データと、前記第三者を示すデータ及び第５債務金額を示すデータを含む第５データに
おいて、コンピュータが、前記第１データとして、第４データに係る第４債務金額を示す
データより大きい第５債務金額に係る第５データを設定するステップと、を更に含む、方
法。

本願発明の一実施例は、第６当事者を示すデータ及び第６債務金額を示すデータを含む第
６データと、第７当事者を示すデータ及び第７債務金額を示すデータを含む第７データに
おいて、コンピュータが、前記第２データとして、第６データに係る第６債務金額を示す
データより大きい第７債務金額に係る第７データを設定するステップと、を更に含む、方
法。

本願発明の一実施例は、コンピュータが、前記第１データとして、前記第三者を示すデー
タと第８債務金額を示すデータを有する複数の第８データのうち、前記第８債務金額が最
も大きい前記第８データを設定するステップと、を更に含む、方法。

本願発明の一実施例は、コンピュータが、前記第２データとして、第９当事者を示すデー
タ及び第９債務金額を示すデータを含む複数の第９データのうち、前記第９債務金額が最
も大きい前記第９データを設定するステップと、を更に含む、方法。

本願発明の一実施例は、マルチラテラルネッティングの当事者である第１当事者及び第２
当事者並びに前記当事者以外の第三者において、前記第三者を示すデータ及び第１債務金
額を示すデータを含むブロックチェーンに係る第１トランザクションと、前記第２当事者
を示すデータ及び第２債務金額を示すデータを含むブロックチェーンに係る第２トランザ
クションと、に基づき、コンピュータが、前記第２データに係る前記第２当事者を示すデ
ータを、ブロックチェーンに係る第３トランザクションの債権者データに設定するステッ
プと、コンピュータが、前記第１データの第１債務金額を示すデータと前記第２データの
第２債務金額を示すデータのうち小さいデータを、前記第３トランザクションの金額デー
タに設定するステップと、を備えるマルチラテラルネッティングを行う方法。

本願発明の一実施例は、コンピュータが、前記第１トランザクションとして、前記第三者
を示すデータと第４債務金額を示すデータを有するブロックチェーンに係る複数の第４ト
ランザクションのうち、前記第４債務金額が最も大きい前記第４トランザクションを設定
するステップと、を更に含む、方法。

本願発明の一実施例は、コンピュータが、前記第２トランザクションとして、第５当事者
を示すデータ及び第５債務金額を示すデータを有するブロックチェーンに係る複数の第５
トランザクションのうち、前記第５債務金額が最も大きい前記第５トランザクションを設
定するステップと、を更に含む、方法。

本願発明の一実施例は、マルチラテラルネッティングの当事者である第１当事者及び第２
当事者並びに前記当事者以外の第三者において、前記第三者を示すデータ及び第１債務金
額を示すデータを含む第１データと、前記第２当事者を示すデータ及び第２債務金額を示
すデータを含む第２データと、に基づき、前記第２データに係る前記第２当事者を示すデ
ータを、第３データの債権者データに設定する債権者データ設定手段と、前記第１データ
の第１債務金額を示すデータと前記第２データの第２債務金額を示すデータのうち小さい
データを、前記第３データの債務金額データに設定する債務金額設定手段と、を備えるマ
ルチラテラルネッティングが可能な情報処理装置又はトランザクションシステム。

本願発明の一実施例は、前記第１データは、前記第三者を示すデータと第４債務金額を示
すデータを有する複数の第４データのうち、前記第４債務金額が最も大きい前記第４デー
タであり、前記第２データは、第５当事者を示すデータ及び第５債務金額を示すデータを
含む複数の第５データのうち、前記第５債務金額が最も大きい前記第５データである、こ
とを特徴とする情報処理装置又はトランザクションシステム。

本願発明の一実施例は、マルチラテラルネッティングの当事者である第１当事者及び第２
当事者並びに前記当事者以外の第三者における、マルチラテラルネッティングのトランザ
クションに係るデータ構造であって、前記第三者を示すデータ及び第１債務金額を示すデ
ータを含む第１データと、前記第２当事者を示すデータ及び第２債務金額を示すデータを
含む第２データと、に基づき、前記第２データに係る前記第２当事者を示すデータと、前
記第１データの第１債務金額を示すデータと前記第２データの第２債務金額を示すデータ
のうち小さいデータと、を有するデータ構造。

本願発明の一実施例は、前記第１データは、前記第三者を示すデータと第３債務金額を示
すデータを有する複数の第３データのうち、前記第３債務金額が最も大きい前記第３デー
タであり、前記第２データは、第４当事者を示すデータ及び第４債務金額を示すデータを
含む複数の第４データのうち、前記第４債務金額が最も大きい前記第４データである、こ
とを特徴とするデータ構造。

本願発明の一実施例は、マルチラテラルネッティングの当事者である第１当事者及び第２
当事者並びに前記当事者以外の第三者において、前記第三者を示すデータ及び第１債務金
額を示すデータを含む第１データと、前記第２当事者を示すデータ及び第２債務金額を示
すデータを含む第２データと、に基づき、コンピュータを、前記第２データに係る前記第
２当事者を示すデータを、第３データの債権者データに設定する債権者データ設定手段、
前記第１データの第１債務金額を示すデータと前記第２データの第２債務金額を示すデー
タのうち小さいデータを、前記第３データの債務金額データに設定する債務金額設定手段
、として動作させることを特徴とするマルチラテラルネッティングが可能なプログラム。

本願発明の一実施例は、前記第１データは、前記第三者を示すデータと第４債務金額を示
すデータを有する複数の第４データのうち、前記第４債務金額が最も大きい前記第４デー
タであり、前記第２データは、第５当事者を示すデータ及び第５債務金額を示すデータを
含む複数の第５データのうち、前記第５債務金額が最も大きい前記第５データである、こ
とを特徴とするプログラム。

前記トランザクションデータと前記債務の原債務者に係る情報を関連付けるデータである
原債務者データにおいて、前記トランザクションデータとは、前記トランザクションデー
タを特定する情報、例えばＩＤの情報、当該ＩＤの一部の情報、当該情報にハッシュ関数
を適用した情報などが挙げられ、原債務者に係る情報とは、例えば原債務者を特定する情
報、原債務者を示す情報、原債務者の公開鍵に係る情報、当該公開鍵に係る情報の一部、
当該情報にハッシュ関数を適用した情報などが挙げられる。

金額は、仮想通貨の額でもよいし、通貨の額でもよい。
債務者による前記トランザクションの生成の成りすましを防止する成り済まし防止のため
のデータとは、例えば、公開暗号方式を用いた手段に係るデータが挙げられる。例えば、
公開鍵、公開鍵の一部、公開鍵をハッシュ関数により処理した値、当該値の一部、暗号鍵
、暗号鍵の一部などが挙げられる。

債務の債権者を示すデータとは、単独で債権者を特定できるデータでもよいし、他の手段
と合わさって債権者を特定できるデータでもよい。例えば、債権者がネットワークにおい
て使用する公開鍵暗号方式における公開鍵でもよいし、またその公開鍵の一部の値でもよ
いし、債権者の特定を阻害しない範囲で当該公開鍵が変更される情報（例えば、公開鍵に
ハッシュ関数が適用されたハッシュ値）などでもよい。また、同一の債権者を特定する情
報は複数ありえることから、本件データ構造を用いるシステム内において、債権者を特定
するデータが全て同じでなく、異なっていてもよい。

トランザクションとは、処理を示すものである。これは、現実世界の取引の数と対応して
いてもよいし、対応していなくても良い。例えば、現実世界で一つの取引があるときに、
複数のトランザクションのデータが作成されることもあれば、現実世界で複数の取引があ
るときに、一つのトランザクションのデータ構造が作成されてもよい。また、本データ構
造の一部が実際の取引と対応していてもよい。
債務の合計は、ビットコインのように金額の生成数の上限が確定しているものではなく、
際限なく増加しうるものである。

本願発明の一実施例は、トランザクションを示すデータ構造であって、債務に係る金額を
示すデータと、前記債務の債権者を示すデータと、前記トランザクションを使用するため
の解除条件を示すデータと、前記解除条件を解くスクリプトのデータと、を有するデータ
構造。

トランザクションを使用するための解除条件のデータとは、債務者が債務を負担するとの
トランザクションを生成する際に充足する必要のある条件である。例えば、公開暗号方式
が使用される際における公開鍵または債務者を示すアドレスを含むが挙げられるが、これ
に限られるものではない。

前記債務の債権者を示すデータと、前記トランザクションを使用するための解除条件を示
すデータと、が成りすまし防止手段として機能してもよい。
公開鍵又は債務者に関わるアドレスと、前記公開鍵又は前記アドレスに対応する秘密鍵と
が、成りすまし防止手段に係るデータであってもよい。

本願発明の一実施例は、前記トランザクションは、前記第１債務者及び前記債務者が有す
る債権を示すトランザクションに係る前記第２債務者の両方の許可により生成されること
を特徴とする上記に記載されるデータ構造。

債務者の許可とは、対象とされるトランザクションの債務者の許可が必要であることを示
し、債務者が有する債権を示すトランザクションに係る債務者の許可とは、債務者が有す
る債権の債務者、又は本明細書で説明する流通によって当該債権の債務者となりえる者の
いずれかを示す。

本願発明の一実施例は、トランザクションを示すデータ構造であって、債務金額を示すデ
ータと、前記債務の取引に係る日を示すデータと、を有するデータ構造。

前記債務の取引に係る日とは、債務と関連のある日であれば何でもよい。例えば、債務に
係る日でもよいし、当該債務が双務契約であって、当該債務と相対する債務に係る日でも
よい。また、債務に係る日として、債務に係る契約の交渉開始に係る日、債務に係る契約
の合意に係る日、債務に係る契約の調印日、債務に係る取引日、又は債務の決済日でもよ
い。またデータ構造が有する債務の取引に係る日は、一つであっても、複数であってもよ
い。なお、トランザクションのデータに情報が入力された日は、債務の取引に係る日と論
理的な関係がないため、前記債務の取引に係る日にあたらない。

提供される情報として、通知又は警告などが挙げられる。通知又は警告などがされること
により、債務者は、支払期限また債務履行日が近づいていることを認識し、それに対応し
た適切な対処を取ることができる。

前記債務の債務者に係る情報処理装置又は前記債務の債権者に係る情報処理装置から取得
した情報とは、前記債務の債務者に係る情報処理装置又は前記債務の債権者に係る情報処
理装置から取得した情報であればどのようなものでもよいが、例えば、債務の債務者又は
債務の債権者が更改に了承したことを示す情報、更改する場合の異なる支払い日に関する
情報、次に作成された債務の支払い方法に関する情報などが挙げられる。なお、更改する
場合であっても、更改によって発生した債務は、履行日が決定している必要はないため、
履行日がない場合もある。また、次に作成された債務の支払い方法も決定していなくても
よい。

金融機関における前記債務に対応する処理を可能とする情報とは、銀行、投資銀行又は郵
便局などの金融機関において、債務の支払い、債務の支払い準備、債務の支払いの調整な
どの債務に対応する処理を可能とするための情報を意味する。当該情報は、債権者、債務
者、支払い日、支払金額、又は支払通貨などでもよい。

債務の債務者又は債務の債権者のいずれかから得られた情報とは、例えば、債務者又は債
権者の指示、支払うための銀行の特定、支払い期限の特定、又は支払い通貨の特定などの
情報が挙げられる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

図１は、本発明の一実施形態の一部に係る情報処理システムの構成を示すブロック図である。 図２は、本発明の他の実施形態の一部に係る情報処理システムの構成を示すブロック図である。 図３は、本発明の他の実施形態の一部に係る情報処理システムの構成を示すブロック図である。 図４は、本発明の一実施形態の一部に係る情報処理システムの構成を示すブロック図である。 図５は、本発明の一実施形態の一部に係るデータ構造の例である。 図６は、本発明の一実施形態の一部に係るデータ構造の例である。 図７は、本発明の一実施形態の一部に係るデータ構造の例である。 図８は、本発明の一実施形態の一部に係るデータ構造の例である。 図９は、本発明の一実施形態の一部に係る機能の例を示すブロック図である。 図１０は、本発明の一実施形態の一部に係る動作の例を示すフロー図である。 図１１は、本発明の一実施形態の一部に係る情報処理装置を含む情報処理システムの一状況を示すブロック図である。 図１２は、本発明の一実施形態の一部に係る機能の例を示すブロック図である。 図１３は、本発明の一実施形態の一部に係るデータ構造の例である。 図１４は、本発明の一実施形態の一部に係る動作の例を示すフロー図である。 図１５は、本発明の一実施形態の一部に係る機能の例を示すブロック図である。 図１６は、本発明の一実施形態の一部に係るデータ構造の例である。 図１７は、本発明の一実施形態の一部に係るデータ構造の例である。 図１８は、本発明の一実施形態の一部に係るデータ構造の例である。 図１９は、本発明の一実施形態の一部に係る動作の例を示すフロー図である。 図２０は、本発明の一実施形態の一部に係る機能の例を示すブロック図である。 図２１は、本発明の一実施形態の一部に係る動作の例を示すフロー図である。 図２２は、本発明の一実施形態の一部に係るデータ構造の例である。 図２３は、本発明の一実施形態の一部に係る動作の例を示すフロー図である。 図２４は、本発明の一実施形態の一部に係る動作の例を示すフロー図である。 図２５は、本発明の一実施形態の一部に係る動作の例を示すフロー図である。 図２６は、本発明の一実施形態の一部に係る動作の例を示すフロー図である。 図２７は、本発明の一実施形態の一部に係る動作の例を示すフロー図である。 図２８は、本発明の一実施形態の一部に係る動作の例を示すフロー図である。 図２９は、本発明の一実施形態の一部に係る動作の例を示すフロー図である。 図３０は、本発明の一実施形態の一部に係る動作の例を示すフロー図である。 図３１は、本発明の一実施形態の一部に係る動作の例を示すフロー図である。 図３２は、本発明の一実施形態の一部に係る動作の例を示すフロー図である。 図３３は、本発明の一実施形態の一部に係る情報処理装置を含む情報処理システムの一状況を示すブロック図である。 図３４は、本発明の一実施形態の一部に係るアプリケーションの画面例を示す図である。 図３５は、本発明の一実施形態の一部に係るアプリケーションの画面例を示す図である。 図３６は、本発明の一実施形態の一部に係るアプリケーションの画面例を示す図である。 図３７は、本発明の一実施形態の一部に係るアプリケーションの画面例を示す図である。 図３８は、本発明の一実施形態の一部に係る動作の例を示すフロー図である。 図３８は、本発明の一実施形態の一部に係る記憶テーブルの例を示す図である。 図４０は、本発明の一実施形態の一部に係る動作の例を示すフロー図である。 図４１は、本発明の一実施形態の一部に係る機能の例を示すブロック図である。 図４２は、本発明の一実施形態の一部に係る機能の決済方法の選択肢の例を示す図である。 図４３は、本発明の一実施形態の一部に係る記憶テーブルの例を示す図である。 図４４は、本発明の一実施形態の一部に係る記憶テーブルの例を示す図である。 図４５は、本発明の一実施形態の一部に係る記憶テーブルの例を示す図である。 図４６は、本発明の一実施形態の一部の例を示した図である。 図４７は、本発明の一実施形態の一部に関するイメージを示すグラフである。 図４８は、従来技術の一例である。 図４９は、本発明の一実施形態の一部であるマルチラテラルネッティングのグループに関する一例である。 図５０は、本発明の一実施形態の一部であるマルチラテラルネッティングのグループに関する一例である。 図５１は、本発明の一実施形態の一部であるＴデータの流通とサプライチェーンの関係を示す一例である。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Claims (16)

1. ブロックチェーンを用いたトランザクションシステムにおいて、
   前記ブロックチェーンに係るマルチラテラルネッティングのためのトランザクションデー
   タは、
   前記マルチラテラルネッティングの当事者とは異なる第三者を示すデータを有し、
   前記トランザクションデータは、前記マルチラテラルネッティングの前記当事者間の一の
   債務に係るデータであることを特徴とする、
   前記トランザクションデータを有する情報処理装置。
2. 前記トランザクションデータが、前記マルチラテラルネッティングの前記当事者間の前記
   一の債務に係るトランザクションを特定するデータと、
   を更に有する請求項１に記載の情報処理装置。
3. 前記トランザクションデータが、
   前記債務に係る債権者である第１当事者が前記第１当事者以外の前記マルチラテラルネッ
   ティングに係る当事者に対して有する債務の額から、前記第１当事者以外の前記マルチラ
   テラルネッティングに係る当事者が前記第一当事者へ有する債務の額を控除した金額を示
   すデータと、
   を更に有する請求項１又は２に記載の情報処理装置。
4. 前記トランザクションデータは、
   前記第１当事者と、前記第１当事者以外の前記マルチラテラルネッティングに係る当事者
   との間の、マルチラテラルネッティングを行うためのトランザクションを示すトランザク
   ションデータに基づき生成されたことを特徴とする、
   請求項１乃至３のいずれか１項に記載の情報処理装置。
5. マルチラテラルネッティングを行うためのトランザクションを示す第１データが、
   前記マルチラテラルネッティングの当事者とは異なる第三者を示すデータを有し、
   前記第１データは、前記マルチラテラルネッティングの前記当事者間の債務に係るデータ
   であることを特徴とする、前記第１データを有する情報処理装置。
6. 前記第１データが、前記マルチラテラルネッティングの前記当事者間の前記一の債務に係
   るトランザクションを特定するデータと、
   を更に有する請求項５に記載の情報処理装置。
7. 前記第１データが、
   前記第１当事者が前記第１当事者以外の前記マルチラテラルネッティングに係る当事者へ
   有する債務の額から、前記第１当事者以外の前記マルチラテラルネッティングに係る当事
   者が前記第一当事者へ有する債務の額を控除した金額を示すデータと、
   を更に有する請求項５又は６に記載の情報処理装置。
8. 前記第１データは、
   前記第１当事者と、前記第１当事者以外の前記マルチラテラルネッティングに係る当事者
   との間の、マルチラテラルネッティングを行うためのトランザクションを示す第２データ
   に基づき生成されたことを特徴とする、
   請求項５乃至７のいずれか１項に記載の情報処理装置。
9. マルチラテラルネッティングを行うためのトランザクションを示す第１データ構造が、
   前記マルチラテラルネッティングの当事者とは異なる第三者を示すデータを有し、
   前記第１データ構造は、前記マルチラテラルネッティングの前記当事者間の債務に係るデ
   ータ構造であることを特徴とするデータ構造。
10. 前記第１データ構造が、前記マルチラテラルネッティングの前記当事者間の前記一の債務
    に係るトランザクションを特定するデータと、
    をさらに有する請求項９に記載のデータ構造。
11. 前記第１データ構造が、
    前記第１当事者が前記第１当事者以外の前記マルチラテラルネッティングに係る当事者へ
    有する債務の額から、前記第１当事者以外の前記マルチラテラルネッティングに係る当事
    者が前記第一当事者へ有する債務の額を控除した金額を示すデータと、
    を更に有する請求項１０に記載のデータ構造。
12. マルチラテラルネッティングを行うためのトランザクションを示す第１データに、
    前記マルチラテラルネッティングの前記当事者間の債務に係るデータとして、前記マルチ
    ラテラルネッティングの当事者とは異なる第三者を示すデータを設定する第三者設定手段
    と、
    第１当事者に係る債務金額を設定する債務金額設定手段と、
    を有する、情報処理装置。
13. 前記マルチラテラルネッティングの前記当事者間の前記一の債務に係るトランザクション
    を特定するデータを設定するトランザクション情報設定手段と、
    を更に有する請求項１２に記載の情報処理装置。
14. コンピュータを、
    マルチラテラルネッティングを行うためのトランザクションを示す第１データの債権者デ
    ータとして、前記マルチラテラルネッティングの当事者とは異なる第三者を示すデータを
    設定する第三者設定手段、
    前記第１データの債務金額として、マルチラテラルネッティングに係る第１の当事者から
    第２の当事者への債務金額を示すデータを設定する債務金額データ設定手段、
    として動作させることを特徴とするプログラム。
15. コンピュータを、更に、
    前記マルチラテラルネッティングの前記当事者間の前記第１の当事者から第２の当事者の
    債務に係るトランザクションを示すデータを特定するデータを設定するトランザクション
    情報設定手段、
    として動作させることを特徴とする請求項１４に記載のプログラム。
16. マルチラテラルネッティングを行うための方法において、
    前記マルチラテラルネッティングの前記当事者間の債務に係るデータとして、前記マルチ
    ラテラルネッティングの当事者とは異なる第三者を示すデータを設定する第三者設定ステ
    ップと、
    第１当事者に係る債務金額を設定する債務金額設定ステップと、
    前記マルチラテラルネッティングの前記当事者間の前記一の債務に係るトランザクション
    を特定するデータを設定するトランザクション情報設定ステップと、
    を有する方法。

Images