- 47—byte1 sync
- If—byte2 pid high
- ff—byte3 pid low
- 20—byte4 all adaptation
- b7—byte5 adaptation len
- 80—byte6 discontinuity flag
- 00—byte7 to n original non-MPEG packet
- 00—byte n+1 to 188 padding
  As indicated in the packet structure above, the first six bytes comprise a set of bytes that incorporates a discontinuity flag while the remaining 7 to n bytes correspond to the non-MPEG payload portion of the MPEG packet. Bytes n+1 through 188 comprise stuff bytes or padding. In one embodiment the variable n corresponds to the value 130 when one or more DirecTV packets are received by the circuitry (ASIC) in the set-top-box. As a consequence, bytes7 to136 are reserved for use by the DirecTV packet. In one embodiment, the payload is identified as non-MPEG when the discontinuity flag (byte #6) is set; as a result, the non-MPEG data passes through to the circuitry (e.g., ASIC) where processing occurs. In one embodiment, as may be described in the exemplary packet structure shown above, the header is located within the first six bytes of a 188 byte MPEG packet. The headers and padding encapsulate or packetize a non-MPEG packet in order to “spoof” or “fool” the POD card.

A 188 byte MPEG packet may be further padded with an additional 12 byte header in an operation that is performed by the circuitry (e.g., ASIC), generating a 200 byte packet. This 12 byte header comprises an LTSID tag or identifier that may be used by the POD card and the circuitry (e.g., ASIC) to further identify and/or appropriately treat the encapsulated 188 byte packet as either a non-MPEG packet or MPEG packet. Each 188 byte packet generated by the circuitry (ASIC) is padded with a 12 byte header prior to transmission to the POD card. The 12 bytes that are added to a 188 byte MPEG packet create a 200 byte packet that complies with the OpenCable™ Advanced Multi-Stream POD Interface Specification and/or the OpenCable™ Multi-Stream CableCARD Interface Specification. When the received data comprises non-MPEG data, such as DirecTV data, for example, the non-MPEG data may be encapsulated to form a 188 byte MPEG packet in order to facilitate processing or handling by the POD card. In one embodiment, the LTSID tag identifies the processing device that performs the processing and/or the type of processing to be performed on its 188 byte packet. Processing, such as security related processing, may be performed, for example, by the POD card if the 188 byte packet is associated with MPEG data. In one embodiment, the LTSID tag may be configured to a value such that the 188 byte packet is treated as MPEG data. In such an instance, processing (e.g, security related processing) of the 188 byte packet is performed at the POD card. In another embodiment, the LTSID is configured to a value such that the non-MPEG data bypasses any processing performed by the POD card. Instead, the POD card transparently passes or returns the non-MPEG data back to the circuitry (ASIC) where processing is performed. In one embodiment, the processing at the POD card or circuitry (e.g., ASIC) may comprise one or more encryption and/or decryption operations. In one embodiment, the LTSID tag may be configured to a value that indicates the type of security processing used and the devices used to perform the processing.

In one or more embodiments, the POD card may be programmed to identify the LTSID tag in each packet it receives in order to perform one or more specific security functions and/or operations. The bits for each LTSID tag may be configured to a specific value such that the POD card may appropriately recognize and perform one or more specific operations. In one embodiment, the LTSID may be used to specify one of 256 different types (e.g., using 8 bits) of possible operations. It is contemplated that one or more of these operations comprises security related operations that involve subscriber authentication and/or verification.

FIG. 3A is an operational flow diagram illustrating a method of processing MPEG and non-MPEG data packets, performed by a circuitry, such as the application specific integrated circuit (ASIC) previously described in relation to the embodiment ofFIG. 1, in accordance with an embodiment of the invention. The MPEG and non-MPEG data packets are provided by a video provider (such as a cable operator, satellite provider, or telecommunications carrier) to a set-top-box (such as a digital cable receiver or set-top-terminal) that utilizes the circuitry (ASIC), in accordance with an embodiment of the invention. Atstep304, the set-top-box (STB) receives video from the video provider. The video received from the video provider may comprise MPEG and/or non-MPEG video. Next, atstep308, the circuitry, such as logic circuitry implemented using an application specific integrated circuit, for example, processes the received video data. After processing, atstep312, the circuitry determines whether the received video comprises MPEG or non-MPEG data. If the video data comprises one or more 188 byte MPEG packets, the process proceeds withstep316. Atstep316, a 12 byte header is appended to each of the 188 byte MPEG packets. The 12 byte header comprises an LTSID field whose value is appropriately configured. The value may comprise an 8 bit value (one byte) that may select one of 256 possible operations which may be performed by a POD card. The value configured into the LTSID field may indicate to the POD card that the packet's payload comprises MPEG data. The LTSID field may comprise one byte, such as the first byte, within the 12 byte header. The 12 byte header is appended to the 188 byte MPEG packet in order to attain a 200 byte packet that conforms to the OpenCable™ Advanced Multi-Stream POD Interface Specification and/or the OpenCable™ Multi-Stream CableCARD Interface Specification. Thereafter, atstep320, the 200 byte packet is transmitted to the POD card, where processing may occur. Referring back to step312, if the circuitry determines that the received video comprises one or more non-MPEG packets, the process proceeds withstep324. Atstep324, (188-n) bytes are added to the one or more non-MPEG packets in order to attain one or more 188 byte MPEG packets. The (188-n) bytes may comprise a discontinuity flag field, of which the discontinuity flag field may comprise 6 bytes. As described previously, the discontinuity field flag may be configured to indicate to the POD card that its associated payload comprises non-MPEG data. As a consequence, processing of the non-MPEG data may be bypassed by the POD card and performed instead at the circuitry (e.g., ASIC) of the STB. Atstep328, a 12 byte header is appended to each of the 188 byte MPEG packets, thereby generating a 200 byte packet. The 12 byte header may comprise an LTSID field whose value may be appropriately configured. The value may comprise an 8 bit value (one byte) that may select one of 256 possible operations that may be performed by a POD card. The value configured into the LTSID field may indicate to the POD card that the video payload which follows comprises non-MPEG data. The LTSID field may comprise one byte, such as the first byte, within the 12 byte header. The header is appended to the 188 byte MPEG packet in order to attain a 200 byte packet that conforms to the OpenCable™ Advanced Multi-Stream POD Interface Specification and/or the OpenCable™ Multi-Stream CableCARD Interface Specification. Thereafter, atstep320, the 200 byte packet is transmitted to the POD card, where additional processing may occur.

FIG. 3B is an operational flow diagram illustrating a method of processing MPEG and non-MPEG video data that has been packetized into 200 byte packets by the circuitry (e.g., ASIC), of the set-top-box (STB), described in relation toFIG. 1, in accordance with an embodiment of the invention. Atstep332, a POD card of the STB parses and reads a 12 byte header that encapsulates each 188 byte MPEG packet. Atstep336, the POD card determines whether an LTSID field is present within the parsed header. If an LTSID field is present, the LTSID field is read by the POD card. Atstep340, the POD card determines whether the LTSID field is set to an appropriate value. If the LTSID field is not set, processing is performed at the POD card, as indicated atstep344. The processing, such as security related processing, may be performed at the POD card. The security related processing may involve user authentication and/or verification. Otherwise, the process continues withstep348. Atstep348, the POD card may examine the remaining 188 byte payload or 188 byte packet. In a representative embodiment, the POD card may examine the 188 byte packet to determine if it comprises a valid MPEG packet (i.e., whether the packet conforms to ISO/IEC 13818-1 (2000) Information Technology—Generic coding of moving pictures and associated audio information: Systems). If atstep348, the POD card is configured to examine the 188 byte payload, the process continues withstep356. Otherwise, if the POD card is configured to not examine the 188 byte payload, the next step continues withstep352, at which, the packet is processed by the ASIC. (It is contemplated that certain POD cards may be capable of further examining the 188 byte packet, even after it is determined that processing at the POD card should be bypassed, by way of using the LTSID field.) Atstep356, the POD card parses and reads the header of the 188 byte packet. The header of the 188 byte packet, as previously described, may comprise a discontinuity flag which utilizes 6 bytes. Next, atstep360, the POD card determines whether the 188 byte packet constitutes a valid MPEG packet. If the packet is a valid MPEG packet, then the next operation occurs atstep364, at which the discontinuity flag is read from a 6 byte discontinuity flag field. The discontinuity flag field may provide a value that determines whether its associated payload is processed at the POD card or at the circuitry (ASIC) of the STB. Atstep368, the POD card determines whether to bypass processing of the packet's payload to the circuitry (e.g., ASIC) of the STB or to perform processing at the POD card, after reading the 6 byte discontinuity flag field. The processing may involve security related processing such as user authentication and/or verification. Atstep372, the processing is performed at the circuitry (ASIC) if the discontinuity flag field is set to an appropriate value. If the discontinuity flag field is not set to an appropriate value, processing is performed at the POD, as shown instep376. If, atstep360, it is determined that the 188 byte packet is an invalid MPEG packet, the next step commences with step380. At step380, the POD card may perform one or more error handing operations. The POD card may perform one or more error handling operations or error checking functions, as a means for detecting communication errors, for example. The one or more error checking functions may comprise a verification of packet length, for example. It is contemplated that certain POD cards may be capable of performing such error handing operations. In another representative embodiment, one or more error handling operations may be incorporated into

steps

332,336, and/or340. The error handling operations may comprise verifying the length and contents of the 200 byte packet received by the POD card, for example.

While the invention has been described with reference to certain embodiments, it will be understood by those skilled in the art that various changes may be made and equivalents may be substituted without departing from the scope of the invention. In addition, many modifications may be made to adapt a particular situation or material to the teachings of the invention without departing from its scope. Therefore, it is intended that the invention not be limited to the particular embodiment disclosed, but that the invention will include all embodiments falling within the scope of the appended claims.