US20080288459A1 - Web page transcoding method and system applying queries to plain text - Google Patents

Abstract

Signature schema documents, pre-defined in a query language, provide one or more instructions for application by an engine to transcode plain text-based web pages of respective web sites. The instructions identify a web page family for the web page and extract a subset of data using one or more signatures previously identified within web pages of the same web page family of the web site. The engine interprets the instructions to search the web page text for signatures to locate and extract the subset of data. Each signature may comprise at least one text string within the code of the web page. Directional references indicate positions of the subset of data relative to the location of the text strings and direct the searching. Transcoding may facilitate use of e-commerce web sites by wireless mobile devices.

Description

CROSS REFERENCE
• This application claims the benefit of the prior filing of U.S. Provisional Patent Application Ser. No. 60/924,503 filed May 17, 2007, the disclosure of which is incorporated herein by reference.
COPYRIGHT
• A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights.
FIELD
• The present application relates generally to telecommunications and more particularly to a system and method for transcoding web pages.
BACKGROUND
• Web sites host and provide information using web pages that are communicated electronically via a telecommunications network. Accessing this information by some client computing devices can be challenging. Computing devices are becoming smaller and increasingly utilize wireless connectivity. Examples of such computing devices include portable computing devices that include wireless network browsing capability as well as telephony and personal information management capabilities.
BRIEF DESCRIPTION OF THE DRAWINGS
• FIG. 1 is schematic representation of a system for content navigation.
• FIG. 2 is a schematic representation of a wireless communication device fromFIG. 1.
• FIG. 3 illustrates a flow of interactions among components of the system ofFIG. 1.
• FIG. 4 is a schematic representation of a system for content navigation in accordance with another embodiment.
• FIG. 5 illustrates a flow of interactions among components of the system ofFIG. 4.
• FIGS. 6A-6D and7A-7D respectively illustrate representative web pages rendered on a first browser window and portions of said representative web pages transcoded and rendered on a second browser window in accordance with an embodiment.
DETAILED DESCRIPTION OF THE EMBODIMENTS
• The smaller size of most wireless mobile client devices necessarily limits their display capabilities. Furthermore the wireless connections to such devices typically have less or more expensive bandwidth than corresponding wired connections. The Wireless Application Protocol (“WAP”) was designed to address such issues, but WAP can still provide a very unsatisfactory experience or even completely ineffective experience, particularly where the small client device needs to effect a connection with web sites that host web pages that are directed to traditional full desktop browsers.
• Signature schema documents, pre-defined in a query language, provide one or more instructions for application by an engine to transcode plain text-based web pages of respective web sites. The instructions identify a web page family for the web page and extract a subset of data using one or more signatures previously identified within web pages of the same web page family of the web site. The engine interprets the instructions to search the web page text for signatures to locate and extract the subset of data. Each signature may comprise at least one text string within the code of the web page. Directional references indicate positions of the subset of data relative to the location of the text strings and direct the searching. Transcoding may facilitate use of e-commerce web sites by wireless mobile devices.
• In accordance with an aspect there is provided a method of transcoding a web page of a web site. The method comprises: receiving a web page comprising plain text; and applying a signature schema comprising one or more instructions to locate and extract a subset of data from the plain text using one or more signatures previously identified within plain text of one or more web pages of a same web page family of the web site. The web page may comprise code in a markup language; and each of the one or more signatures may comprise at least one text string reference for locating within the code. At least some of the one or more instructions may establish a start limit defined using a start text string reference, whereby characters in the text of the received web page before the start limit are ignored when locating and extracting the subset of data; and at least some of the one or more instructions may establish an end limit defined using an end text string reference, whereby characters in the text of the received web page after the end limit are ignored when locating and extracting the subset of data.
• The subset of data may comprise a plurality of elements for an object and its attributes within the web page. Each element may comprise text data that is located and extracted by respective one or more instructions. The respective one or more instructions to extract a particular element may comprise a respective text reference with which to locate the particular element. The respective one or more instructions to extract a particular element further comprise: a directional reference relative to the text reference to direct a search for the text data; and at least one of: i) a start reference comprising a start text string; or ii) an end reference comprising an end text string, the start reference and end reference respectively indicating a starting location and ending location for the text data. The one or more instructions may comprise at least one text manipulation command for manipulating the extracted text data.
• The one or more instructions may be interpreted by a transcoding engine component of a computing device configured for transcoding web pages to a target format. The web site may comprise an e-commerce web site and the web pages may be for conducting a transaction. The target format may be suitable for use by a wireless mobile device.
• The method may further comprise transcoding in a target format the subset of data extracted in accordance with the one or more instructions, thereby providing a transcoded web page.
• In another aspect, there is provided a computing device for transcoding a web page of a web site. The computing device comprises a processor and a memory coupled thereto, said memory storing instructions and data configuring the processor to provide a transcoding engine to: receive a web page comprising plain text; and apply a signature schema comprising one or more schema instructions to locate and extract a subset of data from the plain text using one or more signatures previously identified within plain text of web pages of a same web page family of the web site.
• In another aspect there is provided a computer program product storing computer readable instructions which when executed by a computer processor configure the computer processor to: receive a web page comprising plain text; and apply a signature schema comprising one or more schema instructions to locate, extract and transcode a subset of data from the plain text using one or more signatures previously identified within plain text of web pages of a same web page family of the web site, thereby to transcode the web page.
• In another aspect there is provided a system for transcoding web pages of a web site. The system comprises a web server serving said web pages; at least one client machine configured to utilize transcoded web pages; a gateway coupled between the web server and the at least one client machine via a telecommunication network, said gateway proxying respective requests for web pages from the at least one client machine and responding with transcoded web pages; said gateway configured with a transcoding engine to: receive a web page comprising plain text; and apply a signature schema comprising one or more schema instructions to locate and extract a subset of data from the plain text using one or more signatures previously identified within plain text of web pages of a same web page family of the web site.
• In another aspect there is provided a method of conducting an e-commerce transaction between a wireless mobile device and an e-commerce web site. The method comprises obtaining a signature schema comprising one or more schema instructions to locate, extract and transcode a subset of data from plain text of a web page using one or more signatures previously identified within the plain text of web pages of a same web page family of the e-commerce web site, thereby to transcode the web page; receiving at least one web page from the e-commerce web site comprising plain text for conducting the transaction; and transcoding at least some of the web pages received in accordance with the signature schema to conduct the transaction.
• Referring now toFIG. 1, there is illustrated asystem100 for content navigation via a telecommunications network. In apresent embodiment system100 comprises a plurality of client computing devices in the form ofclient machines102A and102B (collectively102), aweb site server106 hosting aweb site104 and a gateway andschema server120.Devices102 are respectively coupled to communicate with gateway andschema server120 to obtain web pages (e.g.110) transcoded fromweb site104.
• In the present embodiment, aweb server106 comprisesweb site104 serving web pages (e.g.110) defined from a plurality of webpage family templates108A-108D (collectively108) and web page content (described further herein below) fromdata store112. For ease within the present embodiment, only asingle web site104 is shown coupled via gateway andschema server120; however, in another embodiment a plurality of different web sites may be so coupled. In the present embodiment ofsystem100, gateway andschema server120 is coupled to aschema repository124 from which to obtain asignature schema122 for a particular web site. Signature schema documents (e.g.122) provide instructions and data with which anengine140 ofserver120 can extract data from web pages (e.g.110) and transcode same to a target format to provide transcoded web page data (e.g.130 and132) to the respective requestingclient machines102A and102B as described more fully below. Gateway andschema server120 may also be coupled to adatabase126 for retrieving/storing data extracted from web sites in accordance with its operations. Thedatabase126 may be a relational database storing extracted data from web sites in relation to the defined signature schema. The stored data can be accessed by a Structured Query Language (SQL). Signature schemas for respective web sites may be defined (e.g. coded) using acomputing device128 as described herein below.
• Representative client machines102 include any type of computing or electronic device that can be used to communicate and interact with content available via web sites. Each of theclient machines102 may be operated by a respective user U (not shown). Interaction with a particular user includes presenting information on a client machine (e.g. by rendering on a display screen) as well as receiving input at a client machine (e.g. such as via a keyboard for transmitting to a web site). In the present embodiment,client machine102A comprises a mobile electronic device with the combined functionality of a personal digital assistant, cell phone, email paging device, and a web-browser. Such a mobile electronic device may comprise a keyboard (or other input device(s)), a display screen, a speaker, (and other output device(s) (e.g. LEDs)) and a chassis for housing such components. The chassis may further house one or more central processing units, volatile memory (e.g. random access memory), persistent memory (e.g. Flash read only memory) and network interfaces to allowclient machine102A to communicate over the telecommunication network.
• Referring now toFIG. 2, a schematic block diagram shows anexemplary client machine102A in greater detail. It should be emphasized that the structure inFIG. 2 is purely exemplary, and contemplates a device that may be used for both wireless voice (e.g. telephony) and wireless data (e.g. email, web browsing, text) communications.Client machine102A includes a plurality of input devices which in a present embodiment includes a keyboard and, typically, additional input buttons, collectively200, an optional pointing device202 (e.g. a trackball or trackwheel) and amicrophone204. Other input devices, such as a touch screen, and camera lens are also contemplated. Input from keyboard/buttons200, pointingdevice202 andmicrophone204 may be received at aprocessor208.Processor208 may be further operatively coupled with a non-volatile storage unit212 (e.g. read only memory (“ROM”), Erasable Electronic Programmable Read Only Memory (“EEPROM”), or Flash Memory) and a volatile storage unit216 (e.g. random access memory (“RAM”),speaker220,display screen224 and one or more lights (LEDs222).Processor208 may be operatively coupled for network communications via asubsystem226. Wireless communications are effective via at least one radio (e.g.228) such as for Wi-Fi or cellular wireless communications.Client machine102A also may be configured for wired communications such as via a USB or other port and for short range wireless communications such as via a Bluetooth® radio (all not shown).
• Programming instructions that implement the functional teachings ofclient machine102A as described herein are typically maintained, persistently, innon-volatile storage unit212 and used byprocessor208 which makes appropriate utilization ofvolatile storage216 during the execution of such programming instructions. Of particular note is thatnon-volatile storage unit212 persistently maintains aweb browser application86 and, in the present embodiment, anative menu application82, each of which can be executed onprocessor208 making use ofvolatile storage216 as appropriate. An operating system and various other applications (not shown) are maintained innon-volatile storage unit212 according to the desired configuration and functioning ofclient machine102A, one specific non-limiting example of which is a contact manager application (also known as an address book, not shown) which stores a list of contacts, addresses and phone numbers of interest to user U and allows user U to view, update, and delete those contacts, as well as providing user U an option to initiate telecommunications (e.g. telephone, email, instant message (IM), short message service (SMS)) directly from that contact manager application.
• Native menu application82 may be configured to provide menu choices to user U according to the particular application (or other context) that is being accessed. By way of example, while user U is activating the contact manager application, user U can activatemenu application82 to access a plurality of menu choices available that are respective to contact manager application90. For example, menu choices may include options to invoke other applications (e.g. a mapping application to map a contact's address) or communication functions (e.g. call, SMS, IM, email, etc.) on theclient machine102A for a particular contact.Menu application82 may be associated to a particular input button (e.g. one of buttons200) and invoked to provide a contextual menu comprised of a plurality of menu choices that are reflective of the context in which thebutton200 was selected. Note that the options in a contextual menu are stored withinnon-volatile storage212 as being specifically associated with a respective application.Menu application82 may be therefore configured to generate a plurality of different contextual menus that are reflective of the particular context in which themenu application82 is invoked. For example, in an email application where an email is being composed, invokingmenu application82 would generate a contextual menu that included the options of sending the email, cancelling the email, adding addresses to the email, adding attachments, and the like. The contents for such a contextual menu would also be maintained innon-volatile storage212. Other examples of contextual menus will occur to those of ordinary skill in the art.
• As noted, gateway andschema server120 applies a signature schema to transcode a web page and provide transcoded data to a requestingclient machine102.Signature schema122 may be configured to transcode navigational features of aweb site104 to provide menu options tomenu application82 for use when browsing theweb site104 withbrowser86. The signature schema may further transcode web site content for presentation by thebrowser86.
• FIGS. 6A-6D and7A-7D respectively illustrate representative web pages rendered on a first browser window and portions of a subset of data from said representative web pages transcoded and rendered on a second browser window in accordance with an embodiment.FIG. 6A illustrates a representativehome web page660A of an e-commerce web site (e.g.104) in abrowser window650.Window650 is illustrative of a rendering to a large size display device (e.g. desktop monitor).Web page660A comprises, among other things, amenu portion652 and a primarycontent display portion654, in the example, showingvarious advertisements655 for products.
• FIG. 7A illustrates themenu portion652 extracted and transcoded and rendered as a web page on asecond browser window750.Window750 is illustrative of a rendering to a small size display device (e.g. of a wireless mobile device). In addition to transcoding as a web page,menu portion652 may be transcoded formenu application82 e.g. for invocation when browsing thesite104 as referenced further herein.
• FIG. 6B illustrates an exemplaryproduct web page660B inwindow650 showing various product data (collectively666) includingimage666A, price666,title666C anddescription666D data that is transcoded and shown inwindow750 ofFIG. 7B. Also transcoded is the webpage hierarchy list668 showing where the page is on the web site.
• FIG. 6C illustrates an exemplary productlist web page660C inwindow650 showing a list of products (collectively670). A subset of the product data such asimage670A,price670B, andtitle670C is transcoded and shown inwindow750 ofFIG. 7C. Note thatmultiple pages672 may be provided for thelist670.
• FIG. 6D illustrates an exemplary account checkout web page660D inwindow650 showing alogin form680 for receiving account login and password, which form is transcoded and shown inwindow750 ofFIG. 7D. Though not shown, other checkout pages (e.g. for payment or order confirmation, etc.), search pages, product and information pages may be similarly transcoded.
• Returning now toFIG. 1,web server106 and gateway and schema server120 (which can, if desired, be implemented on a single server) can be based on any commonly available server environments or platforms including a module that houses one or more central processing units, volatile memory (e.g. random access memory), persistent memory (e.g. hard disk devices) and network interfaces to allowservers106 and120 to communicate over the telecommunications network.Web server106 hosts software applications comprising instructions and data for generating and serving web pages dynamically from thetemplate families108 and current informational content therefore fromdata store112. Load balancing, security/firewall, billing, account and other applications may also be present as is well-known in the art.
• Gateway andschema server120 hosts software applications comprising instructions and data for proxying requests and responses between theclient machines102 andweb site104. In addition to software for maintaining HTTP communications, performing requests, maintaining sessions, handling cookies, etc.,engine140 may be implemented in software to apply the signature schemas to web pages from web sites. There may be provided an interpreter that interprets the signature schema document and applies the actions against the web page code (as an ASCII (plain text) document) to extract the subset of data to produce a result set. A renderer may be provided to express the subset of data result set (i.e. transcode to a target format such as cHTML (Compact HTML) for a mobile device browser) for transmitting to the client machines also in accordance with the signature schema. A cache feature may also be provided for storing/retrieving data fromdatabase126. Caching may comprise storing web pages from the web site as well as extracted data from which to build a relational database of object and elements and their relationships. The gateway and schema server (or a separate server (not shown)) may host a web site engine to provide content extracted from the relational database (e.g. stored web site data) to theclient machines102.
• Devices102,schema server120 andweb site104 are coupled via a telecommunication network (not shown) typically comprising a plurality of interconnected networks that may include wired and (at least fordevice102A) wireless networks. It should now be understood that the nature of the network is not particularly limited and is, in general, based on any combination of architectures that will support interactions betweenclient machines102 andservers106 and120. In a present embodiment the network includes the Internet as well as appropriate gateways and backhauls.
• More specifically, in the present embodiment, a wireless network forclient machine102A may be based on core mobile network infrastructure (e.g. Global System for Mobile communications (“GSM”), Code Division Multiple Access (“CDMA”), Enhanced Data rates for GSM Evolution (“EDGE”), Evolution Data-Optimized (“EV-DO”), High Speed Downlink Packet Access (“HSPDA”), Universal Mobile Telecommunications System (“UMTS”), etc.) or on wireless local area network (“WLAN”) infrastructures such as the Institute for Electrical and Electronic Engineers (“IEEE”)802.11 Standard (and its variants) or Bluetooth or the like or hybrids thereof. In the present embodiment ofsystem100 it is contemplated thatclient machine102B may be another type of client machine such as a PC (desktop or laptop) configured to include a full desktop computer or as a “thin-client”. Typically such have larger display monitors/screens than portable machines like102A. A wired network forsystem100 anddevice102B can be based on a T1, T3 or any other suitable wired connection.
• As previously stated in relation toFIGS. 1 and 2, each of theclient machines102 is configured to interact with content available over the network, including web pages onweb site104. In a present embodiment,client machines102A and102B may navigate for content using a browser application (e.g.86). As will be explained further below, onclient machine102A,browser application86 may be a mini-browser in the sense that it may be configured to render web pages on the relativelysmall display224 ofclient machine102A. Often, during such rendering, those pages are presented in a format that may be different from how those pages are rendered on a traditional desktop browser application (e.g.browser86 ofclient machine102B). Mini-browsers typically attempt to convey substantially the same information as if the web pages had been rendered on a full browser such as Internet Explorer®, Safari® or Firefox® on a traditional desktop or laptop computer likeclient machine102B.
• FIG. 3 is a flowchart illustrating operations/interactions for transcoding a web page (e.g.110) fromweb site104 forclient machine102A, providing an example of the interaction among the gateway andschema server120,client machine102A and theweb site104.Client machine102A makes arequest302 toserver120, acting as a proxy, for a specific web page (e.g.110) from a web site having a specific domain (URL). The gateway andschema server engine140 receives the request and makes acorresponding request304 as a proxy to the web site'sweb server106 for the specified page, receiving308 the web page code (e.g.110) into the engine's (140) memory. The web page code is treated as an ASCII (plain text) file. It typically does not include objects referenced by the code such as images, video, audio, further web pages, etc. that are typically subsequently retrieved and inserted at the time of rendering a web page by a browser.
• The engine140 (for example, in parallel or without waiting for a response from server106) makes arequest306 to thesignature repository124 for thesignature schema document122 for the web site, which request may use the domain in the URL as an identifier for obtaining thedocument122. Theengine140 receives310 the schema. Theengine140 does not render theweb page110 per se but instead uses the instructions in thesignature schema document122 to extract the subset of data from theweb page110 for transcoding. In the presentembodiment signature schema122 is configured to transcode theweb page110 in accordance with the specific characteristics of the requestingclient device102A, having knowledge ofdisplay224 capabilities—such as screen size, resolution, and other parameters—useful in determining the way in which the transcoded data is to be displayed on themachine102A.
• Optionally, theweb page110 or extracted data or both can be stored312 indatabase126.Engine140 transmits314 the transcodeddata130 that has been extracted and transcoded to a target format fromweb page110, in accordance with theschema122, to the requestingclient machine102A. As noted above, transcodeddata130 may comprise transcoded navigational data formenu application82 and informational content data (e.g. a list of products and related information from a web page) for displaying bybrowser application86.
• Signature schemas are pre-defined documents, and may be eXtensible Markup Language (XML) documents utilizing an SQL-like query language, to incorporate instructions and data with which to intelligently extract the data from web pages (which web pages are typically coded in HTML, DHTML, XHTML, XML, RSS, JavaScript, etc). This extracted data may be transcoded and provided toclient machines102, or used to dynamically generate a relational database (e.g.126) or both. Each signature schema incorporates an understanding of a particular web site's data including relationships among the various data (e.g. among its primary informational content found in the body of its web pages as well as among such content and associated navigational data (e.g. web page links) that govern the data in the page). As described further herein below, prior knowledge of the web page code including specific identifiers, tags and text (i.e. strings) used within the code (sometimes referred to as “signatures” herein), may be used to define instructions to identify portions of the code of interest and to extract specific data.
• As a further feature, transcoding may be configured to provide continuity of browsing/transactional/session experience enabling a user to switch client machines (e.g. starting withclient machine102A and switching tomachine102B (or vice-versa)). A user may be enabled to start an interaction with a web site and have displayed data (published content and navigational data) on theclient machine102A. The browsing session may then be continued on a second client machine (102B) while retaining the transcoding as provided to the first client machine. For example, a user on a desktop can continue to browse the published content and navigational data of the web site as previously experienced on a mobile device, using only a portion of the desktop screen (for example) for data display.
• In accordance with the present embodiment, a signature schema document may be defined for all the pages of a particular web site. Large data-driven web sites (e.g.104) don't maintain thousands of individual web pages per se. The sites typically adopt a fewpage family templates108 and dynamically populate these with pertinent content fromdatabase112 comprising information (e.g. weather, stock data, news, shopping/product data, patent data, trade-mark data etc.) as applicable when a client requests a particular page. Each template represents a family of pages having objects and attributes. Below are representative example page family templates and their objects and attributes for a web site offering news and an e-commerce web site offering products for sale electronically:
Example 1News SiteFamily: List Page
• Objects: lists a selection of news stories
  Attributes: Title, abstract and date
  Family: Detail page
  Objects: lists a single news story (and optionally other related stories)
Attributes: Journalist, City, Date, Title, Full Story, ImageExample 2E-Commerce SiteFamily: List Page
• Objects: lists a selection of products
Attributes: Image, Item Name, Price, Sale Price
• Family: Search Page (a specific kind of list page)
  Objects: Similar to a list page
  Attributes: Similar to a list page
• Each family of pages (the family template) can be identified by a “signature” or unique set of one or more features that automatically identifies a given page on a web site as part of the family and differentiates that family from another family of pages. Similarly each object and attribute field of interest can be identified with its respective unique signature within a family of pages. A signature schema document typically comprise numerous pieces of information (commands), for example, information that instructs theengine140 for:
• • identifying all page families;
  • identifying and extracting a subset of data (i.e. desired objects and attributes) for each page family;
  • capturing the (implicit or explicit) relationships between the objects and attributes; and
  • transcoding the data.
• A signature schema document may also be configured to enable special functionality for the target web site including searching, logging in a user, purchasing items, etc.
• In accordance with a present embodiment, the structure and syntax of a representative signature schema document for a representative e-commerce site eshop.ca is shown and described.Engine140 may be configured to receive web page code comprising text data and search through the text in accordance with the schema document instructions that provide SQL-query like language instructions.Engine140 maintains a pointer within the text as it moves through the web page code performing various actions, as described below, in accordance with the schema instructions. Table 1 illustrates a snippet of a representative signature schema:

• TABLE 1
  XML Signature Schema Snippet for E-Shop.ca

  1 <?xml version=“1.0” encoding=“ISO-8859-1” ?>

  2 <site>

  3   <version major=“1” minor=“2”/>

  4   <url location=“http://www.eshop.ca” key=“eshop.ca” name=“E-Shop” />

  5   <advanced>

  6

  7      <index_link value=“http://www.eshop.ca/home.asp” />

  8   </advanced>

  9   <page_type>

  10     <lookup type=“pex” action=“locate_string” name=

  “list_elements” id=“mylist_1” ref=“Compare products”

  alt1=“Sort products” />

  11     <lookup type=“pex” action=“locate_string” name=“item_elements”

  id=“myitem_1” ref=“&quot;product-details&quot;” />

  12     <lookup type=“pex” action=“locate_string” name=“menu_elements”

  id=“mymenu_2” ref=“anc-lhsnav-subItem” />

  13     <lookup type=“pex” action=“locate_string” name=“menu_elements”

  id=“mymenu_1” ref=“product-table” />

  14     <lookup type=“pex” action=“locate_string” name=“item_elements”

  id=“myitem_1” ref=“*” />

  15   </page_type>

  16   <list_elements id=“mylist_1”>

  ...

  17   </list_elements>

  ...

  18   <item_elements id=“myitem_1”>

  19     <actions>

  20       <lookup type=“pex” action=“move_ptr” ref=“&lt;/head&gt;” />

  21     </actions>

  22     <element>

  23       <lookup type=“pex” action=“get_string” name=“image”

  ref=“largeimageref” location=“after” start=“&lt;img

  src=&quot;” end=“&quot;” />

  24       <lookup type=“pex” action=“get_string” name=“title” ref=“product-

  details-prd-title” location=“after” start=“&lt;span”

  end=“&lt;/span&gt;” include_sz=“1” strip_tags=“1” />

  25       <lookup type=“pex” action=“get_string” name=“price”

  ref=“our price:” location=“after” start=“&lt;td”

  end=“&lt;/td&gt;” include_sz=“1” strip_tags=“1” />

  26       <lookup type=“pex” action=“get_string” name=“sale_price”

  ref=“sale price:” location=“after” start=“&lt;td”

  end=“&lt;/td&gt;” include_sz=“1” strip_tags=“1”

  tolerance=“1” />

  27       <lookup type=“pex” action=“get_string” name=“description”

  ref=“detailbox-text” location=“middle” start=“&lt;p”

  end=“&lt;/p&gt;” include_sz=“1” strip_tags=“1” />

  28     </element>

  29   </item_elements>

  ...

• In the XML code snippet of Table 1, instructions atline 4 are for verifying that the web page under consideration and the signature schema relate to the same web site/domain-eshop.ca. Instructions at lines 9-15 are for determining the particular page family to which the web page under consideration belongs. A respective signature that defines the particular page family has been previously identified for use to distinguish the page. Theengine140 processes the <page type> tag by registering the identification strings for each page family. When a web page is obtained by the engine as input, the engine may be able to identify the page family by its unique string ref=” and the command provides the related tag within the signature schema document where further instructions for the particular web pages are found:
• action=“locate_string”: command to check for the existence of a string.
• name=”: identifies the type of page family for each identified family.
  id=”: assigns an id to the page family that is used across the signature schema document.
• For example, at line 10, the instructions identify a web page using the alternative signatures “Compare products” or “Sort Products”. Web pages with these strings are of the same family type. The instructions at line 10 provide a reference tag to further instructions for this family, providing a link to instructions for the list_elements page family with and ID of mylist_—1 (see lines 16-17). Similarly the other lookup instructions provide references to the specific instructions within the signature schema document for handling a web page of each web page family. Representative instructions for some of the web page families are provided in Table 1, for example, at lines 16-17 and 18-29 with others omitted for brevity.
• With reference to the extraction instructions for one of the web page families (e.g. item_elements id=“myitem_—1”) at lines 18-29, the instruction at line 20 advances the scan pointer within the text file of the web page code to a beginning limit of a region of interest indicated by a signature reference. This establishes an upper limit for review within the text file. Though not shown in this table, an end limit may be defined as well (See Table 4). Further such instructions at lines 22-28 may comprise commands to locate the subset of data using “signatures” such as string identifiers that uniquely identify the data within the region of interest. In the present example the instructions locate and extract a plurality of elements, namely, product image, title, price, sale price and description for a product of the item web page family. For example, instructions at line 23 extract a string in between the first “&It;img src=&quot;” and “&quot;” that appears after next appearance of “largeimageref”. The string returned is the path (relative URL at web site eshop.ca) to the product image. By advancing a search scan pointer within the web code to a particular location, references before that location can be skipped when searching. Any prior instances of a signature string such as “largeimageref” may be ignored. In this way, otherwise ambiguous signature references can be avoided.
• The example in Table 1 shows at least some of the instructions (e.g. lines 23-27) including one or more directional references relative to the signatures to locate and extract the subset of data. For example, directional references such as “before” or “after” command the engine to extract the data that is in a relative position in the web page before or after the signature string (i.e. ref=). Moreover, such instructions may further include at least one of a start reference or an end reference further pinpointing the location of the data in accordance with that direction. Additional directional reference information is discussed herein with reference to code snippets in other Tables and the discussion of an embodiment of signature transcoding engine syntax presented below.
• The example within Table 1 demonstrates the extraction of data and the establishment of relationships between objects and elements within a same page of a web site. However, signature schema documents may further capture relevant attributes of an object across pages. For example, a user ofclient machine102A may click through a number of web pages in eshop.ca to get to a specific product page (e.g. Department->Product Category->Product Sub-Category->Specific Product, such as TV & Video>19″-21″ TVs>LCD TVs>BrandX Product. The navigational hierarchy representing a categorization may be captured and associated to the extracted objects and there elements.
• For brevity, certain instructions were omitted from Table 1. Tables 2-4 provide representative instructions for further web page families for e-shop.ca that may be read with Table 1. Table 2 below provides representative instructions, e.g. for lines 16 and 17 of Table 1, including instructions for a web page family related to a list of items/products for sale. Whereas instructions at lines 22-28 provided product data extraction instructions for a web page family showing a single item (i.e. product), the instructions of Table 2 provide additional instructions that repeat product data extractions for each product in the list.

• TABLE 2
  XML Signature Schema Snippet for Product List Web Page Family of E-
  Shop.ca

  1   <list_elements id=“mylist_1”>

  2     <paging>

  3       <page_variable value=“page” />

  4       <page_start value=“0” />

  5       <lookup type=“pex” action=“get_string” name=“link”

  ref=“Next&amp;nbsp” location=“before” start=“&lt;a

  class=” end=“&lt;/a&gt;” include_sz=“1” strip_tags=“1” />

  6     </paging>

  7     <actions>

  8       <lookup type=“pex” action=“move_ptr” ref=“Sort or compare

  products” ref_alt_1=“Sort products” />

  9     </actions>

  10    <element>

  11       <lookup type=“pex” action=“get_string” name=“link” ref=“thumbnail”

  location=“before” start=“&lt;ahref=&quot;” end=“&quot;&gt;”

  />

  12       <lookup type=“pex” action=“get_string” name=“image”

  ref=“thumbnail” location=“middle” start=“&quot;”

  end=“&quot;” />

  13       <lookup type=“pex” action=“get_string” name=“title”

  ref=“class=&quot;tx-strong-dgrey&amp;quot;”

  location=“after” start=“&lt;a href=” end=“&lt;/a&gt;”

  include_sz=“1” strip_tags=“1” />

  14       <lookup type=“pex” action=“get_string” name=“price” ref=“pricepill/”

  location=“after” start=“/” repeat_start=“1” end=“.gif”

  tolerance=“1” />

  15       <lookup type=“pex” action=“move_ptr” ref=“pricepill/” />

  16     </element>

  17   </list_elements>

• If theengine140 identifies that the page is of the “mylist_—1” family, the engine determines the location in the signature schema document that contains the signature for the objects and elements of that family and applies the instructions therefor. A product list at e-shop.ca may span multiple web pages. Instructions at lines 2-6 of Table 2 find the number of pages and generate the links for each of the pages. Instructions at lines 7-9 (action tag) advance the search scan pointer to the region of web page code that may be of interest (i.e. in this case, the start of the list). In this way, a local signature reference can be used and any earlier ambiguous references skipped. Skipping to the local region of interest may also make the specification of the signature reference less complicated.
• Taking advantage of inherent repeated patterns in the web page code, instructions at lines 10-16 (elements tag) of Table 2 provide product data extraction instructions that may be repeated for each product in the list. Theengine140 may be provided with commands to scan for each data element of interest using a signature reference e.g. ref=”, an action, one or more positional instruction(s) to further identify the data within the text of the web page code, and any additional text data manipulation instructions to extract the data (e.g. to remove HTML formatting characters or add characters). The instruction at line 15 moves the scan pointer to the end of the object (in this example a product in a list of products) to ready the instructions for application against the next object (product) in the list.
• More particularly:
• • lookup type=“pex”: string lookup
  • action=“get_string”: returns a value back that is the desired element of the object.
  • name=“link”: the object element, in this case the link to the product page
  • ref=“thumbnail”: the reference string that identifies where to find the value of the link
  • location=“before”: the value of the link is before the ref string
  • start=“&lt;a href=&quot;”: look for the ref string after this value
  • end=“&quot;&gt;”: look for the ref string before this value.

• TABLE 3
  E-Shop Search Family Signature Schema Snippet

  1 <search_elements id=“mysearch_1”>

  2   <settings>

  3     <search_path value=“http://www.eshop.ca/search/search.asp/>

  4     <search_variable value=“keyword” />

  5   </settings>

  6   <paging>

  7      <page_variable value=“page” />

  8      <page_start value=“0” />

  9      <lookup type=“pex” action=“get_string” name=“link” ref=“Next&amp;nbsp”

  location=“before” start=“&lt;a href=” repeat_start=“1”

  end=“&lt;/a&gt;” include_sz=“1” strip_tags=“1” />

  10   </paging>

  11   <actions>

  12     <lookup type=“pex” action=“move_ptr” ref=“bg-compare-hero” />

  13   </actions>

  14   <element>

  15     <lookup type=“pex” action=“get_string” name=“link” ref=“&gt;”

  location=“after” start=“&lt;a href=&quot;” end=“&quot;&gt;” />

  16     <lookup type=“pex” action=“get_string” name=“image” ref=“&lt;a href”

  location=“after” start=“&lt;img src=&quot;” end=“&quot;” />

  17     <lookup type=“pex” action=“get_string” name=“title”

  ref=“class=&quot;tx-strong-dgrey&amp;quot;” location=“after”

  start=“&lt;a href=” end=“&lt;/a&gt;” include_sz=“1” strip_tags=“1” />

  18     <lookup type=“pex” action=“move_ptr” ref=“bg-compare-hero” />

  19   </element>

  20 </search_elements>

• If theengine140 has identified that the page is of the “mysearch_—1” family the engine applies the portion of the signature schema document that contains the signature for the objects and elements of that family, shown above in Table 3.
• <settings> . . . </settings>: Contains any web page specific manual overrides such as excluding certain menu items, customization, modification of a menu that may be desired. In this example, as per line 3 a value of form variable “keyword” will be posted to “http://www.eshop.ca/search/search.asp”.
  <paging> . . . </paging>: Manages paging for the search pages.
  <actions> . . . </actions>: Instruct the engine to move the scan pointer to the string “bg-compare-hero” (line 12 of Table 3) and start looking for elements from there.
  <element> . . . </element>: Contains lookup instructions for each object element as previously described.

• TABLE 4
  E-shop Menu FamilySignature Schema Snippet

  1  <menu_elements id=“mymenu_1”>

  2   <settings>

  3      <black_list value=“Site Index##External Link” />

  4   </settings>

  5   <actions>

  6      <lookup type=“pex” action=“move_ptr” ref=“bg-lhsnav-title” />

  7      <lookup type=“pex” action=“end_ptr” ref=“&lt;/table&gt;” />

  8   </actions>

  9   <element>

  10     <lookup type=“pex” action=“get_string” name=“link” ref=“&lt;li&gt;”

  location=“after” start=“&lt;a href=&quot;” end=“&quot;” />

  11     <lookup type=“pex” action=“get_string” name=“title” ref=“&lt;li&gt;”

  location=“after” start=“&lt;a href=&quot;” end=“&lt;/a&gt;”

  include_sz=“1” strip_tags=“1” />

  12     <lookup type=“pex” action=“move_ptr” ref=“&lt;/li&gt;”/>

  13   </element>

  14 </menu_elements>

• If theengine140 has identified that it is looking for a menu on a page that contains the menu style of the “mymenu_—1” family, the engine applies the portion of the signature schema document that contains the signature for the objects and elements of that family, shown above in Table 4.
• <settings> . . . </settings>: Contains any page specific manual overrides such as exclude list, customization, modification, personalization, etc. In this example, as perline 3, any result that matches “Site Index”, “External Link” are excluded but partial matches are also possible by using wild card strings.
  <action> . . . </action>: Lines 6-7 of Table 4 sets the start and end limits to instruct theengine140 where to look for menu items.
  <element> . . . </element>: Contains lookup instructions for each object element as previously described. In this example, lines 10 and 11 of Table 4, an element inmymenu_—1′ (each individual menu entry of web page) contains link and title as its properties. Line 12 instructs the engine to move the pointer to “&It;/li&gt;” to get ready to loop through and extract the next menu item with the same elements, taking advantage of the repeated patterns within the text of the web page code.
• Though the example described relates to extracting informational content for an e-commerce oriented site, no limitation should be applied. Similar instructions may be defined for other types of sites, for pages which permit a user to input information and for navigational data extraction.
• Signature schema document122 may further comprise transcoding instructions (not shown) for use byengine140 to express the extracted subset of data in a target format (e.g. a format of HTML, XML, script etc.) for use by the requestingclient machine102. For example, the transcoding instructions may define a web page for displaying the extracted data inbrowser application86 that is suitable for display on theclient device102. The formatting rules can be system and/or user defined and can include parameters such as but not limited to: object positioning, object colour, object size, object shape, object font/image characteristics, background style, and navigational item display (e.g. in a menu as described above) or for display with the content in the generated page on the client screen. Browser application86 (e.g. ofmachine102A) may be configured for using a markup language (e.g. cHTML) or other code format that is not identical to the code provided byweb page110. Alternatively, transcoding instructions may be defined to express the extracted subset of data in XML or another code format such as for use by a different client application or plug-in to a client application such asmenu application82 or another application (not shown) onclient machine102.
• Signature schema documents may be prepared (i.e. coded) using a computing device such ascomputing device128.Computing device128 may be any suitable desktop or laptop device capable of coding documents (which may be but need not be XML-type documents) and may be configured to automate or semi-automate coding of such documents.
• Computing device128 may be coupled toweb site104 to retrieve web pages from the site for reviewing to prepare the custom signature schema document for the site.Computing device128 may be configured to automatically review the web page code and apply heuristics or other techniques (e.g. spatial analysis) to determine probable content of interest (i.e. subset of data) and generate code to extract the subset of data. For example, primary content of interest tends to be located toward the centre of the web page. In another embodiment, the computing device may facilitate a user coding signature schema to manually assist with the analysis of the web page and identification of subset of data and the generation of the instructions.Computing device128 may be further coupled torepository124 to provide (e.g. up-load or publish) coded signature schema documents for use byserver120.
• It will be apparent to a person of ordinary skill in the art that as a web site may be re-designed or otherwise changed such that the code of one or more web page families may be changed or a family added, an existing signature schema may require re-coding to account for the change/addition, as applicable.
Signature (Transcoding) Engine Syntax
• In accordance with a present embodiment, further details concerning the syntax of schema instructions are described.
Lookup Syntax
• The lookup tag instructs theengine140 to perform an insert, delete or query the document contents.
• Type: Defines the data type of the lookup. Type may be “pex” for a string expression. Type may also support more advanced options such as regular expressions, API calls, and SQL queries.
Action:
• Action=“locate_string”: Look for a string (“ref” identifier”) value within the data. Return true iff the string exists in the data (i.e. the “ref” identifier index >=0).
  Action=“replace_string”: Replace a string within the data with the “ref” identifier.
  Action=“move_ptr”: Remove all characters in the data that exist before the location of the “ref” identifier.
  Action=“end_ptr”: Remove all characters in the data that exist after the location of the “ref” identifier.
  Action=“get_string” Extract a string based on the location of the “ref”, “start”, and “end” identifiers.
  ID: ID is an identifier of another section within the signature. It allows the result of a query to trigger another set of actions within the signature. This is primarily used when identifying page types. Once a match has been made, specific instructions are executed that are marked with this ID. Recursive data structures (e.g. lists within lists) may also be supported.
  Ref: Ref defines the initial identifier that the lookup searches for. If an AND case is required multiple ref identifiers can be used (i.e. ref=“string1” ref1=“string2”). If an OR case is required ref_[ref identifier]_alt_—1 can be used (i.e. ref=“string1” ref_alt_—1=“string2”). To demonstrate (X=“1”∥Y=“2”) && (A=“8”∥B=“9”) would translate to ref=“1”ref_alt_—1=“2” ref1=“8”ref1_alt_—1=“9”.
  Repeat_[identifier]: Repeat executes the identifier query additional times. For example, if ref=“hello” to set the identifier index at the second occurrence of hello the following tag would be added: repeat_ref=“1”.
Location:
• Location=“before”: Search the data in a reverse direction, starting from the “ref” identifier. This implies that both the “start” and “end” identifier indexes must be less than the “ref” index.
  Location=“middle”: Search the data in two directions, starting from the “ref” identifier. This implies that the “ref” identifier index is greater than the “start” identifier index and less than the “end” identifier index.
  Location=“after”: Search the data in a forward direction, starting from the “ref” identifier. This implies that both the “start” and “end” identifier indexes must be greater than the “ref” index.
  Start: Start is primarily used when action=“get_string” and may also be used for replace/remove instructions. The start identifier index will be the start index of the string to extract. If an AND case is required multiple “start” identifiers can be used (i.e. start=“string1” start1=“string2”). If an OR case is required start-[start identifier]_alt_—1 can be used (i.e. start=“string1” start_alt_—1=“string2”). To demonstrate (X=“1”∥Y=“2”) && (A=“8”∥B=“9”) would translate to start=“1”start_alt_—1=“2” start1=“8”start1_alt_—1=“9”. To find the n^thmatch see the repeat syntax.
  End: End is primarily used when action=“get_string” and may also be used for replace/remove instructions. The end identifier index will be the end index of the string to extract. If an AND case is required multiple “end” identifiers can be used (i.e. end=“string1” end1=“string2”). If an OR case is required end[end identifier]_alt_—1 can be used (i.e. end=“string1” end_alt_—1=“string2”). To demonstrate (X=“1” ∥Y=“2”) && (A=“8” ∥B=“9”) would translate to end=“1”end_alt_—1=“2” end1=“8”end1_alt_—1=“9”. To find the n^thmatch see the repeat syntax
  Max_index: Max_index is used to limit the scope of a query by ensuring that no other identifier index is greater than the “max_index” . . . . If an AND case is required multiple “max_index” identifiers can be used (i.e. max_index=“string1” max_index1=“string2”). If an OR case is required max_index_[max_index identifier]_alt_—1 can be used (i.e. max_index=“string1” max_index_alt_—1=“string2”). To demonstrate (X=“1”∥Y=“2”) && (A=“8”∥B=“9”) would translate to max_index=“1”max_index alt_—1=“2” max_index=“8”max_index_alt_—1=“9”. To find the n^thmatch see the repeat syntax.
  Max_Index_Use_Ref: Max_Index_Use_Ref is a Boolean value set to 0 or 1. It is used with Max_index. When set to 0, the “max_index” will begin querying at the beginning of the data. When set to 1, the “max_index” will begin querying from the “ref” identifier index.
  Gbl_append_[identifier]: Gbl_append appends a string passed via the url to the identifiers query value
  Gbl_Repeat[identifier]: Gbl_Repeat executes the identifier query additional times. For example, if ref=“hello” to set the identifier index at the second occurrence of hello the following tag would be added: gbl_repeat_ref=“var” where var would be passed in the URL i.e. http://www.eshop.ca/mobile/fatfree.asp?site= . . . &url= . . . &var=1.
  Tolerance: Tolerance is a Boolean value set to 0 or 1. It is used to return an empty string. By default tolerance is set to 0 which enforces that a property be found on a page, otherwise the page will be marked as “invalid” and an appropriate error message returned. When set to one, an empty value is returned for properties that can not be located.
  Include_sz: Include_sz is a Boolean value set to 0 or 1 and used with get_string. It is by default set to 0. When set to 1 it includes the “start” value and the “end” value as part of the result.
  Include_start: Include_start is a Boolean value set to 0 or 1 and used with get_string. It is by default set to 0. When set to 1 it includes the “start” value as part of the result.
  Include_end: Include_end is a Boolean value set to 0 or 1 and used with get_string. It is by default set to 0. When set to 1 it includes the “end” value as part of the result.
  Closetag: Closetag is a Boolean value set to 0 or 1 and used when action=“get_string”. It appends /> to the extracted value.
  Strip_Tags: Strip_Tags removes HTML tags from the value and used when action=“get_string”.
  Strip_tags=“1”: remove all tags.
  Strip_tags=“2”: remove all br and script tags.
  Strip_tags=“3”: remove all tags except replace </p> </li> with <br>.
  Strip_tags=“4”: remove all tags except replace </div> <br> with <br>.
  Strip_tags=“tag1,tag2, . . . tagN”: remove all tag1, tag2, . . . tagN leaving any tag not listed.
  Notrim: Notrim is a Boolean value set to 0 or 1 and used when action=“get_string”. By default all value have white spaced trimmed. When this property is set to 1, white space is not trimmed.
  Append: Append is a string value and used when action=“get_string”. It appends a string to the extracted value.
  Prepend: Prepend is a string value and used when action=“get_string”. It prepends a string to the extracted value.
  Upper: Upper is a Boolean value set to 0 or 1 and used when action=“get_string”. It converts all characters to upper case.
  Lower: Lower is a Boolean value set to 0 or 1 and used when action=“get_string”. It converts all characters to lower case.
Page Syntax
• The page syntax extracts the paging information from the data. This allows the end user the ability to change pages just as on the desktop.
• Page_variable: Defines unique key that defines a family's paging feature.
  Page_start: Defines value of first page in a family's paging feature.
  Page_post: Path where paging variable(s) must be transmitted to.
  Page_start: Defines value of first page in a family's paging feature.
  Page_increment: Defines value that paging increases by for each page in a family's paging feature.
  Page_block: Defines unique key that defines a family's paging block feature.
  Page_block_size: Defines the size of the family's page block. (i.e. 10 items per page)
  Url_append: Append the unique key that defines a family's paging feature and the page number.
Search Syntax
• Make a website family's search feature functional by specifying details such as what variable to post.
• Search_path: Search path where search variable must be transmitted to
  Search_variable: Name of search variable which a website's search feature is looking to read, request, post, etc.
  Url_replace: Remove a portion of the url that is specific to posting search parameters
URL Syntax
• The url tag defines global properties for a site, including the url, and name: <url location=“http://www.eshop.ca” key=“eshop.ca” name=“E-Shop”/>
• Name: Name is the name to display when browsing using thegateway120
  Location: Location defines the fully qualified address of the site.
  Key: Key is the site.
Advanced Syntax
• The advanced tag defines global properties for the site. This at a minimum includes the path to the initial page of the site.

• 	<advanced>
  	<index_link value=“http://www.eshop.ca” />
  	<check_out value=“1” />
  	</advanced>

  
  Index_link: Index_link specifies the path to the initial page of the site. This is usually the same page as the location property from the URL syntax. This field is always required.
  Append_link: Appends a string value to every URL requested for this site.
  No_purchase: No_purchase is aBoolean value 0 or 1. The default value is 0 which implies that an item should contain a purchase link. When true, the purchase link is removed.
  No_item: No_item is aBoolean value 0 or 1. The default value is 0 which implies that Item pages should show up in the breadcrumb. When true, the item is not added to the breadcrumb.
  Check_out: Check_out is aBoolean value 0 or 1. The default value is 0 which implies that Item purchase link sends the request and control away from thegateway server120. When true, then a checkout process has been created for use withgateway server120.
  Product_img_width: Product_img_width defines the width of all item images.
  Use_cookies: Use_cookies aBoolean value 0 or 1. By default it is set to 0, and cookies are not passed to the site. When true,gateway120 passes all cookies fromclient machine102 to thesite104, and from thesite104 to the client machine.
Page Type Syntax
• The page type is a collection of lookup queries that have an id associated with them. Lookup queries may be processed in a top down fashion. The first successful lookup will trigger another section in the signature schema document. For example, if the following evaluates to true:

• 	<page_type>
  	<lookup type=“pex” action=“locate_string”
  	name=“list_elements” id=“mylist_1” ref=“&lt;!--” />
  	</page_type>

• Then the tag element <list_elements id=“mylist_—1”> would be executed next.
General Element Syntax
• Elements include list_elements, menu_elements, item_elements, search_elements, form_elements. Each element has an ID. For example a menu element:
  <menu_element id=“menu_id”/>
  The element may contain the following sub containers (settings, actions, elements, paging) which scope resides only within the element. Each element is associated with a specific rendering function.

• 	<menu_element id=”menu_id”/>
  	<settings> </settings>
  	<paging> </ paging >
  	<elements> </ elements >
  	<actions> </ actions >
  	</menu_element>

Settings Syntax
• Settings syntax varies based on the type of element it resides in. Settings allow customizations that only apply to a specific page family.
  Black_list-menu_elements: Black_list removes menu items with names that reside in the black list. Each entry is separated delimited (e.g. using two pound characters (##).
  Pass_image-list_elements, search_elements: Pass_image adds the image path to the url when requesting an item. The image added to the url will be used as the item image.
  Price[n]-item_elements: Price[n] where n is an integer renames the rendered item with name price[n].
  Action-form_elements: Overrides the action of a form displayed to the end user.
Handle-form_elements
• Handle=“display”—display the form to the end user.
  Handle=“post”—post the form.
  Handle=“get”—get the form.
  Cookie-form_elements: Send additional cookies when posting this form.
  Input-[identifier]-form_elements: Input tag adds/modifies a form value with name [identifier] setting its value.
  Rename_[identifier]-form_elements: Rename tag renames a form value with name [identifier].
Actions Syntax
• The actions tag primary function is data manipulation. It contains lookup queries that modify data with actions of “move_ptr” or “end_ptr”.

• <actions>
  <lookup type=“pex” action=“move_ptr” ref=“&lt;/head&gt;” />
  </actions>

• Persons of ordinary skill in the art will appreciate that alternative embodiments are contemplated. Though not shown, a client machine may incorporate a transcoding engine, applying a signature schema document obtained from a repository such asrepository124 to web pages received from a web site. For example,client machine102B may be configured with an engine in cooperation with a mini-browser application or plug-in to another application. The engine obtains the schema document to apply against web page content from a particular web site. Communications with the web site may be direct and not via agateway120. The transcoding engine may apply the commands from the schema and transcode appropriately for rendering content by the mini-browser or via the plug-in.
• FIG. 4 illustrates a further embodiment comprising asystem400 for content navigation, similar tosystem100 ofFIG. 1 but in which aclient machine102C incorporates asecure transcoding engine402, for example, for communicating directly withweb site104 via secure communications (e.g. Secure Sockets Layer (SSL) or Transport Layer Security (TLS), etc.).Client machine102C may be a wireless device such asdevice102A orwired device102B comprising components as described with reference toFIG. 2 and as further described with reference toFIG. 4.
• Large public database-driven websites do not typically encrypt data that is publicly available. Instead, the sites encrypt specific pages that contain user information, for example login, signup, checkout, and account management pages. One reason why all content is not encrypted may be that SSL/TLS is resource intensive and reduces scalability. Another reason why all content is not encrypted may be that SSL/TLS increase response times for the end user due to the time spent encrypting and decrypting content. Examples of websites that follow this model include online stores, news sites, sports information and weather. Therefore, since the number of SSL/TLS pages is relatively small, signature schema can be created to define a mobile friendly layout. Another benefit of the signature schema, is that each field in an HTML form can be classified and populated with user data from an external application. It will be understood that each individual SSL/TLS page will likely require its own respective page family template within a schema.
• In contrast toFIG. 1,FIG. 4 shows aclient machine102C comprising abrowser application86C similar tobrowser86 for communicating withweb site104 via gateway andschema server120. In a similar way, a signature schema may be used to transcode un-encrypted communications ofweb pages110 to provide transcodeddata408. However,browser86C may be further configured to communicate throughsecure transcoding engine402, handing off communications forsecure web pages404 when such communications betweenmachine102C andweb site104 are to be encrypted.Secure transcoding engine402 may communicate with gateway andschema server120 to obtain thesignature schema document122 which may be applied to transcode secure communications withweb site104.
• FIG. 5 illustrates a flow amongclient machine102C, gateway andschema server120 andweb site104 for secure communications such as forweb page404. It may be presumed thatclient machine102C has previously initiated a flow similar toFIG. 3 for aweb page110 that has resulted in transcodedresponse408 from gateway andschema server120 including the actual location of the secure content (e.g. for end to end encrypted communications withsite104 via HTTPs protocols).Browser86C hands off the request communication (502) to securetranscoder engine402.Secure engine402 requests (504) asignature schema122 fromserver120/engine140. The request may be validated and theschema122 returned (506) by theengine140 fromschema repository124 as may be necessary.Secure engine402requests508 the secure content (e.g.404) via end-to-end encrypted communication from theweb server106. Thesecure engine402 receives (510) thesecure content404 from theweb server106, decrypts the content and then invokes the transcoder using thesignature schema122 as instructions to extract the subset of data from theweb page404 and to re-construct the content in a mobile friendly view for rendering by the browser.
• Schema document122 may include instructions for populating secure responses toweb site104 with data previously stored toclient machine102C. Such information may include personal information that has been stored using an external client application406 such as a password keeping application for securely storing (encrypted) personal information. Schema documents may be coded with suitable instructions to invoke communications or application programming interfaces between the secure transcoding engine and external application406 to securely obtain such data. Such information may be available via a plugin (not shown) tobrowser86C.
• Those skilled in the art will now recognize thatsystem100 may be implemented so that a plurality of web sites are coupled to the telecommunication network (either alone by aserver106 or by a plurality of web servers like web-server106), and that a corresponding plurality of schemas for each of those web sites (or each of the web pages therein, or both) can be maintained by gateway andschema server120 andrepository124. Those skilled in the art will now recognize that there can in fact be a plurality of gateway and schema servers (like server120).Client machines102 can be configured for proxied connection throughdifferent servers120. Those skilled in the art will now further recognize thatservers120 can be hosted by a variety of different parties, including, for example but without limitation: a) a manufacturer ofclient machine102, b) a service provider that provides access to the telecommunication network on behalf of user U of aclient machine102; c) the entity that hosts web-site104 or d) a third party intermediary. In web site host example it can even be desired to simply combine theweb server106 andschema server engine120 on a single server to thereby obviate the need for separate servers.
• Accordingly, signature schemas may be defined to provide custom browsing experiences for small (e.g. mobile) devices (among others) and the proposed framework avoids changing web site code for existing web sites. Data extracted from the web sites may be intelligently stored to a relational database using knowledge of the web pages (i.e. the objects and their attributes) incorporated into the signature schemas. Query language may be used to direct a search of the web page as an ASCII text file to look for signatures to distinguish the web page's family (from other web page families of a site) and to identify the subset of data to be extracted.

Claims (25)

1. A method of transcoding a web page of a web site, the method comprising:

receiving a web page comprising plain text; and

applying a signature schema comprising one or more instructions to locate and extract a subset of data from the plain text using one or more signatures previously identified within plain text of one or more web pages of a same web page family of the web site.

2. The method ofclaim 1 wherein the web page comprises code in a markup language; and wherein each of the one or more signatures comprise at least one text string reference for locating within the code.

3. The method ofclaim 2 wherein at least some of the one or more instructions establish a start limit defined using a start text string reference, whereby characters in the text of the received web page before the start limit are ignored when locating and extracting the subset of data; and wherein at least some of the one or more instructions establish an end limit defined using an end text string reference, whereby characters in the text of the received web page after the end limit are ignored when locating and extracting the subset of data.

4. The method ofclaim 1 wherein the subset of data comprises a plurality of elements for an object and its attributes within the web page, each element comprising text data that is located and extracted by respective one or more instructions.

5. The method ofclaim 4 wherein the respective one or more instructions to extract a particular element comprise a respective text reference with which to locate the particular element.

6. The method ofclaim 5 wherein the respective one or more instructions to extract a particular element further comprise:

a directional reference relative to the text reference to direct a search for the text data; and

at least one of: i) a start reference comprising a start text string; or ii) an end reference comprising an end text string, said start reference and end reference respectively indicating a starting location and ending location for the text data.

