JP2021162974A - 情報処理システム、情報処理装置、サーバ装置、プログラム、又は方法 - Google Patents

Abstract

【課題】債権の活用を促進する情報処理システム、情報処理装置、サーバ装置、プログラム、又は方法を提供する。。
【解決手段】プログラムは、システムを、契約の履行状況に影響を与える情報を取得する取得手段、契約の履行状況に影響を与える情報を用いて、契約に係る債権についての割引に係る情報を生成する割引情報生成手段、として動作させる。また、契約の履行状況に影響を与える情報は、契約に関連付けられる、物又はサービスを含む契約対象についての契約履行の達成度に係る情報を含む。また、契約履行の達成度に係る情報は、契約が物の製造工程を含む場合、契約と関連付けられる対象物の製造状況に係る情報を含む。
【選択図】図１３

Description

本出願において開示された技術は、情報処理システム、情報処理装置、サーバ装置、プログラム、又は方法に関する。

債権は、金銭的価値を有することから、有効に利用することが望まれる。

特開２００２−７３９９６号公報 特開２００４−３１８７６８号公報

特許文献１は、債権に含まれるリスクを均一化する技術に係る。特許文献２は、ファクタリング装置に関する。しかしながら、債権は、不確実性な性質を有することから、債権が有効に利用できない場合があった。そこで、本発明の様々な実施形態は、上記の課題を解決するために、情報処理システム、情報処理装置、サーバ装置、プログラム、又は方法を提供する。

本願発明の第１実施例は、システムを、
契約の履行状況に影響を与える情報を取得する取得手段、
前記契約の履行状況に影響を与える情報を用いて、前記契約に係る債権についての割引に係る情報を生成する割引情報生成手段、
として動作させるためのプログラム。契約の履行状況に与える情報を用いることで、履行期前の債権についての割引に係る情報を効果的に生成できる利点がある。

本願発明の第２実施例は、
前記契約の履行状況に影響を与える情報は、前記契約に関連付けられる、物又はサービスを含む契約対象についての契約履行の達成度に係る情報を含む、
第１実施例のプログラム。契約履行の達成度に係る情報としては、後述の物流管理部で管理される種々の情報が挙げられるが、それらに限られず、履行の達成度を示す指標によって指示されるものであればよい。

本願発明の第３実施例は、
前記契約履行の達成度に係る情報は、前記契約が物の製造工程を含む場合、前記契約と関連付けられる対象物の製造状況に係る情報を含む、
第２実施例のプログラム。ここで、契約が、製造工程に加えて、移送や役務などの工程を含む場合、かかる移送や役務などの工程についての情報は、使用してもよいし、使用しなくともよい。

本願発明の第４実施例は、
前記契約履行の達成度に係る情報は、前記契約が物の移動工程を含む場合、前記契約と関連付けられる対象物の移動状況に係る情報を含む、
第２又は第３実施例のプログラム。ここで、契約が、移動工程に加えて、物の製造や役務などの工程を含む場合、かかる製造や役務などの工程についての情報は、使用してもよいし、使用しなくともよい。

本願発明の第５実施例は、
前記契約の履行状況に影響を与える情報は、前記契約と関連付けられた一又は複数の物に係る情報、を含み、
前記割引情報生成手段は、前記物に係る情報、を用いて、前記割引に係る情報を生成する、
第１乃至第４実施例のいずれか一のプログラム。

本願発明の第６実施例は、
前記割引情報生成手段は、前記契約に基づく金銭債権の債務引受によって同時に生じる二つの債権のうちの一の債権についての割引に係る情報を生成する、
第１乃至第５実施例のいずれか一のプログラム。

本願発明の第７実施例は、
前記二つの債権を第１債権と第２債権とした場合において、
前記第１債権及び前記第２債権を示す情報は、各々、各権利の有効又は無効を示すデータを格納するデータ構造を含み、
前記契約の金銭債権の履行日において、前記第１債権内の前記データ構造内と、前記第２債権内の前記データ構造内と、に各権利の無効を示すデータが同時に設定される、
第１乃至第６実施例のいずれか一のプログラム。

本願発明の第８実施例は、
前記システムを、
前記契約の債権者である第１当事者を示す情報と、債務者として第三者を示す情報と、を含む、第１債権を示す情報を生成する債権情報生成手段、
として動作させるためのプログラムであって、
前記割引情報生成手段が、前記第１債権についての割引に係る情報を生成した後、前記債権情報生成手段が、前記第１債権を示す情報と関連付けて、前記割引に係る情報を記録する、
第１乃至第７実施例のいずれか一のプログラム。

本願発明の第９実施例は、
前記システムを、
第三者に対して第１当事者が有する前記契約に基づいて生じた第１債権を示す情報と、
前記契約と同一商流の契約に基づいて前記第１当事者に対して前記第三者が有する第２債権を示す情報と、
を用いて、前記第１債権と前記第２債権とのうち債権額が小さい債権について、無効であることを示す情報を記憶する、又は、前記第１債権の債権額から前記小さい債権の債権額を減額しかつ前記第２債権の債権額から前記小さい債権の債権額を減額する、相殺手段、
として動作させるための第１乃至第８実施例のいずれか一のプログラム。

本願発明の第１０実施例は、
前記システムを、
前記契約に係る商流内において、所定の条件の下で、第三者に対して割引の請求が可能な地位を示すトークンデータを生成するトークン生成手段、
として動作させるための第１乃至第９実施例のいずれか一のプログラム。

本願発明の第１１実施例は、
前記トークン生成手段は、前記商流内において最初に生成する前記トークンデータの最初の保有者として、前記商流の最下流の当事者を債務者とした場合の債権者を示す情報を設定する、
第１乃至第１０実施例のいずれか一のプログラム。

本願発明の第１２実施例は、
前記トークンデータは、少なくとも、債権額を示す情報、前記地位の保有者を示す情報、及び、前記トークンデータに係る前記地位を過去に保有した全ての保有者を示す情報、を含む、
第１乃至第１１実施例のいずれか一のプログラム。

本願発明の第１３実施例は、
前記トークンデータは、前記割引の請求についての合意の有無を示す情報を含む、
第１乃至第１２実施例のいずれか一のプログラム。

本願発明の第１４実施例は、
前記合意の有無を示す情報は、第三者による同意の有無を示す情報と、前記トークンデータに係る地位の保有者による同意の有無を示す情報と、前記過去の地位の保有者による同意の有無を示す情報と、を含む
第１乃至第１３実施例のいずれか一のプログラム。

本願発明の第１５実施例は、
前記トークンデータは、前記トークンデータが示す前記地位が有効又は無効を示す情報を含む、
第１乃至第１４実施例のいずれか一のプログラム。

本願発明の第１６実施例は、
契約の履行状況に影響を与える情報を取得する取得部、
前記契約の履行状況に影響を与える情報を用いて、前記契約に係る債権についての割引に係る情報を生成する割引情報生成部、
を備えるシステム。

本願発明の第１７実施例は、
前記契約の履行状況に影響を与える情報は、前記契約に関連付けられる、物又はサービスを含む契約対象についての契約履行の達成度に係る情報を含む、
第１６実施例のシステム。

本願発明の第１８実施例は、
前記契約履行の達成度に係る情報は、前記契約が物の製造工程を含む場合、前記契約と関連付けられる対象物の製造状況に係る情報を含む、
第１６乃至第１７実施例のいずれか一のシステム。

本願発明の第１９実施例は、
前記契約履行の達成度に係る情報は、前記契約が物の移動工程を含む場合、前記契約と関連付けられる対象物の移動状況に係る情報を含む、
第１６乃至第１８実施例のいずれか一のシステム。

本願発明の第２０実施例は、
前記契約の履行状況に影響を与える情報は、前記契約と関連付けられた一又は複数の物に係る情報、を含み、
前記割引情報生成手段は、前記物に係る情報、を用いて、前記割引に係る情報を生成する、
第１６乃至第１９実施例のいずれか一のシステム。

本願発明の第２１実施例は、
前記割引情報生成部は、前記契約に基づく金銭債権の債務引受によって同時に生じる二つの債権のうちの一の債権についての割引に係る情報を生成する、
第１６乃至第２０実施例のいずれか一のシステム。

本願発明の第２２実施例は、
前記二つの債権を第１債権と第２債権とした場合において、
前記第１債権及び前記第２債権を示す情報は、各々、各権利の有効又は無効を示すデータを格納するデータ構造を含み、
前記契約の金銭債権の履行日において、前記第１債権内の前記データ構造内と、前記第２債権内の前記データ構造内と、に各権利の無効を示すデータが同時に設定される、
第１６乃至第２１実施例のいずれか一のシステム。

本願発明の第２３実施例は、
前記契約の債権者である第１当事者を示す情報と、債務者として第三者を示す情報と、を含む、第１債権を示す情報を生成する債権情報生成部、を備え、
前記割引情報生成部が、前記第１債権についての割引に係る情報を生成した後、前記債権情報生成手段が、前記第１債権を示す情報と関連付けて、前記割引に係る情報を記録する、
第１６乃至第２２実施例のいずれか一のシステム。

本願発明の第２４実施例は、
第三者に対して第１当事者が有する前記契約に基づいて生じた第１債権を示す情報と、
前記契約と同一商流の契約に基づいて前記第１当事者に対して前記第三者が有する第２債権を示す情報と、
を用いて、前記第１債権と前記第２債権のうち債権額が小さい債権について、無効であることを示す情報を記憶する、又は、前記第１債権の債権額から前記小さい債権の債権額を減額しかつ前記第２債権の債権額から前記小さい債権の債権額を減額する、相殺部、
第１６乃至第２３実施例のいずれか一のシステム。

本願発明の第２５実施例は、
前記契約に係る商流内において、所定の条件の下で、第三者に対して割引の請求が可能な地位を示すトークンデータを生成するトークン生成部
を備える第１６乃至第２４実施例のいずれか一のシステム。

本願発明の第２６実施例は、
前記トークン生成部は、前記商流内において最初に生成する前記トークンデータの最初の保有者として、前記商流の最下流の当事者を債務者とした場合の債権者を示す情報を設定する、
第１６乃至第２５実施例のいずれか一のシステム。

本願発明の第２７実施例は、
前記トークンデータは、少なくとも、債権額を示す情報、前記地位の保有者を示す情報、及び、前記トークンデータに係る前記地位を過去に保有した全ての保有者を示す情報、を含む、
第１６乃至第２６実施例のいずれか一のシステム。

本願発明の第２８実施例は、
前記トークンデータは、前記割引の請求についての合意の有無を示す情報を含む、
第１６乃至第２７実施例のいずれか一のシステム。

本願発明の第２９実施例は、
前記合意の有無を示す情報は、第三者による同意の有無を示す情報と、前記トークンデータに係る地位の保有者による同意の有無を示す情報と、前記過去の地位の保有者による同意の有無を示す情報と、を含む
第１６乃至第２８実施例のいずれか一のシステム。

本願発明の第３０実施例は、
前記トークンデータは、前記トークンデータが示す前記地位が有効又は無効を示す情報を含む、
第１６乃至第２９実施例のいずれか一のシステム。

本願発明の第３１実施例は、
コンピュータが、
契約の履行状況に影響を与える情報を取得する取得ステップ、
前記契約の履行状況に影響を与える情報を用いて、前記契約に係る債権についての割引に係る情報を生成する割引情報生成ステップ、
を実行する方法。

本願発明の第３２実施例は、
前記契約の履行状況に影響を与える情報は、前記契約に関連付けられる、物又はサービスを含む契約対象についての契約履行の達成度に係る情報を含む、
第３１実施例の方法。

本願発明の第３３実施例は、
前記契約履行の達成度に係る情報は、前記契約が物の製造工程を含む場合、前記契約と関連付けられる対象物の製造状況に係る情報を含む、
第３１乃至３２実施例のいずれか一の方法。

本願発明の第３４実施例は、
前記契約履行の達成度に係る情報は、前記契約が物の移動工程を含む場合、前記契約と関連付けられる対象物の移動状況に係る情報を含む、
第３１乃至３３実施例のいずれか一の方法。

本願発明の第３５実施例は、
前記契約の履行状況に影響を与える情報は、前記契約と関連付けられた一又は複数の物に係る情報、を含み、
前記割引情報生成ステップは、前記物に係る情報、を用いて、前記割引に係る情報を生成する、
第３１乃至３４実施例のいずれか一の方法。

本願発明の第３６実施例は、
前記割引情報生成ステップは、前記契約に基づく金銭債権の債務引受によって同時に生じる二つの債権のうちの一の債権についての割引に係る情報を生成する、
第３１乃至３５実施例のいずれか一の方法。

本願発明の第３７実施例は、
前記二つの債権を第１債権と第２債権とした場合において、
前記第１債権及び前記第２債権を示す情報は、各々、各権利の有効又は無効を示すデータを格納するデータ構造を含み、
前記契約の金銭債権の履行日において、前記第１債権内の前記データ構造内と、前記第２債権内の前記データ構造内と、に各権利の無効を示すデータが同時に設定される、
第３１乃至３６実施例のいずれか一の方法。

本願発明の第３８実施例は、
前記コンピュータが、
前記契約の債権者である第１当事者を示す情報と、債務者として第三者を示す情報と、を含む、第１債権を示す情報を生成する債権情報生成ステップ、
を実行する方法であって、
前記割引情報生成ステップが、前記第１債権についての割引に係る情報を生成した後、前記債権情報生成ステップが、前記第１債権を示す情報と関連付けて、前記割引に係る情報を記録する、
第３１乃至３７実施例のいずれか一の方法。

