WO2000052596A2

WO2000052596A2 - Automated form generation into an advanced page layout format with embedded field definitions

Info

Publication number: WO2000052596A2
Application number: PCT/US2000/005822
Authority: WO
Inventors: J. Joel Faul; Mark W. Seamans
Original assignee: Cardiff Software, Inc.
Priority date: 1999-03-04
Filing date: 2000-03-06
Publication date: 2000-09-08
Also published as: AU3395500A; WO2000052596A3

Abstract

A method and system for creating and interpreting forms having embedded interpretable code. The form may be transmitted across a global computer network and received at a remote location. Data fields included on the form are filled out, either fully or partially and either electronically or manually, and thereafter sent to a central location. The embedded interpretable code is accessed for form interpretation. Interpretation of the code allows the form at the central location to be processed for data extraction. Sending the form to the central location may be done through mail, fax, electronic mail or via HyperText Transfer Protocol (HTTP) over the global computer network.

Description

AUTOMATED FORM GENERATION INTO AN ADVANCED PAGE LAYOUT FORMAT WITH EMBEDDED FIELD DEFINITIONS

Background of the Invention

Field of the Invention

The present invention relates to automated form generation and interpretation. More specifically, it relates to generating a page layout format form that can be completed electronically, manually or a combination of manually and electronically, and then be automatically interpreted by a computer.

Description of the Related Technology

In the burgeoning area of networking, particularly a global computer network such as the World Wide Web or Internet, the exchange of information has been increasing at a tremendous rate. However, to date nearly all of the focus in development of the Internet has been put into delivering content to end-users. As a result, the Internet provides an excellent way for delivering graphics, text, video, sound and more, and such technology is constantly improving. Yet, despite the fact that the Internet is a great source for collecting data, development has been relatively weak in that area.

Collecting of data is enhanced by interactivity and because of reach and availability to so many users around the world. There are many reasons for collecting data over the Internet; perhaps the most compelling being e-commerce. In any commercial transaction, data must be exchanged to perfect the deal. Payment. shipping, ordering and personal information must be received to complete the electronic transaction. Similar types of data are gathered for Internet-related services and for entities that simply gather information on-line. For each of these, forms must first be filled out or completed by the end-user so as to collect the needed data.

The authors of HyperText Markup Language (HTML), a computer language used for defining an electronic page viewable in an Internet web browser, provided mechanisms to allow programmers to create web-based forms and the ability to enter information. These authors also defined mechanisms for programmers to be able to capture the data from these forms. HTML programmers have taken advantage of these mechanisms to create many of the forms that are in use today on the Internet.

The disadvantage of using HTML for Internet based form processing is that the skills of a programmer must be employed to perform all of the necessary functions, from creation of the form all the way through validation and collection of the data. For instance, in form creation, the skills of a programmer with knowledge of computer languages, such as HTML and Java, is needed. This is a costly procedure requiring a person with a very specialized expertise.

Form data typically requires validation before collection. Without validation, the collected data may contain a large number of errors, thereby ultimately defeating the purpose. To perform validation checks on the data, again, the high level skills of a computer programmer are needed. Client-specific scripting programs can be written that perform certain data validations, such as range checking, field length enforcement, character level type checking, etc. However, a further problem can arise in that some web browsers are not compatible with certain scripting languages. Also, if script is called from a server location referenced by a universal resource locator (URL), feedback delays are often experienced. Similar problems are encountered in a final step of copying data from the form fields and into a database.

Furthermore, when data needs to be collected from both electronic sources and from paper sources, a system is often put in place to handle one of these sources with the other handled as an after-thought. The other data source may become a significant source of problems as adaptation of the original system is attempted. In some cases. two disparate systems are put in place to accept data - one system for electronic forms and one for paper forms. In such cases, a significant amount of work is duplicated as the form undergoes design for both paper and electronic filling. Also database connections must be set up for both systems. Usually separate servers are also required to handle the data from these different sources. This duplication of resources significantly increases the cost of collecting the data.