7. The method ofclaim 6 wherein the one or more instructions comprise at least one text manipulation command for manipulating the extracted text data.

8. The method ofclaim 1 wherein the one or more instructions are interpreted by a transcoding engine component of a computing device configured for transcoding web pages to a target format.

9. The method ofclaim 8 wherein the web site comprises an e-commerce web site and the web pages are for conducting a transaction.

10. The method ofclaim 9 wherein the target format is suitable for use by a wireless mobile device.

11. The method ofclaim 1 comprising transcoding in a target format the subset of data extracted in accordance with the one or more instructions, thereby providing a transcoded web page.

12. A computing device for transcoding a web page of a web site, the computing device comprising:

a processor and a memory coupled thereto, said memory storing instructions and data configuring the processor to provide a transcoding engine to:

receive a web page comprising plain text; and

apply a signature schema comprising one or more schema instructions to locate and extract a subset of data from the plain text using one or more signatures previously identified within plain text of web pages of a same web page family of the web site.

13. The computing device ofclaim 11 wherein the web page comprises code in a markup language; and wherein the one or more signatures comprise text string references for locating within the code.

14. The computing device ofclaim 12 wherein at least some of the one or more schema instructions establish a start limit defined using a start text string reference, whereby characters in the text of the received web page before the start limit are ignored when locating and extracting the subset of data; and wherein at least some of the one or more schema instructions establish an end limit defined using an end text string reference, whereby characters in the text of the received web page after the end limit are ignored when locating and extracting the subset of data.

15. The computing device ofclaim 11 wherein the subset of data comprises a plurality of elements for an object and its attributes within the web page, each element comprising text data that is located and extracted by respective one or more schema instructions.

16. The computing device ofclaim 15 wherein the respective one or more schema instructions to extract a particular element comprise a respective text reference with which to locate the particular element.

17. The computing device ofclaim 16 wherein the respective one or more schema instructions to extract a particular element further comprise:

a directional reference relative to the text reference to direct a search for the text data; and

at least one of: i) a start reference comprising a start text string; or ii) an end reference comprising an end text string, said start reference and end reference respectively indicating a starting location and ending location for the text data.

18. The computing device ofclaim 17 wherein the one or more schema instructions comprise at least one text manipulation command for manipulating the extracted text data.

19. The computing device ofclaim 11 wherein the engine is configured to store in a database said subset of data extracted in accordance with the one or more schema instructions.

20. The computing device ofclaim 11 wherein the engine applies the one or more schema instructions to transcode said subset of data to a target format.

21. The computing device ofclaim 20 comprising a wireless mobile device.

22. The computing device ofclaim 21 wherein the web site is an e-commerce site and wherein the engine is configured to transcode web pages from the e-commerce site thereby to conduct an e-commerce transaction.

23. A computer program product storing computer readable instructions which when executed by a computer processor configure the computer processor to:

