HK1258030B - A system and method for document information authenticity verification - Google Patents

Description

System and method for document information authenticity verification

Technical Field

The present invention relates to document information authenticity verification, and in particular, but not necessarily completely, to a system and method for document information authenticity verification for use in applications including: verifying authenticity of information declared by achievements of course documents published by registered training organizations, verifying travel documents and other sensitive documents requiring authenticity verification, such as documents published by law firms, accounting firms, government agencies, and the like.

In addition, the authenticity verification techniques described herein may be widely applied to different document media, including hard copy formats (i.e., paper, smart card travel documents) and soft copy formats (i.e., electronic formats, including PDF formats, including storage within a document repository).

Background

Document authenticity verification is desirable for applications including: such as verification of the authenticity of information in legal documents, personal identification documents, authentication documents, access documents, and the like.

The problems with these documents include: the information contained therein may be modified, wherein, for example, authentication is falsely claimed, documents are forged, and so on.

D1: US 2011/0161674 a1(MING), 6.30.2011, attempts to solve this problem by disclosing a method of generating a self-authenticating document in which authentication information for the document is encoded in a barcode that is printed on the document. A hash is computed from the authentication information and transmitted to the server for storage. Upon authenticating the scanned copy of the document, the barcode is read to extract the authentication information. A target hash is computed from the extracted authentication information and transmitted to the server for verification. The server compares the target hash to previously stored hashes. If they are not the same, the barcode has been altered. If they are the same, the scanned copy is authenticated using the extracted authentication information. A document ID may be generated and transmitted to the server, and the stored hash indexed or searched by the server using the document ID.

However, D1 has disadvantages and the server may be compromised and the hash stored therein may be modified to match the tampered document.

Thus, D1 is not suitable for applications requiring high security stringency, such as for boarding passes, personal identification documents, and the like.

Thus, in a preferred embodiment, the present invention utilizes a distributed password-based blockchain to store document authentication records in an unalterable manner.

Currently, D2: according to Wayback Machine's D2 published on 12/2015 and 22: "What is said of existence? "[ 2016 retrieve from the Internet 4/20 ] < URL: https:// web. architectural.org/web/20151222163927/https:// pro-office existence. com/about >, disclosing a blockchain for storing an online distributed proof of existence of a document by storing individual encrypted digests of the respective document in the blockchain.

D2 hashes an electronic document (such as PDF) and stores the hash as a special bitcoin transaction that encodes/contains the hash via OP _ RETURN script. This is a bitcoin script opcode that marks the transaction output as provably unreliable and allows the insertion of a small amount of data (which in this case is the hash value of the document) along with a flag identifying all transactions of D2.

However, D2 does not address the issue of verifying the authenticity of information in a document, but rather proves that a particular document exists in a particular electronic format at a particular time.

Therefore, D2 cannot be used to detect whether a document has been tampered with.

Furthermore, D2 hashes the entire electronic document file and therefore cannot be used for hardcopy documents, where slight print, scan, photocopy appearance aberrations would generate completely different hashes using the system of D2 and therefore the document information contained therein would be unverifiable.

Thus, in a preferred embodiment, the present invention utilizes document content metadata (stored using metadata hashes instead of the document hash of D1) as the basis for verification and thus can be used to hardcopy documents.

Further, D1 and D2 have a disadvantage in that document information cannot be updated while the document remains verifiable.

For example, using D2, a first bitcoin transaction will be created for the original document, and if the original document is updated, a second bitcoin transaction will be created for the updated document.

However, with D2, both the original document and the altered document appear to be valid, even though the original document has been replaced.

In contrast, in one embodiment, the present invention utilizes a blockchain update transaction for the purpose of updating the document content fields in this manner, wherein during the document verification phase, the blockchain may be checked in reverse chronological order to detect whether the document (or a particular document content information field) has been replaced.

Further, both D1 and D2 have drawbacks because the verification cannot be valid for a predetermined period of time.

Rather, according to one embodiment, the present invention creates a blockchain transaction that specifies a validity period.

Furthermore, both D1 and D2 have drawbacks in that documents cannot be revoked.

In contrast, according to one embodiment, the present invention utilizes an undo type blockchain transaction such that an undo of the authenticity of a document may be detected by an undo type transaction that temporally follows a previously authenticated transaction.

Further, D1 and D2 are flawed because the validation information cannot be displayed in association with the document for visual comparison.

Rather, according to one embodiment, the present invention stores the metadata in computer readable data (i.e., a 2D barcode) such as within the document itself or within a blockchain so that the information can then be extracted and displayed to the user.

It will be understood that, if any prior art information is referred to herein, such reference does not constitute an admission that the information forms part of the common general knowledge in the art, in australia or in any other country.

Disclosure of Invention

Thus, in view of the foregoing, according to one embodiment, there is provided a method for document information authenticity verification, the method comprising a verification record creation phase and a document verification phase, wherein the verification record creation phase comprises: receiving document content metadata from a document; generating a metadata hash using the document content metadata; creating a blockchain transaction that includes a metadata hash; generating computer readable data encoding the metadata hash; and updating the document using the computer-readable data; wherein the document verification stage comprises: receiving a document; extracting a metadata hash from the computer-readable data; and identifying a hash of the metadata within a blockchain transaction of the blockchain to verify authenticity of the document metadata.

It will be appreciated that D1 or D2 do not disclose creating a metadata hash for the document information of a document, creating an associated blockchain transaction, and updating the document with computer-readable data (i.e., a 2D barcode) and the metadata hash.

The computer readable data may be a barcode.

The barcode may be a two-dimensional barcode.

The verification logging phase may also include signing the document using a private key associated with the document verification server.

The method may further comprise storing the document content metadata such that wherein the document verification stage may further comprise retrieving the document content metadata and displaying the document content metadata.

Storing document content metadata may include encoding the metadata within computer-readable data.

Storing document content metadata may include encoding the metadata within a blockchain transaction.

The validation record creation phase may also include identifying document content metadata from the document.

The identification of document content metadata may include optical character recognition.

Identification of document content metadata may include performing a search string query against text extracted using optical character recognition.

The identification of the document content metadata may include isolating text within at least one user-defined region of the document.

The method can also comprise a document content updating stage, wherein the document content updating stage comprises the following steps: receiving updated document content metadata for a document; generating a new metadata hash using the updated document metadata; another blockchain transaction is created that includes a new metadata hash.

The document verification stage may include: two or more blockchain transactions associated with the document are identified.

The document verification stage may also include identifying that the document content metadata may be replaced with updated document content metadata.

The method may also include identifying which portion of the document may be replaced.

The method may further include a document authentication revocation phase, the document authentication revocation phase including: creating a revoke blockchain transaction such that during the document validation phase, the method may further comprise: an undo blockchain transaction that follows the blockchain transaction in time is identified to discard verification of authenticity of the document information.

The blockchain transaction also specifies a validity period such that during the document validation phase, the method may further include discarding validation of the document if the validity period expires.

The method may also include creating a validity update blockchain transaction that includes an additional validity period such that the additional validity period may be used in determining the validity of the document during the document validation phase.

