JP4465348B2 - System for remote control of client recording and storage operations - Google Patents

Description

  The present invention relates to control of storage and recording operations of a client system. In particular, the present invention relates to remote control of client system storage and recording operations from a server.

  Systems based on pure client servers such as computer mainframe systems or the World Wide Web and used to solve complex computer problems such as modeling atomic blasting or breaking encryption keys There is a classic tension in the design of automated data processing systems with purely distributed systems such as the Network of Workstations (NOWS).

  Client-server systems are popular because they rely on a clear separation of responsibilities between the server and the client. Servers are often expensive and specially run because it performs calculations or stores data for a large number of clients. Each client is inexpensive because it has only the local resources necessary to interact with the user of the system. A reasonable performance network is considered to connect servers and clients. The economic model of these systems is a model that centralizes management and control at a reduced cost to deploy client systems.

  However, this model requires considerable expense considerations. For example, the incremental cost of adding a new client system can be very high. The added network capacity must be available, sufficient computing resources must be available to support its clients, including storage, memory, and computing cycles, and additional operations Overhead is required for each client due to these additional information resources. As central management servers become larger and more complex, their reliability becomes lower. Ultimately, a server system failure results in all clients losing business.

  Distributed systems are popular because the information resources of the system are distributed to each client. This allows for more complex functionality within the client. Access to programs or data is faster because they are located at the client, which reduces the load on the network itself. This system is more reliable because a node failure only affects it. Many computational tasks are easily broken down into parts that can be calculated independently, and these parts are inexpensively distributed to the systems involved. This relaxes the requirements for network bandwidth and also limits the impact of defective nodes.

  On the other hand, distributed systems are more complex for administrators and can be more difficult to diagnose and resolve hardware or software failures.

  TV viewing can be modeled as a client-server system, but the network path from server to client is infinite speed for all purposes and the path from client to server is incoherent This is an unmanaged model. This is a natural consequence of the broadcast characteristics of television. The cost to add other viewers is zero, and the service delivered is the same as for all other viewers.

  Many attempts have been made to distribute television programs over computer networks such as the Internet or with local cable television facilities operating as a network. The essence of computer network point-to-point makes these attempts cumbersome and expensive as the added information resources are needed for each added viewer. A complete interactive television system in which viewers have overall control of video streaming bandwidth through client set-top devices can benefit and manage the dedication of server information resources to each client It turns out that it is not economical because it rapidly limits the size of the system.

  However, television viewers are very interested in selection and control of television viewing. This interest results in the need for the client system to effectively manage the memory needs for the program material that the viewer wishes to record. In addition, managing the recording of the desired program material is equally important as the memory management task.

  Many consumer electronics devices already include mass storage, which is becoming even larger. The amount of storage available in these devices is already enormous, and there is no limit to the guideline that “doubles every year” for disk drives. Other types of storage media such as CompactFlash®, SmartMedia®, Zip, Flash Memory Stick, MicroDrive, PocketDrive, and SuperDisk also increase storage capacity each year.

  This clear control of storage is performed by a viewer who stores his own TV show, music, images, etc. on his client system. Less obvious, but what will continue to increase in application and importance is the control of this storage by the service provider. Service providers will have an ever-growing desire to control the storage physically owned by the viewer.

  It would be advantageous to provide a system for remotely controlling client recording and storage operations that allows a service provider to remotely control the storage operations of the client system. It would be further advantageous to provide a system for remotely controlling client recording and storage operations where the service provider remotely controls the recording operations of the client system.

U.S. Patent No. 6,233,389 U.S. Pat.No. 6,327,418 John Wiley and Sons, 1995, Bruce Schneier "Applied cryptography: protocols, algorithms and source code in C"

  The present invention provides a system for remotely controlling client recording and storage operations. This system allows the service provider to remotely control the storage operation of the client system. In addition, the present invention provides a system that allows a service provider to remotely control the recording operation of a client system.

  The client device shown in U.S. Pat. No. 6,233,389 owned by the Applicant typically has a centralized video server, such as the storage of large amounts of video content, selecting this content based on the request. And provides the ability to play and control the delivery of the content shown in commonly owned U.S. Pat. No. 6,327,418 completely “like a VCR”.

  In the preferred embodiment of the present invention, reservations are made for recording, storing and deleting multimedia content of the storage device of the client system. The present invention accepts as input a prioritized list of program viewing preferences that is compared to a database of program guide objects. The program guide object indicates the time when the content of interest is actually broadcast.

  A time reservation for the available storage space is generated that is appropriate for the preferred content that the viewer specifically likes or derives. Viewers can request the capture of certain content, which results in the highest possible priority for those content.

  The viewer can also clearly express the preferences using attachments provided via the viewer interface. In addition, the preference can be estimated from the viewing pattern. These preferences correspond to the objects stored in the duplicate database.

  The present invention provides an object called a capture request that is sent by a service provider to a client system. The capture request reflects the local storage management decision on how the client system's storage is allocated (partitioned). Capture requests can be edited and changed over time. The capture request also allows the service provider to determine the content to be recorded by the client system in the same manner that the viewer requests that some content be recorded.

  Capture requests are more powerful than what viewers can request. The recording request for the capture request can preempt the viewer's request or can be entered at the same or lower priority as the viewer's request. The capture request can coordinate all aspects of the recording request and affect the capture request itself. Client system operational functionality is also manipulated by service providers using capture requests.

  The present invention reserves all currently recorded input reservations that track free and occupied time slots for each input source in order to reserve recording of new content and resolve recording conflicts. And a space reservation that tracks content reserved for future recording. If enough space is available to hold it at all times between when the recording starts and when it ends, the content is recorded. Content that is scheduled for recording based on estimated preferences automatically loses all conflict decisions. All reservation conflicts are resolved as soon as possible. Reservation conflicts resulting from the recording of aggregate objects are resolved using related content preference weights.

  The background scheduler tries to reserve each preferred content in turn until the list of preferred content is used up or has no opportunity to record. Preferred content is reserved only if there is no contention with other reserved 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.

  The present invention is illustrated by a system for remotely controlling client recording and storage operations. The system of the present invention allows a service provider to remotely control the storage operation of a client system. In addition, the present invention allows the service provider to remotely control the recording operation of the client system.

  The present invention provides a television viewing information transmission and collection system that improves the ability of individual viewers to select and automatically time-shift television programs while providing opportunities for service providers to enhance and guide the viewing experience. Is implemented. The present invention provides reliable aggregation operations and propagation of information about viewing habits, preferences or purchases, while calculations for individual viewers are personal to individual viewers within a local client device. Describes a fully distributed system that is implemented dynamically.

TV Viewing Information Database FIG. 1 shows a schematic overview of the present invention. A key part of the present invention is a method and apparatus for maintaining a distributed database of television viewing information for a central management site 100 and a large number of client computing system 101 computer systems. The process of extracting an appropriate subset of the central copy of the database is called “slicing” 102, and delivering the resulting “slice” to the client is called “transmission” 103, for the viewer or for viewing. Distributing the information collected on behalf of the person to the central administration site is referred to as “collection” 104 and processing the collected information to generate a new television viewing object or report Called “Analysis” 107. In all cases, the act of reproducing an object from one database within another database is called “replication” 105. The transmitted or collected data items are referred to as “objects” 106 and the central management database and each repeated subset of the central management database contained within the client device is “object-based”. It is a database. Objects in this database are often referred to as “television viewing objects”, “viewing objects” or simply “objects” in order to highlight their use. However, those skilled in the art will readily understand that an object may be any type of data.

  The viewing object database provides a consistent abstract software access model of the objects it contains, independently and in parallel with the replication activities described herein. By using this interface, applications can ensure that a consistent and reliable view of database objects and their relationships is always maintained without concern for basic activities. Create, destroy, read, write, and manipulate objects in.

