JP6841541B1 - 受発注・融資システム、受発注・融資方法、及びプログラム - Google Patents

受発注・融資システム、受発注・融資方法、及びプログラム Download PDF

Info

Publication number
JP6841541B1
JP6841541B1 JP2020139226A JP2020139226A JP6841541B1 JP 6841541 B1 JP6841541 B1 JP 6841541B1 JP 2020139226 A JP2020139226 A JP 2020139226A JP 2020139226 A JP2020139226 A JP 2020139226A JP 6841541 B1 JP6841541 B1 JP 6841541B1
Authority
JP
Japan
Prior art keywords
ordering
transaction information
hierarchical
contractor
invoice
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2020139226A
Other languages
English (en)
Other versions
JP2022035125A (ja
Inventor
宗俊 山田
宗俊 山田
卓哉 関口
卓哉 関口
Original Assignee
宗俊 山田
宗俊 山田
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 宗俊 山田, 宗俊 山田 filed Critical 宗俊 山田
Priority to JP2020139226A priority Critical patent/JP6841541B1/ja
Application granted granted Critical
Publication of JP6841541B1 publication Critical patent/JP6841541B1/ja
Publication of JP2022035125A publication Critical patent/JP2022035125A/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

【課題】多重請負構造における全ての契約内容を一元的に把握する第三者を設けることなく、多重請負構造を可視化する受発注・融資システム、受発注・融資方法及びプログラムを提供する。【解決手段】ネットワークを介して接続された、複数の受発注者端末、金融機関端末、ルート認証局及び公証サービス端末を備える受発注・融資システムにおいて、受発注・融資システムの受発注者端末は、発注者として、発注者から受注者に対する発注の多重請負構造における階層レベルを少なくとも含む階層データをアウトプットデータとする階層取引情報を作成して受注者側に送信する発注登録処理部を有し、記多重請負構造における上層の発注者から受注した発注を多重請負構造における下層の受注者に発注する場合、上層の発注者側から送信された階層取引情報におけるアウトプットデータとしての階層データをインプットデータとする階層取引情報を作成する。【選択図】図２

Description

本発明は、例えば、ＩＴ(Information Technology)業界等における多重請負構造に用いて好適な受発注・融資システム、受発注・融資方法、及びプログラムに関する。
ＩＴ業界では多重請負構造が一般化しており、大手の一次請ＳＩ(System Integrator)から二次請ＳＩへ、二次請ＳＩから三次請ＳＩへと、仕事を下請けに発注する仕組みが確立されている。
このため、下請ＳＩは、発注元から仕事の報酬を受け取るまでにタイムラグが生じて短期的な運転資金不足になってしまうことがあり、その場合、金融機関から融資を受けたいというニーズが発生する。
しかしながら、下請ＳＩは会社規模が比較的小さいことが多く、金融機関から信用度に欠けると判断されてしまい融資を受けられないことが起こり得る。
例えば特許文献１には、金融機関にて使用される複数のＤＢを統合してメタデータを生成し、これに基づき、取引関係を可視化して表示することや、可視化された情報を元に、金融機関が様々な支援を行えるようにすることが記載されている。
特開２００７−２５７２２３号公報
ところで、下請ＳＩが実施する仕事は、元を辿れば、金融機関からの信用度が高い大手ＳＩからの発注であることが多い。そこで、大手ＳＩから下請けＳＩに至る多重請負構造を可視化し、下請ＳＩの仕事の大元が大手ＳＩからの発注であることを金融機関に対して証明できれば、下請ＳＩは、大手ＳＩの信用度を活用して自身の信用度を補完でき、金融機関から融資を受けることができるようになると期待できる。
多重請負構造を可視化するためには、通常、第三者が一元的に全ての契約内容を把握する必要がある。しかしながら、第三者を設けた場合、例えば下請ＳＩ間における単価が元請側に漏洩してしまう等の問題が生じ得る。また、該第三者が保有するデータを金融機関が信頼するためには、該第三者自体の信用も必要である。
本発明は、このような状況に鑑みてなされたものであり、多重請負構造における全ての契約内容を一元的に把握する第三者を設けることなく、多重請負構造を可視化できるようにすることを目的とする。
本願は、上記課題の少なくとも一部を解決する手段を複数含んでいるが、その例を挙げるならば、以下のとおりである。
上記課題を解決すべく、本発明の一態様に係る受発注・融資システムは、多重請負構造に属する発注者及び受注者のそれぞれが使用する複数の受発注者端末を備える受発注・融資システムであって、前記受発注者端末は、前記発注者として、前記発注者と前記受注者との間の発注内容を表す受発注データをアウトプットデータとする受発注取引情報、及び、前記発注者から前記受注者に対する発注の前記多重請負構造における階層レベルを少なくとも含む階層データをアウトプットデータとする階層取引情報を作成して前記受注者側に送信する発注登録処理部と、前記受注者として、前記発注者側から送信された前記受発注取引情報、及び前記階層取引情報を受信、確認して前記発注者側に返信する受注処理部と、を有し、前記発注登録処理部は、前記多重請負構造における上層の前記発注者から受注した発注を前記多重請負構造における下層の前記受注者に発注する場合、前記上層の前記発注者側から送信された前記階層取引情報における前記アウトプットデータとしての前記階層データをインプットデータとする前記階層取引情報を作成して前記下層の受注者側に送信することを特徴とする。
前記発注登録処理部は、作成した前記階層取引情報に前記発注者の電子署名を付して前記受注者側に送信するとともに階層データベースに保存することができ、前記受注処理部は、受信した前記発注者側からの前記階層取引情報に前記受注者の電子署名を追加で付して前記発注者側に返信するともに階層データベースに保存することができる。
前記発注登録処理部は、前記受注者側から返信された前記階層取引情報に対する公的な証明を依頼するための公証依頼情報を作成して公証サービス側に送信し、前記公証サービス側から返信された前記公証サービスの電子署名を前記受注者側に送信するとともに前記階層データベースの、前記発注者の電子署名、及び前記受注者の電子署名が付されている前記階層取引情報に追加で付して保存することができる。
前記発注登録処理部は、作成した前記受発注取引情報に前記発注者の電子署名を付して前記受注者側に送信するとともに契約データベースに保存することができ、前記受注処理部は、受信した前記発注者側からの前記受発注取引情報に前記受注者の電子署名を追加で付して前記発注者側に返信するとともに契約データベースに保存することができる。
前記発注登録処理部は、前記受注者側から返信された前記受発注取引情報に対する公証を依頼するための公証依頼情報を作成して公証サービス側に送信し、前記公証サービス側から返信された前記公証サービスの電子署名を前記受注者側に送信するとともに前記契約データベースの、前記発注者の電子署名、及び前記受注者の電署名が付されている前記階層取引情報に追加で付して保存することができる。
受発注・融資システムは、金融機関が使用する金融機関端末を、備えることができ、前記受発注者端末は、前記受注者兼依頼者として、前記発注者と共有する前記階層取引情報における前記アウトプットデータとしての前記階層データをインプットデータとし、前記発注者との契約金額を少なくとも含むインボイスデータをアウトプットデータとするインボイス取引情報を作成し、前記発注者と共有する前記階層取引情報に連なる一連の階層取引情報とともに前記金融機関側に送信するインボイス登録処理部、を有することができる。
前記金融機関端末は、前記インボイス取引情報、及び前記一連の階層取引情報に基づいて、前記受注者兼依頼者が属する前記多重請負構造を可視化するインボイス受付処理部、を有することができる。
前記インボイス受付処理部は、ユーザからの入力に基づき、前記インボイス取引情報の前記インボイスデータにマージン情報を記録して前記受注者兼依頼者側に返信することができる。
本発明の他の態様に係る受発注・融資方法は、多重請負構造に属する発注者及び受注者のそれぞれが使用する複数の受発注者端末を備える受発注・融資システムによる受発注・融資方法であって、前記発注者が使用する前記受発注者端末による、前記発注者と前記受注者との間の発注内容を表す受発注データをアウトプットデータとする受発注取引情報を作成して前記受注者側に送信する受発注取引情報作成ステップと、前記発注者から前記受注者に対する発注の前記多重請負構造における階層レベルを少なくとも含む階層データをアウトプットデータとする階層取引情報を作成して前記受注者側に送信する階層取引情報作成ステップと、前記受注者が使用する前記受発注者端末による、前記発注者側から送信された前記受発注取引情報を受信、確認して前記発注者側に返信する受発注取引情報確認ステップと、前記発注者側から送信された前記階層取引情報を受信、確認して前記発注者側に返信する階層取引情報確認ステップと、を含み、階層取引情報作成ステップは、前記多重請負構造における上層の前記発注者から受注した発注を前記多重請負構造における下層の前記受注者に発注する場合、前記上層の前記発注者側から送信された前記階層取引情報における前記アウトプットデータとしての前記階層データをインプットデータとする前記階層取引情報を作成して前記下層の受注者側に送信することを特徴とする。
本発明のさらに他の態様に係るプログラムは、多重請負構造に属する発注者及び受注者のそれぞれが使用するコンピュータを、前記発注者として、前記発注者と前記受注者との間の発注内容を表す受発注データをアウトプットデータとする受発注取引情報、及び、前記発注者から前記受注者に対する発注の前記多重請負構造における階層レベルを少なくとも含む階層データをアウトプットデータとする階層取引情報を作成して前記受注者側に送信する発注登録処理部と、前記受注者として、前記発注者側から送信された前記受発注取引情報、及び前記階層取引情報を受信、確認して前記発注者側に返信する受注処理部と、
して機能させ、前記発注登録処理部は、前記多重請負構造における上層の前記発注者から受注した発注を前記多重請負構造における下層の前記受注者に発注する場合、前記上層の前記発注者側から送信された前記階層取引情報における前記アウトプットデータとしての前記階層データをインプットデータとする前記階層取引情報を作成して前記下層の受注者側に送信することを特徴とする。
本発明によれば、多重請負構造における全ての契約内容を一元的に把握する第三者を設けることなく、多重請負構造を可視化することが可能となる。
上記した以外の課題、構成及び効果は、以下の実施形態の説明により明らかにされる。
図１は、本発明の一実施形態に係る受発注・融資システムの構成例を示す図である。 図２は、受発注者端末の構成例を示す図である。 図３は、金融機関端末の構成例を示す図である。 図４は、ノード間で通信される取引情報のデータ構造の一例を示す図である。 図５は、一連の取引情報の関係を説明するための図である。 図６は、受発注データのデータ構造の一例を示す図である。 図７は、階層データのデータ構造の一例を示す図である。 図８は、インボイスデータのデータ構造の一例を示す図である。 図９は、受発注・融資システムによる処理の流れを説明するフローチャートである。 図１０は、発注登録処理の一例を説明するフローチャートである。 図１１は、受発注取引情報作成処理の一例を説明するフローチャートである。 図１２は、一次請ＳＩから二次請ＳＩに送信される受発注取引情報の一例を示す図である。 図１３は、階層取引情報作成処理の一例を説明するフローチャートである。 図１４は、一次請ＳＩから二次請ＳＩに送信される階層取引情報の一例を示す図である。 図１５は、受注処理の一例を説明するフローチャートである。 図１６は、受発注取引情報確認処理の一例を説明するフローチャートである。 図１７は、二次請ＳＩから一次請ＳＩに返信される受発注取引情報の一例を示す図である。 図１８は、階層取引情報確認処理の一例を説明するフローチャートである。 図１９は、二次請ＳＩから一次請ＳＩに返信される階層取引情報の一例を示す図である。 図２０は、受発注取引情報に対する公証依頼情報の一例を示す図である。 図２１は、公証サービス処理の一例を説明するフローチャートである。 図２２は、一次請ＳＩと二次請ＳＩとの間の受発注取引情報の一例を示す図である。 図２３は、一次請ＳＩと二次請ＳＩとの間の階層取引情報の一例を示す図である。 図２４は、二次請ＳＩと三次請ＳＩとの間の受発注取引情報の一例を示す図である。 図２５は、二次請ＳＩと三次請ＳＩとの間の階層取引情報の一例を示す図である。 図２６は、インボイス登録処理の一例を説明するフローチャートである。 図２７は、三次請ＳＩから金融機関に送信されるインボイス取引情報の一例を示す図である。 図２８は、インボイス受付処理の一例を説明するフローチャートである。 図２９は、金融機関から三次請ＳＩに返信されるインボイス取引情報の一例を示す図である。 図３０は、三次請ＳＩから金融機関に返信されるインボイス取引情報の一例を示す図である。 図３１は、インボイス取引情報に対する公証依頼情報の一例を示す図である。 図３２は、三次請ＳＩ及び金融機関に最終的に保存されるインボイス取引情報の一例を示す図である。 図３３は、受発注者端末に表示される発注画面の表示例を示す図である。 図３４は、受発注者端末に表示される受注画面の表示例を示す図である。 図３５は、金融機関端末に表示される受付画面の表示例を示す図である。
以下、本発明に係る一実施形態を図面に基づいて説明する。なお、一実施形態を説明するための全図において、同一の部材には原則として同一の符号を付し、その繰り返しの説明は省略する。また、以下の実施形態において、その構成要素（要素ステップ等も含む）は、特に明示した場合および原理的に明らかに必須であると考えられる場合等を除き、必ずしも必須のものではないことは言うまでもない。また、「Ａからなる」、「Ａよりなる」、「Ａを有する」、「Ａを含む」と言うときは、特にその要素のみである旨明示した場合等を除き、それ以外の要素を排除するものでないことは言うまでもない。同様に、以下の実施形態において、構成要素等の形状、位置関係等に言及するときは、特に明示した場合および原理的に明らかにそうでないと考えられる場合等を除き、実質的にその形状等に近似または類似するもの等を含むものとする。
＜本発明の一実施形態に係る受発注・融資システム１＞
図１は、本発明の一実施形態に係る受発注・融資システム１の構成例を示している。
該受発注・融資システム１は、例えば、ＩＴ業界における多重請負構造を可視化することにより、多重請負構造の下請ＳＩが金融機関からインボイスファイナンス（売掛金担保融資）を受け得るようにするものである。
多重請負構造としては、顧客であるＸ商事からＸ商事システム更改を契約金額１千２百万円で受注した一次請ＳＩのＡシステムズが、二次請ＳＩのＢシステムズに契約金額１千万円で発注し、Ｂシステムズが、三次請ＳＩであるＣシステムズに契約金額８百万円で発注し、Ｃシステムズが金融機関であるＸバンクに対して運転資金８百万円のインボイスファイナンス（売掛金担保融資）を依頼するシナリオを想定する。
受発注・融資システム１は、ネットワーク２を介して接続された、受発注者端末１０１〜１０３、金融機関端末２０、ルート認証局３０、及び公証サービス端末４０を備える。
ネットワーク２は、インターネット、携帯電話通信網等に代表される双方向通信網である。以下、受発注者端末１０１〜１０３、金融機関端末２０、ルート認証局３０、及び公証サービス端末４０それぞれをノードとも称する。
受発注者端末１０１は、多重請負構造を構成する一次請ＳＩ（Ａシステムズ）によって使用される。同様に、受発注者端末１０２，１０３は、多重請負構造を構成する二次請ＳＩ（Ｂシステムズ）、三次請ＳＩ（Ｃシステムズ）によって使用される。以下、受発注者端末１０１〜１０３を個々に区別する必要がない場合、受発注者端末１０と称する。
一次請ＳＩは、顧客から業務委託契約（例えば、準委任契約）を受注する。一次請ＳＩは、一般的には大手ＳＩが担う。二次請ＳＩは、一次請ＳＩから業務委託契約（例えば、準委任契約）を受注する。二次請ＳＩは、一般的には一次請ＳＩよりも会社規模が小さい。三次請ＳＩは、二次請ＳＩから業務委託契約（例えば、準委任契約）を受注する。三次請ＳＩは、一般的には二次請ＳＩよりも会社規模が小さい。
なお、同図においては、多重請負構造が一次請ＳＩ、二次請ＳＩ、及び三次請ＳＩから構成されるものと想定しているが、二次請ＳＩ及び三次請ＳＩは複数存在してもよい。また、四次請ＳＩ、五次請ＳＩ等が存在してもよい。その場合、四次請ＳＩ、五次請ＳＩ等も受発注者端末１０を使用するものとする。
金融機関端末２０は、金融機関によって使用される。金融機関は、三次請ＳＩ等に対してインボイスファイナンス（売掛金担保融資）を提供する。当然ながら、金融機関は、一次請ＳＩや二次請ＳＩ等にもインボイスファイナンス等の融資を提供できるが、以下においては、三次請ＳＩが金融機関に対してインボイスファイナイスを依頼する場合を想定して説明する。なお、金融機関とは、銀行、信用金庫に限らず、融資サービスを提供している各種の事業法人を含む。金融機関端末２０は、複数存在してもよい。
ルート認証局３０は、ルート証明書を保持する認証局であり、各ノードに付与する電子証明書を発行し、ＰＫＩ(Public Key Infrastructure)基盤を提供する。これにより、各ノードは、情報を暗号化する際に用いるそれぞれ専用の秘密鍵と、自己以外のノードによって暗号化されている情報を復号する際に用いる公開鍵を保持することができる。
公証サービス端末４０は、ルート認証局３０によってＰＫＩ基盤が提供されている受発注・融資システム１の各ノード間で通信するデータの二重使用判定機能、及び、電子署名機能を有する。具体的には、公証サービス端末４０は、受信したデータのハッシュ値を公証ＤＢ（データベース）４１に保存し、それ以降に受信したデータのハッシュ値を公証ＤＢ４１から検索し、一致するハッシュ値が検索できた場合には、データが二重使用されていると判定としてエラーを返信し、一致するハッシュ値が検索できなかった場合には、データが二重使用されていないと判定し、データに電子署名を付して返信する。
次に、図２は、受発注者端末１０の構成例を示している。受発注者端末１０は、処理部１１、記憶部１２、入力部１３、表示部１４、及び通信部１５を備える。
受発注者端末１０は、ＣＰＵ(Central Processing Unit)等のプロセッサ、ＤＲＡＭ(Dynamic Random Access Memory)等のメモリ、ＨＤＤ(Hard Disk Drive)やＳＳＤ(Solid State Drive)等のストレージ、キーボード、マウス、タッチパネル等の入力デバイス、ディスプレイ等の出力デバイス、及び、ＮＩＣ(Network Interface Card)等の通信モジュールを備えるパーソナルコンピュータ等の一般的なコンピュータから成る。
処理部１１は、コンピュータのプロセッサにより実現される。処理部１１は、発注登録処理部１１１、受注処理部１１２、及びインボイス登録処理部１１３の機能ブロックを有する。これらの機能ブロックは、コンピュータのプロセッサがメモリにロードされた所定のプログラムを実行することによって実現される。さらに、図示は省略するが、コンピュータのプロセッサが所定のプログラムを実行することにより、ノード間で情報を送受信するためのメッセージキューが実現される。ただし、これらの機能ブロックの一部または全部を集積回路等によりハードウェアとして実現してもよい。
発注登録処理部１１１は、発注者から受注者に業務委託契約を発注する処理を実行する。受注処理部１１２は、発注者から発注された業務委託契約を受注する処理を実行する。インボイス登録処理部１１３は、金融機関に対してインボイスファイナンスを依頼する処理を実行する。
記憶部１２は、コンピュータのメモリ及びストレージによって実現される。記憶部１２には、契約ＤＢ１２１、階層ＤＢ１２２、及びインボイスＤＢ１２３が設けられる。契約ＤＢ１２１には、ノード間で通信された受発注取引情報が格納される。階層ＤＢ１２２には、ノード間で通信された階層取引情報が格納される。インボイスＤＢ１２３には、ノード間で通信されたインボイス取引情報が格納される。なお、記憶部１２には、上述した情報以外の情報を格納してもよい。
入力部１３は、コンピュータの入力デバイスによって実現される。入力部１３は、ユーザからの各種の操作を受け付ける。表示部１４は、コンピュータのディスプレイによって実現される。表示部１４は、例えば、ユーザが各種の情報を入力するための入力画面（不図示）等を表示する。通信部１５は、コンピュータの通信モジュールによって実現される。通信部１５は、ネットワーク２を介し、他の受発注者端末１０、金融機関端末２０、ルート認証局３０、公証サービス端末４０と接続して各種のデータや情報を通信する。
なお、以下においては必要に応じ、一次請ＳＩの受発注者端末１０１における処理部１１や発注登録処理部１１１等を処理部１１１，発注登録処理部１１１１等と称する。二次請ＳＩの受発注者端末１０２、三次請ＳＩの受発注者端末１０３における各構成要素や各機能ブロックについても同様とする。
次に、図３は、金融機関端末２０の構成例を示している。金融機関端末２０は、処理部２１、記憶部２２、入力部２３、表示部２４、及び通信部２５を備える。
金融機関端末２０は、受発注者端末１０と同様、一般的なコンピュータから成る。
処理部２１は、コンピュータのプロセッサにより実現される。処理部２１は、機能ブロックとしてのインボイス受付処理部２１１を有する。機能ブロックは、コンピュータのプロセッサがメモリにロードされた所定のプログラムを実行することによって実現される。さらに、図示は省略するが、コンピュータのプロセッサが所定のプログラムを実行することにより、ノード間で情報を送受信するためのメッセージキューが実現される。ただし、これらの機能ブロックの一部または全部を集積回路等によりハードウェアとして実現してもよい。
インボイス受付処理部２１１は、依頼者（三次請ＳＩ等）からの依頼に応じ、インボイスファイナンスを提供するための処理を実行する。
記憶部２２は、コンピュータのメモリ及びストレージによって実現される。記憶部２２には、インボイスＤＢ２２１が設けられる。インボイスＤＢ２２１には、依頼者（三次請ＳＩ等）との間で通信されたインボイス取引情報が格納される。なお、記憶部２２には、上述した情報以外の情報を格納してもよい。
入力部２３は、コンピュータの入力デバイスによって実現される。入力部２３は、ユーザからの各種の操作を受け付ける。表示部２４は、コンピュータの出力デバイスによって実現される。表示部２４は、例えば、三次請ＳＩの受発注者端末１０３から送信される、多重請負構造を可視化した階層取引情報を表す画面（不図示）等を表示する。通信部２５は、コンピュータの通信モジュールによって実現される。通信部２５は、ネットワーク２を介し、受発注者端末１０、ルート認証局３０、公証サービス端末４０と接続して各種のデータや情報を通信する。
＜ノード間で通信される取引情報５００のデータ構造＞
次に、図４は、ノード間で通信される取引情報５００のデータ構造の一例を示している。取引情報５００は、後述する受発注取引情報、階層取引情報、及びインボイス取引情報の上位概念である。図５は、取引情報５００と、該取引情報５００に繋がる１つ前の取引情報５０００との関係を説明するための図である。
取引情報５００には、ＵＴＸＯ(Unspent Transaction Output Model)が採用されている。ＵＴＸＯは、ある取引情報に含まれるアウトプットデータが、該取引情報に繋がる次の取引情報に含まれるインプットデータとなるモデルである。ある取引情報で一度インプットデータとして使用されたデータのハッシュ値は公証サービス端末４０の公証ＤＢ４１に保存され、二重使用判定機能に用いられる。また、ノード間で合意された各取引情報に対して、公証サービスが電子署名を付すことによって、取引情報のファイナリティ（合意された取引情報に対する公的な証明）が与えられ、これにより、取引間の紐づけが不可逆的となる。
取引情報５００は、前取引ハッシュ値５０１、取引情報ハッシュ値５０２、インプットデータ５０３、及びアウトプットデータ５０５を含むことができる。
前取引ハッシュ値５０１には、該取引情報５００に繋がる１つ前の取引情報５０００のハッシュ値５０２０がコピーされる。１つ前の取引情報５０００が存在しない場合、前取引ハッシュ値５０１は記録されない。
取引情報ハッシュ値５０２には、前取引ハッシュ値５０１、インプットデータ５０３のハッシュ値５０４、及びアウトプットデータ５０５のハッシュ値５０６を入力として算出された、該取引情報５００のハッシュ値が記録される。
なお、取引情報５００のハッシュ値を算出する際の入力に、インプットデータ５０３のハッシュ値５０４及びアウトプットデータ５０５のハッシュ値５０６、に加えて又は替えて、インプットデータ５０３及びアウトプットデータ５０５の少なくとも一方を採用してもよい。また、後述する電子署名は、取引情報５００のハッシュ値を算出する際の入力には用いない。
インプットデータ５０３には、該取引情報５００に繋がる１つ前の取引情報５０００のアウトプットデータ５０５０がコピーされる。インプットデータ５０３には、複数の項目のデータと、該複数の項目のデータのハッシュ値５０４とが含まれる。ただし、１つ前の取引情報５０００が存在しない場合、インプットデータ５０３は記録されない。
アウトプットデータ５０５には、取引相手のノードに伝えるべき複数の項目のデータと、該複数の項目データのハッシュ値５０６とが含まれる。
＜受発注データの一例＞
次に、図６は、取引情報５００としての受発注取引情報のアウトプットデータとなる受発注データ６００のデータ構造の一例である。同図は、一次請ＳＩであるＡシステムズと二次請ＳＩであるＢシステムズとの受発注案件に対応する受発注データ６００の例を示している。
受発注データ６００は、案件ＩＤ６０１、顧客名６０２、案件名６０３、開始日６０４、終了日６０５、発注者６０６、受注者６０７、及び契約金額６０８の各項目のデータ、並びにハッシュ値６０９を含む。
案件ＩＤ６０１には、一次請ＳＩであるＡシステムズと二次請ＳＩであるＢシステムズとの間の受発注案件を一意に特定できる識別子（同図の場合、ＡＢＣ１００）が記録される。顧客名６０２には、一次請ＳＩが受注した顧客名（同図の場合、Ｘ商事）が記録される。案件名６０３には、一次請ＳＩが受注した案件名（同図の場合、Ｘ商事システム更改）が記録される。
開始日６０４には、プロジェクト期間の開始日（同図の場合、２０２０／４／１）が記録される。終了日６０５には、プロジェクト期間の終了日（同図の場合、２０２０／６／３０）が記録される。発注者６０６には、案件ＩＤが表す受発注案件の発注者（同図の場合、Ａシステムズ）が記録される。受注者６０７には、案件ＩＤが表す受発注案件の受注者（同図の場合、Ｂシステムズ）が記録される。契約金額６０８には、案件ＩＤが表す受発注案件の契約金額（同図の場合、１千万円）が記録される。ハッシュ値６０９には、当該受発注データ６００のハッシュ値（同図の場合、ＡＢＣ１００ＨＡＳＨ）が記録される。
＜階層データの一例＞
次に、図７は、取引情報５００としての階層取引情報のアウトプットデータ及びインプットデータとなる階層データ７００のデータ構造の一例である。同図の場合、一次請ＳＩであるＡシステムズと二次請ＳＩであるＢシステムズとの受発注案件に対応する階層データ７００の例を示している。
階層データ７００は、階層ＩＤ７０１、案件ＩＤ７０２、階層レベル７０３、発注者７０４、及び受注者７０５の各項目のデータ、並びハッシュ値７０６を含む。
階層ＩＤ７０１には、一次請ＳＩであるＡシステムズと二次請ＳＩであるＢシステムズとの間の受発注案件に対応する階層データであることを一意に特定できる識別子（同図の場合、ＡＢＣ１００ＫＡＩＳＯ）が記録される。案件ＩＤ７０２には、一次請ＳＩであるＡシステムズと二次請ＳＩであるＢシステムズとの間の受発注案件を一意に特定できる識別子（同図の場合、ＡＢＣ１００）が記録される。
階層レベル７０３には、一次請ＳＩであるＡシステムズと二次請ＳＩであるＢシステムズとの間の受発注が多重請負構造の何層目であるかを表す値（同図の場合、１）が記録される。発注者７０４には、案件ＩＤが表す受発注案件の発注者（同図の場合、Ａシステムズ）が記録される。受注者７０５には、案件ＩＤが表す受発注案件の受注者（同図の場合、Ｂシステムズ）が記録される。ハッシュ値７０６には、当該階層データ７００のハッシュ値（同図の場合、ＡＢＣ１００ＫＤＨＡＳＨ）が記録される。
＜インボイスデータの一例＞
次に、図８は、取引情報５００としてのインボイス取引情報のアウトプットデータとなるインボイスデータ８００のデータ構造の一例である。同図の場合、三次請ＳＩであるＣシステムズが金融機関に対してファイナンスを依頼する際のインボイスデータ８００の例を示している。
インボイスデータ８００は、インボイスＩＤ８０１、案件ＩＤ８０２、発注者８０３、受注者８０４、契約金額８０５、ヘアカット率８０６、及び手数料８０７の各項目のデータ、並びハッシュ値８０８を含む。
インボイスＩＤ８０１には、二次請ＳＩであるＢシステムズと三次請ＳＩであるＣシステムズとの間の受発注案件に対応するインボイスデータであることを一意に特定できる識別子（同図の場合、ＡＢＣ１１０ＩＮＶ）が記録される。案件ＩＤ８０２には、二次請ＳＩであるＢシステムズと三次請ＳＩであるＣシステムズとの間の受発注案件を一意に特定できる識別子（同図の場合、ＡＢＣ１１０）が記録される。
発注者８０３には、案件ＩＤが表す受発注案件の発注者（同図の場合、Ｂシステムズ）が記録される。受注者８０４には、案件ＩＤが表す受発注案件の受注者（同図の場合、Ｃシステムズ）が記録される。ヘアカット率８０６及び手数料８０７には、金融機関が入力するマージン情報であり、ＢシステムズとＣシステムズとの間の契約金額に対する貸付金額の割合（ヘアカット率）と手数料が記録される。ハッシュ値８０８には、当該インボイスデータ８００のハッシュ値（同図の場合、ＡＢＣ１１０ＩＤ２ＨＡＳＨ）が記録される。
＜受発注・融資システム１による処理の流れ＞
次に、図９は、受発注・融資システム１による処理の流れを説明するフローチャートである。
一次請ＳＩ（Ａシステムズ）が顧客（Ｘ商事）からシステム更改を受注すると、初めに、一次請ＳＩの受発注者端末１０１が、顧客から受注した案件内容の情報を二次請ＳＩの候補であるＢシステムズの受発注者端末１０２に対して発注登録処理を行う（ステップＳ１）。なお、複数の二次請ＳＩの候補に対して発注登録処理を行ってもよい。
次に、二次請ＳＩの受発注者端末１０２が、受発注者端末１０１からの発注登録処理に応じて受注処理を行う（ステップＳ２）。具体的には、受発注者端末１０２が、発注の内容を確認して受注する旨を発注元の受発注者端末１０１に送信する。これにより、一次請ＳＩと二次請ＳＩとの契約が完了する。
次に、二次請ＳＩの受発注者端末１０２が、ステップＳ１と同様、三次請ＳＩの候補であるＣシステムズの受発注者端末１０３に対して発注登録処理を行う（ステップＳ３）。次に、受発注者端末１０３が、受発注者端末１０２からの発注登録処理に応じて受注処理を行う（ステップＳ４）。具体的には、三次請ＳＩでは、発注の内容に基づき、社内の人材のうち、受注案件に対してスキルや経験が適合し、且つ、プロジェクト期間に配属可能な人材を割り当てることが可能か否かを確認し、人材を割り当てることができる場合、受発注者端末１０３が、受注する旨を発注元の受発注者端末１０２に送信する。これにより、二次請ＳＩと三次請ＳＩとの契約が完了する。
次に、三次請ＳＩの受発注者端末１０３が、金融機関の金融機関端末２０に対してインボイスファイナンスを依頼するためのインボイス登録処理を行う（ステップＳ５）。該インボイス登録処理に際しては、多重請負構造を可視化可能な階層取引情報（詳細後述）が受発注者端末１０３から金融機関端末２０に送信される。なお、複数の金融機関に対してインボイス登録処理を行い、相見積もりを取るようにしてもよい。
次に、金融機関端末２０が、受発注者端末１０３からのインボイス登録処理に応じてインボイス受付処理を行う（ステップＳ６）。具体的には、金融機関は、多重請負構造におけるＣシステムズの階層と、その上層側（いまの場合、Ｂシステムズ及びＡシステムズ）とを確認する。そして、金融機関は、発注の元がＡシステムズであることを考慮してＣシステムズに対する与信を実施し、マージン情報（ヘアカット率、及び手数料）を決定して依頼元の受発注者端末１０３に送信する。受発注者端末１０３では、マージン情報を確認し、問題なければ金融機関との契約を確定する。この後、金融機関からＣシステムズに対する融資が実行されることになる。以上で、受発注・融資システム１による処理の流れの説明を終了する。以下、上述した各処理の詳細について説明する。
＜一次請ＳＩ（Ａシステムズ）による発注登録処理（図９のステップＳ１）について＞
次に、図１０は、一次請ＳＩから二次請ＳＩに対する発注登録処理の一例を説明するフローチャートである。
該発注登録処理は、顧客（Ｘ商事）からの仕事（システム更改）を受注した一次請ＳＩの受発注者端末１０１に対するユーザからの所定の操作に応じて開始される。
同図に示されるように、発注登録処理は、受発注取引情報作成処理（ステップＳ１１）、及び階層取引情報作成処理（ステップＳ１２）から成る。ただし、受発注取引情報作成処理（ステップＳ１１）、及び階層取引情報作成処理（ステップＳ１２）は、実際には、同時に並行して実行される。
図１１は、受発注取引情報作成処理（ステップＳ１１）の一例を説明するフローチャートである。図１２は、受発注取引情報作成処理にて一次請ＳＩの受発注者端末１０１から二次請ＳＩの受発注者端末１０２に送信される受発注取引情報１０００の一例を示している。
始めに、受発注者端末１０１の発注登録処理部１１１１が、発注画面６０００（図３３）に対するユーザからの入力に基づき、二次請ＳＩの受発注者端末１０２に送信するための受発注取引情報１０００のアウトプットデータ１００１に受発注データを記録する（ステップＳ２１）。
具体的には、例えば、一次請ＳＩから二次請ＳＩへの発注では、ユーザが受発注データの全ての項目を入力する必要がある。ただし、案件ＩＤは、ユーザが入力してもよいし、発注登録処理部１１１１が他の受発注データと重複しない文字列を生成するようにしてもよい。また例えば、二次請ＳＩから三次請ＳＩへの発注では、ユーザが発注画面６０００の前取引案件ＩＤ入力エリア６００１（図３３）に入力した、上層側から受注した取引案件の案件ＩＤに基づき、該案件ＩＤに対応する受発注データが契約ＤＢ１２１から読み出されて、その顧客名、案件名、開始日、終了日、及び受注者（次の発注者として）が流用される。この場合、ユーザは、受注者、及び契約金額の項目にだけ入力すればよい。
次に、発注登録処理部１１１１が、ステップＳ２１で記録した受発注データのハッシュ値１００２を算出し、受発注取引情報１０００に記録する（ステップＳ２２）。
なお、受発注取引情報１０００については、多重請負構造に関係なく、２社（いまの場合、ＡシステムズとＢシステムズ）間の受発注に対応するものであるため、それに繋がる１つ前の受発注取引情報は存在しない。よって、受発注取引情報１０００には、インプットデータ、及び前取引ハッシュ値が記録されない。
次に、発注登録処理部１１１１が、受発注取引情報１０００のハッシュ値１００３を算出して、受発注取引情報１０００に記録する（ステップＳ２３）。
次に、発注登録処理部１１１１が、発注者（Ａシステムズ）の秘密鍵を用い、ステップＳ２２で算出した受発注取引情報１０００のハッシュ値１００３を暗号化することによって発注者の電子署名１００４を作成する（ステップＳ２４）。
次に、発注登録処理部１１１１が、受発注取引情報１０００に電子署名１００４を付して受注者（Ｂシステムズ）の受発注者端末１０２に送信する（ステップＳ２５）。
次に、発注登録処理部１１１１が、電子署名１００４を付した受発注取引情報１０００を契約ＤＢ１２１１に保存する（ステップＳ２６）。
次に、発注登録処理部１１１１が、受発注者端末１０２から返信された受発注取引情報１０００（図１７）を受信したか否かを判断し（ステップＳ２７）、受信していないと判断した場合（ステップＳ２７でＮＯ）、当該判断を繰り返す。その後、発注登録処理部１１１１が、返信された受発注取引情報１０００を受信したと判断した場合（ステップＳ２７でＹＥＳ）、処理はステップＳ２８に進められる。ステップＳ２８以降については後述する。
次に、図１３は、階層取引情報作成処理（ステップＳ１２）の一例を説明するフローチャートである。図１４は、階層取引情報作成処理にて一次請ＳＩの受発注者端末１０１から二次請ＳＩの受発注者端末１０２に送信される階層取引情報２０００の一例を示している。
始めに、受発注者端末１０１の発注登録処理部１１１１が、二次請ＳＩの受発注者端末１０２に送信するための階層取引情報２０００（図１４）に繋がる１つ前の取引情報が存在するか否かを判定する（ステップＳ４１）。具体的には、ユーザが発注画面６０００の前取引案件ＩＤ入力エリア６００１（図３３）に案件ＩＤを入力した場合、階層取引情報２０００に繋がる１つ前の取引情報が存在すると判定する。
ここで、階層取引情報２０００に繋がる１つ前の階層取引情報が存在すると判定された場合（ステップＳ４１でＹＥＳ）、発注登録処理部１１１１が、階層取引情報２０００の前取引ハッシュ値２００１に、１つ前の階層取引情報のハッシュ値をコピーするとともに、階層取引情報２０００のインプットデータ２００２に、１つ前の階層取引情報のアウトプットデータ（アウトプットデータのハッシュ値を含む）をコピーする（ステップＳ４２）。
反対に、階層取引情報２０００に繋がる１つ前の階層取引情報が存在しないと判定された場合（ステップＳ４１でＮＯ）、ステップＳ４２はスキップされる。いまの場合、階層取引情報２０００は、一次請ＳＩから二次請ＳＩへの発注案件に対応するものであり、それに繋がる１つ前の階層取引情報は存在しないので、ステップＳ４２はスキップされ、階層取引情報２０００における前取引ハッシュ値２００１、及びインプットデータ２００２は記録されない。
次に、発注登録処理部１１１１が、契約ＤＢ１２１１の受発注取引情報１０００を参照して、階層取引情報２０００のアウトプットデータ２００３に、階層データの階層レベル１１０４以外の項目、すなわち、階層ＩＤ、案件ＩＤ、発注者、及び受注者を記録する（ステップＳ４３）。
次に、発注登録処理部１１１１が、階層取引情報２０００のアウトプットデータ２００３に記録した階層データの階層レベル２００４に、ステップＳ４２でインプットデータ（１つ前の階層取引情報のアウトプットデータ）２００２に記録した階層データの階層レベルに１だけ加算した値を記録する（ステップＳ４４）。いまの場合、ステップＳ４２はスキップされており、インプットデータ２００２は記録されていないので、階層レベル２００４に１を記録する。
次に、発注登録処理部１１１１が、アウトプットデータ２００３に記録した階層データのハッシュ値２００５を算出して階層取引情報２０００に記録する（ステップＳ４５）。
次に、発注登録処理部１１１１が、階層取引情報２０００のハッシュ値２００６を算出して、階層取引情報２０００に記録する（ステップＳ４６）。
次に、発注登録処理部１１１１が、発注者（Ａシステムズ）の秘密鍵を用いて階層取引情報２０００のハッシュ値２００６を暗号化することによって発注者の電子署名２００７を作成する（ステップＳ４７）。
次に、発注登録処理部１１１１が、電子署名２００７を付した階層取引情報２０００を受注者（Ｂシステムズ）の受発注者端末１０２に送信する（ステップＳ４８）。なお、前の取引案件が存在する場合、階層取引情報２０００に連なる一連の階層取引情報（電子署名付）を階層ＤＢ１２２１から読み出して受注者の受発注者端末１０に送信するようにする。
次に、発注登録処理部１１１１が、電子署名２００７を付した階層取引情報２０００を階層ＤＢ１２２１に保存する（ステップＳ４９）。
次に、発注登録処理部１１１１が、受発注者端末１０２から返信された階層取引情報２０００（図１９）を受信したか否かを判断し（ステップＳ５０）、受信していないと判断した場合（ステップＳ５０でＮＯ）、当該判断を繰り返す。その後、発注登録処理部１１１１が、返信された階層取引情報２０００を受信したと判断した場合（ステップＳ５０でＹＥＳ）、処理はステップＳ５１に進められる。ステップＳ５１以降については後述する。
＜二次請ＳＩ（Ｂシステムズ）による受注処理（図９のステップＳ２）について＞
次に、図１５は、二次請ＳＩによる受注処理の一例を説明するフローチャートである。
該受注処理は、二次請ＳＩの受発注者端末１０２に対するユーザからの所定の操作に応じて開始される。
同図に示されるように、該受注処理は、受発注取引情報確認処理（ステップＳ６１）、及び階層取引情報確認処理（ステップＳ６２）から成る。ただし、受発注取引情報確認処理（ステップＳ６１）、及び階層取引情報確認処理（ステップＳ６２）は、実際には、同時に並行して実行される。
図１６は、受発注取引情報確認処理（ステップＳ６１）の一例を説明するフローチャートである。図１７は、受発注取引情報確認処理にて二次請ＳＩの受発注者端末１０２から一次請ＳＩの受発注者端末１０１に返信される受発注取引情報１０００の一例を示している。
始めに、受発注者端末１０２の受注処理部１１２２が、一次請ＳＩの受発注者端末１０１から送信された受発注取引情報１０００（図１２）を受信したか否かを判断する（ステップＳ７１）。ここで、受発注取引情報１０００を受信していないと判断した場合（ステップＳ７１でＮＯ）、当該判断を繰り返す。
その後、受発注取引情報１０００を受信したと判断した場合（ステップＳ７１でＹＥＳ）、受注処理部１１２２が、受発注取引情報１０００に付された電子署名１００４が一次請ＳＩの受発注者端末１０１にて作成された正規のものであることを検証するとともに、受発注取引情報１０００の内容に改ざんがないことを確認して受注画面６１００（図３４）を表示する（ステップＳ７２）。
具体的には、ルート認証局３０から事前に配布されている、一次請ＳＩの秘密鍵に対応する公開鍵により、電子署名１００４に含まれる暗号化されているハッシュ値の復号を行い、復号できた場合には電子署名１００４が正規のものと判断する。また、受信した受発注取引情報１０００のハッシュ値を改めて算出し、算出したハッシュ値と、復号されたハッシュ値とが一致した場合には受発注取引情報１０００の内容に改ざんが無いと判断する。
なお、ステップＳ７２において、受発注取引情報１０００に付された電子署名１００４が正規のものではなかったり、受発注取引情報１０００の内容に改ざんがあったりしたと判断された場合、またはユーザが受注画面６１００の辞退ボタン６１０３（図３４）を操作した場合、該受発注取引情報確認処理は中断される。
次に、受注処理部１１２２が、ユーザが受注画面６１００の受注ボタン６１０２（図３４）を操作したことに応じ、受信した受発注取引情報１０００のハッシュ値を改めて算出し（ステップＳ７３）、算出したハッシュ値を受注者（Ｂシステムズ）の秘密鍵を用いて暗号化することによって受注者の電子署名１１０１（図１７）を作成する（ステップＳ７４）。
次に、受注処理部１１２２が、電子署名１１０１を追加して付した受発注取引情報１０００を発注者（Ａシステムズ）の受発注者端末１０１に返信する（ステップＳ７５）。
次に、受注処理部１１２２が、電子署名１００４，１１０１が付された受発注取引情報１０００を取引ＤＢ１２１２に保存する（ステップＳ７６）。
次に、受注処理部１１２２が、受発注者端末１０１から送信された公証サービスの電子署名１２０１（図２２）を受信したか否かを判断し（ステップＳ７７）、受信していないと判断した場合（ステップＳ７７でＮＯ）、当該判断を繰り返す。その後、受注処理部１１２２が公証サービスの電子署名１２０１を受信したと判断した場合（ステップＳ７７でＹＥＳ）、処理はステップＳ７８に進められる。ステップＳ７８以降については後述する。
次に、図１８は、階層取引情報確認処理（ステップＳ６２）の一例を説明するフローチャートである。図１９は、階層取引情報確認処理にて二次請ＳＩの受発注者端末１０２から一次請ＳＩの受発注者端末１０１に返信される階層取引情報２０００の一例を示している。
始めに、受発注者端末１０２の受注処理部１１２２が、一次請ＳＩの受発注者端末１０１から送信された階層取引情報２０００（図１４）を受信したか否かを判断する（ステップＳ８１）。ここで、階層取引情報２０００を受信していないと判断した場合（ステップＳ８１でＮＯ）、当該判断を繰り返す。
その後、階層取引情報２０００を受信したと判断した場合（ステップＳ８１でＹＥＳ）、受注処理部１１２２が、階層取引情報２０００に付された電子署名２００７が一次請ＳＩの受発注者端末１０１にて作成された正規のものであることを検証するとともに、階層取引情報２０００の内容に改ざんがないことを確認する（ステップＳ８２）。
なお、電子署名２００７が正規のものであることの検証方法、及び、階層取引情報２０００の内容に改ざんがないことの確認方法については、上述した電子署名１００４、及び受発注取引情報１０００の場合と同様なのでその説明は、適宜、省略する。以降においても同様とする。
さらに、階層取引情報２０００とともに、それに連なる一連の階層取引情報（電子署名付）を受信した場合、受注処理部１１２２が、それらについても、電子署名を検証し、内容に改ざんがないことを確認する。
なお、ステップＳ８２において、電子署名２００７等が正規のものではなかったり、階層取引情報２０００等の内容に改ざんがあったりしたと判断された場合、ユーザにエラーが通知されて該階層取引情報確認処理は中断される。
次に、受注処理部１１２２が、受信した階層取引情報２０００のハッシュ値を改めて算出し（ステップＳ８３）、算出したハッシュ値を受注者（Ｂシステムズ）の秘密鍵を用いて暗号化受注者の電子署名２１０１（図１９）を作成する（ステップＳ８４）。
次に、受注処理部１１２２が、電子署名２１０１を追加して付した階層取引情報２０００を発注者（Ａシステムズ）の受発注者端末１０１に返信する（ステップＳ８５）。
次に、受注処理部１１２２が、電子署名２００７，２１０１が付された階層取引情報２０００を階層ＤＢ１２２２に保存する（ステップＳ８６）。なお、階層取引情報２０００とともに、それに連なる一連の階層取引情報を受信していた場合には、それらも階層ＤＢ１２２２に保存する。
次に、受注処理部１１２２が、受発注者端末１０１から送信される公証サービスの電子署名２２０１（図２３）を受信したか否かを判断し（ステップＳ８７）、受信していないと判断した場合（ステップＳ８７でＮＯ）、当該判断を繰り返す。その後、受注処理部１１２２が電子署名２２０１を受信したと判断した場合（ステップＳ８７でＹＥＳ）、処理はステップＳ８８に進められる。ステップＳ８８以降については後述する。
上述した二次請ＳＩの受発注者端末１０２による受発注取引情報確認処理のステップＳ７５、及び、階層取引情報確認処理のステップＳ８５により、受発注者端末１０２から受発注者端末１０１に対して受発注取引情報１０００及び階層取引情報２０００が返信され、これらが受発注者端末１０１によって受信されることになる。これにより、受発注者端末１０１では、受発注取引情報作成処理（図１１）のステップＳ２８以降、及び、階層取引情報作成処理（図１３）のステップＳ５１以降が再開される。
まず、受発注取引情報作成処理（図１１）のステップＳ２８以降について説明する。図１１に戻る。次に、受発注者端末１０２から返信された受発注取引情報１０００（図１７）を受信したと判断した発注登録処理部１１１１が、受発注取引情報１０００に付された電子署名１１０１が二次請ＳＩの受発注者端末１０２にて作成された正規のものであることを検証するとともに、受発注取引情報１０００の内容に改ざんがないことを確認してから、受信した受発注取引情報１０００を契約ＤＢ１２１１に保存する（ステップＳ２８）。
なお、契約ＤＢ１２１１への受発注取引情報１０００の保存は、ステップＳ２６で保存した受発注取引情報１０００に上書きせずに新規で保存するようにする。
また、ステップＳ２８において、受発注取引情報１０００に付された電子署名１１０１が正規のものではなかったり、受発注取引情報１０００の内容に改ざんがあったりしたと判断された場合、ユーザにエラーが通知されて該受発注取引情報作成処理は中断される。
次に、発注登録処理部１１１１が、受信した受発注取引情報１０００から、受発注取引情報１０００のハッシュ値１００３と、インプットデータのハッシュ値とを抽出して、受発注取引情報１０００に対する公証依頼情報を作成する（ステップＳ２９）。
図２０は、受発注取引情報１０００に対する公証依頼情報３０００の一例を示している。いまの場合、受発注取引情報１０００にはインプットデータが記録されていないので、受発注取引情報１０００から取引情報のハッシュ値１００３だけが抽出されて、公証依頼情報３０００が作成される。同図に示されるように、公証依頼情報３０００には、受発注取引情報１０００に記録されていたインプットデータ及びアウトプットデータの各項目の情報（ハッシュ値を除く）は記録されないので、受注取引の内容が受発注取引の当事者以外の第三者（いまの場合、公証サービス端末４０のユーザ等）に漏洩することを抑止できる。
図１１に戻る。次に、発注登録処理部１１１１が、受発注取引情報１０００に対する公証依頼情報３０００を公証サービス端末４０に送信する（ステップＳ３０）。
ここで、公証依頼情報３０００等の公証依頼情報に応じて公証サービス端末４０が実行する公証サービス処理について説明する。
図２１は、公証サービス処理の一例を説明するフローチャートである。該公証サービス処理は、公証サービス端末４０が公証依頼情報を受信したことに応じて開始される。
始めに、公証サービス端末４０が、公証依頼情報に含まれるインプットデータのハッシュ値が公証ＤＢ４１に登録済みであるか否かを判定する（ステップＳ９１）。ここで、該ハッシュ値が、公証ＤＢ４１に登録済みであると判定した場合（ステップＳ９１でＹＥＳ）、公証依頼情報に含まれるインプットデータが二重使用されていることになるので、依頼者にエラーを通知し（ステップＳ９２）、公証サービス処理を終了する。
反対に、該ハッシュ値が、公証ＤＢ４１に登録済みではないと判定した場合（ステップＳ９１でＮＯ）、次に、公証サービス端末４０が、公証依頼情報に含まれる取引情報のハッシュ値（例えば、図２０の取引情報のハッシュ値１００３）を、公証サービスの秘密鍵で暗号化公証サービスの電子署名１２０１（図２２）を作成する（ステップＳ９３）。
次に、公証サービス端末４０が、公証依頼情報に含まれるインプットデータのハッシュ値を公証ＤＢ４１に保存する（ステップＳ９４）。
次に、公証サービス端末４０が、公証サービスの電子署名１２０１を、公証依頼情報を送信した依頼者の受発注者端末１０に送信する（ステップＳ９５）。以上で、公証サービス処理は終了される。
図１１に戻る。次に、発注登録処理部１１１１が、公証サービス端末４０から送信された公証サービスの電子署名１２０１を受信したか否かを判断し（ステップＳ３１）、受信していないと判断した場合（ステップＳ３１でＮＯ）、該判断を継続する。公証サービスの電子署名１２０１を受信したと判断した場合（ステップＳ３１でＹＥＳ）、次に、発注登録処理部１１１１が、電子署名１２０１が公証サービス端末４０にて作成された正規のものであることを検証する（ステップＳ３２）。
なお、ステップＳ３２において、公証サービスの電子署名１２０１が正規のものではないと判断された場合、ユーザにエラーが通知されて該受発注取引情報作成処理は中断される。
次に、発注登録処理部１１１１が、契約ＤＢ１２１１に保存されている、電子署名１００４，１１０１が付された受発注取引情報１０００に、公証サービスの電子署名１２０１を追加で付して保存する（ステップＳ３３）。これにより、受発注者端末１０１の契約ＤＢ１２１１には、電子署名１００４，１１０１，１２０１が付された受発注取引情報１０００が保存されたことになる。
次に、発注登録処理部１１１１が、公証サービスの電子署名１２０１を受注者である二次請ＳＩの受発注者端末１０２に送信する（ステップＳ３４）。以上で、一次請ＳＩの受発注者端末１０１による受発注取引情報作成処理は終了される。
受発注取引情報作成処理のステップＳ３４により、公証サービスの電子署名１２０１が二次請ＳＩの受発注者端末１０２に送信され、受発注者端末１０２によって受信されることになる。これにより、受発注者端末１０２では受発注取引情報確認処理（図１６）のステップＳ７８以降が再開される。
図１６に戻る。次に、受注処理部１１２２が、受信した電子署名１２０１が公証サービス端末４０にて作成された正規のものであることを検証する（ステップＳ７８）。
なお、ステップＳ７８において、公証サービスの電子署名１２０１が正規のものではないと判断された場合、ユーザにエラーが通知されて該受発注取引確認処理は中断される。
次に、受注処理部１１２２が、契約ＤＢ１２１２に保存されている、電子署名１００４，１１０１が付された受発注取引情報１０００（図１７）に、公証サービスの電子署名１２０１を追加で付して保存する（ステップＳ７９）。これにより、受発注者端末１０２の契約ＤＢ１２１２には、電子署名１００４，１１０１，１２０１が付された受発注取引情報１０００が保存されたことになる。以上で、二次請ＳＩの受発注者端末１０２による受発注取引情報確認処理は終了される。
この段階で、発注者である一次請ＳＩの受発注者端末１０１の契約ＤＢ１２１１と、受注者である二次請ＳＩの受発注者端末１０２の契約ＤＢ１２１２とには、一次請ＳＩの電子署名１００４、二次請ＳＩの電子署名１１０１、及び公証サービスの電子署名１２０１が付された受発注取引情報１０００が共有されたので、一次請ＳＩのＡシステムズと二次請ＳＩのＢシステムズとの受注取引が成立し、且つ、公的な証明が与えられたことになる。
次に、階層取引情報作成処理（図１３）のステップＳ５１以降について説明する。図１３に戻る。受発注者端末１０２から返信された階層取引情報２０００（図１９）を受信したと判断した発注登録処理部１１１１が、階層取引情報２０００に付された電子署名２１０１が二次請ＳＩの受発注者端末１０２にて作成された正規のものであることを検証するとともに、階層取引情報２０００の内容に改ざんがないことを確認してから、受信した階層取引情報２０００を階層ＤＢ１２２１に保存する（ステップＳ５１）。
なお、階層ＤＢ１２２１への階層取引情報２０００の保存は、ステップＳ４９で保存した階層取引情報２０００に上書きせずに新規で保存するようにする。
また、ステップＳ５１において、階層取引情報２０００に付された電子署名２１０１が正規のものではなかったり、階層取引情報２０００の内容に改ざんがあったりしたと判断された場合、ユーザにエラーが通知されて該階層取引情報作成処理は中断される。
次に、発注登録処理部１１１１が、受信した階層取引情報２０００から、階層取引情報２０００のハッシュ値２００６と、インプットデータのハッシュ値とを抽出して、階層取引情報２０００に対する公証依頼情報を作成する（ステップＳ５２）。なお、いまの場合、階層取引情報２０００にはインプットデータが記録されていないので、階層取引情報２０００から取引情報のハッシュ値２００６だけが抽出されて、公証依頼情報が作成される。ここで、作成される公証依頼情報は、図２０に示された、受発注取引情報１０００に対する公証依頼情報３０００と同様であるため、その図示は省略する。
次に、発注登録処理部１１１１が、階層取引情報２０００に対する公証依頼情報を公証サービス端末４０に送信する（ステップＳ５３）。公証サービス端末４０では、該公証依頼情報に応じて上述した公証サービス処理（図２１）が実行され、公証サービス端末４０から受発注者端末１０１に公証サービスの電子署名２２０１（図２３）が送信される。
次に、発注登録処理部１１１１が、公証サービス端末４０から送信された公証サービスの電子署名２２０１を受信したか否かを判断し（ステップＳ５４）、受信していないと判断した場合（ステップＳ５４でＮＯ）、該判断を継続する。公証サービスの電子署名２２０１を受信したと判断した場合（ステップＳ５４でＹＥＳ）、次に、発注登録処理部１１１１が、電子署名２２０１が公証サービス端末４０にて作成された正規のものであることを検証する（ステップＳ５５）。
なお、ステップＳ５５において、公証サービスの電子署名２２０１が正規のものではないと判断された場合、ユーザにエラーが通知されて該階層取引情報作成処理は中断される。
次に、発注登録処理部１１１１が、階層ＤＢ１２２１に保存されている、電子署名２００７，２１０１が付された階層取引情報２０００（図１９）に、公証サービスの電子署名２２０１を追加で付して保存する（ステップＳ５６）。これにより、受発注者端末１０１の階層ＤＢ１２２１には、電子署名２００７，２１０１，２２０１が付された階層取引情報２０００が保存されたことになる。
次に、発注登録処理部１１１１が、公証サービスの電子署名２２０１を受注者である二次請ＳＩの受発注者端末１０２に送信する（ステップＳ５７）。以上で、一次請ＳＩの受発注者端末１０１による階層取引情報作成処理は終了される。
受発注取引情報作成処理のステップＳ５７により、公証サービスの電子署名２２０１が二次請ＳＩの受発注者端末１０２に送信され、受発注者端末１０２によって受信されることになる。これにより、受発注者端末１０２では階層取引情報確認処理（図１８）のステップＳ８８以降が再開される。
図１８に戻る。次に、受注処理部１１２２が、受信した電子署名２２０１が公証サービス端末４０にて作成された正規のものであることを検証する（ステップＳ８８）。具体的には、ルート認証局３０から事前に配布されている、公証サービスの秘密鍵に対応する公開鍵により、電子署名２２０１に含まれる暗号化されているハッシュ値の復号を行い、復号できた場合には電子署名２２０１が正規のものと判断する。
なお、ステップＳ８８において、公証サービスの電子署名２２０１が正規のものではないと判断された場合、ユーザにエラーが通知されて該階層取引確認処理は中断される。
次に、受注処理部１１２２が、階層ＤＢ１２２２に保存されている、電子署名２００７，２１０１が付された階層取引情報２０００（図１９）に公証サービスの電子署名２２０１を追加で付して保存する（ステップＳ８９）。これにより、受発注者端末１０２の階層ＤＢ１２２２には、電子署名２００７，２１０１，２２０１が付された階層取引情報２０００が保存されたことになる。以上で、二次請ＳＩの受発注者端末１０２による階層取引情報確認処理は終了される。
この段階で、発注者である一次請ＳＩの受発注者端末１０１の階層ＤＢ１２２１と、受注者である二次請ＳＩの受発注者端末１０２の階層ＤＢ１２２２とには、一次請ＳＩの電子署名２００７、二次請ＳＩの電子署名２１０１、及び公証サービスの電子署名２２０１が付された階層取引情報２０００が共有されたことになる。階層取引情報２０００は、一次請ＳＩから二次請ＳＩへの請負構造を表すので、一次請ＳＩから二次請ＳＩへの請負構造が公的に証明されたことになる。
＜二次請ＳＩ（Ｂシステムズ）による発注登録処理（図９のステップＳ３）について＞
ステップＳ３の発注登録処理では、上述したステップＳ１の発注登録処理と同様の処理が行われる。
図２４は、ステップＳ３の発注登録処理が実行されたことにより、発注者である二次請ＳＩの受発注者端末１０２の契約ＤＢ１２１２と、受注者である三次請ＳＩの受発注者端末１０３の契約ＤＢ１２１３とに保存され、共有された受発注取引情報１３００の一例を示している。
受発注取引情報１３００は、ステップＳ１の発注登録処理で保存、共有された受発注取引情報１０００（図２２）から、アウトプットデータのデータ名、案件ＩＤ、発注者、受注者、及び契約金額の各項目の内容が変更されたものとなる。
受発注取引情報１３００には、二次請ＳＩの電子署名１３０１、三次請ＳＩの電子署名１３０２、及び公証サービスの電子署名１３０３が付されているので、二次請ＳＩのＢシステムズと三次請ＳＩのＣシステムズとの受注取引が成立し、公的に証明されたことになる。
＜三次請ＳＩ（Ｃシステムズ）による受注処理（図９のステップＳ４）について＞
ステップＳ４の受注処理では、上述したステップＳ２の受注処理と同様の処理が行われる。
図２５は、ステップＳ４の受注処理が実行されたことにより、発注者である二次請ＳＩの受発注者端末１０２の階層ＤＢ１２２２と、受注者である三次請ＳＩの受発注者端末１０３の階層ＤＢ１２２３とに保存され、共有された階層取引情報２３００の一例を示している。
階層取引情報２３００は、そのインプットデータ２３０１に、ステップＳ１の受注処理で保存及び共有された階層取引情報２０００（図２３）のアウトプットデータ２００３がコピーされ、その前取引ハッシュ値２３０２に、階層取引情報２０００のハッシュ値２００６がコピーされている。階層取引情報２３００のアウトプットデータ２３０３の階層レベルには、インプットデータ２３０１の階層レベルである１に１が加算された２が記録されている。
階層取引情報２３００には、二次請ＳＩの電子署名２３０４、三次請ＳＩの電子署名２３０５、及び公証サービスの電子署名２３０６が付されている。階層取引情報２３００は、一次請ＳＩから三次請ＳＩに至る多重請負構造を表すので、一次請ＳＩから三次請ＳＩに至る多重請負構造が公的に証明されたことになる。
＜三次請ＳＩ（Ｃシステムズ）によるインボイス登録処理（図９のステップＳ５）について＞
次に、図２６は、三次請ＳＩ（Ｃシステムズ）によるインボイス登録処理の一例を説明するフローチャートである。図２７は、インボイス登録処理にて依頼者の受発注者端末１０３から金融機関端末２０に送信されるインボイス取引情報４０００の一例を示している。
該インボイス登録処理は、依頼者の受発注者端末１０３に対するユーザからの所定の操作に応じて開始される。
始めに、インボイス登録処理部１１３３が、階層ＤＢ１２２３から、インボイスファイナンスで担保とする受注案件の案件ＩＤ（ユーザにより指定される）に対応する階層データを検索し、インボイス取引情報４０００（図２７）のインプットデータ４００１にコピーする（ステップＳ１０１）。いまの場合、階層ＤＢ１２２３から、案件ＩＤ（ＡＢＣ１１０）に対する階層取引情報２３００（図２３）のアウトプットデータ２３０３に記録されている階層データが検索されて、インボイス取引情報４０００のインプットデータ４００１にコピーされる。
次に、インボイス登録処理部１１３３が、該階層データに紐づけられた階層取引情報とそれに連なる上位側の一連の階層取引情報を階層ＤＢ１２２３から取得する（ステップＳ１０２）。
次に、インボイス登録処理部１１３３が、契約ＤＢ１２１３に保存されている、インボイスファイナンスで担保とする受注案件の案件ＩＤに対応する受発注取引情報１３００（図２４）に基づいて、インボイス取引情報４０００のアウトプットデータ４００２にインボイスデータを記録する（ステップＳ１０３）。インボイスＩＤは、ユーザが入力してもよいし、インボイス登録処理部１１３３が他のインボイスデータと重複しない文字列を生成するようにしてもよい。なお、インボイスデータのヘアカット率及び手数料については金融機関にて記録されるので空欄でよい。
次に、インボイス登録処理部１１３３が、インボイス取引情報４０００の前取引ハッシュ値４００３に、一つ上位の階層取引情報２３００（図２５）のハッシュ値２３０７を記録する（ステップＳ１０４）。
次に、インボイス登録処理部１１３３が、インボイス取引情報４０００のハッシュ値４００４を算出してインボイス取引情報４０００に記録し（ステップＳ１０５）、ハッシュ値４００４を依頼者（Ｃシステムズ）の秘密鍵を用いて暗号化することによって依頼者の電子署名４００５を作成する（ステップＳ１０６）。
次に、インボイス登録処理部１１３３が、電子署名４００５を付したインボイス取引情報４０００、及びステップＳ１０２で取得した一連の階層取引情報２０００，２３００を金融機関端末２０に送信する（ステップＳ１０７）。
金融機関端末２０に送信するインボイス取引情報４０００には、階層データと、インボイスファイナンスに必要な最低限の項目だけが記録されているので、受発注取引の第三者である金融機関に受発注取引に関する情報が漏洩することを抑止できる。
次に、インボイス登録処理部１１３３が、電子署名４００５を付したインボイス取引情報４０００をインボイスＤＢ１２３３に保存する（ステップＳ１０８）。
次に、インボイス登録処理部１１３３が、金融機関端末２０から返信されたインボイス取引情報４１００（図２９）を受信したか否かを判断し（ステップＳ１０９）、受信していないと判断した場合（ステップＳ１０９でＮＯ）、当該判断を繰り返す。その後、インボイス登録処理部１１３３が、返信されたインボイス取引情報４１００を受信したと判断した場合（ステップＳ１０９でＹＥＳ）、処理はステップＳ１１０に進められる。ステップＳ１１０以降については後述する。
＜金融機関によるインボイス受付処理（図９のステップＳ６）について＞
次に、図２８は、金融機関によるインボイス受付処理の一例を説明するフローチャートである。図２９は、インボイス受付処理にて金融機関端末２０から依頼者の受発注者端末１０３に返信されるインボイス取引情報４１００の一例を示している。
該インボイス受付処理は、金融機関端末２０に対するユーザからの所定の操作に応じて開始される。
始めに、金融機関端末２０のインボイス受付処理部２１１が、依頼者の受発注者端末１０３から送信されたインボイス取引情報４０００（図２７）、及び階層取引情報２０００，２３００を受信したか否かを判断する（ステップＳ１２１）。ここで、インボイス取引情報４０００、及び階層取引情報２０００，２３００を受信していないと判断した場合（ステップＳ１２１でＮＯ）、当該判断を繰り返す。
その後、インボイス取引情報４０００、及び階層取引情報２０００，２３００を受信したと判断した場合（ステップＳ１２１でＹＥＳ）、インボイス受付処理部２１１が、インボイス取引情報４０００に付された電子署名４００５が依頼者の受発注者端末１０３にて作成された正規のものであることを検証するとともに、インボイス取引情報４０００の内容に改ざんがないことを確認し、また、階層取引情報２０００，２３００についても電子署名の検証および内容に改ざんがないことの確認を行い、受付画面６２００（図３５）を表示する（ステップＳ１２２）。
なお、ステップＳ１２２において、電子署名４００５等が正規のものではなかったり、インボイス取引情報４０００等の内容に改ざんがあったりしたと判断された場合、またはユーザが受付画面６２００の辞退ボタン６２０５（図３５）を操作した場合、該インボイス受付処理は中断される。
次に、インボイス受付処理部２１１が、インボイス取引情報４０００のインプットデータ４００１、アウトプットデータ４００２、及び前取引ハッシュ値４００３をコピーして、新たにインボイス取引情報４１００を作成する（ステップＳ１２３）。これにより、インボイス取引情報４０００のアウトプットデータ４００２とはデータ名が異なるアウトプットデータ４１０２を有するインボイス取引情報４１００が作成されたことになる。
次に、インボイス受付処理部２１１が、インボイス取引情報４１００のアウトプットデータ４１０２の空欄の項目（ヘアカット率、及び手数料）に、受付画面６２００のヘアカット率入力エリア６２０２、及び手数料入力エリア６２０３（いずれも図３５）にユーザから入力された値を記録するとともに、アウトプットデータ４１０２のハッシュ値を算出して更新する（ステップＳ１２４）。
次に、インボイス受付処理部２１１が、受付画面６２００の融資ボタン６２０４（図３５）をユーザが操作したことに応じ、インボイス取引情報４１００のハッシュ値４１０４を算出してインボイス取引情報４１００に記録し（ステップＳ１２５）、算出したハッシュ値を金融機関の秘密鍵を用いて暗号化することによって金融機関の電子署名４１０５（図２９）を作成する（ステップＳ１２６）。
次に、インボイス受付処理部２１１が、電子署名４１０５を付したインボイス取引情報４１００を依頼者の受発注者端末１０３に返信する（ステップＳ１２７）。
次に、インボイス受付処理部２１１が、電子署名４１０５を付したインボイス取引情報４１００をインボイスＤＢ２２１に保存する（ステップＳ１２８）。
次に、インボイス受付処理部２１１が、依頼者の受発注者端末１０３から送信された公証サービスの電子署名４３０１（図３２）、及び依頼者の電子署名４２０１（図３２）を受信したか否かを判断し（ステップＳ１２９）、受信していないと判断した場合（ステップＳ１２９でＮＯ）、当該判断を繰り返す。その後、インボイス受付処理部２１１が公証サービスの電子署名４３０１及び依頼者の電子署名４２０１を受信したと判断した場合（ステップＳ１２９でＹＥＳ）、処理はステップＳ１３０に進められる。ステップＳ１３０以降については後述する。
上述した金融機関端末２０によるインボイス受付処理のステップＳ１２７により、金融機関端末２０から依頼者の受発注者端末１０３に対してインボイス取引情報４１００が返信され、これが受発注者端末１０３によって受信されることになる。これにより、受発注者端末１０３では、インボイス登録処理（図２６）のステップＳ１１０以降が再開される。
図２６に戻る。次に、金融機関端末２０から返信されたインボイス取引情報４１００（図２９）を受信したと判断したインボイス登録処理部１１３３が、インボイス取引情報４１００のアウトプットデータ４１０２を表示部１４に表示し、ユーザが金融機関にて追加されたヘアカット率及び手数料を確認する（ステップＳ１１０）。
次に、インボイス登録処理部１１３３が、インボイス取引情報４１００に付された電子署名４１０５が金融機関端末２０にて作成された正規のものであることを検証するとともに、インボイス取引情報４１００の内容に改ざんがないことを確認し、保存する（ステップＳ１１１）。
なお、インボイスＤＢ１２３-へのインボイス取引情報４１００の保存は、ステップＳ１０８で保存したインボイス取引情報４０００に上書きせずに新規で保存するようにする。
また、ステップＳ１１２において、インボイス取引情報４１００に付された電子署名４１０５が正規のものではなかったり、インボイス取引情報４１００の内容に改ざんがあったりしたと判断された場合、ユーザにエラーが通知されて該インボイス登録処理は中断される。
次に、インボイス登録処理部１１３３が、受信したインボイス取引情報４１００のハッシュ値を改めて算出して依頼者（Ｃシステムズ）の秘密鍵を用いて暗号化することによって依頼者の電子署名４２０１（図３０）を作成し、受信したインボイス取引情報４１００に追加で付してインボイスＤＢ１２３３に保存する（ステップＳ１１２）。
図３０は、インボイスＤＢ１２３３に保存されたインボイス取引情報４１００の一例を示している。同図に示されるように、保存されたインボイス取引情報４１００には金融機関（Ｘバンク）の電子署名４１０５、及び依頼者（Ｃシステムズ）の電子署名４２０１が付されたものとなる。
次に、インボイス登録処理部１１３３が、インボイス取引情報４１００から、インボイス取引情報４１００の取引情報のハッシュ値４１０４（図３０）と、インプットデータ４１０１のハッシュ値とを抽出して、インボイス取引情報４１００に対する公証依頼情報５０００を作成する（ステップＳ１１３）。図３１は、インボイス取引情報４１００に対する公証依頼情報５０００の一例を示している。
次に、インボイス登録処理部１１３３が、インボイス取引情報４１００に対する公証依頼情報５０００を公証サービス端末４０に送信する（ステップＳ１１４）。公証サービス端末４０では、公証依頼情報５０００に応じ、上述した公証サービス処理（図２１）が実行され、公証サービス端末４０から受発注者端末１０３に公証サービスの電子署名４３０１（図３２）が送信される。
次に、インボイス登録処理部１１３３が、公証サービス端末４０から送信された公証サービスの電子署名４３０１を受信したか否かを判断し（ステップＳ１１５）、受信していないと判断した場合（ステップＳ１１５でＮＯ）、該判断を継続する。公証サービスの電子署名４３０１を受信したと判断した場合、次に、インボイス登録処理部１１３３が、電子署名４３０１が公証サービス端末４０にて作成された正規のものであることを検証する（ステップＳ１１６）。
なお、ステップＳ１１６において、公証サービスの電子署名４３０１が正規のものではないと判断された場合、ユーザにエラーが通知されて該インボイス登録処理は中断される。
次に、インボイス登録処理部１１３３が、インボイスＤＢ１２３３に保存されている、電子署名４１０５，４２０１が付されたインボイス取引情報４１００（図３０）に、公証サービスの電子署名４３０１を追加で付して保存する（ステップＳ１１７）。
図３２は、公証サービスの電子署名４３０１を追加で付されたインボイス取引情報４１００の一例を示している。同図に示されるように、受発注者端末１０３のインボイスＤＢ１２３３には、電子署名４１０５，４２０１，４３０１が付されたインボイス取引情報４１００が保存されたことになる。
次に、インボイス登録処理部１１３３が、公証サービスの電子署名４３０１、及び依頼者の電子署名４２０１を金融機関端末２０に送信する（ステップＳ１１８）。以上で、依頼者の受発注者端末１０３によるインボイス登録処理は終了される。
インボイス登録処理のステップＳ１１９により、公証サービスの電子署名４３０１、及び依頼者の電子署名４２０１が金融機関端末２０に送信され、金融機関端末２０で受信されることになる。これにより、金融機関端末２０ではインボイス受付処理（図２８）のステップＳ１３０以降が再開される。
図２８に戻る。次に、インボイス受付処理部２１１が、受信した電子署名４３０１が公証サービス端末４０にて作成された正規のものであることを検証する（ステップＳ１３０）。具体的には、ルート認証局３０から事前に配布されている、公証サービスの秘密鍵に対応する公開鍵により、電子署名４３０１に含まれる暗号化されているハッシュ値の復号を行い、復号できた場合には電子署名４３０１が正規のものと判断する。
次に、インボイス受付処理部２１１が、受信した電子署名４２０１が依頼者の受発注者端末１０３にて作成された正規のものであることを検証する（ステップＳ１３１）。
なお、ステップＳ１３０において、電子署名４３０１が正規のものではないと判断された場合、またはステップＳ１３１において、電子署名４２０１が正規のものではないと判断された場合、ユーザにエラーが通知されて該インボイス受付処理は中断される。
次に、インボイス受付処理部２１１が、インボイスＤＢ２２１に保存されている、電子署名４１０５が付されたインボイス取引情報４１００（図２９）に公証サービスの電子署名４３０１、及び依頼者の電子署名４２０１を追加で付して保存する（ステップＳ１３２）。これにより、金融機関端末２０のインボイスＤＢ２２１には、電子署名４１０５，４２０１，４３０１が付されたインボイス取引情報４１００が保存されたことになる。以上で、金融機関端末２０によるインボイス受付処理は終了される。
この段階で、依頼者である三次請ＳＩの受発注者端末１０３のインボイスＤＢ１２３３と、金融機関端末２０のインボイスＤＢ２２１とには、依頼者の電子署名４２０１、金融機関の電子署名４１０５、及び公証サービスの電子署名４３０１が付されたインボイス取引情報４１００が保存、共有されたことになり、依頼者と金融機関とのインボイスファイナンスの契約が成立したことになる。
＜操作画面の表示例＞
次に、図３３は、受発注者端末１０に表示される発注画面６０００の表示例を示している。
発注画面６０００には、前取引案件ＩＤ入力エリア６００１、受発注データ入力エリア６００２、及び発注ボタン６００３が設けられている。
前取引案件ＩＤ入力エリア６００１は、例えば、二次請ＳＩから三次請ＳＩに発注する場合のように、多重請負構造の上層側から受注した取引案件を下層側に発注する場合に、上層側から受注した取引案件の案件ＩＤを入力するための領域である。前取引案件ＩＤ入力エリア６００１への入力は、ユーザが案件ＩＤを入力するようにしてもよいし、契約ＤＢ１２１に記録されている受発注取引情報のアウトプットデータから案件ＩＤを抽出し、リスト化して表示し、ユーザに選択させるようにしてもよい。なお、一次請ＳＩから二次請ＳＩに発注する場合、前取引案件ＩＤ入力エリア６００１への入力は不要である。
受発注データ入力エリア６００２は、受発注データの顧客名、案件名、開始日、終了日、発注者、受注者、及び契約金額を入力するための領域である。なお、前取引案件ＩＤ入力エリア６００１に案件ＩＤが入力された場合、該案件ＩＤに対応する受発注データが契約ＤＢ１２１から検索され、そこに記載されている顧客名、案件名、開始日、及び終了日が受発注データ入力エリア６００２の同じ項目にコピーされ、そこに記載されている受注者が受発注データ入力エリア６００２の発注者の項目にコピーされる。よって、ユーザは、受発注データ入力エリア６００２の受注者、及び契約金額の項目にだけ入力すればよい。
前取引案件ＩＤ入力エリア６００１に案件ＩＤが入力されない場合、ユーザは、受発注データ入力エリア６００２のすべての項目に入力する必要がある。
発注ボタン６００３は、受発注データ入力エリア６００２に入力した内容を確定し、受注者（の候補）に対して、受発注取引情報１０００（図１２）の送信を指示するための操作ボタンである。
図３４は、受発注者端末１０に表示される受注画面６１００の表示例を示している。
受注画面６１００には、受発注データ表示エリア６１０１、受注ボタン６１０２、及び辞退ボタン６１０３が設けられている。
受発注データ表示エリア６１０１は、発注者から送信された受発注取引情報１０００のアウトプットデータ１００１に記録されている受発注データのうちの、顧客名、案件名、開始日、終了日、発注者、受注者、及び契約金額を表示するための領域である。受注ボタン６１０２は、受発注データ表示エリア６１０１に表示された内容を確定し、受注する場合に操作するボタンである。辞退ボタン６１０３は、受注を辞退する場合に操作するボタンである。
図３５は、金融機関端末２０に表示される受付画面６２００の表示例を示す図である。
受付画面６２００には、多重請負構造表示エリア６２０１、ヘアカット率入力エリア６２０２、手数料入力エリア６２０３、融資ボタン６２０４、及び辞退ボタン６２０５が設けられている。
多重請負構造表示エリア６２０１は、インボイス取引の依頼者を含む多重請負構造の構成者を表示するための領域である。多重請負構造の構成者は、依頼者からのインボイス取引情報４１００、及び、それに連なる一連の階層取引情報２３００，２０００の階層データにおける発注者と受注者とに基づいて抽出される。
ヘアカット率入力エリア６２０２、及び手数料入力エリア６２０３は、金融機関にてヘアカット率及び手数料を入力するための領域である。融資ボタン６２０４は、多重請負構造表示エリア６２０１に表示された多重請負構造を確認し、入力したヘアカット率及び手数料を確定して、貸し付けの依頼を受ける場合に操作するボタンである。辞退ボタン６２０５は、貸し付けの依頼を辞退する場合に操作するボタンである。
なお、図３３〜図３５に示した操作画面の表示例は一例に過ぎず、これらに限るものではない。
以上に説明した本実施形態の受発注・融資システム１によれば、ＩＴ業界における多重請負構造を金融機関に対して可視化することができる、これにより、金融機関からの信頼度が低い下請ＳＩであっても、発注者である上層側の大手ＳＩの信用度を活用して自身の信用度を補完でき、金融機関からインボイスファイナンスを受け得ることが期待できる。
また、金融機関に送信されるインボイス取引情報には、階層データと、インボイスファイナンスに必要な最低限の項目だけが記録されているので、受発注取引の第三者である金融機関に受発注取引に関する情報が漏洩することを抑止できる。また、各ノード間で通信する各種の取引情報には電子署名を付しているので、その内容が改ざんされてしまうことを抑止できる。
さらに、受発注・融資システム１における公証サービス端末４０の公証ＤＢ４１には、公証依頼情報のインプットデータとして記録されていた階層データのハッシュ値が保存される。これにより、今後、当該階層データを使用したインボイス取引に対して公証サービスの電子署名が発行されない。すなわち、例えば、インボイスファイナンスの依頼者が、同じ階層データを使ったインボイス取引情報を、別の金融機関に送信してインボイスファイナンスを依頼したとしても（売掛債権の二重譲渡）、その金融機関では、依頼者からのインボイス取引情報に対して、公証サービスの電子署名が得られないことを根拠として、依頼者に対してインボイスファイナンスの依頼を拒否することができる。
なお、受発注・融資システム１は、多重請負構造を有するＩＴ業界以外の各種業界、例えば、製造業、建設業、広告業等の業界における受発注取引にも適用することができる。
本発明は、上述した実施形態に限定されるものではなく、様々な変形が可能である。例えば、上述した実施形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施形態の構成の一部を他の実施形態の構成に置き換えたり、追加したりすることが可能である。
また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ等の記録装置、または、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。
１・・・受発注・融資システム、２・・・ネットワーク、１０・・・受発注者端末、１１・・・処理部、１１１・・・発注登録処理部、１１２・・・受注処理部、１１３・・・インボイス登録処理部、１２・・・記憶部、１２１・・・契約ＤＢ、１２２・・・階層ＤＢ、１２３・・・インボイスＤＢ、１３・・・入力部、１４・・・表示部、１５・・・通信部、２０・・・金融機関端末、２１・・・処理部、２１１・・・インボイス受付処理部、２２・・・記憶部、２２１・・・インボイスＤＢ、２３・・・入力部、２４・・・表示部、２５・・・通信部、３０・・・ルート認証局、４０・・・公証サービス端末、４１・・・公証ＤＢ、５００・・・取引情報、６００・・・受発注データ、７００・・・階層データ、８００・・・インボイスデータ、１０００・・・受発注取引情報、２０００，２３００・・・階層取引情報、３０００・・・公証依頼情報、４０００，４１００・・・インボイス取引情報、５０００・・・公証依頼情報、６０００・・・発注画面、６００１・・・前取引案件ＩＤ入力エリア、６００２・・・受発注データ入力エリア、６００３・・・発注ボタン、６１００・・・受注画面、６１０１・・・受発注データ表示エリア、６１０２・・・受注ボタン、６１０３・・・辞退ボタン、６２００・・・受付画面、６２０１・・・多重請負構造表示エリア、６２０２・・・ヘアカット率入力エリア、６２０３・・・手数料入力エリア、６２０４・・・融資ボタン、６２０５・・・辞退ボタン

Claims (10)

  1. 多重請負構造に属する発注者及び受注者のそれぞれが使用する複数の受発注者端末を備える受発注・融資システムであって、
    前記受発注者端末は、
    前記発注者として、前記発注者と前記受注者との間の発注内容を表す受発注データをアウトプットデータとする受発注取引情報、及び、前記発注者から前記受注者に対する発注の前記多重請負構造における階層レベルを少なくとも含む階層データをアウトプットデータとする階層取引情報を作成して前記受注者側に送信する発注登録処理部と、
    前記受注者として、前記発注者側から送信された前記受発注取引情報、及び前記階層取引情報を受信、確認して前記発注者側に返信する受注処理部と、
    を有し、
    前記発注登録処理部は、前記多重請負構造における上層の前記発注者から受注した発注を前記多重請負構造における下層の前記受注者に発注する場合、前記上層の前記発注者側から送信された前記階層取引情報における前記アウトプットデータとしての前記階層データをインプットデータとする前記階層取引情報を作成して前記下層の受注者側に送信する
    ことを特徴とする受発注・融資システム。
  2. 請求項１に記載の受発注・融資システムであって、
    前記発注登録処理部は、作成した前記階層取引情報に前記発注者の電子署名を付して前記受注者側に送信するとともに階層データベースに保存し、
    前記受注処理部は、受信した前記発注者側からの前記階層取引情報に前記受注者の電子署名を追加で付して前記発注者側に返信するともに階層データベースに保存する
    ことを特徴とする受発注・融資システム。
  3. 請求項２に記載の受発注・融資システムであって、
    前記発注登録処理部は、前記受注者側から返信された前記階層取引情報に対する公的な証明を依頼するための公証依頼情報を作成して公証サービス側に送信し、前記公証サービス側から返信された前記公証サービスの電子署名を前記受注者側に送信するとともに前記階層データベースの、前記発注者の電子署名、及び前記受注者の電子署名が付されている前記階層取引情報に追加で付して保存する
    ことを特徴とする受発注・融資システム。
  4. 請求項１〜３のいずれか一項に記載の受発注・融資システムであって、
    前記発注登録処理部は、作成した前記受発注取引情報に前記発注者の電子署名を付して前記受注者側に送信するとともに契約データベースに保存し、
    前記受注処理部は、受信した前記発注者側からの前記受発注取引情報に前記受注者の電子署名を追加で付して前記発注者側に返信するとともに契約データベースに保存する
    ことを特徴とする受発注・融資システム。
  5. 請求項４に記載の受発注・融資システムであって、
    前記発注登録処理部は、前記受注者側から返信された前記受発注取引情報に対する公証を依頼するための公証依頼情報を作成して公証サービス側に送信し、前記公証サービス側から返信された前記公証サービスの電子署名を前記受注者側に送信するとともに前記契約データベースの、前記発注者の電子署名、及び前記受注者の電署名が付されている前記階層取引情報に追加で付して保存する
    ことを特徴とする受発注・融資システム。
  6. 請求項１〜５のいずれか一項に記載の受発注・融資システムであって、
    金融機関が使用する金融機関端末を、備え、
    前記受発注者端末は、
    前記受注者兼依頼者として、前記発注者と共有する前記階層取引情報における前記アウトプットデータとしての前記階層データをインプットデータとし、前記発注者との契約金額を少なくとも含むインボイスデータをアウトプットデータとするインボイス取引情報を作成し、前記発注者と共有する前記階層取引情報に連なる一連の階層取引情報とともに前記金融機関側に送信するインボイス登録処理部、を有する
    ことを特徴とする受発注・融資システム。
  7. 請求項６に記載の受発注・融資システムであって、
    前記金融機関端末は、
    前記インボイス取引情報、及び前記一連の階層取引情報に基づいて、前記受注者兼依頼者が属する前記多重請負構造を可視化するインボイス受付処理部、を有する
    ことを特徴とする受発注・融資システム。
  8. 請求項７に記載の受発注・融資システムであって、
    前記インボイス受付処理部は、ユーザからの入力に基づき、前記インボイス取引情報の前記インボイスデータにマージン情報を記録して前記受注者兼依頼者側に返信する
    ことを特徴とする受発注・融資システム。
  9. 多重請負構造に属する発注者及び受注者のそれぞれが使用する複数の受発注者端末を備える受発注・融資システムによる受発注・融資方法であって、
    前記発注者が使用する前記受発注者端末による、
    前記発注者と前記受注者との間の発注内容を表す受発注データをアウトプットデータとする受発注取引情報を作成して前記受注者側に送信する受発注取引情報作成ステップと、
    前記発注者から前記受注者に対する発注の前記多重請負構造における階層レベルを少なくとも含む階層データをアウトプットデータとする階層取引情報を作成して前記受注者側に送信する階層取引情報作成ステップと、
    前記受注者が使用する前記受発注者端末による、
    前記発注者側から送信された前記受発注取引情報を受信、確認して前記発注者側に返信する受発注取引情報確認ステップと、
    前記発注者側から送信された前記階層取引情報を受信、確認して前記発注者側に返信する階層取引情報確認ステップと、
    を含み、
    階層取引情報作成ステップは、前記多重請負構造における上層の前記発注者から受注した発注を前記多重請負構造における下層の前記受注者に発注する場合、前記上層の前記発注者側から送信された前記階層取引情報における前記アウトプットデータとしての前記階層データをインプットデータとする前記階層取引情報を作成して前記下層の受注者側に送信する
    ことを特徴とする受発注・融資方法。
  10. 多重請負構造に属する発注者及び受注者のそれぞれが使用するコンピュータを、
    前記発注者として、前記発注者と前記受注者との間の発注内容を表す受発注データをアウトプットデータとする受発注取引情報、及び、前記発注者から前記受注者に対する発注の前記多重請負構造における階層レベルを少なくとも含む階層データをアウトプットデータとする階層取引情報を作成して前記受注者側に送信する発注登録処理部と、
    前記受注者として、前記発注者側から送信された前記受発注取引情報、及び前記階層取引情報を受信、確認して前記発注者側に返信する受注処理部と、
    して機能させ、
    前記発注登録処理部は、前記多重請負構造における上層の前記発注者から受注した発注を前記多重請負構造における下層の前記受注者に発注する場合、前記上層の前記発注者側から送信された前記階層取引情報における前記アウトプットデータとしての前記階層データをインプットデータとする前記階層取引情報を作成して前記下層の受注者側に送信する
    ことを特徴とするプログラム。
JP2020139226A 2020-08-20 2020-08-20 受発注・融資システム、受発注・融資方法、及びプログラム Active JP6841541B1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2020139226A JP6841541B1 (ja) 2020-08-20 2020-08-20 受発注・融資システム、受発注・融資方法、及びプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2020139226A JP6841541B1 (ja) 2020-08-20 2020-08-20 受発注・融資システム、受発注・融資方法、及びプログラム

Publications (2)

Publication Number Publication Date
JP6841541B1 true JP6841541B1 (ja) 2021-03-10
JP2022035125A JP2022035125A (ja) 2022-03-04

Family

ID=74845284

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2020139226A Active JP6841541B1 (ja) 2020-08-20 2020-08-20 受発注・融資システム、受発注・融資方法、及びプログラム

Country Status (1)

Country Link
JP (1) JP6841541B1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7058894B1 (ja) 2021-06-29 2022-04-25 有限会社ホリケン 受発注管理サーバと受発注管理プログラムと受発注管理方法

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003218864A (ja) * 2002-01-22 2003-07-31 Hitachi Ltd 本人認証方法およびシステム
JP2003242345A (ja) * 2002-02-20 2003-08-29 Ntt Data Corp 融資支援システム及びコンピュータプログラム
JP2008117258A (ja) * 2006-11-07 2008-05-22 Dainippon Printing Co Ltd 電子封筒を用いたワークフローシステムおよび方法
JP2011008309A (ja) * 2009-06-23 2011-01-13 Hitachi Ltd 電子商取引におけるサプライヤ評価方法及びそのシステム

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7058894B1 (ja) 2021-06-29 2022-04-25 有限会社ホリケン 受発注管理サーバと受発注管理プログラムと受発注管理方法
JP2023005866A (ja) * 2021-06-29 2023-01-18 有限会社ホリケン 受発注管理サーバと受発注管理プログラムと受発注管理方法

Also Published As

Publication number Publication date
JP2022035125A (ja) 2022-03-04

Similar Documents

Publication Publication Date Title
CN110620810B (zh) 在区块链上的连续资产转移的非链接所有权
US10574453B2 (en) System and computer program product for certified confidential data collaboration using blockchains
US11909881B2 (en) Digital asset management
CN110599276B (zh) 票据报销方法、装置和设备及计算机存储介质
CN112565055B (zh) 促进对第三方发送的电子邮件进行认证的系统和方法
CN114445010B (zh) 一种基于区块链的多式联运系统和方法
AU2016414611A1 (en) Digital asset distribution by transaction device
WO2020026676A1 (ja) 流通管理装置、流通管理システム、及び流通管理方法
TWI629658B (zh) 基於區塊鏈智能合約的kyc資料共享系統及其方法
CN108537047B (zh) 基于区块链生成信息的方法及装置
CN110728494A (zh) 不动产业务的办理方法、不动产权信息系统及装置
EP1647932A1 (en) Method and system to automatically evaluate a participant in a trust management infrastructure
US6839677B2 (en) Transactional data transfer in a network system
US20190386968A1 (en) Method to securely broker trusted distributed task contracts
JP2019133630A (ja) 制御方法、コントローラ、データ構造及び電力取引システム
WO2002073364A2 (en) System and method for providing secure transactions
JP6841541B1 (ja) 受発注・融資システム、受発注・融資方法、及びプログラム
Hardjono et al. Wallet attestations for virtual asset service providers and crypto-assets insurance
CN110599176B (zh) 基于区块链的数据处理方法、装置、存储介质及节点设备
JP2007304637A (ja) 公開予約処理サーバ
WO2021117515A1 (ja) 電子資産管理方法、及び電子資産管理装置
US11522862B2 (en) Systems and methods for a trusted entity to facilitate authentication of emails sent by 3rd parties
US20060080256A1 (en) Method and system for establishing a trustworthy supplier
KR102639198B1 (ko) 가상 자산 거래 및 투자 전략 추천 서비스를 제공하는 방법 및 시스템
Kamaludin et al. SERVICE ON THE GO (SERVEGO): Online Service Booking Application

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20200901

A871 Explanation of circumstances concerning accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A871

Effective date: 20200901

A975 Report on accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A971005

Effective date: 20200909

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20210114

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

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20210126

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20210210

R150 Certificate of patent or registration of utility model

Ref document number: 6841541

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150