System and method for interfacing multiple electronic devices

Abstract

A method for operating a video processing system by receiving initial copyright information from a first source, storing the initial copyright information, receiving updated copyright information from a second source, and updating the stored copyright information in response to the updated copyright information. For example in one embodiment of the present invention, the initial copyright information for a program is received from an electronic program guide and updated copyright information is received along with the selected program. The video processing system may be programmed to operate in a first operating mode in response to the initial copyright information and the operating mode of the video processing system may be switched to a second operating mode in response to the updated copyright information.

Claims

What is claimed is:

1. A method of operating a video processing system comprising:

a. receiving initial copyright information associated with a selected program from a first source;

b. storing said initial copyright information and enabling said video processing system to process the selected program in a first operating mode in response to said initial copyright information;

c. receiving updated copyright information associated with said selected program from a second source; and

d. updating said stored copyright information in response to said updated copyright information and enabling said video signal processing system to process the selected program in one of said first and a second operating mode in response to said updated copyright information.

2. The method of claim 1 wherein said first copyright information is received by selecting an available program from a list of available programs provided by an electronic program guide, each of said available programs having associated initial copyright information.

3. The method of claim 2 further comprising the step of receiving said selected program, said selected program containing said updated copyright information.

4. The method of claim 3 wherein said first operating mode is a delay operating mode for digitally recording said selected program.

5. The method of claim 3 wherein said second operating mode is a mode for producing an analog recording of said selected program.

6. A method of operating a video processing system comprising:

a. receiving a list of available programs provided by an electronic program guide, each of said available programs having associated initial copyright information;

b. storing said initial copyright information;

c. selecting one of said available programs and enabling said video processing system to operate in a first operating mode in response to copyright information associated with said selected one of said available programs;

d. receiving said selected program, said selected program containing updated copyright information; and

e. updating said stored copyright information in response to said updated copyright information and enabling said video processing system to operate in said first or a second operating mode in response to said updated copyright information.

7. A method of operating a video processing system comprising:

a. receiving a list of available programs provided by an electronic program guide, each of said available programs having associated initial copyright information;

b. selecting one of said available programs;

c. programming said video processing system to operate in a first operating mode in response to said initial copyright information;

d. receiving said selected program, said selected program containing updated copyright information; and

e. switching said operating mode of said video processing system to a second operating mode in response to said updated copyright information.

Description

FIELD OF THE INVENTION

The invention involves systems for communicating between multiple electronic devices, such as consumer electronic devices, via interconnections such as digital data buses.

BACKGROUND

Data bus protocols such as the Consumer Electronics Bus, or CEBus, can be utilized for interconnecting consumer electronics devices such as television receivers, display devices, video-cassette recorders (VCR), and direct broadcast satellite (DBS) receivers. A bus protocol such as the CEBUS provides for communicating both control information and data. CEBus control information is communicated on a "control channel" having a protocol defined in Electronics Industries Association (EIA) specification IS-60. Control information for a particular application can be defined using a form of programming language known as CAL (Common Application Language).

Consumer electronics devices are becoming increasingly complex and provide an ever-increasing number of features. While coupling these complex devices together via a data bus may be necessary to provide a complete audio-video (A/V) system, doing so creates numerous problems. For example, certain features of one device may require interaction with one or more devices coupled to the bus. A capability of one device may be needed to complete a particular operation in another device. Conflicts between the needs of various devices may arise.

A specific example of an A/V system involving complex electronic devices coupled via a data bus is a system that includes a digital VHS format (DVHS) VCR, such as that being developed by Thomson Consumer Electronics, Inc., of Indianapolis, Ind., and a DSS® satellite receiver, manufactured by Thomson Consumer Electronics, Inc. The DVHS VCR can record either analog or digital signals. Various checks must occur before a recording can occur. For example, is the proper type of tape (analog or digital) loaded in the VCR? Is the user entitled to record a particular program: is the copyright status such that recording is permitted and has the user paid any fees required? Is the DSS® unit available to tune the desired program at the time a recording is to be made? Is the DSS® unit tuning the desired channel? In addition, a user must be informed, e.g., using on-screen display (OSD) messages, regarding the status of each device and what operations each device is performing. The complexity of each device and of the interactions involved creates a need for a robust system and method for communicating information between interconnected electronics devices.

SUMMARY OF THE INVENTION

The invention resides, in part, in recognizing the described problems and, in part, in providing a system and method for solving these problems. Generally, the present invention defines a method for operating a video processing system by receiving initial copyright information from a first source, storing the initial copyright information, receiving updated copyright information from a second source, and updating the stored copyright information in response to the updated copyright information.

In accordance with another aspect of the present invention, the first copyright information is received by selecting an available program from a list of available programs provided by an electronic program guide, each of said available programs having associated initial copyright information. The method further comprises receiving updated copyright information along with the selected program.

In accordance with still another aspect of the present invention, the method also comprises changing the operating mode of the video processing system from a first operating mode in response to the initial copyright information to a second operating mode in response to the updated copyright information. The first operating mode being a delay operating mode for digitally recording said selected program and the second operating mode being a mode for producing an analog recording of said selected program.

In accordance with still another aspect of the present invention, a method for operating a video processing system is defined by receiving a list of available programs provided by an electronic program guide, each of the available programs having associated initial copyright information, storing the initial copyright information, selecting one of the available programs, receiving updated copyright information along with the selected program, and updating the stored copyright information in response to the updated copyright information.

In accordance with yet another aspect of the present invention, a method for operating a video processing system is defined by receiving a list of available programs provided by an electronic program guide, each of the available programs having associated initial copyright information, selecting one of the available programs, programming the video processing system to operate in a first operating mode in response to the initial copyright information, receiving updated copyright information along with the selected program, and switching the operating mode of the video processing system to a second operating mode in response to the updated copyright information.

BRIEF DESCRIPTION OF THE DRAWING

The invention may be better understood by referring to the enclosed drawing in which:

FIGS. 1-3 show, in block diagram form, several embodiments of systems constructed in accordance with principles of the invention;

FIGS. 4-7 show, in block diagram form, various communication operations occurring between devices included in the systems shown in FIGS. 1-3; and

FIGS. 8-16 show, in flowchart form, the operation of systems shown in FIGS. 1-3.

DETAILED DESCRIPTION

FIG. 1 shows a system interfacing multiple electronic devices including D- VHS VCR 100, DSS unit 170, TV 130, another A/V device 150, antenna 140 for receiving broadcast signals, remote control 160 for providing a user interface to DSS unit 170, satellite dish antenna 190 for receiving DSS signals, and RF modulator 120. VCR 100 includes play/record circuitry 101 which receives signals to be recorded from luma/chroma processor 106. Circuitry 101 outputs signals during playback to luma/chroma processor 103. Processor 103 also includes switch 104 for routing signals during playback mode and during other modes as shown. VCR 100 also includes tuner 113 for tuning a desired channel from the signal produced by antenna 140 and line inputs 111 and 112 for receiving composite television signals from other A/V device 150 and line output 171 of DSS unit 170, respectively. Line output 107 of VCR 100 provides a composite television signal output to line input 132 of TV 130. Digital I/O to VCR 100 is provided via digital interface 110. On screen display (OSD) generator 105 produces signals representing user interface information, such as messages and status information, that can be coupled to TV 130 via switch 109 for display. Switches 102, 104, 109, and 114 provide for routing signals as need for each of the operating modes of VCR 100.

Also included in VCR 100 is control microprocessor (μp) 108 which is coupled to and controls functions within VCR 100, such as tuner 113, play/record unit 101 and the luma/chroma processors, via a bus internal VCR 100 (not shown in FIG. 1). Control μp 108 also controls the communication of control information to DSS unit 170 via digital I/O port 110. Digital A/V data is also communicated between VCR 100 and digital data port 172 of DSS unit 170. For example, programs received by DSS unit 170 can be recorded in digital form in response to a user requesting a digital recording by DSS unit 170 providing digital data for the program to VCR 100. Display of a digitally recorded program is accomplished during playback in VCR 100 by coupling the digital data produced by VCR 100 to port 172 of DSS unit 170 which proceeds to process the digital data and produce a composite television signal suitable for coupling to TV 130.

In addition to the features already described, DSS unit 170 includes tuner 178 for tuning a particular signal from the signals received by dish antenna 190. The output of tuner 178 is coupled to signal processing unit 174 which digitally processes the program signal and produces a variety of television signals. First, an S-video signal is produced and coupled to line output 173 which is coupled to line input 133 of TV 130. DSS unit 170 also produces a composite television signal which, as mentioned above, is coupled to VCR 100 via line output 171 of DSS 170. Remote control receiver 176 receives signals, such as infrared (IR) or RF signals from wireless remote 160. The remote control signals provide a user interface permitting a user to control DSS unit 170. Although not shown in FIG. 1, user interfaces such as remote control 160 could may also be provided for VCR 100 and TV 130.

Also included in DSS unit 170 is control μP 175 which is shown connected to various features of DSS unit 170 via a control bus. Microprocessor 175 produces OSD data for providing a visible display of user interface messages and information similarly to that produced by OSD generator 105 of VCR 100. Microprocessor 175 also controls features of DSS unit 170, including digital I/O port 172, in a similar manner to that described above in regard to VCR 100. In particular, as is explained in more detail below, control information communicated between VCR 100 and DSS unit 170 may include user interface information, such as OSD data, information regarding events scheduled in each device, and availability of resources.

The communication of such information allows either VCR 100 or DSS unit to check the status of the other device, obtain information regarding events scheduled in the other device, check for conflicts between events scheduled in DSS unit 170 and VCR 100 (for example, viewing of one program is scheduled in DSS unit 170 while programming of a different program is scheduled in VCR 100), and determine whether errors exist in the other device (e.g., an analog tape is loaded in VCR 100 when a digital recording is supposed to occur). Because either device can obtain such information from the other, either device can determine exception conditions (i.e., conflicts and errors) and can maintain a log of exception conditions that exist for one or both devices. The log can be provided to the user via OSD, for example, to inform the user of the status of the system.

In addition, one device can modify operations scheduled in another device that may involve an error or conflict in an effort to achieve the object of the original operation. For example, assume a user requests a digital recording, but loads an analog tape rather than a digital tape. Control processor 108 in VCR 100 will detect the error. However, control processor 175 in DSS unit 170 could also check the status of VCR 100 by sending appropriate commands to VCR 100 via the digital bus interface comprising digital I/O units 110 and 172. DSS unit 172 would then receive status information, could evaluate the information and detect the error, and could proceed to send appropriate commands to VCR 100 to modify the digital record operation to an analog record operation. Thus, while the user would not obtain a digital recording as desired, at least the user would have a recording of the program, thereby achieving at least part of the original object of the operation. A record of all such modifications of operations that occur in one, or both, devices could be maintained in one device and could be presented to a user, for example, in an OSD display, to inform the user of the changes.

FIGS. 2 and 3 show variations of the system shown in FIG. 1. More specifically, FIG. 2 shows the manner in which the system would be connected if TV 130 has only one line input rather than two as in FIG. 1. In FIG. 2, rather than signals from DSS unit 170 being provided directly to TV 130 via line output 173 as in FIG. 1, the system in FIG. 2 couples the output of DSS unit 170 to line input 132 of TV 130 via line output 171 of DSS unit 170 and line input 111, switch 109, and line output 107 of TV 130. Other aspects of FIG. 2 are substantially the same as in FIG. 1 and will not be described again.

In FIG. 3, TV 130 has only an antenna input and no composite video inputs. As a result, the output of DSS unit 170 in FIG. 3 is routed to the antenna input of TV 130 via switch 177 of DSS unit 170 and RF modulator 120. Other aspects of the system shown in FIG. 3 are substantially the same as in FIGS. 1 and 2 and will not be described again.

Another aspect of the system shown in FIG. 1 involves security issues such as those involving operations requiring a password. For example, before purchase of a pay-per-view event is permitted, it may be necessary to enter a password. Similarly, a password may be needed before viewing of programs with certain ratings is permitted. Normally, a password for such operations would be entered in the DSS unit. However, recording a pay-per-view event or recording an event having a rating that is restricted also requires checking a password. That is, when a user requests recording of a program, VCR 100 sends a request to DSS unit 170 to schedule tuning of the correct program at the correct time. The request causes DSS unit 170 to check authorization information such as whether a password is needed for the particular operation.

As explained in more detail below, the system shown in FIG. 1 provides for password validation as part of a device attempting to access "instance variables" (IV), e.g., VCR 100 attempting to schedule an event in DSS unit 170. Provisions of known systems, such as the CEBus control channel protocol, do not adequately support devices that have configurable security or devices that require a user to input a password when security authorization is required. The system and method described herein enhances security because passwords are not transmitted over a bus such as the CEBus. In addition, multiple devices such as VCR 100 and DSS unit 170 do not all have to know the password or words. Also, multiple passwords having different security levels associated with each password are supported. Timers within a device are not needed and, in particular, a requesting device can take as long as necessary to generate a password, thus supporting user inputted passwords. The exemplary password validation system includes an authentication feature that is implemented using the GE Encryption and Authentication Algorithm Version II as documented in EIA IS-60.4 Part 6 entitled "Application Layer Specification Appendix A".

As an example of password validation, consider a bus such as the CEBus. Three scenarios are possible for executing operations that may require password validation on the CEBus. The first scenario is a normal CEBus request, i.e., Implicit_Invoke, Explicit_Invoke, Conditional_Invoke, or Explicit_Retry. As shown in FIG. 4, a normal request is transmitted from a Node A to a Node B. Node B then determines that none of the operations in the request require a password. Thus, Node B will execute the request.

The second scenario is a normal request (Implicit_Invoke, Explicit_Invoke, Conditional_Invoke, or Explicit_Retry) that requires a password. As shown in FIG. 5, a normal request is transmitted from Node A to Node B. Node B determines that a password is required to execute part of the request. Node B returns a CAL error to Node A indicating that access to a secure instance variable (IV) was denied to Node A. Node A will then prompt the user for a password comprising, for example, from one to 18 characters (bytes). Any of the 18 bytes not entered will be set to zero. Node A then re-sends any operations that are necessary as an Authenticate Invoke packet using the above-mentioned authentication feature. In this packet, the message text is the operations required, the Authentication Key is the password, the Authentication Key ID is 0, and the Authentication Algorithm ID is 3. The packet may optionally be encrypted. Node A then transmits the Authenticate Invoke packet to Node B. Node B receives the request and checks validation using its known password(s) as the Authentication Key to the authentication algorithm. If Node B has several security levels with different passwords for each level, the validation will be checked using each password (starting with the lowest security level) until validation is successful or all known passwords are tried. The MT layer will let the Application Layer know which level of security was successful. If the Authenticate Invoke packet passes validation, Node B performs the operations and the Application Layer will check to see if the appropriate security level is now met. If validation is successful but the security level is not high enough to perform the operations, then Node B will return a CAL error that indicates access to a secured IV was denied. If the Authenticate Invoke packet fails validation for all known passwords, Node B sends a Reject Packet with a reject code of Failed_Authentication (33h).

A third scenario occurs when a CEBus authenticate request (Authenticate_Imp_Invoke, Authenticate_Exp_Inv, Authenticate_Cond_Inv, or Authenticate_Exp_Retry) packet is transmitted from Node A to Node B as shown in FIG. 6. In this scenario, Node A generates an authenticate request packet using the authentication algorithm with the Authentication Key being the password, the Authentication Key ID being 0, and the Authentication Algorithm ID being 3. The packet may optionally be encrypted. Node B receives the request and checks validation using its known password(s) as the Authentication Key to the authentication algorithm. If Node B has several security levels with different passwords for each level, the validation will be checked using each password (starting with the lowest security level) until validation is successful or all known passwords are tried. the MT layer will let the Application Layer know which level of security was successful. If the request passes validation, the request will be executed and the Application Layer will check if the appropriate security level is now met. If validation is successful but the security level is not high enough to perform the operation(s), then Node B will return a CAL error indicating that access to a secured IV was denied. If the request fails validation for all known passwords, a Reject packet with the reject code Failed_Authentication (33h) will be sent from Node B to Node A.

If no password exists at either node, a password of 18 zeros will be used. Node A can either request user input to generate the password or use a password stored in memory. Node B must have the password stored in memory or use the default password.

A specific example will now be explained in reference to the interface between VCR 100 and DSS unit 170 in FIGS. 1-3. A simplified version of the interface is depicted in FIGS. 7A through 7E. In FIG. 7A, a user enters a timer event into VCR 100 which requires the same event to exist on DSS unit 170. VCR 100 sends an Explicit Invoke to DSS unit 170 to create a timer event in DSS unit 170. DSS unit 170 determines that the timer event requires a password because the event exceeds a spending limit imposed on pay-per-view purchases, or exceeds a rating level, or the event is too far in the future. As shown in FIG. 7B, DSS unit 170 sends a CAL Error Result to VCR 100 indicating that access to a secured IV was denied. VCR 100 prompts the user for a password and uses the entered password to create an Authenticate Explicit Invoke packet. VCR 100 then sends the Authenticate Explicit Invoke packet to DSS unit 170 as shown in FIG. 7C. DSS unit 170 receives the Authenticate Invoke packet and validates it using the DSS unit's password(s). If the Authenticate Invoke passes validation and the security level is high enough to perform the operation, the timer event is successfully scheduled with DSS unit 170. As in FIG. 7D, DSS unit 170 sends a Result packet to VCR 100 with a COMPLETED TOKEN (FEh). If the Authenticate Invoke passes validation and the security level is not high enough to perform the operation, the timer event is not scheduled with DSS unit 170. In this case, DSS unit 170 sends a Result packet to the VCR with an ERROR TOKEN (FDh) and an erro code indicating that access to a secured IV was denied. If the Authenticate Response fails validation for all passwords of DSS unit 170, the timer event is not scheduled with DSS unit 170 and DSS unit 170 sends a Reject packet to VCR 100 with a reject code of Failed_Authentication (33h) as shown in FIG. 7E.

