JP7215581B2 - サプライチェーン管理方法、サプライチェーン管理プログラム、取引記録蓄積方法、取引記録蓄積プログラム、取引記録表示方法、及び取引記録表示プログラム - Google Patents

Description

関連出願の相互参照

この出願は、２０１９年７月２日に日本に出願された特許出願第２０１９－１２３８３６号を基礎としており、基礎の出願の内容を、全体的に、参照により援用している。

この明細書による開示は、取引記録を管理するサプライチェーン管理の技術に関する。

特許文献１には、廃棄物の処理に関するトレーサビリティ管理を行うことを目的とした物品処理の管理システムが開示されている。具体的に、特許文献１の管理システムでは、廃棄物情報を記録した二次元コード又はＩＣタグが、マニフェストとして廃棄物と共に流通する。そして、廃棄物処理を処理する業者別に予め識別情報が与えられており、この廃棄物の処理業者にてマニフェストが読み取られると、当該業者における処理の実行記録が、分散型記憶システムに記憶される。

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

特許文献１に開示された管理システムにおいて、マニフェストに記録される情報は、廃棄物カテゴリ、廃棄物の量、及び処理ルート等の予め設定された内容である。しかし、サプライチェーンにおける取引者の不正を排除するためには、予め設定された内容ではなく、それまでの取り引き結果を反映した内容が、取引者間で流通するアイテムに付属することが望ましい。しかし、流通過程で関与した多数の取引者の情報を、アイテムに付属させる二次元コード及びＩＣタグ等に全て記録することは、非常に困難である。

本開示は、アイテムに付属させるデータ量を抑えつつ、サプライチェーンの管理を適切に行うことが可能なサプライチェーン管理方法、サプライチェーン管理プログラム、取引記録蓄積方法、取引記録蓄積プログラム、取引記録表示方法、及び取引記録表示プログラム等の提供を目的とする。

上記目的を達成するため、開示された一つの態様は、コンピュータによって実施され、複数の取引者を含んで構築されるサプライチェーンにおける各取引者間での取引記録を、ブロックチェーンを用いて管理するサプライチェーン管理方法であって、少なくとも一つのプロセッサにて実行される処理に、一つの取引者である特定者に納入された納入アイテムに付属するアイテムデータと、特定者に割り当てられたノード識別データとを取得し、特定者における取引記録をアイテムデータに関連付けて蓄積し、納入アイテムに付属していたアイテムデータを、特定者から別の取引者に出荷される出荷アイテムに付属させるアイテムデータとして継続使用することを決定し、取引記録の参照要求をアイテムデータと共に取得し、アイテムデータが複数の取引者にて継続使用されていた場合に、当該アイテムデータを使用した複数の取引者における各取引記録を、ブロックチェーンを用いて管理された多数の取引記録から抽出し、抽出した取引記録に基づく提供用データを、参照要求の要求元に提供する、というステップを含むサプライチェーン管理方法とされる。
また開示された一つの態様は、複数の取引者を含んで構築されるサプライチェーンにおける各取引者間での取引記録を、ブロックチェーンを用いて管理するサプライチェーン管理プログラムであって、少なくとも一つのプロセッサに、一つの取引者である特定者に納入された納入アイテムに付属するアイテムデータと、特定者に割り当てられたノード識別データとを取得し、特定者における取引記録をアイテムデータに関連付けて蓄積し、納入アイテムに付属していたアイテムデータを、特定者から別の取引者に出荷される出荷アイテムに付属させるアイテムデータとして継続使用することを決定し、取引記録の参照要求をアイテムデータと共に取得し、アイテムデータが複数の取引者にて継続使用されていた場合に、当該アイテムデータを使用した複数の取引者における各取引記録を、ブロックチェーンを用いて管理された多数の取引記録から抽出し、抽出した取引記録に基づく提供用データを、参照要求の要求元に提供する、ことを含む処理を実施させるサプライチェーン管理プログラムとされる。
また開示された一つの態様は、コンピュータによって実施され、サプライチェーンに含まれる複数の取引者の一つである特定者での取引記録を、ホストノードにアップロードする取引記録蓄積方法であって、少なくとも一つのプロセッサにて実行される処理に、特定者に納入された納入アイテムに付属するアイテムデータと、特定者に割り当てられたノード識別データとをホストノードへ向けて送信し、納入アイテムに付属していたアイテムデータを、特定者から別の取引者に出荷される出荷アイテムに付属させるアイテムデータとして継続使用する場合に、アイテムデータの継続使用を許可する旨の許可通知を、ホストノードから受信し、許可通知の受信に基づき、アイテムデータの継続利用を決定する、というステップを含む取引記録蓄積方法とされる。
また開示された一つの態様は、サプライチェーンに含まれる複数の取引者の一つである特定者での取引記録を、ホストノードにアップロードする取引記録蓄積プログラムであって、特定者に納入された納入アイテムに付属するアイテムデータと、特定者に割り当てられたノード識別データとをホストノードへ向けて送信し、納入アイテムに付属していたアイテムデータを、特定者から別の取引者に出荷される出荷アイテムに付属させるアイテムデータとして継続使用する場合に、アイテムデータの継続使用を許可する旨の許可通知を、ホストノードから受信し、許可通知の受信に基づき、アイテムデータの継続利用を決定する、ことを含む処理を、少なくとも一つのプロセッサに実施させる取引記録蓄積プログラムとされる。
また開示された一つの態様は、コンピュータによって実施され、サプライチェーンに含まれる複数の取引者間での取引記録を表示させる取引記録表示方法であって、少なくとも一つのプロセッサにて実行される処理に、取引記録の参照要求を、特定アイテムに付属するアイテムデータと共にホストノードへ送信し、ブロックチェーンを用いて管理された多数の取引記録から抽出された取引記録であって、アイテムデータに関連付けられた取引記録、に基づく提供用データを、ホストノードから受信し、提供用データに基づき、特定アイテムの取引記録を表示させる、ことを含む処理を、少なくとも一つのプロセッサに実施させ、アイテムデータが複数の取引者にて継続使用されていた場合、提供用データには、当該アイテムデータを使用した複数の取引者における各取引記録が含まれる、取引記録表示方法とされる。
また開示された一つの態様は、サプライチェーンに含まれる複数の取引者間での取引記録を表示させる取引記録表示プログラムであって、取引記録の参照要求を、特定アイテムに付属するアイテムデータと共にホストノードへ送信し、ブロックチェーンを用いて管理された多数の取引記録から抽出された取引記録であって、アイテムデータに関連付けられた取引記録、に基づく提供用データを、ホストノードから受信し、提供用データに基づき、特定アイテムの取引記録を表示させる、ことを含む処理を、少なくとも一つのプロセッサに実施させ、アイテムデータが複数の取引者にて継続使用されていた場合、提供用データには、当該アイテムデータを使用した複数の取引者における各取引記録が含まれる、取引記録表示プログラムとされる。

これらの態様によれば、出荷アイテムに付属されるアイテムデータは、複数の取引者によって継続使用される。一方で、ブロックチェーンには、複数の取引者による取引記録が、継続使用される一つのアイテムデータに関連付けて蓄積される。以上によれば、アイテムに付属させるデータ量を抑えつつ、取引者間でのアイテムの取引記録が、アイテムの流通に伴いブロックチェーンに改ざん困難に蓄積されていく。したがって、サプライチェーンの管理を適切に行うことが可能になる。

本開示の第一実施形態によるサプライチェーン管理システムの全体像を示す図である。 ユーザ装置、タイムスタンプサーバ、データ管理サーバ及びユーザ端末の電気的な構成を示すブロック図である。 アイテムデータ等を記録し、取引者間を流通するアイテムに添付される二次元コードの一例を示す図である。 タイムスタンプサーバの応答出力部にて実施される応答出力処理の詳細を示すフローチャートである。 データ管理サーバの記録検証部にて実施されるデータ異常検証処理の詳細を示すフローチャートである。 アイテムの流通に伴ってハッシュ値がマークルツリーとして繋げられていく過程を模式的に示す図である。 サプライチェーン管理システムにて実施されるチェーン生成処理の詳細を示すシーケンス図である。 データ管理サーバ及びユーザ端末の連携により実施される記録照会処理の詳細を示すシーケンス図である。 トレーサビリティ確認アプリによってユーザ端末に表示されるＧＵＩ画面の表示遷移の詳細を示す図である。 図１に示すサプライチェーン管理システムを食パンのサプライチェーンに適用した適用例を示す図である。 初期設定データの登録と基本情報コードの発行とを行う初期設定処理の詳細を示すシーケンス図である。 図７に示すチェーン生成処理を、図１０に示すサプライチェーンに適用した適用例を示す図である。 第二実施形態のチェーン生成処理の詳細を示すシーケンス図である。 第二実施形態の記録照会処理の詳細を示すシーケンス図である。

以下、本開示の複数の実施形態を図面に基づいて説明する。尚、各実施形態において対応する構成要素には同一の符号を付すことにより、重複する説明を省略する場合がある。各実施形態において構成の一部分のみを説明している場合、当該構成の他の部分については、先行して説明した他の実施形態の構成を適用することができる。また、各実施形態の説明において明示している構成の組み合わせばかりではなく、特に組み合わせに支障が生じなければ、明示していなくても複数の実施形態の構成同士を部分的に組み合わせることができる。そして、複数の実施形態及び変形例に記述された構成同士の明示されていない組み合わせも、以下の説明によって開示されているものとする。

（第一実施形態）
図１に示す本開示の第一実施形態によるサプライチェーン管理システム１００は、複数の取引者ＴＲを含んで構築されたサプライチェーンＳＣにおいて、各取引者ＴＲ間にて取引されるアイテムの取引記録ＲｅＴを管理する。サプライチェーン管理システム１００では、取引記録ＲｅＴの改ざん防止を目的として、取引記録ＲｅＴの管理にブロックチェーンＢＣの技術が利用される。

サプライチェーンＳＣは、例えば工業製品、農業製品及び水産物等を消費者ＣＳＴに届けるための取引者ＴＲ同士の繋がりである。一例として、工業製品を消費者ＣＳＴに届けるためのサプライチェーンＳＣでは、材料採掘業者、材料生産者、加工業者、運送業者及び販売業者等が取引者ＴＲに含まれる。この場合、原材料ＭＡＴから最終製品ＦＰまでのサプライチェーンＳＣが構築される。加えて本開示では、最終製品ＦＰの消費者ＣＳＴ及び最終製品ＦＰの廃棄に関わる廃棄処理業者等も、取引者ＴＲに含むことができる。

多数の取引者ＴＲのうちで、消費者ＣＳＴを除く各業者には、認証者Ｃｅｒ（認証機関）によって予め認証が与えられている。認証者Ｃｅｒは、一例として、サプライチェーンＳＣを管理する管理者であり、且つ、最終製品ＦＰを消費者ＣＳＴに提供する提供者である。認証者Ｃｅｒは、所定の基準を満たした業者を認定し、当該認定業者に対して認証を発行することでサプライチェーンＳＣへの参加を許可する。尚、認証者Ｃｅｒは、後述するように、サプライチェーン管理システム１００のシステムサプライヤ又はプラットフォーマー等に相当する会社が担っていてもよい。

図１及び図２に示すように、サプライチェーン管理システム１００は、複数（多数）のユーザ装置１０、タイムスタンプサーバ９０、及び少なくとも一つのデータ管理サーバ６０を含んで構成されている。各ユーザ装置１０、タイムスタンプサーバ９０及びデータ管理サーバ６０は、それぞれネットワークＮＷに接続されており、相互に通信可能である。

ユーザ装置１０は、最終製品ＦＰの生産及び廃棄を行う各取引者ＴＲの施設に、少なくとも一つずつ設置されている。ユーザ装置１０は、設置された特定の取引者ＴＲ（以下、特定業者ＴＲｓ）の施設にて、当該特定業者ＴＲｓの作業員等によって使用される。ユーザ装置１０は、特定業者ＴＲｓに納入されるアイテム（以下、納入アイテムＩＭｉ）の納入記録を、データ管理サーバ６０に送信する。加えてユーザ装置１０は、特定業者ＴＲｓから出荷されるアイテム（以下、出荷アイテムＩＭｏ）に付属させる情報を、データ管理サーバ６０から受信する。ユーザ装置１０は、リーダ１７、ＧＮＳＳ（Global Navigation Satellite System）受信器１８、プリンタ１９及び処理回路１０ａを備えている。

リーダ１７は、アイテムデータ、カンパニーデータ及びタイムスタンプデータ等を読み取る機器である。各データは、例えばＱＲコード（登録商標）等の二次元コードに記録されている。リーダ１７は、ＣＣＤ素子を二次元配列させてなるエリアセンサを含む構成である。リーダ１７は、紙媒体等に印刷された二次元コードを読み取り、読み取った二次元コードの情報を処理回路１０ａに出力する。

アイテムデータは、納入アイテムＩＭｉに付属するデータである。納入アイテムＩＭｉには、アイテムデータを記録した二次元コード（以下、アイテムコードＱＲｉ）が、紙媒体に印刷された状態で、ラベルとして貼り付けられている。アイテムコードＱＲｉの貼り付け場所は、製品本体に限定されず、パッケージ、包装及び証明書類等のいずれかであってよい。アイテムコードＱＲｉには、納入アイテムＩＭｉに紐づくアイテムデータとしてのハッシュ値と、取引記録ＲｅＴの問合わせ先のＩＰアドレスとが少なくとも記録されている（図３参照）。ハッシュ値は、後述するように、納入アイテムＩＭｉのこれまでの流通過程を反映した値（マークルルート）となっている。

尚、アイテムコードＱＲｉには、上述のＩＰアドレスに替えて、取引記録ＲｅＴの問合わせ先のＵＲＬが記録されていてもよい。但し、ＩＰアドレスには、ＵＲＬと比較して、データ量（ビット数）が変動しないという利点がある。さらに、トレーサビリティのシステムとして、取引記録ＲｅＴの問合わせ先の情報が各取引者ＴＲに別の手段で予め提供されていれば、アイテムコードＱＲｉには、問合わせ先を示すＩＰアドレス及びＵＲＬ等は、記録されていなくてもよい。

カンパニーデータは、特定業者ＴＲｓを示す識別データである。各取引者ＴＲには、固有のカンパニーデータが認証者Ｃｅｒによって与えられている。各取引者ＴＲには、カンパニーデータを記録した二次元コード（以下、カンパニーコードＱＲｃ）が、紙媒体等に印刷された状態で、予め配布されている。カンパニーコードＱＲｃには、認証者Ｃｅｒによって各取引者ＴＲに予め紐づけられたハッシュ値が、カンパニーデータとして記録されている。認証者Ｃｅｒは、取引者ＴＲの名前（会社名及び代表者名等）、住所、事業所名、及び経歴等の情報を、認証データとして把握している。カンパニーデータは、こうした認証データに基づくハッシュ値であってよい。

