Electronic document validation

[0001] This application claims priority under 35 U.S.C. § 119(e) to U.S. Provisional Application No. 60/369,030, filed Apr. 1, 2002 and entitled “System, Specification & Tools for Creating Processing, and Validating Electronic Documents,” which is incorporated by reference herein in its entirety.

[0002] 1. Field of the Invention

[0003] This invention relates generally to validating documents, and more particularly to methods and apparatus for validating electronic documents used in mortgage transactions.

[0004] 2. Description of the Related Art

[0005] Information is being increasingly processed electronically in lieu of traditional paper processes. Electronic documents offer substantial benefits, such as cost reduction and the accommodation of rapid manipulation and organization of information. Over the years, laws and business customs have evolved to address concerns associated with paper documents including authenticity (that a document is what it purports to be and has been actually signed by the appropriate entities), integrity (that a document is complete and unaltered), and validity (that a document complies with business and legal rules). Validation of electronic documents should address and satisfy these concerns to support the adoption of electronic documents in various environments.

[0006] Although conventional electronic documents address some of the traditional paper document concerns, they remain problematic in several respects. One problem with electronic documents is that, although they are capable of being rapidly processed, they must still integrate with environments in which their content will need to be accurately and verifiably displayed (e.g., printed, rendered on a monitor, etc.). This is particularly true for mortgage transactions, where documents such as promissory notes are still routinely used in paper form during certain procedures, such as closings. Although the data contained on a printed document could be transferred to an electronic document, in many applications such an electronic document could not be properly validated due to the lack of adequate assurances that the data contained in the electronic document actually corresponds to the printed (or otherwise viewed) document used in an underlying transaction. The printed document could be manually compared to the data in the electronic document in order to validate the electronic document, but such a practice would negate many of the benefits of electronic processing. Alternatively, a conventional markup language could be used to define an electronic document having displayable information. However, in such a case the listing for rendering a display would contain a substantial amount of information not required for subsequent data processing. Moreover, the format of the listing might not be amenable to rapid and accurate processing in many circumstances, and might not be formatted for related transactions.

[0007] Another problem with electronic document validation is the potential for document variation within an industry, as dictated by individual practices, or by the various conditions in which an electronic document might be processed. For example, in mortgage transactions, certain lenders may have a common set of requirements for document validity, but might supplement these with their own particular requirements. A conventional electronic document (e.g., an XML document) can have a specification, such as a document type definition (DTD) that identifies constraints used to determine whether the document is valid, such as whether it contains tags that are not permitted by the DTD. However, while checking for a set of known elements is known, such validation would be inadequate where divergent document requirements are encountered. Specifically, a document may be valid according to a DTD, but invalid according to the format and content required by a particular lender.

[0008] Furthermore, although conventional electronic document definitions include some general mechanisms for validating document integrity with regard to associating values to attributes (e.g. XML validation can ensure that an IDREF points to an ID that is actually defined in a document), there are not adequate assurances that actual values are appropriate for particular applications. That is, conventional validation applies a mechanical determination as to the existence of pairing, but provides no assurance that particular field and value pairings are appropriate for a given environment, and does not necessarily detect a faulty pairing.

[0009] Still further, related transactions might use separate documents that contain some common information, but which are not necessarily identical. For example, in the real estate environment, a closing will require certain documents, but related post-closing activities might require other documents. Conventional electronic document validation does not adequately address such scenarios.

[0010] Thus, what is needed is electronic document validation that verifies the correspondence of processed data to that contained on documents actually used in transactions, that is flexible in handling potentially divergent document and data requirements, and that provides greater assurances of data integrity than is provided with conventional electronic document validation.

[0011] The present invention provides improved electronic document validation.

[0012] In one aspect, electronic document validation verifies that displayable data corresponds to an underlying processed dataset. The validated electronic document has a main data portion and a view portion, wherein the main data portion can be parsed separately from the view portion, and the view portion includes presentation formatting for providing a display corresponding to the main data portion. To validate the electronic document, a set of validation rules is retrieved and applied to the electronic document. The validation rules include comparison rules for determining whether a display provided by the view portion substantially matches the main data portion. In one embodiment, substantial matching is verified for a set of values for fields required to validate a particular transaction. The comparison rules allow a determination whether certain values contained in the main data portion substantially match those found in the view portion of the electronic document.

[0013] In another aspect, linking elements that are also found in the electronic document may be used for matching the main data portion to the view portion. For a given field, a linking element identifies a main data value and a view data value, typically through pointers to fields and corresponding values in the document. Although there may be separate linking elements for each of the set of values, there may be other configurations. Sometimes, for example, a view data value appears numerous times in a viewed document. There, a single linking element might be used to verify matching to a main data value in each of numerous instances, if desired. The linking elements can also reside in a common location, for improved access during electronic document validation, and may further reside in the main data portion.

[0014] In certain embodiments, the validation rules can also include identifier reference rules and membership rules. The identifier reference rules determine whether a value is proper for a given field, in accordance with the type of document being validated. The membership rules determine whether the electronic document includes fields required for electronic documents in a particular environment. Application of the comparison, identifier reference, and membership rules in combination facilitates a validation of an electronic document that verifies that the document includes all necessary parameters for a particular transaction, that the values for the parameters meet expectations, and that the parsed data contained in the document substantially matches the document (or other view) used by parties to a transaction involving the electronic document.

[0015] The present invention can be embodied in various forms, including business processes, computer implemented methods, computer program products, computer systems and networks, user interfaces, application programming interfaces, and the like.

[0035] In the following description, for purposes of explanation, numerous details are set forth, such as flowcharts and system configurations, in order to provide an understanding of one or more embodiments of the present invention. However, it is and will be apparent to one skilled in the art that these specific details are not required in order to practice the present invention.

[0036] FIG. 1 is a block diagram illustrating an embodiment of an electronic document 100 in accordance with the present invention. The electronic document 100 has a modular configuration including a header section 110, a data section 120, a view section 130, and a signature section 140.

[0037] The electronic document 100 is preferably defined using a mark-up language, such as the one described further below. The electronic document 100 may be used in various systems, including a computer network, including but not limited to private networks, the Internet, a local area network, and others, and may be stored on various media including but not limited to a hard disk, floppy disk, tape or compact disc. In one embodiment, validation of the electronic document 100 is variously helpful in originating, closing and delivering loans to an investor in what is referred to as the secondary mortgage market. Although mortgage transactions are described, embodiments of the present invention are also applicable elsewhere, such as for any transactions requiring a transition from static paper-based documents to an electronic format.

[0038] Preferably, the electronic document 100 facilitates tamper-proofing (e.g., ensuring that a document is not altered), non-repudiation (e.g., evidencing that a document was signed by a particular entity at a particular date and time), field validation (e.g., checking that information in a document complies with content category rules), logging (e.g., recording actions performed on the document, with actor identification), access-control (e.g., facilitating prevention of unauthorized users from accessing the document), and self-sufficiency (e.g., avoiding reliance on external software). These and other features, and corresponding validation, are described further below.