According to another aspect, a system for document information authenticity verification may be provided, the system comprising a document information verification server and a client terminal. The document information verification server includes a database and a software module. The database includes: hashing a blockchain; and a document metadata table stored in association with the one-way hash blockchain. The software module comprises: a document creation module; and a document information verification module. The client terminal is in operative communication with the document information verification server. The client terminal includes a computer-readable data reader; a software application in operative communication with the computer readable data reader. The software application includes a document information verification module. Wherein in use the system may be configured for a verification record creation phase and a document information verification phase. The verification record creation phase comprises: the document creation module of the document information verification server: receiving document metadata associated with a document; receiving a one-way hash using a hash algorithm or generating a one-way hash from document metadata; creating an entry for a one-way hash in a one-way hash blockchain; generating computer-readable data comprising at least one of document metadata and a one-way hash; and sending the computer-readable data to a document creation module. The document information verification stage comprises: a document information verification module of the client terminal receiving computer-readable data from the document; at least one of the client terminal and the document information verification server identifying at least one of document metadata and a one-way hash from the computer-readable data, wherein if only the document metadata is received, the one-way hash is generated using a one-way hash algorithm; and a document information verification module of the document information verification server verifying the document by comparing the one-way hash with the one-way hashed entries in the hash blockchain.

The system may also include a document publisher server in operable communication with the document information validation server.

The document information verification server may be configured to receive document metadata from the document publisher server.

The document information verification phase may also include at least one of the client terminal and the document information verification server sending at least one of a one-way hash and document metadata to the document publisher server for further verification of the document.

The document publisher server may include a database containing at least one of hash and metadata data, and wherein the further validating may include cross-referencing at least one of hash and metadata data within the database of the document publisher server.

The document information authentication module of the document information authentication server may be further configured to transmit the authentication result to the client terminal.

The client terminal software application may be further configured for generating a graphical user interface, and wherein the graphical user interface may be configured for displaying the verification result.

The graphical user interface may also be configured to display at least a subset of the document metadata.

The system may include a plurality of document information validation servers, and wherein the blockchain may be a distributed blockchain distributed over the plurality of document information validation servers.

Creating the computer readable data may include creating optical computer readable data.

The computer readable data may be a 2D barcode.

The system may also include inserting the computer-readable data into the document.

Other aspects of the invention are also disclosed.

Drawings

Although there may be any other form which may fall within the scope of the invention, preferred embodiments of the disclosure will now be described, by way of example only, with reference to the accompanying drawings, in which:

FIG. 1 illustrates a system for document information authenticity verification according to an embodiment of the present disclosure;

FIG. 2 illustrates an exemplary method for creating a document information authenticity verification record, according to one embodiment;

FIG. 3 illustrates an exemplary method for verifying the authenticity of a document using a formally created document authenticity verification record, according to one embodiment;

FIG. 4 illustrates an exemplary method for updating document information while also being able to verify the authenticity of the updated document, according to one embodiment;

FIG. 5 illustrates an exemplary method for revoking an authenticity record for a particular document, according to one embodiment; and

FIG. 6 illustrates an exemplary graphical user interface displayed by a client terminal of the system upon verification of the document of FIG. 1 according to one embodiment of the present disclosure.

Detailed Description

For the purposes of promoting an understanding of the principles in accordance with the present disclosure, reference will now be made to the embodiments illustrated in the drawings and specific language will be used to describe the same. It will nevertheless be understood that no limitation of the scope of the disclosure is thereby intended. Any alterations and further modifications of the inventive features illustrated herein, and any additional applications of the principles of the disclosure as illustrated herein, which would normally occur to one skilled in the relevant art and having possession of this disclosure, are to be considered within the scope of the disclosure.

Before the structures, systems, and related methods related to a system for document information authenticity verification are disclosed and described, it is to be understood that this disclosure is not limited to the particular configurations, process steps, and materials disclosed herein as such may vary somewhat. It is also to be understood that the terminology employed herein is used for the purpose of describing particular embodiments only, and is not intended to be limiting, since the scope of the present disclosure will be limited only by the claims and equivalents thereof.

In describing and claiming the subject matter of the present disclosure, the following terminology will be used in accordance with the definitions set forth below.

It must be noted that, as used in this specification and the appended claims, the singular forms "a," "an," and "the" include plural referents unless the context clearly dictates otherwise.

As used herein, the terms "comprising", "including", "containing", "characterized by" and grammatical equivalents thereof are inclusive or open-ended terms that do not exclude additional unrecited elements or method steps.

In the following description it should be noted that similar or identical reference numerals in different embodiments denote the same or similar features.

System architecture for document information authenticity verification

Turning now to FIG. 1, a system 1 for document information authenticity verification is shown.

As will be apparent from the ensuing description, the system 1 is configured for verifying the authenticity of documents, such as paper and electronic documents, and in particular the information presented by such documents, to reduce or eliminate document counterfeiting, qualification, etc.

In the exemplary architecture provided, the system 1 includes a document authentication server 19. As will be described in further detail below, the document authentication server 19 is configured with various software modules for performing the various computing processing tasks described herein.

In an embodiment, the document authentication server 19 may take the form of a physical (such as rack-mounted) computer server, but in an alternative embodiment, the associated server may take the form of a virtualized server instance, such as a server that may be implemented by Amazon Web Services (AWS).

As will be described in further detail below, in an embodiment, the document validation server 19 maintains a copy of the blockchain ledger, and thus the processes described herein of the document validation server 19 may be shared among multiple servers 19.

More specifically, the document authentication server 19 includes a processor 31 for processing digital data. In operative communication with the processor 31 via the system bus 33 is a memory device 29.

The memory device 29 is configured for storing digital data including computer program code. In this manner, during operation, processor 31 may fetch and execute instructions stored within memory device 29 and store the data results of such execution on memory device 29.

The memory 29 may take the form of a combination of volatile (RAM) and non-volatile (HDD) storage.

For ease of illustration, memory 29 is shown in FIG. 1 as being configured with a plurality of software modules 15 and with associated data within database neurons 20.

As can be seen, the software modules 15 may include a creation module 14 for creating a document validation record, which may then be validated by the validation module 13 in a manner described in further detail below.

Further, for ease of illustration, the data shown within the database has been shown to include document metadata 23, and in embodiments utilizing blockchains, blockchain data 26, the blockchain data 26 including a plurality of document hashes 21, 22 representing the document metadata 23 of various verified documents.

The document authentication server 19 also includes an I/O interface 30 for communicating with various computer peripherals, including user interface peripherals and the like.

The I/O interface 30 may also interface with a data storage peripheral such as a USB memory storage device. In this manner, the computer program code modules 15 may be stored on computer readable media, which may be uploaded to the document authentication server 19 via the I/O interface 30 (or network interface 32) to configure the document authentication server 19 to perform the specific computing processing tasks described herein.

The document authentication server 19 also includes a network interface 32 for sending and receiving data over a computer network, shown as the internet 34 in the illustrated system 1. In this manner, the document authentication server 19 may be in operative communication with the other computing participants shown in FIG. 1.

In this regard, in embodiments, the system 1 may also include a document publisher server 16. In general, the document publisher servers 16 are used by persons, entities, organizations, institutions, etc. that publish sensitive documents that require authenticity verification in the manner described herein.

In this regard, a document publisher may utilize the document publisher server 16 to store document metadata 18, compile and generate documents, store documents and forward documents over the Internet 34, and so forth.