A solution is desired that eliminates the need for a programmer to generate client-specific programs for form creation and interpretation. It is desirable that through menu-driven tools of a software application, a user can create a form having embedded coding suitable for both electronic and paper forms. The form coding would be used in a form processing system, including identification, validation and interpretation of data, and would eliminate the need for client-specific scripting programs. Submittal of forms would be done on-line without the need for scripting programs that currently are necessary to perform the noted processing features.

Summary of the Invention

The present invention provides a method and a system for a layperson to create electronic forms with embedded interpretable codes without the necessity of programming in a computer language. The user only needs to become familiar with the menu-driven tools of a software application in order to create forms that may be used in a data processing system, such as a data capture system. The form may be submitted for interpretation via mail, Email, HTTP or fax. The forms may be created using page layout formats such as Forms Data Format (FDF) or Portable Document Format (PDF) that can be viewed and filled out while in a web browser. Embedded coding can be added to these formats and the need for scripting of HTML-based forms is thereby negated. The method and system are integrated so as to permit submittal of forms and data to a central location for data processing using various modes including, fax. postal mail, through HTTP via a global computer network and via electronic mail. Only one system is needed to support all modes of submittal. One aspect if the invention includes a method of creating and interpreting forms, comprising generating a page layout format form having embedded interpretable codes, transmitting the page layout format form a plurality of times across a global computer network, receiving the transmitted page layout format form at a plurality of remote locations from the global computer network, sending more than one completed form to a central location, wherein at least a first one of the received forms has been completed electronically and at least a second one of the received forms has been completed manually, and automatically interpreting the completed forms by accessing the embedded interpretable codes.

An additional aspect of the invention includes a method of producing a form with embedded codes, comprising generating a page layout format form, embedding interpretation codes into the page layout format form resulting in an automatically interpretable form, transmitting the automatically interpretable form across a global computer network to a plurality of remote locations, and providing the automatically interpretable form for completion at the remote locations, wherein each of the forms is configured for being completed electronically, being completed manually, and being completed at least partially electronically and at least partially manually.

Another aspect of the invention includes a method of creating and interpreting forms, comprising generating a page layout format form configured for being completed electronically and being completed manually so as to permit form completion, transmitting the page layout format form across a global computer network to a plurality of remote recipients, providing completion information to the plurality of page layout format forms received by remote recipients, sending at least one electronically completed form and at least one manually completed form to a central location, and automatically interpreting the entered information on the completed forms.

Yet another aspect of the invention includes a system for handling page layout forms, comprising a central computer, a software program executing on the central computer and being configured for interactively creating a page layout format form having embedded interpretable codes, wherein the page layout format form is configured for being completed electronically, being completed manually, and being at least partially completed electronically and partially completed manually, a communications device associated with the central computer and being configured for sending the page layout format form across a global computer network, and a remote computing device configured for receiving the transmitted page layout format form and for at least partially completing the page layout form electronically.

One more aspect of the invention includes a system for creating and interpreting forms, comprising a central computer comprising a software program executing on the central computer and being configured for interactively creating an advanced page layout format form having embedded interpretable codes, wherein the advanced page layout format form is configured for being completed electronically and being completed manually, a communications device configured for sending the advanced page layout format form across a global computer network to a remote recipient, and an interpretation program executing on the central computer being configured for receiving a completed form and being configured for automatically interpreting the completed form, and a remote receiver configured for receiving the transmitted advanced page layout format form.

Brief Description of the Drawings

Figure 1 is a top level functional diagram of the system of the present invention.

Figure 2 is a flow diagram of the submit on-line function shown in Figure 1.

Figure 3 is a diagram of a form designer process for the designer shown in

Figure 1.

Figure 4 is a diagram of a form reader process for the reader shown in Figure 1. Figure 5 is a diagram of a form verifier process for the verifier shown in Figure 1.

Figure 6 is a diagram of a PDF+Forms format process performed by the system of Figure 1.

