AU2020101073A4

AU2020101073A4 - Data verification system and method

Info

Publication number: AU2020101073A4
Application number: AU2020101073A
Authority: AU
Inventors: Tarique Bhuiyan
Original assignee: Hashkloud Pty Ltd
Current assignee: Hashkloud Pty Ltd
Priority date: 2017-01-13
Filing date: 2020-06-21
Publication date: 2020-07-23
Anticipated expiration: 2026-01-14
Also published as: AU2018207471A1; WO2018130994A1

Abstract

A method and system for confirming and verifying the existence of a data object the veracity of which is being queried in relation to a subject uses a communications hub configured to communicate with a verifier holding data concerning a designated subject. A verification request is compiled, a predetermined function known to both the verifier and the hub is applied to the data object, generating a data object value specific to the data. This is recorded to a distributed electronic ledger system, for obtaining a receipt to provide a permanent record of the data object value and thus of the data. The verifier receives the request and receipt, as proof of the existence of the data object. The verifier applies the predetermined function to the data it holds to generate a comparison data object value. Correspondence between the values confirms veracity of the queried data object. SHEET 1OF 3 18 20 VERIFIER HNewReq 14 Request H blocks 'a', 'b', 'C' Step 3 Step632 Step 6 Code 24 36 BC 30 'a', 'd', [date] I 42 16 Step 5 H UB 3 8 22 Step te H Request: blocks'a','b', 'c' Step 1 12 FIGURE 1

Description

A method and system for confirming and verifying the existence of a data object the veracity of which is being queried in relation to a subject uses a communications hub configured to communicate with a verifier holding data concerning a designated subject. A verification request is compiled, a predetermined function known to both the verifier and the hub is applied to the data object, generating a data object value specific to the data. This is recorded to a distributed electronic ledger system, for obtaining a receipt to provide a permanent record of the data object value and thus of the data. The verifier receives the request and receipt, as proof of the existence of the data object. The verifier applies the predetermined function to the data it holds to generate a comparison data object value. Correspondence between the values confirms veracity of the queried data object.

SHEET 1OF 3

18 20 VERIFIER HNewReq 14 HRequest blocks 'a', 'b', 'C' Step 3 Step632

Step 6

Code 24 36 BC 30 'a', 'd', [date] I 42 16 Step 5 H UB 38

te 22 Step HRequest: blocks'a','b', 'c'

Step 1

12

FIGURE 1

DATA VERIFICATION SYSTEM AND METHOD

Field of invention

[01] This invention relates to the verification and authentication of a data object, in particular concerning an entity, be it a device, such as a data signal emitting 'thing' on the internet of things ('loT'), document meta-data, a person, an agency, a corporation or other organisation.

Background to the invention

[02] The existence and irrefutability (E&I) as well as the verification and authentication (V&A) of specific data objects are coming under increased threat as online vulnerabilities are exposed, patched and repatched.

[03] In this specification, the term 'data object' refers to multiple pieces of data or meta-data about an entity or about some specific data that the entity holds or owns, including digital assets, digital instructions of transactions and financial transactions. The data object typically contains data arranged in two or more data fields. If a data field is detected to contain data, it is reported to be populated. If there is no data in the field, the field is considered unpopulated. Whether a field is populated or unpopulated has significance, irrespective of the data contained in the field if populated.

[04] Where the data object emanates from an entity other than a device, the non-device entity would have associated computers and communications systems which they would use to transmit data about themselves or entities or things with which they interact. The data object may for example include or relate to digital instructions concerning transactions, including financial transactions. In the case of a thing, the data object may comprise condition monitoring measurements.

[05] Extensible mark-up language data (XML data) and Java-Script Object Notation (JSON) data are considered to be self-describing or self-defining, meaning that the structure of the data is embedded with the data, so that when the data is received by a recipient device, there is no need to pre-build the structure to store the data: It is dynamically understood within the XML or JSON data. The XML and JSON formats can be used by any entity or group that wants to share information in a consistent way.

[06] A secure hash algorithm (SHA) is a set of algorithms developed by the US National Institutes of Standards and Technology (NIST) and other government and private parties. These provide secure encryption or "file check" functions and have arisen to meet some of the top cybersecurity challenges being encountered, as public service groups work with government agencies to provide better online security standards, both for organizations and the public. Computing the hash value (or 'hash') of a downloaded file and comparing the result to a previously published hash for that file, can show whether the download has been modified or tampered with.