尚、カンパニーデータの生成及びカンパニーコードＱＲｃの配布は、認証を行うサプライチェーンＳＣの管理者ではなく、サプライチェーン管理システム１００のシステムサプライヤによって実施されてよい。この場合、システムサプライヤも、認証者Ｃｅｒの一部とみなす。さらに、カンパニーコードＱＲｃは、一つの事業者に対して、複数提供されていてもよい。例えば、一つの事業者が所有する複数の製作所に、それぞれカンパニーコードＱＲｃが配布されていてもよい。また、特定の製品を製造する個々のラインに対して、互いに異なるカンパニーコードＱＲｃが配布されていてもよい。この場合、カンパニーコードＱＲｃに記録されるカンパニーデータは、事業者だけでなく、製作所及びライン等を特定可能な情報となる。

アイテムコードＱＲｉ及びカンパニーコードＱＲｃには、暗号鍵の利用により、記録された情報の公開及び非公開を設定可能なセキュアなＱＲコード（ＳＱＲＣ，登録商標）の利用が望ましい。ＳＱＲＣに記録されたデータは、公開鍵で暗号化されており、秘密鍵を知るユーザ装置１０からのみ、読み取り可能となる。その結果、アイテムデータ及びカンパニーデータの読み取り可能者が、サプライチェーンＳＣ内の取引者ＴＲに限定され得る。さらに、アイテムコードＱＲｉ及びカンパニーコードＱＲｃには、特殊インクの利用により、コピー機等による複製を困難にしたコピー防止ＱＲコードの利用が望ましい。

タイムスタンプデータは、納入アイテムＩＭｉが特定業者ＴＲｓのもとにあった日時に紐づくデータとして利用される。タイムスタンプデータは、タイムスタンプサーバ９０によって生成される。各取引者ＴＲには、タイムスタンプデータとしてのハッシュ値を記録した二次元コード（以下、タイムスタンプコードＱＲｔ）が、例えば画像データとして提供される。

リーダ１７は、初期設定データをさらに読み取り可能である。初期設定データは、他のデータと同様に、ＱＲコード等の二次元コードに記録されている。初期設定データは、アイテムデータ及びカンパニーデータを補完するデータである。初期設定データの一部の内容は、アイテムデータ又はカンパニーデータと重複していてもよい。初期設定データは、主として、サプライチェーンＳＣに原材料ＭＡＴを供給する取引者ＴＲにより、データ管理サーバ６０に予め登録されている（図１１参照）。一例として、原材料ＭＡＴの生産地及び生産設備等の情報が初期設定データとして登録可能である。データ管理サーバ６０は、初期設定データを記録した二次元コード（以下、基本情報コードＱＲｂ）を発行する。初期設定データを登録した取引者ＴＲには、基本情報コードＱＲｂが、例えば画像データとして提供される。基本情報コードＱＲｂは、紙媒体等に印刷され、アイテムコードＱＲｉ及びカンパニーコードＱＲｃ等と共に、リーダ１７によって読み取られる。

ＧＮＳＳ受信器１８は、複数の人工衛星（測位衛星）から送信された測位信号を受信することにより、ユーザ装置１０が利用されている場所を特定する。ＧＮＳＳ受信器１８によって特定されるユーザ装置１０の位置データは、納入アイテムＩＭｉがあった場所を示す履歴データとなる。ＧＮＳＳ受信器１８は、測位信号に基づく位置データを、処理回路１０ａに提供する。

プリンタ１９は、データ管理サーバ６０より取得する新規のアイテムコードＱＲｉを紙媒体（シール等）に印刷する出力機器である。プリンタ１９により印刷されたアイテムコードＱＲｉは、出荷アイテムＩＭｏに貼り付けられ、当該出荷アイテムＩＭｏに付属された状態で、次工程の取引者ＴＲに流通する。

処理回路１０ａは、プロセッサ１１、ＲＡＭ１２、記憶部１３、入出力インターフェース１４、及びこれらを接続するバス等を備えたマイクロコントローラを主体とする構成である。処理回路１０ａは、ユーザ装置１０のコンピュータとして機能する。処理回路１０ａは、プロセッサ１１のＲＡＭ１２へのアクセス処理により、取引記録ＲｅＴの蓄積に関連する複数の機能部を有する。具体的に、処理回路１０ａは、情報取得部２１、情報送信部２２、コード受信部２３及びコード出力部２４を備える。

情報取得部２１は、リーダ１７によって読み込まれた各コードの画像データから、アイテムデータ、カンパニーデータ及びタイムスタンプデータである各ハッシュ値を取得する。情報取得部２１は、ＧＮＳＳ受信器１８から位置データを取得する。情報送信部２２は、情報取得部２１にて取得された各データを、ネットワークＮＷを通じて、データ管理サーバ６０に送信する。

コード受信部２３は、情報送信部２２の送信データに基づき、データ管理サーバ６０にて生成されたアイテムコードＱＲｉの画像データを、ネットワークＮＷを通じて受信する。コード出力部２４は、コード受信部２３にて受信されたアイテムコードＱＲｉを、プリンタ１９によって出力させる。

タイムスタンプサーバ９０は、タイムスタンプデータを生成するサーバ装置である。タイムスタンプサーバ９０は、ユーザ装置１０及びデータ管理サーバ６０等の他のノードからタイムスタンプデータに関連する情報の提供要求を取得すると、タイムスタンプデータを要求元のノードに提供する。

タイムスタンプサーバ９０は、プロセッサ、ＲＡＭ、記憶部、入出力インターフェース、及びこれらを接続するバス等を備えたコンピュータを主体として含む構成である。プロセッサは、ＲＡＭと結合された演算処理のためのハードウェアである。プロセッサは、ＲＡＭへのアクセスにより、タイムスタンプデータの生成及び配信に関連する種々の処理を実行する。タイムスタンプサーバ９０は、記憶部に記憶されたタイムスタンプ生成プログラムに基づき、時事記述取得部９１、タイムスタンプ生成部９２及び応答出力部９３を備える。

時事記述取得部９１は、ネットワークＮＷに接続されたニュース配信サーバより、例えば当日の日付等、日時を示す情報に紐づけて配信されるニュース記事を取得する。時事記述取得部９１は、ニュース記事の取得を、例えば日毎、又は所定時間毎に実施する。一例として、時事記述取得部９１は、「令和元年スタート（２０１９年５月１日）」、「１７６本のマグロずらり。令和初の競り（２０１９年５月２日）」、「ニュージーランドの首相が婚約（２０１９年５月３日）」等のニュース記事を取得する。

タイムスタンプ生成部９２は、時事記述取得部９１にて取得されるニュース記事に基づき、タイムスタンプデータを生成する。タイムスタンプ生成部９２は、日付情報（例えば、２０１９０５０１）、ニュース記事の文字列、事前指定した文字列を順に結合させた入力情報を生成する。タイムスタンプ生成部９２は、ＳＨＡ－２５６等のハッシュ関数に、ニュース記事を含んだ上述の入力情報を入力する処理により、所定のビット数（例えば、２５６ビット）のハッシュ値を、タイムスタンプデータとして算出する。タイムスタンプ生成部９２は、算出したハッシュ値、日付情報、ニュース記事、所定文字列を、ひと纏まりの探索用データとして、タイムスタンプリストに蓄積する。

尚、サプライチェーン管理システム１００にて使用されるハッシュ関数は、暗号学的ハッシュ関数であり、違う入力から同一のハッシュ値を出力することがなく、且つ、出力されたハッシュ値から入力を推測することが実質不可能という特性を有している。例えば、上記のＳＨＡ－２５６に替えて、ＳＨＡ－１、ＳＨＡ－２及びＳＨＡ－３等の暗号化アルゴリズムが、必要とされる出力長（ビット数）に合わせて適宜使用されてよい。

応答出力部９３は、ネットワークＮＷを通じて、ユーザ装置１０及びデータ管理サーバ６０等の他のノードからタイムスタンプデータに関連する情報の提供要求を取得する。応答出力部９３は、提供要求の取得に基づき、応答出力処理（図４参照）を実施する。応答出力処理において、応答出力部９３は、提供要求と共に受信する引数の有無を判定し、さらに引数の内容を判別する（Ｓ１１参照）。応答出力部９３は、引数がない場合、最新のタイムスタンプデータの有無を判定する（Ｓ１２参照）。応答出力部９３は、最新のタイムスタンプデータがある場合、そのハッシュ値を記録したタイムスタンプコードＱＲｔの画像データを、要求元のノードに返信する（Ｓ１３参照）。一方で、タイムスタンプデータがない場合、応答出力部９３は、エラーを示す値（例えば、０）を通知する（Ｓ２０参照）。

また、ハッシュ値が引数としてある場合、応答出力部９３は、当該ハッシュ値に対応する日付情報をタイムスタンプリストから探索する（Ｓ１４参照）。該当する日付情報が探索された場合（Ｓ１５：ＹＥＳ参照）、応答出力部９３は、該当する日付を要求元のノードに返信する（Ｓ１６参照）。一方、該当する日付情報が探索されなかった場合（Ｓ１５：ＮＯ参照）、応答出力部９３は、エラーを示す値を通知する（Ｓ２０参照）。

さらに、日付が引数としてある場合、応答出力部９３は、当該日付に対応するハッシュ値をタイムスタンプリストから探索する（Ｓ１７参照）。該当するハッシュ値が探索された場合（Ｓ１８：ＹＥＳ参照）、応答出力部９３は、探索されたハッシュ値を要求元のノードに返信する（Ｓ１９参照）。一方、該当するハッシュ値が探索されなかった場合（Ｓ１８：ＮＯ参照）、応答出力部９３は、エラーを示す値を通知する（Ｓ２０参照）。

データ管理サーバ６０は、複数のユーザ装置１０と通信可能なホストノードである。データ管理サーバ６０は、取引記録ＲｅＴを蓄積し、蓄積した取引記録ＲｅＴのデータマイニングを実施する。データ管理サーバ６０は、プロセッサ６１、ＲＡＭ６２、記憶部６３、入出力インターフェース６４、及びこれらを接続するバス等を備えるコンピュータを主体としたサーバ装置６０ａによって構成されている。プロセッサ６１は、ＲＡＭ６２と結合された演算処理のためのハードウェアである。プロセッサ６１は、ＲＡＭ６２へのアクセスにより、データ管理に関連する種々の処理を実行する。記憶部６３には、データ管理を可能にするサプライチェーン管理プログラムが記憶されている。

データ管理サーバ６０は、多数のユーザ装置１０から提供された取引記録ＲｅＴを蓄積する記録生成機能に加えて、取引記録ＲｅＴを参照可能に提供する記録参照機能を備えている。以下、これらの機能のうちで、記録生成機能についての詳細を説明する。記憶部６３には、サプライチェーン管理プログラムの一つとして、取引記録ＲｅＴの蓄積を実現させる記録生成プログラムが格納されている。データ管理サーバ６０は、記録生成プログラムに基づき、記録取得部７１、記録検証部７２、チェーン生成部７３、及びコード提供部７４等の機能部を備える。

記録取得部７１は、ネットワークＮＷを通じて、ユーザ装置１０によって送信された情報を、取引記録ＲｅＴとして取得する。取引記録ＲｅＴには、少なくとも一つのアイテムデータ、カンパニーデータ、タイムスタンプデータ及び位置データが含まれている。アイテムデータ、カンパニーデータ、及びタイムスタンプデータは、それぞれ所定のビット数のハッシュ値である。記録取得部７１は、例えばＳＨＡ－２５６等のハッシュ関数に位置データを入力する演算処理により、位置データのハッシュ値をさらに取得する。

記録取得部７１は、タイムスタンプデータのハッシュ値を引数とする提供要求をタイムスタンプサーバ９０に送信する。その結果、記録取得部７１は、送信したハッシュ値に対応する日付情報を、タイムスタンプサーバ９０から受信する。尚、ユーザ装置１０から記録取得部７１へのタイムスタンプデータの送信は、省略されてもよい。この場合、記録取得部７１は、ユーザ装置１０からアイテムデータ等を取得したタイミングで、タイムスタンプデータとしてのハッシュ値を、当日の日付情報に関連付けて取得する。

記録検証部７２は、記録取得部７１にて取得されたデータを、予め登録されたデータ等と比較することにより、今回取得された各データが正常か否かを検証するデータ異常検証処理（図５参照）を実施する。記録検証部７２は、認証外の業者による不正な製品、部品及び原材料ＭＡＴ等について、サプライチェーンＳＣの流通アイテムへの混入を検知する。

具体的に、記録検証部７２は、各取引者ＴＲに設定されたカンパニーデータのリストを参照し（Ｓ３１参照）、記録取得部７１にて取得されたカンパニーデータがリストに登録された正規の値と一致するか否かを判定する（Ｓ３２参照）。記録検証部７２は、カンパニーデータのハッシュ値が、リストにあるハッシュ値と異なる場合、不正なアイテムの混入可能性がある旨の異常判定を行う（Ｓ３３参照）。

記録検証部７２は、記録取得部７１にて今回取得されたアイテムデータが、別の取引者ＴＲより既に取得したアイテムデータと重複するか否かを判定する（Ｓ３４参照）。詳記すると、新たに出荷アイテムＩＭｏが発生したとき、後述する処理（Ｓ１６４）において、当該出荷アイテムＩＭｏは、未使用のアイテムであるとして、取引記録ＲｅＴに記録される。今回の納入アイテムＩＭｉが未使用のアイテムであれば、記録検証部７２は、当該アイテムの使用ステータスを使用済みに変更する。一方で、今回の納入アイテムＩＭｉが既に使用済みとされたアイテムであれば、生産された個数以上のアイテムが発生していることになるため、記録検証部７２は、異常判定を行う。

記録検証部７２は、アイテムデータに紐づく過去のタイムスタンプデータ、具体的には、前工程以前の取引者ＴＲにて記録されたタイムスタンプデータを参照する（Ｓ３５参照）。記録検証部７２は、過去のタイムスタンプデータに紐づく日付情報について、時系列が正常であるか否かを判定する（Ｓ３６参照）。時系列が矛盾している等の場合、記録検証部７２は、異常判定を行う。

記録検証部７２は、カンパニーデータに対応する特定業者ＴＲｓの位置データのリストを参照（Ｓ３７参照）し、取得した位置データが登録された特定業者ＴＲｓの位置データと整合しているか否かを判定する（Ｓ３８参照）。例えば特定業者ＴＲｓの登録場所と全く異なる位置データが取得されていた場合、記録検証部７２は、異常判定を行う。一方、各データに異常が認められない場合、記録検証部７２は、納入アイテムＩＭｉが正規のアイテムである旨の正常判定を行う（Ｓ３９参照）。

チェーン生成部７３は、記録取得部７１にて取得されたアイテムデータ、カンパニーデータ、タイムスタンプデータ及び位置データ等を、ブロックチェーン技術を利用し、改ざん困難な状態で蓄積していく。チェーン生成部７３は、特定業者ＴＲｓの出荷アイテムＩＭｏに付属させる新たなアイテムデータとしてのハッシュ値を演算する。チェーン生成部７３は、出荷アイテムＩＭｏに関連する全ての納入アイテムＩＭｉのアイテムデータ、特定業者ＴＲｓのカンパニーデータ、タイムスタンプデータ及び位置データの各ハッシュ値を準備する。チェーン生成部７３は、これらのハッシュ値のマークルルートを算出する。

