以下、本発明に係る一実施形態を図面に基づいて説明する。なお、一実施形態を説明するための全図において、同一の部材には原則として同一の符号を付し、その繰り返しの説明は省略する。また、以下の実施形態において、その構成要素(要素ステップ等も含む)は、特に明示した場合および原理的に明らかに必須であると考えられる場合等を除き、必ずしも必須のものではないことは言うまでもない。また、「Aからなる」、「Aよりなる」、「Aを有する」、「Aを含む」と言うときは、特にその要素のみである旨明示した場合等を除き、それ以外の要素を排除するものでないことは言うまでもない。同様に、以下の実施形態において、構成要素等の形状、位置関係等に言及するときは、特に明示した場合および原理的に明らかにそうでないと考えられる場合等を除き、実質的にその形状等に近似または類似するもの等を含むものとする。
<本発明の一実施形態に係る受発注・融資システム1>
図1は、本発明の一実施形態に係る受発注・融資システム1の構成例を示している。
該受発注・融資システム1は、例えば、IT業界における多重請負構造を可視化することにより、多重請負構造の下請SIが金融機関からインボイスファイナンス(売掛金担保融資)を受け得るようにするものである。
多重請負構造としては、顧客であるX商事からX商事システム更改を契約金額1千2百万円で受注した一次請SIのAシステムズが、二次請SIのBシステムズに契約金額1千万円で発注し、Bシステムズが、三次請SIであるCシステムズに契約金額8百万円で発注し、Cシステムズが金融機関であるXバンクに対して運転資金8百万円のインボイスファイナンス(売掛金担保融資)を依頼するシナリオを想定する。
受発注・融資システム1は、ネットワーク2を介して接続された、受発注者端末101〜103、金融機関端末20、ルート認証局30、及び公証サービス端末40を備える。
ネットワーク2は、インターネット、携帯電話通信網等に代表される双方向通信網である。以下、受発注者端末101〜103、金融機関端末20、ルート認証局30、及び公証サービス端末40それぞれをノードとも称する。
受発注者端末101は、多重請負構造を構成する一次請SI(Aシステムズ)によって使用される。同様に、受発注者端末102,103は、多重請負構造を構成する二次請SI(Bシステムズ)、三次請SI(Cシステムズ)によって使用される。以下、受発注者端末101〜103を個々に区別する必要がない場合、受発注者端末10と称する。
一次請SIは、顧客から業務委託契約(例えば、準委任契約)を受注する。一次請SIは、一般的には大手SIが担う。二次請SIは、一次請SIから業務委託契約(例えば、準委任契約)を受注する。二次請SIは、一般的には一次請SIよりも会社規模が小さい。三次請SIは、二次請SIから業務委託契約(例えば、準委任契約)を受注する。三次請SIは、一般的には二次請SIよりも会社規模が小さい。
なお、同図においては、多重請負構造が一次請SI、二次請SI、及び三次請SIから構成されるものと想定しているが、二次請SI及び三次請SIは複数存在してもよい。また、四次請SI、五次請SI等が存在してもよい。その場合、四次請SI、五次請SI等も受発注者端末10を使用するものとする。
金融機関端末20は、金融機関によって使用される。金融機関は、三次請SI等に対してインボイスファイナンス(売掛金担保融資)を提供する。当然ながら、金融機関は、一次請SIや二次請SI等にもインボイスファイナンス等の融資を提供できるが、以下においては、三次請SIが金融機関に対してインボイスファイナイスを依頼する場合を想定して説明する。なお、金融機関とは、銀行、信用金庫に限らず、融資サービスを提供している各種の事業法人を含む。金融機関端末20は、複数存在してもよい。
ルート認証局30は、ルート証明書を保持する認証局であり、各ノードに付与する電子証明書を発行し、PKI(Public Key Infrastructure)基盤を提供する。これにより、各ノードは、情報を暗号化する際に用いるそれぞれ専用の秘密鍵と、自己以外のノードによって暗号化されている情報を復号する際に用いる公開鍵を保持することができる。
公証サービス端末40は、ルート認証局30によってPKI基盤が提供されている受発注・融資システム1の各ノード間で通信するデータの二重使用判定機能、及び、電子署名機能を有する。具体的には、公証サービス端末40は、受信したデータのハッシュ値を公証DB(データベース)41に保存し、それ以降に受信したデータのハッシュ値を公証DB41から検索し、一致するハッシュ値が検索できた場合には、データが二重使用されていると判定としてエラーを返信し、一致するハッシュ値が検索できなかった場合には、データが二重使用されていないと判定し、データに電子署名を付して返信する。
次に、図2は、受発注者端末10の構成例を示している。受発注者端末10は、処理部11、記憶部12、入力部13、表示部14、及び通信部15を備える。
受発注者端末10は、CPU(Central Processing Unit)等のプロセッサ、DRAM(Dynamic Random Access Memory)等のメモリ、HDD(Hard Disk Drive)やSSD(Solid State Drive)等のストレージ、キーボード、マウス、タッチパネル等の入力デバイス、ディスプレイ等の出力デバイス、及び、NIC(Network Interface Card)等の通信モジュールを備えるパーソナルコンピュータ等の一般的なコンピュータから成る。
処理部11は、コンピュータのプロセッサにより実現される。処理部11は、発注登録処理部111、受注処理部112、及びインボイス登録処理部113の機能ブロックを有する。これらの機能ブロックは、コンピュータのプロセッサがメモリにロードされた所定のプログラムを実行することによって実現される。さらに、図示は省略するが、コンピュータのプロセッサが所定のプログラムを実行することにより、ノード間で情報を送受信するためのメッセージキューが実現される。ただし、これらの機能ブロックの一部または全部を集積回路等によりハードウェアとして実現してもよい。
発注登録処理部111は、発注者から受注者に業務委託契約を発注する処理を実行する。受注処理部112は、発注者から発注された業務委託契約を受注する処理を実行する。インボイス登録処理部113は、金融機関に対してインボイスファイナンスを依頼する処理を実行する。
記憶部12は、コンピュータのメモリ及びストレージによって実現される。記憶部12には、契約DB121、階層DB122、及びインボイスDB123が設けられる。契約DB121には、ノード間で通信された受発注取引情報が格納される。階層DB122には、ノード間で通信された階層取引情報が格納される。インボイスDB123には、ノード間で通信されたインボイス取引情報が格納される。なお、記憶部12には、上述した情報以外の情報を格納してもよい。
入力部13は、コンピュータの入力デバイスによって実現される。入力部13は、ユーザからの各種の操作を受け付ける。表示部14は、コンピュータのディスプレイによって実現される。表示部14は、例えば、ユーザが各種の情報を入力するための入力画面(不図示)等を表示する。通信部15は、コンピュータの通信モジュールによって実現される。通信部15は、ネットワーク2を介し、他の受発注者端末10、金融機関端末20、ルート認証局30、公証サービス端末40と接続して各種のデータや情報を通信する。
なお、以下においては必要に応じ、一次請SIの受発注者端末101における処理部11や発注登録処理部111等を処理部111,発注登録処理部1111等と称する。二次請SIの受発注者端末102、三次請SIの受発注者端末103における各構成要素や各機能ブロックについても同様とする。
次に、図3は、金融機関端末20の構成例を示している。金融機関端末20は、処理部21、記憶部22、入力部23、表示部24、及び通信部25を備える。
金融機関端末20は、受発注者端末10と同様、一般的なコンピュータから成る。
処理部21は、コンピュータのプロセッサにより実現される。処理部21は、機能ブロックとしてのインボイス受付処理部211を有する。機能ブロックは、コンピュータのプロセッサがメモリにロードされた所定のプログラムを実行することによって実現される。さらに、図示は省略するが、コンピュータのプロセッサが所定のプログラムを実行することにより、ノード間で情報を送受信するためのメッセージキューが実現される。ただし、これらの機能ブロックの一部または全部を集積回路等によりハードウェアとして実現してもよい。
インボイス受付処理部211は、依頼者(三次請SI等)からの依頼に応じ、インボイスファイナンスを提供するための処理を実行する。
記憶部22は、コンピュータのメモリ及びストレージによって実現される。記憶部22には、インボイスDB221が設けられる。インボイスDB221には、依頼者(三次請SI等)との間で通信されたインボイス取引情報が格納される。なお、記憶部22には、上述した情報以外の情報を格納してもよい。
入力部23は、コンピュータの入力デバイスによって実現される。入力部23は、ユーザからの各種の操作を受け付ける。表示部24は、コンピュータの出力デバイスによって実現される。表示部24は、例えば、三次請SIの受発注者端末103から送信される、多重請負構造を可視化した階層取引情報を表す画面(不図示)等を表示する。通信部25は、コンピュータの通信モジュールによって実現される。通信部25は、ネットワーク2を介し、受発注者端末10、ルート認証局30、公証サービス端末40と接続して各種のデータや情報を通信する。
<ノード間で通信される取引情報500のデータ構造>
次に、図4は、ノード間で通信される取引情報500のデータ構造の一例を示している。取引情報500は、後述する受発注取引情報、階層取引情報、及びインボイス取引情報の上位概念である。図5は、取引情報500と、該取引情報500に繋がる1つ前の取引情報5000との関係を説明するための図である。
取引情報500には、UTXO(Unspent Transaction Output Model)が採用されている。UTXOは、ある取引情報に含まれるアウトプットデータが、該取引情報に繋がる次の取引情報に含まれるインプットデータとなるモデルである。ある取引情報で一度インプットデータとして使用されたデータのハッシュ値は公証サービス端末40の公証DB41に保存され、二重使用判定機能に用いられる。また、ノード間で合意された各取引情報に対して、公証サービスが電子署名を付すことによって、取引情報のファイナリティ(合意された取引情報に対する公的な証明)が与えられ、これにより、取引間の紐づけが不可逆的となる。
取引情報500は、前取引ハッシュ値501、取引情報ハッシュ値502、インプットデータ503、及びアウトプットデータ505を含むことができる。
前取引ハッシュ値501には、該取引情報500に繋がる1つ前の取引情報5000のハッシュ値5020がコピーされる。1つ前の取引情報5000が存在しない場合、前取引ハッシュ値501は記録されない。
取引情報ハッシュ値502には、前取引ハッシュ値501、インプットデータ503のハッシュ値504、及びアウトプットデータ505のハッシュ値506を入力として算出された、該取引情報500のハッシュ値が記録される。
なお、取引情報500のハッシュ値を算出する際の入力に、インプットデータ503のハッシュ値504及びアウトプットデータ505のハッシュ値506、に加えて又は替えて、インプットデータ503及びアウトプットデータ505の少なくとも一方を採用してもよい。また、後述する電子署名は、取引情報500のハッシュ値を算出する際の入力には用いない。
インプットデータ503には、該取引情報500に繋がる1つ前の取引情報5000のアウトプットデータ5050がコピーされる。インプットデータ503には、複数の項目のデータと、該複数の項目のデータのハッシュ値504とが含まれる。ただし、1つ前の取引情報5000が存在しない場合、インプットデータ503は記録されない。
アウトプットデータ505には、取引相手のノードに伝えるべき複数の項目のデータと、該複数の項目データのハッシュ値506とが含まれる。
<受発注データの一例>
次に、図6は、取引情報500としての受発注取引情報のアウトプットデータとなる受発注データ600のデータ構造の一例である。同図は、一次請SIであるAシステムズと二次請SIであるBシステムズとの受発注案件に対応する受発注データ600の例を示している。
受発注データ600は、案件ID601、顧客名602、案件名603、開始日604、終了日605、発注者606、受注者607、及び契約金額608の各項目のデータ、並びにハッシュ値609を含む。
案件ID601には、一次請SIであるAシステムズと二次請SIであるBシステムズとの間の受発注案件を一意に特定できる識別子(同図の場合、ABC100)が記録される。顧客名602には、一次請SIが受注した顧客名(同図の場合、X商事)が記録される。案件名603には、一次請SIが受注した案件名(同図の場合、X商事システム更改)が記録される。
開始日604には、プロジェクト期間の開始日(同図の場合、2020/4/1)が記録される。終了日605には、プロジェクト期間の終了日(同図の場合、2020/6/30)が記録される。発注者606には、案件IDが表す受発注案件の発注者(同図の場合、Aシステムズ)が記録される。受注者607には、案件IDが表す受発注案件の受注者(同図の場合、Bシステムズ)が記録される。契約金額608には、案件IDが表す受発注案件の契約金額(同図の場合、1千万円)が記録される。ハッシュ値609には、当該受発注データ600のハッシュ値(同図の場合、ABC100HASH)が記録される。
<階層データの一例>
次に、図7は、取引情報500としての階層取引情報のアウトプットデータ及びインプットデータとなる階層データ700のデータ構造の一例である。同図の場合、一次請SIであるAシステムズと二次請SIであるBシステムズとの受発注案件に対応する階層データ700の例を示している。
階層データ700は、階層ID701、案件ID702、階層レベル703、発注者704、及び受注者705の各項目のデータ、並びハッシュ値706を含む。
階層ID701には、一次請SIであるAシステムズと二次請SIであるBシステムズとの間の受発注案件に対応する階層データであることを一意に特定できる識別子(同図の場合、ABC100KAISO)が記録される。案件ID702には、一次請SIであるAシステムズと二次請SIであるBシステムズとの間の受発注案件を一意に特定できる識別子(同図の場合、ABC100)が記録される。
階層レベル703には、一次請SIであるAシステムズと二次請SIであるBシステムズとの間の受発注が多重請負構造の何層目であるかを表す値(同図の場合、1)が記録される。発注者704には、案件IDが表す受発注案件の発注者(同図の場合、Aシステムズ)が記録される。受注者705には、案件IDが表す受発注案件の受注者(同図の場合、Bシステムズ)が記録される。ハッシュ値706には、当該階層データ700のハッシュ値(同図の場合、ABC100KDHASH)が記録される。
<インボイスデータの一例>
次に、図8は、取引情報500としてのインボイス取引情報のアウトプットデータとなるインボイスデータ800のデータ構造の一例である。同図の場合、三次請SIであるCシステムズが金融機関に対してファイナンスを依頼する際のインボイスデータ800の例を示している。
インボイスデータ800は、インボイスID801、案件ID802、発注者803、受注者804、契約金額805、ヘアカット率806、及び手数料807の各項目のデータ、並びハッシュ値808を含む。
インボイスID801には、二次請SIであるBシステムズと三次請SIであるCシステムズとの間の受発注案件に対応するインボイスデータであることを一意に特定できる識別子(同図の場合、ABC110INV)が記録される。案件ID802には、二次請SIであるBシステムズと三次請SIであるCシステムズとの間の受発注案件を一意に特定できる識別子(同図の場合、ABC110)が記録される。
発注者803には、案件IDが表す受発注案件の発注者(同図の場合、Bシステムズ)が記録される。受注者804には、案件IDが表す受発注案件の受注者(同図の場合、Cシステムズ)が記録される。ヘアカット率806及び手数料807には、金融機関が入力するマージン情報であり、BシステムズとCシステムズとの間の契約金額に対する貸付金額の割合(ヘアカット率)と手数料が記録される。ハッシュ値808には、当該インボイスデータ800のハッシュ値(同図の場合、ABC110ID2HASH)が記録される。
<受発注・融資システム1による処理の流れ>
次に、図9は、受発注・融資システム1による処理の流れを説明するフローチャートである。
一次請SI(Aシステムズ)が顧客(X商事)からシステム更改を受注すると、初めに、一次請SIの受発注者端末101が、顧客から受注した案件内容の情報を二次請SIの候補であるBシステムズの受発注者端末102に対して発注登録処理を行う(ステップS1)。なお、複数の二次請SIの候補に対して発注登録処理を行ってもよい。
次に、二次請SIの受発注者端末102が、受発注者端末101からの発注登録処理に応じて受注処理を行う(ステップS2)。具体的には、受発注者端末102が、発注の内容を確認して受注する旨を発注元の受発注者端末101に送信する。これにより、一次請SIと二次請SIとの契約が完了する。
次に、二次請SIの受発注者端末102が、ステップS1と同様、三次請SIの候補であるCシステムズの受発注者端末103に対して発注登録処理を行う(ステップS3)。次に、受発注者端末103が、受発注者端末102からの発注登録処理に応じて受注処理を行う(ステップS4)。具体的には、三次請SIでは、発注の内容に基づき、社内の人材のうち、受注案件に対してスキルや経験が適合し、且つ、プロジェクト期間に配属可能な人材を割り当てることが可能か否かを確認し、人材を割り当てることができる場合、受発注者端末103が、受注する旨を発注元の受発注者端末102に送信する。これにより、二次請SIと三次請SIとの契約が完了する。
次に、三次請SIの受発注者端末103が、金融機関の金融機関端末20に対してインボイスファイナンスを依頼するためのインボイス登録処理を行う(ステップS5)。該インボイス登録処理に際しては、多重請負構造を可視化可能な階層取引情報(詳細後述)が受発注者端末103から金融機関端末20に送信される。なお、複数の金融機関に対してインボイス登録処理を行い、相見積もりを取るようにしてもよい。
次に、金融機関端末20が、受発注者端末103からのインボイス登録処理に応じてインボイス受付処理を行う(ステップS6)。具体的には、金融機関は、多重請負構造におけるCシステムズの階層と、その上層側(いまの場合、Bシステムズ及びAシステムズ)とを確認する。そして、金融機関は、発注の元がAシステムズであることを考慮してCシステムズに対する与信を実施し、マージン情報(ヘアカット率、及び手数料)を決定して依頼元の受発注者端末103に送信する。受発注者端末103では、マージン情報を確認し、問題なければ金融機関との契約を確定する。この後、金融機関からCシステムズに対する融資が実行されることになる。以上で、受発注・融資システム1による処理の流れの説明を終了する。以下、上述した各処理の詳細について説明する。
<一次請SI(Aシステムズ)による発注登録処理(図9のステップS1)について>
次に、図10は、一次請SIから二次請SIに対する発注登録処理の一例を説明するフローチャートである。
該発注登録処理は、顧客(X商事)からの仕事(システム更改)を受注した一次請SIの受発注者端末101に対するユーザからの所定の操作に応じて開始される。
同図に示されるように、発注登録処理は、受発注取引情報作成処理(ステップS11)、及び階層取引情報作成処理(ステップS12)から成る。ただし、受発注取引情報作成処理(ステップS11)、及び階層取引情報作成処理(ステップS12)は、実際には、同時に並行して実行される。
図11は、受発注取引情報作成処理(ステップS11)の一例を説明するフローチャートである。図12は、受発注取引情報作成処理にて一次請SIの受発注者端末101から二次請SIの受発注者端末102に送信される受発注取引情報1000の一例を示している。
始めに、受発注者端末101の発注登録処理部1111が、発注画面6000(図33)に対するユーザからの入力に基づき、二次請SIの受発注者端末102に送信するための受発注取引情報1000のアウトプットデータ1001に受発注データを記録する(ステップS21)。
具体的には、例えば、一次請SIから二次請SIへの発注では、ユーザが受発注データの全ての項目を入力する必要がある。ただし、案件IDは、ユーザが入力してもよいし、発注登録処理部1111が他の受発注データと重複しない文字列を生成するようにしてもよい。また例えば、二次請SIから三次請SIへの発注では、ユーザが発注画面6000の前取引案件ID入力エリア6001(図33)に入力した、上層側から受注した取引案件の案件IDに基づき、該案件IDに対応する受発注データが契約DB121から読み出されて、その顧客名、案件名、開始日、終了日、及び受注者(次の発注者として)が流用される。この場合、ユーザは、受注者、及び契約金額の項目にだけ入力すればよい。
次に、発注登録処理部1111が、ステップS21で記録した受発注データのハッシュ値1002を算出し、受発注取引情報1000に記録する(ステップS22)。
なお、受発注取引情報1000については、多重請負構造に関係なく、2社(いまの場合、AシステムズとBシステムズ)間の受発注に対応するものであるため、それに繋がる1つ前の受発注取引情報は存在しない。よって、受発注取引情報1000には、インプットデータ、及び前取引ハッシュ値が記録されない。
次に、発注登録処理部1111が、受発注取引情報1000のハッシュ値1003を算出して、受発注取引情報1000に記録する(ステップS23)。
次に、発注登録処理部1111が、発注者(Aシステムズ)の秘密鍵を用い、ステップS22で算出した受発注取引情報1000のハッシュ値1003を暗号化することによって発注者の電子署名1004を作成する(ステップS24)。
次に、発注登録処理部1111が、受発注取引情報1000に電子署名1004を付して受注者(Bシステムズ)の受発注者端末102に送信する(ステップS25)。
次に、発注登録処理部1111が、電子署名1004を付した受発注取引情報1000を契約DB1211に保存する(ステップS26)。
次に、発注登録処理部1111が、受発注者端末102から返信された受発注取引情報1000(図17)を受信したか否かを判断し(ステップS27)、受信していないと判断した場合(ステップS27でNO)、当該判断を繰り返す。その後、発注登録処理部1111が、返信された受発注取引情報1000を受信したと判断した場合(ステップS27でYES)、処理はステップS28に進められる。ステップS28以降については後述する。
次に、図13は、階層取引情報作成処理(ステップS12)の一例を説明するフローチャートである。図14は、階層取引情報作成処理にて一次請SIの受発注者端末101から二次請SIの受発注者端末102に送信される階層取引情報2000の一例を示している。
始めに、受発注者端末101の発注登録処理部1111が、二次請SIの受発注者端末102に送信するための階層取引情報2000(図14)に繋がる1つ前の取引情報が存在するか否かを判定する(ステップS41)。具体的には、ユーザが発注画面6000の前取引案件ID入力エリア6001(図33)に案件IDを入力した場合、階層取引情報2000に繋がる1つ前の取引情報が存在すると判定する。
ここで、階層取引情報2000に繋がる1つ前の階層取引情報が存在すると判定された場合(ステップS41でYES)、発注登録処理部1111が、階層取引情報2000の前取引ハッシュ値2001に、1つ前の階層取引情報のハッシュ値をコピーするとともに、階層取引情報2000のインプットデータ2002に、1つ前の階層取引情報のアウトプットデータ(アウトプットデータのハッシュ値を含む)をコピーする(ステップS42)。
反対に、階層取引情報2000に繋がる1つ前の階層取引情報が存在しないと判定された場合(ステップS41でNO)、ステップS42はスキップされる。いまの場合、階層取引情報2000は、一次請SIから二次請SIへの発注案件に対応するものであり、それに繋がる1つ前の階層取引情報は存在しないので、ステップS42はスキップされ、階層取引情報2000における前取引ハッシュ値2001、及びインプットデータ2002は記録されない。
次に、発注登録処理部1111が、契約DB1211の受発注取引情報1000を参照して、階層取引情報2000のアウトプットデータ2003に、階層データの階層レベル1104以外の項目、すなわち、階層ID、案件ID、発注者、及び受注者を記録する(ステップS43)。
次に、発注登録処理部1111が、階層取引情報2000のアウトプットデータ2003に記録した階層データの階層レベル2004に、ステップS42でインプットデータ(1つ前の階層取引情報のアウトプットデータ)2002に記録した階層データの階層レベルに1だけ加算した値を記録する(ステップS44)。いまの場合、ステップS42はスキップされており、インプットデータ2002は記録されていないので、階層レベル2004に1を記録する。
次に、発注登録処理部1111が、アウトプットデータ2003に記録した階層データのハッシュ値2005を算出して階層取引情報2000に記録する(ステップS45)。
次に、発注登録処理部1111が、階層取引情報2000のハッシュ値2006を算出して、階層取引情報2000に記録する(ステップS46)。
次に、発注登録処理部1111が、発注者(Aシステムズ)の秘密鍵を用いて階層取引情報2000のハッシュ値2006を暗号化することによって発注者の電子署名2007を作成する(ステップS47)。
次に、発注登録処理部1111が、電子署名2007を付した階層取引情報2000を受注者(Bシステムズ)の受発注者端末102に送信する(ステップS48)。なお、前の取引案件が存在する場合、階層取引情報2000に連なる一連の階層取引情報(電子署名付)を階層DB1221から読み出して受注者の受発注者端末10に送信するようにする。
次に、発注登録処理部1111が、電子署名2007を付した階層取引情報2000を階層DB1221に保存する(ステップS49)。
次に、発注登録処理部1111が、受発注者端末102から返信された階層取引情報2000(図19)を受信したか否かを判断し(ステップS50)、受信していないと判断した場合(ステップS50でNO)、当該判断を繰り返す。その後、発注登録処理部1111が、返信された階層取引情報2000を受信したと判断した場合(ステップS50でYES)、処理はステップS51に進められる。ステップS51以降については後述する。
<二次請SI(Bシステムズ)による受注処理(図9のステップS2)について>
次に、図15は、二次請SIによる受注処理の一例を説明するフローチャートである。
該受注処理は、二次請SIの受発注者端末102に対するユーザからの所定の操作に応じて開始される。
同図に示されるように、該受注処理は、受発注取引情報確認処理(ステップS61)、及び階層取引情報確認処理(ステップS62)から成る。ただし、受発注取引情報確認処理(ステップS61)、及び階層取引情報確認処理(ステップS62)は、実際には、同時に並行して実行される。
図16は、受発注取引情報確認処理(ステップS61)の一例を説明するフローチャートである。図17は、受発注取引情報確認処理にて二次請SIの受発注者端末102から一次請SIの受発注者端末101に返信される受発注取引情報1000の一例を示している。
始めに、受発注者端末102の受注処理部1122が、一次請SIの受発注者端末101から送信された受発注取引情報1000(図12)を受信したか否かを判断する(ステップS71)。ここで、受発注取引情報1000を受信していないと判断した場合(ステップS71でNO)、当該判断を繰り返す。
その後、受発注取引情報1000を受信したと判断した場合(ステップS71でYES)、受注処理部1122が、受発注取引情報1000に付された電子署名1004が一次請SIの受発注者端末101にて作成された正規のものであることを検証するとともに、受発注取引情報1000の内容に改ざんがないことを確認して受注画面6100(図34)を表示する(ステップS72)。
具体的には、ルート認証局30から事前に配布されている、一次請SIの秘密鍵に対応する公開鍵により、電子署名1004に含まれる暗号化されているハッシュ値の復号を行い、復号できた場合には電子署名1004が正規のものと判断する。また、受信した受発注取引情報1000のハッシュ値を改めて算出し、算出したハッシュ値と、復号されたハッシュ値とが一致した場合には受発注取引情報1000の内容に改ざんが無いと判断する。
なお、ステップS72において、受発注取引情報1000に付された電子署名1004が正規のものではなかったり、受発注取引情報1000の内容に改ざんがあったりしたと判断された場合、またはユーザが受注画面6100の辞退ボタン6103(図34)を操作した場合、該受発注取引情報確認処理は中断される。
次に、受注処理部1122が、ユーザが受注画面6100の受注ボタン6102(図34)を操作したことに応じ、受信した受発注取引情報1000のハッシュ値を改めて算出し(ステップS73)、算出したハッシュ値を受注者(Bシステムズ)の秘密鍵を用いて暗号化することによって受注者の電子署名1101(図17)を作成する(ステップS74)。
次に、受注処理部1122が、電子署名1101を追加して付した受発注取引情報1000を発注者(Aシステムズ)の受発注者端末101に返信する(ステップS75)。
次に、受注処理部1122が、電子署名1004,1101が付された受発注取引情報1000を取引DB1212に保存する(ステップS76)。
次に、受注処理部1122が、受発注者端末101から送信された公証サービスの電子署名1201(図22)を受信したか否かを判断し(ステップS77)、受信していないと判断した場合(ステップS77でNO)、当該判断を繰り返す。その後、受注処理部1122が公証サービスの電子署名1201を受信したと判断した場合(ステップS77でYES)、処理はステップS78に進められる。ステップS78以降については後述する。
次に、図18は、階層取引情報確認処理(ステップS62)の一例を説明するフローチャートである。図19は、階層取引情報確認処理にて二次請SIの受発注者端末102から一次請SIの受発注者端末101に返信される階層取引情報2000の一例を示している。
始めに、受発注者端末102の受注処理部1122が、一次請SIの受発注者端末101から送信された階層取引情報2000(図14)を受信したか否かを判断する(ステップS81)。ここで、階層取引情報2000を受信していないと判断した場合(ステップS81でNO)、当該判断を繰り返す。
その後、階層取引情報2000を受信したと判断した場合(ステップS81でYES)、受注処理部1122が、階層取引情報2000に付された電子署名2007が一次請SIの受発注者端末101にて作成された正規のものであることを検証するとともに、階層取引情報2000の内容に改ざんがないことを確認する(ステップS82)。
なお、電子署名2007が正規のものであることの検証方法、及び、階層取引情報2000の内容に改ざんがないことの確認方法については、上述した電子署名1004、及び受発注取引情報1000の場合と同様なのでその説明は、適宜、省略する。以降においても同様とする。
さらに、階層取引情報2000とともに、それに連なる一連の階層取引情報(電子署名付)を受信した場合、受注処理部1122が、それらについても、電子署名を検証し、内容に改ざんがないことを確認する。
なお、ステップS82において、電子署名2007等が正規のものではなかったり、階層取引情報2000等の内容に改ざんがあったりしたと判断された場合、ユーザにエラーが通知されて該階層取引情報確認処理は中断される。
次に、受注処理部1122が、受信した階層取引情報2000のハッシュ値を改めて算出し(ステップS83)、算出したハッシュ値を受注者(Bシステムズ)の秘密鍵を用いて暗号化受注者の電子署名2101(図19)を作成する(ステップS84)。
次に、受注処理部1122が、電子署名2101を追加して付した階層取引情報2000を発注者(Aシステムズ)の受発注者端末101に返信する(ステップS85)。
次に、受注処理部1122が、電子署名2007,2101が付された階層取引情報2000を階層DB1222に保存する(ステップS86)。なお、階層取引情報2000とともに、それに連なる一連の階層取引情報を受信していた場合には、それらも階層DB1222に保存する。
次に、受注処理部1122が、受発注者端末101から送信される公証サービスの電子署名2201(図23)を受信したか否かを判断し(ステップS87)、受信していないと判断した場合(ステップS87でNO)、当該判断を繰り返す。その後、受注処理部1122が電子署名2201を受信したと判断した場合(ステップS87でYES)、処理はステップS88に進められる。ステップS88以降については後述する。
上述した二次請SIの受発注者端末102による受発注取引情報確認処理のステップS75、及び、階層取引情報確認処理のステップS85により、受発注者端末102から受発注者端末101に対して受発注取引情報1000及び階層取引情報2000が返信され、これらが受発注者端末101によって受信されることになる。これにより、受発注者端末101では、受発注取引情報作成処理(図11)のステップS28以降、及び、階層取引情報作成処理(図13)のステップS51以降が再開される。
まず、受発注取引情報作成処理(図11)のステップS28以降について説明する。図11に戻る。次に、受発注者端末102から返信された受発注取引情報1000(図17)を受信したと判断した発注登録処理部1111が、受発注取引情報1000に付された電子署名1101が二次請SIの受発注者端末102にて作成された正規のものであることを検証するとともに、受発注取引情報1000の内容に改ざんがないことを確認してから、受信した受発注取引情報1000を契約DB1211に保存する(ステップS28)。
なお、契約DB1211への受発注取引情報1000の保存は、ステップS26で保存した受発注取引情報1000に上書きせずに新規で保存するようにする。
また、ステップS28において、受発注取引情報1000に付された電子署名1101が正規のものではなかったり、受発注取引情報1000の内容に改ざんがあったりしたと判断された場合、ユーザにエラーが通知されて該受発注取引情報作成処理は中断される。
次に、発注登録処理部1111が、受信した受発注取引情報1000から、受発注取引情報1000のハッシュ値1003と、インプットデータのハッシュ値とを抽出して、受発注取引情報1000に対する公証依頼情報を作成する(ステップS29)。
図20は、受発注取引情報1000に対する公証依頼情報3000の一例を示している。いまの場合、受発注取引情報1000にはインプットデータが記録されていないので、受発注取引情報1000から取引情報のハッシュ値1003だけが抽出されて、公証依頼情報3000が作成される。同図に示されるように、公証依頼情報3000には、受発注取引情報1000に記録されていたインプットデータ及びアウトプットデータの各項目の情報(ハッシュ値を除く)は記録されないので、受注取引の内容が受発注取引の当事者以外の第三者(いまの場合、公証サービス端末40のユーザ等)に漏洩することを抑止できる。
図11に戻る。次に、発注登録処理部1111が、受発注取引情報1000に対する公証依頼情報3000を公証サービス端末40に送信する(ステップS30)。
ここで、公証依頼情報3000等の公証依頼情報に応じて公証サービス端末40が実行する公証サービス処理について説明する。
図21は、公証サービス処理の一例を説明するフローチャートである。該公証サービス処理は、公証サービス端末40が公証依頼情報を受信したことに応じて開始される。
始めに、公証サービス端末40が、公証依頼情報に含まれるインプットデータのハッシュ値が公証DB41に登録済みであるか否かを判定する(ステップS91)。ここで、該ハッシュ値が、公証DB41に登録済みであると判定した場合(ステップS91でYES)、公証依頼情報に含まれるインプットデータが二重使用されていることになるので、依頼者にエラーを通知し(ステップS92)、公証サービス処理を終了する。
反対に、該ハッシュ値が、公証DB41に登録済みではないと判定した場合(ステップS91でNO)、次に、公証サービス端末40が、公証依頼情報に含まれる取引情報のハッシュ値(例えば、図20の取引情報のハッシュ値1003)を、公証サービスの秘密鍵で暗号化公証サービスの電子署名1201(図22)を作成する(ステップS93)。
次に、公証サービス端末40が、公証依頼情報に含まれるインプットデータのハッシュ値を公証DB41に保存する(ステップS94)。
次に、公証サービス端末40が、公証サービスの電子署名1201を、公証依頼情報を送信した依頼者の受発注者端末10に送信する(ステップS95)。以上で、公証サービス処理は終了される。
図11に戻る。次に、発注登録処理部1111が、公証サービス端末40から送信された公証サービスの電子署名1201を受信したか否かを判断し(ステップS31)、受信していないと判断した場合(ステップS31でNO)、該判断を継続する。公証サービスの電子署名1201を受信したと判断した場合(ステップS31でYES)、次に、発注登録処理部1111が、電子署名1201が公証サービス端末40にて作成された正規のものであることを検証する(ステップS32)。
なお、ステップS32において、公証サービスの電子署名1201が正規のものではないと判断された場合、ユーザにエラーが通知されて該受発注取引情報作成処理は中断される。
次に、発注登録処理部1111が、契約DB1211に保存されている、電子署名1004,1101が付された受発注取引情報1000に、公証サービスの電子署名1201を追加で付して保存する(ステップS33)。これにより、受発注者端末101の契約DB1211には、電子署名1004,1101,1201が付された受発注取引情報1000が保存されたことになる。
次に、発注登録処理部1111が、公証サービスの電子署名1201を受注者である二次請SIの受発注者端末102に送信する(ステップS34)。以上で、一次請SIの受発注者端末101による受発注取引情報作成処理は終了される。
受発注取引情報作成処理のステップS34により、公証サービスの電子署名1201が二次請SIの受発注者端末102に送信され、受発注者端末102によって受信されることになる。これにより、受発注者端末102では受発注取引情報確認処理(図16)のステップS78以降が再開される。
図16に戻る。次に、受注処理部1122が、受信した電子署名1201が公証サービス端末40にて作成された正規のものであることを検証する(ステップS78)。
なお、ステップS78において、公証サービスの電子署名1201が正規のものではないと判断された場合、ユーザにエラーが通知されて該受発注取引確認処理は中断される。
次に、受注処理部1122が、契約DB1212に保存されている、電子署名1004,1101が付された受発注取引情報1000(図17)に、公証サービスの電子署名1201を追加で付して保存する(ステップS79)。これにより、受発注者端末102の契約DB1212には、電子署名1004,1101,1201が付された受発注取引情報1000が保存されたことになる。以上で、二次請SIの受発注者端末102による受発注取引情報確認処理は終了される。
この段階で、発注者である一次請SIの受発注者端末101の契約DB1211と、受注者である二次請SIの受発注者端末102の契約DB1212とには、一次請SIの電子署名1004、二次請SIの電子署名1101、及び公証サービスの電子署名1201が付された受発注取引情報1000が共有されたので、一次請SIのAシステムズと二次請SIのBシステムズとの受注取引が成立し、且つ、公的な証明が与えられたことになる。
次に、階層取引情報作成処理(図13)のステップS51以降について説明する。図13に戻る。受発注者端末102から返信された階層取引情報2000(図19)を受信したと判断した発注登録処理部1111が、階層取引情報2000に付された電子署名2101が二次請SIの受発注者端末102にて作成された正規のものであることを検証するとともに、階層取引情報2000の内容に改ざんがないことを確認してから、受信した階層取引情報2000を階層DB1221に保存する(ステップS51)。
なお、階層DB1221への階層取引情報2000の保存は、ステップS49で保存した階層取引情報2000に上書きせずに新規で保存するようにする。
また、ステップS51において、階層取引情報2000に付された電子署名2101が正規のものではなかったり、階層取引情報2000の内容に改ざんがあったりしたと判断された場合、ユーザにエラーが通知されて該階層取引情報作成処理は中断される。
次に、発注登録処理部1111が、受信した階層取引情報2000から、階層取引情報2000のハッシュ値2006と、インプットデータのハッシュ値とを抽出して、階層取引情報2000に対する公証依頼情報を作成する(ステップS52)。なお、いまの場合、階層取引情報2000にはインプットデータが記録されていないので、階層取引情報2000から取引情報のハッシュ値2006だけが抽出されて、公証依頼情報が作成される。ここで、作成される公証依頼情報は、図20に示された、受発注取引情報1000に対する公証依頼情報3000と同様であるため、その図示は省略する。
次に、発注登録処理部1111が、階層取引情報2000に対する公証依頼情報を公証サービス端末40に送信する(ステップS53)。公証サービス端末40では、該公証依頼情報に応じて上述した公証サービス処理(図21)が実行され、公証サービス端末40から受発注者端末101に公証サービスの電子署名2201(図23)が送信される。
次に、発注登録処理部1111が、公証サービス端末40から送信された公証サービスの電子署名2201を受信したか否かを判断し(ステップS54)、受信していないと判断した場合(ステップS54でNO)、該判断を継続する。公証サービスの電子署名2201を受信したと判断した場合(ステップS54でYES)、次に、発注登録処理部1111が、電子署名2201が公証サービス端末40にて作成された正規のものであることを検証する(ステップS55)。
なお、ステップS55において、公証サービスの電子署名2201が正規のものではないと判断された場合、ユーザにエラーが通知されて該階層取引情報作成処理は中断される。
次に、発注登録処理部1111が、階層DB1221に保存されている、電子署名2007,2101が付された階層取引情報2000(図19)に、公証サービスの電子署名2201を追加で付して保存する(ステップS56)。これにより、受発注者端末101の階層DB1221には、電子署名2007,2101,2201が付された階層取引情報2000が保存されたことになる。
次に、発注登録処理部1111が、公証サービスの電子署名2201を受注者である二次請SIの受発注者端末102に送信する(ステップS57)。以上で、一次請SIの受発注者端末101による階層取引情報作成処理は終了される。
受発注取引情報作成処理のステップS57により、公証サービスの電子署名2201が二次請SIの受発注者端末102に送信され、受発注者端末102によって受信されることになる。これにより、受発注者端末102では階層取引情報確認処理(図18)のステップS88以降が再開される。
図18に戻る。次に、受注処理部1122が、受信した電子署名2201が公証サービス端末40にて作成された正規のものであることを検証する(ステップS88)。具体的には、ルート認証局30から事前に配布されている、公証サービスの秘密鍵に対応する公開鍵により、電子署名2201に含まれる暗号化されているハッシュ値の復号を行い、復号できた場合には電子署名2201が正規のものと判断する。
なお、ステップS88において、公証サービスの電子署名2201が正規のものではないと判断された場合、ユーザにエラーが通知されて該階層取引確認処理は中断される。
次に、受注処理部1122が、階層DB1222に保存されている、電子署名2007,2101が付された階層取引情報2000(図19)に公証サービスの電子署名2201を追加で付して保存する(ステップS89)。これにより、受発注者端末102の階層DB1222には、電子署名2007,2101,2201が付された階層取引情報2000が保存されたことになる。以上で、二次請SIの受発注者端末102による階層取引情報確認処理は終了される。
この段階で、発注者である一次請SIの受発注者端末101の階層DB1221と、受注者である二次請SIの受発注者端末102の階層DB1222とには、一次請SIの電子署名2007、二次請SIの電子署名2101、及び公証サービスの電子署名2201が付された階層取引情報2000が共有されたことになる。階層取引情報2000は、一次請SIから二次請SIへの請負構造を表すので、一次請SIから二次請SIへの請負構造が公的に証明されたことになる。
<二次請SI(Bシステムズ)による発注登録処理(図9のステップS3)について>
ステップS3の発注登録処理では、上述したステップS1の発注登録処理と同様の処理が行われる。
図24は、ステップS3の発注登録処理が実行されたことにより、発注者である二次請SIの受発注者端末102の契約DB1212と、受注者である三次請SIの受発注者端末103の契約DB1213とに保存され、共有された受発注取引情報1300の一例を示している。
受発注取引情報1300は、ステップS1の発注登録処理で保存、共有された受発注取引情報1000(図22)から、アウトプットデータのデータ名、案件ID、発注者、受注者、及び契約金額の各項目の内容が変更されたものとなる。
受発注取引情報1300には、二次請SIの電子署名1301、三次請SIの電子署名1302、及び公証サービスの電子署名1303が付されているので、二次請SIのBシステムズと三次請SIのCシステムズとの受注取引が成立し、公的に証明されたことになる。
<三次請SI(Cシステムズ)による受注処理(図9のステップS4)について>
ステップS4の受注処理では、上述したステップS2の受注処理と同様の処理が行われる。
図25は、ステップS4の受注処理が実行されたことにより、発注者である二次請SIの受発注者端末102の階層DB1222と、受注者である三次請SIの受発注者端末103の階層DB1223とに保存され、共有された階層取引情報2300の一例を示している。
階層取引情報2300は、そのインプットデータ2301に、ステップS1の受注処理で保存及び共有された階層取引情報2000(図23)のアウトプットデータ2003がコピーされ、その前取引ハッシュ値2302に、階層取引情報2000のハッシュ値2006がコピーされている。階層取引情報2300のアウトプットデータ2303の階層レベルには、インプットデータ2301の階層レベルである1に1が加算された2が記録されている。
階層取引情報2300には、二次請SIの電子署名2304、三次請SIの電子署名2305、及び公証サービスの電子署名2306が付されている。階層取引情報2300は、一次請SIから三次請SIに至る多重請負構造を表すので、一次請SIから三次請SIに至る多重請負構造が公的に証明されたことになる。
<三次請SI(Cシステムズ)によるインボイス登録処理(図9のステップS5)について>
次に、図26は、三次請SI(Cシステムズ)によるインボイス登録処理の一例を説明するフローチャートである。図27は、インボイス登録処理にて依頼者の受発注者端末103から金融機関端末20に送信されるインボイス取引情報4000の一例を示している。
該インボイス登録処理は、依頼者の受発注者端末103に対するユーザからの所定の操作に応じて開始される。
始めに、インボイス登録処理部1133が、階層DB1223から、インボイスファイナンスで担保とする受注案件の案件ID(ユーザにより指定される)に対応する階層データを検索し、インボイス取引情報4000(図27)のインプットデータ4001にコピーする(ステップS101)。いまの場合、階層DB1223から、案件ID(ABC110)に対する階層取引情報2300(図23)のアウトプットデータ2303に記録されている階層データが検索されて、インボイス取引情報4000のインプットデータ4001にコピーされる。
次に、インボイス登録処理部1133が、該階層データに紐づけられた階層取引情報とそれに連なる上位側の一連の階層取引情報を階層DB1223から取得する(ステップS102)。
次に、インボイス登録処理部1133が、契約DB1213に保存されている、インボイスファイナンスで担保とする受注案件の案件IDに対応する受発注取引情報1300(図24)に基づいて、インボイス取引情報4000のアウトプットデータ4002にインボイスデータを記録する(ステップS103)。インボイスIDは、ユーザが入力してもよいし、インボイス登録処理部1133が他のインボイスデータと重複しない文字列を生成するようにしてもよい。なお、インボイスデータのヘアカット率及び手数料については金融機関にて記録されるので空欄でよい。
次に、インボイス登録処理部1133が、インボイス取引情報4000の前取引ハッシュ値4003に、一つ上位の階層取引情報2300(図25)のハッシュ値2307を記録する(ステップS104)。
次に、インボイス登録処理部1133が、インボイス取引情報4000のハッシュ値4004を算出してインボイス取引情報4000に記録し(ステップS105)、ハッシュ値4004を依頼者(Cシステムズ)の秘密鍵を用いて暗号化することによって依頼者の電子署名4005を作成する(ステップS106)。
次に、インボイス登録処理部1133が、電子署名4005を付したインボイス取引情報4000、及びステップS102で取得した一連の階層取引情報2000,2300を金融機関端末20に送信する(ステップS107)。
金融機関端末20に送信するインボイス取引情報4000には、階層データと、インボイスファイナンスに必要な最低限の項目だけが記録されているので、受発注取引の第三者である金融機関に受発注取引に関する情報が漏洩することを抑止できる。
次に、インボイス登録処理部1133が、電子署名4005を付したインボイス取引情報4000をインボイスDB1233に保存する(ステップS108)。
次に、インボイス登録処理部1133が、金融機関端末20から返信されたインボイス取引情報4100(図29)を受信したか否かを判断し(ステップS109)、受信していないと判断した場合(ステップS109でNO)、当該判断を繰り返す。その後、インボイス登録処理部1133が、返信されたインボイス取引情報4100を受信したと判断した場合(ステップS109でYES)、処理はステップS110に進められる。ステップS110以降については後述する。
<金融機関によるインボイス受付処理(図9のステップS6)について>
次に、図28は、金融機関によるインボイス受付処理の一例を説明するフローチャートである。図29は、インボイス受付処理にて金融機関端末20から依頼者の受発注者端末103に返信されるインボイス取引情報4100の一例を示している。
該インボイス受付処理は、金融機関端末20に対するユーザからの所定の操作に応じて開始される。
始めに、金融機関端末20のインボイス受付処理部211が、依頼者の受発注者端末103から送信されたインボイス取引情報4000(図27)、及び階層取引情報2000,2300を受信したか否かを判断する(ステップS121)。ここで、インボイス取引情報4000、及び階層取引情報2000,2300を受信していないと判断した場合(ステップS121でNO)、当該判断を繰り返す。
その後、インボイス取引情報4000、及び階層取引情報2000,2300を受信したと判断した場合(ステップS121でYES)、インボイス受付処理部211が、インボイス取引情報4000に付された電子署名4005が依頼者の受発注者端末103にて作成された正規のものであることを検証するとともに、インボイス取引情報4000の内容に改ざんがないことを確認し、また、階層取引情報2000,2300についても電子署名の検証および内容に改ざんがないことの確認を行い、受付画面6200(図35)を表示する(ステップS122)。
なお、ステップS122において、電子署名4005等が正規のものではなかったり、インボイス取引情報4000等の内容に改ざんがあったりしたと判断された場合、またはユーザが受付画面6200の辞退ボタン6205(図35)を操作した場合、該インボイス受付処理は中断される。
次に、インボイス受付処理部211が、インボイス取引情報4000のインプットデータ4001、アウトプットデータ4002、及び前取引ハッシュ値4003をコピーして、新たにインボイス取引情報4100を作成する(ステップS123)。これにより、インボイス取引情報4000のアウトプットデータ4002とはデータ名が異なるアウトプットデータ4102を有するインボイス取引情報4100が作成されたことになる。
次に、インボイス受付処理部211が、インボイス取引情報4100のアウトプットデータ4102の空欄の項目(ヘアカット率、及び手数料)に、受付画面6200のヘアカット率入力エリア6202、及び手数料入力エリア6203(いずれも図35)にユーザから入力された値を記録するとともに、アウトプットデータ4102のハッシュ値を算出して更新する(ステップS124)。
次に、インボイス受付処理部211が、受付画面6200の融資ボタン6204(図35)をユーザが操作したことに応じ、インボイス取引情報4100のハッシュ値4104を算出してインボイス取引情報4100に記録し(ステップS125)、算出したハッシュ値を金融機関の秘密鍵を用いて暗号化することによって金融機関の電子署名4105(図29)を作成する(ステップS126)。
次に、インボイス受付処理部211が、電子署名4105を付したインボイス取引情報4100を依頼者の受発注者端末103に返信する(ステップS127)。
次に、インボイス受付処理部211が、電子署名4105を付したインボイス取引情報4100をインボイスDB221に保存する(ステップS128)。
次に、インボイス受付処理部211が、依頼者の受発注者端末103から送信された公証サービスの電子署名4301(図32)、及び依頼者の電子署名4201(図32)を受信したか否かを判断し(ステップS129)、受信していないと判断した場合(ステップS129でNO)、当該判断を繰り返す。その後、インボイス受付処理部211が公証サービスの電子署名4301及び依頼者の電子署名4201を受信したと判断した場合(ステップS129でYES)、処理はステップS130に進められる。ステップS130以降については後述する。
上述した金融機関端末20によるインボイス受付処理のステップS127により、金融機関端末20から依頼者の受発注者端末103に対してインボイス取引情報4100が返信され、これが受発注者端末103によって受信されることになる。これにより、受発注者端末103では、インボイス登録処理(図26)のステップS110以降が再開される。
図26に戻る。次に、金融機関端末20から返信されたインボイス取引情報4100(図29)を受信したと判断したインボイス登録処理部1133が、インボイス取引情報4100のアウトプットデータ4102を表示部14に表示し、ユーザが金融機関にて追加されたヘアカット率及び手数料を確認する(ステップS110)。
次に、インボイス登録処理部1133が、インボイス取引情報4100に付された電子署名4105が金融機関端末20にて作成された正規のものであることを検証するとともに、インボイス取引情報4100の内容に改ざんがないことを確認し、保存する(ステップS111)。
なお、インボイスDB123-へのインボイス取引情報4100の保存は、ステップS108で保存したインボイス取引情報4000に上書きせずに新規で保存するようにする。
また、ステップS112において、インボイス取引情報4100に付された電子署名4105が正規のものではなかったり、インボイス取引情報4100の内容に改ざんがあったりしたと判断された場合、ユーザにエラーが通知されて該インボイス登録処理は中断される。
次に、インボイス登録処理部1133が、受信したインボイス取引情報4100のハッシュ値を改めて算出して依頼者(Cシステムズ)の秘密鍵を用いて暗号化することによって依頼者の電子署名4201(図30)を作成し、受信したインボイス取引情報4100に追加で付してインボイスDB1233に保存する(ステップS112)。
図30は、インボイスDB1233に保存されたインボイス取引情報4100の一例を示している。同図に示されるように、保存されたインボイス取引情報4100には金融機関(Xバンク)の電子署名4105、及び依頼者(Cシステムズ)の電子署名4201が付されたものとなる。
次に、インボイス登録処理部1133が、インボイス取引情報4100から、インボイス取引情報4100の取引情報のハッシュ値4104(図30)と、インプットデータ4101のハッシュ値とを抽出して、インボイス取引情報4100に対する公証依頼情報5000を作成する(ステップS113)。図31は、インボイス取引情報4100に対する公証依頼情報5000の一例を示している。
次に、インボイス登録処理部1133が、インボイス取引情報4100に対する公証依頼情報5000を公証サービス端末40に送信する(ステップS114)。公証サービス端末40では、公証依頼情報5000に応じ、上述した公証サービス処理(図21)が実行され、公証サービス端末40から受発注者端末103に公証サービスの電子署名4301(図32)が送信される。
次に、インボイス登録処理部1133が、公証サービス端末40から送信された公証サービスの電子署名4301を受信したか否かを判断し(ステップS115)、受信していないと判断した場合(ステップS115でNO)、該判断を継続する。公証サービスの電子署名4301を受信したと判断した場合、次に、インボイス登録処理部1133が、電子署名4301が公証サービス端末40にて作成された正規のものであることを検証する(ステップS116)。
なお、ステップS116において、公証サービスの電子署名4301が正規のものではないと判断された場合、ユーザにエラーが通知されて該インボイス登録処理は中断される。
次に、インボイス登録処理部1133が、インボイスDB1233に保存されている、電子署名4105,4201が付されたインボイス取引情報4100(図30)に、公証サービスの電子署名4301を追加で付して保存する(ステップS117)。
図32は、公証サービスの電子署名4301を追加で付されたインボイス取引情報4100の一例を示している。同図に示されるように、受発注者端末103のインボイスDB1233には、電子署名4105,4201,4301が付されたインボイス取引情報4100が保存されたことになる。
次に、インボイス登録処理部1133が、公証サービスの電子署名4301、及び依頼者の電子署名4201を金融機関端末20に送信する(ステップS118)。以上で、依頼者の受発注者端末103によるインボイス登録処理は終了される。
インボイス登録処理のステップS119により、公証サービスの電子署名4301、及び依頼者の電子署名4201が金融機関端末20に送信され、金融機関端末20で受信されることになる。これにより、金融機関端末20ではインボイス受付処理(図28)のステップS130以降が再開される。
図28に戻る。次に、インボイス受付処理部211が、受信した電子署名4301が公証サービス端末40にて作成された正規のものであることを検証する(ステップS130)。具体的には、ルート認証局30から事前に配布されている、公証サービスの秘密鍵に対応する公開鍵により、電子署名4301に含まれる暗号化されているハッシュ値の復号を行い、復号できた場合には電子署名4301が正規のものと判断する。
次に、インボイス受付処理部211が、受信した電子署名4201が依頼者の受発注者端末103にて作成された正規のものであることを検証する(ステップS131)。
なお、ステップS130において、電子署名4301が正規のものではないと判断された場合、またはステップS131において、電子署名4201が正規のものではないと判断された場合、ユーザにエラーが通知されて該インボイス受付処理は中断される。
次に、インボイス受付処理部211が、インボイスDB221に保存されている、電子署名4105が付されたインボイス取引情報4100(図29)に公証サービスの電子署名4301、及び依頼者の電子署名4201を追加で付して保存する(ステップS132)。これにより、金融機関端末20のインボイスDB221には、電子署名4105,4201,4301が付されたインボイス取引情報4100が保存されたことになる。以上で、金融機関端末20によるインボイス受付処理は終了される。
この段階で、依頼者である三次請SIの受発注者端末103のインボイスDB1233と、金融機関端末20のインボイスDB221とには、依頼者の電子署名4201、金融機関の電子署名4105、及び公証サービスの電子署名4301が付されたインボイス取引情報4100が保存、共有されたことになり、依頼者と金融機関とのインボイスファイナンスの契約が成立したことになる。
<操作画面の表示例>
次に、図33は、受発注者端末10に表示される発注画面6000の表示例を示している。
発注画面6000には、前取引案件ID入力エリア6001、受発注データ入力エリア6002、及び発注ボタン6003が設けられている。
前取引案件ID入力エリア6001は、例えば、二次請SIから三次請SIに発注する場合のように、多重請負構造の上層側から受注した取引案件を下層側に発注する場合に、上層側から受注した取引案件の案件IDを入力するための領域である。前取引案件ID入力エリア6001への入力は、ユーザが案件IDを入力するようにしてもよいし、契約DB121に記録されている受発注取引情報のアウトプットデータから案件IDを抽出し、リスト化して表示し、ユーザに選択させるようにしてもよい。なお、一次請SIから二次請SIに発注する場合、前取引案件ID入力エリア6001への入力は不要である。
受発注データ入力エリア6002は、受発注データの顧客名、案件名、開始日、終了日、発注者、受注者、及び契約金額を入力するための領域である。なお、前取引案件ID入力エリア6001に案件IDが入力された場合、該案件IDに対応する受発注データが契約DB121から検索され、そこに記載されている顧客名、案件名、開始日、及び終了日が受発注データ入力エリア6002の同じ項目にコピーされ、そこに記載されている受注者が受発注データ入力エリア6002の発注者の項目にコピーされる。よって、ユーザは、受発注データ入力エリア6002の受注者、及び契約金額の項目にだけ入力すればよい。
前取引案件ID入力エリア6001に案件IDが入力されない場合、ユーザは、受発注データ入力エリア6002のすべての項目に入力する必要がある。
発注ボタン6003は、受発注データ入力エリア6002に入力した内容を確定し、受注者(の候補)に対して、受発注取引情報1000(図12)の送信を指示するための操作ボタンである。
図34は、受発注者端末10に表示される受注画面6100の表示例を示している。
受注画面6100には、受発注データ表示エリア6101、受注ボタン6102、及び辞退ボタン6103が設けられている。
受発注データ表示エリア6101は、発注者から送信された受発注取引情報1000のアウトプットデータ1001に記録されている受発注データのうちの、顧客名、案件名、開始日、終了日、発注者、受注者、及び契約金額を表示するための領域である。受注ボタン6102は、受発注データ表示エリア6101に表示された内容を確定し、受注する場合に操作するボタンである。辞退ボタン6103は、受注を辞退する場合に操作するボタンである。
図35は、金融機関端末20に表示される受付画面6200の表示例を示す図である。
受付画面6200には、多重請負構造表示エリア6201、ヘアカット率入力エリア6202、手数料入力エリア6203、融資ボタン6204、及び辞退ボタン6205が設けられている。
多重請負構造表示エリア6201は、インボイス取引の依頼者を含む多重請負構造の構成者を表示するための領域である。多重請負構造の構成者は、依頼者からのインボイス取引情報4100、及び、それに連なる一連の階層取引情報2300,2000の階層データにおける発注者と受注者とに基づいて抽出される。
ヘアカット率入力エリア6202、及び手数料入力エリア6203は、金融機関にてヘアカット率及び手数料を入力するための領域である。融資ボタン6204は、多重請負構造表示エリア6201に表示された多重請負構造を確認し、入力したヘアカット率及び手数料を確定して、貸し付けの依頼を受ける場合に操作するボタンである。辞退ボタン6205は、貸し付けの依頼を辞退する場合に操作するボタンである。
なお、図33〜図35に示した操作画面の表示例は一例に過ぎず、これらに限るものではない。
以上に説明した本実施形態の受発注・融資システム1によれば、IT業界における多重請負構造を金融機関に対して可視化することができる、これにより、金融機関からの信頼度が低い下請SIであっても、発注者である上層側の大手SIの信用度を活用して自身の信用度を補完でき、金融機関からインボイスファイナンスを受け得ることが期待できる。
また、金融機関に送信されるインボイス取引情報には、階層データと、インボイスファイナンスに必要な最低限の項目だけが記録されているので、受発注取引の第三者である金融機関に受発注取引に関する情報が漏洩することを抑止できる。また、各ノード間で通信する各種の取引情報には電子署名を付しているので、その内容が改ざんされてしまうことを抑止できる。
さらに、受発注・融資システム1における公証サービス端末40の公証DB41には、公証依頼情報のインプットデータとして記録されていた階層データのハッシュ値が保存される。これにより、今後、当該階層データを使用したインボイス取引に対して公証サービスの電子署名が発行されない。すなわち、例えば、インボイスファイナンスの依頼者が、同じ階層データを使ったインボイス取引情報を、別の金融機関に送信してインボイスファイナンスを依頼したとしても(売掛債権の二重譲渡)、その金融機関では、依頼者からのインボイス取引情報に対して、公証サービスの電子署名が得られないことを根拠として、依頼者に対してインボイスファイナンスの依頼を拒否することができる。
なお、受発注・融資システム1は、多重請負構造を有するIT業界以外の各種業界、例えば、製造業、建設業、広告業等の業界における受発注取引にも適用することができる。
本発明は、上述した実施形態に限定されるものではなく、様々な変形が可能である。例えば、上述した実施形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施形態の構成の一部を他の実施形態の構成に置き換えたり、追加したりすることが可能である。
また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、SSD等の記録装置、または、ICカード、SDカード、DVD等の記録媒体に置くことができる。また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。