Patent Description:
<CIT> discloses a method of communicating with and controlling a puppet using story metadata that is downloaded from the internet at a puppeteer base. The puppeteer base includes behaviour selection logic to use the story metadata to choose an appropriate behaviour for the puppet.

<CIT> discloses a method and an apparatus used to target interactive virtual objects to subscribers in a television delivery system.

<CIT> discloses a broadcasting system that can control operations of external devices connected to the receiving device in synchronization with progress of a show being received.

The present invention provides a metadata receiving device and method as defined in the appended claims.

Embodiments are illustrated in the figures of the accompanying drawings, which are meant to be exemplary and not limiting, and in which like references are intended to refer to like or corresponding things.

It is to be understood that the figures and descriptions of the present invention have been simplified to illustrate elements that are relevant for a clear understanding of the present invention, while eliminating, for purposes of clarity, many other elements which are conventional in this art. Those of ordinary skill in the art will recognize that other elements are desirable for implementing the present invention. However, because such elements are well known in the art, and because they do not facilitate a better understanding of the present invention, a discussion of such elements is not provided herein.

The use of the terms "a," "an," "at least one," "one or more," and similar terms indicate one of a feature or element as well as more than one of a feature. The use of the term "the" to refer to the feature does not imply only one of the feature and element.

When an ordinal number (such as "first," "second," "third," and so on) is used as an adjective before a term, that ordinal number is used (unless expressly or clearly specified otherwise) merely to indicate a particular feature, such as to distinguish that particular feature from another feature that is described by the same term or by a similar term.

When a single device, article or other product is described herein, more than one device/article (whether or not they cooperate) may alternatively be used in place of the single device/article that is described. Accordingly, the functionality that is described as being possessed by a device may alternatively be possessed by more than one device/article (whether or not they cooperate). Similarly, where more than one device, article or other product is described herein (whether or not they cooperate), a single device/article may alternatively be used in place of the more than one device or article that is described. Accordingly, the various functionality that is described as being possessed by more than one device or article may alternatively be possessed by a single device/article.

The functionality and/or the features of a single device that is described may be alternatively embodied by one or more other devices, which are described but are not explicitly described as having such functionality/features. Thus, other embodiments need not include the described device itself, but rather can include the one or more other devices that would, in those other embodiments, have such functionality/features.

Various embodiments will now be described in detail on the basis of exemplary embodiments. Embodiments disclosed herein may be practiced using programmable digital computers and networks therefor.

Disclosed is a system that is able to deliver specialized data packets, such as metadata packets, to a target device for a particular piece of media.

<FIG> shows components of one embodiment of an environment in which embodiments of the innovations described herein may be practiced. Not all of the components may be required to practice the innovations, and variations in the arrangement and type of the components may be made without departing from the scope of the invention as defined in the appended claims. As shown, system <NUM> of <FIG> includes a media device or system <NUM>; local area networks (LANs) wide area networks (W ANs)- (network) <NUM>; wireless network <NUM>; target devices <NUM>(a), <NUM>(b). <NUM>(n), which may be a tablet, a set top box or a BD/DVD player; metadata database <NUM>; metadata delivery system <NUM> that delivers metadata stored in metadata database <NUM> to the target device <NUM> (a), <NUM>(b). <NUM>(n); and peripheral devices <NUM>(a), <NUM>(b). <NUM>(n), such as toys or secondary display device, which can be controlled remotely, for example, over a wireless network. The target device <NUM> (a), <NUM>(b). <NUM>(n) and the peripheral devices <NUM>(a), <NUM>(b). <NUM>(n) exchange information via a discovery process during which identification data is exchanged. Exemplary metadata delivery systems are described in <CIT> entitled Management, Categorization, Contextualizing and Sharing of Metadata-Based Content and<CIT>, entitled Identifying and Categorizing Contextual Data for Media, and <CIT> concurrently herewith by the same Applicant, OpenTV, Inc.

At least one embodiment of target devices <NUM>(a)-<NUM>(n) is described in more detail below in conjunction with <FIG>. In one embodiment, at least some of target devices <NUM>(a)-<NUM>(n) may operate over a wired and/or wireless network, such as networks <NUM> and/or <NUM>. Generally, target devices <NUM>(a)-<NUM>(n) may include virtually any computer capable of communicating over a network to send and receive information, perform various online activities, offline actions, or the like. In various embodiments, one or more of target devices <NUM>(a)-<NUM>(n) can be configured to operate with conjunction with a media device or system <NUM>, for example a television, radio, another computer, a tablet device, as smart phone, or any device enabled to allow a user to consume media. For example, target devices <NUM>(a)-<NUM>(n) can be configured to send data from a user consuming a media product on a media device or system <NUM>, for example a movie, television show, or listening to music from or another source or media device or system, e.g.: a television, a radio, a home theater, a sound system, another computer, or even in a movie theater, etc. In various embodiments the media product may be provided to the user locally, for example via DVD, CD, or any locally or physically stored media, etc. and can also be provided by a media content delivery service, such as a streaming media service, which can be provided by the metadata delivery system <NUM> to the other media device (e.g. a television or another computer). Target devices <NUM>(a)-<NUM>(n) need not of course be constrained to such use and may also be employed, for example, as an end-user computing node, or any other typical use for a computer device.

Computers that may operate as target device <NUM>(a) may include computers that typically connect using a wired or wireless communications medium such as personal computers, multiprocessor systems, microprocessor-based or programmable electronic devices, network PCs, or the like. In some embodiments, target devices <NUM>(a)-<NUM>(n) may include virtually any portable personal computer capable of connecting to another computing device and receiving information. However, portable computers are not so limited and may also include other portable devices such as cellular telephones, radio frequency (RF) devices, infrared (IR) devices, Personal Digital Assistants (PDAs), handheld computers, wearable computers, integrated devices combining one or more of the preceding devices, and the like. As such, target devices <NUM>(a)-<NUM>(n) typically range widely in terms of capabilities and features. Moreover, target devices <NUM>(a)-<NUM>(n) may access various computing applications, including a browser, or other web-based application.

A web-enabled target device may include a browser application that is configured to receive and to send web pages, web-based messages, and the like. The browser application may be configured to receive and display graphics, text, multimedia, and the like, employing virtually any web-based language, including a wireless application protocol messages (WAP), and the like. In one embodiment, the browser application is enabled to employ Handheld Device Markup Language (HDML), Wireless Markup Language (WML), WMLScript, JavaScript, Standard Generalized Markup Language (SGML), HyperText Markup Language (HTML), extensible Markup Language (XML), and the like, to display and send a message. In one embodiment, a user of the target device may employ the browser application to perform various activities over a network (online). However, another application may also be used to perform various online activities.