チェーン生成部７３は、取引記録ＲｅＴとして取得した各データ（ハッシュ値）を一つのブロックとし、ブロックチェーンＢＣの最後に連結させる。加えてチェーン生成部７３は、最後のブロックのハッシュ値を、新たなアイテムデータとする。以上の処理により、チェーン生成部７３は、サプライチェーンＳＣ内における各取引者ＴＲ間でのアイテムの取引が進むのに合わせて、それまでの流通過程を反映したハッシュ値の算出を繰り返していく。チェーン生成部７３は、ブロックチェーン化された取引記録ＲｅＴを、記憶部６３内の記憶領域に格納する。

コード提供部７４は、チェーン生成部７３にて算出された最終ブロックのハッシュ値を、取引記録ＲｅＴの送信元であるユーザ装置１０に提供する。コード提供部７４は、ハッシュ値を少なくとも含んだ二次元コードを、新たなアイテムコードＱＲｉとして生成する。コード提供部７４は、アイテムコードＱＲｉの画像データを、ユーザ装置１０へ向けて送信する。アイテムコードＱＲｉは、ユーザ装置１０によって紙媒体に出力され、次工程となる別の取引者ＴＲに特定業者ＴＲｓから出荷される出荷アイテムＩＭｏに添付される。

以上の記録生成機能によるブロックチェーンＢＣの生成過程を、図６に基づき、さらに説明する。図６に示す具体例では、カンパニーＡ及びカンパニーＢから出荷された各出荷アイテムＩＭｏが、それぞれ納入アイテムＩＭｉとしてカンパニーＣに納入される。そして、納入アイテムＩＭｉを使用してカンパニーＣにて生産された出荷アイテムＩＭｏが、次工程の取引者ＴＲへ向けて出荷される。この例において、カンパニーＡ及びカンパニーＢは、例えば材料サプライヤであり、サプライチェーンＳＣの起点となる企業である。一方、カンパニーＣは、例えば部品サプライヤであり、サプライチェーンＳＣの中間となる企業である。

カンパニーＡ及びカンパニーＢでは、タイムスタンプサーバ９０によって準備されたタイムスタンプコードＱＲｔ、認証者Ｃｅｒより配布されたカンパニーコードＱＲｃの読み込みが行われる。各コードＱＲｔ，ＱＲｃに記録された各ハッシュ値は、各カンパニーＡ，Ｂのユーザ装置１０から、データ管理サーバ６０に送信される。これらのハッシュ値は、チェーン生成部７３により、取引記録ＲｅＴとしてブロックチェーンＢＣに組み込まれる。さらに、最終ブロックのハッシュ値がアイテムコードＱＲｉに記録され、各カンパニーＡ，Ｂに送信される。アイテムコードＱＲｉは、紙媒体に印刷されたうえで、出荷アイテムＩＭｏに添付される。

カンパニーＣでは、タイムスタンプコードＱＲｔ及びカンパニーコードＱＲｃに加えて、各カンパニーＡ，Ｂより納入された納入アイテムＩＭｉに付属した各アイテムコードＱＲｉの読み込みが行われる。各コードＱＲｔ，ＱＲｃ，ＱＲｉに記録された各ハッシュ値は、データ管理サーバ６０に送信され、チェーン生成部７３によってブロックチェーンＢＣに組み込まれる。複数の取引者ＴＲからの出荷アイテムＩＭｏが一つ取引者ＴＲに納入されることで、ブロックチェーンＢＣは、直鎖状ではなく、ツリー状を呈する。この場合も、最終ブロックのハッシュ値がアイテムコードＱＲｉに記録され、カンパニーＣに送信される。アイテムコードＱＲｉは、紙媒体に印刷されたうえで、次工程の取引者ＴＲへの出荷アイテムＩＭｏに添付される。

以上の各カンパニーコードＱＲｃに記録されたハッシュ値は、例えば「Ｃｏｍｐａｎｙ Ａ（Ｂ又はＣ） ｃｅｒｔｉｆｉｃａｔｅｄ ｂｙ Ｃｏｍｐａｎｙ Ｘ」という内容をハッシュ値化した文字列である。この「Ｃｏｍｐａｎｙ Ｘ」は、認証者Ｃｅｒの名称である。また、各カンパニーＡ，Ｂに取得されるアイテムコードＱＲｉのハッシュ値は、例えば「Ｐｒｏｄｕｃｔ ｂｙ Ｃｏｍｐａｎｙ Ａ ｏｎ １ｓｔ， Ｍａｙ」といった事項を参照可能にする文字列である。同様に、カンパニーＣに取得されるアイテムコードＱＲｉのハッシュ値は、「Ｐｒｏｄｕｃｔ ｂｙ Ｃｏｍｐａｎｙ Ｃ ｏｎ ３ｒｄ， Ｍａｙ ｕｓｉｎｇ Ｐｒｏｄｕｃｔ ｂｙ Ｃｏｍｐａｎｙ Ａ ｏｎ １ｓｔ， Ｍａｙ ａｎｄ Ｐｒｏｄｕｃｔ ｂｙ Ｃｏｍｐａｎｙ Ｂ ｏｎ ２ｎｄ， Ｍａｙ」といった事項を参照可能にする文字列である。

次に、ここまで説明した各構成の連携により実施されるチェーン生成処理の詳細を、図７に示すシーケンス図に基づき、図１及び図２を参照しつつ、さらに説明する。

タイムスタンプサーバ９０にて実施されるＳ１９１では、ニュース情報の探索及びニュース記事の取得を実施し、Ｓ１９２に進む。Ｓ１９２では、Ｓ１９１にて取得したニュース記事に基づき、タイムスタンプデータとして使用するハッシュ値を生成し、Ｓ１９３に進む。Ｓ１９３では、Ｓ１９２にて算出したハッシュ値を少なくとも記録したタイムスタンプコードＱＲｔを生成し、ユーザ装置１０等に提供可能な状態に準備する。

ユーザ装置１０にて実施されるＳ１１１では、カンパニーコードＱＲｃの読み取りを行い、Ｓ１１２に進む。Ｓ１１２では、アイテムコードＱＲｉの読み取りを行い、Ｓ１１３に進む。納入アイテムＩＭｉが複数ある場合には、全ての納入アイテムＩＭｉに付属するアイテムコードＱＲｉの読み取りを実施する。また、基本情報コードＱＲｂが事前に準備されている場合、基本情報コードＱＲｂの読み取りも、Ｓ１１２にて実施する。

Ｓ１１３では、Ｓ１９３にて準備されたタイムスタンプコードＱＲｔの提示要求、画面への表示、及びの読み取りを実施し、Ｓ１１４に進む。尚、１１１～Ｓ１１３の読み取り処理の順序は、適宜入れ替え可能である。

Ｓ１１４では、Ｓ１１１～Ｓ１１３にて読み取りを行った各コードのハッシュ値と、最新の位置データとを、今回の取引記録ＲｅＴとしてデータ管理サーバ６０へ向けて送信し、Ｓ１１５に進む。

データ管理サーバ６０にて実施されるＳ１６１では、Ｓ１１４にてユーザ装置１０より送信される取引記録ＲｅＴを受信によって取得し、Ｓ１６２に進む。Ｓ１６２では、データ異常検証処理（図５参照）を実施し、今回の納入アイテムＩＭｉに関連する各データについて、異常がないことを確認したうえで、Ｓ１６３に進む。尚、データ異常検証処理によって異常判定が示された場合、エラーを示す値をユーザ装置１０に送信し、一連の処理を終了する。

Ｓ１６３では、Ｓ１６１にて取得した取引記録ＲｅＴに基づくブロックを、ブロックチェーンＢＣの最後に組み込み、Ｓ１６４に進む。Ｓ１６４では、最後のブロックのハッシュ値を演算し、Ｓ１６５に進む。Ｓ１６４では、算出したハッシュ値を付属させる出荷アイテムＩＭｏを、未使用のアイテムとして記録する。その結果、今回の出荷アイテムＩＭｏは、ブロックチェーンＢＣにおけるＵＴＸＯ（Unspent Transaction Output）として登録される。

Ｓ１６５では、Ｓ１６４にて算出したハッシュ値をアイテムコードＱＲｉに記録する。そして、生成したアイテムコードＱＲｉを、取引記録ＲｅＴの送信元であるユーザ装置１０へ向けて送信し、一連の処理を終了する。

ユーザ装置１０にて実施されるＳ１１５では、Ｓ１６５にてデータ管理サーバ６０より送信されるアイテムコードＱＲｉを受信し、Ｓ１１６に進む。Ｓ１１６では、Ｓ１１５にて受信したアイテムコードＱＲｉを出力し、一連の処理を終了する。

次に、データ管理サーバ６０の記録参照機能の詳細を、図１、図２、図８及び図９に基づき説明する。データ管理サーバ６０の記憶部６３には、サプライチェーン管理プログラムの一つとして、記録参照プログラムが格納されている。データ管理サーバ６０は、記録参照プログラムに基づく処理により、ユーザ端末１１０からの参照要求に応じて、ユーザ端末１１０へ送信する提供用データＰＤを生成する。データ管理サーバ６０は、ネットワークＮＷに接続されたユーザ端末１１０と連携し、記録照会処理（図８参照）を実施する。以下、記録照会処理に関連するデータ管理サーバ６０及びユーザ端末１１０の各機能の詳細を説明する。

データ管理サーバ６０は、プロセッサ６１による記録参照プログラムの実行に基づき、要求取得部８１、データ抽出部８２、データ検証部８３及びデータ提供部８４等の機能部を備える。

要求取得部８１は、要求送信部１２２より送信される参照要求と特定アイテムＩＭｓのアイテムデータとを取得する（Ｓ１８１参照）。データ抽出部８２は、ブロックチェーンＢＣを参照し、要求取得部８１にて取得されるアイテムデータに関連する取引記録ＲｅＴを特定する（Ｓ１８２参照）。データ抽出部８２は、ブロックチェーンＢＣにおいて、アイテムデータによりも時系列において過去側となる取引記録ＲｅＴを抽出する。

データ抽出部８２は、取引記録ＲｅＴのハッシュ値に紐づく本体データ、具体的には、取引者ＴＲ（製作所，ライン等）の名称、日時、アイテムの名称等の情報を取得する。データ抽出部８２は、タイムスタンプサーバ９０への提供要求により、日時情報を取得してもよい。データ抽出部８２は、ブロックチェーンＢＣにおけるハッシュ値のマークルツリーの態様に基づき、各本体データをツリー状に整理することで、提供用データＰＤを生成する（Ｓ１８４参照）。提供用データＰＤでは、後工程の取引記録ＲｅＴほど上位層に配置され、前工程の取引記録ＲｅＴほど下位層に配置される。

データ検証部８３は、データ検証処理により、データ抽出部８２によって抽出された取引記録ＲｅＴの改ざん可能性の有無を判定する（Ｓ１８３参照）。データ検証部８３は、マークルツリーの形状に従い、取引記録ＲｅＴとしてのハッシュ値を組み合わせて、マークルルートを算出する処理を繰り返す。データ検証部８３は、要求取得部８１にて取得されたアイテムデータとしてハッシュ値と、取引記録ＲｅＴから再演算したハッシュ値とが一致していた場合、全ての取引記録ＲｅＴに改ざんがないとみなす。一方、二つのハッシュ値が不一致であった場合、データ検証部８３は、取引記録ＲｅＴに改ざんの可能性があると推定する。

データ提供部８４は、データ検証部８３にて改ざん可能性が推定された場合、エラーを通知する値を、ユーザ端末１１０へ向けて送信する。一方で、データ検証部８３にて改ざんがないと判定された場合、データ提供部８４は、データ抽出部８２にて生成された提供用データＰＤを、要求元のユーザ端末１１０へ向けて送信する（Ｓ１８５参照）。

ユーザ端末１１０は、例えばスマートフォン、タブレット端末、及び専用端末等のコンピュータとしての機能を備えた電子機器である。ユーザ端末１１０は、例えば最終製品ＦＰ等の特定アイテムＩＭｓに添付されたアイテムコードＱＲｉを読み込み、その流通経路を示す過去の取引記録ＲｅＴを提示する。ユーザ端末１１０は、カメラ１１６及びディスプレイ１１７と、プロセッサ１１１、ＲＡＭ１１２、記憶部１１３、入出力インターフェース１１４、及びこれらを接続するバス等を備えた制御回路１２０とを備えている。

カメラ１１６は、納入アイテムＩＭｉ又は特定アイテムＩＭｓ等に付属するアイテムコードＱＲｉの撮像データを生成し、制御回路１２０に提供する。ディスプレイ１１７は、液晶パネル等の表示デバイスであり、種々の画像を画面に表示可能である。ディスプレイ１１７は、ユーザ操作を受け付けるタッチパネルの機能を有している。

プロセッサ１１１は、ＲＡＭ１１２と結合された演算処理のためのハードウェアである。記憶部１１３には、取引記録ＲｅＴの確認を可能にする取引記録表示プログラムが格納されている。取引記録表示プログラムは、ネットワークＮＷを通じて配信されるアプリケーションプログラム（以下、トレーサビリティ確認アプリ）である。トレーサビリティ確認アプリは、サイト情報が記録された二次元コードをカメラ１１６によって読み込む作業により、記憶部１１３にダウンロード可能である。

ディスプレイ１１７へのユーザ操作の入力により、トレーサビリティ確認アプリが起動されると、プロセッサ１１１は、ＲＡＭ１１２へのアクセスにより、取引記録ＲｅＴの追跡に関連する種々の処理を実行する。具体的に、制御回路１２０には、トレーサビリティ確認アプリに基づき、コード抽出部１２１、要求送信部１２２、データ受信部１２３及び表示制御部１２４等の機能部が構築される。

コード抽出部１２１は、アイテムコードＱＲｉを撮影した撮像データをカメラ１１６から取得する。コード抽出部１２１は、撮像データの解析により、アイテムコードＱＲｉに記録されたハッシュ値としてのアイテムデータを取得する（Ｓ１２１参照）。要求送信部１２２は、コード抽出部１２１によって取得されたアイテムデータを、取引記録ＲｅＴの参照要求と共に、データ管理サーバ６０に送信する（Ｓ１２２参照）。

データ受信部１２３は、要求送信部１２２による参照要求に基づき、データ管理サーバ６０によって返信される提供用データＰＤを受信する（Ｓ１２３参照）。提供用データＰＤには、特定アイテムＩＭｓに関連する取引記録ＲｅＴが含まれている。

表示制御部１２４は、ディスプレイ１１７による画面表示を制御する機能部である。表示制御部１２４は、データ受信部１２３にて受信された提供用データＰＤを用いて、表示用データを生成し（Ｓ１２４参照）、ディスプレイ１１７に取引記録ＲｅＴを表示させる（Ｓ１２５参照）。表示制御部１２４は、トレーサビリティ確認アプリに基づき、取引記録ＲｅＴの問合せ及び提示のためのＧＵＩ画面１３０（図９参照）を表示させる。表示制御部１２４は、ユーザの操作及びデータ管理サーバ６０との通信に基づき、ＧＵＩ画面１３０を遷移させる。

