Classifications

• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F21/60—Protecting data
  • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F21/60—Protecting data
  • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
  • G06F21/645—Protecting data integrity, e.g. using checksums, certificates or signatures using a third party
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
  • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
  • H04L9/0891—Revocation or update of secret information, e.g. encryption key update or rekeying
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
  • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
  • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
  • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
  • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
  • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
  • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
  • H04L2209/60—Digital content management, e.g. content distribution

Definitions

• the present invention relates to document information authenticity verification and in particular, but not necessarily entirely, to a system and method for document information authenticity verification for applications including verifying the authenticity of information of statements of attainment of course documentation issued by registered training organisations, verification of travel documents and other sensitive documents requiring authenticity verification such as documents issued by law firms, accountancy firms, governmental institutions and the like.
• the authenticity verification techniques described herein may be widely applied for differing document mediums including in hardcopy (i.e. paper, smart card travel document) and softcopy (i.e. electronic formats including in PDF format including being stored within document repositories) format.
• hardcopy i.e. paper, smart card travel document
• softcopy i.e. electronic formats including in PDF format including being stored within document repositories
• Document authenticity verification is desirous for applications including, for example, verification of the authenticity of information in legal documentation, personal identity documentation, accreditation documentation, access documentation and the like.
• Dl suffers from the disadvantage and that the server may be compromised and the hash stored therein modified to match a tampered document.
• Dl is not suitable for applications requiring high security stringency such as for utilisation for boarding passes, personal identification documentation and the like.
• the present invention utilises, in a preferred embodiment, a distributed cryptographically based blockchain for storing document verification records in a way that cannot be altered.
• D2 hashes an electronic document (such as a PDF) and stores the hash as a special bitcoin transaction that encodes/contains the hash via an OP_RETURN script.
• This is a bitcoin scripting opcode that marks the transaction output as provably unspendable and allows a small amount of data to be inserted, which in this case is the document's hash, plus a marker to identify all of D2's transactions.
• D2 is not directed to the problem verifying the authenticity of information in a document but rather proving that a particular document existed in a particular electronic format at a particular time.
• D2 cannot be used to detect whether a document has been tampered with.
• D2 hashes the entire electronic document file and therefore cannot be used for hardcopy documents wherein slight printing, scanning, photocopying appearance aberrations would generate an entirely different hash using the system of D2 and therefore the document information contained therein would be unverifiable.
• the present invention utilises document content metadata (stored using a metadata hash, as opposed to the document hash of Dl) as the basis for verification and can therefore be utilised for hardcopy documents.
• Dl and D2 are deficient in that document information cannot be updated with the document remaining verifiable.
• the present invention utilises blockchain update transactions for the purposes of updating document content fields in this way, during the document verification stage, the blockchain can be inspected in reverse chronological order to detect whether or not a document (or specific document content information fields) has been superseded.
• both Dl and D2 are deficient in that verification cannot be for a predetermined period.
• the present invention in accordance with an embodiment, creates blockchain transactions specifying a validity period.
• the present invention in accordance with an embodiment, utilises revocation- type blockchain transactions such that the revocation of the authenticity of a document may be detected by a revocation-type transaction subsequent in time to a former verification transaction.
• Dl and D2 are deficient in that verified information cannot be displayed in association with the document for visual comparison.
• the present invention stores the meta data, such as in the computer readable data (i.e. 2D barcode) within the document itself or within the blockchain such that the information may subsequently be extracted and displayed to the user.
• the computer readable data i.e. 2D barcode
• a method for document information authenticity verification comprising: a verification record creation stage comprising: receiving document content metadata from a document; generating a metadata hash using the document content metadata; creating a blockchain transaction comprising the metadata hash; and generating computer readable data encoding the metadata hash; updating the document with the computer readable data; a document verification stage comprising: receiving the document; extracting the metadata hash from the computer readable data; and identifying the metadata hash within blockchain transactions of the blockchain to verify the authenticity of the document metadata.
• Dl or D2 do not disclose the creation of a metadata hash for document information of a document, the creation of an associated blockchain transaction and the updating of the document with computer readable data (i.e. 2D barcode) with the meta will data hash.
• the computer readable data may be a barcode.
• the barcode may be a two dimensional barcode.
• the verification record stage further may comprise signing the document with a private key associated with a document verification server.
• the method may further comprise storing the document content metadata such that wherein the document verification stage further may comprise retrieving the document content metadata and displaying the document content metadata.
• Storing the document content metadata may comprise encoding the metadata within the computer readable data.
• Storing the document content metadata may comprise encoding the metadata within the blockchain transaction.
• the verification record creation stage further may comprise identification of the document content metadata from the document.
• the identification of the document content metadata may comprise optical character recognition.
• the identification of the document content metadata may comprise performing search string queries against text extracted using the optical character recognition.
• the identification of the document content metadata may comprise isolating text within at least one user defined region of the document.
• the method may further comprise a document content updating stage comprising: receiving updated document content metadata for the document; generating a new metadata hash using the updated document metadata; creating a further blockchain transaction comprising the new metadata hash.
• the document verification stage may comprise: identifying two or more blockchain transaction associated with the document.
• the document verification stage further may comprise identifying that the document content metadata may be superseded by the updated document content metadata.
• the method may further comprise identifying which of the document may be superseded.
• the method may further comprise a document verification revocation stage comprising: creating a revocation blockchain transaction such that, during the document verification stage, the method further may comprise: identifying the revocation blockchain transaction subsequent in time to the blockchain transaction to fail the verification of the authenticity of the document information.
• the blockchain transaction further specifies a validity period, such that, during the document verification stage, the method further may comprise failing the verification of the document if the validity period has expired.
• the method may further comprise creating a validity period renewal blockchain transaction comprising a further validity period such that, during the document verification stage, the further validity period may be used when determining the validity of the document.
• a system for document information authenticity verification comprising: a document information verification server, the document information verification server comprising: a database comprising: a hash blockchain; anda document metadata table stored in relation to the one-way hash blockchain; software modules comprising: a document creation module; and a document information verification module; a client terminal in operable communication with the document information verification server, the client terminal comprising: a computer readable data reader; a software application in operable communication with the computer readable data reader, the software application comprising: a document information verification module; wherein, in use, the system may be configured for a verification record creation stage comprising: the document creation module of the document information verification server: receiving document metadata in relation to a document; receiving or generating a one-way hash from the document metadata using a
• the system further may comprise a document issuer server in operable communication with the document information verification server.
• the document information verification server may be configured for receiving the document metadata from the document issuer server.
• the document information verification stage further may comprise at least one of the client terminal and document information verification server sending at least one of the one-way hash and the document metadata to the document issuer server for further verification of the document.
• the document issuer server may comprise a database comprising at least one of hash and metadata data and wherein the further verification may comprise cross-referencing at least one of hash and metadata data within the document issuer server database.
• the document information verification module of the document information verification server may be further configured for sending a verification result to the client terminal.
• the client terminal software application may be further configured for generating graphical user interface and wherein the graphical user interface may be configured for displaying the verification result.
• the graphical user interface may be further configured for displaying at least a subset of the document metadata.
• the system may comprise a plurality of document information verification servers and wherein the blockchain may be a distributed blockchain distributed across the plurality of document information verification servers.
• Creating the computer readable data may comprise creating an optical computer readable data.
• the computer readable data may be a 2-D barcode.
• the system may further comprise inserting the computer readable data into the document.
• Figure 1 shows a system for document information authenticity verification in accordance with an embodiment of the present disclosure
• Figure 2 shows an exemplary method for the creation of document information authenticity verification records in accordance with an embodiment
• Figure 3 shows an exemplary method for verifying the authenticity of a document using the formally created document authenticity verification records in accordance with an embodiment
• Figure 4 shows an exemplary method for updating document information while yet being able to verify the authenticity of the updated document in accordance with an embodiment
• Figure 5 shows an exemplary method for revoking the authenticity records of a particular document in accordance with an embodiment
• Figure 6 shows an exemplary graphical user interface displayed by a client terminal of the system when verifying a document of Figure 1 in accordance with an embodiment of the present disclosure.
• FIG 1 there is shown a system 1 for document information authenticity verification.
• the system 1 is configured for verifying the authenticity of documents, such as paper-based and electronic documents, especially the information presented by such documents for reducing or eliminating document forgery, falsification of qualifications and the like.
• the system 1 comprises a document verification server 19.
• the document verification server 19 is configured with various software modules for performing the various computational processing tasks described herein.
• the document verification server 19 may take the form of a physical (such as rack mounted) computer server but, in alternative embodiments, the server in relating may take the form of a virtualised server instance, such as that which may be implemented by Amazon Web Services (AWS).
• AWS Amazon Web Services
• the document verification server 19 maintains copy of a blockchain ledger and therefore the processes described herein of the document verification server 19 may be shared between a plurality of servers 19.
• the document verification server 19 comprises a processor 31 for processing digital data.
• a processor 31 for processing digital data.
• a memory device 29 In operable communication with the processor 31 across a system bus 33 is a memory device 29.
• the memory device 29 is configured for storing digital data including computer program code.
• the processor 31 may fetch and execute instructions stored within the memory device 29 and store the data results of such execution on the memory device in 29.
• the memory 29 may take the form of a combination of volatile (RAM) and nonvolatile (HDD) storage.
• the memory 29 is shown in figure 1 as being configured with a plurality of software modules 15 and associated data within database neural 20.
• the software modules 15 may comprise a creation module 14 for creating document verification records which may be subsequently verified by verification module 13 in the manner described in further detail below.
• the data shown within the database has been shown for illustrative convenience as comprising document metadata 23 and, in embodiments where a blockchain is utilised, the blockchain data 26 comprising a plurality of document hashes 21, 22 representative of document metadata 23 of various verified documents.
• the document verification server 19 further comprises an I/O interface 30 for communicating with various computer peripherals including user interface peripherals and the like.
• the I/O interface 30 may further interface with data storage peripherals such as USB memory storage devices.
• the computer program code modules 15 may be stored on a computer readable medium which may be uploaded to the verification server 19 via the I/O interface 30 (or network interface 32) so as to configure the document verification server 19 to perform the specific computational processing tasks described herein.
• the document verification server 19 further comprises a network interface 32 for sending and receiving data across a computer network illustrated as being the Internet 34 in the system 1 shown. In this manner, the document verification server 19 may be in operable communication with the other computing actors shown in figure 1.
• the system 1, in embodiments, may further comprise a document issuer server 16.
• the document issuer server 16 is utilised by the person, entity, organisation, authority or the like issuing sensitive documents requiring authenticity verification in the manner described herein.
• the document issuer may utilise the document issuer server 16 for the purposes of storing document metadata 16, compiling and generating documents, storing and forwarding the documents across the Internet 34 and the like.
• the document issuer server 16 may similarly comprise software modules 10 having verification 11 and creation modules 12. Furthermore, the document issuer server 16 may further store document metadata 18 and associated hashes 24.
• the document issuer server 16 can perform, in embodiments, all of the document authenticity verification tasks and data such as where, for example, an organisation utilises the document issuer server 16 for performing the document verification in an isolated manner.
• the document issuer 16 may utilise the document verification server 19 (such as on a subscription API basis) for performing all of or at least some of the document verification tasks.
• System 1 further comprises a client terminal 25 in operable communication with at least one of the document issuer server 16 and document verification server 19 across the Internet 34.
• the client terminal 25 may be utilised for displaying information indicative of the authenticity of a document.
• the client terminal 25 may take the form of a personal computer device such as a notebook, mobile communication device (such as a smart phone device such as an Apple iPhone or the like) which may be utilised by a user to verify the authenticity of a document.
• a personal computer device such as a notebook
• mobile communication device such as a smart phone device such as an Apple iPhone or the like
• the client terminal 25 may further comprise a network interface 32 for communicating across the Internet 34.
• the network interface 32 may send and receive data across the cellular network such as a 3-5G cellular data network.
• the client terminal 25 similarly comprises a processor 31 for processing digital data and a memory device 29 in operable communication with the processor 31 across a system bus 33.
• the client terminal 25 memory 29 may further comprise an operating system 30 such as the Apple OS or Android operating systems.
• the client terminal 25 may further comprise an I/O interface 30 which, in the embodiments shown, may interface with a computer readable data reader 8.
• the reader 8 may read computer readable data 27 from a document 2 for verification so as to verify the authenticity of the document.
• the reader 8 may take the form of the image capture/camera device of the client terminal 25 and the computer readable data 27 may take the form of a two dimensional (2D) (such as a Quick Response (QR)) barcode.
• 2D two dimensional
• QR Quick Response
• the client terminal 25 (taking the form of a mobile communication device) be configured utilising a downloaded software application "app" 9 which may be downloaded for installation and execution by the client terminal 25 such as from a software application store, such as the Apple App Store or the like.
• the software application 9 may comprise various sub modules/software modules including a verification module 6 and a graphical user interface module 7.
• Figure 1 further shows the system 1 comprising a document 2 which is verified by the system 1.
• the document 2 may take the form of hard copy and soft copy documents.
• the soft copy (electronic, such as in PDF format) documents may be stored within a document database 34.
• particular documents may be retrieved utilising a URL and document ID or other unique identifier, such as a document hash.
• the document 2 may comprise document content 5. Furthermore, the document 2 may comprise computer readable data 27 which, as alluded to above, may take the form of a 2D barcode included or printed on the document 2. As such, the computer readable data 27 may be read by the client terminal 25 (or other computing actor across the Internet 34) so as to verify the authenticity thereof.
• the computer readable data 27 may comprise a document ID, a document metadata hash 4 or document metadata 3 or a combination thereof depending on the particular application.
• the particular architecture provided in figure 1 is for the application wherein a document verification server 19 is deployed for utilisation on a subscription basis such that various document issuers, users and the like may selectively access the web functions exposed by the document verification server 19 for verifying documents.
• the particular architecture may be modified whilst yet performing the same document authenticity verification tasks and functionality within the purposive scope of the embodiments described herein.
• the method 35 is utilised for creating document authenticity records which may be subsequently utilised and subsequent verification steps.
• the document 2 is a physical document
• the document may be scanned utilising a scanner and the document content obtained utilising optical character recognition (OCR).
• OCR optical character recognition
• the document content may be read from the electronic file system document itself (such as by reading various document metadata or document content, including wherein the document content may also be recognise using OCR) or alternatively retrieved from an appropriate database, such as the database 17 of the document issuer server 16.
• the document content is the important document content (referred to herein as metadata, which is hashed into a metadata hash such as the M D5, SHA256 hash or other suitable oneway hash) for which subsequent alterations or modifications to this important document content may be detected by the system 1.
• metadata the important document content
• the entire document may be hashed into a document hash so that any alterations to the document may be detected.
• system 1 may comprise functionality for the updating of the document content/metadata, or for the revoking of the authenticity accreditation.
• the metadata may represent the name of the issue organisation, the name of the attainer and the name of the qualification.
• the metadata may represent the name of the passenger, the flight number, the boarding gate, the passport number the destination and the like.
• the system 1 is configured for creating a metadata hash 4 of the metadata such that tampering of the important metadata may be detected by the system 1.
• the metadata may be kept in non-hashed format (either in plan text or encrypted) so as to allow for the subsequent display by the client terminal 25 during verification.
• Metadata at step 40 may be useful for hard copy documents such that the important information presented thereon is isolated for verification.
• the document may be modified in other manners, such as including photocopying and scanning aberrations, printing on differing letterheads or the like without affecting the ability to verify the authenticity thereof.
• the electronic document file may be hash, such as the MD5, SHA256 hash or the like.
• a separate meta data hash and document hash may be utilised so that modification of the document or the sensitive meta data therein may be detected independently.
• the metadata used may be user-specified. For example, certain metadata is used from the document issuer database 29 is user-specified.
• search string filters may be specified so as to allow the system 1 to extract (including using OCR) the appropriate metadata.
• document regions/rectangles may be specified (representing the location of the document metadata within the document) so as to allow the system to extract text only from the specified regions.
• a document ID may be obtained or generated.
• the document ID is globally unique (GUID) so as to prevent or substantially eliminate document ID collisions.
• the document ID may be utilised for uniquely identifying documents for verification.
• the document ID may be utilised for retrieving documents from the document database 34 utilising a URL comprising the document ID.
• the document ID may be utilised for updating documents for revoking documents.
• the document ID may be generated by the system 1.
• the document ID 1 may be provided by the document issuer such as wherein, for example, a registered training organisation issues statement of attainment documents in numerical sequential order.
• the document ID may also be hashed as part of the meta data hash or document hash so as to prevent tampering of the document ID.
• a document ID need not necessarily be required.
• a hard copy document may comprise a 2D barcode thereon representing a hash of the metadata, the metadata representing the information displayed by the document.
• the 2D barcode may be scanned for verifying the document content without necessarily having to use a document ID.
• the hash generated from the document file or metadata may serve as the unique document ID.
• a hash 4 is created.
• the hash is a one-way hash such as MD5, SHA256 or the like.
• MD5 hash
• SHA256 hash-way hash
• the hash provides the ability to reduce potentially a large amount of information into a small size but, importantly, wherein tampering even with a single letter of the content drastically affects the hash.
• the hash 4 is a meta data hash such that the meta data (important document information) is hashed so as to be able to detect subsequent altering of this important document information.
• the hash 4 may be a document hash of the electronic document file.
• a combination of the above information may be hashed to form the hash 4.
• the system 1 utilises a blockchain for the purposes of storing the hashes 4 so as to be able to provide an unalterable distributed and trusted ledger of verifying documents.
• the document verification server 19 may store a copy of a blockchain ledger 26 within the database 20 which may be synchronised with other documentation verification server 19.
• the hash is added to a blockchain transaction which is then subsequently mined and added to a block in the blockchain.
• the hash may be added to a blockchain, including, wherein the bitcoin blockchain is utilised, within the bitcoin scripting opcode.
• a customised blockchain may be utilised comprising appropriate data fields.
• the blockchain may be inspected to ascertain whether the hash 4 (which may be scanned from the 2D barcode 27 or alternatively calculated on the fly) resides within the blockchain.
• the entire blockchain may be searched for a hash but, in a preferred embodiment, a separate hash index may be used for speeding the hash finding process.
• the document issuer server 16 may maintain the database of document metadata 18 (or document content) and associated document hashes 24 or document IDs for the purposes of allowing for the verification of documents in isolation without the utilisation of a shared ledger. It is way, the system 1 yet maintains a copy of the meta data 18 (so as to, for example, allow for the display of the meta data during the verification process for visual comparison by the user) and associated hashes so as to be able to detect tampering of the meta data (albeit without security against the database 17 tampering which may be avoided utilising the blockchain).
• step 44 computer readable data may be generated which may then be utilised in conjunction with the document for verification.
• step 46 the computer readable data is inserted into the document, either visibly or invisibly.
• the computer readable data 27 may take the form of a 2D barcode comprising one or more of the document hash, document ID and document metadata.
• the computer readable data 27 is visible so as to allow for printing, scanning and photocopying of the document.
• the document may be modified to visibly display the computer readable data 27 such as wherein, for example, a PDF document is modified to include an image of the 2D barcode at the bottom right-hand side of the document.
• a PDF document is modified to include an image of the 2D barcode at the bottom right-hand side of the document.
• the user may utilise the camera device of the smart phone 25 to capture an image of the 2D barcode to verify the contents or the metadata of the document.
• the computer readable data 27 need not necessarily be human visible and may be incorporated within, for example, the metadata of the document. In this way, when displaying the document the document display software may, in the background, inspect the associated metadata and displaying and indication as to whether the document is verified or not.
• a PDF document may be updated such that the PDF document metadata comprises the computer readable data 27 (which, as alluded to above, may include one or more of the document metadata, document ID and a document hash).
• the PDF software may automatically inspect the computer readable data 27 and display an indication as to whether the document is verified or not.
• FID tags may be used.
• the document may also be digitally signed so as to prevent tampering or modification of the computer readable data included or inserted thereon.
• the document verification server 19 may sign the document using a private key such that others may subsequently verify that the document verification server 19 had indeed signed the document utilising the associated public key.
• FIG 2 there is shown an exemplary method 36 for document authenticity verification. As will become apparent from the ensuing description, the method 36 is utilised for the purposes of verifying the authenticity of a document utilising the computer readable data 27 associated therewith.
• the method 36 starts at step 47 wherein the document is obtained.
• a physical document may be obtained in hand or alternatively, an electronic document may be retrieved from a file system, downloaded from a URL or the like.
• step 48 the computer readable data associated with the document is scanned or read.
• the barcode may be read utilising the reader 8 of the client terminal 25.
• the computer readable data 27 may be retrieved by the document display software (such as Adobe Acrobat).
• the document display software such as Adobe Acrobat.
• the hash may be extracted from the computer readable data 27.
• the document ID may also be retrieved from the computer readable data so as to be able to compare against the document ID used to retrieve the document or associated with the document.
• the blockchain may be inspected for blocks containing transactions containing the hash and, in embodiments, the associated document ID.
• a verification may be displayed to the user indicating that the document is authentic.
• metadata may be extracted from the computer readable data which may then be displayed by the client terminal 25 so as to allow the user to compare the metadata extracted from the computer readable data to that which is displayed on the document.
• the meta data 23 may be stored within the blockchain 26 itself such that the metadata 23 may be retrieved from the blockchain 26 during verification so as to negate the need to store the metadata 23 within the 2D barcode 27 itself.
• FIG 4 there is shown an exemplary method 37 for updating document metadata.
• a need may arise to update document metadata.
• a gate change may occur for boarding passes.
• the name of the attainer may be changed from a maiden name.
• method 37 may be utilised for allowing updating of certain document fields while yet being able to maintain the ability to verify the authenticity of a document.
• the document ID for the document to be updated may be generated or obtained (or other unique identifier such as the document or metadata hash).
• the updated metadata (or document content) is received.
• the updated metadata may comprise a new surname.
• step 56 the new hash is added by way of a further transaction to the blockchain.
• the document may be modified to incorporate the new computer readable data 27.
• the updating of the 2D barcode 27 need not necessarily take place, especially for documents which have already been disseminated.
• the blockchain transactions may be inspected in reverse chronological order wherein the most recent in time verification transaction is utilised as the current verification transaction.
• the client terminal 25 may inform the user that the document metadata/content is out of date and that the document has been superseded.
• the verification result may indicate that the document has been superseded. However, in other embodiments the verification result may indicate which document content metadata has been superseded.
• the document ID and the original metadata hash may be stored within the blockchain.
• 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 be searched for blockchain transactions associated with the document ID.
• the system 1 is able to compare the retrieved hash against the two or more transactions to identify whether the particular transaction is current or has been superseded.
• FIG 5 there is shown an exemplary method 38 for document authenticity revocation.
• a need may arise to revoke a document.
• a person having received a statement of attainment may have subsequently have been found out to having fraudulently obtained the qualification and therefore the statement of attainment requires revocation.
• the method 38 utilises a revocation transaction which is added to the blockchain to revoke a document.
• the method 38 starts at step 60 wherein a revocation request is received for a particular document as is identified by a document ID (or other unique identifier such as the document or metadata hash).
• a revocation transaction is added to the blockchain.
• the revocation transaction is identified by transaction type (the revocation transaction type, which may again be stored in the bitcoin scripting opcode) and the document ID.
• step 62 the computer readable data is received for the document and the document ID and or document hash is extracted therefrom.
• the blockchain is searched for matching document IDs or hashes.
• the system 1 identifies a subsequent revocation transaction within the blockchain associated with the document ID or hash and therefore, at step 64, the verification fails.
• documents may have a finite authenticity. Wherein, for example, documents are valid for 12 months only such as the case may be for driver licenses.
• verification transaction stored within the blockchain may specify a validity period (which may again be stored in the bitcoin scripting opcode).
• the system 1 may inspect the entry dates of the verification transactions and should the current date exceed the validity period, the verification fails.
• validity period may be renewed through the addition of subsequent in time blockchain verification transactions.
• the document issuer (RTO) server 16 comprises a plurality of software modules 10.
• the software modules 10 may comprise a verification record creation module 12 for the purposes of creating a document record for subsequent verification.
• the document information verification server 19 may itself comprise a plurality of software modules 15 itself comprising a verification record creation module 14.
• the software modules 10 of the document issuer (RTO) server 16 may further comprise a verification module 11 for the subsequent verification of documents.
• the software modules 15 of the document information verification server 19 similarly comprise a verification module 13 the purposes of verifying documents as will be described in further detail below.
• verification and creation functionality may be implemented by the same modules if the functionality of the document issuer (RTO) server 16 and the document information verification server 19 is implemented by a single server.
• the document issuer (RTO) server 16 comprises a database 17.
• the database 17 may comprise metadata 18, or other type of structured data, configured for storing various information fields in relation to the course completed by James Smith.
• a hash is created of the above metadata.
• the metadata is concatenated such as into a string comprising:
• the concatenated string is hashed using a one-way hash algorithm, such as an M D5, SHA256 or other hash algorithm.
• a hash may generate the following hash:
• the metadata hash is stored so as to be usable for subsequent document information verification.
• the document information verification server 19 comprises a database 20 for storing various information including hash data.
• the above metadata hash is inserted into the database 20.
• Such insertion may comprise the document information verification server 19 receiving the metadata (or the metadata hash) from the database 17 of the document issuer ( TO) server 16, such as at periodic intervals, upon request and the like.
• the hashing algorithm described herein may be performed by any of the computing actors within the purposive scope of the embodiments described herein.
• the document issuer (RTO) server 16 or the document information verification server 19 may perform the hashing.
• the system 1 may implement a distributed public ledger blockchain 26 such that each hash entry is verifiable in accordance with the other hash entries within the database 20.
• the verification is performed by a single document information verification server 19.
• the blockchain 26 may be a distributed blockchain distributed across a number of servers 19.
• any distributed cryptography based blockchains may be utilised within the purposive scope of the embodiments described here and including those being used in, or being similar to Bitcoin, ehterum, litecoin blockchains and the like.
• each RTO 16 ("document information issuer") and document verification server 19 may be assigned an "issuer address", which may be a Bitcoin wallet address. Capacitor, transactions within the Bitcoin blockchain may be uniquely associated with the respective document issuer server 16 or document verification server 19.
• the metadata may also be stored within the database 20 of the document information verification server 19. In this manner, having the hash (or document ID), the metadata may be looked up.
• the hash may serve as a primary key.
• the database 20 need not necessarily comprise the metadata 23 so as to comprise the hash only for the purposes of document information verification.
• computer readable data is generated comprising at least one of the hash and the metadata.
• the creation of the computer readable data will allow the insertion of the computer readable data onto a document, such as a certificate of attainment, being a paper-based or electronic (i.e. PDF) document which may be subsequently read using the client terminal 25 for the purposes of verifying the authenticity of the document and the document metadata stored therein.
• the computer readable data is embodied in a 2D barcode.
• the following formats may be utilised for data encoding: a. [Key_hash]
• FIG. 1 As can be seen from figure 1, there is shown a document 2 being a certificate of attainment for the course completed by James Smith.
• the document 2 is issued as a PDF document by the document issuer (RTO) server 16.
• RTO document issuer
• James Smith may utilise the electronic PDF document 2 as evidence of his qualification for various employment purposes.
• the document may comprise document content 5 which may comprise the usual human readable information including at least a subset of the above described metadata.
• document content 5 may comprise the usual human readable information including at least a subset of the above described metadata.
• document may be edited, either electronically or physically so as to represent fraudulent information.
• the document by additionally comprising the computer readable data 27 may be verified using the client terminal 25.
• the computer readable data 27 borne by the document 2 may comprise at least one of the metadata 3, the metadata or document hash 4 and the document ID.
• only the metadata 3 is be encoded within the computer readable data 27 such that the hash may be calculated from the metadata for verification.
• only the hash 4 is encoded within the computer readable data 27 such that the metadata may be retrieved from the database 20 of the document information verification server 19 or the database 17 of the document issuer (RTO) server 16 or the blockchain.
• the client terminal 25 comprises a software application 9 configured for implementing the features and functionality described herein.
• the client terminal 25 is a mobile communication device, such as a smart phone device or the like.
• the client terminal 25 may comprise a reader 8, which, in embodiments may take the form of the mobile phone camera.
• the operation of the client terminal 25 may download the software application 9 for execution by the client terminal 25, such as from a software application store, such as the Apple iTunes store or the like.
• the software application 9 may comprise a verification module 6 configured for implementing the client terminal implemented functionality for document information verification and also a graphical user interface (GUI) module presented a graphical user interface for display to the 7 for the purposes of displaying various information to the client terminal user.
• GUI graphical user interface
• the client terminal user in order to verify the authenticity of the document, the client terminal user, using the reader 8, will scan the 2-D barcode computer readable data 27 provided on the document. Having received 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.
• the metadata 3 is encoded within the computer readable data 27 such that the GUI 7 of the client terminal 25 may display the metadata.
• both the hash 4 and the metadata 3 is encoded within the computer readable data 27 such that the client terminal 25 may generate a hash using the hashing algorithm using the encoded metadata 3 so as to verify at least that the encoded hash 4 matches the metadata 3.
• a propriety hash algorithm may be utilised so as to prevent fraudsters from fraudulently generating and encoding the hash using a known hashing algorithm.
• the client terminal 25 by being in operable communication with the document information verification server 19 across a data network, such as the Internet, is able to send at least one of the metadata 3 and the hash 4 to the document information verification server 19 for verification.
• the document information verification server 19 is configured to compare the hash received from the client terminal 25 (or calculated from the metadata 3 read by the client terminal 25) against the hash value stored within the blockchain 26.
• the document information verification server 19 is able to send a verification result back to the client terminal 25 verifying that the document information is authentic.
• the verification server 19 is configured to send and non-verification result back to the client terminal 25 indicating that the document information may be fraudulent or has been tampered with.
• the GUI 7 is configured for displaying the verification results to the client terminal user. Additionally, the GUI 7 may display the associated metadata.
• FIG 6 For example, and turning now to figure 6, there is shown an exemplary interface 28 displayed by the GUI 7 where the document has been verified. As can be seen, the interface 28 comprises various of the metadata and a confirmation that the document information is authentic.
• the system 1 is configured for implementing a further verification wherein the records held within the RTO server database 17 are further cross-referenced (in case the records have been updated or revoked). Specifically, cross-referencing may be performed using at least one of the hash and the metadata.
• the database 17 of the document issuer (RTO) server 16 may be configured for storing the hash values 24 in relation to the metadata 19. As alluded to above, such hash values 24 may be received from the document information verification server 19 or alternatively be computed by the document issuer (RTO) server 16 itself.
• the database 17 need not necessarily comprise the hash values 24 wherein the metadata 18 is cross-referenced.
• At least one of the client terminal 25 and the document information verification server 19 may send a further query to the verification module 11 of the document issuer (RTO) server 16 to verify the data stored within the database 17.
• the client terminal 25 may send the document number to the RTO server 16 to verify that the document number is genuine.
• Other cross-referencing may be done within the purposive scope of the embodiments described herein.
• problems of hard copy documentation may include the appearance of the documentation changing over time, such as by being caused by photocopying aberrations and the like.
• the hard copy document is a contract of sale document which has been countersigned by the seller, purchaser and witness.
• the hard copy document further specifies the immovable property being sold, identified by lot number.
• 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 contract of sale.
• the relevant metadata is the names of the seller and purchaser and lot number.
• the system 1 is configured to extract such metadata from the document.
• the system 1 may be configured to utilise string matching or the like to extract these fields from the data.
• an image scan of the document may be displayed on the client terminal 25 such that the lawyer is able to demarcate the metadata to be verified, such as by dragging rectangles around the associated text using the mouse.
• a document ID may be specified by the lawyer, being a file system generated document ID.
• the system 1 hashes the metadata (and the document ID in embodiments) and creates a verification transaction within the blockchain.
• system 1 Furthermore, the system 1 generates computer readable data in the form of a 2D barcode which is then printed onto the contract of sale document.
• the 2D barcode comprises the metadata hash 4, the document ID and the metadata.
• the conveyancer captures an image of the document utilising the camera of the conveyancer's mobile communication device 25.
• the mobile communication device 25 comprises an application 9 which identifies the 2D barcode and extracts the metadata hash, document ID and metadata from the 2D barcode.
• the mobile communication device 25 then sends a verification request across the Internet 34 to the document verification server 19.
• the verification request comprises the hash but, in embodiments, may additionally include the document ID.
• the document verification server 19 searches through the verification transactions of the blockchain and identifies the earlier verification transaction created.
• the document verification server 19 then sends a verification response to the mobile communication device 25 such that the mobile communication device 25 is able to display an indication that a verification record exists.
• the conveyancer's mobile communication device 25 may display the metadata extracted from the 2D barcode. As such, the conveyancer may visually inspect the names of the parties and the lot number on the document as is displayed by the mobile communication device 25 so as to ensure their consistency. [258] It should be noted that the client terminal 25 may rehash the metadata stored within the 2D barcode so as to confirm whether the generated hash matches the hash of the 2D barcode (so as to prevent tampering of the metadata within the barcode).
• the metadata may also have been stored within the blockchain such that the metadata may sent to the client terminal 25 from the document verification server 19 for display.
• the mobile communication device may perform optical character recognition so as to read the text from the document (despite the photocopying aberrations) and confirm whether the recognised text matches the metadata.
• the client terminal 25 may search the OCR text to identify such metadata. If such is not identified, such as of the scanned document does not contain the same lot number, then the verification fails.
• the relevant metadata is demarcated within boundaries such as wherein, for example, in the embodiment described above, the lawyer draws rectangles over the metadata displayed on screen to be verified.
• the lot number may be in the middle top centre of the page whereas the names of the parties may be at the bottom left-hand right corners of the document respectively.
• the mobile communication device 25 is configured for recognising text only within the demarcated boundaries and then comparing the text extracted from these demarcated boundaries against the metadata.
• the mobile communication device 25 may identify the page corners for orientation so as to be able to accurately place the demarcated boundaries.
• relevant metadata may include the boarding pass ID, name of the passenger, and the departure gate.
• the document verification server 19 may hash the metadata and create an entry within the blockchain and send a 2D barcode to the passenger record computing system which is then printed onto the boarding pass.
• the passenger record computing system may send the boarding pass ID and updated gate number.
• the document verification server 19 For each update, the document verification server 19 creates a new entry within the blockchain.
• the 2D barcodes of the boarding passes are scanned and the boarding pass ID, and metadata (passenger name and gate number) are extracted from the barcodes.
• metadata passenger name and gate number
• such information may also be retrieved via OCR from the boarding pass print.
• Such extracted metadata may be then sent to the document verification server 19 for verification.
• the boarding gate computer may maintain a copy of the blockchain so avoid time-consuming queries across the Internet to the document verification server 19.
• the boarding pass may have been tampered with to change the name printed on the boarding pass and also the associated entry within the passenger record computing system database.
• the metadata stored within the 2D barcode may additionally have been modified.
• the boarding pass may still represent the old gate number.
• the new gate number may be sent by the passenger checking computer to the document verification server 19 wherein the document verification server 19 is able to identify a further verification transaction in relation to the boarding pass ID with the new gate number and therefore pass the verification of the boarding pass.
• the verification would fail for any other gate number provided not matching the gate updating transaction within the blockchain.
• the invention may be embodied using devices conforming to other network standards and for other applications, including, for example other WLAN standards and other wireless standards.
• Applications that can be accommodated include IEEE 802.11 wireless LANs and links, and wireless Ethernet.
• 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 might 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 medium. The term does not imply that the associated devices are coupled by electrically conductive wires.
• 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, e.g., may be stored in registers and/or memory.
• a "computer” or a “computing device” or a “computing machine” or a “computing platform” may include one or more processors.
• the methodologies described herein are, in one embodiment, performable by one or more processors that accept computer-readable (also called machine-readable) code containing a set of instructions that when executed by one or more of the processors carry out at least one of the methods described herein.
• Any processor capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken are included.
• a typical processing system that includes one or more processors.
• the processing system further may include a memory subsystem including main RAM and/or a static RAM, and/or ROM.
• a computer-readable carrier medium may form, or be included in a computer program product.
• a computer program product can be stored on a computer usable carrier medium, the computer program product comprising a computer readable program means for causing a processor to perform a method as described herein.
• the one or more processors operate as a standalone device or may be connected, e.g., networked to other processor(s), in a networked deployment, the one or more processors may operate in the capacity of a server or a client machine in server-client network environment, or as a peer machine in a peer-to-peer or distributed network environment.
• the one or more processors may form a web appliance, 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.
• 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 that are for execution on one or more processors.
• embodiments of the present 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.
• the computer-readable carrier medium carries computer readable code including a set of instructions that when executed on one or more processors cause a processor or processors to implement a method.
• 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.
• the present invention may take the form of 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 further be transmitted or received over a network via a network interface device.
• the carrier medium is shown in an example 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 of the processors and that cause the one or more processors to perform any one or more of the methodologies of the present invention.
• a carrier medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media.
• a device A connected to a device B should not be limited to devices or systems wherein an output of device A is directly connected to an input of device B. It means that there exists a path between an output of A and an input of B which may be a path including other devices or means.
• Connected may mean that two or more elements are either 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.