Figures 7A and 7B are a flowchart of a process for exporting a PDF form as

described in Figure 6.

Figure 8 is a collection of exemplary screen displays or portions of screen

displays while exporting a form to the PDF format.

Detailed Description of the Preferred Embodiments

The following detailed description of the preferred embodiments presents a description of certain specific embodiments of the present invention. However, the present invention can be embodied in a multitude of different ways as defined and covered by the claims. In this description, reference is made to the drawings wherein like parts are designated with like numerals throughout.

This description incorporates by reference U.S. Patent No. 5,943,137 entitled Unified Method Of Creating And Processing Fax Forms and U.S. Patent No. 5,555,101 entitled Forms Creation And Interpretation S> stem.

The following description begins with a general overview of the invention in Figure 1 and then details the major components or component steps in succeeding figures. Top Level Function

Referring to Figure 1 , a top-level process 100 embodying the present invention will be described. Users can create a page layout format form from the beginning using a form designer 102 capable of electronic storage. (One example of a form design tool that generates forms is called TELEform, which is available from Cardiff Software.) Users can also scan a paper form (of potentially unknown design origin) and create fields within designer 102 that correspond with the locations where users would fill out the paper form that was scanned. The designer 102 will be further described in conjunction with Figure 3.

When the form design and configuration is completed or the paper form is scanned into the designer 102, the form can be exported to another format, such as Forms Data Format (FDF) or Portable Document Format (PDF) by selecting an export utility 104 from a form export menu. This may be done using an export conversion tool, such as Acrobat Distiller or Acrobat PDF Writer, or through a low-level program that interfaces with the application protocol interface (API) of PDF in the case of a PDF export, for automatic generation of the PDF form. The choice can be made available as an export option, which may be selected at the time of export. In other embodiments, other page layout formats may be used, such as an advanced page layout format. The remainder of the description will refer to export of a PDFform.

Once in the PDF format, a PDF form can be opened in a viewer capable of reading PDF files, such as Adobe Acrobat Reader 4 or Adobe Acrobat 4. The PDF file will contain the precise look of the original form from the designer 102 or the scanned paper form. The form fields of the PDF form will be overlaid on the designer form so that they may be filled out. The form can then be submitted on-line at a function 122; that is. while the user is connected to a networking system capable of data transfer, such as a global computer network. One example of a global computer network is the Internet. Deployment of the PDF based export of the form and data is similar to HTML based export of the form. However, unlike the HTML export, users are required to have a PDF viewer to open and fill out the form.

To begin the process using the created PDF forms, those PDF forms must be transmitted to a user at a remote location (the person or entity that is destined to fill out the form) so that they may be completed or filled out. The present invention provides at least two methods, one off-line and one on-line, in which a PDF form can be received. To permit users to fill out forms off-line, a user using electronic mail 116 can receive the PDF form. From there, the form can be viewed in a PDF viewer 118 and filled out. Also, the user can print the form and fill it out with hand printing or handwriting. The other method, if chosen by the user, is to fill out the PDF form on a visual display screen, either fully or partially, while it is displayed by a web browser 108. However, whether received via Email 116 for off-line completion or from web browser 108 after being completed on-line, the PDF form can be submitted via Email

120.

After receiving the transmitted form and filling it out, the user submits or sends the PDF form to a central location for further processing. The present invention provides many methods for submitting the PDF form and data. In one embodiment, the three main paths for submittals are to submit on-line, submit via Email using protocols such as POP3, MAPI or SMTP, and to print the PDF form and either fax it or send it via a mail service, for example, the user may be given choices in the export setup dialog. The user may also be given the option of selecting "auto-detect^"", where, the system is programmed to detect, based on certain configurations, which method should be used for submittal. In one embodiment, ^L submit on-line' is the default.

If the user should either submit on-line 122, print and fax 110, or print and send

112. the PDF form is first stored on a web server 106. The PDF form is callable such that when a specific URL, which specifies the physical location of the PDF form, is entered in the web browser 108, the viewing tool selected is executed in web browser