本願発明の第３９実施例は、
前記コンピュータが、
第三者に対して第１当事者が有する前記契約に基づいて生じた第１債権を示す情報と、
前記契約と同一商流の契約に基づいて前記第１当事者に対して前記第三者が有する第２債権を示す情報と、
を用いて、前記第１債権と前記第２債権のうち債権額が小さい債権について、無効であることを示す情報を記憶する、又は、前記第１債権の債権額から前記小さい債権の債権額を減額しかつ前記第２債権の債権額から前記小さい債権の債権額を減額する、相殺ステップ、
第３１乃至３８実施例のいずれか一の方法。

本願発明の第４０実施例は、
前記コンピュータが、
前記契約に係る商流内において、所定の条件の下で、第三者に対して割引の請求が可能な地位を示すトークンデータを生成するトークン生成ステップ、
第３１乃至３９実施例のいずれか一の方法。

本願発明の第４１実施例は、
前記トークン生成ステップは、前記商流内において最初に生成する前記トークンデータの最初の保有者として、前記商流の最下流の当事者を債務者とした場合の債権者を示す情報を設定する、
第３１乃至４０実施例のいずれか一の方法。

本願発明の第４２実施例は、
前記トークンデータは、少なくとも、債権額を示す情報、前記地位の保有者を示す情報、及び、前記トークンデータに係る前記地位を過去に保有した全ての保有者を示す情報、を含む、
第３１乃至４１実施例のいずれか一の方法。

本願発明の第４３実施例は、
前記トークンデータは、前記割引の請求についての合意の有無を示す情報を含む、
第３１乃至４２実施例のいずれか一の方法。

本願発明の第４４実施例は、
前記合意の有無を示す情報は、第三者による同意の有無を示す情報と、前記トークンデータに係る地位の保有者による同意の有無を示す情報と、前記過去の地位の保有者による同意の有無を示す情報と、を含む、
第３１乃至４３実施例のいずれか一の方法。

本願発明の第４５実施例は、
前記トークンデータは、前記トークンデータが示す前記地位が有効又は無効を示す情報を含む、
第３１乃至４４実施例のいずれか一の方法。

本願発明の第４６実施例は、
前記システムは、記憶装置を備える、
第１乃至１５実施例のいずれか一のプログラム。

本願発明の第４７実施例は、
前記システムは、演算装置を備える、
第１乃至１５及び４６実施例のいずれか一のプログラム。

本願発明の第４８実施例は、
前記システムは、記憶装置を備える、
第１６乃至３０実施例のいずれか一のシステム。

本願発明の第４９実施例は、
前記システムは、演算装置を備える、
第１６乃至３０及び４８実施例のいずれか一のシステム。

本願発明の第５０実施例は、
前記システムは、記憶装置を備える、
第３１乃至４５実施例のいずれか一の方法。

本願発明の第５１実施例は、
前記システムは、演算装置を備える、
第３１乃至４５及び５０実施例のいずれか一の方法。

本発明の一実施形態により、より適切に債権を有効利用できる。

図１は、一実施例に係る一のシステムの構成を示すブロック図である。 図２は、一実施例に係る一のシステムの構成を示すブロック図である。 図３は、一実施例に係るシステムの機能を示すブロック図である。 図４は、一実施例に係るシステムの機能を示すブロック図である。 図５は、一実施例に係るシステムのデータ構造を示す図である。 図６は、一実施例に係るシステムの対象とする商流の一例である。 図７は、一実施例に係るシステムのデータ構造を示す図である。 図８は、一実施例に係るシステムのデータ構造を示す図である。 図９は、一実施例に係るシステムの対象とする債権関係を示す一例である。 図１０は、一実施例に係るシステムの対象とするデータの遷移を示す一例である。 図１１は、一実施例に係るシステムの対象とするデータの関係を示す一例である。 図１２は、一実施例に係る一のシステムの構成を示すブロック図である。 図１３は、一実施例に係るシステムの処理するフローの一例である。 図１４は、一実施例に係るシステムに係るデータの関係を示す一例である。 図１５は、一実施例に係るシステムに係る商流の流れを示す一例である。

１．情報処理装置１０の各構成
本願発明に係るシステムは、情報処理装置を用いたものである。一例のシステムは、一又は複数の情報処理装置を用いてよい。複数の情報処理装置は、同一の団体が所有又は利用する情報処理装置であってもよいし、異なる複数の団体が所有又は利用する異なる場所に設置された情報処理装置であってもよい。また、情報処理装置は、中央集権的なものでもよいし、分散処理を可能とするものでもよい。複数の情報処理装置の場合、端末装置、サーバ、クラウド、などの種々のコンピューティングシステムが混在しているものであってもよい。また、情報処理装置は、汎用的な情報処理装置であってもよいし、専用的な情報処理装置であってもよい。情報処理装置は、例えば、ワークステーション、ノートパソコン、デスクトップパソコン、タワー型、ラップトップ型、などの種々の情報処理装置であってよい。端末装置は、携帯可能な端末装置であってよく、例えば、スマートフォン、PDA、携帯電話、ウェアラブルコンピュータ、などの種々の情報処理装置であってよい。なお、本願書類において、システムという用語は、単一の情報処理装置であってもよいし、又は、複数の情報処理装置から構成されるものであってよい。

ここでは、一例としての情報処理装置が備える基本的機能を含む装置を説明するが、本願発明に係るシステムに利用される情報処理装置は、以下で説明する情報処理装置にとどまらず、その一部の機能が強化されたり、一部の機能が省略されるなど、種々の態様の情報処理装置が利用されてよい。

情報処理装置１０は、図１のように、演算装置と記憶装置を備えてよい。かかる演算装置と記憶装置は、バスによって接続されてよい。また、情報処理装置は、外部と通信を可能とする通信ＩＦを備えてよい。通信ＩＦは、ネットワークと接続可能であってよい。また、情報処理装置１０は、入力装置、表示装置を備えてよい。

バスは、装置間で情報を伝達する機能を有する。バスは、演算装置、記憶装置、入力装置、表示装置、及び通信ＩＦの間の情報を伝達する機能を有してよい。

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

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

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

記憶装置は、本願発明に関連する命令を実行するプログラムを備えることができる。また、本願発明に関連する命令を実行する際に必要なデータを、適宜記録することもできる。また、記憶装置は、データベースを含んでもよい。

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

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

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

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

２．一例のシステムの概要
次に、上述の情報処理装置を用いた一例のシステムを、図２を用いて説明する。一例のシステムは、管理システム０１０を含んでよい。管理システム０１０は、対象について管理可能なように管理者端末０１１と接続可能であってよい。本図において、管理システム０１０は、直接、管理者端末０１１と接続されているが、ネットワーク０００などを介して、接続されてもよい。また、管理システムも、システムの一例であり、上述のとおり一又は複数の情報処理装置から構成されてよく、サーバ装置であったり、クラウドであったりしてよい。管理システムは、当事者Ａ乃至Ｃが扱う当事者端末００１、００２、００３、と接続可能であってよい。ここで、当事者端末として３つの例を示しているが、２つであってもよいし、４つ以上であってもよい。また、当事者Ａ乃至Ｃは、一の商流内の当事者であってよい。なお、管理システムは、かかる当事者Ａ乃至Ｃの一の商流とは異なる商流に属する、例えば、当事者Ｐ、Ｑ、Ｒ・・・が各々扱う当事者端末と接続し、同様に、かかる商流や後述する物流、金流、与信、決済などを管理してよい。この場合、商流毎に、商流を区別するＩＤなどを用いて、区別して管理してよい。

３．一例のシステムの機能
次に、一例のシステムにおける機能について、図３を参照して説明する。図３は、本例のシステムに係る機能の具体例を示すブロック図である。一例のシステムは、以下で説明する全ての機能を有してもよいし、その一部の機能であってもよい。また、各機能に関する情報を一覧にしたものが、図４である。なお、図４における所有データや商流管理部乃至決済部の各部の関係は一例であり、所有データはその一部である場合もあれば、他のデータを有する場合もある。また、商流管理部乃至決済部の各部の関係も各機能の必要に応じて、他の商流管理部乃至決済部の各部と情報のやり取りを行い、連携を取る場合がある。

また、以下では、分かりやすさの観点で、機能を分けて説明したが、その実装上、各機能がその単位毎に個別に実装されている必要性はなく、複数の機能が一の実装単位によって実装されてもよいし、一の機能が複数の実装単位で実装されてもよいし、複数の機能がその単位とは異なる単位で複数の実装単位で実装されてもよい。例えば、後述する金流管理部が管理するとされるＳＴ１、ＳＴ２、及び／又は、ＳＴ３の管理と、決済部における処理と、をスマートコントラクトを用いることで原子性をもって処理してもよい。例えば、ＳＴ１、ＳＴ２、及び／又は、ＳＴ３に対して割引処理を行う場合に、同時に、決済部におけるＳｔａｂｌｅ Ｃｏｉｎの発生処理を、スマートコントラクトにおいて定義してよい。これにより、システム上、ＳＴ１及び／又はＳＴ３の割引による減額後、これに対応して、必ず、割引実行額のＳｔａｂｌｅ Ｃｏｉｎが発生するように、一例のシステムを構成することもできる。

３．１．商流管理部３１
商流管理部３１は、一又は複数の商流に係る情報を管理する機能を有する。一の商流に係る情報は、一又は複数の契約に係る情報を含んでよい。契約に係る情報は、契約の当事者、契約の契約対象物、契約対象物の履行に係る情報、及び／又は、契約の対価に係る情報、を含んでよい。

図５は、商流管理部が管理する商流に係る情報の一例である。上述の商流に係る情報が、各商流について、契約に関連する情報が記憶されていることにより、各商流を整理して管理し、必要な場合に必要な情報を取得できる構成とされてよい。また、商流管理部は、商流管理部を備える管理システムに接続されている管理者端末に対して、かかる商流に係る情報を送信し、管理者端末においてかかる商流に係る情報を取得し、管理者端末においてかかる商流に係る情報を表示してよい。この場合、管理者端末を利用する管理者は、商流に係る情報を理解することができ、後述するとおり、与信判断において、管理者が関与する場合に、参考となる情報を取得できる利点がある。

商流管理部は、契約に係る情報を、システムの管理者が入力したことに対応して取得してもよいし、各商流の当事者端末の入力に対応して取得してもよいし、他の契約を管理するシステムと連携してかかる契約を管理するシステムから取得してもよい。

なお、本願書類において、商流とは、同一の契約対象物が、契約に基づいて移転する流れをいう。同一の契約対象物とは、契約対象物を一部に含んでもよい。例えば、Ａ社、Ｂ社、Ｃ社の間において、Ａ社が原材料をＢ社に提供し、Ｂ社が原材料から部品を製造して部品をＣ社に提供し、Ｃ社が部品から製品を提供する場合、Ａ社とＢ社とＣ社は、かかる原材料と部品と製品について、同一の商流であるといえる。また、契約対象物が同一の物である場合、Ａ社の有する物をＢ社に提供し、Ｂ社がかかる物をＣ社に提供する場合においても、Ａ社とＢ社とＣ社は、かかる物について、同一の商流であるといえる。

なお、図６は、同一の商流の例を示す図である。ここで、Ａ、Ｂ、Ｃ、Ｄ、Ｅは、契約当事者を示し、各矢印は、各当事者が物を移転する関係を示す。例えば、ＤとＣ間の矢印は、Ｄが保有している原材料がＣに移転されることを示し、ＣとＢ間の矢印は、Ｃがかかる原材料に基づいて製造した部品をＢに移転することを示し、ＢとＡ間の矢印は、Ｂが部品から製品を製造してＡに移転することを示してよい。同様に、ＤとＥ間の矢印は、Ｄが保有している原材料がＥに移転されることを示し、ＣとＥ間の矢印は、Ｃが製造した部品をＥに移転することを示し、ＥとＢ間の矢印は、Ｃから得た部品とＤから得た原材料からＥが製造した部品をＢに移転することを示してよい。ここで、Ａ乃至Ｅは、同一商流としてよい。本図のように、途中で契約の関係が分岐したり、合流しても、同一商流であってよい。なお、本願書類においては、このように、原材料、部品、製品と物の製造と共に物が移転する商流、又は、物の製造なしに物が移転する商流においては、物の移転を基準として、上流、下流という用語を使用する。すなわち、本図の例においては、物は、Ｄ、Ｃ、Ｂ、Ａと流れることから、Ｄが最上流であり、Ａが最下流であり、ＤよりもＣが下流、ＣよりもＢが下流、ＢよりもＡが下流という関係にある。また、ＥはＤよりも下流であり、ＥはＣよりも下流であり、ＢはＥよりも下流である。

なお、仮に商流管理部が、Ｅに関する情報（例えば、ＤＥ間の契約や後述の物流に関する情報、ＣＥ間の契約やその物流に関する情報）を管理できない事情があるとしても、残りのＡ、Ｂ、Ｃ、Ｄを同一商流として一例のシステムが適用されてよい。この場合、後述の与信判断部は、Ｅに関する情報がないという情報のように、同一商流内の一部の情報が欠けているという情報を用いて、割引に係る情報を生成してよい。例えば、同一商流内の一部の情報がないことが、割引に係る情報についての債権に係る契約の対象物の上流にある場合、かかる一部の情報がないことを、割引に係る情報を生成する際に利用してよい。

３．２．物流管理部３２
物流管理部は、物流に係る情報を管理する機能を有する。物流に係る情報は、契約対象の一又は複数の物に係る情報を含んでよい。物に係る情報は、物のＩＤ、物の性質を説明する情報、物の現在の位置、物の現在の所有者、物の現在の占有者、物の現在の管理者、契約履行時の物の状況に係る情報、及び／又は、物の現在の状況に係る情報を含んでよい。物の現在の状況に係る情報は、物の現在の製造状況に係る情報、及び／又は、物の現在の流通状況に係る情報、を含んでよい。