表示制御部１２４は、ユーザのタップ操作等によってトレーサビリティ確認アプリが起動されると、ＧＵＩ画面１３０として、立上げ画面を表示させる。立上げ画面には、コード認識領域１３１と、再読込みボタン１３２、問合わせボタン１３３及び終了ボタン１３４等の複数のタップアイコンが表示される。コード認識領域１３１は、カメラ１１６の撮像データを表示する表示領域である。コード認識領域１３１にアイテムコードＱＲｉが表示されるようにユーザ端末１１０が操作されると、コード抽出部１２１によるアイテムコードＱＲｉの認識が実施される。その結果、ＧＵＩ画面１３０は、立上げ画面からコード認識画面へと遷移する。

コード認識画面には、コード認識領域１３１及び各タップアイコンに加えて、コード情報表示領域１３５が表示される。コード情報表示領域１３５には、コード抽出部１２１によってアイテムコードＱＲｉから読み出された情報として、アイテムデータとしてのハッシュ値と、問合わせ先となるサーバのＩＰアドレス又はＵＲＬとが表示される。こうした状態下、問合わせボタン１３３のタップ操作が入力されると、ＧＵＩ画面１３０は、コード認識画面から通信中画面へと遷移する。

通信中画面では、「問合わせ中」等のメッセージが表示される。データ管理サーバ６０への問合せの結果、エラー通知を受信した場合、ＧＵＩ画面１３０は、通信中画面から異常時画面へと遷移する。異常時画面には、コード情報表示領域１３５、再読込みボタン１３２及び終了ボタン１３４に加えて、取得情報表示領域１３６が設けられている。異常時画面では、取得情報表示領域１３６に、「情報がありません。メーカーにお問合わせ下さい。」等のメッセージが表示される。

一方、データ管理サーバ６０への問合せの結果、提供用データＰＤを受信できた場合、ＧＵＩ画面１３０は、通信中画面からデータ表示画面へと遷移する。データ表示画面には、異常時画面と同様に、コード情報表示領域１３５、再読込みボタン１３２、終了ボタン１３４及び取得情報表示領域１３６が設けられている。データ表示画面では、取得情報表示領域１３６に、特定アイテムＩＭｓに関連する取引記録ＲｅＴが階層状に表示される。

詳記すると、取得情報表示領域１３６には、提供用データＰＤに含まれる多数の取引記録ＲｅＴのうちで、特定アイテムＩＭｓを出荷した取引者ＴＲの取引記録ＲｅＴのみが、まず表示される。こうした状態下、取得情報表示領域１３６内に表示された展開ボタン１３７に対するタップ操作がユーザによって実施されると、現在表示されている取引記録ＲｅＴの一つ前の工程の取引記録ＲｅＴが、さらに表示される。以上のように、ユーザは、展開ボタン１３７へのタップ操作の繰り返しにより、より深い階層の取引記録ＲｅＴ、換言すれば、より過去の取引記録ＲｅＴを閲覧することが可能になる。尚、多数の取引記録ＲｅＴが展開表示されると、取得情報表示領域１３６は、スクロール可能となる。

ここまで説明した第一実施形態では、複数の取引者ＴＲ間にて取り引きされるアイテムに、それまでの取り引き結果を反映したハッシュ値が付属する。以上によれば、アイテムに付属させるデータ量を抑えつつ、取引者ＴＲ間でのアイテムの取引記録ＲｅＴが、アイテムの流通に伴って改ざん困難に蓄積されていく。以上によれは、サプライチェーンＳＣの管理を適正に行うことが可能になる。

加えて第一実施形態のように、アイテムデータとしてハッシュ値を用いれば、アイテムコードＱＲｉに記録可能な情報量が例えば数１０キロバイト程度に制限されていても、当該アイテムコードＱＲｉの中にアイテムデータを記録しておくことができる。以上によれば、二次元コードの利点を活かし、新規に作成した出荷アイテムＩＭｏ固有のアイテムデータを、当該出荷アイテムＩＭｏに逐次添付させて、当該出荷アイテムＩＭｏと共に流通させることが容易となる。したがって、ハッシュ値を用いたサプライチェーンＳＣの管理の実現性が確保され得る。

また第一実施形態では、出荷アイテムＩＭｏに付属されるハッシュ値は、アイテムデータ及びカンパニーデータに加えて、納入アイテムＩＭｉが特定業者ＴＲｓのもとにあった日時に紐づくタイムスタンプデータに基づき、演算される。以上によれば、取引記録ＲｅＴには、取引された時間を示す時間情報が、改ざん困難に残り得る。故に、サプライチェーンＳＣの信頼性をいっそう高めることが可能になる。

さらに第一実施形態では、複数のタイムスタンプデータの示す日時の前後関係に基づき、取引者ＴＲ間で行われた取引の不正が検出される。以上によれば、例えば逆戻り等の不正が逐次検出可能となる。その結果、サプライチェーンＳＣの信頼性は、さらに向上し得る。

加えて第一実施形態のカンパニーデータは、個々の取引者ＴＲに認証者Ｃｅｒから与えられる固有の内容とされる。そして、ユーザ装置１０から提供されるカンパニーデータについて、正規のデータであるか否かが判定される。以上によれば、認証者Ｃｅｒの認定外の業者による製品、部品及び原材料ＭＡＴ等がサプライチェーンＳＣに混入する事態は、高い確実性をもって防止される。

また第一実施形態では、アイテムデータであるハッシュ値の演算に、位置データがさらに用いられる。以上によれば、原産地及び生産地に関連する不正が、高い確実性をもって検出可能となる。その結果、サプライチェーンＳＣの信頼性をいっそう高めることができる。

さらに第一実施形態では、ブロックチェーンＢＣにおけるＵＴＸＯの考え方を利用し、データ管理サーバ６０に送信されるアイテムデータの重複が検出される。具体的には、納入アイテムＩＭｉを用いて生産及び製造される出荷アイテムＩＭｏについて、数及び重量の点で不整合が生じる場合、こうした不整合は、ブロックチェーンＢＣの二重払い防止に関するＵＴＸＯの考えを用いることで検出可能になる。以上のように、出荷アイテムＩＭｏについて、未使用アイテムか否かを逐次管理する処理によれば、不正な材料及び製品を混在させることが実質不可能になる。したがって、サプライチェーンＳＣの信頼性は、いっそう向上し得る。

加えて第一実施形態では、特定アイテムＩＭｓに付属したアイテムデータを読み取ることにより、この特定アイテムＩＭｓに関連する取引記録ＲｅＴがデータ管理サーバ６０から取得できる。故に、アイテムに付属させるデータ量を抑えつつ、取引者ＴＲ間でのアイテムの取引記録が、ユーザ側から参照可能になる。

また第一実施形態では、取引記録ＲｅＴが特定アイテムＩＭｓの流通過程を反映した階層状に表示されるため、ユーザによる取引記録ＲｅＴの把握が容易となる。以上のような利便性の向上によれば、サプライチェーンＳＣの適切な管理が実現され易くなる。

さらに第一実施形態では、ユーザ端末１１０から送信される参照要求に基づき、蓄積された取引記録ＲｅＴの中から特定アイテムＩＭｓに関連する取引記録ＲｅＴが抽出される。そして、抽出された取引記録ＲｅＴに基づく提供用データＰＤが、ユーザ端末１１０に提供される。以上のように、データ管理サーバ６０にて、必要な取引記録ＲｅＴが整理されることによれば、ユーザは、参照したい取引記録ＲｅＴに容易にアクセス可能となる。

上記実施形態では、アイテムコードＱＲｉが「二次元コード」に相当し、カンパニーデータが「ノード識別データ」に相当し、特定業者ＴＲｓが「特定者」に相当する。また、ユーザ装置１０が「ユーザノード」に相当し、情報取得部２１が「取得部」に相当し、情報送信部２２が「送信部」に相当する。さらに、データ管理サーバ６０が「ホストノード」に相当し、サーバ装置６０ａ及び処理回路１０ａがそれぞれ「コンピュータ」に相当する。加えて、チェーン生成部７３が「演算部」に相当し、コード提供部７４が「提供部」に相当し、ユーザ端末１１０が「要求元」に相当する。

＜第一実施形態の適用例＞
第一実施形態によるサプライチェーン管理方法を、食パンを供給するサプライチェーンＳＣの取引記録ＲｅＴの管理に適用した適用例を、以下、図１０～図１２及び図８に基づき説明する。尚、図１２に示すチェーン生成処理は、図７に示すチェーン生成処理の変形例である。本適用例のチェーン生成処理では、データ管理サーバ６０がタイムスタンプサーバ９０からタイムスタンプを取得する。

サプライチェーンＳＣには、最終製品ＦＰである食パンの製造及び販売等に関わる多数の取引者ＴＲが含まれている。一例として、種生産者、小麦農家、小麦粉メーカー、パンメーカー及びコンビニエンスストア等が、食パンのサプライチェーンＳＣを構成する取引者ＴＲに該当し、食パンの物流経路を形成する（図１０参照）。

具体的に、食パンの物流経路では、（１）種生産者が小麦の種を小麦農家へ出荷し、（２）小麦農家は種から育った小麦を小麦粉メーカーへ出荷し、（３）小麦粉メーカーは小麦を加工してできた小麦粉をパンメーカーへ出荷する。さらに、（４）パンメーカーは小麦粉から製造した食パンをコンビニエンスストアへ出荷し、（５）コンビニエンスストアは調達してきた食パンを消費者へ販売する。そして、（６）消費者は購入した食パンの原材料ＭＡＴ、加工工程及び流通工程等を確認できる。

上記（１）の種生産者は、初期設定データに基づく基本情報コードＱＲｂを、予め準備する。基本情報コードＱＲｂの発行は、種生産者のユーザ装置１０及びデータ管理サーバ６０の連携による初期設定処理（図１１参照）によって実施される。初期設定処理において、ユーザ装置１０は、種の生産に必要な土地、設備、農薬及び肥料等の情報を、初期設定データとして取得する（Ｓ１０１参照）。ユーザ装置１０は、例えばテキストデータ等の読み込み、及び種生産者の作業員による手入力等により、初期設定データを準備する。ユーザ装置１０は、取得した初期設定データを、ネットワークを介してデータ管理サーバ６０に送信する（Ｓ１０２参照）。尚、土地の情報には、種生産者の住所及びＧＰＳ等の位置データ等が使用可能である。

データ管理サーバ６０は、ユーザ装置１０より送信される初期設定データを受信によって取得する（Ｓ１５１参照）。データ管理サーバ６０は、取得した初期設定データを所定のデータ形式でリスト化し（Ｓ１５２参照）、初期設定データのリストに紐づくハッシュ値を生成する（Ｓ１５３参照）。データ管理サーバ６０は、ハッシュ値から照合可能な状態で初期設定データのリストを保存する。加えてデータ管理サーバ６０は、生成したハッシュ値を、ブロックチェーンＢＣに組み込む（Ｓ１５４参照）。原材料ＭＡＴを供給する取引者ＴＲの初期設定データに基づくハッシュ値は、ブロックチェーンＢＣの最初のブロックに組み込まれる。データ管理サーバ６０は、ハッシュ値を記録した基本情報コードＱＲｂを生成し、種生産者のユーザ装置１０に送信する（Ｓ１５５参照）。

種生産者のユーザ装置１０は、データ管理サーバ６０より送信される基本情報コードＱＲｂを受信によって取得する（Ｓ１０３参照）。ユーザ装置１０は、受信した基本情報コードＱＲｂを、例えば印刷等によって紙媒体に出力する（Ｓ１０４参照）。以上により、種生産者のもとに、基本情報コードＱＲｂが準備される。

ここで、基本情報コードＱＲｂには、初期設定データに基づくハッシュ値以外の情報が記録されていてもよい。例えば、ブロックチェーンＢＣに登録された初期設定データ、即ち、種の生産に土地、設備、農薬及び肥料等の情報が、テキストデータ又は画像データ等の形式で、基本情報コードＱＲｂに記録されていてもよい。さらに、基本情報コードＱＲｂには、ハッシュ値に替えて、ブロックチェーンＢＣに登録された内容と同一の初期設定データが、テキストデータ又は画像データ等の形式で、直接記録されていてもよい。

種生産者が生産した種を出荷する場合、種生産者のユーザ装置１０、データ管理サーバ６０及びタイムスタンプサーバ９０の連携により、チェーン生成処理（図１２参照）が実施される。種生産者のユーザ装置１０は、認証者Ｃｅｒによって発行されたカンパニーコードＱＲｃと、事前に準備した基本情報コードＱＲｂとを順に読み取る（Ｓ１０１及びＳ１０２参照）。ユーザ装置１０は、読み取りにより取得した各コードのハッシュ値等を、今回の取引記録ＲｅＴとしてデータ管理サーバ６０へ向けて送信する（Ｓ１０４参照）。

尚、カンパニーデータ及び初期設定データの少なくとも一方は、ユーザ装置１０に予め登録されていてもよい。こうした形態では、ユーザ装置１０の記憶部１３（図２参照）から読み出された各データが、データ管理サーバ６０に送信される。

データ管理サーバ６０は、種生産者のユーザ装置１０より送信されるハッシュ値を受信し、取引記録ＲｅＴとして取得する（Ｓ１６１参照）。データ管理サーバ６０は、取引記録ＲｅＴの取得をトリガとして、タイムスタンプコードＱＲｔ（又はタイムスタンプデータ）の提供をタイムスタンプサーバ９０に要求する。データ管理サーバ６０は、当該要求に基づき提供されたタイムスタンプコードＱＲｔを取得する（Ｓ１６１ａ及びＳ１９３ａ参照）。

データ管理サーバ６０は、データ異常検証処理（Ｓ１６２及び図５参照）を実施する。原材料ＭＡＴを供給する取引者ＴＲから取得した取引記録ＲｅＴのデータ異常検証処理では、未使用のアイテムか否か及び時系列の整合等を確認する一部の処理（図５ Ｓ３４～Ｓ３４参照）が省略されてよい。データ管理サーバ６０は、各データについに異常がないことを確認すると、初期設定データ及びタイムスタンプデータ等の取引記録ＲｅＴに基づくブロックを、ブロックチェーンＢＣの最後に組み込む（Ｓ１６３参照）。

さらに、データ管理サーバ６０は、最後のブロックのハッシュ値を演算し（Ｓ１６４参照）、算出したハッシュ値を付属させる出荷アイテムＩＭｏを、未使用のアイテムとして記録する。データ管理サーバ６０は、算出したハッシュ値を記録したアイテムコードＱＲｉを、種生産者のユーザ装置１０へ向けて送信する（Ｓ１６５参照）。

種生産者のユーザ装置１０は、データ管理サーバ６０より送信されるアイテムコードＱＲｉを受信し（Ｓ１１５参照）、受信したアイテムコードＱＲｉを印刷等によって紙媒体に出力する（Ｓ１１６参照）。種生産者は、印刷されたアイテムコードＱＲｉを種のパッケージ等に添付し、小麦農家へ出荷する。

上記（２）の小麦農家では、調達した種のパッケージに添付されたアイテムコードＱＲｉ、及び認証者Ｃｅｒから小麦農家に発行されたカンパニーコードＱＲｃが、ユーザ装置１０によって読み取られる（Ｓ１０１及びＳ１０２参照）。小麦農家が初期設定データを登録している場合、ユーザ装置１０による基本情報コードＱＲｂの読み取りがさらに実施される。例えば小麦農家は、小麦を栽培する土地の情報をデータ管理サーバ６０に登録可能である。小麦農家のユーザ装置１０は、各コードから読み取った各ハッシュ値等をユーザ装置１０に送信する（Ｓ１０４参照）。

