Auditing of electronic documents

Abstract

Auditing of mortgage documents is faster and simpler. An electronic mortgage application often contains or references a collection of many separate electronic mortgage documents. Electronic data representing an original version of an electronic mortgage document and its current version may be hashed to generate digital signatures. Any auditor may then quickly compare the digital signatures. If the digital signatures match, then the audit reveals that the electronic mortgage document has not changed since its creation. However, if the digital signatures do not match, then the electronic mortgage document has changed since its creation. The auditor may thus flag the electronic mortgage document for additional auditing processes.

Description

BACKGROUND

The mortgage industry has learned from the past. The so-called mortgage crisis of 2007 exposed flaws in the mortgage industry. Many mortgages lacked sufficient documentation, checks and balances were not implemented, and fraud was alleged.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

The features, aspects, and advantages of the exemplary embodiments are understood when the following Detailed Description is read with reference to the accompanying drawings, wherein:

FIGS. 1-7 are simplified illustrations of auditing mortgage documents, according to exemplary embodiments;

FIGS. 8-9 are detailed illustration of an operating environment, according to exemplary embodiments;

FIGS. 10-14 illustrate an audit file, according to exemplary embodiments;

FIG. 15 illustrates an index, according to exemplary embodiments;

FIGS. 16-18 illustrate sourcing, according to exemplary embodiments;

FIG. 19 illustrates document retrieval, according to exemplary embodiments;

FIG. 20 illustrates publication of the audit file, according to exemplary embodiments;

FIGS. 21-22 illustrate secret sharing of the audit file, according to exemplary embodiments;

FIGS. 23-24 illustrate a sharing strategy, according to exemplary embodiments;

FIG. 25 is a flowchart illustrating a method or algorithm for auditing the mortgage documents, according to exemplary embodiments; and

FIGS. 26-27 depict still more operating environments for additional aspects of the exemplary embodiments.

DETAILED DESCRIPTION

The exemplary embodiments will now be described more fully hereinafter with reference to the accompanying drawings. The exemplary embodiments may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. These embodiments are provided so that this disclosure will be thorough and complete and will fully convey the exemplary embodiments to those of ordinary skill in the art. Moreover, all statements herein reciting embodiments, as well as specific examples thereof, are intended to encompass both structural and functional equivalents thereof. Additionally, it is intended that such equivalents include both currently known equivalents as well as equivalents developed in the future (i.e., any elements developed that perform the same function, regardless of structure).

Thus, for example, it will be appreciated by those of ordinary skill in the art that the diagrams, schematics, illustrations, and the like represent conceptual views or processes illustrating the exemplary embodiments. The functions of the various elements shown in the figures may be provided through the use of dedicated hardware as well as hardware capable of executing associated software. Those of ordinary skill in the art further understand that the exemplary hardware, software, processes, methods, and/or operating systems described herein are for illustrative purposes and, thus, are not intended to be limited to any particular named manufacturer.

As used herein, the singular forms “a,” “an,” and “the” are intended to include the plural forms as well, unless expressly stated otherwise. It will be further understood that the terms “includes,” “comprises,” “including,” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. It will be understood that when an element is referred to as being “connected” or “coupled” to another element, it can be directly connected or coupled to the other element or intervening elements may be present. Furthermore, “connected” or “coupled” as used herein may include wirelessly connected or coupled. As used herein, the term “and/or” includes any and all combinations of one or more of the associated listed items.

It will also be understood that, although the terms first, second, etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first device could be termed a second device, and, similarly, a second device could be termed a first device without departing from the teachings of the disclosure.

FIGS. 1-7 are simplified illustrations of auditing mortgage documents, according to exemplary embodiments. FIG. 1 illustrates a server 20 storing electronic data 22 representing one or more electronic mortgage documents 24. The electronic mortgage documents 24 may be a part or a component of one or more loan applications 26. Indeed, many readers are likely familiar with an electronic mortgage application 28 that is processed when financing a mortgage for a home or business property. The electronic data 22, however, may be associated with any other type of loan, such as a vehicle installment, business or equipment purchase, and even equity lines of credit. Whatever the electronic data 22, the server 20 may retrieve the electronic data 22 representing an original version 30 of the electronic mortgage documents 24 at their date and time of creation 32. The server 20 may then hash the original version 30 of the electronic mortgage documents 24 using a cryptographic hashing algorithm 34. This disclosure defines a cryptographic “audit key” 36 as the hash value(s) 38 generated from hashing the original version 30 of the electronic mortgage documents 24. Exemplary embodiments may generate a single audit key 36 or multiple audit keys 36, as later paragraphs will explain.

FIG. 1 also illustrates an auditor 40. As the reader understands, financial records are often sampled and evaluated for correctness and for even fraud. The auditor 40 may thus randomly or periodically request an audit 42 of the electronic mortgage documents 24. When the auditor 40 requests the audit 42, the server 20 generates one or more audit files 44. That is, the server 20 may retrieve the cryptographic audit key(s) 36 generated from hashing the original version 30 of the electronic mortgage documents 24. The server 20 packages or associates the cryptographic audit key(s) 36 to the audit file 44 and sends the audit file 44 via a communications network 46 to the auditor 40 for examination, verification, and/or compliance.

FIG. 2 illustrates an audit server 50. The audit server 50 operates on behalf of the auditor 40 (such as governmental entity or third party) to perform the audit 42. When the audit server 50 receives the audit file 44, the audit 42 may commence. For example, the audit server 50 may retrieve or receive the electronic data 22 representing a current version 52 of the electronic mortgage document 24. As the reader may understand, the current version 52 (perhaps as of a current date and time 54) may different, perhaps only slightly, from the original version 30 generated or saved approximately at the creation 32. Any difference between the original version 30 and the current version 52 may indicate an unintentional, or intentional, change to the electronic mortgage documents 24. Such a slight change is conventionally difficult to discern, especially by human inspection.

