Source: http://www.google.com/patents/US20070101280?dq=6,250,774
Timestamp: 2016-07-27 12:32:57
Document Index: 367429944

Matched Legal Cases: ['art 704', 'art 816', 'arts 818', 'art 1202', 'art 1204', 'art 1210', 'art 1212', 'art 1204', 'art 1210', 'art 1218', 'art 1222', 'art 1212', 'art 1204', 'art 1218', 'art 1226', 'art 1230', 'art 1234', 'art 1236', 'art 1212', 'art 1204', 'art 1218', 'art 1212', 'art 1218', 'art 1202', 'art 1222', 'arts 1204']

Patent US20070101280 - Closer Interface for Designing Electronic Forms and Hierarchical Schemas - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inPatentsA system and method that enables a designer to build electronic forms and corresponding hierarchical schemas are described. Displays of hierarchical schemas, electronic forms, and components used to build the hierarchical schemas and electronic forms are provided to the designer. The designer selects...http://www.google.com/patents/US20070101280?utm_source=gb-gplus-sharePatent US20070101280 - Closer Interface for Designing Electronic Forms and Hierarchical SchemasAdvanced Patent SearchPublication numberUS20070101280 A1Publication typeApplicationApplication numberUS 11/567,149Publication dateMay 3, 2007Filing dateDec 5, 2006Priority dateMar 24, 2003Also published asUS7275216, US8117552, US20040189716, US20070094589, US20070100877Publication number11567149, 567149, US 2007/0101280 A1, US 2007/101280 A1, US 20070101280 A1, US 20070101280A1, US 2007101280 A1, US 2007101280A1, US-A1-20070101280, US-A1-2007101280, US2007/0101280A1, US2007/101280A1, US20070101280 A1, US20070101280A1, US2007101280 A1, US2007101280A1InventorsJean Paoli, Laurent Mollicone, Ned Friend, Matthew Kotler, Thomas Lawrence, Shuk-Yan Lai, Sharma Hendel, Jason WhitmarshOriginal AssigneeMicrosoft CorporationExport CitationBiBTeX, EndNote, RefManPatent Citations (99), Referenced by (38), Classifications (8), Legal Events (1) External Links: USPTO, USPTO Assignment, EspacenetCloser Interface for Designing Electronic Forms and Hierarchical Schemas
[0024] The same numbers are used throughout the disclosure and figures to reference like components and features. DETAILED DESCRIPTION [0025] The following disclosure describes a user-friendly way to design electronic forms and corresponding hierarchical schemas using components and a form-designing area of a display. Components are presented in an area of a display screen, usually graphically, such as with an arrangement of icons. Icons representing each component are a simplification so that a designer can more easily understand the purpose of and choose from a list of components. A designer can choose each component that he or she wishes to include in an electronic form. [0026] The designer can choose a component, such as by clicking on an icon representing a component, to 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. Parts of a hierarchical schema, called schema parts, correspond to the components in the form-design area, and can also be manipulated by the designer. This hierarchical schema can be represented as an XML file or as a data store. When represented as an XML file, a data store can also later be inferred from it. [0027] With each new component added or modified, and in some cases each change made to an electronic form or hierarchical schema, the electronic form and corresponding hierarchical schema are altered to reflect that change. This incremental building of an electronic form and hierarchical schema, and the fact that they are linked so that a change to one can almost instantly be reflected in the other, allows a designer to quickly, easily, and intuitively create electronic forms and corresponding hierarchical schemas. [0028] For discussion purposes, the visual representation of the components, hierarchical schema, and electronic form are described in the context of a single computer, a set of user-input devices, and a single display screen having areas for displaying a representation of the components, the electronic form, and the hierarchical schema. 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. [0029] System Architecture [0030] FIG. 1 shows an exemplary implementation of various devices and an application that can be used to facilitate the creation of electronic forms from a list of components. [0031] FIG. 1 shows an exemplary system 100, which includes a screen 102, user-input devices 104, and a computer 106. [0032] 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, and a mouse 118. The other input devices 116 can include a touch screen, a voice-activated input device, a track ball, and any other device that allows the system 100 to receive input from a designer. The computer 106 includes a processing unit 120 and random access memory and/or read-only memory 122 including applications, such as an operating system 124 and a form and a design application 126, which includes a user interface 128. The computer 106 communicates with a designer through the screen 102 and the user-input devices 104. [0033] The screen 102 includes three displays or screen areas: a hierarchical schema display area 108; a component display area 110; and a form-design area 112. With these areas, a designer can see a representation of and select a component from a list of components. He can also see a representation of the component in an electronic form and schema parts corresponding to the component in a representation of the hierarchical schema. [0034] FIG. 2 shows an exemplary design screen 200, including an example of the form-design area 112 and the hierarchical schema display area 108 (entitled “Data Source”). Partially within the form-design area 112 is a design view of an electronic form 202. The electronic form 202 is a design view because it is in the process of being constructed and so can include information for the designer not intended for viewing by a data entry user. This electronic form 202 is being built from components chosen by a designer. The components chosen create the data-entry fields shown in the electronic form 202. These data-entry fields correspond to parts of a hierarchical schema, the parts being shown through the icons displayed in the hierarchical schema display area 108. The icons displayed are a representation of part of a file of hierarchical schema arranged into a tree structure. [0035] FIG. 3 shows an example of components from which a designer can choose, which are displayed here at the component display area 110. These various components include a text box 302, a rich text box 304, a drop-down list box 306, a list box 308, a date picker 310, a check box 312, an option button 314, a section 316, an optional section 318, a repeating section 320, a repeating table 322, a bulleted list 324, a numbered list 326 a plain list 328, a button 330, and hyperlink 332. Other components can be included as well. As described in further detail below, each of these components represents a data-entry field that can be added to an electronic form. [0036] With the listed components and other components the system 100 enables a designer to build a hierarchical schema and an electronic form with many different types of components, allowing for many different possible types of data-entry fields, such as the electronic form 202 in the form-design area 112 of FIG. 2. The process used to build an electronic form and hierarchical schema from components will be set forth in greater detail below. [0037] 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. 13. Other examples include portable, handheld, or wireless devices. [0038] Techniques for Building Forms and Hierarchical Schemas [0000] Overview [0039] A system, such as the system 100 of FIG. 1, displays components to a designer. The designer can choose from the components to graphically and easily build an electronic form and a corresponding hierarchical schema. The system 100 can also incrementally build an electronic form and hierarchical schema with each new component the designer adds, which allows the designer to see the electronic form and/or hierarchical schema grow with each new component chosen. The designer may also change components existing in the electronic form, the change to each being incrementally reflected by the system 100. [0040] FIG. 4 shows a process 400 for generating an electronic form and a corresponding hierarchical schema. The process 400 is illustrated as a series of blocks representing individual operations or acts performed by the system 100. The process 400 may be implemented in any suitable hardware, software, firmware, or combination thereof. In the case of software and firmware, the process 400 represents a set of operations implemented as computer-executable instructions stored in the memory 122 and executable by the processing unit 120. [0000] Displaying Components and Form-Design Area [0041] At block 402, the user interface 128 displays components and a form-design area. It does so to enable a designer to graphically design an electronic form. [0042] FIG. 5 shows a design screen 500 created by the user interface 128, having an example of the component display area 110 and a blank example of the form-design area 112. The form-design area 112 is displayed to make it easy for a designer without typical programming skills to create an electronic form and corresponding hierarchical schema. [0043] To make it easy, the user interface 128 can provide an editing experience to a designer similar to that commonly provided in word-processing systems. The user interface 128 can, for instance, work like a word-processing system by providing similar font controls and options. In FIG. 5, for example, the user interface 128 displays the form-design area 112 looking like a page from a word-processing application, here a blank, white page. It can also display commonly used icons that represent operations that a designer can choose to perform, such as the font being used (in FIG. 5, Verdana, size 10), bold/underline/italic options, and the like. These word-processing icons can be displayed in many different ways, including as shown in a word-processing icon display 502 of FIG. 5. [0044] Also, as stated elsewhere herein, changes made by the designer to the form-design area 112 can be reflected in the form-design area 112 instantaneously (from the perspective of the designer), further making the design process similar to a typical word-processing experience. By so doing, the user interface 128 makes designing an electronic form simpler and more intuitive for a person skilled in word-processing. [0045] The components are displayed by the user interface 128 in the component display area 110 to make it easy for a designer without extensive knowledge of components to be able to understand what each of them can represent in an electronic form. To show what each component represents, the user interface 128 displays icons and/or text to inform the designer, such as with the icons and text set forth in the component display area 1 10 set forth in FIGS. 3 and 5. In FIG. 3, for example, the text box 302 includes an icon (i.e., a symbol) and text describing what a text box component represents. This icon shows a designer that, should he choose to include a text box component in his electronic form, he will have a data-entry field in which a user of the electronic form will be permitted to input text. Likewise, the text describing the text box 302 (“Text Box”) is also descriptive. [0046] With the component display area 110 and the form-design area 112 displayed, the designer can begin to build an electronic form and corresponding hierarchical schema. He can continue to build the electronic form and hierarchical schema by adding components, but can also alter the electronic form and hierarchical schema by altering existing components. This process of building and altering is shown as a design sub-process 403, which includes blocks 404 to 412. The sub-process 403 includes blocks used to describe the action and interaction of the designer and the system 100. When the designer has finished with the electronic form and hierarchical schema, the design application 126 produces the resulting electronic form and hierarchical schema (block 414). The process 403 and the block 414 will be described in greater detail below. [0047] When the component display area 110 and the form-design area 112 are presented, the designer can pick a component from the list of components in the component display area 110 for insertion into the form-design area 112 (block 404). The designer can pick from components in various ways, including through the mouse 118, the other devices 116 (such as a touch screen, track ball, voice-activation, and the like), and through the keyboard 114, which are shown in FIG. 1. To grant flexibility to the designer, the system 100 enables the designer to move the component in the form-design area 112 to where she desires. [0048] A designer can pick a component, for example, by dragging and dropping (from the component display area 110) a component's icon onto a form-design area 112 shown in FIG. 5. The designer can pick a component to drag and drop with various devices, such as with the mouse 118 or commands entered through the keyboard 114. In FIG. 5, the designer clicks on the icon and text for the text box 302 to select it. [0049] How an icon for a component looks may not exactly indicate how it will look in an electronic form, as icons are too small to be exact. Rather, icons are designed to indicate the look and/or function of the data-entry fields that choosing the component will create. [0050] FIG. 6 shows an exemplary screen display 600 showing what the design application 126 creates after a designer selects the text box 302 in FIG. 5 (also shown in FIG. 6). In this example, the system 100 creates a text box data-entry field 602, which looks like a gray box for entry of text and is labeled “String 1:”, in response to the designer's selection. The design application 126 enables the designer to continue building his electronic form by selecting components, thereby creating data-entry fields. [0000] Building an Electronic Form and Hierarchical Schema [0051] Once the system 100 receives a selection of a component and the placement for the component, the system 100 can identify which component was selected, identify the placement for that component on the form-design area 112, build a hierarchical schema and electronic form based on the component chosen and its location, display the electronic form and/or the hierarchical schema, and, when the designer is finished, produce the resulting electronic form and hierarchical schema. These tasks are set forth in blocks 406, 408, 410, and 414 of FIG. 4, which will be described below. [0052] In block 406, the design application 126 identifies which component was selected. The system 100 can access and/or contain many components, either from local or remote sources. Some of these components are set forth (via icons and text) in the component display area 110 shown in FIGS. 3, 5, 6, and 7. [0053] Also in the block 406, the design application 126 identifies where a component is placed in the form-design area 112. The placement of the component can alter the structure of a corresponding hierarchical schema. How the placement of a component can alter the hierarchical schema's structure will be set forth in greater detail below. [0054] If, for example, a designer chooses the text box 302 from the component display area 110 of FIG. 5, and places the text box 302 in the upper left corner of the form-design area 112, the design application 126 will identify the component and its placement. In this example, the design application 126 will identify that the component chosen was the text box 302 and the placement was a particular spot in the upper left corner of the form-design area 112. With this information, the system 100 proceeds to build the electronic form and hierarchical schema, which will be described in part using FIGS. 5 and 6. [0055] In block 408, the design application 126 changes an electronic form and corresponding hierarchical schema based on a component selected; When a component is added, as has been described in part above, the design application 126 changes the hierarchical schema and electronic form by building in the added component. When an existing component is altered (discussed in greater detail below), the design application 126 changes the electronic form and hierarchical schema to reflect that alteration. [0056] The structure of each component placed into the form-design area 112 is reflected in a corresponding hierarchical schema. The structure or code added to the hierarchical schema for each component selected is called a schema part. Each schema part governs the information added (such as by a data-entry user of the electronic form built by the design application 126 ) into each data-entry field in an electronic form that corresponds to the same component for which the schema part corresponds. A check box component's schema part, for instance, allows only the following values: true, false, 0, or 1 (by default). [0057] Thus, a hierarchical schema governs how information is handled that is input into an electronic form for which it corresponds. Because a hierarchical schema includes the structure of each component chosen, the structure of each chosen component affects the structure of the hierarchical schema. For example, the following components, when added to an electronic form, will add a schema part (when using an XML Schema) having the following code to a hierarchical schema corresponding to the electronic form: Component name Schema Part's Code Text Box <element name=”field#” type=”string”/> Rich Text <element name=”field#”> Box <complexType mixed=”true”> <sequence> <any minOccurs=”0” maxOccurs=”unbounded” namespace=”http://www.w3.org/1999/xhtml” processContents=”lax” /> </sequence> </complexType> </element> Check Box <element name=”field#” type=”boolean”/> List Box <element name=”field#” type=”string”/> Drop-Down <element name=”field#” type=”string”/> List Box Option <element name=”field#” type=”string”/> Button Date <element name=”field#” type=”date”/> Picker Picture <element name=”fieid#” type=”anyURI”/> (linked) Picture <element name=”field#” (inline) type=”base64Binary”/> List (plain, <element name=”group#”> numbered, or <complexType> bulleted) <sequence> <element name=”field#” type=”string” maxOccurs=”unbounded”/> </sequence> </complexType> </element> Section, <element name=”group#”> and Optional <complexType> Section <!-- EMPTY CONTAINER --> </complexType> </element> Repeating <element name=”group#”> Section <complexType> <sequence> <element name=”group#” maxOccurs=”unbounded”> <complexType> <!-- EMPTY CONTAINER --> </complexType> </element> </sequence> </complexType> </element> Repeating <element name=”group#”> Table <complexType> <element name=”group#” maxOccurs=”unbounded”> <complexType> <sequence> <element name=”field#” type=”string”/> <element name=”field#” type=”string”/> <element name=”field#” type=”string”/> <!-- Etc. for each column --> </sequence> </complexType> </element> </complexType> </element> Note: The number of columns is used to determine the number of “field#”s added. Button, None Expression Box, Hyperlink [0058] Note that all of the above “element” elements also have the attribute value “minOccurs=0”, but it has been omitted for clarity. Also note that the pound sign (#) represents a number to make each element name unique. For example: field1, fleld2, and field3. [0059] For the above example, when a component is added to the form-design screen 112, the system 100 will generate a hierarchical schema with a schema part including the above code. [0060] Likewise, each component built into an electronic form governs how the component is displayed and information within it handled. Each component built into an electronic form, for instance, governs the look, display, orientation, and size of data-entry field(s), as well as how and where information entered into these data-entry field(s) is mapped, including to a document governed by a corresponding hierarchical schema. [0061] The set of components available for building the electronic form can be extensible. A developer, by specifying the criteria above (for instance, the look, display, orientation, whether it allows nested components, and so forth) can create a new component that a designer can use to build an electronic form. A developer-created component, like the pre-existing components, can have an appropriate associated schema part from which to build a corresponding hierarchical schema. [0062] Once the system 100 changes the hierarchical schema and electronic form (block 408), it proceeds to block 410 to display the electronic form and hierarchical schema, or to block 414, to complete the process and produce the electronic form and hierarchical schema. Block 410 will be discussed first below, followed later by a discussion of block 414. [0063] In the block 410, the user interface 128 displays the electronic form and/or hierarchical schema. Hierarchical schemas can be represented in various ways, including by visually showing the hierarchical structure of the hierarchical schema. One example of this is the indentations of the hierarchical schema set forth in the hierarchical schema display area 108 of FIG. 2. [0064] Electronic forms can be displayed (to a designer or user) through various techniques, including by transforming the hierarchical schema or its data file into an electronic form. In one implementation, the system 100 creates a display for an electronic form by applying an application written in a transformation language onto a hierarchical schema or its data file written in a machine language. This creates a rendering language document written in a rendering language which can be used to create the display. By way of example, the transformation language can include CSS or XSLT, the machine language XML, and the rendering language HTML or XITML. [0065] Electronic forms can be represented in various ways. The user interface 128 can display a design view of an electronic form to a designer to make it easy for a designer to understand the structure of the electronic form, or can show the electronic form without additional information. A design view of an electronic form can mimic the electronic form that will be seen by a user, such as set forth in form-design area 112 of FIG. 2. The design view can show components built into an electronic form with additional information showing details about the data-entry field or fields corresponding to the components to aid a designer in understanding the components in the electronic form and altering the electronic form. [0066] The user interface 128 can also display the electronic form and hierarchical schema in order for the designer to assess the electronic form and hierarchical schema after each change made by the designer. When the designer can quickly see the effect of his changes, the designer can more easily build an electronic form and hierarchical schema matching the designer's intended results. Once the electronic form is displayed, such as in the form-design area 112, and the hierarchical schema is displayed (if desired) in the hierarchical schema display area 108, the designer can continue to make changes or end the process. Ending the process will be discussed as part of the block 414, described below. [0067] Whether the user interface 128 displays the electronic form or the electronic form and hierarchical schema, the display should show changes made by a designer, such as adding a data-entry field and schema part by selecting and/or inserting a new component. [0068] Continuing the example above (where a designer chooses the text box 302 from the component display area 110 of FIG. 5 and places the text box 302 in the upper left corner of the form-design area 112 ), the design application 126 will build an electronic form and hierarchical schema based on the identity and placement of the component. Using the exemplary code set forth above, the design application 126 can build a hierarchical schema with a schema part including the code: <element name=“string1” type=“string”/>. This code can be displayed on the screen 102, but because most designers are more comfortable with a graphical display, the schema part can be displayed as an icon and text, such as with a schema part string1 604 of FIG. 6. [0069] Also in this example, the design application 126 builds an electronic form with a text box component and displays it as set forth in FIG. 6, with a text box data-entry field 602 in the form-design area 112. [0070] One of the advantages of the design application 126, and the method it employs, is that the electronic form and hierarchical schema can be built incrementally. That is to say, with each component chosen, or in some implementations with each other action taken that will affect the construction of the electronic form and hierarchical schema, the electronic form and hierarchical schema are altered. This incrementalism allows a designer to quickly see how the electronic form and hierarchical schema are changing with each change made by the designer. The designer does not have to work on either a form or a schema and then save the form or schema to see how the corresponding schema or form looks or performs. Instead, as the designer makes a change, it is reflected in the electronic form and hierarchical schema. This makes designing an electronic form and hierarchical schema easy and intuitive. [0071] In one implementation, the design application 126 can reflect each change made by a designer to both the electronic form and hierarchical schema so quickly that the designer sees it in real time, regardless of whether the change was made to the electronic form by altering the form-design area 112 or to the hierarchical schema by altering the hierarchical schema display area 110. By so doing, the designer can more easily design electronic forms and hierarchical schemas. [0072] Once a component has been added (or altered, discussed below), the design application 126 displays the form and hierarchical schema as set forth above. With the new change shown, the design application 126 continues to enable the designer to add components to the electronic form, returning to block 404, or alter an existing component, block 412. [0073] If the designer chooses to add another component, the design application 126 enables him to do so in a manner similar to picking the first component as described above. The electronic form 202 of FIG. 2 is one such example of an electronic form built from many components. [0074] FIG. 7 shows an exemplary screen display 700 showing the continued building of an electronic form. Here, the designer chose another component (the check box 312 of FIG. 6) to add to the electronic form and hierarchical schema shown in FIG. 6. In response to the designer's choice, the design application 126 added a Boolean box 702. As shown in the screen display 700, the Boolean box 702 looks like a small check box (which can be filled with a check mark or left empty by a user) and is labeled “Boolean 1”. Also in response to the designer's choice, the design application 126 altered the hierarchical schema to include a Boolean schema part 704 (labeled “boolean1”) corresponding to the Boolean box 702. [0075] FIG. 8 shows an exemplary design screen 800 showing the continued building of an electronic form. The design screen 800 shows the electronic form and hierarchical schema from FIGS. 6 and 7, and the results of the designer continuing to choose components. Through this process of adding components to the form-design area 112, a designer can build everything from a simple electronic form, such as shown in FIG. 6, to a moderately complex form, such as shown FIG. 8, to a large, complex form, such as shown in FIG. 2. As the design application 126 builds an electronic form, it builds a corresponding hierarchical schema. FIG. 2 shows an example of a hierarchical schema, displayed in hierarchical schema display area 108 of FIG. 2, corresponding to an electronic form, in this case the electronic form 202 of FIG. 2. [0076] A designer can simply make a change, like adding a component, to the electronic form or hierarchical schema and see the change applied to both the electronic form and hierarchical schema. In this sense, the electronic form and hierarchical schema are actively linked. This active linkage makes designing and changing electronic forms and hierarchical schemas quicker, easier, and more intuitive. [0077] The design application 126 links the electronic form and the hierarchical schema by mapping each component within an electronic form to each schema part in the corresponding hierarchical schema. In one implementation, the design application 126 maps them with XPath pointers. [0078] In the block 412, the design application 126 enables a designer to select and alter existing components included in an electronic form and hierarchical schema. The design application 126 allows the designer to intuitively and easily alter the electronic form and hierarchical schema, such as by including editing tools familiar to designers that know word-processing techniques. A designer can change a component stylistically (such as the font, color, size, and the like) and structurally (such as by changing a text box to a Boolean box, and whether or to which other components the component governs or is subordinate). A designer can make these changes also by altering how a component (such as one displayed as a data-entry field) is represented on an electronic form. For example, a designer can click on a component on the form-design screen 112, change the style, move it, delete it, and the like. As the designer makes changes, the design application 126 alters the hierarchical schema to continue to correspond to the altering electronic form. [0079] FIG. 8 shows the exemplary design screen 800, which provides a design view of an electronic form and its corresponding hierarchical schema, shown in the design area 112 and the hierarchical schema display area 108, respectively. To enable the designer to make changes to a component, the design application 126 (through the user interface 128) enables the designer to click on components displayed in the design view of the electronic form. One such component, a text box data-entry field 802 (labeled “String 5”), is shown as an example. Once the designer selects a component, in this example the text box data-entry field 802, the design application 126 provides the designer with multiple options to change the data-entry field. As seen in a design screen 900 (described below), the design application 126 provides options in a way comfortable to a designer familiar with common word-processing techniques and icons. If the designer clicked on the text box data-entry field 802 of FIG. 8, the design application 126 can provide multiple pop-up menus of options for the designer. [0080] FIG. 9 sets forth the exemplary design screen 900 including multiple ways in which the design application 126 provides options for a designer. These include a component context menu 902 and a structure submenu 904. In this example, the design application 126 enables the designer to change the electronic form and hierarchical schema by changing a representation of a component in the form-design area 112 (such as a data-entry field or accompanying graphics and text). Also, the design application 126 enables the designer to cut the component and move it (through selection and deleting or dragging the component), and change its font, borders, shading, and other style changes (through the component context menu 902), as well as change its structure (through the structure submenu 904). In this example, the designer changes the component by changing the structure of a data-entry field corresponding to the component (the text box data-entry field 802) into a date picker data-entry field by selecting a date picker component 906. [0081] Also in the block 412, the design application 126 enables a designer to alter a schema part directly through selecting it from a hierarchical schema. It can do so by allowing the designer to change an electronic form indirectly by making a change to the hierarchical schema. The design application 126 enables this because, while many designers may prefer to build an electronic form and hierarchical schema by changing an electronic form through a form-design screen, such as the design screen 112, some designers will be familiar and comfortable enough with hierarchical schemas to change them through a representative display of the hierarchical schema, such as the hierarchical schema display area 108. In this way, the designer can alter or add schema parts in the hierarchical schema, which may be associated with components reflected in the electronic form. Once the designer has made a change, the design application 126 changes the electronic form and hierarchical schema to reflect the alteration (block 408). [0082] FIG. 10 shows an example of the hierarchical schema display area 108, and how it can be used by a designer to alter a hierarchical schema. In this example, a designer selected a schema part entitled “element” (an element 1002). Once chosen, the design application 126 prompts the designer, asking for information, such as through a change inquiry window 1004. Using the window 1004, the design application 126 enables the designer to make various changes to the element 1002. He can change, for instance, the data type and default value allowed for the element 1002 and its corresponding data-entry field in an electronic form. [0083] Also as part of this example, the design application 126 presents the designer with the current name, type, and data type of a selected schema part. The designer can then make changes by altering these current parameters of the selected schema part, such as set forth in the change inquiry window 1004 by changing the name to “myNewField” from “element” and the data type to “Text (string)” from “Whole Number (integer)”. The design application 126 also enables the designer to make other changes to a schema part, such as whether or not it repeats, has a default value, or can be blank. [0084] Also as part of the block 412, the design application 126 allows a designer to alter components by adding to, deleting from, or otherwise changing schema parts (whether they are schema parts governing or subordinate to other schema parts or otherwise). [0085] FIG. 10 shows an example of a pop-up window with which the design application 126 can enable a designer to alter schema parts. With an alter window 1006, the designer can add or delete aspects of a schema part, set a default value of the schema part, name the schema part, make it repeating or not, and establish whether or not it is allowed to be blank. In addition to these data parameters, the design application 126 can enable the designer to make other changes to a schema part, such as to how it is validated, its script, and other details. [0086] As part of enabling the designer to makes these changes, the design application 126 makes appropriate changes to the structure of the hierarchical schema and electronic form. If the designer deletes a component, for instance, the design application 126 may delete the code corresponding to the component from the hierarchical schema and the electronic form. [0087] Assume, for example, that the designer chose to delete a repeating section 804 from the electronic form shown in the design screen 800 of FIG. 8. With this selection made, the design application 126 deletes a “repeating_item” schema part 816 and its subordinate string hierarchical schema parts 818, 820, and 822 (entitled “string 2”, “string 3”, and “string 4”) from the hierarchical schema. To do so the design application 126 deletes the following code from the hierarchical schema: <element name=“repeating_item”> <complexType> <sequence> <element name=“string2” type=“string”/> <element name=“string3” type=“string”/> <element name=“string4” type=“string”/> </complexType> </element> </sequence> </complexType> </element> [0088] Subsequent to this deletion, the design application 126 deletes the component from the electronic form. In this example, the design application 126 deletes the repeating section 804 and its subordinate repeating string data-entry fields: a repeating string data-entry field 810 (labeled “String 2:”); a repeating string data-entry field 812 (labeled “String 3:”); and a repeating string data-entry field 814 (labeled “String 4:”). This deletion can be shown immediately in the design view of the electronic form in the design screen 800 by the design application 126. By immediately showing the deletion in the electronic form and the hierarchical schema, the design application 126 and the user interface 128 enable the designer to more easily and quickly customize the form to fit his or her preferences. [0089] According to block 414, when finished, the end product is an electronic form and a corresponding hierarchical schema. The electronic form created can be a transformation-language document, and can be written in CSS, XSLT, or otherwise. Hierarchical schemas corresponding to these electronic forms can also be written in various languages, which will be described in greater detail below. [0090] One example of an electronic form created by the design application 126 is the purchase order electronic form 202 viewed in the form-design area 112 of FIG. 2. This electronic form 202, once finished and presented to an end user, can be used by that user to key in information into data-entry fields. After entry of information, the information can be stored in a markup-language document, such as one written in XML. The information stored can conform to a hierarchical schema corresponding to the electronic form, thereby allowing easy use and/or transfer of information stored in the markup-language document. The hierarchical schema to which the markup-language document conforms can be written in various languages, including schemas written to govern markup languages (such as XML). Schemas governing XML documents are commonly called XML Schemas, DTD (Document Type Definition) schemas, and XDR (XML-Data Reduced) schemas. [0091] Thus, a designer not knowledgeable about transformation-language documents (like an electronic form written in CSS), hierarchical schemas, or programming can, easily and with no specialized skills, create an electronic form and corresponding hierarchical schema. [0092] The design application 126 can even create electronic forms that are XSLT transformation-language documents, which is especially complex, and corresponding hierarchical schemas that are XML schemas. In this case, a designer having little knowledge about the XSLT language can create, using XSLT transformation-language components as an example, an electronic form that is an XSLT transformation-language document and a corresponding hierarchical schema which is a schema capable of governing XML documents, such as XML Schema. [0093] The hierarchical schema can be written in many languages, follow various standards, or be a set of tables in a database. Hierarchical schemas can do more than a linear or flat list; they can include, for example, a schema part that governs or contains another schema part that corresponds to a component of a different type than that of the governing schema part. Thus, these types of schemas can allow for a governing schema part to correspond to a text box component, for instance, and at the same time govern a Boolean component. [0094] Hierarchical schemas can govern many different documents. Because of this, an electronic form relating to a hierarchical schema can have thousands of different users keying information into thousands of different documents, all of which can be governed by the one hierarchical schema. [0000] Building a Hierarchical Schema [0095] The system 100 enables a designer to incrementally build an electronic form and corresponding hierarchical schema. [0096] Because the concept of structuring data hierarchically can be difficult for designers to grasp easily and readily, but many users readily understand structuring information spatially, the design application 126 can enable users to incrementally create spatially structured electronic forms. These electronic forms are incrementally converted into hierarchically structured schemas, thus making it easier for a designer to create electronic forms that take advantage of hierarchically structured data. [0097] The hierarchical aspect of the hierarchical schema allows it to correspond to many different types of structures and components in an electronic form. A designer can, for instance, build an electronic form with various structures, like repeating tables and lists. These repeating tables and lists are well suited to a hierarchical schema because of its hierarchical aspect. [0098] A hierarchical schema is structured; in other words, some schema parts may be governed or affected by other schema parts. With the exception of every schema part's subordination to the root schema part, which governs all other schema parts, each schema part may or may not be subordinate to another schema part. In the hierarchical schema display area 108 of FIG. 2 for instance, the root schema part is the schema part labeled “PurchaseOrder”. The next six schema parts, “referenceNumber” to “chargeTo”, are subordinate to (or governed by) only the root schema part, “PurchaseOrder”. Conversely, the six schema parts labeled “prefix” to “singleName” are also governed by the schema part labeled “deliveryTo”. [0099] The design application 126 can build a hierarchical schema hierarchically. It can do so by receiving instructions from a designer as to how to build the hierarchical schema, including how to arrange each schema part as subordinate to or governing another. A designer can, for instance, instruct the design application 126 to make a particular component subordinate to or govern other components. A designer can also instruct the design application 126 to make a particular schema part subordinate to or govern other schema parts. In either case; the design application 126 can build a hierarchical schema and electronic form based on how components or schema parts govern or are subordinate to other components or schema parts. By enabling a designer to give the design application 126 instructions in various ways, including typed-in instructions, clicking on icons, and dragging and dropping icons for schema parts or components, the designer's experience can be made easy and intuitive. [0100] Some of the ways the design application 126 can receive instructions as to how to build an electronic form and hierarchical schema hierarchically can include ways in which a designer will not need to know how or even that a hierarchical schema is being built. Many designers may not understand hierarchical schemas, or may just want to build a hierarchical schema (and, typically, an electronic form) in an easy, graphical, and intuitive manner. [0101] FIG. 11 shows a process 1100 by which the design application 126 enables a designer to give instructions graphically and, using the instructions, determine a governance or subordination of schema parts in a hierarchical schema. As set forth in block 1102, the design application 126 enables a designer to give instructions graphically. In this way, a designer can give instructions (like placing a component in a particular location of the form-design area 112) to the design application 126 from which it can infer how the designer wishes a hierarchical schema to be built. [0102] The design application 126 enables a designer to input his or her preference for a component to be subordinate and/or governing, such as by placing a component's icon or a mouse-pointer beneath, below, within, or otherwise relative to another, existing component (whether when first placed or later moved). To aid the designer to give the designer's intended input to the design application 126, it enables a designer to see how each component is governed by or subordinate to other components. The design application 126, in one implementation, displays subordination areas to graphically indicate which components govern or are subordinate to others. Some of these components inherently contain other components, and so are shown with subordination areas containing data-entry fields in the display area 112; some are altered by the designer to contain other components. [0103] In FIG. 12, for example, an exemplary design screen 1200 shows how the design application 126 can enable a designer to place components subordinate to and/or governing other components by placing them in particular places in the design screen 1200. FIG. 12 shows subordination areas marked by boxes, into which a designer can place a component to be subordinate to another component. If the designer places a component outside all subordination areas, the component will be governed by only the root schema part. These subordination areas show components as subordinate or governing in the electronic form and hierarchical schema. [0104] In this example, a product schema part 1202 is shown to be subordinate (governed by) the “productSection” schema part 1204 by the product schema part's 1202 corresponding product component 1206 being within a productSection box 1208 marked with a tab entitled “Section”. Also in this example, a company schema part 1210 is shown to be governed by a companySection schema part 1212 and the productSection schema part 1204 by the company schema part's 1210 company component 1214 being within a companySection box 1216 marked with a tab entitled “Section”. [0105] Thus, the company schema part 1210 is governed by two schema parts (1212 and 1204) as well as the root schema part 1218 entitled “form”. Continuing this example, a website component 1220 and its schema part 1222 are shown to be governed by the companySection schema part 1212 (through the component being within the companySection box 1216), the productSection schema part 1204, and the root schema part 1218. Likewise, a street component 1224 and its schema part 1226, a city component 1228 and its schema part 1230, and a state component 1232 and its schema part 1234 are shown to be governed by an addressSection schema part 1236, the companySection schema part 1212, the productSection schema part 1204, and the root schema part 1218. [0106] Thus, the design application 126 can show a designer which components govern or are subordinate to other components. Similarly, the design application 126 can infer, in some implementations, which components govern or are subordinate to other components based upon where a component is placed by a designer relative to another component, such as by a designer placing a component within a subordination area, e.g., the product section box 1208. [0107] At block 1104, the design application 126 determines to which other component(s) a placed or moved component is graphically subordinate. It can determine, for example, that the company component 1214 and the website component 1220 are subordinate to the companySection schema part 1212 through being within the companySection box 1216. With this determination, the design application 126 builds the hierarchical schema to represent this subordination (block 1106). The design application 126 can determine this incrementally, such as when a component is added or moved into a subordination area. [0108] The design application 126 adds or rearranges schema parts to represent each component's relationship to the other components. Continuing the above example, for the relationship between the components in the form-design area 112 of FIG. 12, the design application 126 builds a hierarchical schema that corresponds to the form-design area 112, set forth in the hierarchical schema display area 108, also of FIG. 12. The hierarchical schema display area 108, for example, includes the root schema part 1218, though no corresponding component/box is shown in the form-design area 112. [0109] The hierarchical schema displayed in hierarchical schema display area 108 includes schema parts corresponding to components and reflecting the relationships between the components in the form-design area 112. It shows here that the product schema part 1202 and the website schema part 1222 correspond to the product component 1206 and the website component 1220. The hierarchical schema display area 108 shows that these components and their corresponding schema parts ( 1202 and 1222) are subordinate to schema parts 1204 and 1218. [0110] The design application 126 builds this hierarchical structure into the hierarchical schema by subordinating schema parts to other schema parts. Lastly, the design application 126 can build the hierarchical schema to show that schema parts are subordinate to other parts by being placed to the right of those schema parts. [0111] The example set forth in FIG. 12 shows various types of components and schema parts, but is not intended to limit the abilities of the design application 126, the user interface 128, or the system 100; other types of components and ways to present them can be used. [0112] A Computer System [0113] FIG. 13 shows an exemplary computer system that can be used to implement the processes described herein. Computer 1342 includes one or more processors or processing units 1344, a system memory 1346, and a bus 1348 that couples various system components including the system memory 1346 to processors 1344. The bus 1348 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 1346 includes read only memory (ROM) 1350 and random access memory (RAM) 1352. A basic input/output system (BIOS) 1354, containing the basic routines that help to transfer information between elements within computer 1342, such as during start-up, is stored in ROM 1350. [0114] Computer 1342 further includes a hard disk drive 1356 for reading from and writing to a hard disk (not shown), a magnetic disk drive 1358 for reading from and writing to a removable magnetic disk 1360, and an optical disk drive 1362 for reading from or writing to a removable optical disk 1364 such as a CD ROM or other optical media. The hard disk drive 1356, magnetic disk drive 1358, and optical disk drive 1362 are connected to the bus 1348 by an SCSI interface 1366 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 1342. Although the exemplary environment described herein employs a hard disk, a removable magnetic disk 1360 and a removable optical disk 1364, 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. [0115] A number of program modules may be stored on the hard disk 1356, magnetic disk 1360, optical disk 1364, ROM 1350, or RAM 1352, including an operating system 1370, one or more application programs 1372 (such as a design application), other program modules 1374, and program data 1376. A user may enter commands and information into computer 1342 through input devices such as a keyboard 1378 and a pointing device 1380. 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 1344 through an interface 1382 that is coupled to the bus 1348. A monitor 1384 or other type of display device is also connected to the bus 1348 via an interface, such as a video adapter 1386. In addition to the monitor, personal computers typically include other peripheral output devices (not shown) such as speakers and printers. [0116] Computer 1342 commonly operates in a networked environment using logical connections to one or more remote computers, such as a remote computer 1388. The remote computer 1388 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 1342. The logical connections depicted in FIG. 13 include a local area network (LAN) 1390 and a wide area network (WAN) 1392. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets, and the Internet. [0117] When used in a LAN networking environment, computer 1342 is connected to the local network through a network interface or adapter 1394. When used in a WAN networking environment, computer 1342 typically includes a modem 1396 or other means for establishing communications over the wide area network 1392, such as the Internet. The modem 1396, which may be internal or external, is connected to the bus 1348 via a serial port interface 1368. In a networked environment, program modules depicted relative to the personal computer 1342, 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. [0118] Generally, the data processors of computer 1342 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 system 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, in conjunction with a microprocessor or other data processor. The system described can also include the computer itself when programmed according to the methods and techniques described herein. [0119] 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 times in different storage components of the computer, and are executed by the data processor(s) of the computer. CONCLUSION [0120] The above-described system and method enables a designer to easily and incrementally create electronic forms and corresponding hierarchical schemas, even if the designer has only basic skills. The above-described system and method also allows a designer to create, with the click of a mouse, electronic forms written in XSLT and hierarchical schemas written in XML Schema. In addition, the above system and method enables a designer to view changes he is making in real-time to an electronic form and hierarchical schema. Although the system and method has been described in language specific to structural features and/or methodological acts, it is to be understood that the system and method 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 system and method. Patent CitationsCited PatentFiling datePublication dateApplicantTitleUS4498147 *Nov 18, 1982Feb 5, 1985International Business Machines CorporationMethodology for transforming a first editable document form prepared with a batch text processing system to a second editable document form usable by an interactive or batch text processing systemUS4641274 *Aug 19, 1985Feb 3, 1987International Business Machines CorporationMethod for communicating changes made to text form a text processor to a remote hostUS5379419 *Dec 7, 1990Jan 3, 1995Digital Equipment CorporationMethods and apparatus for accesssing non-relational data files using relational queriesUS5410646 *Feb 23, 1994Apr 25, 1995Park City Group, Inc.System and method for creating, processing, and storing forms electronicallyUS5497489 *Jun 7, 1995Mar 5, 1996Menne; David M.Data storage and retrieval systems having labelling for dataUS5600789 *Nov 19, 1992Feb 4, 1997Segue Software, Inc.Automated GUI interface testingUS5625783 *Dec 13, 1994Apr 29, 1997Microsoft CorporationAutomated system and method for dynamic menu construction in a graphical user interfaceUS5745712 *Dec 28, 1995Apr 28, 1998Borland International, Inc.Graphical programming system and methods for assisting a user with creating screen objects on a screen deviceUS5859973 *Aug 21, 1996Jan 12, 1999International Business Machines CorporationMethods, system and computer program products for delayed message generation and encoding in an intermittently connected data communication systemUS5862379 *Mar 7, 1995Jan 19, 1999International Business Machines CorporationVisual programming tool for developing software applicationsUS6035297 *Dec 6, 1996Mar 7, 2000International Business Machines MachineData management system for concurrent engineeringUS6052531 *Mar 25, 1998Apr 18, 2000Symantec CorporationMulti-tiered incremental software updatingUS6182094 *Jun 24, 1998Jan 30, 2001Samsung Electronics Co., Ltd.Programming tool for home networks with an HTML page for a plurality of home devicesUS6182095 *Apr 30, 1998Jan 30, 2001General Electric Capital CorporationDocument generatorUS6188401 *Mar 25, 1998Feb 13, 2001Microsoft CorporationScript-based user interface implementation defining components using a text markup languageUS6191797 *May 21, 1997Feb 20, 2001Canon Kabushiki KaishaExpression tree optimization for processing obscured graphical objectsUS6192367 *Nov 23, 1998Feb 20, 2001International Business Machines CorporationData file editor presenting semi-formatted viewUS6345278 *Jun 3, 1999Feb 5, 2002Collegenet, Inc.Universal forms engineUS6353851 *Dec 28, 1998Mar 5, 2002Lucent Technologies Inc.Method and apparatus for sharing asymmetric information and services in simultaneously viewed documents on a communication systemUS6505200 *Jul 6, 2000Jan 7, 2003International Business Machines CorporationApplication-independent data synchronization techniqueUS6675202 *May 30, 2000Jan 6, 2004Cary D. PerttunenMethods, articles and apparatus for providing a browsing sessionUS6681370 *May 19, 1999Jan 20, 2004Microsoft CorporationHTML/XML tree synchronizationUS6701486 *Jul 29, 1999Mar 2, 2004Grischa CorporationMethod, apparatus, and computer program product for automatic page suppression in formsUS6704906 *Mar 27, 1999Mar 9, 2004Movaris, Inc.Self-directed routable electronic form system and methodUS6847387 *Mar 26, 2001Jan 25, 2005International Business Machines CorporationMenu management mechanism that displays menu items based on multiple heuristic factorsUS6850895 *May 30, 2001Feb 1, 2005Siebel Systems, Inc.Assignment managerUS6874130 *Feb 17, 2000Mar 29, 2005International Business Machines CorporationCopy/move graphical user interface apparatus and methodUS6993714 *Oct 3, 2002Jan 31, 2006Microsoft CorporationGrouping and nesting hierarchical namespacesUS6996776 *May 16, 2000Feb 7, 2006International Business Machines CorporationMethod and system for SGML-to-HTML migration to XML-based systemUS7000179 *Feb 22, 2002Feb 14, 2006Movaris, Inc.Method and apparatus for programmatic learned routing in an electronic form systemUS7002560 *Oct 4, 2002Feb 21, 2006Human Interface Technologies Inc.Method of combining data entry of handwritten symbols with displayed character dataUS7020869 *Nov 26, 2001Mar 28, 2006Corticon Technologies, Inc.Business rules user interface for development of adaptable enterprise applicationsUS7178166 *Sep 19, 2000Feb 13, 2007Internet Security Systems, Inc.Vulnerability assessment and authentication of a computer by a local scannerUS7190376 *Mar 14, 2000Mar 13, 2007Canon Kabushiki KaishaMethod of compiling compositing expressions for optimised renderingUS7191394 *Jun 21, 2000Mar 13, 2007Microsoft CorporationAuthoring arbitrary XML documents using DHTML and XSLTUS7337391 *Mar 12, 2002Feb 26, 2008International Business Machines CorporationMethod and system for stylesheet execution interactive feedbackUS7337392 *Jan 14, 2004Feb 26, 2008Vincent Wen-Jeng LueMethod and apparatus for adapting web contents to different display area dimensionsUS7346610 *Feb 11, 2005Mar 18, 2008Microsoft CorporationMethods and systems of providing information to computer usersUS7346840 *Feb 26, 2001Mar 18, 2008Cisco Technology, Inc.Application server configured for dynamically generating web forms based on extensible markup language documents and retrieved subscriber dataUS7346848 *Jun 21, 2000Mar 18, 2008Microsoft CorporationSingle window navigation methods and systemsUS7350141 *Sep 16, 2004Mar 25, 2008Microsoft CorporationUser interface for integrated spreadsheets and word processing tablesUS20020010743 *Feb 10, 2001Jan 24, 2002Ryan Mark H.Method and system for distributing and collecting spreadsheet informationUS20020010746 *Feb 9, 2001Jan 24, 2002Jilk David J.System, method, apparatus and computer program product for operating a web site by electronic mailUS20020010855 *Mar 5, 2001Jan 24, 2002Eran ReshefSystem for determining web application vulnerabilitiesUS20020013788 *May 18, 2001Jan 31, 2002Pennell Mark E.System and method for automatically learning information used for electronic form-fillingUS20020019941 *Jun 12, 1998Feb 14, 2002Shannon ChanMethod and system for secure running of untrusted contentUS20020026441 *Jun 5, 2001Feb 28, 2002Ali KutaySystem and method for integrating multiple applicationsUS20020032590 *Mar 27, 2001Mar 14, 2002International Business Machines CorporationE-market architecture for supporting multiple roles and reconfigurable business porcessesUS20020032692 *Aug 9, 2001Mar 14, 2002Atsuhito SuzukiWorkflow management method and workflow management system of controlling workflow processUS20020032706 *Apr 19, 2001Mar 14, 2002Jesse PerlaMethod and system for building internet-based applicationsUS20020032768 *Apr 9, 2001Mar 14, 2002Voskuil Erik K.Method and system for configuring remotely located applicationsUS20020035579 *Jan 24, 2001Mar 21, 2002Wang Wayne W.Transform rule generator for web-based markup languagesUS20030004951 *Jan 30, 2001Jan 2, 2003Sandip ChokshiAutomated client-server data validationUS20030020746 *Jan 31, 2002Jan 30, 2003Computer Associates Think, Inc.System and method for dynamically generating a web pageUS20030023641 *Jul 27, 2001Jan 30, 2003Gorman William PhillipWeb page authoring toolUS20030028550 *Jul 30, 2001Feb 6, 2003International Business Machines CorporationMethod, system, and program for maintaining information in database tables and performing operations on data in the database tables.US20030048301 *Mar 23, 2001Mar 13, 2003Menninger Anthony FrankSystem, method and computer program product for editing supplier site information in a supply chain management frameworkUS20030055811 *Sep 20, 2001Mar 20, 2003Ricoh Company, Ltd.Document controlled workflow systems and methodsUS20030055828 *Mar 29, 2002Mar 20, 2003Koch Kevin S.Methods for synchronizing on-line and off-line transcript projectsUS20030061567 *Sep 5, 2001Mar 27, 2003International Business Machines CorporationApparatus and method for protecting entries in a form using access rights informationUS20040002950 *Apr 15, 2003Jan 1, 2004Brennan Sean F.Methods and apparatus for process, factory-floor, environmental, computer aided manufacturing-based or other control system using hierarchically enumerated data setUS20040003031 *Jun 26, 2002Jan 1, 2004International Business Machines CorporationRunning dynamic web pages off-line with a wizardUS20040003353 *May 12, 2003Jan 1, 2004Joey RiveraWorkflow integration system for automatic real time data managementUS20040003389 *Jun 5, 2002Jan 1, 2004Microsoft CorporationMechanism for downloading software components from a remote source for use by a local software applicationUS20040010752 *Jul 9, 2002Jan 15, 2004Lucent Technologies Inc.System and method for filtering XML documents with XPath expressionsUS20040015783 *Jun 20, 2003Jan 22, 2004Canon Kabushiki KaishaMethods for interactively defining transforms and for generating queries by manipulating existing query dataUS20040024842 *Jul 31, 2002Feb 5, 2004Sap AktiengesellschaftValidation framework for validating markup page input on a client computerUS20040030991 *Apr 22, 2003Feb 12, 2004Paul HepworthSystems and methods for facilitating automatic completion of an electronic formUS20040039990 *Mar 28, 2003Feb 26, 2004Xorbix Technologies, Inc.Automated form and data analysis toolUS20040039993 *Aug 27, 2003Feb 26, 2004Panagiotis KougiourisAutomatic formatting and validating of text for a markup language graphical user interfaceUS20040044961 *Sep 23, 2002Mar 4, 2004Leonid PesensonMethod and system for transformation of an extensible markup language documentUS20040044965 *Apr 29, 2003Mar 4, 2004Haruhiko ToyamaStructured document edit apparatus, structured document edit method, and program productUS20040046789 *Aug 14, 2003Mar 11, 2004Angelo InanoriaExtensible user interface (XUI) framework and development environmentUS20040054966 *Sep 16, 2002Mar 18, 2004International Business Machines CorporationReal-time method, system and program product for collecting web form dataUS20040059754 *Jul 11, 2003Mar 25, 2004Lauren BarghoutPerceptual information processing systemUS20050004893 *Jul 2, 2003Jan 6, 2005Sangroniz James M.Workflow management devices and systems, and workflow assignment and management methodsUS20050005248 *Jul 23, 2004Jan 6, 2005Microsoft CorporationTask-sensitive methods and systems for displaying command setsUS20050015732 *Aug 18, 2004Jan 20, 2005Microsoft CorporationMapping tool graphical user interfaceUS20050028073 *Jul 28, 2003Feb 3, 2005Henry Steven G.Method and system for automating workflowsUS20050033728 *Sep 13, 2004Feb 10, 2005Microsoft CorporationMethods, systems, architectures and data structures for delivering software via a networkUS20050038711 *Aug 13, 2003Feb 17, 2005Merwin MarleloMethod for advertising for sale classroom materials and servicesUS20050055627 *Jun 25, 2004Mar 10, 2005Signaturemail.Com, LlcSystem and method for personalizing electronic mail messagesUS20050060324 *Nov 13, 2003Mar 17, 2005Jerry JohnsonSystem and method for creation and maintenance of a rich content or content-centric electronic catalogUS20050060647 *Dec 18, 2003Mar 17, 2005Canon Kabushiki KaishaMethod for presenting hierarchical dataUS20050060721 *Sep 16, 2003Mar 17, 2005International Business Machines CorporationUser-centric policy creation and enforcement to manage visually notified state changes of disparate applicationsUS20050065933 *Sep 22, 2003Mar 24, 2005Thomas GoeringSystem and method for customizing form elements in a form building applicationUS20050065936 *Sep 22, 2003Mar 24, 2005Thomas GoeringSystem and method for reusing form elements in a form building applicationUS20050066287 *Sep 10, 2004Mar 24, 2005Tattrie Scott I.User-friendly data binding, such as drag-and-drop data binding in a workflow applicationUS20050071752 *Sep 24, 2004Mar 31, 2005Marlatt Jane E.Forms management systemUS20060026534 *Sep 23, 2005Feb 2, 2006Microsoft CorporationProviding information to computer usersUS20060059107 *Mar 30, 2001Mar 16, 2006Kevin ElmoreSystem and method for establishing eletronic business systems for supporting communications servuces commerceUS20060059434 *Sep 16, 2004Mar 16, 2006International Business Machines CorporationSystem and method to capture and manage input values for automatic form fillUS20060069605 *Mar 22, 2005Mar 30, 2006Microsoft CorporationWorkflow association in a collaborative applicationUS20070036433 *Aug 15, 2005Feb 15, 2007Microsoft CorporationRecognizing data conforming to a ruleUS20070050719 *Mar 22, 2006Mar 1, 2007Philip LuiSystem and method for dynamic assistance in software applications using behavior and host application modelsUS20070061467 *Sep 15, 2005Mar 15, 2007Microsoft CorporationSessions and session statesUS20070061706 *Sep 14, 2005Mar 15, 2007Microsoft CorporationMapping property hierarchies to schemasUS20070074106 *Nov 8, 2006Mar 29, 2007Microsoft CorporationAuthoring Arbitrary XML Documents Using DHTML and XSLTUS20080028340 *Jun 25, 2007Jan 31, 2008E-Numerate Solutions, Inc.Tree view for reusable data markup language* Cited by examinerReferenced byCiting PatentFiling datePublication dateApplicantTitleUS7673227Sep 16, 2004Mar 2, 2010Microsoft CorporationUser interface for integrated spreadsheets and word processing tablesUS7676843Mar 9, 2010Microsoft CorporationExecuting applications at appropriate trust levelsUS7689929Mar 30, 2010Microsoft CorporationMethods and systems of providing information to computer usersUS7692636Apr 6, 2010Microsoft CorporationSystems and methods for handwriting to a screenUS7712022Nov 15, 2004May 4, 2010Microsoft CorporationMutually exclusive options in electronic formsUS7712048Jul 23, 2004May 4, 2010Microsoft CorporationTask-sensitive methods and systems for displaying command setsUS7721190Nov 16, 2004May 18, 2010Microsoft CorporationMethods and systems for server side form processingUS7725834Mar 4, 2005May 25, 2010Microsoft CorporationDesigner-created aspect for an electronic form templateUS7743063Jun 22, 2010Microsoft CorporationMethods and systems for delivering software via a networkUS7761786 *Dec 6, 2005Jul 20, 2010International Business Machines CorporationReusable XPath validation expressionsUS7774620Aug 10, 2010Microsoft CorporationExecuting applications at appropriate trust levelsUS7779027Aug 17, 2010Microsoft CorporationMethods, systems, architectures and data structures for delivering software via a networkUS7818677Aug 12, 2004Oct 19, 2010Microsoft CorporationSingle window navigation methods and systemsUS7865477Oct 15, 2007Jan 4, 2011Microsoft CorporationSystem and method for real-time validation of structured data filesUS7900134Nov 8, 2006Mar 1, 2011Microsoft CorporationAuthoring arbitrary XML documents using DHTML and XSLTUS7904801Mar 8, 2011Microsoft CorporationRecursive sections in electronic formsUS7913159Mar 22, 2011Microsoft CorporationSystem and method for real-time validation of structured data filesUS7925621Apr 12, 2011Microsoft CorporationInstalling a solutionUS7937651May 3, 2011Microsoft CorporationStructural editing operations for network formsUS7971139Oct 31, 2007Jun 28, 2011Microsoft CorporationCorrelation, association, or correspondence of electronic formsUS7979856Sep 1, 2005Jul 12, 2011Microsoft CorporationNetwork-based software extensionsUS8001459Dec 5, 2005Aug 16, 2011Microsoft CorporationEnabling electronic documents for limited-capability computing devicesUS8010515Aug 30, 2011Microsoft CorporationQuery to an electronic formUS8046683Oct 25, 2011Microsoft CorporationStructural editing with schema awarenessUS8074217Dec 6, 2011Microsoft CorporationMethods and systems for delivering softwareUS8078960Oct 13, 2008Dec 13, 2011Microsoft CorporationRendering an HTML electronic form by applying XSLT to XML using a solutionUS8200975Jun 29, 2005Jun 12, 2012Microsoft CorporationDigital signatures for network formsUS8429522Apr 23, 2013Microsoft CorporationCorrelation, association, or correspondence of electronic formsUS8819072Feb 2, 2004Aug 26, 2014Microsoft CorporationPromoting data from structured data filesUS8892993Feb 8, 2008Nov 18, 2014Microsoft CorporationTranslation fileUS8918729Apr 2, 2008Dec 23, 2014Microsoft CorporationDesigning electronic formsUS9210234Jun 13, 2011Dec 8, 2015Microsoft Technology Licensing, LlcEnabling electronic documents for limited-capability computing devicesUS9229917Mar 18, 2011Jan 5, 2016Microsoft Technology Licensing, LlcElectronic form user interfacesUS9239821Oct 31, 2014Jan 19, 2016Microsoft Technology Licensing, LlcTranslation fileUS9268760Apr 22, 2013Feb 23, 2016Microsoft Technology Licensing, LlcCorrelation, association, or correspondence of electronic formsUS20050187973 *Feb 19, 2004Aug 25, 2005Microsoft CorporationManaging XML documents containing hierarchical database informationUS20060074930 *Sep 30, 2004Apr 6, 2006Microsoft CorporationStructured-document path-language expression methods and systemsUS20070130504 *Dec 6, 2005Jun 7, 2007International Business Machines CorporationReusable XPath validation expressions* Cited by examinerClassifications U.S. Classification715/762International ClassificationG06F3/00, G06F17/22, G06F17/24Cooperative ClassificationG06F17/2247, G06F17/243European ClassificationG06F17/24F, G06F17/22MLegal EventsDateCodeEventDescriptionJan 15, 2015ASAssignmentOwner name: MICROSOFT TECHNOLOGY LICENSING, LLC, WASHINGTONFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:MICROSOFT CORPORATION;REEL/FRAME:034766/0001Effective date: 20141014RotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services