Broadcast service access control6510515Abstract Techniques and systems for controlling access to information broadcast over point-to-multipoint resources in radiocommunication systems are described. These techniques can be used to provide controllable access to broadcast information services, e.g., security quote services, sports information services, etc., which broadcast services can be provided in conjunction with more conventional cellular radiocommunication services, e.g., voice calls. Exemplary embodiments of the present invention enable subscribing users' equipment to output broadcast information using, for example, either a status variable within the remote equipment or encryption for which subscribing devices have a corresponding decryption key. Claims What is claimed is: Description BACKGROUND
Device capabilities
TX capabilities No TX capabilities
LDE type A1 type B1
No LDE type A2 type B2
For example, teleservices involving data (as opposed to voice) transfer between the network and the remote device typically requires an acknowledgement signal in return from the remote device and, sometimes, a further acknowledgement to a dedicated teleservice server. Thus, for type B devices, basing B-SAC on a teleservice-like implementation, where the access control requires some reaction from the remote device, is not feasible. Even if traditional teleservice protocols are relaxed to permit operation without acknowledge signals, the system will still have to handle the issue of ensuring that the remote device actually receives the access control information that has been forwarded to it, e.g., by repeatedly retransmitting this information. This problem is further heightened by the fact that type B devices cannot perform conventional registration processes, i.e., it is more difficult for the system to know the location of the remote device and, therefore, the system would likely need to transmit the information at a greater number of different transmitting stations than if the general position of the remote device were known. Given these general considerations of different remote device types, some or all of which may be used to receive broadcast user information, e.g., stock quote information over S-BCCH sub-channels, several exemplary B-SAC embodiments will now be described. According to a first exemplary B-SAC embodiment, which provides a relatively low level of access control, but is applicable to both A and B type remote devices, access control is provided by way of a status variable monitored by the remote device. More specifically, the remote device maintains a status variable associated with each broadcast service, which variable is enabled or disabled depending upon whether the remote device has subscribed to the associated broadcast service. If the status variable is enabled, then the remote device will display or otherwise output information associated with this broadcast service, i.e., stock quotes. If the status variable is disabled, then the remote device will not output information associated with this service, even though the remote device may be capable of reading the information, i.e., the information can be unencrypted in this exemplary embodiment. The status variable can be maintained in the memory 180 of the remote device. Memory 180 may comprise a register or registers using portions of a non-volatile memory or may comprise a removable smart card associated with the remote device. In either case, the status variable can be enabled and disabled by receipt of special messages transmitted over the air interface. Unlike the broadcast service itself, the special enable/disable message is addressed, i.e., it is device specific, so that individual remote devices can be readily enabled or disabled. According to this exemplary embodiment, remote devices can be manufactured or sold in a mode wherein one or more status variables are preset to "enabled" for a period of time, e.g., one month, to allow the new remote device user a free trial period for certain services. The enabled state of the status variable may remain enabled only for a predetermined time period after receipt of an enabling message. For example, each receipt of a status variable enable signal can reset a stored date to be the date of receipt of the enable signal. This date can be compared with a current date, e.g., as received on the control channel or tracked by the remote device's internal clock. As long as the current date is within some predetermined time period (t.sub.old) of receipt of the enable message, the enabled state is maintained and the remote device will output information broadcast in conjunction with this service. Thus, these enable messages can be considered to be like "heartbeats" in the sense that they breathe life into the subscriber's ability to continue to receive information from the broadcast service. When a subscriber terminates his or her subscription, the system can send disable signals addressed to the subscriber's remote device. This will reset the status variable to a disabled value, by virtue of which the remote device will not output data associated with this service. Of course, if a subscriber becomes aware of the fact that the status variable is changed from enabled to disabled by reception of the disable signal, he or she may decide to try to thwart this process by powering down his or her equipment during periods when a disable signal is expected to be sent by the system, e.g., after the subscription is ended. The effectiveness of this type of activity can be reduced by employing a validation period in conjunction with the enable signal. This exemplary usage of a status variable in a B-SAC technique according to the present invention may be more readily understood by referring to the following example in conjunction with FIG. 5. Therein, a subscription is activated at time to and the service server begins to periodically transmit enable messages, as represented in FIG. 5 by the arrows pointing toward the time line. Initially, the frequency with which these enable messages are transmitted may be relatively high. Although the subscription was activated by the service operator at time t.sub.0, for various reasons such as channel errors or the remote devicet being powered down, the remote device does not receive its first enable message until time t.sub.3. Thus, the remote device can then store the date/time of receipt of the enable message in an associated status variable register and begin to read the information associated with the service that has been enabled, e.g., stock quote information on the S-BCCH subchannels illustrated in FIG. 3. During the period of time that the subscription is active, the service server will periodically send enable signals to reset the date/time of receipt stored in the status variable register against which the current date plus the validation period can be compared, as described below. At some time in the future t.sub.22, the subscription is terminated. At that time, or some time shortly thereafter, the service server will begin to send disable messages as represented by the arrows pointing away from the timeline. As soon as the remote device receives one of these messages, it resets its stored status variable indicator to disabled so that it will no longer output information associated with this service. At some point in time, the service server will stop sending disable messages directed to this particular remote station, assuming that at least one has been received, in order to conserve bandwidth utilization. However, assume that the user powers down his or her remote device at time t.sub.20, i.e., before the subscription ends at time t.sub.22 and before a disable message can be received. Absent some other access control mechanism, the user may not receive a disable signal, assuming that the system eventually stops sending disable signals addressed to that particular remote device. Thus, after the last disable signal is transmitted by the service server, e.g., time t.sub.30 in FIG. 5, the user could theoretically power on his or her and again be able to read the broadcast information since the status variable in his or her device would still be enabled. This potential shortcoming of this exemplary embodiment is addressed by the provision of the validity period t.sub.old. According to exemplary embodiments, the status variable will only retain its enabled state with respect to this service until it receives a disable message or until the date/time of its last received enable signal plus t.sub.old exceeds the current date/time. As seen in FIG. 5, t.sub.old therefore begins when the subscriber's equipment receives its last enable signal (which may not be the last enable signal transmitted by the system, as illustrated by the subsequent two "up" arrows in FIG. 5 after t.sub.old begins). Once t.sub.old ends at time t.sub.45, the status variable is reset to disabled since no further enable signals were received. At this time, the stock quote information will not be output to the user. The parameter t.sub.old may be prestored in the remote device. Alternatively, it may be transmitted to the remote device over the air interface and may be changeable. If changeable, t.sub.old should be permitted to be no greater than some maximum time t.sub.max to avoid fraud. To assess the bandwidth utilization associated with broadcast service access according to this exemplary embodiment consider the following example. Assume 1 million users, with the service adding 50,000 new users every month and terminating 50,000 subscriptions every month. Thus, there would be 1 million users who need to receive an enable message with t.sub.old. Assume t.sub.old is one month. and that five enable messages need to be sent to each user within this time period for redundancy purposes. This requires 5 million messages per month=166000 messages per day=7600 messages per hour=2 messages per second. For the exemplary IS-136 compliant system described above and assuming about 100 bits payload available per S-BCCH slot (every 0.64 second), an address length of 32 bits to identify each subscriber's equipment and 1 bit for the enable/disable flag, this results in 3 enable messages per slot or about 4.7 messages per second. Thus, the enable/disable message requires approximately the capacity of one half of a S-BCCH slot. During off-peak hours, one or more S-BCCH slots can be assigned for this purpose and, correspondingly, none during peak hours. If there are multiple services with multiple associated status variables, only one additional bit per service needs to be transmitted. However, a service identifier may have to be transmitted also if a fixed mapping position in the message is not used, which service identifier may provide a more flexible protocol. The format for the message could then be: address, SV1, SV2, SV3 using a fixed mapping of bit position and service number or: address, SI1, SV1, SI2, SV2, . . . where SI is the service identifier. In addition to being bandwidth feasible, Applicant envisions this status variable B-SAC embodiment to also be commercially viable given the industry practices today. Considering that most users are not sufficiently technically proficient to tamper with a remote device's programming, e.g., to manually reset the status variable, it seems unlikely that this type of fraud would commercially impact the service provider's. Moreover, given the size of the companies that manufacture these remote devices, the subsidization of prices associated with remote devices as an incentive to sell services and the distribution channels for these devices, it seems unlikely that "black" market devices having permanently enabled status variables would be sufficiently valuable to pose problems. Although the status variable B-SAC embodiment provides a beneficial balance between ease-of-use and access control, some service providers/system operators may desire additional access control and some level of data integrity to be accorded these types of broadcast services. Therefore, according to another exemplary embodiment of the present invention, the information broadcast by a service provider may be encrypted. Remote devices can download a decryption (service) key which can change, e.g., on a monthly basis. A special teleservice can be developed for the downloading or it can be an additional element in the Over-the-air Activation TeleService (OATS) set forth in EIA/TIA IS-136. Along with the decryption key, a validity time can be included. Alternatively, a key index is provided. In the broadcast information service channel itself (e.g. stock quote) or in a general place on the BCCH, the current key-index or validity time is provided. This allows the remote device to determine that the service key it has is valid. This is important when e.g. the device has been powered off for a long time. If the key index or the validity time does not match the stored data in the device, the user is alerted. Note that the term service key as used herein does not necessarily imply strong algorithmic encryption techniques. In its simplest form the service key could be a "PIN number" or, in this context, a Service Identification Number (SIN). This is not the same as the Service Identifier which identifies a particular service from a palette of services. If there is no provision to enter the service key through some means easy for a typical user, the service key and key index can be merged i.e. the SIN can be sent in clear form on the BCCH. However, a validity period should preferably be provided. Although a hacker can easily read the SIN, there is no simple way of entering it into the device for ordinary users. In order to avoid interrupted service when the service key is changed, the system may issue the subsequent service key in advance e.g. a week in advance. Thus, the remote device will store both the current service key and the subsequent service key. The mobile will automatically change service keys according to information found on the BCCH. If key index is used, the mobile will first check the index before attempting to read the service content. If validity time in form of a date is used, the mobile can look for a date from the BCCH or if not present, from an internal clock. If the user enables a broadcast service and the device determines that the service key is not valid or that the status variable is disabled (if no encryption as described above), the user is informed with an indication on the display and/or an audible alert. A simpler form of protecting the data broadcast by the service provider is to use a simple form of scrambling instead of encryption. Although scrambling may not bar hackers from reading the information, most potential subscribers will not attempt to access the scrambled data. The benefit achieved with scrambling versus encryption is that the computational complexity is reduced. For example, the data or part of the data may be altered by a semi secret variable e.g. the key itself. A cyclic redundancy check (CRC) on the service layer may be altered (e.g. EXOR'd with the key) or the calculation of the CRC may include the key in addition to the data. A lower layer CRC should not be used for this purpose since the remote device can then not distinguish channel errors from service barring. FIG. 6 illustrates signalling associated with a B-SAC based on scrambling (or encryption) according to this exemplary embodiment. The first event (identified by the leftmost arrow pointing upward toward the timeline) is that the system sets the key to kn. At time t.sub.1, while kn is still valid, the user requests the broadcast service. The service server sends, through the wireless system, the service key a certain number of times, e.g., which procedure is particularly desirable when type B remote devices are being supported by the system. In this example, the third instance of the message containing service key kn (as indicated by the smaller arrows pointing toward the timeline subsequent to time t.sub.1) is correctly received by the remote device. This begins the period of time during which the remote device can read stock quotes from the broadcast service. At a later point in time t.sub.20, while kn is still valid, the user requests termination of the service. The system need not do anything, but instead may permit the user to use the service until the service key expires. At some predetermined time, the system changes the key to kn+1. The user can no longer decrypt the data and the service can not be presented to the user since the broadcast information is now transmitted in an encrypted form using a key which is unknown to this remote device. Those skilled in the art will appreciate that it is possible to combine the disable signal from the embodiment described above with respect to FIG. 5 with this encryption (scrambling) embodiment and have the system send a disable signal to the device with the assumption that the devices are designed to honor the request to be disabled. In FIG. 7 another example wherein the B-SAC is performed by scrambling (or encryption) is depicted. The difference between the example of FIG. 6 and that of FIG. 7, is that the user does not request to terminate the service in the example of FIG. 7. In this case the system sends the new service key kn+1, preferably before the new key becomes valid. A number of transmission instances are provided used in order to maximize the likelihood of having the device receiving at least one of them. Since the key has an index or validity time, the remote device would know that these are just repetitions if it receives more than one. When the kn+1 validity time ends, the system repeats the procedure and sends service key=kn+2 a number of times. This continues until the user wants to terminate the subscription and the procedure defined in FIG. 6 then becomes applicable. In both of the foregoing exemplary embodiments, i.e., status variable and encryption(scrambling), the system must send either an enable/disable message or a service key to the remote device. The sending of the status variable message or service key can be performed on a point-to-point channel, or on the broadcast channel. Although the embodiments of FIGS. 5-7 are described in the context of non-acknowledged status variable or encryption (scrambling) B-SAC embodiments, note that other than the "shotgun" approach of sending multiple messages to the remote devices, the other aspects of these figures are equally applicable to B-SAC embodiments according to the present invention wherein the status variable messages or encryption key messages are acknowledged by the remote devices. For the B-SAC embodiments employing encryption, the service key can be sent on the broadcast channel itself. Preferably, transmission of the service key should also be encrypted, since otherwise the information contents of the service itself may as well be unencrypted if a remote device can read the service key. Note that the service key is the same for all users since the service is a point-to-multipoint service. By encrypting transmission of the service key, fraudulent users can then not read the service key and use it in their devices to read information from a broadcast service. On the broadcast channel, the service key can then be delivered as an addressed message (i.e. the device address is present in the message), encrypted with a personal (unique) key associated with the remote device. For type A devices, conventional cellular encryption techniques can be applied when sending the service key, e.g., sent in an OATS message, or in a special purpose message, encrypted as any other voice or message transaction (e.g., based on the A-key for the TIA standards). However, it is also possible to perform the encryption of the service key using a special (for this purpose) key, referred to herein as the B-key. For a type B device, which does not reveal any information by way of its transmissions, the ESN or similar equipment identifier can be used as the B-key. For Type A and B devices, the B-key may be loaded at manufacturing or entered through the keypad if the remote device has this capability. For type A devices, the OATS procedure, or some similar technique, can be used to download the B-key. For type A devices, the standard MIN/IMSI identifiers can be used for the address of the B-key message. For type B devices, the address can be an equipment identifier (ESN) or an assigned MIN/IMSI. For both A and B type remote devices, a dedicated identifier, termed here a Broadcast Identifier Number (BIN) can be assigned to the device and used for the address. However, the ESN should not be used for both BIN and B-key, since otherwise the decryption key is transmitted in the clear and the purpose for the encryption is lost. In order to save channel capacity in exemplary B-SAC embodiments wherein acknowledged teleservice mechanisms are not used to deliver the service key, the service key for the next period of subscription can be sent when there is less broadcast service data to send, typically nights and early mornings. Thus the user should have the device turned on during off-peak hours to change the service key. While leaving the remote device on during off hours may be undesirable, the increased access control and data integrity associated with encryption may be seen to offset this drawback. For example, these encryption (scrambling) B-SAC embodiments provide mechanisms to bar ineligible users from accessing broadcast information even if they have the capability to manipulate registers and signals within their remote devices. Even if a user can retrieve the service key from one device, the knowledge necessary to enter the service key into multiple devices in a manner which would allow others non-subscribers to read the broadcast information is highly specialized and not easily provided to the public. If the broadcast service is disabled, e.g., by the lack of proper decryption key or by having the status variable set to disabled, the user may be informed that by dialling a special number, the service can be activated. For example, the service provider may issue the following activation information, which could be sent along the billing statement:
monthly
Service fee activate deactivate
1. Stock quotes $19.95 *92*23*1 *92*45*1
(all stocks found in USA Today)
2. Currency $0.95 *92*23*2 *92*45*2
3. Options $4.95 *92*23*3 *92*45*3
4. mutual funds $9.95 *92*23*4 *92*45*4
(all funds found in USA Today)
5. Sports scores $4.95 *92*23*5 *92*45*5
(all major leagues, 30 minutes de-
layed)
This table uses, purely as an example, the digit pair 23 as a code for broadcast service activation, 45 as a code for deactivation, and the last digit indicates the broadcast service number. For type A remote devices, the user may be forwarded to an automatic voice prompt system and requested to confirm a choice by pressing a specified key pad entry. The B-SAC teleservice, containing the service key and other attributes described below, is then downloaded. These attributes may include a text message displayed to the user saying that the service is now enabled. Alternatively, a regular SMS message may be sent along the B-SAC teleservice to indicate the successful activation. The user may be prompted for the time of subscription. If the user selects more than a single minimum time period, multiple service keys and associated attributes can be downloaded. Since there are multiple services that can be subscribed to on an individual basis, each service has its own key or its own service status variable. When an activation signal is sent, the following attributes may be included: service identifier, key, key index, validity period, text describing changes to the service (planned or recent changes) e.g. additions of new types of securities, greeting text, telephone number if problem receiving the service, . . . etc. The system may request to retrieve the key in order to verify the contents of the mobile. In order to avoid false base stations polling for the mobile's keys, only the key index or validity date is sufficient to transmit. This may also be used for maintenance, i.e. using the LDE communication form. However, there are other mechanisms to protect against fraudulent base stations, e.g. using strong encryption on the communication channel or specifically for the B-SAC teleservice. When deactivation is requested the operator may just omit sending the next decryption key or if the status control technique is used immediately send and deactivation signal to put the status to disabled. If the user turns off the phone, in an attempt to avoid receiving the deactivation signal, the system may automatically send this message again when e.g. the device performs a registration (assuming a regular mobile i.e. a type A remote device). For a type A2 remote device the service key etc. could be entered locally. This may be deemed valuable when testing or performing maintenance of the device. For example consider that the user has a complaint regarding the operation of his or her current device and is given a new device while the original device is sent for maintenance. The user still wants to continue receiving information broadcast by his or her subscribed services. The A-key (for regular authentication) can be entered through the key pad. The service decryption keys however should not be entered directly but rather a highly secure form of encryption or other special equipment should be used. Otherwise someone could publish the decryption key on the WEB and any user could enter the key himself. Secure means to access protected program areas in mobile phones are developed and in currently in use. Other optional functions associated with B-SAC may also be implemented. The user may set the remote device to receive a subset of the services subscribed to, e.g. by using the key-pad. The user may, e.g. by entering a special mode, obtain information about remaining subscription time. This may be of special interest for pay-per-view type of subscription or pre-paid which now has become a popular method to acquire users with questionable credit. At activation, the user may have accepted a one time charge for a limited time of service access. The user may have subscribed to multiple time segments and hence have been downloaded several instances of keys for a particular service. The user may have provided a credit card number when the activation request was generated. For smart card applications, the pre-paid service credentials may be stored on the smart card. A set of keys with attributes, potentially for multiple time segments, may have been programmed into the card when the card was manufactured. In this case, the decryption key is provided on the card and may be sent to the device for decryption in the device or the data subject for decryption may first be sent to the card for decryption and then sent back to the device for presentation. In summary, to accommodate type B devices, in particular type B2, the embodiment described above with respect to FIG. 5 is suitable where, on the broadcast channel itself, the signals in the form of status variables or keys are transmitted. An advantage of the status variable solution is that the device need not have any other parameter known to the system than the address. The user who requests a service may inform the operator about the address of the device (e.g. printed on the device). The B-key, however, can not be printed on the device. The service operator then establishes a relationship between an address and a B-key which the manufacture has entered into the device. The same procedure that has been established for transferring an A-key in present cellular phones, before OATS became available, between manufactures and operators can be used. For B2 devices the B-key can not be changed. If the link between address and B-key is ever lost, the device is made inoperable. For B1 type remote devices, a new relationship can be established between an address and a B-key by entering a new key. Once the operator has decided whether it will support type A remote devices only, type B devices only or both type A and type B devices, a B-SAC methodology in accordance with the principles set forth herein can be developed. If an operator predicates B-SAC design on support of only type A remote devices, e.g., in the interest of maintaining the whereabouts of a remote device, then perhaps most B-SAC applications would include the use of an acknowledged delivery teleservice, e.g., OATS, to send either the status variable enable/disable message or the service key to the remote device. Such an exemplary (encryption) embodiment would have some or all of the following features. First, transmit the broadcast service information in an encrypted form. Second, encrypt the service key (used to decrypt the encrypted service information) using a standard form of encryption (e.g., A-key based). Third, use a mechanism that requires an acknowledgement from the remote device, e.g., OATS or a dedicated teleservice to deliver the encrypted service key. Fourth, use the standard MIN/IMSI as the address for the message including the encrypted service key. Other variations of these concepts are also possible. For example, the service could also transmit an indicator as to whether it used a status variable B-SAC like that described above with respect to FIG. 5 or an encryption B-SAC like that described above with respect to FIGS. 6-7. Remote devices could quickly check the indicator to see if they are authorized to read the broadcast information on a particular sub-channel. If unauthorized, the remote device could output a standard message provided by the service provider, e.g., "dial *888 to obtain additional information to activate this service." Commercials for the broadcast service on a sub-channel (or other types of commercials) could also be output, e.g., as a headline banner on the display of the remote device. For example, if the remote device is not authorized to read the broadcast information, e.g., if the status variable is disabled or it does not have the designated key, then commercials may be provided or, alternatively, commercials may be interspersed among the other broadcast information. For example, a description of the contents or a sub-set (sneak view) of the broadcast service which are charged for may be provided on the broadcast channel itself or as a point-to-point message. The descriptions and/or a sneak preview of the service is a form of commercial and provides a teaser to attract more customers. Several exemplary implementations for this sneak preview embodiment will now be described. Note that more than one of these techniques may be used at the same time. First, a commercial preview may be provided on a broadcast channel without access control. Even if the subscription form of the service is controlled using an encryption or scrambling based B-SAC, the preview version is not encrypted. A separate identifier for the preview portion of the information broadcast on the associated channel or subchannel regarding B-SAC is provided, i.e. indicating the service and that no encryption is used for the preview portion. The value for the identifier for the preview may be different than for free services in general. Thus, the user and/or the mobile may recognize that this is a preview of otherwise charged-for broadcast information contents. Similar preview mechanisms can be provided which have access control using a status variable based B-SAC. An identifier can be set to a value indicating a free sub-set of the otherwise charged for service. A second instance of B-SAC control for the charged-for service is provided i.e. set to the status variable to enabled. As an example, the preview contents may include most hold stocks/funds, most active stocks/funds, etc., instead of the complete set available on the charged-for portion of the channel. As a second variation, the entire broadcast service may be made not subject to B-SAC during a limited time. For example, once per month the entire service may be free of charge. If encryption or scrambling based B-SAC is used, the encryption is disabled. The value of the B-SAC control identifier may be different than for free service in general. Thus, the user and/or the mobile may recognize that this is a temporarily free service of what would otherwise be charged contents. A similar provision may be made for status variable based B-SAC. An identifier can be set to a value indicating a free service. As a third variation, a message can be provided, e.g. using a broadcast channel or a point-to-point channel, indicating a description but without an actual sample of the broadcast information service. For example, for a security service it may state that the user will be provided with information regarding all stocks and mutual funds found in the USA Today or Wall Street Journal or any other scope that a user would understand. For a sports result channel, the scope listed can be what leagues' scores are provided e.g. NHL, NBA etc. The user may enter a command and the remote device will display both the available broadcast services and an indication as to which of these services the user is eligible to receive (or, alternatively, the remote device may simply display only those services that the user is eligible to receive). A particular service may be available for a fee by one operator, but available free by another operator. The user may select a displayed service from the menu for more information. In this way, the remote device presents a description of the broadcast service to the users. The information regarding the preview itself, temporarily free content, as well as a description of the preview content can be provided to the remote device or the user by, for example,: (1) including a commercial in the billing statement e.g. that there is a preview channel, when the entire channel is free and where and how (e.g. what key-pad entries to use) to find the description channel, preview channel and the free channel; (2) sending the information to the user using the wireless system e.g. an SMS message or a fax; (3) indicating, e.g., on a service operator's website, a simulated (e.g., not current data) version of the broadcast channel's information or a replica of what is currently transmitted on the wireless channel (with a potential delay between the two transmission means given implementation and protocol constraints). The user would then see a simulated screen representing a lap-top or other device with the contents being updated to provide a realistic view regarding how the service would look if subscribed as an interface between the wireless service and the user's equipment. An alternative to the provision of an identifier indicating a preview is to send the encryption key to all mobiles or the mobiles selected by the system or service operator to get the preview. The preview and the rest of the channel are encrypted with different keys. Drawbacks associated with this implementation include that: regular customers must have two service keys or that the preview contents must be repeated within the regular service, the sneak view customers must be given an encryption key, which increases the demand of distributing keys. This same technique ( and resulting drawbacks) apply to broadcast services employing the status variable based B-SAC mechanism and for the free (as opposed to the preview) channel. A particular broadcast service may be delivered and/or sold with different attributes in order to tailor the service to various market interests. For example, a stock quote service may be delivered in real time or delayed. Since it takes some time to deliver a service over a wireless interface, a "real time" broadcast information service is denoted here as a Near Real Time (NRT) service. That is, at the service server the information is real time but due to delivery time, including channel errors, it may take some additional time to deliver the information to the end user and, therefore, can not be offered as a real time service. Alternatively, for a lower charge the user can subscribe to a delayed service. Two logical sub-channels (or sets of logical sub-channels) can be allocated for the dual purposes of NRT service and delayed service associated with the same broadcast information. Separate status variables or decryption keys are used for each. However, this parallel service transmission would increase the bandwidth requirement to be the sum of both the fast and the slow service. Another, more efficient, solution is to only transmit the NRT service. If the B-SAC methodology implemented for these broadcast services is based on the status variable concept, each service level has its own service indicator (SI). One of the SIs allows the remote device to present the data as it arrives in the device without any restrictions, i.e., to provide NRT service. The second SI implies, by the design of the device, to delay the presentation of the broadcast information by a certain amount of time, i.e., to provide delayed service. Both SIs are sent on the BCCH. Alternatively, a common SI is used and an additional identifier, sent to the device when updating the SV, is used to indicate delayed presentation. The required delay can be sent along the service itself, e.g., on the BCCH. Alternatively, the delay can be entered by the manufacture or sent as a point-to-point message over the wireless link. If the B-SAC methodology implemented is based on the encryption concept, both service levels read the same date and hence use a common key. At key delivery, an additional identifier is sent to the device informing whether the remote device shall impose a delay or not before presenting the data. An alternative solution, which more strongly protects the service from fraudulent usage, is to provide a secret variable alongside the service data. The variable changes periodically for the non-NRT subscribers in an unpredictable fashion. Thus, in addition to the basic encryption, the entire broadcast information service contents are scrambled or encrypted with this secret variable. This secret variable can be sent in the clear or sent under the protection of the basic encryption when the required delay has occurred. The non-NRT subscriber must wait until this variable is present on the channel until it can fully decrypt the service data. All previously received service data since the last presence of the variable is decoded using the variable and the basic decryption key. The variable may be sent repetitively around the time when the stipulated delay has occurred in order to be less sensitive to channel errors. The NRT subscribing remote devices will receive information sent along with the key delivery such that it can decode the data without any delay. For example, a non-linear shift register can be used which outputs the secret variable. The content of this shift register for a given time tic (where the tic is incremented with respect to the delay) is known to the device, which can thus calculate the current value of the secret variable and decode the service data as it arrives. Having the delay not be hardcoded in the remote devices allows the operator to change the delay. More than two levels of delay can also be used since the delay may be device specific or multiple delays can be transmitted on the BCCH. The aspect of delayed delivery is applicable to any of the broadcast service information that may be time/cost variable, e.g., sports results. The organization of the services may be such that the NRT provides only a summary of the information provided on the delayed service, e.g., market indexes, most heavily traded stocks, most commonly held stocks, etc. This summary may or may not be provided by the delayed service as well, i.e., the summary may be a subset of the delayed service. This organization may be of interest if the full scope of the service requires more than a feasible amount of bandwidth to transmit in NRT, i.e., since the faster information associated with a service is to be delivered, the shorter the cycle time and the higher the bandwidth requirement. If providing all of the broadcast information for a particular service in NRT mode is not feasible, organizing the services as a summary in NRT mode and a fuller version in delayed mode still provides a manner whereby the service provider can offer multiple levels of service. Thus, the user may subscribe just to the NRT summary service, just to the fuller delayed service or to both. Again, the appropriate number of keys or SI/SV are delivered to the subscribing remote devices. In addition to delineating different levels of service, the remote devices may operate to read broadcast information services in a manner which is intended to reduce power consumption in those devices. Thus, a remote device may not always read the broadcast service information to which that remote device has access by virtue of having a valid key or having an enabled status variable. For example, the user may set his or her remote device to read a particular, subscribed service only once per hour or once every ten minutes. For broadcast services having different service levels or different parts (e.g., the different sub-channels of the security quote service described above), the reading periodicity of the remote device may be varied by service level or service part. Exemplary service parts also include stock indices or securities which are part of a particular portfolio. Moreover, reading may triggered by more intelligent mechanisms than simply predetermined time intervals. Using the summary NRT and fuller delayed service example described above, the user could set his or her remote device to read the summary NRT every cycle or periodically, e.g., every ten minutes. Then, if information associated with a particular security/index of interest was read on the summary NRT, the remote device could be set by the user read the fuller, delayed version of the service. Alternatively, instead of automatically reading the fuller delayed version of the service, recognition that a preset user triggering condition has occurred could result in the remote device outputting a query to the user regarding whether the fuller, delayed version of the service should be read. The user can request the remote device to read, e.g., one cycle of the desired information. This request can be limited as to a subset of a cycle based on, for example, a predetermined amount of reading time, an attempt to read a full cycle, but if bit errors occur limited to a predetermined amount of reading time, a minimum percentage of the information in a complete cycle, etc. When the information is available, the user is alerted or an icon is displayed on the remote device's screen. Of course, simply because the remote device has acquired new information from a broadcast information service may not justify immediate presentation to the user. Accordingly, the remote device may have several information presentation options which are user-selectable. In one mode information may be automatically presented as acquired. In another mode, when new information is acquired, the device may provide an audible or visual indicator, e.g., an icon, which requires some further input from the user prior to outputting the newly acquired information. As mentioned in the above incorporated U.S. patent application entitled "Channelization and Encoding Techniques for Information Services Transmitted Via Radiocommunication Systems", the information provided by the broadcast information services can be transmitted by the system using broadcast (i.e., point-to-multipoint) resources and/or non-broadcast (i.e., point-to-point including packet data) resources. For example, consider the scenario where a mobile has received, by way of downloading this information from a server accessible via the Internet, an association between a company name and a stock symbol (or just a number), i.e., the type of information found on the Security Name sub-channel in the exemplary embodiment of FIG. 3, via an addressed message. Then, the system may only broadcast the start value sub-channel and the delta sub-channel. Alternatively, the information found on the start value sub-channel may also be provided to remote devices using addressed messages. Even all three of the sub-channels may be provided as addressed messages. For example, once a remote device has downloaded the information associated with he security name and start value sub-channels, it can then request via SMS the delta channel information, e.g., for specific stock symbols or numbers. Yet another alternative is to allow the user to define a portfolio with a service server. Then, a remote device initiated request may simply ask for information regarding the entire portfolio. Upon receiving this request, the service server could provide this information via a teleservice including the information associated with both the start value and delta channels or just the delta channel. Another possibility is that a predefined trigger could result in the downloading of this information. While the present invention has been described with respect to a securities quote service, one skilled in the art will appreciate that the invention would equally apply to other such systems where information is broadcast to a user. Moreover, the LDE described herein can be a cable, an infrared device, a keypad, or a wireless short range communication link. The LDE can communicate with a PC (the user may have gotten the decryption key as an e-mail, and an application program communicates with the device) or a special programming unit owned and operated by the operator or a dealer. Many variants and combinations of the techniques taught above may be devised by a person skilled in the art without departing from the spirit or scope of the invention as described by the following claims.
|
Same subclass Same class Consider this |
||||||||||