Target devices <NUM>(a)-<NUM>(n) may also include at least one other target device application that is configured to receive and/or send content between another computer. The target device application may include a capability to send and/or receive content, or the like. The target device application may further provide information that identifies itself, including a type, capability, name, and the like. In one embodiment, target devices <NUM>(a)-<NUM>(n) may uniquely identify themselves through any of a variety of mechanisms, including an Internet Protocol (IP) address, a phone number, Mobile Identification Number (MIN), an electronic serial number (ESN), or other device identifier. Such information may be provided in a network packet, or the like, sent between other target devices, metadata delivery system <NUM>, or other computers.

Target devices <NUM>(a)-<NUM>(n) may further be configured to include a target device application that enables an end-user to log into an end-user account that may be managed by another computer, such as metadata delivery system <NUM>, or the like. Such end-user account, in one non-limiting example, may be configured to enable the end-user to manage one or more online activities, including in one non-limiting example, search activities, social networking activities, browse various websites, communicate with other users, or the like. However, participation in such online activities may also be performed without logging into the end-user account.

Wireless network <NUM> is configured to couple target devices <NUM>(b)-<NUM>(n) and its components with network <NUM>. Wireless network <NUM> may include any of a variety of wireless sub-networks that may further overlay stand-alone ad-hoc networks, and the like, to provide an infrastructure-oriented connection for target devices <NUM>(b)-<NUM>(n). Such sub-networks may include mesh networks, Wireless LAN (WLAN) networks, cellular networks, and the like. In one embodiment, the system may include more than one wireless network.

Wireless network <NUM> may further include an autonomous system of terminals, gateways, routers, and the like connected by wireless radio links, and the like. These connectors may be configured to move freely and randomly and organize themselves arbitrarily, such that the topology of wireless network <NUM> may change rapidly.

Wireless network <NUM> may further employ a plurality of access technologies including 2nd (<NUM>), 3rd (<NUM>), 4th (<NUM>) 5th (<NUM>) generation radio access for cellular systems, WLAN, Wireless Router (WR) mesh, and the like. Access technologies such as <NUM>, <NUM>, L TE, <NUM>, <NUM>, and future access networks may enable wide area coverage for mobile devices, such as target devices <NUM>(b)-<NUM>(n) with various degrees of mobility. In one non-limiting example, wireless network <NUM> may enable a radio connection through a radio network access such as Global System for Mobile communication (GSM), General Packet Radio Services (GPRS), Enhanced Data GSM Environment (EDGE), code division multiple access (CDMA), time division multiple access (TDMA), Wideband Code Division Multiple Access (WCDMA), High Speed Downlink Packet Access (HSDPA), Long Term Evolution (LTE), and the like. In essence, wireless network <NUM> may include virtually any wireless communication mechanism by which information may travel between target devices <NUM>(b)-<NUM>(n) and another computer, network, and the like.

Network <NUM> is configured to couple network computers with other computers and/or computing devices, including, metadata delivery system <NUM>, target device <NUM>(a), and target devices <NUM>(b)-<NUM>(n) through wireless network <NUM>. Network <NUM> is enabled to employ any form of computer readable media for communicating information from one electronic device to another. Also, network <NUM> can include the Internet in addition to local area networks (LANs), wide area networks (WANs), direct connections, such as through a universal serial bus (USB) port, other forms of computer-readable media, or any combination thereof. On an interconnected set of LANs, including those based on differing architectures and protocols, a router acts as a link between LANs, enabling messages to be sent from one to another. In addition, communication links within LANs typically include twisted wire pair or coaxial cable, while communication links between networks may utilize analog telephone lines, full or fractional dedicated digital lines including T1, T2, T3, and T4, and/or other carrier mechanisms including, for example, E-carriers, Integrated Services Digital Networks (ISDNs), Digital Subscriber Lines (DSLs), wireless links including satellite links, or other communications links known to those skilled in the art. Moreover, communication links may further employ any of a variety of digital signaling technologies, including without limit, for example, DS-<NUM>, DS- <NUM>, DS-<NUM>, DS-<NUM>, DS-<NUM>, OC-<NUM>, OC-<NUM>, OC-<NUM>, or the like. Furthermore, remote computers and other related electronic devices could be remotely connected to either LAN s or WAN s via a modem and temporary telephone link. In one embodiment, network <NUM> may be configured to transport information of an Internet Protocol (IP). In essence, network <NUM> includes any communication method by which information may travel between computing devices.

Additionally, communication media typically embodies computer readable instructions, data structures, program modules, or other transport mechanism and includes any information delivery media. By way of example, communication media includes wired media such as twisted pair, coaxial cable, fiber optics, wave guides, and other wired media and wireless media such as acoustic, RF, infrared, and other wireless media.

One embodiment of a metadata delivery system <NUM> is described in more detail below in conjunctions with <FIG>. Briefly, however, metadata delivery system <NUM> includes virtually any network computer capable of delivering metadata-based content to a client user and accepting requests and data therefrom. For example, target devices <NUM>(a)-<NUM>(n) can be configured to send data from a user consuming a media product, for example a movie, television show, or listening to music from or another source or media device, e.g.: a television, a radio, a, movie theater, etc. The metadata delivery system <NUM> can then deliver, inter alia, complementary synchronous metadata-based content based on the identification of the media being consumed by the user. Computers that may be arranged to operate as metadata delivery system <NUM> include various network computers, including, but not limited to multiprocessor systems, server computers, and the like.

Although the metadata delivery system <NUM> may be a single computer, the invention is not so limited. For example, one or more functions of the metadata delivery system <NUM> may be distributed across one or more distinct network computers. Moreover, metadata delivery system <NUM> is not limited to a particular configuration. Thus, in one embodiment, metadata delivery system <NUM> may contain a plurality of network computers. In another embodiment, metadata delivery system <NUM> may contain a plurality of network computers that operate using a master/slave approach, where one of the plurality of network computers of metadata delivery system <NUM> is operative to manage and/or otherwise coordinate operations of the other network computers. In other embodiments, the metadata delivery system <NUM> may operate as a plurality of network computers arranged in a cluster architecture, a peer-to-peer architecture, and/or even within a cloud architecture. Thus, embodiments are not to be construed as being limited to a single environment, and other configurations, and architectures are also envisaged.

Although illustrated separately, metadata database <NUM> and metadata delivery system <NUM> may be employed as a single network computer, separate network computers, a cluster of network computers, or the like. In some embodiments, either metadata database <NUM> or metadata delivery system <NUM>, or both, may be enabled to deliver content, respond to user interactions with the content, track user interaction with the content, update widgets and widgets controllers, or the like.

<FIG> shows one embodiment of Target Device <NUM> that may be included in a system implementing embodiments of the invention. Target Device <NUM> may include many more or less components than those shown in <FIG>. However, the components shown are sufficient to disclose an illustrative embodiment for practicing the present invention. Target Device <NUM> may represent, for example, one embodiment of at least one of Target Device <NUM><NUM>(a)-<NUM>(n) of <FIG>.

As shown in the figure, Target Device <NUM> includes a processor <NUM> in communication with a mass memory <NUM> via a bus <NUM>. In some embodiments, processor <NUM> may include one or more central processing units (CPU). Target Device <NUM> also includes a power supply <NUM>, one or more network interfaces <NUM>, an audio interface <NUM>, a display <NUM>, a keypad <NUM>, an illuminator <NUM>, a video interface <NUM>, an input/output interface <NUM>, a haptic interface <NUM>, and a global positioning system (GPS) receiver <NUM> or other geolocation components, Power supply <NUM> provides power to Target Device <NUM>. A rechargeable or non-rechargeable battery may be used to provide power. The power may also be provided by an external power source, such as an alternating current (AC) adapter or a powered docking cradle that supplements and/or recharges a battery.

Target Device <NUM> may optionally communicate with a base station (not shown), or directly with another computer. Network interface <NUM> includes circuitry for coupling Target Device <NUM> to one or more networks, and is constructed for use with one or more communication protocols and technologies including, but not limited to, GSM, CDMA, TDMA, GPRS, EDGE, WCDMA, HSDP A, L TE, user datagram protocol (UDP), transmission control protocol/Internet protocol (TCP/IP), short message service (SMS), WAP, ultra-wide band (UWB), IEEE <NUM> Worldwide Interoperability for Microwave Access (WiMax), session initiated protocol/real-time transport protocol (SIP/RTP), or any of a variety of other wireless communication protocols. Network interface <NUM> is sometimes known as a transceiver, transceiving device, or network interface card (NIC).

Audio interface <NUM> is arranged to produce and receive audio signals such as the sound of media from another source (e.g., television, radio, etc.). For example, audio interface <NUM> may be coupled to a speaker and microphone (not shown) to enable telecommunication with others and/or generate an audio acknowledgement for some action.

Display <NUM> may be a liquid crystal display (LCD), gas plasma, light emitting diode (LED), organic LED, or any other type of display used with a computer. Display <NUM> may also include a touch sensitive screen arranged to receive input from an object such as a stylus or a digit from a human hand.

Keypad <NUM> may comprise any input device arranged to receive input from a user. For example, keypad <NUM> may include a push button numeric dial, or a keyboard. Keypad <NUM> may also include command buttons that are associated with selecting and sending images.

Illuminator <NUM> may provide a status indication and/or provide light. Illuminator <NUM> may remain active for specific periods of time or in response to events. For example, when illuminator <NUM> is active, it may backlight the buttons on keypad <NUM> and stay on while the Target Device is powered. Also, illuminator <NUM> may backlight these buttons in various patterns when particular actions are performed, such as dialing another target device. Illuminator <NUM> may also cause light sources positioned within a transparent or translucent case of the target device to illuminate in response to actions.

Video interface <NUM> is arranged to capture video images, such as a still photo, a video segment, an infrared video, or the like. For example, video interface <NUM> may be coupled to a digital video camera, a web-camera, or the like. Video interface <NUM> may comprise a lens, an image sensor, and other electronics. Image sensors may include a complementary metal-oxide-semiconductor (CMOS) integrated circuit, charge-coupled device (CCD), or any other integrated circuit for sensing light.

Target Device <NUM> also comprises input/output interface <NUM> for communicating with external devices, such as a headset, or other input or output devices not shown in <FIG>. Input/output interface <NUM> can utilize one or more communication technologies, such as USB, infrared, Bluetooth™, or the like.

Haptic interface <NUM> is arranged to provide tactile feedback to a user of the target device. For example, the haptic interface <NUM> may be employed to vibrate target device <NUM> in a particular way when another user of a computing computer is calling. Accelerometers and other kinetic or force-based interfaces can be included as well.

Target device <NUM> may also include GPS transceiver <NUM> to determine the physical coordinates of target device <NUM> on the surface of the Earth. GPS transceiver <NUM>, in some embodiments, may be optional. GPS transceiver <NUM> typically outputs a location as latitude and longitude values. However, GPS transceiver <NUM> can also employ other geo-positioning mechanisms, including, but not limited to, triangulation, assisted GPS (AGPS), Enhanced Observed Time Difference (E-OTD), Cell Identifier (CI), Service Area Identifier (SA1), Enhanced Timing Advance (ETA), Base Station Subsystem (BSS), or the like, to further determine the physical location of target device <NUM> on the surface of the Earth. It is understood that under different conditions, GPS transceiver <NUM> can determine a physical location within millimeters for target device <NUM>; and in other cases, the determined physical location may be less precise, such as within a meter or significantly greater distances. In one embodiment, however, target device <NUM> may through other components, provide other information that may be employed to determine a physical location of the computer, including for example, a Media Access Control (MAC) address, IP address, or the like.

Mass memory <NUM> includes a Random Access Memory (RAM) <NUM>, a Read-only Memory (ROM) <NUM>, and other storage means. Mass memory <NUM> illustrates an example of computer readable storage media (devices) for storage of information such as computer readable instructions, data structures, program modules or other data. Mass memory <NUM> stores a basic input/output system (BIOS) <NUM> for controlling low-level operation of target device <NUM>. The mass memory also stores an operating system <NUM> for controlling the operation of target device <NUM>. It will be appreciated that this component may include a general-purpose operating system such as a version of UNIX, or LINUX™, or a specialized client communication operating system such as Microsoft Corporation's Windows Mobile™, Apple Corporation's iOS™, Google Corporation's Android™ or the Symbian® operating system. The operating system may include, or interface with a Java virtual machine module that enables control of hardware components and/or operating system operations via Java application programs.

Mass memory <NUM> further includes one or more data storage <NUM>, which can be utilized by target device <NUM> to store, among other things, applications <NUM> and/or other data. For example, data storage <NUM> may also be employed to store information that describes various capabilities of target device <NUM>. The information may then be provided to another computer based on any of a variety of events, including being sent as part of a header during a communication, sent upon request, or the like. Data storage <NUM> may also be employed to store social networking information including address books, buddy lists, aliases, user profile information, or the like. Further, data storage <NUM> may also store message, web page content, or any of a variety of user generated content. At least a portion of the information may also be stored on another component of target device <NUM>, including, but not limited to processor readable storage media <NUM>, a disk drive or other computer readable storage devices (not shown) within target device <NUM>.

Processor readable storage media <NUM> may include volatile, nonvolatile, removable, and non-removable media implemented in any method or technology for storage of information, such as computer- or processor-readable instructions, data structures, program modules, or other data. Examples of computer readable storage media include RAM, ROM, Electrically Erasable Programmable Read-only Memory (EEPROM), flash memory or other memory technology, Compact Disc Read-only Memory (CD-ROM), digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other physical medium which can be used to store the desired information and which can be accessed by a computer. Processor readable storage media <NUM> may also be referred to herein as computer readable storage media and/or computer readable storage device.

