Relevant excerpt from the patent specification.
FIG. 9 depicts the end result of the process in FIG. 8: a basic UAML-enabled web page as displayed in a typical browser, such as Netscape or Internet Explorer. A link 901 to the UET Company through which the UET system is made possible is provided, as well as a link 902 to the UET Company web page that corresponds to the user’s listing, e.g., FIG. 27 (a listing that is not an auction will be represented on the UET site by a page that is similar to that depicted in FIG. 27 in that it displays information drawn from the UET Company database records pertaining to the given listing except that no data entry fields through which a bid can be submitted appear in the page, being unnecessary to a non-auction listing). The listing user, identified by a registered user ID 908, has specified that payment will be processed through the UET Company 903. A link to the web page on the UET Company site through which a bidder can place a bid is also provided; such a web page is depicted in FIG. 27. Five URLIT enabled images–time remaining 910, sellers feedback rating and bond margin gauge 909, current high bidder 907, current high bid 904, and number of bids 905–also appear in the listing document, along with an item description and other information. An excerpt from the source code of the web page depicted in FIG. 9 appears in FIG. 11; such a document 1101, as is plain, includes both HTML tags and UAML tags. The disclosed UAML system takes advantage of the standard Web browser practice of ignoring unrecognized tags, so that the UAML functionality can be added to a web page without the appearance of the page being affected. The user ID of the seller 908 appears next to the feedback rating image 909, and a link 906 to a bid page 1001 appear in the listing page 900.
Note that the UAML tags describe only parts of the data, namely, that which is to be extracted for replication in the UET Company databases. Thus, much of the data in the document is “invisible” from a UAML perspective, just as the UAML tags themselves are ignored by a Web browser when displaying this page as shown in FIG. 9. By design, however, the data that is described within UAML tags also appears in some form in the web page as displayed by browser. UAML-tagged text is text that is also displayed as text in the browser, and the UAML-tagged image files are displayed as images in the Web browser. In other words, not all data that is relevant from an HTML perspective is relevant from a UAML perspective, but most if not all data that is relevant from a UAML perspective is also relevant from an HTML perspective in this document. Such is the preferred relationship between UAML data and HTML data; preferably, UAML tags should not include attributes, for instance. Data to be captured by a UAML parser should be visible through the Web browser so as to minimize the likelihood of a discrepancy between crucial information seen by a website visitor and that “seen” by a UAML parser. Thus, for instance, a validating UAML parser may be configured to ignore any UAML tags appearing in HTML “comment” tags, since the data within such tags may be ignored by a Web browser in displaying the document.
Since the web page 900 is hosted on the user’s website–either on a computer owned and operated by the user or one which belongs to the website hosting company from which the user rents Web space–and therefore under control of the user, the user can modify the appearance of the web page 900 to suit his or her business branding needs and personal aesthetic preferences so long as the UAML standards for validity of a document are not violated. Such complete user control of the appearance of an auction listing is not possible under the related art systems in which the appearance of auction listings is set by the auctioneer.
While the web page is static, the image files serve as dynamically changing indicators by virtue of the process depicted in FIG. 18A, producing the effect depicted in FIG. 17. When a listing is made active 1801, the relevant fields of the database record in the auction listings database in the UET Company relational database complex are queried to retrieve the current values of the fields 1802.
Specifically, the current high bid field, the current high bidder field, and the other fields which can change during the course of the auction are queried, and the current values of each of these fields is converted to an image file 1803. Each resulting image is named per the URLIT filename step described above and stored at the appropriate image location 1804 so that when the user’s auction listing web page is requested 1805, these dynamically updated images are returned for display in the requesting browser 1806.
Whenever a new bid is submitted, data in the relevant fields changes 1808. When the data in these fields changes, these fields are queried 1802, and a new image is created displaying the new value of the data in each of the relevant fields 1803. The old image is overwritten with the new image 1804 using the same file name and location. The process is repeated until the listing is no longer active 1807. For illustration, FIG. 18B depicts an image file 1813 (e.g., jpg or gif file) which displays the value of the current high bid field at time 1. After a higher bid has been submitted (time 2), the value of the current high bid field changes and a new image 1814 is created and replaces the old image 1813.
The net effect is that the features of a dynamically generated web page can be replicated through a static web page. As shown in FIG. 17, the static web page 1701 is hosted on the user’s website host servers 1704, while each image 1702 serving as a variable real-time indicator is hosted on the UET Company’s servers 1703. This image file is overwritten with a new image at the same file location each time the information it portrays changes as per the process depicted in FIG. 18A. Thus, each time the static web page is requested, the latest value represented by the image is presented to the user. The user cannot control the content of the image or delete the image 1702, since it is hosted on the UET Company’s servers 1703. Also, while the information appears in an image file 1702 in the web page itself 1701, the underlying data is still stored as a value by the UET Company, a more searchable form.
FIG. 12A depicts the initial validation process used during the basic listing process of FIG. 6A to determine whether the listing submission is accepted or rejected 621. Specifically, UET Company software requests the file located at the submitted URL 1201. If the page is found 1202, then the document is parsed and compared to the standards for well-formed UAML 1203, which includes syntactical requirements as well as the requirement that a URLIT be present in the document and tagged as such. If well-formed 1204, the document is then compared to the LTD for the specified type of listing 1205. If the document is valid 1206 under the given LTD, the security check process of FIG. 12B is performed 1207. If the security check passes 1208, then the registered user account of the submitting user is compared 1211 to the minimum standards for acceptance of a listing 1212. For instance, if the submitting user currently has a past due balance owed to the Company or is otherwise delinquent in his or her responsibilities to the UET Company or another registered user, his or her submission will be rejected 1209. If all facets of the validation process are passed, then the listing is accepted 1210.
FIG. 12B depicts the UAML security check process used 1207 in the initial validation process of FIG. 12A. First, the URLIT appearing in the submitted web page is compared to the active URLITs in the UET Company databases 1221. If the URLIT in the submitted page is existent and active (e.g., not expired) 1222, the URLIT is compared to registered URL information in the UET Company databases 1223. If the web page in which the URLIT is being used appears at the same URL for which the given URLIT was issued 1224, then the user ID specified as that of the lister in the listing is compared to the user ID associated with the registered user account to which the URL is registered 1225. If the lister matches 1226, then the image names and locations in the web page are compared to the image names and locations associated with the given URLIT 1229 if applicable. If any security comparison fails, the security check fails 1227. If all succeed, the security check passes 1230.
back to financial services