In this regard, the document publisher server 16 may similarly include a software module 10 having a verification module 11 and a creation module 12. In addition, the document publisher server 16 may also store document metadata 18 and associated hashes 24.

As such, in embodiments, the document publisher server 16 may perform all document authenticity verification tasks and data, e.g., an organization performing document verification in an isolated manner with the document publisher server 16.

In an alternative embodiment, the document publisher 16 may utilize the document authentication server 19 (such as based on a subscription API) to perform all or at least some of the document authentication tasks.

The system 1 also includes a client terminal 25 in operative communication with at least one of the document publisher server 16 and the document verification server 19 via the internet 34.

In general, the client terminal 25 may be used to display information indicating the authenticity of a document.

In one embodiment, the client terminal 25 may take the form of a personal computer device, such as a notebook, a mobile communication device (such as a smart phone device, such as apple's iPhone, or the like), which may be used by a user to verify the authenticity of a document.

It can be seen that the client terminal 25 may also include a network interface 32 for communicating over the internet 34.

In embodiments where the client terminal 25 takes the form of a mobile communication device 25, the network interface 32 may send and receive data over a cellular network, such as a 3-5G cellular data network.

The client terminal 25 similarly includes a processor 31 for processing digital data and a memory device 29 in operative communication with the processor 31 via a system bus 33.

The client terminal 25 memory 29 may also include an operating system 66, such as the Apple OS or Android operating system.

In addition, the client terminal 25 may also include an I/O interface 30, and in the illustrated embodiment, the I/O interface 30 may interface with the computer-readable data reader 8. In this regard, and as will be described in further detail below, the reader 8 may read the computer-readable data 27 from the document 2 for verification in order to verify the authenticity of the document.

In embodiments where the client terminal 25 is in the form of a mobile communication device, the reader 8 may be in the form of an image capture device/camera device of the client terminal 25, and the computer readable data 27 may be in the form of a two-dimensional (2D) (such as a Quick Response (QR)) barcode. Thus, to authenticate the document 2, the user will capture an image of the 2D barcode carried by the document 2 to allow the client terminal 25 to verify its authenticity.

In an embodiment, the client terminal 25 (in the form of a mobile communication device) may be configured with a downloaded software application "App" 9, which App 9 may be downloaded, for example, from a software application Store (such as an Apple App Store or the like) for installation and execution by the client terminal 25.

In this regard, the software application 9 may include various sub-modules/software modules, including the verification module 6 and the graphical user interface module 7.

Fig. 1 also shows a system 1 comprising a document 2 verified by the system 1. As described above, document 2 may take the form of hard copy and soft copy documents. For the latter, soft-copy (electronic, such as PDF format) documents may be stored in a document database 65. In this regard, a particular document may be retrieved using a URL and a document ID or other unique identifier such as a document hash.

As shown, document 2 may include document content 5. Further, the document 2 may include computer readable data 27, and as mentioned above, the computer readable data 27 may be in the form of a 2D barcode included or printed on the document 2. In this way, the computer-readable data 27 can be read by the client terminal 25 (or other computing participant via the internet 34) in order to verify its authenticity.

In embodiments, the computer-readable data 27 may include a document ID, a document metadata hash 4, or a document metadata 3, or a combination thereof, depending on the particular application.

It should be noted that the computer architecture provided in FIG. 1 is primarily exemplary for illustrative purposes.

In particular, the particular architecture provided in FIG. 1 is for deploying an application for the document authentication server 19 to use on a subscription basis such that various document publishers, users, etc. can selectively access network functionality disclosed by the document authentication server 19 for authenticating documents.

It should be particularly noted, however, that within the intended scope of the embodiments described herein, the particular architecture may be modified while still performing the same document authenticity verification tasks and functions.

Exemplary method 35 for document authenticity record creation

Having generally described the above computing architecture, various exemplary methods for document authenticity verification using the system 1 will now be provided, including the method 35 for document authenticity record creation shown in FIG. 2.

The method 35 is used to create a document authenticity record and subsequent verification steps that may be used subsequently.

It should be noted that the method 35 is merely exemplary, and accordingly, technical limitations should not necessarily be ascribed to all embodiments.

In step 39 of method 35, document content is obtained.

In the case where the document 2 is a physical document, the document may be scanned with a scanner and the document content acquired with Optical Character Recognition (OCR).

Alternatively, where the document 2 is a soft copy document, the document content may be read from the electronic file system document itself (such as by reading various document metadata or document content, including OCR may also be used to identify the document content), or alternatively, may be retrieved from an appropriate database, such as the database 17 of the document publisher server 16.

In general, document content is important document content (referred to herein as metadata, which is hashed to a metadata hash such as an MD5, SHA256 hash, or other suitable one-way hash), and subsequent changes or modifications to this important document content may be detected by the system 1. In other embodiments, the entire document may be hashed to a document hash so that any changes to the document may be detected.

Furthermore, as will be described in further detail below, the system 1 may include functionality for updating document content/metadata or for revoking authenticity authentication.

In step 40, various metadata may be identified. As described above, metadata represents important information contained within a document.

For example, for an achievement declaration document, the metadata may represent the name of the issuing organization, the name of the achievement, and the name of the certificate of eligibility. For a boarding pass, for example, the metadata may represent the passenger's name, flight number, gate, passport number, destination, etc.

In an embodiment, the system 1 is configured for creating a metadata hash 4 of the metadata such that tampering of important metadata can be detected by the system 1. Furthermore, the metadata may be maintained in a non-hashed format (in plain text or encrypted form) to allow subsequent display by the client terminal 25 during authentication.

The use of metadata (representing some important document information) in step 40 may be useful for hard copy documents, so that the important information presented thereon is isolated for verification. In this way, the document can be modified in other ways, such as including photocopying and scanning aberrations, printing on different heads, etc., without affecting the ability to verify its authenticity.

However, as noted above, it should be noted that in embodiments, particularly for electronic documents, the metadata need not necessarily be isolated from the document in lieu of having the entire contents of the electronic data file hashed. In particular, in this embodiment, the electronic document file may be a hash, such as an MD5, SHA256 hash, or the like, as opposed to a metadata hash. In embodiments, separate metadata hashes and document hashes may be utilized such that modifications of a document or sensitive metadata therein may be detected independently.

In an embodiment, the metadata used may be user-specified. For example, some of the metadata used from the document publisher database 17 is user-specified.

In an alternative embodiment, where the metadata is extracted from the document itself, a search string filter may be specified to allow the system 1 to extract (including using OCR) the appropriate metadata.

For example, for an achievement statement document, only the names of the organization, the accomplishment, and the certificate of eligibility may be specified to be saved as metadata for verification, enabling modification of other document content without affecting the ability to verify the authenticity of the document's metadata.

In this way, various search strings may be utilized to allow the system 1 to extract these metadata fields.

In further embodiments, a document region/rectangle (representing the location of document metadata within the document) may be specified to allow the system to extract text only from the specified region.

In step 41, a document ID may be obtained or generated. In a preferred embodiment, the document ID is Globally Unique (GUID) in order to prevent or substantially eliminate document ID conflicts.

The document ID may be used to uniquely identify the document for verification. For example, the document ID may be used to retrieve the document from the document database 65 using a URL that includes the document ID. Further, the document ID may be used to update the document for revocation.

In an embodiment, the document ID may be generated by the system 1. However, in an alternative embodiment, the document ID may be provided by the document publisher, where, for example, a registered training organization publishes the achievement statement document in numerical order.

In embodiments, the document ID may also be hashed as a metadata hash or as part of a document hash to prevent tampering with the document ID.

It should be noted, however, that in some embodiments, a document ID is not necessarily required. For example, a hardcopy document may include a 2D barcode thereon representing a hash of metadata, where the metadata represents information displayed by the document. In this way, the 2D barcode may be scanned to verify document content without necessarily having to use a document ID.

In further embodiments, a hash generated from the document file or metadata may be used as the unique document ID.

In step 42, hash 4 is created. Preferably, the hash is a one-way hash, such as MD5, SHA256, or the like. Hashing provides the ability to potentially reduce large amounts of information to a small amount, but importantly, even single letter tampering of content can greatly affect hashing.

In a preferred embodiment, hash 4 is a metadata hash, such that metadata (important document information) is hashed to enable subsequent changes to the important document information to be detected. However, as described above, in other embodiments, the hash 4 may be a document hash of the electronic document file.

Other information may also be hashed within hash 4, including the document ID.

In an embodiment, a combination of the above information may be hashed to form hash 4.

In a preferred embodiment, the system 1 uses a blockchain for the purpose of storing hashes 4, so as to be able to provide an unalterable distributed, trusted ledger of verification documents.

In particular, as shown in FIG. 1, document validation server 19 may store a copy of blockchain ledger 26 within database 20, which may be synchronized with other document validation servers 19.

Thus, in step 43, the hash is added to the blockchain transaction, which is then mined and added to the blocks in the blockchain. There are different ways in which hashes can be added to the blockchain, including the use of bitcoin blockchains within bitcoin script opcodes. In alternative embodiments, a custom blockchain including appropriate data fields may be utilized.

Thus, when a document is verified, the blockchain may be examined to determine whether the hash 4 (which may be scanned from the 2D barcode 27 or alternatively calculated on the fly) resides within the blockchain.

In an embodiment, the entire blockchain may be searched for hashes, but in a preferred embodiment, a separate hash index may be used to speed up the hash lookup process.

It should be noted that not all embodiments necessarily use blockchains. For example, the document publisher server 16 may maintain a database of document metadata 18 (or document content) and associated document hashes 24 or document IDs for the purpose of allowing documents to be validated in isolation without the use of a shared ledger. In other words, the system 1 also maintains a copy of the metadata 18 (to allow, for example, the metadata to be displayed for visual comparison by a user during the verification process) and an associated hash to enable detection of tampering of the metadata (although there is no security measure against tampering of the database 17, this may be avoided with a blockchain).

In step 44, computer readable data may be generated and then used in conjunction with the document for verification.

In step 45, the computer readable data is inserted into the document, either visibly or invisibly.

In one embodiment mentioned above, the computer readable data 27 may take the form of a 2D barcode including one or more of a document hash, a document ID and document metadata.

In a preferred embodiment, the computer readable data 27 is visible to allow printing, scanning and photocopying of the document.

For example, the document may be modified to visually display the computer readable data 27, wherein, for example, the PDF document is modified to include an image of the 2D barcode on the lower right side of the document. In this manner, when subsequently authenticating an electronic document or printout thereof, a user may utilize the camera device of smartphone 25 to capture an image of the 2D barcode to authenticate the content or metadata of the document.

In an alternative embodiment, for electronic documents that exist only in electronic form, the computer-readable data 27 need not be visible to the human eye, and may be incorporated, for example, in the metadata of the document. In this way, when a document is displayed, the document display software may check the associated metadata in the background and display and indicate whether the document is verified.

For example, the PDF document may be updated such that the PDF document metadata includes computer readable data 27 (which may include one or more of document metadata, document ID, and document hash, as described above). In this way, when displayed within a PDF application such as an Adobe Acrobat reader, the PDF software may automatically check the computer readable data 27 and display an indication as to whether the document is verified.

In alternative embodiments, such as when used with travel documents and the like, RFID tags may be used.

In step 46, where the document is in the form of an electronic document, the document may also be digitally signed to prevent tampering or modification of the computer readable data included or inserted thereon.

In one embodiment, the document verification server 19 may sign the document using a private key so that others can then verify that the document verification server 19 has indeed signed the document with the associated public key.

Exemplary method 36 for document authenticity verification

Turning now to FIG. 3, an exemplary method 36 for document authenticity verification is shown. As will be apparent from the ensuing description, the method 36 is for the purpose of verifying the authenticity of a document using the computer-readable data 27 associated therewith.

The method 36 begins at step 47 where a document is obtained. For example, the physical document may be obtained manually, or the electronic document may be retrieved from a file system, downloaded from a URL, and so forth.

In step 48, computer readable data associated with the document is scanned or read.

For a physical document comprising computer readable data 27 in the form of a 2D barcode, the barcode may be read by the reader 8 of the client terminal 25.

For electronic documents, the computer readable data 27 may be retrieved by document display software (such as Adobe Acrobat).

In step 49, a hash may be extracted from the computer readable data 27.

Where the computer readable data includes a document ID, the document ID may also be retrieved from the computer readable data so as to be comparable to the document ID used to retrieve or associated with the document.

In step 50, where system 1 utilizes a blockchain, the blockchain may be examined for blocks containing transactions that include hashes, and in some embodiments, for associated document IDs.

If a matching transaction is found in the blockchain, then in step 51, a verification may be displayed to the user indicating that the document is authentic.

In addition, in step 52, metadata may be extracted from the computer-readable data, which may then be displayed by the client terminal 25 to allow the user to compare the metadata extracted from the computer-readable data with the metadata displayed on the document.

In certain other embodiments, the metadata 23 may be stored within the blockchain 26 itself, such that the metadata 23 may be retrieved from the blockchain 26 during validation to negate the need to store the metadata 23 within the 2D barcode 27 itself.

Exemplary method 37 for updating document metadata

Turning to FIG. 4, an exemplary method 37 for updating document metadata is shown.

In particular, in embodiments, document metadata may need to be updated.

For example, for boarding passes, a gate change may occur. As another example, for an achievement statement, the name of the accomplishment may be changed from the pre-married name.

Thus, the method 37 may be used to allow certain document fields to be updated while still maintaining the ability to verify the authenticity of the document.

Thus, in step 53, a document ID (or other unique identifier, such as a document or metadata hash) of the document to be updated may be generated or obtained.

In step 54, updated metadata (or document content) is received. For example, the updated metadata may include a new last name.

In step 55, the updated metadata (or updated document content) is hashed.

At this point, a new hash is added to the blockchain by another transaction in step 56.

In steps 57-59, the document may be modified to incorporate the new computer-readable data 27. However, the update of the 2D barcode 27 does not necessarily occur, especially for documents that have already been disseminated.

Thus, when a document is subsequently validated, blockchain transactions may be checked in reverse order of time, with the most recent validation transaction in time being used as the current validation transaction.

Alternatively, if a hash is extracted from the document associated with a blockchain transaction for which there is a more recent blockchain transaction, the client terminal 25 may notify the user that the document metadata/content is expired and that the document has been replaced.

In an embodiment, the verification result may indicate that the document has been replaced. However, in other embodiments, the verification result may indicate which document content metadata has been replaced.

For example, when creating a first blockchain validation transaction, the document ID and the original metadata hash may be stored within the blockchain.

Then, when an update to the document metadata is received, a new blockchain transaction may be created within the blockchain that includes the document ID and a new metadata hash (representing the updated metadata).

Thus, during subsequent verification of the document, the computer readable data 27 may be read by the client terminal 25 to extract the document ID and the metadata hash.

The blockchain may then be searched for blockchain transactions associated with the document ID.

However, if the system 1 identifies two or more transactions, the system 1 can compare the retrieved hash to the two or more transactions to identify whether the particular transaction is the current transaction or has been preempted.

Exemplary method 38 for document authenticity revocation

Turning now to FIG. 5, an exemplary method 38 for document authenticity revocation is shown.

In particular, the need to revoke a document may arise. For example, a person who has received an achievement claim may have subsequently been found to be a certificate of eligibility obtained by fraud and therefore the achievement claim needs to be revoked.

In the case of using blockchain techniques, transactions cannot be deleted from the blockchain.

Thus, method 38 utilizes an undo transaction that is added to the blockchain to undo the document.

In particular, the method 38 begins at step 60, where a revocation request is received for a particular document identified by a document ID (or other unique identifier, such as a document or metadata hash) at step 60.

In step 61, undo transactions are added to the blockchain. An undo transaction is identified by a transaction type (an undo transaction type, which may also be stored in a bitcoin script opcode) and a document ID.

Thus, during subsequent authentication, computer readable data for the document is received and the document ID and/or document hash is extracted therefrom in step 62.

In step 63, the blockchain is searched for a matching document ID or hash.

However, for any authentication transaction identified within the blockchain, in step 63, system 1 will identify a subsequent undo transaction within the blockchain associated with the document ID or hash, and thus in step 64, the authentication fails.

Limited authenticity verification period

In an embodiment, the document may have limited authenticity. Where, for example, the document is valid for only 12 months, as may be the case with, for example, a driver's license.

Thus, the validation transaction stored within the blockchain may specify a validity period (which may also be stored in the bitcoin script opcode). Thus, during validation, the system 1 may check the entry date of the validation transaction and if the current date exceeds the validity period, the validation fails.

For example, if system 1 identifies an authentication transaction within the blockchain more than 12 months ago, but the authentication transaction specifies an authentication validity period of 12 months, and system 1 is unable to identify any additional later in time authentication transactions associated with the document, then authentication fails.

In this regard, the validity period may be updated by adding a blockchain validation transaction that is later in time. Exemplary use of System 1 architecture for validating an assertion of achievement document issued by a Registered Training Organization (RTO)

Having described the architecture of the system 1 and related methods described above, an exemplary use of the system 1 for validating an application of an achievement statement document issued by a Registered Training Organization (RTO) will now be described.

It can be seen that the document publisher (RTO) server 16 includes a plurality of software modules 10.

In the embodiments described herein, the software modules 10 may include a verification record creation module 12 for the purpose of creating a document record for subsequent verification.

It will also be seen that the document information authentication server 19 may itself comprise a plurality of software modules 15, the software modules 15 themselves comprising the authentication record creation module 14.

In addition, the software modules 10 of the document publisher (RTO) server 16 may also include a verification module 11 for subsequent document verification.

Similarly, the software modules 15 of the document information validation server 19 similarly include a validation module 13 for the purpose of validating documents, as will be described in further detail below.

As described above, if the functions of the document publisher (RTO) server 16 and the document information verification server 19 are implemented by a single server, such verification and creation functions may be implemented by the same module.

In this exemplary embodiment, a person named James Smith successfully completes a particular RTO course.

After the course is completed, the details of the achievement or course declaration are recorded by the RTO.

In particular, it can be seen that the document publisher (RTO) server 16 includes a database 17.

In addition, database 17 may include metadata 18 or other types of structured data configured to store various information fields related to courses completed by James Smith.

Thus, the following information may be recorded in the database 17:

a. name: james Smith

b. Release date: 7/2007

c. Document number: 0007/07/2007

d. And releasing RTO: allwest training service

e. National supplier code number: 51925

f. Certificate type: achievements/curriculum statements

g. Signing officers: bob Cooper

h. Signing officer positions: chief executive officer

Now, during the verification record creation phase, a hash of the above metadata is created. In one embodiment, the metadata is concatenated into a string, such as including:

james Smith |19051983| M | 007007007 |0007/07/2007| Allwest training service |51925|07072007| achievement statement | carry out haul truck operation | Bob Cooper | chief executive officer

Next, the concatenated string is hashed using a one-way hashing algorithm, such as MD5, SHA256, or other hashing algorithm. For example, such a hash may generate the following hash:

a.25908e49524e4828190dae3d79b894eec7ec3e4843c8bca6ef9f384c679167bc

next, the metadata hash is stored so as to be available for subsequent document information verification.

Specifically, it can be seen that the document information verification server 19 includes a database 20 for storing various information including hash data.

Thus, the above-described metadata hash is inserted into the database 20. Such insertion may include the document information validation server 19 receiving metadata (or a metadata hash) from the database 17 of the document publisher (RTO) server 16, such as at periodic intervals, upon request, and so forth.

It should be noted that the hashing algorithm described herein may be performed by any computing participant within the intended scope of the embodiments described herein. In other words, for example, the document publisher (RTO) server 16 or the document information verification server 19 may perform hashing.

In a preferred embodiment, to prevent fraud due to insertion of fraudulent hash entries into the database 20, the system 1 may implement a distributed public-ledger blockchain 26 such that each hash entry may be verified against other hash entries within the database 20.

In the embodiment described herein, the verification is performed by a single document information verification server 19. However, it should be understood that blockchain 26 may be a distributed blockchain distributed across multiple servers 19.

It should be noted that any distributed cipher-based blockchain may be used within the intended scope of the embodiments described herein, and includes those used in or similar to Bitcoin, ehterum, littoin blockchains, and the like.

In these embodiments, each RTO 16 ("document information publisher") and document verification server 19 may be assigned a "publisher address," which may be a bitcoin wallet address. The transactions within the capacitor, bitcoin blockchain may be uniquely associated with the respective document publisher server 16 or document validation server 19.

In an embodiment, the metadata may also be stored within the database 20 of the document information verification server 19. In this way, metadata can be looked up by hashing (or document ID).

In this embodiment, a hash may be used as the master key. However, it should be understood that the database 20 does not necessarily include the metadata 23, so as to include hashes for the purpose of document information verification only.

Now, computer-readable data comprising at least one of a hash and metadata is generated. The creation of computer readable data will allow computer readable data to be inserted onto a document, such as an achievement certificate, which is a paper or electronic (i.e., PDF) document that can then be read using the client terminal 25 for the purpose of verifying the authenticity of the document and the document metadata stored therein.

In a preferred embodiment, the computer readable data is embodied in a 2D barcode. For example, when generating 2D barcode computer readable data, the data may be encoded using the following format:

[ Key _ hash ] | [ name ] | [ birth date DD/MM/YYYY ] | [ sex ] | [ DL number ] | [ document number ] | [ issue RTO ] | [ national supplier code number ] | [ issue date DD/MM/YYYYYY ] | [ certificate type ] | [ license type ] | [ sign official position ]

This can be generated into the following 2D barcode using a suitable algorithm:

after the computer-readable data is created, the computer-readable data is then inserted or printed onto the document.

As can be seen in FIG. 1, document 2 is shown, document 2 being an achievement certificate for a course completed by James Smith. In this particular embodiment, document 2 is published as a PDF document by a document publisher (RTO) server 16. Thus, James Smith may utilize the electronic PDF document 2 as its warranty for various employment purposes.

It can be seen that the document may include document content 5, and that the document content 5 may include common human-readable information including at least a subset of the above metadata. However, as noted above, in prior art arrangements, documents may be edited electronically or physically to represent fraudulent information.

Thus, by additionally including computer readable data 27, the document can be authenticated using the client terminal 25. It can be seen that the computer-readable data 27 carried by the document 2 may include at least one of metadata 3, metadata or a document hash 4, and a document ID.

In an embodiment, only the metadata 3 is encoded within the computer readable data 27 so that a hash can be computed from the metadata for verification. In other embodiments, only the hash 4 is encoded within the computer readable data 27 so that the metadata can be retrieved from the database 20 of the document information validation server 19 or the database 17 or blockchain of the document publisher (RTO) server 16.

It can be seen that the client terminal 25 includes a software application 9 configured for implementing the features and functions described herein. As described above, in the embodiment, the client terminal 25 is a mobile communication device such as a smartphone device or the like. Herein, the client terminal 25 may include a reader 8; in some embodiments, reader 8 may take the form of a cell phone camera.

In use, operation of the client terminal 25 may download the software application 9 for execution by the client terminal 25, for example from a software application store such as the Apple iTunes store.

It can be seen that the software application 9 may include a verification module 6 configured for implementing client terminal-implemented functionality for document information verification, and also include a Graphical User Interface (GUI) module that presents a graphical user interface for display to the GUI 7 for the purpose of displaying various information to the client terminal user.

Thus, to verify the authenticity of a document, a client end user will scan the 2D barcode computer readable data 27 provided on the document using the reader 8. After receiving the computer-readable data from the document 2, at least one of the client terminal 25 and the document information verification server 19 is configured for identifying at least one of the metadata 3 and the hash 4.

In a preferred embodiment, the metadata 3 is encoded within the computer readable data 27 so that the GUI 7 of the client terminal 25 can display the metadata.

In a further preferred embodiment, both the hash 4 and the metadata 3 are encoded within the computer readable data 27, so that the client terminal 25 can generate a hash using the encoded metadata 3 using a hashing algorithm to verify at least that the encoded hash 4 matches the metadata 3. In an embodiment, a suitable hashing algorithm may be used in order to prevent a fraudster from fraudulently generating and encoding a hash using a known hashing algorithm.

Further, the client terminal 25 can send at least one of the metadata 3 and the hash 4 to the document information authentication server 19 for authentication through a data network such as the internet in operative communication with the document information authentication server 19.

The document information authentication server 19 is configured to compare the hash received from the client terminal 25 (or the hash calculated from the metadata 3 read by the client terminal 25) with the hash value stored in the blockchain 26.

If a match is found, the document information authentication server 19 can return an authentication result to the client terminal 25 to authenticate that the document information is authentic.

Alternatively, if no match is found, the authentication server 19 is configured to return a non-authentication result to the client terminal 25 to indicate that the document information may be fraudulent or has been tampered with.

In either case, the GUI 7 is configured for displaying the verification results to the client terminal user. In addition, the GUI 7 may display associated metadata.

For example, turning now to FIG. 6, an exemplary interface 28 displayed by the GUI 7 is shown in which a document has been verified. As can be seen, the interface 28 includes various metadata and includes confirmation that the document information is authentic.

In an embodiment, the system 1 is configured for implementing a further verification in which the records held within the RTO server database 17 (in case the records have been updated or revoked) are further cross-referenced. In particular, the cross-referencing may be performed using at least one of hashing and metadata. It can be seen that in an embodiment, the database 17 of the document publisher (RTO) server 16 may be configured to store the hash value 24 in relation to the metadata 19. As described above, such hash values 24 may be received from the document information verification server 19, or alternatively calculated by the document publisher (RTO) server 16 itself. Additionally, as noted above, in embodiments, the database 17 need not include hash values 24, in which case the metadata 18 is cross-referenced.

When the metadata 18 is cross-referenced, at least one of the client terminal 25 and the document information validation server 19 may send an additional query to the validation module 11 of the document publisher (RTO) server 16 to validate the data stored in the database 17. For example, the client terminal 25 may send the document number to the RTO server 16 to verify that the document number is genuine. Other cross-references may be made within the scope of the objects of the embodiments described herein.

Exemplary use of System 1 for hardcopy documents

An exemplary use of the system 1 for hard-copy documents will now be described.

In particular, as described above, problems with hardcopy documents may include changes in the appearance of the document over time, such as caused by photocopying aberrations and the like.

Thus, in this exemplary use, the system 1 will be described as being capable of validating a hardcopy document despite variations in appearance.

In particular, in this example, the hard copy document is a sales contract document that has been signed by a seller, buyer, and witness. The hardcopy document further specifies the real estate being sold as identified by the lot number.

Thus, for the purpose of creating a document validation record, the executed contract document may be scanned using a scanner, and wherein the system 1 then performs OCR recognition of the document to identify relevant metadata from the sales contract. In this example, the relevant metadata is the names and lot numbers of the seller and buyer.

Thus, the system 1 is configured to extract such metadata from the document. For example, using OCR, the system 1 may be configured to extract these fields from the data using string matching or the like.

Alternatively, an image scan of the document may be displayed on the client terminal 25 so that the attorney can specify the metadata to be verified, such as by using a mouse to drag a rectangle around the associated text.

Additionally, the document ID may be specified by the attorney, where the document ID is a document ID generated by the document system.

After obtaining the relevant metadata, system 1 hashes the metadata (and document ID in embodiments) and creates a validation transaction within the blockchain.

Further, the system 1 generates computer-readable data in the form of a 2D barcode, which is then printed onto the sales contract document.

The 2D barcode includes a metadata hash 4, a document ID, and metadata.

The contract is then photocopied for sale, and the photocopy is then sent to the sender.

However, slight visual deviations can occur during the photocopying process.

However, to verify the sales contract, the transmitter captures an image of the document using the camera of the transmitter's mobile communication device 25.

The mobile communication device 25 includes an application 9, the application 9 identifying the 2D barcode and extracting the metadata hash, the document ID and the metadata from the 2D barcode.

The mobile communication device 25 then sends a verification request to the document verification server 19 via the internet 34. The authentication request includes a hash, but in some embodiments may additionally include a document ID.

Document authentication server 19 then searches the blockchain for authentication transactions and identifies the earlier created authentication transactions.

The document authentication server 19 then sends an authentication response to the mobile communication device 25 enabling the mobile communication device 25 to display an indication that an authentication record exists.

Now, in one embodiment, the mobile communication device 25 of the transmitter may display the metadata extracted from the 2D barcode. In this way, the sender can visually check the names and batch numbers of the parties on the document displayed by the mobile communication device 25 to ensure their consistency.

It should be noted that the client terminal 25 may re-hash the metadata stored within the 2D barcode in order to confirm that the generated hash matches the hash of the 2D barcode (to prevent tampering with the metadata within the barcode).

Alternatively, the metadata may also already be stored within the blockchain during the initial authentication transaction, so that the metadata may be sent from the document authentication server 19 to the client terminal 25 for display.

In an alternative embodiment, rather than displaying the metadata field for visual comparison by the transmitter, the mobile communication device may perform optical character recognition to read text from the document (despite the presence of photocopy aberrations) and confirm whether the recognized text matches the metadata.

For example, for metadata stored within a 2D barcode or blockchain, the client terminal 25 may search OCR text to identify such metadata. If such a situation is not identified, such as the scanned document does not contain the same batch number, the verification fails.

In an embodiment, the relevant metadata is delimited within boundaries, where, for example, in the above-described embodiment, the attorney draws a rectangle over the metadata to be verified displayed on the screen. For example, the batch number may be centered at the top middle of the page, while the names of the parties may be located in the lower left and right corners of the document, respectively.

Thus, during verification, the mobile communication device 25 is configured to recognize text only within the delineated boundaries and then compare the text extracted from these delineated boundaries with the metadata. When using a camera, the mobile communication device 25 can identify the corners of the page for orientation to enable accurate placement of the demarcated boundaries.

Exemplary use of System 1 architecture for validating boarding passes

An exemplary use of the system for verifying boarding passes will now be described.

In particular, the existing boarding pass system has a problem in that data printed thereon may be tampered with. Additionally, the database entry may be modified to match a tampered print, such that during check-in, the boarding personnel may not notice that the boarding pass has been tampered with to match the modified database entry.

Thus, in this embodiment, when the boarding pass is initially printed, the passenger record computing system sends the relevant metadata to document verification server 19.

In this embodiment, the relevant metadata may include boarding pass ID, passenger name, and gate.

Document authentication server 19 may hash the metadata and create an entry within the blockchain and send the 2D barcode to the passenger record computing system, which 2D barcode is then printed onto the boarding pass.

Now, the rescheduling of flights may result in an update of the gate number before departure. Thus, the passenger record computing system identifies all affected passengers and sends an update notification to the document verification server 19 for the identified affected passengers.

For example, for each boarding pass, the passenger record computing system may send a boarding pass ID and an updated gate number.

For each update, the document authentication server 19 creates a new entry within the blockchain.

Now, during check-in, the 2D barcode of the boarding pass is scanned, and the boarding pass ID and metadata (passenger name and gate number) are extracted from the barcode. At the bottom, such information may also be retrieved from the boarding pass print via OCR.

This extracted metadata may then be sent to the document authentication server 19 for authentication.

In an embodiment, the portal computer may maintain a copy of the blockchain, thereby avoiding time-consuming queries over the Internet to the document authentication server 19.

Now, assuming an attempt to replace the passenger with another name, the boarding pass may have been tampered with to change the name printed on the boarding pass and the associated entry within the passenger record computing system database. In addition, metadata stored within the 2D barcode may be modified.

However, for such name modifications, the authentication of the document authentication server 19 will fail because the document authentication server 19 will not be able to match the hash of the new name with the hashes stored within the blockchain.

Now, for an updated gate number, the boarding pass may still represent the old gate number.

In this way, the hash encoded within the 2D barcode will be outdated (since it still represents the old gate number).

However, at the time of registration, a new gate number may be sent by the passenger check computer to document verification server 19, where document verification server 19 is able to use the new gate number to identify additional verification transactions related to the boarding pass ID, and thus pass the verification of the boarding pass. In this regard, it should be noted that for any other gate number, if it does not match a gate update transaction within the blockchain, then the validation will fail.

Explaining the meaning

Wireless:

the invention may be implemented using devices that conform to other network standards and devices for other applications, including, for example, other WLAN standards and other wireless standards. Applications that may be accommodated include IEEE 802.11 wireless LANs and links and wireless ethernet.

In the context of this document, the term "wireless" and its derivatives may be used to describe circuits, devices, systems, methods, techniques, communications channels, etc., that may communicate data through the use of modulated electromagnetic radiation through a non-solid medium. The term does not imply that the associated devices do not contain any wires, although in some embodiments they may not. In the context of this document, the term "wired" and its derivatives may be used to describe circuits, devices, systems, methods, techniques, communications channels, etc., that may communicate data through the use of modulated electromagnetic radiation through a solid body. The term does not imply that the associated devices are coupled by conductive lines.

The process is as follows:

unless specifically stated otherwise, as apparent from the following discussions, it is appreciated that throughout the specification discussions utilizing terms such as "processing," "computing," "calculating," "determining," "analyzing," or the like, refer to the action and/or processes of a computer or computing system, or similar electronic computing device, that manipulate and/or transform data represented as physical, such as electronic, quantities into other data similarly represented as physical quantities.

A processor:

in a similar manner, the term "processor" may refer to any device or portion of a device that processes electronic data, e.g., from registers and/or memory, to transform that electronic data into other electronic data that may be stored, e.g., in registers and/or memory. A "computer" or "computing device" or "computing machine" or "computing platform" may include one or more processors.

In one embodiment, the methods described herein may be performed by one or more processors accepting computer-readable (also referred to as machine-readable) code comprising a set of instructions which, when executed by the one or more processors, perform at least one of the methods described herein. Including any processor capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken. Thus, one example is a typical processing system that includes one or more processors. The processing system may also include a memory subsystem including main RAM and/or static RAM and/or ROM.

A computer readable medium:

furthermore, the computer readable carrier medium may form or be comprised in a computer program product. A computer program product may be stored on a computer usable carrier medium, the computer program product comprising computer readable program means for causing a processor to perform a method as described herein.

A network or a plurality of processors:

in alternative embodiments, one or more processors operate as standalone devices or may be connected in a networked deployment (e.g., networked to other processors), which may operate in the capacity of a server or a client terminal machine in server client terminal network environment, or as a peer machine in a peer-to-peer or distributed network environment. The one or more processors may form a network device, a network router, switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine.

Note that while some of the figures show only a single processor and a single memory carrying computer readable code, those skilled in the art will appreciate that many of the above-described components are also included, but are not explicitly shown or described in order to avoid obscuring aspects of the present invention. For example, while only a single machine is illustrated, the term "machine" shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.

Additional examples:

accordingly, one embodiment of each of the methods described herein is in the form of a computer-readable carrier medium carrying a set of instructions, e.g., a computer program for execution on one or more processors. Thus, as will be appreciated by one skilled in the art, embodiments of the invention may be embodied as a method, an apparatus such as a special purpose apparatus, an apparatus such as a data processing system, or a computer readable carrier medium. A computer-readable carrier medium carries computer-readable code comprising a set of instructions that, when executed on one or more processors, cause the one or more processors to implement a method. Accordingly, aspects of the present invention may take the form of a method, an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a carrier medium (e.g., a computer program product on a computer-readable storage medium) carrying computer-readable program code embodied in the medium.

Carrier medium:

the software may also be transmitted or received over a network via a network interface device. While the carrier medium is shown in an exemplary embodiment to be a single medium, the term "carrier medium" should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. The term "carrier medium" shall also be taken to include any medium that is capable of storing, encoding or carrying a set of instructions for execution by one or more processors and that cause the one or more processors to perform any one or more of the methodologies of the present invention. The carrier medium may take many forms, including but not limited to, non-volatile media, and transmission media.

The realization is as follows:

it should be understood that the steps of the discussed methods are performed in one embodiment by an appropriate processor(s) of a processing (i.e., computer) system executing instructions (computer readable code) stored in a storage device. It should also be appreciated that the invention is not limited to any particular implementation or programming technique and that the invention can be implemented using any suitable technique for implementing the functionality described herein. The present invention is not limited to any particular programming language or operating system.

Apparatus for performing a method or function

Furthermore, some embodiments are described herein as a method or combination of method elements that can be implemented by a processor of a processor device, a computer system, or by other means of performing that function. A processor having the necessary instructions for carrying out such a method or method element thus forms a means for carrying out the method or method element. Furthermore, the elements of an apparatus embodiment described herein are examples of means for performing the function performed by the element to carry out the invention.

Connection of

Similarly, it is to be noticed that the term 'coupled', when used in the claims, should not be interpreted as being restricted to direct connections only. Thus, the scope of the expression device a connected to device B should not be limited to devices or systems in which the output of device a is directly connected to the input of device B. It means that there exists a path between the output of a and the input of B, which may be a path including other devices or means. "connected" may mean that two or more elements are in direct physical or electrical contact, or that two or more elements are not in direct contact with each other but yet still co-operate or interact with each other.

Example (b):

reference in the specification to "one embodiment" or "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the invention. Thus, the appearances of the phrases "in one embodiment" or "in an embodiment" in various places throughout this specification are not necessarily all referring to the same embodiment, but may. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments, as will be apparent to one of ordinary skill in the art in view of the present disclosure.

Similarly, it should be appreciated that in the foregoing description of example embodiments of the invention, various features of the invention are sometimes grouped together in a single embodiment, figure, or description thereof for the purpose of streamlining the disclosure and aiding in the understanding of one or more of the various inventive aspects. This method of disclosure, however, is not to be interpreted as reflecting an intention that the claimed invention requires more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive aspects lie in less than all features of a single foregoing disclosed embodiment. Thus, the claims following the detailed description are hereby expressly incorporated into this detailed description, with each claim standing on its own as a separate embodiment of this invention.

Furthermore, although some embodiments described herein include some but not other features included in other embodiments, combinations of features of different embodiments are intended to fall within the scope of the invention and form different embodiments, as will be understood by those skilled in the art. For example, in the following claims, any of the claimed embodiments may be used in any combination.

Different object instances

As used herein, unless otherwise specified the use of the ordinal adjectives "first", "second", "third", etc., to describe a common object, merely indicate that different instances of like objects are being referred to, and are not intended to imply that the objects so described must be in a given sequence, either temporally, spatially, in ranking, or in any other manner.

Details of

In the description provided herein, numerous specific details are set forth. However, it is understood that embodiments of the invention may be practiced without these specific details. In other instances, well-known methods, structures and techniques have not been shown in detail in order not to obscure an understanding of this description.

Term(s) for

In describing the preferred embodiments of the present invention illustrated in the drawings, specific terminology will be resorted to for the sake of clarity. However, the present invention is not limited to the specific terms so selected, and it is to be understood that each specific term includes all technical equivalents which operate in a similar manner to accomplish a similar technical purpose. Terms such as "forward", "rearward", "radial", "peripheral", "upward", "downward", and the like are used as words of convenience to provide reference points and should not be construed as limiting terms.

Comprises (comprising) and comprises (including)

In the claims which follow and in the preceding description of the invention, unless the context requires otherwise due to express language or necessary implication, the word "comprise" or variations such as "comprises" or "comprising" is used in an inclusive sense, i.e. to specify the presence of the stated features but not to preclude the presence or addition of further features in various embodiments of the invention.

Any of these terms "comprising" or "it contains" is also an open term that also means including at least the elements/features that follow the term, but not excluding other elements/features. Thus, "comprising" is synonymous with and means "including".

Scope of the invention

Thus, while there has been described what are believed to be the preferred embodiments of the invention, those skilled in the art will recognize that other and further modifications may be made thereto without departing from the spirit of the invention, and it is intended to claim all such changes and modifications as fall within the scope of the invention. For example, any of the formulas given above are merely representative of processes that may be used. Functions may be added or deleted from the block diagrams and operations may be exchanged between functional blocks. Steps may be added or deleted from the described methods within the scope of the invention.

Although the invention has been described with reference to specific examples, it will be appreciated by those skilled in the art that the invention may be embodied in many other forms.

Claims (14)

1. A method for document information authenticity verification, the method comprising:

a verification record creation phase, the verification record creation phase comprising:

receiving document content metadata from a document;

generating a metadata hash using the document content metadata;

creating a blockchain transaction using the metadata hash;

generating computer readable data encoding the metadata hash;

updating the document using the computer-readable data; and

signing the document using a private key associated with a document authentication server;

the document content updating stage comprises the following steps:

receiving updated document content metadata for the document;

generating a further metadata hash using the updated document content metadata; and

creating a further blockchain transaction using the further metadata hash;

a document verification stage, the document verification stage comprising:

receiving the document;

the client side verifies the document through a public key of a document verification server;

extracting the metadata hash from the computer-readable data;

identifying the metadata hash within a blockchain transaction of the blockchain to verify authenticity of the document content metadata; and

checking the blockchain in reverse chronological order to identify further blockchain transactions to identify document content metadata replacements where the document content metadata was updated; and

the document authentication revocation phase comprises the following steps:

creating a cancel blockchain transaction; and

during the document verification phase, identifying the revoke blockchain transaction that temporally follows the blockchain transaction to discard authenticity verifications of document information.

2. The method of claim 1, wherein the computer readable data is a barcode.

3. The method of claim 2, wherein the barcode is a two-dimensional barcode.

4. The method of claim 1, further comprising storing the document content metadata, wherein the document verification stage further comprises retrieving the document content metadata and displaying the document content metadata.

5. The method of claim 4, wherein storing the document content metadata comprises encoding the metadata within the computer-readable data.

6. The method of claim 4, wherein storing the document content metadata comprises encoding the metadata within the blockchain transaction.

7. The method of claim 1, wherein the validation record creation phase further comprises identifying the document content metadata from the document.

8. The method of claim 7, wherein the identification of document content metadata comprises optical character recognition.

9. The method of claim 8, wherein the identification of the document content metadata comprises performing a search string query against text extracted using the optical character recognition.

10. The method of claim 8, wherein the identification of the document content metadata comprises isolating text within at least one user-defined region of the document.

11. The method of claim 1, further comprising identifying which portion of document content metadata is replaced.

12. The method of claim 1, wherein the blockchain transaction further specifies a validity period, wherein during the document validation phase, the method further comprises: if the validity period expires, the verification of the document is discarded.

13. The method of claim 12, further comprising creating a validity update blockchain transaction that includes an additional validity period, wherein the additional validity period is used in determining the validity of the document during the document validation phase.

14. The method of claim 1, wherein creating a blockchain transaction using metadata hashes comprises storing document IDs and metadata hashes of documents within a blockchain, and creating further blockchain transactions further comprises storing document IDs and further metadata hashes within the blockchain, and wherein checking the blockchain in reverse chronological order comprises searching the blockchain using the document IDs.