Landscapes

• Engineering & Computer Science (AREA)
• Computer Security & Cryptography (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Theoretical Computer Science (AREA)
• Health & Medical Sciences (AREA)
• General Health & Medical Sciences (AREA)
• Computer Hardware Design (AREA)
• Software Systems (AREA)
• Physics & Mathematics (AREA)
• General Engineering & Computer Science (AREA)
• General Physics & Mathematics (AREA)
• Bioethics (AREA)
• Storage Device Security (AREA)
• Management, Administration, Business Operations System, And Electronic Commerce (AREA)
• Document Processing Apparatus (AREA)
• Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
• Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Priority Applications (21)

Applications Claiming Priority (2)

Publications (1)

Family

ID=59562866

Family Applications (1)

Country Status (28)

Cited By (39)

Families Citing this family (82)

Citations (4)

Family Cites Families (19)

• 2017
  • 2017-02-07 PT PT177498219T patent/PT3414867T/pt unknown
  • 2017-02-07 BR BR112018016212-4A patent/BR112018016212A2/en active Search and Examination
  • 2017-02-07 CO CONC2018/0009397A patent/CO2018009397A2/es unknown
  • 2017-02-07 CA CA3012870A patent/CA3012870C/en active Active
  • 2017-02-07 SG SG11201805566XA patent/SG11201805566XA/en unknown
  • 2017-02-07 WO PCT/AU2017/050096 patent/WO2017136879A1/en not_active Ceased
  • 2017-02-07 CR CR20180435A patent/CR20180435A/es unknown
  • 2017-02-07 CZ CZ2018-449A patent/CZ2018449A3/cs unknown
  • 2017-02-07 CU CUP2018000085A patent/CU20180085A7/es unknown
  • 2017-02-07 JP JP2018536277A patent/JP6959618B2/ja active Active
  • 2017-02-07 AU AU2017218452A patent/AU2017218452B2/en active Active
  • 2017-02-07 MX MX2018009616A patent/MX2018009616A/es unknown
  • 2017-02-07 MY MYPI2018702583A patent/MY183574A/en unknown
  • 2017-02-07 US US16/073,914 patent/US10972281B2/en active Active
  • 2017-02-07 MA MA044016A patent/MA44016A/fr unknown
  • 2017-02-07 EP EP17749821.9A patent/EP3414867B1/en active Active
  • 2017-02-07 EA EA201891795A patent/EA034354B1/ru unknown
  • 2017-02-07 GE GEAP201714871A patent/GEP20207163B/en unknown
  • 2017-02-07 CN CN201780018818.8A patent/CN109075971B/zh active Active
  • 2017-02-07 KR KR1020187022860A patent/KR20180110670A/ko active Pending
• 2018
  • 2018-07-05 ZA ZA2018/04492A patent/ZA201804492B/en unknown
  • 2018-07-24 PH PH12018501569A patent/PH12018501569A1/en unknown
  • 2018-07-24 SA SA518390002A patent/SA518390002B1/ar unknown
  • 2018-08-07 IL IL261020A patent/IL261020B/en active IP Right Grant
  • 2018-08-07 NI NI201800081A patent/NI201800081A/es unknown
  • 2018-08-08 CL CL2018002135A patent/CL2018002135A1/es unknown
  • 2018-08-08 SV SV2018005732A patent/SV2018005732A/es unknown
  • 2018-08-13 AU AU2018101148A patent/AU2018101148A4/en not_active Expired
  • 2018-09-06 EC ECSENADI201867575A patent/ECSP18067575A/es unknown

Patent Citations (4)

Non-Patent Citations (2)

Also Published As

Similar Documents

Legal Events