System and method for designing electronic forms

Information

  • Patent Grant
  • 7415672
  • Patent Number
    7,415,672
  • Date Filed
    Monday, March 24, 2003
    21 years ago
  • Date Issued
    Tuesday, August 19, 2008
    16 years ago
Abstract
A system and method enabling a designer to build electronic forms from hierarchical data is described. Displays of hierarchical data, facilitation of selection of a portion of the hierarchical data, and displays of one or more transformation-language components associated with a selected portion of hierarchical data are described. From the transformation-language components selected by a designer, generation of an electronic form is also described.
Description
TECHNICAL FIELD

This invention relates to designing electronic forms, and more particularly, to a user-friendly way to design electronic forms using a visual representation of hierarchical data and a form-designing area.


BACKGROUND

Extensible markup language (XML) is increasingly becoming the preferred format for transferring data. XML is a tag-based hierarchical language that is extremely rich in terms of the information that it can be used to represent. For example, XML can be used to represent information spanning the spectrum from semi-structured information (such as one would find in a word processing document) to generally structured information (such as that which is contained in a table). XML is well-suited for many types of communication including business-to-business and client-to-server communication. For more information on XML, XSLT, and XSD (schemas), the reader is referred to the following documents which are the work of, and available from the W3C (World Wide Web consortium): XML Schema Part 2: Datatypes: XML Schema Part 1: Structures, and XSL Transformations (XSLT) Version 1.0; and XML 1.0 second edition specification.


With so information being described and transferred through XML, it is increasingly important to have ways to view that information. One way to view information in an XML document is to transform it with an XSLT file into an HTML (or XHTML) document. HTML documents can be used to render, or view, information, such as information from an XML file. Using XSLT, rather than other transforming languages, is often preferred because XSLT is a W3C standard.


One purpose for using an XSLT file to transform an XML document is to create electronic forms. Electronic forms can be used not only to view information within an XML document, but also to allow a user of the electronic form to add, remove, or change information within the XML document by editing data in a data-entry field within the electronic form.


Currently, to create an HTML document (e.g., an electronic form) that renders information within an XML document, a programmer writes an XSLT file to transform the XML document into the HTML document. The programmer, however, must have a high degree of skill in programming XSLT to program an XSLT file, especially to create an electronic form.


Also, even with a high degree of programming skill, programming an XSLT file can be very time consuming and difficult. It can be difficult and time-consuming because an XSLT programmer cannot see the HTML document that he is creating as he is creating it. The programmer, rather, must complete an XSLT file and apply it to an XML file before he cans ee the view created with the resulting HTML document. Even with the view, each mistake made by the programmer, such as the style, layout, and structure of the view, can be very difficult to relate back to the mistake made in the XSLT file, further complicating programming of XSLT files to create HTML documents.


For these reasons, creating electronic forms and other HTML documents by transforming an XML document with an XSLT file is difficult, time consuming, and requires a high degree of skill.


SUMMARY

A system and method enabling a designer to build electronic forms from hierarchical data is described. Displays of hierarchical data, facilitation of selection of a portion of the hierarchical data, and displays of one or more transformation-language components associated with a selected portion of hierarchical data are described. Generation of an electronic form from transformation-language components selected by a designer is also described.


Also, a system capable of and/or a method of coupling a markup-language document and markup-language schema into a generalized instance is described. Receiving a markup-language document or markup-language schema or both and inferring a markup-language document from only a markup-language schema or a markup-language schema from only a markup-language document is described. With a markup-language document and markup-language schema, whether received or inferred, coupling of the markup-language document and the markup-language schema into a generalized instance is described.





BRIEF DESCRIPTION OF THE DRAWINGS


FIG. 1 illustrates a system with a display screen, computer, and user-input devices. The system implements a method for designing electronic forms.



FIG. 2 illustrates an exemplary screen display showing a data display area and a substantially filled-in form-design area.



FIG. 3 is a flow diagram of an exemplary process for generating electronic forms.



FIG. 4 illustrates an exemplary screen display showing a data display area and a blank form-design area.



FIG. 5 illustrates an exemplary screen display showing part of a data display area, a component display area, and a blank form-design area.



FIG. 6 illustrates an exemplary screen display showing a data display area and a form-design area.



FIG. 7 illustrates an exemplary screen display showing a data display area, an auxiliary component display area, a component display area, and a form-design area.



FIG. 8 illustrates an exemplary screen display showing a data display area and a form-design area.



FIG. 9 is a flow diagram of an exemplary process for coupling a markup-language document and schema.



FIG. 10 is a flow diagram of an exemplary process for rendering transformation-language components and generating a transformation-language document.



FIG. 11 is a block diagram of a computer system that is capable of supporting an electronic-form generation process.





The same numbers are used throughout the disclosure and figures to reference like components and features.


DETAILED DESCRIPTION

The following disclosure describes a user-friendly way to design electronic forms using a visual representation of hierarchical data and a form-designing area of a display. Hierarchical data is presented in an area of a display screen, usually presented graphically, such as with an arrangement of icons. Icons represent some part of the hierarchical data and are generally a simplification of the data so that a designer can more easily understand the purpose of and choose from various parts of the hierarchical data. A designer can choose a part or portion of the hierarchical data that he or she wishes to include in an electronic form.


When the designer chooses part of the hierarchical data, such as by clicking on an icon representing part of the hierarchical data, a component representing a way to present that part of the hierarchical data can be placed on a form-designing area. The form-designing area is presented in an area of a display screen, usually appearing as a blank page, such as is often done when viewing a new document in a word-processing application. Components placed in a form-designing area can be manipulated by a designer to allow the designer to make an electronic form look and feel like the designer desires.


For discussion purposes, the visual representation of the data and the form-designing area are described in the context of a single computer, a set of user-input devices, and a single display screen having an area for displaying a representation of the data and another area for displaying the form-designing area. The display screen, computer, and user-input devices will be described first, followed by a discussion of the techniques in which these and other devices can be used.


The Display Screen, Computer, and User-Input Devices


FIG. 1 shows an exemplary system 100 that facilitates creation of electronic forms from a representation of data. The system 100 includes a monitor or screen 102, one or more user-input devices 104, and a computer 106. The user-input devices 104 can include any device allowing a computer to receive a designer s preferences, such as a keyboard 114, other device(s) 116 (e.g., a touch screen, a voice-activated input device, a track ball, etc.), and a mouse 118. The computer 106 includes a processing unit 120 and memory 121, which includes both volatile and non-volatile memory.


An operating system 124 and one or more applications are stored in memory and execute on the processing unit 120. One particular application is a forms-designer application 126, which allows a designer to create electronic forms with little or no programming skill. The forms-designer application 126 provides a visual what-you-see-is-what-you-get (WYSIWYG) user interface 122 that enables designers to visually construct an electronic form by visually selecting structured data items and arranging them into a form in a manner that is intuitive and straight forward. As the designer builds the form through the user interface, the application 126 enforces the underlying schemas to ensure that the form complies with the intended structure.


The user interface 122 includes three areas depicted on the screen 102: a data display area 108, a component display area 110, and a form-design area 112. The three areas may be shown individually, or in groups of two areas, as desired. The areas 108, 110, and 112 may be implemented as individual graphical windows, such as those supported by Microsoft's Window® operating system. Alternatively, the areas may be panes within a common window, or some other graphical arrangement.


Data display area 108 shows a representation of a data source of hierarchical data. The data may be presented and structured in a number of ways. In one example, the data display area 108 depicts hierarchical data arranged into a tree structure having multiple nodes. From this data display area 108, a designer can select various parts of the hierarchical data to be represented in the form-design area 112 when constructing an electronic form. When the designer selects a certain portion of data in data display area 108, the forms-designer application 126 presents a list of components in the component display area 110 that can be used in the form-design area 112 to represent the selected portion of hierarchical data. The number and type of components in the component display area 110 varies depending upon the hierarchical data that is selected.


The designer can then choose one or more of the components in the component display area 110 and arrange them in a representation of a form being constructed in the form-design area 112. For instance, the designer can drag and drop a component from the component display area 110 (which corresponds to a selected portion of hierarchical data (e.g., node in the data tree) from the display area 108) onto the form-design area 112, and the underlying forms-designer application 126 will show how the selected component will affect the electronic form produced.



FIG. 2 shows an example screen display 200 illustrating construction of an electronic form in the form-design area 112 by selection of hierarchical data elements in the data display area 108. In this example, a representation 202 mimics an electronic form being constructed for a fictitious travel itinerary. It has a top section 204 that describes general trip information, having components that represent data-entry fields in the electronic forms, which will allow entry of the purpose of the trip, the traveler's name, and the start and end dates. The representation 202 also has a bottom section 206 for tracking individual appointments made on the trip. In this example, the appointment section 206 will allow such entries as purpose of the appointment, its location, and the people contacted during the appointment.


