# US 11,310,044 B2 · Authenticate transactions of secured file in blockchain

> Agents: this data is available as JSON from the patentgrep API and MCP server — see https://patentgrep.com/llms.txt

- Number: US 11,310,044 B2
- Document ID: US11310044B2
- Status: Granted
- Kind: B2
- Application number: 16/451,458
- Filed: 2019-06-25
- Published: 2019-10-31
- Granted: 2022-04-19
- Earliest claimed: 2018-04-30
- Assignees: Innoplexus AG
- Applicants: Innoplexus AG
- Inventors: Abhijit Keskar
- Web page: https://patentgrep.com/patent/US11310044B2

## CPC

- H04L 9/088: {Usage controlling of secret information, e.g. techniques for restricting cryptographic keys to pre-authorized uses, different access levels, validity of crypto-period, different key- or password length, or different strong and weak cryptographic algorithms (network architectures or network communication protocols for using time-dependent keys in a packet data network H04L63/068)}
- G06F 21/606: {by securing the transmission between two devices or processes}
- G06F 21/6218: {to a system of files or objects, e.g. local or distributed file system or database}
- G06F 21/64: Protecting data integrity, e.g. using checksums, certificates or signatures
- G06Q 20/065: {using e-cash}
- G06Q 20/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
- G06Q 20/401: {Transaction verification}
- G06Q 20/4015: {using location information}
- H04L 9/0637: {Modes of operation, e.g. cipher block chaining [CBC], electronic codebook [ECB] or Galois/counter mode [GCM]}
- H04L 9/3242: {involving keyed hash functions, e.g. message authentication codes [MACs], CBC-MAC or HMAC}
- H04L 63/0428: {wherein the data content is protected, e.g. by encrypting or encapsulating the payload}
- H04L 63/10: {for controlling access to devices or network resources}
- H04L 63/126: {the source of the received data}
- G06Q 2220/00: Business processing using cryptography
- H04L: TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION (arrangements common to telegraphic and telephonic communication H04M)
- G06F: ELECTRIC DIGITAL DATA PROCESSING (computer systems based on specific computational models G06N)
- 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

## Abstract

Disclosed is system and method for authenticating secured file transactions. Hash of transaction is stored in distributed ledger. Unencrypted intent, encrypted intent of first agent module is generated. Unencrypted consent, encrypted consent of server arrangement is generated. Encrypted consent is communicated to the first agent module along with a location of second agent module. Encrypted consent, the unencrypted intent, the hash and the first agent key are communicated to the second agent module. Encrypted consent is communicated to server arrangement. Encrypted consent is validated by comparing encrypted consent received from second agent module with two newly generated encrypted consents at server arrangement. Two new encrypted intents are generated at second agent module based on validation of encrypted consent. Encrypted intent stored at server arrangement is validated by comparing encrypted intent with two newly generated encrypted intents to authenticate transaction. Distributed ledger may be implemented by a block chain.

## Claims

### Claim 1

An automated system for authenticating file transactions in a tri-party setup, wherein the system is configured to:
store a hash corresponding to a transaction in a distributed ledger;
generate an unencrypted intent and encrypted intent of a first client device, and to communicate the encrypted intent and a file identifier to a server arrangement so as to raise a request for accessing a secured file, wherein the request for accessing the secured file is time bound, and wherein the encrypted intent is generated by encrypting the unencrypted intent with a first client key, further wherein the first client key is dynamically generated at the first client device;
wherein the tri-party set up comprises the first client device, a second client device, and the server arrangement all communicating together to authenticate and perform the file transactions,
generate an unencrypted consent and an encrypted consent of the server arrangement, wherein the encrypted consent is generated by encrypting the unencrypted consent with a server key, wherein the encrypted intent and the unencrypted consent are stored at the server arrangement, wherein the encrypted consent of the sever arrangement is time bound;
communicate the encrypted consent to the first client device along with a location of the second client device;
communicate the encrypted consent, the unencrypted intent and the first client key from the first client device to the second client device based on the received location of the second client device;
communicate the encrypted consent from the second client device to the server arrangement;
validate the encrypted consent at the server arrangement by comparing the encrypted consent received from the second client device with at least two newly generated encrypted consents at the server arrangement, wherein the at least two newly encrypted consents are generated by encrypting the unencrypted consent with the server key, wherein the at least two newly encrypted consents include a current timestamp and a predefined prior timestamp;
generate at least two new encrypted intents, based on the validation of the encrypted consent, at the second client device, wherein the at least two new encrypted intents are generated by encrypting the unencrypted intent with the first client key, wherein the at least two new encrypted intents include current timestamp and a predefined prior timestamp; and
validate the encrypted intent stored at the server arrangement by comparing the encrypted intent with the at least two newly generated encrypted intents received from the second client device,
wherein the second client device receives a confirmation of the validation of the encrypted intent to authenticate the server arrangement.

