[go: up one dir, main page]

HK1140084A1 - A system for remotely controlling client recording and storage behavior - Google Patents

A system for remotely controlling client recording and storage behavior Download PDF

Info

Publication number
HK1140084A1
HK1140084A1 HK10106481.1A HK10106481A HK1140084A1 HK 1140084 A1 HK1140084 A1 HK 1140084A1 HK 10106481 A HK10106481 A HK 10106481A HK 1140084 A1 HK1140084 A1 HK 1140084A1
Authority
HK
Hong Kong
Prior art keywords
client system
capture request
recording
program
client
Prior art date
Application number
HK10106481.1A
Other languages
Chinese (zh)
Other versions
HK1140084B (en
Inventor
保罗‧韦斯特布鲁克
霍华德‧卢克
詹娒斯‧杨
斯蒂芬‧莱西
蒂莫西‧戴维森
Original Assignee
Tivo Solutions Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=32711150&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=HK1140084(A1) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Application filed by Tivo Solutions Inc. filed Critical Tivo Solutions Inc.
Publication of HK1140084A1 publication Critical patent/HK1140084A1/en
Publication of HK1140084B publication Critical patent/HK1140084B/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/65—Transmission of management data between client and server
    • H04N21/654—Transmission by server directed to the client
    • H04N21/6543—Transmission by server directed to the client for forcing some client operations, e.g. recording
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/21—Server components or server architectures
    • H04N21/218—Source of audio or video content, e.g. local disk arrays
    • H04N21/2181—Source of audio or video content, e.g. local disk arrays comprising remotely distributed storage units, e.g. when movies are replicated over a plurality of video servers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/24—Monitoring of processes or resources, e.g. monitoring of server load, available bandwidth, upstream requests
    • H04N21/2407—Monitoring of transmitted content, e.g. distribution time, number of downloads
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/41—Structure of client; Structure of client peripherals
    • H04N21/414—Specialised client platforms, e.g. receiver in car or embedded in a mobile appliance
    • H04N21/4147—PVR [Personal Video Recorder]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/433—Content storage operation, e.g. storage operation in response to a pause request, caching operations
    • H04N21/4331—Caching operations, e.g. of an advertisement for later insertion during playback
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/433—Content storage operation, e.g. storage operation in response to a pause request, caching operations
    • H04N21/4334—Recording operations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/433—Content storage operation, e.g. storage operation in response to a pause request, caching operations
    • H04N21/4335—Housekeeping operations, e.g. prioritizing content for deletion because of storage space restrictions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/442—Monitoring of processes or resources, e.g. detecting the failure of a recording device, monitoring the downstream bandwidth, the number of times a movie has been viewed, the storage space available from the internal hard disk
    • H04N21/44213—Monitoring of end-user related data
    • H04N21/44222—Analytics of user selections, e.g. selection of programs or purchase activity
    • H04N21/44224—Monitoring of user activity on external systems, e.g. Internet browsing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/4508—Management of client data or end-user data
    • H04N21/4516—Management of client data or end-user data involving client characteristics, e.g. Set-Top-Box type, software version or amount of memory available
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/4508—Management of client data or end-user data
    • H04N21/4532—Management of client data or end-user data involving end-user characteristics, e.g. viewer profile, preferences
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/458—Scheduling content for creating a personalised stream, e.g. by combining a locally stored advertisement with an incoming stream; Updating operations, e.g. for OS modules ; time-related management operations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/462—Content or additional data management, e.g. creating a master electronic program guide from data received from the Internet and a Head-end, controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities
    • H04N21/4622—Retrieving content or additional data from different sources, e.g. from a broadcast channel and the Internet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/466—Learning process for intelligent management, e.g. learning user preferences for recommending movies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/466—Learning process for intelligent management, e.g. learning user preferences for recommending movies
    • H04N21/4667—Processing of monitored end-user data, e.g. trend analysis based on the log file of viewer selections
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/472—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content
    • H04N21/47214—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content for content reservation or setting reminders; for requesting event notification, e.g. of sport results or stock market
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/475—End-user interface for inputting end-user data, e.g. personal identification number [PIN], preference data
    • H04N21/4755—End-user interface for inputting end-user data, e.g. personal identification number [PIN], preference data for defining user preferences, e.g. favourite actors or genre
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/858—Linking data to content, e.g. by linking an URL to a video object, by creating a hotspot
    • H04N21/8586—Linking data to content, e.g. by linking an URL to a video object, by creating a hotspot by using a URL
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00—Details of television systems
    • H04N5/76—Television signal recording
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00—Details of television systems
    • H04N5/76—Television signal recording
    • H04N5/765—Interface circuits between an apparatus for recording and another apparatus
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00—Details of television systems
    • H04N5/76—Television signal recording
    • H04N5/78—Television signal recording using magnetic recording
    • H04N5/782—Television signal recording using magnetic recording on tape
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00—Details of television systems
    • H04N5/76—Television signal recording
    • H04N5/91—Television signal processing therefor
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/025—Systems for the transmission of digital non-picture data, e.g. of text during the active part of a television frame
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/16—Analogue secrecy systems; Analogue subscription systems
    • H04N7/162—Authorising the user terminal, e.g. by paying; Registering the use of a subscription channel, e.g. billing

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Human Computer Interaction (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Social Psychology (AREA)
  • Business, Economics & Management (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

A system for remotely controlling client recording and storage behavior schedules the recording, storing, and deleting of multimedia content on a client system storage device. The viewer may request that certain content be captured. Capture requests also allow the service to determine content to be recorded by the client system in the same manner that a viewer requests that certain content are recorded but are more powerful than what a viewer can request. Recording requests for a capture request can preempt viewer requests or be entered at the same or lower priority as a viewer request. Capture requests can adjust all aspects of a recording request and affect the capture request itself. Client system operational functionality are also manipulated by the service using capture requests.

Description

Method and apparatus for remotely controlling storage and operation of a client system
Cross Reference to Related Applications
The present application is a divisional application of the chinese patent application having application number 2004800042390.
Technical Field
The invention relates to controlling storage and recording behavior of a client system. More particularly, the present invention relates to remotely controlling the storage and logging behavior of a client system from a server.
Background
In the design of automated data processing systems, a typical tension exists between pure client-server based systems, such as computer mainframe systems or the world wide web, and pure distributed systems, such as a network of workstations (NOWS), etc., for solving complex computer problems, such as modeling nuclear explosions or breaking cryptographic keys.
Client-server systems are popular because they rely on a clear division of responsibility between the server and the client. A server is often expensive and specially managed because it performs computations or stores data for a large number of clients. Each client is inexpensive, having only the local resources needed to interact with the system user. It is assumed that a network with reasonable performance connects a server and a client. The economic model of these systems is a model of central management and control that reduces the incremental cost of the client systems employed.
However, the model has considerable costs that must be considered. For example, the incremental cost of adding a new client system can be very high. Additional network capacity must be available, sufficient computing resources must be available to support the client, including storage, memory, and computing cycles, and each client requires additional computational overhead due to these additional resources. As central servers become larger and more complex, they become less and less reliable. Eventually, a system failure of the server results in all clients losing service.
Distributed systems are popular because the resources of the system are allocated to each client, which enables more complex functionality within the client. Because the program or data is located with the client, access to the program or data is faster, which reduces the load on the network itself. The system is more reliable because a node failure affects only the node itself. Many computing tasks are easily broken down into parts that can be independently computed and these parts are inexpensively distributed among the systems involved. This also reduces network bandwidth requirements and limits the impact of failed nodes.
On the other hand, distributed systems are more complex for administrators and may be more difficult to diagnose and resolve hardware or software failures.
Television viewing can be modeled as a client-server system, but where server-client network paths are used for all infinite speed purposes and intents, and client-server network paths are incoherent and unmanageable. This is a natural product of the nature of television broadcasts. The cost of adding another viewer is zero and the service delivered is the same as that delivered to all other viewers.
Much effort has been made to deliver television programming over computer networks such as the internet, or even over local cable television equipment operating as a network, and such efforts continue. The point-to-point nature of computer networks makes these efforts impractical and expensive because additional resources are required for each added viewer. Fully interactive television systems, where the viewer has full control of the video stream bandwidth through the client set-top box device, have proven to be less economical because the dedication of server resources to each client quickly limits the size of the system that can be advantageously built and managed.
However, television viewers have shown great interest in selecting and controlling the viewing of television. This interest has created a need for client systems to efficiently manage the memory requirements of the program material that the viewer wants to record. In addition, management of recording desired program material is equally important to memory management tasks.
Many home electronics devices already contain mass storage and are becoming more and more. The amount of storage available in these devices has been staggering, but the end of the "doubling every year" rule of thumb for disk drives is not seen. Each year, the storage capacity of other types of storage media is also becoming larger, including: CompactFlash, SmartMedia, Zip, FlashMemory Sticks, Microdrive, Pocketdrive, and SuperDisk.
The apparent control of this memory is achieved by the viewer storing his own TV programs, music, pictures, etc. on his client system. A less obvious use, but with continued growth in applicability and importance, is the control of this memory by service providers. There is an increasing desire by service providers to control the memory physically owned by the viewer.
It would be advantageous to provide a system for remotely controlling client recording and storage behavior that allows a service provider to remotely control the storage behavior of a client system. It would further be advantageous to provide a system for remotely controlling the recording and storage behavior of a client that allows a service provider to remotely control the recording behavior of a client system.
Disclosure of Invention
The present invention provides a system for remotely controlling client recording and storage behavior. The system allows a service provider to remotely control the storage behavior of a client system. In addition, the present invention provides a system that allows a service provider to remotely control the logging behavior of a client system.
The client device, represented by the applicant's own U.S. patent serial No. 6,233,389, provides functionality typically associated with a central video server, such as storage of large amounts of video content, the ability to select and play such content as needed, and full "VCR-like" control of content delivery, represented by the applicant's own U.S. patent serial No. 6,327, 418.
The preferred embodiment of the present invention schedules (schedule) the recording, storing, and deleting of multimedia content on the client system storage. The present invention takes as input a program viewing preference list in comparison to a program guide object database. The program guide object indicates when the content of interest is actually broadcast.
A schedule of time versus available storage space is generated that is optimal for the viewer's explicit or inferred preferred content. The viewer may request that certain content be captured, which gives those content the highest possible priority.
The viewer can also explicitly express preferences using an adjunct provided through the viewer interface. In addition, preferences may be derived from viewing patterns. These preferences correspond to objects stored in a replicated database.
The present invention provides an object, referred to as a capture request, that is sent by a server to a client system. The capture request reflects local storage management decisions on how the client system memory is allocated (partitioned). Over time, capture requests may be edited and changed. The capture request also allows the server to determine the content to be recorded by the client system in the same manner that the viewer requests the recording of specific content.
The capture request is more powerful than the viewer can request. The record request for the capture request may be entered at the same or a lower priority level instead of or as the (preempt) viewer request. The capture request may adjust aspects of the recording request and affect the capture request itself. The server also manipulates client system operating functionality using the capture request.
The present invention correlates an input schedule that tracks free and occupied time slots for each input resource with a space schedule that tracks all currently recorded content and content that has been scheduled for future recording to schedule new content to be recorded and resolve recording conflicts. If the content is recorded at any time between the start of recording and the termination of recording, there is sufficient space available to hold it. Content scheduled for recording based on inferred preferences automatically loses all conflicting decisions. All scheduling conflicts are resolved as early as possible. The preference weights of the content involved are used to resolve schedule conflicts resulting from recording aggregate objects.
The background scheduler attempts to schedule each preferred content in turn until the preferred content list is exhausted or no further recording opportunities are available. The preferred content is scheduled if and only if there is no conflict with other scheduled content.
Other aspects and advantages of the present invention will become apparent from the following detailed description, taken in conjunction with the accompanying drawings, illustrating by way of example the principles of the invention.
Drawings
FIG. 1 is a schematic block diagram of a preferred embodiment of a distributed television viewing management system in accordance with the present invention;
FIG. 2 is a schematic block diagram of the structure of viewing objects in computer memory for program access in accordance with the present invention;
FIG. 3 is a schematic block diagram illustrating how a schema for viewing objects is structured in computer memory for program access in accordance with the present invention;
FIG. 4 is a schematic block diagram illustrating an example diagram of relationships between viewing objects describing information about a program in accordance with the present invention;
FIG. 5 is a schematic block diagram illustrating an example graph of relationships that may be generated when processing viewer preferences for determining programs of interest in accordance with the present invention;
FIG. 6 is a schematic block diagram illustrating the input and storage space arrangement for making records in accordance with the present invention;
FIG. 7 is a flowchart showing the steps taken to schedule a recording using the mechanism described in FIG. 6, in accordance with the present invention;
FIG. 8 is a schematic block diagram of a preferred embodiment of the present invention showing a boot system configuration in accordance with the present invention;
FIG. 9a is a schematic block diagram of a decision flow diagram for a boot component according to the present invention;
FIG. 9b is a schematic block diagram of a decision flow diagram for a boot component according to the present invention;
FIG. 10 is a schematic block diagram of a decision flow diagram for a software installation process in accordance with the present invention;
FIG. 11 is a schematic block diagram of a preferred embodiment of the present invention for distributing content information to a plurality of client systems recording content from broadcast signals based on remote commands from a server in accordance with the present invention; and
FIG. 12 is a schematic block diagram illustrating an editing and distributed system for controlling the storage and recording behavior of a client system in accordance with the present invention.
Detailed Description
The invention is embodied in a system for remotely controlling client recording and storage behavior. The system according to the invention allows the service provider to remotely control the storage behavior of the client system. In addition, the present invention allows the service provider to remotely control the logging behavior of the client system.
The present invention is embodied in a television viewing information transmission and collection system that improves the ability of individual viewers to select and automatically record television programs for later viewing, while providing opportunities for service providers to enhance and direct the viewing experience. The present invention describes a fully distributed system in which, for an individual viewer, calculations regarding that viewer are performed personally within a local client device, while providing reliable aggregation and dissemination (dissemination) of information regarding viewing habits, preferences, or purchases.
Television viewing information database
Fig. 1 gives a schematic overall view of the invention. The focus of the present invention is a method and apparatus for maintaining a distributed database of television viewing information in the computer systems of a central site (central site)100 and a very large number of client computing systems 101. The process of extracting the appropriate subset of the central copy of the database is referred to as "slicing" 102, delivering the resulting "slices" to the client as "transmission" 103, delivering the collected information about or representative of the audience to the central site as "collection" 104, and processing the collected information to produce a new television viewing object or report as "analysis" 107; in all cases, the act of recreating objects of one database within another is referred to as "replication" 105. The data items to be transferred or collected are referred to as "objects" 106, and each replicated subset of the central database and the central database contained in the client device is a "object-based" database. Objects within this database are often referred to as "television viewing objects", "viewing objects", or simply "objects", emphasizing their intended use. However, one skilled in the art will readily recognize that the object may be any type of data.
The viewing object database provides a consistent abstract software access model for the objects it contains that is independent of and parallel to the replication activities described herein. By using this interface, an application can create, destroy, read, write, and otherwise manipulate objects in a database without regard to the underlying activity, while ensuring that consistent and reliable viewing of the objects in the database and the relationships between them are maintained at all times.
Basic television viewing object principles
Referring to fig. 2, the television viewing objects are structured as a collection of "attributes" 200. Each attribute has, for example, an integer, string, or logical type 201 and a value 202. All attribute types are taken from a fixed pool of basic types supported by the database.
The object attributes are divided into two groups: a "basic" attribute, provided by the creator or maintainer of the viewing object; and "export" attributes, automatically created and maintained by mechanisms within the database. The base type describes the characteristics of the object itself; the derived attributes describe the relationships between objects. Basic attributes are replicated between databases, while derived attributes are not.
Referring to FIG. 3, there is a small set of base object types defined by the present invention; each object type is represented as a particular set of related attributes 300, referred to herein as a "schema". Schema definition is used for each attribute type template 301, where each attribute type template includes a type 302 and an attribute name 303. The actual television viewing object is created by assigning resources to the object and assigning values to the attributes defined by the schema. For example, a "program" mode may include attributes such as the producer, director, or actors in the program, on-screen icons, multi-line descriptions of the program content, edit ratings of the program, and the like. The physical program object is created by allocating storage for the physical program object and filling the attributes with relevant data.
There is a specific object type, called schema type, that is predefined for all databases. Each schema supported by the database is represented by a schema object. This causes the application to perform "introspection" on the database, i.e., dynamically discover what object types are supported and their schema. This greatly simplifies the application software and eliminates the need to change the application software when changing, adding, or deleting modes. Like all other viewing objects, mode objects are processed by the method of the present invention.
Referring again to FIG. 2, each object in the database is assigned an "object ID" 203, which must be unique within the database. Each object ID can take many forms as long as it is unique. The preferred embodiment uses a 32-bit integer for object I D because it provides a useful tradeoff between processing speed and the number of unique objects allowed. Each object also includes a "reference count" 204, which is an integer number given to the number of other objects in the database that refer to the current object. Objects with a reference count of zero will not be present in the database (see below).
One particular type of viewing object is a "directory" object. The directory object holds a list of object IDs and associated simple names for the objects. The directory object may include other directory objects that are part of a list, and there is a single resolvable object called the "root" directory. The directory object order traversed starting at the root directory and continuing until an object of interest is found is referred to as the "path" to the object; thus, a path represents a particular location within the hierarchical namespace created in all directory objects present in the database. An object may be referenced by multiple paths, meaning that an object may have multiple names. For each directory that references it, the reference count on the viewing object is incremented by one.
Method for maintaining database compatibility and accuracy
One of the features of the preferred embodiment of the present invention is to ensure that each database replica remains internally consistent at all times and this consistency is maintained automatically without reference to other databases and without connection to a central site. There is no guarantee that the transmission or collection operation will occur in a timely manner or at any determined period. For example, a client system may be shut down for months; when transmission to the system is ultimately possible, object replication must always form a consistent subset of the server database, even though it is not possible to transmit all the objects needed to fully synchronize the central and client databases.
Even more seriously, there is no guarantee of a stable operating environment during the time that the database is in use or being updated. For example, the power supplied to the device may stop. The present invention treats all data updates as "transactions," which means that all transactions will be completed, or none at all. The particular technique chosen is referred to as a "two-phase commit," in which all elements of a (log) transaction are examined and recorded, after which the actual update is performed. Those skilled in the art will appreciate that a standard log processing technique, in which transactions are segmented (stag) into separate logs, in conjunction with a roll-forward technique, in which logs are used for repeated partial updates in the event of a failure, is sufficient for this purpose.
One required derived attribute for each object is the "version", which changes with each change of the object; the version attribute may be represented as a monotonically increasing integer or other representation that creates a monotonic ordering of the versions. The schema for each object that can be replicated includes an attribute called "source version" that represents the version of the object from which the source version is replicated.
The transmission of the viewing object does not guarantee that every client receives the object. For example, external factors such as sun blackouts can corrupt portions of the transmission sequence (sequence) while the object is being broadcast. Viewing objects may be continuously re-transmitted to address these issues, meaning that the same object may be displayed multiple times for replication. It is not appropriate to simply update the database object each time an object to be copied is received, because the number of versions will increase although no change has actually occurred. Additionally, it is desirable to avoid initializing transactions to update objects when unnecessary; considerable system resources are consumed during the transaction.
Two approaches are combined to solve this problem. First, most objects will have a basic property called "deadline". This is the date and time beyond which its object is no longer valid and should be discarded. When a new object is received, the expiration time is checked and if expired, the object is discarded. The deadline handles objects whose transmission is delayed in some way, but it does not handle multiple receptions of the same unexpired object.
The source version attribute handles this issue. When the viewing object is transmitted, this attribute is copied from the current version attribute of the source object. Upon receipt of the viewing object, the received source version of the object is compared to the source version of the current object. If the new object has a higher source version attribute, it is copied onto the existing object, otherwise it is discarded.
It is assumed that a greater number of viewing objects than are of interest are transmitted to any particular client system. For example, clients connected to other cable systems are not interested in "channel" viewing objects that describe channels on a particular cable system. Due to the overhead of capturing and adding new objects to the database, it is advantageous to filter the received objects according to other attributes in addition to those described above. The present invention achieves this by using a filter based on object type and attribute values. In one embodiment, this filter is based on running some type of executable code, perhaps as a command sequence, which is written with expertise in various object types and how they should be filtered.
In a preferred embodiment of the invention, a "filter" object is defined for each object type that represents what attributes are needed, should not exist, or add attributes to a range of acceptable attribute values in the database. Those skilled in the art will readily appreciate that this filter object may contain some form of executable code (possibly a sequence of executable commands). These commands will examine and compare the attributes and attribute values of the object being filtered, forming an indication of whether the object should be the target for further processing.
The viewing object is rarely independent of other objects. For example, a "show" object (describing a particular time on a particular channel) depends on a "show" object (describing a particular TV show). An important aspect of maintaining compatibility is to ensure that all dependent objects either always exist in the database or are added as part of a single transaction before attempting to add a new viewing object. This is accomplished using a basic property of the new viewing object, called the "dependency" property, which lists only the object ID and source version of the object on which the new object depends. Obviously, the new object versions must be compatible in the sense that the schema defining the new version is the same or has a strict superset of the properties of the original schema.
When a new viewing object is received, the database is checked first to see if all dependencies of the object exist; if so, the object is added to the database. Otherwise, the new object is "segmented" and saved in the save area until all dependent objects are also segmented. Obviously, in order to add a new set of viewing objects to the database, the dependency graph must be closed (close) between objects in the staging area and objects already present in the database based on the two object IDs and source versions. Once the seal is achieved (which means that all dependent objects exist), the new object is added to the database in a single atomic transaction.
Television receiverNaming and finding viewing objects
The directory object has been described previously. Referring to FIG. 4, the collection of directory objects, and the directed graph formed starting at the root path 400 and enumerating all possible paths to viewing objects, are referred to as a "namespace". In order to find an object without knowing a particular object ID, one or more paths within this namespace must reference it. For example, application software is almost uninteresting on object I D, rather the software prefers to reference it via, for example, the "/tvschedule/today" path. In this example, the actual objects referenced may change every day, without requiring changes in any other part of the system.
One way in which a path to an object may be established is to specify a "pathname" base attribute on the object. The object is added to the database and a directory object describing the path component is created or updated to add the object. This naming is typically used only for debugging replication mechanisms. It is not advisable (discovery) to set up explicit paths because the portion of the central database replicated on each client system will be different, creating great difficulty in managing pathnames among all replicas of the database.
The preferred method for adding objects to a database namespace is referred to as "indexing". In a preferred embodiment of the present invention, an "indexer" object is defined for each object type that indicates what properties will be used when indexing it into the database namespace. Those skilled in the art will readily appreciate that this indexer object may contain some form of executable code, possibly a sequence of executable commands. These commands examine and compare the properties and property values of the objects being indexed, forming an indication of where in the namespace the objects should be located.
Depending on the object type, the indexer examines a particular set of attributes connected to the object. When such attributes are found, the indexer automatically adds names to the objects within a hierarchical namespace represented by a directory graph in the database based on the attribute values. Referring again to fig. 4, program object 401 may have both an "actor" attribute with a value of "John Wayne" and a "director" attribute with a value of "John Ford". The root directory may represent two subdirectories: "byactor" 402 and "bydirector" 403. The indexer then adds the paths "/byactor/John Wayne" and "/bydirector/JohnFord" to the database, both of which refer to the same object 401.
An export attribute 404 is maintained for each object that lists the directory object that references this object. When the indexer adds a path to the namespace for this object, it adds the final directory I D in the path to this list. This ensures the closure of the object graph-once an object is found, all references to the object within this database are also found, whether they are paths or dependencies.
The unique new method of adding objects to a database has many advantages over standard methods. The indexer sorts the objects into the database as they are added. Thus, the study of objects associated with a particular path is a sequence selected from an ordered list, which can be efficiently implemented by one skilled in the art.
Deleting objects from a database
While the rules for adding objects to the database are important, the rules for removing objects from the database are also important in maintaining consistency and accuracy. For example, if there are no robust rules for removing objects, the database may grow indefinitely over time as stale objects aggregate.
The ground rule for deleting an object from a database is based on reference counting; objects whose reference count drops to zero are generally deleted. This means, for example, that the object must be referenced by a directory or some other object to exist in the database. This rule applies to all objects in the closed dependency graph based on the object being deleted. Thus, if objects that reference other objects (e.g., directories) are deleted, the reference count on all objects referenced is decremented, and those objects are similarly deleted to a zero count, and so on.
There are also automatic programs for deleting objects from the database, called "harvesters". Periodically, the harvester examines all objects in the database and, depending on the object type, further examines various attributes and attribute values to determine if the object should remain in the database. For example, the expiration attribute may indicate that the object is no longer valid and the reaper will delete the object.
In this preferred embodiment, using a method similar to (or possibly the same as) the filtered indexing method described above, the reaper may instead access a reaper object associated with the object type of the current object, which may include various types of executable code, possibly sequences of executable commands. Such code examines the attributes and attribute values of the current object and determines whether the object should be deleted.
The overhead of deleting each object whose reference count has been reduced to zero individually can be quite high because each such deletion causes a transaction with the database. It is advantageous to limit the performance impact of the harvest object so that foreground operations are performed at maximum speed. In a preferred embodiment, this is achieved using a technique based on the common garbage collection method.
For example, instead of deleting an object whose reference count has been reduced to zero, the reaper does not perform other actions. Periodically, a background task called a garbage collector checks each object in the database. If the reference count for the object is zero, it is added to the list of objects to be deleted. In one embodiment, once the garbage collector has examined the entire database, it will delete all such objects in a single transaction. Those skilled in the art will appreciate that this approach may also result in a significant performance penalty, as other accesses to the database may be delayed while the object is being deleted. Furthermore, if all objects are deleted correctly, changes to the database may have to be delayed during the garbage collector's action, which results in even worse performance.
In a preferred embodiment, the garbage collector checks the database in a series of passes. Once a certain number of objects have been collected, they are eradicated in a single transaction. The procedure continues until all objects have been inspected. This technique does not guarantee that all garbage objects have been collected during the inspection process because parallel activities may free up previously inspected objects. However, these objects will be discovered the next time the garbage collector runs. The number of objects scraped in each pass is adjustable to obtain acceptable performance for other database activities.
Operations on a distributed television viewing object database
Consideration of maintaining a distributed viewing object database
Replication of television viewing objects in a distributed database instance necessarily requires that the objects be transmitted over unreliable and insecure distribution channels.
For example, if the object is transmitted on a broadcaster, such as within a radio or television transmission, there is no guarantee that the data will be transmitted accurately or completely. Weather, such as storms, can cause a signal to be lost during transmission. Other sources of interference may be other broadcast signals, heavy equipment, household appliances, etc.
Those skilled in the art will readily appreciate that there are standard techniques for managing the transmission of data over unreliable channels, including iterative transmission, error correction codes, and other techniques available for transmission, any or all of which may be used in any particular situation.
To improve efficiency, objects to be replicated are collected together in an allocation package, referred to herein as a "slice". A slice is a subset of a database of television viewing objects associated with clients within a particular domain (e.g., a geographic region) or under the coverage area of a satellite transmitter.
The security of these slices is very important. Slices are used to add objects to a database that is used to provide useful services to users of the database, as well as to store information that may be considered private or confidential. Due to the broadcast-oriented nature of slice transmission, slices can be easily copied by third parties when they are transmitted. A practical solution to these problems is to encrypt the slice during transmission. An ideal reference for the technology employed in the present invention is "Applied Cryptography" by Bruce Schneier, John Wiley, and Sons, 1995: protocols, Algorithms, and Source Code in C ".
In a preferred embodiment of the present invention, a secure encrypted channel is established using techniques similar to those described in U.S. Pat. No. 4,405,829, often described as asymmetric key encryption, or sometimes public/private key pair encryption. Those skilled in the art will recognize that asymmetric key encryption based protocols serve as a reliable and efficient basis for authentication of client devices and secure distribution of information. Generally, authentication is provided using the exchange of signed messages between the client and the central system. Secure distribution is provided by encrypting all communications using a short-term symmetric key sent during the authentication phase.
Successful security requires that the sender and receiver agree in advance on the asymmetric key pair used for encryption. Such key distribution is the weakest link in any cryptographic system for protecting electronic data. U.S. patent serial No. 6,385,739 entitled "Self-Test electronic Assembly and Test System" on 19.7.1999, owned by the applicant of the present invention, describes a mechanism by which a client device generates an asymmetric key pair that is automatically the final step in the manufacturing process. The private key thus generated is stored in a secure microprocessor embedded within the client device so that the key is never presented to the external device. The public key thus generated is transmitted to the local manufacturing system, which records the key and the client serial number in a secure database. The database is then securely transmitted to a central distribution system where it is used to perform secure communications with clients.
The unique new application of the key generation solves the key distribution problem because the private key is never presented to an external component in the client, where it is identified using a special tool such as a logic analyzer. Instead, the private key may be used only within the secure microprocessor itself to decrypt the message that was originally encrypted with the public key, and then provide its results to the external component.
The following description assumes that all communications between the client and the central system are authenticated and encrypted as described above.
Transmitting viewing objects to client systems
Referring again to fig. 1, in a preferred embodiment of the present invention, the following steps constitute "transmission" of television viewing objects from a central database using slices:
1. there may be many mechanisms for transmitting slices to the entirety of the client viewing device. For example, the slices may be downloaded directly through a telephone modem or cable modem 109, may be modulated into the lines of the Vertical Blanking Interval (VBI) of a standard television broadcast 108, or added to a digital television multiplex signal as a dedicated data channel. Those skilled in the art will readily appreciate that any mechanism capable of transmitting digital information may be used to transmit the slices of the television viewing object database.
The first step in preparing a television viewing object for transmission is identifying the transmission mechanism to be used for this particular instance and creating a slice of a subset of the database tailored to that mechanism. For example, the database may contain television viewing objects related to all programs in the home country. However, if television viewing objects are to be transmitted using VBI modulation on a local television signal, only those television viewing objects that are related to programs viewable within the coverage area being used to perform their television broadcast should be contained within this relevant slice. Alternatively, if some of the television viewing objects contain promotional material related to a particular geographic region, then those objects should not be transmitted to other geographic regions.
In a preferred embodiment of the invention, the speed and periodicity of traversing the database and generating slices for transmission may be adjusted in any manner to allow for a useful cost/performance tradeoff to be made. For example, slices for a particular transmission method may only need to be created every other day or every hour.
The final step in preparing each slice is to encrypt the slice using a short-term symmetric key. Only client devices that have been authenticated using the security protocol will have a copy of this symmetric key, enabling them to decrypt the slice and access the television viewing objects within the slice.
2. Once the slice is complete, it is copied to a point 110 where the transport mechanism can acquire and send data. For a telephony connection, the slice is placed on the telephony server 111, where each client is provided with data when the telephony server calls in. If television broadcasting is used, the slice is copied to a device residing simultaneously with the station television transmitter, from where it is modulated onto the signal. In these and similar broadcast-oriented examples, the slices are "looped," i.e., the data describing the slices continues to repeat until a new slice is provided for transmission.
Repeated broadcasting of slices is required because it is not guaranteed that the data-bearing signal will reliably reach each client. The client device may be powered down or there may be interference with signal reception. In order to make it highly likely that the transmitted slices will be received correctly at all client devices, they are continuously broadcast repeatedly until updated slices are available for transmission.
A preferred embodiment of the present invention uses a broadcast mechanism, such as a television signal, to transmit the slices. However, it is desirable to provide for downloading over a connection-based mechanism, such as a modem or internet connection. Using a connection-based mechanism often results in a time-based usage fee, making it desirable to minimize the time taken to transmit a slice.
This is achieved using a two-step procedure. When a connection is established, the client system sends a list of previously received slices (inventory) to the telephony server 111. The server compares this list with a list of slices that should have been processed by the client. Unprocessed slices are transmitted to the client system.
3. The encrypted slice is transmitted by dividing it into a series of short-numbered packets. These packets are captured by the client system and remain in the staging area until all packets in the sequence are present. The packets are reassembled into slices, which are then decrypted. The television viewing objects within the slices are then filtered for applicability, where the television viewing objects may be being added to a local television viewing object database. This program reliably copies portions of the central database of television viewing objects to the client.
The present invention tracks the time at which a data packet is received. Periodically purging packets from the staging area for longer than a selected period of time; this avoids consuming space for an infinite period of time while waiting for all portions of a slice to be transmitted.
Various types of errors may occur in the transmitted data, particularly when the object is transmitted over a broadcast medium. Each packet is imprinted with an error detection code (e.g., a parity field or CRC code). When an error is detected, only the packet is discarded. The round robin broadcast will eventually retransmit the data packet that may be correctly received. In this way, slices of any size can be reliably transmitted; this is done at the cost of staging (stage) the received object parts on the client until all parts are received correctly.
4. There may be one or more "special" slices transmitted that convey service-related data to the client system, particularly service authorization information. Importantly, the service provider can control access to value added services (premium services) by the client system if the viewer is not paying for it or for other operational reasons.
One particular type of specific slice contains "authorization" objects. The authorization object is typically encrypted using an asymmetric key based on a public/private key pair associated with a particular client. If the secure microprocessor successfully decrypts the slice using the embedded private key, the slice will contain an object that represents the allowed time delay before receiving another authorized object and one or more symmetric keys that are valid for a short period of time. The delay value is used to set a timestamp in the database indicating when the client system will stop providing service. The symmetric key is stored in a local television viewing object database for decrypting new slices that may be received.
If the client does not receive the correct authorization object by the time set in the database, it will start to deny most of the services to the viewer (as specified by the service provider). Also contained within the authorization object are one or more limited-lifetime download keys that are used to decrypt the transmitted slices. Clearly, if the client system is unable to authenticate itself, it will not be able to decrypt any objects.
Each authorization slice is generated and transmitted separately. If broadcast transmission is used for a slice, all relevant grants are processed as all other slices and are transmitted cyclically with all other data. If direct transmission is used, e.g., via a telephone connection or the like, only the authorization slice for that client is transmitted.
5. Once the client device has received the complete database slice, it adds the new objects contained therein to the database using the methods described previously.
Collecting information from client systems
Referring again to FIG. 1, in a preferred embodiment of the present invention, the following steps constitute "collecting" of television viewing objects from each client database:
1. as the viewer navigates through the television channels available to him, the client system records information of interest, such as the channel tuned to, the tuning time, the dwell time, VCR-like actions (e.g., pause, rewind), and other information of interest. These data are stored in the local television viewing object.
In addition, the viewer may indicate an interest in available sales or promotions, or he may indicate a desire to purchase the product. This information is also recorded into the local television viewing object.
In addition, the operation of the client device may generate important data that should be recorded into the television viewing object. For example, an error may occur when reading from a hard disk drive in a client, or the internal temperature of the device may exceed an operating parameter. Other similar types of information may not download objects correctly, exhaust space for multiple disk-based operations, or accelerate power consumption.
2. At some point, which may be immediate or periodic, the client system contacts the central site via a direct connection 104 (typically via a telephone and/or internet connection). The client device sends a sequence of bit groups identifying itself encrypted with its secret key. The server retrieves the matching television viewing object for the client device from the database and decrypts the sequence of bytes using the key stored in the database. At the same time, the server sends the client a sequence of bytes encrypted by the client's secret key, giving the client a new one-time key for the session.
In order to communicate, both parties must successfully decrypt their authorization messages. This two-way handshake (handshake) is important because it ensures that the other party is valid for both the client and the server. Such authorization is necessary to avoid various attacks that may occur on the client system. For example, if communications are not authenticated in this manner, a malicious party may create an "alias" hub site with a corrupted (corrupt) television viewing object database and provide bad information to the client system, causing incorrect operation. All further communications are encrypted using the one-time session key. Encrypted communication is necessary because information can pass through a network, such as the internet, where data traffic is subject to inspection by all devices it passes through. The viewing objects being collected may contain information that is considered private, so this information must always be fully protected.
Assuming the authorization phase is successful, both parties treat the full duplex telephone line as two unidirectional broadcast channels. The new slice is transmitted to the client and viewing data to be collected is sent back. The connection ends when all data is transferred.
Those skilled in the art will readily appreciate that the connection may be made through a network that is transparent to all other software in the system, such as the internet running standard TCP/IP protocols.
3. Uploaded information is similarly processed by the server; the uploaded information is assumed to represent television viewing objects to be copied to the central database. However, when there are many clients of the service, there may be many uploaded viewing objects. Thus, the uploaded object is assigned a navigation attribute containing its resource information; the objects are then uniquely indexed into the database namespace as they are added.
Uploaded viewing objects are not immediately added to the central database; instead, they are queued for later insertion into the database. This step allows the queue to process a connection pattern independent of the client device. For example, many devices may connect at once, producing a large number of objects. If these objects are added to the central database immediately, the performance of all connections suffers and the connection time will increase. Telephone calls are charged on a duration basis so that any system in which the connection time increases as a function of loading is unacceptable.
Another advantage of this separation is that it is susceptible to machine or network failures. Further, by changing the computer system and its configuration to meet cost or performance goals, the speed at which viewing objects are processed and added to the central database may be controlled by the server provider.
Yet another advantage of this separation is that it provides a mechanism for separating data collected to improve service operation from data that might identify an individual viewer. Importantly, such authentication data is not kept publicly for legal reasons or to improve an individual's trust in the service. For example, the navigation attributes assigned to viewing objects containing records of viewer viewing choices may contain only the viewer's zip, meaning that further processing of these objects cannot construct a path back to an individual identity.
Periodic tasks are invoked on the server to pick these objects from the database and remove them as appropriate. For example, objects representing viewer behavior aggregate into an overall viewer behavior model, and information that may identify individual viewers is discarded. The object containing the operational information is forwarded to an analysis task, which may alert customer service personnel to potential problems. The object containing the transaction information is forwarded to the transaction or business system to be completed.
Any of these activities may result in new television viewing objects being added to the central database or existing objects being updated. These objects will eventually be transmitted to the client device. Thus, the television viewing management system forms a closed loop, creating a self-maintaining replicated database system 105 that can support any number of client systems.
Client system processing of television viewing objects
A television viewing object may contain the following types of information: television program description and show time; a cable; satellite or broadcast signal originator information such as channel number and identification; viewer preference information such as actors, genre, show time, etc.; software, such as enhanced database software, application software, operating system software, and the like; statistical modeling information such as preference vectors, demographic analysis, etc.; and any other arbitrary information that can be represented as digital data.
Method applied to program guide object
The program guide object contains all the information necessary for the software running in the client system to tune, receive, record, and view programs of interest to the user of the client system, selected from all available programs and channels as described by the object in the database.
The program guide information is regularly updated by the service provider. This is handled by the provider obtaining program guide information in some manner (e.g., obtained from a commercial supplier of such information or other broadcast schedule information source). This data is then processed using well understood software techniques to reduce the information to a collection of related viewing objects.
Referring again to fig. 4, exemplary relationships between program guide objects are shown. The television "network" object 407 is any entity that schedules and broadcasts television programming, whether broadcast over the air, cable, satellite, or other suitable medium. The television "program" object 401 is used to describe any of the various segments of a television broadcast signal, such as a particular program, commercial, station promotion, opening, trailer, or any other bounded portion of a television signal. The "show" object 406 is part of the broadcast schedule for the network on which the program is broadcast. The "channel map" object maps network broadcasts onto a particular broadcast channel of the medium being used; for example, a channel map object for a satellite broadcast service includes information about transponders and a data stream containing broadcasts. This program guide data is copied from the central site to the client system using the method described previously, where application software in the client system uses the data to manage television viewing.
The service provider may also provide an aggregate viewing object that describes a set of program guide objects that are related in some fashion. For example, the "Star-Trek" collection may contain references to all program guide objects related to this brand name. Obviously, arbitrary groups of programs can be aggregated in this form. The aggregate object is analogous to a directory. For example, the Star Trek set may be found at "/showcases/Star Trek" in the hierarchical namespace. Aggregate objects are also program guide objects and may be manipulated in a similar fashion, including aggregate objects and the like.
The client system may further redefine the set of program objects. In a system where programming can be captured to internal storage, each captured program is represented by a new program guide object, made available for viewing, aggregation, etc. Explicit viewer behavior may also result in the creation of program guide objects. For example, the viewer may select several programs and cause a new aggregate object to be created.
The description of program-oriented object types is not meant to be limiting; many different uses and ways of generating program guide objects not described herein are possible in accordance with the basic methodology of the present invention.
Program guide objects are used by application software in five ways:
1. in the simplest case, the viewer may wish to browse through these objects to learn about the programming currently or soon to be available. The application maps the object relationships described by the database to some form of audiovisual interface that is convenient for the viewer to use. The viewer may indicate an interest in a particular program, making some application specific action, such as recording the program to local storage as it is broadcast.
2. The application software may also directly process the program guide object to select programs that may be of interest to the viewer. This procedure typically generates a priority order for all available programs based on an analysis of previously viewed programming combined with a statistical model. The highest priority program may be processed in an application specific manner, such as recording the program to local storage as it is broadcast. In case 1, the portion of the priority order thus generated may be presented to the viewer as an additional option.
Those skilled in the art will readily appreciate that there is a great deal of prior art focused on methods for selecting programming for a viewer based on previous viewing history and explicit preferences, such as U.S. patent No. 5,758,257. The methods described in this application are unique and novel with respect to these techniques because they suggest capturing the priority of programming rather than the broadcast or transmission of programming, and there is no time limit to when programming may be broadcast. Further details of these methods will be described later.
Generally, the viewer's explicit selection of programming has the highest capture priority, followed by selection of programming using the preference techniques described herein.
3. The client system will have a small number of inputs that can receive television broadcasts or access web pages over a network such as an intranet or the internet. The scheduling method is used to select how each input is tuned and processed on the resulting captured television signal or web page.
Referring to fig. 6, generally, programs of interest to the viewer may be broadcast at any time, on any channel, as described by the program guide object. In addition, the program of interest may be a Universal Resource Locator (URL) for a web page across a network, such as an intranet or the Internet. The channel metaphor is also used to describe the location or URL of a particular web site or page.
For example, by specifying a web site URL as a channel, the viewer can "tune" into the web site. Whenever the channel is selected, the web address is displayed. The web page may also be designated as a program of interest and a snapshot of the web page may be taken and recorded at a predetermined time.
The scheduler (schedule) accepts as input a prioritized list of program viewing preferences 603 that may be generated as per the above scenario. The scheduling method 601 then compares this list to a database of program guide objects 604 that indicate when the program of interest is actually broadcast. It then generates a schedule of times 607 versus available storage space 606 that is optimal for the viewer's explicit or derived preferred programs. A description of further details of these methods is given later.
4. When viewing a captured program, the matching program guide object is used to provide additional information about the program, which is overlaid on the display screen using any suitable technique, preferably some form of On Screen Display (OSD). Such information may include, but is not limited to: a program name; time, channel or network of the original broadcast; a cut-off time; running time or other information.
5. When viewing real-time programming, the application uses the current time, channel, and channel map to find a matching program guide object. Information from this object is displayed using any suitable technique described above. This information is automatically displayed upon resumption of the program after a commercial break, upon viewer demand, or upon other conditions as the viewer changes channels, at the beginning of a new program.
6. Using techniques similar to those described in case 2, the application software may also capture promotional material that may be of interest to the viewer. This information may be presented as desired by the viewer or automatically inserted into the output television signal at some convenient point. For example, advertisements in a broadcast program may be replaced with different advertisements having higher preference priorities. Using Time anomaly devices such as the device entitled "Multimedia Time warping system" described in U.S. patent No. 6,233,389 filed on 30/7/1998, it is possible to insert any stored program into the output television signal at any point. The time warping device allows for delaying the programs being overwritten during the insertion of the stored programs to do so.
Method for generating a preferred program list
Viewer preferences may be obtained in a variety of ways. The viewer may request that certain programs be captured, which gives those programs the highest possible priority. Alternatively, the viewer may explicitly express preferences using an adjunct provided through the viewer interface, perhaps in response to promotional breaks for a particular program, or even during viewing of the program. Finally, preferences may be deduced from the viewing patterns (programs viewed, commercials viewed or skipped, etc.).
In each case, this preference must correspond to the television viewing object stored in the replicated database. The program object includes much information about each specific program, such as: title, producer, director, actors, rating, etc. These elements are stored as attributes associated with the program object.
Each individual attribute may result in the generation of a preference object. Such objects store the following information:
1. types of preference items, such as actor or director preferences;
2. the preference weight (weight) given by the viewer, which may be expressed in terms of a number of buttons or other means;
3. statically assigned importance of preferences with respect to other preferences, e.g., actor preferences are more important than director preferences;
4. the actual value of the preference item, e.g. the director's name.
Referring to fig. 5, the preference objects are stored in the database as a hierarchy (hierarchy) similar to the hierarchy describing program guide objects, however, this hierarchy 500 is constructed incrementally as the preference is expressed. The hierarchy thus constructed is based on "direct" preferences, e.g., derived from viewer actions or inferred preferences.
Similar hierarchies are developed based on "indirect" preferences 501 that point to the same preference object. In general, indirect preferences are generated when generating preferences for aggregated objects, and are used to further weight direct preferences implied by the set of aggregated objects. Preference objects referenced by indirect preference hierarchies are generated or updated by enumerating available program objects as part of the aggregate object 502 and generating or updating preference objects for each attribute so found.
The weighting of a particular preference 503 begins with zero and then adds a standard value based on the preference expressed (or by multiple buttons) or subtracts the standard value if the expression is not of interest. If a preference is expressed based on the aggregated viewing objects, all preferences generated by all viewing objects belonging to the aggregated objects are similarly weighted. Thus, a new weighting of the relevant preference element is generated from the previous weighting. This procedure is limited by the preference that is allowed to be expressed so that all weights fall within a bounded range.
In a preferred embodiment of the present invention, a non-linear combination may be used to weight the favorites. For example, using a statistical model provided by the central site, the client can deduce that a heavily weighted preference for the associated three attributes indicates that the fourth attribute should also be heavily weighted.
The list of preferred programs is generated as follows:
1. a table 504 is constructed listing the attributes of each possible program object and any preference objects for that attribute that exist are listed in the entry.
2. If the preference item is a string, such as an actor's name, a 32-bit digital signature for the string is calculated using a 32-bit CRC algorithm and stored with the table item rather than the string itself. This allows for much faster scanning of the table because string comparisons are avoided, but there is a slight risk that two different strings will produce the same digital signature.
3. For each program object in the database, and for each attribute of the program, the attribute is looked up in the table. If so, the list of preference objects for the attribute is checked for a match with the attribute of the current program object. If there is a match, the weight associated with the preference object is added to the weight associated with the program object to produce a single weight for the program.
4. Finally, the program objects are ranked according to the total weight for each program, forming a list of most preferred versus least preferred programs.
Given this final priority list, a recording schedule is generated using the method described above, forming a collection of recorded programs of most interest to the viewer.
Method for arranging recording to available storage space
As already described above, generally, the recorded program will have an expiration date after which the recorded program is removed from the client memory. The viewer may indicate at any time that a program should be saved longer, which delays the expiration date by the interval selected by the viewer. The present invention treats the available memory for recording programs as a "cache"; according to such assumptions: if a program is not watched soon after recording it will be assumed not to be watched and the unviewed program is removed after a period of time. The viewed program becomes an intermediate candidate for deletion, assuming that the viewed program is no longer of interest.
Properly scheduling the recording and deletion of old programs may make the smaller storage area look much larger because old programs are continually removed and new programs are continually added. Additionally, if resources are available, the recording of the program may be scheduled according to the derived preferences of the viewer; this is called "fuzzy" recording. This forms a system where the program storage area is always "full" of programming of interest to the viewer; the program is not removed until another program is recorded in the location of the program or the program is explicitly deleted by the viewer.
In addition, the viewer may select a recorded program at any time, but the recording window may conflict with other scheduled recordings or not get enough space when the program must be recorded. The present invention includes a unique and novel approach to resolving such conflicts.
Conflicts can arise for two reasons: lack of storage space, or lack of input resources. The television viewing system described herein includes a fixed number of input resources for recording video and a storage medium, such as a disk, having a limited capacity for storing recorded video. It is not possible to record all television program broadcasts during any significant period of time. Therefore, resolving conflicts due to resource limitations is critical to making the correct program available for viewing.
Referring again to fig. 6, the present invention maintains two schedules: a spatial schedule 601 and an input schedule 602. The spatial schedule keeps track of all currently recorded programs and those programs that have been scheduled for future recording. By creating a sum of all the space occupied (or space that will be occupied at the time) and subtracting that sum from the total capacity available to store the program, the amount of space available at any given time can be found. Programs scheduled for recording based on derived preferences ("fuzzy" recording) are not considered in this calculation; such programs automatically lose all conflicting decisions.
The program may be recorded 603 if there is sufficient space available to hold the program at any time between the start of recording and the expiration of the program. Furthermore, for the duration of the program, there must be an input available from which to record the program. The input schedule 602 tracks the free and occupied slots of each input resource. In a preferred embodiment of the invention, the input resources are not used for the same service, e.g. one input may be from a digital television signal and the other input may be from an analog television signal with a different programming. In this case, only those inputs from which a desired program can be recorded are considered during scheduling.
Referring to FIG. 7, a flowchart is shown depicting the steps taken in scheduling a recording in a preferred embodiment. First, an ordered list of shows of interest 701 is generated. Although a preferred embodiment of the present invention orders the shows according to time so that recording is performed as quickly as possible, any particular ordering may be selected. Each show 702 in this list is then checked to see if a conflict occurs with the input 703 or space 704 as described above. If no conflict is found with the showing, the program is scheduled to be recorded 705.
Otherwise, a preferred embodiment of the present invention selects only shows 706 for those programs for which there is no input conflict. Referring again to fig. 6, it can be seen that the amount of available space will change as other programs are recorded or expire during the lifetime of the recording. The presentation list is then preferably sorted by the minimum amount of space available over the life of the candidate record. Other orderings may also be selected.
Referring again to fig. 7, for each candidate show, the viewer is presented with a choice 708, 709 to shorten the expiration date on the conflicting program. This ordering causes the selections to be presented to viewer 707 in an order from least impact to maximum impact on the scheduled program; the use of this ordering as opposed to any other ordering is not a requirement of the invention.
If the viewer declines all opportunities to shorten the deadline, the final step includes selecting those shows with input conflicts 710 and sorting the shows 711 as in the first conflict resolution method stage. The viewer is then presented with a selection 712, 713 of each previously scheduled recording that supports the desired program cancellation. Of course, the viewer may ultimately decide not to record any new programs 714.
In a preferred embodiment of the invention, all conflicts are resolved as early as possible, giving the viewer greater control over what is recorded. The algorithm described in fig. 7 is used to schedule recordings and manage any conflicts that arise when the viewer explicitly selects a program to be recorded.
Once an explicit selection has been made and the viewer is informed that the recording will be completed, it will not be cancelled without explicit consent of the viewer.
The fuzzy record is scheduled periodically with a background task on the client device. Given the priority list of preferred programs described above, the background scheduler attempts to schedule each preferred program in turn until the list is exhausted, or no further recording opportunities are available. A preferred program is scheduled if and only if there is no conflict with other scheduled programs. The preferred program that has been scheduled can be deleted under two conditions: firstly if it conflicts with an explicit selection and secondly if the change in viewer preferences determines a program with a higher priority that can be recorded at the time.
Another complication arises in dealing with aggregated viewing objects that require recording. If conflict resolutions are processed according to the methods described above for the objects, a potentially large number of conflicts may result, causing confusion and frustration in the experience of the viewer in resolving such conflicts. Thus, when an aggregate object is selected for recording, conflicts are automatically resolved to support the existing schedule using the (in vivo of) existing schedule.
In a preferred embodiment of the invention, conflicts caused by recording aggregate objects will be resolved using preference weighting of the programs involved; if a particular program in the aggregate object causes multiple conflicts, it is only recorded if its preference outweighs the preferences of all conflicting programs.
Method applied to software object
Client systems require complex software environments for proper operation. The operating system manages the interaction between hardware devices in the client and the software applications that manipulate those devices. The television viewing object database is managed by different software applications. A time-anomalous software application is another application.
It is desirable to add new features or correct bugs in these and other software subsystems running on the client hardware devices. Using the methods described herein, it is possible to copy viewing objects containing updated software modules into the client system database. Once present in the client system database, the following unique and novel methods are used to install the updated software and to cause the client system to begin executing the new software.
The software environment of the device is instantiated in a sequence of steps where power is first applied to the device, each step establishing state information that supports proper application of the next step. The final step starts the application that manages the device and interacts with the viewer. The steps are as follows:
1. a read-only or electrically programmable memory in the device holds an initial sequence of boot program instructions. These instructions initialize the low-level parameters of the client device, initialize the disk storage system, and load the boot loader from disk into memory, followed by execution transfer to the memory. The initial boot program may be changed if it resides in an electrically programmable memory.
2. The secondary boot loader then locates the operating system on the disk drive, loads the operating system into memory, and passes execution to the operating system. The loader must exist at a particular location on the disk in order to be easily located by the initial loader.
The operating system performs the necessary hardware and software initialization. It then loads the viewing object database software from the disk drive and begins executing the application software. Other applications, such as time exception software and viewer interaction software, may also be loaded and started. The software is often located on disk in a separate area from the object database or captured television program.
Ideally, the new software is installed simply by copying it to the appropriate location on the disk drive and rebooting the device. This operation is fraught with danger, particularly in the home environment. Power failures can occur during copying of the software, resulting in inconsistent software images and potential operational problems. This new software may have drawbacks that prevent proper operation. A failure may occur on the disk drive, corrupting (corrupt) the software image.
Although the method of the present invention has been described with reference to a disk drive, those skilled in the art will readily appreciate that the method described herein applies generally to any persistent memory system. Disk drives and other persistent storage systems are typically formatted into a sequence of blocks of fixed size, called sectors. A "partition" is a contiguous, non-overlapping subset of this sequence that divides the memory into logically separate regions.
Referring to FIG. 8, the present invention maintains a sector of information in a fixed location on the disk drive 803, referred to as the "boot sector" 804. The boot sector 804 contains sufficient information for the initial boot program 801 to understand the partitioning of the drive 803, and to locate the secondary boot loader 806.
The disk is divided into at least seven (7) partitions. There are two (2) mini-partitions dedicated to holding a copy of secondary boot loader 806, two (2) partitions holding a copy of operating system kernel 807, two (2) partitions containing a copy of application software 808, and one partition used as temporary memory 809. For the copied partition, an indication is recorded in the boot sector 805 with one partition marked as "primary" and the second partition marked as "spare".
Those skilled in the art will readily appreciate that while two partitions are described herein for redundancy (redundancy), triple, quadruple, or more times redundancy may be achieved by creating more duplicate partitions.
Referring to FIGS. 9a and 9b, on boot 901, the initial boot code reads boot sector 902, scans the partition table, and locates the "primary" partition for the secondary boot loader. It then attempts to load the program into memory 903. If it fails 904, e.g., due to a disk drive failure, the boot loader attempts to load 905 the program in the "spare" partition into memory. Whichever attempt is successful, the boot loader then passes control and an indication of the loader from that partition to the newly loaded program 906.
Similarly, the secondary boot loader reads the partition table and locates the "master" operating system kernel 907. If core 908 cannot be loaded, then "standby" core 909 is loaded instead. In any event, control is passed to the operating system 910 along with an indication of the resource partition and the resource partition from being passed as described above.
Eventually, the operating system locates the "master" partition containing the application software and attempts to load the initial application 911. If there is a failure 912, the operating system locates the "spare" partition and loads the initial application from it 913. The indication of the resource partition is passed to the initial application along with the resource partition information from the previous step. At this point, the application replaces the (take over) client system and normal view management behavior is initiated 914.
This sequence of operations provides a reasonable level of protection against disk access errors. New software at any of these levels is also made to be installed and reliably started to function.
An "installer" in the object database views the object for recording the status of the software installation attempt. It records the partition status for each of the three levels described above, including an indication 915 that an attempt to install new software is in progress. This operation is reliable due to the transactional nature of the database.
Referring to FIG. 10, the process of installing a new software image at any of the three levels is as follows: the new software image is first copied 1001 into the appropriate spare partition and then indicated in the database that the software installation is in progress 1002. The primary and standby partition indications 1003 in the partition table are then exchanged, and the system is restarted 1004. Finally, control is passed to the initial application.
Referring again to FIG. 9b, the first task of the application is to update the installer object. For each level 921, 922, the application checks if an installation is in progress 916, 917, and verifies that the level is not unloaded from the primary partition 918. If so, the installation at this level is successful and the installer object is updated to indicate that the level was successful 919. Otherwise, the application copies the backup partition of the level to the primary partition and indicates that the installer object of the level failed 920. Copying the partition ensures that a backup copy of known good software for a level remains available at all times.
In a preferred embodiment of the present invention, the completion of the highest application level of the installed software may be delayed until all parts of the application environment have been successfully loaded and started. This provides an additional level of assurance that all parts of the application environment are working properly before switching permanently to new software.
Method applied to operation state object
An operational state object is a type of viewing object in which information about usage, performance and behavior of the client system is recorded. These objects are collected by the central site as long as communication with the central site is established.
For later collection, the following operational status indicators (indicators) and timestamps are recorded:
1. the viewer actions are recorded, mainly buttons on the remote control. Each press of the "button" is recorded along with the current time, and any other contextual information such as the current viewer context. Post-processing of this object at the central site results in a complete tracking of the viewer's actions, including the context in which each action is performed.
2. Recording automatic actions such as the beginning or end of a program recording, or selecting a program to record according to viewer preferences. In addition, the deletion of the captured program is recorded. Post-processing of this object at the central site results in a complete tracking of program capture actions by the client system, including programs at any point in time that resides in persistent storage.
3. Software installation actions are recorded, including results after receipt, installation, and reboot.
4. Various types of hardware exceptions, including but not limited to: power failure/reboot, internal temperature profile of the device, persistent memory access error, memory parity error, and main partition failure.
Since all actions are recorded with the time stamps, it is possible to reconstruct the behavior of the client system using linear time-based ordering. This allows manual or automatic methods to work on an ordered list of events, correlating actions and behaviors. For example, if the desired automatic action does not occur shortly after a reboot with the new software, it can be deduced that the new software is defective.
Processing of television viewing objects by a central site system
Television viewing object resources
The client system has a single television viewing object resource: a central site. The central site object database has a number of television viewing object resources:
1. program guide information obtained from an external source is processed to produce a consistent set of program guide objects, representing "programs," "shows," "channels," "networks," and other related objects. This set of objects will have dependencies ("channels" dependent on "network", "shows" dependent on "program") and other interrelations. When a complete consistent set of objects is ready, it is added to the database as an atomic operation.
2. The new software is first encapsulated into a "software" viewing object, where the new software includes new applications or revisions to existing software. As above, the software may have interdependencies, e.g., applications rely on dynamically loaded libraries, which must be reflected in the interrelationships of the software objects involved. In another example, there are two types of client systems in use, each of which requires a different software object; these software objects must present attributes that indicate the type of system they are aligned to. Once a consistent set of objects is available, it is added to the database as an atomic operation.
3. Each client system has a unique secret key embedded therein. The public key that matches this secret key, as well as other information of interest about the client (e.g., client type, amount of storage in the system, etc.) is loaded into the "client" management object. These objects are used to generate authorization objects when necessary.
4. Aggregate program guide objects are added in a similar manner. In this case, however, the aggregate program guide object must refer to the original program guide object already present in the database. Other objects such as text descriptions, screen-based icons, and other informational attributes are also associated with the aggregate object. Once a consistent set of auxiliary objects for the aggregate object is available, it may be added to the database as an atomic operation.
5. Data collected from client systems
It is clear that there may be any number of viewing object assets, and this listing shows only the most basic assets possible.
Operations on television viewing objects
There are a large number of possible operations on the central television viewing object database. The following examples are used to illustrate the types of processing that may be performed, however, the potential operations are not limited to these examples:
1. using various viewing objects, a number of interesting statistical analysis tasks can be performed:
1.1. by examining a large number of uploaded operational state objects, it is possible to perform extensive analysis of hardware reliability trends and failure modes. For example, the internal temperature may be correlated to the MTBF (mean time between failures) of the desired client device.
1.2. By examining the heavily uploaded viewing information, it is possible to derive demographic or psychographic information about various groups (population) of client devices. For example, the most frequently viewed TV programs in a particular zip zone in which a client device resides may be correlated.
1.3. Similarly, by examining a large number of viewing information objects, it is possible to generate "ratings" and "share" values for a particular program using a fully automated approach (unlike existing program rating approaches).
1.4. There may be other instances of statistical analysis tasks that may be performed on the viewing object database; these examples are not meant to limit the applicability of the invention, but rather to illustrate the scope of operations that may be performed by the examples.
2. A property (behavior) aggregate object may be automatically generated based on one or more attributes of all available viewing objects.
Such generation is typically performed by first extracting information of interest (e.g., program description, actors, director, etc.) from each viewing object, and then constructing program and attribute profiles (feature aggregation objects). An aggregate viewing object is then generated by selecting one or more attributes and adding the aggregate to programs for which the selected attributes match in some manner.
These objects are then included in the slice generated for transmission, possibly based on geographic or other information. Some example aggregates that may be created are:
2.1. based on an aggregation of events, such as a general union football match in a large city. In this case, all programs available for viewing by client devices in or around the city are collected, and then the programs describe the search team's name, coach name, leading player name, court name, etc. Matching program objects are added to the aggregate, which is then sliced for transmission only to client devices in the city or in areas near the city.
2.2. Based on the aggregation of a large number of people of general interest to the viewer. For example, the aggregate may consist of all "John Wayne" movies broadcast in the next week.
2.3. An aggregation based on viewing behavior may be generated. In this case, uploaded viewing objects are scanned for elements of general interest (e.g., type of program viewed, actual program viewed, etc.). For example, a "top ten list" aggregation of the programs watched on all client devices in the past week may be generated, including the next week showing of those programs.
2.4. Based on the viewer explicitly selected aggregation. During viewing of a program, the viewer may be presented with an opportunity to "vote" on the current program, perhaps according to four understood (perceived) attributes (story line, technique, director, cinematography), which voting opportunity results in viewing objects that are uploaded later. These votes are then scanned to determine a total rating for the program, which is transmitted to the person for whom the vote was perused.
2.5. There are many other examples of how the basic apparatus of the present invention allows a service operator to provide pre-ordered and pre-selected sets of related programs for perusal and selection by a user of a client device. These examples are not meant to limit the applicability of the invention, but merely to illustrate the range of operations that may be performed.
3. Aggregate objects may also be generated using manual methods, a procedure sometimes referred to as "editing". In this case, the person creating the aggregate selects a program to explicitly add to the aggregate. The aggregate is then transmitted in the same manner as described above.
Obviously, aggregating program objects may also allow for the expression of preferences or the recording of other information. These results may be uploaded to a central site to form the basis for the next round of aggregate generation or statistical analysis, etc.
This feedback loop closes the line between the service provider and the audience using the client device as a whole. This unique and novel approach provides a new form of television viewing by providing service providers with a unique and compelling way to present and promote the viewing of television programs of interest while maintaining reliable and consistent operation of the service.
Remote client system control
Many household appliances already have mass storage and are becoming more and more. The amount of available storage in these appliances has been staggering, but the end of the "doubling every year" rule of thumb of disk drives is not seen. Each year, the storage capacity of other types of storage media is also becoming larger, including: CompactFlash, SmartMedia, Zip, FlashMemory Sticks, Microdrive, Pocketdrive, and SuperDisk.
By the user storing his own TV programs, music, pictures etc. an obvious control of the memory is achieved. A less obvious use, but with continued growth in applicability and importance, is the control of this memory by service providers. There is an increasing desire by service providers to control the memory physically owned by the viewer.
Referring to fig. 11, the distributed/telephony server 1101 of the present invention has the capability to send objects to the client systems 1103, 1104, 1105 instructing the client systems to perform a function such as recording a particular program from the broadcaster 1102 or capturing content that the server instructs the client systems to capture. In addition to the aspects of client system maintenance and control, each function that a user can control is also contained in a set of objects called capture requests.
The client systems 1103, 1104, 1105 have the capability to capture and record any type of multimedia material (TV programs, movies, advertisements, product and service offerings, music, radio, audio, electronic books, etc.) transmitted over a broadcast or communication link.
An individual or group that captures the requested object is sent from the distributed/telephony server 1101 to the client systems 1103, 1104, 1105. The following are some examples of capabilities to capture requests (powers):
● the capture request allows the server of the present invention to schedule recordings on the client system. These recordings may be for video or data content.
● captures a request to specify recording using the program name and optionally an Affiliate (Affiliate) name (e.g., NBC). The designated simulcast station limits recording to the designated simulcast station. If the program is shown on another simulcast station, it is not recorded.
● the capture request has the ability to schedule a single recording or schedule all of a series of presentations.
● Capture requests have the ability to set the properties of the record being formed:
● record the disk location-if the recording would take up the user's disk space on the client system or the client system's hidden space on the disk (storage device).
● record tuner priorities-whether these recordings will cause other programs to be unrecorded due to tuner conflicts (on client systems with multiple input tuners).
● record save time-the recommended minimum time that a record should remain on the client system's disk before other records should delete it.
● recording quality-the recording quality of the recording, e.g., low, good, high, best.
● the capture request has the ability to create a season card for the program sequence. The season card should record each showing of a program on a designated channel.
● the capture request may specify an expiration date. This date is used to determine the date on which recordings are not scheduled thereafter. And after the deadline, the capture request is removed from the client system's disk.
● the server of the present invention has the ability to modify a capture request and the client system will reschedule all records from the previous capture request with the new choice.
● the server of the present invention has the ability to target specific client systems to accept specific capture requests. This allows the present invention to schedule records on a subset of all client systems.
Referring to FIG. 12, the mechanism and program for remotely controlling storage on a client system may be divided by function into three parts:
● front-end server 1201: this section creates a capture request using the editing tool, previews the capture request and distributes it to the client device 1205. At the same time, this section determines how the client memory is allocated (partitioned), and it is possible to edit the client memory and change over time. The policy of how to use the memory is compiled at the front end.
● client system 1205: the client system 1205 is responsible for executing the storage partitions as directed by the server, capturing the media or objects for each capture request, and executing the rotation and expiration mechanisms. The client itself does not maintain policies on how to use the memory; it only implements the general mechanism and the policy is given by the server 1201.
● backend server 1206: the client system 1205 may communicate the success or failure of the request reporting server 1201, how to use the received data/media, or even send back data/media (e.g., pictures, videos, music sharing services) redistributed via the distributed servers 1202, 1203, 1204.
Transparent "pull" that looks and feels like a "push"
To the client system 1205, this appears as the server "pulls" down the content (data, media, whatever). In effect, the server merely instructs the client device to push the content, or to capture it. This is transparent to the user of client system 1205.
Remote editing of capture requests
The user of the client system 1205 desires full control over the content stored on the client system 1205, for example, telling the client system 1205 what content to capture and when to capture content, when to delete content, and the like. The capture request mechanism provides peer control of the remote editor.
The editing tool 1201 allows an editor (author) to create a capture request object. The schema definition for this object specifies metadata:
● where to capture the data/media (in the form of a station/channel, URL, or any other indicator of available media).
● when to capture data/media (in the case of broadcast or multicast content).
● captures the priority of the request-how important it is for the client system to prioritize (preempt) over other activities in order to perform the request.
● priority of content-if local storage is not available, what other content should be removed in order to make room.
● presentation of content-how this content should be presented in the client system/user experience (rotation policy, display policy, expiration, view once/many times, eligible, etc.).
● client alignment-the request may include any number of rules that must be satisfied in order for the request to be valid. For example, the request may indicate "execute only on clients having these capabilities" or "execute only on clients that have made this content available. Any complex interrogation mechanism may be used to describe these capabilities.
Remote control of space allocation
In many cases, it is desirable to partition the memory on the client system so that some of the memory is under the full control of the user while some of the memory is under the full control of the server.
The present invention allows the server to change such partitions at any time. This is useful in allowing future changes to policies (e.g., returning some space to the user, or taking some away) or accounting (account for) new storage configurations (e.g., when new larger configurations or updates become available).
This mechanism allows an editor at the server to create a "partition table" that specifies how much storage should be allocated, depending on the size of the storage and the particular client configuration.
Controlling which client accepts which capture request
When a capture request is distributed via the servers 1202, 1203, 1204, the distributed server 1203 controls which client system receives the capture request.
The server-side tool allows the description to be made with serial numbers, with client capabilities, with client server layers, etc. A table is maintained that places each client device into one or more capture request groups. A given capture request is then assigned to one or more of these groups.
Mechanism separate from policy
Note that the overall system is designed to have the policy reside outside of the client system. All policies are determined by the editor or automatically by the server. The client system only performs the instructions or requests from the server.
Application of remotely controlled memory
Remotely controlling memory on a client system is useful in many applications, such as:
● promotion
● market place
● Multi-auditorium cinema
● music
● Picture
● video on demand
● software
● Game
● personal news, weather, sports …
Remote control memory diversity
The remote control memory may take many forms:
● disk drive for all storage media: although a hard disk drive is an obvious application for remotely controlling storage, other media are equally suitable. The music server may "push" promotional music onto the personal music device each time the personal music device is thermally synchronized.
● sometimes open very little once open: this mechanism is equally applicable to systems that are always connected to the server (e.g., with an always-on internet connection), client systems that are periodically connected to the server (e.g., connected overnight via a telephone line), and those that are rarely connected (e.g., when the PDA or camera is thermally synchronized).
The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention, and various modifications and changes may be made by those skilled in the art. Any modification, equivalent replacement, or improvement made within the spirit and principle of the present invention should be included in the scope of the claims of the present invention.

Claims (24)

1. A method for remotely controlling storage and operation of a client system, comprising the steps of:
forming a capture request on a server, the capture request being initialized by the server to instruct a client system to record a particular content;
sending the capture request from the server to one of a plurality of client systems;
wherein the capture request is received by a client system;
the capture request instructing the client system to record specific content from a television broadcast signal or a communication link;
autonomously monitoring, by the client system, the capture request and tuning to the television broadcast signal and recording the particular content on the client system or recording the particular content along a communication link on the client system; and
autonomously scheduling user initiated requested recordings and autonomously scheduling capture requested recordings using a local program guide through the client system and resolving recording conflicts.
2. The method of claim 1, wherein the capture request instructs the client system to schedule a time and a source of the recording of particular content.
3. The method of claim 1, wherein the particular content is video or data content.
4. The method of claim 1, wherein the capture request specifies the particular content using a program name and an optional affiliate name.
5. The method of claim 1, wherein the capture request schedules a single recording of a series of programs or schedules a full recording of a series of programs.
6. The method of claim 1, wherein the capture request sets recording tuner priority when the client system has multiple input tuners.
7. The method of claim 6, wherein the capture request specifies a recording quality setting for the recording.
8. The method of claim 1, wherein the capture request instructs the client system to create a season pass for a program series, and wherein a season pass records each showing of a program on a specified channel.
9. The method of claim 1, wherein the capture request specifies its expiration date.
10. The method of claim 1, wherein the server modifies a capture request that the client system has previously received.
11. The method of claim 1, wherein the server targets a particular client system to receive a particular capture request.
12. The method of claim 1, wherein the capture request specifies content to be transferred from the client system to a device connected to the client system.
13. An apparatus for remotely controlling storage and operation of a client system, comprising:
means for forming a capture request on a server, the capture request being initialized by the server to instruct a client system to record particular content;
means for sending the capture request from the server to one of a plurality of client systems;
wherein the capture request is received by a client system;
the capture request instructing the client system to record specific content from a television broadcast signal or a communication link;
recording means on said client system for autonomously monitoring said capture request and tuning to said television broadcast signal and recording said specific content on said client system or recording said specific content along a communication link on said client system; and
scheduling means on said client system for autonomously scheduling user initiated requested recordings and autonomously scheduling capture requested recordings, and resolving recording conflicts, using a local program guide.
14. The apparatus of claim 13, wherein the capture request instructs the client system to schedule a time and a source of the recording of particular content.
15. The apparatus of claim 13, wherein the particular content is video or data content.
16. The apparatus of claim 13, wherein the capture request specifies the particular content using a program name and an optional affiliate name.
17. The apparatus of claim 13, wherein the capture request schedules a single recording of a series of programs or schedules a full recording of a series of programs.
18. The apparatus of claim 13, wherein said capture request sets recording tuner priority when said client system has multiple input tuners.
19. The apparatus of claim 18, wherein the capture request specifies a recording quality setting for the recording.
20. The apparatus of claim 13, wherein the capture request instructs the client system to create a season pass for a program series, and wherein a season pass records each showing of a program on a specified channel.
21. The apparatus of claim 13, wherein the capture request specifies its expiration date.
22. The apparatus of claim 13, wherein the server modifies a capture request that the client system has previously received.
23. The apparatus of claim 13, wherein the server is directed to a particular client system to receive a special capture request.
24. The apparatus of claim 13, wherein the capture request specifies content to be transferred from the client system to a device connected to the client system.
HK10106481.1A 2003-01-08 2010-07-03 A system for remotely controlling client recording and storage behavior HK1140084B (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US10/339,700 US7543325B2 (en) 1999-03-30 2003-01-08 System for remotely controlling client recording and storage behavior
US10/339,700 2003-01-08

Publications (2)

Publication Number Publication Date
HK1140084A1 true HK1140084A1 (en) 2010-09-30
HK1140084B HK1140084B (en) 2011-12-30

Family

ID=

Also Published As

Publication number Publication date
US7543325B2 (en) 2009-06-02
US20130084058A1 (en) 2013-04-04
US20170085961A1 (en) 2017-03-23
WO2004063891A2 (en) 2004-07-29
CN100559851C (en) 2009-11-11
US20150319504A1 (en) 2015-11-05
EP1582057B1 (en) 2013-07-31
EP1582057A2 (en) 2005-10-05
US7779446B2 (en) 2010-08-17
EP1582057A4 (en) 2009-11-25
JP4465348B2 (en) 2010-05-19
US20110047579A1 (en) 2011-02-24
HK1089029A1 (en) 2006-11-17
WO2004063891A3 (en) 2005-03-24
US9414127B2 (en) 2016-08-09
JP2006516078A (en) 2006-06-15
CN101686368B (en) 2011-08-10
US8321901B2 (en) 2012-11-27
US20090178098A1 (en) 2009-07-09
US10306331B2 (en) 2019-05-28
CN1751506A (en) 2006-03-22
US20050050577A1 (en) 2005-03-03
CN101686368A (en) 2010-03-31
US9083941B2 (en) 2015-07-14
US20190253767A1 (en) 2019-08-15
US9516393B2 (en) 2016-12-06
US20160014472A1 (en) 2016-01-14

Similar Documents

Publication Publication Date Title
US10306331B2 (en) System for remotely controlling client recording and storage behavior
US10140359B2 (en) Distributed database management system
US9693104B2 (en) Client-side multimedia content targeting system
US9674577B1 (en) Data storage management and scheduling system
US7665111B1 (en) Data storage management and scheduling system
HK1140084B (en) A system for remotely controlling client recording and storage behavior
HK1089029B (en) A system for remotely controlling client recording and storage behavior
HK1084811B (en) Broadcast program recording overrun and underrun scheduling system
HK1084811A1 (en) Broadcast program recording overrun and underrun scheduling system

Legal Events

Date Code Title Description
PE Patent expired

Effective date: 20240107