[07] Blockchain is a known distributed ledger technology that assists in the transfer of data through a plurality of routes and the checking at the receiving end for correspondence between the data files received and the data sent. A blockchain receipt is digital, algorithm-produced, cost-efficient and permanent evidence of a Blockchain transaction. It proves that data was recorded in the blockchain and can be used to verify the contents and timestamp of any file, database record, photo, etc. It eliminates the need for middlemen, transaction processors and verifiers.

[08] The recipient of a blockchain receipt pertaining to a third party blockchain transaction will be empowered to know that certain data has been recorded on the blockchain.

[09] US patent application publication no. 2008/0172339 discusses methods of authenticating transactions using a computer program wherein a first data pattern is sent to a mobile telephone requesting a transaction and a second data pattern is sent to a verifier system by a device managing a transaction for a business. The respective data patterns are encrypted using a private key and decrypted using a public key with correspondence being tested. However, the issue of the irrefutability of the data underlying the data pattern is not addressed.

[010] Patent US 8,386,774 (Lin) makes use of a one-way hash function in verification of a transaction- or event-logging system, when testing the integrity of a transaction data set. The trusted third party is not required to perform any hashing on the data that it holds about the transacting party, leaving open an opportunity of compromising the security of the transaction.

Object of the invention

[011] It is an object of this invention to address the shortcomings of the prior art and, in doing so, to provide a method for verifying and further, irrefutably establishing the existence of, certain data, especially data of a restricted nature.

[012] The preceding discussion of the background to the invention is intended to facilitate an understanding of the present invention. However, it should be appreciated that the discussion is not an acknowledgement or admission that any of the material referred to was part of the common general knowledge in Australia or elsewhere as at the priority date of the present application.

[013] Further, and unless the context clearly requires otherwise, throughout the description and the claims, the words 'comprise', 'comprising', and the like are to be construed in an inclusive sense - that is to say "including, but not being limited to" - as opposed to an exclusive or exhaustive sense, meaning "including this and nothing else".

Summary of invention

[014] The invention provides for achieving verification and authentication (V&A) of a data object using cryptographic technologies, such as secure hash algorithms (or SHA), without the need for the party that owns the data, or a party requesting the data, who wishes to have at least a portion of said data verified, to give out or to divulge any of the actual data to each other or to a data verification engine operable by an independent third party. This is achieved by utilising

Blockchain techniques to verify and authenticate, as well as prove the existence and irrefutability of at least a portion of, the data object.

[015] The data not to be divulged to requestor or hub will be referred to as 'restricted data' and will generally be of a confidential or personal nature. By way of example, it may relate to the financial position or the financial transactions of a subject.

[016] According to a first aspect of the invention, there is provided a method of verifying and confirming the existence and irrefutability of a data object, the veracity of which is being queried in relation to a subject, the method comprising the steps of:

a. Providing a communications hub configured to communicate with a verifier holding data pertaining to a designated subject;

b. Compiling a verification request in respect of the data object being queried,

c. Applying to the queried data object a predetermined function known to both the verifier and the hub to generate a data object value specific to the queried data;

d. Recording the data object value to a distributed electronic ledger system for obtaining a receipt from such ledger system providing a permanent record of the query data object value;

e. Sending the verifier the verification request and receipt, as proof of the existence of the query data object,

f. Having the verifier apply the predetermined function to the data it holds to generate a comparison data object value,

g. Comparing the queried data object value and the comparison data object value, and, h. On the basis of correspondence or otherwise between said values, to issue notification as to the veracity of the queried data object.

[017] Preferably, the hub is equipped with an access portal allowing remote authorised access thereto.

[018] In a preferred form of the invention, the method includes providing the data object in a pre-arranged data object pattern.

[019] Preferably, the request includes the data object pattern.

[020] In a further preferred form of the invention, the method further includes holding data object patterns at the hub and making said patterns accessible to external requestors.

[021] In a preferred embodiment, the predetermined function is one that has been agreed on by requestor and hub. In an embodiment where the hub does not exist separately from the requestor, the function is agreed between requestor and verifier (the latter being the entity that performs the verification, not the one that instigates or requests it). Preferably, the verifier returns the comparison value to the hub for comparison.

