Patent Application
20090199283
This invention relates to network communications and, more particularly, to wirelessly receiving broadcast signals using intelligent cards.
Portable electronic devices and tokens have become an integrated part of the regular day to day user experience. There is a wide variety of common portable and handheld devices that users have in their possession including communication, business and entertaining devices such as cell phones, music players, digital cameras, smart cards, memory token and variety of possible combinations of the aforementioned devices and tokens. All of these devices share the commonality that consumer are accustomed to carrying them with them most of the time and to most places. This is true across the various demographics and age groups regardless of the level of the sophistication of the consumer, their age group, their technical level or background.
These common handheld devices offer options for expandable memory. Micro Secure Digital (microSD) is the popular interface across high-end cellphones while SD and MultiMediaCard (MMC) interfaces are also available in limited models. MicroSD is the least common denominator supported by the majority of these devices and tokens (in terms of size). In addition, adaptors are available to convert a MicroSD into MiniSD, SD, MMC and USB Although most popular MP3 player (iPOD) offer's a proprietary interface, competing designs do offer standard interfaces. Digital cameras offer mostly SD and MMC while extreme Digital (xD) is another option. Micro and Mini versions of these interfaces are also available in several models. Mini-USB is increasingly available across cellphones, digital cameras and MP3 players for synchronization with laptops.
Various content providers and service providers are developing digital broadcast networks that will be able to provide TV like viewing channels on mobile devices. Several new mobile handset models are also being developed that embed a miniature broadcast receiver that can receive these digital broadcast signals and use a media player software to offer channel viewing to the consumer. In order to secure access and provide access to premium content like movies, subscription based pay-TV content and music albums, the service provider uses a specially designed conditional access system (CAS) which is able to verify the user's subscription and unscramble premium content before rendering it for viewing.
Such capability can be added to the PC, by adding a hardware transceiver that can be added to the PC using peripheral interfaces such as USB, PCMCIA, PCIA or mini-PCI (and others). To control access, the conditional access system is implemented in the same hardware and comprises of a smart card that securely stores the user's identity and his subscription privileges. In addition, the service provider provides an Electronic Service Guide that the user can use to select the channels that he wishes to view. This software is typically installed on the PC together with the access driver for the hardware. In some options, the default channel guide provided by the operating system of the PC (such as Windows Vista/MacOS etc.) can be used.
There are other consumer devices such as smartphones, MP3 players, game players and portable vides players that may make use of broadcast content connection for useful applications. Since the hardware for the broadcast receiver and the conditional access system is specialized and requires a dedicated processor to receive and unscramble content, many of these devices may not be upgraded with an embedded broadcast reception capability. In addition, these devices also lack PCMCIA or USB type expansion slots where broadcast receiver and CAS hardware could be inserted. These devices also typically lack the slot for a hardware security token such as a smart card in order to provide secure access to a fee based premium TV content. These devices also need memory for the users to record content captured through these devices. The need for such memory is growing at a rapid rate.
The present disclosure is directed to a system and method for wirelessly receiving broadcast signals using intelligent cards. In some implementations, a service card includes a physical interface, a communication module, memory, and a service module. The physical interface connects to a port of a mobile host device. The mobile host device includes a Graphical User Interface (GUI). The communication module wirelessly receives broadcast signals encoding content. The memory stores user information used to decrypt the encoded content independent of the mobile host device. The stored information is associated with a content provider. The service module decrypts the encoded content in response to at least an event and presents the content through the GUI of the mobile host device.
The details of one or more embodiments of the invention are set forth in the accompanying drawings and the description below. Other features, objects, and advantages of the invention will be apparent from the description and drawings, and from the claims.
Like reference symbols in the various drawings indicate like elements.
At a high level, the system 100 includes the mobile devices 102a and 102b and the content provider 104 coupled to the network 106. The mobile device 102 includes a GUI 108 for providing presenting content and a service card 110 for independently converting foreign content to forms compatible with the mobile device 102. In some implementations, the service card 110 may selectively switch antenna on and off in response to an event such as a selection of a graphical element using the GUI 108. The network 108 includes a content distribution stations 112a and 112b (e.g., broadcast tower, satellite, IP broadcast tower) for broadcasting content to the service cards 110.
Each mobile device 102 comprises an electronic device operable to interface with the service card 110. For example, the mobile device 102 may receive and transmit wireless and/or wireless communication with the system 100. As used in this disclosure, the mobile devices 102 are intended to encompass cellular phones, data phones, pagers, portable computers, SIP phones, smart phones, personal data assistants (PDAs), digital cameras, MP3 players, camcorders, video player, game player, one or more processors within these or other devices, or any other suitable processing devices capable of communicating information with the service card 110. In some implementations, the mobile devices 102 may be based on a cellular radio technology. For example, the mobile device 102 may be a PDA operable to wirelessly connect with an external or unsecured network. In another example, the mobile device 102 may comprise a smartphone that includes an input device, such as a keypad, touch screen, mouse, or other device that can accept information, and an output device that conveys information associated with a transaction with the offline store 102, including digital data, visual information, or GUI 108.
The GUI 108 comprises a graphical user interface operable to allow the user of the mobile device 102 to interface with at least a portion of the system 100 for any suitable purpose, such as viewing content channels and/or displaying the Electronic Service Guide (ESG). Generally, the GUI 108 provides the particular user with an efficient and user-friendly presentation of data provided by or communicated within the system 100 and/or also an efficient and user-friendly means for the user to self-manage settings and access channels offered by the content provider 104. The GUI 108 may comprise a plurality of customizable frames or views having interactive fields, pull-down lists, and/or buttons operated by the user. The term graphical user interface may be used in the singular or in the plural to describe one or more graphical user interfaces and each of the displays of a particular graphical user interface. The GUI 108 can include any graphical user interface, such as a generic media player or touch screen, that processes information in the system 100 and presents the results to the user.
The service card 110 can include any software, hardware, and/or firmware configured to receive broadcast signals from the distribution stations 112. For example, the service card 110 may receive content broadcasted by the content provider 104 and translate, map or otherwise convert the received content to forms viewable with the mobile device 102. In some implementations, the service card 110 can present received content through the GUI 108. In some implementations, the service card 110 may include one or more chipsets that execute an operating system and security processes to receive broadcast signals independent of the mobile host device 102. In doing so, the mobile device 102 may not require additional hardware, software, and/or firmware to present foreign content such as digital TV, IP-TV, satellite radio, satellite TV, and/or other broadcast services. In some implementations, the service card 110 may execute one or more of the following: wirelessly receive signals broadcasted by the distribution stations 112; determine subscription levels of the card 110 based, at least in part, on locally-stored user information; descramble content available to the user in accordance with the subscription levels; translate between broadcast protocols (e.g., DVB, FLO, MBMS, DMB) and protocols compatible with the service card 110; translate between service-card protocols and protocols compatible with mobile device 102; present broadcasted content for viewing through the GUI 108; execute applications locally stored in the service card 110; selectively switch the antenna on and off based, at least in part, on one or more events; authenticate user based, at least in part, on information locally stored in the service card 110; present the Electronic Service Guide application for the user through the GUI 108 for selection of available channels; present menu options for managing recordable content and configuring options for the personal video recorder application via GUI 108; present the personal video recorder application for viewing of recorded content via GUI 108; and/or others. In some implementations, the service card 110 may receive a broadcast signal in response to at least a user selecting a graphical element in the GUI 108. In some implementations, the service card 110 may selectively switch the antenna between an on and off state in response to one or more events (e.g., user request, completion of broadcast, change of host device, change of network connection of the host device, change of location). The service card 110 may include a communication module with a protocol translation module, antenna tuning circuit, power circuit and a miniature antenna tuned to receive broadcast signals.
In some implementations, the service card 110 may initiate receiving to a broadcast signal in response to at least a user selecting a graphical element in the GUI 108. In some implementations, the service card 110 may selectively switch the antenna between an on and off state in response to one or more events. The one or more events may include a user request, completion of broadcasted content, insertion of card 110 in a different mobile device, location change, timer events, detection of incorrect user ID and password entered by the user, message received from the content provider 104 using a broadcast/cellular signal, and/or others. For example, the service card 110 may receive one or more commands to switch the antenna off from the distribution tower 112 or from the cellular core network. In some implementations, the service card 110 may request user identification such as a PIN, a user ID and password combination, biometric signature, and/or others.
In regards to translating between protocols, the service card 110 may process information in, for example, ISO 7816, a stand security protocol, and/or others. In this case, the service card 110 may translate between a broadcast protocol and the service-card protocol. Broadcast protocols may include DVB, DMB, FLO and/or MBMS. In some implementations, ISO 7816 commands may be encapsulated within interface commands used to transmit data between the mobile host device 102 and the card 110. In addition, the service card 110 may interface the mobile device 102 through a physical interface such as MicroSD, Mini-SD SD, MMC, miniMMC, microMMC, USB, miniUSB, microUSB, firewire, Apple iDock, and/or others. In regard to security processes, the service card 110 may implement one or more Conditional Access Systems (VideoGuard, Irdeto Access, Nagravision, Conax, Viaccess and Mediaguard (a.k.a. SECA)). The CAS may use encryption algorithms to descramble or otherwise decrypt broadcast signals to determine encoded content. In some implementations, the service card 110 may execute private key (symmetric algorithms) such as Data Encryption Standard (DES), Triple DES (TDES) and/or others or public key (asymmetric algorithms) such as RSA, elliptic curves, and/or others to implement the chosen CAS system compliant with the service provider. For example, the service card 110 may include one or more encryption keys such as public-private keys. In addition, the service card 110 may include memory (e.g., Flash, EEPROM) including a secured token accessible by the content providers 104 to store access rights of the user. The service card 110 may also store user data, applications, offline Webpages, and/or other information. For example, the service card 110 may include a secure token that identifies content that the user subscribes to or can otherwise access. In addition, the service card 110 may execute or otherwise include digital rights management technology to substantially prevent illegal copying, storing or distributing or other violations of digital rights.
The service card 110 may present content (e.g., audio, video) to the user using the GUI 108. In response to initiating foreign-content access, the service card 110 may automatically present an offline Web page through the GUI 108. In some implementations, the offline Web page can be associated with a content provider 104. In some implementations, the service card 110 can be backward compatible and operate as a mass storage device. For example, if the wireless interface of the service card 110 is not available or deactivated, the service card 110 may operate as a mass storage device enabling users to access data stored in the memory component (e.g., Flash). In some implementations, the service card 110 can execute a set of initialization commands in response to at least insertion into the mobile device 102. These initialization commands may include determining device related information for the mobile device 102 (e.g., device ID, device capabilities), determining user relating information (e.g., user ID and password), incrementing counters, setting flags and activating/deactivating functions according to pre-existing rules and/or algorithms.
In some implementations, the service card 110 may automatically execute one or more fraud control processes. For example, the service card 110 may identify an operational change and automatically deactivate the card 110. The service card 110 may execute two fraud control processes: (1) determine a violation of one or more rules; and (2) automatically execute one or more actions in response to at least the violation. In regards to rules, the service card 110 may locally store rules associated with updates to operational aspects of the service card 110. For example, the service card 110 may store a rule indicating a change in mobile host device 102 is an operational violation. In some implementations, the service card 110 may store rules based, at least in part, on updates to one or more of the following: device ID; subscription period; registration information; CAS parameters; and/or other aspects. In response to one or more events matching or otherwise violating rules, the service card 110 may execute one or more processes to substantially prevent access to broadcasted content. In some implementations, the service card 110 may execute a command based, at least in part, on an event type. For example, the service card 110 may re-execute an activation process in response to at least a specified event type. In some implementations, the service card 110 may execute a command to disconnect the GUI 108 from the service card 110. The service card 110 may present a disconnection notification through the GUI 108 prior to executing the command. In some implementations, the service card 110 may provide options for the user to configure a rule table (PVR rule table) related to the personal video recorder application. This may allow the user to specify rules according to which content is automatically recorded by the service card.
In regards to accessing broadcasted services, the interface between the service card 110 and the access point 112 or distribution tower 112 may be DVB-H, DMB, MBMS, or FLO for Mobile-TV and Sirius/XM for Satellite Radio or other digital Mobile-TV and/or satellite broadcast interfaces. Based on the PVR Rule Table, the service card 110 may receive content from the broadcast content provider 204 and store the content in real-time to the memory. The content player of the mobile device 102 may then access the stored content using, for example, a media player and access to the GUI 108. The antenna mode of the service card 110 may be set to physical authentication only because the service card 110 may use the mobile device 102 to present video and/or audio. The secure element of the service card 110 may operate as set-top box (CAS token). In this implementation, the secure element my operate in two different roles as illustrated in Table 1 below.
The table is for illustration purposes only. The activation of the service card 110 may include some, all, or different aspects of the chart.
In some implementations, the user may acquire the service card 110 when subscribing to a content provider's broadcast content service. The activation process may depend on whether the mobile device 102 includes an interface such as a screen, a keyboard and internet access. In some implementations, the service card 110 may be activated online or offline. Online activation may occur when the device 102 includes an interface such as screen, keyboard and wireless internet access (Cellphone, laptop or Wireless PDA), offline activation may occur when a device 102 does not include internet capability or doesn't have a screen/keyboard (MP3/4 players). These two activation processes are illustrated below in Table 2.
The table is for illustration purposes only. The activation of the service card 110 may include some, all, or different aspects of the chart.
In some implementations, the service card 110 may operate as a personal video recorded (PVR). For example, the service card 110 may include GBs of flash memory that may store multimedia content. The service card 110 may include a microcontroller sufficiently strong to operate a recording process while streaming the content to the content player on the mobile device 102 at the same time. The service card 110 may include an application residing on a protected area of the memory that would run a PVR and an Electronic Service Guide (ESG) application to enable a user to review the content program and select the programs recording. The DVR and ESG application may enable playing back the recorded content from the memory. In comparison, the service card 110 may include a stronger microcontroller that has an internal clock (e.g., an ARM series processor). The service card 110 may include a special form factor that allows the SD interface to connect to a SD to USB adaptor for laptop use. In some implementations, the service card 110 includes a secure element OS to enable the functionality described above. The service card 110 may implement a CAS algorithm based on content provider's specification. The secure element OS may structure data in the secure element to enable storage of subscription data for the end user. The microcontroller OS may be capable of personalizing the secure element by loading/updating user subscription parameters. In addition, the microcontroller OS may be capable of presenting the service card 110 as SD mass storage to the mobile device 102. In addition to operating the memory, secure element, the broadcast receiver chipset and the antenna availability, the microcontroller OS may implement a very fast content writing function on the memory in real-time, receive the ESG in real-time from the broadcast content provider 204, and interact with the host device's content player to display the content. The secure element may operate as the CAS and subscription storage token because of cryptographic capabilities. The device application section may be used to store provider specific applications that operate from this segment of the memory or are installed on the mobile device 102 from this segment of the memory.
In some implementations, the service card 110 may include broadcast applications and WAN connectivity. In this case, the user may perform payment to a third party by connecting over the internet and/or performing peer-to-peer payment by connecting to another user with the same functionality. In some implementations, the service card 110 may include broadcast applications and broadcast reception capabilities. In this case, the user may purchase content in real-time and pay for merchandise advertised over the broadcast content in real-time.
The content distribution network 106 facilitates wireless or wired communication between the content providers 104 and any other local or remote computer. The distribution network 106 may be all or a portion of an enterprise or secured network. While illustrated as single network, the distribution network 106 may be a continuous network logically divided into various sub-nets or virtual networks without departing from the scope of this disclosure, so long as at least a portion of distribution network 106 may facilitate communications of transaction information between the content providers 104. In some implementations, the distribution network 106 encompasses any internal or external network, networks, sub-network, or combination thereof operable to facilitate communications between various computing components in system 100. Network 106 may communicate, for example, Internet Protocol (IP) packets, Frame Relay frames, Asynchronous Transfer Mode (ATM) cells, voice, video, data, and other suitable information between network addresses. Network 106 may include one or more local area networks (LANs), radio access networks (RANs), metropolitan area networks (MANs), wide area networks (WANs), all or a portion of the global computer network known as the Internet, and/or any other communication system or systems at one or more locations. In some implementations, the distribution network 106 include the content providers 104a-c.
Content provider 104a-c comprises an electronic device (e.g., computing device) operable to broadcast content. In some implementation, the content provider 104 can provide broadcast signals that encodes content displayable by the service card 110. The content provider 104 may transmit one or more of the following: serial programs (e.g., television series), movies, news, opinions, education content, training, sports events, Web pages; advanced blogging sites, travel-related content, food and/or cooking content; entertainment; topical movies and/or videos (e.g., surfing, sailing, racing, extreme sports, etc.); political content (e.g., campaigning); adult content; court and/or trail programming; local-government content (e.g., C-SPAN); local programming (e.g., Wayne's World); performing arts (e.g., theater, concerts, music videos, etc.); virtual shopping malls; satellite radio content (audio only channels); and/or other content. The provided content may be in any suitable format such as MPEG, streaming, MP3, realtime, WMV, and/or others. In the illustrated implementation, the content provider 104 includes a conditional access module 124 for authenticating a user and associated privileges prior to providing access to services. For example, the CAS module 124 may transmit a request for information associated with the user such as subscriber ID, receiver ID, PIN, username and password, and/or other information. Based, at least in part, on information associated with the user information, the CAS module 124 may determine available services, content, level of services, and/or other aspects of the requested foreign service.
In some implementations, the service card 110 may operate in accordance with one or more of the following modes: active receiver; self train; killed; memory; inactive; and/or other modes. The service card 110 may operate active-receiver mode to present the service card 110 as a broadcast receiver. In this mode, the service card 110 may execute applications access broadcast services through the broadcast network 108. After the antenna of the service card 110 is activated in this mode, the network 108 may detect the presence of the service card 110. In this implementation, the mobile device 102 may not require additional software to access the services.
In regards to the self-train mode, the service card 110 may receive personalization information from another receiver. In some implementations, the self-train mode can be activated by a special action (e.g., a needle point press to a small switch, entry of an administrative password via the GUI 108). In response to at least activating this mode, the service card 110 may be configured to receive personalization data over, for example, the short range wireless interface from another peer service card or a wired connection with the home broadcast receiver. Personalization data received in this mode may include encrypted information that is stored in secured memory of the service card 110. In some implementations, the service card 110 in this mode may receive the information through a wireless interface of a transmitter and/or others. The service card 110 may then synthesize the information that corresponds to the user account and personalize an internal security module that includes, for example, service applications for accessing services from the provider 104 and associated user credentials. The self-train mode may be used to re-personalize the service card 110 in the field. In some implementations, all previous data can be deleted if the self-train mode is activated. The self-train mode may be a peer-to-peer personalization mode where the card 110 may receive personalization information from another service card 110. This mode may represent an additional personalization mode as compared with factory, store and/or Over-The-Air (OTA) personalization scenarios which may be server to client personalization scenarios. In some implementations, the self-train mode may be a peer-to-peer personalization mode where the service card 110 receives personalization information from another service card. Since two service cards 110 are used in this mode, this mode may be different from a server-to-client personalization scenario as with a factory, store, and OTA personalization.
In regards to the inactive mode, the service card 110 may temporarily deactivate the wireless interface. In some implementations, the inactive mode can be activated through the physical interface with the mobile device 102 such as a SD interface. In response to at least the activation of the inactive mode, the service card 110 may temporarily behave as only a mass-memory card. In some implementations, the card 110 may also enter this state when the reset needle point is pressed. In this mode, the service card 110 may preserve locally-stored information including user information. In this mode, the service card 110 may execute the activation process and if successful may return to the active mode. The content provider 104 may use this mode to temporarily prevent usage in response to at least identifying at least potentially fraudulent activity.
In regards to the killed mode, the service card 110 may permanently deactivate the wireless interface. In some implementations, the killed mode is activated through the physical interface with the mobile device 102 such as a SD interface. In response to at least the activation of the killed mode, the service card 110 may permanently behaves as a mass memory stick. In the event that the reset needle point is pressed, the service card 110 may, in some implementations, not be made to enter any other modes. In addition, the service card 110 may delete user information in memory in response to at least this mode being activated. In some implementations, the providers 104 may use this mode to delete data from a service card 110 that is physically lost but still connected to the broadcast network 108.
In regards to the memory mode, the service card 110 may operate as a mass memory stick such that the memory is accessible through conventional methods. In some implementations, the service card 110 may automatically activate this mode in response to at least being removed from the host device, inserted into a non-authorized host device, and/or other events. The service card 110 may be switched to active mode from the memory mode by, for example, inserting the card 110 into an authorized device or may be switched from this mode into the self-train mode to re-personalize the device for a new host device or a new user account. In some implementations, the memory mode may operate substantially same as the inactive mode.
In some implementations, the service card 110 may be re-personalized/updated such as using software device management process and/or a hardware reset. For example, the user may want to re-personalize the service card 110 to change host devices, to have multiple host devices, and/or other reasons. In regards to the software device management, the user may need to cradle the new host device with the service card 110 inserted to launch the software device management application. In some implementations, the software management application can be an application directly installed on a client, integrated as a plug-in to a normal synchronization application such as ActiveSync, available via a browser plug-in running on the plug-in provider's website, and/or other sources. The user may log into the application and verify their identity, and in response to verification, the application may allow access to a devices section in the device management application. The device management application may read the service card 110 and display the MAC addresses, signatures of the devices that he has inserted his plug-in to, and/or other device specific information. The mobile device 102 may be marked as active and the host device may be shown as disallowed or inactive. The application may enable the user to update the status of the new host device, and in response to at least the selection, the device management application may install the signature on the new host device and mark update the status as allowable in secure memory of the service card 110. The user may be able to also update the status of the mobile device 102 to disallowed. Otherwise, both devices may be active and the service card 110 may be switched between the two devices. In regards to the hardware reset process, the use may use the reset needle point press on the physical service card 110 to activate the self-train mode. In this mode, the user data may be deleted and have to be reloaded. When the service card 110 is inserted into the new host device, the provisioning process may begin as discussed above.
In some aspects of operation, the content provider 104 may transmit information to the mobile host device 102 using the service card 110 in response to at least an event. The information may include, for example, service information (e.g., access history), scripts, applications, Web pages, and/or other information associated with the content provider 104. The event may include completing access to a service, determining a service card 110 is outside the operating range of a broadcast network 108, receiving a request from a user of the mobile host device, and/or others. For example, the content provider 104 may identify a mobile host device 102 associated with a card 110 that accessed a service and transmit service information to the service card 110 using the broadcast or cellular core network 108. In addition or alternatively, the content provider 104 may request information from the mobile host device 102, the service card 110 and/or the user using the broadcast or cellular core network 108. For example, the content provider 104 may transmit a request to update the Electronic Service Guide to the card 110 through the broadcast or cellular core network 108.
As illustrated, the service card 110 includes an antenna 202, an Antenna Control Function (ACF) module 204, a broadcast receiver 206, a set-top module 208, a CPU 210 and memory 212. The antenna 202 receives wireless broadcast signals such as satellite radio and/or TV. In some implementations, the ACF module 204 can selectively switch the antenna 202 between an active state and an inactive state in response to at least an event. A switching event may include a user selection through the GUI 108. In some implementations, the switching event may be based, at least in part, on operational aspects of the mobile host device 102 such as completion of presentation of multimedia. In addition, the ACF module 204 may dynamically adjust the impedance of the antenna 202 to tune the receive frequency. The ACF module 204 may selectively switch the antenna 202 on and off in response to at least a command from the CPU 210. In some implementations, the antenna 202 can be connected through a logic gate to allow for code from the CPU 210 to turn the antenna 202 on and off through the ACF module 204.
The receiver 206 can include any software, hardware, and/or firmware configured to receive broadcast signals using the antenna 202. For example, the receiver 206 may convert broadcast signals to set top module processable signals. In some implementations, the receiver 206 may translate a broadcast protocol to a security protocol. For example, the receiver 206 may translate to ISO 7816, a stand security protocol, and/or others. Broadcast signals may include DVB, DMB, FLO and/or MBMS. In some implementations, ISO 7816 commands may be encapsulated within interface commands used to transmit data between the mobile host device 102 and the card 110.
The set-top module 208 can include any software, hardware, and/or firmware configured to unscramble broadcast signals to a form displayable through the GUI 110. For example, the set-top module 208 may launch the CAS application to unscramble the broadcast signal to determine encoded content and decrypt the encoded content to a presentable form (e.g., MPEG 4). In some implementations, the set-top module 208 may authenticate one or more aspects of the mobile host device, user, and/or card 110. In some implementations, the set-top module 208 may authenticate a user by verifying a physical connection with a user using user information such as user ID and password, biometric information (e.g., fingerprint), a PIN entered by the user, a x.509 type certificate that is unique to the user and stored on the host device 110, and/or other processes. For example, the set-top module 208 may compare user information provided through the GUI 108 with user information stored in the local memory 212. Alternatively or in addition, the set-top module 208 may authenticate the mobile host device 102 by comparing a device signature with a locally-stored certificate. In some implementations, the user can select a user-id and password or PIN or certificate at provisioning time. If this case, the CPU 210 may instantiate a software plug-in on the host device. For example, a software plug-in may request the user for his user-id and password or PIN in real time, read a user certificate installed on the device (e.g., x.509), and/or others. The operation of the software plug-in may be customized by the provider. Regardless, the returned user data may be compared with user data stored in the memory 212. In case of a successful match, the ACF module 204 may activate the antenna 202. In case of an unsuccessful match of a certificate and/or user information, the card 110 is deactivated. In case of unsuccessful user ID and password match, the user may be requested to repeat user-id and password attempts until a successful match or the number of attempts exceeds a threshold. The card provider may customize the attempt threshold.
In some implementations, the set-top module 208 may implement one or more Conditional Access Systems with accompanying encryption algorithms to decode broadcast signals. For example, the set-top module 208 may include or otherwise identify a one or more keys for decoding broadcast content. In some implementations, the service card 110 may execute private key (symmetric algorithms) such as Data Encryption Standard (DES), Triple DES (TDES) and/or others or public key (asymmetric algorithms) such as RSA, elliptic curves, and/or others. For example, the service card 110 may include one or more encryption keys such as public-private keys. In connection with decoding signals, the CAS in the set-top module 208 may identify a subscription profile identifying content available to the user. For example, the CAS in the set-top module 208 may determine one or more broadcast channels available to the user and decode one of the available broadcast channels for presenting through the GUI. The set top box 208 may present the Electronic Service Guide to the user through the GUI. The Electronic Service Guide may not only present the choice of channels available to the user but may also make available a detailed listing of programming content available on each channel. The Electronic Service Guide may also interface to the Personal Video Recorder application in the card and provide options to the user to set up timers to record certain programs. The Electronic Service Guide may also be periodically updated by the service provider through the set top box.
The CPU 210 can include any software, hardware, and/or firmware that manages operational aspects of the card 110 independent of the mobile host device 102. For example, the CPU 210 may include a runtime environment for executing broadcast applications for accessing foreign content encoded in broadcast signals. In some implementations, the CPU 210 may execute one or more of the following: interfacing the mobile host device 102 such as translating between protocols; determining operational aspects of the mobile host device 102; transmitting commands to the mobile host device 102 to substantially control one or more hardware components (e.g., GUI 108, memory); identifying events associated with activating and deactivating the antenna 202; executing broadcast applications that present foreign content from the provider 104; executing media protocol conversion to adapt the content according to the capabilities of the media player accessible through the GUI, execute the PVR application to record content on the flash memory of the card, provide access to stored content on the flash memory, manage the set top box using ISO 7816 interface, mange the broadcast chipset using a high-speed IP interface, manage the memory using a standard memory controller interface; and/or others. In some implementations, the CPU 210 may transmit to the ACF module 204 switching commands in response to an event such as a user request, completion of a transaction, and/or others. In some implementations, the CPU 210 may switch the antenna 202 between active and inactivate mode using the ACF module 204 based, at least in part, on a personalization parameter defined by, for example, a user, distributor (e.g., content provider), and/or others. For example, the CPU 210 may activate the antenna 202 when the service card 110 is physically connected to a host device and when a handshake with the host device is successfully executed. In some implementations, the CPU 210 may automatically deactivate the antenna 202 when the service card 110 is removed from the host device. In regards to the handshaking process, the CPU 210 may execute one or more authentication processes prior to activating the service card 110 and/or antenna 202 as illustrated in
The memory 212 may include a secure and non-secured section. In this implementation, the secure memory 212 may store one or more user credentials that are not accessible by the user. In addition, the memory 212 may store offline Web pages, applications, service history, and/or other data. In some implementations, the memory 212 may include Flash memory from 64 MB to 32 GB. In addition, the memory 212 may be partitioned into user memory and device application memory. The memory 212 may store signatures of allowed host devices and/or antenna modes. In some implementations, the memory 212 may include secure portions designed to be accessible only by the content provider.
In some implementations, the service card 110 can include a host controller 302, a real-time framework 304, a broadcast application 306, a real-time OS 308, a high speed IP interface 310, a memory controller 312, and a security module driver 314. In some implementations, the host controller 302 includes an interface layer, an API/UI layer, a Web server, and/or other elements associated with the mobile host device 102. The host controller 302 includes interfaces to the host device, i.e., physical connection. In regards to the physical interface, the host controller 302 may physically interface the mobile device 102 using an SD protocol such as MicroSD, Mini-SD or SD (full-size). In some implementations, the physical interface may include a converter/adapter to convert between two different protocols based, at least in part, on the mobile device 102. In some implementations, the mobile device 102 may communicate using protocols such as USB, MMC, Firewire, iPhone proprietary interface, and/or others. In addition, the host controller 302 may include any software, hardware, and/or firmware that operates as an API between the mobile device 102 and the service card 110. Prior to accessing services, the service card 110 may automatically install drivers in the mobile device 102 in response to at least insertion. For example, the service card 110 may automatically install a microSD device driver in the device 102 to enable the service card 110 to interface the mobile device 102. In some implementations, the service card 110 may install an enhanced device driver such as a Mass Memory with Radio (MMR) API. In this implementation, the interface can drive a class of plug-ins that contain mass memory as well as a radio interface. The MMR API may execute one or more of the following: connect/disconnect to/from the MMR controller (Microcontroller in the plug-in); transfer data using MM protocol (e.g., SD, MMC, XD, USB, Firewire); send encrypted data to the MMR controller; receive Acknowledgement of Success or Error; received status word indicating description of error; turn radio on/off; send instruction to the service card 110 to turn the antenna on with specifying the mode of operation (e.g., sending mode, listening mode); transmit data such as send instruction to controller to transmit data via the radio; listen for data such as send instruction to controller to listen for data; read data such as send instruction to controller to send the data received by the listening radio; and/or others. In some implementations, MMR can be compliant with TCP/IP. In some implementations, API encapsulated ISO 7816 commands may be processed by the security module in addition to other commands.
In some implementations, host controller 302 can operate in accordance with the two processes: (1) the service card 110 as the master and the mobile device 102 as the slave; and (2) the card UT as the master. In the first process, the host controller 302 may pass one or more commands to the mobile device 102 in response to, for example, insertion of the service card 110 into a slot in the mobile device 102, a request from the GUI 108, and/or other events. In some implementations, the host controller 302 can request the mobile device 102 to execute one or more of following functions: Get User Input; Get Signature; Display Data; Send Data; Receive Data; and/or others. The Get User Input command may present a request through the GUI 108 for data from the user. In some implementations, the Get User Input may present a request for multiple data inputs. The data inputs may be any suitable format such as numeric, alphanumeric, and/or other strings of characters. The Get Signature command may request the mobile device 102 to return identification data such as, for example, a phone number, a device ID like an IMEI code or a MAC address, a network code, a subscription ID like the SIM card number, a connection status, location information, Wi-Fi beacons, GPS data, and/or other device specific information. The Display Data command may present a dialog to the user through the GUI 108. In some implementations, the dialog can disappear after a period of time, a user selection, and/or other event. The Send Data command may request the mobile device 102 to transmit packet data using its own connection to the external world (e.g., SMS, cellular, Wi-Fi). The Receive Data command may request the mobile device 102 to open a connection channel with certain parameters and identify data received through the connection. In some implementations, the command can request the mobile device 102 to forward any data (e.g., SMS) satisfying certain criteria to be forwarded to the service card 110.
In regards to the UT as master, the host controller 302 may execute one or more of the following commands: security module Command/Response; Activate/Deactivate; Flash Memory Read/Write; Send Data with or without encryption; Receive Data with or without decryption; URL Get Data/URL Post Data; and/or others. The security module commands may relate to security functions provided by the card and are directed towards the security module within the service card 110 (e.g., standard ISO 7816 command, proprietary commands). In some implementations, the commands may include encryption, authentication, provisioning of data, creation of security domains, update of security domain, update of user credentials after verification of key, and/or others. In some implementations, the commands may include non security related smart card commands such as, for example, read service history commands. The read service guide command may perform a read of the Electronic Service Guide data stored in the memory 212 of the service card 110. In some implementations, certain flags or areas of the memory 212 may be written to after security verification. The Activate/Deactivate command may activate or deactivate certain functions of the service card 110. The Flash Memory Read/Write command may execute a read/write operation on a specified area of the memory 212. The Read command may be used by the Media Player to receive the streaming content selected by the user for viewing. The Send Data with or without encryption command may instruct the mobile device 102 to transmit data using a wireless connection. In addition, the data may be encrypted by the service card 110 prior to transmission using, for example, keys and encryption capability stored within the set-top module 208. The Receive Data with or without decryption command may instruct the service card 110 to switch to listening mode to receive data from its wireless connection with the cellular core network 108. In some implementations, data decryption can be requested by the security module using, for example, keys and decryption algorithms available on the security module, i.e., on-board decryption. The URL Get Data/URL Post Data command may instruct the host controller 302 to return pages as per offline get or post instructions using, for example, offline URLs.
In some implementations, the host controller 302 may assign or otherwise associate URL style addressing to certain files stored in the memory 212 (e.g., flash) of the service card 110. In some implementations, the host controller 302 can locate a file using the URL and returns the file to the GUI 108 using standard HTTP, HTTPS style transfer. In some implementations, the definition of the files can be formatted using standard HTML, XHTML, WML and/or XML style languages. The file may include links that point to additional offline storage locations in the memory 212 and/or Internet sites that the mobile device 102 may access. In some implementations, the host controller 302 may support security protocols such as SSL. The host controller 302 may transfer an application in memory 212 to the mobile device 102 for installation and execution. The host controller 302 may request the capabilities of the browser on the device 102 using, for example, the browser user agent profile, in order to customize the offline Web page according to the supported capabilities of the device and the browser, such as, for example, supported markup language, screen size, resolution, colors and such.
As part of the Real time OS, the real-time framework 304 may execute one or more functions based, at least in part, on one or more periods of time. For example, the real-time framework 304 may enable an internal clock available on the CPU 210 to provide timestamps in response to at least requested events. The real-time framework 304 may allow certain tasks to be pre-scheduled such that the tasks are executed in response to at least certain time and/or event based triggers. This aspect is used by the Real Time OS to generate triggers to launch the Personal Video Recorder application, Set top box and the broadcast chipset to begin reception and recording of the content if the user set timer for content recording has been met. In some implementations, the real-time framework 304 may allow the CPU 210 to insert delays in certain transactions. In some implementation, a part of WAP standards called WTAI (Wireless Telephoney Application Interface) can be implemented to allow offline browser pages on the card 110 to make use of functions offered by the mobile device 102.
The broadcast application 306 can include any software, hardware, and/or firmware that receive broadcast content. For example, the broadcast application 306 may receive a request for content through the GUI and receive the associated broadcast signal in response to at least the request. In some implementations, the broadcast application 306 may execute one or more of the following: transmit properties of the service card 110; to the broadcast Content Distribution System; download the Electronic Service Guide data from the Broadcast Content Distribution System; tune the antenna to the right frequency based, at least in part, on selection made by the user via the Electronic Service Guide viewed on the GUI; receive the broadcasted content based, at least in part, on the subscription information; transmit user profile and authentication data to the content distribution system, receive instructions and data to update the Electronic Service Guide, receive request from the CPU to begin or end the broadcast reception; and/or other processes. In these case, the broadcast application 310 may present media through the GUI 108 that is otherwise not accessible by the mobile host device 102, i.e., foreign content.
The real-time OS 308 may execute or otherwise include one or more of the following: real-time framework 304; a host process that implements the physical interface between the service-card CPU and the mobile device 102; an interface that implements the physical interface between the service-card CPU and the security module; a memory-management process that implements the ISO 7816 physical interface between the service-card CPU and the memory 212; an application-layer process that implements the API and UT capabilities; the ACF module 204; power management; and/or others. In some implementations, the real-time OS 308 may manage the physical interface between the service-card CPU and the memory 212 that includes memory segmentation to allow certain memory areas to be restricted access and/or data buffers/pipes. In some implementations, the CPU 210 may include a separate memory controller 312 for managing the local memory 212. In some implementations, the real-time OS 308 may include a microcontroller OS configured to personalizing the set-top module 208 such as by, for example, converting raw data (account number, subscription information, user profile, receiver ID, CAS parameters) into secure encrypted information. In addition, the microcontroller OS may present the card 110 as a microSD mass storage to the host device 102. The microcontroller OS may partition the memory 212 into a user section and a protected device application section. In this example, the device application section may be used to store provider specific applications that either operate from this segment of the memory or are installed on the host device 102 from this segment of the memory.
The high speed IP interface 318 may provide the hardware protocol implementation and/or drivers for digital streaming content corresponding to the broadcasting signals received by the broadcast receiver. For example, the through this high speed IP interface, the CPU may receive non-encrypted or non-scrambled digital streaming content associated with free or off-air or non-premium channels. In this case, this streaming content is directly made available to the media player of the host device after appropriate media protocol translation if required. For example, through this high speed IP interface, the CPU may receive encrypted or scrambled digital content associated with premium or subscription channels. In this case, the content is first sent to the set-top box for decoding and unscrambling and then forwarded to the media player after any appropriate media translation.
In some implementations, provisioning of the intelligent card can be based, at least in part, on the distribution entity (e.g., service provider, wireless operator, user). For example, the intelligent card may be distributed by a service provider such as a content provider (for example, DirecTV). In the service provider implementation, the intelligent card can be pre-provisioned with user accounts. In this case, the intelligent card may be activated in response to at least initial insertion into a host device. The antenna mode may be set to physical authentication only by default. In some examples, the user may self-select a user-id/password or PIN authentication to prevent unauthorized use or through a PC cradle and plug-in management software if the host device does not have a screen and keyboard. In the wireless-operator implementation, the intelligent card may require device authentication before activation. In some examples, the user may provision service data (e.g., subscriber profile) using one of several methods. In addition, the user may add user authentication. In the user-provided implementation, the user may acquire the intelligent card from, for example, a retail store or other channels like OEM host device manufacturers. In this case, the user may activate the card in a plurality of different devices with provider selected provisioning.
In regards to activation, the intelligent card may be configured in memory mode when user acquires the card from, for example a content provider, a wireless operator, a third-party provider, and/or others. Activation of the card may include the following two levels: 1) physically, specifying antenna availability under a specific set of circumstances desired by the provider; and b) logically, at the service provider signifying activation of the broadcast application carried on the card. In some implementations, activation may be based, at least in part on device distributor, antenna availability selection, and/or type of host device as illustrated in Table 2 below.
The illustrated chart is for example purposes only. The user may activate an intelligent card using the same, some, or different processes without departing from the scope of this disclosure.
Method 500 begins at step 502 where insertion into a host device is detected. For example, the service card 110 may detect insertion into the mobile device 102. If authentication is not required for any aspect of the intelligent card at decisional step 504, then execution ends. If authentication is required for at least one aspect, then execution proceeds to decisional step 506. If communication with the host device includes one or more errors, then, at step 508, a failure is indicated to the user. In the example, the service card 110 may present an indication of a communication error to the user using the GUI 108. If a communication error is not detected at decisional step 506, then execution proceeds to decisional step 510. In some implementations, the intelligent card uploads an SD driver to the host device. If the intelligent card only requires physical authentication, then execution proceeds to decisional step 512. If the network authentication flag is not set to on, then, at step 514, the antenna is turned on and the intelligent card is updated with host-device signature. As for the example, the service card 110 may activate the antenna for wireless transactions and update local memory with the host-device signature. If the network authentication flag is turned on at decisional step 512, then, at step 516, the intelligent card transmits a request for the network ID to the host device. Next, at step 518, the intelligent card retrieves a locally-stored network ID. If the stored network ID and the request network ID match at decisional step 520, then the card is activated at step 514. If the two network ID's do not match, then the antenna is deactivated at step 522.
Returning to decisional step 510, if the authentication is not only physical authentication, then execution proceeds to decisional step 524. If the authentication process includes device authentication, then, at step 526, the intelligent card transmits a request for a network ID to the host device. At step 528, the intelligent card retrieves a locally stored device signatures. If the intelligent card does not include at least one device signature, then execution proceeds to decisional step 534. If the intelligent card includes one or more device signatures, then execution proceeds to decisional step 532. If one of the device signatures matches the request network ID, then execution proceeds to decisional step 534. If the signatures and the request network ID do not match, then execution proceeds to step 522 for deactivation. If user authentication is not included in the authentication process, then execution proceeds to decisional step 512 for physical authentication. If user authentication is included at decisional step 534, then execution proceeds to step 538.
Returning to decisional step 524, if the authentication process does not include device authentication, then execution proceeds to decisional step 536. If user authentication is not included in the process, then, at step 522, the intelligent card is turned off. If user authentication is included, then, at step 538, the intelligent card request a user id and password from the user using the host device. While the user authentication is described with respect to entering a user id and password through the mobile host device, the user may be authenticated using other information such as a simple PIN and/or biometric information (e.g., fingerprint). Again returning to the example, the service card 110 may present a request for the user to enter a user-id and password through the GUI 108. At step 540, the intelligent card sends the entered information to the service provider using the cellular network or the broadcast network. If at the account information is validated by the service provider at decisional step 542, then execution proceeds to decisional step 512 for physical authentication. If the account information is not validated at decisional step 542, then execution proceeds to decisional step 544. If the number of attempts have not exceeded a specified threshold, then execution returns to step 538. If the number of attempts has exceed to the threshold, then the antenna is deactivated at step 522. In the example, if the event that the service card 110 fails to authorize the device, network and/or user, the service card 110 may wirelessly transmit an indication to the associated service provider using the cellular radio technology of the mobile host device 102. In this case, the illustrated method 500 may be implemented as a fraud control process to substantially prevent unauthorized use of the service card 110.
Method 600 begins at step 602 where a request to activate a service card is received. For example, the user may select a graphical element displayed through the GUI 108 of a mobile host device 102 in
As illustrated, the flow 700 may include multiple sessions 720 between the host device 704 and the card 706 and between the card 706 and the cellular network 708. The session 720a illustrates a session managed by the card 706 using the network capabilities of the host device 710. In this example, the card 706 transmits data for transmission through a network connected to the host device 704, and after receiving the data, the host device 704 transmits the data to the network 802. In response to receiving data from the network 702, the host device 704 may automatically transmit the received data to the card 706. In some implementations, the card 706 may transmit a request for a device signature to the host device 704 as illustrated in session 720b. For example, the card 706 may request the device signature during a bootstrapping process. The session 720c illustrates that a user may submit commands to the card 706 through the interface of the host device 704. For example, the user may request that the card display the user's transaction history through the interface of the host device 704.
In some implementations, the card 706 may receive a command to activate or deactivate the antenna through the host device 704 as illustrated in session 720d. For example, a service provider may identify irregular transactions and transmit a command through the network 702 to deactivate the card 706. The card 706 may authorize a user by requesting a user-id and password using the host device 704. As illustrated in session 720e, the user may submit a user-id and password to the card 706 using the interface of the host device 704, and in response to an evaluation of the submitted user-id and password, the card 706 may present through the host device 704 an indication that the user verification is successful or has failed. In some implementations, a user and/or service provider may request a transaction history of the card 706 as illustrated in session 720f. For example, a service provider may transmit a request for the transaction history through the network 702 connected to the host device 704, and in response to at last in the request, the card 706 may transmit the transaction history to the service provider using the network 702 connected to the host device 704. In some implementations, the user may present offline Web pages stored in the card 706 as illustrated in session 720. For example, the card 706 may receive a request to present an offline Web page from the user using the host device 704 and present the offline page using the URL in the request. In some implementations, content data stored in the memory of the card 706 or available via live reception of streaming content may be presented through, for example, the host device 704 as illustrated in session 720h. For example, the user may request specific information associated with the Electronic Service Guide and the card 706 may retrieve the data and present the data to the user using the host device 704. In addition, the user may write data to the memory in the card 706 as illustrated in session 720i. For example, the user may setup timers for the Personal Video Recorder application on the card 706 and the card 706 may indicate the success and failure of the timer setup
In regards to session between the card 706 and the terminal, the flow 700 illustrates the personalization session 720k and the transaction session 7201. In regards to personalization, a service provider may personalize a card 706 with user credentials, user applications, Web pages, and/or other information as illustrated in session 720k. For example, the cellular network 708 may transmit a provisioning request to the card 706 including associated data. The protocol translation 718 may translate the personalization request to a form compatible with the card 706. In response to at least the request, the CPU 712 transmit an indication whether the personalization was a success or not using the protocol translation 718. Prior to the a broadcast session beginning live reception, the broadcast network 708 may submit a subscription verification challenge to the card 706 as illustrated in session 7201. In this case, the card 706 may identify a receiver signature of the receiver 718, present associated data to the user through the host device 704, and transmit the signature to the cellular network 708 using the protocol translation 718.
Method 800 begins at step 802 where ESG data currently stored is identified. For example, the service card 112 may receive ESG data from the broadcast network or the cellular network such as channel lineup, program listing, program information and program ratings. At step 804, previously downloaded ESG content is identified. In the example, the service card 112 may identify content previously downloaded from the content provider to the local memory in the card 112. In some implementations, the service card 112 may identify one or more aspects of memory such as file names, file sizes, dates, and/or other aspects. If the previously-downloaded content matches the current content at decisional step 806, then execution ends. If the previously-downloaded content does not match the current content, then, at step 808, at least a portion of the locally-stored content is automatically updated in the local memory. As for the example, the service card 112 may only download content identified as new content or content that was previously not downloaded. In downloading the content, the service card 112 may substantially updates local-stored ESG content according to the latest available ESG from the service provider
Method 900 begins at step 902 where a timer event triggers the beginning of broadcast reception. For example, the service card 112 may automatically tune the antenna to the channel corresponding to the program that the user has setup to record as associated with the timer. At step 804, available memory space is identified. In the example, the service card 112 may identify free local memory in the card 112. If the available memory is below a certain threshold (configured by the service provider) at decisional step 806, then execution ends. If available memory is above a certain threshold, then, at step 808, broadcast reception is started and content is automatically recorded in the local memory in a newly created program data file. After a specified size of program data is recorded, available memory is checked again and the process is repeated by appending to the program data file until either the program ends or the available memory falls below the threshold. Once the program ends, the program data file is finalized and given a unique identifier so that it can be accessed for viewing.
A number of embodiments of the invention have been described. Nevertheless, it will be understood that various modifications may be made without departing from the spirit and scope of the invention. Accordingly, other embodiments are within the scope of the following claims.
This application claims priority under 35 USC § 119(e) to U.S. Patent Application Ser. No. 60/971,813, filed on Sep. 12, 2007, the entire contents of which are hereby incorporated by reference.
| Number | Date | Country | |
|---|---|---|---|
| 60971813 | Sep 2007 | US |