108 and the PDF form is received therein. After filling out the form, either fully or partially, the user then decides whether to submit on-line 122, print and fax 110, or print and send 112. If the user decides to print and fax 110 the filled out PDF form, the user prints the form to a printer and faxes the printed form to a specific destination. If the user decides to print and send 112 the filled out PDF form, similarly, the user will print the PDF form to a printer. But instead of faxing the PDF form, it is sent to the specified destination where it is scanned for electronic submission to a reader 128 such as a TELEform reader. The reader will be further described in conjunction with Figure 4.

Another option that the user has is to Email 120, such as using any of the protocols noted above, the PDF form on-line through a server, which is used as an Email handler 124, and on to an Internet server 126, such as a TELEform Internet server. Yet, another on-line method for submittal is to post the form data to a server data handling program identified by a universal resource locator (URL), such as a Common Gateway Interface (CGI) program, and the submit the data on-line 122 to the

Email handler 124 or to a directory file. From there, PDF form and data is sent to Internet server 126.

Depending on the submittal method, different processes may be used to obtain the form data. In one embodiment PDF form, which is printed and faxed 1 10, will be transmitted as an image to the reader 128. The reader 128 identifies the form type received and matches the type to a form template. The form template comprises a plurality of fields, each having at least one attribute. Some attributes may be position information or field name, type, location or size. Using the form template, the reader 128 reads the information on the form. Such information may include machine-printed characters, hand-printed characters, check marks, filled bubbles, circled responses, handwriting, and other markings.

Similarly, a PDF form that is printed and sent 112 is later scanned 114 so that an image may be transmitted to the reader 128 for processing. PDF forms and data that are sent via Email 120 or submitted on-line 122 to the Internet server 126 are ultimately gathered by the reader 128 for processing. Whether the form is received by the reader 128 through on-line submittal to the Internet server 126, from the fax 110 or via the scanner 114, the data can be put through a verifier 130 that applies a consistent set of validations. Thus, no matter how the data arrives, it will undergo the same logical tests for recognition accuracy. In some instances, based on system configuration and PDF form design, the verifier 130 may be bypassed. If necessary, data sent to the verifier 130 will be modified in the reader 128 if found to be in error. But regardless of whether or not the data is modified, and regardless of whether the verifier 130 is bypassed, the data may be exported to a database 132. The verifier 130 will be further described in conjunction with Figure 5.

Submit On-line

Referring to Figure 2, the operation of the web browser 108, the submit on-line function 122 and Email from a client 120 to an Email handler 124, i.e., submission online from web browser 108 as shown in Figure 1, will be described. When a user presses the submit button 202 after completing a PDF form on-line, one of two methods is used to send the form and data if the user has configured the form to submit 'Text with/PDF'.

The method is determined at a decision state 204. One method is to send the form via Email. If this option is selected the form is sent via an Email protocol, such as MAPI 206. to the Email handler 207.

The second method is to post the data using a universal resource locator or URL at state 208. Here the data is formatted at state 210 by a computer program, such as a TELEform Internet Solution available from Cardiff Software. Once formatted, the data is Emailed via an appropriate Email protocol, such as SMTP mail 218, to the Email handler 207, or it is written to a file director)- 216. Data, which is written to file directory 216 is polled and collected by a directory search service 217. such as that included in TELEform Internet Solution, for processing. The decision to write to a file directory 216 or send via SMTP mail 218 is configured into the system according the needs of the user.

Designer

Referring to Figure 3, a form designer process for the form designer 102 will be described. The form designer 102 enables the user to create and configure new forms at block 304 or to modify existing forms at block 310. New forms are created using the form designer^'s tools and objects. In one embodiment, new forms may be of at least two form types. One such form type is labeled the traditional form 306. The traditional form 306 includes four standard cornerstones and a Form ID Block. A second form type allows versatility in identification and is termed a VERSIform 308. The VERSIform 308 includes four identifying marks which the user can select. These marks include but are not limited to small squares, circles and triangles. An identifying number may also included on this form type.

