USOO6985934B1
`
`(12) United States Patent
`Armstrong et al.
`
`(10) Patent No.:
`(45) Date of Patent:
`
`US 6,985,934 B1
`Jan. 10, 2006
`
`(54)
`
`(75)
`
`(73)
`
`(21)
`(22)
`(51)
`
`(52)
`(58)
`
`(56)
`
`METHOD AND SYSTEM FOR PROVIDING
`RICH MEDIA CONTENT OVERA
`COMPUTER NETWORK
`
`Inventors: Brooke Allysoun Armstrong, Berkeley,
`CA (US); John Robert Behrens,
`Emeryville, CA (US); Abie
`Hadjitarkhani, San Francisco, CA
`(US); Alexander Blair Ireland, East
`Norriton, PA (US); Stephen John
`Muller, San Francisco, CA (US);
`Nancy Kiyoko Narimatsu, Brisbane,
`CA (US)
`Assignee: Binham Communications
`Corporation, San Francisco, CA (US)
`Subject to any disclaimer, the term of this
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 520 days.
`Appl. No.: 09/693,867
`
`Notice:
`
`Filed:
`
`Oct. 23, 2000
`
`Int. Cl.
`(2006.01)
`G06F I3/00
`U.S. Cl. ....................... 709/219; 709/231; 719/328
`Field of Classification Search ................ 709/217,
`709/219, 224, 225, 226, 227, 231, 232,328,
`709/329; 719/328,329
`See application file for complete Search history.
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`5,187,787 A
`2/1993 Skeen et al.
`5,187,787 A
`2/1993 Skeen et al.
`5,305,195 A 4/1994 Murphy
`5,347,632 A 9/1994 Filepp et al.
`5,515,490 A 5/1996 Buchanan et al.
`5,572,643 A 11/1996 Judson
`5,604,542 A 2/1997 Dedrick
`5,666,359 A 9/1997 Bennett et al.
`5,706.434 A 1/1998 Kremen et al.
`
`5,727,184 A 3/1998 Richter et al.
`5,737,619 A 4/1998 Judson
`5,740,549 A
`4/1998 Reilly et al.
`5,742,602 A 4/1998 Bennett
`5,848,415. A 12/1998 Guck
`(Continued)
`FOREIGN PATENT DOCUMENTS
`
`EP
`
`EPO 996 253 A2 4/2000
`(Continued)
`OTHER PUBLICATIONS
`"Spyglass Prism, Concepts and Applications”, Spyglass
`Prism. Concepts and Application, 1997, pp. 1-7,
`XPOO2943O26.
`Primary Examiner-Viet D. Vu
`(74) Attorney, Agent, or Firm-Sterne, Kessler, Goldstein &
`Fox, P.L.L.C.
`
`(57)
`ABSTRACT
`The invention presented here is a method and System for
`providing rich media content over a computer network. In
`accordance with the invention, a Server on a physical or
`wireleSS computer network polls the Software, hardware, or
`appliance of an end user on the network, for the availability
`of Software and/or hardware necessary for the display of rich
`media content. This polling is transparent to the end user and
`requires no action on the part of the end user. Based on the
`client's response, the Server Sends an appropriately format
`ted version of the rich media file. The user is not necessarily
`aware that this transfer is taking place, as it is taking place
`in the background, while the user is performing other tasks
`or viewing content other than that which is being transferred.
`Once the rich media has been transferred in its entirety and
`Stored, or cached, in the local memory of the client, the rich
`media content is displayed automatically in a designated
`display area. The user may then be able to manipulate the
`rich media content without affecting the other content or
`tasks that were being displayed prior to the display of the
`rich media content.
`
`32 Claims, 8 Drawing Sheets
`
`Server 103
`
`Memory 110
`RichMedia Files 105
`File OS.A.
`C Fies)
`le OS-C
`
`Network
`10
`
`
`
`Client 102
`
`Memory 104
`Local Cache 07
`
`

`

`US 6,985,934 B1
`Page 2
`
`U.S. PATENT DOCUMENTS
`5,872,781 A 2/1999 Bennett et al.
`5,898.833 A 4/1999 Kidder
`5,903,673 A 5/1999 Wang et al.
`5,905,885 A 5/1999 Richter et al.
`5,913,040 A 6/1999 Rakavy et al.
`5,914,712 A 6/1999 Sartain et al.
`5,917,816 A 6/1999 Jacobsohn
`5,933,811 A 8/1999 Angles et al.
`5,936,960 A
`8/1999 Stewart
`5.937,392 A
`8/1999 Alberts
`5,951,639 A * 9/1999 MacInnis ..................... 725/70
`
`5,956,716 A 9/1999 Kenner et al.
`
`5.987,510 A * 11/1999 Imai et al. .................. 709/219
`5.999,912 A 12/1999 Wodarz et al.
`6,006,197 A 12/1999 dEon et al.
`6,006.241 A 12/1999 Purnaveja et al.
`6,006,265 A 12/1999 Rangan et al.
`6,009,410 A 12/1999 LeMole et al.
`6,014,694 A 1/2000 Aharoni et al.
`6,018,765 A
`1/2000 Durana et al.
`
`2/2000 Hill et al. ................... 707/513
`6,023,714 A
`6,029.200 A 2/2000 Beckerman et al.
`6,035,339 A * 3/2000 Agraharam et al. ........ 709/246
`6,088,732 A * 7/2000 Smith et al. ................ 709/229
`6,314,451 B1
`11/2001 Landsman et al.
`6,317,761 B1 11/2001 Landsman et al.
`6,317,789 B1* 11/2001 Rakavy et al. .............. 709/224
`6,442,529 B1
`8/2002 Krishan et al. ............... 705/14
`6,466.967 B2 10/2002 Landsman et al.
`6,496.857 B1 * 12/2002 Dustin et al. ............... 709/219
`6,516.338 B1
`2/2003 Landsman et al.
`6,594,699 B1* 7/2003 Sahai et all
`
`709/228
`
`2- - -2
`
`-
`
`- - - - - - - - - - - - - - - - -
`
`FOREIGN PATENT DOCUMENTS
`
`WO
`WO
`WO
`WO
`
`WO 97/07656
`WO 98/15091
`WO 99/57657
`WO 99/60504
`
`* cited by examiner
`
`3/1997
`4/1998
`11/1999
`11/1999
`
`

`

`U.S. Patent
`
`Jan. 10, 2006
`
`Sheet 1 of 8
`
`US 6,985,934 B1
`
`Figure 1A
`
`
`
`
`
`
`
`
`
`
`
`
`
`Network
`O
`
`Server 103
`
`Memory 110
`Rich Media Files 105
`File 106-A
`
`File 106-X
`
`
`
`
`
`dient 102
`
`
`
`
`
`Memory 104
`Local Cache 107
`
`

`

`U.S. Patent
`
`Jan. 10, 2006
`
`Sheet 2 of 8
`
`US 6,985,934 B1
`
`Figure 1B
`
`Server 03
`
`
`
`
`
`Memory 110
`Rich Media Files 05
`
`
`
`
`
`Query 108
`
`
`
`
`
`; C File 06-X
`
`N.
`
`Network
`O
`
`
`
`Client ()2
`
`Local Cache ()7
`
`

`

`U.S. Patent
`
`Jan. 10, 2006
`
`Sheet 3 of 8
`
`US 6,985,934 B1
`
`Figure 1C
`
`Sever 03
`
`Netwk
`()
`
`f
`
`Memory 10
`Rich Media Files 05
`File O6-A
`File O6-B
`File O6-C
`
`Response 108b.
`"Protocol (C) and (E)'
`
`
`
`Client 02
`
`Memory 04
`Local Cache 07
`
`

`

`U.S. Patent
`
`Jan. 10, 2006
`
`Sheet 4 of 8
`
`US 6,985,934 B1
`
`Figure 1D
`
`
`
`
`
`
`
`
`
`
`
`Network
`O
`
`Schedule of Rich
`Media Formats 109
`
`Server OS
`
`Memory l0
`Rich Media Filies O5
`File 06-A
`( File 106-B)
`File 106-C
`
`
`
`
`
`Response 108b
`"Protocol (C) and (E)'
`
`
`
`
`
`Clien t O2
`
`
`
`Memory 104
`Local Cache 07
`
`

`

`U.S. Patent
`
`Jan. 10, 2006
`
`Sheet 5 of 8
`
`US 6,985,934 B1
`
`Figure 1E
`
`
`
`
`
`
`
`
`
`
`
`
`
`Network
`O
`
`Schedule of Rich
`Media Formats 109
`
`Server 103
`
`Memory i 10
`? Rich Media Files 05
`File 06-A
`File (6-B
`
`File 106-C s ! CFle (6-X
`
`Response 108b
`“Protocol (C) and (E)”
`
`
`
`Client O2
`
`Memory 104
`Local Cache ()7
`
`File 106-C
`
`Display
`(see Figure 2)
`
`

`

`U.S. Patent
`
`Jan. 10, 2006
`
`Sheet 6 of 8
`
`US 6,985,934 B1
`
`Figure 2
`
`Figure 2A
`Designated Display Area 202
`
`OOOO) Controls 203
`
`Figure 2B
`2.
`
`Designated
`Display Area
`2O2
`
`
`
`
`
`
`
`Content Display Area 201
`
`Content Display Area 201
`(same physical Space)
`
`Physical Display Area 200
`(same physical Space)
`
`-
`
`Physical Display Area 200
`
`-
`
`COIntrols 203
`
`Figure 2C
`
`
`
`
`
`
`
`Designated
`Display Area
`2O2
`
`Content Displa
`
`Physical Display Area 200
`
`OOOO) Controls 203
`
`

`

`U.S. Patent
`
`Jan. 10, 2006
`
`Sheet 7 of 8
`
`US 6,985,934 B1
`
`Figure 3
`
`
`
`(If Determining
`Step Not
`Required)
`
`(If no compatible
`format exists,
`Server Sends
`nothing 305a)
`
`Connection
`between Client
`and Server 301
`
`Query Sent By
`Server 302
`
`Client Responds
`to Query 303
`
`Server Compares Client
`Capabilities to Preferred
`Formats 304
`
`Transparent
`to the user
`
`Server sends Rich
`Media File 305
`
`Entire Rich Media File
`received in Client
`memory 306
`
`Rich Media File
`displayed 307
`
`User may
`manipulate Rich
`Media File 308
`
`|
`|
`|
`|
`|
`|
`
`

`

`U.S. Patent
`
`Jan. 10, 2006
`
`Sheet 8 of 8
`
`US 6,985,934 B1
`
`(
`
`)
`
`Processor 404
`
`Computer System 400
`
`
`
`Communication
`infrastructure
`AOS
`
`(
`
`(
`
`
`
`
`
`)
`
`Main Memory 408
`
`)
`
`Display interface 402
`
`Display 430
`
`Secondary Memory 410
`
`Hard Oisk Drive 42
`
`Removable Storage Drive 414
`OW
`g
`
`Removable Storage
`Unit 418
`
`
`
`
`
`Interface 420
`
`Removable Storage
`Unit 422
`
`
`
`Comunications
`Interface 424
`
`F.G. 4
`
`Communications Path 426
`
`

`

`1
`METHOD AND SYSTEM FOR PROVIDING
`RICH MEDIA CONTENT OVERA
`COMPUTER NETWORK
`
`BACKGROUND OF THE INVENTION
`
`1. Field of the Invention
`The present invention is directed to a method and System
`for providing rich media content over a computer network
`and more particularly to a highly reliable, transparent pro
`ceSS for displaying high-quality online advertising imagery.
`2. Related Art
`Computer networks, including the Internet, are a new and
`rapidly growing means of communication. There are cur
`rently over 300 million network users worldwide, and that
`number is expected to double in less than five years accord
`ing to the Computer Industry Almanac (www.c-i-a.com).
`Because of their numbers, and because they are believed to
`be high-end consumers, users of the Internet and other
`computer networks are an attractive audience for advertising
`messages. According to figures from the Internet Advertis
`ing Bureau (“IAB"; www.iab.net), expenditures for Internet
`advertising are growing even faster than the number of
`network users-at almost 25 percent per quarter-and cur
`rently total over S7 billion per year.
`The current Standard for Internet advertising is the banner
`ad, a cartoon-like color image that occupies a fixed part of
`a web page. Banner ads usually come in one of a Small
`number of Standard sizes, and they Sometimes include crude
`animation created by rapidly and repeatedly Superposing a
`Small number of images in the same Space. Banner ads
`comprise the majority of Internet advertising historically
`over half of total expenditures and around three-quarters of
`that on discrete ads (as opposed to sponsorships) according
`to the IAB.
`The content of a banner ad image is contained in a
`computer file that is interpreted and displayed by a network
`user's web-browser program (e.g., Netscape Navigator,
`Microsoft Internet Explorer). Almost all banner ad files use
`the GIF89a format, which can be interpreted and displayed
`by all major web-browser programs currently on the market.
`Each banner ad's file, plus the file containing the content
`of the host web page itself, must be transmitted to, and
`Stored on, a network user's computer before the complete
`web page (ads and content) can be displayed. There may be
`many-Sometimes dozens-of banner ads on a page, and
`advertisers often demand that the page be configured to
`display the ads first. To keep network users from waiting too
`long to See the content of their pages, web page owners
`frequently impose limits on the size of the banner ad files
`they will accept. These limits, in turn, Sharply constrain the
`appearance of banner ads, e.g., by reducing the number of
`images per ad or the number of items per image, or by
`restricting the variety of colors or level of detail in an item
`or image.
`Such limitations have combined to reduce the effective
`neSS of banner ads in two ways. First, they are-and because
`of file size limitations must remain-crude. Because banner
`ads are typically simple cartoons in an environment of
`increasingly rich and complex media, the viewing audience
`is becoming leSS responsive to the ads. The average "click
`through' rate, the rate at which Viewers respond to a banner
`ad by “clicking” on it and being transferred to the web site
`advertised by the banner, is falling rapidly-by almost an
`order of magnitude during the past five years, according to
`contemporary estimates in Advertising Age magazine. Sec
`ondly, despite limitations on their file sizes, banner ads often
`
`15
`
`25
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`US 6,985,934 B1
`
`2
`delay viewing of web page content to the point that users
`routinely redirect their browserS away in frustration; the
`very presence of the ads lowers their own viewership.
`Dwell-time, a measure of the time an average network user
`Spends looking at a Single page, is also declining.
`In brief, banner ads, though they dominate advertising on
`the Internet and are So much the Standard that they are
`directly interpretable by every major web-browser program,
`are an obsolete and increasingly Self-defeating technology.
`Advertisers, aware of the limitations of banner ads, have
`tried two approaches to improve upon them. The first
`approach is to replace the cartoon-like banner ad images
`with Video ads, i.e., online ads that use moving, photo
`graphic-quality images rather than Simple Single images or
`Series of a few simple Single imageS. The Second approach,
`referred to generally as interstitial ads, Sometimes called
`pop-up ads, avoids. Some of the technical problems of banner
`ads and Video ads by effectively Separating the interstitial
`ads from their host web pages. Both approaches, though, like
`the banner ad approach, have run into technical and con
`Sumer-response barriers.
`Video ads, unlike GIF89a-format images, cannot be dis
`played directly by web-browser programs. Instead, they are
`encoded in one of Several specialized formats (e.g., MPEG,
`QTF, AVI) and are displayed by separate-and similarly
`Specialized-Video replay programs. Such video replay pro
`grams are separate from the web-browser programs, but they
`are compatible with the browserS and Sometimes are referred
`to as plug-ins to the browsers. Some replay programs are
`distributed with computer operating Systems, while others
`are available Separately, either for free or at a cost. Some
`replay programs can interpret more than one format,
`although none can interpret even a large minority of the
`existing variety of formats, and file formats are different
`enough that any multi-format program is essentially a pack
`age of Single-format programs. Because of the multiplicity
`of formats and distribution methods, and because many
`formats are in fairly wide use, it is unlikely that any Single
`Standard will emerge in the near future. In other words,
`unlike GIF image technology, the technology of computer
`Video replay is non-Standardized and is functionally com
`plicated, and it is likely to remain So.
`To view a Video, a user's computer must receive at least
`part of the file and then activate and run a compatible replay
`program. This process frequently includes one or more
`“dialogues' between the computer and the user. For
`example, if the file is to be Stored and then replayed, the user
`must specify a storage name (or approve the computer's
`choice) and then activate the replay. If the computer cannot
`determine which replay program to use, the user must
`Specify it. And if there is no compatible replay program on
`the computer, the user must either cancel the replay or spend
`time (and possibly money) identifying, locating, and obtain
`ing one. The complexity and time requirements of this
`process can be daunting even if the user actively Seeks to
`view the video; for advertising, which needs to be entirely
`passive and nearly instantaneous, these are major barriers.
`Another barrier to the use of video ads is imposed by the
`sheer size of most Video files. Video images, like any other
`computer data, are Stored and transmitted as computer files.
`Because of the complexity of the images (color, resolution,
`etc.) and the number of images in a file (usually thousands),
`Video files typically are very large. For example, a word
`processing document file may be on the order of a few dozen
`kilobytes (KB), and a typical web page file may be around
`a hundred KB, but even a thirty-second video will require a
`file size of thousands of KB (i.e., several megabytes, or
`
`

`

`3
`MB). Using a standard telephone modem connection, whose
`transmission rate is limited by telephone technology and
`federal regulation, not by computer modem technology, a
`file of even a few megabytes can require many minutes to
`receive and Store. For example, with a 56K modem and an
`effective transmission rate of over 50K, transmission
`requires at least three minutes per megabyte. Faster connec
`tions (e.g., via DSL or institutional intra-net) reduce this
`time Substantially, but not So much that the file transmission
`does not cause a noticeable interruption. Further, those types
`of connections are available to only a portion of the user
`population. AS noted above, computer users are becoming
`increasingly impatient with any delay, especially for the Sake
`of advertising, and in any case most advertisers are unwill
`ing to limit their messages to only a portion of the popula
`tion.
`To address the problem of file size, Specialized protocols
`were developed that allow near-real-time playback. Some
`times called Streaming, these protocols begin playback when
`only a portion of the file has been transmitted and Stored on
`the user's computer (i.e., buffered). Later portions of the file
`are transmitted as earlier ones play back, and the parameters
`of the process are calibrated So that, if transmission is not
`interrupted, playback is continuous. The practical flaw in
`this approach is that transmission, particularly of large files,
`frequently is interrupted. Net congestion, transmission
`errorS requiring retransmission, competing demands on the
`transmitting computer, and other causes, can interrupt the
`transmission flow long enough that the buffer is completely
`played out, and then playback Stops until enough new data
`have been received. The effect on the user is that Streaming
`video (or audio) either is occasionally interrupted by long
`pauses or has a jerky quality caused by frequent micro
`pauses (the former with a large buffer size and the latter with
`a Small one). These types of interruptions are unacceptable
`to advertisers, whose imagery requires SeamleSS replay.
`Further, Streaming video is Subject to the same requirements
`as non-Streaming video for identifying, obtaining, and/or
`activating a compatible replay program.
`U.S. Pat. No. 6,029.200 to Beckerman et al. discloses a
`process that uses Streaming Video and provides a more
`automated approach to Selecting a replay program. The
`“client” computer (e.g., the network user's computer) is
`offered a list of multiple versions of a video file, each in a
`different format, in a predetermined order, until a compatible
`format-if any is found. This makes it more likely that the
`Video eventually can be viewed by the user, but it requires
`the user's computer to know how to interpret and choose
`among the list of “offers,” which presumably requires Spe
`cialized Software. It is not clear how noticeable the proceSS
`would be to the user (e.g., delay, “dialogues'), and because
`it applies only to Streaming video, the process does not
`address the problem of interruptions in playback. It thus can
`be considered another format, albeit a Somewhat generalized
`one, but with questionable application to advertising.
`Processes developed more recently by bluestreak.com,
`Inc. (www.bluestreak.com) and AudioBase, Inc. (www.au
`diobase.com) also use streaming, and they circumvent the
`replay compatibility issue by transmitting their own replay
`programs along with the data files. These are examples of the
`usage of "push” technology, as used, e.g., in U.S. Pat. No.
`5,740,549, issued Apr. 14, 1998 to Reilly et al. These
`processes are reasonably rapid-although Still noticeable to
`the user-because neither handles full video; bluestreak offers
`audio, GIF-like animation, and other cartoon-like Special
`effects, and AudioBase handles strictly audio. Both also are
`Subject to the problems of Streaming, Such as “stuttering”
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`US 6,985,934 B1
`
`5
`
`15
`
`25
`
`4
`and interruptions in playback. They thus are Suitable for
`certain narrow, Specialized forms of advertising, but their
`transmission delays are Still non-negligible, and like other
`uses of Streaming, their unreliable replay renders them
`problematic for advertising.
`In Summary, attempts to date to put Video advertising onto
`Internet web pages have largely failed because of two
`fundamental technical
`characteristics
`of computer
`Video-lack of Standardization and very large file Size-and
`their implications. Computer users are generally unwilling
`either to wait for large files to be transmitted or to take active
`Steps to ensure a Smooth replay, especially for the Sake of
`Viewing an advertisement. Advertisers are unwilling to
`spend money and effort on technologies that cannot reliably
`deliver uninterrupted imagery to a wide audience. What
`would Satisfy both users and advertisers, but is lacking in the
`prior art, is a means for reliably delivering Video ads without
`any interruption of the user's viewing experience. AS a
`consequence, Video advertising has been and remains a
`Small and Static fraction of all Internet advertising, expen
`ditures on video have consistently been just a few percent of
`the total.
`Interstitial advertisements-Sometimes called pop-up
`ads-bypass Some of the technical problems of on-page
`banner ads and Video ads by effectively Separating the online
`ads from their host web pages. The content of an interstitial
`ad is transmitted Separately from those of its host web page.
`Transmission begins immediately after the host web page
`has been fully transmitted and while it is being displayed
`(i.e., during the “interstices between other web page trans
`missions), and it may continue once the ad itself has begun
`displaying. The ad is displayed in a new “window' or other
`dedicated display area, either immediately after the host
`page is fully displayed (thus “popping up” in front of the
`host page) or when the user Signals that he/she has finished
`reading the host page by closing it or activating a link to a
`new page. Interstitial ads can include GIF images, video,
`audio, or any other web page elements, they are essentially
`Specialized web pages comprised entirely of advertising.
`Because they are transmitted Separately, they do not delay
`the display of the host web page, and because the user
`presumably is occupied for Some time reading the host web
`page, the ads can take much longer to transmit than on-page
`ads without Seriously annoying the user.
`Interstitial transmission of advertising is taught in U.S.
`Pat. No. 5,305,195, issued Apr. 19, 1994 to Murphy, for use
`on Specialized computer terminals Such as bank ATMS and
`School registration Stations. More recent applications
`include U.S. Pat. No. 5,913,040, issued Jun. 15, 1999 to
`Rakavy et al.; U.S. Pat. No. 5,737,619, issued Apr. 7, 1998
`and U.S. Pat. No. 5,572,643, issued Nov. 5, 1996, to Judson;
`and U.S. Pat. No. 5,604,542, issued Feb. 18, 1997 to
`Dedrick.
`The principal problem with interstitial ads is that, as dwell
`time Statistics show, users' patience Still limits the time
`available for transmission. While a user is reading the host
`page, there typically is Sufficient download time for banner
`ads, other GIF images, other Static images, Simple anima
`tions, a streaming video buffer, and usually audio and other
`animated elements and associated programs Such as those
`produced by the bluestreak and AudioBase processes. How
`ever, there is not Sufficient time to transmit more than one
`buffer worth of a video file, and there is no opportunity to
`create a “dialogue' with the user until the interstitial ad is
`displayed. Consequently, both the number and the type of
`elements in an interstitial ad are constrained. Additionally,
`
`

`

`US 6,985,934 B1
`
`S
`interstital Video ads are also Subject to the same problems of
`non-Standardization and display reliability as with on-page
`Video ads.
`A process developed by Unicast Communications Corp.,
`disclosed in International Publication No. WO 99/60504,
`published Nov. 25, 1999, partially addresses these problems
`by installing a program on the user's computer that ensures
`that transmission of ads (and accompanying playback pro
`grams if any) is as “polite” as possible. The concept of
`"polite' transmission-i.e., file transmission minimally
`noticeable to the user-avoids. Some of the problems asso
`ciated with Streaming by fully storing (or caching) ads on the
`user's computer before displaying them. The Unicast pro
`gram also checks that any necessary playback programs are
`available on the user's computer before the ad is displayed.
`However, Such a process is not practically applicable to
`Video ads, because large files take a long time to transmit no
`matter how politely, and Video replay programs are even
`larger than Video ads and are Seldom available for transmis
`Sion along with them. It is also as yet unclear whether Such
`a powerful program will be fully compatible with most
`network users operating Systems and browser programs, or
`whether privacy concerns will limit its functionality or
`popularity.
`Overall, while interstitial ads solve some of the problems
`of computer network advertising, they as yet have shown
`only partial Success at dealing with the non-Standardization
`and file Size issueS associated with Video ads, or with file
`sizes in general. Attempts to create a “Smart’ Solution have
`only added new problems. At least partially as a result,
`interstitials historically have accounted for less than a tenth
`of Internet advertising expenditures, and that share has
`shrunk by almost half in the last year according to the IAB.
`In Summary, what is needed but is missing in the prior art,
`is a highly reliable, entirely transparent proceSS for display
`ing high-quality rich media content over a computer net
`work.
`
`SUMMARY OF THE INVENTION
`
`The present invention is directed to a method, System and
`computer program product for providing rich media content
`over a computer network. In accordance with the present
`invention, a Server on a computer network polls the Soft
`ware, hardware, or electronic appliance of an end user on the
`network, for the availability of software and/or hardware
`necessary for the local display of rich media content. This
`polling is transparent to the end user and requires no action
`on the part of the end user. Based on the client's response,
`the Server Sends an appropriately formatted version of the
`rich media file to the client. The user is not necessarily aware
`that this transfer is taking place, as it is taking place in the
`background, while the user is performing other tasks or
`Viewing other content than that which is being transferred.
`Once the rich media has been transferred in its entirety and
`Stored, or cached, in the local memory of the client, the rich
`media content is displayed automatically, either immediately
`or according to a predefined Schedule or display cue, in a
`designated display area. The user may then be able to
`manipulate the rich media content without affecting the
`other content or tasks that were being displayed prior to the
`display of the rich media content.
`The client may be any of a number of known electronic
`devices connected either physically or wirelessly to a server
`on the computer network. Such devices may include, but are
`not limited to, a desktop computer, a laptop computer, a
`handheld device, a telephone, a Set top box, or an Internet
`
`6
`appliance. In the preferred embodiment, the rich media
`comprises a short, highly compressed digital Video file. For
`example, Such rich media may be a 5-15 Second long video
`advertisement.
`
`BRIEF DESCRIPTION OF THE FIGURES
`
`FIGS. 1A-1E show a computer network according to the
`present invention at various Steps during a method for
`providing rich media content acroSS a computer network
`according to the present invention.
`FIGS. 2A-2C are various embodiments of a client display
`area according to the present invention.
`FIG. 3 is a proceSS diagram of the method for providing
`rich media content acroSS a computer network according to
`the present invention.
`FIG. 4 is a block diagram of an example computer System
`useful for implementing the present invention.
`
`DETAILED DESCRIPTION OF THE
`PREFERRED EMBODIMENTS
`
`A preferred embodiment of the present invention is now
`described with reference to the figures, where like reference
`numbers indicate identical or functionally Similar elements.
`Also in the figures, the left most digit of each reference
`number corresponds to the figure in which the reference
`number is first used. While Specific configurations and
`arrangements are discussed, it should be understood that this
`is done for illustrative purposes only. A perSon skilled in the
`relevant art will recognize that other configurations and
`arrangements can be used without departing from the spirit
`and Scope of the invention. It will be apparent to a perSon
`skilled in the relevant art that this invention can also be
`employed in a variety of other devices and applications.
`FIG. 1A shows a computer network 101 according to the
`present invention, consisting of a System of electronic
`devices connected either physically or wirelessly, wherein
`digital information is transmitted from one device to
`another. Such devices may include, but are not limited to, a
`desktop computer, a laptop computer, a handheld device, a
`telephone, a Set top box, or an Internet appliance. FIG. 1A
`shows a client 102, defined as a computer program resident
`on a computer System, an item of hardware, or an electronic
`appliance that sends and receives digital information via
`computer network 101. Also shown is a server 103, defined
`as a computer program resident on a computer System, an
`item of hardware, or an electronic appliance that Sends and
`receives digital information via computer network 101. The
`role of server 103 shown in FIG. 1A may in some cases be
`played by more than one actual Server, as would be apparent
`to those skilled in the relevant art.
`Server 103 also includes a memory 110 which stores
`digital files, including but not limited to Software and data
`files. Specifically, memory 110 may contain one or more rich
`media files 105, defined as any electronic media content that
`includes moving images, Video with or without audio, a
`Sequence of images captured from frames of film, frames of
`Video, or animated shapes. “Rich’, in general, denotes
`electronic media information that includes more than only
`text or audio. Rich media files 105 are stored in the form of
`digital computer files. In the preferred embodiment, rich
`media file 105 is a 5-10 second video advertisement in the
`form of a highly compressed electronic file. Rich media files
`105 can be stored, transmitted or displayed using a variety
`of proprietary and nonproprietary electronic file formats,
`such as QuickTime, Windows Media Player, GIF89a, Flash,
`
`15
`
`25
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`

`

`7
`AIFF, WAV, RealAudio, RealVideo, or any of a number of
`file formats now emerging for wireleSS devices, Such as
`HDML, WML, BMP, or formats associated with WCA, and
`other formats known to those skilled in the relevant art
`appropriate to various Software, hardware, and electronic
`appliance display Systems. The particular file format does
`not substantially affect the content of rich media file 105.
`Rich media files 105 may be previously created and stored
`in memory 110, or may be created “on-the-fly” in response
`to the requirements of client 102. As discussed below, the
`same rich media file 105 is stored in a number of different
`file formats (106-A, 106-B . . . 106-X) in memory 110 to
`facilitate the transfer and display of rich media file 105
`acroSS computer network 101 according to the present
`invention.
`Client 102 also includes a memory 104, that is entirely
`contained within, or is entirely a part of client 102, which
`Stores digital files, including, but not limited to, Software and
`data files. A subset of client memory 104, local cache 107,
`is defined as that portion of client memory 104 that is used
`for temporary Storage of data files received over computer
`network 101.
`The process according to the present invention is initiated
`at a step 301, as shown in FIGS. 1A and 3, by client 102
`becoming connected to Server 103, for example a desktop
`computer user being connected to a web site using a web
`browser.
`Next, at a step 302, as shown in FIGS. 1B and 3, server
`103 sends a query 108 to client 102. Query 108 is a
`communication wherein server 103 requests data from client
`102 regarding the presence or absence of Specific Software
`and/or hardware that are required to display rich media file
`105, that has been prepared in specific file formats 106-A,
`106-B .
`. . 106-X. In one embodiment, query 108 is
`performed by progressing, via one or more connections with
`client 102, through a set of preferred rich media content
`playback applications to assess the local playback capabili
`ties of client 102. In the preferred embodiment, this proce
`dure is transparent to the user, meaning that the user is not
`required to take action to initiate this step, and the proceSS
`is not noticeable to the user.
`At a step 303, as shown in FIGS. 1C and 3, client