[0039] In certain applications, it might be desirable to strip one or more of header 110, data 120, view 130 and signature 140 sections from the electronic document 100 to facilitate processing, display or transmission. For example, an electronic document that is only intended for machine processing may at times only include the header 110 and data 120 sections. Likewise, an electronic document that is only intended for viewing may not contain a data 120 section (e.g., a billing statement emailed to a client). In addition, it may be desirable to replace the view 130 section with viewable electronic documents in other formats such as a PDF or an image file. Having independent data and view sections is helpful for providing flexible document structures.

[0040] Still referring to FIG. 1, the header section 110 contains information about the document itself, such as its version, the type of document (promissory note, trial transcript, etc.) and whether or not all parties have signed. The data section 120 contains the information corresponding to that originating from an equivalent paper document, such as data from a promissory note. It may also contain some non-viewable information pertaining to transactions. The view section 130 contains tags that describe how to format and present the data contained in the document. Links connect the unformatted information in the data section 120 to the corresponding formatted information in the view section 130. The header 110 and data 120 sections are preferably written in extensible markup language (XML) and the view section 130 is preferably written in extensible hypertext markup language (XHTML), which are conventional languages for creating electronic documents, although various alternative languages may be utilized. Although a single data 120 and view section 130 pair is shown, these sections can be provided in various combinations, as described further below. Generally, there may be various pairs of data and view sections for a plurality of documents defined by the electronic document, or plural view sections sharing a common data section, or other combinations.

[0041] The signature section 140 is optional, and provides the electronic and/or digital signatures for the electronic document. A preferred signatures section 140 includes four components: (1) the signers of the document, their roles and order of signing the electronic document 100; (2) for unsigned documents, signature templates that indicate where signatures are to be applied in the document, the relationship between the signer and the placeholder and how the components of a signature are presented to the signer; (3) for signed documents, a representation of the signature in either digital or electronic form and its relationship to the signer; and (4) for documents with a tamper seal, an XML digital signature verifying the content of the electronic document 100 represented in an XML digital signature. The tamper seal may also be referred to as a tamper evident seal, as it later can provide evidence whether the digital content had been altered. Significantly, some signatures may also reside in the view area.

[0042] The electronic document 100 also includes an audit trail section. This section can be independent, or part of one of the other sections, such as the header section. The audit trail section is used to log actions performed on the document, identify the person or system taking those actions, and to identify next actions for use in workflow management.

[0043] XML allows information to be structured and classified so that it is easy to tell the difference between pieces of information (e.g., a lender's telephone number, and a borrower's zip code). Particularly, XML defines the structure and classification of information in tags or elements. These tags or elements are integrated within the information itself. XML markup tags such as <LENDER> and <BORROWER> easily identify important and meaningful information about the content of the electronic document. The names of the tags and the structure of XML documents are defined by a document type definition (DTD). The DTD associated with a particular electronic document describes the tags or markup and the structure of the document, and specifies which tags contain other tags. For example, the XML tag <PROPERTY> might contains four tags <StreetAddress>, <City>, <State>, and <PostalCode>.

