WO2001022296A1 - Methods and systems for handling and exploiting slidecard use - Google Patents

Abstract

Methods and systems for handling and exploiting slidecard use include a request generator that receives a card code and a key code from a portal device (100). A portal device (100) may be a card reader (105) or the portal device (100) may include one or more buttons or keys (106). The request generator formulates a query to a portal server (108) in a format that maps to a directory structure in the file system of the portal server (108). As a result, the portal server (108) can access a file corresponding to the query without using a database. The query may be formatted as a URL. Because the query is formatted as a URL, the portal server (108) may utilize a standard web server (110) logging mechanism to gather all relevant information regarding a card user avoiding the need for web server (110) logging programs. The portal server (108) returns the requested file to a browser associated with an end user.

Description

Description METHODS AND SYSTEMS FOR HANDLING AND EXPLOITING

SLIDECARD USE Related Application Information

This application is a continuation of U.S. Patent Application Serial No. 09/576,936 filed May 10, 2000, a continuation-in-part of U.S. Patent Application Serial No. 09/440,318 filed November 12, 1999 and further claims the benefit of U.S. Provisional Patent Application Serial No. 60/156,020 filed September 23, 1999, and U.S. Provisional Patent Application Serial No. 60/180,466 filed February 4, 2000, the disclosures of each of which are incorporated herein by reference in their entirety.

Technical Field The present invention relates to methods and systems for handling and exploiting slidecard use.

Related Art

Many companies have observed that it is advantageous to combine the physical world of commerce with the on-line, web world. In one scheme, codes are printed on consumer goods, coupons, and similar items. When a user scans these codes into a computer, a set of processes loads an associated web page into a browser. Such schemes allow consumers easy access to information about products, which creates an advertising opportunity for the seller. U.S. Patent Number 5,976,773, (hereinafter, "the 773 Patent") the disclosure of which is incorporated herein by reference in its entirety, describes a method in which universal product codes (UPC) attached to items can be scanned using a bar code reader attached to a computer. The code is transmitted from the computer to a database. The database translates the code into a uniform resource locator (URL) stored in the database for the product, and the web page associated with the URL is loaded into a browser.

Commonly-assigned, co-pending U.S. Patent Application Serial Number 09/440,318, filed November 12, 1999, discloses a portal device including a keypad and a card reader. The portal device connects to a computer, such as a personal computer. When the user actuates a key, a key code is transmitted to the computer. The key code is used by the computer to access one or more web pages. When a card is inserted in the card reader of the portal device, the card reader reads a code from the card. The card code and the key code are sent to the computer. The computer uses both the card code and the key code to access a desired web page.

Present product-code-based methods and systems for accessing web sites suffer a number of limitations. First, as described in '773 Patent, the process of translating UPC codes into URLs requires a back-end database, situated behind a request-handling web server, as shown in Figure 1 of the '773 Patent. Deploying and maintaining a database is costly, error-prone and limits scalability.

Second, should adoption of product-code-based web page access systems grow, the number of codes could become quite large. For example, a 40-bit code can support over 1 trillion unique codes. Each code would have an associated unique query for accessing a web page associated with the code. Deploying a back-end infrastructure that can respond to such a large number of unique queries is expensive and slow. Third, according to the '773 Patent, product codes are uniquely mapped to URLs. While this mapping is simple, it does not exploit the demographic information advertisers customarily utilize to effectively advertise a product. For example, it is common for advertisers to utilize demographic information regarding consumers to send targeted advertisements to the consumers. Targeted advertising is not possible when a product code is uniquely mapped to a URL.

Fourth, for codes to map to URLs, a standard for code issuance must exist. If such a standard does not exist, two companies desiring to issue product codes might arbitrarily select the same code. In this case, database queries for URLs corresponding to the codes could not resolve uniquely, as the companies will register URLs for the same code. The system described in the '773 Patent suggests no mechanism for automating the process of assigning codes and printing codes on tangible media, such as cards.

Accordingly, in light of these difficulties associated with conventional product-code-based web page access systems, there exists a need for novel methods and systems for handling and exploiting slidecard use in a code- based web page access system. Disclosure of the Invention The present invention includes methods and systems for handling and exploiting slidecard use. As used herein, the term "slidecard" refers to a card having a code readable by a reader associated with a computing device. The term slidecard is not intended to limit the invention to cards that are swiped or slid through a card reader. For example, the cards may be smart cards including microprocessors that communicate with a card reader when the cards are in close proximity to the card reader.

The present invention is not intended to be limited to reading codes from cards. Reading codes from any machine readable indicium is within the scope of the invention. For example, codes may be encoded as bits embedded in a music CD readable by a music CD reader.

As used herein, the term "reader" refers to a standalone reader, such as a wand-style bar code reader, as well as a reader that is part of another device, such as a portal device or embedded in a keyboard.

The terms card codes and key codes are used herein to describe the codes associated with the cards and keys, respectively. Although the examples discussed herein relate primarily to decimal codes, the present invention is not limited to using decimal codes. Any numeric, alphanumeric, binary, or other type of codes for uniquely identifying cards and keys is within the scope of the invention.

Consequently, it is an object of the invention to increase the scalability of a code-based web page access system, including a card-code-based web page access system, by avoiding use of a code database. It is another object of the invention to collect card insertion data without deploying special server software.

It is another object of the invention to further increase scalability of a card-code-based web page access system through intelligent routing of card-code-based web page requests from the reader.

It is another object of the invention to utilize data mining techniques to target URLs to users based on demographic information.

It is another object of this invention to automatically allow card issuers to define unique cards.

Brief Description of the Drawings A description of the present invention will now proceed with reference to the accompanying drawings of which:

Figure 1 is block diagram of an exemplary operating environment for the methods and systems for exploiting slidecard use according to embodiments of the present invention;

Figure 2 is a block diagram illustrating exemplary slidecards according to embodiments of the present invention;

Figure 3 is a block diagram illustrating a system for handling and exploiting slidecard use according to an embodiment of the present invention;

Figure 4 is a flowchart illustrating exemplary steps performed by a request generator and a browser in accessing a desired web page without using a web server database according to an embodiment of the present invention; Figure 5 is a block diagram illustrating a conventional web server load balancing system;

Figure 6 is a block diagram of a client-based portal server selection system according to an embodiment of the present invention; Figure 7 is a flowchart illustrating exemplary steps that may be performed by a request generator in selecting a portal server according to an embodiment of the present invention;

Figure 8 is a flowchart illustrating exemplary steps that may be performed by a request generator in selecting a file extension for a web server query according to an embodiment of the present invention;

Figure 9 is a block diagram illustrating an exemplary combined client- side and server-side portal server selection system according to an embodiment of the present invention;

Figure 10 is a block diagram of a demographic information-based web page access system according to an embodiment of the present invention;

Figure 1 1 is a flowchart illustrating exemplary steps that may be performed by a portal server in delivering targeted web page information to an end user based on demographic information regarding the end user;

Figure 12 is a block diagram illustrating a card usage data collection system according to an embodiment of the present invention;

Figure 13 is a block diagram illustrating a targeted web page delivery system including a scoring algorithm for computing a score for an end user and delivering a targeted web page to the end user based on the score; Figure 14 is a flowchart illustrating exemplary steps that may be performed by a portal server in sending a targeted web page to an end user based on a score computed for the end user;

Figure 15 is a block diagram illustrating an automated slidecard enablement system according to an embodiment of the present invention; and

Figure 16 is a block diagram illustrating slidecard printing according to an embodiment of the present invention.

Detailed Description of the Invention

Figure 1 illustrates an exemplary operating environment for the methods and systems for exploiting slidecard use according to embodiments of the present invention. In Figure 1 , portal device 100 is adapted to send card codes and key codes to portal client 102 residing on portal client computer 104. Portal device 100 includes a reader 105 for reading card codes and keys 106 for generating key codes. The card codes and the key codes are communicated to portal client computer 104 via communications link 107. Details of the internal circuitry of the keypad and the card reader are disclosed in the above-referenced co-pending U.S. Patent Application Serial No. 09/440,318 and need not be repeated herein. What is important for explaining embodiments of the present invention is that reader 105 is adapted to read card codes from slidecards, and keys 106 generate key codes based on a key press by a user. Portal client 102 communicates with portal server 108 residing on portal server computer 109 to access files stored by web servers 110. This communication can include key codes, card codes, and other information to select one or more web pages served by web servers 110. It is the interaction between portal client 102 and portal server 108 to which embodiments of the present invention that relate to the handling of slidecard use apply.

The present invention is not limited to a reader associated with a portal device as illustrated in Figure 1. For example, in an alternative embodiment of the present invention, a reader may be a conventional standalone bar code reader, such as a wand style bar code reader, as described in the '773 Patent referenced above. Such a bar code reader may communicate with portal client computer 104 through any suitable interface, such as the serial port or the universal serial bus (USB) port of the computer.