データ管理サーバ６０は、小麦農家のユーザ装置１０より送信されるハッシュ値等を、取引記録ＲｅＴとして取得する（Ｓ１６１参照）。さらに、データ管理サーバ６０は、ハッシュ値の取得日時を記録するためのタイムスタンプを、タイムスタンプサーバ９０から取得する（Ｓ１６１ａ及びＳ１９３ａ参照）。データ管理サーバ６０は、データ異常検証処理（Ｓ１６２及び図５参照）によって異常がないことを確認する。そして、データ管理サーバ６０は、アイテムデータ、初期設定データ及びタイムスタンプデータ等の取引記録ＲｅＴに基づくブロックを、ブロックチェーンＢＣの最後に組み込む（Ｓ１６３参照）。さらに、データ管理サーバ６０は、最後のブロックのハッシュ値を演算し（Ｓ１６４参照）、算出したハッシュ値を記録したアイテムコードＱＲｉを、小麦農家のユーザ装置１０へ向けて送信する（Ｓ１６５参照）。

小麦農家のユーザ装置１０は、データ管理サーバ６０より送信されるアイテムコードＱＲｉを受信し（Ｓ１１５参照）、受信したアイテムコードＱＲｉを印刷等によって紙媒体に出力する（Ｓ１１６参照）。小麦農家は、印刷されたアイテムコードＱＲｉを小麦のパッケージ等に添付し、小麦粉メーカーへ出荷する。

上記（３）の小麦粉メーカーでは、調達した小麦のパッケージに添付されたアイテムコードＱＲｉ、及び認証者Ｃｅｒから小麦粉メーカーに発行されたカンパニーコードＱＲｃが、ユーザ装置１０によって読み取られる（Ｓ１０１及びＳ１０２参照）。小麦粉メーカーが初期設定データを登録している場合、ユーザ装置１０による基本情報コードＱＲｂの読み取りがさらに実施される。例えば小麦粉メーカーは、小麦粉を生産する設備及び製法等の情報をデータ管理サーバ６０に登録可能である。小麦粉メーカーのユーザ装置１０は、各コードから読み取った各ハッシュ値等をユーザ装置１０に送信する（Ｓ１０４参照）。

データ管理サーバ６０は、小麦粉メーカーのユーザ装置１０より送信されるハッシュ値等を、取引記録ＲｅＴとして取得する（Ｓ１６１参照）。さらに、データ管理サーバ６０は、ハッシュ値の取得日時を記録するためのタイムスタンプを、タイムスタンプサーバ９０から取得する（Ｓ１６１ａ及びＳ１９３ａ参照）。データ管理サーバ６０は、データ異常検証処理（Ｓ１６２及び図５参照）によって異常がないことを確認する。そして、データ管理サーバ６０は、アイテムデータ、初期設定データ及びタイムスタンプデータ等の取引記録ＲｅＴに基づくブロックを、ブロックチェーンＢＣの最後に組み込む（Ｓ１６３参照）。さらに、データ管理サーバ６０は、最後のブロックのハッシュ値を演算し（Ｓ１６４参照）、算出したハッシュ値を記録したアイテムコードＱＲｉを、小麦粉メーカーのユーザ装置１０へ向けて送信する（Ｓ１６５参照）。

小麦粉メーカーのユーザ装置１０は、データ管理サーバ６０より送信されるアイテムコードＱＲｉを受信し（Ｓ１１５参照）、受信したアイテムコードＱＲｉを印刷等によって紙媒体に出力する（Ｓ１１６参照）。小麦粉メーカーは、印刷されたアイテムコードＱＲｉを小麦粉のパッケージ等に添付し、パンメーカーへ出荷する。

上記（４）のパンメーカーでは、認証者Ｃｅｒからパンメーカーに発行されたカンパニーコードＱＲｃが、ユーザ装置１０によって読み取られる（Ｓ１０１参照）。加えて、食パンの原料として調達した小麦粉、イースト菌、食塩、水及び砂糖の各パッケージに添付されたアイテムコードＱＲｉが、ユーザ装置１０によって順に読み取られる（Ｓ１０２参照）。パンメーカーが初期設定データを登録している場合、ユーザ装置１０による基本情報コードＱＲｂの読み取りがさらに実施される。例えばパンメーカーは、パンを生産する設備及び製法等の情報をデータ管理サーバ６０に登録可能である。パンメーカーのユーザ装置１０は、各コードから読み取った各ハッシュ値等をユーザ装置１０に送信する（Ｓ１０４参照）。

データ管理サーバ６０は、パンメーカーのユーザ装置１０より送信されるハッシュ値等を、取引記録ＲｅＴとして取得する（Ｓ１６１参照）。さらに、データ管理サーバ６０は、ハッシュ値の取得日時を記録するためのタイムスタンプを、タイムスタンプサーバ９０から取得する（Ｓ１６１ａ及びＳ１９３ａ参照）。データ管理サーバ６０は、データ異常検証処理（Ｓ１６２及び図５参照）によって異常がないことを確認する。そして、データ管理サーバ６０は、アイテムデータ、初期設定データ及びタイムスタンプデータ等の取引記録ＲｅＴに基づくブロックを、ブロックチェーンＢＣの最後に組み込む（Ｓ１６３参照）。

ここで、パンメーカーから取得する取引記録ＲｅＴには、上述のように、小麦粉、イースト菌、食塩、水及び砂糖といった複数の原料のアイテムデータが含まれている。その結果、データ管理サーバ６０では、各原料の取引記録ＲｅＴをそれぞれ蓄積する複数のブロックチェーンＢＣが、パンメーカーでの加工によって一つに纏められる。その結果、ブロックチェーンＢＣ（分散台帳）のデータ構造は、各ブロックが一対一の直鎖状に連結されるのではなく、複数のブロックが一つのブロックと連結する複数対一のツリー状又は放射状の態様を呈する。こうしたデータ構造により、一つのアイテムデータから、個々の原料の追跡が可能になり、ひいてはユーザへの流通過程の透明性及び検索の容易性の向上が実現される。

また、小麦粉は、食パン以外の食品、例えばうどん等の食材にも使用される。故に、アイテムデータとして生成された一つのハッシュ値の情報が、次工程にて、複数のアイテムに拡散することも考えられる。この場合、ブロックチェーンＢＣのデータ構造は、一対複数のツリー状又は放射状の態様を呈する。

データ管理サーバ６０は、複数の原料の取引記録ＲｅＴと結び付いた最後のブロックのハッシュ値を演算し（Ｓ１６４参照）、算出したハッシュ値を記録したアイテムコードＱＲｉを、パンメーカーのユーザ装置１０へ向けて送信する（Ｓ１６５参照）。

パンメーカーのユーザ装置１０は、データ管理サーバ６０より送信されるアイテムコードＱＲｉを受信し（Ｓ１１５参照）、受信したアイテムコードＱＲｉを印刷等によって紙媒体に出力する（Ｓ１１６参照）。パンメーカーは、印刷されたアイテムコードＱＲｉを食パンのパッケージ等に添付し、コンビニエンスストア等の小売店へ出荷する。

上記（５）のコンビニエンスストアでは、認証者Ｃｅｒからコンビニエンスストアに発行されたカンパニーコードＱＲｃ、及び調達した食パンのパッケージに添付されたアイテムコードＱＲｉがユーザ装置１０によって読み取られる（Ｓ１０１及びＳ１０２参照）。コンビニエンスストアが初期設定データを登録している場合、ユーザ装置１０による基本情報コードＱＲｂの読み取りがさらに実施される。例えばコンビニエンスストアは、店舗名等の情報をデータ管理サーバ６０に登録可能である。コンビニエンスストアのユーザ装置１０は、各コードから読み取った各ハッシュ値等をユーザ装置１０に送信する（Ｓ１０４参照）。

データ管理サーバ６０は、コンビニエンスストアのユーザ装置１０より送信されるハッシュ値等を、取引記録ＲｅＴとして取得する（Ｓ１６１参照）。さらに、データ管理サーバ６０は、ハッシュ値の取得日時を記録するためのタイムスタンプを、タイムスタンプサーバ９０から取得する（Ｓ１６１ａ及びＳ１９３ａ参照）。データ管理サーバ６０は、データ異常検証処理（Ｓ１６２及び図５参照）によって異常がないことを確認する。そして、データ管理サーバ６０は、アイテムデータ、初期設定データ及びタイムスタンプデータ等の取引記録ＲｅＴに基づくブロックを、ブロックチェーンＢＣの最後に組み込む（Ｓ１６３参照）。さらに、データ管理サーバ６０は、最後のブロックのハッシュ値を演算し（Ｓ１６４参照）、算出したハッシュ値を記録したアイテムコードＱＲｉを、コンビニエンスストアのユーザ装置１０へ向けて送信する（Ｓ１６５参照）。

コンビニエンスストアのユーザ装置１０は、データ管理サーバ６０より送信されるアイテムコードＱＲｉを受信し（Ｓ１１５参照）、受信したアイテムコードＱＲｉを印刷等によって紙媒体に出力する（Ｓ１１６参照）。コンビニエンスストアの店員は、印刷されたアイテムコードＱＲｉを食パンのパッケージ等に添付し、商品棚等に陳列する。以上により、食パンが消費者ＣＳＴに供給される。

上記（６）の消費者ＣＳＴは、トレーサビリティ確認アプリをユーザ端末１１０にインストールすることにより、食パンの取引記録ＲｅＴを照会可能になる。食パンの消費者ＣＳＴは、トレーサビリティ確認アプリを実行するユーザ端末１１０で、食パンに添付されたアイテムコードＱＲｉの読み取りを行う。その結果、ユーザ端末１１０は、アイテムコードＱＲｉに記録されたアイテムデータ（ハッシュ値）を取得し（図８ Ｓ１２１参照）、取得したアイテムデータを参照要求と共にデータ管理サーバ６０へ送信する（Ｓ１２２参照）。

データ管理サーバ６０は、ユーザ端末１１０より送信される参照要求と食パンのアイテムデータとを取得する（Ｓ１８１参照）。データ管理サーバ６０は、取得したアイテムデータと紐づくブロックチェーンＢＣと、当該ブロックチェーンＢＣに蓄積された取引記録ＲｅＴとを特定する（Ｓ１８２参照）。データ管理サーバ６０は、特定した取引記録ＲｅＴの検証したうえで（Ｓ１８３参照）、食パンの流通経路をツリー状に再現してなる提供用データＰＤを生成する（Ｓ１８４参照）。データ管理サーバ６０は、生成した提供用データＰＤを、要求元のユーザ端末１１０へ向けて送信する（Ｓ１８５参照）。

ユーザ端末１１０は、参照要求に基づく提供用データＰＤをデータ管理サーバ６０から受信すると（Ｓ１２３参照）、提供用データＰＤを用いて、表示用データを生成する（Ｓ１２４参照）。ユーザ端末１１０は、表示用データに基づき、ディスプレイ１１７の取得情報表示領域１３６（図９参照）に、食パンの流通過程で蓄積された取引記録ＲｅＴを表示させる（Ｓ１２５参照）。

ここまで説明した第一実施形態の適用例でも、取引結果を反映したハッシュ値をアイテムに添付する管理方法によれば、アイテムに添付するデータ量を抑えつつ、過去の取引記録ＲｅＴが、原材料ＭＡＴから最終製品ＦＰに至るまで改ざん困難に蓄積されていく。故に、サプライチェーンＳＣの管理を適正に行うことが可能になる。

また、上記の適用例では、原材料ＭＡＴ（小麦の種）から最終製品ＦＰ（食パン）が消費者ＣＳＴに届けられるまでの食パンの流通経路を具体例として説明したが、他のアイテムのサプライチェーンＳＣにも、第一実施形態に開示の管理方法が適用可能である。一例として、通信端末等のサプライチェーン、新車及び中古車についてのサプライチェーン、加工食品、食材、飲料、酒類、漁業水産及び食肉等についてのサプライチェーン、並びに医薬品についてのサプライチェーン等に、上述の管理方法が適用できる。

さらに、上述のサプライチェーン管理方法は、有体物のサプライチェーンＳＣに適用対象を限定されず、無体物のサプライチェーンＳＣにも適用可能である。具体的に、インターネットを介した電子商取引についてのサプライチェーン、手形等の有価証券の譲渡における受取人情報についてのサプライチェーン、及び建築材の調達から建築物の建設までについてのサプライチェーン等にも、上述の管理方法が適用できる。

また、役務のサプライチェーンＳＣであっても、ブロックチェーンＢＣを用いた管理が可能である。具体的には、役務の提供者及び享受者を予めコード化しておき、役務利用時又は役務提供時に当該コードを読み込むことで、役務の提供及び享受関係が取引記録ＲｅＴとして記録可能である。一例として、伝統工芸に関わる技術伝承の過程、言い替えれば、師弟関係の系譜や、特定資格に関わる知識及び技術の提供者及び享受者の関係等が、ブロックチェーンＢＣを用いて管理可能である。さらに、複数の職人による手仕事の積み重ねによって製作される伝統工芸品について、各工程を担う個々の職人が施した加工の履歴情報が、ブロックチェーンＢＣを用いて記録されてもよい。この場合、完成した工芸品の価値が恒久的に保証され得る。また、ＳＮＳ上でのバトンリレー等、口約束程度の繋がりが、ブロックチェーンＢＣによって記録されてもよい。

（第二実施形態）
図１３及び図１４に示す本開示の第二実施形態は、第一実施形態の変形例である。第二実施形態の記録生成プログラムに基づくチェーン生成処理（図１３参照）では、取引者ＴＲ毎のハッシュ値及びアイテムコードＱＲｉの発行が省略されている。加えて、記録参照プログラムに基づく記録照会処理（図１４参照）では、アイテムコードＱＲｉの発行時よりも後工程の取引記録ＲｅＴが、過去分の取引記録ＲｅＴと共に抽出される。以下、第二実施形態のチェーン生成処理及び記録照会処理について、第一実施形態と異なる点を中心に、図１等を参照しつつ説明する。

チェーン生成処理（図１３参照）において、データ管理サーバ６０は、特定業者ＴＲｓ（図１参照）からアイテムデータ及びカンパニーデータを取得すると（Ｓ１６１参照）、タイムスタンプデータをタイムスタンプサーバ９０から取得する（Ｓ１６１ａ参照）。データ管理サーバ６０は、アイテムデータが添付されたアイテムのサプライチェーンＳＣを管理するブロックチェーンＢＣを特定し、データ異常の検証処理（Ｓ１６２及び図５参照）を実施する。データ管理サーバ６０は、データに異常がないことを確認すると、アイテムデータ及びタイムスタンプデータ等の取引記録ＲｅＴに基づくブロックを、ブロックチェーンＢＣの最後に連結させる（Ｓ２６３参照）。これにより、特定業者ＴＲｓにおける今回の取引記録ＲｅＴ（例えば、加工情報）が、アイテムデータに関連付けて、ブロックチェーンＢＣに蓄積される。第二実施形態では、複数の取引者ＴＲにおける取引記録ＲｅＴが、一種類のアイテムデータに対して関連付けられた状態となる。