物の現在の製造状況に係る情報は、物を製造するために必要な材料や部品の調達に係る情報、物の製造工程に係る情報、及び／又は、物の検査工程に係る情報、などを含んでよい。

また、物の現在の流通状況に係る情報は、物の流通の各過程を特定する情報であってよい。例えば、物の受領、物の第１場所での保管、物の第１場所から第２場所への移動、物の第２場所での保管、物の発送準備、物の発送済み、などの情報であってよい。

なお、物の現在の所有者、物の現在の占有者、物の現在の管理者は、物の状況に係る情報を用いて、予め定められたルールによって、設定されてもよい。

契約履行時の物の状況に係る情報は、契約履行時の物の位置、契約履行時の物の占有者、契約履行時の物の所有者、及び／又は、契約履行時の物の管理者、などを含んでよい。

また、物に係る情報が、契約履行時の物の状況に係る情報を含む場合、後述の与信判断部が、契約履行時の物の状況に係る情報と、物の現在の状況に係る情報と、の対応する情報を用いて、契約の履行状況を数値化するのに使用できてよい。

また、物の現在の状況に係る情報は、上述の製造状況又は流通状況のように、定性的な情報で管理されてもよいし、かかる定性的な情報を用いて生成された定量的な情報が生成されてもよい。例えば、物の製造に係る場合は、原材料の調達と、製造と、検査と、出荷処理、などの全工程を１００とした場合において、各工程に割り当てられた数値によって、定性的なステップを、定量的な評価値としたものを含んでもよい。また、物の流通に係る場合は、物の受領、物の第１場所での保管、物の第２場所での保管、物の発送準備、物の発送済み、などの全工程を１００とした場合において、各工程に割り当てられた数値によって、定性的なステップを、定量的な評価値としたものを含んでもよい。

物流管理部の管理する物流に係る情報の一例は、図７である。本図において、契約ＩＤ１０１に対して、物ＩＤが少なくとも３つ関連付けられている。物流管理部は、一の契約に対して、複数の物についてＩＤを付して、管理してよい。すなわち、契約の単位と物の対応は、物の個数をＮとすると、１対Ｎの関係であってよい。かかる場合は、例えば、一の契約において、複数の部品を扱う場合などが考えられるが、どのように物のＩＤを割り振るかは、対象となる物の性質に応じて設定されてよい。例えば、契約において物が納入される場合、納入単位毎にＩＤが割り振られてもよいし、納入対象の部品毎にＩＤが割り振られてもよいし、納入時の搬送単位毎にＩＤが割り振られてもよい。また、物が原材料や液体のように、用量で分量が特定される場合、かかる容量の特定の単位に対して、ＩＤが割り振られてもよい。

他方、契約ＩＤ１０２に対しては、物ＩＤが１つのみ関連付けられている。このように、物流管理部は、一の契約に対して、一のＩＤを付して、管理してもよい。例えば、契約が、一の物の移送に係る場合、物自体に対して製造などがされないことから、かかる物が同一のＩＤで割り振られて、使用されてもよい。一の商流に対し、複数の契約があるとしても、かかる複数の契約に対して、一の物としての、一の物のＩＤが割り振られてよい。すなわち、この場合、商流のＩＤと、契約のＩＤと、物のＩＤとの関係は、１：Ｎ：１の関係になってもよい。

また、上述の物流に係る情報において、物の占有者や物の管理者は、一例のシステムで扱う契約の当事者でないものが含まれてもよい。例えば、物が運送業者によって運送されている場合、商流に係る契約の当事者とは異なる者が占有者となる場合もあるが、かかる場合においても、例えば、物流に係る情報において、物の運送中、というステータスとして、設定されてよく、かかる状況であっても、後述の与信判断部は機能してよい。

なお、上述の物流に係る情報は、一例のシステムとネットワーク等を介して接続されることで、各契約の当事者の当事者端末や当事者の運用する装置から情報が自動的に取得されてもよい。例えば、物の製造であれば、管理システムが、ネットワークを介して、製造装置や検査装置などと、接続可能であり、かかる装置から情報を取得してもよい。すなわち、物の原材料からの加工の進行状況、物の製造の進行状況、物の検査の進行状況などの情報を、製造装置や検査装置が生成した場合、かかる情報が、管理システムに接続されることによって、上述の物流に係る情報として、記憶されてよい。また、物の流通であれば、管理システムは、かかる物を運送する運送業者が運用する運送管理システムから情報を取得したり、かかる物に備えられた位置情報を提供装置から取得するなどにより、物流に係る情報を取得してもよい。管理システムが、これらの製造装置、検査装置、運送管理システムなどから、物流に係る情報を取得できる場合、物流に係る情報を正確かつリアルタイムに取得できる利点がある。また、これらの技術に代えて、又は、これらの技術と共に、かかる物の製造又は流通に係る当事者が当事者端末に入力したこれらの情報を、管理システムが取得することにより、管理システムは、物流に係る情報を取得してもよい。この場合、当事者に係る装置やシステムが、セキュリティ上の理由や不完全な自動化などにより管理システムが全ての物流に係る情報を自動的に取得できない場合においても、当事者端末に入力された情報を用いて、管理システムが、物流に係る情報を取得し、後述の割引に係る情報をより精度高く生成できる利点がある。

物流管理部は、物流に係る情報を、分散型のネットワークを用いて管理してもよいし、中央集権的なデータベースを用いて管理してもよい。前者においては、例えば、イーサリウム、ビットコイン、などのブロックチェーン技術を用いて記録してもよい。後者においては、暗号化されたデータベースなどの情報を安全に管理可能なシステムであってよい。また、物流管理部は、物流に係る情報を、ブロックチェーン技術においては、ＮＦＴ（Ｎｏｎ Ｆｕｎｇｉｂｌｅ Ｔｏｋｅｎ）として記憶してよい。

３．３．金流管理部３３
金流管理部は、金流に係る情報を管理する機能を有する。金流に係る情報は、債権に係る情報を含んでよい。債権に係る情報は、債権を特定するＩＤ、債務者を示す情報、債権者を示す情報、債権金額を示す情報、債権の支払い期日、債権の移転日、債権の移転の価格、及び／又は、債権の有効又は無効を示す情報、を含んでよい。

債権に係る情報における債権は、一の契約に対して、２つの債権であってよい。すなわち、一の契約ＩＤと、２つの債権に係る情報が、関連付けられて生成されてよい。

かかる２つの債権は、一の契約に対して、免責的債務引受によって生じる２つの債権であってよい。例えば、当事者Ｂが製造した部品を当事者Ａに譲渡する製造委託契約において、当事者Ｂが当事者Ａに対して、かかる物の製造委託の対価としての金銭債権Ｘを取得するとする。このとき、第三者Ｚが金銭債権Ｘについて債務引受をすることにより、当事者Ｂが第三者Ｚに対して有する債権と、第三者Ｚが当事者Ａに対して有する債権と、が生じうると考えることができてよい。

一つ目の債権は、第三者を債務者として、契約の金銭債権の債権者が、有する債権である。かかるタイプの債権を示すデータ情報を、本願書類においては、ＳＴ１と称することがある。ここで、ＳＴ１が含むデータは、かかる債権の発生又は有効性と直接的な関係を有する構成としてもよいし、直接的な関係を有しない構成としてもよいし、一部直接的な関係を有し一部直接的な関係を有しない構成としてもよい。一部直接的な関係を有し一部直接的な関係を有しない構成としては、例えば、ＳＴ１が示すデータが権利の発生とは連動しないがＳＴ１が示すデータが権利の消滅と連動する、などの構成が考えられる。 ＳＴ１は、ＩＤ、本債権の債務者である第三者を示す情報、本債権の債権者であって商流内の契約当事者を示す情報、本債権として利用可能な金額、本債権の支払い期日、本債権の債権移転日、及び／又は、本債権の移転価格、を含んでよい。ここで、本債権として利用可能な金額は、例えば、上述のＢＡ間の製造委託契約においては、金銭債権Ｘの金額が、当初設定されてよい。また、債権の割引や相殺により、かかる債権の示す金額が減額される場合は、対応して残る債権の示す残額を示してよい。また、ＳＴ１は、債権の履行の可否を示す情報を含んでもよい。

なお、ＳＴ１内のデータは、その公開先として、ＳＴ１内の第三者を示す情報における第三者及び債権者を示す情報における債権者のみに公開されてもよいし、かかる債権者の下流の者への公開でもよいし、ＳＴ１に係る同一商流内の当事者全員への公開であってもよいし、ＳＴ１に係る商流と異なる商流内の当事者全員への公開であってもよいし、商流外の者への公開であってもよい。また、公開される場合のデータも、ＳＴ１内の全てのデータが公開されてもよいし、その一部のデータのみが公開されてもよい。また、公開先毎に、公開される対象が異なってもよい。例えば、ＳＴ１に係る商流と異なる商流内の当事者に対しては、ＳＴ１に係る当事者のみが公開される一方、ＳＴ１に係る同一商流内の当事者全員に対しては、金額も含めた公開、などであってよい。また、公開する場合において、公開の時期が制限されてもよい。例えば、公開の始期と終期が定められていてもよい。また、公開の時期は、公開先毎に決められてもよいし、公開されるデータ毎に決められてもよい。ＳＴ１内の情報が公開される場合、閲覧可能な者によるガバナンスを強化できる利点がある。他方、公開を制限する場合、ビジネス上の戦略で商流の直接の当事者以外に価格及び／又は取引自体を知らせない利点がある。

また、ＳＴ１は、一又は複数の同意に係る情報、を含んでもよいし、含まなくてもよい。同意に係る情報は、ＳＴ１が生じた商流の下流の当事者による同意を示す情報であってよい。例えば、ＳＴ１が上述の物の製造委託契約における金銭債権Ｘについて生成された場合において、当事者Ｂの下流である当事者Ａの同意を示す情報が含まれてもよい。また、当事者Ａのみならず、ＳＴ１に係る商流における当事者Ａの一つ下流の当事者など、ＳＴ１に係る商流における下流の複数の当事者の同意を、各々、記憶できるものであってもよい。また、ＳＴ１に係る商流の、最下流の当事者の同意のみを記憶できるものであってもよい。ＳＴ１が、同意に係る情報、を含む場合において、特に、ＳＴ１が生じる元となった金銭債権Ｘの債務者Ａによる同意を示す情報を含む場合、債務引受の法律構成を採用する場合における、かかる債務者Ａの同意をデータとして格納できる利点がある。また、同様に、ＳＴ１が、かかる債務者Ａの更に下流の一又は複数の当事者の同意を示す情報を含む場合、実務上、かかる債務者の同意をデータとして格納できる利点がある。なお、上述では、ＳＴ１自身が、同意に係る情報を含む例を説明したが、これに代えて、又は、これと共に、ＳＴ１内ではない管理システム内等において、かかる情報が記録されてもよい。他方、例えば、契約上、予め同意を得られている場合等においては、かかる同意に係る情報が格納されなくてもよい。なお、かかる同意に係る情報は、同意を与えることができる当事者のみから同意を示す情報を格納できる構成とされてよい。

二つ目の債権は、かかる契約の金銭債権の債務者を債務者として、かかる第三者が有する債権である。かかるタイプの債権を示すデータ情報を、本願書類においては、ＳＴ２と称することがある。ＳＴ２についても、ＳＴ１と同様に、ＳＴ２が含むデータは、かかる債権の発生又は有効性と直接的な関係を有する構成としてもよいし、直接的な関係を有しない構成としてもよいし、一部直接的な関係を有し一部直接的な関係を有しない構成としてもよい。一部直接的な関係を有し一部直接的な関係を有しない構成としては、例えば、ＳＴ２が示すデータが権利の発生とは連動しないがＳＴ２が示すデータが権利の消滅と連動する、などの構成が考えられる。ＳＴ２は、ＩＤ、本債権の債務者であって商流内の契約当事者を示す情報、本債権の債権者である第三者を示す情報、本債権として利用可能な金額、本債権の支払い期日、本債権の債権移転日、及び／又は、本債権の移転価格、を含んでよい。ここで、本債権として利用可能な金額は、例えば、上述のＢＡ間の製造委託契約においては、金銭債権Ｘの金額が、当初設定されてよい。また、ＳＴ２は、債権の履行の可否を示す情報を含んでもよい。

なお、ＳＴ２内のデータも、ＳＴ１内のデータと同様に、その公開先として、ＳＴ２内の第三者を示す情報における第三者及び債権者を示す情報における債権者のみに公開されてもよいし、かかる債権者の下流の者への公開でもよいし、ＳＴ２に係る同一商流内の当事者全員への公開であってもよいし、ＳＴ２に係る商流と異なる商流内の当事者全員への公開であってもよいし、商流外の者への公開であってもよい。また、公開される場合のデータも、ＳＴ２内の全てのデータが公開されてもよいし、その一部のデータのみが公開されてもよい。また、公開先毎に、公開される対象が異なってもよい。例えば、ＳＴ２に係る商流と異なる商流内の当事者に対しては、ＳＴ２に係る当事者のみが公開される一方、ＳＴ２に係る同一商流内の当事者全員に対しては、金額も含めた公開、などであってよい。また、公開する場合において、公開の時期が制限されてもよい。例えば、公開の始期と終期が定められていてもよい。また、公開の時期は、公開先毎に決められてもよいし、公開されるデータ毎に決められてもよい。ＳＴ２内の情報が公開される場合、閲覧可能な者によるガバナンスを強化できる利点がある。他方、公開を制限する場合、ビジネス上の戦略で商流の直接の当事者以外に価格及び／又は取引自体を知らせない利点がある。なお、ＳＴ２の公開先、公開時期、公開対象データは、ＳＴ１の公開先の対応する情報と同じであってもよいし、異なってもよい。