[022] In a still further preferred form of the method, the request further comprises a first information item relating to the subject.

[023] The method preferably also includes:

• allocating a unique request identifier to the request and forwarding both request and identifier to the verifier; and

• causing the verifier to provide a second information item to the subject and to invite the subject to present both first and second information items to the hub access portal.

[024] In a further preferred form of the invention, the step of applying the predetermined function comprises processing the data according to a data object pattern. The data object pattern is held in a bank of data object patterns saved to be accessible from a server associated with the hub.

[025] The method may further comprise the steps of causing the hub to apply the predetermined hash function to generate a second hash value relating to the data object pattern, recording to a Blockchain the second value and obtaining a Blockchain receipt in respect thereof.

[026] The method further may include causing the hub to communicate the Blockchain receipt to the verifier.

[027] According to a second aspect of the invention, there is provided a system of verifying and confirming the existence and irrefutability of a data object being queried as to its veracity in relation to a subject, the system comprising a communications hub configured to communicate with a verifier holding data pertaining to a designated subject; and programmed with executable instructions for:

• Compiling a verification request in respect of the data object being queried,

• Applying to the queried data object a predetermined function known to both the verifier and the hub to generate a data object value specific to the queried data;

• Recording the data object value to a distributed electronic ledger system for obtaining a receipt from such ledger system providing a permanent record of the query data object value;

• Sending the verifier the verification request and receipt, as proof of the existence of the query data object,

• Having the verifier apply the predetermined function to the data it holds to generate a comparison data object value,

• Causing comparison of the queried data object value and the comparison data object value, and,

• On the basis of correspondence or otherwise between said values, issuing notification as to the veracity of the queried data object.

[028] In a preferred form of the system of the invention, the data object is provided in a pre-arranged data object pattern.

[029] Preferably, the data object pattern is included in the request.

[030] The predetermined function preferably comprises a hash function agreed on by the verifier and the hub.

[031] The system preferably configured for the hub to be programmed to receive from the verifier the comparison value for comparison.

[032] The request may comprise a first information item relating to the subject.

[033] The system may further be set up so that a unique request identifier is allocated to the request, and is sent to the verifier along with the first information item and the hub is programmed to cause the verifier to provide a second information item to the subject and to invite the subject to present both first and second information items to an access portal of the hub.

[034] The hub, in a preferred embodiment, is configured for selecting the predetermined function from a bank of selectable logical functions that are executable on data the veracity of which is being queried.

[035] The hub, in a further preferred embodiment is configured for communication with a device from which it receives a query for data verification and compiles the request

[036] According to a third aspect of the invention, a verification system in respect of restricted data comprises a communications hub operable intermediate a verification requestor and a verifier, the hub being configured to provide access to a bank of selectable logical functions that are executable on data in respect of which verification is to be sought, and computation means for executing a function once selected to generate a function value, the system also at least transiently comprising:

(a) a message requesting verification of specified restricted data, the message being in a form communicable to the verifier via the hub,

(b) a confirmation message confirming existence of a relationship between verifier and a subject associated with the restricted data,

(c) a logical function selected for operating on a variable relating to the restricted data,

(d) a function value when executed in relation to an element of the message,

(e) a comparison outcome, representing correspondence between first and second function values computed in relation to the message element, and

(f) a verification message dependent on the comparison outcome.

[037] In a preferred form of the invention, the hub is further configured to receive the verification request message from the requestor, to add a request identifier to the message and forward the message with the identifier to the verifier.

[038] Preferably, the hub comprises an online portal configured for communication with the subject associated with the restricted data.

[039] In this form of the invention, the hub is configured for Blockchain interaction. The verifier is likewise Blockchain-configured.

[040] Further, in a preferred embodiment, the hub is configured for holding data object patterns and making the data patterns accessible to external requestors.

[041] In an embodiment, the first and second function values are computed independently by the verifier and the hub or requestor.

[042] In a fourth aspect of the invention, a method of data verification is provided, the method comprising the steps of:

a. Providing a data hub configured for holding data object patterns,

b. Charging the hub with data object patterns to be held thereon and causing the data patterns to held to be accessible to external entities;