Figure 2 illustrates exemplary slidecards suitable for use with embodiments of the present invention. In Figure 2, slidecards 200 and 202 each include bar codes 204, 206, 208, and 210 for encoding data relating to slidecards 200 and 202. For example, bar codes 206 and 210 may encode card codes for identifying slidecards 200 and 202. Bar codes 204 and 208 may contain sync bits, preamble bits, and post amble bits that enable reader 105 to read bar codes 206 and 208. Card codes encoded by bar codes 206 and 210, may be used in combination with key codes to access a desired web page. For example, slidecard 200 includes store locator key indicator 212 and frequently asked questions key indicator 214. Key indicators 212 and 214 may correspond to one of the keys 106 associated with portal device 100 illustrated in Figure 1. When the user inserts slidecard 200 into reader 105 and presses the key corresponding to store locator key indicator 212, the card code and the key code that are generated are used to access a website, such as a website for locating a WebTV vendor. Similarly, when the user presses a key corresponding to frequently asked questions key indicator 214, a website corresponding to frequently asked questions regarding WebTV provided by Microsoft may be displayed to the end user. Key indicators 216 and 218 perform a similar function for slidecard 202. That is, key indicators 216 and 218 enable a user to access specific web pages associated with the Expedia.com card. Slidecards 200 and 202 may be of any suitable structure. In the illustrated embodiment, slidecards 200 and 202 have a credit-card-like appearance. That is, slidecards 200 and 202 are wallet-sized and comprise a plastic material. Bar codes 204, 206, 208, and 210 comprise reflective and non-reflective areas readable by one or more optical sensors associated with reader 105 illustrated in Figure 1.

The present invention is not limited to using bar codes to encode card codes or to using slidecards that have a credit-card-like appearance. For example, in an alternative embodiment of the invention, slidecards may include a magnetic strip that encodes the card code. In yet another alternative, the slidecards may comprise smart cards that include microprocessors for communicating the card codes to external devices. In yet another alternative embodiment, slidecards 200 and 202 may be part of an advertisement in a newspaper or magazine. In such an embodiment, barcodes 204, 206, 208 and 210 could be readable using a wand style bar code reader. Improved Scalability by Eliminating Server-Side Database According to a first aspect, the present invention includes a code- based web page access system, and in particular a card-code-based web page access system, that eliminates the need for a server-side database for determining URLs corresponding to card codes.

In brief, the system includes client-side software for constructing a web query that maps to a directory structure on one or more portal servers, which preferably comprise web servers. Because the query maps to a web server directory structure, the portal server receiving the query can access the requested file using standard web server functionality without accessing a database. Thus, by combining functions deployed at the client and the server, standard web server functionality to eliminate the need for a database. Figure 3 illustrates a code-based web page access system according to an embodiment of the present invention that eliminates the need for a server-side database. In Figure 3, portal device 100 includes reader 105 and keys 106, as previously described. In an alternative embodiment, keys 106 may be omitted such that portal device 100 comprises a stand-alone reader for reading card codes. In the illustrated embodiment, reader 105 and keys 106 generate card codes and key codes and communicate the card codes and key codes to portal client 102.

Portal client 102 includes request generator 300 and browser 302.

Portal client 102 can execute on any type of computing device, such as a personal computer, a workstation, a personal digital assistant (PDA), a WebTV device, a cellular phone or other device suitable for executing network communications software.

Request Generator Request generator 300 is responsible for formulating queries such that the queries can be handled by a portal server using standard web server functionality. Request generator 300 receives a card code and optional key code, and formulates a web server query. In the preferred embodiment, the web server query is a URL. The URL has the form: <protocol>//<server>/<routing>/<card and key codes>parameters. In most web cases, the protocol will be HyperText Transfer Protocol (HTTP), so the <protocol> portion of the query will typically be: http: The <server> portion of the query defines the portal server that will handle the request. In the simplest case, a well-known server such as www.planetportal.net handles all such requests. An extended mechanism that uses multiple portal servers to increase scalability will be described in more detail below.

The <routing> field in the web server query is optional, and can specify a subdirectory within the file system of a portal server in which to find the card and key codes. In a simple case, this field would be omitted, but could be specified as: cards The card and key code information is combined to complete the URL. The card code is mapped to a directory containing files associated with each key code. In the case where the portal device includes three keys, the possible values in the <card and key codes> field of the query for a card with a card code of 12 and 3 keys would be:

12/1. html 12/2.html

12/3.html If the portal device does not include keys, request generator 300 can send a null key code along with the card code to one of the portal servers 108. A predetermined character, such as "0" may be defined as the null key. Thus, the field value for the <card and key codes> portion of the query corresponding to a card code of 12 with no keys may be:

12/0.html The <parameters> portion of the query can be used to pass additional information to the server. In one example, the parameters include an indication of the version of the portal device used to read the card. Exemplary parameters might include:

?&deviceType=WebRemoteControl1 .2, or ?&deviceType=IBMKeyboard3.4 These parameters respectively indicate reading of a card code by a portal device that comprises a WebRemote Control version 1.2 or IBM Corp Keyboard, version 3.4, respectively.

When the query is received at one of the portal servers 108, the receiving portal server can tailor its actions based on the query, log the query or tailor its actions and log the query. Other parameters can be added or substituted in the query to flow additional information of interest. When a card having a card number of 12 is read by reader 105, and a key having a key code of 1 is pressed, the complete query might be: http://www.planetportal.eom/cards/12/1.html?&deviceType=WebRemoteControl1.2 The <routing> and <card and key codes> portions of the query are cards/12/1 .html

These fields map to a directory, subdirectory, and file in a web server file system, such as the file system of one of the portal servers 108. The receiving portal server may utilize standard web server functionality to parse the query and map the query to its local file system. For example, the receiving portal server may map cards/12/1.html to c:\cards\12\1.html, where 1.html is the file containing information requested by the query. Because request generator 300 formulates the query in a manner that maps directly to the portal server file system, there is no need for a server-side code database, such as the database described in the above-referenced '773 Patent. Because no database is required, portal server query processing time is reduced and scalability is increased.

In some cases, the distributor of reader 105 might want users to be taken to a website upon reading of a card code. This case is handled by assigning an arbitrary "swipe number" to the act of swiping a card through a reader. For example, code 999 might be used, and a swipe query for card

12 would be: http://www.planetportal.com/cards/12/999.html Although in the illustrated embodiment, request generator 300 executes on a client computer external to portal device 100, in an alternative embodiment request generator 300 may be internal to portal device 100. In yet another alternative embodiment, request generator 300 might execute on a stand-alone device separate from both portal device 100 and portal client computer 104.

Browser Once request generator 300 formulates the query, request generator

300 passes the query to browser 302. Browser 302 may be a standard browser, such as Internet Explorer version 5 available from Microsoft Corporation of Redmond, Washington. Request generator 300 may utilize a standard operating system function to invoke the browser. For example, in the Windows 98 operating system available from Microsoft Corporation, the call

Shell Execute when passed a URL such as the one above will activate the default browser, and cause it to load the web page specified by the URL. To load the web page, the browser 302 sends a query (for example, using HTTP) to one of portal servers 108, as indicated in the <server> portion of the query. This query travels over the Internet to the specified portal server. The flow of the data from browser 302 to one of the portal servers 108 may be an HTTP GET request sent in a TCP/IP packet.

Portal Server

When the request reaches one of the portal servers 108, the receiving portal server uses standard web server technology to fetch the requested page. In the typical case, portal server 108 returns the contents of the page specified by the request. In the above-described example where key 1 was pressed on card 12, portal server 108 at www.planetportal.net accesses the "cards" directory in the portal server file system, locates the "12" subdirectory, and returns the contents of the file "1.html" located in the "12" subdirectory. Thus, in addition to formulating web page queries in a manner that reduces the need for a server-side database, the present embodiment also includes arranging card codes and key codes in a predetermined hierarchy in a portal server file system. For example, if card 12 has 4 keys, the portal server file system may include a subdirectory of 12 containing the files:

1.html 2.html

3.html 4.html Similar directory structures may be included for other card numbers. For example, a subdirectory of 1 1 may be provisional with files for each key on card number 1 1 . Provisioning the portal server file system with directory structures that correspond to card and key codes further decreases portal server query processing time and increases scalability.

Web servers can be configured to map "virtual directory names" such as "cards" to physical directories on the machine. This allows the server to export one name space externally, while maintaining a different one internally, allowing the systems administrator more flexibility. For example, "cards" might be translated by the web server into "CardDir", which would be used for the lookup. Thus, mapping from virtual to physical directory names in a portal server file system is within the scope of the invention. ln one embodiment of the invention, the files on each portal server 108 contain a copy of the requested web page. For example, if card 12 is issued for Pepsi Cola™, the file stored on each portal server 108 might contain an advertisement, a coupon, or other information regarding Pepsi Cola™. However, if each portal server 108 maintains information about all products locally, the portal servers 108 will be required to store enormous quantities of data. Consequently, portal server 108 preferably stores files such as "1.html" that contain web redirect indications such as: <META HTTP-EQUIV="refresh" CONTENT="0;URL=http://www.pepsi.com"> This redirection indication is transferred back to browser 302 instead of the desired web page.

When such redirect indications are received by browser 302, rather than rendering the content, browser 302 executes a subsequent web query to load the URL indicated in the redirect. In this example, the redirection indication instructs the browser to load the web page located at the domain name www.pepsi.com.

