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
  • G06Q30/00—Commerce
  • G06Q30/06—Buying, selling or leasing transactions
• • 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/04—Payment circuits
  • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
• • 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/04—Payment circuits
  • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
  • G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
• • 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/3236—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 using cryptographic hash functions
• • 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/3297—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 time stamps, e.g. generation of time stamps
• • 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/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
• • 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

Definitions

• the present disclosure relates to a digital asset platform and method of use.
• the exemplary embodiments disclosed herein provide a distributed system for executing transactional workflows among a plurality of participants.
• An exemplary embodiment method of manipulating data structures for distributed multilateral bookkeeping includes receiving previously agreed and formalized rules; receiving an authorized decision; evolving an agreement based on the authorized decision and the rules; notifying participants in the agreement of the evolved agreement; and storing the evolved agreement with evidence of notification in a shared append-only ledger.
• the method may include detecting contradicting agreements; and excluding a contradicting agreement based on evidence from the shared append-only ledger.
• the method may include providing participants partial insight to agreements through a partial agreement store sufficient for their own authorization and records, wherein the partial agreement store of the participants remains without contradiction to other participant's records and is validatable within the bounds of their visibility.
• the method may include automatically auditing authorization and evolution of the agreement.
• the method may be employed where the append-only ledger comprises a blockchain.
• the method may include executing transactional workflows between a plurality of participants including: interacting with the append-only ledger using a Command Query Responsibility Segregation (CQRS) pattern having a plurality of modules, wherein the modules include: a ledger writer configured to record evidence indicative of a transaction dataset through a first write module of the CQRS to the ledger; and a ledger reader configured to detect evidence on the ledger having a matching notification token, and read such matching evidence through a first read module of the CQRS.
• CQRS Command Query Responsibility Segregation
• the method may be employed where the evidence indicative of an agreement comprises a timestamp indicative of recordation time on the ledger.
• the method may be employed where the evidence indicative of an agreement comprises a Merkle hash of the transaction dataset.
• the method may further be employed where the hashed transaction dataset comprises proof of a corresponding multilaterally authorized business intent message and proof of a current agreement used to translate the business intent message into the transaction dataset.
• the method may be employed where each of a plurality of distributed nodes comprise different modules of the CQRS.
• the method may further be employed where a reduced subset of the nodes comprises the first write module of the CQRS.
• the method may be employed where the matching notification token is detected through a second read module of the CQRS.
• the method may include issuing an announcement of identities on the ledger.
• the method may further include computing a unique shared secret for each participant and log-writer pair.
• the method may be employed where the matching notification token is recognizable by involved parties but remains secret to others.
• the method may be employed where the transaction dataset stores the current agreement as an abstract syntax tree (AST).
• the method may further be employed where the transaction dataset is updated with Merkle hashes to form a Merklized abstract syntax tree (MAST).
• the method may include further auditing to prove that an evolution of an agreement from a first transaction dataset to a second transaction dataset was properly authorized and properly executed, and that all participants were notified of the changes pertinent to them.
• the method may further be employed where auditing further proves that participants were not notified of changes not pertinent to them.
• An exemplary embodiment system for distributed multilateral bookkeeping includes a business intent unit configured to receive previously agreed and formalized rules; a choice unit configured to receive an authorized decision from the business intent unit; a processing unit configured to evolve an agreement based on the authorized decision and the rules; a notification unit configured to notify participants in the agreement of the evolved agreement; and an append-only ledger configured to store the evolved agreement with evidence of notifications.
• the system may include an audit unit configured to detect contradicting agreements.
• the system may further be employed where a detected contradicting agreement is excluded based on evidence from the shared append-only ledger.
• the system may further be employed where the audit unit supports automatically auditing authorization and evolution of the agreement.
• the system may be employed where the append-only ledger supports: providing participants partial insight to agreements through a partial agreement store sufficient for their own authorization and records, wherein the partial agreement store of participants remains without contradiction to other participant's records and is validatable within the bounds of their visibility.
• the system may include a Command Query Responsibility Segregation (CQRS) pattern having a plurality of modules supporting interaction with the append-only ledger; a ledger writer configured to record evidence indicative of a transaction dataset through a first write module of the CQRS to the ledger; and a ledger reader configured to detect evidence on the ledger having a matching notification token, and read such matching evidence through a first read module of the CQRS.
• CQRS Command Query Responsibility Segregation
• the system may be employed where the append-only ledger comprises a blockchain.
• the system may be employed where the evidence indicative of an agreement comprises a timestamp indicative of recordation time on the ledger.
• the system may be employed where the evidence indicative of an agreement comprises a Merkle hash of the transaction dataset.
• the system may further be employed where the hashed transaction dataset comprises proof of a corresponding multilaterally authorized business intent message and proof of a current agreement used to translate the business intent message into the transaction dataset.
• the system may be employed where each of a plurality of distributed nodes comprise different modules of the CQRS.
• the system may further be employed where a reduced subset of the nodes comprises the first write module of the CQRS.
• the system may be employed where each node is configured to maintain a received announcement of identities on the ledger.
• the system may be employed where each node is configured to compute a unique shared secret corresponding to its participant and any log-writer.
• the system may be employed where the matching notification token is recognizable by involved parties but secret to others.
• the system may be employed where the matching notification token is detected through a second read module of the CQRS.
• the system may be employed where the transaction dataset stores the current agreement as an abstract syntax tree (AST).
• the system may further be employed where the transaction dataset is updated with Merkle hashes to form a Merklized abstract syntax tree (MAST).
• the system may include an auditor configured for proving that an evolution of an agreement from a first transaction dataset to a second transaction dataset was properly authorized and properly executed, and that all participants were notified of the changes pertinent to them.
• the system may be employed where the auditor further proves that participants were not notified of changes not pertinent to them.
• An exemplary embodiment program storage device tangibly embodying program steps executable by a computer for manipulating data structures in distributed multilateral bookkeeping includes program steps for receiving previously agreed and formalized rules; receiving an authorized decision; evolving an agreement based on the authorized decision and the rules; notifying participants in the agreement of the evolved agreement; and storing the evolved agreement with evidence of notification in a shared append-only ledger.
• the device may include steps for: detecting contradicting agreements; and excluding a contradicting agreement based on evidence from the shared append-only ledger.
• the device may include steps for: providing participants partial insight to agreements through a partial agreement store sufficient for their own authorization and records, wherein the partial agreement store of the participants remains without contradiction to other participant's records and is validatable within the bounds of their visibility.
• the device may include steps for automatically auditing authorization and evolution of the agreement.
• the device may be employed where the append-only ledger comprises a blockchain.
• the device may include steps for executing transactional workflows between a plurality of participants including: interacting with the append-only ledger using a Command Query Responsibility Segregation (CQRS) pattern having a plurality of modules, wherein the modules include: a ledger writer configured to record evidence indicative of a transaction dataset through a first write module of the CQRS to the ledger; and a ledger reader configured to detect evidence on the ledger having a matching notification token, and read such matching evidence through a first read module of the CQRS.
• CQRS Command Query Responsibility Segregation
• the device may be employed where the evidence indicative of an agreement a timestamp indicative of recordation time on the ledger.
• the device may be employed where the evidence indicative of an agreement comprises a Merkle hash of the transaction dataset.
• the device may further be employed where the hashed transaction dataset comprises proof of a corresponding multilaterally authorized business intent message and proof of a current agreement used to translate the business intent message into the transaction dataset.
• the device may be employed where each of a plurality of distributed nodes comprise different modules of the CQRS.
• the device may further be employed where a reduced subset of the nodes comprises the first write module of the CQRS.
• the device may be employed where the matching notification token is detected through a second read module of the CQRS.
• the device may include steps for issuing an announcement of identities on the ledger.
• the device may include steps for computing a unique shared secret for each participant and log-writer pair.
• the device may be employed where the matching notification token is recognizable by involved parties but remains secret to others.
• the device may be employed where the transaction dataset stores the current agreement as an abstract syntax tree (AST).
• the device may further be employed where the transaction dataset is updated with Merkle hashes to form a Merklized abstract syntax tree (MAST).
• the device may include steps for auditing to prove that an evolution of an agreement from a first transaction dataset to a second transaction dataset was properly authorized and properly executed, and that all participants were notified of the changes pertinent to them.
• the device may further be employed where auditing further proves that participants were not notified of changes not pertinent to them.
• Figure 1 is a schematic block diagram showing evolution of a Digital Asset Modeling Language (DAMLTM) agreement through a decision in accordance with an exemplary embodiment of the present disclosure
• DMLTM Digital Asset Modeling Language
• Figure 2 is a schematic Abstract Syntax Tree (AST) parsing diagram in accordance with an exemplary embodiment of the present disclosure
• Figure 3 is a schematic block diagram showing evolution of a DAMLTM agreement through a decision validated with Distributed Ledger Technology (DLT) Log evidence in accordance with an exemplary embodiment of the present disclosure
• Figure 4 is a schematic block diagram showing party identification in accordance with an exemplary embodiment of the present disclosure
• Figure 5 is a schematic Merklized Abstract Syntax Tree (MAST) parsing diagram in accordance with an exemplary embodiment of the present disclosure.
• Figure 6 is a schematic system diagram showing a Contract Authorization
• model is defined as at least one bundle of agreement(s) or potential transaction(s), which, under certain governing rules such as may be provided by a Master Contract, for example, might or might not have the potential to represent a digitally-represented agreement or a legally binding contract.
• An exemplary embodiment system performs multilateral bookkeeping where agreements evolve in consequence of authorized decisions and along previously agreed and formalized rules, participants are guaranteed to learn of agreements that they are involved in, contradicting agreements can be excluded through a shared append-only log of agreement transitions, participants may have only partial insight to agreements that is sufficient for their own authorization and records, the partial agreement store of participants remains without contradiction to other participant's records and is validatable within the bounds of their visibility, and an audit of agreement authorization and evolution can be automated.
• DAMLTM Digital Asset Modeling Language
• a DAMLTM previous agreement 1 10 is affected by a decision 1 12 to yield a DAMLTM current agreement 1 14.
• an exemplary DAMLTM Abstract Syntax Tree (AST) parsing diagram is indicated generally by the reference numeral 200.
• an operator 210 references a stub 212 and another operator 220.
• the other operator 220 references a first stub 222, a second stub 224, and a third stub 226.
• the exemplary AST is based on DAMLTM, alternate embodiment ASTs may be based on alternate contract specification languages (CSL).
• a DAMLTM agreement evolution validated with Distributed Ledger Technology (DLT) Log evidence is indicated generally by the reference numeral 300.
• a DLT blockchain Global Synchronization Log includes blocks 310, 312, 314, 316, 318, 320, 322, 324, and 326.
• a DAMLTM previous agreement 330 is affected by a decision 332 to yield a DAMLTM agreement 334.
• the DAMLTM previous agreement 330 is affected by an alternate decision 336 to yield a DAMLTM alternate agreement 338.
• Evidence from block 326 is employed to verify the previous agreement 330, and evidence from block 318 is employed to verify the agreement 334.
• the alternate agreement 338 is invalid.
• a party identification workflow is indicated generally by the reference numeral 400.
• a log writer derives a token from the identity of Party A and the log writer's secret key.
• a Party A derives a token from the identity of the log writer and Party A's secret key.
• evidence of an agreement involving Party A is received with a notification token.
• the function block 432 may perform optional processing and refer to a function block 434.
• the function block 434 determines the identity of Party A, and refers to block 436.
• the function block 436 may perform optional processing and refer to a function block 438.
• the function block 438 determines the identity of the log writer.
• a Merklized Abstract Syntax Tree (MAST) DAMLTM parsing diagram is indicated generally by the reference numeral 500.
• a Merkle hash 540 references another Merkle hash 542 and an operator 520.
• the operator 520 references a first stub 522, a second stub 524, and a third stub 526.
• a Contract Authorization and Distribution Framework (CADF) interconnected system is indicated generally by the reference numeral 600.
• a Global Synchronization Log 650 based on an exemplary Digital Ledger Technology (DLT) blockchain, is connected to each of a first CADF unit 660 and a second CADF unit 670.
• the first and second CADF units communicate using agreements written in DAMLTM that may be translated to AST or MAST.
• the CADF system may authorize, store and request agreements from another CADF system acting in behalf of another party.
• the first CADF 660 is connected to the information technology (IT) systems 680 of Party A, while the second CADF 670, in turn, is connected to the IT systems 690 of Party B.
• IT information technology
• the Digital Asset Modeling Language (DAMLTM) is an expressive language enabling financial institutions to model and execute agreements with certainty and finality.
• the Global Synchronization Log based on Distributed Ledger Technology (DLT) is a shared, replicated ledger, such as but not limited to a blockchain, with a synchronizing mechanism known as a "consensus algorithm”.
• a Contract Authorization and Distribution Framework (CADF) supports or includes a service to selectively disclose contracts to parties involved and collect their authorizations for decisions.
• the presently disclosed Digital Asset Platform supports roles with different abilities to enter into and/or review agreements, or technically support the security of the platform.
• Unique design decisions while configuring DAMLTM, DLT Log, and/or CADF provide powerful tools to streamline and execute contractual workflows between and within financial institutions.
• DAMLTM code models an agreement between parties as a model typically eventually referencing further DAMLTM models, which each evolve through a decision by a party into a new model.
• the new model might involve other parties to or into the contract, might offer new decision choices, or might even be the same as the previous model.
• Unique properties of the DAMLTM language particularly suited for such purposes include: 1 ) A DAML model enumerates all possible current choices of the parties and their respective consequences. 2) A decision evolves a DAML model into a new DAML model in finite steps after which the new DAML model awaits new decisions to evolve further.
• a DAML model can be analyzed, to deduce: a) Current parties and their available choices; and b) The set of parties who would become involved in the new contract if a current party would decide for any of its respective current choices. 4) DAML allows for extracting fractions of the model such that those fractions are also valid DAML models on their own, but potentially with a lesser number of involved parties.
• DAML is human readable and editable, it can be converted into and from a well-defined and unique technical representation called an Abstract Syntax Tree (AST), as shown in Figure 2.
• AST Abstract Syntax Tree
• DAML allows for Operators that might combine Stubs or further Operators.
• An Operator might represent a decision option and its sub-tree might define the effect of the decision.
• a Stub might be replaced with a model, again represented as an AST, in consequence of a decision.
• DLT Distributed Ledger Technology
• DLT presents an alternative to third-party and bilateral bookkeeping. Its primary advantages lie in scalability if compared with bilateral bookkeeping, and lie in attack resilience if compared to third-party bookkeeping.
• Distributed Ledger Technology introduces multilateral bookkeeping whereby members of the network cooperate to create a reliable shared infrastructure that decides on the order of agreements. Once the order of agreements is definite, contradicting agreements may be resolved by considering only the earlier agreement valid.
• the DLT Global Synchronization Log is an append-only log of evidence for agreement evolutions. The DLT Log data structure features sophisticated integrity proofs based on digital signatures and cryptographic hashes.
• DLT Log network can prove to themselves through execution of a consensus algorithm that their copy of the log matches those of the majority of network participants.
• a benefit of DLT for contractual parties is that if the parties decide that the DLT Log shall include all contracts, it can identify the complete set of current contracts while automatically excluding alternatives.
• the DLT Log When representing the complete set of current contracts, the DLT Log also acts as a publication channel to announce new contracts to the parties involved. Notification of involved parties is required for the validity of an agreement.
• the presently disclosed Digital Asset Platform stores notification tokens into the evidence of the new model. Involved parties may monitor for their tokens. To protect privacy of involved parties, the notification token is calculated such that it is known to be linked to the party only by the writer of the log and the involved party.
• the notification token is a function of a shared secret between the log writer and the notified party. Derivation of shared secrets is made possible by prior announcement of the identities of the log writer and the involved parties on the log. Identities are tied to public keys for which the private key is kept secret by the actor behind the announced identity. The log supports announcement and revocation of identities for regular key rolling or emergency withdrawal after a security breach affecting the party.
• a Contract Authorization and Distribution Framework (CADF) are used for decisions that require proper authorization by the party who makes a choice.
• the platform collects digital signatures on business intent formalized using DAML derived ASTs into evidence authorization. Since the DAML might not be authored by the authorizer, it needs to be delivered on demand by the author's network node. Delivery of the AST for signature might be denied if the requestor is not entitled to see the contract, or replied with a partially blinded AST, just sufficient to support the decision process of the authorizer.
• the platform uses a Merklized Abstract Syntax Tree (MAST) for partial blinding of an AST. Parts of an AST are substituted with the Merkle Hash of their respective sub-tree to create a MAST. Merkle Hashes do not reveal anything about the information blinded. Merkle Hashes are computed such that the digital signature on the complete AST or on any of its derived MAST is verifiable with knowledge of the AST or any of its derived MAST. As a result, parties will hold incomplete sets of copies of models just as they are entitled to see or are required to authorize. Their model storage resembles multilateral bookkeeping, but formalized and properly authorized.
• MAST Merklized Abstract Syntax Tree
• the new agreement will be evidenced on the DLT Log.
• the evidence does not disclose anything about the model's content, but is a fingerprint compiled such that all involved parties are able to prove that the evidence is for a particular agreement.
• the multilateral model store filtered by evidence on the DLT Log completely and reliably defines the current set of agreements for all parties involved.
• the various network nodes connected to the shared infrastructure may have different roles.
• a node may fulfill several roles.
• a network node that records evidence into the append-only log is a ledger writer. Although technically not necessary, it will most likely also guarantee the contradiction-less recording of evidence and, as a consequence, have full visibility into agreements it records, for which it will have full records in its CADF.
• the role of the ledger writer might be shared by several nodes, such that a ledger write requires joint authorization by them in desired scenarios.
• Another role is that of a "ledger reader”. This is a network node that acts in behalf of parties that might be involved in some agreements or for supervising authorities. The ledger reader will watch out for notifications for its served parties on the DLT Log, and aggregate a partial database of agreements through its CADF.
• Auditor Yet another role is that of an "auditor".
• the purpose of an Auditor is to keep a check on the ledger writer by proving that agreement evolutions are properly executed and authorized and that involved parties were notified and no contradicting agreements were recorded. Similar to the ledger writer, an Auditor will have some visibility into agreements, but in addition it will also have knowledge of shared secrets for many parties. A breach of protocol by the Ledger Writer would be flagged by the Auditor and handled outside of the described shared infrastructure. Since the Auditor's task is the execution of a checking algorithm that needs no human discretion or oversight, the Auditor may be an autonomously executed algorithm running within a secure computing environment. Communication with the secure environment may be encrypted, and it may be configured so no data may leave the secure environment except for raising a flag on any failed rule validation the Auditor observes.
• All code, data structures and the like discussed above can be stored in non- transient computer readable storage media.
• Functional steps described herein can be accomplished by computer code executed on a processor.
• the various data manipulations described above can be accomplished on stored data structures to create transformed data structures that are processed by a computer processor in a different manner.
• the various functions of the embodiments allow a computing system to operate in a new manner to accomplish transactions and provide new advantages.
• the various flowchart steps can be accomplished by software modules executed on a computer processor.
• Blocks illustrated in the figures can represent data structures, such as databases storing records, which are manipulated in the described manner to allow a computing system to operate on the data and transform the data.

