Blockchain Fintech – Brian Deery, Paul Snow, Mahesh PAOLINI-SUBRAMANYA, Inveniam Capital Partners Inc
Abstract for “Validating documents using blockchain”
“Multiple digital signatures are used to authenticate electronic documents. To generate multiple digital signatures that can be distributed via the blockchain, structured data, metadata and instructions may all be hashed. A peer may verify the authenticity of an electronic document by using any of the multiple digital signatures included in the blockchain.
Background for “Validating documents using blockchain”
Online, authenticity is essential. Electronic documents can be easily shared, especially through private and public networks (such the Internet). It is easy to alter electronic documents for fraudulent purposes.
“BRIEF DESCRIPTION ABOUT THE VIEWS FROM THE DRAWINGS”
“The features, aspects and benefits of the exemplary embodiments can be understood by reading the following detailed description with reference to the accompanying illustrations.
“FIGS. “FIGS.1-3” are simplified examples of validating electronic documents according to exemplary embodiments.
“FIGS. “FIGS.
“FIGS. 8-12 illustrate further verification, according to exemplary embodiments.
“FIG. “FIG.
“FIG. “FIG.
“FIG. “FIG.
“FIGS. “FIGS.
“FIG. “FIG.
“FIGS. 19-20 show additional operating environments that allow for further aspects of the exemplary embodiments.
“The accompanying drawings will be used to describe the exemplary embodiments more fully. However, the exemplary embodiments can be implemented in many other forms, and should not be considered limited to those described herein. These embodiments have been provided to ensure that the disclosure is complete and comprehensive and that the exemplary embodiments are fully communicated to all who are skilled in the art. Furthermore, the embodiments cited herein, along with specific examples, are meant to include both functional and structural equivalents. It is also intended that these equivalents include both current equivalents and future equivalents (i.e. any elements that perform the same function regardless of their structure).
“The diagrams, schematics and illustrations are conceptual views or processes that illustrate the exemplary embodiments. This is what ordinary skill in art will appreciate. You can achieve the functions of the different elements in the figures by using dedicated hardware or hardware that can execute associated software. People of ordinary skill in art also understand that the illustrative hardware, software, processes and/or operating system described herein are intended to be used as a guide only and are not meant to be restricted to any manufacturer.
“As used herein the singular forms?a? ?an,? ?an,? Unless otherwise stated, the plural forms of?the? and?includes? are meant to be used together. Further, it will be understood that the terms “includes”,? ?comprises,? ?including,? and/or ?comprising,? When used in this specification, they indicate the presence of the stated features, integers and steps, operations, element and/or component. However, it does not preclude the addition or presence of other features, integers and steps, operations and elements and/or parts. It is understood that an element can be referred to as being “connected” or “coupled”. It is possible to refer to an element as being?connected? It can be connected to or coupled with another element. Interfering elements may also be present. Furthermore, ?connected? Also,?connected? oder?coupled? can be used. Wirelessly connected and coupled may also be used as an expression herein. The term “and/or” as used herein may also be called wirelessly connected or coupled. The term?and/or? refers to any combination of one or more of these listed items.
“It is also understood that the terms first, third, and so on are not exclusive to one element. These terms may be used to describe different elements. However, they should not be limited. These terms can only be used to differentiate one element from the other. A first device might be called a second, while a second could be called a first. This is consistent with the disclosure’s teachings.
“FIGS. “FIGS.1-3” are simplified examples of validating electronic document 20 according to exemplary embodiments. These examples verify that the electronic document 20 was not altered since its creation. An authenticity 22 of an electronic document 20 is important for banking, security, identification and other online activities. The electronic document 20 may have been altered since its creation. This could lead to banking and other online activities being compromised. An altered version 24 may be a sign that malicious or fraudulent activity has been attempted. One example of a security plan that uses electronic data 26 to represent the electronic document 20 is a security scheme.
“FIG. “FIG. The verification server 28 checks whether the electronic document 20 was modified since its creation 30. The verification server 28 retrieves electronic data 26, which is the original version 32 of electronic document 20. This disclosure mainly explains the original 32 version as it was created on a date of 34. However, the original version 32 may be delineated with reference to any date, time or version. The verification server 28 can generate one or more hash value 36 associated with a haveh tree 38 based upon the electronic data 26 that represents the original version 32. An electronic representation of the hashing algorithm 40 may be used to generate the hash tree 38. One or more of 36 hash values may be distributed by the verification server 28 via a blockchain 50. Any of the 36 hash values (e.g. hash list, hash chains, branches, nodal Leaves) can be added to, stored or incorporated into any record, transaction or block that is distributed via the blockchain 50. The blockchain 50 can be sent to or routed to any destination (e.g., an Internet Protocol address associated for another server), FIG. 1 illustrates peer distribution. The verification server 28 could broadcast the blockchain 50 from the IP addresses of a network 52 that includes peer devices or nodes. Exemplary embodiments could use the blockchain 50 to distribute or publish information. The blockchain 50 is a digital ledger that records transactions chronologically and/or publicly. Most commonly, the blockchain 50 is used for decentralized cryptocurrency (such as Bitcoin). However, the blockchain 50 can be used in any custody or chain (such as medical records and title chains in real estate transactions). There are many configurations and mechanisms for the blockchain 50. Exemplary embodiments can be modified to fit any version. Peer-to-peer Blockchain technology is well-known, so this disclosure does not need to provide an in-depth explanation.
“FIG. “FIG. The verification server 28 checks whether the current version 60 has changed from the original electronic document 20’s creation date. The verification server 28 checks whether the current version 60 is different from the original 32. The verification server 28 retrieves electronic information 61 that represents the current version 60 from the electronic document 20. Based on the electronic data 61, the verification server 28 can generate one or more verification haveh values 62. The electronic representation of the hashing algorithms 40 is used to generate the verification hash value 62. The verification server 28 can then compare the verification values 62 with the hash value 36 that represent the original 32 version (as at the date 34 of its creation). The verification server 28 can infer that the current version 60 corresponds to the original 32 version by comparing the verification hash value 62 with the hash value 36. The verification server 28 can infer, however, that the current version 60 is different from the original 32 version if the verification hash value 62 fails to meet the 36 hash values. In other words, the current electronic document 20 version 60 has been modified since its creation date of 34. To implement additional security measures, the verification server 28 could generate a fraud alert 64.
“Exemplary embodiments might detect minor changes. Even subtle changes in electronic document 20 can make the hashing algorithm 40 very sensitive. There are many algorithms for hashing, and some embodiments can use any of them. This disclosure will focus on the SHA family cryptographic hashing algorithm, as many readers are familiar with it. If the SHA-256 algorithm was applied to electronic data 26, representing the original 32-bit version, the result would be a 256-bit digital signing. It is extremely unlikely that two sources of data will produce the same digital signature. If the current electronic document 60 has any subtle changes (such as one character in a textual word or number), the corresponding digital signature (e.g. the verification hash value 62) will not match the original 32 hash values. Exemplary embodiments can quickly tell if the electronic document 20 was modified since its creation date of 34.
“FIG. 3 illustrates nodal verification. Exemplary embodiments can distribute one or more hash values 36 via blockchain 50. The verification server 28 can generate the hash value 36 based on the electronic data 26, which represents the original 32-bit electronic document 20, and then the verification server 28, may distribute the 36 hash values via the blockchain 50. The verification server 28 could include the 256-bit digital sign 70 (generated using the SHA256 algorithm) in the blockchain 50. Any member of the trusted network 52 of peer devices can then verify the current version 60. For example, a trusted peer device 72 may obtain the blockchain 50 and retrieve the digital signature 70. Trusted peer 72 can then retrieve the electronic data 71 corresponding to the current version 60, and generate verification hash value 62 (such a 256-bit digital signature 74). The trusted peer 72 may then compare 36 hash values (received via blockchain 50) with the verification hash value 62 generated based upon the electronic document 20, version 60. The trusted peer device 72 could compare the 256 bit digital signature 70 (based upon the original 32-bit version) with the 256 bit verification digital signature 75 (based on current version 60). The trusted peer device 72 can infer that the current version 60 has been authenticated and not altered if the 36 verification hash value (e.g., a 256 bit verification digital signature 75) is compared to 36 hash values (e.g., the 256 bit digital signature 70) received over the blockchain 50. The trusted peer device 72 could infer or determine that the current version 60 has been altered and inauthentic if the 36 verification hash value (e.g. the 256 bit verification digital signature 74), fails to meet the 36 hash values (e.g. the 256 bit digital signature 70). To implement additional security measures, the trusted peer device 72 could generate the fraud alert 64.
“FIGS. “FIGS.4” 4-7 are detailed examples of an operating environment according to exemplary embodiments. FIG. FIG. 4 shows the verification server 28 communicating via a communications network 80 or wireless network 82 with the trusted peer device 72. FIG. FIG. As we will see, the trusted peer device 72 could be any processor-controlled device. The verification server 28 could have a processor (e.g., “??P?”). A processor 86 (e.g.,??P?), an application specific integrated circuit or another component that executes the verification algorithm 86 stored on a local memory device. 88. The verification algorithm (86) includes instructions, code and/or program that causes the verification server 28 perform operations such as creating the hash values 36 for the electronic document 20 (as described in the previous paragraphs). The verification algorithm may generate the digital signature 70 that represents the original 32-bit version (using the hashing algorithms 40). The verification algorithm 28 may instruct the verification server 28 or cause it to incorporate the digital signature 70 into a blockchain 50 for distribution on the mobile phone 84. Exemplary embodiments may, however, send the digital signature 70 or the blockchain 50 to any IP address associated any device or network destination.
“FIG. “FIG.5” illustrates peer verification. The blockchain 50 has been distributed. Now, the trusted peer 72 (again illustrated by the mobile phone 84) can determine the authenticity 22. FIG. FIG. 5 shows the mobile phone 84 that has received the blockchain 50 and digital signature 70. The processor 90 is an application-specific integrated circuit (ASIC) or another component that executes the peer-side verification algorithm. It’s stored in a local storage device 94. Peer-side verification algorithm (92) includes instructions, code and/or programmes that cause the processor to perform operations such as verifying version 60 of electronic document 20. Peer-side verification algorithm (92) causes the mobile phone 84 to retrieve electronic data 71 that represents the current version 60, and generate the verification digital signature74 (such as the corresponding hash of 256 bits). The peer-side verification algorithm (92) may determine or infer that the current version 60 has not been altered or authenticated if the verification digital signatures 74 and 70 compare satisfactorily. The peer-side verification algorithm (92) may determine that the current version 60 has been altered or inauthentic if the verification signature 74 does not match the digital signature 70 obtained via the blockchain 50. To implement additional security measures, the peer-side verification algorithm may generate the fraud alert 64.
“FIG. 6 illustrates servile verification. The verification server 28 can determine whether the electronic document 20’s authenticity 22 is genuine. The verification server 28 can notify or alert of security concerns if it receives the current electronic document 20 version 60. The verification algorithm 86 triggers the verification server to obtain the current version 60, and generate the appropriate verification digital signature 74. The verification algorithm 86 can infer that the current version 60 has been authenticated and not altered if the verification digital signature 74.1 is able to match the digital signature 70. If the verification digital signature of 74 does not satisfy the digital signature 70 (representing version 32), the verification algorithm 64 may apply the fraud alert 64 to determine if the current version 60 has been altered or inauthentic.
“FIG. The general verification scheme is illustrated in FIG. 7. The SHA256 hashing algorithm is well-known to many. Therefore, the general verification scheme could use the 256-bit hash value calculated by the SHA256 algorithm. Exemplary embodiments retrieve or obtain the electronic data 26, which is the original 32-bit version of the electronic document 20. The SHA256 hashing algorithm is used to create a 256-bit digital signature 70. Exemplary embodiments can also retrieve or obtain the electronic data 71, which represents the current version 60. The SHA256 hashing algorithm uses the electronic data 71 to generate a corresponding 256 bit hash value for the verification digital signature 74. Exemplary embodiments can infer that the current version 60 has been authenticated and not altered if a match is found. If the digital signatures 70 or 74 do not match, exemplary embodiments could infer that the current 60 version is fake and issue the fraud alert 64.
“Exemplary embodiments can use any type of processing component, configuration, and system. Multiple processors could be used, including distributed processors and parallel processors on a single machine. A virtual processing environment can be supported by the processor. A state machine, an application specific integrated circuit, (ASIC), programmable gates array (PGA) and a state machine could all be part of the processor. Any of the processors can execute instructions to perform “operations”. This could be the processor directly performing the operation or facilitating, directing or cooperating with another component or device to do the operation.
“Exemplary embodiments can packetize. The trusted peer device 72 and the verification server 28 may have network interfaces to 80. This allows for the collection and retrieval information. Information may be received in packets according to a packet protocol, such as the Internet Protocol. The payload of a message is described in bits and bytes within the packets of data. Each packet of data can have a header that contains routing information. This information may identify an origination address or destination address, and/or be associated with the verification server 28 or the trusted peer device 72.
“Exemplary embodiments can be applied to any file format and/or specification. Format 102 can be proprietary, open-source, unpublished, or free. Format 102 can be used for images, containers and audio/video, text, subtitles, control character, and other encoding schemes. Format 102 can be HTML, vector graphics or source code. It also includes text files, syntax and software programming.
“FIG. “FIG. 9 illustrates structured information 110. The electronic data 26 that represents the electronic document 20 could be structured data 110, as the reader will understand. The structured data 110 could be organized in any way you like. It may contain an entry 112 or a database field 114 within a relational spreadsheet116 or database118, or be contained within a fixed field 120 or data record 122, and/or be addressable via network or memory address 124. The structured data 110 can be organized using the JavaScript object notation (or?JSON?) again, referring to the electronic driver’s license 100. The JSON format is a well-known format for structuring data. JavaScript Object Notation can be used to do this. {Suffice it to say that at least some of the electronic data 26 representing the driver’s license 100 may be a JSON document 126 having the structured data 110 arranged as fields [It is possible that some electronic data 26 which represents the driver’s licence 100 could be a JSON file 126 with the structured data 110 organized as fields [?Name?]. :?Bob Smith? }, {?State? : ?TX? }, {?Birth? :?May 1, 1975?} . . . ]. {The driver’s license 100 may thus be formatted according to a JSON schema 128 and stored in an electronic database 130 (perhaps having other structured data 110, such as electronic database associations according to [Driver’s license 100 could be formatted using a JSON schema 128. It may then be stored in an electronic data 130. :?Drivers License?, ?properties? : {?Name? : ?type?:?string? . . . ].”
“FIGS. 10-11 illustrate metadata 140. Here the electronic data 26 representing the electronic document 20 (such as the driver’s license 100) may include the metadata 140 (such as [{?CreationTime?:?2012-05-07T11:12:32? }, {?SourceID? : ?1131122? }, {?Location? : ?Wells Fargo System XXX, ID YYY?} . . . ]. Exemplary embodiments could retrieve the metadata 140 and generate a corresponding digital signature 70 (such a the 256-bit hash value that represents the metadata 140). Exemplary embodiments could then include the digital signature 70 representing metadata 140 into the Blockchain 50 for distribution to trusted peer device 72. Two-fold verification may be performed by the trusted peer device 72. That is, any alteration to the driver’s license 100 may be determined (as this disclosure explains), but exemplary embodiments may also verify that the date 34 of creation (e.g., [?CreationTime?:?2012-05-07T11:12:32?] The date 34 of creation (e.g., [?CreationTime?:?2012-05-07T11:12:32]) has not been changed. If the digital signature 70 representing metadata 140 has changed in time (such as when comparing version 32 and the current version 60), then exemplary embodiments can flag or notify of fraud attempts. Audit trails may be used to track changes in the digital signature 70 as they occur in banking, mortgage processing and other activities.
“FIG. “FIG. 11 illustrates various types of the metadata 140. Although exemplary embodiments could haveh any type or combination of the metadata 140 described in this disclosure, it will focus on the most familiar metadata 140 to most readers. The metadata 140 could include the date 112 of its creation, title, author, location (such GPS information at creation), word/character counts, and an abstract summarizing or describing the electronic document 20. One or more keywords may be included in the metadata 140. The metadata 140 could also contain a file hierarchy containing the electronic document 20, and/or a network adress for retrieval. For example, the network address may be associated to a server, remote machine, or any other device that stores electronic document 20. Metadata 140 can also contain structural details such as file size and page numbering, chapter organization, image data, and chapter organization. Other metadata 140 could describe authorized users, such as administrator and user identities and digital rights management (or?DRM?). Any standard can be used to format the metadata 140.
“FIG. Instructions 150 are illustrated in FIG. 12. The instructions 150 may be included in the electronic data 26 that represents the driver’s licence 100. Although exemplary embodiments can be applied to any instructions, they may also be structured (such executable code) or unstructured (such nonexecutable commentary lines within code such as English language “do something 1, then thing 2 then thing 3?” Other instructions 150 may include any messages (such as ?When this document is accessed, POST to the URL http://some.target.url?). Exemplary embodiments could retrieve the instructions 150 and generate the digital signature 70 (such the 256-bit hash value corresponding to the instructions 150), which they then incorporate into the blockchain 50. Exemplary embodiments can also flag or notify fraud attempts if the digital signature 70 representing instructions 150 has been altered over time.
“FIG. “FIG. 13 illustrates multiple digital Signatures 160, according exemplary embodiments. Exemplary embodiments can generate multiple digital signatures 160 because the electronic document 20 could contain or include multiple types of electronic data 26. Exemplary embodiments may, for instance, generate a first digital signing 70 a (such a 256-bit hash value using SHA-256 hashing algorithms 40) based upon the data version 132 associated to the electronic document 20 (as explained above with reference to FIGS. 8-9). Exemplary embodiments could generate a second digital sign 70 b using the metadata 140 found within or associated with the electronic document 20 (as explained above with reference to FIGS. 10-11). Exemplary embodiments could generate a third digital sign 70 c based upon the instructions 150 within or associated with the electronic document 20 (as explained above with reference to FIG. 12). Based on electronic data 26, which represents the electronic document 20, any or all of the multiple digital signings 160 can be generated.
“FIG. “FIG. 14 illustrates the blockchain 50 according to exemplary embodiments. Exemplary embodiments can incorporate any one or more digital signatures 160 into their blockchain 50 once they have generated any of the multiple signatures 160. Any one or more digital signatures 160 can be added, stored in, or integrated into any record, transaction or block within the Blockchain 50. FIG. FIG. 14. This illustrates the blockchain 50, which includes the first digital signature 70a (based upon the data version 132), the second digital signature 70b (based onto the metadata 140) and the third digital signature 70c (based upon the instructions 150). For verification purposes, the verification server 28 can then broadcast or distribute the blockchain 50 to trusted peer devices 72.
“FIG. “FIG. 15 illustrates multiple verifications according to exemplary embodiments. After any of the multiple signatures 160 (e.g. 70 a, 70b, or 70c) have been received (perhaps via blockchain 50), the trusted peers device 72 can then use one or more of multiple digital signatures 160 in order to verify the authenticity 22 for the electronic document 20. For example, the peer-side verification algorithm (92) may cause trusted peer device 72 generate a first verification electronic signature (?1st DDS?) 74a by hashing data version 132 that is associated with the current 60. The peer-side authentication algorithm 92 can also cause trusted peer devices 72 to generate a second digital signature (?2nd D?) 74 b by hashing metadata 140 that is associated with the current version 60. The peer-side authentication algorithm 92 can also cause trusted peer devices 72 to generate a third digital signature (?3rdVDS?) 74 b is generated by hashing the metadata 140 that is associated with the current 60. The peer-side verification algorithm (92) may determine or infer that the current version 60 has not been altered or authenticated if any of the verification digital signs 74a, 74b, or 74c satisfactorily matches their respective digital signatures 70a, 70b, or 70c. The peer-side verification algorithm may determine that the current version 60 has been altered or inauthentic if one or more verification digital signatures (74a,74b, and/or74c) fails to match their respective digital signatures 70a, 70b, and/or70c. To implement additional security measures, the peer-side verification algorithm may generate the fraud alert 64.
“FIGS. 16-17 are flowcharts that illustrate a method for authentication according to exemplary embodiments. The electronic data 26, which represents the original 32-bit electronic document 20, is retrieved (Block 202), and hashed with the hashing algorithm 40. (Block 202). A number of digital signatures 160 are generated (Block 204), and incorporated into the Blockchain 50 (Block 206). The internet is used to distribute the blockchain 50 (Block 208). Any recipient can receive the blockchain 50 (such as the trusted peer device 72), (Block 201). Any of the multiple digital signatures 160 can be used to verify the current version 60 (Block 212). Based on the current version 60 (Block 212), the multiple verification digital signatures of 74, 74, and/or 75 c were generated.
“The flowchart continues to FIG. 17. Multiple verification digital signatures 74a, 74b and/or 74c can be compared with multiple digital signatures 160 that were incorporated into Block 218, which are also compared. The total number of matches is added (Block 218) and then compared to a verification threshold. (Block 222). The current version 60 will be authenticated (Block 226) if the number of matches exceeds or equals the verification threshold (Block 220). If the verification threshold is not met, then the current version 60 will be authenticated (Block 226). Otherwise fraud alert 64 will be generated (Block 238).
“FIG. “FIG. The fraud alert 64 is generated by the verification server 28 or the trusted peer device 72. The fraud alert 64 can have many mechanisms and structures, but FIG. FIG. 17 shows a simple notification example. An electronic message 240 is used to send the fraud alert 64 to one or more notification addresses 242. The electronic message 240 is routed via the communications network 80 towards a network address (e.g. IP address) associated to a destination device 244. The electronic message 240 contains data or information that describes an inauthenticity of current version 60 of electronic document 20. It is based on one of the non-matching signatures 70.
“FIG. “FIG. FIG. FIG. 19 shows a more detailed diagram of a 250-processor-controlled device. As explained in previous paragraphs, the verification algorithm (86) and the peer-side verification method (92) may operate in any mobile processor-controlled device. FIG. FIG. 19 shows the verification algorithm (86) and peer-side verification algorithms (92), which are stored in the memory subsystem of the processor controlled device 250. One or more processors can communicate with the memory subsystem to execute any, all, or some applications. The processor-controlled device 250 is well-known to anyone with ordinary skill in the arts. No further explanation is required.
“FIG. FIG. 20 illustrates additional operating environments that may be used to demonstrate the exemplary embodiments. FIG. FIG. 20 shows the verification algorithm (86) and peer-side verification algorithm (92), as they operate within other processor-controlled devices 250. FIG. FIG. 20 illustrates, for example that the verification algorithm (86) and the peer-side validation algorithm (92) may operate entirely or partially within a set top box (?STB?) (252), a personal/digital camera (PVR/DVR 254), a Global Positioning System device (GPS) 256, an interactive TV 258, a tablet computer (260), or any other computer system, communications device or processor-controlled device that uses any of the above-described processors and/or a Digital Signal Processor (DP/DSP 262). The processor-controlled device 250 could also include wearable devices such as watches, radios, vehicle electronics and clocks. It may also include printers, gateways and mobile/implantable medical equipment. The architecture and operating principles for the various devices 250 have been well documented. Therefore, we are not going to show and describe the hardware and software components of the devices 250.
“Exemplary embodiments can be physically encoded on or within a computer-readable storage media. For example, this computer-readable medium could include CD-ROM or DVD, tape, cassettes, floppy disc, optical disks, memory cards, large-capacity drives, memory cards, and floppy disks. This computer-readable media or medium could be distributed to assignees, licensees, end-subscribers and licensees. As explained in the previous paragraphs, a computer program product is a set of processor-executable instructions that verify electronic documents’ authenticity.
“While the exemplary embodiments were described in terms of various features, aspects and embodiments, both skilled and unskilled art practitioners will be able to recognize that the exemplary embodiments do not limit themselves. You can make other variations, modifications and alternate embodiments without departing from what is intended.
Summary for “Validating documents using blockchain”
Online, authenticity is essential. Electronic documents can be easily shared, especially through private and public networks (such the Internet). It is easy to alter electronic documents for fraudulent purposes.
“BRIEF DESCRIPTION ABOUT THE VIEWS FROM THE DRAWINGS”
“The features, aspects and benefits of the exemplary embodiments can be understood by reading the following detailed description with reference to the accompanying illustrations.
“FIGS. “FIGS.1-3” are simplified examples of validating electronic documents according to exemplary embodiments.
“FIGS. “FIGS.
“FIGS. 8-12 illustrate further verification, according to exemplary embodiments.
“FIG. “FIG.
“FIG. “FIG.
“FIG. “FIG.
“FIGS. “FIGS.
“FIG. “FIG.
“FIGS. 19-20 show additional operating environments that allow for further aspects of the exemplary embodiments.
“The accompanying drawings will be used to describe the exemplary embodiments more fully. However, the exemplary embodiments can be implemented in many other forms, and should not be considered limited to those described herein. These embodiments have been provided to ensure that the disclosure is complete and comprehensive and that the exemplary embodiments are fully communicated to all who are skilled in the art. Furthermore, the embodiments cited herein, along with specific examples, are meant to include both functional and structural equivalents. It is also intended that these equivalents include both current equivalents and future equivalents (i.e. any elements that perform the same function regardless of their structure).
“The diagrams, schematics and illustrations are conceptual views or processes that illustrate the exemplary embodiments. This is what ordinary skill in art will appreciate. You can achieve the functions of the different elements in the figures by using dedicated hardware or hardware that can execute associated software. People of ordinary skill in art also understand that the illustrative hardware, software, processes and/or operating system described herein are intended to be used as a guide only and are not meant to be restricted to any manufacturer.
“As used herein the singular forms?a? ?an,? ?an,? Unless otherwise stated, the plural forms of?the? and?includes? are meant to be used together. Further, it will be understood that the terms “includes”,? ?comprises,? ?including,? and/or ?comprising,? When used in this specification, they indicate the presence of the stated features, integers and steps, operations, element and/or component. However, it does not preclude the addition or presence of other features, integers and steps, operations and elements and/or parts. It is understood that an element can be referred to as being “connected” or “coupled”. It is possible to refer to an element as being?connected? It can be connected to or coupled with another element. Interfering elements may also be present. Furthermore, ?connected? Also,?connected? oder?coupled? can be used. Wirelessly connected and coupled may also be used as an expression herein. The term “and/or” as used herein may also be called wirelessly connected or coupled. The term?and/or? refers to any combination of one or more of these listed items.
“It is also understood that the terms first, third, and so on are not exclusive to one element. These terms may be used to describe different elements. However, they should not be limited. These terms can only be used to differentiate one element from the other. A first device might be called a second, while a second could be called a first. This is consistent with the disclosure’s teachings.
“FIGS. “FIGS.1-3” are simplified examples of validating electronic document 20 according to exemplary embodiments. These examples verify that the electronic document 20 was not altered since its creation. An authenticity 22 of an electronic document 20 is important for banking, security, identification and other online activities. The electronic document 20 may have been altered since its creation. This could lead to banking and other online activities being compromised. An altered version 24 may be a sign that malicious or fraudulent activity has been attempted. One example of a security plan that uses electronic data 26 to represent the electronic document 20 is a security scheme.
“FIG. “FIG. The verification server 28 checks whether the electronic document 20 was modified since its creation 30. The verification server 28 retrieves electronic data 26, which is the original version 32 of electronic document 20. This disclosure mainly explains the original 32 version as it was created on a date of 34. However, the original version 32 may be delineated with reference to any date, time or version. The verification server 28 can generate one or more hash value 36 associated with a haveh tree 38 based upon the electronic data 26 that represents the original version 32. An electronic representation of the hashing algorithm 40 may be used to generate the hash tree 38. One or more of 36 hash values may be distributed by the verification server 28 via a blockchain 50. Any of the 36 hash values (e.g. hash list, hash chains, branches, nodal Leaves) can be added to, stored or incorporated into any record, transaction or block that is distributed via the blockchain 50. The blockchain 50 can be sent to or routed to any destination (e.g., an Internet Protocol address associated for another server), FIG. 1 illustrates peer distribution. The verification server 28 could broadcast the blockchain 50 from the IP addresses of a network 52 that includes peer devices or nodes. Exemplary embodiments could use the blockchain 50 to distribute or publish information. The blockchain 50 is a digital ledger that records transactions chronologically and/or publicly. Most commonly, the blockchain 50 is used for decentralized cryptocurrency (such as Bitcoin). However, the blockchain 50 can be used in any custody or chain (such as medical records and title chains in real estate transactions). There are many configurations and mechanisms for the blockchain 50. Exemplary embodiments can be modified to fit any version. Peer-to-peer Blockchain technology is well-known, so this disclosure does not need to provide an in-depth explanation.
“FIG. “FIG. The verification server 28 checks whether the current version 60 has changed from the original electronic document 20’s creation date. The verification server 28 checks whether the current version 60 is different from the original 32. The verification server 28 retrieves electronic information 61 that represents the current version 60 from the electronic document 20. Based on the electronic data 61, the verification server 28 can generate one or more verification haveh values 62. The electronic representation of the hashing algorithms 40 is used to generate the verification hash value 62. The verification server 28 can then compare the verification values 62 with the hash value 36 that represent the original 32 version (as at the date 34 of its creation). The verification server 28 can infer that the current version 60 corresponds to the original 32 version by comparing the verification hash value 62 with the hash value 36. The verification server 28 can infer, however, that the current version 60 is different from the original 32 version if the verification hash value 62 fails to meet the 36 hash values. In other words, the current electronic document 20 version 60 has been modified since its creation date of 34. To implement additional security measures, the verification server 28 could generate a fraud alert 64.
“Exemplary embodiments might detect minor changes. Even subtle changes in electronic document 20 can make the hashing algorithm 40 very sensitive. There are many algorithms for hashing, and some embodiments can use any of them. This disclosure will focus on the SHA family cryptographic hashing algorithm, as many readers are familiar with it. If the SHA-256 algorithm was applied to electronic data 26, representing the original 32-bit version, the result would be a 256-bit digital signing. It is extremely unlikely that two sources of data will produce the same digital signature. If the current electronic document 60 has any subtle changes (such as one character in a textual word or number), the corresponding digital signature (e.g. the verification hash value 62) will not match the original 32 hash values. Exemplary embodiments can quickly tell if the electronic document 20 was modified since its creation date of 34.
“FIG. 3 illustrates nodal verification. Exemplary embodiments can distribute one or more hash values 36 via blockchain 50. The verification server 28 can generate the hash value 36 based on the electronic data 26, which represents the original 32-bit electronic document 20, and then the verification server 28, may distribute the 36 hash values via the blockchain 50. The verification server 28 could include the 256-bit digital sign 70 (generated using the SHA256 algorithm) in the blockchain 50. Any member of the trusted network 52 of peer devices can then verify the current version 60. For example, a trusted peer device 72 may obtain the blockchain 50 and retrieve the digital signature 70. Trusted peer 72 can then retrieve the electronic data 71 corresponding to the current version 60, and generate verification hash value 62 (such a 256-bit digital signature 74). The trusted peer 72 may then compare 36 hash values (received via blockchain 50) with the verification hash value 62 generated based upon the electronic document 20, version 60. The trusted peer device 72 could compare the 256 bit digital signature 70 (based upon the original 32-bit version) with the 256 bit verification digital signature 75 (based on current version 60). The trusted peer device 72 can infer that the current version 60 has been authenticated and not altered if the 36 verification hash value (e.g., a 256 bit verification digital signature 75) is compared to 36 hash values (e.g., the 256 bit digital signature 70) received over the blockchain 50. The trusted peer device 72 could infer or determine that the current version 60 has been altered and inauthentic if the 36 verification hash value (e.g. the 256 bit verification digital signature 74), fails to meet the 36 hash values (e.g. the 256 bit digital signature 70). To implement additional security measures, the trusted peer device 72 could generate the fraud alert 64.
“FIGS. “FIGS.4” 4-7 are detailed examples of an operating environment according to exemplary embodiments. FIG. FIG. 4 shows the verification server 28 communicating via a communications network 80 or wireless network 82 with the trusted peer device 72. FIG. FIG. As we will see, the trusted peer device 72 could be any processor-controlled device. The verification server 28 could have a processor (e.g., “??P?”). A processor 86 (e.g.,??P?), an application specific integrated circuit or another component that executes the verification algorithm 86 stored on a local memory device. 88. The verification algorithm (86) includes instructions, code and/or program that causes the verification server 28 perform operations such as creating the hash values 36 for the electronic document 20 (as described in the previous paragraphs). The verification algorithm may generate the digital signature 70 that represents the original 32-bit version (using the hashing algorithms 40). The verification algorithm 28 may instruct the verification server 28 or cause it to incorporate the digital signature 70 into a blockchain 50 for distribution on the mobile phone 84. Exemplary embodiments may, however, send the digital signature 70 or the blockchain 50 to any IP address associated any device or network destination.
“FIG. “FIG.5” illustrates peer verification. The blockchain 50 has been distributed. Now, the trusted peer 72 (again illustrated by the mobile phone 84) can determine the authenticity 22. FIG. FIG. 5 shows the mobile phone 84 that has received the blockchain 50 and digital signature 70. The processor 90 is an application-specific integrated circuit (ASIC) or another component that executes the peer-side verification algorithm. It’s stored in a local storage device 94. Peer-side verification algorithm (92) includes instructions, code and/or programmes that cause the processor to perform operations such as verifying version 60 of electronic document 20. Peer-side verification algorithm (92) causes the mobile phone 84 to retrieve electronic data 71 that represents the current version 60, and generate the verification digital signature74 (such as the corresponding hash of 256 bits). The peer-side verification algorithm (92) may determine or infer that the current version 60 has not been altered or authenticated if the verification digital signatures 74 and 70 compare satisfactorily. The peer-side verification algorithm (92) may determine that the current version 60 has been altered or inauthentic if the verification signature 74 does not match the digital signature 70 obtained via the blockchain 50. To implement additional security measures, the peer-side verification algorithm may generate the fraud alert 64.
“FIG. 6 illustrates servile verification. The verification server 28 can determine whether the electronic document 20’s authenticity 22 is genuine. The verification server 28 can notify or alert of security concerns if it receives the current electronic document 20 version 60. The verification algorithm 86 triggers the verification server to obtain the current version 60, and generate the appropriate verification digital signature 74. The verification algorithm 86 can infer that the current version 60 has been authenticated and not altered if the verification digital signature 74.1 is able to match the digital signature 70. If the verification digital signature of 74 does not satisfy the digital signature 70 (representing version 32), the verification algorithm 64 may apply the fraud alert 64 to determine if the current version 60 has been altered or inauthentic.
“FIG. The general verification scheme is illustrated in FIG. 7. The SHA256 hashing algorithm is well-known to many. Therefore, the general verification scheme could use the 256-bit hash value calculated by the SHA256 algorithm. Exemplary embodiments retrieve or obtain the electronic data 26, which is the original 32-bit version of the electronic document 20. The SHA256 hashing algorithm is used to create a 256-bit digital signature 70. Exemplary embodiments can also retrieve or obtain the electronic data 71, which represents the current version 60. The SHA256 hashing algorithm uses the electronic data 71 to generate a corresponding 256 bit hash value for the verification digital signature 74. Exemplary embodiments can infer that the current version 60 has been authenticated and not altered if a match is found. If the digital signatures 70 or 74 do not match, exemplary embodiments could infer that the current 60 version is fake and issue the fraud alert 64.
“Exemplary embodiments can use any type of processing component, configuration, and system. Multiple processors could be used, including distributed processors and parallel processors on a single machine. A virtual processing environment can be supported by the processor. A state machine, an application specific integrated circuit, (ASIC), programmable gates array (PGA) and a state machine could all be part of the processor. Any of the processors can execute instructions to perform “operations”. This could be the processor directly performing the operation or facilitating, directing or cooperating with another component or device to do the operation.
“Exemplary embodiments can packetize. The trusted peer device 72 and the verification server 28 may have network interfaces to 80. This allows for the collection and retrieval information. Information may be received in packets according to a packet protocol, such as the Internet Protocol. The payload of a message is described in bits and bytes within the packets of data. Each packet of data can have a header that contains routing information. This information may identify an origination address or destination address, and/or be associated with the verification server 28 or the trusted peer device 72.
“Exemplary embodiments can be applied to any file format and/or specification. Format 102 can be proprietary, open-source, unpublished, or free. Format 102 can be used for images, containers and audio/video, text, subtitles, control character, and other encoding schemes. Format 102 can be HTML, vector graphics or source code. It also includes text files, syntax and software programming.
“FIG. “FIG. 9 illustrates structured information 110. The electronic data 26 that represents the electronic document 20 could be structured data 110, as the reader will understand. The structured data 110 could be organized in any way you like. It may contain an entry 112 or a database field 114 within a relational spreadsheet116 or database118, or be contained within a fixed field 120 or data record 122, and/or be addressable via network or memory address 124. The structured data 110 can be organized using the JavaScript object notation (or?JSON?) again, referring to the electronic driver’s license 100. The JSON format is a well-known format for structuring data. JavaScript Object Notation can be used to do this. {Suffice it to say that at least some of the electronic data 26 representing the driver’s license 100 may be a JSON document 126 having the structured data 110 arranged as fields [It is possible that some electronic data 26 which represents the driver’s licence 100 could be a JSON file 126 with the structured data 110 organized as fields [?Name?]. :?Bob Smith? }, {?State? : ?TX? }, {?Birth? :?May 1, 1975?} . . . ]. {The driver’s license 100 may thus be formatted according to a JSON schema 128 and stored in an electronic database 130 (perhaps having other structured data 110, such as electronic database associations according to [Driver’s license 100 could be formatted using a JSON schema 128. It may then be stored in an electronic data 130. :?Drivers License?, ?properties? : {?Name? : ?type?:?string? . . . ].”
“FIGS. 10-11 illustrate metadata 140. Here the electronic data 26 representing the electronic document 20 (such as the driver’s license 100) may include the metadata 140 (such as [{?CreationTime?:?2012-05-07T11:12:32? }, {?SourceID? : ?1131122? }, {?Location? : ?Wells Fargo System XXX, ID YYY?} . . . ]. Exemplary embodiments could retrieve the metadata 140 and generate a corresponding digital signature 70 (such a the 256-bit hash value that represents the metadata 140). Exemplary embodiments could then include the digital signature 70 representing metadata 140 into the Blockchain 50 for distribution to trusted peer device 72. Two-fold verification may be performed by the trusted peer device 72. That is, any alteration to the driver’s license 100 may be determined (as this disclosure explains), but exemplary embodiments may also verify that the date 34 of creation (e.g., [?CreationTime?:?2012-05-07T11:12:32?] The date 34 of creation (e.g., [?CreationTime?:?2012-05-07T11:12:32]) has not been changed. If the digital signature 70 representing metadata 140 has changed in time (such as when comparing version 32 and the current version 60), then exemplary embodiments can flag or notify of fraud attempts. Audit trails may be used to track changes in the digital signature 70 as they occur in banking, mortgage processing and other activities.
“FIG. “FIG. 11 illustrates various types of the metadata 140. Although exemplary embodiments could haveh any type or combination of the metadata 140 described in this disclosure, it will focus on the most familiar metadata 140 to most readers. The metadata 140 could include the date 112 of its creation, title, author, location (such GPS information at creation), word/character counts, and an abstract summarizing or describing the electronic document 20. One or more keywords may be included in the metadata 140. The metadata 140 could also contain a file hierarchy containing the electronic document 20, and/or a network adress for retrieval. For example, the network address may be associated to a server, remote machine, or any other device that stores electronic document 20. Metadata 140 can also contain structural details such as file size and page numbering, chapter organization, image data, and chapter organization. Other metadata 140 could describe authorized users, such as administrator and user identities and digital rights management (or?DRM?). Any standard can be used to format the metadata 140.
“FIG. Instructions 150 are illustrated in FIG. 12. The instructions 150 may be included in the electronic data 26 that represents the driver’s licence 100. Although exemplary embodiments can be applied to any instructions, they may also be structured (such executable code) or unstructured (such nonexecutable commentary lines within code such as English language “do something 1, then thing 2 then thing 3?” Other instructions 150 may include any messages (such as ?When this document is accessed, POST to the URL http://some.target.url?). Exemplary embodiments could retrieve the instructions 150 and generate the digital signature 70 (such the 256-bit hash value corresponding to the instructions 150), which they then incorporate into the blockchain 50. Exemplary embodiments can also flag or notify fraud attempts if the digital signature 70 representing instructions 150 has been altered over time.
“FIG. “FIG. 13 illustrates multiple digital Signatures 160, according exemplary embodiments. Exemplary embodiments can generate multiple digital signatures 160 because the electronic document 20 could contain or include multiple types of electronic data 26. Exemplary embodiments may, for instance, generate a first digital signing 70 a (such a 256-bit hash value using SHA-256 hashing algorithms 40) based upon the data version 132 associated to the electronic document 20 (as explained above with reference to FIGS. 8-9). Exemplary embodiments could generate a second digital sign 70 b using the metadata 140 found within or associated with the electronic document 20 (as explained above with reference to FIGS. 10-11). Exemplary embodiments could generate a third digital sign 70 c based upon the instructions 150 within or associated with the electronic document 20 (as explained above with reference to FIG. 12). Based on electronic data 26, which represents the electronic document 20, any or all of the multiple digital signings 160 can be generated.
“FIG. “FIG. 14 illustrates the blockchain 50 according to exemplary embodiments. Exemplary embodiments can incorporate any one or more digital signatures 160 into their blockchain 50 once they have generated any of the multiple signatures 160. Any one or more digital signatures 160 can be added, stored in, or integrated into any record, transaction or block within the Blockchain 50. FIG. FIG. 14. This illustrates the blockchain 50, which includes the first digital signature 70a (based upon the data version 132), the second digital signature 70b (based onto the metadata 140) and the third digital signature 70c (based upon the instructions 150). For verification purposes, the verification server 28 can then broadcast or distribute the blockchain 50 to trusted peer devices 72.
“FIG. “FIG. 15 illustrates multiple verifications according to exemplary embodiments. After any of the multiple signatures 160 (e.g. 70 a, 70b, or 70c) have been received (perhaps via blockchain 50), the trusted peers device 72 can then use one or more of multiple digital signatures 160 in order to verify the authenticity 22 for the electronic document 20. For example, the peer-side verification algorithm (92) may cause trusted peer device 72 generate a first verification electronic signature (?1st DDS?) 74a by hashing data version 132 that is associated with the current 60. The peer-side authentication algorithm 92 can also cause trusted peer devices 72 to generate a second digital signature (?2nd D?) 74 b by hashing metadata 140 that is associated with the current version 60. The peer-side authentication algorithm 92 can also cause trusted peer devices 72 to generate a third digital signature (?3rdVDS?) 74 b is generated by hashing the metadata 140 that is associated with the current 60. The peer-side verification algorithm (92) may determine or infer that the current version 60 has not been altered or authenticated if any of the verification digital signs 74a, 74b, or 74c satisfactorily matches their respective digital signatures 70a, 70b, or 70c. The peer-side verification algorithm may determine that the current version 60 has been altered or inauthentic if one or more verification digital signatures (74a,74b, and/or74c) fails to match their respective digital signatures 70a, 70b, and/or70c. To implement additional security measures, the peer-side verification algorithm may generate the fraud alert 64.
“FIGS. 16-17 are flowcharts that illustrate a method for authentication according to exemplary embodiments. The electronic data 26, which represents the original 32-bit electronic document 20, is retrieved (Block 202), and hashed with the hashing algorithm 40. (Block 202). A number of digital signatures 160 are generated (Block 204), and incorporated into the Blockchain 50 (Block 206). The internet is used to distribute the blockchain 50 (Block 208). Any recipient can receive the blockchain 50 (such as the trusted peer device 72), (Block 201). Any of the multiple digital signatures 160 can be used to verify the current version 60 (Block 212). Based on the current version 60 (Block 212), the multiple verification digital signatures of 74, 74, and/or 75 c were generated.
“The flowchart continues to FIG. 17. Multiple verification digital signatures 74a, 74b and/or 74c can be compared with multiple digital signatures 160 that were incorporated into Block 218, which are also compared. The total number of matches is added (Block 218) and then compared to a verification threshold. (Block 222). The current version 60 will be authenticated (Block 226) if the number of matches exceeds or equals the verification threshold (Block 220). If the verification threshold is not met, then the current version 60 will be authenticated (Block 226). Otherwise fraud alert 64 will be generated (Block 238).
“FIG. “FIG. The fraud alert 64 is generated by the verification server 28 or the trusted peer device 72. The fraud alert 64 can have many mechanisms and structures, but FIG. FIG. 17 shows a simple notification example. An electronic message 240 is used to send the fraud alert 64 to one or more notification addresses 242. The electronic message 240 is routed via the communications network 80 towards a network address (e.g. IP address) associated to a destination device 244. The electronic message 240 contains data or information that describes an inauthenticity of current version 60 of electronic document 20. It is based on one of the non-matching signatures 70.
“FIG. “FIG. FIG. FIG. 19 shows a more detailed diagram of a 250-processor-controlled device. As explained in previous paragraphs, the verification algorithm (86) and the peer-side verification method (92) may operate in any mobile processor-controlled device. FIG. FIG. 19 shows the verification algorithm (86) and peer-side verification algorithms (92), which are stored in the memory subsystem of the processor controlled device 250. One or more processors can communicate with the memory subsystem to execute any, all, or some applications. The processor-controlled device 250 is well-known to anyone with ordinary skill in the arts. No further explanation is required.
“FIG. FIG. 20 illustrates additional operating environments that may be used to demonstrate the exemplary embodiments. FIG. FIG. 20 shows the verification algorithm (86) and peer-side verification algorithm (92), as they operate within other processor-controlled devices 250. FIG. FIG. 20 illustrates, for example that the verification algorithm (86) and the peer-side validation algorithm (92) may operate entirely or partially within a set top box (?STB?) (252), a personal/digital camera (PVR/DVR 254), a Global Positioning System device (GPS) 256, an interactive TV 258, a tablet computer (260), or any other computer system, communications device or processor-controlled device that uses any of the above-described processors and/or a Digital Signal Processor (DP/DSP 262). The processor-controlled device 250 could also include wearable devices such as watches, radios, vehicle electronics and clocks. It may also include printers, gateways and mobile/implantable medical equipment. The architecture and operating principles for the various devices 250 have been well documented. Therefore, we are not going to show and describe the hardware and software components of the devices 250.
“Exemplary embodiments can be physically encoded on or within a computer-readable storage media. For example, this computer-readable medium could include CD-ROM or DVD, tape, cassettes, floppy disc, optical disks, memory cards, large-capacity drives, memory cards, and floppy disks. This computer-readable media or medium could be distributed to assignees, licensees, end-subscribers and licensees. As explained in the previous paragraphs, a computer program product is a set of processor-executable instructions that verify electronic documents’ authenticity.
“While the exemplary embodiments were described in terms of various features, aspects and embodiments, both skilled and unskilled art practitioners will be able to recognize that the exemplary embodiments do not limit themselves. You can make other variations, modifications and alternate embodiments without departing from what is intended.
Click here to view the patent on Google Patents.