METHOD AND APPARATUS FOR PROVIDING MEDIA HIGHLIGHTS
Field of the Invention
The invention generally relates to providing highlights for real time events, such as sporting events, and, more particularly, to acquiring statistics for real time events and using such statistics for identification of highlights.
Background
Media services typically report on newsworthy or noteworthy events that may be of interest to a broad spectrum of society. Traditional services include reporting on the current state of national and local politics, weather, sporting events, human interest stories, acts of crime, etc.
Traditional media services were print based, and therefore suffered from delays incident to having to print and distribute a printed report of an event to consumers, such as by way of a daily newspaper or a weekly news magazine. The advent of wireless media services, such as radio and televised media services, allowed more immediate access to events. For example, scheduled news discussions, and "news flashes" provided more immediate access to events that printed media would not be able to distribute for some time.
One typical limitation to such wireless services, however, is limited time slots in which to deliver their content. To compensate, reporting services typically condensed an event into a few highlights capturing activities the reporting service believed to summarize moments of interest within the event. Such highlighting, however, leads to another limitation: consumers are not able to control distribution of highlights. As a consequence, the reporting service must provide highlights that are generally applicable to a broad consumer base, which potentially requires a consumer to view highlights of no interest to the consumer.
The recent proliferation of Internet and intranet network connections partially overcomes this problem. Consumers may now engage in a networked client-server
relationship to allow consumers to randomly access desired information without waiting for distribution by a media service. For example, to do so, databases can be used to store data, such as news stories, highlights, etc. Consumers can then use a computer, handheld device, etc., to access the database and retrieve desired highlights. Thus, a basketball game may be recorded, and highlights of the game prepared and stored in a database. Consumers may then search the database and retrieve only those highlights of interest to the consumer.
Unfortunately, one limitation to such accessing of stored highlights is that the event in question needs to be recorded, and the recording then subsequently partitioned into the highlights that are stored in the database. Highlights are not available to a consumer client device contemporaneously with performance of the event.
Brief Description Of The Drawings
The features and advantages of the present invention will become apparent from the following detailed description of the present invention in which:
FIG. 1 illustrates one embodiment for acquiring and distributing an event's secondary data.
FIG. 2 illustrates one embodiment for acquiring an event's primary data and partitioning it with respect to FIG. 1 secondary data.
FIG. 3 illustrates distribution of new partitions through a distribution service.
FIG. 4 illustrates providing a highlight to a requesting client.
FIG. 5 illustrates a suitable computing environment in which certain aspects of the invention may be implemented.
Detailed Description
The illustrated embodiments of the invention show exemplary systems and methods for obtaining event highlights contemporaneously with performance of an event. As in this description and claims that follow, the phrase "primary data" refers to a representation or encoding (e.g., analog or digital recording) of an event, and the phrase "secondary data" refers to data (e.g., statistics or other data) associated with the event. As will be discussed below, highlights are stored in a database or other data construct, and the database may be searched according to the associated secondary data.
FIG. 1 illustrates one embodiment for acquiring and distributing an event's secondary data. For this illustrated embodiment, it is assumed the event is a sporting event, and the secondary data is statistics compiled about the event during the event.
A first operation is to acquire 100 secondary data related to primary data. In one embodiment, a third-party data source is contacted. This source may be a real- time data feed, such as from a courtside statistician entering data at a sporting event, or it may be a time delayed retrieval, such as real-time data that has been post- processed (e.g., corrected, synchronized with the event, etc.) before subsequent distribution. Time delayed may also include retrieval from a database or other storage medium.
The acquired data may then be converted 102, if necessary, into another format for storage into a database or other storage format. It is assumed herein that the invention may be used to acquire secondary data from many different sources; and that these sources may each use their own encoding format for initially encoding the secondary data. In such circumstances where there are multiple encoding formats, it is assumed that all formats not already in a common (e.g., unitary) format are converted into the common format for storage.
The secondary data, which may have been converted, is stored 104 in a database. In one embodiment, synchronization data is determined 106 and provided 108 to a partitioner (see FIG. 2), and stored 110 in the database along with the
secondary data. The synchronization data is used to cross-reference secondary data with primary data. Assuming secondary data is compiled contemporaneously with an event, in one embodiment, synchronization determination 106 includes identifying time stamps or other temporal markers to correlate a particular secondary data entry with the entry's corresponding primary data.
For example, if the event is a basketball game, the primary data can be a digital recording (or other format) of the game. The recording has explicit or implicit time markers tracking recording duration and/or time of day for game play. The secondary data can be real-time statistics entered by a courtside statistician. Statistic entries will have associated time markers for when the statistic was entered. In one embodiment, associated with these entries will be starting time and stopping time markers for the portion of the event relating to a particular statistic entry. For example, if a statistic concerns a three point shot, then the starting and stopping markers indicate, with respect to the primary data recording, where in the primary data recording that three point shot occurred. In another embodiment, rather than a statistic having explicit starting and stopping markers, instead a single time marker is used to mark the occurrence of a specific event, e.g., the three point shot. Starting and stopping markers can be determined later according to a variety of techniques.
For example, rules can be used to set the starting and stopping time markers. In one embodiment, a rule applying a preset time window can be used. Thus, for the above three point shot, the shot is assumed to occur 5 seconds prior to the statistic's time marker, and last for 5 seconds after the statistic entry. In another embodiment, a rule applying past experience with a statistic type can be used to set starting and stopping markers. For example, if it is known a certain occurrence type has a typical duration, then the rule can use this typical duration to set the starting and stopping markers.
In another embodiment, a rule identifying significant statistics can be used to set or adjust (e.g., operating in conjunction with another rule) starting and stopping markers. For example, in a baseball game where a player has just set a new record for home runs, the significance of a new record may be used to adjust markers. Thus, if
using the 5 seconds before/after statistic rule, set a stopping marker to 30 seconds after a statistic entry to account for more activity incident to the setting of a new record.
In one embodiment, starting and stopping markers are manually cross- referenced with the primary data contemporaneous with recording the statistic. In another embodiment, video analysis or image / pattern recognition is used to automatically identify starting and stopping markers. Both primary and secondary data markers may be localized, e.g., each starting at zero, or they may be based on a global clock, a standard atomic clock, or other timing technique, so long as they may be cross-referenced to each other.
FIG. 2 illustrates one embodiment for acquiring primary data for an event, and using synchronization data (from FIG. 1) to partition the primary data for distribution. A first operation is to acquire 200 primary data, such as a camera input signal. As discussed above, input signal can be for a sporting event, such as a basketball game, however the input signal may also represent, for example, a play, opera, interactive game, or any other event having transactions that can be recorded in analog or digital format to a medium.
The acquired primary data is then converted 202, if necessary, into a digital format. Similar to acquiring 100 (FIG. 1) secondary data, such as statistics, related to the event, acquired primary data may be received in a variety of formats. All primary data is therefore converted, when needed, into a common unitary format. As will be discussed below, the unitary format may then be provided to a requesting client in a particular desired format. For example, a live performance may be captured by a recording camera, stored in the unitary format, and then later converted into a Moving Pictures Experts Group (MPEG), Nideo for Windows, Indeo, QuickTime, Windows Media Format, Real Media Format, or other data file for distribution to the client. (All marks used herein are the property of their respective owners.)
The digital media file is then partitioned 204 in accordance with provided 108
(FIG. 1) synchronization data. Partitioning is helpful in that it allows for quick distribution of data containing highlights, e.g., highlights can be made available
contemporaneous with the action giving rise to the highlight. In addition, small sections of the primary data facilitate distribution of highlights.
The primary data for the event can be accessed while the primary data file is being written. As soon as a portion of the digital media file is recorded, but before the event is over and recording completes, the recorded portion of the digital media file may be used for distribution of highlights related to secondary data entries that have been cross-referenced to the partial digital media file. This allows distribution of highlights during the event for which the highlight was generated.
Note that while it is assumed a single primary data file is used, some operating systems and/or environments may not allow access to the primary data while it is being written. Although such a restriction does not affect the principles of operation for the invention, it will be appreciated that the restriction may be overcome by interleaving recording of the event into multiple primary data files. For example, recording in a first primary data file can occur until a certain end-point, such as a recording time limit, end of a partition, or other event. Then, recording of the first primary data file is closed, and simultaneously, a new recording in a second primary data file immediately started. In such fashion, the first completed primary data file may be processed.
In one embodiment, each partition contains only a single highlight. In another embodiment, more than one highlight may be present within a given partition of the digital media file. As discussed above, acquired secondary data has associated temporal markers, such as starting and stopping markers, that synchronize portions of the primary data to secondary data referencing the primary data, e.g., these markers indicate the portions of the primary data that are a highlight.
Multiple secondary data entries can refer to a single partition, thus allowing multiple highlights on a single partition, and multiple entries referring to a single highlight (e.g., broad and narrow statistical categories may refer to the same highlight). For example, a shot attempt, rebound and tip-in would generate several statistics all referencing the same partition. In one embodiment, partition contents overlap to ensure a highlight does not begin in one partition, and end in another
partition. Overlap may occur when partition sizing requirements, such as fixed partition sizes, cause a highlight to be broken across multiple partitions. In one embodiment, portions of the primary data that are not referenced by a highlight are discarded.
In one embodiment, rather than partitioning based on temporal markers, density (or frequency) of synchronization data may be used to partition the primary data according to activity within the event. For example, using the above basketball game example, it can be assumed the statistician only enters statistics (secondary data) for noteworthy actions in the game. Based on this assumption, if many statistics are entered for a first portion of the game, then the primary data corresponding to that period will be partitioned into smaller (possibly overlapping) partitions. In the above example of a shot attempt, rebound and tip-in, these activities result in several statistics in a short period of time. In this embodiment, several highlights for these activities would be bundled within a single partition. Conversely, if no statistics are entered for a portion of the game, then primary-data for this portion of game can be discarded, or relegated to a single partition that is unlikely be downloaded since it contains no highlights.
It is assumed partitioning results in separate data files. However it will be appreciated that partitioning can be logically effected using pointers referencing into a randomly accessible monolithic primary data file representing the event (or all highlights for the event). A client request for a partition, such as by a media access application program (see FIG. 4), can be resolved to offsets within the data file that define a virtual partition. In this embodiment, a distribution service would have the entire monolithic data file stored on its devices, and then determine and send the virtual partition in response to the client request. In such manner, various other partitioning schemes may be implemented through use of pointers to define virtual partitions.
After partitioning 204 the primary data, the partition may be converted 206 into a different data format. Conversion may be used when it is desired to pre-provide partition data in a variety of data formats, such as Microsoft's Audio Nideo Interleave
(ANI) format, Apple's QuickTime format, Interactive Pictures Corporation's "IPIX" (360° data), MPEG, Nideo for Windows, Indeo, QuickTime, Windows Media Format, Real Media Format, three-dimensional encodings, or other audio and/or visual encoding formats. Pre-provision can expedite delivery of content to requesting clients, as well as reduce load on a distribution service responsible for delivering the requested content. Conversion may be required if the primary data's digital format is not suited for distribution to requesting clients. For example, the primary data may be recorded in a non-standard format to facilitate partitioning of recorded event data.
After possibly converting the digital format for a partition, a media catalog is notified 208 of the existence of the new partition. The media catalog is responsible for recording 210, in a database or equivalent data construct, new partition creations. The recording 210 of the new partition identifies the created partition, and this identification is cross-referenced 212 with the database entry (or entries) containing secondary data entry referencing the new partition. Identification can be by way of partition name, storage location, file begin/end offsets within a data file, the start and stop time of the partition as synchronized to a global clock, or other uniquely identifying references.
One or more database records may be used to record a secondary data entry and associated creation notifications. In one embodiment, both secondary data and partitions are synchronized to a global clock to facilitate cross-referencing one to the other, and for searching for highlights within a particular partition. The database entry for the recorded 210 partition creation is marked 214 as being unavailable, and submitted 216 to a distribution service for media distribution. Marking as unavailable allows for a lag time between partition creation, and actual availability to a requesting client device. In one embodiment, recording 210 and submitting 216 are performed in parallel.
FIG. 3 illustrates one embodiment for distribution of new partitions through a content distribution service such as is provided by Digital Island, Inc. of San
Francisco, CA. A notification of a newly created partition is received 300. The content distribution service is contacted 302 to arrange for delivery of the new
partition's data to the distribution service. It will be appreciated that multiple distribution systems may be contacted so as to allow for distribution optimizations, such as by directing client access requests to distribution services that can most efficiently service the request.
After contacting the distribution service, the newly created partition is identified 304 to the distribution service, and submitted 306 to the service for distribution. In one embodiment, in response to submission, partitions are assigned a Uniform Resource Locator (URL) (or equivalent) address through which the new partition may be indirectly accessed through resolution of a database query which returns a file containing the partition's URL and offsets within the partition for accessing a particular highlight therein for playing by a client media access application such as a video player application commercially available from Microsoft Corporation or Real Networks, Inc.
In one embodiment, the File Transfer Protocol (FTP) is used to convey partition data to the distribution service. Other embodiments may use one or more protocols, including Unix-to-Unix Copy (UUCP), HyperText Transfer Protocol (HTTP) (e.g., through forms or other HTTP constructs), direct networking (e.g., over Transmission Control Protocol / Internet Protocol (TCP/IP) links), Point-to-Point Tunneling Protocol (PPTP), Virtual Private Networks (VPNs), or other communication arrangements.
After submitting the partition, a test 308 is performed to determine whether the submitted partition is available for retrieval from the distribution service. As indicated above, there can be a delay between submission and actual availability of the new partition. If 310 the new partition is available, then the database record for the new partition is marked 312 as being available. In one embodiment, the assigned URL is tested to determine retrievability of the submitted partition.
If 310 the new partition is not yet available, a test 314 is performed to determine whether a timeout condition has occurred. For example, a submitted partition may be required to be available within five minutes of submission, within a certain number of retrievability tests, or in accord with another metric. If a timeout
has not occurred, retrievability is tested again. If a timeout does occur, an error 316 condition is reached. In response, appropriate action can be taken, such as attempting to re-submit 306 the new partition for distribution, or generating an error condition and taking other action.
FIG. 4 illustrates providing a highlight to a client in response to a request from the client for the highlight. A highlight reel construction component receives 400 a highlight request from a media access application, such as a Microsoft video player, Real Networks player, etc. The highlight reel construction component is in communication with the database storing secondary data and associated links to partitions. It will be appreciated that highlights may have non-audio and/or visual formats. However, for simplicity, audiovisual players are assumed to be used by requesting clients.
In one embodiment, the request is formulated through client interaction (not illustrated) with a web site, database service, or other service. For example, a client may access a web page containing links identifying certain highlights, where each link encodes a query related to the identified highlights. Selecting a link, in one embodiment, directs the media access application program to submit the selected encoded query to the highlight reel construction component. In another embodiment, selecting the link results in the web page's web server submitting the selected encoded query to the highlight reel construction component.
In one embodiment, links are dynamically created through client interaction with web page controls, such as through selection of check boxes, menus, etc., where user manipulation of these controls generates a URL with an appropriate embedded search query. Thus, in the above basketball example, a first drop-down menu might allow a user to select a particular game, a second menu might allow the user to select a desired player, and a third menu might allow the user to select a desired shot, e.g., three-point shots. These selections are then encoded into a URL that is either presented to the user for selection and sending to the highlight reel construction component, or it is automatically sent to the highlight reel construction component.
The highlight reel construction component converts 402 a received request (e.g., from the client media application program, web server, or other service) into a search request of the database storing secondary data and cross-references to primary data partitions. The database is searched 404 for the highlight(s) satisfying the request. Only highlights marked as available (see FIG. 3 item 308) are returned in response to a search.
The search results are packaged 406 and returned 408 to the client media access application. In one embodiment, packaging comprises converting the database search results and associated highlight data, or link thereto, into an extensible Markup Language (XML) document which is returned to the media access application. In one embodiment, distribution service links to available highlights, secondary data related thereto, and indexing information (if needed) to identify the highlight locations within referenced partitions, are returned within the package. It will be appreciated that a different packaging formats may be used depending on the requirements or abilities of utilized media access applications. In one embodiment, the distribution service has multiple points of presence, and retrieval optimizations are applied to determine the best URL or equivalent links to package for the desired highlight(s).
In an alternate embodiment, the highlight reel construction component packages the highlights data itself rather than packaging links thereto. Note that, as discussed above, depending on how an event's primary data is partitioned 204 (FIG. 2), one or more highlights may reside within a partition. In this embodiment, if a requested highlight resides in a large partition, packaging automatically extracts (not illustrated) and packages only portions of the large partition relevant to the received request.
FIG. 5 and the following discussion are intended to provide a brief, general description of a suitable computing environment in which certain aspects of the illustrated invention may be implemented.
An exemplary system for implementing the invention includes a computing device 500 having system bus 502 for coupling various computing device components. Typically, attached to the bus are non-programmable and programmable
processors 504, a memory 506 (e.g., RAM, ROM), storage devices 508, a video interface 510, and input/output interface ports 512. Storage devices include hard- drives, floppy-disks, optical storage, magnetic cassettes, tapes, flash memory cards, memory sticks, digital video disks, and the like.
The invention may be described by reference to different high-level program modules and/or low-level hardware contexts. Those skilled in the art will realize that program modules can be interchanged with low-level hardware instructions. Program modules include procedures, functions, programs, components, data structures, and the like, for performing particular tasks or implementing particular abstract data types. Modules may be incorporated into single and multi-processor computing devices, Personal Digital Assistants (PDAs), cellular telephones, and the like. Thus, the storage systems and associated media can store data and executable instructions for the computing device.
The computing device is expected to operate in a networked environment using logical connections to one or more remote computing devices 514, 516 through a network interface 518, modem 520, or other communication pathway. Computing devices may be interconnected by way of a network 522 such as an intranet, the Internet, or other network. Modules may be implemented within a single computing device, or processed in a distributed network environment, and stored in both local and remote memory. Thus, for example, with respect to the illustrated embodiments, assuming computing device 500 is a client searching for and requesting highlights, then remote devices 514, 516 may be computing systems respectively storing the database containing secondary data, and the distribution service containing the partitioned primary data containing the highlights.
It will be appreciated that remote computing devices 514, 516 may be configured like computing device 500, and therefore include many or all of the elements discussed for computing device. It should also be appreciated that computing devices 500, 514, 516 may be embodied within a single device, or separate communicatively-coupled components, and may include or be embodied within routers, bridges, peer devices, web servers, and application programs utilizing
network application protocols such as the HyperText Transfer Protocol (HTTP), File Transfer Protocol (FTP), and the like.
Having described and illustrated the principles of the invention with reference to illustrated embodiments, it will be recognized that the illustrated embodiments can be modified in arrangement and detail without departing from such principles.
In addition, even though the foregoing discussion has focused on particular embodiments, it is understood that other configurations are contemplated. In particular, even though expressions such as "in one embodiment," "in another embodiment," or the like are used herein, these phrases are meant to generally reference embodiment possibilities, and are not intended to limit the invention to particular embodiment configurations. As used herein, these terms may reference the same or different embodiments, and unless implicitly or expressly indicated otherwise, embodiments are combinable into other embodiments. Consequently, in view of the wide variety of permutations to the above-described embodiments, the detailed description is intended to be illustrative only, and should not be taken as limiting the scope of the invention.
What is claimed as the invention, therefore, is all such modifications as may come within the scope and spirit of the following claims and equivalents thereto.