Data processing: software development – installation – and managem – Software program development tool – Code generation
Reexamination Certificate
1998-12-31
2002-10-29
Dam, Tuan Q. (Department: 2122)
Data processing: software development, installation, and managem
Software program development tool
Code generation
C717S107000, C717S108000, C707S793000, C707S793000
Reexamination Certificate
active
06473892
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates in general to a system for automatically generating documents and in particular to a document assembly system that automatically selects document language in response to input data indicating the nature of a transaction to be documented, describing the parties to the transaction and circumstances surrounding the transaction.
2. Description of Related Art
A form is a template for creating a document in which text can be either fixed when the form is created or part of a variable field to be determined each time a document is created from the form. A simple preprinted form includes the fixed text in preprinted form and represents variable fields with blank spaces, optional words, check boxes and the like to be filled in or selected to create a document. For example a preprinted power of attorney form may include a paragraph such as the following:
residing at
do hereby appoint
as (my/our) attorney in fact to:
The first blank is filled with the name or names of the party or parties signing the document, the second blank with their address, and the third blank with the name of the person being appointed as attorney. The person filling out the form may strike either “my” or “our” depending on the number of parties. This fill-in-the-blank form system works well for short, simple forms but can be tedious for long forms and produces a document that is partially hand written.
A form can be implemented as a data file to be edited by a word processor. U.S. Pat. No. 5,313,394 issued May 17, 1994 to Clapp teaches that a variable field in a form can appear as an instruction defining the nature of the variable field. For example the above power of attorney form paragraph would appear as follows:
[Party's or Parties' Name(s)] residing at [Party's Address] do hereby appoint [Attorney's Name] as [my/our] attorney in fact to:
Employing a word processing system to create a document from the form, a user scrolls through the form and replaces each instruction or variable name in brackets with data that is appropriate for the document being created. Clapp teaches that an instruction should be embedded in the document in front of the optional text to indicate the conditions under which the optional text is to be included in the document. The end of the optional text is marked by a code such as {END CONDITION}. For example the power of attorney form may include the following lines:
{The following text will be included if this power of attorney is granted for a specific period of time.} This power of attorney shall become effective on [Effective date] and shall terminate on [Expiration date]. {END CONDITION}
When creating a power of attorney document, the user deletes the conditional instruction surrounded by brackets “{ }” and the END CONDITION code, and either deletes or retains the optional text based on the decision outlined in the conditional instruction. The difficulty with such a system is that it requires the user to manually scroll through and edit the entire form which includes all possible language that may be included in the document to be produced. This can be slow and tedious for large forms.
In a “mail merge” system a form is defined by a data file in which a merge code represents each variable field. To create a document, the user or data base program first generates a “merge file” listing text that is to be inserted into the form in place of each merge code in order merge codes appear in the form. The following is an example of the power of attorney paragraph in mail merge form:
{circumflex over ( )}MERGE residing at {circumflex over ( )}MERGE do hereby appoint {circumflex over ( )}MERGE as {circumflex over ( )}MERGE attorney in fact to:
A suitable merge file would include a list of merge data in the following order:
John Smith
555 S.W. 6th Ave, Portland Oreg.
Aaron Jones
my
After creating the merge file, the user invokes the mail merge system and provides it with the name of the form file and the name of the merge file. The mail merge system then creates a document by replacing each {circumflex over ( )}MERGE code in the form with corresponding data included in the merge file. This system does not require the user to manually edit the form, but it may require the user to provide the same information many times in the merge file. For example if there are ten places in a document where the user has to choose between “my” and “our”, then the merge file will have to make that choice ten times. Also the user or data base system creating the merge file must be made aware of any changes to the form so as to properly adjust the order in which the data appears in the merge file.
U.S. Pat. No. 5,446,653 issued Aug. 29, 1995 to Miller et al, describes a document generation system that separately stores all paragraphs that might be used in creating an insurance policy document. A policy form is primarily a list of references to the paragraphs that may be included in a policy document. The document generation system merges necessary paragraphs into a policy document as it creates the document. A user supplies the system with data that the system needs to determine which paragraphs are to be included in the document. Such data may, for example, indicate the types of coverage and endorsements, the state in which the policy is to issue, etc. Thereafter, when creating the document, the system invokes a set of rules by which it determines from the input data which paragraphs are to be included in the document. For example if the input data indicates that the policy is to include a certain type of coverage, a rule will tell the system which paragraphs must be included in order to implement that kind of coverage.
U.S. Pat. No. 5,729,751 issued Mar. 17, 1998 to Schoolcraft describes an interactive document assembly system in which codes are embedded in a form at points where a decision must be made as to whether to include or delete a clause, insert a variable field or make a word choice. Each code value is associated with a set of instructions stored in an instruction data base. When creating a document, the system sequences through the form, and whenever it encounters a code it obtains and executes the instructions associated with the code. The instruction may tell the system to query a user for input, or may automatically make choices based on previous queries. For example the power of attorney paragraph would appear as follows:
~4 residing at ~9 do hereby appoint ~3 as ~11 attorney in fact to:
The instructions invoked by codes ~4 and ~9 will tell the system to query the user to input the name or names of the parties and the parties address. The instruction referenced by code
3
may prompt the user for an attorney name. The instructions referenced by code 11 could tell the system to query the user to select between “my” and “our” or could automatically select between “my” and “our” based on whether the user provided more than one party name in response to an earlier query. In addition to handling choice of words, instructions referenced by an embedded code may also determine whether a paragraph should be merged into the document based on user supplied data. One difficulty with this system is that it requires the user to be available for responding to questioning when the document is being created. Since the questions are asked in the order of occurrence as the system scans through the form, the system is not easily adapted for use with user-friendly data entry screens. While such a document generation system is very flexible, a system capable of producing a large number of complex documents could require hundreds of such codes. Programmers would find it difficult to update and maintain such a system without duplicating the content codes.
What is needed is a fully-automated, easily-maintained and easily-updated document generation system that obtains all of the information it needs to prepar
Bedell Daniel J.
Dam Tuan Q.
Das Chameli C.
Harland Financial Solutions, Inc.
Smith-Hill and Bedell
LandOfFree
Data driven, dynamic language document assembly system does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Data driven, dynamic language document assembly system, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Data driven, dynamic language document assembly system will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2990239