c. Sending to the hub a request to verify data in relation to a data object associated with a subject, the request comprising a data object in a selected pattern; and

d. Responsive to said verification request, causing the hub to confirm the data object with a verifier having communication with the subject.

[043] In a preferred form of the invention, the hub comprises a data processing platform having a data processor.

[044] In a preferred form of the invention, the step of causing the hub to confirm the data object comprises confirming said object via an entity that independently of the hub holds original data associated with the subject.

[045] In a further preferred form of the invention, the step of confirming the data object portion comprises applying cryptographic methods to the data object.

[046] In an embodiment, the method includes applying a nested hash function to the data object.

[047] The method preferably further includes the step of establishing the existence of the data for which verification is to be sought. Preferably the existence of otherwise of the data is established by recording a file containing information derived from the data to Blockchain.

Brief description of drawings

[048] In order that the invention may be readily understood, and put into practical effect, reference will now be made to the accompanying figures. Thus:

Figure 1 shows in schematic view a preferred embodiment of the process of this invention.

Figure 2 is a table showing the data and information flow paths between entities when the process is implemented.

Detailed description of an embodiment of the invention

[049] The invention provides for achieving verification and authentication of data objects comprising data that has been arranged in an agreed, preferably standardized, form. The invention makes use of cryptographic technologies, for example Secure Hash Algorithms (SHA), without the need for a primary verification-capable entity - such as a party that holds (for example on the basis that it owns) the data - or the requesting entity, who wishes to establish the validity of at least a portion of said data before entering into a transaction with the data owner, to give out or to divulge any of the actual data to each other, or to a data hub having a verification platform engine. The hub is operated independently of requestor and verifier, for example by a third party.

[050] Blockchain techniques are employed to prove the existence and irrefutability of the data being verified. The data may include financial transaction instructions and data relating to digital assets. In the exemplary embodiment presented below, the implementation of the invention is in a context of verifying data concerning parties to a proposed financial transaction. However, the invention is not confined to this field and transactions between different entities need not necessarily be involved.

[051] The data object is provided in a specific data format, non-limiting examples including XML (Extensible Mark-up Language) and, preferably JSON (Java Script Object Notification). Data structures in JSON are based on key / value pairs. The key is a string, while the value may be numerical, Boolean (true or false), an object, or a combination of any of these.

[052] Any data able to be held and communicated in a standardized format is able to be verified using the data hub method of this invention. If a data set requires verification and authentication (V&A), but no standard exists for that data set, then the requestor will need to attach the data schema or data object pattern (but not the actual data) with their request message.

[053] According to the invention, it is contemplated that a disinterested party, or a third party at arm's length, operates the data hub and publishes data object patterns, which are identified to users by way of unique object pattern identification (ID) strings. The hub includes a processor, a search engine and communications hardware and software.

[054] Referring to the diagram of Figure 1, the steps of the process are set out in a non-limiting example of this invention. Thus, at step 1, a requestor 12 issues an online request 14 to a data hub 16. The data hub comprises a data processing platform having data processing hardware and software defining a data search engine, as well as digital communications capacity including an email client and communications hardware, including for text messaging, such as via a short messaging system (SMS).

[055] The request is sent by way of a data file in any acceptable format, for example using XML or preferably JSON via REST services over the web, or even via a secured electronic mail service. In the case of the latter, the data object is attached to the email as a JSON or XML object. In other examples, it may be sent as an XML or a JSON file, or even as a text file (.TXT).

[056] It must be appreciated that the data object is to be distinguished from the actual data in respect of which the requestor seeks verification.

[057] The data object in request 14 is made up of a plurality of data blocks. In this embodiment, they are:

(a) A header block, 'a': This comprises fields providing limited data about a subject 22 of a verifying entity 18, in whom requestor 12 has an interest. The subject is associated with the verifier. It may, for example, be a customer of verifier 18 and a prospective customer of requestor 12. Non-limiting examples of these fields are:

1. A request identifier (ID), preferably allocated by the requestor to identify its request for future reference and response. However, it may alternatively be allocated by the data hub operator, or according to a protocol prescribed or agreed between requestor and hub operator.

II. An indicator of the request type: The type may, for example, be for verification and authentication (V&A) of a data object. This is referred to below as a 'type 1' request. The type of request may alternatively be or relate to an instruction for performing a financial transaction for both V&A and transaction processing - referred to as a 'type 2' request.

III. A customer reference number (CRN): This is a reference number previously allocated by verifying entity 18 to the subject. The CRN will identify the requestor's subject of interest to the verifier. The CRN is held in a database of entity 18.

IV. An access identifier in respect of data hub 16: This is a string furnished to the subject for use in gaining access to a portal for obtaining access to the hub. The access identifier may be, for example, an email address of the subject, or a user ID of a different form, which has been allocated and recognized by the data hub, as an access ID for use by the subject.

V. The subject's first name, last name and date of birth (in the case of an individual) or entity name and date of incorporation or registration number for a corporate body.

VI. A data object pattern identifier (ID), published by the data hub.

(b) Instruction data block 'b': If request 14 is a transaction instruction (a type 2 request), this block will set out the instruction/s for the transaction. The instructions are arranged according to a predefined data object pattern. This data block is of course not required for a type 1 request, where no transaction is being actuated. Optionally, in a preferred version of the invention, block 'b' will, in addition to the instructions, contain a status code, which may have any of the following values:

'O' meaning 'to be processed',

'1' meaning 'processed with positive results',

'2' meaning 'processed with negative results', and

'9' meaning 'not processed'.

(c) A hash value (HRequest) block 'c': This provides the value of the total hash (also known as the message digest) of the data that belongs to the data object pattern in block 'b'. This hash value is recorded onto a Blockchain and the Blockchain receipt is separately sent to the verifier.

[058] The data of block'a' therefore:

• identifies the request to the hub operator (or, when the hub operator itself is the requestor, identifies it in a log or similar administrative tool),

* identifies the subject of the request to the verifier,

• provides an access code for use by the subject for accessing the hub (in cases wherein the hub is not also the requestor);

• categorizes the request by type, and

• indicates the format or pattern of the data for which verification is being requested.

[059] It will be appreciated that, for financial transaction requests (type 2 requests), the hash value in block 'c' (HRequest) is therefore the hash of the instructions of block 'b'. The invention thus includes hashing the data object and recording the hash onto a Blockchain, with the Blockchain receipt separately being sent to the verifier, proving the existence of the data object and data.

[060] In Figure 2, the information flow is schematically tracked in tabular form in the steps to be further described below.

[061] On receiving request 14, data hub 16 forwards it, as denoted by the label 14', to an entity 18, which is known to hold or be otherwise enabled to access the subject data to be verified. By way of example, the situation may involve a business A (as requestor 12) requesting verification of an account number NNN held by subject B (subject 22) at Bank C, which is in the role of verifier 18.

[062] Forwarded request 14' is supplemented by a request identifier block, 'd', which the data hub uniquely allocates to this request. Block 'd' represents an additional data item, as seen at step 2 in Figure 1. Together with forwarded request 14', it constitutes a new request 20.

[063] Bank C in this example represents the entity 18 that is called on to verify the data object contained in original request 14. It is therefore referred to as the 'verifier'. The verifier receives new request 20 from data hub 16 and, at step 3, sends to the customer concerned, being subject 22, a confirmation code 24, together with the request ID generated within block 'a' (which hub 16 had received from requestor 12). These data items are sent to subject 22 via a mobile telephone text message in this embodiment, although any other suitable known communication means (preferably digital) may be used as an alternative.

[064] Verifier 18 applies the predesignated hash function used by hub 16 (or requestor 12 as the case requires), for example SHA512, to the variables below:

SHA512(Subject hub confirmation code 24 + Requestor's original request ID +

hub-generated request ID 'd'+ date of request 'd')

[065] Verifier 18 then makes a record of the verification request it has received. In this record it stores the hash value computed above. Alternative functions may of course be used.

[066] Subject 22, having received code 24 and the original request ID, with instructions relating to their use, carries out the instructions by logging on to an access portal associated with data hub 16 and inputs the code and the request ID when prompted (see step 4). An alternative way of confirming the instruction is 2 Factor Authentication (2FA), using a mobile telephone handset or equivalently 2FA-capable device.

[067] The subject's act in accessing the hub portal successfully, using the confirmation code and inputting the original request ID, proves to the hub operator the subject's association with the CRN because the verifier used the CRN it received to determine to which of its customers (subjects) it should send the code and request ID.

