JP2022550223A - 分散データレコード - Google Patents

分散データレコード Download PDF

Info

Publication number
JP2022550223A
JP2022550223A JP2020540614A JP2020540614A JP2022550223A JP 2022550223 A JP2022550223 A JP 2022550223A JP 2020540614 A JP2020540614 A JP 2020540614A JP 2020540614 A JP2020540614 A JP 2020540614A JP 2022550223 A JP2022550223 A JP 2022550223A
Authority
JP
Japan
Prior art keywords
record
digital
transaction
digital record
creating
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2020540614A
Other languages
English (en)
Other versions
JP7504794B2 (ja
Inventor
デ・マトス，ルシオ・ドラジオ・ペドロ
Original Assignee
オラクル・インターナショナル・コーポレイション
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by オラクル・インターナショナル・コーポレイション filed Critical オラクル・インターナショナル・コーポレイション
Publication of JP2022550223A publication Critical patent/JP2022550223A/ja
Application granted granted Critical
Publication of JP7504794B2 publication Critical patent/JP7504794B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/405—Establishing or using transaction specific rules
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/18—File system types
    • G06F16/1805—Append-only file systems, e.g. using logs or journals to store data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6209—Protecting access to data via a platform, e.g. using keys or access control rules to a single file or object, e.g. in a secure envelope, encrypted and accessed using a key, or with access control rules appended to the object itself
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3823—Payment protocols; Details thereof insuring higher security of transaction combining multiple encryption tools for a transaction
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3825—Use of electronic signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3827—Use of message hashing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0643—Hash functions, e.g. MD5, SHA, HMAC or f9 MAC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • H04L9/3066—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy involving algebraic varieties, e.g. elliptic or hyper-elliptic curves
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q2220/00—Business processing using cryptography

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Accounting & Taxation (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • General Engineering & Computer Science (AREA)
  • Strategic Management (AREA)
  • Finance (AREA)
  • General Business, Economics & Management (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • General Health & Medical Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Computing Systems (AREA)
  • Databases & Information Systems (AREA)
  • Pure & Applied Mathematics (AREA)
  • Mathematical Physics (AREA)
  • Mathematical Optimization (AREA)
  • Mathematical Analysis (AREA)
  • Algebra (AREA)
  • Data Mining & Analysis (AREA)
  • Power Engineering (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Storage Device Security (AREA)

Abstract

実施形態は、資産を表すデジタルレコードを作成および照合する。実施形態は、デジタルレコードの作成者に対応する第１の秘密鍵および第１の公開鍵を取得し、デジタルレコードについての１つ以上のパラメータを生成する。パラメータのうちの第１のパラメータは、デジタルレコードのトランザクションに関係している。実施形態は、デジタルレコードについての１つ以上のルールを生成し、ルールのうちの第１のルールは、第１のパラメータに対応するとともにトランザクションを制約する。実施形態は、第１の秘密鍵を使用して、第１の公開鍵、パラメータおよびルールのすべての第１のデジタル署名を計算し、第１の公開鍵、パラメータ、ルールおよび第１のデジタル署名を含む第１のデジタルレコードを作成する。

Description

分野
一実施形態は一般に、データレコードに関し、特に、分散されたデータレコードおよび電子台帳に関する。
背景技術
従来、電子レコードまたは契約の経過を追うために、中央集中型データベースは、すべての資産、所有者、トランザクションなどの経過を追う。１つのパーティによって制御されない信頼されるプラットフォームを使用して、人々が所有権の資産移転を直接的に交渉することを可能にするよう、電子消耗品、トークン、ポイント、通貨、タイトル、イベントチケット、バウチャ、クーポンといったデジタル資産またはデータレコードはしばしば、ピアツーピアの態様で移転可能である必要がある。分散および公開台帳を含むブロックチェーンは、１つのソリューションを提供するが、多くのノードが完全なトランザクション履歴を格納しなければならないので、高い計算コストおよびストレージの制限といった特定の課題を有する。したがって、大規模なストレージを必要とするプロジェクトは、中央集中化を必要とすることになり、パブリックブロックチェーンは完全に好適でなくなる。
発明の概要
実施形態は、資産を表すデジタルレコードを作成および照合する。実施形態は、デジタルレコードの作成者に対応する第１の秘密鍵および第１の公開鍵を取得し、デジタルレコードについての１つ以上のパラメータを生成する。パラメータのうちの第１のパラメータは、デジタルレコードのトランザクションに関係している。実施形態は、デジタルレコードについての１つ以上のルールを生成し、ルールのうちの第１のルールは、第１のパラメータに対応するとともにトランザクションを制約する。実施形態は、第１の秘密鍵を使用して、第１の公開鍵、パラメータおよびルールのすべての第１のデジタル署名を計算し、第１の公開鍵、パラメータ、ルールおよび第１のデジタル署名を含む第１のデジタルレコードを作成する。
本発明の実施形態を実現し得る要素の全体図である。 本発明の実施形態に従ったコンピュータサーバ／システムのブロック図である。 一実施形態に従った、新しい電子レコード／デジタル証明書を作成する際の図２の分散データレコードモジュールの機能のフロー図である。 一実施形態に従った、電子レコードによりトランザクションを実行する際の図２の分散データレコードモジュールの機能のフロー図である。 一実施形態に従った、電子レコードを照合する際の図２の分散データレコードモジュールの機能のフロー図である。 一実施形態に従った、トランザクションルールにより電子レコードを照合する際の図２の分散データレコードモジュールの機能のフロー図である。 一実施形態に従った、サードパーティバリデータ（third party validator）によってレコードを照合する際の図２の分散データレコードモジュールの機能のフロー図である。 一実施形態に従った、付加的なセキュリティを有するサードパーティバリデータに晒される新しいレコードを作成する際の図２の分散データレコードモジュールの機能のフロー図である。 一実施形態に従った、パラメータを複数の子レコードに分割する際の図２の分散データレコードモジュールの機能のフロー図である。 一実施形態に従った、分割されたトランザクションをバリデータリポジトリに記録する際の図２の分散データレコードモジュールの機能のフロー図である。
詳細な説明
実施形態は、中央データベースではなくスタンドアロンファイルにより構成される台帳データベースに関する。実施形態は、情報が中央集中型データベースインスタンスに保持されないが別個のデバイス上に個別に維持され、かつ、各ユーザが自身のレコードを管理することに責任を負うデータレコードまたは証明書のシステムを提供する。ユーザは、自身が所有する個々のレコードの管理人であり、すべての参加者によって信頼され得る態様で、自身のレコードに対するデータ更新を実行可能であり得る。
いくつかの実施形態では、データレコードは、それぞれのデバイスにおいて、当該データの個々の所有者／ユーザの各々によって維持される。データレコードの各所有者に対応するとともにデータレコードを格納するために使用されるデバイスはたとえば、コンピュータデバイス、スマートフォン、ユニバーサルシリアルバス（ＵＳＢ: Universal Serial Bus）ストレージスティック、電子メールもしくはオンラインストレージ、または、紙に印刷されるかもしくは２次元のクイックレスポンス（ＱＲ: Quick Response）コード画像として保存されるデータレコードを含み得る。実施形態における各データレコードは、以下に詳細に開示されるように、従来の中央集中型データベースインスタンスによって提供される同じ特徴のうちのいくつかを送達するのに十分な情報を自身の中に含む。たとえば、当該データレコードは、（１）レコードの起源が真であることを保証し、（２）どの更新が許可され、どの更新が許可されないかを強制し、（３）レコードの現在の状態（すなわち、レコードの現在の所有者を含む各レコードパラメータの現在の値）を確証し、（４）現在の状態がどのようにして現在のようになったかを証明するようにトランザクションの履歴を維持し、（５）認証されていないユーザによってレコードの変更が行われないようにセキュリティを提供するのに十分な情報を自身の中に含む。
各ノードで複製される一般的なデータベースのようなレコードストレージのコストのかかるシステム（すなわち、既知のブロックチェーンシステム）を使用する代わりに、実施形態では、各資産が自身の経過を追う。たとえばブロックチェーンにより、すべてのレコード情報およびトランザクション履歴を管理するデータベースノードの代わりに、実施形態では、データレコードが自由に世界を循環し、それらの所有権およびステータスを管理する。
たとえば、実施形態において、アリスがデジタル「コイン」（すなわち、デジタル署名されたコンピュータファイル）をボブに送る場合、そのコイン（またはファイル）は、署名された履歴を自身の中に保持し、その真正な起源および所有権を証明する。当該デジタル資産が、コイン、トークン、タイトル、チケット、バウチャ、クーポンなどの合計であるか否かにかかわらず、各個々の資産は、マスターデータベースにトランザクションの詳細をログ記録する必要なしに、デジタル資産／レコードがそれ自身を表す態様で、自身の履歴を自身の中に有し、デジタル署名される。資産の所在は、公には完全に未知である。現在誰がどの資産を所有しているかは、公には未知であり得る。その代わりに、その所有者によって保持される可能性が高いファイルが、資産の経過を追うものである。しかしながら、実施形態では、暗号化により、「不正行為」することが極めて困難である。実施形態によると、ユーザは、自身の台帳の管理人であるが、それを調整（temper）することができないか、または、許可されない態様でその値を修正することができない。
実施形態は、楕円曲線デジタル署名アルゴリズム（「ＥＣＤＳＡ: Elliptic Curve Digital Signature Algorithm」）のようなデジタル署名を使用して実現される。ＥＣＤＳＡでは、レコード作成およびトランザクションは、シークレットな秘密鍵によって署名され、関係する公開鍵によって照合される。レコードは、その作成者の秘密鍵によって作成および署名され、署名を照合するのに使用され得る署名文字列が残される。次のトランザクションまたはレコード更新が、再び署名され、これにより、署名されたコンテンツの部分として以前の署名を含むレコードの署名が生成される。レコードは、更新されるたびに、すべての以前の署名を含むレコードの署名を再び生成し、署名の上に署名のチェーンを作成する。そのため、履歴の任意の部分が調整される場合、署名は、照合中に予測される値とマッチしない。さらに、レコードは、どの更新が許可、禁止または必要とされるかを記述するメタデータも含む。メタデータに記述されるこれらのルールも、署名によって保護される（すなわち、ルールテキストが変更されると、署名は照合にパスしない）。レコードの照合が、署名の照合と、任意のあらかじめ定義されたトランザクションルールへの準拠の照合との両方をともに必要とするので、実施形態は部分的に新規である。レコードは、両方の照合にパスした場合にのみ真である。
図１は、本発明の実施形態を実現し得る要素の全体図である。実施形態は、ネットワーク１１０を介して、連続的または断続的に互いに通信し得る個々のデバイス１０１～１０８に関する。各デバイス１０１～１０８は、命令を実行するためのプロセッサ／コントローラ（またはハードウェア実現例）と、ファイルを格納するためのストレージデバイスと、他のデバイスと通信するための通信デバイスとを含む任意のタイプのデバイスである。デバイス１０１～１０８は、デスクトップまたはラップトップコンピュータ、サーバ、スマートフォン、タブレット、ウォッチなどを含み得る。ネットワーク１１０は、インターネットまたはローカルネットワークのような任意のタイプの通信メカニズムであり得るか、または、異なるネットワークの組み合わせであり得る。サードパーティバリデータを使用する以下に開示される実施形態では、図１のデバイスのうちの１つがバリデータとして機能する。
図２は、本発明の実施形態に従ったコンピュータサーバ／システム１０のブロック図である。単一のシステムとして示されているが、システム１０の機能は分散システムとして実現され得る。さらに、本明細書において開示される機能は、ネットワークを介してともに結合され得る別個のサーバまたはデバイス上で実現され得る。さらに、システム１０の１つ以上の構成要素は含まれなくてもよい。複数のシステム１０は、図１の要素のすべてのために機能を提供し得る。
システム１０は、情報を通信するためのバス１２または他の通信メカニズムと、情報を処理するための、バス１２に結合されるプロセッサ２２とを含む。プロセッサ２２は、任意のタイプの汎用または特定目的のプロセッサであってもよい。システム１０はさらに、情報と、プロセッサ２２によって実行されるべき命令とを格納するためのメモリ１４を含む。メモリ１４は、ランダムアクセスメモリ（「ＲＡＭ」: random access memory）、リードオンリーメモリ(「ＲＯＭ」: read only memory)、磁気ディスクもしくは光ディスクのようなスタティックストレージ、または、任意の他のタイプのコンピュータ読取可能媒体の任意の組み合わせにより構成され得る。システム１０はさらに、ネットワークへのアクセスを提供するために、ネットワークインターフェイスカードのような通信デバイス２０を含む。したがって、ユーザは、システム１０と直接的に、ネットワークを介してリモートに、または、任意の他の方法で、インターフェイスにより接続し得る。
コンピュータ読取可能媒体は、プロセッサ２２によってアクセスされ得る任意の利用可能な媒体であり得、揮発性および不揮発性媒体の両方と、取り外しできるおよび取り外しできない媒体と、通信媒体とを含む。通信媒体は、コンピュータ読取可能命令、データ構造、プログラムモジュール、または、搬送波もしくは他のトランスポートメカニズムのような変調されたデータ信号における他のデータを含み得、かつ、任意の情報送達媒体を含む。
プロセッサ２２はさらに、バス１２を介して、液晶ディスプレイ（「ＬＣＤ: Liquid Crystal Display」）のようなディスプレイ２４に結合される。キーボード２６およびコンピュータマウスのようなカーソル制御デバイス２８はさらに、ユーザがシステム１０とインターフェイスにより接続することを可能にするよう、バス１２に結合される。
一実施形態では、メモリ１４は、プロセッサ２２によって実行されると機能を提供するソフトウェアモジュールを格納する。モジュールは、システム１０のためのオペレーティングシステム機能を提供するオペレーティングシステム１５を含む。モジュールはさらに、それぞれのデバイスのための分散データレコード機能と、本明細書において開示されるすべての他の機能とを提供する分散データレコードモジュール１６を含む。システム１０は、より大きなシステムの部分であり得る。したがって、システム１０は、付加的な機能を含むよう、トランザクションベースのシステム、デジタルウォレット、または、デジタル資産を利用する任意の他のタイプのアプリといった１つ以上の付加的な機能モジュール１８を含み得る。ファイルストレージデバイスまたはデータベース１７は、バス１２に結合され、これにより、モジュール１６および１８と、データレコードファイルと、デジタル署名のような任意の他の必要なデータとのための中央集中型ストレージデバイスを提供する。一実施形態では、データベース１７は、格納されたデータを管理するためにストラクチャードクエリランゲージ（「ＳＱＬ: Structured Query Language」）を使用し得るリレーショナルデータベース管理システム（ＲＤＢＭＳ: relational database management system）である。
一実施形態では、特に単一のデバイスにおいて多数の分散ファイルが存在する場合、データベース１７は、インメモリデータベース（「ＩＭＤＢ: in-memory database」）として実現される。ＩＭＤＢは、主にコンピュータデータストレージのためのメインメモリに依拠するデータベース管理システムである。これは、ディスクストレージメカニズムを使用するデータベース管理システムと対照をなす。メインメモリデータベースは、ディスクが最適化されたデータベースよりも高速である。その理由は、ディスクアクセスは、メモリアクセスよりも遅く、内部最適化アルゴリズムは、よりシンプルであるとともにより少ないＣＰＵ命令を実行するからである。メモリ内のデータにアクセスすることにより、データをクエリ送信する際のシーク時間が解消され、これにより、ディスクよりも高速かつ予測可能なパフォーマンスが提供される。
一実施形態では、データベース１７は、ＩＭＤＢとして実現される場合、分散データグリッドに基づいて実現される。分散データグリッドは、コンピュータサーバの集合が１つ以上のクラスタで一緒に動作して、分散またはクラスタリングされた環境内において、情報および計算のような関係する動作を管理するシステムである。分散データグリッドは、サーバにわたって共有されるアプリケーションオブジェクトおよびデータを管理するよう使用され得る。分散データグリッドは、低応答時間、高スループット、予測可能なスケーラビリティ、連続的な可用性、および、情報の信頼性を提供する。特定の例では、たとえばオラクル社の「Oracle Coherence」データグリッドのような分散データグリッドは、より高いパフォーマンスを達成するために情報をインメモリに格納し、かつ、複数のサーバにわたって同期されるその情報のコピーを保持することにおいて冗長性を利用しており、これにより、システムの復元力と、サーバの障害時にデータの継続的な可用性とが保証される。
一実施形態では、システム１０は、企業組織のためのアプリケーションまたは分散されたアプリケーションの集合を含むコンピューティング／データ処理システムであり、ロジスティクス管理機能、製造管理機能、および、在庫管理機能も実現し得る。アプリケーションおよびコンピューティングシステム１０は、クラウドベースのネットワーキングシステム、ソフトウェア・アズ・ア・サービス（ＳａａＳ: software-as-a-service）アーキテクチャ、もしくは、他のタイプのコンピューティングソリューションにより動作するように構成されてもよいし、または、クラウドベースのネットワーキングシステム、ソフトウェア・アズ・ア・サービス（ＳａａＳ: software-as-a-service）アーキテクチャ、もしくは、他のタイプのコンピューティングソリューションとして実現されてもよい。
開示されるように、実施形態は、各分散された資産が自身を表し、どのタイプのトランザクションが許可されるかを制御するメタデータを担持する分散された資産／レコードを提供する。これは、（ただ１つの資産ではなく）資産のすべての完全な台帳として機能するとともに各ユーザによって格納される共有された台帳に依拠するブロックチェーンシステムとは対照的である。いくつかの実施形態では、デジタル資産が分散データレコードとして機能し、サードパーティバリデータが照合のために使用される。
分散デジタルデータレコード
デジタルレコード、デジタル資産、または、「証明書ファイル」は、誰が何を所有しているかを証明する。本発明の実施形態の文脈では、証明書ファイルは、チケット、コイン、データ、バウチャ、デジタルアート、電子デバイス、有形の対象物、または、サービスといった資産を表す。証明書ファイルは、所有者アドレスを含む。所有者アドレスは、そのアドレスについて署名可能なシークレットな秘密鍵に関連付けられる。資産は、デジタル署名のチェーンとして表される。トランザクションは、その所有者が、以前のトランザクションのハッシュと、次の状態のパラメータとにデジタル署名し、公開鍵を付加し、照合可能なチェーンを作成することによって記録される。ブロックチェーンベースの台帳では、この署名チェーンはブロックチェーンサーバ上に記録される。対照的に、実施形態によれば、ユーザのデバイス上において、各証明書が自身内にこの署名チェーンを担持する。
例として、アリスは、自身が作製した１００個のカスタムギターの購入者に与えられることになる１００個の真正性証明書のセットを開始し得る。ボブは、２００，０００個の「ボブコイン」のプールを開始し得る。キャロルは、フェアのための食べ物および飲料のチケットのプールを開始し得る。これらの資産は、証明書ファイルとしてピアツーピアでトレードされる。ウォレットアプリおよびＱＲコード（登録商標）を使用して、これらのアイテムは取得、使用、贈呈、または、販売され得、それらの証明書は、新しいアドレスに移転され得、他のアドレスの間で分割または統合され得、連続する証明書ファイルに起源を与える。各その後の証明書ファイルは、その由来（pedigree）の照合可能な署名履歴を含む。
したがって、デイブが分散データレコードファイルによって経過を追われる資産を所有する場合、デイブは、そのファイルを、自身が望む任意の場所に格納し得る。デイブがそのレコードを移転または履行すると決定すると、デイブのウォレットアプリは、新しいレコードファイルのパラメータを認証するデジタル署名を提供する。実施形態によれば、デイブがそのトランザクションを行うと、デイブの古いレコードファイルは無効にならなければならない。これは、相対的に少量のオンラインデジタル情報により達成されることになり、デイブは、もはや古いレコードファイルを再び使用できないようになる。古いファイルがもはや受け入れられないことを全世界が知らなければならないからである。そうでなければ、デイブは、二重支払い（double-spend）することが可能になる。
サードパーティバリデータリポジトリ
実施形態において、デジタルレコード／資産／証明書は、スタンドアロンのデジタルファイルである。しかしながら、いくつかの実施形態では、それらの完全性の証明（proof of integrity）は、相対的に少量のデジタル情報が、オンラインであることを必要とし、かつ、現在有効な証明書の各々の暗号チェックサムの形態でネットワーク(たとえば、バリデータサーバ)を介して利用可能であることを必要とし得る。証明書は、そのチェックサムダイジェスト（checksum digest）がリポジトリに存在する場合、有効である。署名されたトランザクションがポストされると、新しい子証明書のチェックサムダイジェストが挿入されるので、実施形態は、親証明書のチェックサムダイジェストがリポジトリから除去されることを保証することによって、二重支払いを防止する。
実施形態は、分散コンセンサスアルゴリズム（distributed consensus algorithm）を提供しない。プライベート台帳または共同台帳の場合、バリデータ（またはチェックサムダイジェストリポジトリ）はプライベートな分散データベースであり得る。分散台帳の場合、このリポジトリは、ブロックチェーンスマートコントラクトまたはハッシュグラフなどといった分散型アルゴリズム上で動作すべきである。それにもかかわらず、照合リポジトリを運用するエンティティは、資産、アドレス、もしくは鍵に対する制御を有さないので、偽造の証明書を発行することができない。リポジトリは、解しがたい(obscure)なチェックサムハッシュ値を管理するだけであるので、造幣局（mint authority）ではない。その唯一の目的は二重支払いを止めることであり、デジタル資産がバイト単位でどれほど大きくても、そのために必要なストレージは非常に少ない。リポジトリ内のチェックサムハッシュダイジェストのリストが如何なる有用な情報も提供できないので、プライバシーは非常に高い。
電子データレコード／資産の作成および照合
図３Ａは、一実施形態に従った、新しい電子レコード／デジタル証明書を作成する際の図２の分散データレコードモジュール１６の機能のフロー図である。一実施形態では、図３Ａ（および以下の図３Ｂおよび図４～図９）のフロー図の機能がメモリまたは他のコンピュータ読取可能もしくは有形媒体に格納されるソフトウェアによって実現され、プロセッサによって実行される。他の実施形態では、当該機能は、ハードウェアによって（たとえば、特定用途向け集積回路（「ＡＳＩＣ: application specific integrated circuit」）、プログラマブルゲートアレイ（「ＰＧＡ: programmable gate array」）、フィールドプログラマブルゲートアレイ（「ＦＰＧＡ: field programmable gate array」）などの使用を通じて）、または、ハードウェアおよびソフトウェアの任意の組み合せによって実行され得る。
３０２において、レコード作成者の秘密鍵／公開鍵の対（たとえば、楕円曲線デジタル署名鍵の対）が取得される。３０４において、以下により詳細に記載される少なくとも１つのパラメータを含む新しい電子レコードが書き込まれる。３０６において、レコード作成者の秘密鍵および全レコード情報を、作成者の公開鍵を含むメッセージテキストとして使用して、デジタル署名が計算され、これにより署名ハッシュ値が得られることになる。３０８において、デジタル署名値がレコードに追加される。
図３Ａの機能の例として、デジタルレコードは以下の通りである。
Figure 2022550223000002
上記のデジタルレコードの例および本明細書における他のすべての例は、読みやすさのためにJavaScript Object Notation（「ＪＳＯＮ」）で記述されている。しかしながら、レコードは、特殊文字で区切られたフィールド（たとえばカンマで区切られたファイルもしくはタブで区切られたファイル）、タグで区切られたフィールド（Extensible Markup Language（「ＸＭＬ」）など）、または、固定幅で区切られたフィールド、または、行番号で区切られたフィールドを有するデータレコードを含む任意のフォーマットであり得る。レコードは、人間が読むことが可能なテキストであり得るか、または、バイナリフォーマットもしくは圧縮フォーマットといった人間が読むことが不可能であり得る。レコードは、リードアクセスメモリ（「ＲＡＭ: Read Access Memory」）における情報であり得るか、または、データベースのコンテンツのようなより大きなデータセットのセグメントとして格納される情報であり得るので、コンピュータファイルとして表される必要はない。本明細書に開示される例では、ＪＳＯＮが使用されるので、ＪＳＯＮは定義上ソートされないことが言及される。ＪＳＯＮレコードは、異なる順序でパラメータを有し得るが、それでも等しいと考えられ得る。実施形態はデジタル署名およびチェックサムハッシュの使用を採用するので、レコードは、すべてのクライアントによって、プロセスのすべての部分において一貫して同じでなければならない。これは、ＪＳＯＮフォーマット（または任意のソートされないフォーマット）を使用する場合、署名、チェックサム、および、照合が決定論的であることを保証するために、すべての参加者は、同一の順序およびフォーマット（インデンテーション、改行など）でパラメータを扱わなければならず、これにより常に同じ結果が達成されることを意味する。
上記デジタルレコードは、「Hello word!」という値を有する「メッセージ（message）」というパラメータを有する。レコードは、「作成者（creator）」の公開鍵と、作成者のシークレットな秘密鍵を使用して計算されたデジタル署名とを示す。
以下の第２の例では、レコードは、さらに多くのパラメータを含む。作成中、作成者は既にレコードの所有権を別の鍵の対に割り当てており、次いで、以下のようにそれに署名する。
Figure 2022550223000003
デジタル署名は、署名するべきメッセージとして、秘密鍵およびレコードの全コンテンツを使用して計算される。トランザクションパラメータ「to」は、デジタル署名されるべきメッセージの部分である。
Figure 2022550223000004
という署名は、レコードに追加される。その後、当該レコードは保存されるか、または、その意図される宛先に送られる。
図３Ｂは、一実施形態に従った、電子レコードによりトランザクションを実行する際の図２の分散データレコードモジュール１６の機能のフロー図である。
３１０において、関連するレコードが取得される（すなわち、ストレージから抽出される）。３１２において、所有権の移転および／または１つ以上のパラメータの値への変更といった新しいトランザクションが、レコードに追加される。３１４において、修正されたレコードは、入力メッセージとして、レコード上のすべての情報を使用してデジタル署名され、すべての以前のトランザクションおよび署名を含み、現在のトランザクションに関する詳細を含む。最低でも、署名される情報(すなわち、署名アルゴリズムへの入力メッセージ)は少なくとも、最も最近の以前の署名を含まなければならない。なぜならば、最も最近の以前の署名は、以前に発生したすべてと、修正されたパラメータ値またはレコード所有権の変更といった現在のトランザクションに関する詳細とを既に証明しているからである。しかしながら、いくつかの実施形態では、すべての以前のトランザクションおよび署名、または、レコードのパラメータ値が、署名されるメッセージの部分としてさらに含まれ得る。現在のレコード所有者の秘密鍵は、デジタル署名を計算するために使用される。３１６において、デジタル署名値は、現在のトランザクションの部分として、レコードに追加される。
図３Ｂの機能の例として、１つの署名されたトランザクションを含むレコードが既に受け取られたと仮定する。第２のトランザクションおよび第３のトランザクションにデジタル署名を追加した後、レコードは以下のようになる。
Figure 2022550223000005
Figure 2022550223000006
上記の例では、レコードは、既に１つのトランザクションを有しており、当該１つのトランザクションは所有権の移転であった。第２のトランザクションがレコードに追加され、「タイトル（title）」パラメータの更新が行われ、次いで、第３のトランザクションが追加され、所有権の別の変更が行われた。
その後のトランザクションは、上記のステップを繰り返すことによって何度も実行され得、レコードは、順次記録される署名されたトランザクションにより増加する。最も最近の署名の値は、入力の部分として、すべての以前の署名を含む計算の積である。誰かが当該ファイル内のどこかにおいて何かを修正しようとした場合、最後のデジタル署名は照合不能または無効になる。
上記の例では、レコードは、所有権の複数の移転を有していた。この場合、レコードの現在の所有者は、最新の移転の「to」フィールド内の公開鍵に関連付けられる秘密鍵を制御する任意のものである。この例では、現在レコードを制御するのは公開鍵／秘密鍵の対である。
いくつかの実施形態は、複数の所有者が同時にレコードを所有することを可能にする。そのような場合、レコードの所有者は、複数のアドレスによって、または、導出されたアドレスを使用しない場合は公開鍵によって、識別され得る。たとえば、所有者は、カンマで分離されたアドレス文字列のアレイによって表され得る。この場合、レコードは、所有者のいずれか、いくつか、または、すべてがトランザクションに署名することを必要とし得る。複数の所有者を伴うトランザクションを達成するために、一所有者がトランザクションに署名し、デジタル署名を生成し、それをレコードに追加し、次いで、結果得られたレコードを次の所有者に渡し、同じトランザクションに署名し、当該署名も同様に追加する。トランザクションは、すべての要求された所有者がそれに署名した後、確定されたと考えられる。そのような実施形態では、トランザクションを照合することは、複数の所有者によって署名された複数のトランザクションの各々を照合することをそれぞれ必要とする。
図４は、一実施形態に従った、電子レコードを照合する際の図２の分散データレコードモジュール１６の機能のフロー図である。
４０２において、照合すべき電子レコードが取得される。４０４において、照合すべき第１の（または次の）トランザクションが選択される。レコードが複数のトランザクションを含む場合、プロセスは、特定の順序が必要とされないので、任意のものから開始し得る。４０６において、署名ハッシュ値および公開鍵文字列は、レコードの署名されたトランザクションから抽出される。これら２つの値は、署名が有効か否かを照合する関数において入力として使用されることになる。署名を照合するために、実施形態は、署名時に使用されたものと同一の入力メッセージを取得しなければならない。これを行うために、署名文字列は、署名時にまだ存在していなかったので、除去され、この時点で照合されたものの後に行われたすべてのトランザクションが除去される。４０４および４０６の機能は、任意の順序で行なわれ得る。
４１０において、３つの重要な情報が取得されているので、署名照合アルゴリズムが呼び出され／実行され、デジタル署名が有効か否かを照合する。論じられたように、当該３つの情報は、（１）署名時のレコードの状態であった、署名されたオリジナルメッセージのコピーと、（２）署名したものの入力メッセージに署名するために使われるシークレットな秘密鍵に対応する公開鍵（対）と、（３）トランザクション上に記録された署名ハッシュ値とである。これら３つの要素により、公開鍵に対応するシークレットな秘密鍵により署名が実際に生成されたか否かを確認する関数が実行され得る。したがって、実施形態は、レコードの作成者または任意のその後のトランザクションの作成者の秘密鍵を知る必要性を回避している。一実施形態では、使用される関数が楕円曲線デジタル署名アルゴリズムであるが、他のアルゴリズムが使用され得る。署名アルゴリズムは、すべての参加者によって既知であると仮定される。たとえば、レコードが楕円曲線デジタル署名アルゴリズムを使用して署名および照合される場合、曲線がファイル中に指定されていないので、当該曲線は、当該ファイルを照合するプログラムによって既知であると仮定される。
４１０において、まったく同じメッセージを使用して、公開鍵に対応する秘密鍵により署名が実際に生成されたことを関数が確認した場合、４１２において、関数は４１４に進む。当該照合が失敗した場合、４１８において、関数は、失敗（すなわち、レコードは有効ではないこと）を返した後に終了する。
４１４において、照合すべき付加的なトランザクションが存在する場合、機能は４０４において継続する。そうでなければ、４１６において、レコードが有効であること（すなわち、照合成功）が返され、機能が終了する。
図４の機能の例として、２つのトランザクション（両方とも一方のレコード所有者から別のレコード所有者への移転）を有する以下のサンプルレコードを仮定する。
Figure 2022550223000007
上記のレコードを照合するために、図４の機能は、１つの署名されたトランザクションをチェックすることによって開始する。どちらのトランザクションでもよい（特に順序は必要ない）が、この例では、機能は第１のトランザクションから開始する。
１）第１のトランザクション上の公開鍵は、以下のとおりである。
Figure 2022550223000008
２）第１のトランザクション上の署名ハッシュ値は、以下のとおりである。
Figure 2022550223000009
３）第１のトランザクションにおいて署名されたオリジナルメッセージ入力は、以下のとおりである。
Figure 2022550223000010
これら３つの情報は、署名が実際に秘密鍵を使用して生成されたか否かを照合するために使用される。当該テストにパスした場合、他のすべてのトランザクションについて同じことが行われる。しかしながら、トランザクションは、すべてのその後のトランザクションを除外するがすべての以前のトランザクションを含む入力メッセージを使用して照合される。したがって、第２のトランザクションをテストする場合、第１のトランザクションに関する詳細は、署名された入力メッセージの部分になる。
第２のトランザクションを照合する入力メッセージの抽出されたコピーは、一例において（署名なしで）次のように表される。
Figure 2022550223000011
アドレスの使用
実施形態において、アドレスは、公開鍵から導出されるハッシュ値、または、鍵の対の公開部分である。たとえば、レコードが「アドレス（address）」に移転される所有権を有する場合、受信者の公開鍵は、いくつかの実施形態では、将来の署名が行われるまでシークレットのままであり得る。この随意のセキュリティ対策が必要とされ得るのは、使用されるデジタル署名アルゴリズムに依存して、使用されるまで公開鍵をシークレットにしておくことが最善であり得るからである。クライアントアプリケーションの読みやすさのために、レコードは、作成者のアドレスおよび現在の所有者のアドレスについてのトップレベルのパラメータも含み得るので、クライアントアプリケーションは、トランザクション履歴からその情報を抽出する必要はない。
このセキュリティ対策を使用する実施形態では、当該機能は、レコードを制御する鍵の対が、公開鍵自体ではなく公開鍵のハッシュによって識別されることを除いて、図３Ａ、図３Ｂ、および図４の機能と同様である。
トランザクションルール
いくつかの実施形態では、電子レコードは、許可されたパラメータ値変更、禁止されたパラメータ値変更、または、必要とされるパラメータ値変更を命令するメタデータを含み得る。たとえば、数値パラメータは、１つ以上の数学的比較を常に満たす必要がある。その例としては、１つ以上のあらかじめ定義された値、別のパラメータもしくは関数の値に等しいこと、および／または、それよりも小さいこと、および／または、それよりも大きいこと、および／または、それとは異なることが挙げられる。テキストパラメータは、１つ以上のフォーマットまたは値の比較を満たす必要があり得る。その例としては、フォーマットマスクもしくは正規表現を満たす必要があること、または、別のフィールドからの値もしくは許可された値のあらかじめ定義されたリストからの値にマッチする必要があることが挙げられる。日時パラメータは、特定の日時もしくは日時の範囲、または、別の日時パラメータの値と等しいか、それより大きいか、それより小さいか、または、それとは異なる値を有する必要があり得る。
パラメータ値の更新は、ルールによって必要とされ得る。レコードは、あるイベントに応答して、１つ以上のパラメータが更新されることを命令するメタデータを含み得る。たとえば、レコードは、レコード所有権の変更がトランザクションによって行われるたびに、あらかじめ定義された係数１だけ「transfer_counter」という数値パラメータがインクリメントされることを必要とし得、パラメータは許可される移転の最大数に制限を課すために使用される。
パラメータ制約を有するレコードを作成するための機能は、図３Ａに示すように、１つ以上のパラメータが任意の条件を満たす値を有さなければならないか否かを説明する付加的なメタデータをレコード自体が含むことを除いて、「基本」レコードを作成する機能と同じである。
パラメータ制約を有する例示的なレコードは、以下のとおりである。
Figure 2022550223000012
上記のレコードでは、各パラメータは、特定されるいくつかのルールを有する。「スピード（Speed）」および「アビリティ（Ability）」というパラメータは、読み取り専用であり、修正され得ない。
「ステータス（Status）」というパラメータは、修正され得るが、テキスト値のあらかじめ定義されたリストとマッチしなければならない。
「移転（Transfers）」というパラメータは、読み取り専用であり、ユーザによって意図的に修正され得ないが、トランザクションが所有者を変更するたびに係数１だけインクリメントする必要があり、１０の最大値を有する。したがって、レコードは、１０回移転された後、もはや新しい所有者に移転され得ないか、そうでなければ、照合中に条件が満たされないことになる。
パラメータ値によって実現されるこれらのルールは、レコードにおいてドキュメント化され、それらのテキストは、レコード作成者によって署名される。したがって、別のユーザは、作成者の署名を無効にすることになるので、ルール定義を修正し得ない。ルールは、作成者の署名によって保護される。
パラメータ制約を含むレコードを照合するために、当該機能は、パラメータなしであって１つの付加的なタスクを有する場合と同様である。すなわち、トランザクションを照合する際、すべてのルール要件がトランザクションによって満たされているか否かをチェックし、任意のトランザクションによって、レコード作成者によって定義されたルールを満たさないパラメータ値が得られた場合には無効を返すよう、あらかじめ定義されたトランザクションルールを有する各レコードパラメータが比較されなければならない。
照合機能は、任意の順序で実行され得る。その例としては、（１）最初にすべてのトランザクションについてすべての署名を照合し、次いで、すべてのトランザクションについてすべてのルールを照合すること、（２）最初にすべてのトランザクションについてすべてのルールを照合し、次いで、すべての署名を照合すること、（３）各トランザクションについて、すなわち、一度に１つのトランザクションについてルールコンプライアンスおよび署名を照合すること、または、（４）各トランザクションについて、すなわち、一度に１つのトランザクションについて署名およびルールコンプライアンスを照合することが挙げられる。すべての署名およびすべてのルールが照合される限り、順序は重要でない。
図５は、一実施形態に従った、トランザクションルールにより電子レコードを照合する際の図２の分散データレコードモジュール１６の機能のフロー図である。
図５の機能は、図４の同じ機能を含むが、以下が追加される。５０２において、メタデータが、チェックすべき任意の(または次の)ルールについてチェックされる。たとえば、許可される最大値を有するパラメータであり得る。５０４において、ルール要件がトランザクション値の変更と比較される。たとえば、許可される最大トランザクション値が１０であることをルールが特定する場合、トランザクションは、１１に更新される値を有する。５０６において、ルールに違反した場合、４１８においてレコードは無効である。そうでなければ、５０８において、機能は５０２において継続する。
サードパーティバリデータ
実施形態では、電子レコードが更新されると、レコードの以前のバージョンが古くなり、もはや有効でなくなることがしばしば必要とされる。たとえば、レコードが所有権を変更する場合、以前の所有者が有する古いバージョンは無効になるべきである。レコードのシステムは、競合状態または「二重支払い」を回避するために、時系列的な状態である必要があり得る。これは、サードパーティバリデータを使用することによって解決され得る。レコードの作成、トランザクション、および、照合は、レコードが古いかまたは現在のものであるかを識別し得るサードパーティサービスに送信され得る。オンラインバリデータは、現在有効なレコードのリストを維持することによって、レコードが現在のものかまたは古いものかを確認し得る。そのリポジトリ（ファイル、ディレクトリ、データベース、または、データ構造であり得る）は、各レコードの全コピーを維持する必要はない。その理由は、各現在有効なレコードのチェックサムのみを必要とするからである。チェックサムは非常に短い文字列であり得る。任意のサイズのレコードは、レコードのチェックサムがバリデータリポジトリに存在する場合、有効であると確認され得る。
サードパーティバリデータに晒される新しいレコードを作成するために、図３Ａの新しい署名されたレコードを作成するための機能が実現される。次いで、レコードがデジタル署名を含んだ後（すなわち、３０８の後）、ｍｄ５、ｋｅｃｃａｋまたはＳＨＡのようなハッシュアルゴリズムを使用して、レコードのチェックサムハッシュを計算するよう、入力メッセージとしてレコードが使用される。次いで、チェックサムは、オンラインリポジトリまたはデータベースに挿入され、このことは、クレデンシャルおよび作成特権を必要とし得る。バリデータリポジトリにおけるチェックサムは、レコードが正当であることを示すことになる。
図６は、一実施形態に従った、サードパーティバリデータによってレコードを照合する際の図２の分散データレコードモジュール１６の機能のフロー図である。図６の機能は、６０２において、サードパーティバリデータチェックサムを含む更新されたレコードをサードパーティにおいて受け取った後に実現される。
６０４において、更新を受け取る古いレコードが実際に有効であるか否かをチェックする必要がある。これは、古いレコードのチェックサムがリポジトリに存在するか否かをチェックすることによって行われる。これを行うために、レコードの古いバージョン（つまり、トランザクションの前のもの）を取得するために、最新のトランザクションがレコードから除去される。
６０６において、レコードの古いバージョンのチェックサムハッシュが計算される。６０８において、古いレコードのチェックサムがリポジトリに存在する場合、当該古いレコードは有効である。６０８において「ＮＯ」の場合、古いレコードは無効であり、照合は失敗する。たとえば、古いレコードは、最初にポストされた別のトランザクションによって既に古くなっている場合がある。
６０８においてＹＥＳの場合、６１０において、新しい更新されたレコードが図４および図５の機能を使用して照合される。これは、トランザクション署名が実際にレコードの現在の所有者の秘密鍵により署名されているか否かをチェックすることと、任意の潜在的なルール違反についてチェックすることとを意味する。古いレコードのチェックサムは既に照合されているので、すべてのトランザクション履歴を再度照合する必要はない。新しいトランザクションのみが照合される必要がある。
６１２において、新しい（更新された）レコードが有効な場合は、６１４に進む。しかしながら、新しいトランザクション署名が無効であるか、または、ルールに違反している場合、当該照合は失敗する。
古いレコードおよび新しいレコードが照合されたので、６１４において古いファイルのチェックサムを除去し、６１６において新しいファイルのチェックサムを挿入することが安全である。使用されるデータリポジトリのタイプに依存して、６１４および６１６は、「除去および挿入」ではなく、１つの「更新」に統合され得る。除去／挿入のメソッドを使用する場合、使用されるデータベース管理システムは、アトミックな変更（atomic change）を保証する機能を提供し得、これは、削除および挿入の両方が成功するか、または、両方が失敗することを意味する。
図６の機能を使用して、要求者は、（１）レコードのチェックサムハッシュを計算するステップと、（２）チェックサムが有効である（存在する）か、または、無効である（発見されない）かを確認するようサードパーティバリデータに要求するステップという２つのシンプルなステップを実行することによって、サードパーティバリデータを使用して、レコードが有効か否かを照合し得る。
一実施形態では、具体的には、オンラインバリデータリポジトリが、たとえばプライベートシステム、または、評判のよい分散アルゴリズム（たとえば、評判のよい分散システム上のオープンソーススマートコントラクト）において完全に信頼されている場合、署名チェーンはレコードからオミットされ得る。すべてのトランザクションが、リポジトリの更新前にオンラインバリデータによって照合されるため、署名チェーンは暗黙的であり得る。換言すると、チェックサムダイジェストがオンラインリポジトリに存在する場合、すべての以前のトランザクションが信用可能（honorable）でなければならない。そうでなければ、チェックサムはリポジトリにおいて発見されない。この実施形態は、レコードの完全なトランザクション履歴を維持するための、レコードについての必要性を除去する。このモデルを採用するシステムは、レコードの部分としてトランザクション履歴を除外するレコードを作成および更新するよう、最初から設計および開発されなければならない。これにより、レコードファイルサイズが大きくなりすぎることが防止される。さらに、レコードの以前の所有者が未知であるので、所望の場合、究極的なプライバシーが提供される。しかしながら、これは、リポジトリ（オンラインバリデータ）が完全に信頼され得る場合にのみ有益であり、いつもそうであるとは限らない。さらに、いくつかのユースケースでは、トランザクション履歴は、他の理由のために依然として必要とされ得る。その例としては、レコードが、予測される所有権を通過したことを照合することが挙げられる。
いくつかの実施形態では、レコードの記載されたシステムは、特定のソフトウェアと、単一のオンラインバリデータと、既知の作成者鍵と、既知の署名アルゴリズムと、既知のチェックサムアルゴリズムとにより動作し得る。しかしながら、他の実施形態では、一般的なレコードのシステムが、多くの異なるソフトウェア（たとえば、異なるスマートフォンウォレット）と、多くのレコード作成者と、多くの使用されるアルゴリズムと、多くのバリデータサービスとを使用して作成され、トランザクションされ、かつ、照合される。したがって、実施形態では、電子レコードは、ユニバーサルなフレームワークを促進するよう、以下の付加的なパラメータを含み得る。
（Ａ）ユーザおよびクライアントアプリケーションが作成者のアドレスを照合することを可能にする、作成者のハイパーテキスト転送プロトコル（「ＨＴＴＰ: Hyper Text Transfer Protocol」）ユニフォームリソースロケータ（「ＵＲＬ: Uniform Resource Locator」）についてのパラメータ。たとえば、ＡＣＭＥ．ＣＯＭという会社が、レコードを作成する場合、ＡＣＭＥ．ＣＯＭドメイン上にページをポストし得、これにより、ユーザおよびアプリケーションが自身の公式なアドレスまたは公開鍵を取得することが可能になる。ウォレットアプリは、検査されているレコードが、その公開部分がＡＣＭＥ．ＣＯＭによって提供される鍵を使用して署名されているとユーザに通知し得る。
（Ｂ）バリデータサービスのＨＴＴＰ ＵＲＬについてのパラメータ（すなわち、レコードを照合する場所をクライアントアプリケーションに指示すること）。
（Ｃ）使用される署名アルゴリズムについてのパラメータ。たとえば、楕円曲線を使用する場合、他のアプリケーションがファイルを照合することができるように、どの曲線が使用されるかを示すパラメータ。
いくつかの実施形態は、作成者の鍵が一度のみ使用され得ることを保証するようセキュリティオプションを提供する。これは、作成者のシークレットな秘密鍵が損なわれた場合に望ましく、または、作成者が同じの鍵を使用して付加的なレコードを作成する能力を有することがなく、これにより、供給が制限されることをユーザが確信したい場合に望ましい。これを達成するために、サードパーティオンラインバリデータは、作成者の公開鍵（またはアドレスを使用している場合はアドレス）を、以前に使用された鍵（またはアドレス）のリストに付加し得る。任意の新しいレコードの作成が完了する前に、サードパーティバリデータは、作成者の鍵が、過去のレコードを作成するために以前に使用されたか否かをチェックし得る。
図７は、一実施形態に従った、付加的なセキュリティを有するサードパーティバリデータに晒される新しいレコードを作成する際の図２の分散データレコードモジュール１６の機能のフロー図である。図７の機能は、サードパーティバリデータに晒される新しいレコードを作成するための上で開示された機能に追加される。
７０２において新しいレコードを挿入する要求を受け取った後、７０４において、新しく作成されたレコードは正しく署名されていると照合され（すなわち、署名が、作成者の公開鍵に対して照合され）、７０６において、以前に使用された鍵またはアドレスの経過を追うリスト、ディレクトリ、または、データベースに対してクエリ送信することによって、作成者の鍵が以前に使用されていないと照合される。７０４および７０６は、任意の順序で実行され得る。
７０８において、作成者の鍵（またはアドレス）が、以前に使用された鍵またはアドレスの経過を追うリスト、ディレクトリ、または、データベースに挿入される。７１０において、新しいレコードのチェックサムが作成される。７１２において、チェックサムは、有効なレコードのリスト、ディレクトリまたはデータベースに挿入される。
レコード分割
実施形態において、レコードは、分割可能な数値パラメータを有し得る。たとえば、アカウントを表すレコードは、ポイント、通貨、株式、または、分割可能な任意の数値の残高を有し得、当該残高は、部分的に他の所有者に割り当てられ得る。
たとえば、アリスは、「１０」の値を有する「ポイント」パラメータを有するレコードを制御し得る。アリスは、３「ポイント」をボブ（彼のアドレス）に割り当て、２「ポイント」をキャロル（彼女のアドレス）に割り当てるトランザクションを実行し得る。このトランザクションにより、ボブの秘密鍵が３「ポイント」を制御することを可能にするレコードが得られる一方、キャロルの秘密鍵は、２「ポイント」を制御し、アリスの秘密鍵は、５「ポイント」に対する制御を保持する。その時点から、彼らは、レコードの単一のコピーを維持する必要はない。彼らは各々、自身のコピーを取得し、所望のことを、他の２人がそれを知ることなく、行い得る。
レコード分割トランザクションは、トランザクションの詳細がたとえば以下のように部分の割り当てに関する詳細を含むことを除いて、以下に開示されるトランザクションと同様である。
Figure 2022550223000013
上記の例では、作成者（5XA5AH...）が、分割可能であるとともに、異なる所有者に割り当てられる部分を有し得る数値パラメータである１０「キュードス（Kudos）」を有するレコードを作成した。作成者は、アリス（CIDK3...）にレコードの所有権を移転するトランザクションを記録した。
第２のトランザクション上において、アリスは、当該キュードスパラメータを分割し、ボブ（SDJF8...）に３「キュードス」を与える。この時点から、７キュードスまたはそれ以下でアリスが何かを行うことによって署名されたトランザクションをこのレコードが受け取る場合、当該レコードは有効である。ボブが３キュードスまたはそれ以下で何かを行うことによって署名されたトランザクションをレコードが受け取る場合、当該レコードも有効である。したがって、アリスおよびボブは両方とも、異なる経路上でこのレコードに継続性を与え得、これにより、最終的に、互いに異なるがそれでも有効である複数のファイルが得られる。
上で開示される分割機能は、二重支払いが懸念されない場合、および、レコードのシステムがサードパーティバリデータを必要としない場合に、有用である。他の実施形態では、二重支払いに抵抗性がある分割が実行され、かつ、サードパーティリポジトリによって照合される。これらの実施形態では、分割によって、異なるチェックサムハッシュ値が得られるのに十分なだけ互いに異なる複数の子レコードが得られるはずである。たとえば、レコードＡが２つの部分に分割される場合、２つの新しいレコードＢおよびＣが得られるはずであり、Ａ、ＢおよびＣは、リポジトリのために別個のチェックサム値を生成する。分割がリポジトリに記録された後、レコードＡのチェックサムは除去されることになり、レコードＢおよびＣのチェックサムはリポジトリに発見されることになる。レコードを２つより多い部分に分割することも可能である。
図８は、一実施形態に従った、パラメータを複数の子レコードに分割する際の図２の分散データレコードモジュール１６の機能のフロー図である。図８の機能の例として、レコードパラメータが１０の初期供給を含み、当該初期供給が被減数（minuend）となると仮定する。所有者であるアリスが３ユニットをボブに与え、２ユニットをキャロルに与え、５ユニットは彼女自身がキープする場合、当該供給は、以下のように何も残さずに分割される。
Figure 2022550223000014
図８の機能の場合、元々の量から差し引かれる各部分は、減数（subtrahend）と称される。各減数により、一意の子レコードが得られる。オリジナルレコード（開始点）は、各子レコードについての開始コピーとして再使用されることになる。
８０２においてオリジナルレコードを取得した後、８０４において、各減数（元々の量から差し引かれる部分）について、オリジナルレコードのコピーが開始点として作成される。８０６において、トランザクションが、子レコードに追加され、公開鍵または導出されたアドレスの制御に減数を割り当てる。たとえば、アリスがボブに３ユニットを与える場合、３ユニットがボブの公開鍵（またはアドレス）に割り当てられたことを示すよう、トランザクションが子レコードに追加される。
８０８において、８０６からのトランザクションは、レコードを制御するシークレットな秘密鍵によりデジタル署名される。８１０において、デジタル署名がトランザクションに追加され、子レコードが完成する。
８１２において、このトランザクションにおいてさらなる減数が存在するか否かが決定される。換言すると、依然として子レコードとして記録される必要がある、分割される元々の量のさらなる部分が存在するか否かが決定される。８１２において「ＮＯ」の場合、機能は８０４において継続する。８１２においてＹＥＳの場合、複数の一意の子レコードのバッチを返すことで機能が終了する。
実施形態では、トランザクションがレコードを複数の子レコードに分割する場合、それらをバリデータリポジトリに記録することは、１つの古いチェックサムハッシュが除去されることになることと、多くの新しいチェックサムハッシュが付加されることとを意味する。図９は、一実施形態に従った、バリデータリポジトリにおいて分割トランザクションを記録する際の図２の分散データレコードモジュール１６の機能のフロー図である。
９０２において、レコードのバッチが受け取られる。９０４において、バッチ内の次のレコードが選択される。９０６において、選択された子レコードからの最後のトランザクションが除去される。これは、（分割されたトランザクションの前の）オリジナルドキュメントが、開始するのが良いか否かがチェックされ得るように、オリジナルドキュメントを識別するために行われる。
９０８において、オリジナルレコードのチェックサムハッシュが計算され、後のために保存される。９１０において、子レコードは、図４または図５の機能を使用して照合される。子レコードは、署名の照合が失敗した場合、または、トランザクションルールに違反した場合、無効になる。９１２において、子レコードが無効である場合、記録は失敗する。そうでなければ、９１４において、新しい子レコードのチェックサムハッシュが計算され、後のために保存される。古いオリジナルレコードのチェックサムはすでに保存されているが、新しいレコードのチェックサムも必要とされる。
９１６において、バッチ内においてさらに子レコードが存在する場合、機能は９０４にて継続する。そうでなければ、９１８において、バッチ内のすべての子レコードは、同じオリジナルレコードの一意の連続性であるはずである。実施形態は、すべての子レコードが同じ正確な起源を有すること、または、換言すると、オリジナルレコード部分がそれらのすべてにおいて同一であることを確実にする必要がある。これを行う複数の方法が存在する。１つは、最後のトランザクションなしで、それらのテキストを比較して、それらがすべて同じ同一のオリジナル部分を有することを確実にすることである。別の方法は、図９の実施形態で使用される方法であって、ステップ３において生成されたすべてのチェックサムを取得し、それらがすべてマッチすることを確実にすることである。各子レコードについて、９０８において、それらのオリジナルレコードのチェックサムが作成された。それらのすべてが同じチェックサムを生成した場合、それらはすべて開始点とまったく同じオリジナルレコードを有し、プロセスは継続し得る。少なくとも１つの子レコードがその中にミスマッチする「オリジナルレコード」を有する場合、プロセスは失敗することになる。
９２０において、すべての子レコードについて同一であると現在既知である、９０８において生成されたチェックサムは、有効なレコードとしてリポジトリ内に存在するか否かが決定される。９２０において「ＮＯ」の場合、プロセスは失敗する。オリジナルレコードは、リポジトリにチェックサムを有さない場合は、有効ではない。９２０においてＹＥＳの場合、９２２において、リポジトリからオリジナルレコードのチェックサムが除去される。９２４において、各子レコードのチェックサムがリポジトリに挿入される。
９０８、９１０、９１２および９１４は、異なる順序であり得る。たとえば、チェックサムは、ファイルを照合した後に決定され得る。９１８および９２０は、任意の順序であり得る。９２２および９２４は、アトミックであるべきである、すなわち、「オールオアナッシングの態様」であるべきである。すべての挿入および削除が成功しなければならず、そうでなければ、すべてが初期状態にロールバックしなければならない。
実施形態では、すべての子レコードは一意でなければならない。たとえば、アリスがボブに２ユニットを割り当て、ボブにさらに２ユニットを割り当て、ボブにさらに２ユニットを割り当てる場合、３つの減数によって、同じチェックサムを有する３つの同一レコードが得られることになる。これは、リポジトリにおいて一意のチェックサムが得られるようにすべての子レコードが少なくとも１つの文字によって一意であることを保証するために、各子レコードが、各トランザクションについての一意の部分ＩＤ番号のような十分な情報を有することを保証するよう考慮されるべきである。
さらに、実施形態において、オリジナルドキュメントがトランザクションの記録（tally）を保持するように、１つずつ記録される分割トランザクションについてのオプションが含められ得る。たとえば、アリスが数量の部分をボブに与え、次いで別の部分をキャロルに与え、次いで別の部分をデイブに与える場合、アリスは、すべての３つの異なる分割トランザクションのトレースを含むレコードにおける残りを記録として有し得る。これは、アリスがボブのアドレスに支払いをしたことをボブに証明する必要がある場合に有用である。当該証明は、アリスの現在有効なファイルがボブのアドレスへの支払いのトランザクションを示すことである。これにより、レコードは、自身において、支払い履歴の維持台帳（running ledger）となる。
例として、レコードは、３つの子レコードのバッチに分割され得る。この例では、作成者（5XA5A...）が１０「キュードス」の供給を有するレコードを作成し、それをアリス（CIDK3...）に割り当てる。アリスは次いで、１０キュードスを分割し、３のキュードスをボブ（SDJF8...）に割り当て、２個のキュードスをキャロル（S98DF...）に割り当て、残りの５キュードスを自身自身に戻すよう割り当てる。３つの子レコードのバッチは、以下のように３つの入れ子型のＪＳＯＮドキュメントのアレイとしてＪＳＯＮフォーマットで表される。
Figure 2022550223000015
Figure 2022550223000016
Figure 2022550223000017
Figure 2022550223000018
Figure 2022550223000019
開示されるように、実施形態は、スタンドアロンファイルから構成される台帳データベースを作成する。たとえば、アリスの銀行口座は、彼女のパーソナルラップトップ上のファイルである。ボブの銀行口座は、彼のスマートフォン上のファイルである。彼らは、自身の台帳履歴の管理者であるが、現代の暗号によって、彼らが不正行為をすることが不可能である。このモデルは、データの大部分がコンシューマ自身のデバイスにオフロードされるので、ストレージを実質的に無制限にする。実施形態における制御データベースは、すべてを格納する必要はなく、各スタンドアロンファイルの小さいチェックサムのみを格納する必要がある。したがって、数バイトのデータベースストレージは、コンシューマ自身のデバイスにオフロードされるギガバイトのアプリケーションデータを表わし得、かつ、照合し得る。
実施形態は、以下の例示的なユースケースを可能にする。
１．コンサート、スポーツイベントまたはフェリーなどのチケット。チケット所有者は、「署名された」ＱＲコード画像をスキャナに提示することで入ることが許可される。チケットは２回使用され得ない。チケットは偽造され得ない。チケットの盗難は、秘密鍵なしでは無駄である。
２．紙の連なりのチケット（たとえば、「一名様有効」と示している赤いクーポン）のデジタル代替品としての、パブリックフェアでの食べ物、飲料および活動のためのチケット。正当でないチケットを持ってくる人々からの損失を防ぐ。人々は、クレジットカード、ペイパルなどを使用してチケットクレジットを自身の電話アプリにロードし得るので、現金を交換する必要がなくなる。
３．ラッフルチケット。上記と同じ。人々は、ラッフルチケットを購入し、偽造することが不可能なデジタル証明書を取得し、真の所有者のみがそれを引き換え得る。
４．カジノ、リゾートまたはクルーズ船でのゲストクレジット。プラスチックカードにクレジットを投入する代わりに、ゲストは自身の電話にクレジットを投入し得る。
５．サプライチェーンの完全性。製薬会社は、小売業者または病院に薬剤を出荷し得、すべての計画された移転（たとえば、トラック、倉庫など）の署名チェーンを示す証明書を使用することによって、当該薬剤が真正であることを証明し得る。販売／消費された後、その証明書はもはや、コピーされたシリアル番号を有する別のボトルを表すよう使用され得ない。
６．ゲームマップの所有権、または、スポーツビデオゲームにおける有名なアスリートのカードといったビデオゲーム消耗品。
７．デジタル証券取引。分散された自律的な会社が、分散データレコードの形態で自社の株式を発行する。議決および移転は、秘密鍵により署名し得る者によって行われる。データベースにおけるデータまたはトークン供給といったデジタル資産、オンライン組織の制御、または、オープンソースプロジェクトは、米国証券取引委員会によって規制されていない分割可能な資産の例である。
８．収集品または記念品と共に発行される真正性および所有権の権原の証明書。
９．投票システム。各投票者は、一意の証明書をデジタル投票用紙として受け取り、署名された最終投票を投票カウンタに送る。家からの投票。
１０．人ではなく鍵保有者によって署名されるべき任意の契約書。
実施形態は、従来のデータベースまたはブロックチェーンにデータを格納することに対して以下の利点を有する。
１．完全なプライバシー。レコードの現在の状態またはトランザクション履歴を分析するように科学捜査的に調査され得るデータベースインスタンスまたはノードは存在しない。その理由は、当該情報が、世界を通じて、データベースインスタンスではなく、おそらくユーザのパーソナルデバイスに保存されている分離され独立したレコードファイルに保持されているからである。データセットに対してレポートクエリを実行することはできない。この制限は、いくつかのプライバシー指向のユースケースにおいて望ましい機能である。
２．ポータビリティ。コミュニティは、バックエンドデータベースソリューションを開発する必要なく、または、バックエンドデータベースソリューションに資金投入する必要なく、その場でレコードのシステムを作製し得る。レコードを発行し、当該レコードによりトランザクションを実行するのに必要なのは、スマートフォンまたはコンピュータのみである。データベースのコストなしでトランザクションシステムを構築することは、自由なオープンソースの取り組みを可能にする。たとえば、あるコミュニティが、オープンソースビデオゲームを開発し得、アイテムをトレードするためのバックエンドシステムを開発する必要なく、または、バックエンドシステムに資金投入する必要なく、プレーヤは、ゲーム内の消耗品を交換することができる。
３．スケーラビリティ。情報はデータベースノードに格納されないので、ストレージのアロケーションは困難ではない。
４．可用性。従来のデータベースモデルでは、データベースが使用不能または到達不能な場合、トランザクションは行われ得ない。対照的に、実施形態では、トランザクションはユーザ自身のデバイス上で行われ、結果得られる更新されたレコード（新しいトランザクション履歴および状態を有する）が別のユーザに直接的に送信され得る。
５．照合可能性。いくつかの実施形態によると、誰かが、レコードの制御を有していると主張し、売り出しまたは使用のためにレコードをプライベートにまたはパブリックにリストする場合、他の者は、当該レコードの完全性および正当性を迅速に照合し得る。たとえば、チケット、ビデオゲーム消耗品、または、タイトルのようなレコードを販売していることを誰かがウェブサイトにポストする場合、潜在的な買い手は、販売のためにリストされたレコードが真正であり、かつ、売り手が実際にそれを制御しているか、または換言すると、それが偽物ではないかを照合することができることになる。トランザクションは、シークレットな秘密鍵によってデジタル署名されなければならないので、レコード所有者は、レコードの公開検査を安全に可能にし、それでもレコードの完全な制御を維持し得る。レコードを公に公開することは、レコードが盗まれるリスクにレコードを晒すことではない。これは、大きな利点である。その理由は、人々がインターネット上で販売のためにデジタルアイテム（ビデオゲーム消耗品またはイベントチケットなど）をリストする多くの場合、それらは偽物または詐欺であるからである。
６．保証された価値。ユーザ（または技術的にはユーザの鍵の対およびアドレス）は、そのようなエンティティの経過を追うインスタンスが存在しないので、システムから禁止され得ない。さらに、レコードは、管理者の権限に晒されるまたは影響を受けるインスタンスが存在しないので、その価値を増加または減少するように管理者によって変更され得ない。これらの制限は、究極的な信頼を必要とするいくつかのユースケースにおいて望ましい保護であり得る。随意では、すべての参加者（サービスプロバイダおよびコンシューマ）が有限の供給制限が実施される（換言すると、新しい付加的な供給アイテムが発行されることがない）ことを確信し得るように、レコードの有限の供給を保証することも容易である。この保証は可能かつ随意であり、腐敗を防止するために有用であり得、かつ、サプライチェーンへの偽造品の導入を防止するために有用であり得る。ユーザがレコードまたは当該レコードを制御する秘密鍵を失わない限り、価値は保証される。
いくつかの実施形態が、本明細書において具体的に説明および／または記載される。しかしながら、開示された実施形態の修正例および変形例は、本発明の精神および意図される範囲から逸脱することがなければ、上記の教示によって、および、添付の請求の範囲の範囲内でカバーされることが理解されるであろう。

Claims (16)

  1. 資産を表すデジタルレコードを作成および照合する方法であって、
    前記デジタルレコードの作成者に対応する第１の秘密鍵および第１の公開鍵を取得することと、
    前記デジタルレコードについての１つ以上のパラメータを生成することとを含み、前記パラメータのうちの第１のパラメータは、前記デジタルレコードのトランザクションに関係しており、
    前記方法はさらに、
    前記デジタルレコードについての１つ以上のルールを生成することを含み、前記ルールのうちの第１のルールは、前記第１のパラメータに対応するとともに前記トランザクションを制約し、
    前記方法はさらに、
    前記第１の秘密鍵を使用して、前記第１の公開鍵、前記パラメータおよび前記ルールのすべての第１のデジタル署名を計算することと、
    前記第１の公開鍵、前記パラメータ、前記ルールおよび前記第１のデジタル署名を含む第１のデジタルレコードを作成することと、
    前記第１のデジタルレコードのチェックサムハッシュを作成することと、
    前記チェックサムハッシュをオンラインリポジトリに送信することとを含み、前記オンラインリポジトリは、前記チェックサムハッシュを使用して任意の以前のデジタルレコードを作成する前に、前記第１の秘密鍵が使用されていないことを照合するように構成される、方法。
  2. 前記方法は、
    前記資産の所有権を前記作成者から第２の所有者に移転する第１のトランザクションに応答して、前記第１のトランザクションを前記第１のデジタルレコードに追加することをさらに含み、前記第１のトランザクションは、前記第１の公開鍵と、前記第２の所有者に対応する第２の公開鍵とを含み、
    前記方法はさらに、
    前記第１の秘密鍵を使用して、前記第１のデジタルレコードおよび前記第１のトランザクションのすべての第２のデジタル署名を計算することと、
    前記第１のデジタルレコード、前記第１のトランザクションおよび前記第２のデジタル署名を含む第２のデジタルレコードを作成することと、
    前記第２のデジタルレコードを前記第２の所有者に送信することとを含む、請求項１に記載の方法。
  3. 前記第１のパラメータは、ある数のトランザクションを含み、前記第１のルールは、最大数のトランザクションを含む、請求項１に記載の方法。
  4. 前記方法は、
    前記資産の所有権を前記作成者から第２の所有者に移転する第１のトランザクションに応答して、前記第１のトランザクションを前記第１のデジタルレコードに追加することをさらに含み、前記第１のトランザクションは、前記第１の公開鍵と、前記第２の所有者に対応する第２の公開鍵から導出される第２のハッシュ値とを含み、
    前記方法はさらに、
    前記第１の秘密鍵を使用して、前記第１のデジタルレコードおよび前記第１のトランザクションのすべての第２のデジタル署名を計算することと、
    前記第１のデジタルレコード、前記第１のトランザクションおよび前記第２のデジタル署名を含む第２のデジタルレコードを作成することと、
    前記第２のデジタルレコードを前記第２の所有者に送信することとを含む、請求項１に記載の方法。
  5. 前記パラメータのうちの第２のパラメータをさらに含み、前記第２のパラメータは、前記資産の所有権が複数の異なる所有者に割り当て可能であるように、複数の部分に分割可能である、請求項１に記載の方法。
  6. 前記第２の所有者において、前記第１のトランザクションを照合することをさらに含み、
    前記第２の所有者において、前記第１のトランザクションを照合することは、
    前記第２のデジタルレコードから前記第２のデジタル署名および前記第２の公開鍵を抽出することと、
    オリジナルトランザクションメッセージを生成するよう、前記第２のデジタル署名と、前記第１のトランザクションの後に行われた任意の付加的なトランザクションとを前記第２のデジタルレコードから除去することと、
    前記第２のデジタル署名が前記第１の秘密鍵により生成されたことを確認するよう、前記第２のデジタル署名、前記第２の公開鍵、および、前記オリジナルトランザクションメッセージを照合機能への入力として使用することとを含む、請求項２に記載の方法。
  7. 前記オンラインリポジトリは、前記チェックサムハッシュが前記オンラインリポジトリによって格納されることを決定することによって、前記第１のデジタルレコードの少なくとも１つのトランザクションが有効であることに応答して生成される受信された第２のデジタルレコードが、前記オンラインリポジトリによって格納されることを照合するために、前記チェックサムハッシュを使用するように構成される、請求項１に記載の方法。
  8. 格納された命令を有するコンピュータ読取可能媒体であって、前記命令は、プロセッサによって実行されると、前記プロセッサに、資産を表すデジタルレコードを作成および照合させ、
    前記作成および照合することは、
    前記デジタルレコードの作成者に対応する第１の秘密鍵および第１の公開鍵を取得することと、
    前記デジタルレコードについての１つ以上のパラメータを生成することとを含み、前記パラメータのうちの第１のパラメータは、前記デジタルレコードのトランザクションに関係しており、
    前記作成および照合することはさらに、
    前記デジタルレコードについての１つ以上のルールを生成することを含み、前記ルールのうちの第１のルールは、前記第１のパラメータに対応するとともに前記トランザクションを制約し、
    前記作成および照合することはさらに、
    前記第１の秘密鍵を使用して、前記第１の公開鍵、前記パラメータおよび前記ルールのすべての第１のデジタル署名を計算することと、
    前記第１の公開鍵、前記パラメータ、前記ルールおよび前記第１のデジタル署名を含む第１のデジタルレコードを作成することと、
    前記第１のデジタルレコードのチェックサムハッシュを作成することと、
    前記チェックサムハッシュをオンラインリポジトリに送信することとを含み、前記オンラインリポジトリは、前記チェックサムハッシュを使用して任意の以前のデジタルレコードを作成する前に、前記第１の秘密鍵が使用されていないことを照合するように構成される、コンピュータ読取可能媒体。
  9. 前記作成および照合することは、
    前記資産の所有権を前記作成者から第２の所有者に移転する第１のトランザクションに応答して、前記第１のトランザクションを前記第１のデジタルレコードに追加することをさらに含み、前記第１のトランザクションは、前記第１の公開鍵と、前記第２の所有者に対応する第２の公開鍵とを含み、
    前記作成および照合することはさらに、
    前記第１の秘密鍵を使用して、前記第１のデジタルレコードおよび前記第１のトランザクションのすべての第２のデジタル署名を計算することと、
    前記第１のデジタルレコード、前記第１のトランザクションおよび前記第２のデジタル署名を含む第２のデジタルレコードを作成することと、
    前記第２のデジタルレコードを前記第２の所有者に送信することとを含む、請求項８に記載のコンピュータ読取可能媒体。
  10. 前記第１のパラメータは、ある数のトランザクションを含み、前記第１のルールは、最大数のトランザクションを含む、請求項８に記載のコンピュータ読取可能媒体。
  11. 前記作成および照合することは、
    前記資産の所有権を前記作成者から第２の所有者に移転する第１のトランザクションに応答して、前記第１のトランザクションを前記第１のデジタルレコードに追加することをさらに含み、前記第１のトランザクションは、前記第１の公開鍵と、前記第２の所有者に対応する第２の公開鍵から導出される第２のハッシュ値とを含み、
    前記作成および照合することはさらに、
    前記第１の秘密鍵を使用して、前記第１のデジタルレコードおよび前記第１のトランザクションのすべての第２のデジタル署名を計算することと、
    前記第１のデジタルレコード、前記第１のトランザクションおよび前記第２のデジタル署名を含む第２のデジタルレコードを作成することと、
    前記第２のデジタルレコードを前記第２の所有者に送信することとを含む、請求項８に記載のコンピュータ読取可能媒体。
  12. 前記作成および照合することは、前記パラメータのうちの第２のパラメータをさらに含み、前記第２のパラメータは、前記資産の所有権が複数の異なる所有者に割り当て可能であるように、複数の部分に分割可能である、請求項８に記載のコンピュータ読取可能媒体。
  13. 前記作成および照合することは、
    前記第２の所有者において、前記第１のトランザクションを照合することをさらに含み、
    前記第２の所有者において、前記第１のトランザクションを照合することは、
    前記第２のデジタルレコードから前記第２のデジタル署名および前記第２の公開鍵を抽出することと、
    オリジナルトランザクションメッセージを生成するよう、前記第２のデジタル署名と、前記第１のトランザクションの後に行われた任意の付加的なトランザクションとを前記第２のデジタルレコードから除去することと、
    前記第２のデジタル署名が前記第１の秘密鍵により生成されたことを確認するよう、前記第２のデジタル署名、前記第２の公開鍵、および、前記オリジナルトランザクションメッセージを照合機能への入力として使用することとを含む、請求項９に記載のコンピュータ読取可能媒体。
  14. 前記オンラインリポジトリは、前記チェックサムハッシュが前記オンラインリポジトリによって格納されることを決定することによって、前記第１のデジタルレコードの少なくとも１つのトランザクションが有効であることに応答して生成される受信された第２のデジタルレコードが、前記オンラインリポジトリによって格納されることを照合するために、前記チェックサムハッシュを使用するように構成される、請求項８に記載のコンピュータ読取可能媒体。
  15. デジタルレコード作成および照合システムであって、
    前記システムは、
    資産を表すデジタルレコードの作成者に対応する第１の秘密鍵および第１の公開鍵と、
    ストレージデバイスとを含み、前記ストレージデバイスは、前記デジタルレコードについての１つ以上のパラメータを格納し、前記パラメータのうちの第１のパラメータは、前記デジタルレコードのトランザクションに関係しており、前記ストレージデバイスは、前記デジタルレコードについての１つ以上のルールを格納し、前記ルールのうちの第１のルールは、前記第１のパラメータに対応するとともに前記トランザクションを制約し、
    前記システムはさらに、
    前記第１の秘密鍵を使用して、前記第１の公開鍵、前記パラメータおよび前記ルールのすべての第１のデジタル署名を計算することと、前記第１の公開鍵、前記パラメータ、前記ルールおよび前記第１のデジタル署名を含む第１のデジタルレコードを作成することと、前記第１のデジタルレコードのチェックサムハッシュを作成することと、前記チェックサムハッシュをオンラインリポジトリに送信することとを行うよう命令を実行するように適合されるプロセッサを含み、
    前記オンラインリポジトリは、前記チェックサムハッシュを使用して任意の以前のデジタルレコードを作成する前に、前記第１の秘密鍵が使用されていないことを照合するように構成される、システム。
  16. 前記プロセッサは、
    前記資産の所有権を前記作成者から第２の所有者に移転する第１のトランザクションに応答して、前記第１のトランザクションを前記第１のデジタルレコードに追加することを行うようにさらに適合され、前記第１のトランザクションは、前記第１の公開鍵と、前記第２の所有者に対応する第２の公開鍵とを含み、
    前記プロセッサはさらに、
    前記第１の秘密鍵を使用して、前記第１のデジタルレコードおよび前記第１のトランザクションのすべての第２のデジタル署名を計算することと、
    前記第１のデジタルレコード、前記第１のトランザクションおよび前記第２のデジタル署名を含む第２のデジタルレコードを作成することと、
    前記第２のデジタルレコードを前記第２の所有者に送信することと
    を行うように適合される、請求項１５に記載のシステム。
JP2020540614A 2019-06-21 2019-08-02 分散データレコード Active JP7504794B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US16/448,299 US11271751B2 (en) 2019-06-21 2019-06-21 Distributed data records
US16/448,299 2019-06-21
PCT/US2019/044837 WO2020256754A1 (en) 2019-06-21 2019-08-02 Distributed data records

Publications (2)

Publication Number Publication Date
JP2022550223A true JP2022550223A (ja) 2022-12-01
JP7504794B2 JP7504794B2 (ja) 2024-06-24

Family

ID=67660821

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2020540614A Active JP7504794B2 (ja) 2019-06-21 2019-08-02 分散データレコード

Country Status (5)

Country Link
US (2) US11271751B2 (ja)
EP (1) EP3987427A1 (ja)
JP (1) JP7504794B2 (ja)
CN (1) CN112437922A (ja)
WO (1) WO2020256754A1 (ja)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11153096B2 (en) * 2017-08-16 2021-10-19 Royal Bank Of Canada Platform for generating authenticated data objects
US11556665B2 (en) 2019-12-08 2023-01-17 Western Digital Technologies, Inc. Unlocking a data storage device
US11366933B2 (en) 2019-12-08 2022-06-21 Western Digital Technologies, Inc. Multi-device unlocking of a data storage device
US11088832B2 (en) * 2020-01-09 2021-08-10 Western Digital Technologies, Inc. Secure logging of data storage device events
US11606206B2 (en) 2020-01-09 2023-03-14 Western Digital Technologies, Inc. Recovery key for unlocking a data storage device
US11334677B2 (en) 2020-01-09 2022-05-17 Western Digital Technologies, Inc. Multi-role unlocking of a data storage device
US11831752B2 (en) 2020-01-09 2023-11-28 Western Digital Technologies, Inc. Initializing a data storage device with a manager device
US11265152B2 (en) 2020-01-09 2022-03-01 Western Digital Technologies, Inc. Enrolment of pre-authorized device
US11469885B2 (en) 2020-01-09 2022-10-11 Western Digital Technologies, Inc. Remote grant of access to locked data storage device
US12015540B2 (en) * 2021-09-07 2024-06-18 Red Hat, Inc. Distributed data grid routing for clusters managed using container orchestration services
US11924362B2 (en) * 2022-07-29 2024-03-05 Intuit Inc. Anonymous uncensorable cryptographic chains

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006127365A (ja) * 2004-11-01 2006-05-18 Hitachi Ltd 電子文書保存管理システム、電子文書保存管理方法、および電子文書保存管理プログラム
JP2008269591A (ja) * 2007-03-28 2008-11-06 Ricoh Co Ltd 書類画像を認証するための装置、方法及びコンピュータプログラム
JP2010157022A (ja) * 2008-12-26 2010-07-15 Toshiba Corp 情報ライフサイクル管理システム、情報管理サーバ装置、情報媒体制御装置及びプログラム
US20170046526A1 (en) * 2015-08-13 2017-02-16 TD Bank Group System and Method for Implementing Hybrid Public-Private Block-Chain Ledgers
US20170237554A1 (en) * 2016-02-12 2017-08-17 Mondo Jacobs Methods and systems for using digital signatures to create trusted digital asset transfers
JP2018511137A (ja) * 2015-04-05 2018-04-19 デジタル・アセット・ホールディングス デジタル資産仲介電子決済プラットフォーム
WO2019072312A2 (en) * 2018-12-29 2019-04-18 Alibaba Group Holding Limited SYSTEM AND METHOD FOR DETECTING REJECTION ATTACK

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8140861B2 (en) * 2006-12-28 2012-03-20 International Business Machines Corporation Method and system for content-based encrypted access to a database
CA2981952A1 (en) * 2015-04-06 2016-10-13 Bitmark, Inc. System and method for decentralized title recordation and authentication
US11494761B2 (en) * 2015-11-06 2022-11-08 Cable Television Laboratories, Inc. Systems and methods for digital asset security ecosystems
US20190050851A1 (en) * 2017-02-20 2019-02-14 Tovarystvo z obmezhenoiu vidpovidalnistiu, Simcord The method of management of property rights to assets and the system for its implementation
EP3593305A4 (en) * 2017-03-08 2020-10-21 IP Oversight Corporation SYSTEM AND PROCEDURE FOR GENERATING TOKENS SECURED BY THE VALUE OF GOODS FROM RESERVES
US10541820B2 (en) * 2017-08-17 2020-01-21 Global Bonsai LLC Distributed digital ledger
US11481786B2 (en) * 2017-10-03 2022-10-25 Sony Group Corporation Genuine instance of digital goods
US20190333033A1 (en) * 2018-04-29 2019-10-31 Keir Finlow-Bates System and method for creating, storing and transferring unforgeable digital assets in a database

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006127365A (ja) * 2004-11-01 2006-05-18 Hitachi Ltd 電子文書保存管理システム、電子文書保存管理方法、および電子文書保存管理プログラム
JP2008269591A (ja) * 2007-03-28 2008-11-06 Ricoh Co Ltd 書類画像を認証するための装置、方法及びコンピュータプログラム
JP2010157022A (ja) * 2008-12-26 2010-07-15 Toshiba Corp 情報ライフサイクル管理システム、情報管理サーバ装置、情報媒体制御装置及びプログラム
JP2018511137A (ja) * 2015-04-05 2018-04-19 デジタル・アセット・ホールディングス デジタル資産仲介電子決済プラットフォーム
US20170046526A1 (en) * 2015-08-13 2017-02-16 TD Bank Group System and Method for Implementing Hybrid Public-Private Block-Chain Ledgers
US20170237554A1 (en) * 2016-02-12 2017-08-17 Mondo Jacobs Methods and systems for using digital signatures to create trusted digital asset transfers
WO2019072312A2 (en) * 2018-12-29 2019-04-18 Alibaba Group Holding Limited SYSTEM AND METHOD FOR DETECTING REJECTION ATTACK

Also Published As

Publication number Publication date
CN112437922A (zh) 2021-03-02
EP3987427A1 (en) 2022-04-27
US20200403786A1 (en) 2020-12-24
JP7504794B2 (ja) 2024-06-24
US10771257B1 (en) 2020-09-08
US11271751B2 (en) 2022-03-08
WO2020256754A1 (en) 2020-12-24

Similar Documents

Publication Publication Date Title
JP7504794B2 (ja) 分散データレコード
US20220171877A1 (en) Systems and methods for providing identity verification services
US20190019180A1 (en) Digital ledger authentication using address encoding
JP7377312B2 (ja) ブロックチェーンにより実現されるシステム及び方法
CN111989707B (zh) 管理基于区块链的海关清关服务的用户权限
US11461771B2 (en) Hybrid digital ledger control with address encoding
CN111868725B (zh) 基于区块链处理进口海关清关数据
CN111936995A (zh) 海关清关数据的分布式存储
CN111095863B (zh) 在区块链网络上通信、存储和处理数据的基于区块链的系统和方法
CN111989663A (zh) 基于区块链的智能合约池
US20230298001A1 (en) Non-fungible token (nft) purchase and transfer system
CN114930330A (zh) 基于区块链的海关清关服务平台的用户管理
US20220311611A1 (en) Reputation profile propagation on blockchain networks
US11449911B2 (en) Blockchain-based document registration for custom clearance
CN116194940A (zh) 基于区块链的税收机制
Hill et al. Blockchain Developer's Guide: Develop smart applications with Blockchain technologies-Ethereum, JavaScript, Hyperledger Fabric, and Corda
Hill et al. Blockchain Quick Reference: A guide to exploring decentralized blockchain application development
US20230259919A1 (en) Review engine verification with non-fungible authentication tokens
CN115730277A (zh) 使用非同质化代币nft的补充数字内容访问控制
US20230043223A1 (en) Methods for Securely Adding Data to a Blockchain Using Dynamic Time Quanta and Version Authentication
Domingue et al. The FAIR TRADE framework for assessing decentralised data solutions
CN117616410A (zh) 计算机分片环境中的多方计算
Khedekar et al. Protection to Personal Data Using Decentralizing Privacy of Blockchain.
Shamsi et al. A secure and efficient approach for issuing KYC token as COVID-19 health certificate based on stellar blockchain network
KR20240024767A (ko) 커미트먼트의 사용자 체인에 랑데뷰 블록체인 트랜잭션을 첨부하기 위한 방법 및 시스템

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20220729

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20220729

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20230731

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20230905

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20231204

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20240202

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

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20240514

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20240612

R150 Certificate of patent or registration of utility model

Ref document number: 7504794

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150