The present invention is not limited to returning a redirection indication to browser 302 and having browser 302 formulate a subsequent query to access the desired web page. In an alternate embodiment, portal server 108 can formulate a query to the web page specified in the redirect indication, and return the desired web page directly to browser 302. This solution is not preferred because portal servers 108 will receive a high volume of requests. As a result, it is advantageous to reduce the amount of processing per request performed by portal servers 108. Since less processing is required to return a redirection indication to browser 302 than to access and forward the desired web page, forwarding the redirection indication is preferred.

Figure 4 is a flowchart summarizing the steps performed by the entities illustrated in Figure 3 to access a desired web page without using a database at portal server 108. It is understood that the steps illustrated in Figure 4 may be implemented as or by computer program products comprising computer-executable instructions embodied in a computer- readable medium. Referring to Figure 4, in step ST1 , request generator 300 receives a card code and a key code from portal device 100. In step ST2, request generator 300 formulates a web server query that maps to a portal server file system. Formulating a web server query that maps to a directory structure in portal server file system can include encoding directory information and file name information in the web server query. For example, if the portal server is www.planetportal.net, the card code is 12 and the key code is 1 , the query may be http://www.planetport.al. net/12/1.html. In step ST3, request generator 300 invokes browser 302 to forward the web server query to the portal server, specified by the query. As discussed above, the browser may be invoked using the ShellExecute command.

In step ST4, the portal server receives the web server query and maps the query to the corresponding directory structure in portal server file system using standard web server technology. For example, portal server 108 may parse the query to extract the card and key code portion in the web server query formulated by the request generator. Portal server 108 may then locate the file indicated by the card and key information. For the example above of http:/www.planetportal. net/12/1.html, portal server 108 may map the query to c:\cards\12\1.html.

In step ST5, portal server 108 extracts the contents of the file specified by the web server query. Continuing with the example, the file 1.html may contain a redirection indication corresponding to the card and button number. In step ST7, portal server 108 returns the file contents. An example of such an indication is:

<META HTTP-EQUIV="refresh"content="0;URL=http:/www.pepsi.com">.

In step ST7, browser 302 receives the file contents. In this example, since the contents are a redirection indication, browser 302 formulates a query to the desired web server. In step ST8, browser 302 receives the desired web page from one of the web servers 110 and displays the content to the user.

Thus, by using the request generator to carefully construct an HTTP request (or one using a similar protocol) that maps to a directory structure in a portal server file system, and deploying the appropriate file structure on the portal server, where each file contains a redirection indication pointing to the proper page, the need for a database to supplement web server functionality is eliminated. By eliminating the database, processing time is decreased, and scalability is increased. In addition, using a web server as the portal server simplifies the process of data collection by exploiting logging mechanisms inherent in many modern web servers. This further reduces complexity. The logging process is discussed further below. Returning Extensible Markup Language (XML) in Response to

Card-Code-Based Web Server Queries In the examples presented above, web servers 110 supply browser 302 with data encoded using the HyperText Markup Language (HTML). The present invention is not limited to accessing desired web pages encoded in HTML format. A variety of alternative data formats are within the scope of the invention. In one novel extension to the present invention, the web page data provided by portal servers 108 and/or web servers 110 to browser 302 can be supplied in extensible markup language (XML), a web-standard, data-interchange format. By providing data in this format in response to card-swipes, the information received from portal servers 108 and/or web servers 110 can be processed by applications other than browser 302. For example, if a card includes a card code for accessing a stock-trading site, the data received from web portal servers 108 and/or web servers 110 in response to the insertion might encode stock symbols, and other stock- related information. Once the XML data is received by browser 302, that data can be loaded by a stock-trading or a stock-monitoring application. Thus, rather than simply providing static data in response to a card insertion, an advertiser can provide mark-up data that is used as input into an application. This increases the utility of the invention for certain classes of potential card issuers. Of course, the data supplied in XML format can also be rendered by many modern browsers. Intelligent Client-Based Server Selection In the scenario described above, portal client 102 creates a URL specific to a given card/key pair, and sends it to a predefined portal server. However, as the number of card transactions increases, a single portal server will have difficulty handling all of the transactions.

In current systems that provide web content to web clients, multiple web servers can be deployed behind a machine that load balances among the servers. This configuration is shown in Figure 5. In Figure 5, clients 500 access web server 110 through load balancer 502. Clients 500 may comprise conventional web clients, such as browsers. Web servers 110 are the same as those previously described with respect to Figure 1 , which contain web pages desired to be accessed by clients 500. Load balancer 502 is a process that monitors the processing capacity of web servers 110 and forwards queries from clients 500 to web servers 110 based on the capacity. For example, if load balancer 502 determines that one web server 110 is overloaded, load balancer 520 may route queries from clients 500 to another web server 110.

One disadvantage to the approach illustrated in Figure 2 is that each of the web servers 110 must have access to all web pages that are accessible from any of the web servers 110. When this technique is applied to a card-based web server access system including millions or billions of cards, the resulting amount of information sharing among the content- providing servers typically accomplished by file sharing becomes overwhelming. Either the file system will prove a bottleneck, resulting in reduced scalability, or each machine will require its own copy of all of the files, resulting in higher costs.

To overcome this limitation, the present embodiment supplements database-elimination with the optional use of client-side portal server selection. Referring again to Figure 6, in intelligent client-side server selection, request generator 302 may access a list of portal servers 600, and algo thmically map the card code to a unique portal server. In Figure 6, it is assumed that portal servers 108 are provisioned to provide redirection indications as described with respect to Figure 3. Alternatively, portal server 108 could be content-providing web servers. There is no difference in portal sever functionality required to provide content versus redirection indications. The only difference according to the present embodiment is that the files accessed by web queries in each portal server file system contain the desired web page, rather than a URL that points to the desired web page. The file system directory structure of portal servers 108 illustrated in Figure 6 is assumed to be the same as that described with respect to Figure 3.

In a preferred embodiment, request generator 302 accesses server list 600 to determine portal servers that are available to process queries. Server list 600 may comprise a simple text file, and is of a form such as: www1.planetportal.net

www2.planetportal.net wwwN.planetportal.net or an equivalent form. The server names need not appear as similar as they do in this example. In another example, the list could be: www.myfirstserver.com www.mysecondserver.net w3.yetanotherserver.edu This list simply defines portal servers capable of processing queries. Figure 7 illustrates exemplary steps that may be performed by request generator 300 in performing client-side server selection. In step ST1 , request generator 300 receives a card code and optionally a key code from portal device 100. In step ST2, request generator 300 algorithmically determines a portal server selection code based on the card code. In a preferred embodiment, request generator 300 uses a modulus function to determine the portal server selection code. Portal servers 108 may be assigned zero-based indices. That is, the portal server selection code or index for portal server www1.planetportal.net may be 0. The portal server selection code for portal server www2.planetportal.net may be 1. Finally, the portal server selection code for portal server www3.planetportal.net may be 2. The portal server selection code may be computed according to the expression (CARD CODE)MOD(# of portal servers). The result is used to select the proper portal server. For example, if the portal servers are: wwwl .planetportal.net www2.planetportal.net www3.planetportal.net then there are three total servers, so portal server selection codes may be computed by card codes modulo three. Since 1 MOD3 is 1 , card 1 has a portal server selection of 1 , card 2 has a portal server selection of zero, and card 3 has a portal server selection code of 0. Using a modulus function to distribute web queries among portal servers provides an efficient mechanism for dividing query processing evenly among portal servers as the number of issued codes increases. For example, if the number of unique card codes increases from 500,000 to 600,000, and there are 4 portal servers that handle queries from all of the codes, the modulus function divides the responsibility for processing the individual codes evenly among the portal servers - 25,000 for each portal server. In addition, for each incremental increase in card codes, the processing load is shared among the portal servers. As a result, the present embodiment provides an efficient scaling mechanism.

Referring again to Figure 7, in step ST3, request generator 300 selects a portal server name based on the portal server selection code. Using the zero-based indexing, the portal server selection code 0 maps to www1.planetportal.net; portal server selection code 1 maps to www2.planetportal.net; and portal server selection code 2 maps to www3.planetportal.net.

In step ST4, request generator 300 formulates a portal server query including the selected portal server name. The server name is included in the <server> field of the URL, as described above. In the simplest case, there is a single portal server, such as: www.planetportal.net, and this method reduces to the simple method described above.

The present invention is not limited to using a portal server selection code to select from a list of portal servers. In an alternate embodiment, instead of using lists of servers request generator 302 is supplied simply with the number of servers, and algorithmically computes the server name. For example, the portal servers can be assigned names such as: wwwO.planetportal.net wwwl .planetportal.net www2.planetportal.net www3.planetportal.net www4.planetportal.net

Request generator 300 is supplied with 5 as the number of portal servers.

Request generator 300 then computes (card code)MOD(number of portal servers). The resulting modules can then be used in the portal server name itself. In this case, if M is the modulus, then the portal server name is: wwwM.planetportal.net

The present invention is not limited to using a modulus function to perform client-side portal server selection. Functions of increased complexity can be used for mapping card codes to portal server names. For example, certain bits in the card code can be combined using Boolean algebra to determine the portal server name. Similarly, simple mechanisms such as downloading a file containing a list of mappings of cards to portal servers can be employed. However, such a file will likely grow large, so algorithmic approaches are preferable.

Intelligent Client-Side Server Selection to Separate Static Content from

Dynamic Content According to another aspect of client-side server selection, static web content can be separated from dynamic web content. Separating such content improves web server performance. Once the portal server selection code is computed based on the modulus function specified above, the portal server selection code is used to select the extension for file associated with the key or card. In a preferred embodiment, request generator 300 compares the portal server selection code to one-half the number of portal servers. If the portal server selection code is less than half, the extension is ".html;" otherwise, the extension is ".cgi". For example, if the number of servers is 10, and the portal server selection code computed by request generator 300 is 4, the extension is ".html"; if the portal server selection code is 6, then the extension is ".cgi".

Furthering the example, if the card code is 1 , the computed portal server selection code is 1 , and key 2 is pressed, using the format defined above, the URL would be: http://www1.planetportal.net/cards/1/2.html

Similarly, if the card code is 6, the portal selection code is 6, and the key code is 1 , the URL would be: http://www6.planetportal.net/cards/6/1.cgi Figure 8 illustrates an exemplary algorithm for content-based server selection that may be performed by request generator 300 illustrated in Figure 6. In step ST1 , request generator 300 receives a card number from a portal device. In step ST2, request generator 300 computes a portal server selection code based on the card number. In a preferred embodiment, request generator 300 uses the modulus function described above to compute the portal server selection code. In step ST3, request generator 300 compares the portal server selection code to one half of the number of portal servers. In step ST4, if the selection code is less than one half the number of portal servers, in step ST5, assigns a file extension of .cgi to the query. CGI or common gateway interface files are used to access dynamic content on web servers.

In step ST4, if request generator 300 determines that the portal server selection code is not less than one half the number of portal servers, in step ST6, request generator 300 assigns a file extension of .html to the query. HTML files are used to select static web server content. Table 1 shown below illustrates an example of file extensions computed by request generator 300. The first column in Table 1 lists card codes. In this example, it is assumed that there are 12 card codes and 4 portal servers. The second column in Table 1 lists the portal server selection codes computed by the expression (cardnum)MOD(num_portal_servers). The third column in Table 1 is the file extension corresponding to the portal server selection code. As illustrated in Table 1 , the content-based client-side server selection algorithm described with respect to Figure 8 evenly divides queries between static and dynamic web server content. As a result, portal servers can be provisioned to provide either static or dynamic content and thus process queries more efficiently as a whole.

Table 1

Query Re-Routinq

In some cases, request generator 300 will accidentally route requests to an incorrect server. This can happen when a client has an outdated server list. For example, when a new portal server is added, some portion of the card requests will be assigned to the new portal server. Until request generator 300 receives an indication of this new assignment, some fraction of the requests will be misrouted.

Many modern web servers, including the Apache web server produced by the Apache Group (www.apache.org), allow web masters to specify files that will be returned should a request fail. These files can be specified per requested directory.

When a card-based web server query is misrouted, a query intended for one portal server, such as wwwO.planetportal.net may be sent to another portal server, such as www1 .planetportal.net. In such a case, the receiving portal server executes the server-lookup algorithm to determine the proper server, and returns a redirect indicator to the client. The redirect process is described above. An example of a script that performs query re-routing is as follows:

# ! /usr/bin/perl sub lookup {

# contains the server lookup algorithm. This is a very

# basic sample lookup algorithm, using mod 10 to pick a

# server name from wwwO to www9 my $cardid = $_[0] ; my $serverid = cardid % 10; return "www$serverid.planetportal .net" ;

}

$document_name = $ENV{ ^VHTTP_REFERER' } ,- # in this implementation,

# referrer

# would contain the

# original

# card filename requested,

# although

# this could come from

# other sources

# in other implementations

$document_name =~ s/http ( . *) net// ; # substitute out the bad

# server name

$document_name =~ / ( . *) (\d*) \ .html/ ; # match the numeric

# element of the $card_number = $2 ; # filename and assign it

# to

$path_name = $1; # card_number, match the

# path data

# and assign to path_data

$new_server = klookup ($card_number) ; # &lookup function

# contains the

# algorithm, which returns

# the

# text string containing

# the

# proper server name

$new_document_name = $new_server . $path_name . $card_number . ' . html ' ;

# build new URI with

# corrected

# server name print "Location: $new_document_name\n\n" According to the above-listed query re-routing script, when a server receives a request for a card that it does not handle, it will attempt to look up the file (or program) associated with the card. This search will fail. The failure of the search triggers the re-routing algorithm in the script whereby the portal server algorithmically computes the correct portal server name using the card code received in the request. The script then builds a new URL corresponding to the correct server name and forwards the URL to the client as a redirection indication. The client can then contact the correct server.

Using Client Location Information to Perform Intelligent Client-Side Portal Server Selection According to yet another aspect of client-side portal server selection, the location of the client is used to determine where the portal server farm resides. In this case, request generator 300 uses a location indicator along with the card code to locate the server. For example, during setup, most PCs ask the user to supply the country in which the PC will be used. This information can be used by request generator 302 to append a country code to the URL sent to one of the portal servers. In one variation of this scheme, request generator 300 is supplied with a mapping of countries to portal servers local to each country. Referring again to Figure 6, request generator 300 may have access to country mapping table 602 that contains mapping information for mapping countries to server names an example of such a table is as follows:

In the above-listed country mapping table, when a client is located in Japan, Korea, or China, the file extension is .jp. Similarly, when the client is located in the USA, Canada, or Mexico, the server file extension is .us.

These file extensions may be appended to the server names computed as described above. For example, the server name in a query from a client machine in Japan may be www1.planetportal.jp. Similarly, the server name in a query from a client machine located in Canada may be www1.planetportal.us. This scheme further balances load among servers, and provides improved response time to card requests by using servers that are geographically proximal to the clients. Such geographical mapping is an optional addition to the client-side selection mechanism.

Client-Side Server Selection in Combination with Server-Side

Load Balancing None of the client-side server selection schemes discussed above preclude the use of server-side load balancing. Figure 9 illustrates a system in which client-side server selection and server-side load balancing are used in combination to distribute queries among portal servers 108. In Figure 9, request generator 300 performs steps similar to those illustrated in Figure 6 to determine a portal server selection code. Then, rather than mapping the portal server selection code to a portal server name, request generator 300 maps the portal server selection code to a load balancer name. This mapping may be performed using a list or an algorithm as described above. The query is then sent to one of the load balancers 502. Load balancers 502 determine the portal server that is appropriate to receive the query based on portal server processing load. Accordingly, the present embodiment provides load balancing among portal servers using both the client- and server-side portal server selection.

Automatic Updating of Server List Server list 600 used by request generator 300 to configure the client- side server selection can be downloaded dynamically using the mechanism disclosed in the above-referenced co-pending U.S. Patent Application Serial No. 09/440,318 filed November 12, 1999. In brief, this mechanism includes sending an HTML request to one of the portal servers 108 to determine whether server list 600 requires updating. First, request generator 300 determines the version number of the server list 600 containing the list of portal server names currently in use. Request generator 300 then increments the version number and transmits the incremented version number to a portal server. The portal server maps the incremented version number to a file location in the portal server file system using a mechanism similar to that described above with respect to card codes and key codes. For example, version 3 of the server list may map to the directory c:\serverlist\3\. If a configuration file exists at the location, the new file is downloaded to request generator 300. If a file does not exist at that location, a file-not-found message may be sent to request generator 300. Thus, the present embodiment includes a method for dynamically updating a configuration file used for client-side server selection.

Summary of Client-Side Server Selection In summary, the client-side server selection reduces the load on any given portal server, and additionally reduces the number of files that need be accessed by any given portal server. The objective is accomplished by algorithmic assignment of card codes to portal servers, optionally supplemented by geographic distribution techniques.

Tailored Responses to Card-Based Web Page Queries

The mechanisms described above improve the scalability of a card- based web page access system. However, they do not attempt to improve the user experience, which limits the value to both users and to advertisers.

The present embodiment improves user experience by tailoring responses to card-based web page queries based on knowledge about the user.

Gathering Descriptive Information Regarding Card Users To tailor responses to card-based web server requests, information about the user must be gathered. This is routinely done by commercial software and by web sites such as "http://my.yahoo.com". Such information includes demographics that can include, but is not limited to: name, address, zip code, e-mail address, gender, income, etc. The mechanisms described below will use such demographic information to select among one or more web pages associated with any given card.

Web-Page Selection Using Demographic Information According to the present embodiment of a card-code-based web page access system, information about a user is used in addition to the card code to further select among files stored on a portal server. Information about a user includes both static information such as gender, address, etc., and behavioral information, such as "user used this card ten times." In one simple example, gender can be used to tailor responses to card-based web page queries. Recalling the URL format of a card-based web page query described above:

<protocol><server>[<routing>]<card and key codes> According to the present embodiment this format is updated to include demographic information:

<protocol><server>[<routing>]<card and key codesxdemographic indicator In the example query the <demographic indicator portion is used to select among multiple files on a portal server associated with each card code and/or key code. For example, when card 12 is swiped, and key 1 is pressed by a male, the query formulated by request generator 300 illustrated in Figure 6 may be: http://www.planetportal.eom/cards/12/1/male.html. This file would contain a URL tailored for a male interested in the product advertised by the card.

In cases where request generator 300 creates a request, and no demographic specific files are supplied by the receiving portal server, a webserver failover technique can be used to ensure that the user is supplied meaningful data. As described above, many modern web servers, including the Apache web server produced by the Apache Group (www.apache.org), allow web masters to specify files that will be returned should a request fail. These files can be specified per requested directory. To handle the case above, the proper redirect file would be used as the failover file assigned to: http://www.planetportal.eom/cards/12/1

That is, all users who request any file in: http://www.planetportal.eom/cards/12/1 , including http://www.planetportal.eom/cards/12/1/male.html, and http://www.planetportal.eom/cards/12/1/female.html would receive the redirect file associated with card 12, key 1 .

In some cases, the order of the <routing>, <card and button indicators;*, and <demographic indicator can be interchanged in some cases without materially affecting the invention. The fields in the example above can be transposed to be: http://www.planetportal.eom/cards/12/male/1 .html. or http://www.planetportal.eom/cards/male/12/1 .html. In all of these cases, the same file would be served. Using the technique described above, other individual demographic fields can be used, and multiple fields can be combined at the expense of complexity in the portal server file system structure.

Using Parameters to Communicate Demographic Information to the Portal Server

Portal server file system complexity can be saved at the expense of server-side processing. According to this aspect of the invention, demographic information is communicated to the portal server as parameters on the URL in a card-based web page query, rather than as file system specifier. The format of the URL becomes:

<protocol><server>[<routing>]<card and key codes>?<parameters>, where "?" is the standard indicator of the start of a list of parameters. In the example above where the user is male, the request becomes: http://www.planetportal.eom/cards/12/1 .html?gender=male or a similar format. Parameters can be combined in URLs such as: http://www.planetportal.eom/cards/12/1. html?gender=male&zipcode=27514& phonenumber=9195551212.

The portal server receiving the URL would use the file system to select the file as described above. In this example, the portal server would find the file "1.html" in the subdirectory "cards/12". However, in this case, the file could access the URL's parameters.

In most cases, HTML files don't access parameters, but server-side scripts such as CGI programs do. Thus, to generate demographic-based responses, the HTML file is typically replaced by a server-side script. In the present example, a web query directed to a CGI program might be: http://www.planetportal.eom/cards/12/1.cgi?gender=male The CGI program then uses standard web techniques to parse the parameters, and select among multiple redirect sites. An exemplary server side script suitable for demographic-information-based web page selection according to the present embodiment is as follows:

# ! /usr/bin/perl require "cgi-lib.pl" ; # standard cgi library

&ReadParse (\%input) ,- # Read parameters into name/value pairs in

# the %input hash table

# In this basic case, we assume that the # script is looking to send

# the user to different sites based upon

# gender. if ($input{ 'gender' } eq 'male') { $URL = 'http://www.men.com';

} elsif ($input{ 'gender' } eq 'female') {

$URL = 'http://www.women.com'; } else {

$URL = 'http://www.alien.com'; } print "Location: $URL\n\n" ;

The above script may be executed by a portal server to determine the URL to send to browser 302 illustrated in Figure 6 in response to a web server query. In the example, if the web server query includes a "male" parameter, browser 302 is redirected to http://www.men.com. If the gender parameter is "female", the portal server redirects browser 302 to http://www.women.com. If the gender parameter is not included or is not equal to male or female, browser 302 is redirected to a default web page, such as http://www.alien.com. Using server-side scripts to perform gender- based file server selection greatly reduces complexity in the portal server file system, but at the expense of running server-side scripts. Such scripts consume server cycles, and thus increase costs.

Intelligent client direction of card-code-based web server queries can be used to minimize the effect of .cgi processing on overall system performance. For example, servers can be divided into two groups - one group that provides only static content, such as .html files and another group that provides dynamic content, such as .cgi scripts. Queries requesting static content can be directed to the first group of servers, and queries requesting dynamic content can be directed to the second group of servers. A key assumption here is that the amount of static content will greatly outnumber CGI generated dynamic content, thus ensuring that the differences in overhead of delivering dynamic vs. static content would be offset by the significantly smaller number of requests for dynamic content. The more servers that need to be dedicated to dynamic content, clearly, the higher the cost.

Accessing Demographic Information Stored by a Portal Server

Based on a User ID Yet another alternative, illustrated in Figure 10, is to replace the demographic parameters in each web server query with a user identification (user ID). In Figure 10, portal server 108 has access to a demographic information database 800 containing demographic information pertaining to users of portal devices 100. When a user first installs request generator 300 and other portal client software 102, the user may be prompted for demographic information, such as gender, age, income level, etc. When the user enters the demographic information, that information may be uploaded to portal server 108 and stored in demographic information database 800. The demographic information for the user may be stored in a database record indexed by a unique user ID code. Portal server 108 may return the user ID code to request generator 300 when the user demographic information is stored in database 800.

When request generator 300 formulates a web server query, request generator 300 preferably includes the user ID in the query. An example, of such a query is as follows: http://www.planetportal.eom/cards/12/1.cgi?userlD=dlk12345

Upon receiving such a flow, a server-side script associated with portal server 108 parses the user ID from the query, and looks up the user's demographic record in demographic information database 800. Portal server 108 then uses the demographic information to select among multiple redirect sites. The selected redirect site is returned to browser 302, as described above. The advantage of this embodiment is that the entire demographic record is available to the server-side CGI program, even if the URL only specifies a single parameter (the user ID). However, this embodiment requires the deployment of a demographic database, which can increase costs. The previously-described techniques of demographic-parameter- based response generation, user-ID-based response generation, and default processing can be combined seamlessly into a single program, such as a CGI program, that may be invoked by portal server 108. Figure 11 illustrates exemplary steps that may be performed by a CGI program invoked by portal server 108 in processing demographic or user ID information in requests received from request generator 300. Referring to Figure 11 , in step ST1 , CGI program receives a request from request generator 300. In step ST2, the CGI program determines whether the request includes one or more demographic parameters. In step ST3, if the CGI program determines that one or more demographic parameters are present, in step ST4, the CGI program sends a redirect message to browser 302 based on the demographic parameters. For example, if the demographic parameters indicate that the user is a male, the redirection indicator sent to browser 302 may direct browser 302 to a website containing targeted advertisements for male users.

In step ST3, if the CGI program determines that demographic parameters are not present in the request, in step ST5, the CGI program determines whether a user ID is present in the request. In step ST6, if the CGI program determines if the user ID is present, in step ST7, the CGI program extracts demographic information from the demographic information database based on the user ID. In step ST8, the CGI program sends a demographic-information-based redirect message to browser 302 based on the information extracted from the database. In step ST6, if the CGI program determines that the user ID is not present, in step ST9, the CGI program sends a default redirect message to browser 302. Thus, in summary, request generator 300 and portal server 108 can corroborate to redirect browser 302 to demographic based websites.

Data Mining

The techniques described above select among static web-page alternatives. These techniques can be supplemented by employing data mining techniques. Data mining is a generic term that indicates data is scanned for patterns. For example, through data mining of its receipts, a grocery store might learn that bagels and cream cheese are frequently purchased together. After learning this fact, the store might locate these items closer together.

Techniques for data mining are well-known in the industry, and will not be discussed in depth here. The present embodiment applies data mining to web page selection.

Each card issuer, or an agent acting for the issuer, executes the following steps:

1 ) deploy a card in which each button mapped to an initial URL

2) collect data about card use 3) partition the data

4) perform pattern inferences

5) dynamically adjust URL mappings according to inferred data Each of these steps will now be discussed in more detail. In step (1 ), the card issuer prints a set of cards, each containing the same card code. The issuer, or an agent of the issuer, distributes the cards to some set of potential customers.

In step (2), as customers use the cards, data are collected at a central site. Figure 12 illustrates an exemplary system for collecting card usage data according to an embodiment of the present invention. In Figure 12, when a user inserts a card into reader 106 and presses one of the keys 106, an HTTP request flows from request generator 302 to portal server 108, as is described in detail above. In a preferred embodiment, portal server 108 comprises an Apache web server. As with many web servers, Apache web servers can be configured to log all incoming requests. The logging feature is preferably enabled.

With logging enabled, a record of each transaction is written to log file 1200 which is preferably stored on a stable medium, such as a disk drive. The HTTP requests created by request generator 300 contain, without limitation, the card code, key code, user ID, and other information. It is this information that is written to log file 1200. Thus, by enabling logging on the Apache server, and exploiting the careful creation of the HTTP requests, this feature enables the collection of data without any changes to a standard web server.

In a preferred embodiment, the HTTP requests are formatted as uniform resource locators (URLs) containing information, such as a card code, a key code, a device ID, etc., indicative of a web page access.