The representation 202 follows the file of hierarchical data provided in data display area 108. In this example, the hierarchical data file is arranged into a tree structure, which includes a node named “generalTripInfo” that generally corresponds to the top portion 204 of the form, and hierarchical nodes named “event” and “appointment” that generally correspond to the bottom portion 206.


The representation 202 (and, eventually, the electronic form it mimics) can be constructed by selecting nodes in the data tree structure in display area 108 and arranging representative components onto the form-design area 112. For example, to create the “Purpose” entry field representation 208 in the top section 204, the designer selects the purpose node 210 in the data display area 108. The application presents a list of components (not shown in FIG. 2 corresponding to the purpose node 210. The designer then chooses a component and identifies a corresponding location in the form-design area 112 for the component to be placed. One technique for this selection and placement of the component is to drag-and-drop the selected component corresponding to the node 210 onto the desired location, and the forms-designer application 126 will show a representation of how an operable field corresponding to the component will appear in the electronic form.


The process used to build an electronic form from components associated with hierarchical data will be set forth in greater detail below. The above devices and applications are merely representative, and other known devices and applications may be substituted for or added to those shown in FIG. 1. One example of another known device that can be substituted for those shown in FIG. 1 is the device shown in FIG. 11.


Overview of Technique for Creating Electronic Forms


FIG. 3 shows a process 300 for modularly generating an electronic form. The process 300 is illustrated as a series of blocks representing individual operations or acts performed by the system 100. The process 300 may be implemented in any suitable hardware, software, firmware, or combination thereof. In the case of software and firmware, the process 300 represents a set of operations implemented as computer-executable instructions stored in memory and executable by one or more processors.


Displaying Hierarchical Data


At block 302, the system 100 display hierarchical data. The hierarchical data is displayed so that a designer can chose particular parts of the hierarchical data to be represented in an electronic form that the designer wants to build. The system 100 displays the hierarchical data so that it is easy for the designer to choose a particular part of the hierarchical data, such as by clicking on an icon.



FIG. 4 shows an example data display area 108 in which hierarchical data is displayed as icons with associated names. For instance, the depicted data includes such items of data named “myFields,” “string1,” “xhtml1,” “container1,” “repeating item,” “string1,” and so forth to “boolean2”. Each of these named icons represents a part of the hierarchical data. These icons make it easier to understand the hierarchical data, especially for a designer unfamiliar with the often-complex details of hierarchical data. These icons can also make it easier for a designer to select particular parts of the hierarchical data. Whether the icons, text, or otherwise, the system 100 makes the structure of the hierarchical data apparent to a designer.


In FIG. 4, the hierarchical data is arranged in the form of a tree. The named icons are representative of nodes in the tree. The tree structure leads a visually hierarchy to the data, where certain nodes are nested within other nodes. For instance, a parent “container3” node 440 contains a “string5” node 442 and a “boolean2” node 444, which is set forth graphically by the “string5” node 442 and the “boolean2” node 444 being indented relative to the “container3” node 440.


Nodes, as well as parts of hierarchical data not presented in a tree, have a structure. This structure can include rules governing the node itself or the type of information that the node can contain.


There are various types of languages with which hierarchical data files are written, such as markup languages. One of the most common types of markup language is the eXtensible Markup Language, or XML. Markup-language data is often used to transfer, store, or represent data.


Selecting a Part or Node of the Hierarchical Data


At block 304, the system 100 enables selection of a portion of the hierarchical data. In FIG. 4, the designer has selected the ¢string1” node 418 as represented by the highlight bar placed at the node. Selection can be made using conventional user interface techniques, such as a computer mouse pointer, a stylus, a touch screen, or some other input mechanism that facilitates selection of a specific item. The designer selects a portion of hierarchical data by clicking on )or tapping, or otherwise identifying) the icon or text name representing a particular part of the hierarchical data.


Components Associated With the Selected Portion