Basic Principle of Television Viewing Object Referring to FIG. 2, a television viewing object is constructed as a set of “attributes” 200. Each attribute has a type 201 (eg, integer, string or boolean, and value 202). All attribute types are drawn from a basic fixed pool supported by the database.

  The attributes of an object are in two groups: a “basic” attribute (supplied by the viewing object author or maintainer) and a “derived” attribute (created automatically and maintained by a mechanism in the database) Divided. The basic attribute describes the characteristics of the object itself, and the derived attribute describes the relationship of the object. Basic attributes are self-replicating between databases, while derived attributes are not self-replicating.

  As shown in FIG. 3, there is a small set of basic object types defined by the present invention. Each object type is represented as a specific set of related attributes 300, referred to herein as a “schema”. The schema defines a template for each attribute type 301 that includes the name of type 302 and attribute 303. An actual television viewing object is created by assigning information resources to the object and assigning values to attributes defined by the schema. For example, a “program” schema may include attributes such as producers, directors, or actors in programs, icons on the screen, multi-line descriptions of program content, program edit ratings, and the like. A physical program object is created by assigning storage to it and filling attributes with associated data.

  There is one special object type that is predefined for all databases, called the schema type. Each schema supported by the database is represented by a schema object. This allows the application to perform “introspection” on the database, ie dynamically discover what object types are supported and their schemas. When the schema is changed, added or deleted, this greatly simplifies the application software and avoids the need to change the application software. Schema objects are treated like all other viewing objects under the method of the present invention.

  Referring again to FIG. 2, each object in the database is assigned an “object ID” 203 that must be unique within the database. As long as each object ID is unique, this object ID can take many forms. In the preferred embodiment, a 32-bit integer is used for the object ID because it provides a useful tradeoff between computation speed and the number of unique objects allowed. Each object also includes a “reference count” 204 which is an integer giving the number of other objects in the database that refer to the current object. Objects with a reference count of zero do not remain in the database (see below).

  One particular type of viewing object is a “directory” object. A directory object maintains a simple name associated with a list of object IDs for the object. Directory objects can contain other directory objects as part of the list, and there is a single identified object called the “root” directory. The sequence of traversing directory objects starting from the root directory and continuing until an object of interest is found is called the “path” to the object. This path thus points to a specific location within the hierarchical namespace created within all directory objects that exist in the database. An object can be referenced by multiple paths, which means that an object can have many names. The reference count of the viewing object is incremented by 1 for each directory that points to it.

Method for Maintaining Database Consistency and Accuracy One of the features of the preferred embodiment of the present invention is that each database replica remains internally consistent at any time, and this consistency is consistent with other databases. To ensure that it is automatically maintained without the need for reference to or binding to a central administration site. There is no guarantee that the transmission or collection operation will occur in a timely manner or at any guaranteed period. For example, a client system may have been closed for months, but once transmission to the system is finally possible, all that is needed to bring the central management and client database into full synchronization, for example Even if it is not possible to transmit a single object, the replication of the object must always result in a consistent subset of the server database.

  Even more serious is that a stable operating environment cannot be guaranteed while the database is in use or being updated. For example, power to the device may stop. The present invention treats all database updates as “processing”, meaning that all tasks are completed or none of them are completed. The particular technique chosen is called “two-phase commit”, where all elements of the process are examined and recorded, followed by the actual update. For those familiar with the prior art, processing is deployed in a separate log combined with a forward recovery technique that uses the log to repeat the partial updates that were in progress when the failure occurred. You will understand standard journaling techniques.

  What is needed for the derived attributes of any object is a “version” that changes with each change to the object. The version attribute can be represented as a monotonically increasing integer or other representation that creates a monotonic ranking of versions. The schema for each object that can be self-replicated includes an attribute called "source version" that indicates the version of the object that is self-replicated.

  For transmission of a viewing object, it is not guaranteed that all clients will receive the object. For example, while an object is being broadcast, external factors such as sunspots can destroy part of the transmission sequence. The viewing object can be continually retransmitted (meaning presenting the same object multiple times for duplication) to solve these problems. Since no change actually occurred, but the version number is incremented, it is inappropriate to simply update the database object each time an object to be replicated is received. In addition, since significant system resources are consumed during processing, it is desirable to avoid initiating processing to update an object if it is unnecessary.

  To solve this problem, two methods are combined. First, most objects will have a basic attribute called “revocation”. This is the date and time that the object is no longer valid and must be discarded. When a new object is received, the expiration time is checked, and if it has expired, the object is discarded. Revocation deals with objects whose transmission is delayed for some reason, but it does not deal with multiple receptions of the same and unexpired objects.

  The source version attribute addresses this issue. When the viewing object is transmitted, this attribute is duplicated from the current version attribute of the source object. When a viewing object is received, the source version of the received object is compared with the source version of the current object. If a new object has a higher source version attribute, it is replicated to an existing object, otherwise it is discarded.

  Assume that a very large number of viewing objects are being transmitted to any particular client system. For example, clients belonging to other cable systems are not interested in “channel” viewing objects that describe the channels of a particular cable system. As overhead introduces and adds new objects to the database, it may be advantageous for received objects to be filtered to other attributes in addition to the attributes described above. The present invention accomplishes this by using filtering based on object type and attribute values. In one embodiment, this filtering may be performed in certain operations, perhaps as a series of instructions written with specific knowledge of the various object types and how they must be filtered. Based on executable code.

  In the preferred embodiment of the present invention, a “filter” object is provided for each object that indicates what attributes are required, should not be present, or a range of values for attributes that are acceptable for addition to the database. Specified for type. Those skilled in the art will readily recognize that this filter object may contain some form of executable code, possibly as a series of executable instructions. These instructions will examine and compare the attributes and attribute values of the object being filtered, which will indicate whether this object should be subject to further processing.

  A viewing object is rarely independent of other objects. For example, a “display” object (which describes a particular time on a particular channel) depends on a “program” object (which describes a particular television program). One important aspect of maintaining consistency is that all subordinate objects already exist in the database or are added as part of a single transaction before attempting to add a new viewing object. It is to guarantee that it should be. This is accomplished simply using a basic attribute of the new viewing object called the “dependency” attribute that lists the object ID and source version of the object on which the new object depends. Obviously, the new version of the object must be compatible, in the sense that the schema that defines the new version is the same or has a strict superversion of the attributes of the original schema.

  When a new viewing object is received, the database is first checked to see if all the dependencies of that object exist, and if so, the object is added to the database. If not, the new object is “staged” and all subordinate objects are also saved in the holding area until they are also staged. Obviously, in order to add a new set of viewing objects to the database, the dependency graph must be closed between the intermediate region and the object already in the database, based on the object ID and source version. Don't be. When the closure is performed (which means that all subordinate objects exist), the new object is added to the database for a single atomic transaction.

Naming and discovery of television viewing objects Directory objects have been previously described. Referring to FIG. 4, the directed graph formed by collecting directory objects and starting from the root path 400 and enumerating all possible paths to the viewing object is called a “namespace”. In order to discover an object without knowing the specialized object ID, one or more paths in this namespace must refer to it. For example, in an example where the application software has little interest in the object ID and instead wants the software to reference the object, for example by the path "/ tvschedule / today", any other part of the system The actual object referenced can be changed daily without requiring any changes in.

  One way to determine the path to an object is to specify the “path name” basic attribute on the object. Objects are added to the database, and directory objects that describe the components of the path are created or updated and added to the objects. Such nomenclature is typically used only for debugging replication mechanisms. Since the portion of the central management database that is self-replicated to each client system is different and it becomes very difficult to manage the path names of all replicas of the database, no clear path is set.

  A preferred method for adding objects to the database namespace is called "indexing". In the preferred embodiment of the present invention, an "indexer" object is defined for each object type that indicates what attributes are used when indexing it into the database namespace. Those skilled in the art will readily recognize that this indexer object can include executable code in some form, perhaps as a series of executable instructions. These instructions examine and compare the attributes and attribute values of the indexed object. This will result in indicating where the object should be located in the namespace.

  Based on the object type, the indexer looks at a specific set of attributes attached to the object. When such an attribute is found, the indexer automatically names the object based on the value of the attribute in the hierarchical namespace represented by the database directory graph. Referring again to FIG. 4, the program object may have an “actor” attribute having the value “John Wayne” and a “director” attribute having the value “John Ford” 401. The root directory may show two subdirectories, “byactor” 402 and “bydirector” 403. The indexer will then add the paths / byactor / John Wayne and / bydirector / John Ford, both of which reference the same object 401 to the database.

  Derived attributes are maintained for each object that lists directory objects that reference this object 404. Since the indexer adds a path to the namespace for this object, it adds the final directory ID of the path to this list. This ensures that when an object is discovered, the object graph is closed, and all references to that object within the database are also discovered, regardless of whether they are paths or dependencies. The

  This unique and new way of adding objects to the database has significant advantages over the standard approach. The indexer sorts the object into the database as it is added. Thus, the search for objects associated with a particular path is a series of selections from an ordered list, which can be efficiently performed by those skilled in the art.