また、ＳＴ２も、ＳＴ１と同様に、一又は複数の同意に係る情報、を含んでもよいし、含まなくてもよい。同意に係る情報は、ＳＴ２が生じた商流の下流の当事者による同意を示す情報であってよい。例えば、ＳＴ２が上述の物の製造委託契約における金銭債権Ｘについて生成されたＳＴ１に対応して生成された場合において、当事者Ｂの下流である当事者Ａの同意を示す情報が含まれてもよい。また、当事者Ａのみならず、ＳＴ２に係る商流における当事者Ａの一つ下流の当事者など、ＳＴ２に係る商流における下流の複数の当事者の同意を、各々、記憶できるものであってもよい。また、ＳＴ２に係る商流の、最下流の当事者の同意のみを記憶できるものであってもよい。なお、上述では、ＳＴ２自身が、同意に係る情報を含む例を説明したが、これに代えて、又は、これと共に、ＳＴ２内ではない管理システム内等において、かかる情報が記録されてもよい。他方、例えば、契約上、予め同意を得られている場合等においては、かかる同意に係る情報が格納されなくてもよい。なお、かかる同意に係る情報は、同意を与えることができる当事者のみから同意を示す情報を格納できる構成とされてよい。

図８は、ＳＴ１及びＳＴ２のデータ構造を模式化した一例である。ＳＴ１及びＳＴ２は、一例のシステム内において、同一のデータ構造を有していてもよいし、異なる構造を有していてもよい。例えば、ＳＴ１は、他社に対して移転しない構成とする場合、債権移転日や債権移転価格のデータ構造を有しなくてよい。

また、ＳＴ１及び／又はＳＴ２の上述の債権の履行の可否を示すデータは、種々のデータを格納してよく、また、どのような法的な意味づけとするかは、法的整理との関係で決定されてもよく、さらに、そのデータ構造内の情報に応じて、ＳＴ１及び／又はＳＴ２に対する処理が変更されてよい。

例えば、一の法的整理としては、ＳＴ１の示す債権とＳＴ２の示す債権が、上述の例の製造委託契約から生じた金銭債権について、第三者との間に債務引受契約によって同時に生じた二つの債権であるとした場合を考える。すなわち、ＳＴ１が示す債権が、免責的債務引受された権利を示し、ＳＴ２が示す債権が、かかるＳＴ１が示す債権についての割引又は相殺を停止条件とする引受代金債権を示す場合である。この場合、例えば、ＳＴ１及びＳＴ２は、各データが示す債権についての割引又は相殺がされた時点で、夫々、権利が履行不可能であることを示す情報を含むよう設定されてよい。ここで、相殺は、図９のように、債務引受によって生じた金銭債権に基づく債権を示すＳＴ１と生じた引受代金債権を示すＳＴ２について、互いに相対する債権者と債務者間で生じうるものである。また、ＳＴ２は、かかるＳＴ１の割引又は相殺がされた時点で、権利が履行可能であることを示す情報を含むよう設定されてよい。この点、ＳＴ２が上述のとおり停止条件付引受代金債権として構成される場合、ＳＴ２についての債権の停止条件が成立していない状態を示す情報として、権利が履行不可能であることを示す情報が設定されてよい。また、かかる免責的債務引受契約において、上述の製造委託契約における金銭債権Ｘの履行期が到来したとき（履行期の前日が経過したとき）、免責的債務引受の効力が将来に向かって消滅する旨が規定されている場合、かかる履行期が到来したとき、ＳＴ１及びＳＴ２は、権利が履行不可能であることを示す情報を含むよう設定されてよい。このような場合、一例のシステムは、ＳＴ１及びＳＴ２のそれぞれについて、権利が履行可能であることを示す情報を含む場合に限り、対応するＳＴ１及びＳＴ２の金額の減額処理が可能であるよう構成され、権利が履行不可能であることを示す情報を含む場合は、対応するＳＴ１及びＳＴ２の金額の減額処理ができないよう構成されてよい。なお、上述の製造委託契約等の現実の契約関係においては、債務者が破産して、債権の回収が困難になる場合もある。このようなケースへの対応のため、例えば、上述における金銭債権Ｘの債務者が破産した場合、すなわちかかる債務者が破産したことの情報を取得した場合、一例のシステムは、かかる金銭債権Ｘに基づくＳＴ１に対し、権利が履行不可能であることを示す情報を設定する、よう構成されてよい。

なお、上述の法的構成は、一例にすぎず、他の法的構成を採用してもよい。また、上述の例においては、ＳＴ１及びＳＴ２における債権の履行の可否のデータとして、債権の履行可能と履行不可能という２つの選択肢の一の情報を格納するためのデータとして説明したが、これに限らず、３以上の選択肢の情報を格納できるよう構成してもよい。例えば、権利の有効／無効、権利の履行の可否、権利の未履行／履行済み、又は、これらの組み合わせ、などであってもよい。また、ＳＴ１及びＳＴ２がそれぞれ有する情報の格納の数も、上述のように、債権の履行の可否、という１つの格納場所に限らず、２つ以上の情報の格納場所を、ＳＴ１及びＳＴ２の各々が有するよう構成してもよく、またその格納場所の数は、ＳＴ１とＳＴ２とが同一であってもよいし異なってもよい。また、各法的構成に応じて、データ構造及びかかるデータ構造に対するデータ処理の条件についての情報処理を規定してもよい。

なお、ＳＴ１が有する金額は、ＳＴ１が示す金銭債権としての金額であってよい。そのため、かかる債権についての一部割引又は相殺がされた場合、割引又は相殺がされていない部分の金銭債権の金額が記憶されてよい。なお、割引又は相殺などにより、複数回、金額が利用される可能性がある場合、ＳＴ１及びＳＴ２のデータ構造内ではない情報処理装置内において、ＳＴ１及び／又はＳＴ２の利用履歴が管理されてよい。かかる利用履歴は、ＳＴ１及び／又はＳＴ２を特定する情報と、割引や相殺により利用された一又は複数の金額と、を関連付けられたデータを含んでよい。また、かかる利用履歴は、金額の減少が生じた日、減額の生じた原因についての情報（例えば、割引や相殺）を含んでもよい。かかる利用履歴を参照することにより、一例のシステムは、ＳＴ１及び／又はＳＴ２が示す金額の経緯を管理し、端末からの要請に応じて、表示可能な利点がある。

一例のシステムの金流管理部は、上述の商流管理部に記憶されている各商流に係る情報を用いて、ＳＴ１及びＳＴ２を生成してよい。一例のシステムの金流管理部は、商流管理部が商流に係る情報を取得したことに対応して、ＳＴ１及びＳＴ２を生成してよい。この場合、金流管理部は、ＳＴ１及びＳＴ２を同時に生成してよい。また、金流管理部は、商流管理部が商流に係る情報を取得した時点とは異なるタイミングにＳＴ１及びＳＴ２を生成してもよい。例えば、金流管理部は、ＳＴ１及びＳＴ２に係る金銭債権が発生する当事者間の契約の締結日や、かかる金銭債権が発生する当事者間の契約が含まれる商流における当事者間の契約の最も早い契約の締結日や、かかる金銭債権に対応する債務の履行期、など種々の時点において生成してもよい。また、この場合、ＳＴ１及びＳＴ２を同時に生成してもよいし、異なる時点で生成してもよい。

また、ＳＴ１は、割引についての合意を示す情報、を含んでよい。かかる割引についての合意は、ＳＴ１が示す金銭債権の債権者による割引に対する同意に係る情報と、ＳＴ１が示す金銭債権の債務者による割引に対する同意の有無に係る情報と、を含んでよい。金流管理部は、ＳＴ１の生成時点において、かかる情報を、割引に対し合意していない情報を示す情報を設定してよい。金流管理部は、金銭債権の債権者から、割引に同意する情報を取得した場合、かかるＳＴ１が示す金銭債権の債権者による割引に対する同意を示す情報に、同意の情報を設定してよい。そして、金流管理部は、ＳＴ１が示す金銭債権の債務者による割引に対する同意の情報を取得した場合、かかるＳＴ１が示す金銭債権の債務者による割引に対する同意を示す情報に、同意の情報を設定してよい。なお、このように、債権者から割引に同意する情報を取得することで割引に対する同意の情報を設定するのは、割引に係る情報が自動的に生成される場合であって良い。

また、他の態様として、ＳＴ１は、割引についての合意を示す情報として、ＳＴ１が示す金銭債権の債権者による割引に対してリクエストを示す情報と、ＳＴ１が示す金銭債権の債務者による割引に対する同意を示す情報と、ＳＴ１が示す金銭債権の債権者による割引に対する同意を示す情報と、を含んでよい。本態様においても、金流管理部は、ＳＴ１を生成する時点において、各々、リクエストをしていない情報、債務者による割引に対する同意をしていない情報、債権者による割引に対する同意をしていない情報、を設定してよい。金流管理部は、金銭債権の債権者から、割引に対するリクエストの情報を取得した場合、ＳＴ１が示す金銭債権の債権者による割引に対してリクエストを示す情報に、リクエストを示す情報を設定してよい。また、金流管理部は、ＳＴ１が示す金銭債権の債務者による割引に対する同意の情報を取得した場合、かかるＳＴ１が示す金銭債権の債務者による同意を示す情報に、同意の情報を設定してよい。この場合、後述の与信判断部は、割引に係る情報を生成し、かかる金銭債権の債権者に対して、かかる割引に係る情報を提示してよい。さらに、金流管理部は、かかるＳＴ１が示す金銭債権の債権者による同意を示す情報を取得した場合に、かかる同意の情報を設定してよい。

また、ＳＴ１及び／又はＳＴ２は、ＳＴ１及び／又はＳＴ２の割引について、ＳＴ１及び／又はＳＴ２に係る商流の下流に係る当事者の同意を示す情報を含んでよい。かかる下流に係る当事者は、全ての下流の当事者であってもよいし、その一部の下流の当事者であってもよい。かかる構成により、割引率算出において参照する下流の当事者を特定できる利点がある。かかる下流の当事者を特定できることにより、第三者とかかる商流の当事者との間において相殺を行う場合における範囲を特定できる利点がある。より具体的には、ＳＴ１及び／又はＳＴ２に係る当事者から順に下流に同意の有無が判定され、同意をしない当事者における割引率が適用されてよい。もしくは、ＳＴ１及び／又はＳＴ２に係る当事者が下流の当事者を特定し、ＳＴ１及び／又はＳＴ２に係る当事者から特定された下流の当事者まで順に下流に同意の有無が判定され、特定された下流の当事者もしくは同意をしない当事者における割引率が適用されてもよい。なお、かかるＳＴ１及び／又はＳＴ２に係る商流の下流に係る当事者の同意を示す情報は、ＳＴ１及び／又はＳＴ２内と共に又は代えて、ＳＴ１内ではなくかつＳＴ２内ではない情報処理装置内に記録されてもよい。

また、金流管理部は、ＳＴ１及び／又はＳＴ２が示す金銭債権を生じさせた契約におけるかかる金銭債権の履行期において、かかるＳＴ１及び／又はＳＴ２が、ＳＴ１及び／又はＳＴ２が示す金銭債権の履行が可能である又は可能ではないことを示す情報を含む場合、かかる情報について、履行が可能ではないことを示す情報を設定してよい。この場合、履行期を含む履行期以降は、割引又は相殺などのＳＴ１及び／又はＳＴ２に基づく処理ができないことを明確化できる利点がある。なお、かかる場合において、金流管理部は、ＳＴ１及びＳＴ２について、同時に、上述の、履行が可能ではないことを示す情報を設定してよい。

金流管理部は、また、一の商流について、第三者に対して割引の請求が可能な地位を示すトークンデータを生成してよい。本願書類において、かかるデータを、ＳＴ３ということもある。一の商流内において、最初に生成されるトークンデータは、商流の最下流の当事者を債務者とした場合の債権者を保有者として、生成されてよい。すなわち、一の商流内において、最初に生成されるトークンデータの保有者として、商流の最下流の当事者を債務者とした場合の債権者を示す情報を設定してよい。かかる構成の場合、最下流への信頼をベースとして、かかるトークンデータの保有者に対する割引に対し、第三者は債権の割引などを実行できる。

なお、ＳＴ３内のデータも、ＳＴ１及びＳＴ２内のデータと同様に、その公開先として、ＳＴ２内の第三者を示す情報における第三者及び債権者を示す情報における債権者のみに公開されてもよいし、かかる債権者の下流の者への公開でもよいし、ＳＴ３の地位の保有者のみの公開でもよいし、ＳＴ３に係る同一商流内の当事者全員への公開であってもよいし、ＳＴ３に係る商流と異なる商流内の当事者全員への公開であってもよいし、商流外の者への公開であってもよい。また、公開される場合のデータも、ＳＴ３内の全てのデータが公開されてもよいし、その一部のデータのみが公開されてもよい。また、公開先毎に、公開される対象が異なってもよい。例えば、ＳＴ３に係る商流と異なる商流内の当事者に対しては、ＳＴ３に係る当事者のみが公開される一方、ＳＴ３に係る同一商流内の当事者全員に対しては、金額も含めた公開、などであってよい。また、公開する場合において、公開の時期が制限されてもよい。例えば、公開の始期と終期が定められていてもよい。また、公開の時期は、公開先毎に決められてもよいし、公開されるデータ毎に決められてもよい。ＳＴ３内の情報が公開される場合、閲覧可能な者によるガバナンスを強化できる利点がある。他方、公開を制限する場合、ビジネス上の戦略で商流の直接の当事者以外に価格及び／又は取引自体を知らせない利点がある。なお、ＳＴ３の公開先、公開時期、公開対象データは、ＳＴ１及びＳＴ２の公開先の対応する情報と同じであってもよいし、異なってもよい。

ＳＴ３は、債権額を示す情報、を含んでよい。かかる債権額を示す情報について、一の商流内で最初に生成されたＳＴ３においては、一の商流内の最下流の当事者を債務者とする金銭債務に対応する金銭債権が債務引受されることで生成されたＳＴ２に基づいてよい。すなわち、かかるＳＴ３に係る債権額を示す情報は、ＳＴ２と同額の債権額が設定されてよい。かかる債権額は、一の商流内の最下流の当事者を債務者とする金銭債務の債務額と同一であってよい。

ＳＴ３は、第三者に対して割引の請求が可能な地位の保有者を示す情報を含んでよい。なお、一の商流内で最初に生成された場合、上述のとおり、かかる地位の保有者は、一の商流内の最下流の当事者を債務者とする金銭債務に対応する金銭債権の債権者であってよい。

また、ＳＴ３は、かかる地位の保有者の指示に基づき、同一商流内の他の当事者に移転可能であってよい。金流管理部は、かかる地位の保有者に係る当事者端末から、かかる移転の指示を取得した場合、移転先の当事者を示す情報を、ＳＴ３内の地位の保有者を示す情報に設定してよい。

なお、かかる地位の保有者は、ＳＴ３の示す債権額の全ての額について、移転してもよいし、その一部の額について、移転してもよい。前者は、上述の通りの処理となる。他方、後者の場合、金流管理部は、移転される一部の額についての債権額を示す情報と、移転先の当事者についての地位の保有者を示す情報と、を含むＳＴ３を生成してよい。また、移転前の元のＳＴ３については、債権額を示す情報として移転後の減額された額を設定してよい。

金流管理部は、上述の移転の際、過去の保有者を、各ＳＴ３に含ませるよう処理してよい。すなわち、ＳＴ３は、ＳＴ３に係る地位を過去に保有した全ての保有者を示す情報、を含んでよい。金流管理部は、上述の移転の場合、同一の商流であることを示す同一商流内の共通のＩＤと、分割して移転されたことを示すサブのＩＤと、をＳＴ３内に設定してよい。そして、分割移転の場合、金流管理部は、移転先の当事者を、現在の地位の保有者として、地位の保有者を示す情報としてＳＴ３に設定し、また、過去に保有した全ての保有者に、移転元の当事者を加えて、過去に保有した全ての保有者を示す情報を、ＳＴ３内に設定してよい。

例えば、図１０は、かかるＳＴ３の分割移転の一例を示す図である。本図において、Ａは、一の商流内の最下流の当事者を債務者とする金銭債権の債権者であり、かかる商流内で最初に生成されるＳＴ３における地位の保有者であってよい。ここで、ＳＴ３は、金額として１００が設定されているとする。このとき、当事者Ａは、任意の希望のタイミングにより、かかる１００を分割して、当事者Ｂや当事者Ｃに移転してよい。なお、当事者ＢやＣは、同一商流内において、当事者Ａが直接契約関係にある者であってもよいし、かかる契約関係が直接ない同一商流内の当事者であってもよい。

当事者Ａが、１００のうち、６０を当事者Ｂに移転し、３０を当事者Ｃに移転し、残りの１０を保有し続ける場合を考える。また、当事者Ａを地位の保有者として生成されたＳＴ３のＩＤをＰ０であるとし、当事者Ｂを地位の保有者として新たに生成されたＳＴ３のサブのＩＤをＰ１とし、当事者Ｃを地位の保有者として新たに生成されたＳＴ３のサブのＩＤをＰ２とする。このとき、ＳＴ３のＰ１は、債権額を示す情報として６０を含み、現在の地位の保有者を示す情報として当事者Ｂを示す情報を含み、過去の保有者を示す情報として当事者Ａを示す情報を含んでよい。同様に、ＳＴ３のＰ２は、債権額を示す情報として３０を含み、現在の地位の保有者を示す情報として当事者Ｃを示す情報を含み、過去の保有者を示す情報として当事者Ａを示す情報を含んでよい。

次に、当事者Ｂは、６０のうち、４０を当事者Ｄに移転し、２０を保有し続ける場合を考える。当事者Ｄを地位の保有者として新たに生成されたＳＴ３のサブのＩＤをＰ１１とする。このとき、ＳＴ３のＰ１は、債権額を示す情報として２０が設定され、現在の地位の保有者を示す情報として当事者Ｂを示す情報を含み、過去の保有者を示す情報として当事者Ａを示す情報を含んでよい。同様に、ＳＴ３のＰ１１は、債権額を示す情報として４０が設定され、現在の地位の保有者を示す情報として当事者Ｄを示す情報を含み、過去の保有者を示す情報として当事者Ａ及びＢを示す情報を含んでよい。

また、当事者Ｃは、３０のうち、１０を当事者Ｄに移転し、１５を当事者Ｅに移転し、５を保有し続ける場合を考える。当事者Ｄを地位の保有者として新たに生成されたＳＴ３のサブのＩＤをＰ２１とし、当事者Ｅを地位の保有者として新たに設定されたＳＴ３のサブのＩＤをＰ２２とする。このとき、ＳＴ３のＰ２は、債権額を示す情報として５が設定され、現在の地位の保有者を示す情報として当事者Ｃを示す情報を含み、過去の保有者を示す情報として当事者Ａを示す情報を含んでよい。同様に、ＳＴ３のＰ２１は、債権額を示す情報として１０が設定され、現在の地位の保有者を示す情報として当事者Ｄを示す情報を含み、過去の保有者を示す情報として当事者Ａ及びＣを示す情報を含んでよい。同様に、ＳＴ３のＰ２２は、債権額を示す情報として１５が設定され、現在の地位の保有者を示す情報として当事者Ｅを示す情報を含み、過去の保有者を示す情報として当事者Ａ及びＣを示す情報を含んでよい。

なお、上述において、過去の地位の保有者を示す情報とは、過去のＳＴ３のＩＤやサブＩＤを含んでよい。これらも、間接的に過去の地位の保有者を示す情報であるためである。

また、かかるトークンデータは、前記割引の請求についての合意の有無を示す情報を含んでよく、かかる合意の有無を示す情報は、第三者による同意の有無を示す情報と、前記トークンデータに係る債権の保有者による同意の有無を示す情報と、前記過去の地位の保有者による同意の有無を示す情報と、を含んでよい。かかるトークンデータが、過去の地位の保有者による同意の有無を示すことにより、かかるトークンデータが割引の地位の請求を行う際に、過去の地位の保有者もかかる割引について同意の有無を確認できる利点がある。また、同一商流内においてかかる地位を過去の保有した全ての保有者を示す情報を有することで、割引にあたり同意に必要なかかる過去の全ての地位の保有者を特定し、比較することで、過去に地位を保有した保有者が割引に同意したかどうかを確認できる利点がある。なお、ＳＴ３が、同一商流内においてかかる地位を過去の保有した全ての保有者を示す情報を有する場合、かかる情報は、相殺をする場合に、相殺すべき債権を遡って特定するために使用されてよい。

金流管理部は、ＳＴ３の生成する時点において、上述のＳＴ１と同様に、合意の有無を示す情報について、割引に対し合意していない情報を示す情報を設定してよい。また、上述のＳＴ１と同様に、金流管理部は、ＳＴ３に係る地位の保有者に係る当事者端末から割引に合意する情報を取得した場合、かかるＳＴ３に係る保有者による同意の情報を設定してよい。また、金流管理部は、ＳＴ３に係る第三者による割引に対する同意の情報を取得した場合、かかるＳＴ３に係る第三者による同意を示す情報に、同意の情報を設定してよい。また、金流管理部は、ＳＴ１とは異なり、ＳＴ３においては、ＳＴ３に係る過去の地位の保有者から割引に対する同意の情報を取得した場合、かかる過去の全ての保有者による合意を示す情報に、同意の情報を設定してよい。この場合、金流管理部は、過去の全ての地位の保有者に対する同意の情報の取得の有無は、かかるＳＴ３の全ての地位の保有者を示す情報を用いて、判定してよく、かかる全ての地位の保有者を示す情報を用いて、例えば、地位の保有者に係る当事者端末に問い合わせ、その回答を取得してよい。

なお、一の商流内において、割引に常に同意する者Ｘがいる場合、仮にかかる者Ｘが地位を保有するとしても、ＳＴ３は、かかる者Ｘを示す情報を、過去に保有した全ての保有者を示す情報内に含ませなくてもよい。また、同様に、ＳＴ３は、かかる者Ｘによる割引についての同意を示す情報を含まなくても、かかる者Ｘによる割引についての同意を示す情報がないとしても、割引が実行されてよい。

また、他の態様として、一の商流内において、割引に常に同意する者Ｘがいる場合、仮にかかる者Ｘが地位を保有するとしても、ＳＴ３は、かかる者Ｘを示す情報を、過去に保有した全ての保有者を示す情報内に含ませた場合でも、ＳＴ３は、予め、かかる者Ｘによる割引についての同意を示す情報を含むよう当初から設定することにより、かかる者Ｘによる同意を別途必要とせず、割引の実行が可能なように構成されてよい。具体的には、決済部において、金流管理部における、かかる同意を示す情報を確認することなしに、割引の実行が可能なように一例のシステムが構成されてよい。

上述の関係は、一の商流内の全ての者が、割引に常に同意する場合も同様である。すなわち、一の商流内の全ての者が割引に常に同意する場合、かかる地位を過去の保有した全ての保有者による割引に対する同意を示す情報を格納するデータ構造を有しなくてもよい。そして、ＳＴ３が、かかる地位を過去の保有した全ての保有者による割引に対する同意を示す情報を格納するデータ構造、を有しないとしても、別途当事者の同意を必要とせず、割引の実行が可能なように構成されてよい。この場合、上述と同様に、決済部において、金流管理部における、かかる同意を示す情報を確認することなしに、割引の実行が可能なように一例のシステムが構成されてよい。

なお、金流管理部が、上述のＳＴ３を生成する場合、金流管理部は、更に、ＳＴ１及びＳＴ２を、上述とは異なる利用方法を採用してもよい。すなわち、金流管理部が、ＳＴ３について分割移転を含み移転する場合、対応して、ＳＴ１及びＳＴ２を生成してよい。ここで、ＳＴ１とＳＴ２は、各々、この場合、ＳＴ１は、金額を示す情報と、権利者を示す情報と、義務者を示す情報と、を含んでよい。また、ＳＴ１は、権利の有効又は無効を示す情報を、含んでよい。例えば、上述において、当事者Ａが有するＳＴ３の１００のうち、当事者Ｂに６０を分割移転する場合、かかる分割移転に対応して、ＳＴ１とＳＴ２を６０について、生成してよい。すなわち、かかる分割移転に対応して、ＳＴ３と同時に生成されるＳＴ１は、金額を示す情報として６０を含み、権利者を示す情報として当事者Ｂを含み、義務者を示す情報として第三者を含んでよい。同様に、かかる分割移転に対応して、ＳＴ３と同時に生成されるＳＴ２は、金額を示す情報として６０を含み、権利者を示す情報として第三者を含み、義務者を示す情報として当事者Ａを含んでよい。このようにＳＴ３に対応して、ＳＴ１及びＳＴ２を生成することにより、ＳＴ３によって生成された情報の明確化が可能となる。

また、同様に、ＳＴ３について、当事者Ｂが、６０のうち、当事者Ｄに４０を分割移転する場合を考える。このとき、金流管理部は、かかる分割移転に対応して、金額を示す情報として４０を含み、権利者を示す情報として当事者Ｄを含み、義務者を示す情報として第三者を含む、ＳＴ１を、かかるＳＴ３と同時に生成してよい。同様に、かかる分割移転に対応して、ＳＴ３と同時に、金額を示す情報として４０を含み、権利者を示す情報として第三者を含み、義務者を示す情報として当事者Ｂを含むＳＴ２を、かかるＳＴ３と同時に生成してよい。

そして、当事者Ｂに着目すると、上述のとおり、金額を示す情報として４０と、権利者を示す情報として第三者と、義務者を示す情報として当事者Ｂと、を含むＳＴ２と、金額を示す情報として６０と、権利者を示す情報として当事者Ｂと、義務者を示す情報として第三者と、を含むＳＴ１と、が生成されている。これらのＳＴ１とＳＴ２は、互いに相対する権利者と義務者の関係にあることから、これらの少ない額を双方から減額可能であり、その結果、６０−４０＝２０が残る。この残る２０は、具体的には、金額を示す情報として２０と、権利者を示す情報として当事者Ｂと、義務者を示す情報として第三者と、を含むＳＴ１であり、これは、当事者Ｂが、ＳＴ３として２０を有することに対応する。このように、ＳＴ１とＳＴ２を用いることにより、ＳＴ３の現在の金額がどのように生成されたのかというその過程を明確化できる利点がある。

なお、金流管理部は、上述のＳＴ１とＳＴ２が互いに相対する権利者と義務者の関係にある上述のＳＴ１とＳＴ２について、双方のうちの少ない額を、双方から減額する処理は、以下の場合に限り、行われるよう構成されてもよい。すなわち、ＳＴ１及びＳＴ２の両方が、かかる権利者及び義務者からかかる減額する処理に合意した旨を示す情報が設定されている場合である。この場合、このように互いに相対する権利者と義務者による双方の減額処理の合意を要求する場合、かかる減額のタイミングをコントロールできる利点がある。

ＳＴ３は、ＳＴ３に係る地位が有効又は無効を示す情報を含んでよい。後述の決済部が、ＳＴ３に係る債権の割引を実行する場合、かかる割引に対応する金額分、金流管理部は、ＳＴ３に係る債権額を示す情報を減額し、減額後の金額をＳＴ３に設定してよい。

なお、ＳＴ３について、債権の割引が実行される場合において、対応するＳＴ１について、対応して、減額後の金額が、ＳＴ１に設定されてもよい。かかる処理は、上述のＳＴ１についての処理と同様である。ＳＴ３についての処理を、ＳＴ１に対する処理に反映させることにより、より権利関係が明確化できる利点がある。

一例のシステムの金流管理部は、ＳＴ１、ＳＴ２、ＳＴ３を、種々の技術を用いて、生成してよい。例えば、ブロックチェーンを用いた技術においては、セキュリティトークンを用いて実装してよい。この場合、改ざん防止の機能が実現できる利点がある。特に、金銭的価値を有するものをデータとするため、かかる金銭的価値の使用に対する合意の情報など関係者の信頼向上のために、改ざん防止の機能を用いることが好ましい。他方、データベースにおいて実装される場合は、これらを改ざん防止機能の付いたデータによって、実装されてよい。この場合も同様に、関係者の信頼を向上できる利点がある。なお、一例のシステムは、金流管理部を備えるものであるが、特にＳＴ１、ＳＴ２、ＳＴ３へのアクセスは、各当事者端末においても実行可能であってよく、この場合、一例のシステムは、分散環境において実施可能なものであってよい。

３．４．与信判断部３４
与信判断部は、与信判断を行う機能を有する。与信は、債権についての与信であってよい。

与信判断部は、与えられた債権について、契約の履行状況に影響を与える情報を用いて、前記契約に係る債権についての割引に係る情報を生成してよい。

契約の履行状況に影響を与える情報は、上述の物流管理部において管理されている情報であってよい。

割引に係る情報は、契約に係る債権の価値に関する情報を含んでよい。例えば、割引に係る情報は、契約に係る債権を割り引く場合における割引料を含んでよいし、かかる債権を買い取る場合において割引実行額を含んでもよいし、及び／又は、割引に係る割合を含んでもよい。例えば、契約に係る債権が１００であるとして、かかる１００のうちの一部である８０を割引対象額とし、２０を残す場合を考えると、例えば、割引実行額が７０、割引料（金利分）が１０、割引後の残額であって割引の対象ではない部分として２０などであってよい。なお、本例に基づいて割引がされる場合において、後述の決済部において割引に対応してＳｔａｂｌｅ Ｃｏｉｎを発生させる場合、割引実行額として７０のＳｔａｂｌｅ Ｃｏｉｎを発生させてよい。なお、上述は一の債権において割引の対象ではない部分のある場合を説明したが、一の債権の全てを割引の対象としてもよい。

与信判断部が、割引に係る情報を生成するにあたり、契約の履行状況に影響を与える情報を利用することにより、より適切に、債権の価値を判断できる利点がある。特に物流管理部において管理されている情報を用いることにより、契約対象物の状況を踏まえて、契約の履行実現性を予測できる利点がある。

与信判断部は、割引に係る情報を生成するにあたり、予め定められた所定のルールを用いてよい。かかる所定のルールは、第三者に係る管理者端末から取得した情報を用いて、所定のルールを適用してもよいし、かかる第三者に係る管理者端末から取得した情報を使用せずに、所定のルールを適用してもよい。また、第三者に係る管理者端末から取得した情報を用いる場合、与信判断の対象となる債権について物流管理部において管理されている情報の一部又は全部を、第三者に係る管理者端末に送信し、それに対応して第三者に係る管理者端末から取得した情報を用いて、所定のルールを適用してもよいし、第三者に係る管理者端末から取得する情報のみを用いて情報を生成し、所定のルールを適用しなくてもよい。第三者に係る管理者端末に送信され、表示される、物流管理部において管理されている情報の一部又は全部は、上述の物に係る情報であってよく、管理者は、かかる情報を用いて、債権の履行可能性を判断できる利点がある。

与信判断部は、債権についての割引に係る情報を、予め、生成してもよいし、かかる債権の債権者からの要求に対応して、割引に係る情報を生成してもよい。前者の場合、かかる予め生成された情報を、債権者に係る当事者端末に送信し、かかる当事者端末に表示させることで、かかる債権者に、現時点の債権の価値を理解できる利点がある。後者の場合、特に管理者の判断を含めて割引に係る情報を生成する場合、必要な範囲で管理者が判断すればよい利点がある。

また、与信判断部は、割引に係る情報として、かかる債権の価値を示す情報で割引に対応可能な期限を示す情報を含ませてもよい。かかる期限は、履行期と同じであってもよいし、異なってもよい。後者は、履行期よりも前であってよい。一般的には、契約の履行状況に合わせて履行可能性は上昇する可能性が高いものの、例えば、物品の製造に必要な材料の到達が所定の期間以上遅延することが判明したり、製造製品の検査の結果欠品数が所定の値以上生じた場合には、債権の価値が、対応して低下する場合もあり、当初提示した割引情報による割引の実行が難しくなる場合もあるため、提示した割引情報で対応してもよい（対応する場合のリスクを負う）と提示者が示す期限を示すものである。

次に、一例のシステムにおける与信判断部が一部関与するフローについて、与信判断部が、割引に係る情報を、全て自動的に生成する場合と、少なくとも一部人の判断に基づき生成される場合と、を分けて説明する。

与信判断部が、ある金銭債権についての割引に係る情報を自動的に生成可能である場合、与信判断部は、かかるある債権と関連付けられたかかる割引に係る情報を、債権者である当事者端末に送信する。当事者端末において、かかる債権を示す情報と対応する割引に係る情報が、表示されてよい。債権者が、かかる債権について、かかる割引に係る情報において割引を行う場合、割引リクエストを行う。この場合、一例のシステムは、対応して、かかる債権に係るＳＴ１に割引リクエストの同意を示す情報を設定してよい。次に、債権者が割引リクエストの同意を示す情報が設定されたことを検知した一例のシステムは、かかる割引リクエストを、管理者端末に表示させる。管理者端末に表示される情報は、かかる債権を示す情報と、対応する割引に係る情報と、割引リクエストに債権者が合意した旨を示す情報と、を含んでよい。管理者端末に係る第三者等の債務者が、かかる割引リクエストに対して応じる場合、一例のシステムは、かかるＳＴ１における割引に同意を示す情報を設定してよい。ＳＴ１において、かかる割引リクエストに同意する情報が債権者に基づく情報によって設定され、かかる割引リクエストに合意する情報が債務者に基づく情報によって設定されている場合、一例のシステムは、かかる債権の割引を実行してよい。

他方、与信判断部が、ある金銭債権についての割引に係る情報を自動的に生成可能ではなく、少なくとも一部について、第三者等の債務者が割引に係る情報の生成に関与する場合を説明する。この場合、ある債権の債権者が、ある債権についての割引リクエストを行う。例えば、かかる債権者は、かかる債権者に係る当事者端末において、特定の債権について、割引リクエストを入力する。一例のシステムは、かかる入力を受けて、対応する債権に係るＳＴ１において、債権者が、割引リクエストの同意を示す情報を設定する。次に、一例のシステムは、割引リクエストの同意を示す情報が設定されたＳＴ１について、第三者等の債務者に係る管理者端末において、かかるＳＴ１に係る債権について、割引リクエストが行われたことを示す情報を表示する。少なくとも一部、人的な判断が行われ、かかる債権についての割引に係る情報が生成され、かかる割引に係る情報の有効期間と共に、一例のシステムは、対応するＳＴ１に対し、割引の同意に係る情報を設定する。かかる割引の合意に係る情報は、割引に合意したことを示す情報、割引に係る情報、及び／又は、かかる情報の有効期間、を含んでよい。第三者等の債務者からかかる情報を取得した一例のシステムは、債権者に対して、かかる情報を提示してよい。例えば、一例のシステムにおけるかかる当事者端末は、割引に係る情報を、債権者に係る当事者端末に表示してよい。債権者は、割引率等を確認した上で、割引に同意してよい。例えば、一例のシステムは、対応するＳＴ１において、債権者の割引の同意を示す情報を、設定してよい。ＳＴ１において、かかる割引リクエストを行った情報が債権者に基づく情報によって設定され、かかる割引リクエストに同意する情報が債務者に基づく情報によって設定され、かかる割引に同意する情報が債権者によって設定されている場合、一例のシステムは、かかる債権の割引を実行してよい。

なお、債権者の割引請求を示す情報の記憶や第三者である債務者による割引の同意を示す情報の記憶は、仮想通貨のＷＡＬＬＥＴを用いて行われてよい。

なお、上述では、ＳＴ１の場合について説明したが、ＳＴ３においても同様であって良い。すなわち、与信判断部は、ＳＴ３に係る債権の割引に係る情報を生成し、かかる債権についての債権者及び第三者の同意について、ＳＴ３がデータとして設定されるよう、構成されてよい。

３．５．決済部３５
決済部は、決済を管理する機能を有する。

決済部は、ＳＴ１が、ＳＴ１が示す金銭債権の債権者による割引に対する同意を示す情報と、ＳＴ１が示す金銭債権の債務者による割引に対する同意を示す情報を、を含んでいる場合、かかるＳＴ１が示す金銭債権についての割引を実行してよい。

また、他の態様として、決済部は、ＳＴ１が、ＳＴ１が示す金銭債権の債権者による割引に対してリクエストを示す情報と、ＳＴ１が示す金銭債権の債務者による割引に対する同意を示す情報と、ＳＴ１が示す金銭債権の債権者による割引に対する同意を示す情報と、を含んでいる場合、かかるＳＴ１が示す金銭債権についての割引を実行してよい。

また、決済部は、ＳＴ１が同意に係る情報を使用する場合、必要な当事者に係る同意に係る情報において同意を示す情報が含まれる場合に限り、割引を実行してよい。

また、決済部は、ＳＴ３について、第三者による同意を示す情報と、前記トークンデータに係る債権の所有者による同意を示す情報と、前記過去の地位の保有者による同意を示す情報と、を含む場合、かかるＳＴ３が示す割引を実行してよい。

割引についての実行は、種々の態様であって良く、債務者から債権者に、割引実行額に対応する資金が提供されればよい。例えば、決済部は、仮想通貨システムや勘定系システムと連携し、債権者が割引の額に対応する額の仮想通貨や預金を有するよう処理してよい。より具体的には、決済部は、仮想通貨システムや勘定系システムと連携し、債権者が割引実行額に対応する額のＳｔａｂｌｅ Ｃｏｉｎを有する処理をしてよく、対応して、債務者が割引対象額に対応する額のＳｔａｂｌｅ Ｃｏｉｎを減額させる処理をしてよい。債務者の預金残高の範囲内で、割引されていないＳＴ１の金額と同額もしくはＳＴ１の割引額の残額のＳｔａｂｌｅ ＣｏｉｎがＳＴ１の債権者（すなわちＳＴ１の債務引受の基となる金銭債権の債権者）を保有者として発生してよい。

４．実施例
４．１．実施例１
実施例１に係る一例のシステムは、物を製造する商流に対して適用される例である。

例えば、図１１は、電機メーカーＡと、組立工場Ｂと、素材メーカーＣと、部品メーカーＤと、が一の商流内に関与する状況を示す。電機メーカーＡと組立工場Ｂとが売買契約αを締結し、組立工場Ｂと素材メーカーＣとが売買契約βを締結し、組立工場Ｂと部品メーカーＤとが売買契約γを締結している状態である。

かかる契約を背景に、一例のシステムの管理システムは、図１２に示される通り、電機メーカーＡの利用する当事者端末Ａと、組立工場Ｂの利用する当事者端末Ｂと、素材メーカーＣの利用する当事者端末Ｃと、部品メーカーＤの利用する当事者端末Ｄと、接続されていてよい。また、管理システム０１０は、管理者端末０１１とも接続されていてよい。ここで、管理者端末は、金融機関が利用する端末であってよいが、金融機関に限らず任意の第三者であってもよい。

本例のシステムが行う処理について図１３を用いて説明する。まず、商流管理部が、各契約についての、契約に係る情報を取得する（ステップ１）。次に、物流管理部は、商流管理部によって取得された種々の契約に係る情報を用いて、各契約に対応する物流に係る情報を生成する（ステップ２）。次に、金流管理部は、各契約に対応するＳＴ１及びＳＴ２を生成する（ステップ３）。次に、各契約の履行状況に伴って物流管理部は物流に係る情報を更新する（ステップ４）。債権の割引のリクエストの受領に対応して、与信判断部は割引に係る情報を生成して当事者に提示し、当事者と金融機関の合意が得られた場合、金流管理部は、かかる割引額に対応するＳＴ１について使用済みを示す情報にアップデートとする（ステップ５）。なお、状況に応じて、相殺などもされてよい。

上述の構成によって、一例のシステムの商流管理部は、かかる契約α、β、γについての情報を取得する。かかる契約が電子契約システムに入力されているのであれば、一例のシステムの商流管理部は、かかる電子契約システムとＡＰＩ接続等によって、契約α、β、γについての情報を取得して、記憶する。

