Agent-based technique for implementing browser-initiated user-transparent interstitial web advertising in a client computer

Abstract

A technique for implementing in a networked client-server environment, e.g., the Internet, network-distributed advertising in which advertisements are downloaded, from an advertising server to a browser executing at a client computer, in a manner transparent to a user situated at the browser, and subsequently displayed, by that browser on an interstitial basis, in response to a click-stream generated by the user to move from one web page to the next. Specifically, an HTML advertising tag is embedded into a referring web page. This tag contains two components. One component effectively downloads, from an distribution web server and to an extent necessary, and then persistently instantiates an agent at the client browser. This agent "politely" and transparently downloads advertising files (media and where necessary player files), originating from an ad management system residing on a third-party advertising web server, for a given advertisement into browser cache and subsequently plays those media files through the browser on an interstitial basis and in response to a user click-stream. The other component is a reference, in terms of a web address, of the advertising management system. This latter reference totally "decouples" advertising content from a web page such that a web page, rather than embedding actual advertising content within the page itself, merely includes an advertising tag that refers, via a URL, to a specific ad management system rather than to a particular advertisement or its content. The ad management system selects the given advertisement that is to be downloaded, rather than having that selection or its content being embedded in the web content page.

Claims

We claim:

1. Apparatus for rendering an information object in response to a first web page, the apparatus comprising:

a processor;

a memory connected to the processor and storing computer executable instructions, the instructions representing page content and embedded code, the first web page being stored in the memory and containing both the page content and the embedded code; and

an output device responsive to the processor;

wherein the processor, in response to the computer executable instructions, downloads, as a result of executing the embedded code during processing the instructions on the page, an agent from a first server, and then executes the agent, such that the processor, through the agent:

downloads to the memory, and while the first web page is being rendered on the output device, both a manifest file associated with the information object from a second server into the memory and at least one additional file as specified in the manifest file from a corresponding file server, wherein the manifest file specifies at least one predefined informational file that comprises part of the information object, a network address at which the one informational file can be accessed and associated configuration information necessary to properly render the information object;

detects a user-initiated event for initiating a transition from the first web page to a second web page and which signifies a start of an interstitial interval; and

in response to an occurrence of the event:

ceases downloading of a further file specified in the manifest file, to the extent any downloading of the further file is then occurring; and

processes files for an information object that has been previously downloaded and is currently ready to be rendered so as to render the previously downloaded information object during the interstitial interval to the user.

2. The apparatus in claim 1 wherein the information object comprises a web advertisement, the code comprises advertising code and the manifest file specifies at least one advertisement file such that the further file constitutes a further advertisement file.

3. The apparatus in claim 2 wherein the processor, through the agent and during the interstitial interval, downloads the second web page from an associated web server in lieu of downloading the further advertisement file.

4. The apparatus in claim 3 wherein the processor, through execution of the advertising code, downloads the agent in a user-transparent manner, from the first server while the first web page is being rendered through the output device to a user.

5. The apparatus in claim 4 wherein the agent comprises first and second applets.

6. The apparatus in claim 5 wherein the processor, in response to executing the advertising code while the first web page is being rendered:

downloads the first applet; and

once the first applet is downloaded, instantiates and then executes the first applet.

7. The apparatus in claim 6 wherein the processor, during execution of the first applet:

instantiates and starts execution of the second applet; and

monitors the click-stream so as to detect the user-initiated event such that the processor:

instructs the second applet to download the manifest file for the web advertisement from the second server into browser storage residing in the memory; and

in response to an occurrence of the event, instructs the second applet to cease the download of the further advertisement file specified in the manifest file, to the extent any downloading of said further advertisement file is then occurring, and initiates processing through a browser, of files for the previously downloaded advertisement so as to render the previously downloaded advertisement during the next interstitial interval to the user.

8. The apparatus in claim 7 wherein the first and second servers are a distribution server and an advertising file server, respectively.

9. The apparatus in claim 7 wherein the processor, in response to executing the advertising code:

determines, through the agent, whether a new version of either the first or second applets then resides on the first server relative to a corresponding version, if any, of the first and second applets, respectively, then residing in the browser storage; and

if said new version exists on the first server, downloads the new version from the first server into the browser storage and executes the new version in lieu of the corresponding version.

10. The apparatus in claim 7 wherein the first and second applets comprise a Transition Sensor applet and an Ad Controller applet, respectively.

11. The apparatus in claim 4 wherein the manifest file comprises an Ad Descriptor file having a manifest of names of a plurality of predefined advertising files and associated configuration information necessary to properly play the downloaded advertisement through the browser.

12. The apparatus in claim 11 wherein the agent comprises first and second applets.

13. The apparatus in claim 12 wherein the processor, in response to executing the advertising code while the first web page is being rendered:

downloads the first applet; and

once the first applet is downloaded, instantiates and then executes the first applet.

14. The apparatus in claim 13 wherein the processor, during execution of the first applet:

instantiates and starts execution of the second applet; and

monitors the click-stream so as to detect the user-initiated event such that the processor:

instructs the second applet to download the manifest file for the web advertisement from the second server into browser storage residing in the memory; and

in response to an occurrence of the event, instructs the second applet to cease the download of the further advertisement file specified in the manifest file, to the extent any downloading of said further advertisement file is then occurring, and initiates processing through a browser, of files for the previously downloaded advertisement so as to render the previously downloaded advertisement during the next interstitial interval to the user.

15. The apparatus in claim 14 wherein the first and second servers are a distribution server and an advertising file server, respectively.

16. The apparatus in claim 14 wherein the processor, in response to executing the advertising code:

determines, through the agent, whether a new version of either the first or second applets then resides on the first server relative to a corresponding version, if any, of the first and second applets, respectively, then residing in the browser storage; and

if said new version exists on the first server, downloads the new version from the first server into the browser storage and executes the new version in lieu of the corresponding version.

17. The apparatus in claim 14 wherein the first and second applets comprise a Transition Sensor applet and an Ad Controller applet, respectively.

18. The apparatus in claim 11 wherein the Ad Descriptor file comprises a list having: a name of each player and media file that constitutes the downloaded advertisement, a corresponding network address at which said each file can be accessed, configuration information for at least one of the player files for properly configuring the corresponding player to render an associated media file.

19. The apparatus in claim 5 wherein the advertising code further comprises a component specifying the second server.

20. The apparatus in claim 19 wherein the processor, during execution of the second applet and in response to the component contained in the code, downloads an Ad Descriptor file originating from the second server specified in the second component, the second server being an advertising server.

21. The apparatus in claim 20 wherein the first and second servers are a distribution server and an advertising file server, respectively.

22. The apparatus in claim 10 wherein the Ad Controller applet comprises a download queue and a play queue, wherein, the processor during execution of the Ad Controller applet:

inserts an associated Ad Descriptor file for a advertisement to be downloaded into an end of the download queue;

downloads advertising files specified in a given Ad Descriptor file, then situated at a head of the download queue, into browser storage;

once all the advertising files specified in the given Ad Descriptor file for a corresponding advertisement reside in the browser storage on the computer, removes the given Ad Descriptor file from the download queue and inserts the given Ad Descriptor file into an end of the play queue; and

in response to the user-initiated event and during the ensuing interstitial interval, processes advertising files specified in a specific Ad Descriptor file then situated at a head of the play queue so as to render, through the output device, an advertisement, corresponding to the specific Ad Descriptor file, to the user.

23. The apparatus in claim 22 wherein the agent, in response to the occurrence of the user-initiated event, generates a stop event which, when processed by the agent, suspends the downloading of further advertisement files and initiates processing of files specified in the Ad Descriptor file, then situated at the head of the play queue, so as to render the web advertisement associated therewith during the ensuing interstitial interval.

24. The apparatus in claim 23 wherein the Transition Sensor applet monitors a user click stream so as to detect the user-initiated event and, in response thereto, produce the stop event, and wherein Ad Controller applet processes the stop event to suspend said downloading of further advertisement files and to render the advertisement associated with the Ad Descriptor file then situated at the head of the play queue.

25. The apparatus in claim 24 wherein the output device is a display.

26. The apparatus in claim 24 wherein the first and second servers are a distribution server and an advertising file server, respectively.

27. The apparatus in claim 7 wherein the agent further comprises an applet registry for providing inter-applet communication between the Transition Sensor and Ad Controller applets.

28. The apparatus in claim 7 wherein the processor, in response to execution of the agent, overrides default life cycle methods defined in the browser with corresponding substitute methods such that the agent persistently remains in browser storage as the browser transitions across successive web pages and different web sites.

29. The apparatus in claim 28 wherein the life cycle methods comprise at least one of start, run, stop, initialize and destroy methods.

30. The apparatus in claim 28 wherein the first and second servers are a distribution server and an advertising file server, respectively.

31. The apparatus in claim 7 wherein the processor, through the agent, processes each advertisement as a separate thread so as to effectuate pipe-lined processing of advertisements.

32. The apparatus in claim 31 wherein the first and second servers are a distribution server and an advertising file server, respectively.

33. The apparatus in claim 4 wherein the advertising code comprises an advertising tag and the processor, in response to execution of the tag:

dynamically writes a plurality of predefined applet tags that collectively implement a script into the first web page; and

downloads, in response to subsequent execution of the script, the agent from the first server into the memory and thereafter instantiates and executes the agent.

34. The apparatus in claim 33 wherein the agent comprises first and second applets.

35. The apparatus in claim 34 wherein the processor, in response to executing the advertising tag while the first web page is being rendered:

downloads the first applet; and

once the first applet is downloaded, instantiates and then executes the first applet.

36. The apparatus in claim 35 wherein the processor, during execution of the first applet:

instantiates and starts execution of the second applet; and

monitors the click-stream so as to detect the user-initiated event such that the processor:

instructs the second applet to download the manifest file for the web advertisement from the second server into browser storage residing in the memory; and

in response to an occurrence of the event, instructs the second applet to cease the download of the further advertisement file specified in the manifest file, to the extent any downloading of said further advertisement file is then occurring, and initiates processing through a browser, of files for the previously downloaded advertisement so as to render the previously downloaded advertisement during the next interstitial interval to the user.

37. The apparatus in claim 36 wherein the first and second servers are a distribution server and an advertising file server, respectively.

38. The apparatus in claim 36 wherein the processor, in response to executing the advertising tag:

determines, through the agent, whether a new version of either the first or second applets then resides on the first server relative to a corresponding version, if any, of the first and second applets, respectively, then residing in the browser storage; and

if said new version exists on the first server, downloads the new version from the first server into the browser storage and executes the new version in lieu of the corresponding version.

39. The apparatus in claim 36 wherein the first and second applets comprise a Transition Sensor applet and an Ad Controller applet, respectively.

40. The apparatus in claim 33 wherein the manifest file comprises an Ad Descriptor file having a manifest of names of a plurality of predefined advertising files and associated configuration information necessary to properly play the downloaded advertisement through the browser.

41. The apparatus in claim 40 wherein the agent comprises first and second applets.

42. The apparatus in claim 41 wherein the processor, in response to executing the advertising tag while the first web page is being rendered:

downloads the first applet; and

once the first applet is downloaded, instantiates and then executes the first applet.

43. The apparatus in claim 42 wherein the processor, during execution of the first applet:

instantiates and starts execution of the second applet; and

monitors the click-stream so as to detect the user-initiated event such that the processor:

instructs the second applet to download the manifest file for the web advertisement from the second server into browser storage residing in the memory; and

in response to an occurrence of the event, instructs the second applet to cease the download of the further advertisement file specified in the manifest file, to the extent any downloading of said further advertisement file is then occurring, and initiates processing through a browser, of files for the previously downloaded advertisement so as to render the previously downloaded advertisement during the next interstitial interval to the user.

44. The apparatus in claim 43 wherein the first and second servers are a distribution server and an advertising file server, respectively.

45. The apparatus in claim 43 wherein the processor, in response to executing the advertising tag:

determines, through the agent, whether a new version of either the first or second applets then resides on the first server relative to a corresponding version, if any, of the first and second applets, respectively, then residing in the browser storage; and

if said new version exists on the first server, downloads the new version from the first server into the browser storage and executes the new version in lieu of the corresponding version.

46. The apparatus in claim 43 wherein the first and second applets comprise a Transition Sensor applet and an Ad Controller applet, respectively.

47. The apparatus in claim 40 wherein the Ad Descriptor file comprises a list having: a name of each player and media file that constitutes the downloaded advertisement, a corresponding network address at which said each file can be accessed, configuration information for at least one of the player files for properly configuring the corresponding player to render an associated media file.

48. The apparatus in claim 33 wherein the advertising tag further comprises a component specifying the second server.

49. The apparatus in claim 48 wherein the processor, during execution of the second applet and in response to the component contained in the tag, downloads an Ad Descriptor file originating from the second server specified in the second component, the second server being an advertising server.

50. The apparatus in claim 49 wherein the first and second servers are a distribution server and an advertising file server, respectively.

51. The apparatus in claim 39 wherein the Ad Controller applet comprises a download queue and a play queue, wherein, the processor during execution of the Ad Controller applet:

inserts an associated Ad Descriptor file for a advertisement to be downloaded into an end of the download queue;

downloads advertising files specified in a given Ad Descriptor file, then situated at a head of the download queue, into browser storage;

once all the advertising files specified in the given Ad Descriptor file for a corresponding advertisement reside in the browser storage on the computer, removes the given Ad Descriptor file from the download queue and inserts the given Ad Descriptor file into an end of the play queue; and

in response to the user-initiated event and during the ensuing interstitial interval, processes advertising files specified in a specific Ad Descriptor file then situated at a head of the play queue so as to render, through the output device, an advertisement, corresponding to the specific Ad Descriptor file, to the user.

52. The apparatus in claim 51 wherein the agent, in response to the occurrence of the user-initiated event, generates a stop event which, when processed by the agent, suspends the downloading of further advertisement files and initiates processing of files specified in the Ad Descriptor file, then situated at the head of the play queue, so as to render the web advertisement associated therewith during the ensuing interstitial interval.

53. The apparatus in claim 52 wherein the Transition Sensor applet monitors a user click stream so as to detect the user-initiated event and, in response thereto, produce the stop event, and wherein Ad Controller applet processes the stop event to suspend said downloading of further advertisement files and to render the advertisement associated with the Ad Descriptor file then situated at the head of the play queue.

54. The apparatus in claim 53 wherein the output device is a display.

55. The apparatus in claim 53 wherein the first and second servers are a distribution server and an advertising file server, respectively.

56. The apparatus in claim 36 wherein the agent further comprises an applet registry for providing inter-applet communication between the Transition Sensor and Ad Controller applets.

57. The apparatus in claim 36 wherein the processor, in response to execution of the agent, overrides default life cycle methods defined in the browser with corresponding substitute methods such that the agent persistently remains in browser storage as the browser transitions across successive web pages and different web sites.

58. The apparatus in claim 57 wherein the life cycle methods comprise at least one of start, run, stop, initialize and destroy methods.

59. The apparatus in claim 57 wherein the first and second servers are a distribution server and an advertising file server, respectively.

60. The apparatus in claim 36 wherein the processor, through the agent, processes each advertisement as a separate thread so as to effectuate pipe-lined processing of advertisements.

61. The apparatus in claim 60 wherein the first and second servers are a distribution server and an advertising file server, respectively.

62. In a computer having a processor, a memory connected to the processor and storing computer executable instructions, the instructions representing page content and embedded code, a first web page being stored in the memory and containing both the page content and the embedded code, and an output device responsive to the processor, a method for rendering an information object in response to the first web page comprising the steps of:

downloading, as a result of executing the embedded code during processing of the instructions on the first web page, an agent from a first server, and then executing the agent, such that the processor, and through the agent:

downloading to the memory, and while the first web page is being rendered on the output device, both a manifest file associated with the information object from a second server into the memory and at least one additional file as specified in the manifest file from a corresponding file server, wherein the manifest file specifies at least one predefined informational file that comprises part of the information object, a network address at which the one informational file can be accessed and associated configuration information necessary to properly render the information object;

detecting a user-initiated event for initiating a transition from the first web page to a second web page and which signifies a start of an interstitial interval; and

in response to an occurrence of the event:

ceasing downloading of a further file specified in the manifest file, to the extent any downloading of the further file is then occurring; and

processing files for an information object that has been previously downloaded and is currently ready to be rendered so as to render the previously downloaded information object during the interstitial interval to the user.

63. The method in claim 62 wherein the information object comprises a web advertisement, the code comprises advertising code and the manifest file specifies at least an additional file such that the further file constitutes a further advertisement file.

64. The method in claim 63 further comprising the step, performed through the agent and during the interstitial interval, of downloading the second web page from an associated web server in lieu of downloading the further advertisement file.

65. The method in claim 64 further comprising the step performed by the processor, through execution of the advertising code, of downloading the agent in a user-transparent manner, from the first server while the first web page is being rendered through the output device to a user.

66. The method in claim 65 wherein the agent comprises first and second applets.

67. The method in claim 66 further comprising the steps, performed by the processor in response to executing the advertising code while the first web page is being rendered, of:

downloading the first applet; and

once the first applet is downloaded, instantiating and then executing the first applet.

68. The method in claim 67 further comprising the steps performed by the processor, during execution of the first applet, of:

instantiating and starting execution of the second applet; and

monitoring the click-stream so as to detect the user-initiated event comprising the steps of:

instructing the second applet to download the manifest file for the web advertisement from the second server into browser storage residing in the memory; and

in response to an occurrence of the event, instructing the second applet to cease the download of the further advertisement file specified in the manifest file, to the extent any downloading of said further advertisement file is then occurring, and initiating processing through a browser, of files for the previously downloaded advertisement so as to render the previously downloaded advertisement during the next interstitial interval to the user.

69. The method in claim 68 further comprising the steps, performed by the processor in response to executing the advertising code, of:

determining, through the agent, whether a new version of either the first or second applets then resides on the first server relative to a corresponding version, if any, of the first and second applets, respectively, then residing in the browser storage; and

if said new version exists on the first server, downloading the new version from the first server into the browser storage and executing the new version in lieu of the corresponding version.

70. The method in claim 68 wherein the first and second applets comprise a Transition Sensor applet and an Ad Controller applet, respectively.

71. The method in claim 65 wherein the manifest file comprises an Ad Descriptor file having a manifest of names of a plurality of predefined advertising files and associated configuration information necessary to properly play the downloaded advertisement through the browser.

72. The method in claim 71 wherein the agent comprises first and second applets.

73. The method in claim 72 further comprising the steps, performed by the processor in response to executing the advertising code while the first web page is being rendered, of:

downloading the first applet; and

once the first applet is downloaded, instantiating and then executing the first applet.

74. The method in claim 73 further comprising the steps, performed by the processor during execution of the first applet, of:

instantiating and starting execution of the second applet; and

monitoring the click-stream so as to detect the user-initiated event comprising the steps of:

instructing the second applet to download the manifest file for the web advertisement from the second server into browser storage residing in the memory; and

in response to an occurrence of the event, instructing the second applet to cease the download of the further advertisement file specified in the manifest file, to the extent any downloading of said further advertisement file is then occurring, and initiating processing through a browser, of files for the previously downloaded advertisement so as to render the previously downloaded advertisement during the next interstitial interval to the user.

75. The method in claim 74 further comprising the steps, performed by the processor in response to executing the advertising code, of:

determining, through the agent, whether a new version of either the first or second applets then resides on the first server relative to a corresponding version, if any, of the first and second applets, respectively, then residing in the browser storage; and

if said new version exists on the first server, downloading the new version from the first server into the browser storage and executing the new version in lieu of the corresponding version.

76. The method in claim 74 wherein the first and second applets comprise a Transition Sensor applet and an Ad Controller applet, respectively.

77. The method in claim 71 wherein the Ad Descriptor file comprises a list having: a name of each player and media file that constitutes the downloaded advertisement, a corresponding network address at which said each file can be accessed, configuration information for at least one of the player files for properly configuring the corresponding player to render an associated media file.

78. The method in claim 66 wherein the advertising code further comprises a component specifying the second server.

79. The method in claim 78 further comprising the steps, performed by the processor during execution of the second applet and in response to the component contained in the code, of downloading an Ad Descriptor file originating from the second server specified in the second component, the second server being an advertising server.

80. The method in claim 70, wherein the Ad Controller applet comprises a download queue and a play queue, further comprising the steps, performed by the processor during execution of the Ad Controller applet, of:

inserting an associated Ad Descriptor file for a advertisement to be downloaded into an end of the download queue;

downloading advertising files specified in a given Ad Descriptor file, then situated at a head of the download queue, into browser storage;

once all the advertising files specified in the given Ad Descriptor file for a corresponding advertisement reside in the browser storage on the computer, removing the given Ad Descriptor file from the download queue and inserting the given Ad Descriptor file into an end of the play queue; and

in response to the user-initiated event and during the ensuing interstitial interval, processing advertising files specified in a specific Ad Descriptor file then situated at a head of the play queue so as to render, through the output device, an advertisement, corresponding to the specific Ad Descriptor file, to the user.

81. The method in claim 80 further comprising the step, performed through the agent in response to the occurrence of the user-initiated event, of generating a stop event which, when subsequently processed by the agent, suspends the downloading of further advertisement files and initiates processing of files specified in the Ad Descriptor file, then situated at the head of the play queue, so as to render the web advertisement associated therewith during the ensuing interstitial interval.

82. The method in claim 81 further comprising the step, performed through the Transition Sensor applet, of monitoring a user click stream so as to detect the user-initiated event and, in response thereto, producing the stop event, and the step, performed through the Ad Controller applet, of processing the stop event to suspend said downloading of further advertisement files and to render the advertisement associated with the Ad Descriptor file then situated at the head of the play queue.

83. The method in claim 68 further comprising the step, performed by the processor in response to execution of the agent, of overriding default life cycle methods defined in the browser with corresponding substitute methods such that the agent persistently remains in browser storage as the browser transitions across successive web pages and different web sites.

84. The method in claim 83 wherein the life cycle methods comprise at least one of start, run, stop, initialize and destroy methods.

85. The method in claim 68 further comprising the step, performed through the agent, of processing each advertisement as a separate thread so as to effectuate pipe-lined processing of advertisements.

86. The method in claim 65 wherein the advertising code comprises an advertising tag, further comprising the step, performed by the processor in response to execution of the tag, of:

dynamically writing a plurality of predefined applet tags that collectively implement a script into the first web page; and

downloading, in response to subsequent execution of the script, the agent from the first server into the memory and thereafter instantiating and executing the agent.

87. The method in claim 86 wherein the agent comprises first and second applets.

88. The method in claim 87 further comprising the steps, performed by the processor in response to executing the advertising tag while the first web page is being rendered, of:

downloading the first applet; and

once the first applet is downloaded, instantiating and then executing the first applet.

89. The method in claim 88 further, comprising the steps performed by the processor during execution of the first applet, of:

instantiating and starting execution of the second applet; and

monitoring the click-stream so as to detect the user-initiated event comprising the steps of:

instructing the second applet to download the manifest file for the web advertisement from the second server into browser storage residing in the memory; and

in response to an occurrence of the event, instructing the second applet to cease the download of the further advertisement file specified in the manifest file, to the extent any downloading of said further advertisement file is then occurring, and initiating processing through a browser, of files for the previously downloaded advertisement so as to render the previously downloaded advertisement during the next interstitial interval to the user.

90. The method in claim 89 further comprising the steps, performed through the processor in response to executing the advertising tag, of:

determining, through the agent, whether a new version of either the first or second applets then resides on the first server relative to a corresponding version, if any, of the first and second applets, respectively, then residing in the browser storage; and

if said new version exists on the first server, downloading the new version from the first server into the browser storage and executing the new version in lieu of the corresponding version.

91. The method in claim 89 wherein the first and second applets comprise a Transition Sensor applet and an Ad Controller applet, respectively.

92. The method in claim 86 wherein the manifest file comprises an Ad Descriptor file having a manifest of names of a plurality of predefined advertising files and associated configuration information necessary to properly play the downloaded advertisement through the browser.

93. The method in claim 92 wherein the agent comprises first and second applets.

94. The method in claim 93 further comprising the steps, performed by the processor in response to executing the advertising tag while the first web page is being rendered, of:

downloading the first applet; and

once the first applet is downloaded, instantiating and then executing the first applet.

95. The method in claim 94 further comprising the steps, performed by the processor during execution of the first applet, of:

instantiating and starting execution of the second applet; and

monitoring the click-stream so as to detect the user-initiated event comprising the steps of:

instructing the second applet to download the manifest file for the web advertisement from the second server into browser storage residing in the memory; and

in response to an occurrence of the event, instructing the second applet to cease the download of the further advertisement file specified in the manifest file, to the extent any downloading of said further advertisement file is then occurring, and initiating processing through a browser, of files for the previously downloaded advertisement so as to render the previously downloaded advertisement during the next interstitial interval to the user.

96. The method in claim 95 further comprising the steps, performed by the processor in response to executing the advertising tag, of:

determining, through the agent, whether a new version of either the first or second applets then resides on the first server relative to a corresponding version, if any, of the first and second applets, respectively, then residing in the browser storage; and

if said new version exists on the first server, downloading the new version from the first server into the browser storage and executing the new version in lieu of the corresponding version.

97. The method in claim 95 wherein the first and second applets comprise a Transition Sensor applet and an Ad Controller applet, respectively.

98. The method in claim 92 wherein the Ad Descriptor file comprises a list having: a name of each player and media file that constitutes the downloaded advertisement, a corresponding network address at which said each file can be accessed, configuration information for at least one of the player files for properly configuring the corresponding player to render an associated media file.

99. The method in claim 86 wherein the advertising tag further comprises a component specifying the second server.

100. The method in claim 99 further comprising the step, performed by the processor during execution of the second applet and in response to the component contained in the tag, of downloading an Ad Descriptor file originating from the second server specified in the second component, the second server being an advertising server.

101. The method in claim 91, wherein the Ad Controller applet comprises a download queue and a play queue, further comprising the steps, performed by the processor during execution of the Ad Controller applet, of:

inserting an associated Ad Descriptor file for a advertisement to be downloaded into an end of the download queue;

downloading advertising files specified in a given Ad Descriptor file, then situated at a head of the download queue, into browser storage;

once all the advertising files specified in the given Ad Descriptor file for a corresponding advertisement reside in the browser storage on the computer, removing the given Ad Descriptor file from the download queue and inserting the given Ad Descriptor file into an end of the play queue; and

in response to the user-initiated event and during the ensuing interstitial interval, processing advertising files specified in a specific Ad Descriptor file then situated at a head of the play queue so as to render, through the output device, an advertisement, corresponding to the specific Ad Descriptor file, to the user.

102. The method in claim 101 further comprising the step, performed through the agent in response to the occurrence of the user-initiated event, of generating a stop event which, when processed by the agent, suspends the downloading of further advertisement files and initiates processing of files specified in the Ad Descriptor file, then situated at the head of the play queue, so as to render the web advertisement associated therewith during the ensuing interstitial interval.

103. The method in claim 102 further comprising the step, performed through the Transition Sensor applet, of monitoring a user click stream so as to detect the user-initiated event and, in response thereto, produce the stop event, and the step, performed through the Ad Controller applet, of processing the stop event to suspend said downloading of further advertisement files and to render the advertisement associated with the Ad Descriptor file then situated at the head of the play queue.

104. The method in claim 89 further comprising the step, performed by the processor in response to execution of the agent, of overriding default life cycle methods defined in the browser with corresponding substitute methods such that the agent persistently remains in browser storage as the browser transitions across successive web pages and different web sites.

105. The method in claim 104 wherein the life cycle methods comprise at least one of start, run, stop, initialize and destroy methods.

106. The method in claim 89 further comprising the step, performed through the agent, of processing each advertisement as a separate thread so as to effectuate pipe-lined processing of advertisements.

Description

BACKGROUND OF THE DISCLOSURE

1. Field of the Invention

The invention relates to a technique, specifically apparatus and accompanying methods, for implementing in a networked client-server environment, such as the Internet, network-distributed advertising in which an advertisement is downloaded, from an advertising server to a web browser executing at a client computer, in a manner transparent to a user situated at the browser, and subsequently displayed, by that browser and on an interstitial basis, in response to a click-stream generated by the user to move from one web page to the next.

2. Description of the Prior Art

Currently, Internet usage, and particularly that of the World Wide Web (henceforth referred to as simply the "web"), is growing explosively, particularly as the number of web sites and users that have access to the Internet continue to rapidly and to a great extent, exponentially, expand.

In essence, after establishing a suitable network connection to the Internet, a user at a client computer can easily employ a graphical web browser, such as the Internet Explorer ("IE") browser presently available from Microsoft Corporation of Redmond, Wash., to connect to a web site and ther download a desired web page by simply supplying a specific address (known as a URL or uniform resource locator) of that page to the browser. The URL identifies both an address of the site, in terms of its Internet domain name, and a page of information at that site, in terms of its corresponding file name. Each web site stores at least one, and often times substantially more pages all arranged in a pre-defined hierarchy, generally beginning, at its root, with a so-called "home page". Each such page is written in HTML (hypertext markup language) form. A page, in this context, refers to content accessed via a single URL, including, e.g., text, graphics and other information specified in the code for that particular page. Once a user supplies an URL of interest, the browser operated by that user sends an appropriate command, using a TCP/IP protocol (transmission control protocol/internet protocol), to a remote HTTP (hypertext transport protocol) server, located at the web site and which stores that page, to access and download a corresponding file for that page. In response, the server then sends, using the TCP/IP protocol, a stored file containing HTML code that constitutes that page back to the browser. As the file that constitutes the page itself is received by the browser, the browser interprets and executes the HTML code in that file to properly assemble and render the page on, e.g., a monitor to a user situated at the client computer. Such a page may itself contain HTML commands that reference other files, residing on the same or different web sites, which, when these commands are appropriately interpreted and executed by the browser, result in those files being downloaded and their resulting content properly assembled by the browser into the rendered page. Once all the content associated with the page is rendered, the user can then position his(her) mouse cursor on a suitable hypertext link, button or other suitable user input field (whichever here implements a "hotlink") displayed on that page and then, through, e.g., a mouse "click", effectively download a file for and render another desired page in succession until the user has finished his(her) visit to that site, at which point, the user can transition through a hotlink to a page at another site, and so forth. A hotlink specifies a complete web address of an associated page, including a domain name of its hosting web site at which that page is situated. Consequently, by simply and successively positioning and "clicking" his(her) mouse at an appropriate hotlink for each one of a number of desired web pages, the user can readily retrieve an HTML file for each desired page in succession from its corresponding web site and render that page, and, by doing so, essentially effortlessly jump from site to site, regardless of where those sites are physically located.

Ever since their introduction several years ago, HTML and accompanying browser software, now including, e.g., attendant programming languages such as Java and JavaScript languages ("Java" is a registered trademark of Sun Microsystems in Mountain View, Calif.; "JavaScript" is a trademark of Netscape Communications in Mountain View, Calif.), have undergone rather rapid and continual evolution. A major purpose of which has been and continues to be to provide web page authors with an ability to render increasingly rich content through their pages and, as a result, heighten a "user experience" for those users who visit these pages. Consequently, web pages are no longer limited to relatively simple textual displays--as occurred with early versions of HTML and browser software, but can now encompass even full-motion multimedia presentations and interactive games that use rather sophisticated graphics.

The simplicity of browsing the web coupled with the relative low-cost of accessing the Internet, and the relative ease through which a web site can be established are collectively fueling unparalleled growth and diffusion of the Internet itself, web sites and the Internet user community throughout the world. In that regard, by establishing web sites, merchants, vendors and other information providers have an unparalleled opportunity, basically unheard of as little as 5-10 years ago, to reach enormous numbers of potential consumers--regardless of where these consumers reside--at costs far less than previously thought possible. Moreover, given the staggering amount and wide diversity of information currently available on the web, web browsing is becoming so popular a past-time for sufficient numbers of individuals that browsing is beginning to divert significant viewership away from traditional forms of mass entertainment, such as television and cable. While such diversion is relatively small at present, it is likely to rapidly grow. Moreover, given the ease and convenience with which users, situated at their personal computers and with basically nothing more complicated than a few mouse clicks, can effectively interact with remote web sites, electronic commerce, through which goods and services are ordered through the Internet without ever visiting a physical store, is rapidly emerging as a significant sales medium. This medium is likely to significantly challenge and possibly, over a relatively short time, may even alter traditional forms of retailing.

Given the wide and ever-growing reach of the web as a source of consumer information and the increasing consumer acceptance of electronic commerce, advertisers have clearly recognized the immense potential of the web as an effective medium for disseminating advertisements to a consuming public.

Unfortunately, conventional web-based advertising, for various practical reasons--some being technical in nature and others relating to a nature of traditional web advertisements themselves, has generally yielded unsatisfactory results and thus has usually been shunned by most large advertisers. In that regard, several approaches exist in the art for implementing web based advertisements. However, all suffer serious limitations of one form or another that have sharply restricted their desirability and use.

Currently, a predominant format, referred to as a "banner", for a web advertisement takes the form of a rectangular graphical display situated, typically at a fixed location, in a rendered web page. A banner, which can be static or animated, can be situated anywhere within a rendered web page but most often is situated at a top or bottom, or along a vertical edge of that page. A banner, depending on its size, can extend across an entire page width or length, and usually contains, in a graphical eye-catching form, a name of a product or service being advertised. Increasingly, a banner for a given product or service implements a hotlink to enable a consumer to "click-through" the banner (i.e., generate a mouse click on the banner) in order to transition, via his browser, to a web site maintained by a corresponding advertiser and, from that site, fetch a web page to provide additional information regarding that product or service. Hence, the consumer could easily obtain more information by a click-through; while an advertiser, monitoring counts of such click-throughs that occur in a given period of time, could gain feedback on the effectiveness of the corresponding banner.

A banner is generally produced by properly embedding specific HTML code for that banner within the HTML coding for a given web page in which the banner is to appear. A client browser, as it interprets and sequentially executes the HTML code for a fetched page, will, in turn, compile and execute the embedded code for the banner and hence display the banner, as part of a rendered page and at a specified location thereon.

In implementing a banner, whether static or even animated, its HTML coding generally involved downloading an appropriate file, for that banner, to a client browser. The file may be stored on the same server that stores the HTML file for the page, or accessed from a remote server. The file may contain a graphic itself, such as in a GIF (graphic interchange format) file, or a Java applet which, once interpreted and executed by the browser, generates and renders a desired animated graphic. This file, whether it be a graphic or applet, requires time to download and must be downloaded and assembled by the browser on the page prior to that page being fully rendered. The download time for that file, particularly as it increases in size, clearly, a priori, lengthens a time interval during which that page would completely download, thereby extending the time to fully render the page, including the banner, after a user transitioned to that page. Channel bandwidth to a client computer (e.g., personal computer--PC), such as that provided through a modem connection, is often rather limited. Consequently, if the file size for the banner were relatively large--as would certainly be the case for relatively "rich" content, e.g., audio or video content, the delay in downloading such a file over such a limited bandwidth connection could be excessive, and consequently highly frustrating to the user. Hence, a user would likely wait a considerable amount of time before all the page components for multimedia content are fully downloaded to permit that page to be rendered. Such delay, if encountered during a page transition, can be rather frustrating to a user, even to the point at which the user, just to end his(her) waiting, will prematurely terminate the download and transition to another page. Therefore, in an effort to preserve an appropriate "editorial experience" for a user, content suppliers sharply limit the file size, of such banners to be rendered on their pages, in order to minimize page download and hence latency times.

Unfortunately, such restricted file sizes effectively limit the richness of the content of a banner to a rather simplistic advertisement--even with animation. Thus, banners often failed, as advertisers soon recognized by relatively low click-through counts, to attract sufficient viewer attention to justify their use and expense.