receive a web page comprising plain text; and

apply a signature schema comprising one or more schema instructions to locate, extract and transcode a subset of data from the plain text using one or more signatures previously identified within plain text of web pages of a same web page family of the web site, thereby to transcode the web page.

24. A system for transcoding web pages of a web site, the system comprising:

a web server serving said web pages;

at least one client machine configured to utilize transcoded web pages;

a gateway coupled between the web server and the at least one client machine via a telecommunication network, said gateway proxying respective requests for web pages from the at least one client machine and responding with transcoded web pages; said gateway configured with a transcoding engine to:

receive a web page comprising plain text; and

apply a signature schema comprising one or more schema instructions to locate and extract a subset of data from the plain text using one or more signatures previously identified within plain text of web pages of a same web page family of the web site.

25. A method of conducting an e-commerce transaction between a wireless mobile device and an e-commerce web site, said method comprising:

obtaining a signature schema comprising one or more schema instructions to locate, extract and transcode a subset of data from plain text of a web page using one or more signatures previously identified within the plain text of web pages of a same web page family of the e-commerce web site, thereby to transcode the web page;

receiving at least one web page from the e-commerce web site comprising plain text for conducting the transaction; and

transcoding at least some of the web pages received in accordance with the signature schema to conduct the transaction.

Images