Deleting objects from the database The rules for adding objects to the database are important, but the rules for removing objects from the database are also important for maintaining consistency and accuracy. For example, if there are no strong rules for removing objects, the database may grow indefinitely over time as unused objects accumulate.

  The basic rules for deleting objects from the database are based on reference counts. Objects whose reference count has dropped to zero are deleted immediately. For example, this means that the object must be referenced by either a directory or some other object that remains in the database. This rule applies to all objects in the closed dependency graph based on the deleted object. Thus, if an object that references another object (such as a directory) is deleted, the reference count on all referenced objects is decreased, and these objects are similarly reduced to zero count. Continue to be deleted.

  There is also an automated process for deleting objects from a database called “reaper”. The reaper periodically examines all objects in the database and, if the object is to be retained in the database, further examines and determines various attributes and attribute values according to the object type. For example, the revocation attribute can indicate that the object is no longer valid, and the reaper will delete the object.

  In the preferred embodiment, using a method similar to (or possibly identical to) the filtering and indexing methods described above, the reaper instead accesses the reaper object associated with the object type of the current object. can do. This can include various types (possibly a series of executable instructions) of executable code. This code examines the attributes and attribute values of the current object and determines whether the object should be deleted.

  The overhead of individually deleting every object whose reference count has been reduced to zero can be very high because any such deletion results in processing with the database. It would be advantageous to limit the performance impact of acquiring objects so that foreground operations continue at maximum speed. In the preferred embodiment, this is accomplished using techniques based on common garbage collection methods.

  For example, instead of deleting an object whose reference count has been reduced to zero, the reaper does not perform any other action. Periodically, a background task called a garbage collector looks at each object in the database. If the object has a reference count of zero, it is added to the list of objects to be deleted. In one embodiment, if the garbage collector examines the entire database, it will delete all such objects in a single transaction. Those familiar with this technology may find that this method can also result in an important performance penalty, as other access to the database may be delayed while the object is deleted. You will recognize. In addition, if all objects should be deleted properly, changes to the database may have to be delayed while the garbage collector is running. This can even make performance worse.

  In the preferred embodiment, the garbage collector examines a series of path databases. When a certain number of objects are collected, they are deleted in a single transaction. The process continues until all objects have been examined. This technique does not guarantee that all garbage objects are collected during the review process, as parallel activities can free previously examined objects. However, these objects will be discovered the next time the garbage collector operates. The number of objects deleted in each pass can be adjusted to achieve acceptable performance for other database activities.

Behavior of a distributed television viewing object database Considerations for maintaining a distributed viewing object database Replication of television viewing objects in a distributed database instance is necessarily unreliable and secure Not require the transmission of objects on distributed channels.

  For example, if an object is transmitted by a broadcast mechanism such as wireless or television broadcast, it cannot be guaranteed that the data will be transmitted accurately or completely. Some weather conditions such as storms can cause transmission dropouts. Other causes of interference are other broadcast signals, large equipment, home appliances and the like.

  There are several standard techniques that can be used for transmission to manage data transmission over unreliable channels, including repetitive transmissions, error correction codes, etc., and any or all of these can be It will be readily appreciated that it can be used for any particular instance.

  For simplicity, the self-replicating objects are collected here in a distributed package called a “slice”. A slice is a subset of a television viewing object database associated with clients in a particular region, such as a geographic region or a satellite transmitter service area.

  Security for these slices is very important. Slices are used to add objects to a database that is used to provide useful services to database users and to store information that can be considered private or private. Due to the broadcast nature of slice transmission, slices can be easily duplicated by a third party when they are transmitted. A practical solution to these problems is to encrypt the slice during transmission. The best reference text on the technique used in the present invention is “Applied Cryptography: Protocols, Algorithms and Source Code in C”, published by John Wiley and Sons, 1995, Bruce Schneier.

  In the preferred embodiment of the present invention, secure, encrypted channels are often described as asymmetric key encryption, or often as public / private key pair encryption, US Pat. No. 4,405,829. Established using techniques similar to those described in this issue. Practitioners skilled in the art will recognize that a protocol based on asymmetric key encryption serves as a reliable and effective basis for authenticating client devices and ensures the distribution of information. Let's go. In general, authentication is provided using an exchange of signed messages between the client and the central management system. Distributing securely is done by encrypting all communications using a short-term symmetric key sent during the authentication phase.

  In order for security to be successful, it is necessary for the sender and receiver to 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 No. 6,385,739, "Automatic Test Electronic Assembly and System", filed July 19, 1999, owned by the present applicant, is a client device that is automatically asymmetric as a final step in the manufacturing process. A mechanism for generating key pairs is described. The secret key generated in this way is stored in a secure microprocessor embedded in the client device so that this key is never presented to the external device. The public key thus generated is transmitted to the local manufacturing system where the key is recorded along with the client serial number under a secure database. This database is later securely transmitted to the centrally managed distributed system, where it is used to perform secure communications with clients.

  This unique and new application of key generation solves the key distribution problem because the secret key is never presented to the external component of the client. Here it may be identified using a special tool, such as a logic analyzer. Alternatively, it may be used only to decrypt the message originally encrypted with the public key (and then provide the result to the external component) within the security microprocessor itself. .

  In the following discussion, it is assumed that all communications between the client and the central management system are authenticated and encrypted as described above.

Transmission of Viewing Objects to Client System Returning again to FIG. 1, in the preferred embodiment of the present invention, the following steps constitute a “transmission” of television viewing objects from a central management database using slices.

  1． There are many mechanisms for transmitting slices to an ancestral group of client viewing devices. For example, slices can be downloaded directly through a telephone modulation demodulator or cable modem 109, or they can be modulated into a standard television broadcast 108 vertical blanking interval (VBI) line, or private data Channels can be added to digital television multiplex signals. Those skilled in the art will readily recognize that any mechanism capable of transmitting digital information can be used to transmit a slice of a television viewing object database.

  The first step in preparing a TV viewing object for transmission is to recognize the transmission mechanism used for this particular instance and create a slice of a subset of the database that is customized for that mechanism. is there. For example, the database may include television viewing objects for all programs in the country. However, if TV viewing objects are sent using VBI modulation on local television signals, they are related to programs that are viewable within the television broadcast service area used to carry them. Only those TV viewing objects that should be included should fall within the scope of the corresponding slice. Alternatively, if some television viewing objects contain promotional material associated with a particular geographic area, these objects should not be transmitted to other geographic areas.

  In the preferred embodiment of the present invention, the speed and periodicity of traversing the database and generating slices for transmission can be adjusted in any manner to allow useful cost / performance tradeoffs. . For example, for some transmission methods, it may be sufficient to make slices 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 already been authenticated using a secure protocol will have a copy of this symmetric key, which will allow them to decrypt this slice and access the television viewing objects within it. Will do.

  2. Once a slice is complete, it is copied to a location where the transmission mechanism can obtain and transmit data 110. For telephone connections, the slice is placed on the telephony server 111 that provides data to each client when it calls in. If television broadcast is used, the slice is replicated to equipment that resides with the station television transmitter, where it is modulated into a signal. For these and similar broadcast cases, the slice is “carouseled”, ie, the data describing the slice is constantly repeated until a new slice is provided for transmission.

  This repeated broadcast of slices is necessary because there is no guarantee that the signal carrying the data will reach each client reliably. The client device may not be turned on or there may be a failure to receive the signal. In order to achieve that the transmitted slices are properly received by all client devices with a high probability, they are continually rebroadcast until updated slices are available for transmission. .

  The preferred embodiment of the present invention uses a broadcast mechanism, such as a television signal, to transmit slices. However, it is desirable to provide downloads via a connection-based mechanism, such as a modem or Internet connection. Using a connection-based mechanism usually results in a time usage fee, and therefore it is desirable to minimize the time spent transmitting slices.

  This is achieved using a two-stage process. When the connection is established, the client system sends a list of previously received slices to the telephony server 111. The server compares this inventory with a list of slices that should have been processed by that client. Unprocessed slices are transmitted to the client system.

  3. This slice is transmitted by breaking the encrypted slice into a series of short numbered data packets. These packets are captured by the client system and held in the intermediate area until all packets in the sequence are present. The packet is reassembled into slices and it is then decrypted. Television viewing objects within the slice are then filtered for applicability, which is probably added to the local television viewing object database. This process ensures that some central management database of television viewing objects is replicated to the client.

  The present invention keeps track of the time at which data packets are received. Data packets older than the selected time interval are purged from the intermediate area on a periodic basis. This avoids consuming space for unspecified intervals while waiting for all parts of the slice to be transmitted.

  In particular, when transmitting an object via a broadcast medium, various types of errors can occur in the transmitted data. Each data packet is stamped with an error detection code (eg, a parity field or CRC code). If an error is detected, the data packet is simply discarded. This broadcast carousel eventually retransmits the data packet, which is likely to be properly received. In this way, slices of any size can be sent reliably. This is achieved at the expense of showing the received part of the object on the client until all parts are properly received.

  4. There may be one or more transmitted “special” slices that communicate data related to the service, in particular service authorization information, to the client system. It is important that the service provider be able to control client system access to premium services if the viewer does not pay his bills or for other operational reasons.

  One particular type of special slice includes an “authorization” object. The authorization object is typically encrypted using asymmetric key encryption based on the public / private key pair associated with a particular client. If the slice can be successfully decrypted by the security microprocessor using the embedded secret key, the slice is an object that exhibits an acceptable time delay before other authorization objects are received; And one or more symmetric keys for short time intervals. The delay value is used to reset the database time stamp indicating when the client system stops providing service. The symmetric key is stored in the local television viewing object database for use to decrypt new slices that can be received.

  If the client does not receive the appropriate authentication object by the time set in the database, it will begin to refuse most services to the viewer (as specified by the service provider). Let's go. Also included in the authentication object is a download key that has one or more valid lifetimes required to decrypt the transmitted slice. It will be clear that if the client system is unable to authenticate itself, it cannot decrypt any object.

  Each authorized slice is generated and transmitted individually. When broadcast transmission is used for a slice, all associated grants are processed like all other slices and carouseled with all other data. If direct transmission, such as over a telephone connection, is used, only the authentication slice for that client is transmitted.

  5. When the client device receives a complete database slice, it uses the method described above to add new objects contained within it to the database.

Collecting Information from Client Systems Referring again to FIG. 1, in the preferred embodiment of the present invention, the following steps constitute a “collection” of television viewing objects from each client database.

  1. As the viewer progresses through the TV channels available to him, the client system will tune the channel, the time of tuning, the duration of the stay, the action like VCR (eg pause, rewind) and Record interesting information, like other interesting information. This data is stored in the local television viewing object.

  In addition, the viewer can indicate interest in the subscription or promotion being made available, or he can indicate a desire to purchase the item. This information is also recorded in the local television viewing object.

  In addition, the operation of the client device can result in important data that must be recorded on the television viewing object. For example, an error may occur when reading from a client hard disk drive or when the internal temperature of the device exceeds operating parameters. Other similar types of information may fail to properly download objects, which may consume space for various disk-based operations or rapid power cycling.

  2. At a particular time, which may be based on immediate or periodic criteria, the client system can communicate with the central administration site via a direct connection 104 (usually via a telephone and / or internet connection). Contact. The client device sends a byte string that identifies itself that is encrypted by its private key. The server fetches matching television viewing objects for the client device from the database and uses the key stored therein to decrypt the byte string. At the same time, the server sends a byte sequence encrypted in its private key to the client, which gives the client a new one-time encryption key for the session.

  Both sides must successfully decrypt their authentication messages in order to communicate. This two-way handshake is important because it ensures both the client and the server that the other is valid. Such authentication is necessary to avoid various attacks that can occur on the client system. For example, if the communication is not authenticated in such a form, the malicious party creates an “Arias” central administration site with a fraudulent television viewing object database and provides bad information to the client system, resulting in misoperation. May cause it. All further communications are encrypted using a one-time session key. Since information is transmitted over a network such as the Internet, encrypted communication is required. Here, the data traffic is open for inspection by all equipment that it passes through. Since the viewing that the collected object presence can do contains information that is considered private, the information must always be fully protected.

  Assuming that the authentication phase is successful, both parties consider the full-duplex telephone line as two one-way broadcast channels. A new slice is distributed to the client and the viewing data to be collected is sent back. When all the data is delivered, the connection ends.

  Those skilled in the art will readily recognize that this connection can occur transparently to all other software in the system by a network, such as the Internet running the standard TCP / IP protocol. Let's go.

  3. Uploaded information is processed in the same way by the server. That is, it is assumed that the TV viewing object to be copied to the central management database is presented. However, since there can be many service provider clients, there can be many uploaded viewing objects. Uploaded objects are therefore assigned information including navigable attributes about their source. That is, the object is then uniquely indexed into the database namespace when it is added.

  Uploaded viewing objects are not immediately added to the central management database. Instead, they are queued for later insertion into the database. This step allows column processing to be independent of the connection pattern of the client device. For example, many devices can create and connect many objects at once. If these objects are immediately added to the central management database, the performance of all connections will be compromised and the connection time will increase. Since telephone charges are charged by usage time, any system whose connection time increases as a function of load is not acceptable.

  Another effect of this isolation is that it can easily withstand machine or network failures. In addition, the rate at which viewing objects are processed and added to the central management database can be controlled by the service provider by changing computer systems and their configurations to achieve cost or performance goals. it can.

  Another effect of this separation is that it provides a mechanism to separate the collected data to improve service operations and data that may identify individual viewers. It is important to keep such identification data private for legal reasons and to increase the confidence that individuals have within the service provider. For example, a navigable attribute assigned to a viewing object that includes a record of the viewer's viewing selection may include only the viewer's zip code. This means that further processing of these objects cannot build a path to individual identification.

  Periodic work causes the server to perform a selection of these objects from the database and dispose of them appropriately. For example, objects indicating viewer behavior are aggregated into an overall viewer behavior model, and information that may identify individual viewers is discarded. Objects that contain operational information are sent to the analytical work, which can alert customer service personnel to potential problems. The object containing the transaction information is delivered to a processing or commercial system for execution.

  Any of these activities can result in new television viewing objects being added to the central management database, or existing objects being updated. These objects will eventually be transmitted to the client device. Thus, the television viewing management system is a closed loop that creates a self-maintained replicated database system 105 that can support any number of client systems.

Processing of the television viewing object by the client system The television viewing object will contain the following types of information: That is,
TV program description and display time,
Cable, satellite or broadcast signal originator information such as channel numbering and identification,
Viewer preference information such as actor, genre, display time,
Improved software such as database software, application software, operating system software,
Statistical modeling information such as preference vectors, demographic analysis,
And any other optional information that can be presented as digital data.

Method applied to the program guide object The program guide object is used by the software running on the client system to select among all available programs and channels described by the object within the database. -Includes all the information necessary to tune in, receive, record and watch programs of interest to users of the system.

  This program guide information is regularly updated by the service provider. This is handled, for example, by providers obtaining program guide information in some way from commercial suppliers of such information or other broadcast reservation information sources. This data is then processed using well-understood software techniques to reduce this information to a collection of interrelated viewing objects.

  Referring again to FIG. 4, a typical relationship between program guide objects is shown. A television “network” object 407 is any entity that reserves and broadcasts a television program, regardless of whether the broadcast is made over the air, cable, satellite or other suitable medium. is there. A television “program” object 401 can be any different segment of a television broadcast signal, such as a particular program, commercial advertisement, station promotion, opener, trailer, or any other enclosed part of the television signal. It is a description. A “display” object 406 is part of a broadcast reservation for the network on which the program is broadcast. The “Channel Map” object maps a network broadcast to a specific broadcast channel for the medium being used. For example, a channel map object for a satellite broadcast service will contain information about the flow of data including transponders and broadcasts. Using the previously described method, this program guide data is self-replicated from the central administration site to the client system. Here, the application software of the client system uses this data to manage TV viewing.

  The service provider can also provide an aggregate viewing object that describes a set of program guide objects that are interrelated in some form. For example, the collection of “Star-Trek” may include a reference to all program guide objects associated with this trade name. Obviously, any set of programs can be aggregated in this form. Aggregated objects are similar to directories. For example, a collection of space operations may be found in a hierarchical namespace with "/ showcase / Star Trek". The accumulation object is also a program guide object, and can be operated in the same form including aggregation of accumulation objects and the like.

  The client system can further refine the collection of program objects. For systems that can capture programming to internal storage, each captured program is represented by a new program guide object, which is made available for viewing, aggregation, and the like. A clear viewer action also results in creating a program guide object. For example, the viewer can select several programs and have a new aggregate object created.

  It does not mean that a description of the type of program guide object is included. Many different uses and methods of generating program guide objects not described herein that can benefit from the basic method of the present invention can also be used. Program guide objects are used by application software in five ways.

  1. In the simplest case, viewers want to browse these objects to identify programming that will be available now or soon. The application software will map the object relationships described by the database in the form of a visual and audible interface that is convenient and useful to the viewer. Viewers can indicate that they are interested in a particular program and should result in an application specific action, such as recording the program in local storage when it is broadcast.

  2. The application software can also directly process program guide objects to select programs that the viewer may be interested in. This process is basically based on the analysis of previously seen programs combined with a statistical model, which results in prioritization of all available programs. The highest priority program can be processed in an application-specific manner such as recording the program on local storage when it is broadcast. The prioritized part formed in this way can be presented to the viewer for additional selections as in case 1.

  Those skilled in the art will recognize that there are many prior arts (eg, US Pat. No. 5,758,257) that concentrate on methods for choosing programming for viewers based on previous viewing history and explicit preferences. Will be easily recognized. The methods described in this patent suggest a priority for capturing programming rather than broadcasting or transmitting programming, and there is no time constraint on when to broadcast programming So unique and new compared to these technologies. Further details regarding these methods are given after this description.

  In general, the clear choice of programming by the viewer has the highest priority for capture. This is followed by programming selected using the preference techniques described herein.

  3. The client system has a small number of inputs that can receive television broadcasts or access network-wide web pages such as an intranet or the Internet. The reservation method is used to select how each input is tuned and what is done by the resulting captured television signal or web page.

  Referring to FIG. 6, a program in which a viewer is interested can be broadcast at an arbitrary time on an arbitrary channel described by a program guide object. In addition, the program of interest may be a network-wide web page Universal Resource Locators (URL), such as an intranet or the Internet. Channel metaphors are also used to describe the location or URL of a particular web site or page.

  The viewer can “tune” the site to the web, for example by assigning a web site URL to the channel. Whenever that channel is chosen, a web site is shown. A web page can also be assigned to a program of interest, and a snapshot of the web page will be taken and recorded at a predetermined time.

  The scheduler accepts as input a preferential list of program viewing preferences 603, possibly generated according to the above case. The reservation method 601 then compares this list to a database of program guide objects 604 that indicates when the program of interest is actually broadcast. It then generates a reservation of available storage space 606 that is optimal for the viewer's explicit or derived preferred program for time 607. Further details regarding these methods are given after this description.

  4. When the captured program is watched, the matching program guide object uses any suitable technique (preferably with some form of On Screen Display (OSD)) to show the program overlaid on the display. Used to provide additional information about. Such information includes, but is not limited to, program name, original broadcast program time, channel or network, expiration time, execution time or other information.

  5. When valid programming is seen, the application uses the current time, channel, and channel map to find a matching program guide object. Information from this object is presented using any suitable technique, as described above. When the viewer changes channels, the information can be automatically indicated when a new program is started by the viewer, when the program resumes after a commercial, or by a request based on other circumstances .

  6. Using techniques similar to those described in Case 2, the application software can also incorporate promotional material that the viewer may be interested in. This information can be presented at the viewer's request and it can be automatically inserted into the output television signal at some convenient location. For example, broadcast program advertisements may be replaced with different advertisements with higher preference priorities. Using the time warping device described in US Pat. No. 6,233,389 (named “Multimedia Time Warping System”), filed July 30, 1998, the output television signal can be output at any location. Arbitrary overlay programs can be inserted. While an overlay program is inserted to perform this task, the time warping device allows the overlaid program to be delayed.