[0044] The World Wide Web Consortium (W3C) is the organization responsible for the XML standard, DTDs and related standards (http://www.w3.org). Notwithstanding the reference to DTDs to define the structure of XML documents, it should be understood that other specifications, methodologies, systems, protocols, or schemes could define the structure of markup languages.

[0045] Hypertext Markup Language (HTML) is the set of codes in electronic documents that allow the documents to be displayed by a World Wide Web browser. HTML documents describe the presentation of information, such as on a computer screen. HTML is related to XML; however, an HTML document is not an XML document. The W3C is also maintains the HTML standard. XHTML is essentially a reformulation of HTML that is intended to provide users with some of the functionality, extensibility and versatility of XML while maintaining the ability to display documents in a web browser. An XHTML document is an HTML document that can be viewed as a web page and can be processed by XML software. They are readily viewed, edited, and validated with standard XML tools. The can often be viewed using conventional HTML browsers, or more robustly using XHTML conforming browsers.

[0046] XHTML allows the comingling of user-defined XML tags within presentation elements. For example, in the following line of XHTML: <b><BORROWER_NAME>Joe Smith </BORROWER_NAME></b>, a BORROWER_NAME element is nested within a “b” element, which stands for “bold”. Thus, the XML tag, “BORROWER_NAME”, describes the contained data while the presentation tag, “b”, instructs the browser on how to present the contained data (the presentation will not include any markup tags).

[0047] While XHTML is more robust and can provide the user with information concerning the data via the descriptive tags, XHTML constrains the form of the XML tags that can be embedded in the document, and requires presentation and XML data to take the same form, even if an alternate form is more suitable for later machine processing. It is therefore preferred to separate the XML tags that make up a document's structure (also called a model) from the document's presentation (also called a view).

[0048] FIG. 2 is a schematic diagram illustrating an embodiment of the architecture for an electronic document 200 in accordance with the present invention. The electronic document 200 includes a root element ElectronicDoc 210 having four sub-nodes or children elements: Header 220, Data 230, View 240 and Signature 250. The View element 240 has a child HTML View element 260, and the Data element 230 has two children elements, Main element 270 and Map element 280. In turn, the Main element 270 has a child element Note Info 290 and the Map element 280 has two ARC elements 295. Following are examples of electronic documents defined according to this architecture.

[0049] FIG. 3 illustrates a sample listing for an XML/XHTML based electronic mortgage document 300 in accordance with the architecture of FIGS. 1 and 2. Although an electronic mortgage document is shown, the present invention is equally applicable to other environments. The sample listing for the electronic document 300 includes the root element which is the ELECTRONICDOC element 310 contained between the opening tag <ELECTRONICDOC> and closing tag </ELECTRONICDOC> and its four children elements (HEADER, DATA, VIEW and SIGNATURE) that demarcate the sections of the document: the header section 320, the data section 330, the view section 340, and the signature section 350. Specifically, the header section 320 is between opening and closing tags <HEADER> and </HEADER>, the data section 330 is between opening and closing tags <DATA> and </DATA>, the view section 340 is between opening and closing tags <VIEW> and </VIEW> and the signature section 350 is between opening and closing tags <SIGNATURE> and </SIGNATURE>. The view section 340 is further subdivided into a main section 360 and a map section 370.

[0050] FIG. 4 illustrates another example of a listing for an electronic document 400, and is shown in the unsigned state, having a header section 410, data section 420, view section 430 and signature section 440. The listing for the same electronic document 400 is shown in the signed state in FIGS. 5A and 5B. The individual sections shown in FIGS. 4, 5A and 5B are discussed further below.

[0051] 1. The Header Section

[0052] Preferably, the header section 420 and data section 430 are written in XML, and the view section 440 in XHTML. The header section 420 contains information about the electronic document 400 such as type, state, signature, and access information. Presenting information identifying the characteristics of the electronic document in the header section 420 allows easy determination of the content of the document 400 without having to access and analyze the main data for such determinations.

[0053] A preferred HEADER element includes NAME, AUDIT_TRAIL, SIG_MODEL element, and may further include an ACCESS_CONTROL element.

[0054] The NAME element contains information about the document's class, state, and process properties. The attributes include Type, State, Negotiable, and MustBeRecorded. The Type attribute defines the type of document(s) that the electronic document 400 defines. It can be a single document, such as a “Note” as shown. It can also be an enumerated list. Options for the type of document will vary based upon application. For mortgage transactions, the available types include Note, Addendum, Security_Instrument, Assignment, Rider, Disclosure, TIL, Itemization, RightToCancel, HUD-1, RESPA, Closing Instruction, PaymentLetter, BorrowerAffidavit, Insurance, Lender, Investor, LoanModification, DeedOffrust, and Other. The header identifies various electronic document characteristics.

[0055] The state preferably defines the document's current stage in the document lifecycle. Although various state values may be applied, in one embodiment, they include “unpopulated,” wherein the document has an unpopulated data section and unpopulated and unsigned view; “populated,” wherein the document has been completed with data; “signable,” wherein the document is populated with data that specifies all of the proposed signers and contains placeholders for signature lines; “signed,” wherein the electronic document has all of the signatures for all signers, with the exception of the recorder, and the document is tamper sealed; “recordable,” which is a stage wherein the document is in a combination of signed and unsigned states, occurring when a borrower and/or notary have signed the document and it is presented for a recorder's signature; “recorded,” wherein the document has all of the signatures for all signers including the recorder and is digitally tamper sealed; exported, wherein a document that is a copy or a view of an archived document is exported, while the original electronic document remains stored as an immutable archived copy; and “voided,” wherein a signed or recorded document no longer has legal effect. These meta-information sub-elements and attributes are contained within the HEADER element, as shown in FIGS. 4 and 5A. Specifically, in FIG. 4 the state is indicated as “signable” and in FIG. 5A the state is indicated as “signed” since at least one person has signed the electronic document 400. Of course, the meaning of “signed” might require more than one signature to adopt that state. For example, the “signed” state might require all parties to the transaction to have signed the electronic document, including a tamper seal based signature.

[0056] Regarding the remaining attributes, the Negotiable attribute indicates whether the electronic document is a negotiable instrument or not, and the MustBeRecorded attribute is a Boolean attribute that indicates whether the electronic document must be recorded.

[0057] The AUDIT_TRAIL element contains a log of all of the actions that have been performed on the document, recording the party who performed an action, the action performed and the date and time of the action. This is useful for workflow management and for review of actions performed on the electronic document. As with the header generally, providing a specific area to inquire about audit trail information is useful in its provision of information in a well defined area, for easy determinations about type, state, and other information. In the illustrated example, the audit trail information reveals that a party denoted Joe Smith created an electronic document template, and then that a “Doc Prep” party populated the document and placed it in condition for signing (according to the above described states).

[0058] The SIG_MODEL element connects signers, targets and signatures. The illustrated element includes attributes indicating signer areas, role, targets, and tamper seal information. These attributes are described further in connection with the signature section, below.

[0059] The ACCESS_CONTROL element lists the classes of entities that may access the document. Attributes can define particular classes of entities (e.g., Lender, Notary, ClosingAgent, etc.), corresponding permissions (e.g., edit; read only; etc.), and targets for those permissions (e.g., a particular View; the entire document; etc.).

[0060] Other elements can also be provided to identify information about the electronic document. For example, a HEADER element ID can also be provided to uniquely identify the header element within the document.

[0061] 2. The Data Section

[0062] The data section 430 contains the typically processed data for the electronic document (e.g., loan amounts, loan type, loan term lender's name, borrower's name and property address). Because the data section 430 does not typically contain format information, repetitions of data or lengthy signature information, it usually requires less storage than the view section 440 and the signature section 450 (the data section 430 often comprises less than fifteen percent of the electronic document). Providing the separate data section 430 is helpful to processing because computational resources are not dedicated to searching through the entire document for data, or separating data from view information.

[0063] The data section 430, which is demarcated by the DATA element, is further subdivided into a main section 460 and a map section 470 demarcated by the MAIN and MAP elements, respectively. The main section 460 contains the data model that is the XML structural description of the electronic mortgage document, which includes the XML elements corresponding to the elements in the DTD, an example of which is shown in FIG. 5. In the illustrative mortgage environment, the MAIN element comprises LOAN (the terms and features of the loan, e.g., the interest rate and loan amount), BORROWER (information about the borrower), LENDER (information about the lender), PROPERTY (information about the property which is the subject of the mortgage), and EXECUTION (information about the date and location of the execution of the note) elements.

[0064] The map section 470 links structural fields in the data section 430 to presentation fields in the view section 440. A map section 470 is used with a “tagged” view in order to link the variable data fields in the view section 440 to their counterparts in the main section 460 (which contains the XML data elements). There should be one MAP element for each view that a DATA element is linked to. For example, if an electronic document contained three different view sections representing the data from a single data section, there would be three corresponding MAP elements within the DATA element.

[0065] The MAP element includes ARC elements that link values in the view section 440 to those in the data section 430. These may also be referred to as linking elements. There are various ways that the linking element can reference the necessary values. For example, the illustrated ARC elements include a pointer to a field in the data section 430 (in an attribute called DataEnd) and a pointer to a field in the view section 440 (in an attributed called ViewEnd). Preferably, the format of these pointers conforms to the conventional W3C XPATH specification, although various alternatives can be provided and the present invention is not limited to this language or format.

[0066] ARC elements may be used for one-to-one mapping, one-to-many mapping, one-to-one data type conversion and one-to-many data type conversion. A single ARC element is used to create a one-to-one map. One way to create a one-to-many mapping uses multiple ARC elements, one for each data-to-view linkage. In this example, if an electronic document displays the first name of a borrower five times, then the MAP element contains five ARC elements, each linking the borrower's first name field from the data section to an instance of the name in the view section 440.

[0067] The format for a value displayed in the view section 440 will often differ from that in the data section 430. For example, a date may be represented numerically in the data Section 430 (e.g., “8/30/75”) and in text form in the view section 440 (e.g., “Aug. 30, 1975”). When validating the document, it is helpful to convert the data into the same format for comparison (e.g., to ensure that corresponding values for fields in the view and data sections are identical).

[0068] When it is necessary to perform a data conversion, the ARC element is paired with a CONVERT element, which facilitates conversion of data types so that they are similarly formatted for comparison purposes. Various pairing configurations can be used. For example, ARC elements can be contained by a CONVERT element (typically for group conversions) or can contain a CONVERT element (typically for single conversions). The CONVERT element has three attributes: the name of the conversion process, the data type of the data in the data section, and the data type of the data in the view section. Various conversion processes can be applied. For example, the process called “ConvertType,” transforms decimal numbers into text. This would be used to compare a numerical data section value (e.g., loan principal is “125000.00”) with a text based view section representation (e.g., loan principal is “One Hundred Twenty Five Thousand.”) Many conversion processes use masks to specify how a data field is to be compared with a data field formatted for presentation. For example, if “#” indicates an optional digit, then the following mask “$ ##,###.##” would convert 125000.00 into “$ 125,000.00.”

[0069] For one-to-many data conversions, the CONVERT element contains a set of ARC elements. This allows for a conversion to map several input data fields to a single output presentation field (e.g., take a separate day, month, and year field to generate a single date display) or to map one data input field to many output presentation fields (e.g., represent the loan principal amount both numerically and in text-form in the view section).

[0070] An optional OPERATOR element may be used to specify different types of allowable conversions on data for different presentations. This optional element allows several ARC elements to be combined in Boolean fashion (i.e., with AND or OR).

[0071] A DATA element can also contain a CUSTOM element. The CUSTOM element provides users with an area to place proprietary data, new requirements data or anything that a particular system may need that does not “fit” anywhere else. As with all the XML elements, the scope of the data acceptable via the CUSTOM element is defined in the DTD. The DTD defines the scope of user-defined and user-named sub-elements to the CUSTOM element. Preferably, the CUSTOM element sits outside the MAIN element because it is designed to contain proprietary or ad hoc data.

[0072] 3. The View Section

[0073] The view section 440 includes data corresponding to that contained in the XML data section 430 along with information on how to display the data. Typically, the view section and the displays created thereby are considered to be the legally binding portion of the electronic document, so the data section can be said to contain copies of data found in the view section. The view section 440 can contain multiple views, each implemented by a pairing or linking of visual formatting information and data. DATA and VIEW elements may be present in various combinations. There can be multiple pairings of DATA and VIEW elements, and multiple VIEW elements may be paired with a single DATA element.

[0074] As discussed above, the map section 470 contains the explicit links between structural fields in the data section 430 and presentation fields in the view section 440. The map section 470 is used with a “tagged” view in order to link the variable data fields in the view section 440 to their counterparts in the main section 460 (which contains the XML data elements).

[0075] The XHTML views are “tagged” by marking the variable fields. Particularly, a SPAN or DIV element can be used to tag variable data fields. The SPAN element used in this example has an ID attribute with a unique ID that can be referred to by an ARC element in the map section. As discussed above, ARC elements contain a pointer to a field in the data section 430 (in an attribute called DataEnd) and a pointer to a field in the view section 440 (in an attribute called ViewEnd). Thus, the SPAN (or DIV) element is used to envelop the data field in the view section, and to uniquely identify it using an ID attribute.

[0076] 4. The Signature Section:

[0077] The signature section 450, shown in FIGS. 5A and 5B, ensures the authenticity and integrity of the electronic document 400. Various signatures, including digital and electronic signatures, may be used. For digital signatures, a Signature element according to the W3C XML Signature specification is preferably used. For electronic signatures, there are three types of signature elements: SIG_IMAGE, SIG_TEXT, and SIG_OBJECT. The SIG_IMAGE element corresponds to a locally encoded image of the person's signature or a holographic signature. The SIG_TEXT element refers to a string of text inputted by the signer. If the SIG_TEXT element is within a viewable HTML view, the text will appear. Outside of the SIG_TEXT element an application is free to style the signed text with an enclosing SPAN tag. Lastly, a SIG_OBJECT element corresponds to any external object code to be presented as an electronic signature. This would correspond to an HTML embed tag for the specific purpose of presenting a captured signature (e.g., a form of a biometric signature).

[0078] To understand the signature section 450, reference is now made to FIGS. 4, 5A and 5B which depict the listing for the electronic document 400 in the unsigned and signed states. As shown in FIGS. 4 and 5A, the header section 410 includes a SIG_MODEL element. The view section 430 contains a SIG_TARGET element and a SIG_LINE element within the VIEW element. As this listing demonstrates, parts of the signature section 450 are actually implemented within the HEADER and VIEW elements.

[0079] The <SIG_MODEL> element defines signatures provided in the electronic document and accommodates the transition from a signable state to a signed state. For each signature that is applied to the electronic document 400, the SIG_MODEL element will contain a SIGNER element. A corresponding SIG_TARGET element will exist in the view section 440 between the <VIEW> opening tag and the <VIEW> closing tag. The SIGNER and SIG_TARGET elements describe how a particular signature is to be applied to the electronic document 400.

[0080] The SIGNER elements have the following attributes: Role (defines which class of users may sign in a particular area), Roleorder (the order in which the signature should be applied relative to other signatures on the document), Type (the type of signature that will be used, e.g., digital or biometric signature), Targets (the particular SIG_TARGET within a VIEW element that is to be signed), Area (the specific SIG_AREA elements to which this SIGNER refers), Areas (the specific SIG_AREAS elements to which this SIGNER refers), Data, and Signature (the specific signature elements (electronic or digital) this SIGNER refers to).

[0081] In electronic document 400, the SIG_MODEL indicates that its corresponding SIG_TARGET will be electronically signed by a borrower, that the signature will be in text form, that it should be signed before all other signatures are applied, and that the electronic signature will be stored at the SIG_LINE with the unique identifier “BorrowerArea01.” In addition, a tamper seal is applied in the form of a digital signature having as its target the entire view section identified by the unique Id “View01.” The tamper seal wraps the entire view including the first applied electronic signature of the borrower.

[0082] More specifically, as shown in FIGS. 4 and 5A, the view section 440 contains the SIG_TARGET element which has the unique identifier “Borrower01.” Within the SIG_TARGET is the area to be signed using the designated signature type (e.g., electronic or digital), which includes the HTML HEAD and BODY elements. The BODY element contains the text of the note and a SIG_AREAS element. The SIG_AREAS element holds all of the SIG_AREA elements for the View Section (although in this example there is only one SIG_AREA, “BorrowerArea01”). There should be one SIG_AREA for each signature that will be placed on the document. The SIG_AREA includes SIG_ABOVE (the text that goes above the signature line), SIG_LINE (the actual text representation of the signature line, which in this case is a long underscore line), and SIG_BELOW (the text that goes below the signature line). In the present example, the SIG_MODEL element indicates that this information located between the <SIG_TARGET> opening tag having the identifier “Borrower01” and the <SIG_TARGET> closing tag will be electronically signed by the borrower, Rebecca Kate Thornton, using a text-based signature.

[0083] When the electronic document 400 is signed, the SIG_MODEL element, the SIG_TARGET element and the SIGNATURE element are modified. The SIG_TARGET element of the VIEW element is modified to depict a document where the borrower's full name has been filled in. Since the Type attribute of the SIGNER element indicates a text signature for the borrower, the SIG_LINE element is replaced by the SIG_TEXT element which contains the actual electronic signature (in this case the underscore shown in FIG. 4 is replaced with “eSigned by Rebecca Thornton at 3:46 on 11/16/2001” as shown in FIG. 5A).

[0084] The SIG_MODEL element also includes a Signature=“TamperSeal01” to serve as a pointer to the signature. Once the electronic document has been signed, a SIGNATURE element is added which contains tamper sealing information in the form of an encrypted hash of the document. As shown in FIG. 5B, the digital signature tamper seal is performed using a standard PKI method. Both the digest or hash value and the key value are included between the <SIGNATURE> tags. The actual digital signature value (i.e., the value generated by encrypting the message digest with the private key is stored between opening and closing <SignatureValue> tags shown in FIG. 5B. In addition, the digital certificate including the public key of the private-public key pair is stored within the signature section 450.

[0085] FIGS. 6A, 6B, and 6C illustrate a sample format for an XML DTD file for an electronic document. The DTD includes conventional commentary syntax for explaining the function of various sections of the DTD file. The beginning of a comment is signified by “<!--” and the end of a comment is signified by “-->.” “|” represents the logical expression “or,” “?” signifies an optional element (zero or one of the element may be present), “*” signifies zero or more, and “+” signifies one or more.

[0086] The DTD 600 also contains Entity definitions that define the members and structures of groups. For example, the Role definition lists the various recognized roles: borrower, lender, notary, closing agent, recorder, grantor, assignor and other. The Boolean definition lists the recognized values for a Boolean, which are “true” and “false.” The <ELECTRONIC DOC> element is the root of the document. The DTD specifies that electronic document 600 may contain more than one view and that the data section is optional. This means that there can be various configurations such as a header and a data section; or a header and a view; or a header, data and one or more views. This flexibility is useful for a set of mortgage documents to be packaged together where all documents do not require tagged views. The elements described in connection with the electronic document are generally provided, either directly or referentially, according to the DTD 600. Again, this DTD 600 merely suggests one possible format, and the ordinarily skilled artisan will recognize the various different options for providing an electronic document DTD according to required business practices for each particular electronic document.

[0087] FIGS. 7 through 12 illustrate an embodiment of a STRUCT_MODEL element, which is an optional element that can be used to organize the electronic document or documents, and components thereof. The STRUCT_MODEL element typically resides in the header section of an electronic document, and allows the electronic document to be split into different files and components for independent processing. For example, the STRUCT_MODEL element allows the data section and view section to be extracted into different files. Alternatively, several documents can share sub-parts. For example, many documents of lesser importance could share a single data block, reducing the data redundancy of the documents, and making their creation simpler for document preparation entities.

[0088] FIG. 7 illustrates a STRUCT_MODEL element 700. Relationships between the document and its sub-parts are maintained by linking the PARENT element 710 and the PART element 720. The STRUCT_MODEL element 700 preferably uses XLink Version 1.0. An XLink is similar to an HTML hyperlink with several additional features such as allowing one link to reference many destination links. The previously W3C also manages the XLINK specification, which is referred to as the XML Linking Language. It allows elements to be inserted into XML documents in order to create and describe links between resources. It uses XML syntax to create structures that can describe links similar to the simple unidirectional hyperlinks of HTML, as well as more sophisticated links.

[0089] In compliance with the XLink standard, the information attributes 730 contained within the STRUCT_MODEL element 700 include XLINK:TYPE, XLINK:TITLE, CONTENT, and TYPE. The XLINK:TYPE attribute defines the type of link. In STRUCT_MODEL elements this value is “extended,” meaning that it is a one-to-many link. The XLINK:TITLE attribute holds the title of the structural model. The CONTENT attribute describes how content is rendered in the given document, with “static” meaning that all information may be viewed or processed by a user and “dynamic” meaning that additional processing is required to render the content viewable by the user. The TYPE attribute describes where parts of the document are stored. This attribute has the values “Document,” “Pool” or “Package.”

[0090] The PARENT element 710 points to a parent container or document. A PART element 720 points to a member of the current container. A container can be an element, a file or a JAR archive file format (i.e., Java™ .jar file format). PARENT elements 710 and PART elements 720 have four common attributes: XLINK:ROLE, which defines the role of the part or parent pointed to (e.g., delivery package, view section, closing package); XLINK:TITLE, an optional attribute for specifying the title of the part or parent; STORAGE, the attribute used to describe where the part or parent is stored (locally or remotely); and XPATH, an optional attribute used to provide an Xpath expression for the location of a locally stored part.

[0091] Although the electronic document can be variously embodied and stored, it may be arranged for storage according to the JAR archive file format. This allows the bundling of multiple documents into a commonly archived file that can be digitally signed. For example, FIG. 8 is a schematic diagram illustrating the basic architecture for a delivery package 800 within a JAR file containing an electronic document representing a Note 820 and an electronic document representing an Assignment 830. The Note 820 and the Assignment 830 are preferably XML files. The Note 820 points to the JAR delivery package represented by the circle 810 as its parent, and to its data section “D” and view section “V” as parts. Similarly, the Assignment 830 points to the JAR delivery package represented by the circle 810 as its parent, and to its data section and view section as parts. The JAR delivery package 810 does not point to a parent (because it is not a sub-part of any file) and points to the Note 820 and the Assignment 830 as its parts. This allows for a clean separation of data components for storage in multiple configurations, and assigns labels for software programs to process the individual parts and aggregation of parts correctly. Various alternatives to the JAR file format can be provided, such as including files in a .zip file or using a conventional XML packaging format.

[0092] FIG. 9 is a schematic diagram illustrating the basic architecture for a delivery package 900 within a JAR file containing an electronic document representing a Note 920 and an electronic document representing an Assignment 930. The Note 920 and the Assignment 930 are preferably XML files. The Note 920 points to the JAR delivery package represented by the circle 910 as its parent, and to its data section “D” and view section “V” as parts. Similarly, the Assignment 930 points to the JAR delivery package represented by the circle 910 as its parent, and to its data section and view section as parts. The JAR delivery package 910 does not point to a parent (because it is not a sub-part of any file) and points to the Note 920 and the Assignment 930 as its parts. Thus, the structure of the Delivery Package is defined and implemented in the STRUCT_MODEL elements of the various files. This allows for a clean separation of data components for storage in multiple configurations, and assigns labels for software programs to process the individual parts and aggregation of parts correctly.

[0093] FIG. 10 is a schematic diagram illustrating a JAR set of loans package containing multiple loans. The JAR package for the set of loans 1000 contains multiple JAR delivery packages 1020, 1030, each of which contains a Note electronic document 1040 and an Assignment electronic document 1050. Each of these JAR delivery packages 1020, 1030 points to the set of loans JAR file represented by the circle 1010 as its parent. The set of loans JAR file 1010 points to the delivery package JAR files 1020, 1030 as its parts.

[0094] FIG. 11 illustrates an example listing for a dynamic STRUCT_MODEL element 1110 for a closing package having a container in the form of a JAR file. As described previously, the STRUCT_MODEL element contains information attributes 1110, a PARENT element 1120, a PART element 1130 for a data section of an electronic document according to the present invention, and a PART element 1140 for a view section.

[0095] FIG. 12 illustrates the structure of a closing package JAR file having a shared data section. The closing package 1200 contains two XML electronic documents 1220, 1230, both of which share the same data section 1240. Each document 1220, 1230 within the closing package 1100 contains a view section, which it points to as a part, and points to the closing package represented by the circle 1210 as a parent. The document 1220 (or 1230) and the closing package 1200 all point to the data section 1240 as a part. This structure allows multiple related documents to share their data sections or portions of their data sections. This ensures the integrity of the entire package, by eliminating the possibility of inconsistency between the various documents in the package.

[0096] As discussed in detail above, the electronic document separates format information from the underlying data, providing separate data and view sections. In one embodiment, the present invention provides electronic document validation that ensures that the visual information displayed for a user is identical to the transaction data contained within the underlying electronic document. Preferably, such validation operates in conjunction with electronic documents having separate data and view sections.

[0097] Validation in accordance with the present invention can be variously embodied. For example, embodiments include but are not necessarily limited to a method for validation; software that performs the described validation function, which may be stored on various media such as hard disks, floppy disks, optical (e.g. compact) discs or the like; a validation system including a processor that executes instructions found in a memory to perform validation; and an apparatus configured to perform validation. For ease of discussion, validation is described as being performed by a “validation tool” below.

[0098] The validation tool verifies that an electronic document is compliant with various rules. This includes checking that a document is in the proper structural format and contains all necessary information fields, confirming that the document complies with certain legal or business rules, and ensuring that there is an exact correspondence between the information in the data section and the information in the view section. In mortgage transactions, there are various sources of potential differences between document and transaction data. Inconsistencies between the data and a view are likely to be introduced at the time a document is created, as different parties with different information systems can produce documents in a mortgage set. Information is also changed in the time leading up to the closing of a mortgage, and that information may not be changed consistently throughout multiple documents and document sections.

[0099] Validation uses the DTD for the electronic document (e.g., according to the format illustrated in FIGS. 6A-C) and particular validation rules described below to validate electronic documents. If all validation tests are passed, the Validation Tool adds an entry to the AUDIT_TRAIL element (located within the Header Section) of an XML electronic document recording the successful validation.

[0100] In a first level of validation, the validation tool performs baseline validation, which is similar to standard XML parse validation that determines whether an XML document conforms to its DTD definition. For example, the electronic document must contain all necessary fields (e.g., a loan document may be required to contain a LOAN element), comply with grammatical rules (e.g., all elements must have a beginning and an end), and comply with structural rules (e.g., a loan element must contain a balance field and an interest field). In addition, unlike a conventional validating XML parser, the validation tool determines whether pointers (e.g., IDREF) points to an appropriate part of the document and accommodates appropriate data conversions (e.g., using the CONVERT elements) for data and view section comparisons.

[0101] The validation tool is preferably provided as software, although it may also be provided in hardware, firmware, or combinations thereof. The validation tool may be variously modularized according to the functionality described below. The validation tool also implements a customizable rule language and rule execution engine. The rule suite which is preferably in a java code or XML is preferably run on a computer workstation having at least 128 Mbytes of physical RAM, at least 66 Mbytes of free disk space and at least a 166 MHZ processor. The computer workstation operating system preferably supports Java 1.3.1 and Internet protocols and software. Preferably, the validation tool also operates an interactive graphical user interface, although the tool may also be implemented through other modes including but not limited to a console (command line) mode, a batch mode or a web-based mode.

[0102] After the Validation Tool uses a document's DTD file to perform baseline validation, it loads the document's associated rule suite to perform more in depth validation by applying its own validation rules. Preferably, the validation rules are organized into rule sets, and rule sets into suites. A validation suite is a collection of rule sets targeted at a single document type. Sample formats for a rule suite DTD and a corresponding validation rule suite XML listing are respectively shown in FIGS. 13A-B and 14A-C. As indicated in FIGS. 13A-B, the DTD 1300 defines as possible elements the different types of rules in one type of rule set, namely comparison, membership, IDREF and Group Membership rules as indicated. It further describes the potential elements and attributes for the triggers and corresponding reports for each of the types of rules. FIGS. 14A-C illustrate a sample format for an XML listing 1400. The XML listing itself can be verified against a rule suite DTD, such as the one in FIGS. 13A-B, if desired.

[0103] The XML listing 1400 provides the rules that are applied to the electronic document to be validated, with the validator executing the provided rules. In some instances, the electronic document may contain additional information that is used to execute the rules. For example, the electronic document may contain the previously described ARC and CONVERT elements, which respectively identify values for comparison and modify them to accommodate the comparison. The sample listing includes a number of rule sets. Referring first to FIG. 14A, one rule set is the comparison rule set. These are triggered by the presence of and correlate to the MAP section of the electronic document. As the listing illustrates, for each ARC element in the MAP section of the electronic document, view and data values are compared to determine whether they are equal.

[0104] Other rule sets include the identifier reference “IDREF” rules, and membership rules, as illustrated in FIG. 14B. The example for the IDREF rule set shown in FIG. 14B accommodates a determination whether an electronic document in an unsigned state includes what are considered to be necessary elements. According to the provided example, the presence of SIG_TARGET, SIG_LINE, and SIGNATURE elements is required for a valid electronic document in this state. The membership rules are used to determine whether the main data section of the electronic document includes the necessary elements for the type of document being validated. The examples illustrated in FIG. 14B are MORTGAGE_TERMS, LOAN_FEATURES, LENDER, BORROWER, and PROPERTY. There will be various formats, and the elements to be checked will vary. For example, the membership rules also likely will include sub-elements. For example, in addition to generally validating the presence of the LOAN_FEATURES element, several specific loan features, such as the late fee percentage and other parameters, could also be included as elements whose presence is verified according to the membership rules.

[0105] Referring to FIG. 14C, various presence triggers will dictate whether some the previously described rule sets will be invoked against a document to be validated. For example, if the document to be validated includes the DATA/MAP element (and thus the MAP section), then the above described comparison rules are triggered. Similarly, the presence of the HEADER/SIG_MODEL element and DATA/MAIN elements respectively trigger the above described IDREF and membership rules. Other triggers can also be applied, such as those that accommodate conversion that is applied to view and/or data values to accommodate a matching comparison as described.

[0106] This listing 1400 format is merely provided as an example. The ordinarily skilled artisan can variously modify or implement different formats in order to provide the validation functionality, which is described below in connection with FIGS. 15-18. Thus, a listing might not necessarily include all of the different rule types described herein, including only one type, such as comparison rules, or another combination of types, such as comparison and membership rules without IDREF rules, depending upon the type of validation that is required or desired.

[0107] As introduced above, examples of rules that can be used by the Validation Tool are comparison rules, IDREF rules, and membership rules. These rules are described further below.

[0108] FIG. 18 is a block diagram illustrating one embodiment of a Validation Tool 1800 in accordance with the present invention. The Validation Tool is shown to reside within a computer memory. As indicated above, the Tool is preferably provided as software. The software provides instructions that are executed by a conventional processor to provide the described validation functionality. Although one modular breakdown is shown, fewer or more modules can provide the same functionality. The Validation Tool 1800 includes an electronic document storage module 1802, a validation rules module 1804, a rules execution module 1806 and an electronic document updating module 1808. It may also include any necessary components for rendering displays that provide user interfaces through which users provide input to and receive output from the Validation Tool 1800 (not shown).

[0109] The electronic document storage module 1802 receives an electronic document to be validated. A preferred electronic document is described herein. That type of electronic document has a main data portion and a view portion, wherein the main data portion can be parsed separately from the view portion, and the view portion includes presentation formatting for providing displays corresponding to the main data portion. These displays are typically human readable displays (e.g, printed on paper, or shown on a computer monitor) that are used pursuant to transactions, such as promissory notes used in mortgage transactions. The electronic document can be stored for processing in conventional fashion. It may be contained in a JAR file but may be variously stored, such as in a standalone file.

[0110] The validation rules module 1804 loads a set of validation rules corresponding to the electronic document. The validation rules may be organized into suites pertaining to particular types of document, and may include various types of rules such as comparison, membership and IDREF rules. The rule suites may be stored in a separate database from which a particular suite is loaded based upon a determination of the type of electronic document being validated.

[0111] The rules execution module 1806 communicates with the validation rules module 1804 and the electronic document storage module 1802 and applies the rules to the document to determine its validity. It includes instructions for executing the validation rules, which are described further in connection with FIG. 15 below. Finally, the electronic document updating module 1808 includes instructions for updating the electronic document where it is determined that the electronic document is valid, such as by accessing information in the electronic document header and updating a state based field to indicate confirmed validity.

[0112] FIG. 15 is a flow diagram illustrating an embodiment of validating an electronic document 1500 in accordance with the present invention. The user activates the Validation Tool and selects a target document to validate. The Validation Tool initially loads 1510 a DTD appropriate for the value for the “type” field of the header section. For example, if the electronic document is indicated to be a note, then a DTD particular to the note is loaded by the Validation Tool. Additionally, as described earlier, a DTD is available for the electronic document generally. From the note validation DTD, the validation tool can load 1520 the validation rules suite particular to the note.

[0113] The Validation Tool then applies the various validation rules to the electronic document. As indicated, the Validation Tool applies 1530 membership rules to the target electronic document. The membership rules check for the presence or absence of specific fields in the document. The membership rules determine and thus verify whether the first electronic document includes a set of fields required for electronic documents in a particular environment. In their simplest form, membership rules comprise a listing of fields that act as a check off listing for the inspected document. In one embodiment, the membership rules determine whether the main data section in the electronic document includes mortgage terms, loan features, lender information, borrower information, and the property address. These in turn may include additional elements whose presence can also be validated. Various alternatives can be provided includes those with more, less or different fields of information.

[0114] Membership rules can also specify the number of instances of a field (e.g., that a certain field or element must appear one time, no times or between ten and twelve times). Furthermore, membership rules can also be based on logical statements (e.g., if a certain field is present then there must be two of another field present. For example, where a particular entity such as a borrower is present, the presence of fields pertaining to the name, address or other related is determined by the membership rules) or field values (e.g., if the state of the document is “signed note” then there must be one to three signatures present, so the membership rules determine whether such is the case).

[0115] Validation in accordance with this embodiment of the present invention also accommodates various different types of documents, each compliant with a general electronic document format. For example, a general DTD can specify as optional components all of the fields that are potentially applicable with the electronic document generally. This can be referred to as a superset of fields that are required for a plurality of environments. Initial conventional XML validation of the electronic document will not prompt a failure where optional fields are absent from the document. Then, the membership rules can be used to verify whether the particular document has its particular required fields.

[0116] The Validation Tool also applies 1540 comparison rules to the target document. The comparison rules generally are used for determining whether one or more displays provided by the view portion substantially match the main data portion of the electronic document for a given set of values. The given set of values can vary. In one embodiment, they are those values that are required for the view to be considered a legally enforceable document, which will be dictated by conventional industry practice. Although any mechanism for comparing the values in the view and data sections can be provided, in one embodiment the comparison rules engage the previously described ARC elements that define links between the two sections in an electronic document. Particularly, the ARC elements point to such values, and accessing each ARC element provides a return verification of the matching condition (or lack thereof). Alternatively, the document may merely provide pointers to fields whose values are then accessed and retrieved to conduct a comparison of view and main data values external to the document.

[0117] The ARC elements may invoke conversion elements to commonly format the data and view values for comparison. Preferably, the comparison rules ensure that there is an exact correspondence between the information in the data section and the view section. The comparison rules indicate a failure if any of the compared values are not equal or if any value is missing.

[0118] Rules provided along with (or separate from) the comparison rules may also provide additional verifications beyond mere comparison, addressing the substance of values within a document. In one embodiment, a comparison rule specifies that the date of the recordation of a document must be after the date the document was signed. Another verifies that the purchase price of a property is greater than zero.

[0119] Still referring to FIG. 15, the Validation Tool then applies 1550 IDREF rules to the target document. IDREF rules examine the IDREFs, which are pointers to sections within a document. Among other things, the Validation Tool checks that all Ids (identifications given to sections of a document) within a document are unique (e.g., that there is only one section called “View01”), that all IDs which are pointed to within the document actually exist (e.g., that if a MAP element states that the data within “Data01” is linked to “View01” that “View01” actually exists), that all IDREFs point to IDs that are in appropriate locations (e.g., that ARC elements point to portions of a View Section), and that associated values are consistent with environmental expectations (e.g., that a name, and not a number, is associated as the value for a Borrower Name field).

[0120] In addition to the above, the Validation Tool may be configured to validate tamper seals as applied during the signature process. Validation in this instance would resemble standard PKI validation wherein the message digest or hash is checked to confirm the integrity of the electronic document and the digital certificate is validated against a certification revocation list. Rules may also combine comparison, IDREF, membership and logical expressions, and activate external programs to perform some validation tasks. For example, the signature integrity rule preferably invokes a conventional digital signature verification program.

[0121] Application of each of these rule sets returns a success or failure signal. A multitude of additional rules may be applied to validate an electronic document (e.g., verifying that the digital signature contains a certificate or is compliant with a specific signature algorithm). In one embodiment, an electronic document passes validation where all of the validation tests are passed. If it is determined 1560 that all validation tests passed, then a “validation stamp” entry is added 1570 to the document's AUDIT_TRAIL field in the Header Section, denoting that the document was successfully validated. Otherwise, an error message is generated 1580 and displayed, preferably listing the tests that were failed. If the Validation Tool is operated in a batch mode, the results are stored in a simple XML format.

[0122] As indicated, multiple different displays or views can be defined in the electronic document view section. Accordingly, the above validation is potentially applicable to these different views. A different set of validation rules may apply for each, or a single set of validation rules tailored for the multiple different defined displays can be provided. Regardless, the set of validation rules can be used to determine whether the second display provided by the view portion substantially matches the main data portion for its particular set of required values, and to support indication that the first electronic document is valid upon a determination that both the first and second displays substantially match the main data portion.

[0123] Referring now to FIG. 16A, a graphical user interface (GUI) 1600 for the Validation Tool is illustrated. The GUI includes a Document Panel 1610, a Rules Panel 1620, a Message Log Panel 1630, a Menu Bar 1640 and a Toolbar 1650. Documents which are loaded into the Validation Tool application appear in the Document Panel 1610 and rules contained in the validation suite, loaded from the DTD file, appear in the Rules Panel 1620. A record of the interaction between the user and the Validation Tool appears in the Message Log Panel 1630. The panels may be resized, hidden or rearranged. The Validation Tool is given commands through either the Menu Bar 1640 or the Toolbar 1650.

[0124] FIG. 16B depicts a screenshot of a Validation Tool GUI, as shown in FIG. 16A, in the process of validating a document “Note.XML.” The Document Panel 1610 displays a portion of the text of Note.XML. The Rules Panel 1620 lists the rules that are going to be used to validate Note.XML. Finally, the Message Log Panel 1630 presents a log of the activities of the Validation Tool. For example, as illustrated the Message Log Panel reflects that the file Note.XML has been successfully opened.

[0125] The following options are available through the Menu Bar's pulldown menus: File (exit the Validation Tool, open, reload or close document files); Edit (launch an external text editor or clear the Message Log Panel 1630); View (toggle the panels of the Validation Tool GUI or change the layout of the GUI window); Format (change font, typestyle or typesize of the text displayed in the Document Panel 1610); Trace (control validation and toggle tracing on and off); Window (create a new Validation Tool window or display the document in a browser); and Help (access the Validation Tool help files).

[0126] As shown in FIGS. 16A and 16B, the elements of the Toolbar shown as graphical buttons include Open Document, Edit, Reload Document, Enable Tracing, Reset Tracing, Start/Resume Validation, Step Forward, Step Back, Display HTML View, Split Vertically, Split Horizontally and the Contextual Help. The Toolbar provides push-button versions of the more frequently used commands for the Validation Tool. The Open Document button is used to load a document into the Validation Tool. The Edit Button is used to edit the contents of a document. The Reload Document button is used to reload the last document opened by the Validation Tool. The Enable Tracing Button activates the tracing feature, allowing the user to step through the validation process one rule at a time. The Reset Tracing Button is used to reposition the tracing mechanism to the beginning of a document. The Start/Resume Validation Button is used to validate the rest of the document. The Step Forward button is used to apply the next rule in the validation process. The Step Back button is used to apply the previous rule to the document. The Display HTML View button is used to display the View Section of a document. The Split Vertically and Split Horizontally buttons are used to change the window layout to vertical (as illustrated in FIGS. 16A and 16B, Document Panel 1610 and Rules Panel 1620 are side by side) or horizontal (Document Panel 1610 would be above the Rules Panel 1620). The Contextual Help button will bring up help information about specific parts of the Validation Tool interface.

[0127] The flow diagram of FIG. 17 illustrates an embodiment of a process 1700 for validating an electronic document. The user opens 1710 the Validation Tool program, and opens 1720 a document, such as by opening the described popup window or by selecting File-Open from a pull-down menu. The validation suite associated with the document is loaded 1730, and a summary of the validation rules appears in the Rules Panel. The text of the document is displayed in the Document Panel. If the Validation Tool is unable to open either the document or its associated validation suite, an appropriate error message will be displayed in the Message Log Panel. Otherwise, a message that the document has been opened will appear in the Message Log Panel.

[0128] The user then may select 1740 one of several task options 1750-1780. For example, the user may display 1750 a facsimile of the document as it would appear on paper by using the Windows-HTML View pulldown command or by pressing the View HTML button. An HTML browser window containing the formatted View Section of the document will appear on screen.

[0129] The user may then validate 1760 the entire document without tracing, by selecting the Trace-Start/Resume pulldown command or the Start/Resume Validation button. The Validation Tool will then check the entire document from beginning to end against all of the rules in the validation suite. If the validation is successful a message will appear confirming that the document is valid. A validation stamp may also be appended to the document. If the document fails a test, a message will appear informing the user that the document is invalid. Text describing the specific error or errors will appear in the Message Log Panel.

[0130] The user may apply 1770 the tracing functionality to document validation by selecting the Trace-Enable Tracing pull down command or by pressing the Enable Tracing button. At this point the Step Forward button and the Reset Tracing button will become active. The user may validate the entire document by selecting the Trace-Start/Resume pulldown command or the Start/Resume Validation button. The Validation Tool will then check the entire document. As the Validation Tool proceeds through the document, the portion of the document being examined and the current rule being applied are highlighted. When the validation is successful, the last rule set in the Rule Panel to be applied is highlighted. Otherwise, the rule set where an error occurred is highlighted.

[0131] With tracing turned on, the user may also perform a rule-by-rule validation of the document. This is useful if the user wants to isolate the source of an error in the document. To go forward one rule, the user may select the Trace-Step Forward pulldown command or press the Step Forward button. To go back one rule, the user may select the Trace-Step Back pulldown command or press the Step Back button. To restart the validation of the document, the user can use the Trace-Reset pull down command or the Rest Tracing button.

[0132] The user may also edit the contents of a document by selecting the Edit-Edit Document pull down command or the Edit Document button (1780). This will launch the associated text editor. This is useful if the user wishes to make modifications to the document or to attempt to rectify a problem that the Validation Tool has identified. The user may terminate 1790 the Validation Tool application as indicated.

[0133] Thus embodiments of the present invention provide validation of electronic documents. Although the present invention has been described in considerable detail with reference to certain embodiments thereof, the invention may be variously embodied without departing from the spirit or scope of the invention. Therefore, the following claims should not be limited to the description of the embodiments contained herein in any way.