[068] In response to the subject's successful access, a data processor associated with data hub 16 is operated to apply SHA512 again to the hash value computed above, plus the variable of block 'c', thereby determining a further hash value as follows:

HNewRequest= SHA512((SHA512(hub confirmation code 24 + Requestor's original request ID + Hub-generated request ID 'd' + Request date) + 'c'))

[069] At step 5, hub operator 16 records the value HNewRequest on to Blockchain , for which it receives a Blockchain receipt 32, proving the fact that the data has existed.

[070] Data hub 16 then, at step 6, responds by sending a file containing the value it has calculated for HNewRequest to verifier 18, along with the following:

• The original request ID from block 'a',

• The hub identifier 'd' that it generated for association with original request 14; and

• A copy of Blockchain receipt 32.

Type 1 Requests

[071] In the case where the request 14 is of type 1, that is where the requested data object relates to information for V&A only, not for a transaction to be carried out, verifier 18 extracts the requested data from its database against the CRN number supplied and then applies the same secure hash logic to the data to find the Hash value (HResponse). In the present example, in which the SHA function being applied is SHA512, the outcome is the result of performing the following logic:

HResponse = SHA512((SHA512(Code + Original Request ID + Data hub Request ID 'd' + Request Date) + 'c')).

[072] If the value HNewRequest = HResponse, then verifier 18 sends a positive response 36 back to data hub 16 - see step 7. Failing hash value parity, a negative response is returned, by way of verifier 18 logging the appropriate process status code (from the options 0, 1, 2 and 9 listed above) in the header data block.

[073] Data hub 16 records the request and response details onto Blockchain and thereafter, in step 8, forwards the positive / negative response received from verifier 18 to the third party requestor 12.

[074] Verifier 18 verifies that the HNewRequest has not been tampered with, by making use of Blockchain receipt 32 it received at step 6.

Type 2 Requests

[075] The following steps will be implemented subsequent to step 6, when the request is of type 2, i.e. where the data object is in the form of or comprises a financial transaction instruction and where the request is for V&A as well as transaction processing.

• Verifier 18 checks the file it receives from the hub for signs of tampering: It locates SHA512, computes SHA512('b') and SHA512('c'). Parity on comparison will confirm the data in 'b' has not been tampered with.

• Verifier 18 then extracts the data from its database against the subject's CRN number supplied. It then applies the same logic to the data, i.e. SHA512((SHA512(Code + Original Request ID + Hub 16's Request ID'd'+ Request Date) + 'c')) to determine a response hash value, HResponse

[076] Verifier 18 adds the further step of verifying that the HNewRequest has not been tampered with, by using Blockchain receipt 32 that it received from hub 16.

[077] If HNewRequest = HResponse, then the verifier processes the requested financial transaction in relation to the subject customer associated with the CRN in block 'a'.

[078] If both legs of the financial transactions (i.e. debit and credit) are within the same financial institution, such as verifier 18 in this example, the verifier financial institution processes the following transactions:

• debit to ordering subject account and credit to an Intra-Bank Settlement account of data hub 16, followed by

* debit to said Intra-Bank Settlement account and credit to the beneficiary subject account.

[079] Verifier 18 thereafter sends a positive or a negative response back to data hub 16 with the same data fields as header data block'a', but having changed the 'Process Status' code either to '1', meaning a Positive, or '2', meaning a Negative, response.

[080] If the respective legs of the financial transactions (i.e. debit and credit) are in different financial institutions, whether in the same or different countries, then the following occur:

• Verifier financial institution 18 processes the first leg of the transactions:

* debit to ordering subject account (A) and

* credit to the data hub Interbank Settlement account B (if in the same country) or credit to Interbank Nostro Settlement account (if in different countries).

• Verifier financial institution 18 sends a 'positive' or a 'negative' response back to data hub 16 with the same data fields as 'a', but having changed the 'Process Status' code either to '1', meaning a positive, or'2' meaning a negative, response.

• Data hub 16 then records the request / response details onto Blockchain and forwards the positive / negative response received from the verifier 18 to third party requestor 12.

[081] As noted, the second leg of the transaction in this embodiment is processed by a second verifying entity 34 (see Figure 1), according to the following protocol:

