WO2001018656A1 - Virtual server system for dynamic content in world wide web pages - Google Patents

Virtual server system for dynamic content in world wide web pages Download PDF

Info

Publication number
WO2001018656A1
WO2001018656A1 PCT/US2000/024695 US0024695W WO0118656A1 WO 2001018656 A1 WO2001018656 A1 WO 2001018656A1 US 0024695 W US0024695 W US 0024695W WO 0118656 A1 WO0118656 A1 WO 0118656A1
Authority
WO
WIPO (PCT)
Prior art keywords
data access
definitions
dynamic
dynamic content
database
Prior art date
Application number
PCT/US2000/024695
Other languages
French (fr)
Inventor
Barry Reynolds
Vernon R. Imrich
William Langlais
Paul Howard
Anastasios Giakouminakis
Original Assignee
Percussion Software, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Percussion Software, Inc. filed Critical Percussion Software, Inc.
Priority to AU71264/00A priority Critical patent/AU7126400A/en
Publication of WO2001018656A1 publication Critical patent/WO2001018656A1/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90Details of database functions independent of the retrieved data types
    • G06F16/95Retrieval from the web
    • G06F16/958Organisation or management of web site content, e.g. publishing, maintaining pages or automatic linking

Definitions

  • the present invention relates generally to the field of creating interactive World Wide Web display documents for use over the Internet and more particularly to a virtual server for automatically generating web pages containing dynamic content.
  • FIG. 2A The illustration in Figure 2A(Prior Art) shows the different types of IT skill levels that this might entail.
  • the simplest IT skill level is shown at level A A, where WYSIWYG (What You See Is What You Get) design tools such as DREAMWEAVERTM and FRONTPAGETM provided by Microsoft, allow graphic designers to design web pages and to control the contents of them.
  • WYSIWYG What You See Is What You Get
  • DREAMWEAVERTM FRONTPAGETM provided by Microsoft
  • HTML Hypertext Markup Language
  • WYSIWYG tools allow a designer to manipulate symbols and graphics in such a way that as the designer places them on a webpage, they can be viewed as they will appear to a user. For the typical static content of most websites these tools have eliminated the need for training the web designer in the details of IT and more advanced programming skills.
  • HTML only defines formatting - -XML allows a user to classify the data using tags. For example, HTML only allows a user to format the appearance of the words "Charles Dickens", while XML allows a user to tag those words to indicate he is an author.
  • the business application being developed for the Internet may require that the web page designer and the data access designer allow a user to conditionally extract data for certain kinds of queries.
  • one field in the webpage may need to relate back to many columns of data in the database 00 backend or vice versa, depending on the data values or the context of the query.
  • the business wants to enable the web browser user to update a database 00, additional complications can arise. Is the update an addition, a deletion, or a change? How is the data sent to the web server handling the webpage and the database to be used? What formats are required?
  • the web server protocol HTTP used by designers of HTML documents operates on the principle of "request and return".
  • web servers can deliver rich formatted information inside the web pages they serve, but they can only accept relatively simple information from within a request that is sent by a user at a web browser. Specifically, when a web server receives information, it natively accepts only a simple list of HTML parameters and their values. These parameters are either attached to the URL directly or are sent separately from the URL when submitted from a form using the POST method. Present attempts to address this problem with existing tools require even more special programming and exceptions.
  • the application allows the user at a web browser to submit requests that "drill down" through multiple levels of data detail in the backend database 00 to find very specific data knowing only general information about its location.
  • the problem faced by the data access IT person and the graphics person occurs when they try to make the system automatically determine the navigational information required about the location of the specific data, so that each successive request can be defined and altered independently of the other requests, but in such a way that the links between them are automatically maintained.
  • the database contains a list of employees
  • the user at a web browser only knows that she wants to find an employee named Joe, who lives in the Northeast
  • the user might request all those named Joe Smith.
  • the user sees the list she sees one living in Boston Massachusetts and one in Nashua, New Hampshire. If she remembers the area code, she can ask again to see the one with area code 603, which is the New Hampshire Joe Smith.Retrieving all the necessary information required so that a user can perform this kind of search is a significant challenge for present tools.
  • Recent industry projections indicate that the creation of a simple website with static displays can cost a company anywhere from several thousand US dollars to hundreds of thousands of dollars. Many business organizations may also have existing internal databases and applications programs they have spent thousands or millions of dollars developing.
  • a virtual server system for generating dynamic content and a display document therefor to be sent over a network which automates the retrieval of dynamic content and uses previously defined style and content definition sheets to format the display document.
  • dynamic data is accessed from a database, in any of a number of formats and schemas, using data access definitions and parameters generated at design time.
  • the virtual server uses a previously defined XSL style sheet document containing the static formatting desired and an XML DTD document defining the dynamic content to be applied to the data to generate and serve the requested display document.
  • a display document can be generated at runtime by a virtual server which not only creates the document but also accesses any dynamic data needed in the display.
  • Figure 1A is a block diagram of the present invention.
  • Figure IB is a schematic drawing of the present invention in use.
  • Figure IC is a block diagram of illustrative syntax used by the invention.
  • Figure ID is a block diagram of illustrative syntax used by the invention.
  • Figure IE is a block diagram of illustrative syntax used by the invention.
  • Figure IF is a block diagram illustrating the formatting of repeating rows.
  • Figure 1G is a block diagram illustrating the formatting of nested tables.
  • Figure IH is a block diagram illustrating the formatting of nested tables.
  • Figure II is a block diagram illustrating the formatting of repeating bulleted lists.
  • Figure 1J is a block diagram illustrating the formatting of repeating form elements.
  • Figure 2A is a block diagram of skill levels required by the prior art.
  • Figure 2B(Prior Art) is a block diagram of prior art techniques.
  • Figure 3 (Prior Art) is a schematic diagram of a prior art access to a database, illustrating a problem.
  • Figure 4A is a block diagram of server processing in the prior art.
  • Figure 4B is a block diagram of server processing using the present invention.
  • Figure 4C is a block diagram of the present invention in operation at runtime.
  • Figure 4D is a block diagram of a visual mapper of the present invention.
  • FIGS. 5 - 15 are flow and block diagrams of the present invention. Detailed Description of the Invention
  • FIG 1A an overview of the present invention is shown.
  • Web pages such as input page 15 designed in standard HTML for the World Wide Web usually contain formatting definitions 15a and static content 15b.
  • the present invention's dynamic content identifier (DCI) 18 evaluates the syntax used by the designer to create the page. Using a special, simplified syntax and context analysis discussed below, DCI 18 splits input page 15's elements into those which are static content and those which are dynamic content. In the embodiment shown, DCI 18 creates an XSL compliant style sheet 25, which describes the formatting 26 of the static content of input page 15.
  • DCI 18 also creates a dynamic content definition 28, in XML compliant Document Type Definition (DTD) format.
  • DTD Document Type Definition
  • a data access designer uses page request definition generator 19 of the invention to create data access definitions 32b, which are input parameters for the invention's page request object handler 32.
  • data access definitions 32b are input parameters for the invention's page request object handler 32.
  • the invention's server applies style sheet 25 and dynamic content definition 28 to the content retrieved dynamically from a database to produce a fully formatted HTML page.
  • server objects 30, include server and data access core code 31 and a page request object handler 32.
  • Page request object handler 32 in the embodiment shown includes a handler routine which accepts parameters generated at design time by page request definition generator 19. These parameters define how to access the data in a database and how to map that data into XML format. The parameters also define how to connect to the database, how to login, how to generate queries against it, and so on.
  • DCI 18 allows designers to define all formatting for dynamic content using existing standard HTML tags, using any type of HTML editor or designer tool 13.
  • DCI 18 operates as a separate tool from designer tool 13. However, it could also operate as a subset or extension of a designer tool 13.
  • DCI 18 recognizes specially prefixed field names and attributes, and contextual data to automatically generate an XSL compliant style sheet from the HTML input page 15.
  • Figure IC illustrates some of the general types of specially prefixed field names and attributes.
  • a default prefix 80 such as "psx" can be used by the web designer to identify dynamic content. While the examples shown here use psx, another prefix could be supplied by the designer at the initial configuration of the system.
  • a web designer can use the default prefix 80 with any field names 82 that conform to the XML syntax. Note that these field names are written in HTML by the designer, but conform to XML syntax. Since XML field name syntax requires all fields to share a common "root" node name, the present invention automatically generates a "root" node name for all fields in the HTML document.
  • the root node name comes from the base names of the HTML display document that is being analyzed by DCI 18. For example, assume that in Figure IC, field 82c "psx-name/first" is contained in an input page 15 called person.htm.
  • the present invention gives field 82c the full name 84 of "person /name /first" and the associated DTD document 86 is called "person.dtd”.
  • the root node name is "person.” Any field names 82 in the HTML document input page 15 which already use the correct root node name are not altered by DCI 18.
  • Figure ID illustrates exposed syntax
  • Figure IE illustrates hidden syntax
  • the present invention enables the web designer to use the default prefix 80 with fields which are inserted directly inside existing HTML tags 91 or attributes 92.
  • any dynamic links, images, or other page properties may appear broken to the designer until the actual run-time page is served.
  • Generic tag content 90 illustrates the use of an exposed, specially prefixed fieldname 82 inserted between two tagnames 91.
  • Generic tag attribute 92 shows use of a specially prefixed fieldname 82 as an attribute 92.
  • Figure IE shows the use of hidden syntax.
  • field names 82 are hidden as either generic tag content 100 or generic tag attributes 102.
  • hidden syntax the designer is free to use "dummy" data throughout input page 15 for a better sense of how the runtime document will look.
  • the actual values of the field names 82 will be supplied.
  • a browser does not send the web server the same information that it receives from a web server.
  • the browser sends only the information in a URL (Uniform Resource Locator) and a simple list of HTML parameters and their values. These are either attached to the URL or are sent separately along with the URL when submitted from a Form using the "POST" method. See Figure 4A(Prior Art).
  • URL Uniform Resource Locator
  • the specially prefixed fields will be used by the present invention to populate data into web pages that are served.
  • the browser at the user's location doesn't send back those same fields to the web server when it submits the form, because HTTP does not permit them. Instead, the browser only sends back the HTML parameter list based on the names defined in the HTML FORM. These parameter names are standard HTML and do not use or need the special prefix syntax of the present invention.
  • the present invention supports this situation by allowing one set of mappings to be active when the web page is served from a query, and a different set of mappings to be active when a form is used to update.
  • the invention maps the specially prefixed fields.
  • the invention maps the HTML parameters defined by the form.
  • the present invention also allows a query definition to set default values, attributes, and selection lists for all the form's fields, as well as the form's action attribute and other page properties.
  • Other client programs, such as special Java application programs can send back data in any format, including files, which can also be handled by the present invention. Usually, such special programs will use the same sets of fields as the input page.
  • FIG. 1F-1J the syntax and context analysis used by the present invention to format repeating fields is illustrated.
  • the same field in a document may be repeated in the display document multiple times, each time having a different value.
  • the virtual server of the present invention creates an XML document from back-end data, (database 00) at run-time, it may repeat the same field in that document multiple times, each time with a different value.
  • the DCI 18 of the present invention generates, at design time, style sheets 25 capable of repeating both the fields and the surrounding HTML formatting tags.
  • DCI 18 also allows nesting of repeated fields and formatting within other repeating fields and formatting.
  • a designer controls repeating formatting for fields based on placement of the fields in an HTML page and on the structure of the hierarchical node names shared by the repeated fields.
  • DCI 18 and virtual server 54 of present invention analyze the prefixes and the context of these formats to determine the repeat patterns.
  • Figure IF the method for repeating table rows is shown.
  • all fields share a common root node which associates all fields with their parent document. Since this node is automatically part of all field names and designers do not usually enter it, it is not considered or shown in the examples below.
  • a table row is repeated once for each time the first node (reading the field left to right) is shared by all repeating fields in the row. Any static text in the row repeats when the row repeats. All row and cell attributes (such as border and background color) also repeat.
  • table 114 only the second row 112 has a specially prefixed fieldname 82.
  • the fieldname 82 has a single node Nl called here "itemfeature". The second row will therefore be repeated once for each occurrence of "itemfeature" in the run-time XML document.
  • row 132 has two static fields (Product Name and Product Features) and row 134 has two dynamic fields, as indicated by the special prefix 82, psx in this example.
  • the formatting specified by the designer for these fields will be as seen at runtime in Table 140, when the dynamic data for them has been retrieved and served.
  • the static row 142 is not repeated, but for each dynamic occurrence of a product name, one or more product features 146 are shown and formatted as originally specified by the web page designer. Each product appears on a new row and within that row the features are listed.
  • the formatting shown here which includes the prefix and node names is the formatting defined by the designer at design time - -in Figure 1G, that is table 130.
  • the results - -here table 140 of Figure 1G- - are provided by virtual server 54 of the present invention in a display document in response to that formatting and to the actual results from database 00.
  • table 150 is defined at design time.
  • the outermost table row 152 repeats for the first shared node Nl (from left to right), the second table row 154 inward repeats for the second shared node N2 (continuing to right) and so on continuing inward until either all nested tables or shared nodes are exhausted.
  • This formatting is described by DCI in an XSL style sheet and the dynamic data is identified by DCI 18 in a DTD format dynamic content definition 28.
  • Figure 1J illustrates how the DCI 18 of the present invention can be used to format forms from a browser, applying the same analysis.
  • FIG. IB virtual server 54 of the present invention is shown.
  • a standard web server 52 such as Microsoft Corporation's Internet Information Server (IIS) web server is used, and Microsoft's standard Windows NTTM operating system 50 is used as well.
  • IIS Internet Information Server
  • Figure IB illustrates the relationship of the invention's design time tools - -data access page request definition generator 19 and web page designer's DCI 18- - with actual runtime programs, such as the present invention's virtual server 54, and other web applications 60, web browser 70, and database 00.
  • FIG. 4B an overview of the operation of virtual server 54 of the present invention is shown.
  • a query request is made from a user at UU, it is translated by the web browser into standard http protocol requests S5, such as GET URL, POST Body, and forwarded to the webserver machine S15.
  • standard http protocol requests S5 such as GET URL, POST Body
  • the webserver 52 maps the URL to find the predefined request object handler 32 of the present invention's virtual server 54.
  • Predefined request object handler 32 uses the dynamic content definition 28 created at web page design time in DTD format, and data access definitions 32b created at data access design time to find a database 00, to get the data at block 25, and then to generate the reply in XML format that will be combined by virtual server 54 with the previously defined XSL style sheet to create a web page display document DD that has all the dynamic fields requested and formatted as the web page designer intended.
  • virtual server 54 automatically generates and serves virtual, hierarchically structured documents from structured data stored in a variety of data schemas (relational, tabular, indexed, hierarchical) in a database 00,
  • all data transformations necessary to map from the storage schema of database 00 into the front-end display document DD hierarchy schema may be defined visually without the need for any code, (as described below) thus simplifying the data access logic as well.
  • the data retrieval and data processing logic are pre-compiled and optimized when the virtual server 54 process is started. No run-time code is generated nor is any code interpreted while processing runtime requests.
  • the transformation mappings done by virtual server 54 allow structured data organized in rows and columns to be automatically repeated or collapsed as necessary to fit a hierarchical document's content structure.
  • an input web page 15 in the present invention is a virtual document described by XSL style sheet 25 and dynamic content definition 28. Consequently, in the present invention, a request for such a virtual document appears the same (uses the same request syntax) as a request for an actual physical document being served from disk, although the document in the case of the present invention is entirely virtual. Because the document is virtual, no physical web page document need be stored on, or requested from disk in order for the final display document DD to be served.
  • the present invention's virtual server 54 generates a virtual document at runtime, based on the parameters stored in the predefined request definition object data access definitions 32b and XSL style sheet 25.
  • Virtual server 54 of the present invention both generates and serves XML and HTML documents via the HTTP protocol from various back end data sources- - database 00 - -including relational SQL (Standard Query Language) databases, other XML or HTML files, hierarchical databases (AS/400), and file systems, among others. This allows the data access logic and design to be completely separated from the "look and feel" of the web page design.
  • page request definition generator 19 is used by the data access designer to create the data access definitions 32b that are stored in page request object data access definitions 32b.
  • a request R when a request R is made by a user UU, it travels using standard HTTP protocol over the Internet II to computer S15, which is running an operating system 50, a webserver 52 and the present invention's virtual server 54.
  • Virtual server 54 executes the page request object handler 32 which is associated with the fields in the request R, and uses the data access definitions 32b, which were created by the page request definition generator 19, to access database 00 and find data 01 which meets the request R.
  • the data access definitions 32b can be defined to work with data 01 in a number of common formats, or schemas, such as relational databases, flat fields databases and so on.
  • the data access definitions 32b are used to find the database 00 and make the appropriate read or write requests against it.
  • virtual server 54 maps the data 01 found into XML format using the dynamic content definition 28 created by DCI 18 at web page design time.
  • the formatting defined in style sheet 25 is applied to both the dynamic and the static content of the data found and the virtual display document DD being created.
  • virtual web page display document DD is sent back to the user UU over the Internet II, using the standard webserver software 52.
  • display document DD is not stored at the webserver site or in the database 00 but is created dynamically in accordance with the parameters that are stored in page request object XML mappings 32a and data access definitions 32b, XSL style sheet 25 and dynamic content definition 28.
  • page request object handler 32 includes handler code which accepts the information in the data access definitions 32b, dynamic content definition 28 and XSL style sheet 25 as parameters to be used in satisfying the request R.
  • handler code which accepts the information in the data access definitions 32b, dynamic content definition 28 and XSL style sheet 25 as parameters to be used in satisfying the request R.
  • mapping to XML format performed by the invention 's virtual server 54 is also simplified by use of the current invention's visual mapper 33, shown in Figure 4D.
  • the data access designer can use visual mapper 33 to specify how data 01 found in database 00 should be mapped into XML fields and formats stored in XML mapping 32a. Since this mapping is done at data access design time, it turns the actual mapping at runtime into the application of predefined parameters.
  • FIG. IG an example of XML 141 generated by page request object handler 32 in virtual server 54 of the present invention is shown.
  • page request object handler 32 applies the XSL style sheet 25 formatting, and the dynamic content definition 28 at runtime, the results will appear as table 140 when that particular request is handled.
  • page request definition generator 19 of the present invention is used by the data access designer, at design time to create data access definitions 32b of the page request object handler 32.
  • page request object handler 32 will have as input parameters the XML mapping resulting from dynamic content definition 28 and the data access definitions 32b, as well as XSL style sheet 25.
  • Dynamic content definitions 28 can also contain information regarding the repetitiveness of the data elements. For instance, if there is a table in database 00 called orders with the following structure: order_id Item
  • Orders As a root node which contains Order elements.
  • Orders element declaration there is an asterisk next to Order in the Orders element declaration. This indicates that Order is a repeating entry.
  • Order contains a single attribute, the order id. That maps to an order_id column.
  • ItemList element which contains item elements. The item elements map to the item column.
  • the id attribute of the Order element must be the identifier for item entries. This means that for each matching id (order_id in the back-end) the invention creates one ItemList entry. It then collapses multiple item entries into their matching ItemList entry. Since the id attribute (order_id column) is the key, the back-end query must be sorted on orderjd. If "Use WHERE table" is specified in the data selector on the query pipe and no sorted columns have been specified, the present invention will define orderings (ORDER BY) in the SQL statement issued to the back-end database 00. If sorted columns have been specified, or "Manually enter SQL" has been chosen, the user must be sure to properly sort the data. In the above example, the user wants to collapse items based upon their order id. Consequently, the invention will sort on the order_id column.
  • Orders is a root node which contains Order elements.
  • Order contains the order id, but now it contains the item element directly.
  • This structure indicates there are repeating Order elements, but id and item are now a one to one match.
  • the invention makes no assumptions about sorting requirements. It would now generate the following XML: ⁇ Orders>
  • the data may contain conditionals which can change the way data is mapped.
  • conditionals which can change the way data is mapped.
  • the data contains a phones table as follows:
  • the Contacts /Contact element is repeating. It's id attribute maps to the cont_id column. This tells the present invention it will be sorting on cont_id and collapsing phone records into the Phones element.
  • the pipe character in the Phones element declaration signifies that the Phones element contains home, business or fax elements. Furthermore, the asterisk signifies that there may be many of these.
  • the data access designer builds a mapping such as the following:
  • the invention processes the data, in the embodiment shown, it will first create the Contacts /Contact element and set the id to the cont_id column value. For each matching cont_id value, it will then look at the conditionals phonejype column value to determine what to do. If the column contains 'H' as it's value, it will create a Contacts/Contact/Phones/home element containing the phone_no column's value and set the id attribute to the phone_id column's value. If the phonejype column contains 'B' or 'F' it will create the business or fax element in the same fashion. Based upon the data specified above, the following XML document is generated:
  • update mappings rely heavily upon the XML mapping definitions 32a and the input data structure. For example with the following XML document:
  • Enabling users to navigate, link, or "drill down” from one page to the next is also provided for by the present invention.
  • the data access designer can simply use a request URL on the "source" (current) page to point to the next successive "target” page.
  • the request URL to the"target" page needs to supply more information in order to get the right type of dynamic content.
  • the source page is designed to show people by name, it would have to "know ahead of time" that it is linked to a target page which requires the employee ID number and not the person's name. Otherwise, the source page would be delivered without the employeelD and it would not be possible to link it to the target page. Furthermore, if the target page is changed to use something other than employee ID, then the source page would have to be kept in synch or the links could be broken.
  • the data access designer visually links the "source” data request 1400 to all the other possible “target” data requests, 1402,1404,1406 etc., that could be linked to from that source.
  • the "source” request handler auto-generates all the possible URLs required to link from the source web page to the target pages. Each of these URLs are placed in the "source”, in addition to the other data defined by that source request. If a linked target resource definition is altered to require a new type of request URL, the source request handler is also altered so as to generate the new URL to the target resource.
  • URLs may be used however the designer wishes in the actual pages returned. Most often, the URL is placed as the contents of the HREF attribute on the A (anchor) tag to allow for hypertext linking between documents. However, it is also commonly used in the SRC attribute of the IMG tag (for navigation links attached to non-text resources), or the ACTION attribute of the FORM tag (for navigation links attached to update resources), or anywhere else a standard URL is used in an HTML page or other client application.
  • the subsequent request handler for the "source” is created with additional properties as follows for each linked target.
  • the "source” request must always be a query.
  • the target request definition is examined to determine any required request parameters. 2. If the target is a query: a. The data selection properties for the target are determined. b. Required data for selection is mapped to request parameters for the URL c. The source request handler is updated to include processing of the additional parameters into valid URL syntax. 3. If the target is an update the links may be defined to allow updates, inserts, or deletes. There are two cases to be considered: a. URLs for inserts i. Only the request properties for the target are mapped to request parameters for the URL. ii. The source request handler is updated to include processing of the additional parameters into valid URL syntax, b. URLs for updates or deletes i. The data update properties for the target are determined. ii. Required key data for the update is mapped to request parameters for the URL iii. The source request handler is updated to include processing of the additional parameters into valid URL syntax.
  • the request handler for the "source" page now includes the necessary mechanisms to generate all the URLs to each linked target.
  • the additional URL generation takes place, and the URLs are included with the source document when it is served.
  • DCI 18's processing of the HTML nodes is shown.
  • An input page 15, here shown as HTML 1500 is analyzed HTML node by HTML node, as illustrated at step 1502.
  • DCI 18 checks to see if it has child nodes at decision block 1504. If it does, DCI 18 loops through each HTML childnode until the last or innermost is found. When that is found, processing proceeds at step 1510, to process all the HTML node information from static text at 1512, to other attributes at 1538. The prefix and context analysis described above is applied to each, as appropriate.
  • DCI 18 corrects the node context at step 1540, transforms the HTML node to an XSL node at 1510, and replaces the older one, if any. Processing continues in this manner at 1506 for each HTML node in the child node list. When processing is completed, an XSL style sheet 25 and a dynamic content definition 28 have been created.
  • step 500 the webserver hook of virtual server 54 receives a request.
  • decision block 502 it checks to see if the URL specified in the request is in this server's root. If it is not, the event is released untouched at step 504. If the request does have a URL contained in virtual server 54's root, the invention checks to seek if there is at least on application also in the root, and if the rest of virtual server 54 is up and running. If not, the event is either released at step 508, or the checks for maintenance processing at step 512 through 522 are executed. If virtual server 54 is up, the request is handed to its dispatcher at step 520.
  • step 524 the input parameters of the request are parsed and then run through virtual server' 4's request filters, shown below. Checks are made to see if the request is tied to an application, or if SSL (Secure Socket Layer or other encryption technology is required) and appropriate reports are generated. At step 542, the invention can check use statistics to select the most available server for handling the present request and forward the request to that server.
  • SSL Secure Socket Layer or other encryption technology
  • Figure 6 is a flow diagram which illustrates some of the pre-processing of the request done by the present invention.
  • the system checks to see if raw input data exits have been defined by the user, and if they have, an exit handler is executed for each one specified at step 610. Exits, as they are defined in the embodiment shown, are custom code a data access designer may have written. While it is a goal of the present invention to minimize the need for any custom code, it also permits such code to be included by a data access designer, if desired. If no special exits are need, the invention proceeds to step 604 to map the input data in the request to the back-end data in database 00, by mapping names, and converting data types as necessary. If this succeeds, processing flows to the statement builder at step 618.
  • the statement builder of the present invention is shown in Figure 7. Essentially, the statement builder determines what kind of data access is required. As seen at block 710, if a simple query is required, processing proceeds to execute the query at step 718. If an insert is requested, that processing is selected, and so on. Figure 8 illustrates the processing to execute a query, Figure 10 illustrates the logic for inserting data, Figure 12 illustrates update processing, and Figure 13, delete processing. Figure 11 shows the processing of an actual transaction against database 00, and Figure 9 illustrates the generation of the results. As seen at step 926 in Figure 9, the results are the generated HTML display document DD.
  • Windows NT- compatible personal computers and workstations are used to implement the present invention.
  • other computer platforms such as SUN Microsystems workstations, or IBM Mainframes could be used as well, either in client server or centralized or distributed network configurations.
  • the embodiments shown are programmed using C++, other programming languages can be used as well.
  • software has been used along with the above computer systems to implement the invention, part or all of the invention could be included in firmware or hardware circuitry without deviating from the spirit of the present invention.