データ管理サーバ６０は、今回の取引記録ＲｅＴの登録を完了させると、アイテムデータの継続使用を許可する判断を行う。データ管理サーバ６０は、アイテムデータの送信元である特定業者ＴＲｓのユーザ装置１０に、アイテムデータの継続使用を許可する旨の許可通知を送信する（Ｓ２６４参照）。

特定業者ＴＲｓのユーザ装置１０は、データ管理サーバ６０より送信される許可通知を受信すると（Ｓ２１５参照）、納入アイテムＩＭｉに付属していたアイテムデータの継続使用を決定する（Ｓ２１６参照）。以上により、特定業者ＴＲｓでは、納入アイテムＩＭｉに添付されていたアイテムコードＱＲｉが、出荷アイテムＩＭｏに付属させるアイテムコードＱＲｉとして、そのまま利用される。この場合、ユーザ装置１０は、音声又は画面表示等のメッセージにより、継続使用を作業者に通知する。

ここで、ユーザ装置１０は、アイテムデータの継続使用を決定した場合でも、アイテムコードＱＲｉを使用し続けることが物理的に困難な場合、納入アイテムＩＭｉに添付されたものと同一のアイテムコードＱＲｉを再出力できる。一例として、納入アイテムＩＭｉに添付されていたアイテムコードＱＲｉが破損又は汚損しており、アイテムデータの読み取りに支障が生じると判断した場合、ユーザ装置１０は、出荷アイテムＩＭｏに貼り直すためのアイテムコードＱＲｉを印刷する。また、出荷アイテムＩＭｏのパッケージが納入アイテムＩＭｉのパッケージと異なる場合、ユーザ装置１０は、同一のアイテムデータを記録したアイテムコードＱＲｉを印刷可能である。

記録照会処理（図１４参照）において、データ管理サーバ６０は、ユーザ端末１１０より送信される参照要求とアイテムデータとを取得する（Ｓ２８１参照）。データ管理サーバ６０は、取得したアイテムデータが添付されたアイテムのブロックチェーンＢＣを特定する。データ管理サーバ６０は、ブロックチェーンＢＣに紐づく情報を参照し、取得したアイテムデータについて、複数の取引者ＴＲによる継続使用の有無を判定する（Ｓ２８２参照）。具体的に、データ管理サーバ６０は、取得したアイテムデータに、複数の取引者ＴＲの取引記録ＲｅＴが紐づけられている場合、このアイテムデータが継続使用されたと判定する。

データ管理サーバ６０は、取得したアイテムデータに関連する取引記録ＲｅＴを、ブロックチェーンＢＣを用いて管理された多数の取引記録ＲｅＴの中から抽出する（Ｓ２８３参照）。具体的に、データ管理サーバ６０は、アイテムデータが一つの取引者ＴＲの取引記録ＲｅＴのみに紐づいている場合、当該取引者ＴＲでの取引記録ＲｅＴと、この取引記録ＲｅＴよりも過去側（前工程）の取引記録ＲｅＴとを、提供対象に選定する。一方で、アイテムデータが複数の取引者ＴＲにて継続使用され、複数の取引者ＴＲの取引記録ＲｅＴに紐づいている場合、これら複数の取引者ＴＲにおける全ての取引記録ＲｅＴを、過去分の取引記録ＲｅＴと共に提供対象に選定する。

データ管理サーバ６０は、選定した取引記録ＲｅＴ等のデータ検証処理を実施し（Ｓ２８４参照）、抽出した取引記録ＲｅＴに基づく提供用データＰＤを生成する（Ｓ２８５参照）。そして、データ管理サーバ６０は、生成した提供用データＰＤを、参照要求の要求元であるユーザ端末１１０に提供する（Ｓ２８６参照）。ユーザ装置１０は、データ管理サーバ６０より送信された提供用データＰＤを取得すると、第一実施形態と同様に、アイテムに関連する取引記録ＲｅＴを表示させる（Ｓ１２３～Ｓ１２５参照）。

ここまで説明した第二実施形態では、出荷アイテムＩＭｏに付属されるアイテムデータは、複数の取引者ＴＲによって継続使用される。故に、流通過程が進んでも、アイテムデータのデータ量が増加し難い。一方で、ブロックチェーンＢＣには、複数の取引者ＴＲによる取引記録ＲｅＴが、継続使用された一つのアイテムデータに関連付けて蓄積される。以上によれば、アイテムに付属させるデータ量を抑えつつ、取引者ＴＲ間でのアイテムの取引記録ＲｅＴが、アイテムの流通に伴いブロックチェーンＢＣに改ざん困難に蓄積されていく。したがって、第二実施形態でも、サプライチェーンＳＣの管理を適切に行うことが可能になる。

加えて第二実施形態では、一つのアイテムデータに複数の取引者ＴＲの取引記録ＲｅＴが紐づけ可能となっている。そして、参照要求に対しては、アイテムデータを使用した複数の取引者ＴＲにおける各取引記録ＲｅＴが全て抽出され、これらの取引記録ＲｅＴが要求元に提供される。以上によれば、提供用データＰＤには、アイテムデータを最後に使用した取引者ＴＲの取引記録ＲｅＴ（例えば、加工情報等）が必ず含まれるようになる。したがって、納入アイテムＩＭｉに付属していたアイテムコードＱＲｉ（アイテムデータ）を出荷アイテムＩＭｏに継続使用しても、アイテムデータと共に受信する参照要求に対し、適切な取引記録ＲｅＴを提供することが可能になる。

詳細に説明すると、アイテムデータを継続使用した場合、特定業者ＴＲｓにて加工されたアイテムに添付されるアイテムデータ（ハッシュ値）には、特定業者ＴＲｓによって実施された加工の情報が反映されない。しかし、ブロックチェーンＢＣ上には、特定業者ＴＲｓによって実施された加工の情報が反映される。即ち、特定業者ＴＲｓから出荷される加工品の各原料、加工、生産者、加工者及び時刻等の情報は、ブロックチェーンＢＣに連鎖して記録される。故に、アイテム（例えば、ある工程の原料）に添付されたアイテムコードＱＲｉを読み取れば、当該アイテムコードＱＲｉが複数工程前に発行されたものであっても、直前の工程までの経緯を全て参照することが可能になる。

具体的に、複数の取引者ＴＲで加工の工程が進んでいくサプライチェーンＳＣであれば、各工程の加工物に添付するアイテムコードＱＲｉは、工程の起点となる最初の取引者ＴＲに発行されたアイテムコードＱＲｉのままであってよい。以上によれば、アイテムコードＱＲｉの発行の簡略化が可能になる。

この場合、継続使用される一種類のアイテムコードＱＲｉは、原料情報のみを反映した内容であり、加工情報を反映しない内容となる。しかし、サプライチェーンＳＣの取引者ＴＲがブロックチェーンＢＣにアクセスすれば、これまでの工程で実施された加工の詳細や使用された原料の情報等が取得可能である。故に、一種類のアイテムコードＱＲｉでもサプライチェーンＳＣの全て又は特定区間の管理が可能であり、且つ、原料及び加工工程のトレーサビリティも確保される。

一例として、食パンの供給に関わるサプライチェーンＳＣ（図１０参照）では、原料である小麦の情報を化体したアイテムコードＱＲｉ（アイテムデータ）が、一貫して利用される。そのためパンメーカーは、生産物である食パンに、小麦の情報を化体したアイテムコードＱＲｉを添付する。

この場合でも、ブロックチェーンＢＣには、小麦粉メーカー及びパンメーカー等の各加工情報が蓄積される。故に、パンメーカーは、小麦粉に添付されたアイテムコードＱＲｉを利用して、前工程までの加工履歴を参照できる。同様に、エンドユーザーとなる食パンの消費者ＣＳＴは、食パンに添付されたアイテムコードＱＲｉを利用して、パンメーカーでの加工情報等を参照できる。以上のように、小麦粉メーカーやパンメーカーでの加工情報が化体されたアイテムコードＱＲｉの発行は、省略可能になる。

（第三実施形態）
本開示の第三実施形態は、第一実施形態の別の変形例である。第三実施形態のサプライチェーン管理システム１００は、サプライチェーンＳＣを管理する別の管理システムとの併存を前提に設計されている。別の管理システムは、一例として、ブロックチェーンＢＣを用いない管理システム（以下、旧管理システム）である。

こうしたシステム構成に対応し、第三実施形態のアイテムコードＱＲｉは、旧管理システムで管理に使用される情報と、サプライチェーン管理システム１００で管理に使用される情報（アイテムデータ）とを併有している。詳記すると、アイテムコードＱＲｉとして用いられる二次元コードには、データを登録する領域が複数（二つ）規定されている。

一方の領域（以下、第一領域）には、旧管理システムにて使用される情報が記録されている。一例として、第一領域には、第一領域のフォーマット形式、データ数、データ本体、及び第一領域の終端記号が順に記録されている。他方の領域（以下、第二領域）には、サプライチェーン管理システム１００にて使用される情報が記録されている。一例として、第二領域には、第二領域のデータのフォーマット形式、データ数、データ本体、及び第二領域の終端記号が順に記録されている。

さらに、第二領域は、旧管理システムでは読み取ることができない秘匿領域となっている。これにより、第二領域に記録されたデータは、サプライチェーン管理システム１００のユーザ装置１０によってのみ、利用可能となる。一例として、アイテムコードＱＲｉの第二領域の反射率を変える等の加工により、旧管理システムの端末からの第二領域の秘匿化が実現されている。この場合、第二領域（秘匿領域）の反射率は、第一領域（公開領域）の反射率よりも低くされる。

以上のアイテムコードＱＲｉが流通アイテムに添付されれば、旧管理システムの端末は、当該システムのサーバにアイテムの情報をアップロードするとき、第一領域の情報だけを選択的にアイテムコードＱＲｉから読み取ることができる。言い替えれば、第二領域の情報を旧管理システムの端末に意図的に無視させることが可能になる。

一方、ユーザ装置１０のリーダ１７は、秘匿化された第二領域の部分を読み取ることができる。ユーザ装置１０は、第一領域から読み取った情報をソフトウェア的に無視し、第二領域から読み取ったアイテムデータを選択的にデータ管理サーバ６０に送信できる。

また、ユーザ装置１０は、二つのシステムの情報を併有するアイテムコードＱＲｉを出力（印刷）できるように構成されている。詳記すると、ユーザ装置１０は、画像形式、テキスト形式及びプログラムコード形式等、加工可能なフォーマットで生成されたアイテムデータを、データ管理サーバ６０から取得する。加えてユーザ装置１０は、旧管理システムにて使用される出力用データも、旧管理システムのサーバから取得する。ユーザ装置１０は、旧管理システムの出力用データ及びアイテムデータがそれぞれ第一領域及び第二領域に記録されたアイテムコードＱＲｉを生成し、当該アイテムコードＱＲｉをプリンタ１９によって印刷する。

尚、アイテムコードＱＲｉの印刷は、旧管理システムの端末によって実施されてもよい。この場合、ユーザ装置１０は、旧管理システムの端末が加工可能なフォーマットで、当該端末にアイテムデータを提供する。その結果、旧管理システムの端末は、二つのシステムで使用される管理情報を併有したアイテムコードＱＲｉを、発行機等から出力可能になる。

ここまで説明した第三実施形態でも、第一実施形態と同様の効果を奏し、二つのシステム用の情報を併有するアイテムコードＱＲｉの運用により、サプライチェーンＳＣの管理を適正に行うことが可能になる。

加えて第三実施形態では、第二領域の情報が、既存の旧管理システムの端末からは読み取りできない。故に、アイテムコードＱＲｉに二種類の情報を併有させたことに起因して、旧管理システムの端末又はユーザ装置１０による情報の読み取りの不具合が生じ難い。以上によれば、既存の旧管理システムに変更を加えることなく、サプライチェーン管理システム１００の運用を、旧管理システムと調和させつつ開始することが可能になる。したがって、既存の旧管理システムへの適合性を向上させたサプライチェーン管理システム１００が実現できる。

ここで、第一領域及び第二領域をそれぞれ割り当てる管理システムは、変更可能であってよい。一例として、サプライチェーン管理システム１００の運用が安定化した後、当該管理システム１００よりも新しい別の管理システム（以下、将来システム）を導入する場合が想定される。この場合、サプライチェーン管理システム１００のための情報（アイテムデータ）を第一領域に記録し、将来システムのための情報を第二領域に記録するよう、記録領域の割り当てが変更可能である。以上のように、管理システムの更新に合わせて、秘匿領域から公開領域に、情報の記録領域を順に移動させれば、円滑なシステム更新に寄与することができる。

ここまで説明した第三実施形態に関する技術的特徴として、さらに以下の付記を開示する。
（付記１）
複数の取引者（ＴＲ）を含んで構築されるサプライチェーン（ＳＣ）において各前記取引者間で取引されるアイテムに付属され、前記サプライチェーンを管理する複数の管理システムの読取器によって読み取られる情報コードであって、
第一の読取器によって読み取られ、第一の管理システムにて用いられる第一情報を記録した第一領域と、
第二の読取器によって読み取られ、第二の管理システムにて用いられる第二情報を記録した第二領域と、を含む情報コード。

上記（付記１）の情報コード（二次元コード、バーコード等）では、第二領域は、第一の読取器によって認識されない。第一領域には、第一の読取器に読み取りの終了を通知する終端記号が設けられている。第一の読取器の読み取り順において、第一領域の終端記号の後に、第二領域が配置されている。一方、第二の読取器は、第一領域に記録された第一情報を認識対象外とし、終端記号の後の第二領域を認識対象とする。

さらに、情報コードには、第一領域及び第二領域以外にも複数の記録領域（第三領域、第四領域・・・・）が設けられていてもよい。この場合、第三領域は、第三の管理システムにて用いられる第三情報を記録する。同様に、第四領域は、第四の管理システムにて用いられる第四情報を記録する。以上のように、アイテムの取引記録を扱う管理システムの数に合わせて、情報コードに複数の記録領域が設定可能である。その結果、情報コードの各記録領域は、管理システムの更新時にて新旧それぞれ専用の記録領域として機能したり、またアイテムを取り扱う複数の小売業者の管理システム専用の記録領域として機能したりできる。

（他の実施形態）
以上、本開示による複数の実施形態について説明したが、本開示は、上記実施形態に限定して解釈されるものではなく、本開示の要旨を逸脱しない範囲内において種々の実施形態及び組み合わせに適用することができる。

上記実施形態の変形例１では、ＲＦＩＤ（radio frequency identifier）の技術を利用し、アイテムデータの流通アイテムへの付属が実現されている。この変形例１では、流通アイテムに添付されるデータ記録媒体には、二次元コードを印刷した紙媒体に替えて、ＲＦＩＤタグが用いられる。ＲＦＩＤを利用する場合、ユーザ装置１０のリーダ１７は、近距離の無線通信により、ＲＦＩＤタグに記録されたアイテムデータを読み出し可能な構成とされる。加えてユーザ装置１０は、プリンタ１９に替えて、ＲＦＩＤタグに記録された情報を書き換え可能なライタを備える。

