Traffic Authentication of Audio and Video Programming Provided over a Computer Network
Field of the Invention
The present invention relates to measuring viewer traffic of audio or video programming delivered over a computer network and, in particular, to providing secure measurement of such viewer traffic.
Background and Summary of the Invention
In many countries, conventional broadcast radio and television programming are supported by advertising in the form of commercials that are interspersed throughout the programming. The costs for advertising during different radio and television shows depend upon sampled measurements of the numbers of people who listen to or watch those shows. (For purposes of simplicity, listeners and viewers are both referred to as viewers herein.) The most famous sampled measurements for programming are the Nielson ratings provided by Nielsen Media Research, Inc. and the Arbitron ratings provided by the Arbitron Company.
Transmission of audio and video programming over computer networks, such as the Internet, has become widely available and is becoming increasingly popular. Much of this online programming is being supported by advertising similar to the manner that advertising supports conventional broadcast programming. As with conventional broadcast programming, advertising costs are based upon measuring the numbers of users. As with conventional broadcast programming, measurement of numbers of viewers of online programming is typically conducted by sampled measurements and surveys.
Such sampled measurement of the viewers of online programming suffers from the disadvantage that many online broadcast programming sites might have insufficient traffic to be accurately measured by such sampling.
Moreover, such sampling fails to utilize computer network transmission information that is commonly available in the form of network server log files.
A conventional log file typically includes a simple text listing of each file (e.g., media file) that is transmitted by a media server to a client computer. A conventional log file typically will include information such as which media file was transmitted (or requested), a network address (e.g., TCP/IP) identification of the client computer that requested (or to which was transmitted) the media file, and the network browsing software and operating system of the client computer. Typically, a conventional server log file is readily available to the operator of a server computer so that access to and usage of the server can be monitored. Numerous software utilities are available to provide summaries of usage information included in conventional server log files. Such usage information can be used by the operator of a server computer to discern usage patterns and correlate them with various business or marketing factors. With advertiser support of a broadcast network site, both the advertisers and the operator of a server have direct economic interests in a conventional log file because advertising rates are typically tied directly to the sizes and types of viewer audiences (i.e., viewer traffic). However, the ready accessibility to and potential for improper manipulation of conventional log files by the operators of servers can render them an unreliable indication of viewer traffic from an advertiser's perspective. As a consequence, advertisers resort to sampled audience or traffic measurements by third parties to obtain objective measurements. In accordance with the present invention, a viewer traffic authentication method provides authenticated information about audio or video program traffic over a computer network from a media server. This method overcomes the limitations of conventional sampled measurement of programming traffic and the limitations of relying on conventional server log files.
In one implementation, the method includes generating on the media server a secure viewer traffic log of media traffic information relating
media files transmitted or requested from the media server. The secure viewer traffic log is secure (e.g., encrypted or digitally signed) with regard to the operator of the media server. The secure viewer traffic log is transmitted to a viewer traffic authentication server that is operated by a party other than the operator of the media server. A report is then generated from the secure viewer traffic log received at the viewer traffic authentication server summarizing viewer traffic at the media server.
For example, the secure viewer traffic log may include traffic records that list individual files transmitted to client computers. The method may further include identifying in the secure viewer traffic log a media viewing session in which plural media files are transmitted to a selected client computer. Moreover, multiple media files may be associated together in a serializing media file in a serializing media file format, such as a streaming media file format like those promulgated by RealNetworks, Inc. of Seattle, Washington, or a serializing meta-file format like the Synchronized Multimedia Integration Language (SMIL). Identification of a media viewing session for such media files may include parsing the serializing media file to identify the associated media files of a media viewing session.
Additional objects and advantages of the present invention will be apparent from the detailed description of the preferred embodiment thereof, which proceeds with reference to the accompanying drawings. Brief Description of the Drawings Fig. 1 is a block diagram illustrating a computer network architecture as an operating environment for the present invention. Fig. 2 is a flow diagram of a secure viewer traffic authentication method of the present invention.
Fig. 3 is a diagrammatic illustration of a media viewing session. Fig. 4 is a flow diagram of another secure viewer traffic authentication method of the present invention. Detailed Description of Preferred Embodiments
Fig. 1 is a block diagram illustrating a computer network architecture as an operating environment for the present invention. Multiple
client computers or clients 10 are in communication with a server computer or server 12 via a network 16, such as a LAN, WAN, an intranet, or the Internet. Clients 10 and server 12 have, for example, conventional computer configurations that may include a high speed processing unit (CPU) in conjunction with a memory system (with volatile and/or non-volatile memory), an input device, and an output device, as is known in the art. Server 12 may be implemented as one or more server computers, which in the latter case may communicate with each other over one or more local or remote networks. Each of clients 10 is a personal computer running media player software 18 capable of playing or rendering audio or video files (referred to herein as media files 20). For example, media player software 18 may be Real Player from RealNetworks, Inc. of Seattle, Washington or Windows Media Player from Microsoft Corporation of Redmond, Washington. It will be appreciated that media player software 18 may be integral with or a plug-in added to commercially available network browser software, such as Netscape Navigator from Netscape Corporation or Internet Explorer from Microsoft Corporation, or may be an entirely separate application.
Server 16 is a computer with media broadcast server software 22 that provides serialized audio, video, or other media files to multiple client computers 10. For example, media files 20 are in a streaming file format or in a serialized meta-file format in which an audio or video presentation may include multiple media file segments or component files. Examples of streaming file formats include RealMedia file formats promulgated by RealNetworks, Inc. An example of a serialized meta-file format is the SMIL (Synchronized Multimedia Integration Language) file format, which is sometimes referred to as a multimedia layout and integration language.
Typically, a conventional log file 24 that is generated by media broadcast server software 22 as it transmits media files 20 to clients 10. Conventional log file 24 typically includes a simple text listing or record of each media file 20 that is transmitted by broadcast server software 22. Typically, conventional log file 24 will have a format such as:
192.168.1.111 - - [21/Jul/2000:16:00:38 -0700] "GET g2video.rm RTSP/1.0" 200 261409 [WinNT_4.0_6.0.6.94_play32_RN6C_en- US_686] [3f13ec98-2af0-1 1d4-9508-00b0d02359b1] [Statl : 91 0 0 0 0 6_Kbps_Music][Stat2: 6000 15076 0 0 0 0 0 0 0 0 47 6_Kbps_Music] 1273163 59 14 0 0 1 and will include information such as which media file 20, or file component, was transmitted (or requested), a network address (e.g., TCP/IP) identification of the client 10 that requested (or to which was transmitted) media file 20, or its component, the network browsing software and operating system of client 10, etc.
Typically, conventional server log file 24 is readily available to the operator of server 12 so that access to and usage of server 12 can be monitored. Numerous software utilities are available to provide summaries of usage information included in conventional server logs 24. Such usage information can be used by the operator of a server computer to discern usage patterns and correlate them with various system diagnostics or business or marketing factors, as is known in the art.
With conventional computer network sites (sometimes called Web sites, in reference to the World Wide Web of the Internet), such usage information is often of primary economic interest to the operator of the server. In some instances of server 16 operating broadcast server software 22, the broadcasting of media files 20 is supported by advertisers who pay the operator of server 16 (i.e., the broadcaster) to transmit information such as advertisements with other media files 20 that are directed to viewers. (For reference purposes, a person who listens to audio media or who views video media is referred to herein collectively and interchangeably as a viewer.) Advertiser payments to the operator of server 16 commonly relate to the numbers of viewers to whom media files 20 are broadcast from server 16.
In these instances, both the advertisers and the operator of server 16 have direct economic interests in conventional log file 24 because advertising rates are typically tied directly to the sizes and types of viewer audiences (i.e., viewer traffic). However, the ready accessibility to and
potential for improper manipulation of conventional log files 24 by the operator of server 16 can render log files 24 an unreliable indication of viewer traffic.
In accordance with the present invention, media server 16 includes viewer traffic authentication software 30 that operates in conjunction with media broadcast server software 22. Viewer traffic authentication software 30 generates a secure viewer traffic log 32 that is distinct from conventional log 24 and is transmitted over network 16 to a viewer traffic authentication server 34, which typically would be operated by a party other than the operator of server 16. Viewer traffic authentication server 34 obtains viewer traffic information from secure viewer traffic logs 32 without risk of improper manipulation by the operator of server 16. The viewer traffic information from secure viewer traffic logs 32 may then be made available to advertisers and the operator of server 16 in a secure, impartial manner. Typically, traffic authentication server 34 would receive secure viewer traffic logs 32 from multiple broadcast servers 16 (only one shown).
Fig. 2 is a flow diagram of a secure viewer traffic authentication method 50 that can be performed by viewer traffic authentication software 30 and traffic authentication server 34, for example. It will be appreciated that traffic authentication method 50 represents one implementation of the operation of viewer traffic authentication software 30 and traffic authentication server 34 and that the operation of them in other implementations may differ from traffic authentication method 50.
Process block 52 indicates that a secure viewer traffic log 32 is formed on broadcast server 16 in coordination with broadcasting of media files 20 to clients 10. Secure viewer traffic log 32 is secure in that it is encrypted (e.g., public-private key encryption) or otherwise secured (e.g., digitally signed) to prevent log 32 from being modified or viewed by the operator of server 16, or to indicate if log 32 was modified by the operator of server 16. Secure viewer traffic log 32 includes in one instance a media viewing record of media viewing information for each media file transmitted to or requested from a client 10. The media viewing information of each record includes, for example, an identifier for the media file 20, or component, that was transmitted (or
requested), a network address (e.g., TCP/IP) identification of the client 10 that requested (or to which was transmitted) media file 20, or its component, the network browsing software and operating system of client 10, etc.
In one implementation, media player software 18 selectively provides to server 12 client identification information in addition to conventional network address (e.g., TCP/IP) information. For example, clients 10 with media player software 18 may have globally unique identifiers (GUIDs) assigned to them. As is known in the art, GUIDs are capable of uniquely distinguishing every client computer 10. Some implementations of media player software 18 are capable of providing to server 16 the GUIDs of clients 10 from which media files 20 are requested. In such an implementation, secure viewer traffic log 32 includes available GUIDs of client computers 10 from which media files are requested.
Process block 54 indicates that media viewing events or sessions are identified from one or more media viewing records in secure viewer traffic log 32. Media viewing sessions represent a time period during which one or more media files 20, or their components, are viewed in succession on a client 10. In one implementation, a media viewing session is determined as the one or more related media files 20, or their components, that are transmitted to (or requested from) a client computer 10 with less than a predetermined threshold of time separation between transmission (or requests) of successive media files 20, or their components.
Fig. 3 is a diagrammatic illustration of a media viewing session 60 based upon a SMIL serialized meta-file format, for example, but is similarly applicable to other serialized media file formats. Media viewing session 60 includes transmission of media files 64A-64D over respective time periods 66A-66D.
In this exemplary illustration, an initial SMIL file 64A provides serialized access to media content requested by or transmitted to a client 10. As is known in the art, a SMIL file can provide access to one or more associated media files and other files. An initial media viewing record (not
shown) indicates a transmission or accessing of the SMIL file 64A over a time period 66A.
As established by SMIL file 64A, text and video files 64B and 64C are subsequently transmitted to client 10 over time periods 66B and 66C, respectively. For example, text and video files 64B and 64C are in RealText and RealVideo file formats, as promulgated by RealNetworks, Inc., or could be in other formats, whether standardized or proprietary. In this example, time periods 66B and 66C begin at about the same time, following time period 66A by a pause 68A, but have different durations. An audio file 64D (e.g., RealAudio file format) is transmitted to client 10 over a time period 66D following a pause 68B after time period 66C.
In another implementation, media viewing session 60 may be identified by viewer traffic authentication software 30 first parsing SMIL file 64A to establish a record list of files (e.g., 64B-64D) associated with initial file 64A. Media viewing session 60 may then be identified as the files in the record list associated with initial file 64A that are transmitted to a client 10 with pauses 68 of less than a predetermined time threshold. Such a media viewing session 60 represents the media viewed by a single viewer during a single media viewing session. In contrast, conventional log file 24 typically would not relate the transmissions of such serialized files 64 to a single viewing session, and so could misrepresent (i.e., overstate) the number of viewers seeing the media content.
In yet another implementation, the one or more files that correspond to media viewing session 60 may be pre-defined by the operator of server 12 and identified to viewer traffic authentication software 30 before being transmitted to viewers. For example, media viewing session 60 may be defined with reference to a SMIL file that is active during an entire playback or with reference to multiple files.
Referring to Fig. 2, process block 70 indicates that secure viewer traffic log 32 is modified to identify or distinguish media viewing sessions 60 that include multiple serialized media files.
Process block 74 indicates that secure viewer traffic log 32 is transmitted over network 16 to viewer traffic authentication server 34. Typically, secure viewer traffic log 32 may be transmitted to viewer traffic authentication server 34 periodically, such as daily or more frequently (e.g., hourly). In the illustrated implementation, secure viewer traffic log 32 is transmitted to viewer traffic authentication server 34 with media viewing sessions identified. In another implementations, secure viewer traffic log 32 could be transmitted to viewer traffic authentication server 34 without media viewing sessions being identified. Process block 76 indicates that clients 10 listed in secure viewer traffic log 32 are compared against a registered viewer database 78 stored on or in association with (e.g., on) viewer traffic authentication server 34. A registered viewer is a user who has previously provided personal information, including demographic information, and been assigned a unique registered viewer identifier. For example, the operator of a viewer traffic authentication service according to the present invention could obtain demographic information from users who elect to provide such information, in association with media content network sites that are served by the viewer traffic authentication service, or otherwise. In one implementation, registered viewer database 78 includes for each registered user a GUID that is associated with the client 10 from which the viewer registered. Comparison of the clients 10 listed in secure viewer traffic log 32 against the registered viewer database may be performed by comparison of the GUIDs included in secure viewer traffic log 32 against the GUIDs in the registered viewer database. In this implementation, the clients 10 listed in secure viewer traffic log 32 would typically include registered viewers and unregistered viewers with clients 10 that are identified by GUIDs. In addition, the clients 10 listed in secure viewer traffic log 32 could also include unregistered users with clients 10 that are not identified by GUIDs, where media player software 18 allows viewers to selectively block GUID assignments for their computers.
Process block 80 indicates that demographic information associated with registered viewers is correlated with the GUIDs of clients 10 included in secure viewer traffic log 32. Correlating the viewers listed in secure viewer traffic log 32 to demographic information about them can further increase the efficacy and value of the viewer traffic information and, hence, the value of advertising transmitted with the media content.
Process block 82 indicates that a report 84 is generated summarizing the viewer traffic information, and any associated demographic information, relating to operation of a media server 16. Process block 86 indicates that report 84 is provided or made available to subscribers to the viewer traffic authentication service, including the operator of server 16 and advertisers, or their representatives.
Fig. 4 is a flow diagram of a secure viewer traffic authentication method 100 that can be performed by viewer traffic authentication software 30 and traffic authentication server 34, for example. It will be appreciated that traffic authentication method 100 represents another implementation of the operation of viewer traffic authentication software 30 and traffic authentication server 34. Traffic authentication method 100 is generally analogous to traffic authentication method 50, except that the former transmits viewer traffic data to traffic authentication server 34 as the data is generated, rather than compiling a batch of such data on server 12 in the form of secure viewer traffic log 32.
Process block 102 indicates that viewer traffic data (not shown) are transmitted to traffic authentication server 34 substantially in coordination with broadcasting of media files 20 to clients 10. The viewer traffic data may be transmitted in substantially the format generated by broadcast server software 22 or may first be converted to a secure format, as described above. For example, each transmission of the viewer traffic data includes a media viewing record of media viewing information for a viewing session of, or a media file transmitted to or requested from, a client 10.
The media viewing information of each record includes, for example, an identifier for the media file 20, or component, that was transmitted
(or requested), a network address (e.g., TCP/IP) identification of the client 10 that requested (or to which was transmitted) media file 20, or its component, the network browsing software and operating system of client 10, etc. Media viewing sessions represent a time period during which one or more media files 20, or their components, are viewed in succession on a client 10.
Process block 104 indicates that the viewer traffic data are processed for report generation. For example, the viewer traffic data may be processed in the manner described above with reference to process blocks 76, 80, 82, and 86 of method δO.Having described and illustrated the principles of our invention with reference to an illustrated embodiment, it will be recognized that the illustrated embodiment can be modified in arrangement and detail without departing from such principles. It should be understood that the programs, processes, or methods described herein are not related or limited to any particular type of computer apparatus, unless indicated otherwise. Various types of general purpose or specialized computer apparatus may be used with or perform operations in accordance with the teachings described herein. Elements of the illustrated embodiment shown in software may be implemented in hardware and vice versa.
In view of the many possible embodiments to which the principles of our invention may be applied, it should be recognized that the detailed embodiments are illustrative only and should not be taken as limiting the scope of our invention. Rather, we claim as our invention all such embodiments as may come within the scope and spirit of the following claims and equivalents thereto.