Existing forms 310 may also be modified using the form designer 102. Existing forms 310 are modified from a form image. This image may be in existence or generated by scanning a form 302 into the designer 102. Forms already created in the form designer 102 and exported may also be imported into the designer 102 for editing and re-export.

Once a form exists in designer 102. it may be exported at block 312 in multiple formats, depending on the user^'s needs, or it may be printed. Some of the export formats, selected from a 'Export a Form^" dialog box, include TELEform. Adobe PDF 318, and HTML 316.

Forms are created with embedded interpretation codes that provide for automatic interpretation of the form. Such code can include form identification and form template information that comprises at least one attribute for each of a plurality of fields. These were described above. Form Reader

Referring to Figure 4 and Figure 1, a form reader process 400 for the form reader 128 will be described. The form reader 128 recognizes form types and interprets hand and machine printed text, mark sense (OMR) fields and bar codes, and captures zones scheduled for keying (Selective Key From Image (SKFI) zones) on the forms.

Multiple methods exist to obtain the forms and data for processing at the reader 128.

Two of the off-line methods described above enter the PDF form and data to the reader 128. The first method is via print and fax 110. A printed PDF form is faxed at block 404 to create an electronic image of the PDF form and data. The resulting image is sent to the reader 128. The second method is via print and send 112, where the printed paper is scanned at block 406 to generate an electronic image. The resulting image is sent to the reader 128.

The reader 128 may also be configured to poll directories for received images at block 408. Once images are determined to be in the designated directory, they can be copied or moved to the reader 128 for processing.

Another method to receive forms is through a form product Internet solution 402, such as the TELEform Internet Solution program. Form product Internet solution 402 sends data to reader 128 for processing, ensuring that regardless of the method used, be it print and fax 110, print and send 1 12, or submit on-line 122, the form uses the same logic and validation processing. What happens to the data and how it is handled depends on the form configuration options, which are set when the form was designed.

If the form has no fields or characters needing review when the form is interpreted, the data is sent directly to a data warehouse 412 and/or auto-exported to a predetermined database 410. If the form has characters that caimot be interpreted or fields that have failed validation, or are fields designated to always be reviewed, the field is marked for review and the form is held for verification at block 414.

A copy of the form image may also be made and stored to an archive and retrieval system 416. In the case of a PDF or HTML form, the data can be merged onto the form template, creating an image for storage. This can be used for later reference by the user. A custom data export option is available at block 418. One final option is to create a printed document 420.

Verifier

Referring to Figure 5, a form verifier process 500 will be describe. The verifier

130 is the application used to correct forms. Forms, attachments, and data at block 502 are all input to verifier 130. Attachments are images not classified as forms in the system. Once all forms have been corrected and saved, the data and images may be sent to a number of devices and/or systems for storage and usage.

Verified data may be sent to a data warehouse 504, a database 506 or a custom data export 508. The system allows data to be sent to one or all of the above. Images and data may be sent to an archive & retrieval system 512 or printed as a document 510 if needed.

PDF+Forms

Referring to Figure 6, a PDF+ Forms format will be described. PDF forms are created in the form designer 102 where export selection is made. Once the form designer form is completed and configuration settings are set, the form can be exported at a decision state 604 to create a PDF form 606. In one embodiment, the created PDF form can be distributed at block 608 to the user in three different ways. The form may be faxed 610 to a user, printed as a paper document 614 and given or sent to a recipient, or mailed electronically 612. The email method 612 was discussed above as Email 116.

Forms which have been Emailed or otherwise distributed in the PDF format may be filled out at block 616 and submitted at block 620, or partially filled out and then printed at block 618, or filled out and re-sent electronically at block 622. If the

PDF form is partially filled and printed at 618, the form can be forwarded to another user for further completion of the form..