### Claim 2 (depends on 1)

The system of claim 1, wherein a transaction key is generated by encrypting a first client identifier, a second client identifier and a file identifier with the first client key.

### Claim 3 (depends on 1)

The system of claim 1, wherein the system is further configured to validate the hash corresponding to the transaction by comparing the hash received from the server arrangement and hash received from the distributed ledger.

### Claim 4 (depends on 2)

The system of claim 2, wherein the system is further configured to validate the transaction key stored in the distributed ledger, wherein the transaction key is validated by comparing the transaction key stored at the distributed ledger with a new transaction key, wherein the new transaction key is generated by encrypting the first client identifier, the second client identifier and the file identifier with the first client key stored at the second client device.

### Claim 5 (depends on 1)

The system of claim 1, wherein the system is further configured to share payment details associated with the transaction for validation at the server arrangement.

### Claim 6 (depends on 1)

The system of claim 1, wherein the server arrangement is configured to associate the received file identifier with a list of second client identifier, to identify the second client identifier and the location of the second client device, wherein the list of second client identifier and file identifier are stored in a data repository associated with the server arrangement.

### Claim 7 (depends on 6)

The system of claim 6, wherein the unencrypted consent, the encrypted intent, and the server key used for encrypting the unencrypted consent is stored at the data repository associated with the server arrangement.

### Claim 8 (depends on 1)

The system of claim 1, wherein the unencrypted intent is stored at the first client device.

### Claim 9

A method for authenticating file transactions in a tri-party setup, the method comprising:
storing a hash corresponding to a transaction in a distributed ledger;
wherein the tri-party set up comprises a first client device, a second client device, and a server arrangement all communicating together to authenticate and perform the file transactions, the method further comprising:
generating an unencrypted intent and an encrypted intent of the first client device, wherein the encrypted intent and the file identifier are shared with the server arrangement so as to raise a request for accessing a secured file, wherein the request for accessing the secured file is time bound wherein the encrypted intent is generated by encrypting the unencrypted intent with a first client key, wherein the first client key is dynamically generated at the first client device;
generating an unencrypted consent and an encrypted consent of the server arrangement, wherein the encrypted consent is generated by encrypting the unencrypted consent with a server key, wherein the encrypted intent and the unencrypted consent are stored at the server arrangement, wherein the encrypted consent of the sever arrangement is time bound;
communicating the encrypted consent to the first client device along with a location of the second client device;
communicating the encrypted consent, the unencrypted intent, and the first client key from the first client device to the second client device based on the received location of the second client device;
communicating the encrypted consent from the second client device to the server arrangement;
validating the encrypted consent by comparing the encrypted consent received from the second client device with at least two newly generated encrypted consents at the server arrangement, wherein the at least two newly encrypted consents are generated by encrypting the unencrypted consent with the server key, wherein the at least two newly encrypted consents include a current timestamp and a predefined prior timestamp;
generating at least two new encrypted intents, at the second client device, based on the validation of the encrypted consent, wherein the at least two new encrypted intents are generated by encrypting the unencrypted intent with the first client key, wherein the at least two new encrypted intents include current timestamp and a predefined prior timestamp;
validating the encrypted intent stored at the server arrangement by comparing the encrypted intent with the at least two newly generated encrypted intents received from the second client device,
wherein the second client device receives a confirmation of the validation of the encrypted intent to authenticate the server arrangement.

### Claim 10 (depends on 9)

The method of claim 9, further comprising generating a transaction key by encrypting a first client identifier, a second client identifier and a file identifier with the first client key.

### Claim 11 (depends on 9)

The method of claim 9, further comprising validating the hash corresponding to the transaction by comparing the hash received from the server arrangement and hash received from the distributed ledger.

### Claim 12 (depends on 10)

The method of claim 10, further comprising validating the transaction key to authenticate the transaction, wherein the transaction key is validated by comparing the transaction key stored at the distributed ledger with a new transaction key, wherein the new transaction key is generated by encrypting the first client identifier, the second client identifier and the file identifier with the first client key stored at the second client device.

### Claim 13 (depends on 9)

The method of claim 9, further comprising sharing payment details associated with the transaction for validation at the server arrangement.

### Claim 14 (depends on 9)

The method of claim 9, further comprising associating the received file identifier with a list of second client identifier to identify the second client identifier and the location of the second client device, wherein the list of second client identifier and file identifier are stored in a data repository associated with the server arrangement.

### Claim 15 (depends on 9)

The method of claim 9, further comprising storing the unencrypted consent, the encrypted intent, and the server key used for encrypting the unencrypted consent at the data repository of the server arrangement.

### Claim 16 (depends on 9)

The method of claim 9, further comprising the unencrypted intent stored at the first client device.