Landscapes

• Engineering & Computer Science (AREA)
• Business, Economics & Management (AREA)
• Accounting & Taxation (AREA)
• Computer Security & Cryptography (AREA)
• General Business, Economics & Management (AREA)
• Signal Processing (AREA)
• Strategic Management (AREA)
• Physics & Mathematics (AREA)
• Computer Networks & Wireless Communication (AREA)
• General Physics & Mathematics (AREA)
• Finance (AREA)
• Theoretical Computer Science (AREA)
• Development Economics (AREA)
• Economics (AREA)
• Marketing (AREA)
• Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
• Management, Administration, Business Operations System, And Electronic Commerce (AREA)
• Storage Device Security (AREA)

Priority Applications (8)

Applications Claiming Priority (1)

Related Child Applications (1)

Publications (1)

Family

ID=60953207

Family Applications (1)

Country Status (3)

Cited By (3)

Families Citing this family (1)

Citations (3)

Family Cites Families (2)

• 2016
  • 2016-07-14 CN CN201680087670.9A patent/CN110192212B/zh active Active
  • 2016-07-14 WO PCT/US2016/042322 patent/WO2018013124A1/en active Search and Examination
  • 2016-07-14 EP EP16909020.6A patent/EP3472779A4/de not_active Ceased

Patent Citations (3)

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events