コード出力部２４は、コード受信部２３にてデータ管理サーバ６０より受信される新規のハッシュ値を、ライタを利用して、出荷アイテムＩＭｏに付属されたＲＦＩＤタグに記録する。このような処理が、上記実施形態にてアイテムコードＱＲｉを生成するデータ管理サーバ６０の処理（Ｓ１６５参照）に替えて、「ハッシュ値を少なくとも含んだアイテムデータを記録する」という処理のステップに相当する。

以上のようなＲＦＩＤの利用によれば、例えばＲＦＩＤタグが視認されない状態であっても、リーダ１７によるアイテムデータの遠隔での読み取りが可能になる。加えて、アイテムデータとしてのハッシュ値の上書きの繰り返しによれば、二次元コードの印刷及び貼り付け等の作業が省略され得る。

尚、サプライチェーンＳＣの一部で二次元コードが利用され、他の一部でＲＦＩＤタグが利用されてもよい。また、二次元コード及びＲＦＩＤタグの両方が、共にアイテムに添付されてもよい。さらに、二次元コード及びＲＦＩＤタグとは異なる記憶媒体が、ハッシュ値を記憶する媒体として、アイテムと共に流通してもよい。

さらに、二次元コード及びＲＦＩＤ以外の手段が、アイテムデータ（ハッシュ値）をアイテムに付属させるために利用可能である。具体的には、ラベル等に替えて、アイテム自体への焼き印、レーザー刻印、切削などの加工により、ハッシュ値を化体した情報が埋め込まれてもよい。また、生物的な方法や無機化学を利用した方法を用いてハッシュ値を記録する媒体等の利用が可能である。具体的には、ハッシュ値を化体したＤＮＡ情報、分子構造、元素割合等を利用し、生理的な影響をアイテムに与えないようにスプレーで塗布する方法、ハッシュ値を化体した成分情報をもつ金属材料をアイテムの一部に採用又は添付する方法等が、採用可能である。

上記実施形態に記載したように、アイテムコードＱＲｉ、基本情報コードＱＲｂ及びカンパニーコードＱＲｃをそれぞれ読み込み、これらのデータをブロックチェーンＢＣ上にアップロードする処理は、適宜省略可能である。具体的に、変形例２では、ユーザ装置１０の記憶部１３に、基本情報コードＱＲｂ及びカンパニーコードＱＲｃに記録されたハッシュ値等が予め登録されている。ユーザ装置１０は、納入アイテムの商品情報を化体したアイテムコードＱＲｉを読み取った際に、記憶部１３から読み出した各ハッシュ値をデータ管理サーバ６０に送信する。故に、リーダ１７によるカンパニーコードＱＲｃ等の読み取り作業を省略しても、カンパニーデータ（ハッシュ値）等は、アイテムデータと共にデータ管理サーバ６０に逐次通知される。以上によれば、取引記録ＲｅＴを残すための作業負荷が軽減可能になる。

上記第二実施形態の変形例３では、再利用可能な紙媒体にアイテムコードＱＲｉが印刷されている。そのため、納入アイテムＩＭｉと出荷アイテムＩＭｏとで異なるパッケージを使用する場合でも、納入アイテムＩＭｉから剥がしたアイテムコードＱＲｉを、出荷アイテムＩＭｏに貼り直し、物理的に同じアイテムコードＱＲｉを継続使用することが可能になる。さらに、アイテムコードＱＲｉを印刷する紙媒体は、転写機能をもった複数枚の用紙を重ねたものであってもよく、一部を切り取り可能に形成したものであってもよい。こうした紙媒体を用いれば、取引者間での流通に伴い紙媒体の一枚又は一部を剥がしながら、同一のアイテムコードＱＲｉが継続使用される。

尚、上記第二実施形態は、第一実施形態に対し、アイテムコードＱＲｉの発行を省略できるメリットがある。一方で、上記第一実施形態は、第二実施形態に対し、アイテムデータに対応する取引記録ＲｅＴの検索処理を少なくできるメリットがある。また、第一実施形態は、アイテムコードＱＲｉの物理的な損傷等に起因して、読み取りが難しくなるリスクを抑えるメリットをさらに有している。

上記第三実施形態にて説明したように、既存の旧管理システムが稼働している場合、ブロックチェーンＢＣを利用したサプライチェーン管理システム１００を新規で導入しようとすると、旧管理システムに大きな改修が必要となる。この場合、改修のための時間も必要となる。このことが、ブロックチェーンＢＣを用いたサプライチェーン管理システム１００の導入を困難にしていた。

そこで上記実施形態の変形例４では、サプライチェーン管理システム１００のアイテムコードＱＲｉが、旧管理システムの情報に併記又は上書きされて、アイテムと共に流通する。詳記すると、変形例４のユーザ装置１０は、アイテムコードＱＲｉを画像形式のデータとして、プリンタ１９等の発行機に送信し、紙媒体に出力する。印刷されたアイテムコードＱＲｉは、パッケージに添付又は上書きされる。このような方法であれば、新旧のシステムの適合性を問題にすることなく、ブロックチェーンによるトレーサビリティの管理を容易に行うことができる。

また、上述の例では、ブロックチェーンに記録された情報を二次元コードの画像形式でユーザ装置１０に送信した。しかし、アイテムデータは、画像形式ではなく、テキスト形式、プログラムコード形式など種々のデータフォーマットに従って、ユーザ装置１０又はプリンタ１９等の発行機に送信されてよい。

上記実施形態の変形例５では、マークルルートの算出に、タイムスタンプデータのハッシュ値は使用されない。また、上記実施形態の変形例６では、マークルルートの算出に、位置データに基づくハッシュ値は使用されない。以上のように、タイムスタンプデータ及び位置データは、データ受信時の異常検出のみに使用され、ブロックチェーンＢＣに組み込まれなくてもよい。さらに、タイムスタンプデータ及び位置データは、取得されなくてもよい。

上記実施形態の変形例７では、ユーザ装置１０によるタイムスタンプコードＱＲｔの読み取りが省略される。データ管理サーバ６０は、ユーザ装置１０から取引記録ＲｅＴを取得したことに基づき、タイムスタンプサーバ９０から、ハッシュ値としてのタイムスタンプデータを受信する。また、上記実施形態の変形例８では、ユーザ装置１０に送信されたタイムスタンプデータとしてのハッシュ値が、アイテムコードＱＲｉの送信に合わせて、アイテムデータと共にデータ管理サーバ６０に送信される。以上のように、タイムスタンプデータの自動取得によれば、取引者ＴＲにおけるコード読み取り作業の軽減が可能になる。

上記実施形態の変形例９では、チェーン生成処理におけるデータ異常検証処理（Ｓ１６２参照）が省略される。変形例９の記録検証部７２は、チェーン生成処理から独立して、取得された取引記録ＲｅＴに対するデータ異常検証処理を繰り返す。また上記実施形態の変形例７では、記録照会処理におけるデータ検証処理（Ｓ１８３参照）が省略される。変形例１０のデータ検証部８３は、記録照会処理から独立して、蓄積された取引記録ＲｅＴに対するデータ検証処理を繰り返す。

上記実施形態の変形例１１にて用いられるノード識別データ（カンパニーデータ）は、単なる会社名に基づいたハッシュ値であってもよい。又は、ユーザ装置１０に紐づく識別情報を利用して、データ管理サーバ６０にて、カンパニーデータとしてハッシュ値が生成されてもよい。以上のように、認証者Ｃｅｒが取引者ＴＲを認定したことを示すカンパニーコードＱＲｃの配布は、省略されてもよい。

上記実施形態の変形例１２のＧＵＩ画面１３０では、参照要求に対して返信された取引記録ＲｅＴが一覧で表示される。具体的に、変形例１２では、タイムスタンプデータに紐づく日時が新しい（又は古い）取引記録ＲｅＴから順に表示される。以上の変形例９のように、取引記録ＲｅＴの表示方法は、ツリー状（階層状）に限定されず、適宜変更されてよい。さらに、ユーザ端末１１０の種別に応じて、ＧＵＩ画面１３０は、適宜変更されてよい。

ユーザ端末１１０によって取引記録ＲｅＴを参照可能なアイテムは、最終製品ＦＰに限定されない。例えば、モジュールサプライヤが、納入アイテムＩＭｉに付属するアイテムコードＱＲｉを使用して、納入アイテムＩＭｉの取引記録ＲｅＴを参照してもよい。さらに、ユーザ装置１０に、納入アイテムＩＭｉの取引記録ＲｅＴを参照する機能が設けられていてもよい。

上述したように、取引者ＴＲは、製造業者に限定されない。例えば、上記実施形態の変形例１３では、最終製品ＦＰとしての車両がユーザに渡った後で、ディーラでの整備履歴及び部品交換の履歴等が、ディーラのユーザ装置１０からデータ管理サーバ６０に取引記録ＲｅＴとして送信される。データ管理サーバ６０は、車両製造の際に生成されたブロックチェーンに、新たな取引記録ＲｅＴに基づくブロックを接続する。データ管理サーバ６０は、最終ブロックのハッシュ値を記録したアイテムコードＱＲｉを生成し、ディーラのユーザ装置１０に送信する。このアイテムコードＱＲｉを車検証に添付していくシステムが運用されれば、最終製品ＦＰのメンテナンスを含めた信頼性の高いサプライチェーンＳＣの構築が可能になる。

さらに、上記実施形態の変形例１４では、車検業者、再販業者及びリサイクル業者が、取引者ＴＲに含まれている。各取引業者は、車検、再販及びリサイクル等のタイミングで、ハッシュ値の返信要求をデータ管理サーバ６０に送信する。データ管理サーバ６０では、製造及び使用の実績が保存されているブロックチェーンの最終ブロックを読み込み、当該最終ブロックのハッシュ値を演算する。各取引業者は、最終ブロックのハッシュ値が記録されたアイテムコードＱＲｉをユーザ装置１０によって出力し、車検証への印刷、或いは再販又はリサイクルの製品又は商品に添付する。以上の管理システムが運用されれば、製品又は商品の製造からリサイクルまで、信頼の高いサプライチェーンＳＣが構築される。

上記実施形態にて、最終製品ＦＰに添付されるアイテムコードＱＲｉは、通常のＱＲコードであった。対して、上記実施形態の変形例１５では、通常のＱＲコードよりなるアイテムコードＱＲｉに加えて、ＳＱＲＣよりなるアイテムコードＱＲｉがさらに添付される。ＳＱＲＣは、コピー防止機能を備えていてもよい。こうしたＱＲコードの併記によれば、スマートフォン等のユーザ端末１１０を利用した記録参照の容易性を確保しつつ、通常のＱＲコードの改ざんが疑われるケースでは、専用スキャナによるＳＱＲＣの読み取りにより、厳密な記録参照を行うことが可能になる。

上記実施形態では、本開示によるサプライチェーンＳＣの管理方法が、工業製品に適用された場合を主に説明した。こうした用途への適用によれば、児童の強制労働等よって採掘された原材料ＭＡＴ（例えばレアメタル等）のサプライチェーンＳＣからの排除が実現され得る。加えて、本開示のサプライチェーン管理方法によれば、ある情報が、ある時刻に存在していたことを、後々証明することが可能になる。故に、ブロックチェーンによって保存された情報は、公的な監査への利用にも好適となる。

さらに、サプライチェーンＳＣによって提供される最終製品ＦＰは、上述したように、工業製品に限定されない。例えば、最終製品ＦＰが農作物であれば、消費者ＣＳＴは、小売店の店頭で、最終製品ＦＰに添付されたアイテムコードＱＲｉから、生産地、生産者、検査項目及び検査機関等に関連する一連の履歴情報を纏めて参照可能になる。同様に、最終製品ＦＰが水産物であれば、消費者ＣＳＴは、最終製品ＦＰに添付されたアイテムコードＱＲｉから、原産国名、水域名、水揚げ港、水産業者、養殖地、養殖業者、検査項目及び検査機関等に関連する一連の履歴情報を纏めて参照可能になる。こうした用途への適用によれば、食品の安全性に対する消費者ＣＳＴの信頼向上や、フェアトレード製品であることの確実な立証等が可能になる。

上記実施形態にて、データ管理サーバ及びタイムスタンプサーバによって提供されていた各機能は、ソフトウェア及びそれを実行するハードウェア、ソフトウェアのみ、ハードウェアのみ、あるいはそれらの複合的な組合せによっても提供可能である。また同様に、ユーザ装置の処理回路及びユーザ端末の制御回路等によって提供されていた各機能も、ソフトウェア及びそれを実行するハードウェア、ソフトウェアのみ、ハードウェアのみ、あるいはそれらの複合的な組合せによっても提供可能である。こうした機能がハードウェアとしての電子回路によって提供される場合、各機能は、多数の論理回路を含むデジタル回路、又はアナログ回路によっても提供可能である。

上記実施形態の各プロセッサは、ＣＰＵ（Central Processing Unit）及びＧＰＵ（Graphics Processing Unit）等の演算コアを少なくとも一つ含む構成であってよい。さらに、プロセッサは、ＦＰＧＡ（Field-Programmable Gate Array）、ＮＰＵ（Neural network Processing Unit）及び他の専用機能を備えたＩＰコア等をさらに含む構成であってよい。

上記実施形態の各記憶部として採用され、本開示のサプライチェーン管理方法に関連した各プログラムを記憶する記憶媒体の形態は、適宜変更されてよい。例えば記憶媒体は、回路基板上に設けられた構成に限定されず、メモリカード等の形態で提供され、スロット部に挿入されて、コンピュータのバスに電気的に接続される構成であってよい。さらに、記憶媒体は、コンピュータへのプログラムのコピー基となる光学ディスク及びのハードディスクドライブ等であってもよい。