A detailed description of an embodiment implementing an interface system that provides the above described features follows. In addition to explanatory text, the following description provides CAL language (common application language) instructions that, for one skilled in the art, clearly define an exemplary embodiment of the above-described system. As a further aid to understanding the following description, FIGS. 8 through 16 provide flowcharts illustrating the system and methods described below.

The DVHS-VCR being developed by Thomson Consumer Electronics, Inc. has a standard A/V input, A/V IN, as well as the simplified Digital A/V Bus, DAV. This allows the DVHS-VCR to record and play back either standard analog or digital video and audio. The DAV bus uses a P1394 physical layer to send the digital bit stream. The CEBus uses a single ended common collector physical layer and the IS-60 communication protocol.

The analog input, AN IN, allows the user to monitor the DSS video from the VCR. This capability also allows the VCR to record the analog video and audio signal. The VCR has a default recording mode determined by an external switch located on the DVHS- VCR. The user preference setup and VCR media determine the recording mode on event by event basis.

The programmed timer event information shares information necessary to schedule an event between the DSS and DVHS-VCR. This includes, among other things, time, date, program duration, recording mode (analog or digital) and frequency of the timer program event.

The DVHS-VCR play back is recording dependent. The VHS play back occurs via a conventional VHS tape display system. Digital play back involves sending a digital bit stream to the DSS for decoding and display. There are four means to send the DSS audio and video to the TV. An S-Video TV is connected directly to the DSS S-Video output. A TV with only one A/V input uses the DVHS-VCR output video switch to route DSS video to the DVHS- VCR A/V OUT. The TV RF input can receive the DSS RF modulator output. Finally, a TV can receive and send a DAV bitstream.

The DVHS includes a CEBus application layer comprising seven CEBus contexts. All CEBus devices must contain the Universal Context. The DVHS-VCR also contains a Media Transport, Tuner, User Interface, A/V (Data Channel), Receiver Control, and Time Context. The DSS3 contains the Tuner, User Interface, A/V (Data Channel), Receiver Control, and Time Context.

Specific operational rules governing the playback and recording functions of the DSS-DVHS interface are described first.

The next section describes the DSS and VCR interaction necessary to schedule and carry out a pre-scheduled Program Timer Event from the VCR User Interface. The program timer recording event requires three separate functions: (1) Resource verification; (2) Password validation; (3) Copy Protection; (4) Error or conflict resolution; and (5) the record event.

In the case of establishing a DSS scheduled programmed event from the VCR, the VCR must retain the event and wait for the DSS to initiate the recording. The VCR can add or delete program event information in the DSS. The VCR may not remotely modify the DSS program events. The DSS updates the VCR when the DSS user interface deletes or changes a program timer event. If the event is deleted from the VCR user interface, the VCR deletes the event in the DSS. The VCR cannot modify the DSS program timer event data.

The DSS is responsible for initiating the record session. The DSS request VCR availability, Tape Type, switches the VCR's A/V input to DSS Video, and Hails for the DAV bus (digital recordings). The error and conflict resolution function involves the detection of a Tape Type miss-match, VCR schedule conflicts, or VCR not on the bus (no response).

The VCR maintains the scheduled event until it expires or is pre-empted by another programmed event timer. The steps required to setup a program timer event with the DSS from the DVHS-VCR are as follows.

STEP 1: DSS Availability Inquiry

The VCR verifies it has an available Program Timer Event Object. If there are no available events, the VCR generates an OSD message indicating the VCR program event scheduler is full.

The VCR sends an Explicit_Invoke message to all Data Memory class objects (16) in the DSS Time Context (05) requesting "If current_status=not programmed then getValue timer_object_id "m" (6D). The DSS returns a completed token "FE" plus the timer_object_id IV value "m" for those program event objects not in use ("C"=0). All other Program Timer Event Objects return FC. The VCR will use the first available program event timer.

The following CAL command is sent from the VCR to the DSS: