Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q30/00—Commerce
  • G06Q30/02—Marketing; Price estimation or determination; Fundraising

Definitions

• the present invention is directed to the field of electronic advertising and content delivery.
• Web pages are typically encoded in HyperText Markup Language ("HTML").
• HTML HyperText Markup Language
• URL Uniform Resource Locator
• HTTP request HyperText Transfer Protocol request
• a user in order to retrieve and display a particular web page, a user causes his or her web browser to issue an HTTP request for the URL of the web page.
• the user may do so by, for example, typing the URL into a URL field of the browser, or by selecting a link on a currently-displayed web page or a bookmark in a bookmark list.
• the browser transmits the HTTP request to the web server on which the web page resides, which replies with an HTTP response containing the requested web page, also called an HTML document.
• the browser receives the HTTP response, it displays the contained web page. In this manner, the user may retrieve and display a web page describing a particular product and offering it for sale.
• the user may wish to read a review of the product, determine whether the product can be purchased for a lower price from another vendor, or identify alternatives to the product. While this additional information is often available via the Internet, to obtain it the user generally must invest significant additional effort locating and retrieving the web pages containing this additional information. Further, even after the user has invested this additional effort, the web pages containing the additional information typically visually replace or obscure the original web page, making it difficult for the user to both at the same time.
• Internet advertising refers to the practice of including advertisements in web pages.
• Internet advertising involves purchasing from a publisher space in web pages served by the publisher. Advertisements are then inserted into these web pages in positions selected by the publisher and with the publisher's cooperation.
• a facility for adding advertising to a web page without the participation of the publisher would provide added flexibility to the advertiser.
• Figure 1 is a network diagram showing the environment in which the facility preferably operates.
• Figure 2 is a high-level block diagram of the proxy server computer system.
• Figure 3 is a flow diagram showing the steps preferably performed by the facility when an HTTP request is received from the client.
• Figure 4 is a data flow diagram showing the makeup of a sample document processing pipeline.
• Figure 5 is a flow diagram showing the steps preferably performed by the facility when it receives an HTTP response from a web server.
• Figure 6 is a display diagram showing the original web page as it would be rendered from the HTTP response body shown in Code Block 4 if received by a browser without having been modified by the facility.
• Figure 7 is a display diagram showing the sample web page as rendered by the client's browser after being modified by the facility.
• Figure 8 is a display diagram showing the rendered modified web page with its supplemental information bar visually murirnized.
• Figure 9 is a data flow diagram showing conventional proxying of a secure web conversation.
• Figure 10 is a data flow diagram showing proxying of a secure web conversation by the facility.
• a software facility for performing commercial activity in conjunction with document retrieval (“the facility”) is provided.
• the facility preferably utilizes an intermediary computer system, such as a proxy server, through which all document retrieval requests from a particular user and the resultant document retrieval responses are routed, to examine documents during their retrieval, and identify additional, related information to be displayed in conjunction with the retrieved documents.
• the facility causes such additional information to be displayed in conjunction with a retrieved document by modifying the document to contain the additional information.
• the facility When the facility receives in the intermediate computer system a document retrieval request from the user of a client, such as a request for a web page, the facility replaces the indication the request originated at the client with an indication that it originated at the intermediate computer system and forwards it to the server.
• the server When the server receives the request, it prepares a response containing the requested document and returns it to the facility on the intermediate computer system. At this point, the facility modifies the document contained by the response to include the additional, related information and forwards the response to the client.
• the information added to the document is preferably targeted based upon the contents of the document and/or a profile characterizing the user maintained by the facility.
• the added information can include advertising, or additional relevant content. For example, for a document containing an offer for sale of a product, the facility may add a review of that product, information about a competing offer for sale, or links to documents frequently requested by other users requesting the current document.
• FIG. 1 is a network diagram showing the environment in which the facility preferably operates.
• a client computer system 101 connects to the Internet 120 via an Internet Service Provider ("ISP") 110.
• ISP Internet Service Provider
• traffic passing between client computer system 101 and the Internet 120 is redirected by a layer 4 switch 113 through a proxy server 111 and a router 112.
• the facility, which processes web pages passing from web servers such as web servers 131-133 to the client computer system is preferably implemented in proxy server 111.
• proxy server 111 In addition to being used by client computer systems such as client computer system 101 that use ISP 110 which operates the proxy server 111, an alternate configuration shows the proxy server to be utilized by client computer systems using other ISPs, such as client computer system 151 using ISP 140. In this alternate configuration, a proxy auto-configuration file is sent to the browser residing on the client computer system 151 which directs the browser to send requests through the proxy server 111.
• the proxy server 111 may also be installed in a collocation facility not associated with an ISP.
• FIG. 2 is a high-level block diagram of the proxy server computer system.
• the proxy server 111 contains a memory 210.
• the memory 210 preferably contains the facility 211, as well as scripts 212, profiles 213, and cookies 214 used by the facility. While items 211-214 are preferably stored in memory while being used, those skilled in the art will appreciate that these items, or portions of them, may be transferred between memory and a persistent storage device 202 for purposes of memory management and data integrity.
• the proxy server fiirther contains one or more central processing units (CPUs) 201 for executing programs, such as programs comprising the facility 211, and a computer-readable medium drive 203 for reading information or installing programs such as those comprising the facility from computer-readable media, such as a floppy disk, a CD ROM or a DVD. While preferred embodiments are described in terms of the environment described above, those skilled in the art will appreciate that the facility may be implemented in a variety of other environments, including various other combinations of computer systems or similar devices connected in various ways. The operation of the facility to process an HTTP request and the resulting HTTP response is described in detail below. To more fully illustrate the design and operation of the facility, this description is conducted in conjunction with an example.
• FIG. 3 is a flow diagram showing the steps preferably performed by the facility when an HTTP request is received from the client.
• the facility determines the host and path of the web server to which the HTTP request is directed. If the HTTP request is a proxy request, the facility extracts the host and the path from its URL. If the HTTP request is not a proxy request, the facility extracts the host from the host header field of the HTTP request.
• Code Block 1 shows a sample HTTP request received by the facility.
• 1 GET http //www. lava-lampsdirect . com/lava-lamp . html HTTP/1. 0
• the sample HTTP request in Code Block 1 is a proxy request, so the facility in step 301 extracts from its URL the host, "www.lava-lampsdirect.com", and its path, "lava-lamp.html”.
• the facility uses the host and path determined in step 301 to determine the sequence of processing specifications to apply in processing the HTTP response that will be produced by the web server in response to the HTTP request.
• the facility preferably maintains a table mapping regular expressions matching a set of URI's (host/path combined) to sequences of document processing specification identifiers each identifying a document processing specification.
• the facility determines in step 302 that, based upon the web server host and path extracted from the sample HTTP request, the following sequence of processing specifications will be applied to the corresponding HTTP response: First, a document processing specification to extract product data from the web page; second, a document processing specification to add supplemental information to the web page; and third, a document processing specification to rewrite secure references in the web page to refer to a facility.
• these three document processing specifications are implemented as procedural scripts expressed in a scripting language similar to Perl. These scripts are shown below in Code Blocks 2, 3, and 4, respectively, and discussed further below.
• step 303 the facility constructs, in accordance with the sequence determined in step 302, a processing pipeline that will later be used by the facility to process the HTTP response generated by the web server in response to this HTTP request.
• step 303 involves instantiating a document processing, or "parser,” object for each processing specification, storing in each document processing object a pointer to the corresponding document processing specification, and linking the objects together in the same sequence as that specified for the document processing specifications.
• the facility preferably registers the constructed pipeline with an HTTP callback so that, when the corresponding HTTP response is returned from the server, it is submitted to the pipeline for processing.
• FIG. 4 is a data flow diagram showing the makeup of a sample document processing pipeline.
• the document processing pipeline 420 is comprised of three document processing specifications 421-423.
• the facility submits the portion of the HTML document 410 to a first document processing specification for extracting product data from the document 421.
• the document processing specification 421 processes the received portion of the HTML document, as well as an earlier-received HTML that has been retained by this document processing specification for fiirther processing, to extract product data from the document.
• Any HTML content completely processed by document processing specification 421 is passed to document processing specification 422, which processes the HTML to add supplemental information to the web page.
• Any HTML content completely processed by document processing specification 422 is passed to document processing specification 423 to rewrite secure references occurring in the HTML content.
• Any HTML content completely processed by document processing specification 423 is transmitted to the client as HTML portion 430.
• step 304 the facility generates an HTTP request to send to the web server based upon the HTTP request received from the client.
• the HTTP request generated by the facility in step 304 is derived from the HTTP request received by the facility from the client shown in Code Block 1.
• the actual request is generated by connecting to the web server identified by the host portion of the URI in the proxy request and sending the path information as the request.
• This step is the same processing typically performed in a proxy server.
• step 305 if the cookie maintenance service provided by the facility is active for this client, web server, and request, then the facility continues the step 306, or else the facility continues the step 307.
• the cookie maintenance service is typically active for all pages requested from sites for which secure requests need to be processed.
• step 306 the facility adds a cookie for this client, web server to the HTTP request generating step 304.
• the facility preferably maintains a table of client cookie values and expiration dates indexed by client and sub-indexed by domain and path. This is similar to the cookie storage normally performed by the browser when the facility is not present.
• step 306 the facility continues to step 307.
• step 307 the facility sends the generated HTTP request to the web server, using the host and path determined in step 301. After step 307, these steps conclude.
• FIG. 5 is a flow diagram showing the steps preferably performed by the facility when it receives an HTTP response from a web server.
• the facility first receives the header of the HTTP response from the web server.
• a sample HTTP response header is shown in Code Block 2.
• Lines 4-5 of the sample received header shown in Code Block 2 contain a set-cookie command instructing the browser that receives it to set a cookie named "USER ID” to a value of "01203" for the domain "lava-lampsdirect.com.”
• the sample received header contains a content-length field indicating that the body of the HTTP response that follows the header is 3686 bytes long.
• step 502 the facility replaces a content-length header field in a received header with an indication that the proxy server's connection with the client computer system will be explicitly closed after the entire response has been sent to the client.
• the facility makes it possible to begin sending the processed response to the client before it has received and processed the original response from the web server in its entirety, and therefore knows the final length of the processed response.
• step 503 if the cookie maintenance service is active for this client and web server, then the facility continues in step 504, else the facility continues in step 505.
• step 504 the facility removes from the received header any set-cookie fields, and processes the set-cookie command of each such set-cookie field against the table of client cookie values maintained by the facility to set the cookie values specified in the commands. After step 504, the facility continues in step 505.
• step 505 the facility sends the header to the client.
• Code Block 3 below shows the contents of the sample received header shown in Code Block 2 transmitted to the client after modification by the facility.
• step 502 replaced the content-length field on line 6 of Code Block 2 with the connection close field on line 4 of Code Block 3. It can further be seen that in step 504 the facility will move the set-cookie field occurring on lines 4-5 in Code Block 2.
• step 506 the facility receives a portion of the body of the
• step 507 the facility submits the received portion of the body to the document processing pipeline constructed in response to the corresponding HTTP request.
• the facility processes body data through the pipeline constructed for the HTTP response in step 303 by passing output generated by each parser object to the next one.
• step 509 after processing the data through the pipeline, the facility sends to the client any content emerging from the pipeline.
• step 510 if a portion of the body received in step 506 contains the end of the HTTP response, then the facility continues in step 511, else the facility continues in step 506 to receive the next portion of the body.
• step 511 the facility explicitly closes the connection with the client and flushes the pipeline by sending an EOF (end of file) message to the pipeline.
• This message indicates to the parser objects that no more html data is forthcoming, so any data still being accumulated should be sent on without further processing.
• step 512 the facility deletes the document processing pipeline. After step 512, these steps conclude.
• Code Block 4 shows a sample HTTP response body received by the facility.
• Lava has a calming effect, as it 53 gently
• Figure 6 is a display diagram showing the original web page as it would be rendered from the HTTP response body shown in Code Block 4 if received by a browser without having been modified by the facility.
• a browser window 600 contains a web page rendering window 610.
• the web page rendering window 610 in turn contains the rendered contents of the unmodified web page.
• the rendered web page includes information about a lava-lamp product, including a product name 621, a product item number 622, a textual description of the product 623, a price for the product 624, and a picture of the product 625.
• the rendered web page further includes a purchasing control 631 that may be operated by the user in order to buy the product from the publisher of the web page, as well as a secure link 641 to a separate account management web page published by the publisher of the current web page.
• Code Block 5 shows the HTTP response body preferably transmitted to the client after modification by the facility in accordance with document processing specifications 421-423 shown in Figure 4.
• Lava has a calming effect, as it 54 gently
• Figure 7 is a display diagram showing the sample web page as rendered by the client's browser after being modified by the facility.
• the application of document processing pipeline 420 shown in Figure 4 can be seen in comparing Figures 6 and 7.
• the facility extracts from the web page and stores in its database such information as the item brand "Hot Lava” and description "motion lamp” 621, the item number "groovy 321" 622 and the item price "$99.99" 624.
• the facility modifies the title bar of the browser window 600 to include a user and a pod name as shown in the title bar of browser window 700.
• the facility further adds a supplemental information bar 750 to the web page rendering area 710.
• the supplemental information bar includes links, such as a link 751 to add the product described in the web page to a wish list maintained for the user, a link 752 to a page containing information for the user, a link 753 to disable the facility and/or the display of the supplemental information bar, and a link 754 to a help page, and a link 755 for switching to a different user.
• the supplemental information bar further contains information produced by three features: a Community feature 760, an AuctionWatch feature 770, and a PriceCompare feature 780.
• the Community feature contain links 761 and 762 to two products that are popular with other users that have requested information about and/or purchased the lava-lamp product.
• the AuctionWatch feature contains two links 771 and 772 to on-line auctions in which the lava-lamp product is offered for sale.
• the PriceCompare feature contains two links 781 and 782 to other web-based merchants that are offering the lava-lamp product for sale at lower prices.
• the facility modifies the URL for secure link 641 to refer to the facility rather than to the web server to which it originally referred.
• Figure 8 is a display diagram showing the rendered modified web page with its supplemental information bar visually minimized.
• the supplemental information bar 750 has been replaced with a much smaller supplemental information bar icon 890 by selecting a minimize control of the supplemental information bar 750. This enables the user to view any content of the original web page that may be obscured by the display of the supplemental information bar 750.
• the facility uses procedural scripts as document processing specifications.
• Such procedural scripts are preferably expressed in a command language similar to Perl called "ZCL.”
• ZCL is described at a high level herein, and is described in greater detail in Appendix 1 which follows hereafter.
• a parser in the document processing pipeline is to process the HTML content that it receives from the previous link in the chain by applying its ZCL script to that stream of data.
• a simple ZCL script comprises a set of "SELECT" statements that indicate portions of the incoming page to which to apply commands. The commands to be applied are attached to each "SELECT" statement.
• the parser accumulates all HTML data until it encounters data that matches the regular expression that indicates that the current "SELECT" statement has been satisfied. When the termination expression is satisfied, the parser then applies all the commands to the data grabbed from the page, returns the processed data, and goes on to process the next "SELECT" statement.
• Commands in a "SELECT" block can perform two general functions. They modify the HTML data, and/or they grab data from the HTML page and store them in ZCL variables for later use. "MatchAndReplace” commands that perform substitution based on regular expressions perform the HTML modification. Data retrieval is performed by "GrabText” commands that assign data using the result of regular expression matching.
• ZCL In addition to “SELECT”-based processing, ZCL also supports a more flexible, global search-and-replace function called "PipelinedMatch".
• This command applies a regular expression-based search and replace to the whole HTML page while forwarding HTML data as soon as a match is processed or it is clear that no match will be found in that text.
• the facility stores data collected during HTML processing in a database resident on the proxy server computer system.
• This database stores data "grabbed" from the pages for each user by ZCL scripts.
• the database is designed with a dynamic schema, which is updated whenever new ZCL scripts are installed for use by the facility.
• Scripts for web pages containing consumer-oriented data generally grab product descriptions, as well as more detailed information such as item type, price, and URL of the product page.
• the facility builds a user profile by grabbing data from pages the user visits. Each time the user visits a product page (i.e., a page describing a specific product), a data extraction script stores the products description and price. The facility processes this data to extract the last n items that the user viewed. In one preferred embodiment, the facility maintains information on the 50 items most recently viewed. The facility uses these items to generate a profile of the user's interests.
• a product page i.e., a page describing a specific product
• the facility processes this data to extract the last n items that the user viewed.
• the facility maintains information on the 50 items most recently viewed. The facility uses these items to generate a profile of the user's interests.
• the facility characterizes a user's profile according to keyword frequency and item type frequency.
• Keyword frequency is the number of times a given keyword occurs in the recorded items.
• Item type frequency is the number of times a given item type (product category) occurs.
• the facility records the user's top keywords and item types and uses them to target advertisements and other content that are relevant to the user's recent browsing.
• Code Block 6 is a sample document processing script corresponding to the product data extraction document processing specification 421 shown in Figure 4, to which the contents of the body of the HTTP response shown in Code Block 4 are first subjected. This script extracts product data from the body of the HTTP response for use in profiling the user retrieving this web page.
• CODE BLOCK 6 The script shown in Code Block 6 extracts product data from the web page and stores it in the database.
• a ZCL statement in lines 14-17 of Code Block 6 processes data until the first occurrence of the string " ⁇ b> ⁇ font". This string occurs in the page just before the heading of the page (in this case "LAVA-LAMPS" in lines 24-25 of Code Block 4).
• the empty command clause allows the parser to pass data on as soon as it is clear that it doesn't contain the termination string. Thus, as data comes in, it is passed on to the next ZCL script in the chain.
• the ZCL statement in lines 19-28 of Code Block 6 extracts the heading of the page, "LAVA-LAMPS," from line 25 of Code Block 4 into the variable named "item subtype".
• the ZCL statements in lines 30-38 and 39-44 advance the HTML stream to just before the brand name, and then extract the brand name "Hot Lava", from lines 32-33 of Code Block 4, into the item brand variable.
• next ZCL statements in Code Block 6 are structured similarly to the first four, with several pairs of statements to advance to the next data item, and then to extract the data item into the ZCL variables item description, item number, and item_price.
• the final statement at lines 89-99 of Code Block 6 stores the acquired text into the database, indexed by domain name and user name.
• the facility preferably adds to certain web pages a subwindow called a "supplemental information bar" that contains additional information relating to the web page.
• the supplemental information bar is preferably implemented as a DHTML widget, which enables the information contained in it to be displayed in a relatively unobtrusive manner.
• the supplemental information bar floats above the page and can be "ntinimized" so that it doesn't obscure the existing page content.
• the supplemental information bar allows easy substitution of features, which enables a "slotting" strategy. That is, slots in the supplemental information bar can be sold.
• the supplemental information bar code is capable of placing different features on different pages.
• the supplemental information bar is preferably implemented using a Perl function which generates HTML text which is inserted into the original page between the ⁇ /BODY> and ⁇ /HTML> tags. This ensures that all the important HTML text in the page will have been processed by the time the supplemental information bar function is called. This allows ZCL parsers earlier in the chain to grab all relevant information out of the page so the variables can be passed to the supplemental information bar.
• the supplemental information bar pulls in external content from server-side scripts, such as CGI scripts, that are called from the browser by elements able to reference external objects, such as ⁇ DIV> tags in Netscape, or ⁇ IFRAME> tags in Internet Explorer.
• the ZCL script that places the supplemental information bar into the page generates the URLs for the CGI requests, passing the appropriate data grabbed from the page as parameters.
• the product description is passed to a CGI script which generates a price comparison.
• the supplemental information bar uses ⁇ LAYER> and ⁇ DIV> tags to place external content into the page.
• the content is generated by CGI scripts which are handed parameters grabbed from the page.
• a ⁇ LAYER> tag is used to include the external content.
• ⁇ DIV> tags are used instead, with an ⁇ IFRAME> holding the actual content generated by the script.
• the CGI content is received, it is copied from the ⁇ IFRAME> into the ⁇ DIV>. Note that to accomplish this, a special proxy command has been implemented.
• In order to prevent malicious web sites from capturing data from users by copying data from one frame to another Internet Explorer enforces a security measure preventing access of frames from a web server other than the one running the script.
• a proxy command is used to direct the proxy that requests from URI's whose path component begins with a certain keyword should be forwarded to the internal CGI server instead of being forwarded to the web server as they normally would be. This means that even though the browser appears to be sending the request to the original web served the response is actually generated by the facility's CGI server.
• the CGI scripts are passed a cookie which identifies the user making the request The scripts can use this information to customize the data returned for the request.
• CGI script application would be using collaborative filtering to deliver recommendations related to the product or web page being displayed.
• Collaborative filtering attempts to determine interests of one user by correlating the user's product browsing history with the histories of other users. Identifying similar users allows the script to determine what other products were interesting to those users.
• Code Block 7 below is a sample document processing script corresponding to the supplemental information addition document processing specification 422 shown in Figure 4, to which the contents of the body of the HTTP response shown in Code Block 4 are subjected after they are subjected to the sample document processing script shown in Code Block 6 above.
• This script adds a supplemental information bar to the web page containing information relating to the content of the web page and the user, including links to additional related information.
• the script in Code Block 7 uses information extracted in the script shown in Code Block 6 to add the user's name to the title bar of the web page and to add supplemental information to the web page in a supplemental information bar.
• the "PipelmedMatch" statement in lines 15-18 of Code Block 7 performs a global replacement in the page that adds the user's name and proxy server site to the title bar of the web page.
• a Perl function (InsertUsername) is used to generate the actual HTML content. For example, the facility inserts the user and pod name string "[janedoe@podl]" before the page title "Acme.electronics" in line 3 of Code Block 5.
• the user and pod name string are generated by an "InsertUsername" Perl function that takes ZCL variables containing the user's name and the pod's name as parameters.
• the PipelmedMatch statement consumes data and passes it on as soon as it determines that the match expression doesn't match the contents of the accumulated data. Given the chaining of the two scripts in this example, the match will occur in the first batch of data received from ZCL script shown in Code Block 6 (the batch ending in " ⁇ b> ⁇ font").
• the PipelmedMatch statement in lines 1-13 of Code Block 7 uses the variables set by ZCL script shown in Code Block 6 to call a Perl function that generates the supplemental information bar.
• the supplemental information bar is added to the sample web page at lines 95-269 of Code Block 5.
• the call to the Perl function specifies the content features to include in the supplemental information bar.
• the parameters passed to the Perl script include the URL of a CGI script to produce the content for the feature as well as parameters passed to the CGI script for use in producing the content. For example, for a PriceCompare feature preferably provided by the facility, a description of the item whose price is to be compared is ultimately passed to the CGI script.
• the parameters to the CGI script are expressed, at least in some cases, in terms of ZCL variables whose values are extracted from the web page by the script shown in Code Block 6.
• the ZCL variables are replaced with their values.
• the $%item_description variable name shown in line 7 of Code Block 7 is replaced with its value extracted from the sample web page, "Hot Lava motion lamp.”
• the Perl function When invoked, for each specified feature, it adds a CGI script call to the HTML content generated by the Perl function and added to the web page by the ZCL script.
• the facility preferably adds the CGI script call shown in lines 261-263 of Code Block 5.
• the facility When the client receives the modified web page, for each CGI script call added by the Perl function, the facility generates an additional HTTP request invoking the script and passing the parameters. In the corresponding HTTP response, the facility receives the HTML content for the feature generated by the CGI script and displays this HTML content in the supplemental information bar. For example, the content for the PriceCompare feature is displayed in area 780 of the supplemental information bar.
• An alternate implementation of the supplemental information bar processing uses a proxy command to invoke a Perl module which acts as a customized parser object.
• This Perl module externally behaves like a parser object for ZCL scripts, but actually is not associated with any script. Instead, it contains Perl code which is optimized to search for the appropriate place to insert the DHTML content to implement the supplemental information bar.
• the variables initialized by parser objects earlier in the pipeline are passed to this Perl code, allowing selection of features to include based on available data. This allows the facility to avoid placing features in the bar which generate no useful information in the context of a given page.
• Code Block 8 below is a sample document processing script corresponding to the secure reference re-writing document processing specification 423 shown in Figure 4, to which the contents of the body of the HTTP response shown in Code Block 4 are subjected after they are subjected to the sample document processing script shown in Code Block 7 above.
• This script replaces any secure HTTP references to web servers with secure HTTP references to the facility.
• the facility preferably replaces the secure HTTP reference to a web server in line 82 of Code Block 4, "https://www.lava-lampsdirect.com/ cgi-bin myaccount.cgi," with a secure HTTP reference to the facility in lines 83-84 of Code Block 5, "https://secure.zackne1work.corn//www.lava-lampsdirect.com cgi- bin myaccount. cgi”.
• Non-secure HTTP references to web servers such as the HTTP reference to a web server in line 25 of Code Block 4, "/lavalamps.html", on the other hand, are not replaced with an http reference to the facility, as can be seen at line 26 of Code Block 5.
• the facility uses several additional mechanisms. These mechanisms redirect the secure connection to an instance of the proxy server nmning in a secure mode (the "secure proxy") so that it is a part of the communication between the user and the web site.
• the secure proxy is responsible for script processing on secure web pages.
• Secure web conversations are generally conducted using the SSL protocol.
• This protocol entails a key exchange between the two endpoints of the conversation and subsequent establishment of a secure channel which cannot be understood by a third party.
• a normal web proxy server simply forwards the keys and encrypted data stream without being able to decrypt the actual data that is transferred.
• Figure 9 is a data flow diagram showing conventional proxying of a secure web conversation.
• the diagram shows that, when the client 910 generates a secure request 911, the request is encrypted before leaving the client using a key set negotiated between the client and web server for the secure conversation, as shown by the wavy line extending from the request.
• the request 911 remains encrypted while it passes through a conventional proxy server 920, and until it reaches the web server 930.
• the web server 930 uses the key set negotiated between the client and web server for the secure conversation to decrypt the request 911, as shown by the transition from a wavy line to a straight line in web server 930.
• the web server 930 generates a secure response 931, which it encrypts with the key set before transmitting it to the client.
• the secure response 931 remains encrypted throughout its transmission to the client, including the time during which it is passing through the conventional proxy server 930.
• the client decrypts the secure response using the key set for the secure conversation. Accordingly, the conventional proxy server 920 never has access to the secure request 911 or the secure response 931 in plaintext form.
• the proxy server In order to be able to rewrite secure web pages, the proxy server must participate in this key exchange. For an HTTP conversation, this means that the browser must be directed to connect directly to the proxy instead of the ultimate web site. That is, the browser must be connecting to a URL which looks like it is resident on the proxy server, not on the actual site. A consequence of this redirection is that cookies (which are presented only to the site that sets them) will not be passed for the actual site, as the browser doesn't know that the request is actually intended for a different site.
• FIG. 10 is a data flow diagram showing proxying of a secure web conversation by the facility.
• the diagram shows that a secure conversation using the facility is actually implemented using two different secure conversations: a first secure conversation between the client and the proxy server, and a second secure conversation between the proxy server and the web server.
• the client 1010 generates secure request 1011, which it encrypts using a key set negotiated with the proxy server before sending to the proxy server 1020.
• the proxy server 1020 receives the encrypted secure request 1011, the proxy server decrypts the secure request using the key set negotiated with the client for the first secure session. Once it has decrypted the request, the proxy server may read, copy, modify, filter, or otherwise process the secure request in plaintext form.
• the proxy server then re-encrypts the secure request using a key set negotiated with the web server for the second conversation, and forwards the re-encrypted secure request to the web server 1030.
• the web server receives the re- encrypted request, the web server decrypts the re-encrypted request using the key set negotiated with the proxy server for the second secure conversation.
• the web server generates a secure response 1031, which it encrypts using the key set negotiated with the proxy server for the second secure conversation, and transmits the encrypted secure response
• the proxy server decrypts the encrypted secure response using the key set negotiated with the web server for the second secure conversation. After so decrypting the secure response, the proxy server can read, copy, modify, filter, or otherwise process the secure response in plaintext form.
• the proxy server then re-encrypts the decrypted secure response using the key set negotiated with the client for the first secure conversation, and transmits the re-encrypted secure response to the client.
• the client decrypts the re-encrypted secure response using the key set negotiated with the proxy server for the first secure conversation.
• the secure "proxy” is implemented as a web server, not a web proxy server. It supports URL requests which contain the site from which to retrieve the data.
• the URL that the browser requests actually specifies the secure proxy server as the location of the page. For example, a request from "https://www.asite.com/apath" would be requested as
• the proxy auto- configuration file provided to the browser at login time by the facility is set up to pass all requests to "secure.zacknetwork.com” through without proxying.
• the facility preferably rewrites all sources from which a secure request may originate. In general, these points are either links or redirection requests. Hyperlinks from one page to another often point to a secure page. These links must be rewritten. Redirection requests (e.g., HTTP 302 replies) are also often used to direct a browser to a new page, which could be a secure page. These redirection requests must also be rewritten to point to the secure proxy.
• Links that are external to the click stream cannot be rewritten by this mechanism.
• links are preferably rewritten using the normal ZCL mechanisms. This means that a script such as the script in Code Block 8 is written to process the insecure (standard HTTP) pages and rewrite all links so that the old URL now points to the facility (for example, the URL "https://www.asite.com/apath” is rewritten as "https://secureproxy. zacknetwork.com/www.asite.com apath").
• Redirection requests generally cannot be rewritten by ZCL script as the location of the redirection is returned in a header field.
• the facility therefore allows specification of a proxy command that indicates that redirection requests returned from a set of URLs should be rewritten.
• the requests are rewritten by prepending the name of the secure proxy server to the Location header field specified in the original response.
• the facility could be adapted or extended in various ways.
• the facility may be straightforwardly adapted to operating computing environments other than the Internet.
• the facility can add virtually any type of information to a document. This information may be selected based upon the content of the document, the source of the document, the identity of the user, user profile information, and/or a variety of other sources.
• the facility may be used for a variety of economic purposes, including generating goodwill with and/or deriving revenue from users, Internet Service Providers, advertisers, and publishers, as well as other related business entities. While the foregoing description makes reference to preferred embodiments, the scoped of the invention is defined solely by the claims that follow and the elements recited therein.

Landscapes

• Business, Economics & Management (AREA)
• Engineering & Computer Science (AREA)
• Accounting & Taxation (AREA)
• Development Economics (AREA)
• Strategic Management (AREA)
• Finance (AREA)
• Game Theory and Decision Science (AREA)
• Entrepreneurship & Innovation (AREA)
• Economics (AREA)
• Marketing (AREA)
• Physics & Mathematics (AREA)
• General Business, Economics & Management (AREA)
• General Physics & Mathematics (AREA)
• Theoretical Computer Science (AREA)
• Information Transfer Between Computers (AREA)

Priority Applications (1)

Applications Claiming Priority (2)

Publications (1)

Family

ID=24041406

Family Applications (1)

Country Status (2)

Cited By (3)

• 2001
  • 2001-02-05 AU AU2001236649A patent/AU2001236649A1/en not_active Abandoned
  • 2001-02-05 WO PCT/US2001/003609 patent/WO2001063444A2/fr active Search and Examination

Also Published As

Similar Documents

Legal Events