In an effort to overcome the content limitation associated with banners, the art teaches the use of a different advertising modality: so-called "interstitial" advertisements. See, e.g., U.S. Pat. No. 5,305,195 (issued to A. J. Murphy on Apr. 19, 1994--hereinafter the "Murphy" patent) which discloses the concept of using interstitial advertisements though not in the context of web advertising. As described in the Murphy patent, pre-stored advertisements are displayed at specific intervals on each one of a group of networked ATM (automated transaction machines) terminals. In particular, the advertisements are downloaded, either directly or via a server, from a remote computer and locally stored on each such terminal and subsequently displayed on that terminal while it waits for a response, from a remote mainframe transaction server, to a transaction initiated at that terminal.

Generally speaking and with specific reference to web advertising, interstitial ads are displayed in an interval of time that occurs after a user has clicked on a hot-link displayed by a browser to retrieve a desired web page but before that browser has started rendering that page. Such an interval, commonly referred to as an "interstitial", arises for the simple reason that a browser requires time, once a user clicks on a hotlink for a new page, to fetch a file(s) from a remote web server(s) for that particular page and then fully assemble and render that page. The length of an interstitial interval, which is quite variable, is governed by a variety of factors, including, e.g., a number of files required to fully render the new page and the size of each such file, and network and server congestion and attendant delays occurring when the user activated the hotlink.

Interstitial web advertising is taught in, e.g., U.S. Pat. Nos. 5,737,619 and 5,572,643 (both of which issued to D. H. Judson but on Apr. 7, 1998 and Nov. 5, 1996, respectively--hereinafter the "Judson" patents). The Judson patents disclose the concept of embedding an advertisement, as an information object, in a web page file in such a manner that the object will remain hidden and not displayed when the file is executed to render the page. Rather than being displayed, the information object is locally cached by the browser during execution of the code for that page. Then, during a transition initiated by user activation of a hotlink to move from that page to a next successive page, i.e., during an interstitial, the browser accesses the advertisement from local cache and displays it until such time as that next successive page is downloaded and rendered. See also, published International patent application WO 97/07656 (to E. Barkat et al and published on Mar. 6, 1997) which teaches the concept of "polite" downloading. Here, a browser, on a local computer (e.g., a client PC) downloads, from an remote advertising system server and ostensibly as a background process, file(s) for a web advertisement only during those intervals when bandwidth utilization of a communication channel (link) connected to the browser is less than a pre-established threshold. Such "polite" downloading is intended to minimally interfere with other communication applications, then executing on the client PC, which will utilize the link. The browser displays the downloaded ad(s) to the user only after the user has not interacted, as detected by a conventional screen saver process, with his(her) PC for a predefined period of time, such as by neither moving a mouse nor depressing a key on a keyboard during that period. The server selects those advertisements for download to the client PC based on a user-ID and preference information of the user, who is then situated at that PC, and configuration information of that PC, which, when a connection is established between the client PC and the server, the client PC uploads to the server. Though the files associated with an interstitial advertisement can be large, these files are advantageously fetched by a client browser during those intervals when otherwise the browser would be idle and hence bandwidth utilization of its network connection would be relatively low. Such "idle times" would occur, in the absence of processing an interstitial ad, after the browser has fully rendered a web page and a user is viewing the page but has not yet clicked on a hotlink to transition to another page. During such an idle time, the browser would simply wait for further user input.

By reducing, if not eliminating, problems, inherent in banners and engendered by download latency, interstitial web advertisements, by employing idle time downloading and local caching, provide a theoretical promise of conveying very rich media content with a pleasing "user experience". However, interstitial advertisements, as conventionally implemented, have serious practical deficiencies which have severely limited their use.

Conventional interstitial, as well as other forms of current, web advertisements--here not unlike banners--rely on embedding HTML ad code, as, e.g., a separate non-displayable object, within HTML coding for a web page. Unfortunately, this approach, inherent in that taught by the Judson patents, can be inflexible and expensive for an advertiser to implement and particularly later should that advertiser, for whatever reason, seek to modify his(her) ad content. In particular and presently, ad coding is manually inserted into each and every content web page that is to carry advertising. Consequently, insertion of increasingly sophisticated embedded advertising, such as multi-media or video or audio, in existing web site content requires a large investment in terms of human resources, time and cost as web sites, particularly large sites, increase a number of content pages available for advertising. In that regard, where a banner usually required insertion of, e.g., a single line of HTML code, content rich advertisements, such as those now implemented by parameterized embedded Java advertising applets, often consist of an entire page of coding and hence require far more extensive and increasingly labor-intensive and costly insertions. Moreover, over time, advertisers do change their ads--such as by replacing one ad with a totally new version. However, once HTML ad coding is embedded within a number of web pages, it can be quite impractical and rather costly for an advertiser to access each and every page in which his(her) ad coding has been inserted and then manually change the ad coding, as desired. The impracticality and attendant cost compound if these pages are copied to other web sites and hence diffuse through the Internet.

Given these deficiencies, the art teaches a concept of implementing web advertising through using so-called "push" technology. See, e.g., U.S. Pat. No. 5,740,549 (issued to J. P. Reilly et al on Apr. 14, 1998--hereinafter the "Reilly et al" patent). In essence and as described in the Reilly et al patent, a client PC, through execution of a "push" application program (called "administration manager"), establishes a network connection with an information server, i.e., a "push" web server, typically during off-hours, such as in the late evening or early morning, or at a predefined interval (e.g., every four hours). The information server then downloads, i.e., "pushes", to the administration manager, content files, such as for advertisements and/or other predefined information, that are to be played to the user sometime later. The administration manager, i.e., the "push" application, in turn, stores all the "pushed" content files into a local database (referred to as the "information database") on a local hard disk and, in response to instructions received from the information server, deletes those previously "pushed" content files which have already been displayed. The administration manager also maintains a user profile, which specifies user preferences as to the specific advertising and/or other information (s)he wants to receive, in the information database. As such, through each connection, the information server, by selecting content from its database relative to preferences specified in the user profile, attempts to "push" fresh content to the client PC that is likely to be of interest to the user but without duplicating that which was already displayed. Stored "pushed" content is later displayed, using a data viewer, either on user demand or during those times when the user is not interacting with the system, here too detected by a conventional screen saver procedure.

While push technology reduces download latency, by shifting downloads to occur at off-hours, this technology also suffers serious drawbacks which have greatly restricted its practical acceptance.

In particular, to access "pushed" content, a user must initially download and install to his(her) client PC a separate, platform-specific, software application program, as well as subsequent updates to that program as new push capabilities are released by the manufacturer of the program. Unfortunately, these application programs can often extend to tens of megabytes in length. Since typical Internet users establish modem connections to their Internet service provider, these users will find that downloading these relatively large program files, even in compressed form, will consume an inordinate amount of time and is generally impractical while (s)he is actively using his(her) client PC. Consequently, these users are constrained to purchasing, at some cost, an off-the-shelf version of the application program or downloading that program, typically at no cost for the program itself, at off-hours, when network congestion is relatively light. Furthermore, while some efforts are underway in the art to automatically "push" and install incremental software updates to a client PC, thus eliminating a need for a user to manually do so, the user still faces the burden associated with the initial download and installation of the "push" application program.

In addition, "push" application programs continue to increase in size, often considerably, as they provide added capabilities to a user. Downloading and then regularly updating a push application will reduce, sometimes considerably, the amount of disk space available to the user on his(her) client PC. Furthermore, "push" applications rely on periodically "pushing" large quantities of media content from a push server to the client PC and storing that content on the hard disk of that PC pending subsequent display. This content, depending on its volume, can consume inordinate amounts of hard disk space. Furthermore, advertisers have discovered, not surprisingly, that relatively few PC users will undertake any affirmative action, such as by downloading and installing an application program--almost regardless of its size, to receive advertisements and other such information.

Faced with these practical, and rather acute, deficiencies inhering in web advertising conventionally provided on either an interstitial or "push" basis, web advertisers have apparently relegated their efforts to displaying their advertisements on a banner-like approach, through real-time downloading and rendering of advertising HTML files. Here, the advertising files are sited on remote web servers, rather than being embedded within given web page HTML files, with appropriate HTML tags, which reference the ad files, being embedded into the web page files themselves. Such a tag specifies when and where, within the page, an advertisement is to appear.

To surmount the latency problems inherent in such banner-like advertisements, various proprietary media formats have appeared in the art. These formats employ increasingly sophisticated data compression, sometimes in conjunction with video and/or audio streaming. Rather than waiting for a media file to fully download prior to its being rendered, streaming permits content in a "streamed" media file to be presented in real-time to the user as that content arrives at his(her) client browser. While this approach clearly provides enhanced richness in content over that obtainable through a conventional banner and thus can heighten a "user experience", it nevertheless relies, to its detriment, on a continuous real-time network connection existing to a remote web server.

Unfortunately, any network or server congestion which stops the download, even if temporary, can suspend, i.e., freeze, or totally halt the "streamed" media presentation to the user prior to its completion. This interruption, if noticeable and sufficiently long, will likely frustrate the user and degrade the "user experience".

In spite of these drawbacks, particularly with respect to interstitial advertisements and push technology, and apparently for lack of a better alternative, most web advertising currently in use employs real-time streaming of graphic files with their content being rendered by the browser.

Web advertisements, like other forms of mass advertising, do generate revenue, often in the form of an on-going stream of payments to the host of the ads, in this case web site owners. Accurate user accounting is essential to ensure that an advertiser is not over- or under-charged given an extent to which an ad is actually disseminated. Hence, these payments are often tied to a function of the number of web users whom the ad reached. But with web advertisements, accurately ascertaining that number has been difficult and problematic at best, and, given a basic technique employed to do so, manifestly error-prone, thereby causing unreliable user counts and erroneous ad charges.

In particular and as conventionally employed, delivery of a web advertisement, such as, e.g., a streamed ad, is logged as a "user impression" at a web server at an instant an advertising file(s), e.g., a streamed file, is served, rather than after the browser has completely rendered the advertisement to the user. Unfortunately, serving these ad files does not guarantee that these files will be ultimately and completely rendered by a client browser to a user. Consequently, web server generated "user impression" counts can be grossly understated. For example, if a user navigates to a new content page after an advertisement has started playing but before that advertisement completes and, by doing so, prematurely terminated the advertisement, a full impression is nevertheless logged--erroneously--since that advertisement was completely served. Additional errors arise if a proxy server is situated between multiple client PCs situated on an intranet or a local area network (LAN) and a web advertisement server situated on the Internet (or other insecure public network). In this case, a request from one of the client PCs for the advertisement files will be routed to the proxy server, which, in turn, will direct that request onward to the advertisement web server. The latter, in response to the request, will serve one complete copy of the advertisement files to the proxy server. The resulting fetched advertisement files will be locally cached in the proxy server and, from there, provided to the requesting client PC. Should any of the other client PCs request the same files, the proxy server will provide these files, totally unbeknownst to the web server, from its local cache rather than directing a request from that other PC back to the web server. Hence, the web server will be totally oblivious to each additional instance in which the proxy server accessed the ad files from its local cache and disseminated the advertisement to any client PC other than that which first requested the ad. Inasmuch as some intranets situated behind a proxy server(s) can be rather extensive with tens or hundreds of thousands of individual client PCs, server-based user impression accounting based on copies delivered by a web server may, owing to the presence of proxy servers, be inordinately low and result in significant under-charges to the advertiser. As of yet, no solution apparently exists in the art that can provide accurate counts of "user impressions" of web advertisements.

Other conventional approaches aimed at reducing latency times associated with downloading content files through relatively slow speed communication links, e.g., modem connections, have involved development and use of new facilities within various programming languages. These approaches, most notably involving the Java and JavaScript programming languages, while helpful, still cause inefficient use of available link bandwidth and still constrain the size of the content files. These limitations arise from premature terminations of preloaded files whenever a user transitions to a new web page. Specifically, with these approaches, if a user activates a hotlink to transition to a new web page while an ad file is being downloaded but before the downloading has completed, then the downloading simply stops. The downloading will need to be re-started, but from the beginning of the file, the next time that particular ad file is requested. Hence, the time and bandwidth that has then been expended in downloading part of that ad file is completely wasted. In practice, many users tend to quickly navigate through a series of web pages until they reach a desired destination. Consequently, advertisers are constrained to again minimize content file sizes and hence "richness" of their advertisements in an effort to decrease a number of premature terminations per unit time and in doing so reduce latency caused by downloading duplicate sections of the same ad file. Therefore, these approaches have generally proven to be wholly unsatisfactory.

In view of the fundamental drawbacks associated with various web based advertising techniques known in the art, interstitial web advertising appears to hold the most promise of all these techniques. Yet, the limitations inherent in conventional implementations of conventional interstitial advertising have effectively prevented this form of web advertising from effectively fulfilling its promise. Moreover, the deficiencies inherent in all known web advertising techniques have, to a significant extent, collectively inhibited the use of web advertising in general.

Thus, a pressing need exists in the art for a new web-based interstitial advertising technique which does not suffer from infirmities associated with such interstitial advertising techniques known in the art.

In that regard, this new technique should preferably not embed advertising HTML files within a web page. If this could be accomplished, then advantageously such a technique would likely provide considerable economies to advertisers in saved labor, time and cost in terms of both inserting advertisements into web page files, and later changing any of those advertisements. In addition, such a new technique should preferably function in a manner that is substantially, if not totally, transparent to a user and which neither inconveniences nor burdens that user. In particular, this new technique should preferably not require a user to download and install on his(her) PC a separate application program, let alone any update to it, specifically to receive web advertising, or perform any affirmative act, other than normal web browsing, to receive such advertising. Furthermore, this new technique should preferably be platform independent and, by doing so, operate with substantially any web browser on substantially any PC. Also, this new technique, when in use, should preferably not consume excessive hard disk space on a client PC. Moreover, to provide a pleasing "user experience", this new technique should render an ad fully and without any interruptions that might otherwise result from network and/or server congestion. Lastly, this new technique should provide proper accounting to an advertiser by accurately and validly ascertaining user impressions of fully rendered advertisements.

We believe that if such a new web-based interstitial advertising technique could be provided, then this technique, which should be both effective and desirable, may well achieve broad support and use by advertisers and acceptance by web users; hence, substantially expanding the use of web-based advertising in general.

SUMMARY OF THE INVENTION

Advantageously, our present inventive technique satisfies this need by overcoming the deficiencies associated with conventional web-based interstitial advertising techniques.

Our present invention accomplishes this, in accordance with our broad inventive teachings, by: completely "decoupling" advertising content from a web content page (also hereinafter referred to as a "referring" page); "politely" downloading advertising files, through a browser executing at a client computer, into browser caches (e.g., browser disk and RAM cache) at that computer and in a manner that is transparent to a user situated at the browser; and interstitially displaying advertisements through the browser in response to a user click-stream associated with normal user navigation across different web pages.

Specifically, our technique relies on embedding an HTML tag (which, where necessary, to distinguish this tag from other HTML tags, will be also referred to hereinafter as an "advertising tag") into a referring page. This tag contains two components. One component effectively downloads, from an distribution HTTP (web) server and to an extent necessary, and then persistently instantiates an agent, implemented as a "light-weight" Java applet, at the client browser. This agent then "politely" and transparently downloads advertising files (media, and, where necessary, player files), originating from an ad management system residing on a third-party advertising HTTP (web) server, for a given advertisement into browser-disk cache (also in the case of media files into the browser RAM cache) and subsequently plays those media files through the browser on an interstitial basis and in response to a user click-stream. The other component is a reference, in terms of a web address, of the advertising management system from which the advertising files are to be downloaded. This latter reference totally "decouples" advertising content from a web page such that a web page, rather than embedding actual advertising content within the page itself--as conventionally occurs, merely includes an advertising tag that refers, via a URL, to a specific ad management system rather than to a particular advertisement or its content. The ad management system selects the given advertisement that is to be downloaded, rather than having that selection or its content being embedded in the web content page.

Advantageously, the agent operates independently, in the client browser, of the content in any referring web page. Once loaded and started, the agent executes in parallel, with standard browser functionality, continually and transparently requesting and downloading advertisements to browser cache residing in a client computer (e.g., personal computer--PC) and interstitially playing those advertisements.

In particular, once the agent is started, the agent politely and transparently downloads, through the client browser and to the browser cache, both media and player files, originating from the advertisement management server, for an advertisement that are needed to fully play content in that advertisement. The agent also monitors a click-stream generated by a user who then operates the browser. In response to a user-initiated action, e.g., a mouse click, which instructs the client browser to transition to a next successive content web page and which signifies a start of an interstitial interval, the agent, if all the media and player files are then resident on the client hard disk, plays the media files, through the browser and during that interstitial interval, directly from the browser cache. Advertisements are interstitially played typically in the order in which they were downloaded to the client browser. Interstitial play from browser cache advantageously permits previously cached content rich advertisements to be played through the browser without adversely affecting communication link bandwidth then available to the client browser. Thus, the full available link bandwidth can be used, while an advertisement is being played, to download a next successive content web page.

Employing a user click-stream to trigger play of cached advertisements frees the user, for receiving advertising, of any need either to undertake any affirmative action, other than normal web browsing, or to learn any new procedure; thus, advantageously imposing no added burden on the user.

Advantageously, the agent "politely" downloads advertisement media and player files, originating from the advertising server, to the browser cache, during what otherwise would be browser idle times, i.e., while a web page is being displayed to a user and the browser is waiting for user input. Caching advertisement files in this fashion advantageously circumvents variable latency and erratic (e.g., intermittent or suspended) play that frequently occurs with conventional streamed and static media delivered over the web.

At the start of an interstitial interval, the agent determines whether all the media and player files required to play a given advertisement (typically that having its so-called AdDescriptor file situated in a head of a play queue) then reside on the disk of the client PC or, with respect to media files, are resident in browser RAM cache. If so, the agent then accesses these files from the disk to "play" that advertisement. Since all the media and player files are then locally resident, the advertisement, from a user's perspective, is immediately rendered from the client hard disk or browser RAM cache with essentially no downloading delay, thus providing a highly pleasing "user experience" with rich multi-media content approaching that obtainable through current CD-ROM based delivery. Thereafter, the agent returns control to the browser to permit the browser, if a next successive web page has been downloaded, assembled and ready to be rendered, to render that particular page to the user. If, however, an advertisement is prematurely terminated by a user, that advertisement (in terms of its AdDescriptor file) will remain in a play queue (with its media and player files remaining on the client hard disk or, in the case of media files, in browser RAM cache) and will be re-played from its beginning at the start of a next successive interstitial interval. Furthermore, if download of the media and player files for an advertisement were to be interrupted by a user click-stream, i.e., start of interstitial interval, the agent suspends further downloading until after the ensuing interstitial interval terminates. To conserve communication link bandwidth, the agent then resumes downloading of these files at a point it was suspended, rather than, as conventionally occurs, totally re-starting the download.

In accordance with our specific inventive teachings, the agent contains two applets: a Transition Sensor applet and an "AdController" applet. Only the Transition Sensor applet is itself associated with any content page. Though the AdController applet, once started, executes under the browser, it is not under the control of the browser itself.

The advertising tag is itself embedded in a content web page. The advertising tag, as one of its components, references a JavaScript file (which contains a "script") stored on a distribution server. The JavaScript file, when executed, downloads and implements, through dynamic writing of applet tags, the Transition Sensor applet. This particular applet remains visually transparent to a user who displays, with his(her) browser, the HTML coding for that page. Specifically, when the JavaScript file is downloaded and the script it contains is then executed by the browser, the script dynamically writes a predefined number and combination of applet tags, i.e., which collectively form the Transition Sensor applet, into the retrieved web page content in lieu of the advertising tag. Subsequent execution of these tags, by the client browser, invokes the Transition Sensor applet. As discussed, the advertising tag also, as the other of its components, encapsulates a reference, i.e., a URL to a specific ad management server, typically sited on a third party advertising server, containing specific media, that collectively constitutes web advertisements, and accompanying player files.

In particular, when executed, the Transition Sensor applet instantiates an Applet Registry, which is used for inter-applet communication. Thereafter, the Transition Sensor applet determines whether the AdController applet has been downloaded to the browser disk cache or whether an updated version of this particular applet resides on the distribution server. If an updated version of this applet exists on the distribution server relative to that previously downloaded to the browser disk cache or if this applet has not been download at all onto this cache, the Transition Sensor applet loads the AdController applet from the distribution server into the browser disk cache. The Transition Sensor applet then instantiates the AdController applet. Once this occurs, the Transition Sensor applet then establishes appropriate entries in the Applet Registry for itself and the AdController applet.

The Transition Sensor applet then passes the URL of the ad management system, as specified in the advertising tag, to the AdController applet in order for the latter applet to request delivery of an advertisement, specifically an associated AdDescriptor file, originating from that system. The system then selects the advertisement to be delivered and, via the third party advertising server, so informs the AdController applet by returning the requested AdDescriptor file. For a given advertisement, this particular file, which is textual in nature, contains a manifest, i.e., a list, of: file names and corresponding web addresses of all media files that constitute content for that advertisement and all player files necessary to play all the media files; an order in which the various media files are to be played; and various configuration and other parameters need to configure and operate the operation of each player in order for it to properly play a corresponding media file(s). The AdController then "politely" downloads, typically via the advertising distribution server, the associated media and player files, as specified in the AdDescriptor file--and to the extent they do not already reside on the hard disk of the client PC. As noted above, the Transition Sensor applet also monitors a click-stream produced by the current user to detect a user-initiated page transition and hence the start of an interstitial interval.

Advantageously, the AdDescriptor file implements a data abstraction that totally separates the media and player files from the referring web page thus assuring that the advertisement content itself remains completely independent of the content web page that invoked its presentation. This abstraction permits our technique to provide a highly effective, generalized and very flexible mechanism for delivering rich web advertisements, particularly those that require complex sets of media files and players. Through use of this abstraction, our technique is able to handle present and future media formats, regardless of their requirements, including proprietary streaming and other content delivery technologies that rely on Java applets as a delivery mechanism--all transparently to the user. Moreover, since the AdDescriptor file can specify media and player files for different browsers, operating systems and computing platforms then in use, our technique can readily function with a wide variety of different computing and browsing platforms.

The Transition Sensor and AdController applets are each implemented through appropriate Java classes and collectively persist, through storage in the browser disk cache, across different content pages within a site, across different web sites, and across successive browser sessions. Once either of these applets is completely downloaded, providing it is not subsequently flushed from the browser disk cache as the user navigates across web sites on the web, the files for that applet will be loaded from that cache, rather than being downloaded from the distribution server, the next time that applet is required, e.g., when the user next navigates, either during a current browser session or a subsequent session, to any content page that contains an advertising tag.

Whenever the client browser encounters a next successive page containing an advertising tag, then the browser will first and automatically inquire with the distribution server to ensure that executable code for the Transition Sensor applet, if previously downloaded into the browser disk cache, has not been superseded by an updated version. If such an updated version then exists, the browser will collectively download updated files from the distribution server and replace, to the extent necessary, each Transition Sensor applet file residing in the browser disk cache with its updated version. Alternatively, if the Transition Sensor applet has not been previously downloaded into the browser disk cache, then the browser will download all the necessary files for the Transition Sensor applet from the distribution server into that cache. The Transition Sensor applet, once executing, will load, through the browser, the AdController applet. To do so, the browser will, if necessary, obtain an updated version, from the distribution server, in the same manner as it did for the Transition Sensor. As a result, any corrections or enhancements made to the agent (specifically the Transition Sensor and/or the AdController applets) since the agent was last downloaded to the client browser will be automatically and transparently, from a user perspective, distributed to that browser and downloaded into the browser disk cache the next time the browser encounters a web page containing an advertising tag. By operating in this fashion, the user is totally and advantageously relieved of any need to: both initially load and install an application program to obtain advertising and/or later update that program.

Furthermore, the agent advantageously persists and functions transparently in background, independent and transparent to user navigation across pages on a common web site and across web sites. The agent effectively implements a background process which runs in parallel with and is transparent to normal HTML and HTTP operations implemented by the client browser.

Moreover, in sharp contrast to conventional server-based accounting of web advertisements, our inventive technique provides highly accurate client-side accounting of each user impression. Each log entry, produced by the AdController applet, specifies a successful presentation of a complete advertisement at a client browser. This entry may include a source of the ad content, i.e., in terms of the URL of the associated ad management system, a title of the advertisement and the URL of the referring web page. Other client-side information can be measured and included in each entry, such as: an amount of time during which the advertisement was rendered by the browser (presumably during which the user dwelled on the advertisement); as well as an identification, in terms of a URL, of a content web page to which the user next navigated (particularly if the user reached that page through a hotlink displayed in the advertisement). Subsequently, the AdController applet uploads the log entries to the advertising server. These entries will be collectively processed, as needed, to permit shared ad revenues from web-based advertisers to be properly allocated among different web page content providers.

Advantageously, our inventive technique, by totally decoupling referring web page content from its corresponding advertising content, easily permits an advertiser to change or update any of its advertisements by just modifying, as needed, appropriate media and AdDescriptor files that reside in the third-party advertising management system. Since a referring web page merely incorporates an advertising tag totally devoid of advertising content, no changes whatsoever need to be made to that page. Hence, use of our inventive technique substantially reduces the burden, time and cost associated with maintaining and updating web-based advertising over that conventionally required.

As a feature, our inventive technique advantageously implements, in conjunction with its persistent agent approach, multi-threaded pipelining. By processing each different advertisement as a different thread, each one of a sequence of different processing operations can be performed, effectively on a pipe-lined parallel basis, on different sequentially occurring advertisements, thereby enhancing a rate (increasing throughput) at which advertisements can be queued for playback. In addition, through such pipe-lining, logging of a fully presented advertisement can occur as a last operation in a pipeline and essentially in parallel either: with presentation of cached advertisement having its AdDescriptor file situated in the play queue immediately behind that for the just presented advertisement, or with downloading and caching of a next successive advertisement.

BRIEF DESCRIPTION OF THE DRAWINGS

The teachings of the present invention can be readily understood by considering the following detailed description in conjunction with the accompanying drawings, in which:

FIG. 1A depicts the correct alignment of the drawing sheets for FIGS. 1B and 1C;

FIGS. 1B and 1C collectively depict a high-level block diagram of an illustrative client-server distributed processing environment, implemented through the Internet, which embodies the teachings of our present invention, along with, as pertinent to the invention, basic inter-computer actions that occur in that environment and associated client processing operations;

FIG. 1D depicts the correct alignment of the drawing sheets for FIGS. 1E and 1F;

FIGS. 1E and 1F collectively depict the same environment as shown in FIGS. 1B and 1C but showing an detailed version of agent download/instantiate/execute operations 50 shown in the latter figures;

FIG. 2 depicts the correct alignment of the drawing sheets for FIGS. 2A and 2B;

FIGS. 2A and 2B collectively depict generalized web page HTML code 35, specifically inclusion of advertising tag 40, which transparently invokes our invention, and changes which our invention dynamically makes to that code, specifically substitution of Transition Sensor applet 210 for tag 40 to yield page 35', in order to download and render web advertisements;

FIG. 3 depicts a high-level block diagram of client PC 5 shown in FIGS. 1B and 1C, and 1E and 1F;

FIG. 4 depicts a simplified high-level block diagram of application programs 400 resident within client PC 5 shown in FIG. 3;

FIG. 5 depicts a high-level block diagram of AdController agent 420 shown in FIG. 4, which implements our present invention;

FIG. 6 depicts the correct alignment of the drawing sheets for FIGS. 6A and 6B;

FIGS. 6A and 6B collectively depict a high-level flowchart of processing operations 600 performed by AdController agent 420 shown in FIG. 5;

FIG. 7 depicts a high-level block diagram of basic processing threads that implement AdController applet 424 which, as shown in FIG. 4, forms part of AdController agent 420;

FIG. 8 depicts a high-level flowchart of processing operations 800 performed by AdController applet 424 shown in FIG. 7;

FIG. 9 depicts the correct alignment of the drawing sheets for FIGS. 9A and 9B;

FIGS. 9A and 9B collectively depict a flowchart of processing operations 900 performed by AdController applet 424, shown in FIG. 7, specifically for processing an advertisement;

FIG. 10 depicts inter-applet events that occur within AdController agent 420 during execution of Transition Sensor applet 422;

FIG. 11 depicts a high-level block diagram of basic processing threads that implement Transition Sensor applet 422 which, as shown in FIG. 4, forms part of AdController agent 420;

FIG. 12 depicts a high-level flowchart of processing operations 1200 performed by Transition Sensor applet 422 shown in FIG. 11;

FIG. 13 depicts a high-level block diagram of Ad Loader process 1300 which can be used to provide advertiser control over various functions, for advertisement play and logging, implemented by AdController applet 424;

FIG. 14 depicts a high-level block diagram of Ad Pipeline 545 that is implemented by and forms part of AdController applet 424 shown in FIG. 4;

FIG. 15 depicts a high-level block diagram of Ad Producer process 1500 that is executed by Ad Pipeline 545 shown in FIG. 14;

FIG. 16 depicts a high-level block diagram of Ad Location process 1600 that is also executed by Ad Pipeline 545 shown in FIG. 14;

FIG. 17 depicts a high-level block diagram of Ad Downloader process 1700 that is also executed by Ad Pipeline 545 shown in FIG. 14;

FIG. 18 depicts a flowchart of stop method 1800 invoked by Transition Sensor applet 422 shown in FIG. 4;

FIG. 19 depicts a flowchart of start method 1900 invoked by Transition Sensor applet 422 shown in FIG. 4; and

FIG. 20 depicts contents of actual illustrative AdDescriptor file 2000 for use in interstitially rendering a PointCast type Java advertisement through our present invention.

To facilitate understanding, identical reference numerals have been used, where possible, to designate identical elements that are common to the figures.

DETAILED DESCRIPTION

After considering the following description, those skilled in the art will clearly realize that the teachings of our present invention can be utilized in any networked client-server environment in which advertising or other information is to be presented to a user during interstitial intervals, i.e., during a transition between successively displayed web pages. Such an environment can encompass the Internet or an intranet, or any client-server environment in which a client browser (regardless of whether that browser executes on a dedicated client computer or not) is used to access and download web pages or, more generally speaking, files through a network communication channel (link) from a server (again regardless of whether that server executes on a dedicated computer or not). In that regard, the server can be a separate software application which executes on any computer in the networked environment, even if that computer is itself a client to another server in the network.

For purposes of simplicity and to facilitate reader understanding, we will discuss our present invention in the illustrative context of use in rendering interstitial web-based advertisements to a client personal computer (PC) connected to the Internet, where specifically a client browser executing in the PC is used to download and render web pages from a remote networked Internet accessible web server. Clearly, after considering the ensuing description, anyone skilled in the art will readily appreciate how the teachings of our invention can be easily incorporated into any client-server or other similar distributed processing environment in which a client can encompass not only a specific computer connected to a network but a software process that possesses network connectivity to another such process and requests information from and, in response, obtains information supplied by the latter.

We will first present an overview of our invention, particularly in the context of its use with an Internet web browser in a client PC, followed by describing each basic component of its implementation.

A. Overview

A general deployment of our invention in an Internet environment is collectively shown in FIGS. 1B and 1C, with a detailed view of a portion of the inter-processor agent download/instantiation operations 50 shown in these figures being depicted in FIGS. 1E and 1F. The correct alignment of the drawing sheets for FIGS. 1B and 1C, and 1E and 1F is shown in FIGS. 1A and 1D, respectively. FIGS. 2A and 2B, for which the correct alignment of the drawing sheets for these figures is shown in FIG. 2, collectively depicts generalized web page HTML code which transparently invokes our invention, and changes which our invention dynamically makes to that code in order to download and render web advertisements. For a understanding, the reader should simultaneously refer to FIGS. 1B and 1C, 1E and 1F, and 2A and 2B throughput the following discussion.

As shown, client PC 5, upon which client browser 7 executes, is connected through communication link 9 to Internet 10. Browser 7 is a conventional web browser, such as Internet Explorer or Netscape Navigator commercially available from Microsoft Corporation or Netscape Corporation, respectively. Preferably, for reasons that will shortly become clear, that browser should preferably support dynamic writing of applet tags. Though, for ease of illustrating inter-computer actions, we depicted Internet 10 as having portions 10.sub.A and 10.sub.B, we will collectively refer to both portions as simply Internet 10. Web server 13, connected, via link 11, to Internet 10 represents any web HTTP (hypertext transfer protocol) server. This server, in response to a request to fetch a specific file from web browser 7, downloads that file, using conventional TCP/IP protocols (transmission control protocols/internet protocols), through the Internet to browser 7. Browser 7 will, in turn, render that file typically on a monitor to a user situated at the client PC.

Advertising distribution HTTP server (also referred to as "agent" server) 15 is connected, via communications link 17, to Internet 10 and stores files that collectively implement a predefined agent, specifically, a light weight Java applet. This agent (referred to herein as the "AdController" agent) transparently pre-loads itself, as well as media rich advertising content, into a local hard disk cache associated with the browser ("browser disk cache") on client PC 5. Server 15 downloads the AdController agent in a manner to be described below, to client browser 7. This agent, once instantiated and started, then transparently and politely downloads (actually pre-loads) advertisements into the browser disk cache, and subsequently plays each of those advertisements, on an interstitial basis, in response to a click stream generated by the user as (s)he navigates, through use of browser 7, between successive web pages. Such hard disk caching advantageously circumvents variable latency and erratic play associated with conventional streamed and static media delivered over the Internet. The agent enables rich advertising to be presented in a highly-controlled fashion, resulting in user experiences approaching that of CD-ROM.

Third-party ad HTTP server 20, connected to Internet 10 via, e.g., communications links 18 and 23, hosts ad management system 25. In essence and as discussed in detail below, this system, in response to a request originating from the AdController agent executing in browser 7, selects a given advertisement and then downloads, in a "polite" manner controlled by the agent, media and player files that form that advertisement to the agent for storage in the browser disk cache. Inasmuch as Java applets are currently restricted under constraints inherent in the Java programming language itself to retrieving files from an identical Internet host that served the applet itself, the request for an advertisement to system 25 as well as resulting media and player files served by system 25 are routed through agent server 15 as a proxy server.

Advantageously, our inventive technique completely "decouples" advertising content from a web content page (also hereinafter referred to as a "referring" page). This, in turn, permits our technique to render media-rich advertisements without requiring inclusion of any advertising content into a referring web page. This "decoupling" is effectuated through inclusion of an HTML tag into a content web page, which when the latter is downloaded, interpreted and executed by the browser, effectively loads and instantiates the agent and then retrieves advertisement files from an ad management system specified in the tag. Thus, advertising files (both media and player files) can be maintained totally independently of their referring web page(s), with advantageously any changes made to the former having no effect on HTML coding contained in the latter.

In particular, HTML tag 40 (which, where necessary, to distinguish this tag from other HTML tags, will be also referred to hereinafter as an "advertising tag") is embedded by a content provider(s) into HTML code that constitutes each referring web page, e.g., here page 35. Generally, the position of this tag relative to existing HTML code (shown as HTML code portions 35.sub.A and 35.sub.B in FIGS. 2A and 2B) for this page is not critical. Advantageously, very rarely, if ever at all, do any changes need to be made to these code portions to accommodate the tag. As shown and as reproduced in Table 1 below, this tag, which typically consumes one line in a web page, implements a script.

                             TABLE 1
                         ADVERTISING TAG
                <SCRIPT SRC=http://unicast.com/loadad.js>
                AdServer="http://AdManagement system"
                </SCRIPT>

                             TABLE 2
                     TRANSITION SENSOR APPLET
    <applet code="com.unicast.adcontroller.tools.TransitionSensor"
    codebase="http://www.unicast.com/java/classes/"
    align="baseline" width="0" height="0" name="TransitionSensor"
    archive="adcontroller.jar">
    <param name="adURL"
    value="http://www.unicast.com/media/fireworks_01_ad_descriptor.txt">
    <param name="cabbase" value="adcontroller.cab">
    </applet>