Once the PDF form is completed, it can be submitted on-line via a HyperText Transfer Protocol (HTTP) on the global computer network or Email at block 622 or printed and faxed at block 624, or printed and scanned at block 626.

PDF Export

Referring to Figures 7A and 7B, a PDF Export process 700 will be described beginning at a start state 701. In the form designer 102, as stated above, a user may choose to export a form as a PDF form. When this option is chosen, an attempt is made to open the form at a decision state 702. If the attempt to open the desired form fails, the process exits at a state 704.

Upon successful opening of the form at decision state 702. the form is printed to a printer driver at state 706, such as PDF Writer or a Postscript driver. In one embodiment, the driver is selected by the user. If a PostScript driver is selected, the Acrobat Distiller program may be run at state 706 to convert the document from the PostScript format to the PDF format.

After the PDF file is created, an attempt is made to open the PDF file at a decision state 708. If unsuccessful, the process exits at state 704. Upon successful opening of the PDF file at the decision state 708, a list of objects from the form is made at state 712 based on labels embedded in features of the form created or modified by the designer 102. This list of objects is generally a list of fields and groups of fields from the form but can include other features. The object list is traversed, one object at a time, in the remaining steps of the process 700.

Some fields require special fonts for display. Those fonts are generated at state 714 after the object list has been created.

A determination is made at a decision state 716 regarding an object from the list. If it is not the last item in the list of objects, the process 700 proceeds to a decision state 718. A determination is made at decision state 718 as to the whether an object requires the generation of a PDF field, which is a field that is editable in a PDF viewer. This too is determined tlirough embedded coding in the designer 102 created/modified form. If the object requires generation of a PDF field, the object is exported to the PDF file. Otherwise, the next object in the list is examined.

If the object examined at decision state 718 is an object that requires generation of a PDF field, it is exported and the flow then proceeds to a decision state 720 where a determination is made as to whether the object is actually a group of objects. (A group of objects contains another list of objects). If the object is a group, then the group's list is traversed beginning at decision state 716 in the same manner as the main object list for the form is traversed.

If the object is the last item in the list as determined at decision state 716, execution continues at decision state 740 to determine if the object was part of a group. If it is part of a group, process 700 continues at decision state 716 for traverse just as other groups and the main object list.

If the object examined at 720 is not a group, then the flow proceeds to a decision state 722 where a field template mask is examined. Some fields with a template mask (such as NNN-NN-NNNN for a Social Security Number) may need to be broken up into sub-fields. If the field examined at decision state 722 is this type of field, process 700 proceeds to a decision state 724 where the first sub-field is identified and the process proceeds back to decision state 722. Since sub-fields are not generally broken up into further sub-fields, process 700 at decision state 722 proceeds to state

726 for the first sub-field.

Whether the flow is handling a sub-field or a full field, the PDF field, position and properties are generated at state 726. State 726 creates a field that can be overlaid on the PDF document at the same relative location as where the field exists in the designer 102.

The field or sub-field is examined at a decision state 728 to see if any drawing code is needed to represent the field accurately. If so, the drawing code is generated at state 730.

In either case of decision state 728 process 700 advances to a decision state 732 where the field or sub-field is examined to see if a pre-fill value is defined for the field.

This is done when the form designer wishes a field to contain predetermined characters. If so, the designer assigns this pre-fill value during design for the form. If a pre-fill value is defined, the value is set within the field or sub-field at state 734.

In either case, the flow proceeds to state 736 where any function calls necessary to implement validations such as type checking, length checking and range checking are generated. Such function calls can be derived through a computer program using languages such as JavaScript.

If the object was determined to be a sub-field at a decision state 738, process

700 proceeds to decision state 724 where the next sub-field is determined. If another sub-field is needed, process 700 proceeds to decision state 722 and repeats. If another sub-field is not needed, then process 700 advances to state 726 where, in one embodiment, all of the PDF code and scripts are generated for the parent field of the sub-fields. If the object was not a sub-field or the parent field of the sub-fields was just handled at decision state 738, then process 700 continues at decision state 716 where the next field in the current group or the next field in the main form list is examined.