なお、一例のシステムの商流管理部は、かかる情報の記憶後、記憶された情報を、当事者Ａ乃至Ｄの利用する当事者端末に送信し、各当事者端末において各契約情報を表示させ、各当事者において、実際に締結した契約内容が反映されているか、一例のシステム内の契約情報に間違いがないか、を確認するステップがあってもよい。

なお、一例のシステムの商流管理部が、上述の契約に関する情報を取得する順序はどのようなものであってもよいが、契約は物の動きとは逆の動きの下流から締結されることが多く、本例においては、ＡＢ間の契約の後に、ＢＣ間及びＢＤ間で契約が締結されることとなるが、かかる順番に対応して、商流管理部は、商流に係る情報を取得し記憶してよい。また、かかる情報の取得に対応して、各商流に係る情報を記憶するＮＦＴのＩＤを生成してよい。

商流に係る情報の生成に伴い、一例のシステムの物流管理部は、各契約に対応する物流に係る情報を生成してよい。例えば、本図においては、組立工場Ｂから電機メーカーＡに納品予定の製品について、物流管理部は、ＩＤ＝α１、を生成し、記憶して、管理してよい。また、素材メーカーＣから組立工場Ｂに提供予定の素材β１及びβ２について、物流管理部は、ＩＤ＝β１及びβ２を生成し、記憶して、管理してよい。同様に、部品メーカーＤから組立工場Ｂに提供予定の部品γ１について、物流管理部は、ＩＤ＝γ１を生成し、記憶して、管理してよい。

また、商流に係る情報の生成に伴い、一例のシステムの金流管理部は、各契約に対応するＳＴ１及びＳＴ２を生成してよい。

次に、契約に従い、各当事者が契約の履行を進める。例えば、素材メーカーＣは、素材β１及びβ２の提供の準備を行う。例えば、素材の原材料の調達や、素材の原材料の加工、検査、などのステップがありうる。かかる契約の履行に係る情報を、素材メーカーＣは、利用する当事者端末を用いて、一例のシステムの物流管理部に、入力してよい。同様に、部品メーカーＤは、部品γ１の提供の準備を行う。例えば、部品の原材料の調達や、部品の原材料の加工、検査、などのステップがありうる。かかる契約の履行に係る情報を、部品メーカーＤは、利用する当事者端末を用いて、一例のシステムの物流管理部に、入力してよい。
また、上述の当事者端末と一例のシステムの接続と共に又は代えて、素材メーカーＣ及び／又は部品メーカーＤの有する製造装置や検査装置と、一例のシステムの物流管理部が、ネットワーク等を介して、接続され、素材メーカーＣ及び／又は部品メーカーＤにおける製造の状況や検査の状況などの情報が、自動的に、ネットワークを介して、一例の物流管理部に記憶され、管理されてもよい。例えば、図１２においては、当事者Ｂ装置００２Ａ、当事者Ｃ装置００３Ａ、当事者Ｄ装置００４Ａ、などが挙げられる。なお、本図においては、各当事者について一の装置を図示しているが、一の当事者について、複数の装置が、ネットワークを介して、一例のシステムと接続されていてもよい。このように、一例のシステムの物流管理部が、契約に係る当事者の利用する製造装置、搬送装置、管理装置、及び／又は、検査装置、の一部又は全部とネットワーク等を介して接続され、各装置の稼働状況や契約に係る対象物の状況の情報を取得できる場合、リアルタイムかつ正確な情報を、物流管理部は取得できる利点があり、与信判断部において、割引に係る情報をより正確かつリアルタイムに生成できる利点がある。

上述の各当事者は、契約の締結などの時点で、各製造委託契約に基づく金銭債権を有する。具体的には、素材メーカーＣ、部品メーカーＤ、組立工場Ｂは、それぞれ、製造委託契約の対価としての金銭債権を有する。しかしながら、かかる金銭債権は、発生しているとしても、支払履行期にならなければ、各金銭債権の債務者に対して履行を請求できない。そして支払履行期は、製造委託契約の対象物である、原材料、部品、製品の製造が、少なくとも一定程度経過する時点であり、通常は、これらの契約対象物の引き渡し後（場合によっては引き渡しされた物についての検品後）に、支払期が来るため、その時点で金銭債権の履行が可能となる。しかしながら、各社のビジネス判断に応じて、かかる支払期以前に債権の資金化を希望する場合がある。

債権の資金化を希望する当事者は、債権の資金化の希望を出す。例えば、当事者Ｃが、当事者Ｂに対する金銭債権について、資金化の希望を出してよい。

資金化に対応するＳＴ１の役割は、上述の通りである。なお、資金化を行う場合、Ｗａｌｌｅｔを用いて、債権者及び債務者の合意が設定され、かかる債権の割引後の金額について、金融機関などの第三者は、当事者Ｃに対して、例えば、ＳｔａｂｌｅＣｏｉｎを用いて支払ってよい。

なお、上述の資金化を可能とする一つの法的整理としては、ＣＢ間の金銭債権が、当事者Ｃから金融機関への債権と、金融機関から当事者Ｂへの債権と、に債務引受がされたと構成し、当事者Ｃが金融機関へ有する債権を資金化するものとして、捉えることができる。かかる構成は、例えば、図１４のように図示できる。上述のＣの有する金銭債権の割引については、本図においては、ＳＴ１（Ｃ＝＞ＢＫ）についての割引として、当事者Ｃが資金化できたと考えられる。

なお、本図において、ＳＴ１と同時又は異時に生成されたＳＴ２（ＢＫ＝＞Ｂ）を、金融機関は当事者Ｂに対して有する。このとき、当事者Ｂが当事者Ａに対して有する金銭債権も同様に、金融機関を介する債務引受によって、ＳＴ１（Ｂ＝＞ＢＫ）とＳＴ２（ＢＫ＝＞Ａ）を生成できる。そのため、金融機関が当事者Ｂに対して有する金銭債権ＳＴ２（ＢＫ＝＞Ｂ）と、当事者Ｂが金融機関に対して有する金銭債権ＳＴ１（Ｂ＝＞ＢＫ）は、債権者と債務者が互いに交互である相対する債権であることから、双方の債権が履行可能であれば、相殺することもできる。

相殺は、例えば、予め、当事者Ｂが相殺の期限の利益を放棄することが金融機関とＢ間で取り決められている場合において、金融機関の相殺の指示に基づいて、金流管理部は、ＳＴ１（Ｂ＝＞ＢＫ）とＳＴ２（ＢＫ＝＞Ｂ）とを相殺させることが可能であってよい。より具体的には、管理者端末から、ＳＴ１（Ｂ＝＞ＢＫ）を特定して相殺する指示を金流管理部が得た場合、ＳＴ１（Ｂ＝＞ＢＫ）内の金額とＳＴ２（ＢＫ＝＞Ｂ）内の金額との小さい金額を、双方から減額した値を、ＳＴ１（Ｂ＝＞ＢＫ）内の金額とＳＴ２（ＢＫ＝＞Ｂ）の金額に、設定してよい。例えば、ＳＴ１（Ｂ＝＞ＢＫ）とＳＴ２（ＢＫ＝＞Ｂ）の金額が、それぞれ、１００と１２０であれば、相殺の処理後は、ＳＴ１（Ｂ＝＞ＢＫ）とＳＴ２（ＢＫ＝＞Ｂ）は、それぞれ、０と２０となる。

なお、一例のシステムの金流管理部において、ＳＴ１についての相殺が可能になった場合には、かかるＳＴ１と互いに相対する債権者と債務者の関係にあるＳＴ２について相殺が可能であるように、当事者は常に相殺の期限の利益を放棄する等のルールを実装してもよい。この場合、相殺が可能になった段階で、上述の処理、すなわち、債権者と債務者とが互いに交互の関係にある相対する債権であるＳＴ１とＳＴ２について、履行可能な状態になった場合、自動的に、各ＳＴ１とＳＴ２についてのそれぞれの金額から、それらのうちの小さい金額を減額して、それぞれの金額を減額後の金額とする処理を行ってよい。

なお、かかる相殺についての処理が可能な場合は、相殺されるＳＴ１及びＳＴ２に係る権利者及び債務者の合意の設定があることに加えて、債権者の全ての上流のＳＴ１及びＳＴ２についての割引又は相殺がされた場合に限定してもよい。この場合、一例のシステムは、対象となるＳＴ１及びＳＴ２の、上流のＳＴ１及びＳＴ２における割引又は相殺の有無の情報を用いて、対象となるＳＴ１及びＳＴ２についての相殺処理を行ってよい。

従来、履行期前の債権の割引は、その価格について、債権の履行可能性を判断する必要があり、その情報の収集や判断が難しかった。一例のシステムが、上述のとおり、契約に関連する契約の履行状況に係る情報を、物流管理部が取得して記憶し、与信判断部が、かかる物流管理部が管理する情報を用いて自動的に与信判断を行う又は与信判断に必要な情報を管理者に対して提示できる場合、より根拠を持って債権の履行の実現度を評価できることから、より債権の資金化が可能となる利点がある。

４．２．実施例２
実施例２に係るシステムは、実施例１における商流において、物の移送の例である。ここでは、物は製造されず、また、物の個数も変化しないものとする。すなわち、上流における物が、最下流においても、同一の物で変化がないものとする。実施例２に係るシステムについては、対象が物の移送であることのみが異なることから、実施例１と異なる部分のみを説明する。

実施例２に係るシステムは、物流管理部において、各契約に対応する物流に係る情報を生成してよい。ただし、実施例１に係るシステムと異なり、本例においては、移送される物についてのＩＤは、再利用されてよい。例えば、図１５において、当事者Ｄが扱う物について、ＩＤ＝Ｘが付与された場合、当事者Ｃ、当事者Ｂ、当事者Ａと物が移転される場合のＩＤも、同一のＸであってよい。この場合、ＩＤ＝ＸのＮＦＴにおいて、その保有者が、当事者Ｄ、当事者Ｃ、当事者Ｂ、当事者Ａ、と変更されていってよい。なお、各当事者がＸを保有している間において、物流に係る情報として、物の受領、物の第１場所での保管、物の第２場所での保管、物の発送準備、物の発送済み、などの各工程の定性的な情報や、全工程を１００とした場合における各工程に割り当てられた数値を用いた定量的な評価値が生成され、含まれてもよい。かかる情報によって、物の移送の場合であっても、与信判断部は、各物の移送の状況に応じて、割引に係る情報の生成が可能となる利点がある。

なお、実施例１と実施例２において、物の製造と、物の移送という、両極端のケースを説明したが、一例のシステムは、これらの混合されたケースにおいても、同様に適用できることは言うまでもない。混合されたケースとしては、物を製造しつつ、移送するケースが挙げられる。また、単に物を移送する場合であっても、かかる物の移送時の外装としてのパッケージが付与されたり、複数の物に分けられたり、複数の物が一の物に合わさったりするなど、種々の態様があってよい。また、サービス（役務）の提供についても、同様に適用可能であってもよい。かかるサービスの提供において、物を利用する場合における物の工程を、上述の物の製造や物の移送と同じように管理することによって、サービスの提供における進捗に係る情報を取得可能である。また、物以外のサービス（役務）についても、かかるサービス（役務）の提供の工程について、上述と同様に管理することにより、サービスの提供における進捗に係る情報を取得可能である。いずれについても、進捗に係る情報を、契約履行の達成度に係る情報として、上述の割引に係る情報の生成に用いてよい。かかる構成により、サービス（役務）などにおいても、同様に、債権の有効な利用が可能となる可能性がある。

４．３．実施例３
実施例３に係るシステムは、各当事者が有する債権を示すデータとして、ＳＴ３を使用する例である。実施例３に係るシステムは、上述のＳＴ３を利用した場合における対応するＳＴ１及びＳＴ２を生成してもよい。

例えば、図１０のように、種々のＳＴ３が生成されている場合、各ＳＴ３を有する当事者Ａ乃至Ｅは、現在保有しているＳＴ３の金額について、割引を請求してよい。かかる割引により、各当事者は、資金を容易に取得する手段を得る利点がある。

なお、当事者Ａが有していた１００という金額を含むＳＴ３を、Ｂ乃至Ｅに、移転する（分割移転を含む。以下同じ。）利点は、かかる移転により、上流工程における当事者の資金化を促進することにより、ひいては、対象とする商流における契約の履行を促進することにある。すなわち、資金化の手段を、上流工程の当事者に提供することによって、円滑な契約の履行を促進し、ひいては、上流から取得した物を用いて、当事者Ａ自身が最下流の製品についての履行可能性を高めることにある。同様に、当事者ＢやＣについても、自身が資金化を実行してもよいし、上流のＤ又はＥにＳＴ３を移転することにより、資金化の手段を提供し、上流の契約履行可能性を向上させることで、当事者Ｂ及びＣ自身についての契約の履行可能性を向上する利点がある。

上述では、本例のシステムが実施する構成として説明したが、これらは、システム内の一又は複数の情報処理装置が実施する構成であってもよい。

本願書類の実施例において述べた発明例は、本願書類で説明されたものに限らず、その技術的思想の範囲内で、種々の例に適用できることはいうまでもない。例えば、第三者は、金融機関であってもよいし金融機関以外の者であってもよく、管理システムと関連付けられる管理者端末における管理者も、本例のシステムの管理者であってもよいし、債務引受などにおける第三者であってもよい。また、本願書類において、同意、合意、という用語はあくまで一例であり、これらと関連付けられた各情報は、割引、相殺、債務引受等の各処理や各法的構成に対応した当事者の肯定的評価を示す情報であればよい。

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

