Patent Publication Number: US-2021174353-A1

Title: Auditing of Electronic Documents

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
     This patent application is a continuation of U.S. application Ser. No. 15/465,702 filed Mar. 22, 2017 and since issued as U.S. Patent X, which is incorporated herein by reference in its entirety. This patent application also relates to U.S. application Ser. No. 15/419,033 filed Jan. 30, 2017 (since issued as U.S. Pat. No. 10,419,225), to U.S. application Ser. No. 15/419,042 filed Jan. 30, 2017, to U.S. application Ser. No. 15/435,612 filed Feb. 17, 2017 (since issued as U.S. Pat. No. 10,411,897), to U.S. application Ser. No. 15/452,760 filed Mar. 8, 2017, to U.S. application Ser. No. 15/456,067 filed Mar. 10, 2017, and to U.S. application Ser. No. 15/459,061 filed Mar. 15, 2017, with all applications incorporated herein by reference in their entireties. 
    
    
     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&#39;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&#39;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&#39;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&#39;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  28   a - d . Moreover, even though each applicant&#39;s electronic mortgage application  28   a - d  may contain hundreds of pages/forms,  FIG. 4  for simplicity again illustrates the corresponding IRS W-2 statements  74   a - d . That is, the audit file  44  may contain the collection  80  of the IRS W-2 statements  74   a - d  associated with each applicant&#39;s electronic mortgage application  28   a - 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  36   a - d  (generated from hashing the original versions  30   a - d ) to the current version  52   a - d  of the IRS W-2 statements  74   a - d , then the applicant&#39;s corresponding IRS W-2 statement  74   a - d  is unaltered and authentic  58 . However, if the verification hash value  56   a - d  fails to match the cryptographic audit key  36   a - d , then the corresponding applicant&#39;s IRS W-2 statement  74   a - d  has changed since its date and time of creation  32   a - 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&#39;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  112   a - c . The blockchains  112   a - c  may then be distributed to the same destination or to different destinations.  FIG. 22 , for example, illustrates three (3) different groups  244   a - 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  112   a  and distributed (via the communications network  46  illustrated in  FIGS. 1 and 7 ) to a first group  244   a  of peer devices. A second subset  248  of the shares  242  are integrated into a second blockchain  112   b  and distributed to a second group  244   b  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  112   c  and distributed to a third group  244   c  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  112   a - 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  112   a  contains less than the M Min    252  of the total shares  242 , then the first group  244   a  of peer devices cannot reconstruct the audit file  44 . Likewise, if the second blockchain  112   b  and/or the third blockchain  112   c  also contains less than the M Min    252 , the second group  244   b  of peer devices and the third group  244   c  of peer devices are also unable to reveal or decipher the audit file  44 . In other words, no single one of the multiple blockchains  112   a - 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  112   a - 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  112   a - 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  112   a - c . Even if the blockchains  112   a - 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&#39;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 Ns (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 Ns  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 
     
       
         
           
             
               
                 
                   N 
                   S 
                 
                 
                   N 
                   B 
                 
               
               = 
               
                 10 
                  
                 
                   , 
                 
                  
                 000 
               
             
             , 
           
         
       
     
     where the total number Ns  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 Ns. (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 NR (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 
     
       
         
           
             
               
                 
                   N 
                   R 
                 
                 
                   N 
                   B 
                 
               
               = 
               100 
             
             , 
           
         
       
     
     where the total number NR  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.