Once the system 100 receives a selection of a portion of the hierarchical data, the system 100 displays one or more components associated with the selected portion of the hierarchical data (block 306 in FIG. 3. The components can be displayed in various ways such that a designer is able to readily choose among possible components (if a choice needs to be made). The components can be depicted in a separate area, such as a separate graphical window or pane.



FIG. 5 illustrates an exemplary component display area 110 that is depicted upon selection of the “string1” node 418 in the data display area 108. The component display area 110 is illustrated as a pop-up menu or list that is positioned just beneath the selected data item and overlies the data display area 108. The component display area 110 contains a list of components that are associated with the selected node 418. That is, each component set forth how the selected part of the hierarchical data could be represented in the electronic form. In this example, the selected “string1” node 418 can be represented by such components as a text box 502, a drop-down list box 504, a list box 506, an option button 514, a check box 516, and so on. The component display area 110 may further include other menu options that enhance the usability for the designer. These options may be general or context specific. Representative options “Add”, “Reference”, “Move”, “Delete”, and “Properties” are illustrated in FIG. 5.


When a selection is made, the component display area 110 can present a restriction of the entire library of components known to the system 100. In such a case, the component display area 110 presents a scrollable list or some other mechanism that allows the designer to move through the library and select the desired component. Alternatively, the system 100 can display a reduced set of components that are associated with the selected portion of the hierarchical data. The system 100 identifies which components are associated with a selected portion of hierarchical data according its structure. Thus, if the structure of the portion of hierarchical data allows for storage of only textual data, the system will provide as a default only those components that allow for entry of just textual data. Likewise, if the structure of a portion allows for multiple fields of data, the system will provide to a designer components allowing for multiple fields, such as components allowing for repeating sections and/or a repeating table, like the drop-down list box 504 and the list box 506 of FIG. 5.


Components may be constructed in various ways. Components can be written in a transformation-language. These transformation-language components are code that can be used to transform pieces of markup-language data (a type of hierarchical data) into visual and/or structural fields in an electronic form that are consistent with the structure of the markup-language data. Examples of transformation-language components include files, applets, or other code written in Cascading Style-Sheet Language (CSS) and xTensible Style-sheet Language Transformation (XSLT) languages.


In one implementation, transformation-language components are written in XSLT. XSLT components include those shown in the component display area 110: the text box 502, the drop-down list box 504, the list box 506, the option button 514, and the check box 516. These components in the component display area 110 are represented with icons that approximate the data-entry fields that the components can be used to create in an electronic form.


For example, if a designer chooses a piece of the markup-language data and the piece has only Boolean information or a structure allowing for only Boolean information (e.g., yes or no) (e.g., the “boolean2” node 44 in FIG. 4), the system 100 will display components compatible with the Boolean information and/or structure. The option button 514 or the check box 516 in the components display area 110 of FIG. 5 are examples of compatible components.


Components, whether transformation-language components or otherwise, can be used to create operable fields in electronic forms. Operable fields, such as data entry fields, when integrated into an electronic form, can display or receive information. The information received can be input by a user of an electronic form containing the data-entry field or the information can be copied (automatically or otherwise) from a data source of hierarchical data containing the information. The “Purpose” data-entry field 208 of FIG. 2, is one example of a data-entry field.


The components associated with the selected part of the hierarchical data, whether a transformation-language component or otherwise, are displayed in component display area 110 so that a designer can chose between them. Components do not need to be displayed, however, if one is chosen by the system 100, such as by a particular component being a default choice or if there is only one component associated with a selected portion of hierarchical data.


In one implementation, the system 100 chooses the component (such as by intelligently determining a component most likely to be desired based on the designer's history of choosing or an algorithm), lessening the need for displaying multiple components unless a designer requests.


Choosing a Component and Other Preferences


At block 308, the system 100 enables the designer to choose one of the components that is associated with the selected portion of hierarchical data. The designer can make this choice using similar user interface techniques that are employed to select a particular portion of hierarchical data. The system 100 can, for instance, enable a designer to select a component by clicking on an icon or text for a component in the component display area 110 (FIG. 5). Alternatively, the system 100 can enable a designer to drag and drop a component from the component display area 110 to the form-design area 112, thereby choosing the component and the placement of the component on the form-design area 112. The system 100 then displays the selected component on the form-design area 112. The selected component can be displayed at a place on the form-design area 112 where a designer selects, or placed where it will not obscure another component on the form-design area 112.


Continuing our example, after the designer selects the string1 node 418 in the data display area 108 (FIG. 4) to invoke the list of components in component display area 110 (FIG. 5), the designer can choose one of the components in component display area 110. In this example, the designer chooses the text box 502 and identifies where the field created with the component is to be positioned in the form-design area 112. This can be done by dragging and dropping the component from the list 110 the form-design area 112, such as the upper left hand corner of form-design area 112 as shown in FIG. 6. The forms-designer application 126 will display the selected text box 502 component substantially as it will appear as an operable field (a text box representation 602, which has the corresponding name “String 1”).


However and wherever placed, components generally can be moved and altered by a designer to allow the designer to create an electronic form to match the designer's preference. In one implementation, the system 100 enables a designer to place a component onto the form-design area 112 wherever the designer chooses. This allows the designer freedom to easily organize and create a view (and eventually an electronic form) of one or more components on the form-design area 112.


The system 100 enables a designer not only to choose a particular component, but also other preferences. These preferences can include the placement on the form-design area 112 of each component. These preferences can also include alterations to the components, like the size, font, color, orientation, and the like.


The system 100 also allows a designer to request changes to the form-design area 112 that are not related to components, such as adding text and graphics to the form-design area 112 (such as the header “Travel Itinerary” shown in FIG. 2's example of the form-design area 112). In one implementation, these preferences can include most of the preferences available to a user of a typical word-processing program.


A designer can choose additional parts of an arrangement of hierarchical data and select additional components associated with the chosen parts of hierarchical data to add to the form-design area 112. Continuing the above example, after the text box representation 602 is displayed on the form-design area of FIG. 6, a designer could continue to select the same or another portion of the hierarchical data in the data display area 108 and position the corresponding component onto the form.



FIG. 7 shows an example of a designer selecting the “string1” node 418 and then choosing a different component, in this case a drop-down list box 504 from the component display area 110. This example also illustrates another feature, in that the selection of a component may invoke another menu that presents further design options for the selected component. Here, selection of the drop-down list box 504 causes a secondary or auxiliary component display area 720 to be depicted on the screen (although it is illustrated in FIG. 7 off the screen for clarity and purposes of discussion in relation to the underlying areas 110 and 108. The location of this display area 720 is configurable, and may be located just beneath the selected drop-down list box item in display area 110, or elsewhere. The auxiliary component display area 720 includes various component alternatives for implementing the drop-down list box 504, including a table 722, an HTML text 724, a plain text box 726, a plain text area 728, a check box 730, a combo box 732, and a list box 734.


From this auxiliary list, suppose the designer chooses the combo box 732 and positions that component onto the form-display area 112 just beneath the text box representation 602. The forms-designer application 126 uses the selected combo box 732 to represent what will be an operable drop-down list data-entry field in the electronic form (a drop-down representation 802 shown in FIG. 8). Since the component is derived from the “string1” node 418 in data display area 108, the drop-down representation 802 is initially given the name “String1”. This name can be subsequently edited, if the designer so desires.


A designer can continue to add components and make alterations to the form-design screen 112. By allowing additions and alterations to the form-design screen 112, the system 100 enables a designer to easily and intuitively create an electronic form built to the designer's preferences. A designer could, for example, continue to add components and make alterations to the components and form-design area 112 until the designer has created a form-design area like the form-design area 112 of FIG. 2, entitled “Travel Itinerary.”


Generating an Electronic Form


At block 310, the system 100 generates an electronic form. Components placed within the form-design area 112 are used to generate an electronic form. The electronic form is the product of the placement of various components on the form-design area 112, and can include where the components were placed, how they were altered, and any stylistic changes made to how the components are displayed on or to the form-design area. Once created, the electronic form visually mimics the look of the form-design area at the time the designer decided to create the electronic form. How the system 100 generates an electronic form will be set forth in greater detail below.


Techniques for Creating Electronic Forms

Various implementations of a form-designing process are set forth below. The form designing process can begin with a generalized instance process 900, and can include a process 1000 for rendering transformation-language components and generating a transformation-language document from an annotated rendering-language document.


Creating a Generalized Instance



FIG. 9 sets forth a process 900 for creating a generalized instance from one or both of a markup-language document and a markup-language schema. A generalized instance contains hierarchical data. The process 900 is illustrated as a series of blocks representing individual operations or acts performed by the system 100. The process 900 may be implemented in any suitable hardware, software, firmware, or combination thereof. In the case of software and firmware, the process 900 represents a set of operations implemented as computer-executable instructions stored in memory and executable by one or more processors.


Three ways to create a generalized instance are set forth in process 900. In the first, the system 100 receives only a markup-language document. In the second, the system 100 receives both a markup-language document and its markup-language schema. In the third, the system 100 receives only a markup-language schema.


In the first way, the system 100 creates a generalized instance from only a markup-language document. The system 100 does so following blocks 902, 904, and 906 of FIG. 9.


In the block 902, the system 100 receives a markup-language document without its associated schema. The markup-language document received is a document containing hierarchical data that conforms to a markup-language schema, but the markup-language schema is not known. To determine or fabricate a schema for the markup-language document, the system 100 analyzes the structure in which the markup-language document conforms and/or investigates clues or references in the markup-language document.


With this information, the system 100 infers a markup-language schema according to the block 904. The system 100 can infer the markup-language schema by building it based on the structure of the markup-language document. The system 100 can also infer the markup-language schema by searching sources containing schemas until it finds a schema matching the structure of or reference in the markup-language document. The World Wide Web Consortium (“W3C”) is a source for the language used to describe some markup-language schemas.


In block 906, the system 100 couples the markup-language document and its associated markup-language schema. Either of the markup-language document or markup-language schema may have been inferred. The generalized instance contains a hierarchical arrangement of data with each part of the hierarchical data also containing or referencing each part of the schema that governs that part of the hierarchical data.


In one implementation, the system 100 couples the markup-language document and its schema modularly. The system 100 analyzes the structure of the markup-language document and the structure allowed by its schema to determine how the markup-language document can be modularized. The system 100 breaks the markup-language document into parts (referred to sometimes as “nodes” when the generalized instance is arranged as a tree). Based on each of these parts of the markup-language document, the system 100 associates pieces of the schema that govern the structure of a particular part to that particular part. By so doing, the markup-language document and its schema can be broken down into parts. These modular parts each contain a part of the markup-language document and a part of the markup-language schema governing that part.


These parts are then arranged into a generalized instance. The generalized instance contains an arrangement of parts, each part containing a piece of the markup-language document and piece of the markup-language schema governing that piece of the markup-language document.


For example, in FIG. 6, a “container3” node 440 is a part of a larger markup-language document (entitled “My Fields”) associated with a markup-language schema. The “container3” node 440 contains information on its own and the information of a “string5” node 442 and “boolean2” node 444. The “container3” node 440 also, if it is part of a generalized instance, contains the part of the schema associated with the markup-language document that governs the container3 node 440, the string 5 node 442, and the boolean2 node 44. Thus, that part of the markup-language document that is called the container3 node 440 is modular by virtue of being coupled with the schema governing it. So each part of a markup-language document that is coupled with its markup-language schema is independent and modular. The generalized instance is a compilation of all the coupled parts.


One of the benefits of creating a generalized instance is that the system 100, when it receives a selection of one part of hierarchical data that is modularized into a generalized istance, can more easily associate that selected part to one or more components. The system 100, with just the selected part, can determine what rules govern that part, such as the type of information the part can contain, how it is arranged, how it can be used, and the like. Thus, the system 100 can more easily (and in some cases more accurately) associate particular components with the selected part of the hierarchical data when it is modularized into a generalized instance.


In one implementation, a generalized instance describes, for each part of a hierarchical data file, every possible type of information that can be contained within that part. With this information, the system 100 can more easily determine which components to associate with a selected part of hierarchical data that have been coupled or modularized into a generalized instance.


In the second way to create a generalized instance, the system 100 creates a generalized instance from a markup-language document and its markup-language schema. The system 100 does so following blocks 908 and 906 of FIG. 9.


In the block 908, the system 100 receives a markup-language document and its associated schema. The markup-language schema describes the rules and/or structure governing the markup-language document received but can also govern other markup-language documents as well. With the markup-language document and its schema, the system 100 creates a generalized instance as set forth in block 906 above.


In the third way, the system 100 creates a generalized instance from only a markup-language schema. The system 100 does so following blocks 910, 912, and 906 of FIG. 9.


In the block 910, the system 100 receives a markup-language schema without a conforming markup-language document. This markup-language schema can be one of many different types, including a schema not conforming to a W3C standard or one having an arbitrary syntax.


The system 110, through the forms-designer application 126, analyzes the markup-language schema to determine the range of markup-language documents that can conform to the markup-language schema (block 912). One of the powerful aspects of the forms-designer application 126 is that it can determine this range of documents even when the markup-language schema defines an arbitrary syntax or does not conform to a known standard. This ability enables the forms-designer application 126 to create generalized instances for these schemas. With these generalized instances, it can build electronic forms for use with data files having non-standard or arbitrary structures.


With the range of markup-language documents that can conform to the markup-language schema, the system 100 infers a markup-language document that conforms to the markup-language schema. With the markup-language document and its schema, the system 100 creates a generalized instance as set forth in block 906 above.


Rendering-Language and Transformation-Language Documents



FIG. 10 sets forth a process 1000 for rendering of transformation-language components and generating a transformation-language document.


The process 100 is illustrated as a series of blocks representing individual operations or acts performed by the system 100. The process 1000 may be implemented in any suitable hardware, software, firmware, or combination thereof. In the case of software and firmware, the process 100 represents a set of operations implemented as computer-executable instructions stored in memory and executable by one or more processors.


The process 1000 begins with a block 1002, where they system 100 prepares hierarchical data into a generalized instance, as set forth in the description of the process 900. The process 1000 can start with a generalized instance through block 1002 or otherwise, so long as the hierarchical data is displayed.


In the following description of the process 1000, hierarchical data is sometimes referred to as a markup-language document and components as transformation-language components. It is to be understood that these terms are used to aid in the clear exposition of the process 1000, and are not in any way limiting of the process 1000.


Creating and Annotating a Rendering-Language Document


In block 1004, the system 100 creates and/or annotates a rendering-language document. A rendering-language document is a document or file that, when executed (alone or in conjunction with other files or applications) displays a view on a screen. One example is a file that displays a webpage. This type of file gives a reader a view of information, such as through text, graphics, and the like. A rendering-language document is not the same thing as an electronic form, but rather is a view of what an electronic form can look lie. Thus, a rendering-language document can create views seen in the form-design area 112.


As part of the block 1004, the system 100 creates a rendering-language document by applying one or more components on one or more parts of hierarchical data. In the following description, the components are written in a transformation-language and the hierarchical data includes a markup-language document.


Rendering-language documents can be written in HTML or XHTML document, other machine-language documents, or other documents adept at viewing or displaying. To create rendering-language documents written in XHTML, the system 100 applies one or more XSLT transformation-language components on one or more nodes or portions of an XML document.


Once the system 100 creates a rendering-language document, the system 100 can annotate the rendering-language document to make it easier to create an electronic form from the rendering-language document.


These annotations include two primary types. One annotation indicates the type of transformation-language component selected. Another annotation indicate the node of the tree of hierarchical data selected (or part of the hierarchical data). The placement chosen for each component on the form-design area 112 can be part of the rendering-language document, but is not generally considered an annotation. Thus, the product to this point is an annotated rendering-language document (such as an XHTML document) that can render (shows a vie of) the selected transformation-language component (such as an XSLT component) on the form-design area 112 (such as is set forth in FIG. 2).


Annotating the rendering-language document by adding this information enriches the rendering-language document so that it contains information for the system 100 to later analyze the rendering-language document to help create an electronic form. The system 100 can, for example, identify the annotations in an annotated rendering-language document to create an electronic form visually mimicking the view created by the annotated rendering-language document. Thus, in this example, the system 100 can create an electronic form mimicking the view of the transformation-language components set forth and manipulated by a designer in the form-design area 112 (such as set forth in FIG. 2. With the electronic form a user can enter information into fields of the electronic form that can be retained by a file. The file, in some cases, mimics the structure of the hierarchical data file from which the electronic form was created, such as an XML document.


Rendering Transformation-Language Components with a Rendering-Language Document


Once this rendering-language document is created and/or annotated, it can be used by the system 100 to render transformation-language components, as set forth in a block 1006. Typically, the system 100 renders the transformation-language components on a display, such as the form-design area 112 of the screen 102 of FIG. 1.


Based on the structure of the rendering-language document, the system 100 can render transformation-language components in various ways. For example, the system 100 can render the text box 502 of FIG. 5 (which is a component) to look like the box set forth in FIG. 6 as the text box representation 602.


In FIG. 2, for instance, the system 100 renders transformation-language components with a rendering-language document to create the view set forth in the form-design area 112, which mimics how the electronic form will appear.


Thus, using XSLT transformation-language components, XML hierarchical data, and XHTML rendering-language documents as examples, once the system 100 receives from a designer a selection and placement of one of a list XSLT transformation-language components associated with a selected node of the XML document, such as by the designer clicking on the XSLT transformation-language component's icon or text and dragging the icon or text over to the form-design area 112, the system 100 renders the transformation-language component.


To do so, the system 100 applies the selected XSLT transformation-language component to the XML hierarchical data represented by the selected node or portion. By so doing, the system 100 creates an XHTML document that renders a visual representation of the XSLT transformation-language component on the form-design area 112 at the place the designer selected.


Compiling Transformation-Language Components into a Transformation Language Document


In block 1008, the system then determines, from the annotated rendering-language document, the transformation-language components used and the location of the nodes in the markup-language document that are associated with each transformation-language component rendered. In block 1012, the system generates a transformation-language document from this information (as well as the information regarding the placement style, and formatting of transformation-language components included within the rendering-language document), either after or independent of a designer saving the form-design screen 112 (block 1010).


The transformation-language document is the document ultimately created and saved by the system 100, while the rendering-language document is no longer needed. This is because the transformation-language document can create a view of hierarchical data mimicking the view created by the rendering-language document that was used to create the transformation-language document. The transformation-language document, when applied to a markup-language document having the same schema as the one from which the parts were chosen by the designer, will create an electronic form visually mimicking the rendering made by the rendering-language document. The electronic form created, however, can contain fields that can be populated by information from a user or from another markup-language document.


The electronic form created can be used by a user to key in information into fields, such as the purpose of an appointment (see the form-design area 112 of FIG. 2). The electronic form created can also have its fields populated by other hierarchical data files, thereby reducing the labor needed to key-in information by hand. One way in which an electronic form can be created with one or more fields already populated, is by applying a transformation-language document to a markup-language data file containing information. The result can be an electronic form with the fields filled where nodes of a markup-language data file corresponding to those fields contain information.


Thus, a designer not knowledgeable about transformation-language documents or programming can, in an easy-to-us way, create an electronic form from a markup-language document. This electronic form also can be flexibly created, allowing a designer to choose various transformation-language components, change the orientation and placement of the transformation-language components, change the font, color, size, and make other word-processor-like changes to the transformation-language components, so that the electronic form will have the structure and look intended by the designer.


The system 100 can even create XSLT transformation-language documents, which are especially complex. In this case, a designer having little knowledge about the XSLT language can create, using XSLT transformation-language components, XML hierarchical data, and an XHTML rendering-language document as examples, an XSLT transformation-language document.


A Computer System



FIG. 11 shows an exemplary computer system that can be used to implement the processes described herein. Computer 142 includes one or more processors or processing units 114, a system memory 146, and a bus 148 that couples various system components including the system memory 146 to processors 144. The bus 148 represents one or more of any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. The system memory 146 includes read only memory (ROM) 150 and random access memory (RAM) 152. A basic input/output system (BIOS) 154, containing the basic routines that help to transfer information between elements within computer 142, such as during start-up, is stored in ROM 150.


Computer 142 further includes a hard disk drive 156 for reading from and writing to a hard disk (not shown), a magnetic disk drive 158 for reading from and writing to a removable magnetic disk 160, and an optical disk drive 162 for reading from or writing to a removable optical disk 164 such as a CD ROM or other optical media. The hard disk drive 156, magnetic disk drive 158, and optical disk drive 162 are connected to the bus 148 by an SCSI interface 166 or some other appropriate interface. The drives and their associated computer-readable media provide nonvolatile storage of computer-readable instructions, data structures, program modules and other data for computer 142. Although the exemplary environment described herein employs a hard disk, a removable magnetic disk 160 and a removable optical disk 164, it should be appreciated by those skilled in the art that other types of computer-readable media which can store data that is accessible by a computer, such as magnetic cassettes, flash memory cards, digital video disks, random access memories (RAMs), read only memories (ROMs), and the like, may also be used in the exemplary operating environment.


A number of program modules may be stored on the hard disk 156, magnetic disk 160, optical disk 164, ROM 150, or RAM 152, including an operating system 170, one or more forms-designer application 172, other program modules 174, and program data 176. A user may enter commands and information into computer 142 through input devices such as a keyboard 178 and a pointing device 180. Other input devices (not shown) may include a microphone, joystick, game pad, satellite dish, scanner, or the like. These and other input devices are connected to the processing unit 144 through an interface 182 that is coupled to the bus 148. A monitor 184 or other type of display device is also connected to the bus 148 via an interface, such as a video adapter 186. In addition to the monitor, personal computers typically include other peripheral output devices (not shown) such as speakers and printers.


Computer 142 commonly operates in a networked environment using logical connections to one or more remote computers, such as a remote computer 188. The remote computer 188 may be another personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to computer 142. The logical connections depicted in FIG. 11 include a local area network (LAN) and a wide area network (WAN) 194. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets, and the Internet.


When used in a LAN networking environment, computer 142 is connected to the local network through a network interface or adapter 196. When used in a WAN networking environment, computer 142 typically includes a modem 198 or other means for establishing communications over the wide area network 194, such as the Internet. The modem 198, which may be internal or external, is connected to the bus 148 via serial port interface 168. In a networked environment, program modules depicted relative to the personal computer 142, or portions thereof, may be stored in the remote memory storage device. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.


Generally, the data processors of computer 142 are programmed by means of instructions stored at different times in the various computer-readable storage media of the computer. Programs and operating systems are typically distributed, for example, on floppy disks or CD-ROMs. From there, they are installed or loaded into the secondary memory of a computer. At execution, they are loaded at least partially into the computer's primary electronic memory. The invention described herein includes these and other various types of computer-readable storage media when such media contain instructions or programs for implementing the blocks described below in conjunction with a microprocessor or other data processor. The invention also includes the computer itself when programmed according to the methods and techniques described below.


For purposes of illustration, programs and other executable program components such as the operating system are illustrated herein as discrete blocks, although it is recognized that such programs and components reside at various time in different storage components of the computer, and are executed by the data processor(s) of the computer


CONCLUSION

The above-described system and method for generating electronic forms allows a designer to easily create electronic forms from a file of hierarchical data, even if the designer has only very basic skills. The above-described system and method also allows a designer to create, with the click of a mouse, XSLT files capable of transforming XML documents into XHTML files simply by clicking on parts of an XML document and/or its schema. Although the invention has been described in language specific to structural features and/or methodological acts, it is to be understood that the invention defined in the appended claims is not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as exemplary forms of implementing the claimed invention.

Claims
  • 1. One or more computer-readable storage media storing computer-executable instructions that, when executed by a computing device, perform acts comprising: displaying hierarchical data in a first area of a screen;facilitating selection of a first portion and a second portion of the hierarchical data;receiving selection of the first portion of the hierarchical data;displaying, in a second area of the screen and in response to receiving selection of the first portion, a first visual representation of a first operable field corresponding to the first portion;receiving selection of the second portion of the hierarchical data; anddisplaying, in the second area of the screen along with the first visual representation of the first operable field and in response to receiving selection of the second portion, a second visual representation of a second operable field corresponding to the selected second portion, the acts of displaying the first visual representation and the second visual representation being effective to build a visual representation of an electronic form having the first operable field and the second operable field wherein the act of displaying the hierarchical data displays the hierarchical data in a tree arrangement of XML data having portions represented by nodes in the tree arrangement, the act of receiving selection of the first portion receives selection of a first node, and the act of receiving selection of the second portion receives selection of a second node.
  • 2. The computer-readable storage media of claim 1, further comprising: generating an electronic form having the first operable field and the second operable field.
  • 3. The computer-readable storage media of claim 1, further comprising: generating an electronic form that visually mimics the visual representation.
  • 4. The computer-readable storage media of claim 3, wherein the electronic form is created using an XSLT file.
  • 5. The computer readable storage media of claim 1, wherein the act of displaying the first visual representation displays a first XSLT component based on the first node, and the act of displaying the second visual representation displays a second XSLT component based on the second node.
  • 6. The computer-readable storage media of claim 5, further comprising annotating an XHTML document to include a first reference to the first XSLT component and a second reference to the second XSLT component.
  • 7. The computer-readable storage media of claim 6, wherein the act of displaying the first XSLT component renders the first XSLT component based on the first reference in the annotated XHTML document and the act of displaying the second XSLT component renders the second XSLT component based on the second reference in the annotated XHTML document.
  • 8. The computer-readable storage media of claim 5, further comprising identifying the first XSLT component based on a schema governing the first node.
  • 9. One or more computer-readable storage media storing computer-executable instructions that, when executed by a computing device, perform acts comprising: present a first screen area displaying hierarchical data in a tree arrangement of XML data having portions represented by nodes in the tree arrangement;provide an interface to enable two iterations of: selecting a portion of the hierarchical data;through a node in the tree arrangement andarranging a visual representation of an operable field corresponding to the selected portion of the hierarchical data,wherein said portion, node, visual representation, and operable field in the first iteration is a first portion, first node, first visual representation, and first operable field, respectively, and in the second iteration is a second portion, second node, second visual representation, and second operable field, respectively, andpresent a second screen area, in response to each of the iterations of selecting and arranging, to display the first and second visual representations of the first and second operable fields in the selected visual arrangement effective to modularly generate a visual representation of an electronic form having said first and second operable fields.
  • 10. The computer-readable storage media of claim 9, further comprising generating the electronic form visually represented in the second screen area.
  • 11. The computer-readable storage media of claim 10, wherein the electronic form comprises the first and second operable fields represented by the first and second visual representations in the second screen area and in the selected visual arrangement of the first and second visual representations of the first and second operable fields displayed in the second screen area.
  • 12. The computer-readable storage media of claim 9, wherein the interface further enables selecting to alter the selected visual arrangement of the first and second visual representations in the second screen area.
  • 13. The computer-readable storage media of claim 9, wherein the interface further enables selecting to alter an operation of one of the first and second operable fields by altering the visual representation of that operable field.
  • 14. A method comprising: displaying hierarchical data in a first screen area;receiving input selecting a first portion of the hierarchical data;displaying, in a second screen area in response to receiving input selecting the first portion of the hierarchical data, a first visual representation of a first operable field corresponding to the first selected portion of the hierarchical data;receiving, after displaying the first visual representation, input selecting a second portion of the hierarchical data;receiving input visually arranging at least a second visual representation of a second operable field corresponding to the second selected portion of the hierarchical data; anddisplaying, in response to receiving input selecting the second portion of the hierarchical data and receiving input visually arranging the second visual representation, the second visual representation in the second screen area in the selected visual arrangement effective to enable a user to build a visual representation of an electronic form having the first operable field and the second operable field wherein the act of displaying the hierarchical data displays the hierarchical data in a tree arrangement of XML data having portions represented by nodes in the tree arrangement, the act of receiving input of the first portion receives selection of a first node, and the act of receiving input of the second portion receives selection of a second node.
  • 15. The method of claim 14, further comprising generating the electronic form visually mimicking the second screen area and having the first operable field and the second operable field.
  • 16. The method of claim 14, further comprising receiving input altering the visual representation of the first operable field or the second operable field in the second screen area.
  • 17. The method of claim 16, wherein the input altering the visual representation corresponds to an alteration to an operation of the first or second operable field and further comprising generating the electronic form having the alteration to the operation of the first or second operable field.
US Referenced Citations (555)
Number Name Date Kind
4498147 Agnew et al. Feb 1985 A
4514800 Gruner et al. Apr 1985 A
4641274 Swank Feb 1987 A
4674040 Barker et al. Jun 1987 A
4723211 Barker et al. Feb 1988 A
4739477 Barker et al. Apr 1988 A
4815029 Barker et al. Mar 1989 A
4847749 Collins et al. Jul 1989 A
4910663 Bailey Mar 1990 A
4933880 Borgendale et al. Jun 1990 A
4962475 Hernandez et al. Oct 1990 A
5072412 Henderson, Jr. et al. Dec 1991 A
5179703 Evans Jan 1993 A
5182709 Makus Jan 1993 A
5187786 Densmore et al. Feb 1993 A
5191645 Carlucci et al. Mar 1993 A
5195183 Miller et al. Mar 1993 A
5204947 Bernstein et al. Apr 1993 A
5206951 Khoyi et al. Apr 1993 A
5218672 Morgan et al. Jun 1993 A
5237680 Adams et al. Aug 1993 A
5249275 Srivastava Sep 1993 A
5274803 Dubin et al. Dec 1993 A
5297249 Bernstein et al. Mar 1994 A
5297283 Kelly, Jr. et al. Mar 1994 A
5313631 Kao May 1994 A
5313646 Hendricks et al. May 1994 A
5317686 Salas et al. May 1994 A
5333317 Dann Jul 1994 A
5339423 Beitel et al. Aug 1994 A
5339424 Fushimi Aug 1994 A
5341478 Travis, Jr. et al. Aug 1994 A
5369766 Nakano et al. Nov 1994 A
5369778 San Soucie et al. Nov 1994 A
5371675 Greif et al. Dec 1994 A
5377323 Vasudevan Dec 1994 A
5379419 Heffernan et al. Jan 1995 A
5381547 Flug et al. Jan 1995 A
5390325 Miller Feb 1995 A
5396623 McCall et al. Mar 1995 A
5408665 Fitzgerald Apr 1995 A
5410646 Tondevold et al. Apr 1995 A
5410688 Williams et al. Apr 1995 A
5412772 Monson May 1995 A
5434975 Allen Jul 1995 A
5436637 Gayraud et al. Jul 1995 A
5438659 Notess et al. Aug 1995 A
5440744 Jacobson et al. Aug 1995 A
5446842 Schaeffer et al. Aug 1995 A
5459865 Heninger et al. Oct 1995 A
5481722 Skinner Jan 1996 A
5497489 Menne Mar 1996 A
5504898 Klein Apr 1996 A
5517655 Collins et al. May 1996 A
5535389 Elder et al. Jul 1996 A
5542070 LeBlanc et al. Jul 1996 A
5550976 Henderson et al. Aug 1996 A
5551035 Arnold et al. Aug 1996 A
5572643 Judson Nov 1996 A
5572648 Bibayan Nov 1996 A
5577252 Nelson et al. Nov 1996 A
5581686 Koppolu et al. Dec 1996 A
5581760 Atkinson et al. Dec 1996 A
5602996 Powers, III et al. Feb 1997 A
5608720 Biegel et al. Mar 1997 A
5625783 Ezekiel et al. Apr 1997 A
5627979 Chang et al. May 1997 A
5630126 Redpath May 1997 A
5634121 Tracz et al. May 1997 A
5640544 Onodera et al. Jun 1997 A
5644738 Goldman et al. Jul 1997 A
5649099 Theimer et al. Jul 1997 A
5659729 Nielsen Aug 1997 A
5664178 Sinofsky Sep 1997 A
5668966 Ono et al. Sep 1997 A
5669005 Curbow et al. Sep 1997 A
5682536 Atkinson et al. Oct 1997 A
5689667 Kurtenbach Nov 1997 A
5689703 Atkinson et al. Nov 1997 A
5704029 Wright, Jr. Dec 1997 A
5706501 Horikiri et al. Jan 1998 A
5717939 Bricklin et al. Feb 1998 A
5721824 Taylor Feb 1998 A
5740439 Atkinson et al. Apr 1998 A
5742504 Meyer et al. Apr 1998 A
5745683 Lee et al. Apr 1998 A
5745712 Turpin et al. Apr 1998 A
5758184 Lucovsky et al. May 1998 A
5758358 Ebbo May 1998 A
5761408 Kolawa et al. Jun 1998 A
5761683 Logan et al. Jun 1998 A
5764984 Loucks Jun 1998 A
5764985 Smale Jun 1998 A
5778372 Cordell et al. Jul 1998 A
5778402 Gipson Jul 1998 A
5784555 Stone Jul 1998 A
5790796 Sadowsky Aug 1998 A
5798757 Smith Aug 1998 A
5801701 Koppolu et al. Sep 1998 A
5802304 Stone Sep 1998 A
5806079 Rivette et al. Sep 1998 A
5815830 Anthony Sep 1998 A
5826265 Van Huben et al. Oct 1998 A
5835777 Staelin Nov 1998 A
5838906 Doyle et al. Nov 1998 A
5842018 Atkinson et al. Nov 1998 A
5845077 Fawcett Dec 1998 A
5845090 Collins, III et al. Dec 1998 A
5854630 Nielsen Dec 1998 A
5859973 Carpenter et al. Jan 1999 A
5862372 Morris et al. Jan 1999 A
5864819 De Armas et al. Jan 1999 A
5907704 Gudmundson et al. May 1999 A
5910895 Proskauer et al. Jun 1999 A
5911776 Guck Jun 1999 A
5915112 Boutcher Jun 1999 A
5922072 Hutchinson et al. Jul 1999 A
5929858 Shibata et al. Jul 1999 A
5940075 Mutschler, III et al. Aug 1999 A
5950010 Hesse et al. Sep 1999 A
5956481 Walsh et al. Sep 1999 A
5960199 Brodsky et al. Sep 1999 A
5963964 Nielsen Oct 1999 A
5974454 Apfel et al. Oct 1999 A
5982370 Kamper Nov 1999 A
5987480 Donohue et al. Nov 1999 A
5991710 Papineni et al. Nov 1999 A
5991877 Luckenbaugh Nov 1999 A
5995103 Ashe Nov 1999 A
5999740 Rowley Dec 1999 A
6005570 Gayraud et al. Dec 1999 A
6014135 Fernandes Jan 2000 A
6016520 Facq et al. Jan 2000 A
6018743 Xu Jan 2000 A
6026379 Haller et al. Feb 2000 A
6026416 Kanerva et al. Feb 2000 A
6031989 Cordell Feb 2000 A
6035297 Van Huben et al. Mar 2000 A
6035309 Dauerer et al. Mar 2000 A
6044205 Reed et al. Mar 2000 A
6052531 Waldin et al. Apr 2000 A
6052710 Saliba et al. Apr 2000 A
6054987 Richardson Apr 2000 A
6072870 Nguyen et al. Jun 2000 A
6078326 Kilmer et al. Jun 2000 A
6078327 Liman et al. Jun 2000 A
6078924 Ainsbury et al. Jun 2000 A
6081610 Dwork et al. Jun 2000 A
6084585 Kraft et al. Jul 2000 A
6088708 Burch et al. Jul 2000 A
6091417 Lefkowitz Jul 2000 A
6094657 Hailpern et al. Jul 2000 A
6097382 Rosen et al. Aug 2000 A
6098081 Heidorn et al. Aug 2000 A
6108637 Blumenau Aug 2000 A
6108783 Krawczyk et al. Aug 2000 A
6115646 Fiszman et al. Sep 2000 A
6121965 Kenney et al. Sep 2000 A
6122647 Horowitz et al. Sep 2000 A
6144969 Inokuchi et al. Nov 2000 A
6151624 Teare et al. Nov 2000 A
6154128 Wookey et al. Nov 2000 A
6163772 Kramer et al. Dec 2000 A
6167521 Smith et al. Dec 2000 A
6167523 Strong Dec 2000 A
6182095 Leymaster et al. Jan 2001 B1
6188401 Peyer Feb 2001 B1
6191797 Politis Feb 2001 B1
6192367 Hawley et al. Feb 2001 B1
6195661 Filepp et al. Feb 2001 B1
6199204 Donohue Mar 2001 B1
6209128 Gerard et al. Mar 2001 B1
6216152 Wong et al. Apr 2001 B1
6219698 Iannucci et al. Apr 2001 B1
6225996 Gibb et al. May 2001 B1
6235027 Herzon May 2001 B1
6253366 Mutschler, III Jun 2001 B1
6253374 Dresevic et al. Jun 2001 B1
6263313 Milsted et al. Jul 2001 B1
6266810 Tanaka et al. Jul 2001 B1
6268852 Lindhorst et al. Jul 2001 B1
6272506 Bell Aug 2001 B1
6275227 DeStefano Aug 2001 B1
6275599 Adler et al. Aug 2001 B1
6281896 Alimpich et al. Aug 2001 B1
6282711 Halpern et al. Aug 2001 B1
6286033 Kishinsky et al. Sep 2001 B1
6292897 Gennaro et al. Sep 2001 B1
6297819 Furst Oct 2001 B1
6300948 Geller et al. Oct 2001 B1
6307955 Zank et al. Oct 2001 B1
6308179 Petersen et al. Oct 2001 B1
6311271 Gennaro et al. Oct 2001 B1
6321259 Ouellette et al. Nov 2001 B1
6321334 Jerger et al. Nov 2001 B1
6327628 Anuff et al. Dec 2001 B1
6331864 Coco et al. Dec 2001 B1
6342907 Petty et al. Jan 2002 B1
6343302 Graham Jan 2002 B1
6345256 Milsted et al. Feb 2002 B1
6345278 Hitchcock et al. Feb 2002 B1
6345361 Jerger et al. Feb 2002 B1
6347323 Garber et al. Feb 2002 B1
6349408 Smith Feb 2002 B1
6353926 Parthesarathy et al. Mar 2002 B1
6356906 Lippert et al. Mar 2002 B1
6357038 Scouten Mar 2002 B1
6366907 Fanning et al. Apr 2002 B1
6366912 Wallent et al. Apr 2002 B1
6367013 Bisbee et al. Apr 2002 B1
6369840 Barnett et al. Apr 2002 B1
6369841 Salomon et al. Apr 2002 B1
6374402 Schmeidler et al. Apr 2002 B1
6381742 Forbes et al. Apr 2002 B2
6381743 Mutschler, III Apr 2002 B1
6389434 Rivette et al. May 2002 B1
6393456 Ambler et al. May 2002 B1
6396488 Simmons et al. May 2002 B1
6405221 Levine et al. Jun 2002 B1
6408311 Baisley et al. Jun 2002 B1
6414700 Kurtenbach et al. Jul 2002 B1
6421070 Ramos et al. Jul 2002 B1
6421656 Cheng et al. Jul 2002 B1
6425125 Fries et al. Jul 2002 B1
6429885 Saib et al. Aug 2002 B1
6434563 Pasquali et al. Aug 2002 B1
6434564 Ebert Aug 2002 B2
6442563 Bacon et al. Aug 2002 B1
6442755 Lemmons et al. Aug 2002 B1
6446110 Lection et al. Sep 2002 B1
6449617 Quinn et al. Sep 2002 B1
6457009 Bollay Sep 2002 B1
6460058 Koppolu et al. Oct 2002 B2
6463419 Kluss Oct 2002 B1
6470349 Heninger et al. Oct 2002 B1
6473800 Jerger et al. Oct 2002 B1
6476828 Burkett et al. Nov 2002 B1
6476833 Moshfeghi Nov 2002 B1
6477544 Bolosky et al. Nov 2002 B1
6480860 Monday Nov 2002 B1
6487566 Sundaresan Nov 2002 B1
6490601 Markus et al. Dec 2002 B1
6493702 Adar et al. Dec 2002 B1
6502101 Verprauskus et al. Dec 2002 B1
6502103 Frey et al. Dec 2002 B1
6505230 Mohan et al. Jan 2003 B1
6505300 Chan et al. Jan 2003 B2
6507856 Chen et al. Jan 2003 B1
6516322 Meredith Feb 2003 B1
6519617 Wanderski et al. Feb 2003 B1
RE38070 Spies et al. Apr 2003 E
6546546 Van Doorn Apr 2003 B1
6549221 Brown et al. Apr 2003 B1
6549878 Lowry et al. Apr 2003 B1
6549922 Srivastava et al. Apr 2003 B1
6553402 Makarios et al. Apr 2003 B1
6560616 Garber May 2003 B1
6560620 Ching May 2003 B1
6560640 Smethers May 2003 B2
6563514 Samar May 2003 B1
6571253 Thompson et al. May 2003 B1
6578144 Gennaro et al. Jun 2003 B1
6581061 Graham Jun 2003 B2
6584548 Bourne et al. Jun 2003 B1
6585778 Hind et al. Jul 2003 B1
6589290 Maxwell et al. Jul 2003 B1
6598219 Lau Jul 2003 B1
6603489 Edlund et al. Aug 2003 B1
6604099 Chung et al. Aug 2003 B1
6606606 Starr Aug 2003 B2
6609200 Anderson et al. Aug 2003 B2
6611822 Beams et al. Aug 2003 B1
6611840 Baer et al. Aug 2003 B1
6611843 Jacobs Aug 2003 B1
6613098 Sorge et al. Sep 2003 B1
6615276 Mastriann et al. Sep 2003 B1
6629109 Koshisaka Sep 2003 B1
6631357 Perkowski Oct 2003 B1
6631379 Cox Oct 2003 B2
6631497 Jamshidi et al. Oct 2003 B1
6631519 Nicholson et al. Oct 2003 B1
6632251 Rutten et al. Oct 2003 B1
6635089 Burkett et al. Oct 2003 B1
6636845 Chau et al. Oct 2003 B2
6643633 Chau et al. Nov 2003 B2
6643652 Helgeson et al. Nov 2003 B2
6643684 Malkin et al. Nov 2003 B1
6651217 Kennedy et al. Nov 2003 B1
6654737 Nunez Nov 2003 B1
6654932 Bahrs et al. Nov 2003 B1
6658417 Stakutis et al. Dec 2003 B1
6658622 Aiken et al. Dec 2003 B1
6668369 Krebs et al. Dec 2003 B1
6671805 Brown et al. Dec 2003 B1
6675202 Perttunen Jan 2004 B1
6678717 Schneider Jan 2004 B1
6691230 Bardon Feb 2004 B1
6691281 Sorge et al. Feb 2004 B1
6697944 Jones et al. Feb 2004 B1
6701434 Rohatgi Mar 2004 B1
6701486 Weber et al. Mar 2004 B1
6704906 Yankovich et al. Mar 2004 B1
6711679 Guski et al. Mar 2004 B1
6720985 Lapstun et al. Apr 2004 B1
6725426 Pavlov Apr 2004 B1
6735721 Morrow et al. May 2004 B1
6748385 Rodkin et al. Jun 2004 B1
6751777 Bates et al. Jun 2004 B2
6754874 Richman Jun 2004 B1
6757868 Glaser et al. Jun 2004 B1
6760723 Oshinsky et al. Jul 2004 B2
6763343 Brooke et al. Jul 2004 B1
6772139 Smith, III Aug 2004 B1
6772165 O'Carroll Aug 2004 B2
6774926 Ellis et al. Aug 2004 B1
6779154 Nussbaum et al. Aug 2004 B1
6781609 Barker et al. Aug 2004 B1
6799299 Li et al. Sep 2004 B1
6801929 Donoho et al. Oct 2004 B1
6816849 Halt, Jr. Nov 2004 B1
6845380 Su et al. Jan 2005 B2
6845499 Srivastava et al. Jan 2005 B2
6847387 Roth Jan 2005 B2
6848078 Birsan et al. Jan 2005 B1
6871220 Rajan et al. Mar 2005 B1
6874130 Baweja et al. Mar 2005 B1
6876996 Czajkowski et al. Apr 2005 B2
6889359 Conner et al. May 2005 B1
6901403 Bata et al. May 2005 B1
6915454 Moore et al. Jul 2005 B1
6931532 Davis et al. Aug 2005 B1
6941510 Ozzie et al. Sep 2005 B1
6941511 Hind et al. Sep 2005 B1
6941521 Lin et al. Sep 2005 B2
6948133 Haley Sep 2005 B2
6948135 Ruthfield et al. Sep 2005 B1
6950980 Malcolm Sep 2005 B1
6961897 Peel, Jr. et al. Nov 2005 B1
6963875 Moore et al. Nov 2005 B2
6968503 Chang et al. Nov 2005 B1
6968505 Stoll et al. Nov 2005 B2
6993714 Kaler et al. Jan 2006 B2
6996776 Makely et al. Feb 2006 B1
6996781 Myers et al. Feb 2006 B1
7003722 Rothchiller et al. Feb 2006 B2
7010580 Fu et al. Mar 2006 B1
7024417 Russakovsky et al. Apr 2006 B1
7032170 Poulose Apr 2006 B2
7036072 Sulistio et al. Apr 2006 B1
7039875 Khalfay et al. May 2006 B2
7051273 Holt et al. May 2006 B1
7058663 Johnston et al. Jun 2006 B2
7062764 Cohen et al. Jun 2006 B2
7065493 Homsi Jun 2006 B1
7080325 Treibach-Heck et al. Jul 2006 B2
7086009 Resnick et al. Aug 2006 B2
7088374 David et al. Aug 2006 B2
7103611 Murthy et al. Sep 2006 B2
7106888 Silverbrook et al. Sep 2006 B1
7107282 Yalamanchi Sep 2006 B1
7107521 Santos Sep 2006 B2
7152205 Day et al. Dec 2006 B2
7190376 Tonisson Mar 2007 B1
7191394 Ardeleanu et al. Mar 2007 B1
7281018 Begun et al. Oct 2007 B1
7296017 Larcheveque et al. Nov 2007 B2
20010007109 Lange Jul 2001 A1
20010022592 Alimpich et al. Sep 2001 A1
20010024195 Hayakawa Sep 2001 A1
20010037345 Kiernan Nov 2001 A1
20010054004 Powers Dec 2001 A1
20010056429 Moore et al. Dec 2001 A1
20010056460 Sahota et al. Dec 2001 A1
20020010700 Wotring Jan 2002 A1
20020010743 Ryan et al. Jan 2002 A1
20020010746 Jilk et al. Jan 2002 A1
20020013788 Pennell et al. Jan 2002 A1
20020023113 Hsing et al. Feb 2002 A1
20020026441 Kutay Feb 2002 A1
20020026461 Kutay et al. Feb 2002 A1
20020032590 Anand et al. Mar 2002 A1
20020032692 Suzuki et al. Mar 2002 A1
20020032706 Perla et al. Mar 2002 A1
20020032768 Voskuil Mar 2002 A1
20020035579 Wang et al. Mar 2002 A1
20020035581 Reymar et al. Mar 2002 A1
20020040469 Pramberger Apr 2002 A1
20020054128 Lau et al. May 2002 A1
20020057297 Grimes et al. May 2002 A1
20020065798 Bostleman et al. May 2002 A1
20020070973 Croley Jun 2002 A1
20020078074 Cho et al. Jun 2002 A1
20020078103 Gorman et al. Jun 2002 A1
20020100027 Binding et al. Jul 2002 A1
20020112224 Cox Aug 2002 A1
20020129056 Conant Sep 2002 A1
20020133484 Chau et al. Sep 2002 A1
20020152222 Holbrook Oct 2002 A1
20020152244 Dean et al. Oct 2002 A1
20020156772 Chau et al. Oct 2002 A1
20020156846 Rawat et al. Oct 2002 A1
20020156929 Hekmatpour Oct 2002 A1
20020169752 Kusama et al. Nov 2002 A1
20020169789 Kutay Nov 2002 A1
20020174147 Wang et al. Nov 2002 A1
20020174417 Sijacic et al. Nov 2002 A1
20020184219 Preisig et al. Dec 2002 A1
20020188597 Kern et al. Dec 2002 A1
20020188613 Chakraborty et al. Dec 2002 A1
20020194219 Bradley et al. Dec 2002 A1
20020196281 Audleman et al. Dec 2002 A1
20020196288 Emrani Dec 2002 A1
20020198891 Li et al. Dec 2002 A1
20020198935 Crandall, Sr et al. Dec 2002 A1
20030004951 Chokshi Jan 2003 A1
20030007000 Carlson et al. Jan 2003 A1
20030014397 Chau et al. Jan 2003 A1
20030018668 Britton et al. Jan 2003 A1
20030020746 Chen et al. Jan 2003 A1
20030023641 Gorman et al. Jan 2003 A1
20030025732 Prichard Feb 2003 A1
20030033037 Yuen et al. Feb 2003 A1
20030037303 Bodlaender Feb 2003 A1
20030043986 Creamer Mar 2003 A1
20030046665 Ilin Mar 2003 A1
20030048301 Menninger Mar 2003 A1
20030051243 Lemmons et al. Mar 2003 A1
20030055811 Stork et al. Mar 2003 A1
20030055828 Koch et al Mar 2003 A1
20030056198 Al-Azzawe Mar 2003 A1
20030061386 Brown Mar 2003 A1
20030061567 Brown et al. Mar 2003 A1
20030084424 Reddy et al. May 2003 A1
20030093755 O'Carroll May 2003 A1
20030120578 Newman Jun 2003 A1
20030120651 Bernstein et al. Jun 2003 A1
20030120659 Sridhar Jun 2003 A1
20030120671 Kim et al. Jun 2003 A1
20030120686 Kim et al. Jun 2003 A1
20030126555 Aggarwal et al. Jul 2003 A1
20030128196 Lapstun et al. Jul 2003 A1
20030135825 Gertner et al. Jul 2003 A1
20030140132 Champagne et al. Jul 2003 A1
20030158897 Ben-Natan et al. Aug 2003 A1
20030167277 Hejlsberg et al. Sep 2003 A1
20030182268 Lal Sep 2003 A1
20030182327 Ramanujam et al. Sep 2003 A1
20030187756 Klivington et al. Oct 2003 A1
20030187930 Ghaffar et al. Oct 2003 A1
20030188260 Jensen et al. Oct 2003 A1
20030189593 Yarvin Oct 2003 A1
20030192008 Lee Oct 2003 A1
20030204511 Brundage Oct 2003 A1
20030204814 Elo et al. Oct 2003 A1
20030205615 Marappan Nov 2003 A1
20030212664 Breining et al. Nov 2003 A1
20030217053 Bachman et al. Nov 2003 A1
20030220930 Milleker et al. Nov 2003 A1
20030225469 DeRemer et al. Dec 2003 A1
20030225768 Chaudhuri Dec 2003 A1
20030225829 Pena et al. Dec 2003 A1
20030226111 Wirts et al. Dec 2003 A1
20030226132 Tondreau et al. Dec 2003 A1
20030233374 Spinola et al. Dec 2003 A1
20030236859 Vaschillo et al. Dec 2003 A1
20030237046 Parker et al. Dec 2003 A1
20030237047 Borson Dec 2003 A1
20040002939 Arora Jan 2004 A1
20040003031 Brown et al. Jan 2004 A1
20040003353 Rivera et al. Jan 2004 A1
20040003389 Reynar et al. Jan 2004 A1
20040010752 Chan et al. Jan 2004 A1
20040024842 Witt Feb 2004 A1
20040030991 Hepworth et al. Feb 2004 A1
20040039990 Bakar et al. Feb 2004 A1
20040039993 Kougiouris et al. Feb 2004 A1
20040044961 Pesenson Mar 2004 A1
20040044965 Toyama et al. Mar 2004 A1
20040054966 Busch et al. Mar 2004 A1
20040059754 Barghout et al. Mar 2004 A1
20040073565 Kaufman et al. Apr 2004 A1
20040073868 Easter et al. Apr 2004 A1
20040078756 Napper et al. Apr 2004 A1
20040083426 Sahu Apr 2004 A1
20040088647 Miller et al. May 2004 A1
20040093596 Koyano May 2004 A1
20040107367 Kisters Jun 2004 A1
20040117769 Lauzon et al. Jun 2004 A1
20040123277 Schrader et al. Jun 2004 A1
20040146199 Berkner et al. Jul 2004 A1
20040163041 Engel Aug 2004 A1
20040172442 Ripley Sep 2004 A1
20040186762 Beaven et al. Sep 2004 A1
20040189716 Paoli et al. Sep 2004 A1
20040194035 Chakraborty Sep 2004 A1
20040205473 Fisher et al. Oct 2004 A1
20040205525 Murren et al. Oct 2004 A1
20040205534 Koelle Oct 2004 A1
20040205571 Adler et al. Oct 2004 A1
20040205592 Huang Oct 2004 A1
20040205605 Adler et al. Oct 2004 A1
20040205653 Hadfield et al. Oct 2004 A1
20040205671 Sukehiro et al. Oct 2004 A1
20040210599 Friedman et al. Oct 2004 A1
20040221238 Cifra et al. Nov 2004 A1
20040221245 Chickles et al. Nov 2004 A1
20040237030 Malkin Nov 2004 A1
20040268229 Paoli et al. Dec 2004 A1
20050004893 Sangroniz Jan 2005 A1
20050005248 Rockey et al. Jan 2005 A1
20050015732 Vedula et al. Jan 2005 A1
20050022115 Baumgartner et al. Jan 2005 A1
20050027757 Klessig et al. Feb 2005 A1
20050038711 Marlelo Feb 2005 A1
20050055627 Lloyd et al. Mar 2005 A1
20050060324 Johnson et al. Mar 2005 A1
20050065933 Goering Mar 2005 A1
20050065936 Goering Mar 2005 A1
20050066287 Tattrie et al. Mar 2005 A1
20050071752 Marlatt Mar 2005 A1
20050076049 Qubti et al. Apr 2005 A1
20050091285 Krishnan et al. Apr 2005 A1
20050091305 Lange et al. Apr 2005 A1
20050102370 Lin et al. May 2005 A1
20050102612 Allan et al. May 2005 A1
20050108104 Woo May 2005 A1
20050108624 Carrier May 2005 A1
20050114757 Sahota et al. May 2005 A1
20050138086 Pecht-Seibert Jun 2005 A1
20050171746 Thalhammer-Reyero Aug 2005 A1
20050198086 Moore Sep 2005 A1
20050198247 Perry et al. Sep 2005 A1
20050223063 Chang et al. Oct 2005 A1
20050223320 Brintzenhofe et al. Oct 2005 A1
20050240876 Myers et al. Oct 2005 A1
20050268222 Cheng Dec 2005 A1
20060020586 Prompt et al. Jan 2006 A1
20060026534 Ruthfield et al. Feb 2006 A1
20060031757 Vincent, III Feb 2006 A9
20060036995 Chickles et al. Feb 2006 A1
20060041838 Khan Feb 2006 A1
20060059434 Boss et al. Mar 2006 A1
20060069605 Hatoun Mar 2006 A1
20060069985 Friedman et al. Mar 2006 A1
20060085409 Rys et al. Apr 2006 A1
20060143220 Spencer, Jr. Jun 2006 A1
20070036433 Teutsch Feb 2007 A1
20070050719 Lui et al. Mar 2007 A1
20070061467 Essey Mar 2007 A1
20070061706 Cupala Mar 2007 A1
20070074106 Ardeleanu Mar 2007 A1
20070094589 Paoli Apr 2007 A1
20070100877 Paoli May 2007 A1
20070101280 Paoli May 2007 A1
20070118803 Walker et al. May 2007 A1
Foreign Referenced Citations (21)
Number Date Country
0 841 615 May 1998 EP
0 961 197 Dec 1999 EP
1 076 290 Feb 2001 EP
1221661 Jul 2002 EP
63085960 Apr 1988 JP
401173140 Jul 1989 JP
3191429 Aug 1991 JP
4225466 Aug 1992 JP
5314152 Nov 1993 JP
406014105 Jan 1994 JP
6139241 May 1994 JP
6180697 Jun 1994 JP
6180698 Jun 1994 JP
2000132436 May 2000 JP
2002183652 Jun 2002 JP
2003173288 Jun 2003 JP
WO 9924945 May 1999 WO
WO 9956207 Nov 1999 WO
WO 0144934 Jun 2001 WO
WO0157720 Aug 2001 WO
WO0157720 Mar 2006 WO