Exemplary embodiments, though, automate the audit 42. Exemplary embodiments compare the cryptographic audit key(s) 36 to the current version 52 of the electronic mortgage documents 24. That is, the audit server 50 may independently hash the electronic data 22 representing the current version 52 of the electronic mortgage documents 24 (using the same cryptographic hashing algorithm 34) to generate one or more verification hash values 56. If the verification hash values 56 match the cryptographic audit keys 36 sent via the audit file 44, then the electronic mortgage document 24 has not changed since the date and time of creation 32. That is, the current version 52 of the electronic mortgage documents 24 is the same as the original version 30, unaltered, and thus authentic 58. However, if the verification hash values 56 (generated from hashing the current version 52 of the electronic mortgage documents 24) fail to match the cryptographic audit keys 36 incorporated into the audit file 44, then the electronic mortgage documents 24 have changed since the date and time of creation 32. The audit file 44, in other words, reveals an alteration that may indicate the current version 52 is inauthentic 60. Exemplary embodiments may thus generate a flag 62 or other fraud alert 64 to initiate further investigation.

Exemplary embodiments thus present elegant auditing tools. Exemplary embodiments may provide the auditor 40 with both the cryptographic hash of the original version 30 and the raw electronic data 22 representing the current version 52. If the auditor 40 substantially or exactly matches the digital signatures (e.g., the verification hash values 56 and the cryptographic audit keys 36), then perhaps the audit 42 is complete and no further inquiry is required. But if the current version 52 has changed, the digital signatures will differ, perhaps even substantially. Indeed, even a change to a single character in a single word can produce a noticeable difference in hash values. So, if the digital signatures are different, the current version 52 of the electronic mortgage documents 24 may fail an authentication (e.g., the authentic 58 or inauthentic 60 determination). The auditor 40 may have thus discovered an altered/forged version of the electronic mortgage documents 24.

FIG. 3 further illustrates the audit file 44. Here the audit file 44 may include a subset 70 of the electronic mortgage documents 24 from a single electronic mortgage application 28. The reader likely understands that the electronic mortgage application 28 contains many different and separate documents. For example, the electronic mortgage application 28 may include an applicant's tax returns, employment verification, pay stubs, bank statements, and other documents. The electronic mortgage application 28 may also contain application paperwork (such as a Uniform Residential Loan Application), purchase agreement, appraisal, title history, and still many more documents. The audit file 44, though, may contain the electronic data 22 representing a sample of all the documents or pages representing the electronic mortgage application 28 associated with a single applicant 72. Suppose, for example, that the audit file 44 only contains the subset 70 representing the original version 30 of an IRS W-2 statement 74 associated with the single applicant 72 (e.g., name, address, and/or social security number). The server 20 sends the audit file 44 to the auditor 40 (e.g., the audit server 50) for examination and verification. When the audit server 50 receives the audit file 44, the audit server 50 performs the audit 42 of the subset 70 representing the IRS W-2 statement 74. That is, the audit server 50 may compare the cryptographic audit key 36 (generated from hashing the original version 30 of the IRS W-2 statement 74) to the current version 52 of the IRS W-2 statement 74. If the verification hash value(s) 56 (representing the current version 52 of the IRS W-2 statement 74) matches the cryptographic audit key 36 (generated from the original version 30 at the creation 32), then the applicant's IRS W-2 statement 74 is authentic 58 and perhaps no further auditing is required. However, if the verification hash value 56 fails to match the cryptographic audit key 36, then the applicant's IRS W-2 statement 74 has changed since the date and time of creation 32. Exemplary embodiments have thus discovered an alteration to the applicant's IRS W-2 statement 74. The current version 52 of the IRS W-2 statement 74 may thus be inauthentic 60, so exemplary embodiments may thus escalate the audit 42 and, perhaps, generate the fraud alert 64.

FIG. 4 also illustrates the audit file 44. Here, though, the audit file 44 may include a collection 80 of the electronic mortgage documents 24 from a set 82 of multiple electronic mortgage applications 28. The audit file 44 may thus contain the electronic data 22 representing a sampling of the electronic mortgage documents 24 associated with multiple and different applicants 84. While exemplary embodiments may sample any number of electronic mortgage applications 28, for simplicity FIG. 4 illustrates four (4) electronic mortgage applications 28a-d. Moreover, even though each applicant's electronic mortgage application 28a-d may contain hundreds of pages/forms, FIG. 4 for simplicity again illustrates the corresponding IRS W-2 statements 74a-d. That is, the audit file 44 may contain the collection 80 of the IRS W-2 statements 74a-d associated with each applicant's electronic mortgage application 28a-d. The server 20 sends the audit file 44 to the auditor 40 for examination and verification. If the audit server 50 matches any corresponding cryptographic audit key 36a-d (generated from hashing the original versions 30a-d) to the current version 52a-d of the IRS W-2 statements 74a-d, then the applicant's corresponding IRS W-2 statement 74a-d is unaltered and authentic 58. However, if the verification hash value 56a-d fails to match the cryptographic audit key 36a-d, then the corresponding applicant's IRS W-2 statement 74a-d has changed since its date and time of creation 32a-d. Exemplary embodiments may thus escalate the audit 42 and, perhaps, generate the fraud alert 64.

