WO2001073619A1

WO2001073619A1 - A data delivery process

Info

Publication number: WO2001073619A1
Application number: PCT/AU2001/000346
Authority: WO
Inventors: Christopher Andrew Leishman; Sydney Gordon Low
Original assignee: Sharinga Networks Inc.
Priority date: 2000-03-28
Filing date: 2001-03-28
Publication date: 2001-10-04
Also published as: AUPQ653800A0

Abstract

A data delivery process, including receiving data requested by a user connected to a communications network as serial Internet Protocol (IP) packets, processing said packets in real-time as a data stream, and sending the data stream to the user, the processing including parsing the stream for at least one predetermined data element and adding insert data in the data stream relative to the predetermined data element. A server, such as a proxy server, can be used to execute the process, and the data inserted may be marketing information in the form of watermark data, image data, toolbar data, dynamic layer data or banner data. The information sent and the element parsed for is determined on the basis of profile data and/or connection state data for the user.

Description

A DATA DELIVERY PROCESS

The present invention relates to a data delivery process and a server for executing the process.

Internet service providers (ISPs) need to recover costs associated with providing Internet access to their customers and at the same time wish to minimise charges levied against the customers. If alternative sources of revenue for ISPs can be established, then it is possible for ISPs to provide free Internet access to customers. One alternative source of revenue is from advertising based on advertisements sent by ISPs to customers. One way of effectively achieving this requires the ISPs to control to some extent the content delivered to customers. Various techniques for controlling content delivery have been used and proposed, such as sending data to a user's browser to generate a new browser window with an advertisement or controlling a HTML page viewed by a browser, as described in the specification of International Patent Application No. PCT/AUOO/00418 to the applicant. It is desired, however, to provide a process which allows content, such as an advertisement, to be inserted directly in and integrated with data requested by a customer, or at least provide a useful alternative.

The present invention relates to a data delivery process, including: receiving data requested by a user connected to a communications network as serial data packets; processing said packets in real-time as a data stream; and sending said data stream to said user; said processing including parsing said stream for predetermined data elements and substituting data in said data stream bounded by said predetermined elements with substitute data.

Advantageously, the data stream may be an IP protocol stream and a header of the stream is analysed to determine said predetermined data elements in said stream.

Preferably, the predetermined elements are determined on the basis of profile data and/or connection state data for said user. Preferably said substitute data is determined, on the basis of profile data and/or connection state data for said user. Preferably said profile data and/or connection state data is accessed in response to analysis of said header of said stream.

The present invention also provides a data delivery process, including: receiving data requested by a user connected to a communications network as serial Internet Protocol (IP) packets; processing said packets in real-time as a data stream; and sending said data stream to said user; said processing including parsing said stream for at least one predetermined data element and adding insert data in said data stream relative to said at least one predetermined data element.

The present invention also provides a data delivery process, including: receiving an instant messaging login request from a user connected to a communications network; processing the request in real-time to build a list of active users including said user; sending said login request; and sending a marketing message to at least one user of said list based on user data for said at least one user.

Preferred embodiments of the present invention are hereinafter described, by way of example only, with reference to the accompanying drawings, wherein: Figure 1 is a block diagram of a preferred embodiment of a proxy server connected to the Internet and a user's terminal;

Figure 2 is a flow diagram of a preferred embodiment of a data delivery process executed by the proxy server;

Figures 3 and 4 are screen displays generated on the user's terminal by data sent from the proxy server; and Figure 5 is a flow diagram of another preferred embodiment of a data delivery process executed by the proxy server.

A proxy server 6, as shown in Figure 1, can be employed by ISPs to administer, control and cache Internet data for users or customers connected to the ISPs equipment using a remote computer terminal 2. Remote users are able to connect to the Internet 8 by the proxy server using a browser, such as Internet Explorer™, and dial-up or IP connection software stored and executed on the terminal 2. This allows the terminal 2 to connect to a remote access server (RAS) 4 of the ISP. All of the connections on the RAS 4 can be connected to the proxy server 6 which sends messages to and receives responses from the Internet 8, in response to messages received from the terminals 2 requesting data. The functionality of the servers 4 and 6 can be combined into one machine or distributed, as will be understood by those in the art.

Conventional proxy servers receive data requests from users and respond by providing the data requested either as a direct stream from the Internet 8 or from cache data held on the server 6. For example HTTP requests, if the data is not cached, are responded to by simply forwarding the request to the Internet 8 and returning the HTTP response directly to the user's terminal 2 by the RAS 4. The proxy server 6, however, includes a discrete finite automata (DFA) module which provides a state machine that is able to process HTTP responses in real-time and insert substitute data, such as advertising data, in the responses. This allows a HTML page requested and received by the browser of the terminal 2 to be embedded with advertising information "on the fly". The process is entirely transparent to the user of the terminal 2, as the page is displayed as if it already included the advertising information. Accordingly it cannot simply be ignored or neglected, as is the case with a "pop-up" window that can be simply closed. The information can be displayed in a number of forms, such as a banner at the top of a page or as a watermark underlying the text of the page. The process, as described in more detail below, provides real-time dynamic data replacement or addition for an Internet protocol response. The proxy server 6, and in particular the DFA of the server 6, executes a data delivery process, as shown in Figure 2. The process is hereinafter described with respect to processing a HTTP response, but the process can be adjusted to handle any Internet protocol proxied by the server 6, as described below. For each HTTP response received for a user, at step 12, the initial packets of the response which make up the HTTP header are buffered at step 14 by the DFA, which analyses the header to extract relevant information, such as response content type and response content-length or transfer encoding. This information in combination with profile information concerning the user that the response is to be sent to is used to determine whether or not the response needs to be processed to add substitute data. The profile information for the IP address from which the client connected can be used to identify the user. After the header has been analysed the remaining data payload of the response is received.

Alternatively, other indicators can be used to determine the identity of the user, such as HTTP cookies, special URLs or other HTTP headers. For protocols other than HTTP other indicators may be used.

As the data bytes of the payload are received, each data byte or element is parsed in real-time as it is received, at step 16, if the DFA has been set to a parse state after analysing the header. If the data is not to be parsed the header is sent to the user at step 36 and each data element of the payload is read and sent to the user at steps 38 and 40 until it is determined at step 22 that the last data element has been sent. Operation then returns to step 12 to await a new response. Some data need not be parsed, for example images files, such as jpg, .gif and .png files. Also only the data elements of a response that need to be parsed are parsed, with remainder being sent directly to the terminal 2.

If the DFA is in a parse state, each data element, such as a data byte, is parsed in real-time and a determination made at step 22 as to whether it indicates that data needs to be substituted. A received data element is read at step 18 and buffered at step 20 and then analysed to determine whether any data substitution is to occur at step 22. For example, if a substitute identifier, such as a HTML tag, is located at step 22 then at step 32 all of the subsequently received data elements are buffered until an end identifier is detected. The beginning and end identifiers may, for example, define a colour or background for the page, an image which can be replaced or a significant space in the page which allows an image or ad information to be substituted. The data elements between the identifiers are then substituted by substitute data, at step 34, and check made at step 24 to determine if the last data element to be parsed for the required substitution has been reached. The substitute data may be watermark data, image data, toolbar data, dynamic layer data and/or banner data. If the last data element has not been received, operation returns to step 18. The last data element to be parsed is determined on the basis of the data substitution which has been designated for the user based on the profile information. For instance, if a toolbar of information is to be inserted at the top of a requested HTML page then only the data elements at the top of the page need to be parsed until the substitution has been executed. The remaining data elements can then simply be sent to the user terminal 2. If however data is to be substituted to the bottom of a HTML page then all of the data elements of a pages may need to be buffered.

If the last data element to be parsed has been received then the content-length value in the buffered header is updated or adjusted based on the number of data elements for the response, at step 26. The content-length data determines the size of a HTML page and may need to replace the content-length value received in the header. The content-length data defines the length of the HTTP response, and defines for the browser the size of the display or page which needs to be rendered on the terminal 2. This caters for the addition of substitute data which increases the length of the response or the size of the display to be rendered.

After step 26, the header is sent at step 28 and the buffered data sent at step 30, together with the remaining data elements of the response as they are received. The header and data needs to be buffered to at least some extent for a parsed HTML page because most versions of the HTTP protocol require the header to carry the content-length for an entire page. If this is altered by the parsing process, as discussed above, then the header needs to be updated and the data sent subsequently. Alternatively, the DFA can be configured to execute a process that is optimised for new versions of the HTTP protocol, ie versions > version 1.1. These versions allow the data to be sent to the terminal 2 without the DFA having to update the content-length in the header. Instead, the DFA is able to use a chunked transfer encoding to indicate the length of the response. The alternative process executed by the server 6, as shown in Figure 5, receives the response header at step 101, and in step 102 the header is analysed to determine if the data received needs to be parsed and how the data is to be encoded. For 1.0 version data, this will normally not be encoded but will have a content-length value in the header indicating the size of the data. For data received from 1.1 version servers the data may be encoded using the chunked transfer encoding. Other encodings, such as gzip, can also be supported by the server.

If the data needs to be parsed, as determined at step 103, then at step 104 the determination is made with regard to the suitable transfer encoding for the data to be sent to the terminal 2. If the terminal 2 has software that supports version 1.1 of the HTTP protocol, then the DFA selects chunk transfer encoding. The header of the response is then updated to reflect the new encoding that will be applied, and is sent at step 105.

A single block of data of the response is then read at step 106 unencoded at step

107, and added to the end of a buffer. The data is parsed at step 108, and if it is determined at step 109 that data to be substituted or inserted has been located, based on locating predetermined data elements found in the received or buffered data, then that data is inserted at step 110. A test is marked at step 111 to determine whether the last block of the response stream has been received. If not, a determination is made at step 112 as to what portion of the buffered data cannot be part of a possible future substitution, and that data is then extracted from the buffer and encoded using the transfer encoding determined earlier (step 104), at step 113. The encoded data is sent at step 114 and operation returned to step 106. The operation is repeated until the last block of the response stream 111 is reached, and then at this step all the data is removed from the buffer at step 105, encoded at step 116, and sent at step 117. The process completes at step 118. If the data does not need to be parsed, as determined at step 103, then the header and the data blocks are sent at steps 119, 120, 121 and 122 in an unmodified form, as for steps 36 to 22 described with reference to Figure 2.

For terminals 2 that only support HTTP protocol version 1.0, the process described with reference to Figure 2 is executed. Another alternative is to use the process described with reference to Figure 5 but choose not to apply any encoding to the data, remove any indication of the content-length (in step 104) and at completion close the TCP/IP connection to the client which will indicate the end of the data (step 118).

The proxy server 6 is able to execute a number of threads of the DFA to process a number of response data streams simultaneously as described above. The process can handle a number of different Internet protocols and be adjusted accordingly if necessary, as described below.

For the HTTP protocol various data substitutions can be executed using the DFA process described above. For example a toolbar can be inserted into every web page to provide context sensitive information to the user to improve the quality of their browsing or surfing experience. The toolbar may include a link to a list of web sites in the same category as the one the user has requested or a quality ranking of the requested web site against others in the category. The toolbar may also state information relevant to the user, such as a visual indication as to whenever a new e-mail has arrived for the user or when a user's bid on an auction web site was successful. To execute this the analysis step 14 would involve execution of the following steps by the proxy server 6:

1. On detecting that a web page has been requested, information is retrieved concerning the web site from a web site database.

2 Data is also retrieved, if it has not already been retrieved, concerning the type of assistance information which the user has selected and which is stored in the user's profile in a profile database. 3. The current connection or browsing state for the user is determined.

4. On the basis of the data collected above from the analysis process, HTML code is generated to form the toolbar and a modified content-length associated with the toolbar is calculated.

For a HTTP response, the referrer code in a hyperlink of a web page can be substituted for another referrer code to enhance the revenue for the access provider delivering the web page. This is simply achieved by searching for substitute identifiers at step 22 which correspond to the start of a refer code and then substituting the refer code with the desired code.

For POP and SMTP e-mail protocols, an e-mail message, when requested by an e- mail client executing on the terminal 2, can be intercepted and marketing information directly inserted into the body of the e-mail message, as shown in Figure 3. The proxy server achieves this by determining when a POP or SMTP session for the user is in progress and then extracting profile information for the user from the member database. Content to be inserted is then generated based on the accessed profile information. For example, if the user is female with a four year old child, a marketing offer is retrieved from a marketing database which matches the profile of the user. An insertion point for the POP or SMTP session is then determined by the proxy server for each requested e-mail, such as the top of the e-mail message, and the DFA is used to parse data elements of the message to insert the content in the message before it is sent to the terminal 2.

For audio and video streaming protocols a marketing offer can be inserted at the start of streaming content. For instance, if a streaming connection is initiated this is detected by the proxy server 6 as a trigger to intercept the connection and access profile information from the member database, and state information on the user's current connection or browsing state. A marketing message is then accessed which is formatted for the specific stream protocol and matched to the user's profile and state. For example, if the protocol is streaming audio a marketing offer is retrieved from the streaming audio marketing database. The requested streaming content is sent immediately thereafter to the user's terminal 2.

For ICQ and instant messaging protocols, login requests can be intercepted to build up a list of active users. A broadcast is periodically sent with targeted offer to all connected users. The offers are matched to individual user's profiles. The proxy server 6 executes this by detecting when a messaging protocol login request is received, and this triggers a process of interception and determining the associated user. The login status and connection state information for the user is adjusted accordingly for every messaging protocol. The logon request is then sent to the original requested destination so as to continue the user's login process. The proxy server 6 at a predetermined time sends an instant message to all selected users containing a marketing message, as shown in Figure 4. The marketing message, as mentioned previously, is determined on the basis of the user's profile which may include demographic, psychographic and purchasing propensity indicators based on their past data requests and other character data that has been collected. The proxy server 6 then also monitors for a logoff request so as to update a user's login status and connection state data when received. The logoff request is then forwarded to the original destination to continue the user's logoff process.

The various databases described that hold information, such as the profile information for the proxy server 6 may be stored on the server 6 itself but a practical implementation would have one or more data stores holding the data and populating it to the proxy server 6 when a user connects to the server and/or changes connection or browsing state.

The proxy server 6, as described above, is able to determine where, when and what to insert on the basis of the profile data and connection state data for the identified user. If desired, the process executed by the server may rely only on the profile data or only on the connection state data. Many modifications will be apparent to those skilled in the art without departing from the scope of the present invention as herein described with reference to the accompanying drawings.

Claims

CLAIMS:

1. A data delivery process, including: receiving data requested by a user connected to a communications network as serial data packets; processing said packets in real-time as a data stream; and sending said data stream to said user; said processing including parsing said stream for predetermined data elements and substituting data in said data stream bounded by said predetermined elements with substitute data.

2. A data delivery process as claimed in claim 1, wherein said data stream is an Internet Protocol (IP) protocol stream and a header of the stream is analysed to determine said predetermined data elements in said stream.

3. A data delivery process as claimed in claim 2, wherein the predetermined elements are determined on the basis of profile data and/or connection state data for said user.

4. A data delivery process as claimed in claim 3, wherein said profile data and/or connection state data is accessed in response to analysis of said header of said stream.

5. A data delivery process as claimed in claim 3, wherein said substitute data is determined, on the basis of profile data and/or connection state data for said user.

6. A data delivery process as claimed in claim 5, wherein said profile data and/or connection state data is accessed in response to analysis of said header of said stream.

7. A data delivery process as claimed in claim 1, wherein said processing includes sending received packets of said stream without said parsing on completion of said substituting.

8. A data delivery process as claimed in claim 2, said processing includes adjusting content-length data of said header.

9. A data delivery process as claimed in claim 2, wherein the IP protocol of said stream is one of a plurality of IP protocols.

10. A data delivery process as claimed in claim 1, wherein said data is markup language data and the predetermined data elements are tags.

11. A data delivery process as claimed in claim 2, wherein the IP protocol of said stream is a messaging protocol.

12. A data delivery process as claimed in claim 2, wherein the IP protocol of said stream is an email protocol.

13. A data delivery process as claimed in claim 2, wherein the IP protocol of said stream is a video streaming protocol.

14. A data delivery process as claimed in claim 2, wherein the IP protocol of said stream is an audio streaming protocol.

15. A data delivery process as claimed in claim 2, wherein the IP protocol of said stream is a file transfer protocol.

16. A data delivery process as claimed in claim 1, wherein the substitute data may be watermark data, image data, toolbar data, dynamic layer data and/or banner data.

17. A data delivery process as claimed in claim 1, wherein the data represents a web page and the substitute data represents marketing information inserted and integrated with the page.

18. A server having components for executing the steps of a data delivery process as claimed in any one of the preceding claims.

19. Computer software stored on a computer readable storage medium and having code for executing the steps of a data delivery process as claimed in any one of claims 1 to 17.

20. A server having: means for receiving data requested by a user connected to a communications network as serial data packets; means for processing said packets in real-time as a data stream; means for sending said data stream to said user; and said processing means parsing said stream for predetermined data elements and substituting data in said data stream bounded by said predetermined elements with substitute data.

21. A data delivery process including: receiving Internet Protocol (IP) packets requested by a user connected to the Internet; processing the packets in real-time; and sending the packets to the user; said processing including analysing a header of said packets to determine predetermined data elements, parsing the packets for the elements and inserting data in the packets relative to the elements.

22. A proxy server, including: means for receiving data requested by a user as serial Internet Protocol (IP) packets; means for processing said packets in real-time as a data stream; and means for sending said data stream to said user; said processing means parsing said stream for predetermined data elements after analysing a header of the stream, and inserting data in said data stream relative to said predetermined elements.

23. A data delivery process, including: receiving data requested by a user connected to a communications network as serial Internet Protocol (IP) packets; processing said packets in real-time as a data stream; and sending said data stream to said user; said processing including parsing said stream for at least one predetermined data element and adding insert data in said data stream relative to said at least one predetermined data element.

24. A data delivery process as claimed in claim 23, wherein a header of the stream is analysed to determine said at least one predetermined data element in said stream.

25. A data delivery process as claimed in claim 24, wherein said at least one predetermined element is determined on the basis of profile data and/or connection state data for said user.

26. A data delivery process as claimed in claim 25, wherein said profile data and/or connection state data is accessed in response to analysis of said header of said stream.

27. A data delivery process as claimed in claim 25, wherein said insert data is determined, on the basis of profile data and/or connection state data for said user.

28. A data delivery process as claimed in claim 27, wherein said profile data and/or connection state data is accessed in response to analysis of said header of said stream.

29. A data delivery process as claimed in claim 23, wherein said processing includes sending received packets of said stream without said parsing on completion of said adding.

30. A data delivery process as claimed in claim 24, said processing includes reencoding said data stream.

31. A data delivery process as claimed in claim 24, wherein said stream uses one of a plurality of IP protocols.

32. A data delivery process as claimed in claim 23, wherein said data is markup language data and said at least one predetermined data elements is a tag.

33. A data delivery process as claimed in claim 31, wherein the IP protocol of said stream is a messaging protocol.

34. A data delivery process as claimed in claim 31, wherein the IP protocol of said stream is an email protocol.

35. A data delivery process as claimed in claim 31, wherein the IP protocol of said stream is a video streaming protocol.

36. A data delivery process as claimed in claim 31, wherein the IP protocol of said stream is an audio streaming protocol.

37. A data delivery process as claimed in claim 31, wherein the IP protocol of said stream is a file transfer protocol.

38. A data delivery process as claimed in claim 23, wherein the insert data may be watermark data, image data, toolbar data, dynamic layer data and/or banner data.

39. A data delivery process as claimed in claim 23, wherein the data represents a web page and the insert data represents marketing information inserted and integrated with the page.

40. A server having components for executing the steps of a data delivery process as claimed in any one of claims 23 to 39.

41. Computer software stored on a computer readable storage medium and having code for executing the steps of a data delivery process as claimed in any one of claims 23 to 39.

42. A server having: means for receiving data requested by a user connected to a com munications network as serial Internet Protocol (IP) packets; means for processing said packets in real-time as a data stream; means for sending said data stream to said user; and said processing means parsing said stream for at least one predetermined data element and adding data in said data stream relative to said at least one predetermined element.

43. A data delivery process, including: receiving an instant messaging login request from a user connected to a communications network; processing the request in real-time to build a list of active users including said user; sending said login request; and sending a marketing message to at least one user of said list based on user data for said at least one users.

44. A server having components for executing the steps of the data delivery process as claimed in claim 43.

45. Computer software stored on a computer readable storage medium and having code for executing the steps of a data delivery process as claimed in claim 43.