5 Returning to decision state 740, if the last object was determined at decision state 740 to be part of a group, then the group is finished and the next object in the parent group or the main form list is examined at decision state 716 and the flow is as discussed earlier. If the last object at decision state 740 was not part of a group but was instead an object on the main form list, then all of the form objects have been created.

10 Process 700 moves to state 742 where submit and reset buttons are generated for the form. These allow a user who fills out a PDF form and submits it on-line, via posting to a server data handling program identified by URL or through Email to do so with the click of a mouse or other selection device. Subsequently, all hidden fields and fields needed for control purposes in processing the form, such as the form identification

15 (I.D.), are generated at state 744.

The fields are then sorted at 746 according to the tab order defined in the designer 102 so that the same tab order will be honored in the PDF form. Document level JavaScript (i.e., not field specific), or other similar computer code, is generated at 20 state 748. This provides a way for individual field scripts which are used to perform validations to call a master program having shared code. Process 700 completes at an exit state 750.

Referring to Figure 8, exemplary on-screen displays are shown while 25 performing the steps for exporting a form to the PDF format for one embodiment of the invention.

Conclusion

3 ;>0

Specific blocks, sections, devices, and modules may have been set forth. However, a skilled technologist will realize that there are many ways to partition the system of the present invention, and that there are many parts or components that may be substituted for those listed above. For example, the export need not to PDF format nor viewed by a PDF viewer. Any format capable of being viewed in a web browser and written to with overlaid fields can be used.

While the above detailed description has shown, described, and pointed out the fundamental novel features of the invention as applied to various embodiments, it will be understood that various omissions and substitutions and changes in the form and details of the system illustrated may be made by those skilled in the art. without departing from the intent of the invention.

Claims

WHAT IS CLAIMED IS:

1. A method of creating and interpreting forms, comprising: generating a page layout format form having embedded interpretable codes; transmitting the page layout format form a plurality of times across a global computer network; receiving the transmitted page layout format form at a plurality of remote locations from the global computer network; sending more than one completed form to a central location, wherein at least a first one of the received forms has been completed electronically and at least a second one of the received forms has been completed manually; and automatically interpreting the completed forms by accessing the embedded interpretable codes.

2. The method defined in Claim 1. wherein sending includes sending a third one of the received forms that has been at least partially completed electronically and at least partially completed manually.

3. The method defined in Claim 1. wherein sending comprises faxing or mailing the completed form.

4. The method defined in Claim 1, wherein sending comprises electronic mailing the completed form.

5. The method defined in Claim 4. wherein electronic mailing comprises processing one of the following protocols: POP3. MAPI, or SMTP.

6. The method defined in Claim 1. wherein sending comprises transmitting the completed form via a HyperText Transfer Protocol (HTTP) on the global computer network.

7. The method defined in Claim 1, wherein the page layout format is Forms Data Format (FDF) or Portable Document Format (PDF).

8. The method defined in Claim 1, wherein the second one of the received forms that has been completed manually -emprises completing the form by handwriting or hand-printing.

9. The method defined in Claim 1, wherein the page layout format is an advanced page layout format.

10. A method of producing a form with embedded codes, comprising: generating a page layout format form; embedding interpretation codes into the page layout format form resulting in an automatically interpretable form; transmitting the automatically interpretable form across a global computer network to a plurality of remote locations; and providing the automatically interpretable form for completion at the remote locations, wherein each of the forms is configured for being completed electronically, being completed manually, and being completed at least partially electronically and at least partially manually.

1 1. The method defined in Claim 10, wherein the interpretation codes include a form identification.

12. The method defined in Claim 10, wherein the interpretation codes include form template information.

13. The method defined in Claim 12. wherein the form template information comprises a plurality of fields, wherein each field comprises at least one attribute.

