(57)【要約】      （修正有）【課題】ネットワーク（例えば異なるタイプの複数のデバイスからなるヘテロジニアスネットワーク）内のデバイスに関する情報を効率的かつ確実に追跡する方法を提供する。【解決手段】システム１００、１６０〜１６６において、情報は、１つまたは複数のセンサ／データソースから、所定の期間にわたって収集され、単一のトランザクションレコードにグループ化される。トランザクションレコードは、ゲートウェイからネットワーククラウドのサーバに、サイクルの所定のタイムスロット中に、システム内のゲートウェイおよびセンサの数に部分的に基づいて送られる。各トランザクションレコードは、情報が追跡されているシステム全体に関する直前のトランザクションレコードの一方向ハッシュおよび直前のトランザクションレコードへの参照を含む。【選択図】図１
2019009772.tif 000002
【特許請求の範囲】
【請求項１】
ネットワーク内の複数のデバイスに関する情報を追跡する方法であって、
第１ゲートウェイで、前記複数のデバイスのうちの１つのデバイスの状態を示す情報をそれぞれ含む複数の通信を受信することと、
前記第１ゲートウェイで、前記複数の通信のうちの２つ以上からの前記情報を、前記ネットワークに関する直前のトランザクションレコードのハッシュを含む単一のトランザクションレコードにグループ化することと、
前記単一のトランザクションレコードを前記第１ゲートウェイからサーバに送ることと、を含む、方法。
【請求項２】
前記トランザクションレコードは、ブロックチェーンのトランザクションブロックである、請求項１に記載の方法。
【請求項３】
前記サーバにトランザクションレコード送信要求を送信することと、
前記送信に応答して、前記直前のトランザクションレコードの前記ハッシュを受信することと、をさらに含み、前記単一のトランザクションレコードは、前記ハッシュの受信に応答して送られる、請求項１に記載の方法。
【請求項４】
前記情報をグループ化することは、前記複数の通信のうち、前記複数のデバイスのうちの１つのデバイスの状態の変化を表す通信からの情報のみをグループ化することを含む、請求項１に記載の方法。
【請求項５】
送ることは、既定のスケジュールに従い、前記単一のトランザクションレコードを送ることを含む、請求項１に記載の方法。
【請求項６】
前記既定のスケジュールに関する情報は、前記サーバに送られる前記トランザクションレコードに含まれる、請求項５に記載の方法。
【請求項７】
前記ネットワークは、前記第１ゲートウェイを含む複数のゲートウェイを含み、各ゲートウェイは、所与のサイクル内の所定のタイムスロット中に１つまたは複数のトランザクションレコードを送る、請求項５に記載の方法。
【請求項８】
前記複数のゲートウェイについて、前記サイクルを定めるスケジュールと、前記サイクル内の複数のタイムスロットとを維持することをさらに含む、請求項７に記載の方法。
【請求項９】
各タイムスロットについて、前記複数のデバイスのうちの１つのデバイスの変化した状態を示す情報のみを前記サーバに格納する、請求項７に記載の方法。
【請求項１０】
サイクルごとに１度、前記複数のゲートウェイから送られた前記１つまたは複数のトランザクションレコードに含まれる情報を、前記情報がデバイスの変化した状態を表すかどうかに関係なく、前記サーバに記録する、請求項９に記載の方法。
【請求項１１】
前記単一のトランザクションレコードは、情報の１つまたは複数の部分を含み、情報の各部分は、前記複数のデバイスのうちの１つのデバイスの前記状態を示す、前記第１ゲートウェイで受信された前記通信の１つに含まれる情報に対応し、前記１つまたは複数の部分のうちの少なくとも第１部分は、前記対応する物理デバイスのセキュリティクレデンシャルで暗号化された情報を含む、請求項１に記載の方法。
【請求項１２】
前記第１部分は、暗号化されていない情報を含む、請求項１１に記載の方法。
【請求項１３】
前記ゲートウェイは、前記単一のトランザクションレコードの少なくとも一部分を暗号化するために、トラステッドプラットフォームモジュールを含む、請求項１に記載の方法。
【請求項１４】
前記単一のトランザクションレコードは、レコード本体とレコードヘッダとを有し、前記レコード本体は、前記グループ化された情報を含み、前記レコードヘッダは、前記直前のトランザクションレコードの前記ハッシュを含む、請求項１に記載の方法。
【請求項１５】
前記単一のトランザクションレコードを前記ゲートウェイに格納することをさらに含む、請求項１に記載の方法。
【請求項１６】
前記レコードチェーンの１つまたは複数のトランザクションレコードを求める要求を前記サーバに送信することによって、前記ネットワーク上の１つまたは複数のデバイスの状態の変化を判断することをさらに含む、請求項１に記載の方法。
【請求項１７】
前記ネットワークは、前記第１ゲートウェイを含む複数のゲートウェイを含み、直前のトランザクションレコードを表すトランザクションレコードのヘッダを除き、前記第１ゲートウェイは、前記サーバに要求を送信することによって、前記複数のゲートウェイのうちの他のものが作成したトランザクションレコードのヘッダのみを受信する、請求項１に記載の方法。
【請求項１８】
前記複数の通信は、セキュアな通信チャネル上で受信され、前記単一のトランザクションレコードは、セキュアな通信チャネル上で送られる、請求項１に記載の方法。
【請求項１９】
前記単一のトランザクションレコードは、ＴＬＳを使用して前記単一のトランザクションレコードを暗号化する通信で送られる、請求項１に記載の方法。
【請求項２０】
前記単一のトランザクションレコードをレコードチェーンの一部として１つまたは複数の記憶媒体に格納する前記サーバをさらに含む、請求項１に記載の方法。
【請求項２１】
前記レコードチェーンは、前記ネットワーク上の前記複数のゲートウェイに対応するすべてのトランザクションのトランザクションレジスタを表す、請求項２０に記載の方法。
【請求項２２】
前記複数のデバイスのうちの１つのデバイスの状態を示すトランザクションレコードを、前記１つのデバイスまたは前記１つのデバイスに対応するセンサから、直接前記サーバに送ることをさらに含む、請求項１に記載の方法。
【請求項２３】
スマートコントラクトを実施するために、前記単一のトランザクションレコードを使用することをさらに含む、請求項１に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願の相互参照
本出願は、２０１７年６月２６日に出願された、「ブロック−チェーン（ＢＬＯＣＫ−ＣＨＡＩＮ）」と題する米国仮特許出願第６２／５２４，８０７号、および２０１８年２月２８日に出願された、「ネットワーク上でデバイスの情報を追跡するための、ブロックチェーンの使用（ＵＳＩＮＧ  ＢＬＯＣＫＣＨＡＩＮ  ＴＯ  ＴＲＡＣＫ  ＩＮＦＯＲＭＡＴＩＯＮ  ＦＯＲ  ＤＥＶＩＣＥＳ  ＯＮ  Ａ  ＮＥＴＷＯＲＫ）」と題する米国特許出願第１５／９０７，５００号に対する優先権を主張し、同出願を参照により本明細書に組み込む。
【０００２】
本出願は、デバイスの監視および管理の分野に向けられ、より具体的には、デバイスの情報の維持の分野に向けられる。
【背景技術】
【０００３】
製品「フード」チェーンは、その製造から、使用や保守を経て、その寿命に至るまでの製品／機械のライフサイクル中の多くの企業のために存在する。Ｓ−Ｉ−Ｐ−Ｄ−Ｕ−ＯまたはＳＩＰＤＵＯは、このようなフードチェーンのモデルの一例であり、サプライヤＳが、デバイスの一部（例えば、機械）をインテグレータＩに引き渡す。Ｉは、デバイスのサブシステムを統合して、生産者Ｐに引き渡す。Ｐは、デバイスを生産して、それをディーラーＤに販売する。ディーラーは、ユーザＵにデバイスを設置し、ユーザＵは、デバイスを操作する。ある場合には、数百台のデバイス、またはさらにそれ以上のデバイスからデータを収集するために、オペレータＯが必要である。しかし、ＳＩＰＤＵＯの当事者の１つまたは複数が、このデータの少なくともある部分を自身のものだと考える可能性がある。例えば、サプライヤＳは、サプライヤＳ自身のものだと考えるデータにアクセスしたいが、他の当事者のうちの１つまたは複数が、この試みをブロックする可能性がある。別の場合には、ユーザＵは、ユーザＵ自身にデバイスのすべてのデータの独占的な権利があることを望むか、または該権利があると考えることがある。あるいは、もしかすると、オペレータＯは、データを取り扱う責任があり、例えば、サービスレベル（ＳＬ）の目的または要件を満たすためにデータに関する統計値を望むが、それにアクセスできない可能性がある。
【０００４】
また、複数のサブコンポーネントを含むデバイス、例えば複数の部品を含む機械では、様々なサブコンポーネントの状態の確実な追跡、および／または管理が難しいことが多い。このように、状態情報を確実に追跡できないことから、その一部を成すデバイスのサブコンポーネントの性能問題もしくは故障の原因を判断すること、例えば、問題を引き起こした当事者および問題が引き起こされた時（例えば、製造中もしくは使用中）を判断することが難しくなることがある。デバイスの製造、輸送、設置および使用を通して情報を追跡しても、このような情報は将来の改ざんを受けやすいため、このような情報は、本質的に不確実なものになる。この不確実性は、デバイス内の問題の発生源の判断を難しくするだけでなく、デバイスの効果的な管理を一層難しくする。
【０００５】
したがって、異なる、しばしば無関係のサプライヤによってコンポーネントが提供され統合される場合に、システムのコンポーネントに関するデータを確実に追跡して維持するメカニズムを提供することが望ましい。また、当事者、例えば、製品フードチェーンの当事者が、例えばライセンスまたは販売の一環として、該データに関わるトランザクション、例えば該データの共有および／または取引に、非公式にまたは契約に基づいて、確実に参加できることも望ましい。
【発明の概要】
【０００６】
本明細書で説明するシステムによれば、ネットワーク内の複数のデバイスに関する情報を追跡することは、第１ゲートウェイで、複数のデバイスのうちの１つのデバイスの状態を示す情報をそれぞれ含む複数の通信を受信することと、第１ゲートウェイで、複数の通信のうちの２つ以上からの情報を、ネットワークに関する直前のトランザクションレコードのハッシュを含む単一のトランザクションレコードにグループ化することと、単一のトランザクションレコードを第１ゲートウェイからサーバに送ることと、を含む。トランザクションレコードは、ブロックチェーンのトランザクションブロックであってもよい。また、ネットワーク内の複数のデバイスに関する情報を追跡することは、サーバにトランザクションレコード送信要求を送信することと、送信に応答して、直前のトランザクションレコードのハッシュを受信することと、を含んでもよく、単一のトランザクションレコードは、ハッシュの受信に応答して送られる。情報をグループ化することは、また、複数の通信のうち、複数のデバイスのうちの１つのデバイスの状態の変化を表す通信からの情報のみをグループ化することを含んでもよい。送ることは、既定のスケジュールに従い、単一のトランザクションレコードを送ることを含んでもよい。既定のスケジュールに関する情報は、サーバに送られるトランザクションレコードに含んでもよい。ネットワークは、第１ゲートウェイを含む複数のゲートウェイを含んでもよく、各ゲートウェイは、所与のサイクル内の所定のタイムスロット中に１つまたは複数のトランザクションレコードを送ってもよい。また、ネットワーク内の複数のデバイスに関する情報を追跡することは、複数のゲートウェイについて、サイクルを定めるスケジュールと、サイクル内の複数のタイムスロットとを維持することを含んでもよい。各タイムスロットについて、複数のデバイスのうちの１つのデバイスの変化した状態を示す情報のみをサーバに格納してもよい。サイクルごとに１度、複数のゲートウェイから送られた１つまたは複数のトランザクションレコードに含まれる情報を、該情報がデバイスの変化した状態を表すかどうかに関係なく、サーバに記録してもよい。単一のトランザクションレコードは、情報の１つまたは複数の部分を含んでもよく、情報の各部分は、複数のデバイスのうちの１つのデバイスの状態を示す、第１ゲートウェイで受信された通信の１つに含まれる情報に対応し、１つまたは複数の部分のうちの少なくとも第１部分は、対応する物理デバイスのセキュリティクレデンシャルで暗号化された情報を含んでもよい。第１部分は、暗号化されていない情報を含んでもよい。ゲートウェイは、単一のトランザクションレコードの少なくとも一部分を暗号化するために、トラステッドプラットフォームモジュールを含んでもよい。単一のトランザクションレコードは、グループ化された情報を含むレコード本体と、直前のトランザクションレコードのハッシュを含むレコードヘッダとを有してもよい。ネットワーク内の複数のデバイスに関する情報を追跡することは、単一のトランザクションレコードをゲートウェイに格納することを含んでもよい。ネットワーク内の複数のデバイスに関する情報を追跡することは、レコードチェーンの１つまたは複数のトランザクションレコードを求める要求をサーバに送信することによって、ネットワーク上の１つまたは複数のデバイスの状態の変化を判断することも含んでもよい。ネットワークは、第１ゲートウェイを含む複数のゲートウェイを含んでもよく、直前のトランザクションレコードを表すトランザクションレコードのヘッダを除き、第１ゲートウェイは、サーバに要求を送信することによって、複数のゲートウェイのうちの他のものが作成したトランザクションレコードのヘッダのみを受信してもよい。複数の通信は、セキュアな通信チャネル上で受信してもよく、単一トランザクションレコードは、セキュアな通信チャネル上で送ってもよい。単一のトランザクションレコードは、ＴＬＳを使用して単一のトランザクションレコードを暗号化する通信で送ってもよい。ネットワーク内の複数のデバイスに関する情報を追跡することは、単一トランザクションレコードをレコードチェーンの一部として１つまたは複数の記憶媒体に格納するサーバも含んでもよい。レコードチェーンは、ネットワーク上の複数のゲートウェイに対応するすべてのトランザクションのトランザクションレジスタを表してもよい。ネットワーク内の複数のデバイスに関する情報を追跡することは、複数のデバイスのうちの１つのデバイスの状態を示すトランザクションレコードを、該１つのデバイスまたは該１つのデバイスに対応するセンサから、直接サーバに送ることも含んでもよい。ネットワーク内の複数のデバイスに関する情報を追跡することは、スマートコントラクトを実施するために、単一のトランザクションレコードを使用することも含んでもよい。
【図面の簡単な説明】
【０００７】
ここで、本明細書で説明するシステムの実施形態を、以下簡潔に説明する図面の図に従ってより詳細に説明していく。
【図１】本明細書で説明するシステムの実施形態に係る、ネットワーク上のデバイス情報を効率的かつ確実に追跡するシステムの一例を示すブロック図である。
【図２】本明細書で説明するシステムの実施形態に係る、システムのコンポーネントとフードチェーン内の当事者／役割との関係の一例を示す。
【図３】本明細書で説明するシステムの実施形態に係る、複数の通信からの情報をトランザクションレコードにグループ化する一例を示すブロック図である。
【図４】本明細書で説明するシステムの実施形態に係る、複数のトランザクションレコードの一例を示す。
【図５】本明細書で説明するシステムの実施形態に係る、複数のトランザクションレコードの一例を示す。
【図６】本明細書で説明するシステムの実施形態に係る、ネットワーク上でデバイス情報を効率的かつ確実に追跡する方法の一例を示すフローチャートである。
【図７】本明細書で説明するシステムの実施形態に係る、ネットワーク上でデバイス情報を効率的かつ確実に追跡するための、センサ、ゲートウェイおよびサーバ間の通信のシーケンスを示すシーケンス図である。
【図８】本明細書で説明するシステムの実施形態に係る、サーバへのトランザクションレコードの送信をスケジューリングするための、１サイクル内のタイムスロットの使用の一例を示す図である。
【図９】本明細書で説明する本発明の実施形態に係る、トランザクションレコードを含むメッセージの一例を示すブロック図である。
【発明を実施するための形態】
【０００８】
本明細書で説明するシステムは、ネットワーク、例えば異なる製造者／コンポーネントインテグレータから、例えば異なるタイプの複数のデバイスからなるヘテロジニアスネットワーク上で、デバイスに関する情報を効率的かつ確実に追跡するために使用してもよい。情報は、将来のアクセスおよび使用のために、情報の完全性を高い確度で確保する、計算効率のよいセキュアな態様で収集し格納してもよい。複数のサブコンポーネントを含むデバイス、例えば複数の部品を含む機械の場合、様々なサブコンポーネントの状態を確実に追跡できる能力は、サブコンポーネントまたはそれが一部を成すデバイスの性能問題または故障の原因の判断、例えば、問題を引き起こした当事者および当事者が問題を引き起こした時の判断に役立つ。デバイスのデータを確実に追跡できる能力は、デバイスの管理にも役立つ。
【０００９】
いくつかの実施形態では、情報は、１つまたは複数のセンサ／データソースから、例えば所定の期間にわたって収集してもよく、単一のトランザクションレコードにグループ化してもよい。トランザクションレコードは、ゲートウェイから、（例えば、ネットワーククラウド内に常駐する）サーバに送ってもよい。各トランザクションレコードは、情報が追跡されているシステム全体（例えば、ネットワーク）に関する直前のトランザクションレコードの一方向ハッシュ、および該直前のトランザクションレコードへの参照（例えば、リンクまたはポインタ）を含んでもよい。トランザクションレコードのハッシュは、トランザクションレコードに適用される算術関数、アルゴリズムまたは変換（以下、「ハッシュ関数」）の出力である。ハッシュ関数は、一定のサイズまたはサイズの範囲のデータ構造（例えば、ストリング）によって表すことのできるハッシュ値を生成するように構成してもよい。本明細書で説明するシステムのいくつかの実施形態では、ハッシュは、ハッシュ値を生成したハッシュ関数（以下、「暗号学的ハッシュ関数」）を反転することが実行不可能な一方向ハッシュである。一方向ハッシュを次の（つまり、現在の）トランザクションレコードの一部にすることで、改変されたトランザクションレコードから生成された一方向ハッシュはチェーン内の次のトランザクションに格納されるものと一致しないので、直前のレコードが改変されたかどうかを判断してもよい。さらに、本明細書で説明するシステムの実施形態において、各トランザクションレコードは、直前のトランザクションレコードの一方向ハッシュ、および該直前のトランザクションレコードへの参照（例えば、リンクまたはポインタ）を含み、継続的に増大するレコードの時系列リスト（本明細書でレコードチェーンと呼ばれる）を形成する。レコードチェーン内のトランザクションレコードを改変することは、ソースの改変されたレコードを判断することができるように、予想される将来のすべてのトランザクションレコードの一方向ハッシュを変えるカスケード効果をもつ。このように、一方向ハッシュ関数を使用することで、本明細書で説明する他の特徴と合わせて、システム内のデバイス情報を確実に追跡することが可能になる。例えば、ＭＤ４、ＭＤ５、ＳＨＡ−１およびＳＨＡ−２といった、多様な暗号学的ハッシュ関数のうちのいずれを使用してもよい。
【００１０】
いくつかの実施形態においては、レコードチェーンは、ブロックチェーンを使用して実施することができ、レコードチェーンの各トランザクションレコードは、ブロックチェーン（ブロック−チェーンまたはブロック・チェーンとしても知られる）のトランザクションブロックを使用して実施される。ブロックチェーンは、ブロックと呼ばれる、継続的に増大するレコードのリストであり、これをリンクさせて、暗号法を使用して安全にする。各ブロックは、トランザクションデータまたは情報を含み、前のブロック（すなわち、チェーン内の直前のブロック）へのリンクとしてのハッシュポインタと、タイムスタンプとを含んでもよい。設計上、ブロックチェーンは、データの変更に対して本質的に耐性がある。ブロックチェーンは、２当事者間のトランザクションを効率的かつ検証可能で恒久的な方法で記録することのできる、オープンな分散型台帳である。分散型台帳として使用するために、ブロックチェーンは、新しいブロックの妥当性検証をするためのプロトコルに集合的に従うピアツーピアネットワークによって管理してもよい。一旦記録されると、所与のブロック内のデータは、後続のすべてのブロックの改変なしには遡及的に改変することはできず、それには、ネットワークの大部分が共謀する必要がある。ブロックチェーンは、設計上セキュアと見なしてもよく、高いビザンチンフォールトトレランス性を有する分散型コンピューティングシステムの一例と見なしてもよい。本明細書で説明するシステムの様々な実施形態はブロックチェーンを使用するが、本発明はそのように制限されるわけではない。その手法がデータの変更に本質的に耐性があり、データブロック間の時間的関係を保つ検証可能で恒久的な方法でデータを記録でき、例えばチェーン内の任意のブロックの削除／除去を検出できる場合、本明細書のトランザクションを記録するために、またはレコードチェーンを実施するために、他の適切な手法を採用してもよい。一旦データが任意のブロックに記録されると、当該データは、そのブロック−チェーン内の後続のすべてのブロックの改変なしには遡及的に改変することはできない。特に具体的に別様に述べていない限り、本明細書において、「データ」という用語と「情報」という用語は交換可能に使用される。
【００１１】
トランザクションレコードに記録される情報には、デバイスに対応するフードチェーン内の様々な当事者、例えば、サプライヤ、インテグレータ、生産者、ディーラー、ユーザおよびオペレータに固有の情報、またはこれらが所有する情報を含んでもよい。トランザクションレコード内の情報は、デバイスに固有の秘密鍵を使用して暗号化することのできる非公開データを含んでもよく、暗号化されていない公開データを含んでもよい。公開データも、該データの値を保護して、例えばスマートコントラクトの一部として、データの取引を可能にするために、暗号化してもよい。公開データと非公開データとの区別は、程度の問題であろう。例えば、公開データおよび非公開データの両方が、ある当事者の専有のものであるかもしれないが、非公開データは、よりセンシティブ（例えば、むしろ秘密）であると見なされ、したがってそのように保護される。例えば、公開データは、製品または製品の一部に関連する基本仕様であってよく、当事者が任意の顧客または見込み客と共有するつもりがあるデータであるのに対し、非公開データは、例えば支払またはライセンス料について、当事者が技術パートナーまたは事業パートナーとのみ共有するつもりのデータである。したがって、公開データは、全く暗号化することなく、トランザクションレコードへのアクセスが与えられた任意の当事者による該公開データへのアクセスを可能にするか、または非公開データとは異なるクレデンシャル（例えば、鍵）を使用して暗号化して、当事者が非公開データへのアクセスを可能にするときにさらに選択的になれるように、すなわち一定の契約の当事者にのみ非公開データに関連するクレデンシャルを与えるようにしてもよい。暗号化したデータは、公開か非公開かに関係なく、対称暗号方式を採用する場合には秘密鍵に対応する鍵、例えば秘密鍵自体、または非対称公開鍵暗号方式を採用する場合には対応する公開鍵、を有する当事者によってのみアクセス可能である。このように、デバイスに対応する情報を所有する当事者は、より詳細に以下で説明するように、例えばスマートコントラクトに従い、情報のある部分を公開にして、他の部分は、選ばれた当事者にのみのプライベートなものにしてもよい。
【００１２】
本明細書で説明するシステムのいくつかの実施形態では、ゲートウェイは、各デバイスに関する現在の状態情報を、各トランザクションレコードの一部としてサーバに送る（例えば、送信する）ようにしてよく、他の実施形態では、ゲートウェイは、ゲートウェイからサーバに送られた最後のトランザクションレコード以降に変更された状態情報のみを送り、それによってネットワークリソースの消費量を削減する。さらに、いくつかの実施形態では、トランザクションサイクルの割り当てスロット中にシステムの各ゲートウェイがサーバにトランザクションレコードを送信する、サイクル／スロットスケジュールが実施される。そのような実施形態では、ゲートウェイから各タイムスロット中にトランザクションレコードに受信した変更情報のみをサーバに格納することができ、サイクルごとに１度、サイクル中に受信したすべてのトランザクション情報、すなわち、タイムスロット中に受信した累積トランザクション情報、をサーバに記録してもよい。システムに関するすべての完全なトランザクション情報をサイクルに１度のみ格納し、サイクルを通して各トランザクションの変更情報のみを格納することで、ネットワークリソース、特にストレージリソースを節約してもよい。
【００１３】
いくつかの実施形態においては、トランザクションレコードをサーバに送る前に、ゲートウェイは、トランザクション送信要求をサーバに送信し、サーバからの応答を受信した後でのみ、トランザクションレコードをサーバに送ってもよい。応答は、レコードチェーンの直前のレコードのハッシュを含んでもよい。いくつかの実施形態においては、直前のレコードのハッシュの他には、ゲートウェイは、要求をサーバに送信することにより、システム全体の他のトランザクションレコード（例えば、ブロックチェーンのブロック）に関する情報のみを受信する。これは、トランザクションがゲートウェイからサーバに送られるたびにシステムの各ゲートウェイに更新が送られる実施形態とは対照的である。ブロックチェーンの送付／送信要求に応答して直前のブロックのハッシュを受信することにより、前述の更新を各ゲートウェイに送る必要なく、レコードチェーンシステムの完全性を維持することができ、それによっていくつかの実施形態では大幅に、ネットワークリソースの消費量が削減される。
【００１４】
いくつかの実施形態においては、各トランザクションレコードは、本体とヘッダとを含む。本体は、デバイスから得た情報、例えば、本明細書の他の箇所でより詳細に説明する非公開および／または公開情報を含んでもよい。ヘッダは、レコードチェーンの直前のトランザクションレコードのハッシュを含むことができ、該直前のトランザクションレコードへの参照（例えば、ポインタまたはリンク）を有することができ、これをハッシュ自体の一部として提供してもよい。ヘッダは、より詳細に以下で説明するように、現在のトランザクションレコード自体のハッシュ、タイムスタンプおよび／またはスケジュール情報も含んでもよい。
【００１５】
本明細書で説明するシステムのいくつかの実施形態において、システム（サーバおよび／またはゲートウェイによって定義される）の複数のゲートウェイの各ゲートウェイは、トランザクションレコードと、おそらくは他の情報も、所定のスケジュールに従って送る。例えば、各ゲートウェイにはタイムサイクル内の所定のタイムスロットを割り当てることができ、その間に、ゲートウェイは、ブロックと、おそらくは他の情報もサーバに送ってもよい。タイムサイクルとは、システム内のすべてのゲートウェイに関する情報が処理される時間的な周期であり、すなわち、システム内のあらゆるゲートウェイに関するトランザクションレコードがサーバに送信される時間的な周期である。各タイムスロットの時間の長さは、他の因子の中でも特に、ゲートウェイに連結されているデバイスの数、または送信されるデータ量の関数としてもよい。いくつかの実施形態においては、システムのゲートウェイの中のいずれかのゲートウェイに必要な最長の時間に基づいて、どのタイムスロットの長さも同じに既定され、各ゲートウェイのトランザクションレコードをその割り当てタイムスロット中に処理するのに十分な時間を確保するようにする。そして、サイクルの長さも同様に、ゲートウェイの数、ユーザ発信情報要求の予想頻度、そして、おそらくは他の因子の関数としてもよい。サイクル時間の長さは、ユーザ要求の頻度と各ユーザ要求を処理するための時間量とを考慮して、システムのすべてのゲートウェイのトランザクションを処理するだけの十分な時間を確保するように設定してもよい。一実施形態において、システムは、各ユーザ要求をタイムスロットの継続時間内に処理するように構成してもよい。各ゲートウェイは、サイクル内のゲートウェイのタイムスロットに基づいて、トランザクションレコードの送信プロセス（本明細書においてより詳細に説明されるように、トランザクション送信要求の送信で始めてもよい）を開始するべき時を判断するために、タイマー機能を設けて構成してもよい。ゲートウェイは、より詳細に以下で説明するように、各トランザクションレコードに、例えば、トランザクションレコードのヘッダ内に、所定のスケジュールに関する情報を含んでもよい。
【００１６】
トランザクションチェーンは、本明細書で説明するように、継続的に更新されるトランザクションチェーンの一部として、クラウドでサーバに格納してもよい。トランザクションチェーンは、トランザクションをシステム内に効率的かつ検証可能で恒久的な方法で記録するレジスタとして機能してもよい。システムの当事者のいずれも、デバイスに関する情報を収集し、他者と情報の部分を公開または非公開として共有し、システムのデバイスに関する他者の公開および非公開情報にアクセスしてもよい。
【００１７】
トランザクションチェーンは、システム内のデバイスの監査証跡として機能してもよい。例えば、工場に設置された機械は、いくつかの部品を含んでもよく、これらの部品自体の多くが他の部品から構成してもよい。製造、輸送、設置および使用を含む機械のライフサイクル中に、いくつかの異なる当事者（サプライヤ、インテグレータ、ディーラーなど）が各部品に関わった可能性がある。各部品のライフサイクルを通して、各部品の状態を、本明細書で説明するシステムおよび方法論を用いて、監視し、確実に追跡してもよい。部品の追加、撤去および交換も同様にトランザクションチェーンを使用して追跡してもよい。いずれかの情報の変更（および不正な変更）の源泉およびタイミングが確実に判断できるように情報の完全性が維持されるので、トランザクションチェーンが提供する追跡は確実であると見なしてもよい。
【００１８】
トランザクションチェーンの確実性は、トラステッドプラットフォームモジュール暗号チップ（ＴＰＭ）を使用して高めてもよく、これは、ドイツの連邦情報技術安全局（ＳＩ）などのセキュリティ機関のコモンクライテリア評価に従って国家当局が認証してもよい。そのようなＴＰＭは、例えば、図１に関連して以下説明するように、様々なデバイスの内部で使用してもよい。トランザクションチェーンの確実性は、例えば図８に関連して以下説明するように、例えば所定のサイクル／スロット構造を使用して分散型アーキテクチャを実装することにより、また、例えば図７に関連して説明するように、トランザクションチェーンの分散・非集中型コンピューティングをサポートする情報交換パターンを使用することにより、高めてもよい。
【００１９】
さらに、機械もしくはそのサブコンポーネントがその後売却されるか、リースされるか、またはその他の形で契約取引の一部となる場合、トランザクションチェーンを当事者間の契約取引の一部として使用してもよい。例えば、購入またはリースは、機械のトランザクションチェーンへのアクセス権および／または該トランザクションチェーンの支配権を売主が買主に提供することを含んでもよい。取引時点から先、買主は、トランザクションチェーンを拡大し続け、後日、将来の買主などにチェーンへのアクセス権または該チェーンの支配権を提供してもよい。いくつかの実施形態では、本明細書で説明するように、トランザクションチェーン（例えば、ブロックチェーン）を使用して、契約取引自体を実施する。すなわち、トランザクションチェーンは、契約のルール（すなわち、条件）（支払条件、情報へのアクセス、タイミング等を含む）を定め、契約のルールを施行し、契約および／または契約に基づくトランザクションの実行をトランザクションチェーンのトランザクションレコードとして記録することにより、当事者間の「スマートコントラクト」を実施するために使用してもよい。例えば、トランザクションチェーンは、本明細書で説明するように、デバイス、またはそのサブコンポーネント（例えば、部品）からなるシステムに関わるライセンススキーム（例えば、１回限りの料金、分割払い、利用回数制料金等）を定め、このような契約に基づくトランザクションを、トランザクションチェーンのトランザクションレコードとして記録してもよい。ある場合には、スマートコントラクトは、システムまたはそのサブコンポーネントに関係する情報の交換についてのルールを定めてもよい。
【００２０】
そのようなスマートコントラクトは、本明細書で説明するように公開および非公開データ／情報の交換を規定するルールを定め、それに関係するトランザクションの結果を記録してもよい。例えば、スマートコントラクトは、第１の当事者、例えばインテグレータが、特定のシステムもしくはその一部に関するインテグレータの公開もしくは非公開情報と引き換えに、またはおそらくは通貨、例えばビットコインもしくは別の資産と引き換えに、サプライヤの公開もしくは非公開情報、例えば、特定のシステムもしくはその一部に関する専有の仕様へのアクセスを許されるルールを定めてもよい。専有情報には、例えば、内部設計、専有インタフェース、ベンチマーキングの結果、他の試験データ、製造信頼性データ、顧客リスト、価格リスト、ソースコード等を含んでもよい。スマートコントラクトは、例えば当事者が行う支払、行為の履行に対して、または何らかの他の形態の対価と引き換えに、契約の当事者に、暗号化された公開もしくは非公開情報へのアクセス権を与える１つもしくは複数の鍵（例えば、秘密および／もしくは公開暗号鍵）または他のクレデンシャルを提供するように定めてもよい。
【００２１】
図１は、本明細書で説明するシステムのいくつかの実施形態に係る、ネットワーク上でデバイス情報を効率的かつ確実に追跡するシステム１００の一例を示すブロック図である。ネットワーク上でデバイス情報を効率的かつ確実に追跡するシステムの他の実施形態、例えばシステム１００の変型も可能であり、本発明の範囲に含まれることが意図される。本明細書の他の箇所でより詳細に説明するように、システム１００の様々な態様および本明細書で説明するシステムの実施形態は、２０１６年１１月２９日にベルント・ムーラー（Ｂｅｒｎｄ  Ｍｏｅｌｌｅｒ）に発行された「ヘテロジニアスネットワークにおけるデバイスの管理（Ｍａｎａｇｉｎｇ  Ｄｅｖｉｃｅｓ  ｉｎ  ａ  Ｈｅｔｅｒｏｇｅｎｅｏｕｓ  Ｎｅｔｗｏｒｋ）」と題する米国特許第９，５０９，６２８号（以下、‘６２８号特許という）に説明されるシステムの態様を使用して実施することができ、その内容全体を参照により本明細書に組み込む。
【００２２】
システム１００は、ネットワーク１０２、サーバ１０４、ゲートウェイ１１２、１１４、１１６、ユーザ装置１０６、１０８、１１０、データソース１２１、１２２、１３２、１２４、１３４、１４４、１５４、１２６、１３６、１４６（例えば、センサ）、他のコンポーネント、または前述の任意の適切な組み合わせのいずれを含んでもよい。
【００２３】
サーバ１０４は、ネットワーク１０２の一部であってよく、これは、例えばパブリッククラウドまたはプライベートクラウドなどのクラウドネットワークであってもよい。サーバ１０４は、単一コンポーネントとして図示しているが、サーバ１０４がネットワーククラウドの原理に一致した分散型サーバシステムを表せることは理解されるであろう。したがって、サーバ１０４は、複数の物理的に分離した／遠隔のコンポーネント（例えば、サーバクラスタ）または該コンポーネントの部分を含んでもよい。さらに、図１には１つのサーバしか図示していないが、本発明はそのような制限を受けることはなく、数十、数百、数千、またはそれ以上のサーバをシステム１００に含めてもよい。
【００２４】
各データソースは、多様なコンポーネントまたはセンサの種類のいずれでもよく、例えば、ドイツ、ニュルンベルグに事務所を置くマイオメガ・システムズ社（ＭｙＯｍｅｇａ  Ｓｙｓｔｅｍｓ  ＧｍｂＨ）（以下、「ＭｙＯｍｅｇａ」という）から入手可能なもののいずれでもよく、温度、赤外線もしくは温度アレイ、光強度、イメージ、色、湿度、圧力、応力、摩耗、電圧、電流、重量、質量、サイズ、高さ、場所、距離、速度、空間消費量、電力消費量、ネットワーク周波数、回転数、気流、体積、位置推定、ネットワークセル識別、超音波反射値、距離尺度（飛行時間など）、タグＩＤおよびＲＦＩＤパラメータ、機械振動、音、偏向磁場（特に地球の磁場）、資源消費量、消費率、オン、オフ、低、高、損傷、動作不能、減少、他の特性、情報、パラメータ値もしくは状態、または前述の任意の適切な組み合わせを含むがこれだけに限定されない、多様な物理的、電気機械的、もしくは他の特性、情報、パラメータ値または状態のいずれかを感知、捕捉または判断するように構成してもよい。
【００２５】
図１には図示していないが、各データソースは、データソースが情報を捕捉および通信するデバイス内に埋め込むか、または他の形で（物理的に、光学的に、電磁的に、もしくはその他の形で）該デバイスに連結してもよい。例えば、データソース１３２が、ＭｙＯｍｅｇａから入手可能なＴｒａｃｏＢｉｎ（登録商標）である場合、データソース１３２は、収納箱などの監視対象デバイス１３３に連結してもよい。あるいは、データソース１３２は、データソース１３２が状態情報を捕捉する、デバイス１３５内に埋め込まれるセンサであってもよい。センサが、デバイス内に埋め込まれるかまたはデバイスの一体的な一部である実施形態では、デバイスおよびセンサは、１つの同じものと見なしてもよい。デバイス自体もしくはおそらくはデバイス内に埋め込まれているセンサがゲートウェイと通信可能に連結される場合、またはデバイスに連結されて該デバイスから情報を検知するセンサがゲートウェイに通信可能に連結される場合、本明細書において、デバイスがゲートウェイに連結または接続されると見してもよい。このように、本明細書の実施形態は、デバイス（例えば、デバイス１３３）がデバイスに関する情報をゲートウェイ（例えば、ゲートウェイ１１２）に通信することを説明するが、これは、デバイス（例えば、デバイス１３３）に連結されるセンサ（例えば、データソース１３２）がゲートウェイ（例えば、ゲートウェイ１１２）に情報を通信していることも意味することは理解されるであろう。
【００２６】
センサが連結されるか、内部に埋め込まれるか、または統合されるデバイスは、コンピュータ、機械、装置、器具、回路、コンテナ、樽、タンク、ＩＢＣ（中間バルクコンテナ）、ツール、栓、切削工具、ドリルもしくはフライス盤、武器、玩具、他の種類のデバイス、前述のいずれかのサブコンポーネントもしくは部品、または例えば自動車、工場、工業プラント、建物、住宅、ネットワーク（送電網、通信、コンピュータ、交通、その他）、倉庫、店舗、モール、データセンタ、制御システム、もしくは他の複雑なシステムなどの、より複雑なシステムのサブコンポーネントもしくは部品、または前述のいずれかの適切な組み合わせを含むがこれだけに限定されない、多様な種類のデバイスのいずれかであってもよい。１つまたは複数のデバイスをキャピラリデバイスであってもよいことは理解されるであろう。各デバイスに関する情報は、イベントに応答して、および／またはユーザの要求／入力に応答して、センサによってゲートウェイに定期的に通信してもよい。さらに、長期的には、センサは、情報を通信するやり方を、例えばセルラー、有線、無線、キャピラリ通信、他の手法、または前述の任意の適切な組み合わせ間で変えてもよい。
【００２７】
各データソース／センサは、ＴＰＭ（例えば、デバイス１２２のＴＰＭ１２３）、１つもしくは複数のセキュアエレメント、加入者識別モジュール（ＳＩＭ）、クリプトブロック、他のデータセキュリティコンポーネントおよび／または前述の任意の適切な組み合わせを含んでもよい。ＴＭＰという用語は、本明細書を通して使用されるが、前述のセキュリティ／暗号コンポーネントまたはその組み合わせ、または同様なコンポーネントのいずれかを使用して、本明細書で説明する暗号操作を含むデータセキュリティ操作を行えることは理解されるであろう。さらに、本明細書で説明するデータセキュリティ操作の１つもしくは複数を行うために、ＴＰＭは、システム１００の他のコンポーネント、例えば、ＵＥ、ゲートウェイおよびサーバのいずれに含むこともでき、またはこれらに採用してもよい。操作は、情報のプライバシーを保護するために、例えば、デバイスに固有の秘密鍵を使用して、デバイス情報を暗号化することを含んでもよい。秘密鍵は、対称暗号方式の当事者（本明細書で説明するフードチェーンの当事者の１つもしくは複数）間で共有される秘密鍵（例えば、共有暗号鍵）、または非対称暗号方式の秘密／公開鍵ペアの秘密鍵であってもよい。ゲートウェイ１１２、１１４および１１６に送られる通信に含まれる情報の１つもしくは複数の部分をセンサのいずれかが暗号化することができ、または、暗号化されずに受信した情報の部分を各ゲートウェイが暗号化してもよい。図１には９つのセンサしか図示していないが、本発明はそのような制限を受けることはなく、数百、数千、数百万、またはそれ以上のセンサをシステム１００に含めてもよい。
【００２８】
ゲートウェイ１１２、１１４、１１６は、サーバ１０４に連結することができ、図１に図示されるように、ゲートウェイ１１２、１１４、１１６のそれぞれを複数のデバイスに連結してもよい。例えば、ゲートウェイ１１２は、デバイス１２２、１３２および１３３に連結してもよい。ゲートウェイは、センサ／データソースをクラウドに連結し、さらに、特にサーバ１０４に連結する（すなわち、センサ／データソースのクラウドのゲートウェイとして機能する）。いくつかの実施形態において、例えばデバイス１３１（例えば、ポンプまたはファン）に接続されているところが示される図１のセンサ１２１に図示されるように、データソース／センサの１つまたは複数を、クラウドまたはサーバに直接接続してもよい。そのような実施形態において、データソース自体、またはセンサ／デバイスの組み合わせは、ゲートウェイ１１１のように扱ってもよい。
【００２９】
各ゲートウェイは、‘６２８号特許の図２に関連して説明される能力を含め、‘６２８号特許の図１のコントローラ５２の１つまたは複数の能力を備えて構成してもよい。これらの実施形態は、‘６２８号特許の図２に関連して説明されるレイヤ８８、‘６２８号特許の図４に図示されるマッピング手法、および、‘６２８号特許の図６〜図７に関連して説明される様々な衝突管理手法のものを含んでもよい。各ゲートウェイは、例えば汎用コンピュータ、ＭｙＯｍｅｇａから入手可能なＭＹＮＸＧ（登録商標）ゲートウェイもしくはコントローラなどのより専門化したデバイス、多様な他のデバイスのいずれか、または前述の任意の適切な組み合わせなど、本明細書で定義されるゲートウェイ機能を行うように構成されている複数の種類のデバイスのいずれかであってもよい。図１には３つのゲートウェイしか図示していないが、本発明はそのように制限を受けず、数百、数千、数万、またはさらにそれ以上のゲートウェイをシステム１００に含めてもよい。各ゲートウェイは、トラステッドプラットフォームモジュール（ＴＰＭ）（例えば、ゲートウェイ１１２のＴＰＭ１１３）を含んでもよい。前述したように、ＴＰＭを使用して、センサからゲートウェイへの通信の部分を暗号化すること、または暗号化されずにゲートウェイで受信した情報の部分を暗号化することを含め、多様なデータセキュリティ操作のいずれを行ってもよい。ＴＰＭは、本明細書で説明する実施形態に従いトランザクションレコードの一方向ハッシュ（もしくは他の種類のハッシュ）を生成すること、またはシステム１００の要素コンポーネント間、例えば、サーバ、ゲートウェイおよびデバイス間のセキュアな通信を提供することを含め、本明細書で説明するシステムの様々な実施形態で使用される他のデータセキュリティ操作のために採用してもよい。例えば、ＴＰＭもしくはシステム１００の他のコンポーネントは、例えば‘６２８号特許で説明されるように、ＨＴＴＰＳ通信用のトランスポートレイヤセキュリティ（ＴＬＳ）および／または制約付きアプリケーションプロトコル（ＣｏＡＰ）通信用のデータグラムトランスポートレイヤセキュリティ（ＤＴＬＳ）を実装するように構成してもよい。さらに、前述のデータセキュリティ操作のいずれかに関連する１つまたは複数のセキュリティクレデンシャルをＴＰＭに格納してもよい。本明細書で説明するシステムのパフォーマンスおよびセキュリティは、これらのデータセキュリティ操作のために、ＴＰＭを使用してセンサ／データソース、ゲートウェイおよびサーバによって改善してもよい。
【００３０】
ＴＰＭは、例えば生産中に、システム１００のゲートウェイ（例えば、ＴＰＭ１１３）、データソースまたはサーバのいずれかの中に実装することができ、ゲートウェイまたはデータソース／センサをパーソナライズするために使用してもよい。そのようなゲートウェイ、データソースおよび／またはサーバは、鍵およびクレデンシャルの管理のために、公開鍵インフラストラクチャ（ＰＫＩ）を（例えば、製造中またはその後に）実装するように構成してもよい。ＴＰＭは、個別の暗号化オブジェクトを作成し、これを、トランザクション、例えば図３に関連して以下説明するトランザクションを格納するために使用してもよい。いくつかの実施形態では、該ＴＰＭオブジェクトは、例えば、該デバイスの生産中に、センサ、ゲートウェイおよび／またはサーバの不揮発性メモリの内部に格納することができ、それにより、該デバイスの生産サイクルをより速くしてもよい。他の暗号手法も同様に前述の目的のために使用してもよい。
【００３１】
複数のユーザデバイス／装置（ＵＥ）１０６、１０８、１１０は、ユーザがシステム１００の他のコンポーネント（例えば、ゲートウェイ、サーバ、センサ、監視対象デバイス）と対話することを可能にする複数のデバイス（例えば、デスクトップコンピュータ、ラップトップコンピュータ、タブレット、携帯情報端末（ＰＤＡ）、セルラースマートフォン、または他のデバイス）のいずれかであってもよい。各ＵＥは、‘６２８号特許の図２および図３に関連して説明されるＵＥ機能を含め、ＵＥ５４、５５、５６に関して‘６２８号特許で説明される機能のいずれを備えても構成してもよい。いくつかの実施形態において、１つもしくは複数のゲートウェイは、ＵＥ機能を備えて構成してもよく、および／または、１つもしくは複数のＵＥは、ゲートウェイ機能を備えて構成してもよい。図１では３つのＵＥを図示しているが、本発明はそのような制限を受けず、数百、数千、数万、またはさらにそれ以上のＵＥをシステム１００に含めてもよい。
【００３２】
いくつかの実施形態において、システム１００は、システム１００の１つまたは複数のコンポーネントを含む、１つまたは複数のサブシステムを有すると見なすことができ、これは、本明細書のシステムとして見なし、参照してもよい。例えば、ゲートウェイ１１２、１１４、１１６とサーバ１０４との組み合わせは、システム１６０と見なすことができ、ゲートウェイとゲートウェイが接続するセンサ／データソースとの組み合わせは、システム、例えば、システム１６２、１６４、１６６と見なしてもよい。サーバ、ＵＥ、ゲートウェイおよびセンサ／データソースの他の組み合わせも同様にシステムとして扱ってもよい。本明細書で使用されるトランザクションチェーン（例えば、ブロックチェーン）は、システム１００に関して概念化された任意のシステム、例えば、前述のシステムのいずれかに基づくか、またはそのために定義してもよい。例えば、ブロックチェーンは、システム１６２のために、またはクラウド／サーバレベルで（例えば、システム１６０）作成されて維持されることが可能である。そのようなシステムは、本明細書の他の箇所でより詳細に説明するように、フードチェーンの当事者に合致するように編成してもよい。
【００３３】
図２は、本明細書で説明するシステムの実施形態に係る、フードチェーン内のシステムのコンポーネントと当事者／役割との関係の一例を示す概念モデル２００である。フードチェーン内のシステムのコンポーネントと当事者／役割との関係の他の実施形態、例えば、モデル２００の変型も可能であり、本明細書で説明するシステムの範囲に含まれることが意図される。図２に図示するように、サプライヤの役割は、コンポーネント２０２、２０４で示されるセンサ／データソースに合致させてもよい。生産者の役割は、コンポーネント２０６、２０８で示されるゲートウェイに合致させてもよい。そして、オペレータの役割は、コンポーネント２１０、２１２で示されるクラウド（例えば、クラウド内のサーバ）に合致させてもよい。ディーラー、ユーザおよびインテグレータとシステムコンポーネントとの関係も図２に示す。
【００３４】
図３は、本明細書で説明するシステムの実施形態に係る、複数の通信からの情報をトランザクションレコードにグループ化する一例を示すブロック図である。異なるレイアウトを有するトランザクションレコードへの通信の他のグループ化、例えば、図３に示すグループ化の変型も可能であり、本明細書で説明するシステムの範囲に含まれることが意図される。
【００３５】
複数のセンサ３０２、３０４、３０６は、イベント（例えば、監視対象財産の状態の変化）に応答して、またはユーザの入力（例えば、データ要求）に応答して、例えば既定のスケジュールに従って、通信３０８、３１４、３２０をそれぞれゲートウェイ３３０（例えば、システム１００に関連して示されているゲートウェイのうちの１つ）に同時に、または異なる時刻に送る（例えば、送信する）ようにしてもよい。通信３０８、３１４、３２０の各々は、本明細書の他の箇所でより詳細に説明する、公開情報要素３１０、３１６、３２２と、非公開情報要素３１２、３１８、３２４とをそれぞれ含んでもよい。ゲートウェイ３３０は、トランザクションレコード３３２を生成することができ、サーバ３５６にトランザクションレコード３３２を送ってもよい。トランザクションレコード３３２は、トランザクションヘッダ３３４とトランザクション本体３３６とを含んでもよい。トランザクション本体３３６は、公開情報要素３１０、３１６、３３２にそれぞれ対応する公開情報要素３３８、３４２、３４６と、非公開情報要素３１２、３１８、３２４にそれぞれ対応する非公開情報要素３４０、３４４、３４８とを含んでもよい。
【００３６】
トランザクションヘッダ３３２は、直前のトランザクションレコードｔｎ−１の一方向ハッシュ３５０、直前のトランザクションレコードｔｎ−１への参照（例えば、リンクまたはポインタ）３５５、現在のトランザクションレコードｔｎの一方向ハッシュ３５２、およびスケジュール情報３５４を含んでもよい。ｔｎ−１の一方向ハッシュは、本明細書の他の箇所でより詳細に説明するように、要求に応答してサーバ３５６から取得されたもの、または別の実施形態では、サーバ３５６への別のトランザクションレコードの送信に応答してサーバ３５６からの更新で取得されたものでもよい。一方向ハッシュ３５０、３５２およびスケジュール情報３５４の生成は、本明細書の他の箇所でより詳細に説明する。レコードのトランザクション本体３３６に含まれる情報は、最後のトランザクションから変化したデバイスの情報のみを含んでもよい。いくつかの実施形態では、最後のトランザクションから変化していない情報は、トランザクションレコード本体３３６に含まれ、どの情報が変化したかを示すためのメカニズムがある。
【００３７】
トランザクションレコードは、例えば図９に関連して説明するものなどのように、多様なフォーマットのいずれかでサーバ３５６に送信してもよい。図９は、本明細書で説明する本発明の実施形態に係る、トランザクションレコード９１０を含むメッセージ９００の一例を示すブロック図である。メッセージの他の実施形態、例えば、メッセージ９００の変型も可能であり、本発明の範囲に含まれることが意図される。メッセージ９００は、イーサネット、ＴＣＰ／ＩＰおよびＴＬＳプロトコルに従ってフォーマット化することができ、そのため、イーサネットヘッダ９０２、ＴＣＰヘッダ９０６、ＩＰヘッダ９０４およびＴＬＳ証明書９０８を含んでもよい。前述のプロトコルに加えて、またはその代わりとして、他のプロトコルも使用することができ、その場合、追加フィールドまたは代替フィールドがメッセージ９００に含まれ得ることは理解されるであろう。トランザクションレコード９１０は、ＪＳＯＮに従ってフォーマット化してもよい。トランザクションレコードは、図３のトランザクションレコード３３２に関連して上記説明したフィールドの１つまたは複数を含むことができ、トランザクションレコード３３２に関連して上記説明したようにフォーマット化することができ、または、異なる情報を含み、および／もしくは異なるようにフォーマット化してもよい。例えば、トランザクションレコード９１０は、トランザクションレコード９２０として実施してもよい。トランザクションレコードは、メタデータ９２２、直前のトランザクションのハッシュ９２４、公開鍵暗号標準（ＰＫＣＳ）証明書９２６、公開情報９２８、別のＰＫＣＳ証明書９３０、非公開情報９３２、およびトランザクションレコード９２０が表すトランザクションのハッシュのうちのいずれを含んでもよい。
【００３８】
メタデータ９２２は、ゲートウェイまたはサーバが使用することのできる複数の情報のいずれか、例えば図３に関連して上記説明したスケジュール情報３５４を含んでもよく、例えばＰＫＣＳを用いて暗号化してもよい。ハッシュ９２４および９３４は、図３のハッシュ３５０および３５２に関連して上記説明したように実施してもよい。公開情報９２８および非公開情報９３２は、図３に関連して上記説明した公開非公開情報フィールドに関連して上記説明したように実施することができ、それぞれ、ＰＫＣＳまたは別の暗号化技術、例えば、秘密共有鍵（ＰＳＫ）に従って暗号化してもよい。ＰＫＣＳ証明書９２６および９３０は、ＰＫＣＳ暗号化フィールド９２８および９３２にそれぞれ対応してもよい。他の暗号化技術を使用することもでき、その場合、採用する暗号化に対応する証明書をＰＫＣＳ証明書の代わりにフィールド９２６および９３０に使用してもよい。
【００３９】
ゲートウェイからサーバに送信されるトランザクションレコード（例えば、トランザクションレコード３３２）は、ゲートウェイのトランザクションチェーン、すなわち、システム（例えば、ゲートウェイ１１２に対応するシステム１６２）を表すトランザクションチェーンの一部としてサーバに格納してもよい。サーバ（例えば、サーバ３５６）は、サーバ／クラウドレベルで、システム、例えばサーバ１０４に対応するシステム１６０に対応するトランザクションチェーンの一部としても、トランザクションレコードを格納してもよい。すなわち、サーバ１０５は、ゲートウェイ１１２、１１４および１１６に対応するトランザクションレコードを含むトランザクションチェーンを格納してもよい。
【００４０】
図４は、本明細書で説明するシステムの実施形態による複数のトランザクションレコード４０２、４０４、４０６を示す。トランザクションレコードの他の実施形態、例えば、トランザクションレコード４０２、４０４、４０６の変型も可能であり、本明細書で説明するシステムの範囲に含まれることが意図される。トランザクションレコード４０２、４０４、４０６は、それぞれトランザクションレコード本体４０８、４２０、４２４と、それぞれレコードヘッダ４１４、４２２、４２６とを含んでもよい。各ヘッダは、直前のトランザクションレコードの一方向ハッシュと、現在のトランザクションレコードの一方向ハッシュ、例えば、トランザクションレコード４０２のヘッダ４１４の、トランザクションレコード２の一方向ハッシュ４１８と、トランザクションレコード３の一方向ハッシュ４１６とを含んでもよい。各レコード本体は、複数の公開および／または非公開情報を含んでもよい。図４に示す実施形態では、デバイスの各非公開情報要素は、同じデバイスの対応する公開情報要素を有する。例えば、情報部分４１３は、同じデバイスの非公開情報要素４１３ａと公開情報要素４１３ｂとを含む。
【００４１】
トランザクションレコード本体４０８、４２０、４２４において、各情報要素は、４フィールド識別子を有してもよい。１フィールドは、情報の所有者、例えばサプライヤ、インテグレータ、生産者、ユーザまたはオペレータを識別する。サプライヤはデータソース／センサに対応し、生産者はゲートウェイに、オペレータはサーバに対応してもよい。別のフィールドは、デバイスが属するシステムの識別子である。例えば、デバイスは冷却ファンであってもよいし、システムは器具であってもよい。別のフィールドは、デバイスの製造番号（おそらくは各デバイスに固有のもの）を識別し、別のフィールドは、要素の情報を提供したオリジナルのトランザクションを表す。例えば、情報要素４１３ａ、４１３ｂは、オペレータが所有し、製造番号１で、システム１の一部であるデバイスに関するものであり、トランザクション３によって元々提供されたものである。
【００４２】
いくつかの実施形態では、情報要素が現在のトランザクション以外のトランザクションによって元々提供された場合、これは、情報要素によって表される情報が現在のトランザクションについて変化していないことを意味する。例えば、情報要素４１０は、すべて、レコード４０２が表すトランザクション３とは異なるトランザクション２によって元々提供されたものであり、デバイスＵ．２．１およびＧ２．２の情報は、トランザクション３について変化していないことを意味する。各情報要素について、トランザクションレコード本体は、要素が表す情報が、表されるトランザクションについて変化したかどうかの表示を含んでもよい。図４では、情報要素が表す情報が変化していない場合（例えば、要素４１０）、情報要素は、グレーの背景に白色の文字で強調表示される。要素４１０とは対照的に、トランザクションレコード４０２の要素４１２は、これらの項目を元々提供したトランザクション（３）がトランザクションレコードのトランザクション３と等しいことを反映するように変化している。本明細書で説明するシステムのいくつかの実施形態では、変化した情報のみをトランザクションレコードに含める。
【００４３】
トランザクションレコード４０２、４０４、４０６は、複数のゲートウェイを含むシステム、例えばゲートウェイ１１２、１１４および１１６を含むシステム１６０のトランザクションレジスタとして機能するトランザクションチェーンの一部としてサーバに格納されるトランザクションレコードを表してもよい。例えば、トランザクションレコード４０２、４０４、４０６のそれぞれは、図示される情報要素に反映されるように、ゲートウェイＧ１、Ｇ３およびＧ２からそれぞれ受信したトランザクションレコードに対応してもよい。これは、各トランザクションで他のゲートウェイに対応する情報要素が、トランザクションレコード４０２、４０４、４０６のそれぞれにおいて変化しないで反映される理由であろう。例えば、トランザクションレコード４０６内のトランザクション情報は、ゲートウェイＧ２から受信したトランザクションレコードに対応し、ゲートウェイＧ１およびＧ３に対応する情報要素は、トランザクション４０６では変化しないため、すなわち、ゲートウェイＧ２からのトランザクションレコードは、Ｇ１およびＧ３に対応するトランザクションを反映しないためである。
【００４４】
いくつかの実施形態では、トランザクション情報の格納は、図８に関連して以下説明するスロット／サイクルのスケジューリング手法に従って行ってもよく、その場合、１サイクル中の所与のシステムの完全なトランザクション情報は、サイクルごとに１度のみ格納してもよく、そのサイクル内のそれぞれのタイムスロット中には、トランザクションごとに変化した情報のみを格納してもよい。図５は、本明細書で説明するシステムの実施形態に係る、図８に関連してより詳細に以下で説明するスロット／サイクルのスケジューリング手法に従ってトランザクション情報が格納される、複数のトランザクションレコード５０２、５０４、５０６の一例を示す。トランザクションレコードの他の実施形態、例えばトランザクションレコード５０２、５０４、５０６の変型も可能であり、本明細書で説明するシステムの範囲に含まれることが意図される。トランザクションレコード５０２、５０４、５０６は、それぞれレコード本体５０８、５１８、５２２と、それぞれレコードヘッダ５１０、５２０、５２４とを含んでもよい。各ヘッダは、直前のトランザクションレコードの一方向ハッシュと、現在のトランザクションレコードの一方向ハッシュ、例えば、トランザクションレコード５０２のヘッダ５１０の、トランザクションレコード５の一方向ハッシュ５１６と、トランザクションレコード６の一方向ハッシュ５１４とを含んでもよい。各レコードヘッダは、システムのスケジュール情報（例えば、サイクルスケジューラ情報）も含んでもよい。
【００４５】
トランザクションレコード４０２、４０４、４０６と同様に、トランザクションレコード５０２、５０４および５０６は、複数のゲートウェイを含むシステム、例えば、ゲートウェイ１１２、１１４および１１６を含むシステム１６０のトランザクションレジスタとして機能するトランザクションチェーンの一部としてサーバに格納されるトランザクションレコードを表してもよい。しかし、図４のトランザクションレコード４０２、４０４、４０６とは異なり、トランザクションレコード５０２、５０４は、表されるトランザクションについて変化していない情報の情報要素は含まず、むしろトランザクションについて変化した情報のみを含む。例えば、トランザクション５０２は、Ｇ１に対応する情報のみを変化したものとして示すように、ゲートウェイＧ１に対応してもよい。同様に、トランザクション５０４は、Ｇ３に対応する情報のみを変化したものとして示すように、ゲートウェイＧ３に対応してもよい。他方で、トランザクションレコード５０６は、変化したか変化していないかに関わらず、１サイクル中にシステムのゲートウェイから受信したあらゆるトランザクションレコードに含まれるすべてのトランザクション情報を表してもよい。このようなレコードは、そのサイクル中に受信した一連のトランザクション情報のすべてを表すことができ、そのサイクルの最後のトランザクション（例えば、スロット）の時点で変化した情報要素、すなわちゲートウェイＧ２に対応する情報要素のみが、トランザクションレコード５０６において変化したものとして反映される。システムのすべての完全なトランザクション情報をサイクルごとに１度だけ格納し、サイクルを通して各トランザクションについて変化した情報のみを格納することにより、トランザクションごとにゲートウェイのすべてのデバイスについて情報を格納するのと比較してネットワークリソースを節約してもよい。このネットワークリソース、特にストレージリソースの節約は、システム上のデバイス数が多くなるにつれて重要性が高まってくる。
【００４６】
システム内の各システムについて、例えば、各ゲートウェイ、または各データソース、または１つのシステムとして定義されるゲートウェイおよび／もしくはデータソースのグループについても、個別のトランザクションチェーン、例えばトランザクションレジスタを維持してもよいことは理解されるであろう。そのようなトランザクションチェーンは、システムの複数のコンポーネントのいずれにも、例えば、図１に関連して上記説明したシステム１００のコンポーネントのいずれにも格納してもよい。例えば、サーバ１０４は、複数のトランザクションチェーン、例えばゲートウェイ１１２、１１４および１１６にそれぞれ対応するシステム１６２、１６４および１６６のそれぞれのトランザクションチェーン、およびゲートウェイ１１２、１１４および１１６のグループに対応するシステム１６０のトランザクションチェーンを格納するか、またはそのストレージを制御してもよい。
【００４７】
図６は、本明細書で説明するシステムの実施形態に係る、ネットワーク上でデバイス情報を効率的かつ確実に追跡する一例を示すフローチャート６００である。ネットワーク上でデバイス情報を効率的かつ確実に追跡する方法の他の実施形態も可能であり、本明細書で説明するシステムの範囲に含まれることが意図される。フローチャート６００が示す処理は、ネットワークまたはシステムの１つもしくは複数のゲートウェイ、例えばネットワーク１００のゲートウェイ１１２、１１４、１１６のいずれによっても行ってもよい。
【００４８】
処理は、ステップ６０２で始まり、デバイスからの次の通信が、例えば、ゲートウェイに連結されているデバイスのいずれかによって受信されたかどうかを判断してもよい。次の通信が受信されていなければ、制御はステップ６０２に戻る。このループは、デバイスからの次の通信が受信されるまで繰り返すことができ、それに応答して、処理は、ステップ６０４に進み、デバイスからの通信がデバイスの状態の何らかの変化、すなわちデバイスに関する何らかの情報の変化を反映するかどうかが判断される。反映されていなければ、制御は、さらに繰り返すためにステップ６０２に戻る。そうでなければ、制御は、ステップ６０４からステップ６０６に移る。代替実施形態では、ステップ６０２で次の通信が受信されていれば、制御は、ステップ６０２からそのままステップ６０６に移り、したがってテストステップ６０４を飛ばす。テストステップ６０４は、デバイスの何らかの情報の変化（状態変化）のみを記すのが望ましい実施形態で行ってもよい。例えば、いくつかの実施形態においては、変化した情報のみをサーバに送られるトランザクションレコードに含んでもよく、または変化した情報のみをサーバおよび／もしくはゲートウェイに保存してもよい。情報（状態）の変化のみを判断することが望ましくない実施形態では、ステップ６０４を省略してもよい。情報が変化したとき、すなわち情報が変化したとセンサ／データソースが示す場合にのみデバイスが通信を送る実施形態でも、ステップ６０４を省略してもよいことにも留意されたい。そのような実施形態では、変化した情報のみが送られるので、テストステップ６０４は必要ない。
【００４９】
ステップ６０６で、通信に含まれる情報の少なくとも一部を暗号化してもよい。例えば、本明細書の他の箇所で説明するように、非公開情報の暗号化を、例えばゲートウェイに含まれるＴＰＭを用いて、または別のメカニズムによって行ってもよい。いくつかの実施形態では、ゲートウェイに通信を送る前に非公開情報がデバイスまたはそれに対応するセンサ上ですでに暗号化されている可能性があるので、暗号化の実施が必要ないことがある。このように、図６には図示していないが、センサまたはデバイスがゲートウェイに通信を送る前に、例えば、本明細書の他の箇所で説明するように、デバイスに対応する秘密鍵を使用して非公開データを暗号化することが可能である。ステップ６０６で任意の暗号化を行う予定である限り、例えば、変化した情報のみをサーバに送られるトランザクションレコードに含める、および／またはゲートウェイに保存する実施形態では、暗号化は、変化した情報に制限してもよい。
【００５０】
ステップ６０６の次がステップ６０８で、少なくとも変化した情報をトランザクションレコードの情報に追加してもよい。例えば、トランザクションレコードをサーバに送る準備として、ゲートウェイで新たな通信が受信されるたびにトランザクションレコードの情報を増大させるかまたはその他の形で変更するように、各通信を受信するとトランザクションレコードを繰り返し生成してもよい。トランザクションレコードを繰り返し構築するために、何らかの形態の一時的なデータ構造を使用してもよい。変化した情報のみをトランザクションレコードに含める実施形態では、通信から、変化した情報のみをトランザクションレコードの情報に追加してもよい。
【００５１】
ステップ６０８の次がテストステップ６１０で、ゲートウェイについて、トランザクションレコードをサーバに送る予定時刻であるかどうかを判断する。予定時刻でなければ、制御は、ステップ６０２に戻って、デバイスからの次の通信を待つ。そうでなければ、制御は、ステップ６１０からステップ６１２に移る。送信スケジュールが採用されていない実施形態では、ステップ６０８からそのままステップ６１２になる。ステップ６１２で、本明細書の他の箇所で説明するように、ブロック送信要求をサーバに送ってもよい。ステップ６１２の次がステップ６１４で、直前のトランザクションレコードの一方向ハッシュを受信してもよい。ステップ６１４の次がステップ６１６で、現在のトランザクションの一方向ハッシュを生成してもよい。ステップ６１６の次がステップ６１８で、現在のトランザクションのトランザクションレコードをサーバに送ってもよい。トランザクションレコードは、本明細書で説明するもののうちの任意のものを含む、多様な形態のいずれかであってもよい。ステップ６１８の次がステップ６２０で、トランザクションレコードは、例えば、トランザクションチェーンの一部として、サーバ、ゲートウェイおよび／または他の場所に格納される。
【００５２】
いくつかの実施形態では、ステップ６１２で要求を送って、ステップ６１４で一方向ハッシュを受信してから、ステップ６１８でトランザクションレコードを送るのではなく、ゲートウェイは、トランザクションレコードを単に送信してもよい。そのような実施形態では、現在のトランザクションレコードを作成する一部として使用するために各ゲートウェイが直前のトランザクションの一方向ハッシュを有するように、送信レコードが任意のゲートウェイによってサーバに送信されるたびにトランザクションレコードの更新をゲートウェイが受信してもよい。
【００５３】
図７は、本発明のいくつかの実施形態に係る、ネットワーク上でデバイス情報を効率的かつ確実に追跡するための、データソース／センサ７１０、７１２、ゲートウェイ７０４、７０６、７０８および（例えば、ネットワーククラウドの）サーバ７０２間の通信のシーケンス７００を示すシーケンス図である。ネットワーク上でデバイス情報を効率的かつ確実に追跡するための、センサ、ゲートウェイおよびネットワーククラウド間の通信のシーケンスの他の実施形態、例えば、シーケンス７００の変型も可能であり、本明細書で説明するシステムの範囲に含まれることが意図される。シーケンス７００は、本明細書の他の箇所で説明するシステム１００のコンポーネントを使用して実施してもよい。
【００５４】
公開データ「１」と非公開データ「（ｆ１）」とを含む通信７１４は、センサ７１２からゲートウェイ７１０に送信され、次いで、公開データ「２」と非公開データ「（ｆ２）」とを含む通信７１６は、センサ７１０からゲートウェイ７０８に送信される。ある後の時点で、例えば本明細書で説明する割り当てタイムスロット中に、ゲートウェイ７０８は、トランザクション送信要求７１８、例えばデータハートビート（ＨＢ）要求をサーバ７０２に送信する。応答して、サーバ７０２は、直前のトランザクションレコードｎ−１の一方向ハッシュ７２０を、例えばトランザクションブロックｎ−１のヘッダからゲートウェイ７０８に送る。ゲートウェイ７０８は、次いで、トランザクションレコード７２２、例えばデータＨＢトランザクションｎを、通信７１４、７１６からの公開および非公開情報を含めて送り、サーバ７０２は、確認応答（ＡＣＫ）７２４を返す。ゲートウェイ７０６は、次いで、例えば、ゲートウェイ７０６の割り当てタイムスロット中に、トランザクション送信要求７２６、例えばデータハートビート（ＨＢ）要求をサーバ７０２に送信する。応答して、サーバ７０２は、直前のトランザクションレコードｎ（すなわち、トランザクションレコード７２２）の一方向ハッシュ７２８を、例えばトランザクションブロックｎのヘッダから、ゲートウェイ７０６に送る。ゲートウェイ７０６は、次いで、トランザクションレコード７３０、例えばデータＨＢトランザクションｎ＋１を、例えば、ゲートウェイ７０６に連結されている１つまたは複数のセンサからの通信で受信された公開情報「３」および「４」と非公開情報「（ｆ３）」および「（ｆ４）」を含めて送り、サーバ７０２は、確認応答（ＡＣＫ）７３２を返す。
【００５５】
図７に図示するように、ゲートウェイからサーバへのトランザクションレコードの送信の一部として交換されるとともに、図６に関連してより詳細に説明される４つの通信は、ネットワークリソースを効率的に活用し、トランザクションチェーン（例えば、ブロックチェーン）を適切に実施するために必要な通信オーバーヘッドを最小量にすると見なしてもよい。この効率的なリソースの利用は、例えばゲートウェイがサーバにトランザクションレコードを送信するたびにすべてのゲートウェイが更新を受信する代替実施形態とは対照的である。トランザクション情報が記録される任意の手法で、トランザクションレコードのデバイス情報が送信され、確認応答が受信されることを考えると、本明細書で説明する４つの通信シーケンスに従って追加される唯一の通信オーバーヘッドは、トランザクション送信要求を送ること、前のトランザクションの一方向ハッシュを受信すること、およびトランザクションレコードにトランザクションの一方向ハッシュを含めることである。すなわち、システムのゲートウェイとサーバとの間のトランザクションがｎ回の場合、メッセージのオーバーヘッドは（トランザクションチェーンを使用しないシステムと比較して）、２×ｎのメッセージだけである。
【００５６】
例えば、ゲートウェイあたり３０個のセンサを有する比較的小さなシステムの場合、センサあたり１２バイトの情報が生成され、トランザクションの一方向ハッシュは２５６ビット（３２バイト）の長さを有し、通信の通信ヘッダが６４バイトの長さを有すると仮定すると、ゲートウェイからのトランザクションレコードの送信１回につき消費されるバイト数と、それに関連した通信オーバーヘッドは、以下のように計算してもよい。
・トランザクション送信要求＝通信ヘッダ＝６４バイト
・サーバからの応答＝通信ヘッダ＋一方向ハッシュ＝６４＋３２＋９６バイト
・トランザクションレコード＝通信ヘッダ＋一方向ハッシュ＋デバイス情報＝６４＋３２＋１２×３０＝４５６バイト
・ＡＣＫメッセージ＝通信ヘッダ＝６４バイト
・トランザクションレコードの総バイト＝６４＋９６＋４５６＋６４＝６８０バイト
・トランザクションレコードの総オーバーヘッド＝トランザクション送信要求＋サーバからの応答＋トランザクションレコードの一方向ハッシュ＝１９２バイト、これはトランザクションレコードの総バイトの約２５％である。
【００５７】
センサの数が増えるにつれて、オーバーヘッドの割合は下がる。例えば、ＭｙＯｍｅｇａから入手可能なＭＹＮＸＧ  ＴｒａｃｏＢｉｎ（登録商標）内のように５００個のセンサがある場合、オーバーヘッドの割合は３％未満にしてもよい。
【００５８】
本明細書の他の箇所で述べるように、ゲートウェイからサーバへのトランザクションレコードの送信は、サイクル内の所定のタイムスロットを使用してスケジューリングしてもよい。より詳細にこれを説明する。図８は、サーバへのトランザクションレコードの送信をスケジューリングするためにサイクル内のタイムスロットを使用する一例を示す図である。サーバへのトランザクションレコードの送信をスケジューリングするためにサイクル内のタイムスロットを使用する他の実施形態は、例えば、図８に示す使用も可能であり、本明細書で説明するシステムの範囲に含まれることが意図される。送信スケジュールは、レコードトランザクションを送信するサーバで定め、そこに格納し、および／またはその管理下に置いてもよく、クラウドベースのスケジューラを含む多様な技術のいずれを使用しても実施してもよい。
【００５９】
サイクルタイム８０２を有するサイクルは、複数のタイムスロット８０６を含むように構成することができ、いくつかの実施形態では、各タイムスロットは、同じ継続時間のスロットタイム８０４を有するように定義される。スロットタイム８０４は、所与のゲートウェイについて以下のすべてのことを行うためにかかる推定累積時間に基づいて決定してもよい。
１．ゲートウェイ間のトランザクションレコードの送信を完了するための通信、例えば、図７および図６に関連して上記説明した通信７１８、７２０、７２２、７２４を送信する。
２．トランザクションレコードの一方向ハッシュを計算し、本明細書の他の箇所でより詳細に説明するように、ゲートウェイによって他の必要な暗号化を行う。
３．ネットワーククラウド内のサーバまたは他の箇所にトランザクションレコードを格納する。
４．トランザクションレコードのトランザクションヘッダを作成する。
【００６０】
いくつかの実施形態では、スロットタイム８０４は、任意の所与のゲートウェイについて前述のことを行うためにかかる最長の推定累積時間に基づいて、例えば、ゲートウェイの計算能力とそれに連結されているセンサの数とを考慮して決定してもよい。最長推定時間に基づいてスロットタイムを決定することにより、タイムスロットがすべてのゲートウェイについて十分な継続時間をもつことを確保してもよい。
【００６１】
いくつかの実施形態では、システム（例えば、サーバと各ゲートウェイ）は、サーバに与えられる（例えば、ＵＥからの）任意のユーザ要求を１スロットタイム内に完了できる（例えば、応答を計算して送信する）ように構成してもよい。このようなユーザ要求は、ユーザが権利をもつトランザクションチェーン内の情報のすべて（例えば、すべての公開情報と、ユーザが権利をもつ非公開情報のみ）またはその一部を要求してもよい。そのような実施形態では、サイクルタイム８０２は、決定したタイムスロット８０４の継続時間、サーバにレコードトランザクションを送信するゲートウェイの数、およびユーザ要求をサーバに送信する推定レート、すなわち、所与の時間枠内にどれくらい多くのユーザ要求が見込まれるか、に基づいて決定してもよい。システムのすべてのゲートウェイへの対応をサイクルタイム８０２中に確実に行えるようにするために、追加のバッファタイムも計算に入れてもよい。サイクルタイム８０２は以下のように表現してもよい。
サイクルタイム≧スロットタイムｘ（ゲートウェイ数＋単位時間あたりの推定ユーザ要求数＋バッファｘ）
【００６２】
例えば、図８を参照すると、サイクルタイム８０２中に、ゲートウェイ８０８は、タイムスロット８１０（Ｓ１）中にサーバによってサービスを受けることができ、ユーザ要求８１２は、タイムスロット８１４（Ｓ３）中にサービスを受けることができ、ゲートウェイ８１６は、タイムスロット８１８（Ｓ５）中にサービスを受けることができ、ユーザ要求８２０は、タイムスロット８２２（Ｓ６）中にサービスを受けることができ、ゲートウェイ８２４は、タイムスロット８２６（Ｓ９）中にサービスを受けてもよい。ユーザ要求８２０は、タイムスロット８１８ではなくタイムスロット８２２の一部として処理してもよい。これは、ユーザ要求８２０が到着したときにサーバがすでにゲートウェイ８１６にサービスを提供しており、サーバは、次のユーザ要求を処理する前に該サービス提供を完了するように構成されているためである。タイムスロット８０６のすべてがサイクルタイム８０２の一部として使用されたわけではないことは理解されるであろう。これは、すべてのユーザ要求、およびおそらくは他の予期できない遅延に対応するために十分なタイムスロットがあるように確保するための、ユーザ要求率の保守的な推定と保守的なバッファｘとから生じる。図８の例の場合、推定した最大ユーザ要求よりも少ない要求が受信された。いくつかの実施形態では、サービスを提供するゲートウェイ間でユーザ要求に対応するために十分な時間があるように確保するのを助けるため、ゲートウェイについてスケジューリングされるタイムスロットを、サイクル内で間隔を空けて設けることも理解されるであろう。
【００６３】
本明細書に述べる様々な実施形態は、本明細書で説明するシステムに関連して、適切な組み合わせで、互いに組み合わせてもよい。さらに、ある場合には、フローチャート、フロー図および／または説明されるフロー処理におけるステップの順番は、適切な場合、変更してもよい。続いて、スクリーンレイアウトに記載されるスクリーンの要素およびエリアは、本明細書で提示する例示とは変わってもよい。また、本明細書で説明するシステムの様々な態様は、記載される特徴を有し、記載される機能を実行するソフトウェア、ハードウェア、ソフトウェアとハードウェアとの組み合わせ、および／または他のコンピュータ実装モジュールもしくはデバイスを使用して実施してもよい。本明細書で説明するシステムは、タッチスクリーン、電磁ペンまたは他のペンによって作動させることのできる任意の種類の電子スクリーンとともに実施してもよい。
【００６４】
本明細書で説明するシステムのソフトウェア実装は、コンピュータ可読媒体に格納されるとともに１つまたは複数のプロセッサで実行される、実行可能コードを含んでもよい。コンピュータ可読媒体は、非一時的なものであってもよく、コンピュータハードドライブ、ＲＯＭ、ＲＡＭ、フラッシュメモリ、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、フラッシュドライブ、ＳＤカード、および／もしくは、例えばユニバーサルシリアルバス（ＵＳＢ）インタフェースを有する他のドライブなどの携帯コンピュータ記憶媒体、ならびに／または実行可能コードを格納しプロセッサで実行することができる任意の他の適切な有形もしくは非一時的コンピュータ可読媒体もしくはコンピュータメモリであってもよい。本明細書で説明するシステムは、任意の適切なオペレーティングシステムとの関係で使用してもよい。
【００６５】
本発明の他の実施形態は、本明細書で開示する本発明の明細または実施を考慮することで当業者には明らかになるであろう。明細および実施例は例示的なものとしてのみ見なされ、本発明の真の範囲および精神は以下の請求項によって示されることが意図される。
【図１】
2019009772.tif 000003
【図２】
2019009772.tif 000004
【図３】
2019009772.tif 000005
【図４】
2019009772.tif 000006
【図５】
2019009772.tif 000007
【図６】
2019009772.tif 000008
【図７】
2019009772.tif 000009
【図８】
2019009772.tif 000010
【図９】
2019009772.tif 000011
【外国語明細書】
2019009772000001.pdf