Applications <NUM> may include computer executable instructions which, when executed by target device <NUM>, transmit, receive, and/or otherwise process network data. Network data may include, but is not limited to, messages (e.g. SMS, Multimedia Message Service (MMS), instant message (IM), email, and/or other messages), audio, video, and enable telecommunication with another user of another client computer. Applications <NUM> may include, for example, browser <NUM>, and other applications <NUM> including those described with respect to <FIG>. Other applications <NUM> may also include, but are not limited to, calendars, search programs, email clients, IM applications, SMS applications, voice over Internet Protocol (VOIP) applications, contact managers, task managers, transcoders, database programs, word processing programs, security applications, spreadsheet programs, games, search programs, and so forth.

Browser <NUM> may include virtually any application configured to receive and display graphics, text, multimedia, messages, and the like, employing virtually any web based language. In one embodiment, the browser application is enabled to employ HDML, WML, WMLScript, JavaScript, HTML, XML, and the like, to display and send a message. However, any of a variety of other web-based programming languages may be employed. In one embodiment, browser <NUM> may enable a user of target device <NUM> to communicate with another network computer, such as Metadata Delivery System 104of <FIG>.

Applications <NUM> may also include Widget Controller <NUM> and one or more Widgets <NUM>. Widgets <NUM> may be collections of content provided to the target device by Metadata Delivery System <NUM>. Widget Controller <NUM> may be a program that may be provided to the target device by Metadata Delivery System <NUM>. Widget Controller <NUM> and Widgets <NUM> may run as native target device applications or they may run in Browser <NUM> as web browser based applications. Also, Widget Controller <NUM> and Widgets <NUM> may be arranged to run as native applications or web browser applications, or combination thereof.

As used herein, the term "widget controller" refers to a computer program that may be operative on a client application. Widget controllers may be downloaded and/or otherwise deployed to a client application. Widget controllers may be arranged to be operative for downloading content, monitoring media, or otherwise managing widgets located within client applications.

As used herein, the term "widget" refers to a user-interface element located in the client application. Widgets may be invisible or visible to users of the client applications. In some cases, a widget controller may generate widget "on-the-fly" before deploying content into the widget. Widgets may be adapted to reflect the operating environment of the client application that they are being hosted within. For example, in clients that support HTML, CSS a widget may be an HTML element such as a DIV, P, or the like. For client application operative in a Java environment, a widget may be a View object or Window object, and so on.

<FIG> shows one embodiment of a network computer <NUM>, according to one embodiment of the invention. Network computer <NUM> may include many more or less components than those shown. The components shown, however, are sufficient to disclose an illustrative embodiment for practicing the invention. Network computer <NUM> may be configured to operate as a server, client, peer, a host, or any other computer. Network computer <NUM> may represent, for example Metadata Delivery System <NUM> of <FIG>, and/or other network computers.

Network computer <NUM> includes processor <NUM>, processor readable storage media <NUM>, network interface unit <NUM>, an input/output interface <NUM>, hard disk drive <NUM>, video display adapter <NUM>, and memory <NUM>, all in communication with each other via bus <NUM>. In some embodiments, processor <NUM> may include one or more central processing units.

As illustrated in <FIG>, network computer <NUM> also can communicate with the Internet, or some other communications network, via network interface unit <NUM>, which is constructed for use with various communication protocols including the TCP/IP protocol. Network interface unit <NUM> is sometimes known as a transceiver, transceiving device, or network interface card (NIC).

Network computer <NUM> also comprises input/output interface <NUM> for communicating with external devices, such as a keyboard, or other input or output devices not shown in <FIG>. Input/output interface <NUM> can utilize one or more communication technologies, such as USB, infrared, Bluetooth™, or the like.

Memory <NUM> generally includes RAM <NUM>, ROM <NUM> and one or more permanent mass storage devices, such as hard disk drive <NUM>, tape drive, optical drive, and/or floppy disk drive. Memory <NUM> stores operating system <NUM> for controlling the operation of network computer <NUM>. Any general-purpose operating system may be employed. Basic input/output system (BIOS) <NUM> is also provided for controlling the low-level operation of network computer <NUM>.

Although illustrated separately, memory <NUM> may include processor readable storage media <NUM>. Processor readable storage media <NUM> may be referred to and/or include computer readable media, computer readable storage media, and/or processor readable storage device. Processor readable storage media <NUM> may include volatile, nonvolatile, removable, and non-removable media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules, or other data. Examples of processor readable storage media include RAM, ROM, EEPROM, flash memory or other memory technology, CDROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other media which can be used to store the desired information and which can be accessed by a computer.

Memory <NUM> further includes one or more data storage <NUM>, which can be utilized by network computer <NUM> to store, among other things, applications <NUM> and/or other data such as content <NUM>. For example, data storage <NUM> may also be employed to store information that describes various capabilities of network computer <NUM>. The information may then be provided to another computer based on any of a variety of events, including being sent as part of a header during a communication, sent upon request, or the like. Data storage <NUM> may also be employed to store messages, web page content, or the like. At least a portion of the information may also be stored on another component of network computer <NUM>, including, but not limited to processor readable storage media <NUM>, hard disk drive <NUM>, or other computer readable storage medias (not shown) within network compute <NUM>.

Data storage <NUM> may include a database, text, spreadsheet, folder, file, or the like, that may be configured to maintain and store user account identifiers, user profiles, email addresses, IM addresses, and/or other network addresses; or the like.

In at least one of the various embodiments, data storage <NUM> may include databases <NUM>. In various embodiments, as shown in <FIG>, databases include such as one or more signature databases (e.g. an audio signature database <NUM>, a video signature database <NUM>, a narrative signature database <NUM>), a segment database <NUM>, an associations database <NUM>, a metadata database <NUM>, a media playlist database <NUM>, a context database <NUM>, and a context category database <NUM>. Although the system shows the databases <NUM> as included in the system and server <NUM>, one or more of the databases can be external to the server or system and operatively connected thereto.

Returning to <FIG>, data storage <NUM> may further include program code, data, algorithms, and the like, for use by a processor, such as processor <NUM> to execute and perform actions. In one embodiment, at least some of data store <NUM> might also be stored on another component of network computer <NUM>, including, but not limited to processor-readable storage media <NUM>, hard disk drive <NUM>, or the like.

Applications <NUM> may include computer executable instructions, which may be loaded into mass memory and run on operating system <NUM>. Examples of application programs may include transcoders, schedulers, calendars, database programs, word processing programs, Hypertext Transfer Protocol (HTTP) programs, customizable user interface programs, IPSec applications, encryption programs, security programs, SMS message servers, IM message servers, email servers, account managers, and so forth. Applications <NUM> may also include, for example, a website server <NUM>, a Common Segment Detector Application <NUM>, one or more Context Difference Detector Applications <NUM>, a Data Categorizer Application <NUM>, a Context Assignment Module <NUM>, and/or Context Filtering and Request Handler <NUM>.

Website server <NUM> may represents any of a variety of information and services that are configured to provide content, including messages, over a network to another computer. Thus, website server <NUM> can include, for example, a web server, a File Transfer Protocol (FTP) server, a database server, a content server, or the like. Website server <NUM> may provide the content including messages over the network using any of a variety of formats including, but not limited to HTML, XML, Compact HTML (cHTML), Extensible HTML (xHTML), or the like.

In at least one of the various embodiments, Applications <NUM> may be operative on Metadata Delivery System <NUM> of <FIG>. Applications <NUM> may employ processes, or parts of processes, similar to those described in conjunction with <FIG>, to perform at least some of its actions.

<FIG> depicts an example of representations for baseline synchronized metadata. As shown in <FIG>, the synchronized textual metadata <NUM> (a), <NUM>(b). <NUM>(n) contains precise timing information related to the AN stream timeline <NUM> of media <NUM> being played back, which results in that the target device is able to synchronize the rendering of the metadata to the playback. For example, when the media <NUM> is movie Toy Story, the synchronized textual metadata <NUM> (a) indicates that the type of metadata <NUM> (a) is fact, and at time point "<NUM>" text "Toy Story is a <NUM> American computer-animated buddy-comedy adventure film produced by Pixar Animation Studios and released by Walt Disney Pictures. Directed by John Lasseter, Toy Story was the first feature-length computer-animated film and the first theatrical film produced by Pixar" will be displayed on the screen associated with the target device.

<FIG> shows an exemplary flow showing binary control data targeted based on peripherals. As shown in <FIG>, target devices <NUM>(a) and <NUM>(b) are connected to peripheral devices <NUM>(a), <NUM>(b), <NUM>(c), and <NUM>(d), respectively. Each type of peripheral device has its own set of control commands that are unique for that type of peripheral. Sequences of control commands, which can have very precise timing, are configured to control the peripheral (e.g., toy) to perform different functions.

As shown in <FIG>, metadata database <NUM> provides metadata to the metadata delivery system <NUM>. Target device <NUM>(a) communicates the peripheral identification information <NUM>, which is data about the connected peripheral devices <NUM>(a) and <NUM>(b), to the metadata delivery system <NUM> so that the metadata delivery system <NUM> may send peripheral control data <NUM>, which is only relevant for peripheral device R <NUM>(a) and peripheral device S <NUM>(b), to target device <NUM>(a). Similarly, target device <NUM>(b) communicates the peripheral identification information <NUM>, which is data about the connected peripheral devices <NUM>(b) and <NUM>(c), to the metadata delivery system <NUM> so that the metadata delivery system <NUM> may send peripheral control data <NUM>, which is only relevant for peripheral device S <NUM>(b) and peripheral device T <NUM>(c), to target device <NUM>(b). It will be noted that a peripheral device may be connected to one or more target devices. The control commands for the peripherals are inserted into binary metadata packets and distributed to the target device using the metadata delivery system, which will be described below referring to <FIG>.

<FIG> depicts exemplary representations for baseline system enhanced with binary data packets intended for peripherals. As shown in <FIG>, in addition to the synchronized textual metadata <NUM>(a)-<NUM>(e) that corresponds to the A/V stream timeline <NUM> of the media <NUM> which has been described in <FIG>, synchronized binary metadata <NUM>(a)-<NUM>(f) that corresponds to the A/V stream timeline <NUM> is also delivered to the target device. The binary data packets include a textual header with some peripheral specific addressing information in text format and a binary payload holding the control data for the peripheral. An example of the binary data packet <NUM>(a) will be described below referring to <FIG>.

<FIG> illustrates an example of metadata packet intended for a peripheral device. In the metadata packet <NUM>(a), type <NUM> "PeripheralData" indicates that metadata packet <NUM>(a) is intended for a peripheral device. Time <NUM> indicates the time point, for example, <NUM>, at which the intended peripheral device should perform a particular action designated by the metadata packet <NUM>(a). Peripheral ID <NUM> indicates that metadata packet <NUM>(a) is intended for a particular peripheral device with ID "Disney_35". Payload <NUM> indicates the action indicated by "0xAB01F12C. " to be performed by the particular peripheral device.

Referring back to <FIG>, for example, synchronized binary metadata <NUM>(a) includes information that means that the peripheral device "Jessie doll" with version higher than <NUM>. x should perform action "giggle" at time point <NUM>. Similarly, metadata <NUM>(b) means that the peripheral device "Woody doll" with version higher than <NUM>. 4x should perform action "raise right arm" at time point <NUM><NUM><NUM>; metadata <NUM>(c) means that the peripheral device "Woody doll" should speak "Hi Jessie. Long time no see" at time point <NUM>; metadata <NUM>(d) means that the peripheral device "Buzz toy" with version no lower than <NUM> should speak "To infinity and beyond" at time point <NUM>; metadata <NUM>(e) means that the peripheral device "Jessie doll" with version higher than <NUM>. x should perform action "kick left leg" at time point <NUM>; and metadata <NUM>(f) means that the peripheral device "Buzz toy" with version no lower than <NUM> should perform action "turn head right and blink" at time point <NUM>.

<FIG> depicts an exemplary embodiment of an overall architecture and data flow of the metadata delivery system. As shown in <FIG>, metadata delivery system <NUM> delivers standard textual metadata <NUM> and peripheral specific binary data <NUM> to the target device <NUM>. The peripheral specific binary data <NUM> includes binary metadata <NUM>(a)-<NUM>(c), which is intended to peripheral devices <NUM>(a)-<NUM>(c), respectively. The target device <NUM> distributes the binary metadata <NUM>(a)-<NUM>(c) to the corresponding peripheral devices <NUM>(a)-<NUM>(c), which will perform actions according to the distributed metadata.

As shown in <FIG>, the target device typically renders the delivered metadata on its associated screen <NUM>, e.g. a TV for a set top box. In the case of binary data packets meant for a peripheral, the packet data may not be rendered, but instead broadcast to the appropriate peripheral via a wireless network to which both the target device and peripherals are connected.

In various embodiments, the sourcing of the binary data packets meant for the peripherals is external to the metadata delivery system and the packets can be sourced in a just-in-time fashion before being delivered to the target device. This type of external sourcing allows for real-time changes to the peripheral control data, e.g. to fix bugs or to modify the behavior of the peripheral, e.g. the toy, by the peripheral maker. One exemplary advantage of external sourcing is that the system can be configured to avoid having peripheral control data permanently coded into a non-external video delivery stream (e.g. coded or provided in a local device or product) and hence not being changeable over time. For example, Toy Story has been distributed on DVD, BD and in streaming format. A Toy Story DVD purchased <NUM> years ago can be played still in any DVD player. That DVD contains no information beyond the movie itself. If Disney produced a wirelessly controllable Woody doll next year, none of the millions of existing Toy Story DVD's in circulation would be able to control the Woody doll and thus, the Woody doll would not be able to interact with the media as it is being played back.

Further, in the metadata delivery system, each piece of data delivered to the target device carries timing information relative to the media being played back. In this way the target device can buffer data and only act on the data at exactly the right time, thus achieving precise synchronization with the playback of the media.

For binary packets intended for peripherals, the packets are broadcast to a relevant, connected peripheral. In certain embodiments, distances between the target device and the peripherals are short and hence network transmission quality can be very good with negligible lag between the target device broadcast moment and the reception of the data by the peripheral. This means that the peripheral can derive its internal timing in part based on when it receives data and thus, highly precise synchronization between the peripheral and the media can be achieved even without a two-way protocol such as RTSP. If the target device loses sync with the media, this can be communicated to the peripherals. In various embodiments the target device can be configured to stop transmitting control data to the peripherals until the target device has regained synch with the media.

In various embodiments, each peripheral may communicate directly with the metadata delivery system, so that the flow of data may be managed without using a target device.

Accordingly, in various embodiments the system is configured to enable the peripheral devices to synchronize behaviors independently of the way the media item is distributed. Additionally, in various embodiments the behaviors do not have to be prebuilt into a peripheral, for example, in a toy at shipping. Thus the peripheral's behavior can change and evolve over time. Thus the peripheral can be synchronized to a more expansive and evolving media as the peripheral's behaviors can be updated or modified for each new media item.

For example, where the peripheral is a toy, the toy 'recognizes' a video sequence from a new movie related to the toy, and multiple behaviors can be supported for any particular video sequence, and not be limited to the inbuilt memory capacity of the toy; new behaviors can be introduced over time keeping the toy's behavior fresh.

In various embodiments, a peripheral can be configured to learn and add new behaviors which can then be stored in the system. For example, when the user of the toy moves the toy while watching/synchronized to a video sequence, the toy's sensors can record the movements introduced by the user. When the toy is moved by the user to perform actions of, for instance, a dance, these actions may be automatically uploaded into the system and used by other toys for that particular video sequence. A toy can learn how to dance to a particular video sequence by aggregating how the toy users' moves their toy during that sequence. The aggregation algorithm may apply methods that include averaging and smoothing the limb movements, for example, to effectively crowd source a new toy dance or movements for that video sequence.

As shown in <FIG>, in various embodiments the peripheral devices have their own class of metadata packets, and do not generate their own response data. In other embodiments, the peripheral devices can generate their own data to be sent to other devices, such as the target device. Thus in various embodiments, there can be a class of metadata packets intended for peripheral device that generates response data, which is described below referring to <FIG>.

<FIG> illustrates an example of metadata packet intended for a peripheral device that is capable of generating its own response data asynchronously and sending the response data back to the target device. The target device can monitor the motions of the peripheral device by reading at the response data sent back from the peripheral device. The metadata packets include an identifier indicating the peripheral can send response data and also include a Response Handler portion, after the Peripheral Payload portion.

In the metadata packet <NUM>, type <NUM> indicates that metadata packet <NUM> is "Two way peripheral data. " Time <NUM> indicates the time point at which the intended peripheral device should perform a particular action designated by the metadata packet <NUM>. Peripheral ID <NUM> indicates that metadata packet <NUM> is intended for a particular peripheral device with ID "Disney_87". Peripheral Payload <NUM> indicates the action to be performed by the particular peripheral device. The Response Handler <NUM> is a set of instructions intended for the target device, which instructs the target device how to act after the target device has sent the Peripheral Payload to the desired peripheral device. In their simplest form, these instructions are byte codes, but they can also be higher level direct action instructions that are tailored to functionality of the target device.

<FIG> illustrates an example of possible implementation of actions included in the Response Handler. As shown in <FIG>, an action can have arguments following it. For example, the possible Two Way Peripheral Data Response Handler actions may be "wait N seconds," "pause playback N second," "capture activity motion," "filter for min movement," "positive audio, Good Job", etc..

Because the format for these actions is target device independent, a same interpreter can be used on multiple target devices, and only a recompile is required for that particular device.

<FIG> depicts an example of the data flow of a metadata delivery system comprising a peripheral device that can generate response data. As shown in <FIG>, after the synchronized data <NUM> is delivered to the target device <NUM>, the target device <NUM> sends the Peripheral Payload <NUM> to the peripheral device <NUM> and passes the Response Handler <NUM> to the interpreter <NUM>. The peripheral device <NUM> sends data <NUM> generated by itself back to the target device <NUM>. These generated data <NUM> are used as inputs to the interpreter <NUM> when the actions <NUM> are processed. Some actions, such as play audio or pause playback, require communication with the native code <NUM> on the target device <NUM>.

Alternatively, <FIG> depicts the data flow of a metadata delivery system, which defines standard interfaces for the peripheral device and Response Handler actions. As shown in <FIG>, having a standard data interface <NUM> for peripherals cuts down the chance of errors and having a standard set of actions <NUM> simplifies the processing. Similar to those described above with respect to <FIG>, after the synchronized data <NUM> is delivered to the target device <NUM>, the target device <NUM> sends the Peripheral Payload <NUM> to the peripheral device <NUM> and passes the Response Handler <NUM> to the interpreter <NUM>. The peripheral device <NUM> sends data <NUM> generated by itself back to standard interface <NUM> of the target device <NUM>. These generated data <NUM> are used as inputs to the interpreter <NUM> when the standard actions <NUM> are processed. Some actions require communication with the native code <NUM> on the target device <NUM>.

<FIG> shows a flow chart for one possible implementation of how to process a "Two Way Peripheral Data" packet on a target device. The target device starts the metadata packet processing at step <NUM>. The metadata delivery system sends the metadata packet <NUM> to the target device. The metadata packet <NUM>, for example, indicates that this is a Two Way Peripheral Data type metadata which is intended to peripheral device with ID "Fitbit_12" to perform actions indicated by Peripheral Payload at time point "<NUM>".

After receiving the metadata packet <NUM>, in step <NUM> a determination is made regarding whether the type of the metadata packet <NUM> is Two Way Peripheral Data. If the type of the metadata packet <NUM> is not Two Way Peripheral Data, the "NO" line leads to step <NUM> where the target device begin to process the metadata as other types of packets. If the type of the metadata packet <NUM> is determined as Two Way Peripheral Data, the "YES" line leads to step <NUM> where a determination is made regarding whether it is time to process the packet based on the current time <NUM>. If it is determined that it is not the right time, the "NO" line leads back to step <NUM> where determination is made again until the determination result is "YES", then the "YES" line leads to step <NUM> where the target device sends the Peripheral Payload to all the peripheral devices with ID designated by the Two Way Peripheral Data packet, e.g., "Fitbit_12". Then the target device executes Response Handler in step <NUM>, which will be described in detail in <FIG>. In step <NUM>, a determination is made regarding whether there is more data to be processed, and if there is more data, the "YES" line leads back to step <NUM>. Otherwise, the "NO" line leads to an end step <NUM>.

<FIG> shows a flow chart for one possible execution of a Response Handler on the target device. The target device starts the Response Handler executing at step <NUM>. For example, the metadata packet <NUM> delivered to the target device indicates that this is a Two Way Peripheral Data type metadata which is intended to peripheral device with ID "Fitbit_12" to perform actions indicated by Peripheral Payload at time point "<NUM>", and the Response Handler indicates the actions to be performed by the target device, such as "wait N second for movement", "if no movement, play audio 'pausing video' wait N seconds", etc..

After receiving the metadata packet <NUM> that includes the Response Handler, the interpreter in the target device interprets the action in the Response Handler in step <NUM>. After receiving data <NUM> from the peripheral device with ID "Fitbit_12", e.g., AccelerometerData="0x123aC237. ", in step <NUM> the interpreter interprets data in context of Response Handler Action, and the target device execute the needed functions, e.g., pause video, play video, play audio, etc. In step <NUM>, a determination is made regarding whether there are more actions in Response Handler, and if there are more actions, the "YES" line leads back to step <NUM>. Otherwise, the "NO" line leads to an end step <NUM>. It will be noted that most Response Handler actions can be both synchronous and asynchronous.

In another embodiment, the peripheral devices or the target device may be second screen applications or companion applications, which are meant to complement media played on another screen, such as a primary screen. The peripheral device, such as the toy, may have a built-in target device. The target device and the peripheral may exist in a same physical object as well as separate, networked objects. Companion applications are running in proximity to the primary screen. Since both the primary screen and the secondary screen produce ambient light, to avoid the contrast between these different sources of ambient light that creates a distracting or unpleasant viewing environment, the metadata delivery system may create trigger events within the database using a data map, and send the trigger-points to the companion application to change the graphical user interface (GUI) of the second screen or companion application at specific moments of the media being playback.

<FIG> depicts an exemplary data flow of an embodiment of a metadata delivery system that creates GUI adjustment triggers. The system can gather information about a media title from a variety of sources and then linking this information to create an information map of the media, e.g., a film. The triggers can be generated automatically based on automated audio/video analysis or manually using the data map as a guideline to what GUI changes are most appropriate.

As shown in <FIG>, a video analyzer and data input application <NUM> gathers information from three data sources, including media source <NUM> that provides audio and video stream data <NUM>, existing media database <NUM> that provides contextual information about collections of media <NUM>, and data providers <NUM> that provides contextual and temporal information <NUM>. An example of data sources that provide contextual data are described in <CIT> entitled Management, Categorization, Contextualizing and Sharing of Metadata-Based Content and <CIT> , entitled Identifying and Categorizing Contextual Data for Media, and <CIT> concurrently herewith by the same Applicant, OpenTV, Inc. Further, in various embodiments manual data can be gathered from paid annotators or crowd-sourcing applications.

The resulting pool of data can be aggregated and linked through the timeline of the media and key contextual elements of the media (genre, era, etc. The same contextual elements can also be used to link several media titles together and determine useful patterns shared by groups of film and television programs. These patterns can then be used to approximate appropriate GUI changes for an unanalyzed media title based on similar media titles. Although this data can come from a variety of sources, the data itself can be from automated analysis of a temporal A/V element, contextual data, or other temporal data, examples of each of which are described below.

<FIG> depicts an embodiment of an exemplary data flow for processing audio and video packets from an elementary stream in a media source <NUM>, to perform automated analysis of a temporal A/V element. Automated analysis of an A/V element data can give the system guidelines to most needed changes to the GUI. Digitally encoded audio and video can be extracted from an elementary stream <NUM> as a frame image (video) <NUM> or pulse-code modulation (PCM) audio segment <NUM>. In a standard player, these pieces are rendered and synchronized during audio/video playback. However, these packets can also be fed into various algorithms, such as video analyzing algorithms <NUM> and audio analyzing algorithms <NUM>, to analyze the properties of the audio and video. Some examples of data derived from these types of analyses are edit detection metrics, color-palette skew (e.g. warm, cool, vibrant, pastel, etc.,) gamma and histogram distribution of color, luma (i.e. brightness,) face recognition, song recognition, and peaks in audio amplitude. For example, the result of video analyzing algorithms <NUM> shows that palette skew is vibrant; luminosity is dark; last frame delta is <NUM>%, etc, and the result of audio analyzing algorithms <NUM> shows that amplitude max is. <NUM>, duration is <NUM>, etc. The results of these analyses can be mapped to a timeline using the timestamps that are built into the digital video format meant to synchronize audio and video playback. One example of this form of timestamps is the presentation timestamp (PTS) of the MPEG-<NUM> transport stream. The result of this process is a collection of information about the audio and video mapped to the timeline of a specific media title.

Referring back to <FIG>, existing media databases <NUM> store non-time-related, contextual information about media titles. Using the title of the media in question, these databases can provide data such as filmmakers, genres, release dates, series or serial relationships, and so on.

In various embodiments the system is configured to process contextual data. <FIG> illustrates an example of finding relationships between films to estimate GUI triggers. Each of these data points can be queried to find other media titles similar to the original media title. For example, a query of the film The Thin Man <NUM> could return that the film's genres are mystery <NUM> and comedy <NUM>, and the release year <NUM> of the film is <NUM>. The film's writer is Dashiell Hammett <NUM>, and the director is W. Van Dyke <NUM>. The stars in the film include William Powell1507 and Myrna Loy <NUM>. The film has a sequel which is After the Thin Man <NUM>. Further analysis of these attributes of The Thin Man <NUM> would reveal several similarities to the film The Maltese Falcon <NUM> whose release year <NUM> is <NUM>, since they share the same writer Dashiell Hammett <NUM>, same genre mystery <NUM> and same general era attribute, e.g. <NUM> year apart. It also shows that the director of film The Maltese Falcon <NUM> is John Huston <NUM>, and the stars include Humphrey Bogart <NUM> and May Astor <NUM>. This relational information could prove important if a system has an A V-Element Analysis of The Thin Man <NUM>, but not of The Maltese Falcon <NUM>. In this case it may be viable to use some generalized (non-temporal) GUI modifications determined or defined for The Thin Man <NUM> during playback of The Maltese Falcon <NUM>.

Referring back to <FIG>, data providers <NUM> may provide other temporal data, for example contextual and temporal information <NUM> for events that occur in film that are difficult or impossible to determine programmatically and automatically as described above. For example the geographical setting within the narrative space is very difficult to determine from video analysis of the frame images, especially if the location in question only exists in the fictional space of the media. Other examples include era, art direction and props. All of this information can be manually entered by human contributors and attached to moments along the timeline. For example, a person can note that a film takes place in a Victorian mansion in rural England during specific moments. Now the location, era, and artistic styling of the narrative space can be stored in a database along with the times within the film during which this data is valid.

As shown in <FIG>, the data collected from three data sources may be linked together using the common data markers of the film and the timeline of the film. That is, from time x to time y in a specific media title, the video analyzer and data input application <NUM> performs a digital analysis of the audio and video combined with the temporal data provided by human contributors. There is general information about the media title for estimating unknown data from other related media titles. The aggregated data is generated and the video analyzer & data input application <NUM> sends the contextually and temporally synchronized visual palettes <NUM>, i.e., a data map, to database <NUM>.

<FIG> illustrates an example of segments of a data map. Segment <NUM>, which includes the information of cut <NUM>, indicates scene number is <NUM>, location of the cut is Lord Busness's Tower, luma of the cut is <NUM>, and color distribution of the cut <NUM> which is illustrated by histograms showing the intensity of Red, Green, and Blue. Similarly, segment <NUM>, which includes the information of cut <NUM>, indicates scene number is <NUM>, location of the cut is Western Saloon, luma of the cut is <NUM>, and color distribution of the cut <NUM>. Segment <NUM>, which includes the information of cut <NUM>, indicates scene number is <NUM>, location of the cut is Lego Plane, luma of the cut is <NUM>, and color distribution of the cut <NUM>. Segment <NUM>, which includes the information of the cut <NUM>, indicates scene number is <NUM>, location of the cut is Western Town Saloon, luma of the cut is <NUM>, and color distribution of the cut <NUM>.

In various embodiments the data map can be used to create trigger events within the database that tell the companion application how and when to change its GUI at specific moments of the film. These GUI adjustment triggers can be created manually with the creator of the trigger using the data map as reference. Triggers can also be created automatically using the AV -Element data to guide changes like color, volume, or brightness.

For example, the GUI adjustments may be simple changes like adjusting the brightness or volume of the companion application to complement the source media as it changes throughout playback, or adjustments may be complicated changes like reskinning the entire GUI to match the current era of a time-traveling character as he or she jumps through centuries within a film.

<FIG> illustrates an example of segments of a data map with GUI triggers. For example, if the GUI adjustment triggers is created based on the luma of the cut, as shown in <FIG>, the GUI adjustment <NUM> may adjust the brightness of the companion application to complement the cut <NUM> whose luma is <NUM>. Similarly, if the GUI adjustment triggers is created based on the color distribution of the cut, the GUI adjustment <NUM> may adjust the color of the companion application to complement the color distribution of the cut <NUM>. If the GUI adjustment triggers is created based on the location of the cut, the GUI adjustment <NUM> may adjust the volume of the companion application, for example, to increase the volume, to complement the cut <NUM> whose location is Lego Plane which, for example, is very noisy.

After the GUI adjustment triggers are created, referring back to <FIG>, the database <NUM> sends the contextually and temporally synchronized GUI instruction <NUM> which includes the GUI adjustment triggers to the second device <NUM>. The primary screen <NUM> and the second device <NUM> may be located in the same viewing room <NUM>. Therefore, the contrast between the different ambient light produced by the primary screen and the second screen can be avoided by sending GUI adjustment triggers to adjust the second screen to complement media played on the primary screen.

Accordingly, disclosed is a system which is capable of delivering synchronized metadata to a target device for a specific piece of media. The metadata delivery stream includes externally sourced peripheral specific binary control data packets. The binary data packets are not rendered by the target device, but rather broadcast in a synchronized fashion any connected peripheral. The binary data packets are only fully interpreted by the peripheral itself.

Claim 1:
A method implemented on a target device (<NUM>(a)-(n), <NUM> (a), <NUM>(b), <NUM>, <NUM>, <NUM>, <NUM>) including at least one processor, a computer readable storage medium including computer code, and at least one storage device, wherein, when the computer code is executed by the at least one processor, the computer code causes the at least one processor to:
receive, from a metadata delivery system (<NUM>, <NUM>, <NUM>), metadata packets related to media (<NUM>) being consumed by the target device (<NUM>(a)-(n), <NUM>(a), <NUM> (b), <NUM>, <NUM>, <NUM>, <NUM>), wherein the media (<NUM>) includes audio and video data, and the metadata packets include textual metadata packets (<NUM>(a)-(e)) which include timing information (<NUM>, <NUM>) related to the media (<NUM>) for synchronizing the rendering of text in the textual metadata packets (<NUM>(a)-(e)) at the target device (<NUM>(a)-(n), <NUM>(a), <NUM> (b), <NUM>, <NUM>, <NUM>, <NUM>) with the media (<NUM>) on a primary device (<NUM>, <NUM>) associated with the target device (<NUM>(a)-(n), <NUM>(a), <NUM>(b), <NUM>, <NUM>, <NUM>, <NUM>);
wherein the metadata packets further include peripheral metadata packets (<NUM>(a)(f), <NUM>, <NUM>, <NUM>) which include the timing information related to the media (<NUM>), peripheral addressing information for a plurality of peripherals (<NUM>(a)-(n), <NUM>(a)-(d), <NUM>(a)-(c), <NUM>, <NUM>, <NUM>) associated with the target device (<NUM> (a)-(n), <NUM>(a), <NUM>(b), <NUM>, <NUM>, <NUM>, <NUM>), and a peripheral payload (<NUM>, <NUM>, <NUM>) including a first set of actions for use by the plurality of peripherals (<NUM>(a)-(n), <NUM>(a)-(d), <NUM>(a)-(c), <NUM>, <NUM>, <NUM>) to perform the first set of actions; and
send information (<NUM>, <NUM>) to the metadata delivery system (<NUM>, <NUM>, <NUM>) the information comprising peripheral identification information (<NUM>, <NUM>) for the plurality of peripherals (<NUM>(a)-(n), <NUM>(a)-(d), <NUM>(a)-(c), <NUM>, <NUM>, <NUM>) connected to the target device (<NUM>(a)-(n), <NUM>(a), <NUM>(b), <NUM>, <NUM>, <NUM>, <NUM>), and information identifying the media (<NUM>), the peripheral identification information (<NUM>, <NUM>) being used to send metadata to a given target device based on peripheral devices connected to this given target device.