14. The method defined in Claim 13, wherein each field includes one of the following types of entry data: machine -printed characters, hand-printed characters, check marks, filled bubbles, circled responses, barcodes, signatures, or handwriting.

15. The method defined in Claim 13, wherein the attributes of each field comprise position information.

16. The method defined in Claim 13, wherein the attributes of each field comprise field name, type, location, and size.

17. The method defined in Claim 10, wherein providing includes displaying the automatically interpretable form on a visual display screen.

18. The method defined in Claim 10, wherein providing includes printing the automatically interpretable form.

19. The method defined in Claim 10, wherein providing includes displaying the automatically interpretable form on a visual display screen and subsequently printing at least a partially completed form.

20. A method of creating and interpreting forms, comprising: generating a page layout format form configured for being completed electronically and being completed manually so as to permit form completion; transmitting the page layout format form across a global computer network to a plurality of remote recipients; providing completion information to the plurality of page layout format forms received by remote recipients; sending at least one electronically completed form and at least one manually completed form to a central location; and automatically interpreting the entered information on the completed forms.

21. The method defined in Claim 20, wherein automatically interpreting includes accessing embedded interpretable codes included on the page layout format form.

22. The method defined in Claim 20, wherein sending includes sending a form that has been at least partially completed electronically and at least partially completed manually.

23. The method defined in Claim 20, wherein sending the electronically completed form is from a location that is different than a location sending the manually completed form.

24. The method defined in Claim 20, wherein sending the electronically completed form is from a location that is the same as the location sending the manually completed form.

25. A system for handling page layout forms, comprising: a central computer; a software program executing on the central computer and being configured for interactively creating a page layout format form having embedded interpretable codes, wherein the page layout format form is configured for being completed electronically, being completed manually, and being at least partially completed electronically and partially completed manually; a communications device associated with the central computer and being configured for sending the page layout format form across a global computer network; and a remote computing device configured for receiving the transmitted page layout format form and for at least partially completing the page layout form electronically.

26. The system defined in Claim 25, additionally comprising an interpretation program executing on a forms interpretation computer receiving a completed form and being configured for automatically interpreting the completed form.

27. The system defined in Claim 26, additionally comprising a communications device associated with the remote computing device and being configured for sending the completed form to a central computer.

28. The system defined in Claim 27, wherein the central computer and the forms interpretation computer are the same computer.

29. The system defined in Claim 27, wherein the communications device handles a facsimile protocol.

30. The system defined in Claim 27, wherein the communications device associated with the remote computing device handles an electronic mailing protocol.

31. The system defined in Claim 27, wherein the communications device associated with the remote computing device handles a HyperText Transfer Protocol

(HTTP).

32. The system defined in Claim 26, wherein the page layout format form is printed and at least partially completed manually.

33. The system defined in Claim 32, wherein the completed form is sent by a postal service to the location of the forms interpretation computer.

34. The system defined in Claim 25. wherein the central computer includes a memory configured for storing the page layout format form.

35. A system for creating and interpreting forms, comprising: a central computer comprising: a software program executing on the central computer and being configured for interactively creating an advanced page layout format form having embedded interpretable codes, wherein the advanced page layout format form is configured for being completed electronically and being completed manually,

-ZJ- a communications device configured for sending the advanced page layout format form across a global computer network to a remote recipient, and an interpretation program executing on the central computer being configured for receiving a completed form and being configured for automatically interpreting the completed form; and a remote receiver configured for receiving the transmitted advanced page layout format form.

36. The system defined in Claim 35, wherein the remote receiver comprises a remote computer associated with the remote recipient.

37. The system defined in Claim 35, wherein the remote receiver comprises a communication device configured for sending the completed form to the central computer.

38. The system defined in Claim 35, wherein the remote receiver includes a facsimile function.

39. The system defined in Claim 35, wherein the remote receiver includes a mail address.

40. The system defined in Claim 35, wherein the advanced page layout format form is additionally configured for being at least partialh' completed electronically and at least partially completed manually.