FIG. 5 illustrates sourcing data 90. Here the audit file 44 may include the sourcing data 90 associated with any of the electronic mortgage documents 24. The sourcing data 90 specifies from where the corresponding electronic mortgage document 24 may be obtained. That is, the sourcing data 90 specifies a network location, address, website, and/or other information associated with a networked device or server that physically stores the electronic mortgage document 24. The sourcing data 90 may be as simple or detailed as needed to ease access to the electronic mortgage document 24. The sourcing data 90, for example, may be defined as [{“Source”:{“Name”: “Wells Fargo System XXX”}, {“ID”:“YYY”}, {“Access Link”:“https://foo.wellsfargo.com”} . . . ] and textually written or encoded as metadata 92. The sourcing data 90 may thus specify one or more uniform resource locators (URLs) as website links from where the corresponding electronic mortgage document 24 (document identifier “ID”:YYY″) may be queried and retrieved. The sourcing data 90 may thus be populated by an originator or creator of the electronic mortgage document 24. The sourcing data 90 may also be populated by an owner of the electronic mortgage document 24 (such as lender or contractor). The sourcing data 90 may thus be added as the metadata 92 to the audit file 44. When the audit server 50 receives the audit file 44, the audit server 50 may thus read and/or retrieve the sourcing data 90 to retrieve the corresponding electronic mortgage document 24.

FIG. 6 illustrates a timing requirement. Here the audit file 44 may include data or information specifying an auditing interval 100 of time in which the audit 42 must be commenced and/or completed. The audit file 44 may thus cause the audit server 50 to call or invoke a timing mechanism (such as a timer 102) that begins counting up, or down, from an initial time 104 to a final time 106. If the auditing interval 100 of time expires prior to commencement or completion of the audit 42, exemplary embodiments may decline further access to, and/or read usage of, the audit file 44. The auditing interval 100 of time may thus be a time box or window that increments from a date/time of receipt 108, or at date/time of initial read access 110, by the audit server 50. The auditing interval 100 of time may additionally or alternatively increment at a date/time of sending 112 the audit file 44 from the server 20. The audit file 44 may have additional configuration options that further define the access or usage conditions related to the auditing interval 100 of time.

FIG. 7 illustrates audit records. Here exemplary embodiments may record the audit 42, and/or an audit result 110, as a record in a blockchain 112. As the reader may understand, the blockchain 112 is generally a digital ledger in which transactions are chronologically and/or publically recorded. The blockchain 112 is most commonly used in decentralized cryptocurrencies (such as Bitcoin). The blockchain 112, however, may be adapted to any chain or custody (such as the electronic mortgage document(s) 24 representing the electronic mortgage application(s) 28). Indeed, there are many different mechanisms and configurations of the blockchain 112, and exemplary embodiments may be adapted to any version. Regardless, the audit result 110 may be integrated into the blockchain 112 for distribution or publication to one or more trusted peer devices 114 (such as the audit server 50). As a simple example, if the IRS W-2 statement 74 is true and unaltered (as explained with reference to FIG. 3), the auditing result or determination may be added to, or incorporated in, any record, transaction, or block and distributed via the blockchain 112. However, if the current version 52 has been altered, the inauthentic 60 determination (and the fraud alert 64) may be recorded. Indeed, any details related to the audit 42 (such as a date of the audit 42 and an auditor identifier that uniquely identifies the auditor 40) may be integrated into the blockchain 112. The audit server 50 may also hash the audit result 110 (using the cryptographic hashing algorithm 34) to generate hash values representing a digital signature (such as an audit result key) that may also be integrated into the blockchain 112 for historical documentation.

Exemplary embodiments may be applied to any electronic document. Most readers are thought familiar with mortgage documents. This disclosure thus mainly explains auditing of mortgage documents. Exemplary embodiments, though, may be applied to auditing of any electronic data representing any document.

FIGS. 8-9 are detailed illustration of an operating environment, according to exemplary embodiments. FIG. 8 illustrates the server 20 communicating with the audit server 50 (via the communications network 46 illustrated in FIGS. 1 and 7). The server 20 may have a processor 120 (e.g., “μP”), application specific integrated circuit (ASIC), or other component that executes a server-side algorithm 122 stored in a local memory device 124. The server-side algorithm 122 includes instructions, code, and/or programs that cause the server 20 to perform operations, such as hashing the electronic data 22 representing the original version 30 of the electronic mortgage document 24 (using the hashing algorithm 34) to generate the audit key(s) 36 and the audit file 44 (as the above paragraphs explained). The server-side algorithm 122 may also instruct or cause the server 20 to send the audit file 44 to the audit server 50. The server-side algorithm 122 may also instruct or cause the server 20 to send the audit file 44 to any IP address associated with any network destination or device.

Exemplary embodiments may use any hashing function. Many readers may be familiar with the SHA-256 hashing algorithm that generates a 256-bit hash value. Exemplary embodiments obtain or retrieve the electronic data 22 representing the original version 30. The SHA-256 hashing algorithm acts on the electronic data 22 to generate a 256-bit hash value as the cryptographic audit key 36. The audit key 36 is thus a digital signature that uniquely represents the electronic data 22. There are many hashing algorithms, though, and exemplary embodiments may be adapted to any hashing algorithm.

FIG. 9 illustrates auditing instructions. When the auditor 40 wishes to perform the audit 42, the audit server 50 sends an audit request 126. The audit request 126 includes data or information that specifies a subject 128 of the audit 42. The subject 128 may be broadly or narrowly specified to ensnare a single document, a single mortgage application, multiple documents from the single mortgage application, the single document from multiple mortgage applications, or multiple documents from the multiple mortgage applications. In general, then, the audit request 126 may specify a document range identifying the document(s) to be audited and an applicant range identifying the applicant name(s) and/or mortgage application(s) to be audited. The audit server 50 may have a processor 130 (e.g., “μP”), application specific integrated circuit (ASIC), or other component that executes an audit-side algorithm 132 stored in a local memory device 134. The audit-side algorithm 1332 includes instructions, code, and/or programs that cause the audit server 50 to perform operations, such as generating the audit request 126 and sending the audit request 126 to the IP address associated with the server 20. The server 20 thus generates the audit file 44 as a response to the audit request 126. The server 20 and the audit server 50 may thus cooperate to perform the audit 42 of the electronic mortgage documents 24 based on the audit file 44.

Exemplary embodiments may be applied regardless of networking environment. Exemplary embodiments may be easily adapted to stationary or mobile devices having cellular, wireless fidelity (WI-FI®), near field, and/or BLUETOOTH® capability. Exemplary embodiments may be applied to mobile devices utilizing any portion of the electromagnetic spectrum and any signaling standard (such as the IEEE 802 family of standards, GSM/CDMA/TDMA or any cellular standard, and/or the ISM band). Exemplary embodiments, however, may be applied to any processor-controlled device operating in the radio-frequency domain and/or the Internet Protocol (IP) domain. Exemplary embodiments may be applied to any processor-controlled device utilizing a distributed computing network, such as the Internet (sometimes alternatively known as the “World Wide Web”), an intranet, a local-area network (LAN), and/or a wide-area network (WAN). Exemplary embodiments may be applied to any processor-controlled device utilizing power line technologies, in which signals are communicated via electrical wiring. Indeed, exemplary embodiments may be applied regardless of physical componentry, physical configuration, or communications standard(s).

Exemplary embodiments may utilize any processing component, configuration, or system. Any processor could be multiple processors, which could include distributed processors or parallel processors in a single machine or multiple machines. The processor can be used in supporting a virtual processing environment. The processor could include a state machine, application specific integrated circuit (ASIC), programmable gate array (PGA) including a Field PGA, or state machine. When any of the processors execute instructions to perform “operations,” this could include the processor performing the operations directly and/or facilitating, directing, or cooperating with another device or component to perform the operations.

Exemplary embodiments may packetize. The server 20 and the audit server 50 may have network interfaces to the communications network 46, thus allowing collection and retrieval of information. The information may be received as packets of data according to a packet protocol (such as the Internet Protocol). The packets of data contain bits or bytes of data describing the contents, or payload, of a message. A header of each packet of data may contain routing information identifying an origination address and/or a destination address.

FIGS. 10-14 further illustrate the audit file 44, according to exemplary embodiments. Here the audit file 44 may include the metadata 92 associated with the original version 30 of the electronic mortgage document(s) 24. For example, the metadata 92 may describe the creation 32 (such as {“CreationTime”:“2012-05-07T11:12:32”}). The metadata 92 may additionally or alternatively describe the sourcing data 90 (such as {“SourceID”: “1131122”} or {“Location”: “Wells Fargo System XXX, ID YYY”}). The metadata 92 may describe the applicant, a location (such as GPS information at creation 32), word/character count, and an abstract describing or summarizing the electronic mortgage document(s) 24. The metadata 92 may also include one or more keywords associated with any of the electronic mortgage document(s) 24. The metadata 92 may also include a file hierarchy where the electronic mortgage document(s) 24 is stored and/or a network address for retrieval. The network address, for example, may be associated with a source server or other machine locally or remotely storing the electronic mortgage document(s) 24. The metadata 92 may also include structural details, such as file size, page numbering, chapter organization, and image data. Other metadata 92 may describe approved users (such as administrator and user permissions or identities) and digital rights management (or “DRM”). The metadata 92 may be formatted according to any standard. The audit file 44 may thus include any metadata 92 associated with the electronic mortgage document(s) 24.

FIG. 11 illustrates formatting. Here the electronic data 22 representing the metadata 92 may describe one or more formats 140. Most readers, for example, are thought familiar with a portable document format (“PDF”) 142, the MICROSOFT® WORD® extensible markup language extension (“docx”) 144, and/or the extensible markup language (“XML”) 146. Exemplary embodiments, though, may be applied to any file formatting and/or specification. The format 140 may be proprietary, free, unpublished, and/or open. The format 140 may be designed for images, containers, audio, video, text, subtitles, control characters, and encoding schemes. The format 140 may be HTML, vector graphics, source code, text files, syntax, and software programming. Whatever the format 140, exemplary embodiments may retrieve the electronic data 22 representing the format 140 of any electronic mortgage document 24. The audit file 44 may thus include any metadata 92 associated with the format 140 of the electronic mortgage document(s) 24.

FIG. 12 illustrates structured data 150. As the reader may understand, the electronic data 22 representing the electronic mortgage document 24 may be the structured data 150. That is, the structured data 150 may be organized (such as an entry 152 or database field 154 in a relational spreadsheet 156 or database 158), contained within a fixed data field 160 or data record 162, and/or be addressable via a network or memory address 164. Again referencing the electronic mortgage application 28, the structured data 150 may be organized according to the JavaScript Object Notation (or “JSON”). As the JavaScript Object Notation is a known format for structuring data, the JSON format need not be explained in detail. Suffice it to say that at least some of the electronic data 22 representing the electronic mortgage document 24 and/or the audit file 44 may be a JSON document 166 having the structured data 150 arranged as fields, formatted according to a JSON schema 168.

Exemplary embodiment may thus incorporate a data version 170 in the audit file 44. For example, if the electronic mortgage document 24 and/or the audit file 44 is the JSON document 166, then the data version 170 may be the structured data 150 arranged or formatted according to the JSON schema 168. Exemplary embodiments may thus retrieve and incorporate the data version 170 in the audit file 44.

FIG. 13 illustrates instructions 180. Here the audit file 44 may include the instructions 180. While exemplary embodiments may be applicable to any instructions, the instructions 180 may be structured (such as executable code), unstructured instructions (such as non-executable commentary lines in code, such as English language “do thing 1, then thing 2, then thing 3”). Other instructions 180 may include any messages (such as “When this document is accessed, POST to the URL http://some.target.url”). Exemplary embodiments may thus retrieve and incorporate the instructions 180 into the audit file 44.

FIG. 14 illustrates common loan data 190. Here the audit file 44 may include data or information that is common or applicable to each electronic mortgage document 24 described, referenced, or included within the audit file 44. For example, each electronic mortgage document 24 may be associated with the metadata 92 describing a common geographic location (e.g., street, city, state, and/or ZIP). The common loan data 190 may additionally or alternatively specify a single or common document or page (again, such as the IRS W-2 statement 74 included in each electronic mortgage application 28, as explained with reference to FIGS. 3-4). Similarly, the common loan data 190 may also include or describe a financial lender (such as WELLS FARGO′ or BANK OF AMERICA®) offering, evaluating, and/or processing the electronic mortgage applications 28. Whatever the common loan data 190 describes, exemplary embodiments may incorporate the common loan data 190 into the audit file 44.

FIG. 15 illustrates an index 200, according to exemplary embodiments. Here the audit file 44 may include the index 200. The index 200 may list or describe any or of all the electronic mortgage documents 24 that are included within, or referenced by, the audit file 44. Because the audit file 44 may contain many different and separate documents, the index 200 may be provided as a courtesy to the auditor 40 performing the audit 42. Indeed, the audit request 126 (explained with reference to FIG. 9) may even require the index 200. The index 200 may be generated from the electronic data 22 representing the electronic mortgage documents 24. The index 200, for example, may be generated from the metadata 92 associated with the electronic mortgage documents 24. The index 200 may be also arranged by topical subject 202, document name 204, and/or page number 206 to promote auditing efforts. The index 200 may additionally or alternatively be alphabetically arranged 208 to aid human search and retrieval. The index 200 may even describe and/or locate the metadata 92 associated with each electronic mortgage document 24. The index 200 may also describe the sourcing data 90 specifying the storage/retrieval location for each electronic mortgage document 24. When the auditor 40 (such as the audit server 50) receives the audit file 44, the index 200 permits easy machine or user access to the informational components within the audit file 44.

FIGS. 16-18 illustrate sourcing, according to exemplary embodiments. Here the sourcing data 90 may be used to retrieve the original version 30 and/or the current version 52 of the electronic mortgage document 24. When the audit server 50 receives the audit file 44, the audit file 44 may include or specify the cryptographic audit key 36 (as this disclosure above explains). The cryptographic audit key 36 may thus represent a unique digital signature generated from hashing the metadata 92 describing the sourcing data 90 representing a storage or network location (as explained with reference to FIGS. 5 and 10). Exemplary embodiments may thus generate one or more source keys 210 as the hash value(s) generated from hashing the sourcing data 90. Once the audit server 50 receives the audit file 44, the audit server 50 may thus read and/or retrieve the source key(s) 210 to easily and quickly discover the storage location of the corresponding original version 30 and/or the current version 52 of the electronic mortgage document 24. That is, the source key 210 may be used to reverse lookup the sourcing data 90. The audit server 50 generates and sends a key query 212 to the network address associated with an electronic database 214 of keys. FIG. 16 illustrates a key server 216 storing or maintaining the electronic database 214 of keys. The electronic database 214 of keys, however, may be stored at maintained at any network device or location. The electronic database 214 of keys stores entries that electronically associate different source keys 210 to their corresponding sourcing data 90. The audit server 50 queries the key server 216 (via the communications network 46 illustrated in FIGS. 1 and 7) for the source key 210 received via the audit file 44. The key server 216 retrieves the corresponding sourcing data 90 and sends a key response 218 to the audit server 50. The key response 218 includes information describing the sourcing data 90 retrieved from the electronic database 214 of keys. Exemplary embodiments thus allow the audit server 50 to translate or convert the source key 210 into its corresponding sourcing data 90.

FIG. 17 further illustrates the electronic database 214 of keys. The key server 216 functions to answer queries submitted by authorized clients. That is, the key server 216 executes a query handler application 220 that accepts the source key 210 as a query term. The query handler application 220 may then search the electronic database 214 of keys for a matching entry. While the electronic database 214 of keys may have any structure, FIG. 17 illustrates the electronic database 214 of keys as a table 222 that electronically maps, relates, or associates different source keys 210 to their corresponding sourcing data 90. The electronic database 214 of keys may thus be loaded or configured with data or information for determining the retrieval locations of mortgage documents. If a match is determined, the corresponding sourcing data 90 is identified. FIG. 17 illustrates the electronic database 214 of keys as being locally stored in the key server 216, but some of the database entries may be dispersed to multiple other devices or locations in the communications network (illustrated as reference numeral 46 in illustrated in FIGS. 1 and 7). While FIG. 17 only illustrates a few entries, in practice the electronic database 214 of keys may contain hundreds, thousands, or even millions of entries detailing many mortgage documents.

FIG. 18 illustrates database replies. The audit server 50 queries the electronic database 214 of keys for the source key 210 received via the audit file 44. The key server 216 retrieves and packages the corresponding sourcing data 90 as a key response 224. The key server 216 sends the key response 224 to the network address (e.g., IP address) associated with the audit server 50.

FIG. 19 illustrates document retrieval, according to exemplary embodiments. Now that the audit server 50 has determined the sourcing data 90 associated with the source key 210, the audit server 50 may retrieve the corresponding electronic mortgage document 24. The audit server 50 sends a document query 226 specifying the sourcing data 90 to a source server 228. When the source server 228 receives the document query 226, the source server 228 retrieves and sends the corresponding electronic mortgage document 24 as a document response 230. The audit server 50 has thus obtained the electronic mortgage document 24 referenced or associated with the audit file 44.

Exemplary embodiments may thus be used to retrieve different versions of the electronic mortgage document 24. If the audit file 44 references the source key 210 representing the original version 30 of the electronic mortgage document 24, then the audit server 50 need only query the key server 216 to determine the corresponding sourcing data 90 describing the network location associated with the original version 30. Similarly, if the audit file 44 references the source key 210 representing the current version 52 of the electronic mortgage document 24, then the audit server 50 need only query the key server 216 to determine the corresponding sourcing data 90 describing the network location associated with the current version 52. Exemplary embodiments may thus hash any of the metadata 92 and include the resulting hash values in the audit file 44.

FIG. 20 illustrates publication of the audit file 44, according to exemplary embodiments. Here exemplary embodiments may distribute the audit file 44 as a record in the blockchain 112. Exemplary embodiments, in other words, may integrate the audit file 44 as a transaction or block of data in the blockchain 112. FIG. 20 illustrates the blockchain 112 being distributed to the audit server 50, but the blockchain 112 may be unicast or broadcast to any one or more peer device. Exemplary embodiments may thus hash the electronic data 22 representing the audit file 44 as a further cryptographic security measure. That is, the cryptographic audit key 36 may represent the hash values generated from hashing some or all of the audit file 44 using the hashing algorithm 34. Exemplary embodiments may integrate the cryptographic audit key 36 (representing the audit file 44) as a historical ledger transaction or block in the blockchain 112.

FIGS. 21-22 illustrate secret sharing of the audit file 44, according to exemplary embodiments. By now the reader understands that the audit file 44 may contain sensitive information (such as an applicant's social security number, income, banking, and other personal information). The audit file 44, in plain words, may contain secret data 240. If the audit file 44 was to fall into the wrong hands, the secret data 240 may be nefariously used by a rogue entity.

Exemplary embodiments may thus protect the audit file 44. When the server 20 generates the audit file 44, the server 20 may split the audit file 44 into multiple pieces termed shares 242. The server 20 may then distribute one or more of the shares 242 via the blockchain 112 to the Internet Protocol address associated with the audit server 50.

FIG. 22 further illustrates secret sharing. Here, though, the server 20 may integrate any one or more of the shares 242 into multiple blockchains 112. While exemplary embodiments may utilize any number of different blockchains 112, FIG. 22 illustrates a simple example of three (3) blockchains 112a-c. The blockchains 112a-c may then be distributed to the same destination or to different destinations. FIG. 22, for example, illustrates three (3) different groups 244a-c of destinations, with the audit server 50 being one of the recipients. That is, some of the shares 242 (such as a first subset 246) are integrated into a first blockchain 112a and distributed (via the communications network 46 illustrated in FIGS. 1 and 7) to a first group 244a of peer devices. A second subset 248 of the shares 242 are integrated into a second blockchain 112b and distributed to a second group 244b of peer devices. Still more shares 242 (such as the remaining portion or pieces in a third subset 250) are integrated into a third blockchain 112c and distributed to a third group 244c of peer devices (illustrated as the audit server 50). Different collections of the shares 242, in other words, may be distributed via different blockchains 112 to different destinations/devices.

Exemplary embodiments may thus stash the shares 242 in the multiple blockchains 112a-c. Because the audit file 44 may be split into the multiple shares 242, any one or more recipient peer devices must possess a sufficient minimum number M_Min (illustrated as reference numeral 252) of the shares 242 before the audit file 44 may be recovered. That is, possession of an insufficient number of the shares 242 guarantees that the audit file 44 remains unknown and confidential. So, if the first blockchain 112a contains less than the M_Min 252 of the total shares 242, then the first group 244a of peer devices cannot reconstruct the audit file 44. Likewise, if the second blockchain 112b and/or the third blockchain 112c also contains less than the M_Min 252, the second group 244b of peer devices and the third group 244c of peer devices are also unable to reveal or decipher the audit file 44. In other words, no single one of the multiple blockchains 112a-c stores the requisite minimum number M_Min 252 of the shares 242 to launch a brute-force attack on the audit file 44. Even multiple ones of the blockchains 112a-c may be purposefully designed to never exceed the requisite minimum number M_Min 252 of the shares 242, perhaps thus forcing a hacker to compromise several or all of the blockchains 112a-c. A rogue attack, in simple words, would have to access and compromise multiple blockchains 112 before jeopardizing the audit file 44.

Exemplary embodiments thus present another elegant solution. The sensitive, secret audit file 44 may be secretly shared via the one or more blockchains 112a-c. Even if the blockchains 112a-c are dispersed to trusted peer devices, the peer devices still cannot discern the audit file 44 until the threshold minimum number M_Min 252 of the shares 242 is obtained. Exemplary embodiments thus purposefully add a second-layer of protection, beyond merely trusted receipt of the blockchain 112. The trusted peers simply do not have access to the audit file 44 until the minimum number M_Min 252 of the shares 242 is obtained.

Any secret sharing scheme may be utilized. The reader is perhaps familiar with Shamir's Secret Sharing Algorithm, which is a well-known cryptographic algorithm. Exemplary embodiments may thus divide the audit file 44 into unique parts (e.g., the shares 242), with each individual share 242 being different from other shares 242. However, there are many secret sharing or splitting schemes and algorithms for distributing a secret, and exemplary embodiments may be applied regardless of any particular scheme or algorithm.

FIGS. 23-24 illustrate a sharing strategy 260, according to exemplary embodiments. Here the server-side algorithm 122 may call a sharing algorithm 262 to retrieve and/or to implement the sharing strategy 260 that defines distribution via the multiple blockchains 112 to protect the audit file 44. Suppose, for example, that the total number N_S (illustrated as reference numeral 264) of the shares 242 defines a number N_B (illustrated as reference numeral 266) of the different blockchains 112. The total number N_S 264 of the shares 242, in other words, may relate by a ratio to the number N_B 266 of blockchains 112 that must be used. As a simple example, the ratio may be

$\frac{N_S}{N_B}=10\text{,}000,$ where the total number N_S 264 of the shares 242 is ten thousand (10,000) times the number N_B 266 of blockchains 112 that must be used. Again, as a simple example, if the audit file 44 is associated with one million (1,000,000) shares 242, then one hundred (100) different blockchains 112 must be generated and distributed. The sharing strategy 260, in other words, may set a maximum number N_S. (illustrated as reference numeral 268) of shares 242 integrated into any single blockchain 112. The sharing strategy 260, in other words, may thus limit the number of the shares 242 exposed by any individual blockchain 112.

FIG. 24 further illustrates the sharing strategy 260. Here, though, the number N_B 266 of blockchains may be based on the number of recipients. That is, the total number N_R (illustrated as reference numeral 270) of the recipients may define the number N_B 266 of the different blockchains 112. The greater the recipients, in other words, then the greater the N_B 266 of blockchains 112 that must be used. Again, suppose that the sharing strategy 260 may again be defined as the ratio

$\frac{N_R}{N_B}=100,$ where the total number N_R 270 of the recipients is one hundred (100) times the number N_B 266 of blockchains 112 that must be used. Again, as a simple example, if there are ten thousand recipients, then one hundred (100) different blockchains 112 must be generated and distributed. The sharing strategy 260, in other words, may set a maximum number N_Rmax (illustrated as reference numeral 272) of recipients per blockchain 112. The sharing strategy 260, in other words, may thus limit the number of the shares 242 exposed by any individual blockchain 112.

The sharing strategy 260 may be implemented as logical rules. If the sharing strategy 260 is mathematically defined (such as the ratio above discussed), the sharing strategy 260 may be expressed as logical statements involving mathematical expressions. Exemplary embodiments may code or program the sharing strategy 260 to achieve policy goals and/or security objectives.

FIG. 25 is a flowchart illustrating a method or algorithm for auditing the electronic mortgage documents 24, according to exemplary embodiments. The electronic data 22 representing the mortgage document 24 is received (Block 280). The electronic data 22 is hashed using the cryptographic hashing algorithm 34 (Block 282) to generate the audit key(s) 36 (Block 284). The audit file 44 is generated (Block 286). If secret sharing is desired (Block 288), then the audit file 44 is split into the shares 242 (Block 290). If secure distribution is desired (Block 292), then the audit file 44 and/or the shares 242 are published via the blockchain(s) 112 (Block 294). The auditor 40 receives the audit file (Block 296) and conducts the audit 42 (as this disclosure explains) (Block 298) to determine whether the mortgage document 24 is authentic 58 or inauthentic 60 (Block 300). If the mortgage document 24 is inauthentic 60, the fraud alert 64 may be generated (Block 302).

FIG. 26 is a schematic illustrating still more exemplary embodiments. FIG. 26 is a more detailed diagram illustrating a processor-controlled device 350. As earlier paragraphs explained, the server-side algorithm 122 and the audit-side algorithm 132 may partially or entirely operate in any mobile or stationary processor-controlled device. FIG. 26, then, illustrates the server-side algorithm 122 and the audit-side algorithm 132 stored in a memory subsystem of the processor-controlled device 350. One or more processors communicate with the memory subsystem and execute either, some, or all applications. Because the processor-controlled device 350 is well known to those of ordinary skill in the art, no further explanation is needed.

FIG. 27 depicts other possible operating environments for additional aspects of the exemplary embodiments. FIG. 27 illustrates the server-side algorithm 122 and the audit-side algorithm 132 operating within various other processor-controlled devices 350. FIG. 27, for example, illustrates that the server-side algorithm 122 and the audit-side algorithm 132 may entirely or partially operate within a set-top box (“STB”) (352), a personal/digital video recorder (PVR/DVR) 354, a Global Positioning System (GPS) device 356, an interactive television 358, a tablet computer 360, or any computer system, communications device, or processor-controlled device utilizing any of the processors above described and/or a digital signal processor (DP/DSP) 362. Moreover, the processor-controlled device 350 may also include wearable devices (such as watches), radios, vehicle electronics, clocks, printers, gateways, mobile/implantable medical devices, and other apparatuses and systems. Because the architecture and operating principles of the various devices 350 are well known, the hardware and software componentry of the various devices 350 are not further shown and described.

Exemplary embodiments may be applied to any signaling standard. Most readers are thought familiar with the Global System for Mobile (GSM) communications signaling standard. Those of ordinary skill in the art, however, also recognize that exemplary embodiments are equally applicable to any communications device utilizing the Time Division Multiple Access signaling standard, the Code Division Multiple Access signaling standard, the “dual-mode” GSM-ANSI Interoperability Team (GAIT) signaling standard, or any variant of the GSM/CDMA/TDMA signaling standard. Exemplary embodiments may also be applied to other standards, such as the I.E.E.E. 802 family of standards, the Industrial, Scientific, and Medical band of the electromagnetic spectrum, BLUETOOTH®, and any other.

Exemplary embodiments may be physically embodied on or in a computer-readable storage medium. This computer-readable medium, for example, may include CD-ROM, DVD, tape, cassette, floppy disk, optical disk, memory card, memory drive, and large-capacity disks. This computer-readable medium, or media, could be distributed to end-subscribers, licensees, and assignees. A computer program product comprises processor-executable instructions for auditing mortgage documents, as the above paragraphs explained.

While the exemplary embodiments have been described with respect to various features, aspects, and embodiments, those skilled and unskilled in the art will recognize the exemplary embodiments are not so limited. Other variations, modifications, and alternative embodiments may be made without departing from the spirit and scope of the exemplary embodiments.

Claims

1. A method of auditing an electronic document, comprising: receiving, by a server, an audit file specifying the electronic document, the audit file comprising (i) a cryptographic audit key representing a first portion of a first version of the electronic document, (ii) an interval of time for auditing the electronic document, and (iii) a sourcing data associated with a second version of the electronic document;using the sourcing data to obtain, by the server, the second version of the electronic document;retrieving, by the server, the interval of time specified by the audit file;generating, by the server, a verification hash value by hashing an electronic data representing a portion of the second version of the electronic document using a cryptographic hashing algorithm, the portion of the second version of the electronic document corresponding to the first portion of the first version of the electronic document;invoking, by the server, a timer that increments from an initial value to a final value determined by the interval of time;as the timer increments, comparing, by the server, the verification hash value to the cryptographic audit key; andperforming one of (i) in response to art expiration of the interval of time, declining further access to the audit file, (ii) in response to the verification hash value matching the cryptographic audit key prior to the expiration of the interval of time, verifying, by the server, that the second version of the electronic document is authentic, and (iii) in response to the verification hash value failing to match the cryptographic audit key prior to the expiration of the interval of time, determining that the second version of the electronic document is inauthentic.

2. The method of claim 1, further comprising recording an audit result to a blockchain.

3. The method of claim 1, further comprising distributing the verification hash value via a blockchain.

4. The method of claim 1, wherein the first portion of the first version of the electronic document comprises an entirety of the first version of the electronic document.

5. The method of claim 1, further comprising retrieving a metadata associated with the electronic document from the audit file, the metadata comprising at least one of (i) a creation date of the first version of the electronic document, and (ii) an identifier of the first version of the electronic document.

6. The method of claim 5, further comprising generating a digital signature by hashing the metadata retrieved from the audit file.

7. The method of claim 5, wherein the metadata provides a further description of the first version of the electronic document.

8. A system for auditing an electronic document, the system comprising: a hardware processor; anda memory device storing instructions that, when executed by the hardware processor, perform operations comprising:receiving an audit file associated with the electronic document, the audit file comprising (i) a cryptographic audit key representing a first portion of a first version of the electronic document, (ii) an interval of time for auditing the electronic document, and (iii) a sourcing data associated with a second version of the electronic document;retrieving the interval of time specified by the audit file;using the sourcing data to obtain the second version of the electronic document;generating a verification hash value by hashing an electronic data representing a portion of the second version of the electronic document using a cryptographic hashing algorithm, the portion of the second version of the electronic document corresponding to the first portion of the first version of the electronic document;invoking a timer that increments from an initial value to a final value determined by the interval of time for auditing the electronic document;as the timer increments, comparing the verification hash value to the cryptographic audit key; andperforming one of (i) in response to an expiration of the interval of time, declining further access to the audit file, (ii) in response to the verification hash value matching the cryptographic audit key prior to the expiration of the interval of time, determining that the second version of the electronic document is authentic, and (iii) in response to the verification hash value failing to match the cryptographic audit key prior to the expiration of the interval of time, determining that the second version of the electronic document is inauthentic.

9. The system of claim 8, wherein the operations further comprise recording an audit result to a blockchain.

10. The system of claim 8, wherein the operations further comprise distributing the verification hash value via a blockchain.

11. The system of claim 8, wherein the first portion of the first version of the electronic document comprises an entirety of the first version of the electronic document.

12. The system of claim 8, wherein the operations further comprise retrieving a metadata associated with the electronic document from the audit file, the metadata comprising at least one of (i) a creation date of the first version of the electronic document, and (ii) an identifier of the first version of the electronic document.

13. The system of claim 12, wherein the operations further comprise generating a digital signature by hashing only the metadata.

14. The system of claim 12, wherein the metadata provides a further description of the first version of the electronic document.

15. A memory device storing instructions that, when executed by a hardware processor, perform operations comprising: receiving an audit file associated with an electronic document, the audit file comprising (i) a cryptographic audit key representing a first portion of a first version of the electronic document, (ii) an interval of time for auditing the electronic document, and (iii) a sourcing data associated with a second version of the electronic document;using the sourcing data to obtain the second version of the electronic document;generating a verification hash value by hashing an electronic data representing a portion of the second version of the electronic document using a cryptographic hashing algorithm, the portion of the second version of the electronic document corresponding to the first portion of the first version of the electronic document;retrieving the interval of time specified by the audit file;initiating a timer that increments from an initial value to a final value determined by the interval of time;as the timer increments, performing a cryptographic audit by comparing the verification hash value to the cryptographic audit key; andperforming one of (i) in response to an expiration of the interval of time, declining further access to the audit file, (ii) in response to the verification hash value matching the cryptographic audit key prior to the expiration of the interval of time, determining that the second version of the electronic document is authentic, and (iii) in response to the verification hash value failing to match the cryptographic audit key prior to the expiration of the interval of time, determining that the second version of the electronic document is inauthentic.

16. The memory device of claim 15, wherein the operations further comprise recording an audit result to a blockchain.

17. The memory device of claim 15, wherein the first portion of the first version of the electronic document comprises an entirety of the first version of the electronic document.

18. The memory device of claim 15, wherein the operations further comprise determining a date of creation associated with the electronic document.

19. The memory device of claim 15, wherein the operations further comprise retrieving a metadata associated with the electronic document from the audit file, the metadata comprising at least one of (i) a creation date of the first version of the electronic document, and (ii) an identifier of the first version of the electronic document.

20. The memory device of claim 19, wherein the metadata provides a further description of the first version of the electronic document.