１０ 情報処理装置
１１ 演算装置
１２ 記憶装置
１３ 入力装置
１４ 表示装置
１５ バス
１６ 通信装置
０００、１７ ネットワーク
００１乃至００４ 当事者Ａ乃至当事者Ｄ端末
００１Ａ乃至００４Ａ 当事者Ａ乃至当事者Ｄ装置
０１０ 管理システム
０１１ 管理者端末

Claims (51)

1. システムを、
   契約の履行状況に影響を与える情報を取得する取得手段、
   前記契約の履行状況に影響を与える情報を用いて、前記契約に係る債権についての割引に係る情報を生成する割引情報生成手段、
   として動作させるためのプログラム。
2. 前記契約の履行状況に影響を与える情報は、前記契約に関連付けられる、物又はサービスを含む契約対象についての契約履行の達成度に係る情報を含む、
   請求項１に記載のプログラム。
3. 前記契約履行の達成度に係る情報は、前記契約が物の製造工程を含む場合、前記契約と関連付けられる対象物の製造状況に係る情報を含む、
   請求項２に記載のプログラム。
4. 前記契約履行の達成度に係る情報は、前記契約が物の移動工程を含む場合、前記契約と関連付けられる対象物の移動状況に係る情報を含む、
   請求項２又は３のいずれか１項に記載のプログラム。
5. 前記契約の履行状況に影響を与える情報は、前記契約と関連付けられた一又は複数の物に係る情報、を含み、
   前記割引情報生成手段は、前記物に係る情報、を用いて、前記割引に係る情報を生成する、
   請求項１乃至４のいずれか１項に記載のプログラム。
6. 前記割引情報生成手段は、前記契約に基づく金銭債権の債務引受によって同時に生じる二つの債権のうちの一の債権についての割引に係る情報を生成する、
   請求項１乃至５のいずれか１項に記載のプログラム。
7. 前記二つの債権を第１債権と第２債権とした場合において、
   前記第１債権及び前記第２債権を示す情報は、各々、各権利の有効又は無効を示すデータを格納するデータ構造を含み、
   前記契約の金銭債権の履行日において、前記第１債権内の前記データ構造内と、前記第２債権内の前記データ構造内と、に各権利の無効を示すデータが同時に設定される、
   請求項６に記載のプログラム。
8. 前記システムを、
   前記契約の債権者である第１当事者を示す情報と、債務者として第三者を示す情報と、を含む、第１債権を示す情報を生成する債権情報生成手段、
   として動作させるためのプログラムであって、
   前記割引情報生成手段が、前記第１債権についての割引に係る情報を生成した後、前記債権情報生成手段が、前記第１債権を示す情報と関連付けて、前記割引に係る情報を記録する、
   請求項１乃至６のいずれか１項に記載のプログラム。
9. 前記システムを、
   第三者に対して第１当事者が有する前記契約に基づいて生じた第１債権を示す情報と、
   前記契約と同一商流の契約に基づいて前記第１当事者に対して前記第三者が有する第２債権を示す情報と、
   を用いて、前記第１債権と前記第２債権のうち債権額が小さい債権について、無効であることを示す情報を記憶する、又は、前記第１債権の債権額から前記小さい債権の債権額を減額しかつ前記第２債権の債権額から前記小さい債権の債権額を減額する、相殺手段、
   として動作させるための請求項１乃至６のいずれか１項に記載のプログラム。
10. 前記システムを、
    前記契約に係る商流内において、所定の条件の下で、第三者に対して割引の請求が可能な地位を示すトークンデータを生成するトークン生成手段、
    として動作させるための請求項１乃至９のいずれか１項に記載のプログラム。
11. 前記トークン生成手段は、前記商流内において最初に生成する前記トークンデータの最初の保有者として、前記商流の最下流の当事者を債務者とした場合の債権者を示す情報を設定する、
    請求項１０に記載のプログラム。
12. 前記トークンデータは、少なくとも、債権額を示す情報、前記地位の保有者を示す情報、及び、前記トークンデータに係る前記地位を過去に保有した全ての保有者を示す情報、を含む、
    請求項１０又は１１のいずれか１項に記載のプログラム。
13. 前記トークンデータは、前記割引の請求についての合意の有無を示す情報を含む、
    請求項１０乃至１２のいずれか１項に記載のプログラム。
14. 前記合意の有無を示す情報は、第三者による同意の有無を示す情報と、前記トークンデータに係る地位の保有者による同意の有無を示す情報と、前記過去の地位の保有者による同意の有無を示す情報と、を含む
    請求項１３に記載のプログラム。
15. 前記トークンデータは、前記トークンデータが示す前記地位が有効又は無効を示す情報を含む、
    請求項１０乃至１４のいずれか１項に記載のプログラム。
16. 契約の履行状況に影響を与える情報を取得する取得部、
    前記契約の履行状況に影響を与える情報を用いて、前記契約に係る債権についての割引に係る情報を生成する割引情報生成部、
    を備えるシステム。
17. 前記契約の履行状況に影響を与える情報は、前記契約に関連付けられる、物又はサービスを含む契約対象についての契約履行の達成度に係る情報を含む、
    請求項１６に記載のシステム。
18. 前記契約履行の達成度に係る情報は、前記契約が物の製造工程を含む場合、前記契約と関連付けられる対象物の製造状況に係る情報を含む、
    請求項１７に記載のシステム。
19. 前記契約履行の達成度に係る情報は、前記契約が物の移動工程を含む場合、前記契約と関連付けられる対象物の移動状況に係る情報を含む、
    請求項１７又は１８のいずれか１項に記載のシステム。
20. 前記契約の履行状況に影響を与える情報は、前記契約と関連付けられた一又は複数の物に係る情報、を含み、
    前記割引情報生成手段は、前記物に係る情報、を用いて、前記割引に係る情報を生成する、
    請求項１６乃至１９のいずれか１項に記載のシステム。
21. 前記割引情報生成部は、前記契約に基づく金銭債権の債務引受によって同時に生じる二つの債権のうちの一の債権についての割引に係る情報を生成する、
    請求項１６乃至２０のいずれか１項に記載のシステム。
22. 前記二つの債権を第１債権と第２債権とした場合において、
    前記第１債権及び前記第２債権を示す情報は、各々、各権利の有効又は無効を示すデータを格納するデータ構造を含み、
    前記契約の金銭債権の履行日において、前記第１債権内の前記データ構造内と、前記第２債権内の前記データ構造内と、に各権利の無効を示すデータが同時に設定される、
    請求項２１に記載のシステム。
23. 前記契約の債権者である第１当事者を示す情報と、債務者として第三者を示す情報と、を含む、第１債権を示す情報を生成する債権情報生成部、を備え、
    前記割引情報生成部が、前記第１債権についての割引に係る情報を生成した後、前記債権情報生成手段が、前記第１債権を示す情報と関連付けて、前記割引に係る情報を記録する、
    請求項１６乃至２１のいずれか１項に記載のシステム。
24. 第三者に対して第１当事者が有する前記契約に基づいて生じた第１債権を示す情報と、
    前記契約と同一商流の契約に基づいて前記第１当事者に対して前記第三者が有する第２債権を示す情報と、
    を用いて、前記第１債権と前記第２債権のうち債権額が小さい債権について、無効であることを示す情報を記憶する、又は、前記第１債権の債権額から前記小さい債権の債権額を減額しかつ前記第２債権の債権額から前記小さい債権の債権額を減額する、相殺部、
    を備える請求項１６乃至２１のいずれか１項に記載のシステム。
25. 前記契約に係る商流内において、所定の条件の下で、第三者に対して割引の請求が可能な地位を示すトークンデータを生成するトークン生成部
    を備える請求項１６乃至２４のいずれか１項に記載のシステム。
26. 前記トークン生成部は、前記商流内において最初に生成する前記トークンデータの最初の保有者として、前記商流の最下流の当事者を債務者とした場合の債権者を示す情報を設定する、
    請求項２５に記載のシステム。
27. 前記トークンデータは、少なくとも、債権額を示す情報、前記地位の保有者を示す情報、及び、前記トークンデータに係る前記地位を過去に保有した全ての保有者を示す情報、を含む、
    請求項２５又は２６のいずれか１項に記載のシステム。
28. 前記トークンデータは、前記割引の請求についての合意の有無を示す情報を含む、
    請求項２５乃至２７のいずれか１項に記載のシステム。
29. 前記合意の有無を示す情報は、第三者による同意の有無を示す情報と、前記トークンデータに係る地位の保有者による同意の有無を示す情報と、前記過去の地位の保有者による同意の有無を示す情報と、を含む
    請求項２８に記載のシステム。
30. 前記トークンデータは、前記トークンデータが示す前記地位が有効又は無効を示す情報を含む、
    請求項２５乃至２９のいずれか１項に記載のシステム。
31. コンピュータが、
    契約の履行状況に影響を与える情報を取得する取得ステップ、
    前記契約の履行状況に影響を与える情報を用いて、前記契約に係る債権についての割引に係る情報を生成する割引情報生成ステップ、
    を実行する方法。
32. 前記契約の履行状況に影響を与える情報は、前記契約に関連付けられる、物又はサービスを含む契約対象についての契約履行の達成度に係る情報を含む、
    請求項３１に記載の方法。
33. 前記契約履行の達成度に係る情報は、前記契約が物の製造工程を含む場合、前記契約と関連付けられる対象物の製造状況に係る情報を含む、
    請求項３２に記載の方法。
34. 前記契約履行の達成度に係る情報は、前記契約が物の移動工程を含む場合、前記契約と関連付けられる対象物の移動状況に係る情報を含む、
    請求項３２又は３３のいずれか１項に記載の方法。
35. 前記契約の履行状況に影響を与える情報は、前記契約と関連付けられた一又は複数の物に係る情報、を含み、
    前記割引情報生成ステップは、前記物に係る情報、を用いて、前記割引に係る情報を生成する、
    請求項３１乃至３４のいずれか１項に記載の方法。
36. 前記割引情報生成ステップは、前記契約に基づく金銭債権の債務引受によって同時に生じる二つの債権のうちの一の債権についての割引に係る情報を生成する、
    請求項３１乃至３５のいずれか１項に記載の方法。
37. 前記二つの債権を第１債権と第２債権とした場合において、
    前記第１債権及び前記第２債権を示す情報は、各々、各権利の有効又は無効を示すデータを格納するデータ構造を含み、
    前記契約の金銭債権の履行日において、前記第１債権内の前記データ構造内と、前記第２債権内の前記データ構造内と、に各権利の無効を示すデータが同時に設定される、
    請求項３６に記載の方法。
38. 前記コンピュータが、
    前記契約の債権者である第１当事者を示す情報と、債務者として第三者を示す情報と、を含む、第１債権を示す情報を生成する債権情報生成ステップ、
    を実行する方法であって、
    前記割引情報生成ステップが、前記第１債権についての割引に係る情報を生成した後、前記債権情報生成ステップが、前記第１債権を示す情報と関連付けて、前記割引に係る情報を記録する、
    請求項３１乃至３６のいずれか１項に記載の方法。
39. 前記コンピュータが、
    第三者に対して第１当事者が有する前記契約に基づいて生じた第１債権を示す情報と、
    前記契約と同一商流の契約に基づいて前記第１当事者に対して前記第三者が有する第２債権を示す情報と、
    を用いて、前記第１債権と前記第２債権のうち債権額が小さい債権について、無効であることを示す情報を記憶する、又は、前記第１債権の債権額から前記小さい債権の債権額を減額しかつ前記第２債権の債権額から前記小さい債権の債権額を減額する、相殺ステップ、
    を実行する請求項３１乃至３６のいずれか１項に記載の方法。
40. 前記コンピュータが、
    前記契約に係る商流内において、所定の条件の下で、第三者に対して割引の請求が可能な地位を示すトークンデータを生成するトークン生成ステップ、
    を実行する請求項３１乃至３９のいずれか１項に記載の方法。
41. 前記トークン生成ステップは、前記商流内において最初に生成する前記トークンデータの最初の保有者として、前記商流の最下流の当事者を債務者とした場合の債権者を示す情報を設定する、
    請求項４０に記載の方法。
42. 前記トークンデータは、少なくとも、債権額を示す情報、前記地位の保有者を示す情報、及び、前記トークンデータに係る前記地位を過去に保有した全ての保有者を示す情報、を含む、
    請求項４０又は４１のいずれか１項に記載の方法。
43. 前記トークンデータは、前記割引の請求についての合意の有無を示す情報を含む、
    請求項４０乃至４２のいずれか１項に記載の方法。
44. 前記合意の有無を示す情報は、第三者による同意の有無を示す情報と、前記トークンデータに係る地位の保有者による同意の有無を示す情報と、前記過去の地位の保有者による同意の有無を示す情報と、を含む、
    請求項４３に記載の方法。
45. 前記トークンデータは、前記トークンデータが示す前記地位が有効又は無効を示す情報を含む、
    請求項４０乃至４４のいずれか１項に記載の方法。
46. 前記システムは、記憶装置を備える、
    請求項１乃至１５のいずれか１項に記載のプログラム。
47. 前記システムは、演算装置を備える、
    請求項１乃至１５及び４６のいずれか１項に記載のプログラム。
48. 前記システムは、記憶装置を備える、
    請求項１６乃至３０のいずれか１項に記載のシステム。
49. 前記システムは、演算装置を備える、
    請求項１６乃至３０及び４８のいずれか１項に記載のシステム。
50. 前記コンピュータは、記憶装置を備える、
    請求項３１乃至４５のいずれか１項に記載の方法。
51. 前記コンピュータは、演算装置を備える、
    請求項３１乃至４５および５０のいずれか１項に記載の方法。
    
    

Images