Abstract

A virtual server (54) which automates the retrieval of dynamic content for a web page and applies previously generated style (25) and content definition (28) sheets to format the content is disclosed. In the embodiment shown, an HTML document converted into an XSL style sheet document containing the static formatting and an XMLDTD document defining the dynamic content are created at design time. These identify which parts of the formatted document should be considered dynamic content and which should be considered as static. At run time, the invention automatically generates and serves virtual, hierarchically structured documents from structured data stored in a variety of data schemas. The style sheet (25) and content definitions (28) are applied to the data so that a virtual display document is created and sent in response to a user's request. The embodiment shown also allows data transformations to be defined visually. Data retrieval and processing are pre-compiled and optimized when virtual server process is started.

Description

Description Virtual Server System For Dynamic Content In World Wide Web Pages
Technical Field
The present invention relates generally to the field of creating interactive World Wide Web display documents for use over the Internet and more particularly to a virtual server for automatically generating web pages containing dynamic content.
Background
The explosive growth of the Internet and the World Wide Web (the Web) in the last few years has been accompanied by an ever-increasing use of the Internet and the Web for business and commercial purposes. However, most of the tools, such as the Standardized General Markup Language "SGML" and Hypertext Markup Language "HTML" languages and page generation tools which have been developed to allow individuals and companies to create Websites, assume that the content of a Website will be relatively static. HTML, for example, does not provide any syntax for dynamic content. For a retail website designed to display a retail catalog and price list that changes only once every few months, this tends not to be a problem, if products and prices do not change more rapidly. However, as more dynamic business applications are projected for the web, the need to transmit "live," current data through the website has increased dramatically. The proposed extensible Markup Language "XML" and extensible Style Language "XSL" formats should assist in standardizing the format for dynamic content but there are few, if any, tools which allow a statically defined website to handle dynamic content changes readily. Consequently, those businesses seeking to develop such applications will typically need to hire skilled information technology (IT) resources to do so.
The illustration in Figure 2A(Prior Art) shows the different types of IT skill levels that this might entail. Presently, the simplest IT skill level is shown at level A A, where WYSIWYG (What You See Is What You Get) design tools such as DREAMWEAVER™ and FRONTPAGE™ provided by Microsoft, allow graphic designers to design web pages and to control the contents of them. Ideally, as level AA indicates, a web designer is likely to be able to use HTML (Hypertext Markup Language). This is a relatively simple, easy to use language that allows a web designer to "mark up" text and graphics in a web page so they will display as desired at the user's web browser. As the WYSIWYG term implies, WYSIWYG tools allow a designer to manipulate symbols and graphics in such a way that as the designer places them on a webpage, they can be viewed as they will appear to a user. For the typical static content of most websites these tools have eliminated the need for training the web designer in the details of IT and more advanced programming skills.
To the extent that the owner of a commercial website wishes to include the kind of dynamic content associated with many business applications, some higher level of IT skill will usually be required to accomplish this. As shown in Figure 2 (Prior Art), as the IT skill level needed ascends the pyramid shown, resources tend to become scarcer and usually more costly. This is true even with the advent of XML. For example, if a user wants to develop an application that permits use of a volatile, rapidly changing internal database over the Internet, it is very likely that dynamic queries made against the database will turn up a variety of responses. HTML does not allow a designer to specify content as dynamic. Most present design tools have non-standard extensions to HTML that allow a designer to include some dynamic data. However, since these are non-standard extensions, the designer may be locked in to one tool. Also, they usually require additional training of the designer. Most problematic, however, is the fact that they are likely to intermingle data access design logic with display design.
These tools also may or may not be able to handle some of the more complex types of repeating fields in dynamic data. Problems frequently arise when the application under development attempts to map columns C1-C5, in a database, such as database 00 in Figure 3(Prior Art) to field F mappings in a web page 15, when the columns or the field contain hierarchical node components. Thus, FI in webpage 15 may actually require several hierarchical sub -fields F1-F4 to display the hierarchy of subset data found in a column C in database 00. Conversely, in some cases a query made by a user against the database 00 may require the data access design to resolve repeated rows of data from database 00 into an aggregated document for display on the webpage 15. In order for such multiple results to be displayed on webpage 15, additional custom programming beyond the IT skill level of the typical web designer has usually been required.
The prior art tools usually put dynamic data directly into HTML formatted pages physically stored on the website, if they are able to handle dynamic data. Today, many users would prefer to be able to put the dynamic data into XML format first, to take advantage of its tag labeling features. HTML only defines formatting - -XML allows a user to classify the data using tags. For example, HTML only allows a user to format the appearance of the words "Charles Dickens", while XML allows a user to tag those words to indicate he is an author.
Present techniques for solving the IT problem, even with existing tools, usually involve having an IT professional who is skilled in Java or C++ or other languages work in serial with the web designer. Typically, the IT professional develops data access logic to provide the data for the web designer's page design. As shown in Figure 2B(Prior Art) this data access logic is usually embedded in the server enabled page 40 as a data access component 42 (an object or piece of code) or as a server side call 44 within a static HTML document. This means that the page design or "look and feel" of the website or application is tied together with data access and processing and vice versa. Page designers cannot re-design for look and feel without also affecting the data access design. Data access logic cannot be re-designed without also affecting the page design.
This also means designers and IT professionals must interact more than they might otherwise need to do. In normal developments this occurs serially. That is, a page designer may propose a layout which then has to be reviewed and accommodated by the data access IT personnel. If IT personnel think data access logic can be developed or modified to accomplish it, IT approves it and proceeds with development. If IT does not approve, several discussions may be needed to identify compromise solutions. Similarly, changes in the data access logic which might necessitate changes in the page document display will have to be reviewed and accommodated by the graphics page designer. There can often be several iterations back and forth before final common specifications are agreed upon. This tends to cause delays and loss of productivity, as well as a greater chance for design errors.
With the interdependencies that exist between page design and data access design in this approach, other errors can arise easily based on misunderstandings between persons with different skill sets. What may seem to be an obvious page design requirement based on the data access logic design may not be obvious to a graphics designer handling the web page. Similarly, a page design that optimizes attractive display and ease of use may not appear so useful to the data access logic personnel if it makes their jobs more difficult. These discrepancies may not become apparent until well into the development cycle when the page design is first used in connection with the data access design.
Similarly, the business application being developed for the Internet may require that the web page designer and the data access designer allow a user to conditionally extract data for certain kinds of queries. In these cases, one field in the webpage may need to relate back to many columns of data in the database 00 backend or vice versa, depending on the data values or the context of the query. If the business wants to enable the web browser user to update a database 00, additional complications can arise. Is the update an addition, a deletion, or a change? How is the data sent to the web server handling the webpage and the database to be used? What formats are required? The web server protocol HTTP used by designers of HTML documents operates on the principle of "request and return". This means web servers can deliver rich formatted information inside the web pages they serve, but they can only accept relatively simple information from within a request that is sent by a user at a web browser. Specifically, when a web server receives information, it natively accepts only a simple list of HTML parameters and their values. These parameters are either attached to the URL directly or are sent separately from the URL when submitted from a form using the POST method. Present attempts to address this problem with existing tools require even more special programming and exceptions.
For more complex business applications, automatic retrieval and processing of all information needed to make successive data access requests based on the results of the current request may be desired. In this kind of system, the application allows the user at a web browser to submit requests that "drill down" through multiple levels of data detail in the backend database 00 to find very specific data knowing only general information about its location. The problem faced by the data access IT person and the graphics person occurs when they try to make the system automatically determine the navigational information required about the location of the specific data, so that each successive request can be defined and altered independently of the other requests, but in such a way that the links between them are automatically maintained. For example, if the database contains a list of employees, and the user at a web browser only knows that she wants to find an employee named Joe, who lives in the Northeast, she might search the database for all employees named Joe. To find a specific one, the user might request all those named Joe Smith. When the user sees the list she sees one living in Boston Massachusetts and one in Nashua, New Hampshire. If she remembers the area code, she can ask again to see the one with area code 603, which is the New Hampshire Joe Smith.Retrieving all the necessary information required so that a user can perform this kind of search is a significant challenge for present tools.
Recent industry projections indicate that the creation of a simple website with static displays can cost a company anywhere from several thousand US dollars to hundreds of thousands of dollars. Many business organizations may also have existing internal databases and applications programs they have spent thousands or millions of dollars developing.
At present, programming language tools for the Web, such as ASP™, provided by Microsoft and COLDFUSION™'s CFML™, provided by Allair, attempt to offer businesses a way to integrate the dynamic content of backend databases with statically defined website pages, but these tools involve using a specially developed proprietary language with its own complexity and hence, the need for a higher IT skill level. CFML, for example, has over 200 different commands a designer might need to learn. These tools as well as custom programmed efforts written in Java or C++ also tend to require the embedding of code in the webpage documents. This code is usually executed at run-time each time requests are made for dynamic data. As seen in Figure 2B(Prior Art) this can also slow down the overall execution of queries made at run- time over the Web. Present attempts to design or modify web pages to incorporate dynamic data content are thus hampered by the potential need for higher, more expensive and scarcer IT skill levels, costly development times and delays, and final products that may be comparatively slower in execution time. Additionally, some current techniques require a user to include programs written in proprietary languages or custom-developed programs.
Summary
A virtual server system for generating dynamic content and a display document therefor to be sent over a network is disclosed which automates the retrieval of dynamic content and uses previously defined style and content definition sheets to format the display document. In the embodiment shown, dynamic data is accessed from a database, in any of a number of formats and schemas, using data access definitions and parameters generated at design time. The virtual server uses a previously defined XSL style sheet document containing the static formatting desired and an XML DTD document defining the dynamic content to be applied to the data to generate and serve the requested display document.
It is an aspect of the present invention that no physical display document is stored.
It is another aspect of the present invention that a display document can be generated at runtime by a virtual server which not only creates the document but also accesses any dynamic data needed in the display.
Brief Description of the Drawings.
Figure 1A is a block diagram of the present invention.
Figure IB is a schematic drawing of the present invention in use.
Figure IC is a block diagram of illustrative syntax used by the invention. Figure ID is a block diagram of illustrative syntax used by the invention.
Figure IE is a block diagram of illustrative syntax used by the invention.
Figure IF is a block diagram illustrating the formatting of repeating rows.
Figure 1G is a block diagram illustrating the formatting of nested tables.
Figure IH is a block diagram illustrating the formatting of nested tables. Figure II is a block diagram illustrating the formatting of repeating bulleted lists.
Figure 1J is a block diagram illustrating the formatting of repeating form elements.
Figure 2A(Prior Art) is a block diagram of skill levels required by the prior art.
Figure 2B(Prior Art) is a block diagram of prior art techniques. Figure 3 (Prior Art) is a schematic diagram of a prior art access to a database, illustrating a problem.
Figure 4A (Prior Art) is a block diagram of server processing in the prior art.
Figure 4B is a block diagram of server processing using the present invention.
Figure 4C is a block diagram of the present invention in operation at runtime. Figure 4D is a block diagram of a visual mapper of the present invention.
Figures 5 - 15 are flow and block diagrams of the present invention. Detailed Description of the Invention
In Figure 1A an overview of the present invention is shown. An input page 15, which is being designed by a web designer, is depicted. Web pages such as input page 15 designed in standard HTML for the World Wide Web usually contain formatting definitions 15a and static content 15b. Working in conjunction with the web page designer's choice of designer tool 13, the present invention's dynamic content identifier (DCI) 18 evaluates the syntax used by the designer to create the page. Using a special, simplified syntax and context analysis discussed below, DCI 18 splits input page 15's elements into those which are static content and those which are dynamic content. In the embodiment shown, DCI 18 creates an XSL compliant style sheet 25, which describes the formatting 26 of the static content of input page 15. DCI 18 also creates a dynamic content definition 28, in XML compliant Document Type Definition (DTD) format. At design time a data access designer uses page request definition generator 19 of the invention to create data access definitions 32b, which are input parameters for the invention's page request object handler 32. When a web page such as input page 15 is requested from the present invention's virtual server (described below) at runtime, the invention's server applies style sheet 25 and dynamic content definition 28 to the content retrieved dynamically from a database to produce a fully formatted HTML page. This is performed by server objects 30, which include server and data access core code 31 and a page request object handler 32. Page request object handler 32 in the embodiment shown includes a handler routine which accepts parameters generated at design time by page request definition generator 19. These parameters define how to access the data in a database and how to map that data into XML format. The parameters also define how to connect to the database, how to login, how to generate queries against it, and so on.
Despite the fact that HTML at present has no support for dynamic content, the present invention's dynamic content identifier (DCI) 18 allows designers to define all formatting for dynamic content using existing standard HTML tags, using any type of HTML editor or designer tool 13. In the embodiment shown, DCI 18 operates as a separate tool from designer tool 13. However, it could also operate as a subset or extension of a designer tool 13. DCI 18 recognizes specially prefixed field names and attributes, and contextual data to automatically generate an XSL compliant style sheet from the HTML input page 15.
Figure IC illustrates some of the general types of specially prefixed field names and attributes. In the embodiment shown, a default prefix 80 such as "psx" can be used by the web designer to identify dynamic content. While the examples shown here use psx, another prefix could be supplied by the designer at the initial configuration of the system.
Still in Figure IC, a web designer can use the default prefix 80 with any field names 82 that conform to the XML syntax. Note that these field names are written in HTML by the designer, but conform to XML syntax. Since XML field name syntax requires all fields to share a common "root" node name, the present invention automatically generates a "root" node name for all fields in the HTML document. The root node name comes from the base names of the HTML display document that is being analyzed by DCI 18. For example, assume that in Figure IC, field 82c "psx-name/first" is contained in an input page 15 called person.htm. In this example, the present invention gives field 82c the full name 84 of "person /name /first" and the associated DTD document 86 is called "person.dtd". In this example, the root node name is "person." Any field names 82 in the HTML document input page 15 which already use the correct root node name are not altered by DCI 18.
Turning now to Figures ID, and IE, two types of special syntax recognized by the present invention are illustrated. Figure ID illustrates exposed syntax and Figure IE illustrates hidden syntax.
First, in Figure ID, the present invention enables the web designer to use the default prefix 80 with fields which are inserted directly inside existing HTML tags 91 or attributes 92. This is exposed syntax. That is, the field names 82 will show up on input page 15 during design time. This kind of syntax makes it easier for the designer to tell where the dynamic content is located, but makes it harder to get a sense of what the actual run-time page will look like. In addition, in exposed syntax, any dynamic links, images, or other page properties may appear broken to the designer until the actual run-time page is served. Generic tag content 90 illustrates the use of an exposed, specially prefixed fieldname 82 inserted between two tagnames 91. Generic tag attribute 92 shows use of a specially prefixed fieldname 82 as an attribute 92.
Figure IE shows the use of hidden syntax. In this syntax, field names 82 are hidden as either generic tag content 100 or generic tag attributes 102. With hidden syntax, the designer is free to use "dummy" data throughout input page 15 for a better sense of how the runtime document will look. At run-time, the actual values of the field names 82 will be supplied.
In most present browsers designed for the Worldwide Web, a browser does not send the web server the same information that it receives from a web server. When sending information, the browser sends only the information in a URL (Uniform Resource Locator) and a simple list of HTML parameters and their values. These are either attached to the URL or are sent separately along with the URL when submitted from a Form using the "POST" method. See Figure 4A(Prior Art). Thus, if a page has both queries and updates, the specially prefixed fields will be used by the present invention to populate data into web pages that are served. However, the browser at the user's location doesn't send back those same fields to the web server when it submits the form, because HTTP does not permit them. Instead, the browser only sends back the HTML parameter list based on the names defined in the HTML FORM. These parameter names are standard HTML and do not use or need the special prefix syntax of the present invention.
The present invention supports this situation by allowing one set of mappings to be active when the web page is served from a query, and a different set of mappings to be active when a form is used to update. On the query, the invention maps the specially prefixed fields. On a form update, the invention maps the HTML parameters defined by the form. The present invention also allows a query definition to set default values, attributes, and selection lists for all the form's fields, as well as the form's action attribute and other page properties. Other client programs, such as special Java application programs can send back data in any format, including files, which can also be handled by the present invention. Usually, such special programs will use the same sets of fields as the input page.
Turning now to Figures 1F-1J, the syntax and context analysis used by the present invention to format repeating fields is illustrated. When a user is accessing dynamic data from a database, the same field in a document may be repeated in the display document multiple times, each time having a different value.
When the virtual server of the present invention (discussed in more detail below) creates an XML document from back-end data, (database 00) at run-time, it may repeat the same field in that document multiple times, each time with a different value. To format these repeated fields, the DCI 18 of the present invention generates, at design time, style sheets 25 capable of repeating both the fields and the surrounding HTML formatting tags.
DCI 18 also allows nesting of repeated fields and formatting within other repeating fields and formatting. A designer controls repeating formatting for fields based on placement of the fields in an HTML page and on the structure of the hierarchical node names shared by the repeated fields. DCI 18 and virtual server 54 of present invention analyze the prefixes and the context of these formats to determine the repeat patterns.
In Figure IF, the method for repeating table rows is shown. In the embodiment shown, all fields share a common root node which associates all fields with their parent document. Since this node is automatically part of all field names and designers do not usually enter it, it is not considered or shown in the examples below. In Figure IF, a table row is repeated once for each time the first node (reading the field left to right) is shared by all repeating fields in the row. Any static text in the row repeats when the row repeats. All row and cell attributes (such as border and background color) also repeat.
In Figure IF, table 114, only the second row 112 has a specially prefixed fieldname 82. The fieldname 82 has a single node Nl called here "itemfeature". The second row will therefore be repeated once for each occurrence of "itemfeature" in the run-time XML document.
Thus, as shown by table 116 of Figure If, if there is only one actual occurrence of an "itemfeature" (here the actual itemfeature is "It's cheap!) when the backend data from the database is served by server 54 in an XML format, then the example of row 120 will be displayed when the page is served. However, if the field has several entries in the database, the present invention allows the field formatting to be repeatedly applied to them, as seen in Table 118 , rows 122-126 of Figure IF.
With reference now to Figure 1G, the present invention allows a web page designer to repeat the formatting for multiple fields sharing the same node. In table 130, as it appears at design time, row 132 has two static fields (Product Name and Product Features) and row 134 has two dynamic fields, as indicated by the special prefix 82, psx in this example. The formatting specified by the designer for these fields will be as seen at runtime in Table 140, when the dynamic data for them has been retrieved and served. Here, the static row 142 is not repeated, but for each dynamic occurrence of a product name, one or more product features 146 are shown and formatted as originally specified by the web page designer. Each product appears on a new row and within that row the features are listed. It should be noted in these examples, that the formatting shown here which includes the prefix and node names is the formatting defined by the designer at design time - -in Figure 1G, that is table 130. The results - -here table 140 of Figure 1G- - are provided by virtual server 54 of the present invention in a display document in response to that formatting and to the actual results from database 00.
Turning now to Figure IH, it can be seen that the embodiment shown also allows repeating of rows within rows. In Figure IH , table 150 is defined at design time. In table 150, the outermost table row 152, repeats for the first shared node Nl (from left to right), the second table row 154 inward repeats for the second shared node N2 (continuing to right) and so on continuing inward until either all nested tables or shared nodes are exhausted. This formatting is described by DCI in an XSL style sheet and the dynamic data is identified by DCI 18 in a DTD format dynamic content definition 28. When dynamic data is retrieved at runtime about 3 different productsl58,162,164, each having one or more featuresl70,172,174,176, the XSL style sheet 25 and the dynamic content definition 28 created at design time are applied by the invention's virtual server so that the information is displayed as shown in table 156 of Figure IH . In Figure IH note that the static content 160 "Take a look at these features!" is repeated with each occurrence of the product/name, while the changeable, dynamic content about products and features has been arranged as shown in Table 156. All other repeatable formats nested within a table, such as the bulleted list shown in Figure II, , exhaust the shared nodes (from left to right) in the order of outermost to innermost repeatable formatting. Those skilled in the art will appreciate that other methods for analyzing the context and syntax could be used without deviating from the present invention. Special characters or indicators could be used, for example, or context might be analyzed differently.
Figure 1J illustrates how the DCI 18 of the present invention can be used to format forms from a browser, applying the same analysis.
Now turning to Figure IB, virtual server 54 of the present invention is shown. In the embodiment shown, a standard web server 52, such as Microsoft Corporation's Internet Information Server (IIS) web server is used, and Microsoft's standard Windows NT™ operating system 50 is used as well. As will be apparent to those skilled in the art, other web servers, operating systems, and network protocols could be used without deviating from the spirit of the present invention. Figure IB illustrates the relationship of the invention's design time tools - -data access page request definition generator 19 and web page designer's DCI 18- - with actual runtime programs, such as the present invention's virtual server 54, and other web applications 60, web browser 70, and database 00.
Turning briefly to Figure 4B, an overview of the operation of virtual server 54 of the present invention is shown. When a query request is made from a user at UU, it is translated by the web browser into standard http protocol requests S5, such as GET URL, POST Body, and forwarded to the webserver machine S15. There the webserver 52 maps the URL to find the predefined request object handler 32 of the present invention's virtual server 54. Predefined request object handler 32 uses the dynamic content definition 28 created at web page design time in DTD format, and data access definitions 32b created at data access design time to find a database 00, to get the data at block 25, and then to generate the reply in XML format that will be combined by virtual server 54 with the previously defined XSL style sheet to create a web page display document DD that has all the dynamic fields requested and formatted as the web page designer intended.
In the embodiment shown, virtual server 54 automatically generates and serves virtual, hierarchically structured documents from structured data stored in a variety of data schemas (relational, tabular, indexed, hierarchical) in a database 00, In addition, all data transformations necessary to map from the storage schema of database 00 into the front-end display document DD hierarchy schema may be defined visually without the need for any code, (as described below) thus simplifying the data access logic as well. The data retrieval and data processing logic are pre-compiled and optimized when the virtual server 54 process is started. No run-time code is generated nor is any code interpreted while processing runtime requests. The transformation mappings done by virtual server 54 allow structured data organized in rows and columns to be automatically repeated or collapsed as necessary to fit a hierarchical document's content structure.
In the embodiment shown, no physical input page 15 was actually stored on disk at design time by DCI 18. Instead, an input web page 15 in the present invention is a virtual document described by XSL style sheet 25 and dynamic content definition 28. Consequently, in the present invention, a request for such a virtual document appears the same (uses the same request syntax) as a request for an actual physical document being served from disk, although the document in the case of the present invention is entirely virtual. Because the document is virtual, no physical web page document need be stored on, or requested from disk in order for the final display document DD to be served.
In other words, while prior art approaches usually store a physical document - - such as input page 15- - containing HTML formatting and embedded code , the present invention's virtual server 54 generates a virtual document at runtime, based on the parameters stored in the predefined request definition object data access definitions 32b and XSL style sheet 25.
Virtual server 54 of the present invention both generates and serves XML and HTML documents via the HTTP protocol from various back end data sources- - database 00 - -including relational SQL (Standard Query Language) databases, other XML or HTML files, hierarchical databases (AS/400), and file systems, among others. This allows the data access logic and design to be completely separated from the "look and feel" of the web page design. Returning to Figure 1A for a moment, page request definition generator 19 is used by the data access designer to create the data access definitions 32b that are stored in page request object data access definitions 32b.
Now referring to Figure 4C, when a request R is made by a user UU, it travels using standard HTTP protocol over the Internet II to computer S15, which is running an operating system 50, a webserver 52 and the present invention's virtual server 54. Virtual server 54 executes the page request object handler 32 which is associated with the fields in the request R, and uses the data access definitions 32b, which were created by the page request definition generator 19, to access database 00 and find data 01 which meets the request R. The data access definitions 32b can be defined to work with data 01 in a number of common formats, or schemas, such as relational databases, flat fields databases and so on. The data access definitions 32b are used to find the database 00 and make the appropriate read or write requests against it.
In the embodiment shown in Figure 4C, virtual server 54 maps the data 01 found into XML format using the dynamic content definition 28 created by DCI 18 at web page design time. As part of this processing, the formatting defined in style sheet 25 is applied to both the dynamic and the static content of the data found and the virtual display document DD being created. When formatting is completed, virtual web page display document DD is sent back to the user UU over the Internet II, using the standard webserver software 52. As seen in this example, display document DD is not stored at the webserver site or in the database 00 but is created dynamically in accordance with the parameters that are stored in page request object XML mappings 32a and data access definitions 32b, XSL style sheet 25 and dynamic content definition 28. In the embodiment shown, page request object handler 32 includes handler code which accepts the information in the data access definitions 32b, dynamic content definition 28 and XSL style sheet 25 as parameters to be used in satisfying the request R. Thus, no code is embedded in display document DD. This makes it easy for the data access logic to be changed without affecting the web page formatting and vice versa.
In addition, the mapping to XML format performed by the invention 's virtual server 54 is also simplified by use of the current invention's visual mapper 33, shown in Figure 4D. As seen there, the data access designer can use visual mapper 33 to specify how data 01 found in database 00 should be mapped into XML fields and formats stored in XML mapping 32a. Since this mapping is done at data access design time, it turns the actual mapping at runtime into the application of predefined parameters.
Turning back briefly to Figure IG, an example of XML 141 generated by page request object handler 32 in virtual server 54 of the present invention is shown. When page request object handler 32 applies the XSL style sheet 25 formatting, and the dynamic content definition 28 at runtime, the results will appear as table 140 when that particular request is handled.
With reference now to Figure 1A again, page request definition generator 19 of the present invention is used by the data access designer, at design time to create data access definitions 32b of the page request object handler 32. Thus, at run time, page request object handler 32 will have as input parameters the XML mapping resulting from dynamic content definition 28 and the data access definitions 32b, as well as XSL style sheet 25.
This enables virtual server 54 of the present invention to take advantage of the dynamic content definition 28 to determine what the output format should be.
Dynamic content definitions 28 can also contain information regarding the repetitiveness of the data elements. For instance, if there is a table in database 00 called orders with the following structure: order_id Item
123 1
123 2
123 3
456 1 456 2 there are many ways to create an XML document from this data. One way to force the structure is to build the dynamic content definition 28 in the appropriate manner. For example:
<!ELEMENT Orders (Order*)> <!ELEMENT Order (ItemList)> <!ATTLIST Order id ID #REQUIRED> <!ELEMENT ItemList (item*)> <!ELEMENT item (#PCDATA)>
This has Orders as a root node which contains Order elements. Looking at the above dynamic content definition 28, there is an asterisk next to Order in the Orders element declaration. This indicates that Order is a repeating entry. Order contains a single attribute, the order id. That maps to an order_id column. There is also an ItemList element which contains item elements. The item elements map to the item column. Once again, from the dynamic content definition 28 it is seen that item is a repeating entry. The id attribute, on the other hand, cannot repeat, because attributes cannot repeat in XML. Based upon these relationships, the present invention makes a few determinations:
- -the id attribute of the Order element must be the identifier for item entries. This means that for each matching id (order_id in the back-end) the invention creates one ItemList entry. It then collapses multiple item entries into their matching ItemList entry. Since the id attribute (order_id column) is the key, the back-end query must be sorted on orderjd. If "Use WHERE table" is specified in the data selector on the query pipe and no sorted columns have been specified, the present invention will define orderings (ORDER BY) in the SQL statement issued to the back-end database 00. If sorted columns have been specified, or "Manually enter SQL" has been chosen, the user must be sure to properly sort the data. In the above example, the user wants to collapse items based upon their order id. Consequently, the invention will sort on the order_id column.
This would cause the following XML to be generated:
<Orders>
<Order id="123"> <ItemList>
<item>l</item> <item>2< / item> <item>3< / item> </ItemList> </Order> <Order id="456"> <ItemList>
<item> 1 < / item> <item>2</item> </ItemList> </ Order > </Orders>
If a slight change is made as follows, to the dynamic content definition 28 :
<!ELEMENT Orders (Order*)> <!ELEMENT Order (item)> <!ATTLIST Order id ID #REQUIRED>
<!ELEMENT item (#PCDATA)>
once again Orders is a root node which contains Order elements. Order contains the order id, but now it contains the item element directly. This structure indicates there are repeating Order elements, but id and item are now a one to one match. For this model, the invention makes no assumptions about sorting requirements. It would now generate the following XML: <Orders>
<Order id="123">
<item> 1 < / item> </ Order > <Order id="123">
<item>2</item> </Order> <Order id="123">
<item>3< / item> </Order>
<Order id="456">
<item> 1 < / item> </Order> <Order id="456"> <item>2</item>
</Order> </Orders>
Further complicating query mappings, the data may contain conditionals which can change the way data is mapped. For example, assume the data contains a phones table as follows:
phone_id cont_id phone_type phone_no
1 1 H 111-1111 2 1 B 222-2222
3 1 F 333-3333
4 2 B 444-4444
5 2 F 555-5555 and the following dynamic content definition 28 is generated:
<!ELEMENT Contacts (Contact*)> <!ELEMENT Contact (Phones)> <!ATTLIST Contact id ID #REQUIRED> <!ELEMENT Phones ((home | business | fax)*)> <!ELEMENT home (#PCDATA)> <!ATTLIST home id ID #REQUIRED> <!ELEMENT business (#PCDATA)> <!ATTLIST business id ID #REQUIRED> <!ELEMENT fax (#PCDATA)> <!ATTLIST fax id ID #REQUIRED>
In this example, first note that the Contacts /Contact element is repeating. It's id attribute maps to the cont_id column. This tells the present invention it will be sorting on cont_id and collapsing phone records into the Phones element. The pipe character in the Phones element declaration signifies that the Phones element contains home, business or fax elements. Furthermore, the asterisk signifies that there may be many of these. To get the phone numbers into the appropriate places, the data access designer builds a mapping such as the following:
XML Field Back-End Column Conditionals
Contacts/Contact/@id cont_id Contacts / Contact / Phones /home / @id phone_id phone_type =
H
Contacts /Contact / Phones /home phone_no phone_type =
H
Contacts/Contact/Phones/business/@id phone_id phonejype =
B
Contacts/Contact/Phones/business phone_no phone_type =
B
Contacts / Contact /Phones / fax / @id phone_id phone_type =
F
Contacts /Contact / Phones / fax phone_no phonejype =
F
As the invention processes the data, in the embodiment shown, it will first create the Contacts /Contact element and set the id to the cont_id column value. For each matching cont_id value, it will then look at the conditionals phonejype column value to determine what to do. If the column contains 'H' as it's value, it will create a Contacts/Contact/Phones/home element containing the phone_no column's value and set the id attribute to the phone_id column's value. If the phonejype column contains 'B' or 'F' it will create the business or fax element in the same fashion. Based upon the data specified above, the following XML document is generated:
<Contacts>
<Contact id="l"> <Phones>
<home id="l">lll-llll</home> <business id="2">222-2222< /business> <fax id="3">333-3333</fax> -29-
</Phones> <Contact> <Contact id="2"> <Phones> <business id="4">444-4444</business>
<fax id="5">555-5555</fax> </Phones> <Contact> <Contacts>
When performing updates, inserts or deletes, the embodiment of the invention shown here needs an attribute or element to be defined which tells it which of these three actions it should take.
Unlike query mappings which take advantage of the dynamic content definition 28, update mappings rely heavily upon the XML mapping definitions 32a and the input data structure. For example with the following XML document:
<Contacts>
<Contact id="l">
<Phones DBActionType="UPDATE">
<home id="l">lll-llll</home> <business id="2">800-222-2222</business>
<fax id="3">333-3333</fax> </Phones> <Contact> <Contact id="2"> <Phones>
<business id="4">444-4444</business> <fax id="5">555-5555</fax> </Phones> <Contact> <Contacts> there is an added attribute, DBActionType, to the Phones element. When performing updates, inserts or deletes, the page request object handler 32 of the present invention needs an attribute or element to be defined which tells it which of these three actions it should take. The system would then see a need to update the phone numbers for the first contact, but skip the second contact.
This entails applying data from multiple XML fields into the same back-end table. To do this, the data access designer has created a set of mappings for each XML group to its corresponding back-end group. By repeating the back-end column entries, the present invention will process each group of entries as a separate update to the back-end database 00.
Enabling users to navigate, link, or "drill down" from one page to the next is also provided for by the present invention. In its simplest form, the data access designer can simply use a request URL on the "source" (current) page to point to the next successive "target" page. However, in a dynamic environment things quickly get more complicated. The request URL to the"target" page needs to supply more information in order to get the right type of dynamic content.
For example, in a static environment with only one person, the request URL needs to only specify "person.htm" but in a dynamic content environment with many people, the URL would need to specify "person.htm?firstname=Joe&lastname=Smith" in order to get the exact person page for "Joe Smith". Complicating issues further, the source page may itself have been created dynamically based on some other request. Suppose for example, the source page contained a list of people to choose from by name, but now the target page required an employee ID number to locate any specific person such as, "person.htm?employeeid=123". Here, though the source page is designed to show people by name, it would have to "know ahead of time" that it is linked to a target page which requires the employee ID number and not the person's name. Otherwise, the source page would be delivered without the employeelD and it would not be possible to link it to the target page. Furthermore, if the target page is changed to use something other than employee ID, then the source page would have to be kept in synch or the links could be broken.
The present invention solves these problems through the use of navigation links. As seen in Figure 14, the data access designer visually links the "source" data request 1400 to all the other possible "target" data requests, 1402,1404,1406 etc., that could be linked to from that source. When this is done, the "source" request handler auto-generates all the possible URLs required to link from the source web page to the target pages. Each of these URLs are placed in the "source", in addition to the other data defined by that source request. If a linked target resource definition is altered to require a new type of request URL, the source request handler is also altered so as to generate the new URL to the target resource.
These autogenerated URLs may be used however the designer wishes in the actual pages returned. Most often, the URL is placed as the contents of the HREF attribute on the A (anchor) tag to allow for hypertext linking between documents. However, it is also commonly used in the SRC attribute of the IMG tag (for navigation links attached to non-text resources), or the ACTION attribute of the FORM tag (for navigation links attached to update resources), or anywhere else a standard URL is used in an HTML page or other client application.
When a "source" request is linked to a "target" request at design time, the subsequent request handler for the "source" is created with additional properties as follows for each linked target. In the embodiment shown, the "source" request must always be a query.
1. The target request definition is examined to determine any required request parameters. 2. If the target is a query: a. The data selection properties for the target are determined. b. Required data for selection is mapped to request parameters for the URL c. The source request handler is updated to include processing of the additional parameters into valid URL syntax. 3. If the target is an update the links may be defined to allow updates, inserts, or deletes. There are two cases to be considered: a. URLs for inserts i. Only the request properties for the target are mapped to request parameters for the URL. ii. The source request handler is updated to include processing of the additional parameters into valid URL syntax, b. URLs for updates or deletes i. The data update properties for the target are determined. ii. Required key data for the update is mapped to request parameters for the URL iii. The source request handler is updated to include processing of the additional parameters into valid URL syntax.
At run time, the request handler for the "source" page now includes the necessary mechanisms to generate all the URLs to each linked target. When the source page is processed, the additional URL generation takes place, and the URLs are included with the source document when it is served.
Detailed flow diagrams illustrate the logic of the embodiment shown. Beginning with Figure 15, DCI 18's processing of the HTML nodes is shown. An input page 15, here shown as HTML 1500 is analyzed HTML node by HTML node, as illustrated at step 1502. Once an HTML node is selected, DCI 18 checks to see if it has child nodes at decision block 1504. If it does, DCI 18 loops through each HTML childnode until the last or innermost is found. When that is found, processing proceeds at step 1510, to process all the HTML node information from static text at 1512, to other attributes at 1538. The prefix and context analysis described above is applied to each, as appropriate. Then DCI 18 corrects the node context at step 1540, transforms the HTML node to an XSL node at 1510, and replaces the older one, if any. Processing continues in this manner at 1506 for each HTML node in the child node list. When processing is completed, an XSL style sheet 25 and a dynamic content definition 28 have been created.
Turning now to Figure 5, initiation of the invention's virtual server 54, here referred to as E2 is shown. At step 500 the webserver hook of virtual server 54 receives a request. At decision block 502 it checks to see if the URL specified in the request is in this server's root. If it is not, the event is released untouched at step 504. If the request does have a URL contained in virtual server 54's root, the invention checks to seek if there is at least on application also in the root, and if the rest of virtual server 54 is up and running. If not, the event is either released at step 508, or the checks for maintenance processing at step 512 through 522 are executed. If virtual server 54 is up, the request is handed to its dispatcher at step 520. At step 524 the input parameters of the request are parsed and then run through virtual server' 4's request filters, shown below. Checks are made to see if the request is tied to an application, or if SSL (Secure Socket Layer or other encryption technology is required) and appropriate reports are generated. At step 542, the invention can check use statistics to select the most available server for handling the present request and forward the request to that server.
Figure 6 is a flow diagram which illustrates some of the pre-processing of the request done by the present invention. At decision block 602, the system checks to see if raw input data exits have been defined by the user, and if they have, an exit handler is executed for each one specified at step 610. Exits, as they are defined in the embodiment shown, are custom code a data access designer may have written. While it is a goal of the present invention to minimize the need for any custom code, it also permits such code to be included by a data access designer, if desired. If no special exits are need, the invention proceeds to step 604 to map the input data in the request to the back-end data in database 00, by mapping names, and converting data types as necessary. If this succeeds, processing flows to the statement builder at step 618.
The statement builder of the present invention is shown in Figure 7. Essentially, the statement builder determines what kind of data access is required. As seen at block 710, if a simple query is required, processing proceeds to execute the query at step 718. If an insert is requested, that processing is selected, and so on. Figure 8 illustrates the processing to execute a query, Figure 10 illustrates the logic for inserting data, Figure 12 illustrates update processing, and Figure 13, delete processing. Figure 11 shows the processing of an actual transaction against database 00, and Figure 9 illustrates the generation of the results. As seen at step 926 in Figure 9, the results are the generated HTML display document DD.
In the embodiments shown, Windows NT- compatible personal computers and workstations are used to implement the present invention. However, those skilled in the art appreciate that other computer platforms such as SUN Microsystems workstations, or IBM Mainframes could be used as well, either in client server or centralized or distributed network configurations. While the embodiments shown are programmed using C++, other programming languages can be used as well. Similarly, while software has been used along with the above computer systems to implement the invention, part or all of the invention could be included in firmware or hardware circuitry without deviating from the spirit of the present invention.

Claims

ClaimsWhat is claimed is:
1. A method for generating a virtual display document containing dynamic content over a network in response to a request, comprising the steps of: accessing dynamic data in a database using a previously generated dynamic data access definition; applying a previously generated style sheet to format the static fields of the virtual display document; applying a previously defined dynamic content definition for the virtual display document which describes how dynamic fields are to be formatted; and dynamically serving a virtual display document formatted accordingly in response to the request.
2. The method of Claim 1, wherein the step of accessing dynamic data in a database using a previously generated dynamic data access definition further comprises the step of using the data access definition to find the database and make the appropriate input and output requests to the database.
3. The method of Claim 1 wherein the step of accessing dynamic data in a database using a previously generated dynamic data access definition further comprises the step of using the previously generated dynamic data access definition to work with data in any of a plurality of common formats.
4. The method of Claim 1, wherein the step of dynamically serving a virtual display document further comprises the step of mapping data access definitions, style sheets and dynamic content definitions to generate the virtual display document.
5. The method of Claim 4, wherein the step of mapping data access definitions, style sheets and dynamic content definitions further comprises the step of mapping data access definitions, style sheets and dynamic content definitions into XML format.
6. The method of Claim 4, wherein the step of mapping data access definitions, style sheets and dynamic content definitions is performed dynamically by a page request object handler.
7. The method of Claim 6, wherein the step of mapping data access definitions, style sheets and dynamic content definitions further comprises the steps of: - - mapping the correspondences between data access definitions, style sheets and dynamic content definitions and XML fields and formats at design time and storing the mapping results in the database; and - -using the page request object handler to apply the mapping results when the virtual display document is served.
8. The method of Claim 7 wherein the step of mapping the correspondences is done by a visual mapper.
9. An apparatus for generating a virtual display document containing dynamic content over a network in response to a request, comprising: means for accessing dynamic data in a database using a previously generated dynanric data access definition; means for applying a previously generated style sheet to format the static fields of the virtual display document; means for applying a previously defined dynamic content definition for the virtual display document which describes how dynamic fields are to be formatted; and means for dynamically serving a virtual display document formatted accordingly in response to the request.
10. The apparatus of Claim 9, wherein the means for accessing dynamic data in a database using a previously generated dynamic data access definition further comprises means for using the data access definition to find the database and make the appropriate input and output requests to the database.
11. The apparatus of Claim 9 wherein the means for accessing dynamic data in a database using a previously generated dynamic data access definition further comprises means for using the previously generated dynamic data access definition to work with data in any of a plurality of common formats.
12. The apparatus of Claim 9, wherein the means for dynamically serving a virtual display document further comprises means for mapping data access definitions, style sheets and dynamic content definitions to generate the virtual display document.
13. The apparatus of Claim 12, wherein the means for mapping data access definitions, style sheets and dynamic content definitions further comprises means for mapping data access definitions, style sheets and dynamic content definitions into XML format.
14. The apparatus of Claim 12, wherein the means for mapping data access definitions, style sheets and dynamic content definitions is performed dynamically by a page request object handler.
15. The apparatus of Claim 14, wherein the means for mapping data access definitions, style sheets and dynamic content definitions further comprises: means for mapping the correspondences between data access definitions, style sheets and dynamic content definitions and XML fields and formats at design time and storing the mapping results in the database; and means for using the page request object handler to apply the mapping results when the virtual display document is served.
16. The apparatus of Claim 15 wherein the means for mapping the correspondences is a visual mapper.
PCT/US2000/024695 1999-09-09 2000-09-08 Virtual server system for dynamic content in world wide web pages WO2001018656A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU71264/00A AU7126400A (en) 1999-09-09 2000-09-08 Virtual server system for dynamic content in world wide web pages

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US39299599A 1999-09-09 1999-09-09
US09/392,995 1999-09-09

Publications (1)

Publication Number Publication Date
WO2001018656A1 true WO2001018656A1 (en) 2001-03-15

Family

ID=23552864

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2000/024695 WO2001018656A1 (en) 1999-09-09 2000-09-08 Virtual server system for dynamic content in world wide web pages

Country Status (2)

Country Link
AU (1) AU7126400A (en)
WO (1) WO2001018656A1 (en)

Cited By (34)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002082326A2 (en) * 2001-04-09 2002-10-17 Xmlcities, Inc. Extensible stylesheet designs using meta-tag information
GB2381340A (en) * 2001-10-27 2003-04-30 Hewlett Packard Co Document generation in a distributed information network
WO2003102819A1 (en) * 2002-05-31 2003-12-11 Myers Robert T Computer-based method for conveying interrelated textual and image information
US7246324B2 (en) * 2002-05-23 2007-07-17 Jpmorgan Chase Bank Method and system for data capture with hidden applets
US7536433B2 (en) 2002-09-25 2009-05-19 Jpmorgan Chase Bank, N.A. System and method for customizing a portal environment
US7685013B2 (en) 1999-11-04 2010-03-23 Jpmorgan Chase Bank System and method for automatic financial project management
US7689504B2 (en) 2001-11-01 2010-03-30 Jpmorgan Chase Bank, N.A. System and method for establishing or modifying an account with user selectable terms
US7703009B2 (en) 2001-04-09 2010-04-20 Huang Evan S Extensible stylesheet designs using meta-tag information
US7756816B2 (en) 2002-10-02 2010-07-13 Jpmorgan Chase Bank, N.A. System and method for network-based project management
US7783578B2 (en) 2001-09-21 2010-08-24 Jpmorgan Chase Bank, N.A. System for providing cardless payment
US7823164B2 (en) 2007-06-01 2010-10-26 Microsoft Corporation Automated generation of different script versions
US7941533B2 (en) 2002-02-19 2011-05-10 Jpmorgan Chase Bank, N.A. System and method for single sign-on session management without central server
US7966496B2 (en) 1999-07-02 2011-06-21 Jpmorgan Chase Bank, N.A. System and method for single sign on process for websites with multiple applications and services
US7987501B2 (en) 2001-12-04 2011-07-26 Jpmorgan Chase Bank, N.A. System and method for single session sign-on
US8160960B1 (en) 2001-06-07 2012-04-17 Jpmorgan Chase Bank, N.A. System and method for rapid updating of credit information
US8185940B2 (en) 2001-07-12 2012-05-22 Jpmorgan Chase Bank, N.A. System and method for providing discriminated content to network users
US8185877B1 (en) 2005-06-22 2012-05-22 Jpmorgan Chase Bank, N.A. System and method for testing applications
US8190893B2 (en) 2003-10-27 2012-05-29 Jp Morgan Chase Bank Portable security transaction protocol
US8301493B2 (en) 2002-11-05 2012-10-30 Jpmorgan Chase Bank, N.A. System and method for providing incentives to consumers to share information
US8335855B2 (en) 2001-09-19 2012-12-18 Jpmorgan Chase Bank, N.A. System and method for portal infrastructure tracking
US8438086B2 (en) 2000-06-12 2013-05-07 Jpmorgan Chase Bank, N.A. System and method for providing customers with seamless entry to a remote server
US8473735B1 (en) 2007-05-17 2013-06-25 Jpmorgan Chase Systems and methods for managing digital certificates
US8571975B1 (en) 1999-11-24 2013-10-29 Jpmorgan Chase Bank, N.A. System and method for sending money via E-mail over the internet
US8793490B1 (en) 2006-07-14 2014-07-29 Jpmorgan Chase Bank, N.A. Systems and methods for multifactor authentication
US8849716B1 (en) 2001-04-20 2014-09-30 Jpmorgan Chase Bank, N.A. System and method for preventing identity theft or misuse by restricting access
US9043691B2 (en) 2005-02-28 2015-05-26 James Monro Productions Inc. Method and apparatus for editing media
US9374366B1 (en) 2005-09-19 2016-06-21 Jpmorgan Chase Bank, N.A. System and method for anti-phishing authentication
US9419957B1 (en) 2013-03-15 2016-08-16 Jpmorgan Chase Bank, N.A. Confidence-based authentication
US9608826B2 (en) 2009-06-29 2017-03-28 Jpmorgan Chase Bank, N.A. System and method for partner key management
US10148726B1 (en) 2014-01-24 2018-12-04 Jpmorgan Chase Bank, N.A. Initiating operating system commands based on browser cookies
US10185936B2 (en) 2000-06-22 2019-01-22 Jpmorgan Chase Bank, N.A. Method and system for processing internet payments
US10275780B1 (en) 1999-11-24 2019-04-30 Jpmorgan Chase Bank, N.A. Method and apparatus for sending a rebate via electronic mail over the internet
US10726417B1 (en) 2002-03-25 2020-07-28 Jpmorgan Chase Bank, N.A. Systems and methods for multifactor authentication
US10970778B1 (en) 2013-03-13 2021-04-06 Jpmorgan Chase Bank, N. A. System and method for using a financial services website

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5748188A (en) * 1995-10-12 1998-05-05 Ncr Corporation Hypertext markup language (HTML) extensions for graphical reporting over an internet
US5870746A (en) * 1995-10-12 1999-02-09 Ncr Corporation System and method for segmenting a database based upon data attributes
US5983267A (en) * 1997-09-23 1999-11-09 Information Architects Corporation System for indexing and displaying requested data having heterogeneous content and representation
US6012071A (en) * 1996-01-29 2000-01-04 Futuretense, Inc. Distributed electronic publishing system
US6035119A (en) * 1997-10-28 2000-03-07 Microsoft Corporation Method and apparatus for automatic generation of text and computer-executable code
US6067559A (en) * 1998-04-23 2000-05-23 Microsoft Corporation Server architecture for segregation of dynamic content generation applications into separate process spaces

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5748188A (en) * 1995-10-12 1998-05-05 Ncr Corporation Hypertext markup language (HTML) extensions for graphical reporting over an internet
US5870746A (en) * 1995-10-12 1999-02-09 Ncr Corporation System and method for segmenting a database based upon data attributes
US6012071A (en) * 1996-01-29 2000-01-04 Futuretense, Inc. Distributed electronic publishing system
US5983267A (en) * 1997-09-23 1999-11-09 Information Architects Corporation System for indexing and displaying requested data having heterogeneous content and representation
US6035119A (en) * 1997-10-28 2000-03-07 Microsoft Corporation Method and apparatus for automatic generation of text and computer-executable code
US6067559A (en) * 1998-04-23 2000-05-23 Microsoft Corporation Server architecture for segregation of dynamic content generation applications into separate process spaces

Cited By (51)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7966496B2 (en) 1999-07-02 2011-06-21 Jpmorgan Chase Bank, N.A. System and method for single sign on process for websites with multiple applications and services
US7685013B2 (en) 1999-11-04 2010-03-23 Jpmorgan Chase Bank System and method for automatic financial project management
US8571975B1 (en) 1999-11-24 2013-10-29 Jpmorgan Chase Bank, N.A. System and method for sending money via E-mail over the internet
US10275780B1 (en) 1999-11-24 2019-04-30 Jpmorgan Chase Bank, N.A. Method and apparatus for sending a rebate via electronic mail over the internet
US8438086B2 (en) 2000-06-12 2013-05-07 Jpmorgan Chase Bank, N.A. System and method for providing customers with seamless entry to a remote server
US8458070B2 (en) 2000-06-12 2013-06-04 Jpmorgan Chase Bank, N.A. System and method for providing customers with seamless entry to a remote server
US10185936B2 (en) 2000-06-22 2019-01-22 Jpmorgan Chase Bank, N.A. Method and system for processing internet payments
US8484552B2 (en) 2001-04-09 2013-07-09 Parc Acquisitions LLC Extensible stylesheet designs using meta-tag information
WO2002082326A3 (en) * 2001-04-09 2003-08-21 Xmlcities Inc Extensible stylesheet designs using meta-tag information
US7703009B2 (en) 2001-04-09 2010-04-20 Huang Evan S Extensible stylesheet designs using meta-tag information
WO2002082326A2 (en) * 2001-04-09 2002-10-17 Xmlcities, Inc. Extensible stylesheet designs using meta-tag information
US8849716B1 (en) 2001-04-20 2014-09-30 Jpmorgan Chase Bank, N.A. System and method for preventing identity theft or misuse by restricting access
US10380374B2 (en) 2001-04-20 2019-08-13 Jpmorgan Chase Bank, N.A. System and method for preventing identity theft or misuse by restricting access
US8160960B1 (en) 2001-06-07 2012-04-17 Jpmorgan Chase Bank, N.A. System and method for rapid updating of credit information
US8185940B2 (en) 2001-07-12 2012-05-22 Jpmorgan Chase Bank, N.A. System and method for providing discriminated content to network users
US8335855B2 (en) 2001-09-19 2012-12-18 Jpmorgan Chase Bank, N.A. System and method for portal infrastructure tracking
US7783578B2 (en) 2001-09-21 2010-08-24 Jpmorgan Chase Bank, N.A. System for providing cardless payment
US9646304B2 (en) 2001-09-21 2017-05-09 Jpmorgan Chase Bank, N.A. System for providing cardless payment
GB2381340A (en) * 2001-10-27 2003-04-30 Hewlett Packard Co Document generation in a distributed information network
WO2003038658A3 (en) * 2001-10-27 2004-03-11 Hewlett Packard Co Dynamic workflow document generation
WO2003038658A2 (en) * 2001-10-27 2003-05-08 Hewlett-Packard Company Dynamic workflow document generation
US7689504B2 (en) 2001-11-01 2010-03-30 Jpmorgan Chase Bank, N.A. System and method for establishing or modifying an account with user selectable terms
US8732072B2 (en) 2001-11-01 2014-05-20 Jpmorgan Chase Bank, N.A. System and method for establishing or modifying an account with user selectable terms
US8145522B2 (en) 2001-11-01 2012-03-27 Jpmorgan Chase Bank, N.A. System and method for establishing or modifying an account with user selectable terms
US7987501B2 (en) 2001-12-04 2011-07-26 Jpmorgan Chase Bank, N.A. System and method for single session sign-on
US7941533B2 (en) 2002-02-19 2011-05-10 Jpmorgan Chase Bank, N.A. System and method for single sign-on session management without central server
US10726417B1 (en) 2002-03-25 2020-07-28 Jpmorgan Chase Bank, N.A. Systems and methods for multifactor authentication
US7246324B2 (en) * 2002-05-23 2007-07-17 Jpmorgan Chase Bank Method and system for data capture with hidden applets
US6892352B1 (en) 2002-05-31 2005-05-10 Robert T. Myers Computer-based method for conveying interrelated textual narrative and image information
WO2003102819A1 (en) * 2002-05-31 2003-12-11 Myers Robert T Computer-based method for conveying interrelated textual and image information
US7536433B2 (en) 2002-09-25 2009-05-19 Jpmorgan Chase Bank, N.A. System and method for customizing a portal environment
US7756816B2 (en) 2002-10-02 2010-07-13 Jpmorgan Chase Bank, N.A. System and method for network-based project management
US8301493B2 (en) 2002-11-05 2012-10-30 Jpmorgan Chase Bank, N.A. System and method for providing incentives to consumers to share information
US8190893B2 (en) 2003-10-27 2012-05-29 Jp Morgan Chase Bank Portable security transaction protocol
US9043691B2 (en) 2005-02-28 2015-05-26 James Monro Productions Inc. Method and apparatus for editing media
US8185877B1 (en) 2005-06-22 2012-05-22 Jpmorgan Chase Bank, N.A. System and method for testing applications
US9661021B2 (en) 2005-09-19 2017-05-23 Jpmorgan Chase Bank, N.A. System and method for anti-phishing authentication
US9374366B1 (en) 2005-09-19 2016-06-21 Jpmorgan Chase Bank, N.A. System and method for anti-phishing authentication
US10027707B2 (en) 2005-09-19 2018-07-17 Jpmorgan Chase Bank, N.A. System and method for anti-phishing authentication
US8793490B1 (en) 2006-07-14 2014-07-29 Jpmorgan Chase Bank, N.A. Systems and methods for multifactor authentication
US9679293B1 (en) 2006-07-14 2017-06-13 Jpmorgan Chase Bank, N.A. Systems and methods for multifactor authentication
US9240012B1 (en) 2006-07-14 2016-01-19 Jpmorgan Chase Bank, N.A. Systems and methods for multifactor authentication
US8473735B1 (en) 2007-05-17 2013-06-25 Jpmorgan Chase Systems and methods for managing digital certificates
US7823164B2 (en) 2007-06-01 2010-10-26 Microsoft Corporation Automated generation of different script versions
US9608826B2 (en) 2009-06-29 2017-03-28 Jpmorgan Chase Bank, N.A. System and method for partner key management
US10762501B2 (en) 2009-06-29 2020-09-01 Jpmorgan Chase Bank, N.A. System and method for partner key management
US10970778B1 (en) 2013-03-13 2021-04-06 Jpmorgan Chase Bank, N. A. System and method for using a financial services website
US10339294B2 (en) 2013-03-15 2019-07-02 Jpmorgan Chase Bank, N.A. Confidence-based authentication
US9419957B1 (en) 2013-03-15 2016-08-16 Jpmorgan Chase Bank, N.A. Confidence-based authentication
US10148726B1 (en) 2014-01-24 2018-12-04 Jpmorgan Chase Bank, N.A. Initiating operating system commands based on browser cookies
US10686864B2 (en) 2014-01-24 2020-06-16 Jpmorgan Chase Bank, N.A. Initiating operating system commands based on browser cookies

Also Published As

Publication number Publication date
AU7126400A (en) 2001-04-10

Similar Documents

Publication Publication Date Title
WO2001018656A1 (en) Virtual server system for dynamic content in world wide web pages
US7165073B2 (en) Dynamic, hierarchical data exchange system
US8484552B2 (en) Extensible stylesheet designs using meta-tag information
JP4264118B2 (en) How to configure information from different sources on the network
US6484149B1 (en) Systems and methods for viewing product information, and methods for generating web pages
US7747610B2 (en) Database system and methodology for processing path based queries
US7895516B2 (en) Document assembly system
US8484210B2 (en) Representing markup language document data in a searchable format in a database system
TW501033B (en) Electronic shopping agent which is capable of operating with vendor sites which have disparate formats
US20030135825A1 (en) Dynamically generated mark-up based graphical user interfaced with an extensible application framework with links to enterprise resources
US20030149934A1 (en) Computer program connecting the structure of a xml document to its underlying meaning
US20050198567A1 (en) Web navigation method and system
US20080072140A1 (en) Techniques for inducing high quality structural templates for electronic documents
US6569208B2 (en) Method and system for representing a web element for storing and rendering into other formats
US20040187090A1 (en) Method and system for creating interactive software
WO2002061622A9 (en) Technique for encapsulating a query definition
US20180165253A1 (en) Information architecture for the interactive environment
US20040019589A1 (en) Driver for mapping standard database queries and commands to markup language documents
JP2002251388A (en) Generalizer system and method
WO2001018630A2 (en) Xml dynamic content retrieval using style and content definition sheets
US20070094289A1 (en) Dynamic, hierarchical data exchange system
WO2001018657A1 (en) Dynamic content identifier for xml web pages
Yu et al. Metadata management system: design and implementation
JP2003281149A (en) Method of setting access right and system of structured document management
EP1014283A1 (en) Intranet-based cataloguing and publishing system and method

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP