Patent Grant
11102619
The present invention is generally directed to subscriber based broadcast and communication systems, and in particular to various systems and methods for transmitting conditional access information to various subscribers or authorized users, and their various devices or combinations of devices, so that they can access the subscribed to content.
Conventionally, there are a few methods of effecting conditional access for a system with devices to be activated and/or authorized in the field. Broadcast systems, such as, for example, Satellite Digital Audio Radio Services (“SDARS”), transmit conditional access information in a 1-way manner and use multiple repeat methodologies to ensure receipt of such information by the devices. Point-to-point systems, such as, for example, telematics systems, generally transmit conditional access information in a 2-way manner and use acknowledgement methodologies to ensure receipt of such information by the intended devices.
Various multiple methods of data transport, and combinations thereof, may be used to initialize or update conditional access information on various devices. In an integrated device having both a broadcast receiver, such as an SDARS receiver, and a two-way communications transceiver, such as an LTE, 3G, 4G or 5G modem, or the like, conditional access information for the broadcast receiver may be sent to the transceiver, and then passed to the broadcast receiver, or vice versa. Additionally, for example, the broadcast receiver may be sent, over the broadcast communications channel, a “wake-up” message for the two-way transceiver, which message may then be passed to the two-way transceiver, so as to make it ready to receive conditional access information over the two-way communications channel, or vice versa. Moreover, because of the presence of a two-way communications path, various acknowledgements of conditional access status updates received and processed by the broadcast receiver may be sent—thus realizing a significant improvement over the current practice of sending multiple periodic messages over the broadcast channel, to insure (but never have confirmation of) receipt.
The patent or application file contains at least one drawing executed in color. Copies of this patent or patent application publication with color drawing(s) will be provided by the Office upon request and payment of the necessary fee.
The present invention will be more readily understood with reference to various exemplary embodiments thereof, as shown in the drawing figures, in which:
conditional access information is needed to access protected communications channels, such as, for example, subscription service satellite radio or television, or, for example, cellular phone and data access via a wireless communications network or the like. In general, a user device needs to receive conditional access information in order to receive and decode the subscribed to service, or to access the communications network. In one approach, this information can be sent initially, and then the device has and retains access until a follow-up message removing the access is sent.
Previous systems and methods for transmitting conditional access information to devices receiving satellite broadcast services generally relied solely on a broadcast transmission path to send the conditional access information. They tended to rely on a “controller” to make a determination as to whether or not it was connected to the subscription receiver, and then also relied on the same controller to request a deactivation to remove service (i.e., the ability to receive and decode it) from the subscription receiver.
In contrast, in exemplary embodiments of the present invention, a subscription receiver may, for example, require a periodic or quasi-periodic sequence of conditional access updates at either a substantially fixed, or some configurable, frequency in order to maintain its activation state. This is an inherently more secure method of ensuring that, for example, a radio authorized using this method will only remain authorized for an extremely limited time. In one implementation, using a tethered smart phone to a satellite radio receiver (as shown in
In what follows, the term “1-way” refers to a communications channel, where communications are sent from a source to one or more receivers, but the receivers cannot communicate back to the source, such as in a radio service broadcasting to various receivers. Similarly, the term “2-way” refers to a communications channel, such as a point to point system, where a first point can transmit to a second, and in turn the second point can transmit back to the first point, such as, for example, in cellular communications, satellite telephones, wired and wireless communications networks, vehicular communications over cellular and wireless networks, etc.
Various methods exist for effecting conditional access for a system with devices to be activated and/or authorized in the field. For example, broadcast systems, such as, for example, satellite radio services, transmit conditional access information in a 1-way manner and use multiple repeat methodologies to ensure receipt of such information by the devices. Point-to-point systems, such as, for example, Telematics, transmit conditional access information in a 2-way manner and use acknowledgement methodologies to ensure receipt of such information by the devices. Combining these modalities in a single device or in a pair of linked or tethered devices, whether linked or paired for a short time, such as via a docking device, or long term, such as by being provided in an integrated device (e.g., in a vehicle infotainment system) provides enhanced functionality.
In what follows, various exemplary implementations to send and acknowledge conditional access messages are described, for both a “single device” scenario as well as a “dual device” scenario. In particular,
Single Device Concept
In exemplary embodiments of the present invention, a single device system can, for example, include at least one 1-way receive path, and at least one 2-way transmit/receive path, a controller connected to all receive-only paths and all transmit/receive paths, and a non-volatile memory to store received conditional access information. In addition, such a system can interact with a conditional access control center that transmits using one or more transmit paths, and receives using one or more receive paths, the relevant conditional access information to a plurality of devices in the field. In various exemplary embodiments of the present invention, conditional access information can be transmitted using one or more paths, and one or more acknowledgements, if any, can be received using one or more paths. Various permutations of such a process are possible, and thus
As noted, a single device system as shown in
In all of these single device scenarios, as well as any dual device scenario described below, the initial request from a potential subscriber for radio authorization (what may be termed “Step 0”) is not shown. It is noted that such a request to the conditional access control center may be accomplished via a phone call to a listener care center (where the order could be processed by an automated voice response system, or, for example, by a human listener care agent), by accessing a web portal using any device capable of accessing the Internet, or by some user interface connected directly to the single combined device itself.
Thus, in the example scenario of
A similar communications process can be used to update the conditional access information for the one-way, or Broadcast Receiver Device (e.g., an in vehicle SDARS radio or the like) as shown in
Thus, in the example scenario of
Thus, in the example scenario of
It is noted that the scenario of
Thus, in the example scenario of
Finally,
Continuing with reference to
Thus, in the example scenario of
It is noted that the situation of
It is here noted that in the context of a future wake-up event, an exemplary device may send an acknowledgement of the fact that a future wake-up message was received, processed and stored so that the Central Conditional Access Center may have some reasonable degree of confidence that (i) it could begin transmitting the conditional access information at that future time, and that (ii) the intended target or targets for the messages would be awake to receive the messages. Clearly, the acknowledgement can only be sent during a period of time when the one-way device itself is awake prior to the scheduled wake-up time of the one-way device to receive the conditional access information. For example, a message could be sent over the two-way path on a Monday morning indicating that a given Broadcast Receiver Device (that is not always on) should wake up on the following Wednesday at 2 AM to receive an update. On Tuesday the Broadcast Receiver Device wakes up as part of normal operation, receives the future wakeup message from the two-way device and acknowledges receipt to the two-way device. Then the two-way device may, for example, send that acknowledgement to the conditional access center, and the 2 AM transmission from the Conditional Access Center to the one-way Broadcast Receiver Device can take place as scheduled. If the one-way Broadcast Receiver Device is never powered up, and/or never acknowledges receipt of the message, then the 2 AM broadcast is delayed, or, for example, in the case that the broadcast is targeted at multiple one-way devices, some of which may have acknowledged receipt while others have not, an alternate path can be used to update those specific one-way devices, such as, for example, using a two-way path of a device connected to them, such as the exemplary two-way device shown in
Additional Acknowledgements
It is further noted that in exemplary embodiments of the present invention, various other acknowledgements may be sent, as may be useful, in any of the single unit (e.g., CSU) or double unit (e.g., tethered smartphone to Broadcast Receiver Device in vehicle head unit) scenarios described herein. The illustrative acknowledgements shown in
Other examples of acknowledgements which may be useful, specifically in the case of very lengthy messages or conditional access code updates, which may be sent in pieces or as a plurality of individually identifiable messages or packets, can include, for example:
Dual Device Concept/Scenarios
In addition to the single-device scenarios of
As noted above,
Dual Device Concept:
In exemplary embodiments of the present invention, as illustrated in
A MAC algorithm, sometimes called a keyed (cryptographic) hash function, accepts as input a secret key and an arbitrary-length message to be authenticated, and outputs a MAC (sometimes known as a tag). The MAC value protects both a message's data integrity as well as its authenticity, by allowing verifiers (who also possess the secret key) to detect any changes to the message content.
As shown at 710, the Conditional Access Memory of the Broadcast Receiver Device should preferably have at least some portion which is fixed or only programmable with great difficulty (such as One-Time Programmable memory) containing the identity of the Radio and at least one fixed key.
In a preferred exemplary implementation, the Mobile Device, or more correctly, an application running on the Mobile Device, can, for example, send the Mobile Device Identity (2a) to (1) the Receiver Unit (or Radio Module), which in turn can secure the unique ID by encryption or appending a message authentication code. The Mobile Device can then send an (2b) Authorization Request 720—an example of which is shown at the bottom left of
In an alternate exemplary implementation, the next request time could be hard coded to a specific fixed offset from the expiration time, so that the next request is always sent, for example, N seconds before the authorization expires. Still alternatively, the expiration time could be a fixed offset M from the time that the authorization message was received by the device, such that each authorization message received would grant service for some fixed amount of time, such as, for example, 10 minutes, 15 minutes, 20 minutes, etc. In the above example, N could be, for example, 60, 90 or 120 seconds, or any other convenient increment.
Thus, as shown in
Multiple Two-way Devices Connected
With reference to
As shown at 910, the Conditional Access Memory of the Broadcast Receiver Device should preferably have at least some portion which is fixed or only programmable with great difficulty (such as One-Time Programmable memory) containing the identity of the Radio and at least one fixed key.
Similar to the scenario shown in
An example format of the Authorization Response 930 (sent at 4) is shown at the bottom right of
In this way, the Broadcast Receiver Device can support multiple smartphones. Moreover, even if the Broadcast Receiver Device is not an authorized SDARS receiver on its own, such as, for example, the owner of the vehicle has not yet subscribed to the SDARS service that the Broadcast Receiver Device receives, the authorization code received from the smartphone will enable it to be authorized for the specified period of time AND only authorized for the specific Two-Way Transceiver Device (smartphone) that requested such access. In other words, if the SDARS device is not authorized, it can, for example, provide channel 7 over Wi-Fi to the smartphone, but it will NOT play any channels on its own (in the vehicle, through the vehicle infotainment system). Alternatively, even if not authorized, if an authorized smartphone is tethered to it, while the two are tethered, the Broadcast Receiver Device can also play any channels on its own, under a “derivative” authorized subscription feature attached to the smartphone (i.e., the smartphone owner may use an unauthorized head unit to play content through the vehicle's infotainment system as long as the two are tethered and as long as access is authorized, as described above). Various contractual combinations and permutations of these functionalities and derivative or temporary authorized content access scenarios are possible in various exemplary embodiments.
It is noted that one smartphone may request access on behalf of a number of additional smartphone listeners, or for an unauthorized broadcast receiver itself, as long as its account with the SDARS broadcasting service allows such multiple device access. If multiple smartphones request and gain access independently, they may each be independently served by the Broadcast Receiver Device, and then if one leaves, this has no effect on the others' ability to listen. As can well be appreciated, many variations are possible, all dependent upon the level of access granted by the SDARS service to each smartphone owner; all such possibilities being within the scope of the present invention.
Sending Decryption Keys Over A Broadcast Receiver
In exemplary embodiments of the present invention, a large number of encrypted, device specific authentication certificates, for various types of devices needing conditional access, may be stored in a broadcast communication receiver device associated with one or more such devices, and using a decryption key, then be transmitted over a broadcast communication path on a periodic basis (e.g. weekly, monthly or quarterly, etc.) to enable the broadcast receiver to unlock one or more certificates, or bundles of certificates, for use in various types of in-vehicle, as well as general two-way network communications. It is noted that the decryption key referred to above is a relatively small amount of data, and it is this decryption key entity that is transmitted over the broadcast path. Once received, the key can then be used to decrypt the (relatively large) certificate that is already stored in a given device.
For example, a given device that regularly updates its access to a network, such as, for example, a V2V device, in-vehicle communications device, or more generally, any other “guest” or temporary user of a large number of users network, may, for example, have three years of certificates stored in it at the time of “personalization” before being deployed to the field. These certificates may be used at some finite rate, say, for example, a rate of 20 per week and then expire over time. In order to be renewed, such a device must communicate with “infrastructure” to request additional certificates. However, at least some vehicles may operate in remote areas where the ability communicate with such infrastructure devices is rare or non-existent. Increasing the number of pre-stored certificates increases the potential number of certificates that must be revoked if one of the in-vehicle or other devices is “rogue” (e.g., transmitting false and/or misleading information with the intent of disrupting traffic) so that other vehicles, or other participants in the multi-user network, will no longer trust the device and all of its certificates. A better solution is to store additional certificates in a way that they can be efficiently released over time with messages broadcast over a satellite path.
Thus, for example, a satellite receiver may have ten years' worth of certificates (such as, for example, 20 certificates per week, for 52 weeks per year, for 10 years, or 10,400 total certificates). Each bundle of 20 certificates can, for example, have a validity period of one week, and each week the satellite transmission system could send messages to radios (or groups of radios) containing the key necessary to decrypt that week's worth of certificates for use, in the event that they were unable to replenish their certificates through the normal network infrastructure. Alternative implementations can, for example, bundle the certificates in groups with longer validity periods, such as, for example, 20 certificates with a one month validity period, and/or in various different size groups. In a further refinement of this approach, the key used to decrypt the certificates can be designed such that each decryption key could be used to decrypt the certificates in one group as well as evolving the decryption keys required for all previous certificate groups. In this way, transmitting a single decryption key to a single device could unlock a variable number of certificates for future use. Thus, for example, transmitting the “July 2020 group key” would unlock certificates for July 2020, June 2020, May 2020, and so forth, back to the current month.
Exemplary Implementations
The various illustrative systems, methods, logical features, blocks, modules, components, circuits, and algorithm steps described herein may be implemented, performed, or otherwise controlled by suitable hardware known or later developed in the art, or by software executed by a processor (also referred to as a “processing device” and also inclusive of any number of processors), or by both. A processor may perform or cause any of the processing, computational, method steps, or other system functionality relating to the processes/methodologies and systems disclosed herein, including analysis, manipulation, conversion or creation of data, or other operations on data. A processor may include a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, server, or any combination thereof. A processor may be a conventional processor, microprocessor, controller, microcontroller, or state machine. A processor can also refer to a chip, where that chip includes various components (e.g., a microprocessor and other components). The term “processor” may refer to one, two or more processors of the same or different types. It is noted that the terms “computer” or “computing device” or “user device” or the like may refer to devices that include a processor, or may refer to the processor itself. Software may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium. A “memory” may be coupled to a processor such that the processor can read information from and write information to the memory. The storage medium may be integral to the processor. Software may be stored on or encoded as one or more instructions or code on a computer-readable medium. Computer-readable media be any available storage media, including nonvolatile media (e.g., optical, magnetic, semiconductor) and carrier waves that transfer data and instructions through wireless, optical, or wired signaling media over a network using network transfer protocols. Aspects of systems and methods described herein may be implemented as functionality programmed into any of a variety of circuitry, including. Aspects may be embodied in processors having software-based circuit emulation, discrete logic, custom devices, neural logic, quantum devices, PLDs, FPGA, PAL, ASIC, MOSFET, CMOS, ECL, polymer technologies, mixed analog and digital, and hybrids thereof. Data, instructions, commands, information, signals, bits, symbols, and chips that may be referenced throughout the above description may be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof. Computing networks may be used to carry out aspects and may include hardware components (servers, monitors, I/O, network connection). Application programs may carry out aspects by receiving, converting, processing, storing, retrieving, transferring and/or exporting data, which may be stored in a hierarchical, network, relational, non-relational, object-oriented, or other data source. “Data” and “information” may be used interchangeably. The words “comprise,” “comprising,” “include,” “including” and the like are to be construed in an inclusive sense (i.e., not limited to) as opposed to an exclusive sense (i.e., consisting only of). Words using the singular or plural number also include the plural or singular number respectively. The words “or” or “and” cover any of the items and all of the items in a list. “Some” and “any” and “at least one” refers to one or more. The term “device” may comprise one or more components (e.g., a processor, a memory, a screen). The terms “module,” “block,” “feature,” or “component” may refer to hardware or software, or a combination of both hardware and software, that is configured to carry out or otherwise achieve the functionality associated with those modules, blocks, features or components. Similarly, features in system and apparatus figures that are illustrated as rectangles may refer to hardware or software. It is noted that lines linking two such features may be illustrative of data transfer between those features. Such transfer may occur directly between those features or through intermediate features even if not illustrated. Where no line connects two features, transfer of data between those features is contemplated unless otherwise stated. Accordingly, the lines are provide to illustrate certain aspects, but should not be interpreted as limiting.
Any suitable programming language can be used to implement the routines of particular exemplary embodiments including, but not limited to, the following: C, C++, Java, JavaScript, Python, Ruby, CoffeeScript, assembly language, etc. Different programming techniques can be employed such as procedural or object oriented. The routines can execute on a single processing device or multiple processors. Although the steps, operations, or computations may be presented in a specific order, this order may be changed in different particular embodiments. In some particular embodiments, multiple steps shown as sequential in this specification can be performed at the same time
Particular embodiments may be implemented in a computer-readable storage device or non-transitory computer readable medium for use by or in connection with the instruction execution system, apparatus, system, or device. Particular embodiments can be implemented in the form of control logic in software or hardware or a combination of both. The control logic, when executed by one or more processors, may be operable to perform that which is described in particular embodiments.
Particular embodiments may be implemented by using a programmed general purpose digital computer, by using application specific integrated circuits, programmable logic devices, field programmable gate arrays, optical, chemical, biological, quantum or nanoengineered systems, components and mechanisms may be used. In general, the functions of particular embodiments can be achieved by any means as is known in the art. Distributed, networked systems, components, and/or circuits can be used. Communication, or transfer, of data may be wired, wireless, or by any other means.
It will also be appreciated that one or more of the elements depicted in the drawings/figures can also be implemented in a more separated or integrated manner, or even removed or rendered as inoperable in certain cases, as is useful in accordance with a particular application. It is also within the spirit and scope to implement a program or code that can be stored in a machine-readable medium, such as a storage device, to permit a computer to perform any of the methods described above.
As used in the description herein and throughout the claims that follow, “a”, “an”, and “the” includes plural references unless the context clearly dictates otherwise. Also, as used in the description herein and throughout the claims that follow, the meaning of “in” includes “in” and “on” unless the context clearly dictates otherwise.
While there have been described methods for transmitting conditional access information, it is to be understood that many changes may be made therein without departing from the spirit and scope of the invention. Insubstantial changes from the claimed subject matter as viewed by a person with ordinary skill in the art, no known or later devised, are expressly contemplated as being equivalently within the scope of the claims. Therefore, obvious substitutions now or later known to one with ordinary skill in the art are defined to be within the scope of the defined elements. The described embodiments of the invention are presented for the purpose of illustration and not of limitation.
The above-presented description and figures are intended by way of example only and are not intended to limit the present invention in any way except as set forth in the following claims. It is particularly noted that the persons skilled in the art can readily combine the various technical aspects of the various elements of the various exemplary embodiments that have been described above in numerous other ways, all of which are considered to be within the scope of the invention.
This is a continuation of U.S. patent application Ser. No. 15/013,006, filed on Feb. 2, 2016 which is a continuation-in-part of international application PCT/US2014/049650, filed on Aug. 4, 2014, which published as WO 2015/017867, which itself claims priority to United States Provisional Patent Applications (i) No. 61/861,678, filed on Aug. 2, 2013, entitled “HYBRID TRANSPORT CONDITIONAL ACCESS METHODS AND SYSTEMS,” and (ii) 61/947,955, entitled “SATELLITE PROVISIONING OF CELL SERVICE,” filed on Mar. 4, 2014, the entire disclosure of each of which is hereby incorporated herein by this reference. The U.S. patent application Ser. No. 15/013,006, filed on Feb. 2, 2016 also claims priority to continuation-in-part of international application PCT/US2015/018792, filed on Mar. 4, 2015, which published as WO 2015/134644, entitled “SATELLITE PROVISIONING OF CELL SERVICE,” which itself claims priority to U.S. Provisional Patent Application No. 61/947,955, entitled “SATELLITE PROVISIONING OF CELL SERVICE,” filed on Mar. 4, 2014, the entire disclosure of which is hereby incorporated herein by this reference.
| Number | Name | Date | Kind |
|---|---|---|---|
| 20020021465 | Moore, Jr. | Feb 2002 | A1 |
| 20020101991 | Bacon | Aug 2002 | A1 |
| 20030066075 | Bahn | Apr 2003 | A1 |
| 20040088537 | Swander | May 2004 | A1 |
| 20060041891 | Aaron | Feb 2006 | A1 |
| 20060156416 | Huotari | Jul 2006 | A1 |
| 20060294250 | Stone | Dec 2006 | A1 |
| 20070033419 | Kocher | Feb 2007 | A1 |
| 20080112405 | Cholas | May 2008 | A1 |
| 20080134309 | Qin | Jun 2008 | A1 |
| 20080313691 | Cholas | Dec 2008 | A1 |
| 20110239287 | Pak | Sep 2011 | A1 |
| 20110302324 | Karaoguz | Dec 2011 | A1 |
| 20110302624 | Chen | Dec 2011 | A1 |
| Number | Date | Country | |
|---|---|---|---|
| 20190281462 A1 | Sep 2019 | US |
| Number | Date | Country | |
|---|---|---|---|
| 61861678 | Aug 2013 | US | |
| 61947955 | Mar 2014 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 15013006 | Feb 2016 | US |
| Child | 16358429 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | PCT/US2014/049650 | Aug 2014 | US |
| Child | 15013006 | US | |
| Parent | 16358429 | Mar 2019 | US |
| Child | 15013006 | US | |
| Parent | PCT/US2015/018792 | Mar 2015 | US |
| Child | 16358429 | US |
