A system for presenting and executing a multiplicity of interactive forms as a single document includes a server having one or more copies of a multi-form package and configured to deliver a copy of the package to a requesting device upon request. The system also includes a client computing device configured to request and receive the multi-form package, the first computing device including an application program and a multi-form document engine configured to receive commands from the application program and, in response, cause forms from the multi-form package to be presented and executed.
|
1. A method for presenting, on a client computing device, a plurality of interactive forms as a single document, the method comprising:
receiving at a server a request from the client computing device for a multi-form document comprising multiple forms;
creating at the server in response to the request an open document format (odf) package containing some or all of the forms of the multi-form document, the odf package including instructions for navigating from one form of the multi-form document to another form of the multi-form document;
transmitting the package to the client computing device;
unzipping the odf package, removing a first one of the forms from the unzipped odf package and providing the first one of the forms to a form processor resident on the client computing device while remaining ones of the forms remain zipped in the odf package; and
sequentially providing at least one other of the forms from the package to the form processor while remaining ones of the forms remain zipped in the odf package, the sequence being determined by at least one of navigation instructions in the package and data collected by the form processor.
13. A system representing and executing a multiplicity of interactive forms as a single document, the system comprising:
a server having one or more copies of a zipped open document format (odf) package created at the server and containing multiple forms of a multi-form document inserted into the odf package, the odf package also containing instructions for navigating from one form of the multi-form document to another form of the multi-form document, the server being configured to deliver a copy of the odf package to a requesting device upon request; and
a client computing device configured to request and receive the odf package, the first computing device including a form processor, an application program and a multi-form document engine configured to receive commands from the application program and, in response, cause forms from the odf package to be loaded into memory by unzipping the odf package, removing from the unzipped odf package a first one of the forms and processing the first one of the forms while remaining ones of the forms remain contained in the zipped odf package, and sequentially unzipping and processing at least one other of the forms from the package while remaining ones of the forms remain contained in the zipped odf package, the sequence being determined by at least one of navigation instructions contained in the odf package.
2. The method of
3. The method of
4. The method of
5. The method of
6. The method of
7. The method of
loading a first form from the package into memory;
receiving information from a user;
storing the information in at least one data instance; and
based on the information, loading a second form from the package into memory.
9. The method of
10. The method of
11. The method of
12. The method of
14. The system of
15. The system of
16. The system of
17. The system of
18. The system of
19. The system of
20. The system of
|
This application is a Continuation of U.S. patent application Ser. No. 12/783,534, filed on May 19, 2010, which claims priority to Canadian Patent Application No. 2666212, filed May 20, 2009, the entirety of each which is herein incorporated by reference.
The present invention relates to forms, and more specifically, to multiple computerized forms that must operate together to collect data.
The term “document” as used in computer based and produced documents is a convenient metaphor for representing an instance of a form application because it allows the end-user to save, email and digitally sign a complete digital representation of their interactions with the form application and the full context of those interactions. The document is also a convenient metaphor for forms application developers as it gives them a single digital asset that can be routed through a business process, encapsulate the full user experience definition for a rich interactive application, and contain all user input, attachments and digital signatures related to a business process transaction. Thus, it is also easy to offer an offline or disconnected form fill experience to end-users.
However, many business processes require a user to interact with more than one related form. For example, an insurance claim, loan agreement, grant proposal or tax form may consist of a primary form to collect the root data of the transaction as well as numerous additional forms that may conditionally need to be filled out depending on data supplied earlier in the fill experience. There are two solutions to this problem currently in practice. The first is to construct a web application from the collection of forms. The disadvantage of this approach is that it loses the many benefits of a document-centric architecture. The application is no longer expressed as a single document, so the user cannot have an offline or disconnected fill experience. That is, the user is no longer able to locally save a document representing the whole insurance policy, loan agreement, grant proposal or tax filing. If the user tries to email the form they are working on to someone else for collaboration, the context of that form within the web application is either lost or very difficult for the application to maintain. Further, a digital signature on a form in the application protects only that form and not necessarily the full transaction represented by the web application logic. Finally, having to involve server programmers to code web application logic is diametric to the simplification theme at the heart of declarative, document-centric electronic forms technology. It is therefore preferable to meet the functional requirements of multiple form applications by extending the capabilities of the electronic forms system.
The second solution is to cram the logical components of the multiple forms into a single form. In principle, this preserves the document-centric benefits of the web application, but in practice there are consequences for run-time performance, design-time understandability, maintainability and collaborative capability. At run-time, the single document takes much longer to start up and consumes much more memory to represent the run-time structures. The performance of interactional operations degrades because the single document is maintaining a larger, global run-time system of data structures for all logical components, rather than being narrowly focused on the logical components that are applicable to the user experience.
According to one embodiment of the present invention, a method for presenting, on a client computing device, a plurality of interactive forms as a single document is provided. The method includes receiving at a server a request from the client computing device for a multi-form document; creating at the server, in response to the request, a package containing some or all of the portions of the multi-form document, the package including instructions for navigating from one portion to the multi-form document to another portion of the multi-form document; transmitting the package to the client computing device; providing a first form from the package to a form processor resident on the client computing device; and sequentially providing at least one other form from the package to the form processor, the sequence being determined by at least one of navigation instructions in the package and data collected by the form processor.
Another embodiment of the present invention is directed to a system representing and executing a multiplicity of interactive forms as a single document that includes a server having one or more copies of a multi-form package and configured to deliver a copy of the package to a requesting device upon request. The system also includes a client computing device configured to request and receive the multi-form package, the first computing device including a form processor and a document execution engine configured to receive commands from the form processor and, in response, cause portions of the multi-form package to be loaded into memory.
Additional features and advantages are realized through the techniques of the present invention. Other embodiments and aspects of the invention are described in detail herein and are considered a part of the claimed invention. For a better understanding of the invention with the advantages and the features, refer to the description and to the drawings.
The subject matter which is regarded as the invention is particularly pointed out and distinctly claimed in the claims at the conclusion of the specification. The forgoing and other features, and advantages of the invention are apparent from the following detailed description taken in conjunction with the accompanying drawings in which:
The current method of multiplexing forms is to combine all the logical forms, data, model business rules, images, attachments, wizard step pages and so forth into a single monolithic form. This creates a form that has performance problems and design maintainability problems due to its size and complexity. A method is, therefore, needed that allows forms application components to remain separate yet together as the application is instantiated as a document which then traverses the business process lifecycle.
Embodiments of the present invention may overcome some or all of these and possibly other problems by providing systems and methods for storing all the components as separate files within a single compressed archive file (document) that conforms to the ODF (open document format) packaging format. Then, the multiplexing technology taught herein defines a processing model that enables the capabilities of a server-side web application to be deployed to a client (operating as a rich client plugin or as a web browser) as a single document, without loss of a consumable division of logical components of the application.
In more detail, the prior art monolithic form stores in a single XML (eXtensible Markup Language) document all images, all supporting document attachments provided by end-users, all XML data instances and business rule models, all form pages needed for various wizard experiences, and all forms with a high-precision, contractual view of some aspect of the overall business process or transaction. As an “ODF package” of files, embodiments of the present invention allow for logical components to be stored as separate files. In one embodiment, a package containing all of the logical components stored as separate files may be provided. This package may be zipped and only those portions currently being accessed unzipped and loaded into active memory. After completion, the ODF package format provides a format for serializing a single “ODF package” document that represents an instance of the modularized forms application.
In one embodiment, the ODF package of the present invention may include one or more logical files to represent data to be collected by the document, one or more logical components to import the data and apply business rules to the data (at times referred to herein as XForms models), one or more logical form files containing forms capable of reading from and writing to the logical data files of the document, and a logical component representing a form navigation state machine containing the descriptions of how and under what conditions to transition between forms. In other embodiments, the package may include a navigational state description indicating the current form immediately applicable to the user experience of the document. In addition, the package may include a form processor. This form processor may be responsive to a document engine resident on the client that invokes a particular form. The document execution engine may be capable of reading the document, executing its current form including document data read and write operations, changing the current form based on the conditions of the navigation state description, and serializing the document as altered by end-user interaction with one or more contained forms.
Additional capabilities may include the ability for the document execution engine to transmit the document serialization to a server, store the document serialization to a local disk file, allow attachments to be added to the package, the ability of any form to extract, remove or display attachments from the logical file set of the document, generate a digital signature into a logical data file of the document (package) and this signature may refer to one or more of the logical files in the document, and the ability to have a logical data file specify the document print operation in terms of printing any subset of pages from any number of the logical forms in the document. One advantage of the present invention is that multiple forms are multiplexed into a single document, preserving the overall document-centric application architecture. The aspects described above may allow a web application consisting of multiple forms to be represented at run-time by a single document in a performant manner. Operations such as printing, digital signing, file attachment, and local file save may be defined in terms of the overall document, rather than a single form in the document. The save operation allows the user to obtain a copy of the document that can be reloaded at a later time to continue working or emailed to other collaborators in an ad hoc workflow scenario. The submission capability allows the full document representing the application instance to get back to the server to participate in the business process. The system architecture also supports the application design experience. Since the document is comprised of a set of logical files for the logical components, the components of the application can be stored in an actual file directory at design time.
Referring to
Thus, as configured in
It will be appreciated that the system 100 can be any suitable computer or computing platform, and may include a terminal, wireless device, information appliance, device, workstation, mini-computer, mainframe computer, personal digital assistant (PDA) or other computing device. It shall be understood that the system 100 may include multiple computing devices linked together by a communication network. For example, there may exist a client-server relationship between two systems and processing may be split between the two.
Examples of operating systems that may be supported by the system 100 include Windows 95, Windows 98, Windows NT 4.0, Windows XP, Windows 2000, Windows CE, Windows Vista, Macintosh, Java, LINUX, and UNIX, or any other suitable operating system. The system 100 also includes a network interface 106 for communicating over a network 116. The network 116 can be a local-area network (LAN), a metro-area network (MAN), or wide-area network (WAN), such as the Internet or World Wide Web.
Users of the system 100 can connect to the network through any suitable network interface 116 connection, such as standard telephone lines, digital subscriber line, LAN or WAN links (e.g., T1, T3), broadband connections (Frame Relay, ATM), and wireless connections (e.g., 802.11(a), 802.11(b), 802.11(g)).
As disclosed herein, the system 100 includes machine-readable instructions stored on machine readable media (for example, the hard disk 104) for capture and interactive display of information shown on the screen 115 of a user. As discussed herein, the instructions are referred to as “software” 120. The software 120 may be produced using software development tools as are known in the art. Also discussed herein, the software 120 may also referred to as a “command line testing tool” 120, an “a testing interface” 120 or by other similar terms. The software 120 may include various tools and features for providing user interaction capabilities as are known in the art.
In some embodiments, the software 120 is provided as an overlay to another program. For example, the software 120 may be provided as an “add-in” to an application (or operating system). Note that the term “add-in” generally refers to supplemental program code as is known in the art. In such embodiments, the software 120 may replace structures or objects of the application or operating system with which it cooperates.
Regardless, a rich client viewer agent shall be capable of running the multiplexed forms document in offline/disconnected mode as well as within a web browser. The thin client online user agent shall be capable of executing the multiplexed forms document execution engine on the server side and serving out the HTML translation for the active page of the current form to a web browser for end-user interaction.
According to the ODF packaging format, the main file is called content.xml. Accordingly, the package 200 may include a file called content 203. In one embodiment, the schema for content 203 is specific to the type of document. In the case of multiplexed forms applications, content 203 may include a simple schema that indicates the current form file on which to begin processing if the document is launched (this setting may be adjusted whenever the user navigates to a new form in the document), the base URI of the server from which the document was first obtained (assuming the document 200 was obtained from the web), and a document-level definition for the print operation.
One embodiment of the present invention utilizes features of open standards such as XForms, XML signatures, and the ODF packaging format. In particular, the URI is the typical means by which both XForms and XML signatures interact with external entities, and the ODF packaging format defines the notion of a package-relative URI, which allows resources in a package to refer by URI to other resources in the same package. In one embodiment, anywhere that the XForms and XML signatures standards allow URIs, a package-relative URI may be used. This allows the conceptual model for the document execution engine (i.e., the client) to be quite similar to the standard client/server web application, even though the document engine 206 is technically a client technology that may run in the same location as the electronic form run-time processor (for example, Lotus Forms Viewer) or in a remote location distinct from both the client location and the server-side web application (for example, Lotus Forms Web Form Server).
In one embodiment, the package 200 includes an information portion 204. The information portion 204 may include, in one embodiment, information entered by users as well as the forms and rules related thereto. In one embodiment, the information portion 204 may include wizard pages, images, form pages, attachments, data instances and XForms models.
As discussed above, the package may include an information portion 204. The information portion 204 may contain, for example, in one embodiment, wizard pages, images, form pages, attachments, data instances and XForms models. The information portion 204 may also include an interaction controller 314 that controls the movement between form pages. In one embodiment, the interaction controller is not a separate entity, but rather consists of instructions embedded within wizard pages 304 and forms 306.
The package 300 may also include one or more wizard pages 304a . . . 304n. These wizard pages 304 may include programming that causes a display screen to display a form with blanks to be filled in by a user. These blanks may be prompted by questions or other means is receiving a response. Naturally, the forms application developer may have the option to separate all wizard pages into separate resources, or to group together sets of related wizard pages into a single form within the package 300. Similarly, single and multiple-page “contract view” forms (labeled as element 306 in
The package 300 may also include data blocks 310a . . . 310n. The data stored in the data blocks 310 is received by the wizard pages 304. In one embodiment, the data blocks may contain XML data instances. One or more of the forms 306 may use the information stored in data blocks 310. The forms 306 may represent the final contract, agreement or transaction to be created. Of course, the forms 306 may be saved or printed at any point in the creation thereof according to embodiments of the present invention. In one embodiment, data blocks 310 may be stored within content 203 rather than as separate entities.
The information section 204 may also include data models 312. These data models 312 may contain business or other models that are to be adhered to in the creation of the final document. For example, the XForms models may include, based on information already received, additional information that may be needed. In one embodiment, data models 312 may be stored within wizard pages 304 and forms 306 rather than as separate entities.
To maximize efficiency of a multiplexed forms application, it may be necessary to decompose business rule models into subordinate models 312 and then aggregate carefully selected models for each form in the application instance document. To satisfy these needs, this section describes two straightforward features that may be present in embodiments of the present invention. First, an outer model can contain instance data, submissions, actions and binds as per the standard, but also any number of model elements. Each inner model can contain instances, actions, binds and still more models. All inner models contribute by simple inclusion to the outermost containing model, all contained model scan share data.
Second, to allow model sharing, it is possible for each page 304 or form 306 to import models 312 that are stored in separate logical files in the package. In one embodiment, the <xforms:model> is equipped with the src attribute, which can, in lieu of content, express a URI for the model content. In particular, note that resources within a container document can share models using package-relative URIs in the src attributes. The model content provided by the URI is used in lieu of any content that may appear within the <xforms:model> element. Combining the above two features, a monolithic model can be decomposed into its logical components and then precision model aggregation within each form of a package 300 can be achieved by using both model nesting and model sharing together. In short, data models 312 may refer to other data models 312 according to embodiments of the present invention.
As discussed above, some forms technologies, such as XForms, support an external referencing mechanism to obtain data, such as use of the src attribute on the <xforms:instance> element. Such an instance is called an external instance. According to embodiments of the present invention, the src attribute shall support package-relative URIs. A page 304 or form 306 may continue to use internal instances (i.e. an <xforms:instance> without an src attribute) to store ephemeral data that is only needed during user interaction with a particular wizard page 304 or form 306. However, an external instance should be used for XML data 310 that must be shared by more than one page 304 or form 306 in the package 300, and external instances are also available to allow a file in the document to be used when the data must be shared with external business processes. Note that the content obtained from a src URI may be used in lieu of any content appearing in an <xforms:instance> element. Navigation from one page to another in the same form is handled by the normal means available to the forms processor 205, but the new page to which the end-user navigates is recorded in content 203 so that a save and reload operation can resume with the same form and page as was being shown to the end-user at the time of the save operation. Navigation to a page 304 or to a page in another form 306 in the document 300 is accomplished with an <xforms:submission> whose resource attribute contains a package-relative URI to the new form and possibly an ID reference to a page within the form. Again, the new form and page are automatically written to content.xml to preserve the state of package in save/reload scenarios.
When the user navigates away from a form to another form in the document, any instance data that is not synchronized to the document would be lost. The ability to synchronize instance data during the navigation submission is supported via the ability to add an xforms-submit or xforms-submit-done handler that invokes submissions to put the instance data from the form to the multiplexing document along with a submission that navigates to a new page or form.
The package 300 may also include an interaction controller 314. The interaction controller 314 is configured to control transitions between pages. In one embodiment, the interaction controller 314 may include rules that define, based on user selections and data values, which page 304 or form 306 should be presented to the user next by the multiplexing document execution engine 206 or whether the document has been completed by the user and should be provided to the server-side application for processing or provisioning to another user in a workflow.
The package 300 may also include other files 308 such as images, user-provided attachments, scripts, and stylesheets that may be referenced by one or all of the pages 304 and forms 306. In such cases, it may be preferable to allow the other files to be referred to by package-relative URIs. If such is done, the pages 304 and forms 306 may share the other files while only requiring one copy of the file to be included in the package 300.
The XML Signatures standard defines an XML format for a digital signature that is capable of signing multiple resources by using one <dsig:Reference> element per resource. This allows a single signature to sign not only data 310, but also page 304 and form 306 templates, and other files 308 associated with presenting the data to the user, such as images, attachments, scripts and stylesheets. Therefore, digital signing within multiplexed forms application documents will be achievable by combining the notion of package-relative URI with the standard capabilities of XML signatures. Thus, XML signatures in the multiplexed forms application may typically involve the use of multiple <dsig:Reference> elements, all of which will have a URI attribute with a package-relative URI, to protect a multiplicity of forms, data files, and other resources in the containing document. An XML signature is created by an end-user, and the XForms philosophy is that the end-user modifies instance data. Therefore, XML signatures appear in data blocks 310. The generation of an XML Signature is triggered, for example, by a user action such as clicking a button user interface element associated with XFDL markup for a button of type signature. The location of the XML signature in instance data is based on the UI binding of the xforms:trigger within the XFDL button markup, which indicates the dsig:SignatureValue element of the signature to be generated. When the button is activated, the XML signature is generated. Because an XML Signature appears in instance data, the notion of “same document” refers to the instance data file in the multiplexing document. Thus, one <dsig:Reference> of an XML Signature will typically use the empty URI to indicate the containing data file, whereas the remaining <dsig:Reference> elements typically use package-relative URIs to indicate other components of the package 300.
The general application 402 may operate on forms from the package 300. In one embodiment, once a first form from package 300 is delivered from engine 206 to the form processor 205 of the general application 402, the application program 402 uses instructions in the form to determine how to communicate with and control the package 300 through the engine 206. As discussed above, the multiplexing document execution engine 206 and general application 402 may be deployed to the client 400 separately, prior to the delivery of a package 300 to the client 400. However, as a component of general application 402, the form processor 205 may also be deployed separately to the client 400, or it may be delivered to the client 400 as part of package 300 and deployed by engine 206 prior to delivering a first form from package 300 to general application 402. In one embodiment not depicted in
In one embodiment, the server 404 may be configured in such a manner as to receive a request from the client 400 to create an instance of a multi-form document. For example, the server could receive a request from the client 400 to create a grant proposal. The grant proposal could be contained, for example, on the server 404 and could be a multi-form document having wizard pages and longer fill-in-the-blank forms and requiring that the collaborators on the grant proposal attach a curriculum vitae (CV). In the prior art, the server 404 may have had to create a version of the grant proposal and maintain that version, including all of the related wizard pages, rules, user attachments, etc. until the proposal was completed.
According to the present invention, the server 404 need only create a copy of the package 300 related to grant proposals and send that package 300 to engine 206.
Referring back to
The engine 206 may operate as part of the general application 402 or may operate as a buffer between the general application 402 and the package 300. For the following description is assumed that the engine 206 is a separate entity from the general application 402. The following description assumes that the engine 206 may be in communication with a form processor (e.g., element 205 of
A user may use the general application 402 to request the package 300. The engine 206 receives this request and examines the content block 203. This examination may reveal the starting or current form that the general application 402 is to present to the user. As discussed above, the content block 203 may be updated as a user moves among pages 304 and forms 306 (e.g., from form 306a to form 306b) during operation.
The wizard pages 304 and forms 306 are created to prompt the user to provide information that may be stored, for example, in the data instances 310. The data instances 310 may be linked to one or more models 312. As data is placed in the data instances 310 the engine 206 may analyze any related model 312 to ensure that the data is in the correct format. In addition, based on the information received, the interaction controller 314 may indicate that additional forms need to be completed. In this manner, the interaction controller 314, based on predetermined rules or analysis by the models 312, controls the path taken through the pages 304 and forms 306 that are actually completed. In operation, some or all of the pages 304 and forms 306 may be used. As information is received and stored in the data instances 310 is may be used to populate pages 304 and forms 306 to which they are related. In one embodiment, the pages 304 and forms 306 link to the data in the data instances 310.
When the package 300 is completed, the entire package 300 may be returned to the server 404. The package 300 may only be complete, in some instances, when all of the persons required to provide information have done so. The interaction controller 314 may be queried to ensure that the package 300 is complete. This may include, for example, ensuring that all participants have completed the required forms. In addition, it should be noted, that the interaction controller 314 may be configured to keep track of the last page accessed so that as the package 300 is passed to different individuals, the first page accessed by the next person is the information that that individual is responsible for providing. In one embodiment, the package may be returned in a serialized form. Of course, the serialized package may, in some embodiments, only include the data instances, not the other wizards, rules, etc. originally contained in the package 300.
When serialized, the mime type of the returning package may be changed to indicate the content-encoding of base64 (to encode as base-64 the binary content of the ODF packaging format). In one embodiment, this may include an XForms submission method of “post” and the “replace” attribute should have the default “all” setting, which causes the submission data to be the entire multiplexing document. The shared instance data must also be synchronized to the document prior to full document submission. This capability is offered by the same mechanism as data synchronization for form navigation within the document. Specifically, the data can be synchronized using additional submission operations performed prior to the full document submission. In one embodiment, a prime mover submission begins the data synchronization submissions with an xforms-submit-done handler, and the xforms-submit-done handler on the last data synchronization submission initiates the full document submission.
One problem that may have existed in the prior art is that forms could not be saved and printed prior to their completion. Embodiments of the present invention may allow for both of these operations. For example, when a forms application (such as Lotus Forms) run-time is executing a multiplexed form according to the present invention, the save operation for that form is overridden to save the entire package 300. This type of save may allow for all of the portions of the package 300 to be saved, rather than just the current page. This may be controlled by the engine 206.
When the application Forms run-time is executing a multiplexed form, the print operation for that form is overridden by the printing definition in the package 300. The description of which forms and which pages to print shall be contained in the content block 203 file. This allows a traditional “contract” view of a multiple form application to be printed even if the end-user is currently working on a (non-printing) wizard page of the application. The multiplexing technology also offers the ability to dynamically change the print definition. Since the definition is contained by content.xml, which may be an XML data file, <xforms:submission> operations with get and put methods can be used to read and write the print definition by using a package-relative URI to the content.xml file.
The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one ore more other features, integers, steps, operations, element components, and/or groups thereof.
The corresponding structures, materials, acts, and equivalents of all means or step plus function elements in the claims below are intended to include any structure, material, or act for performing the function in combination with other claimed elements as specifically claimed. The description of the present invention has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the invention. The embodiment was chosen and described in order to best explain the principles of the invention and the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated
The flow diagrams depicted herein are just one example. There may be many variations to this diagram or the steps (or operations) described therein without departing from the spirit of the invention. For instance, the steps may be performed in a differing order or steps may be added, deleted or modified. All of these variations are considered a part of the claimed invention.
While the preferred embodiment to the invention had been described, it will be understood that those skilled in the art, both now and in the future, may make various improvements and enhancements which fall within the scope of the claims which follow. These claims should be construed to maintain the proper protection for the invention first described.
Boyer, John M., Manning, David F., Mansell, Michael C.
Patent | Priority | Assignee | Title |
Patent | Priority | Assignee | Title |
5960204, | Oct 28 1996 | Oracle International Corporation | System and method for installing applications on a computer on an as needed basis |
6070177, | Mar 06 1998 | Vita Systems, Inc. | Database forms with attached audit history |
6108673, | Feb 25 1997 | International Business Machines Corporation | System for creating a form from a template that includes replication block |
6212534, | May 13 1999 | Progress Software Corporation | System and method for facilitating collaboration in connection with generating documents among a plurality of operators using networked computer systems |
6557015, | Sep 18 1998 | International Business Machines Corporation | Determining whether a second hypertext document is included in a list of active document trails |
6725229, | Dec 29 2000 | Bellsouth Intellectual Property Corporation | Configuration utility |
6925594, | Feb 28 2001 | International Business Machines Corporation | Saving selected hyperlinks for retrieval of the hyperlinked documents upon selection of a finished reading button in a web browser |
7313757, | Apr 18 2001 | Adobe Inc | Method and system for cross-platform form creation and deployment |
7363579, | Sep 03 2003 | Thomson Reuters Enterprise Centre GmbH | Mark-up of automated documents |
7555564, | Jul 10 2004 | Hewlett-Packard Development Company, L.P. | Document delivery |
7577906, | Nov 08 2004 | Microsoft Technology Licensing, LLC | Method and system for document assembly |
7752537, | Dec 31 2004 | International Business Machines Corporation | Methods, apparatus, and computer program products for dynamic generation of forms |
7761601, | Apr 01 2005 | Microsoft Technology Licensing, LLC | Strategies for transforming markup content to code-bearing content for consumption by a receiving device |
7818215, | Apr 19 2004 | Kyocera Corporation | Processing techniques for text capture from a rendered document |
7818677, | Jun 21 2000 | Microsoft Technology Licensing, LLC | Single window navigation methods and systems |
8032626, | Nov 16 2000 | CLOUDING CORP | Method and system for monitoring the performance of a distributed application |
8108464, | Mar 31 2006 | GOOGLE LLC | Collaborative workflow through messaging conversations |
20010020243, | |||
20030052920, | |||
20040111664, | |||
20040123284, | |||
20040205644, | |||
20050010871, | |||
20050154779, | |||
20050177784, | |||
20050210009, | |||
20050246642, | |||
20060026502, | |||
20060117307, | |||
20060149758, | |||
20070226635, | |||
20080098018, | |||
20080163199, | |||
20080172598, | |||
20080215957, | |||
20080219553, | |||
20090024993, | |||
20090324065, | |||
20100070844, | |||
20100091322, | |||
20100110095, | |||
20100174997, | |||
20100250926, | |||
20100254604, | |||
20100262908, | |||
20100299389, | |||
20110153571, | |||
20130179774, | |||
CA2517804, | |||
CA2588164, |
Executed on | Assignor | Assignee | Conveyance | Frame | Reel | Doc |
Feb 20 2017 | BOYER, JOHN M | International Business Machines Corporation | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 042220 | /0291 | |
Feb 22 2017 | MANNING, DAVID F | International Business Machines Corporation | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 042220 | /0291 | |
Mar 28 2017 | MANSELL, MICHAEL C | International Business Machines Corporation | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 042220 | /0291 | |
May 02 2017 | International Business Machines Corporation | (assignment on the face of the patent) | / |
Date | Maintenance Fee Events |
Sep 25 2023 | REM: Maintenance Fee Reminder Mailed. |
Mar 11 2024 | EXP: Patent Expired for Failure to Pay Maintenance Fees. |
Date | Maintenance Schedule |
Feb 04 2023 | 4 years fee payment window open |
Aug 04 2023 | 6 months grace period start (w surcharge) |
Feb 04 2024 | patent expiry (for year 4) |
Feb 04 2026 | 2 years to revive unintentionally abandoned end. (for year 4) |
Feb 04 2027 | 8 years fee payment window open |
Aug 04 2027 | 6 months grace period start (w surcharge) |
Feb 04 2028 | patent expiry (for year 8) |
Feb 04 2030 | 2 years to revive unintentionally abandoned end. (for year 8) |
Feb 04 2031 | 12 years fee payment window open |
Aug 04 2031 | 6 months grace period start (w surcharge) |
Feb 04 2032 | patent expiry (for year 12) |
Feb 04 2034 | 2 years to revive unintentionally abandoned end. (for year 12) |