How to Generate a List of Favorite Programs Viewer preferences can be obtained in a number of ways. The viewer can request to capture a specific program. This results in the highest priority for those programs. Instead, viewers may clarify preferences using attachments provided in the viewer interface, perhaps in response to a promotional spot for a particular program, or even during the viewing of a program. Can be expressed as Finally, preferences can be inferred from viewing patterns such as previously viewed programs, commercial advertisements such as viewed or skipped.

  In any case, such preferences must correspond to television viewing objects stored in the replica database. The program object includes rich information regarding each specific program such as a title, description, director, producer, actor, and evaluation. These elements are stored as attributes attached to the program object.

Individual attributes can result in preference objects being generated. Such an object stores the following information.
1. the type of preference item, such as a favorite actor or director,
2. Preference weight given by the viewer, which may be indicated by multiple button presses or other means
3. Statically assigned importance of preference over other preferences, for example, actor preference is more important than director preference,
4. For example, the effective value of a preference item such as the director's name.

  With respect to FIG. 5, preference objects are stored in the database as a hierarchy similar to that described for program guide objects. However, this hierarchy is built incrementally as the preference is expressed, 500. The hierarchy thus constructed is based on “direct” preferences, such as those derived from viewer actions or estimated preferences.

  Similar hierarchies are created based on “indirect” preferences indicating the same preference object 501. In general, indirect preferences occur when preferences for aggregate objects are generated and direct preferences are used for further weights implied by the aggregated object collection. The preference object referenced by the indirect preference hierarchy enumerates the available program objects that are part of the aggregate object 502 and creates or updates a preference object for each attribute found in this way Occur or be updated.

  The weight of a particular preference 503 starts at zero, and then a standard value is added based on the preference or standard degree represented (possibly by multiple button presses), or indifference expressed If so, the standard value is subtracted. If preferences are expressed based on aggregated viewing objects, all preferences generated by all viewing objects subordinate to the aggregated objects are weighted in the same way. Thus, a new weighting of the associated preference element is generated from the previous weighting. This process is determined by the degree of preference that it is possible to represent, so all weights fall within a limited range.

  In the preferred embodiment of the invention, non-linear combinations can be used to weight preference items. For example, using the statistical model provided by the central administration site, the client can determine that a preference heavily weighted for three attributes should be weighted for the fourth attribute as well. You can guess what to show.

A list of preferred programs occurs as follows.
1. Table 504 is configured to show a list of each possible program object attribute, and any preference object for that existing attribute is listed in that entry.
2. If the preference item is a string such as an actor name, the 32-bit digital signature for that string is calculated using a 32-bit CRC algorithm and stored with the table item rather than the string itself . This allows for faster scanning of the table while keeping the risk of two different strings generating the same digital signature, since string comparison is avoided.
3. For each program object in the database, and for each attribute of that program, the attributes are seen in a table. If present, the list of preference objects for that attribute is examined for a match with the attributes of the current program object. If a match occurs, the weight associated with that preference object is added to the weight associated with the program object to generate a single weight for this program.
4. Eventually, the program objects are ranked based on the overall weight for each program, which results in a list of most preferred to least preferred programs.

  Given this final priority list, a recording reservation is generated using the method described below. This results in a collection of recorded programs that the viewer is most interested in.

Method Applied to Recording Reservation for Available Storage Space As noted above, recorded programs generally have an expiration date when the recorded program is removed from the client's storage. The viewer can indicate at any time that the program should be stored longer, which delays expiration until the interval selected by the viewer. The present invention views the available storage for recording programs as “cache”. Programs that were not watched are removed after a period of time based on the assumption that if they are not watched immediately after recording, they will not be watched in the future. Watched programs become candidates for immediate deletion based on the assumption that they are no longer interested.

  Proper recording reservations and deletion of old programs allow a smaller storage area to appear much larger because there is ongoing flushing of old programs and the addition of new programs. In addition, if the information resource is available, the recording can be used to reserve a program based on the viewer's estimated preferences. These are called “fuzzy” records. This results in a system where the program storage area is always the “complete” program that the viewer is interested in, and other programs are recorded at that location or the viewer explicitly deletes it. Until the program is not removed.

  In addition, the viewer can select a program for recording at any time and the recording window may compete with other reserved recordings or must record the program. There may not be enough space available when not. The present invention includes a unique and new way to resolve such conflicts.

  Conflicts arise for two reasons: lack of storage space or lack of input sources. The television viewing system described herein includes a fixed number of input sources for recording video and storage media, such as a finite capacity magnetic disk for storing recorded video. It is impossible to record all television program broadcasts over any significant period. Therefore, resolving contention that occurs due to resource limitations is the key to enabling the correct program to be viewed.

  Referring again to FIG. 6, the present invention maintains two reservations, Space Schedule 601 and Input Schedule 602. Space Schedule tracks all programs that have been recorded at the present time, and programs that are scheduled to be recorded in the future. The total space available at any given time in time generates the sum of all occupied space (or space that will be occupied at that time) and is used to store the program It can be found by subtracting it from the total capacity it can. Programs that are scheduled to be recorded based on estimated preferences ("fuzzy" recording) are not counted in this calculation. Such programs automatically lose all contention decisions.

  The program can be recorded 603 if sufficient space is available to hold it at all times between when the recording begins and when it expires. In addition, during the program there must be input that can be used to record it. Input Schedule 602 tracks the free and occupied time slots for each input source. In the preferred embodiment of the present invention, the input source cannot be used for the same service. For example, one input may be a digital television signal and the other input may be an analog television signal with different programming. In this case, only those inputs that can record the desired program are considered during the reservation.

  With reference to FIG. 7, the flowchart shows a description of the steps taken to reserve a recording in the preferred embodiment. First, a list 701 is generated in which the display of programs of interest is ordered. The preferred embodiment of the present invention orders these displays by time so that recording is done as soon as possible, but any particular ranking can be selected. Each display of this list 702 is then checked to see if contention for input 703 or space 704 occurs as described above. If no conflict is found in the display, this program is reserved for record 705.

  If a conflict is found, the preferred embodiment of the present invention selects only the display of programs that do not have an input conflict 706. Referring again to FIG. 6, it can be seen that over the lifetime of the recording, the amount of free space changes as other programs are recorded or expire. This list of displays is then preferably sorted by the minimum amount of free space during the lifetime of the candidate record. Other rankings can also be selected.

  Referring again to FIG. 7, for each candidate display, the viewer is given the option of shortening the expiration date of competing programs 708, 709. By this ranking, selecting 707 of the reserved programs in the order of minimum to maximum results in being presented to the viewer. The present invention has no need to use this ranking against others.

  If the viewer rejects all opportunities to reduce the expiration time, the final step is to select 710 these displays in the input conflict and sort these displays in the first conflict resolution phase 711 Including that. The viewer is then given the option to cancel each previously reserved recording for the desired program 712,713. Of course, the viewer can finally decide that anything new is not recorded 714.

  In the preferred embodiment of the present invention, all conflicts are resolved as soon as possible so that the viewer has more control over what is recorded. When the viewer makes a clear selection of the program to record, the algorithm described in FIG. 7 is used to immediately reserve the recording and manage any contention that has occurred.

  If a clear choice is made and the viewer informs that the recording will be made, it will not be canceled without the viewer's explicit approval.

  Fuzzy recordings are periodically reserved by background tasks on the client device. Given a prioritized list of preferred programs as described above, the background scheduler reserves each preferred program in turn until the list is exhausted or there are no more opportunities to record. Try that. A preferred program is reserved only if there is no conflict with other reserved programs. Preferred preferred programs that are reserved are firstly when they compete with a clear choice and secondly when a change in viewer preference identifies higher priority programs that can then be recorded Say, can be deleted under two conditions.

  Further complications arise when dealing with aggregate viewing objects that require recording. If conflict resolution is handled by the method described above for such objects, potentially a significant number of conflicts may be generated. This provides a confusing and stressful experience for viewers in resolving conflicts. Thus, when an aggregate object is selected for recording, the conflict is automatically resolved to take advantage of existing reservations.

  In the preferred embodiment of the present invention, the conflicts resulting from the recording of the aggregate object can be resolved using the related program preference weighting if multiple conflicts are caused by a particular program in the aggregate object. I will. If that preference exceeds that of all competing programs, it will only be recorded.

Methods applied to software objects Client systems require a complex software environment for proper operation. The operating system manages the interaction between the client hardware devices and the software applications that manage these devices. The television viewing object database is managed by an explicit software application. Time warping software applications are yet another application.

  It is preferable to add new features or correct defects in these and other software subsystems that work for client hardware devices. Using the methods described herein, it is possible to self-replicate a viewing object that includes an updated software module into a client system database. Once present in the client system database, the following unique and new methods are used to install the updated software and have the client system start running the new software.

The software environment of the device is instantiated as a series of steps that take place when power is first applied to the device. Here, each step creates state information that supports the appropriate application for the next process. The final step starts an application that manages the device and interacts with the viewer. These steps are as follows.
1. The device's read-only or electrically programmable memory holds the initial bootstrap sequence of instructions. These instructions initialize the low-level parameters of the client device, initialize the disk storage system, and load the bootstrap loader from disk to memory, which is then executed. This initial bootstrap can be changed if it is in electrically programmable memory.
2. The second stage boot loader then looks for the disk drive's operating system, loads the operating system into memory, and causes the operating system to execute. This loader must be at a specific location on the disk so that the initial loader can easily find it.

  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. Other application software, such as time warping software and viewer interaction software, is also loaded and started. This software is usually placed in a separate area on the disc from the object database or the captured television program.

  Ideally, the new software would be installed by simply copying it to the appropriate location on the disk drive and restarting the device. This behavior is full of danger, especially in the home environment. While duplicating software, power may be reduced, resulting in software images that are incorrect and may cause potential operational problems. This new software may have defects that prevent proper operation. Failures occur in the disk drive and may damage the software image.

  Although the method of the present invention has been described for a disk drive, those skilled in the art will readily recognize that the method described herein can generally be applied to any persistent storage system. Let's go. Disk drives and other persistent storage systems are typically formatted into fixed size blocks called a series of sectors. A “split” is a non-overlapping subset of this sequence over time that decomposes the storage into logically independent regions.

  As shown in FIG. 8, the present invention maintains a sector of information in a fixed position on the disk drive 803 called “boot sector” 804. The boot sector 804 contains sufficient information for the initial boot strap 801 to understand the partitioning of the drive 803 and search for the second stage boot loader 806.

  The disc is divided into at least seven sections. As two small partitions dedicated to holding a copy of the second stage boot loader 806, two partitions holding a copy of the working system kernel 807, two partitions containing a copy of the application software 808, and scratch memory 809 There is a partition used. For overlapping partitions, one of the partitions is marked “first” and the second is marked “backup” and an index is recorded in the boot sector 805.

  Those skilled in the art have described only two partitions for redundancy herein, but that triple, quadruple or more redundancy can be achieved by more overlapping of partitions. Will be easily recognized.

  Referring to FIGS. 9a and 9b, at boot 901, the initial bootstrap code reads the boot sector 902, scans the partition table, and looks for the “primary” partition for the second stage boot loader. It then tries to load this program into memory 903. If it fails 904, for example due to a disk drive failure, the boot loader attempts to load the “backup” partition program into memory 905. If any attempt is successful, the boot loader then passes control to the newly loaded program along with the indicator 906 of the partition in which the program was loaded.

  Similarly, the second stage boot loader reads the partition table and looks for the “primary” operating system kernel 907. If the kernel cannot be loaded 908, a “backup” kernel is loaded 909 instead. In any case, with the source partition passed from above 910, control is passed to the operating system along with an indication of the source partition.

  Eventually, the operating system looks for the “major” partition containing the application software and attempts to load the initial application 911. If this fails 912, the operating system looks for a “backup” partition and then loads 913 the initial application. The source partition index is passed to the initial application along with the source partition information from the previous step. At this point, the application software takes over the client system and begins 914 normal viewing management operations.

  This sequence of operations provides an appropriate level of protection from disk access errors. This also allows a method that allows new software to be installed and operated reliably at any of these levels.

  The “Installer” viewing object in the object database is used to record the status of software installation attempts. It records the split status for each of the three levels above, including an indicator that indicates that an attempt to install new software is in progress 915. This operation is highly reliable due to the nature of database processing.

  Referring to FIG. 10, installing a new software image at any of the three levels is handled as follows. That is, a new software image is first replicated to the appropriate backup partition 1001 and an indicator is created 1002 in the database that indicates that a software installation is in progress. The partition table primary and backup partition indicators are then exchanged 1003 and the system is restarted 1004. Eventually, control will be passed to the initial application.

  Referring again to FIG. 9b, the first task of this application is to update the installer object. For each level 921, 922, the application checks whether an installation has occurred, 916, 917, and verifies whether the level has been loaded off into the primary partition 918. If loaded off, the installation at that level is successful and the installer object is updated 919 to indicate that it was successful for that level. If not loaded, the application duplicates the backup split for that level in the primary partition, and 920 indicates a failure of the installer object for that level. Duplicating a partition ensures that a known good software backup copy for the level is kept available at all times.

  In the preferred embodiment of the present invention, finalizing the installation for the top application level of the software can be delayed until all parts of the application environment have been successfully loaded and started. This provides an additional level that ensures that all parts of the application environment work properly before permanently switching to new software.

Methods Applied to Behavioral Status Objects A behavioral status object is a class of viewing objects in which information about client system usage, performance, and behavior is recorded. These objects are collected by the central administration site whenever communication with the central administration site is established.

The following operational status indicators are recorded with a time stamp for later collection.
1. The viewer's action of pressing a button on the remote control device is basically recorded. Each “button press” is recorded with the current time and any other contextual information such as the current viewer context is also recorded. Post-processing of this object at the central administration site results in a complete trace of viewer actions, including the context in which each action is performed.
2. Automatic actions are recorded, such as recording the start or end of a program, or selecting a program to record based on viewer preferences. In addition, deletion of captured programs is also recorded. The post processing of this object at the central administration site results in a complete trace of the program capture actions performed by the client system, including programs that are permanently stored at any time.
3. Software installation actions, including results of reception, installation, and post reboot are recorded.
4. Exclusion of various types of hardware, including but not limited to power failure / resumption, device internal temperature profile, permanent storage access errors, memory parity errors and basic partition failures.

  Since all actions are recorded with a time stamp, it is possible to reconstruct the operation of the client system using linear time base ranking. This allows manual or automatic methods to act on the ordered list of events to correlate actions and behaviors. For example, if the predicted automatic action does not occur immediately after restarting with the new software, it can be assumed that the new software was incomplete.

TV viewing object processing system by central administration site Television viewing object source The client system has a single source of television viewing objects, the central administration site. The central administration site object database has many sources of television viewing objects.
1. Program guide information obtained from external sources is processed to create a consistent program guide object that indicates "program", "display", "channel", "network" and other related objects. This set of objects will have dependencies ("channel" depends on "network" and "display" depends on "program") and other interrelationships. When a complete and consistent set of objects is ready, it is added to the database as an atomic action.
2. New software, including new applications or modifications to existing software, is first implemented in a “software” viewing object. As described above, software can have interdependencies such as applications that depend on dynamically loaded libraries that must be reflected in the interrelationships of the related software objects. In other examples, two types of client systems may be used, each requiring a different software object. These software objects must have an attribute that indicates the type of system they are targeting. Once a consistent set of objects is available, it is added to the database as an atomic operation.
3. Each client system has its own private key embedded in it. The public key that matches this private key is loaded into the “client” managed object, along with other interesting information about this client such as the client type, the amount of storage in the system, etc. These objects are used to generate authentication objects as needed.
4. Aggregated operation program guide objects are added in the same way. In this case, however, the aggregate operation object must refer to a basic program guide object that already exists in the database. Other objects such as text descriptions, screen-based icons, and other information attributes are also attached to the aggregate operation object. Once a consistent set of auxiliary objects for the aggregate operation is available, it is added to the database as an atomic operation.
5. Data collected from the client system.

  It will be clear that there can be any number of sources of viewing objects, and this enumeration simply indicates the most basic possible source.