Because the requests are preferably formatted as URLs, the automatic logging functionality that is standard in most web servers may be used to log the requests. As a result, the need for additional logging functionality at the server is reduced.

In step (3), once the data are collected, the data are partitioned. Partitioning data can be as simple as retrieving all log records from log file 1200 for a single card. Retrieving log records for a single card is the typical case. However, in cases where an issuer deploys multiple cards (e.g., Coke and Diet Coke cards), the issuer can be allowed access to complex sets of data.

Similarly, the company collecting the data can allow access to results from cards issued by other companies, either individually, or in aggregate. Such data can help an issuer tailor their promotions. For example, if a cola manufacturer gains access to the results of card promotion by beer manufacturers, the cola manufacturer can learn about mechanisms that increase card usage. In a simple case, the cola manufacturer might learn that 10% discounts increase card usage rates 50%, and that 20% discounts increase rates 51%. From that information, the cola manufacture might conclude that a 10% discount is sufficient and provide a coupon for a 10% discount on a web site accessed by card usage.

The ability to generate revenue by selling card information from other card issuances is a novel feature of the present invention. For example, company A might collect card usage data that may be of interest to company B. Company A may sell the card usage for company A's cards to company B. Company B may then utilize data mining techniques, such as pattern inferencing, to increase usage of company B's cards. Because card usage data includes data that may be valuable across companies and across products, collecting card usage using the system illustrated in Figure 12 provides new revenue generation opportunities for card usage data collectors.

In step (4), the card issuer, or an agent of the issuer performs pattern inferences. One example of such an inference is the discount example given above. Such inferences are well known in data mining art, and will not be discussed in detail here. However, it should be noted that the data used for inferencing are not limited to data gathered in response to card usage. In some cases, these data might be supplemented with data obtained through other sources. For example, many clearinghouses sell mailing lists, some of which also contain prior purchasing behavior. This information will, in some cases, be used to enhance inferencing.

In step (5), the inferences are used to modify the URLs mapped by the card and key codes. Modifying the URL mapping, in a preferred embodiment of the invention, includes changing the redirect site in the HTML or CGI file stored in the portal server file system, as described in great detail above. The new URLs are chosen to better entice one or more demographic categories of user to utilize the card.

In one example, a card issued by a beer manufacturer might include two key mappings. On the first card insertion, the user is taken to the beer company's home page; the first key of keys 106 takes the user to a coupon web page that provides 10% discount on the next purchase; and the second key of keys 106 takes the user to an offer for a free calendar containing risque pictures. Upon mining the data, the beer company might learn that females predominately press key 1 , and males predominately press key 2. ln response, the beer company can change the initial-insertion site for females to be the discount page, and the page for males to be the calendar offer.

Virtually any data mining technique can be used, with associated dynamic adjustment to the URL mappings. This example is not intended to limit the invention.

Scoring Another novel feature of the present invention is the use of "scoring" to provide intelligent card-based web page selection. As used herein, a score is a value computed for a card user based on demographic information and observed behavior. In a preferred embodiment, the score is derived from a regression model. However, other models for computing a score are intended to be within the scope of the invention.

According to the present embodiment, each card user is observed to have both demographic characteristics (e.g., gender), and observed behaviors (e.g., how many times the user inserted the card 10). Card issuers are permitted to supply a model by which users are scored, and to supply URLs appropriate for each score.

Figure 13 illustrates a card-based web page access system that utilizes a scoring algorithm to send targeted web pages to card users. In Figure 13, scoring algorithm 1300 is operatively associated with portal server 108 to compute a score for each card user based on observed behaviors and information stored in demographic information/observed behaviors database 1302 for the user. When a user inserts a card into reader 105, the ensuing request carries the user's unique ID. The request is sent to portal server 108. Portal server 108 utilizes the user ID in the request to query database 1302 containing the user's demographics and observed behaviors. Portal server 108 retrieves information relevant to the user, and passes the information to scoring algorithm 1300. Scoring algorithm 1300 uses the information to calculate the score according to the supplied model. Based on this calculation, the URL appropriate for this score is returned to the user's browser using the redirect mechanism described above. For clarity, and without limitation, an example of utilizing a score to select a target web page is provided. A user may have a known set of demographics and behaviors. In this example, the user's income is $100,000, the user has 6 children, and the user works as a stock trader. The observed behavior collected for the user may indicate that the user visited a given site 37 times; visited another site 15 times. First, scoring algorithm 1300 translates the user's occupation, or class of occupation (e.g., white collar) into a score. In this example, it is assumed that a stock trader is "worth" 21 points.

Scoring algorithm 1300 may then use a regression model of the form: Score = b1^*v1 + b2^*v2 + ... + bN^*vN

In this case, there are five variables, which reduces the formula to: Score = b1^*v1 + b2^*v2 + b3^*v3 + b4*v4 + b5^*v5 Next, each parameter must be assigned a weighting appropriate for this model. In this example, the weighting assigned to each parameter is assumed to be: .006, .03, 7.65, .25, and .61. These weightings are preferably determined by the card issuer in a way that reflects the relevance of each item parameter to the card issuer's products. Substituting, the weightings in the expression listed above, the score is: Score = 006^*100,000 + .03^*6 + 7.65^*21 + .25^*37 + .61^*15, which rounds to a score of 779.

Once the score is computed, it is used to select the appropriate URL.

Preferably, the selection is accomplished by a CGI program running on portal server 108, but other equivalent technologies (such as servlets) can be used. An exemplary CGI program that may be executed by portal server 108 in selecting a web page based on a score is as follows:

# ! /usr/bin/perl require "cgi-lib .pi" ; # standard cgi library &ReadParse (\%values) ; # Read parameters into name/value

# pairs in the %input hash table

# In this basic case, it is assumed

# that the script is looking to send # the user to different sites based

# upon scoring of multiple parameters,

# here assigned the values bl ... b5.

# Values for corresponding weighting

# of behavior params are kept in the # hash table %weight, which may be

# imported many ways, but in this case

# is simply defined by assignment.

%weight = ( 'bl' => .006,

'b2' => .03,

'b3' => 7.65,

'b4' => .25,

'b5' => .61 );

$score = 0; # initialize score foreach $key (keys %values) { # Iterate through all # params passed to script if ($key =~ /b\n+/) { # If this is a behavior

# value b0..±>n

$score += ($values{ '$key' } * $weight{ ' $key' } ) ; } # Add computed value to

# the score } if ($score > 700) {

$URL = 'http://www.company.com/ideal_customer.html'; } elsif ($score > 300) {

$URL = 'http://www.company.com/good_customer.html'; } else { $URL = 'http://www.company.com/welcome.html';

} print "Location: $URL\n\n" ;

In the example script, a score is computed based on a weighted sum of parameter values. This score is then compared to predetermined thresholds of 300 and 700. If the score is greater than 700, the user is directed to the URL http://www.company.com/ideal_customer.html. If the user's score is between 300 and 700, the user is directed to the URL http://www.company.com/good_customer.html. Finally, if the user score is below 300, the user is directed to URL: http://www.company.com/welcome.html. In this example, the user's score of 779 is considered high, so the user is redirected to a site offering premier service, such as a large discount for a first purchase. In this example, by employing the scoring technique, the card issuer can restrict its best offers for users that the scoring algorithm predicts will become better customers, thus maximizing revenue to the card issuer. This illustrates the value of scoring in response to card requests.

Figure 14 is a flowchart illustrating exemplary steps that may be performed by portal server 108 and scoring algorithm 1300 in redirecting users to preferred user type web pages based on scoring. In step ST1 , portal server 108 receives a card-based web page query from a user. This query may be generated upon insertion of a card into reader 105 illustrated in Figure 12. In step ST2, portal server 108 extracts demographic and behavioral information regarding the user from database 1302 based on information contained in the request. For example, the request may include a user ID. In step ST3, scoring algorithm 1300 computes a score for the end user based on the data extracted from database 1302. In step ST4, portal server 108 compares the score to a predetermined value or values. In step

ST5, portal server 108 modifies a redirection indication to be sent to the end user based on the comparison results. As stated above, in one embodiment, a higher score may send the user to a web page that is more advantageous to the user. Thus, the combination of scoring and card based web page access according to the present embodiment allows card issuers to give preferential treatment to good customers.

Since the card issuer is provided additional value by scoring-based web page selection, the firm coordinating the card requests gains another opportunity to generate additional revenue from the card issuer. In one model, card issuers may be charged a fee for employing scoring to select URLs. In another model, one fee (possibly zero) may be charged for employing a standard scoring technique, and a second fee, typically higher will be charged for the issuer to supply their own model. In yet another model, the card issuer is charged by the number of different URLs they choose to deploy. Such a model can be combined with others outlined above

Automated Card Enablement Process Once sufficient processes have been deployed to handle a large volume of card requests, the bottleneck becomes the efficient process of producing and distributing cards. This aspect of the invention provides automated methods and systems for designing cards, manufacturing cards, and deploying the associated URLs. These tasks of creating manufacturing, and deploying cards are collectively referred to herein as card enablement.

Figure 15 illustrates the main components of a system for card enablement according to an embodiment of the present invention. The main components of the system include: • Request coordinator 1500

• Art generator 1502

• Identification database 1504

• Printer 1506

• Fulfillment coordinator 1508 • Portal server 108

Each of these components will now be explained in more detail.

Request coordinator 1500 orchestrates the entire process of card enablement, interacting with the other components of the system. Request coordinator 1500 might include centralized software for coordinating actions associated with card enablement.

A business might operate request coordinator 1500, and other components of this system. This party is referred to herein as the "firm." This firm can generate revenue from the business model associated with the process. Request coordinator 1500 executes the following steps:

1 ) Gather issuer input

2) Obtain a unique identifier

3) Register the card's URLs with the proper portal server Optionally, request coordinator 1500 can execute one of more of the follow steps to simplify fulfillment of the card order.

4) create an image for the card

5) route the order to a printer

6) arrange fulfillment of the cards Each of these steps is now discussed in more detail.

The first set of steps, i.e., steps 1 - 3, allows a card issuer to obtain a code, and prepares the portal server or servers to handle requests associated with the code.

In step (1 ), request coordinator 1500 gathers information from the card issuer. At a minimum, this includes one or more URLs associated with the card, and an indication of how those URLs are to map to keys 106 and card inserts associated with portal device 100.

Optionally, request coordinator 1500 can gather other data, such as information about the issuer, billing information for the account, a user ID for this account and an associated password. This information is stored in customer database 1510.

In step (2), request coordinator 1500 queries ID database 1504 to obtain a unique code for a card. Preferably, to avoid conflicts, ID database 1504 issues codes sequentially. As an improvement to the simple scenario, a card issuer can request blocks of similar code, which are then reserved by ID database 1504. To use a pre-reserved code, the card issuer supplies the code, along with identification (preferably a user ID and password) to request coordinator 1504. The request coordinator 1500 validates the user's identity using the customer database, then proceeds with the process described below.

Optionally, the firm can charge a fee for code issuance.

Finally, request coordinator 1500 establishes the proper file infrastructure to handle card request. Preferably, this entails storing files in directories containing redirect indicators in the structure described at length above. For example, if card 15 was issued, and the card issuer indicated the www.planetportal.com was to be associated with key 1 , then a file containing a redirect indicator (as described above) would be created in a directory called "15", with the file named "1.html". Portal server 108 is then prepared to handle requests for this card.

The present invention is not limited to storing redirection indicators in the file system of a portal server 108. The code mappings can be stored in a database that is accessed by a portal server 108 without departing from the scope of the invention. The firm can charge a fee for establishing and/or hosting the URL mappings either on a portal server file system or in a database.

Optionally, request coordinator 1500 can handle other portions of the card enablement process, requiring slight modifications to the process described above. These other portions and modifications are now discussed in more detail. First, each card must carry a printed version of the code. In addition to the artwork typically carried on card, the code must be printed. First, request generator 1500 receives from the issuer an image format for the card. Examples of image formats include, but are not limited to graphical information format (GIF), bitmap (BMP), and joint picture experts group (JPEG). This supplements the input gathering step listed above.

Next, the code is translated into binary format. Preferably, the integer code is converted into its binary representation. For example, in a 3-bit code, 0 is represented as 000, 1 as 001 , 2 as 010, etc. The binary code is then converted into a machine-readable format. Many technologies exist for such conversion. In one simple example, the binary digit '0' is represented by a reflective area of the card, and a '1 ' is represented as a non-reflective area. A reader for such a reflective/non-reflective encoding is described in above- referenced co-pending U.S. Patent Application Serial No. 09/440,318. This machine-readable format is then converted into an image representation, which is superimposed on the image supplied by the issuer. This process will be described with respect to Figure 16. In Figure 16, request coordinator 1500 obtains an image of card logo and artwork information 1600 from the card issuer. Request generator 1500 then generates a unique card code for the present batch of cards and generates a machine-readable version of the code. This machine-readable version is placed at location 1602 of an image of a slidecard. Finally, request coordinator 1500 superimposes image 1600 containing the artwork onto image 1602 containing the code to produce completed slidecard image 1604. Next, in step (5) should the issuer choose, completed slidecard image 1604 can be routed to printer 1506. This requires modification to step (1 ) such that the issuer optionally provides the quantity of cards desired, along with billing information. Request coordinator 1500 stores the quantity locally, and stores the billing information in the customer database. The image file for the card is then routed to an appropriate printer.

There are at least two alternatives for billing. First, printer 1506 is given the issuer's billing information, and bills the issuer directly. Optionally, the firm operating request coordinator 1500 can charge a fee to printer 1506 for the referral. Second, printer 1506 can bill the firm, which in turn bills the issuer. Optionally, the firm can include a markup to generate revenue from the act of printing.

In step (6), the firm can handle card fulfillment. In this optional case, in step (1 ), request coordinator 1500 is provided with a list of addresses to which cards are to be mailed. When the cards return from printer 1506, as described in step (5), they are sent to the addresses provided in step (1 ). This act can be performed by the firm, or by an agent of the firm that specialized in mass mailing.

Step (6) provides three revenue opportunities. First, the card issuer can be charged a fee above the cost of fulfillment. Second, the firm can collect information about which consumers are sent which card. This information can be used to target consumers for future promotions. Firms wishing to access information about prior mailings would be charged a fee. Finally, it is possible in some cases to associate a unique identifier with each card. This identifier is in addition to the card code discussed above. When a user inserts a card tagged with this unique identifier, information about the swipe is collected (as described in detail above). This information can be used to create a profile user behavior. Such user profiles have proven to be valuable to advertisers. Thus, the firm can charge advertisers a fee for access to this information.

In summary, this mechanism above describes a method for automated card enablement. Such a process makes it easier for card issuers to obtain and distribute cards, thus increasing the likelihood of such issuances. In addition, the enablement process presents several opportunities for the firm operating this process to generate revenue.

It will be understood that various details of the invention may be changed without departing from the scope of the invention. Furthermore, the foregoing description is for the purpose of illustration only, and not for the purpose of limitation — the invention being defined by the claims.

Claims

CLAIMSWhat is claimed is:

1. A system for facilitating access to a web page, the system comprising: (a) a reader for reading a code from a physical medium; and (b) a request generator operatively associated with the reader for receiving the code and, in response, for formulating a query containing information usable by a server for locating a file containing web page information without using a code database.

2. The system of claim 1 wherein the server is a web server having a file system and the information generated by the request generator maps to a directory structure in the web server file system.

3. The system of claim 2 wherein the information generated by the request generator includes a uniform resource locator (URL) containing a directory and a file name in the web server file system.

4. The system of claim 1 comprising at least one key associated with the reader for generating a key code in response to activation of the key by a user.

5. The system of claim 4 wherein the request generator receives the key code and generates the information in the query based on the key code and the code read from the physical medium.

6. The system of claim 5 wherein the physical medium is a card, the code read from the physical medium is a card code, and the request generator is adapted to generate the information in the query based on the key code and the card code.

7. The system for claim 6 wherein the reader is embedded in a portal device.

8. The system of claim 6 wherein the reader is embedded in a keyboard.

9. The system of claim 6 wherein the server is a web server having a file system, the information in the query includes a directory and a file name in the web server file system, the directory corresponds to the card code, and the file name corresponds to the key code.

10. The system of claim 9 wherein the information generated by the request generator includes a uniform resource locator (URL) containing the directory and file- name in the web server file system.

1 1. The system of claim 1 wherein the web page information comprises a redirection indicator for directing a browser to a desired web page.

12. The system of claim 1 wherein the web page information is a desired web page.

13. The system of claim 12 wherein the desired web page includes extensible markup language (XML) data.

14. The system of claim 1 wherein the query includes information for selecting among a plurality of servers to process the query.

15. The system of claim 14 wherein the information for selecting among the servers includes information for selecting among the servers based on geographic location of the servers.

16. The system of claim 14 wherein the request generator is adapted to use the code read from the physical medium to determine the information for selecting among the servers based on geographic location of the servers.

17. The system of claim 14 wherein the request generator is adapted to use the code read from the physical medium to generate the information for selecting among the servers.

18. The system of claim 17 wherein the request generator is adapted to apply a modulus function to the code read from the physical medium to generate the information for selecting among the servers.

19. The system of claim 1 wherein the query includes information for selecting between static and dynamic web page content.

20. The system of claim 19 wherein the request generator is adapted to use the code read from the physical medium to generate the information for selecting between static and dynamic web page content.

21. The system of claim 20 wherein the request generator is adapted to use the code to select a file extension to be appended to a file name in the query for selecting between static and dynamic web page content.

22. The system of claim 1 further comprising: (c) a user application operatively associated with the request generator for sending the query over a network, receiving responses from the network, and displaying the responses to a user; and

(d) a server for receiving the query and sending the web page information to the user application in response to the query.

23. The system of claim 22 comprising at least one load balancer for receiving the query and selecting a server for processing the query.

24. The system of claim 22 wherein the server utilizes the information in the query to locate the web page information without using a code database.

25. The system of claim 22 wherein the server is adapted to determine whether the query is erroneously addressed, and, in response to determining that the query is erroneously addressed, the server is adapted to forward the query to a second server.