[082] If the response received by data hub 16 from verifier 18 is positive, it then sends the request 14 containing blocks 'a', 'b' and 'c' along with the positive response to said second verifier 34 in a data package 38.

[083] Second verifier 34 processes the second leg of the transaction, namely: It debits either the Interbank Settlement account B, if located in the same country as verifier 18, or the Interbank Nostro Settlement account of platform 16, if located in a different country, and credits the nominated beneficiary account.

[084] Second verifier 34 sends a response 42 to the data hub with the same data fields as header data block 'a' but with the 'Process Status' code changed either to '1' meaning 'Positive' or a '2' meaning 'Negative'. The hub provides appropriate confirmation to the requestor.

[085] Examples of data object patterns (DOPs) are set out below and should not be construed as limiting:

1 Personal Banking / Insurance Accounts & Balances/ Transaction(s) / Transaction Instruction(s) / Liens / Bills Discounting/ Limits, etc.: Non-limiting examples of DOPs are provided below: Bank Account details (CRN, Date, A/C Number, A/C Open Date) Insurance Account Details (CRN, Date, Insurance A/C number, A/C Open Date), Bank Account Limit Details (CRN, Date, A/C Number, Limit Amount, Limit Currency Code) Customer Proof of Age (CRN, Date, customer's age in range), Account Balance (CRN, A/C number, Balance, Date) Transaction /Receipt Verification (CRN, Bank Details, Transaction/ Receipt Details) Funds or Asset Lien (CRN, Bank Details, Funds or Asset Details) Financial Transaction Instruction (CRN, Date, Debit Account Details, Debit Account Details, the data hub Financial Transaction Instruction Token, etc.) 2 My Txns/ Receipts / Pass / Tickets / Prescriptions / Warranty / etc.: Example of DOP like Boarding Pass Details (CRN, Flight Number, Flight Date, Boarding Pass Reference #), etc. 3 My Loyalty Accounts / Balances, etc.: Examples of DPO like Loyalty Account Details (CRN, Loyalty Balance), etc. 4 My Utility & Telco Accounts: Example of DOP like Cell Phone Number Ownership (CRN, Cell Phone Number, First Name, Last Name, DOB, etc.), Utility Account Details (CRN, Utility Company, Utility Account Number, First Name, Last Name, etc.), etc. My documents: Example of documents include Application form as a document (e.g. PDF document) and not as a web form (for any service) where the DOP includes document meta-data (CRN, Document Number, DOB, Mobile Phone Number, etc.). The same could be applied to any digital document including legally binding agreements, certificates, event admission tickets, and the like.

[086] From the above it can be appreciated that restricted data may be personal data relating to a subject and defines a data object in this invention. The data object consists of a range of data types. These may be stored in data fields in a database operated by third party agency, such as a regulatory authority, or an educational, financial or commercial institution. The invention provides for the use of data object patterns created in relation to selected data combinations from various data types. The data object patterns (but not the actual data) are retained on a purpose-built platform, for example a hub, and made available via a web portal to requestors.

[087] When a requestor wants to verify data about a subject, that requestor will send a V&A request to the platform or hub operator and, in response, the data hub engine will confirm (or refute) the data or data object sent by the requestor. Since the data object pattern exists and can be verified using the Blockchain receipt, it can be assumed the data that forms the pattern has integrity. The data hub will also record particular requests and response combinations on to Blockchain, as proof of existence and integrity (E&I), as well as for audit purposes for the data.

[088] The embodiments described and proposed merely illustrate particular examples of the method, system and apparatus of the invention providing means for the authentication of data being transferred from a transferor to a recipient. With the insight gained from this disclosure, the person skilled in the art is well placed to discern further embodiments by means of which to put the claimed invention into practice.

end

Claims

1. A method of using a computer network in verifying and confirming the existence and irrefutability of a data object, the veracity of which is being queried by electronic communication in relation to a subject, without data from the data object being divulged, the method comprising the steps of operating programmed interacting computer systems to execute machine-readable instructions for:

a. Providing a communications hub configured to communicate with a data storing and transaction-processing verifier system that holds data pertaining to a designated subject;

b. Causing compilation of a verification request in respect of the data object being queried,

c. Applying to the queried data object a predetermined function known to both the verifier system and the hub to generate a data object value specific to the queried data;

d. Recording the data object value to an electronic distributed ledger system for obtaining a receipt from such ledger system that provides a permanent record of the query data object value;

e. Sending the verifier system the verification request and receipt, as proof of the existence of the query data object, without sending the data itself,

f. Having the verifier system apply the predetermined function to the data it holds to generate a comparison data object value,

g. Comparing the queried data object value and the comparison data object value, and,

h. On the basis of correspondence or otherwise between said values, to issue notification as to the veracity of the queried data object.

2. The method of claim 1, wherein the request comprises a first information item relating to the subject and includes the step of allocating a unique request identifier to the request, sending both to the verifier system; causing the verifier system to provide a second information item to the subject and to invite the subject to present both first and second information items to the hub access portal.

3. A programmed computer system for verifying and confirming the existence and irrefutability of a data object, the veracity of which is being electronically queried in relation to a subject, the system comprising a communications hub associated with a computer processor that has been configured to communicate with a data holding verifier system that holds data pertaining to said subject and programmed with executable instructions for:

a. Compiling a verification request in respect of the data object being queried,

b. Applying to the queried data object a predetermined function known to both the verifier system and the hub to generate a data object value specific to the queried data;

c. Recording the data object value to a distributed electronic ledger system for obtaining a receipt from such ledger system providing a permanent record of the query data object value;

d. Sending the verifier system the verification request and receipt, as proof of the existence of the query data object,

e. Having the verifier system apply the predetermined function to the data it holds to generate a comparison data object value,

f. Causing comparison of the queried data object value and the comparison data object value, and

g. On the basis of correspondence or otherwise between said values, issuing notification as to the veracity of the queried data object, whereby said data itself is not divulged to the verifier system.

4. The system of claim 3, wherein the hub is programmed to receive from the verifier system the comparison value for comparison.

5. A data-containing data object having verified existence and irrefutability based on:

a. correspondence between first and second hash values independently computed for the data object respectively at a communications hub and a verifier system, by applying to the data object a predetermined hashing function, without data in said object being divulged to the verifier system,

b. a receipt being

i. issued by an electronic distributed ledger system permanently recording the first hash value and

ii. communicated to the verifier system as proof of existence of the data object; and

c. the second value being computed by applying the hashing function to comparison data held by the verifier.

SHEET 1 OF 3 21 Jun 2020

18 20 2020101073

VERIFIER HNewReq: ’d’ + 14’ Request H : blocks ‘a’, ‘b’, ‘c’ Step 3 Step 6 32

A Step 2 34 B Step 7

36 BC 30 Code 24 ‘a’, ‘d’, [date] 42 16 Step 5 HUB 38

Step 14 22 4 HRequest: blocks ‘a’, ‘b’, ‘c’

Step 1 Step 8

12

FIGURE 1

SHEET 2 OF 3

21 Jun 2020

REQUESTOR

DATA HUB

VERIFIER

SUBJECT 12

16

18

22 Sends request (14) 2020101073

comprising ‘a’, ‘b’, ‘c’: ‘a’ has: Original request ID Forwards request (14’) Request type (1 or 2) + hub’s request ID ‘d’ Sends subject: CRN (for Verifier) As new request (20) Portal access code (24) Hub UID for Subject + Original request ID Computes Personal details & stores value HNewRequest Data object pattern ID ‘b’ instructions + Status code 0/1/2/9 Hash Accesses portal Computes value HNewRequest Sends to BC and to STEP 6 Verifier + Orig Req ID + Hub Req ID + BC receipt (opt) Extracts requested data using CRN Computes HResponse from #(Access Code; Orig Req ID; Hub Req ID; Req date) + ‘c’ + BC TYPE 1 REQUEST Recpt Compare HNewRequest = HResponse? Send positive or neg result + status code 0/1/2/9 Records request & response details to BC; Forwards pos/neg response to Requestor

SHEET 3 OF 3 21 Jun 2020 REQUESTOR 12

DATA HUB 16

VERIFIER 18

SUBJECT 22 TYPE 2 REQUEST Forwards request 14 == 2020101073

Receives forwarded request, Checks for tampering: retrieves and applies SHA512(‘b’) Computes SHA512(‘c’) Compares SHA512(’b’)= SHA512(‘c’) Reports to hub Confirms correspondence to Requestor

FIGURE 2