Operations of TV viewing objects A number of operations are possible in the centrally managed TV viewing object database. The following examples illustrate the types of processing that can be performed, but possible operations are not limited to these examples.
1. Many interesting statistical analysis tasks can be performed using various viewing objects.
1.1. By examining a large number of uploaded activity objects, it is possible to perform a comprehensive analysis of hardware reliability trends and failure modes. For example, the internal temperature can be related to the expected MTBF (Mean Time Between Failures) of the client device.
1.2. By examining a large number of uploaded viewing information, it is possible to derive demographic or psychological information about various populations of client devices. For example, the most watched television program can be correlated by a client device with a specific existing zip code.
1.3. Similarly, by examining a large number of viewing information objects, generating “rating” and “shared” values for a particular program in a completely automated manner that differs from existing program evaluation methods It is also possible.
1.4. There are many other examples of statistical analysis work that may be performed on a viewing object database. These examples do not limit the applicability of the present invention, but illustrate the spectrum of operations that may be performed.

2. Specialized aggregate computing objects can be automatically generated based on one or more attributes of all available viewing objects.
Such generation typically involves first extracting information of interest, such as program descriptions, actors, directors, etc. from each viewing object, and constructing a simple table of programs and attributes. It is executed by. An aggregate viewing object is then generated by selecting one or more attributes and adding them to aggregate those programs that match in some way.
These objects are then included in the slices that are generated for transmission (perhaps based on geographic or other information). Some specific examples of aggregation that may be made are as follows.
2.1. Aggregation based on events such as big league football games in big cities. In this case, all programs that can be viewed by the client device in or around the city, and the programs searched for the names of teams playing, names of coaches, names of main players, names of stadiums, etc. A description is collected. The matching program object is added to the aggregation, which is then sliced to be transmitted only to client devices in or around the city.
2.2. Aggregation based on people who are interested in many viewers. For example, an aggregation may be configured for all the movies of "John Wayne" that are scheduled for the next weekly broadcast.
2.3. Aggregation can be created based on viewing behavior. In this case, the uploaded viewing object is scanned for elements of general interest such as the type of program viewed, the actual program viewed, etc. For example, a “Top 10 List” summary of programs viewed on all client devices last week may be generated to include a display of these programs from next week onwards.
2.4. Aggregation based on clear selection by viewers. During the viewing of the program, the viewer may be given an opportunity to “vote” for the current program, probably based on four recognized attributes (scenario, activation, director, cinematography). Absent. This creates a viewing object that is uploaded later. These votes are then scanned to determine the overall rating of the program, which is transmitted to those who voted for their viewing.
2.5. The basic functionality of the present invention allows a service operator to provide a user of a client device with a pre-sorted and pre-selected group of related programs for viewing and selection. There are many other specific examples. These examples are not intended to limit the applicability of the present invention, but merely illustrate the spectrum of operations that may be performed.

  3. Manual methods can also be used to generate aggregate objects, and the process is often referred to as “authoring”. In this case, the person who creates the aggregate selects the program for explicit addition to the aggregate. It is then transmitted in the same way as described above.

  Obviously, the aggregate operation program object can also allow the recording of preference formulas or other information. These results can be uploaded to the central administration site to form the basis for the next round, such as aggregate generation or statistical analysis.

  This feedback loop closes the circuit between the service provider and the world of the viewer using the client device. This unique and novel way is a unique and mandatory way for service providers to present and encourage them to watch television programs of interest to individuals while maintaining reliable and consistent behavior. Provide a new way of viewing television by

Remote control of client systems Many consumer electronics devices already contain mass storage and its capacity is increasing. The amount of storage available in these devices is already enormous, and no limit is seen from the guideline that “doubles each year” for disk drives. Other methods of storage media such as CompactFlash, SmartMedia, Zip, Flash Memory Stick, MicroDrive, PocketDrive, and SuperDisk are also increasing in capacity each year.

  The clear control of this storage is to store its own TV show, music, images, etc. by the consumer. A use that continues to grow in application and importance, but less clear, is that the service provider controls this storage. The desire for service providers to control consumer physically owned storage is constantly increasing.

  Referring to FIG. 11, the distributed / telephone server 1101 of the present invention performs functions such as recording a specific program from a broadcaster 1102 in a client system, or a service provider uses a client It has the ability to send objects to the client system that instruct the systems 1103, 1104, 1105 to capture content. In addition to the maintenance and control aspects of the client system, any functional control that the user can control is contained in a set of objects called capture requests.

  Client systems 1103, 1104, 1105 can be any type of multimedia material (TV shows, movies, advertisements, products and service offerings, music, wireless, audio, e-books, etc.) transmitted over a broadcast or communication link ) Capability to capture and record.

The capture request object is sent from the distributed / telephone server to an individual or group of client systems. The following are some examples of capture request power:
* Capture requests allow the service provider of the present invention to reserve records for client systems 1103, 1104, 1105. These records can be video or data content.
* Capture request uses a program name and optionally a member affiliated station (eg, NBC) to identify the record. Identifying the affiliated affiliated station limits the recording to the identified affiliated affiliated station. If the program is shown to other affiliated stations, it is not recorded.
* A capture request has the ability to reserve a single record or to reserve all records in a series display.
* Capture requests have the ability to set attributes for the resulting record.
* Recording disk location-if the recording occupies the client system user's disk space or the disk (storage device) client system hidden space.
* Record Tuner Priority-whether these records will prevent other programs from being recorded due to tuner contention (on client systems with multiple input tuners).
* Record retention period-the suggested minimum time that a record must remain on the client system's disk before another record should delete it.
* Recording quality-Low, good, high, best recording quality.
* Capture request has the ability to create a period pass for the program series. The duration pass records every display of the program on the specified channel.
* Capture date can specify the expiration date. This date is then used to determine the date on which no recording is reserved. Also, after the expiration date, the capture request is removed from the client system disk.
* The service provider of the present invention has the ability to modify a capture request, and the client system changes all reservations of records from a previous capture request with a new option.
* The service provider of the present invention has the ability to target a specific client system to receive a specific capture request. This allows the present invention to reserve records for all subsets of the client system.

Referring to FIG. 12, the mechanism and process for remote storage of operations on the client system can be functionally divided into three parts:
* Front End Service 1201: This part is where capture requests are created using the authoring tool, where they are previewed, and how they are distributed to client devices Indicates. This also allows the decision on how client-side storage is allocated (split) to be edited and changed over time. The policy on how storage is used is edited in this front end.
* Client system 1205: The client system performs storage partitioning as directed by the service provider, captures media or objects for each capture request, and implements rotation and revocation mechanisms. The client itself does not maintain any policy on how storage is used. It simply implements the general mechanism and the policy is given by the service.
* Backend service 1206: The client system can report the success or failure of the request by the service, how the received data / medium is used, and distributed services 1202, 1203, 1204, for example Data / media redistributed via (image, video, music sharing service) can even be sent back.

A transparent "pull" that looks and feels like a "push"
To the client system 1205, this looks like content (data, media, etc.) “pushed” by the service provider. In practice, the service provider simply instructed the client device to pull or retrieve the content. This is transparent to the user of the client system 1205.

Remote authoring of capture requests The user of the client system 1205 expects to have complete control over the content stored in the client system 1205. For example, it tells the client system 1205 what to retrieve, when to capture content, when to delete content, and so on. The capture request mechanism gives this same level of control to remote authors.

The authoring tool 1201 allows authors to create capture request objects. The schema for this object specifies the metadata to identify:
* Where data / medium should be captured (in the form of a station / channel, URL or any other pointer to available media).
* When data / media should be captured (in broadcast or multicast content).
* Capture request priority-how important is the client system to preempt other activities to fulfill this request.
* Content priority-if local storage is not available, what other content must be displaced to make space.
* Content presentation-how this content should be presented in the client system / user-experience (rotation policy, display policy, revocation, single / multiple viewing, eligibility, etc.).
* Client-side goals-This request can include any number of criteria that must be met for the request to be valid. For example, this request may say “perform only for clients that have these capabilities” or “perform only for clients that already have this content available”. These abilities can be described using arbitrarily sophisticated query mechanisms.

Remote control of free space allocation In many cases, client storage so that some stores remain under the full control of the user and some stores are under the full control of the service provider. It is desirable to partition the storage of the system.

  The present invention allows service providers to change this partition at any time. This may be due to future policy changes (eg to give the user some space or remove some space) or new memory settings (eg when new, larger configurations or upgrades become available) Useful in that it allows changes to be addressed.

  The mechanism allows the author to create a “partition table” that identifies at the service provider how much storage should be allocated based on the size of the storage and specific client configuration.

Controlling which clients receive which capture requests When capture requests are distributed through services 1202, 1203, 1204, distributed service 1203 controls which client systems receive the capture requests.

  Service provider side tools allow identification by serial number, by client capabilities, such as by client service hierarchy. A table that places each client device into one or more capture request groups is maintained. A predetermined capture request can then be assigned to one or more of these groups.

Mechanism decoupled from policy It should be noted that the entire system is designed to retain the policy from the client system. All policies are determined by the author or automatically by the service provider. The client system simply executes commands or requests from the service provider.

Remotely controlled storage applications Remote control of client system storage is useful in many applications:
* Sales Promotion
* the mall
* Cineplex
* musics
* Image
* Video on demand
* Software
* Game
* Personal news, weather, sports, etc.

Remotely operated storage Remotely controlled storage can take many forms:
* Disk drive vs. all storage media: Hard disk drives are an obvious application for remote storage, but other media will work equally well. A music service can “push” promotional music to a music device whenever a private music device is hotly synchronized.
* Always on, sometimes on, infrequently on: This mechanism can also be applied to systems that are always connected to a service provider (eg, with an always-on Internet connection) (eg, phone calls every night). Client systems that are periodically connected to service providers (connected via wire) can also (for example,
It applies equally well to those systems that are rarely connected (when the PDA or camera is hot synchronized).

  Although the present invention has been described herein with reference to a preferred embodiment, those skilled in the art will described other applications herein without departing from the spirit and scope of the present invention. It will be readily appreciated that it can be substituted for. Accordingly, the invention should be limited only by the claims.

1 is a block schematic diagram of a preferred embodiment of a distributed television viewing management system of the present invention. 2 is a block schematic diagram of the structure of a viewing object stored in a computer for program access according to the present invention. Fig. 4 is a schematic block diagram illustrating how a schema for a viewing object is configured in computer storage for program access according to the present invention. FIG. 4 is a block schematic diagram illustrating an example graph of relationships between viewing objects describing information relating to the program of the present invention. FIG. 5 is a block schematic diagram illustrating an example of a relationship graph generated when processing viewer preferences to determine programs of interest according to the present invention. FIG. 6 is a block schematic diagram showing the input and storage space reservations for creating the record of the present invention. 7 is a flowchart illustrating steps taken to reserve a recording using the mechanism represented in FIG. 6 according to the present invention. 1 is a block diagram illustrating a preferred embodiment of the present invention in a boot strap system configuration of the present invention. 4 is a block schematic diagram of a bootstrap component determination flowchart of the present invention. 4 is a block schematic diagram of a bootstrap component determination flowchart of the present invention. 4 is a block schematic diagram of a decision flowchart for the software installation procedure of the present invention. FIG. 6 is a block schematic diagram of a preferred embodiment of the present invention for distributing content information to multiple client systems that record content from broadcast signals based on remote commands from a server of the present invention. 2 is a block schematic diagram illustrating an authoring and distributed system for controlling the storage and recording operations of the client system of the present invention.

Explanation of symbols

101 Central administration site
102 Client computing system
103 Slicing
104 Send
105 collection
106 Duplication
107 analysis
108 TV broadcasting
109 cable modem
110 data
111 Telephone communication server
200 attributes
201 type
202 value
203 Object ID
204 Reference count
300 attributes
301 Each attribute type
302 type
303 attributes
401 John Ford
402 byactor
403 bydirector
404 object
406 objects
407 TV "Network" Object
500 Incremental
501 preference object
502 aggregate object
503 preferences
504 tables
601 Space Schedule
602 Input Schedule
603 Program viewing preferences
604 Program guide object
800 storage space
801 hours
802 Initial bootstrap
803 disk drive
804 Boot sector
806 boot loader
807 system kernel
808 application software
809 scratch memory
1101 Distributed / telephone communication server
1102 Broadcaster
1103, 1104, 1105 client systems
1201 Front-end service
1202, 1203, 1204 Decentralized service
1205 client system
1206 Backend service

Claims (32)

Editing the capture request on the server;
Sending the capture request from the server to a client system in a plurality of client systems,
The capture request is received by the client system;
The capture request is a request issued by a server, instructing the client system to record specific content from a television broadcast signal or to record specific content from a source via a network; and
Monitor the capture request on the client system, tune one of the input tuners of the client system to the TV broadcast signal, and record the specific content in digital form on a local storage device Recording specific content from a source in a digital form on the local storage device over a network;
The client system, records and by the capture request and a recording by a request generated by a user using the local program guide, spontaneously reservation, comprising the steps,
Simultaneously recording content from at least two input sources to the local storage device;
A process that remotely controls the storage and operation of the client system that it comprises.   The process of claim 1, wherein the capture request directs the client system for time and channel to reserve the recording of specific content.   The process of claim 1, wherein the specific content is video or data content.   The process of claim 1, wherein the capture request identifies the specific content using the name of the program and optionally the name of the affiliate.   The process of claim 1, wherein the capture request reserves a record for one time or reserves a record for all times of a series.   The process of claim 1, wherein the capture request sets an attribute of the specific content to be recorded.   The process of claim 1, wherein the capture request sets a location of the recorded specific content in a storage device of the client system, and the location is either a user storage space or a system storage space. .   The process of claim 1, wherein when the client system has multiple input tuners, the capture request sets a priority for the recording tuner.   The process of claim 1, wherein the capture request specifies a suggested minimum time that a record should remain in the storage device of the client system.   The process of claim 1, wherein the capture request specifies a recording quality setting for the recording.   The process of claim 1, wherein the capture request instructs the client system to create a season pass for a series of programs, and the season pass records a display of a particular channel program each time.   The process of claim 1, wherein the capture request identifies its own expiration date.   The process of claim 1, wherein the server modifies a capture request previously received by the client system.   The process of claim 1, wherein the server targets a particular client system to receive a special capture request.   The process of claim 1, wherein the capture request identifies content to be transferred from the client system to a device connected to the client system. Editing the action request on the server;
Transmitting the operation request from the server to a client system in a plurality of client systems,
The operation request is received by the client system;
The operation request includes a partition map that instructs the client system to allocate a user space area and a system space area to a storage device of the client system;
Providing storage allocation means on the client system to partition the local storage device as specified in the partition map;
The process of remotely controlling the storage allocation of a client system comprising A module to edit capture requests on the server;
A module for transmitting the capture request from the server to a client system in a plurality of client systems,
The capture request is received by the client system;
A module for instructing the client system to record the specific content from a television broadcast signal or to record the specific content from a source via a network;
Monitor the capture request on the client system, tune one of the input tuners of the client system to the television broadcast signal, and store the specific content in local form on the local storage device Recording means on the client system for recording or recording specific content from a source in digital form on the local storage device via a network;
The client system, records and by the capture request, the user and a recording by request issued using the local program guide, spontaneously reservation, and reservation means,
Prepared,
The recording means records content from at least two input sources simultaneously to the local storage device;
A device that remotely controls the storage and operation of client systems.   18. The process of claim 17, wherein the capture request instructs the client system for time and channel to reserve the recording of specific content.   The process of claim 17, wherein the specific content is video or data content.   18. The process of claim 17, wherein the capture request identifies the specific content using the name of the program and optionally the name of the affiliate.   18. The process of claim 17, wherein the capture request reserves one record or reserves all series records.   The process of claim 17, wherein the capture request sets an attribute of the particular content to be recorded.   The capture request sets a location of the particular content to be recorded in a storage device of the client system, and the location is either a user storage space or a system storage space. 22 processes.   18. The process of claim 17, wherein when the client system has multiple input tuners, the capture request sets a priority for the recording tuner.   23. The process of claim 22, wherein the capture request specifies a suggested minimum time that a record should remain on the client system storage device.   23. The process of claim 22, wherein the capture request specifies a record quality setting for the record.   18. The process of claim 17, wherein the capture request instructs the client system to create a season pass for a series of programs, and the season pass records a display of a particular channel program each time.   The process of claim 17, wherein the capture request identifies its own expiration date.   The process of claim 17, wherein the server modifies a capture request previously received by the client.   The process of claim 17, wherein the server targets a particular client system to receive a special capture request.   The process of claim 17, wherein the capture request identifies content to be transferred from the client system to a device connected to the client system. A module for editing operation requests on the server;
The server is a module that transmits the operation request to one client system in a plurality of client systems,
The operation request is received by the client system;
A module that includes a partition map that instructs the client system to allocate user space and system space to a storage device of the client system;
Storage allocation means on the client system that partitions the local storage device as specified in the partition map;
A device for remotely controlling the storage and operation of a client system.