26. The system of claim 25 wherein the server is adapted to locate the second server based on the code read from the physical medium.

27. The system of claim 1 wherein the request generator is adapted to generate a default key code in response to failing to receive a key code from the reader.

28. The system of claim 27 wherein the request generator is adapted to use the default key code and the code read from the physical medium to generate the information to be included in the query.

29. The system of claim 1 wherein the request generator is adapted to include a user demographic information indicator in the query usable by the server to locate demographic information regarding the user and wherein the system further comprises a server for locating the user demographic information based on the user demographic information indicator.

30. The system of claim 29 wherein the user demographic information indicator is a user ID.

31. The system of claim 30 wherein the server performs a lookup in a user demographic information database to locate the user demographic information.

32. The system of claim 29 comprising a scoring algorithm operatively associated with the server for computing a score based on the user demographic information.

33. The system of claim 32 wherein the scoring algorithm is adapted to compute the score based on user behavior information in addition to the user demographic information.

34. The system of claim 33 wherein the server selects a file containing the web page information based on the score and the code read from the physical medium.

35. The system of claim 33 wherein the server selects a uniform resource locator (URL) from a list of URLs based on the score and the code read from the physical medium.

36. The system of claim 33 wherein the user behavior information used to compute the score includes information regarding prior usage of the physical medium by the user.

37. The system of claim 36 wherein the server is adapted to include product or service discount information in the web page information based on the score.

38. The system of claim 37 wherein the server is adapted to include product or service discount information in the web page information in response to a score indicating an increased likelihood that the user will purchase the good or service.

39. The system of claim 29 wherein the server includes a log file for logging the query from the request generator.

40. A method for using data mining to target a web page to a user, the method comprising: (a) at a server, collecting data regarding usage of slidecards to access web pages;

(b) inferring a pattern from the data; and

(c) changing a web page address mapping associated with a slidecard at the server based on the pattern.

41. The method of claim 40 wherein collecting data regarding usage of slidecards to access desired web pages includes logging slidecard-based queries in a log file associated with the server.

42. The method of claim 41 comprising transferring the queries from the log file to a database.

43. The method of claim 42 wherein inferring a pattern from the data includes inferring a pattern from the data stored in the database.

44. The method of claim 41 wherein logging slidecard-based queries in the log file includes logging a card code associated with each query in the log file.

45. The method of claim 41 wherein logging slidecard-based queries in the log file includes logging a key code associated with each query in the log file.

46. The method of claim 41 wherein logging slidecard-based queries in the log file includes logging a user ID associated with each query in the log file.

47. The method of claim 41 wherein logging slidecard-based queries in the log file includes logging, for each query, a device ID indicative of a reader that read each slidecard in the log file.

48. A method for sending targeted web page information to a user based on slidecard usage, the method comprising: (a) receiving, from a request generator, a web page request generated in response to insertion of a slidecard in a card reader;

(b) determining whether the request includes demographic information relating to a user; and

(c) in response to determining that the request contains demographic information relating to the user, forwarding targeted web page information to the user based on the demographic information.

49. The method of claim 48 wherein the request is a uniform resource locator (URL); the demographic information is included in the URL, and determining whether the request includes demographic information includes parsing the URL for the demographic information.

50. The method of claim 48 wherein the request is a uniform resource locator (URL), the demographic information is included as at least one parameter to the URL, and determining whether the request includes demographic information comprises parsing the URL parameter.

51. The method of claim 48 comprising, in response to determining that the request does not include demographic information, forwarding default web page information to the user based on the request.

52. The method of claim 48 wherein determining whether the request contains demographic information includes executing a computer program to process the request.

53. The method of claim 52 wherein executing a computer program comprises executing a common gateway interface (cgi) program.

54. The method of claim 48 comprising, in response to determining that the request does not contain demographic information, determining whether the request contains a user ID.

55. The method of claim 54 comprising, in response to determining that the request contains a user ID, extracting demographic information for the user from a database based on the user ID.

56. The method of claim 55, comprising sending targeted web page information to the user based on the demographic information extracted from the database.

57. A method for using scoring to send targeted web page information to a card user, the method comprising:

(a) receiving a query containing a card code and an indicator for obtaining demographic information regarding a card user;

(b) accessing a database to obtain the demographic information based on the indicator; (c) determining a score for the card user based on the demographic information; and

(d) returning targeted web page information to the card user based on the score.

58. The method of claim 57 wherein returning targeted web page information to the card user based on the score includes comparing the score to a predetermined value, and selecting the targeted web page information based on a relationship between the score and the predetermined value.

59. The method of claim 57 comprising charging a card issuer for determining the score for the card user.

60. The method of claim 57 comprising charging a card issuer for access to the demographic information stored in the database.

61. The method of claim 57 wherein determining a score for the card user includes calculating the score based on the demographic information using a predetermined scoring algorithm.

62. The method of claim 61 wherein calculating a score using a predetermined scoring algorithm includes calculating a score based on a regression model.

63. The method of claim 57 wherein determining a score for the card user includes performing a lookup in a score database containing pre-computed score values based on the demographic information to obtain the score.

64. The method of claim 57 wherein the indicator for obtaining demographic information includes a user ID.

65. The method of claim 57 wherein the demographic information includes at least one of: the card user's occupation, the card user's income, the card user's class of occupation, and information regarding the card user's family size.

66. The method of claim 57 wherein determining the score for the card user includes determining the score based on behavioral information for the card user and demographic information for the card user.

67. The method of claim 66 wherein the behavioral information includes the number of times the user has accessed one or more web pages.

68. An automated process for producing and distributing slidecards, the process comprising:

(a) collecting input from a card issuer including information required for issuing a predetermined number of slidecards;

(b) determining a unique card code for the slidecards; and (c) storing uniform resource locators (URLs) associated with the cards in a directory structure in a server file system, wherein at least a portion of the directory structure corresponds to the card code.

69. The process of claim 68 wherein collecting input from a card issuer includes collecting the URLs to be stored in the server file system.

70. The process of claim 68 wherein collecting input from a card issuer includes collecting billing information from the card issuer for billing the card issuer for issuance of the cards.

71 . The process of claim 68 wherein determining a unique card code for the slidecards includes extracting the unique card code from a database.

72. The method of claim 71 wherein determining a unique card code for the slidecards includes extracting a block of unique card codes from the database.

73. The process of claim 68 comprising charging a fee to the card issuer for using the unique card code.

74. The process of claim 68 wherein storing URLs associated with the cards in a directory structure in a server file system includes storing URLs associated with the cards in a directory structure in a web server file system.

75. The process of claim 68 further comprising automatically generating a pattern printable on the slidecards, wherein the pattern encodes the card code.

76. The process of claim 75 wherein automatically generating a printable pattern includes automatically generating a graphics information (GIF) file.

77. The process of claim 75 wherein automatically generating a printable pattern includes automatically generating a joint picture experts group (JPEG) file.

78. The process of claim 75 wherein automatically generating a printable pattern includes automatically generating a bitmap file.

79. The process of claim 75 comprising forwarding the slidecards to a printer to receive the printable patterns.

80. The process of claim 79 comprising charging the card issuer a fee for routing the slidecards to the printer.

81. The process of claim 79 comprising routing the cards from the printer to a fulfillment coordinator.

82. The process of claim 68 comprising charging the card issuer for access to information regarding prior slidecard promotions.

83. The process of claim 68 comprising charging the card issuer for storing the URLs in the server file system.

84. A process for recording events associated with a web page comprising:

(a) generating information indicative of the occurrence of an event associated with a web page access; and

(b) in response to generation of the information, encoding the information as a uniform resource locator (URL).

85. The process of claim 84 comprising forwarding the URL to a server.

86. The process of claim 85 wherein forwarding the URL to a server comprises forwarding the URL to a web server.

87. The process of claim 86 comprising, at the web server, logging the URL to a computer-readable medium.

88. The process of claim 87 wherein the event is insertion of a slidecard into a card reader.

89. The process of claim 88 wherein the URL includes a card code corresponding to the slidecard.

90. The process of claim 89 wherein the URL includes information indicative of a card insertion.

91 . The process of claim 90 wherein the information indicative of a card insertion is a key code.

92. A computer program product comprising computer-executable instructions embodied in a computer-readable medium for performing steps comprising: (a) receiving a card code from a portal device in response to reading of a card by the portal device;

(b) algorithmically determining a portal server selection code based on the card code;

(c) determining a portal server name based on the portal server selection code; and

(d) formulating a web page query to the portal server specified by the portal server name.

93. The computer program product to claim 92 wherein computing a portal server selection code includes utilizing a modulus function.

94. The computer program product of claim 93 wherein utilizing a modulus function includes computing:

(card_code)MOD(num_portal_servers), where card_code is the card code, MOD is the modulus function, and num_portal_servers is the number of portal servers available to process the web page query.

95. The computer program product of claim 92 wherein determining a portal server name based on the portal server selection code includes selecting the name from a list of portal server names based on the portal server selection code.

96. The computer program product of claim 92 wherein determining a portal server name based on the portal server selection code includes inserting the portal server selection code into a character string to form the portal server name.