本開示に記載の制御部及びその手法は、コンピュータプログラムにより具体化された一つ乃至は複数の機能を実行するようにプログラムされたプロセッサを構成する専用コンピュータにより、実現されてもよい。あるいは、本開示に記載の装置及びその手法は、専用ハードウェア論理回路により、実現されてもよい。もしくは、本開示に記載の装置及びその手法は、コンピュータプログラムを実行するプロセッサと一つ以上のハードウェア論理回路との組み合わせにより構成された一つ以上の専用コンピュータにより、実現されてもよい。また、コンピュータプログラムは、コンピュータにより実行されるインストラクションとして、コンピュータ読み取り可能な非遷移有形記録媒体に記憶されていてもよい。
（付記１－１）
コンピュータ（１０ａ，６０ａ）によって実施され、複数の取引者（ＴＲ）を含んで構築されるサプライチェーン（ＳＣ）における各前記取引者間での取引記録（ＲｅＴ）を、ブロックチェーン（ＢＣ）を用いて管理するサプライチェーン管理方法であって、
少なくとも一つのプロセッサ（１１，６１）にて実行される処理に、
一つの前記取引者である特定者（ＴＲｓ）に納入された納入アイテム（ＩＭｉ）に付属するアイテムデータと、前記特定者に割り当てられたノード識別データとを取得し（Ｓ１６１）、
前記アイテムデータ及び前記ノード識別データに基づくハッシュ値を演算し（Ｓ１６３）、
前記特定者から別の前記取引者に出荷される出荷アイテム（ＩＭｏ）に付属させる前記アイテムデータとして、少なくとも前記ハッシュ値を前記特定者に提供する、
というステップを含むサプライチェーン管理方法。
（付記１－２）
前記出荷アイテムに添付させる二次元コード（ＱＲｉ）及びＲＦＩＤタグの少なくとも一方に、前記ハッシュ値を少なくとも含んだ前記アイテムデータを記録する（Ｓ１６５）、というステップをさらに含む付記１に記載のサプライチェーン管理方法。
（付記１－３）
データを取得するステップでは、前記納入アイテムが前記特定者のもとにあった日時に紐づくタイムスタンプデータをさらに取得し、
前記ハッシュ値を演算するステップでは、前記アイテムデータ及び前記ノード識別データに加えて、前記タイムスタンプデータに基づき、前記ハッシュ値を演算する付記１又は２に記載のサプライチェーン管理方法。
（付記１－４）
複数の前記タイムスタンプデータの示す前記日時の前後関係に基づき、前記取引者間の取引の不正の有無を判定する（Ｓ３５）、というステップをさらに含む付記３に記載のサプライチェーン管理方法。
（付記１－５）
前記ノード識別データは、個々の前記取引者に認証者（Ｃｅｒ）から与えられる固有の内容であり、
前記特定者から取得する前記ノード識別データが、前記認証者によって与えられた前記ノード識別データであるか否かを判定する（Ｓ３２）、というステップをさらに含む付記１～４のいずれか一項に記載のサプライチェーン管理方法。
（付記１－６）
データを取得するステップでは、前記アイテムデータが読み取られた場所を示す位置データをさらに取得し、
前記ハッシュ値を演算するステップでは、前記アイテムデータ及び前記ノード識別データに加えて、前記位置データに基づき、前記ハッシュ値を演算する付記１～５のいずれか一項に記載のサプライチェーン管理方法。
（付記１－７）
前記特定者より取得する前記アイテムデータが、別の前記取引者より既に取得した前記アイテムデータと重複するか否かを判定する（Ｓ３４）、というステップをさらに含む付記１～６のいずれか一項に記載のサプライチェーン管理方法。
（付記１－８）
前記取引記録の参照要求を前記アイテムデータと共に取得し（Ｓ１８１）、
前記アイテムデータに基づき、前記アイテムデータが付属された前記納入アイテムに関連する前記取引記録を、蓄積された多数の前記取引記録から抽出し（Ｓ１８２）、
抽出した前記取引記録に基づく提供用データ（ＰＤ）を、前記参照要求の要求元（１１０）に提供する（Ｓ１８５）、
というステップをさらに含む付記１～７のいずれか一項に記載のサプライチェーン管理方法。
（付記１－９）
サプライチェーン（ＳＣ）に含まれる複数の取引者（ＴＲ）間での取引記録（ＲｅＴ）を表示させる取引記録表示プログラムであって、
少なくとも一つのプロセッサ（１１１）に、
特定アイテム（ＩＭｓ）に付属するアイテムデータであって、前記特定アイテムの流通過程を反映したハッシュ値を少なくとも含むアイテムデータを読み取り（Ｓ１２１）、
当該特定アイテムに関連する前記取引記録の参照要求を、前記アイテムデータと共にホストノード（６０）へ送信し（Ｓ１２２）、
ブロックチェーン（ＢＣ）を用いて管理された前記取引記録であって、前記特定アイテムに関連する前記取引記録、に関する提供用データ（ＰＤ）を前記ホストノードから受信し（Ｓ１２３）、
前記提供用データに基づき、前記特定アイテムの流通過程を反映した階層状に前記取引記録を表示させる（Ｓ１２５）、
ことを含む処理を実施させる取引記録表示プログラム。
（付記１－１０）
複数の取引者（ＴＲ）を含んで構築されるサプライチェーン（ＳＣ）における各前記取引者間での取引記録（ＲｅＴ）を、ブロックチェーン（ＢＣ）を用いて管理するサプライチェーン管理プログラムであって、
少なくとも一つのプロセッサ（６１）に、
一つの前記取引者である特定者（ＴＲｓ）に納入された納入アイテム（ＩＭｉ）に付属するアイテムデータと、前記特定者に割り当てられたノード識別データとを取得し（Ｓ１６１）、
前記アイテムデータ及び前記ノード識別データに基づくハッシュ値を演算し（Ｓ１６３）、
前記特定者から別の前記取引者に出荷される出荷アイテム（ＩＭｏ）に付属させる前記アイテムデータとして、少なくとも前記ハッシュ値を前記特定者に提供する、
ことを含む処理を実施させるサプライチェーン管理プログラム。
（付記１－１１）
複数の取引者（ＴＲ）を含んで構築されるサプライチェーン（ＳＣ）における各前記取引者間での取引記録（ＲｅＴ）を、ブロックチェーン（ＢＣ）を用いて管理するサプライチェーン管理システムであって、
個々の前記取引者にて用いられるユーザノード（１０）と、
複数の前記ユーザノードと通信可能な少なくとも一つのホストノード（６０）とを含み、
一つの前記取引者である特定者（ＴＲｓ）が利用する前記ユーザノードは、
前記特定者に納入された納入アイテム（ＩＭｉ）に付属するアイテムデータと、前記特定者に割り当てられたノード識別データとを取得する取得部（２１）と、
前記取得部にて取得される前記アイテムデータ及び前記ノード識別データを、前記ホストノードに送信する送信部（２２）と、を有し、
前記ホストノードは、
前記ユーザノードから受信する前記アイテムデータ及び前記ノード識別データに基づくハッシュ値を演算する演算部（７３）と、
前記特定者から別の前記取引者に出荷される出荷アイテム（ＩＭｏ）に付属させる前記アイテムデータとして、少なくとも前記ハッシュ値を前記特定者に提供する提供部（７４）と、を有するサプライチェーン管理システム。
（付記１－１２）
コンピュータ（１０ａ）によって実施され、複数の取引者（ＴＲ）を含んで構築されるサプライチェーン（ＳＣ）における各前記取引者間での取引記録（ＲｅＴ）のデータ管理サーバ（６０）による管理を、ブロックチェーン（ＢＣ）を用いて実現するサプライチェーン管理方法であって、
少なくとも一つのプロセッサ（１１）にて実行される処理に、
一つの前記取引者である特定者（ＴＲｓ）に納入された納入アイテム（ＩＭｉ）に付属するアイテムデータを取得し（Ｓ１１２）、
前記アイテムデータを少なくとも含む前記特定者での前記取引記録を前記データ管理サーバへ向けて送信し（Ｓ１１４）、
少なくとも前記アイテムデータに基づき前記データ管理サーバにて演算されたハッシュ値を受信し（Ｓ１１５）、
前記ハッシュ値を少なくとも含むデータを、前記特定者から別の前記取引者に出荷される出荷アイテム（ＩＭｏ）に付属させる前記アイテムデータとする（Ｓ１１６）、
というステップを含むサプライチェーン管理方法。
（付記１－１３）
複数の取引者（ＴＲ）を含んで構築されるサプライチェーン（ＳＣ）における各前記取引者間での取引記録（ＲｅＴ）のデータ管理サーバ（６０）による管理を、ブロックチェーン（ＢＣ）を用いて実現するサプライチェーン管理プログラムであって、
少なくとも一つのプロセッサ（１１）に、
一つの前記取引者である特定者（ＴＲｓ）に納入された納入アイテム（ＩＭｉ）に付属するアイテムデータを取得し（Ｓ１１２）、
前記アイテムデータを少なくとも含む前記特定者での前記取引記録を前記データ管理サーバへ向けて送信し（Ｓ１１４）、
少なくとも前記アイテムデータに基づき前記データ管理サーバにて演算されたハッシュ値を受信し（Ｓ１１５）、
前記ハッシュ値を少なくとも含むデータを、前記特定者から別の前記取引者に出荷される出荷アイテム（ＩＭｏ）に付属させる前記アイテムデータとする（Ｓ１１６）、
ことを含む処理を実施させるサプライチェーン管理プログラム。

Claims (6)

1. コンピュータ（１０ａ，６０ａ）によって実施され、複数の取引者（ＴＲ）を含んで構築されるサプライチェーン（ＳＣ）における各前記取引者間での取引記録（ＲｅＴ）を、ブロックチェーン（ＢＣ）を用いて管理するサプライチェーン管理方法であって、
   少なくとも一つのプロセッサ（１１，６１）にて実行される処理に、
   一つの前記取引者である特定者（ＴＲｓ）に納入された納入アイテム（ＩＭｉ）に付属するアイテムデータと、前記特定者に割り当てられたノード識別データとを取得し（Ｓ１６１）、
   前記特定者における前記取引記録を前記アイテムデータに関連付けて蓄積し（Ｓ２６３）、
   前記納入アイテムに付属していた前記アイテムデータを、前記特定者から別の前記取引者に出荷される出荷アイテム（ＩＭｏ）に付属させる前記アイテムデータとして継続使用することを決定し（Ｓ２６４，Ｓ２１６）、
   前記取引記録の参照要求を前記アイテムデータと共に取得し（Ｓ２８１）、
   前記アイテムデータが複数の前記取引者にて継続使用されていた場合に、当該アイテムデータを使用した複数の前記取引者における各前記取引記録を、前記ブロックチェーンを用いて管理された多数の前記取引記録から抽出し（Ｓ２８３）、
   抽出した前記取引記録に基づく提供用データ（ＰＤ）を、前記参照要求の要求元（１１０）に提供する（Ｓ２８６）、
   というステップを含むサプライチェーン管理方法。
2. 複数の取引者（ＴＲ）を含んで構築されるサプライチェーン（ＳＣ）における各前記取引者間での取引記録（ＲｅＴ）を、ブロックチェーン（ＢＣ）を用いて管理するサプライチェーン管理プログラムであって、
   少なくとも一つのプロセッサ（１１，６１）に、
   一つの前記取引者である特定者（ＴＲｓ）に納入された納入アイテム（ＩＭｉ）に付属するアイテムデータと、前記特定者に割り当てられたノード識別データとを取得し（Ｓ１６１）、
   前記特定者における前記取引記録を前記アイテムデータに関連付けて蓄積し（Ｓ２６３）、
   前記納入アイテムに付属していた前記アイテムデータを、前記特定者から別の前記取引者に出荷される出荷アイテム（ＩＭｏ）に付属させる前記アイテムデータとして継続使用することを決定し（Ｓ２６４，Ｓ２１６）、
   前記取引記録の参照要求を前記アイテムデータと共に取得し（Ｓ２８１）、
   前記アイテムデータが複数の前記取引者にて継続使用されていた場合に、当該アイテムデータを使用した複数の前記取引者における各前記取引記録を、前記ブロックチェーンを用いて管理された多数の前記取引記録から抽出し（Ｓ２８３）、
   抽出した前記取引記録に基づく提供用データ（ＰＤ）を、前記参照要求の要求元（１１０）に提供する（Ｓ２８６）、
   ことを含む処理を実施させるサプライチェーン管理プログラム。
3. コンピュータ（１０ａ）によって実施され、サプライチェーン（ＳＣ）に含まれる複数の取引者（ＴＲ）の一つである特定者（ＴＲｓ）での取引記録（ＲｅＴ）を、ホストノード（６０）にアップロードする取引記録蓄積方法であって、
   少なくとも一つのプロセッサ（１１）にて実行される処理に、
   前記特定者に納入された納入アイテム（ＩＭｉ）に付属するアイテムデータと、前記特定者に割り当てられたノード識別データとを前記ホストノードへ向けて送信し（Ｓ１１４）、
   前記納入アイテムに付属していた前記アイテムデータを、前記特定者から別の前記取引者に出荷される出荷アイテム（ＩＭｏ）に付属させる前記アイテムデータとして継続使用する場合に、前記アイテムデータの継続使用を許可する旨の許可通知を、前記ホストノードから受信し（Ｓ２１５）、
   前記許可通知の受信に基づき、前記アイテムデータの継続利用を決定する（Ｓ２１６）、
   というステップを含む取引記録蓄積方法。
4. サプライチェーン（ＳＣ）に含まれる複数の取引者（ＴＲ）の一つである特定者（ＴＲｓ）での取引記録（ＲｅＴ）を、ホストノード（６０）にアップロードする取引記録蓄積プログラムであって、
   前記特定者に納入された納入アイテム（ＩＭｉ）に付属するアイテムデータと、前記特定者に割り当てられたノード識別データとを前記ホストノードへ向けて送信し（Ｓ１１４）、
   前記納入アイテムに付属していた前記アイテムデータを、前記特定者から別の前記取引者に出荷される出荷アイテム（ＩＭｏ）に付属させる前記アイテムデータとして継続使用する場合に、前記アイテムデータの継続使用を許可する旨の許可通知を、前記ホストノードから受信し（Ｓ２１５）、
   前記許可通知の受信に基づき、前記アイテムデータの継続利用を決定する（Ｓ２１６）、
   ことを含む処理を、少なくとも一つのプロセッサ（１１）に実施させる取引記録蓄積プログラム。
5. コンピュータ（１１０）によって実施され、サプライチェーン（ＳＣ）に含まれる複数の取引者（ＴＲ）間での取引記録（ＲｅＴ）を表示させる取引記録表示方法であって、
   少なくとも一つのプロセッサ（１１１）にて実行される処理に、
   前記取引記録の参照要求を、特定アイテム（ＩＭｓ）に付属するアイテムデータと共にホストノード（６０）へ送信し（Ｓ１２２）、
   ブロックチェーンを用いて管理された多数の前記取引記録から抽出された前記取引記録であって、前記アイテムデータに関連付けられた前記取引記録、に基づく提供用データ（ＰＤ）を、前記ホストノードから受信し（Ｓ１２３）、
   前記提供用データに基づき、前記特定アイテムの前記取引記録を表示させる（Ｓ１２５）、
   ことを含む処理を、少なくとも一つのプロセッサ（１１１）に実施させ、
   前記アイテムデータが複数の前記取引者にて継続使用されていた場合、前記提供用データには、当該アイテムデータを使用した複数の前記取引者における各前記取引記録が含まれる、取引記録表示方法。
6. サプライチェーン（ＳＣ）に含まれる複数の取引者（ＴＲ）間での取引記録（ＲｅＴ）を表示させる取引記録表示プログラムであって、
   前記取引記録の参照要求を、特定アイテム（ＩＭｓ）に付属するアイテムデータと共にホストノード（６０）へ送信し（Ｓ１２２）、
   ブロックチェーンを用いて管理された多数の前記取引記録から抽出された前記取引記録であって、前記アイテムデータに関連付けられた前記取引記録、に基づく提供用データ（ＰＤ）を、前記ホストノードから受信し（Ｓ１２３）、
   前記提供用データに基づき、前記特定アイテムの前記取引記録を表示させる（Ｓ１２５）、
   ことを含む処理を、少なくとも一つのプロセッサ（１１１）に実施させ、
   前記アイテムデータが複数の前記取引者にて継続使用されていた場合、前記提供用データには、当該アイテムデータを使用した複数の前記取引者における各前記取引記録が含まれる、取引記録表示プログラム。

Images