Patent Publication Number: US-6993132-B2

Title: System and method for reducing fraud in a digital cable network

Description:
FIELD OF THE INVENTION 
   The present invention relates to cable networks, and more particularly to an architecture that provides improved platform validation or fraudulent access prevention in digital cable networks. 
   BACKGROUND OF THE INVENTION 
   Cable system operators charge monthly fees for various services. Cable systems can be implemented using analog and/or digital networks. The analog cable networks typically offer limited services such as basic channels and premium channels. In addition to basic services, the digital cable networks offer expanded services including one or more of the following: electronic program guides (EPGs), premium channels, impulse pay-per-view (IPPV), video-on-demand (VOD), interactive sports, game shows, web access and features such as e-mail, chat, and instant messaging, interactive games, and/or services such as shopping (television commerce, or “T-Commerce”), home banking, and personal video recorders (PVR). 
   Some customers may attempt to fraudulently obtain one or more of the cable services. To maintain revenues, service providers must be able to reduce fraudulent access. The ability to cut off and/or to identify the location of customers who have fraudulently obtained the cable services would help to reduce fraudulent access. 
   Service providers must also be able to provide service provisioning in a cost effective manner. In analog cable networks, service provisioning is an expensive process. Referring now to  FIG. 1 , an analog cable network  10  includes a cable service provider  14  that generates cable signals over cable  18 . Cable drops  22 - 1 ,  22 - 2 , . . . , and  22 - n  provide the cable signals to cable boxes  26 - 1 ,  26 - 2 , . . . , and  26 - n  at customer locations. One or more analog filters  30  are added to each of the cable drops  22  at the customer locations to disable or filter out one or more premium channels if the customer is not a subscriber. When a subscription change is requested, the cable service provider  14  must dispatch a crew to the customer location. The crew adds or removes the filters  30 , which remove or add, respectively, a premium channel. The cost of dispatching the crew must be included in the price of the premium channel, which increases the cost to the consumer. 
   OpenCable™ is a standard that has been defined by cable operators to provide digital cable-ready devices using a common platform. Referring now to  FIG. 2 , the OpenCable™ standard defines a host  50 , which is typically a set top box  50 - 1  or an integrated television  50 - 2 . The set top box  50 - 1  is typically connected to a television or monitor  54 . A POD module  58 , which is removable from the host  50 , provides security and user authentication. The POD module  58  contains functionality that is associated with a proprietary conditional access system of a local cable provider or multiple system operator (MSO)  60 . The POD module  58  is provided by the MSO  60  and is typically implemented using a PCMCIA or PC card. The POD module  58  may communicate with the MSO  60  using an in-band channel  64 - 1  and/or an out of band (OOB) channel  64 - 2  over the cable  64 . 
   One goal of OpenCable™ is to provide portability. A consumer who purchases the host  50  for one cable system can relocate to another cable system and use the same host  50 . OpenCable™ also seeks to lower the cost of service provisioning and to reduce fraudulent access. The OpenCable™ Applications Platform (OCAP™) specifications (OC-SP-OCAP1.0-I04-021028 and OC-SP-OCAP2.0-I01-020419) which are hereby incorporated by reference in their entirety, provides an open interface between the manufacturer&#39;s operating system (OS) and the various applications that will run within the host  50 . Currently, developers of interactive television (iTV) applications must rewrite their programs for each proprietary platform. OCAP™ provides a standard application programming interface (API) to allow applications to be deployed on all hosts  50 . 
   To allow portability, encryption and security are separated from the host  50  and are located in the POD module  58 . When inserted into the host  50 , the POD module  58  decodes encrypted content from the cable provider  60 . 
   OpenCable™ provides channel-based service provisioning. When the consumer requests a premium channel or other resource, the POD module  58  sends a message to the cable provider  60 . If the consumer subscribes to the premium channel or other resource, the cable provider  60  sends an entitlement message (EMM) back to the POD module  58 . If the EMM is received, the host  50  is granted access. For premium channels, the granularity of control provided by OpenCable™ is at the level of a physical channel. In other words, the premium channel is either enabled or disabled. 
   OCAP™ also specifies a mechanism for platform validation, which detects fraudulent and/or compromised receivers in hosts. As used herein, platform validation and fraudulent access prevention are used interchangeably. A certificate, a signature file and hash files are embedded in the receiver of the host. The hash file enumerates a list of hash values for memory blocks in the receiver. A monitor application (MA) reads the blocks of data over a data bus and computes the hash value. The MA compares the computed hash value to the hash value specified in an encrypted file. The MA takes appropriate action such as terminating service and sending notification to the MSO when a mismatch occurs. 
   There are several disadvantages with the foregoing mechanism for preventing fraudulent receivers. First, the hash file is embedded in the receiver. The contents of the hash file cannot be easily changed without reprogramming the receiver. Secondly, the MA computes the same hash value every time. Hackers can monitor the host data bus for hash calculations. Over time, hackers will figure out the hash function since the computation would be very predictable. In addition, the API for the OCAP™ specification has been published, which includes API&#39;s for reading the contents of the flash memory. In summary, the entire firmware is exposed using this approach and the likelihood of fraudulent access is significantly increased. 
   Additionally, the OpenCable™ standards define a resource manager (RM) that manages system resources such as tuning, audio/video decodings, graphics plane and background devices. Once programmed, the RM manages resource contention based on predefined default rules that cannot be changed without reprogramming the host. 
   SUMMARY OF THE INVENTION 
   A digital cable network architecture according to the present invention includes a cable medium and a plurality of hosts that include a receiver with a hash function generator that calculates hash values based on a hash function and data from memory blocks in the receiver. A policy file store contains policy files having at least one of a service provider section, a consumer section, and a manufacturer section that can be updated by the service provider, a consumer and/or a receiver manufacturer. A service provider that is associated with the policy file store provides digital cable services over the cable medium to the hosts and downloads monitor applications (MAs) and policy files to the hosts over the cable medium. The MAs access the service provider section, the consumer section, and/or the manufacturer section of the policy file to alter resource contention, alter service provisioning at levels below a channel level, and/or alter fraudulent receiver identification calculations. The hash function of the receiver outputs the hash values to the MA, which compares the hash values to expected hash values to identify fraudulent access. 
   In other features, the hash function generator selectively operates using one of a plurality of selectable hash functions. The MA transmits a hash function selector to the receiver to select one of the plurality of selectable hash functions to be used. The MA transmits a data selector to the receiver to select data blocks from the memory to be used to generate a current hash value. The current hash value is compared by the MA to the expected hash value that is stored in the manufacturer section of the policy file. 
   In still other features, the expected hash value is stored in a table format in the manufacturer section of the policy file and is associated with the data selector and the hash function selector that are transmitted to the receiver. The expected hash values are stored in one of the MA and the manufacturer section of the policy file. The expected hash values are encrypted. 
   Further areas of applicability of the present invention will become apparent from the detailed description provided hereinafter. It should be understood that the detailed description and specific examples, while indicating the preferred embodiment of the invention, are intended for purposes of illustration only and are not intended to limit the scope of the invention. 

   
     BRIEF DESCRIPTION OF THE DRAWINGS 
     The present invention will become more fully understood from the detailed description and the accompanying drawings, wherein: 
     The present invention will become more fully understood from the detailed description and the accompanying drawings, wherein: 
       FIG. 1  is a functional block diagram illustrating service provisioning in an analog cable network according to the prior art; 
       FIG. 2  is a functional block diagram illustrating service provisioning in a digital cable network according to the prior art; 
       FIG. 3  is a functional block diagram illustrating service provisioning in a digital cable network according to the present invention; 
       FIG. 4  is a functional block diagram of the host in  FIG. 3  in further detail; 
       FIG. 5  is a functional block diagram illustrating an example of service provisioning in accordance with the prior art; 
       FIG. 6  is a functional block diagram illustrating service provisioning using a policy file (PF) and a monitor application (MA) according to the present invention; 
       FIG. 7  is a functional block diagram of resource contention resolution using the PF and the MA according to the present invention; 
       FIG. 8  is a flowchart illustrating steps for updating the MA and the PF according to the present invention; 
       FIGS. 9A and 9B  are flowcharts illustrating steps for resource contention resolution according to the present invention; 
       FIG. 10  illustrates a service provisioning example; 
       FIG. 11A  is a functional block diagram illustrating a fraudulent access identification system according to the prior art; 
       FIG. 11B  illustrates a fraudulent access identification method according to the prior art; 
       FIG. 12A  is a functional block diagram illustrating a first fraudulent access identification system according to the present invention; 
       FIG. 12B  illustrates a first fraudulent access identification method according to the present invention; 
       FIG. 13A  is a functional block diagram illustrating a second fraudulent access identification system according to the present invention; and 
       FIG. 13B  illustrates a second fraudulent access identification method according to the present invention. 
   

   DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
   The following description of the preferred embodiment(s) is merely exemplary in nature and is in no way intended to limit the invention, its application, or uses. For purposes of clarity, the same reference numbers will be used in the drawings to identify similar elements. 
   The present invention discloses an open architecture for digital cable services. A monitor application (MA) is periodically updated by the MSO. The MA accesses a policy file (PF) that includes customer, MSO and/or manufacturer sections. These sections can be changed by the customer, the MSO, and the manufacturer, respectively. The policy file allows the customer, the MSO and the manufacturer to customize their respective interfaces without requiring the host, the receiver, etc. to be reprogrammed. 
   For example, the customer can use the customer section of the PF to provide additional content, time and/or monetary control, such as time of operation, program content, gaming content, channels, dollars spent and other details, on levels below the channel level that is currently provided. For example, the MSO can use the MSO section of the PF to update resource contention defaults as situations, business relationships or other conditions dictate. For example, the manufacturer can use the manufacturer section of the PF to alter platform validation calculations over time to avoid fraudulent use by hackers. 
   Referring now to  FIG. 3 , a digital cable network  100  provides digital cable services to a plurality of hosts  102 - 1 ,  102 - 2 , . . . , and  102 - n . The hosts  102  can be set-top boxes, integrated TVs, or any other type of host. The hosts  102  include removable POD modules  104 - 1 ,  104 - 2 , . . . , and  104 - n , which handle security and encryption. The POD modules  104  connect the hosts  102  to the MSO by a cable medium  108  using in-band and out-of-band channels  108 - 1  and  108 - 2 , respectively. The hosts  102  may optionally include a web browser  112 . 
   The MSO  120  includes a policy file (PF) manager  122 , that manages a PF data store  124  containing PFs for hosts in the digital cable network  100 . Each PF preferably includes one or more sections. A first or customer section of the PF is for the customer. For example, the customer may use the customer section to provide service provisioning with additional granularity. An optional second section of the PF is for the MSO. For example, the MSO may use the MSO section to define resource permission settings for host applications and to resolve resource contention between host applications. An optional third section of the PF is for the manufacturer. The manufacturer section may be used to periodically modify fraud identification techniques. The sections of the PF can be modified for each host  102  by the respective section “owner”. In other words, the manufacturer can modify the manufacturer section, the customer can modify the customer section, and the MSO can modify the MSO section. 
   The MSO, the customer, and/or the manufacturer may access the PF in several different ways. Computers  126  that include a web browser  128  can access the PF over a distributed communications system  130  such as the Internet. A web server  132  associated with the MSO interfaces with the PF manager  122  to change the PF. Hosts  102  with web browsers  112  may access the PF using a cable modem over the cable  108  and/or using other Internet access methods. When changes are made to the PFs stored in the PF manager  122 , the MSO  120  pushes the PF to the corresponding host  102 . Alternatively, the MSO  120  notifies the host  102  that a new PF version is available. The MSO preferably encrypts the PF using an encryption device  134  and sends the PF using head end gear  136 . Other services  140  described above are also provided on the cable  108  through the head end gear  136 . 
   Referring now to  FIG. 4A , the host  102  is shown in more detail. When initially connected to the digital cable network  100  and before receiving (or having) a resident MA (MA)  150 , the host  102  is controlled by an executive application (EA)  152  stored in memory  153 , which may include read only memory, FLASH memory or any other suitable electronic data storage. 
   A receiver  154  monitors an extended applications information table (XAIT)  156  in the memory  153 . The MSO  120  notifies the receiver  154  of a current version of the MA  150  using the XAIT  156 . The receiver  154  detects a mismatch between a current MA version (or no MA) and the current MA version in the XAIT  156 . If a version mismatch occurs, the receiver  154  reads a virtual channel table (VCT)  160 , which identifies a physical channel for receiving the MA  150 . The receiver  154  tunes to the specified physical channel and receives the MA  150 . The MSO  120  broadcasts the MA  150  in a continuous loop, at predetermined times, or in any other suitable fashion on the specified channel. After receiving the MA  150  and storing the MA in FLASH, the host  102  begins operating using the MA  150 . 
   The MSO  120  may push a PF to the host  102  when the MA is downloaded. Alternately, the MA  120  may include a routine to automatically download a current PF when a new MA or new MA version is downloaded and stored in FLASH. The MSO  120  also automatically downloads the PF to the host  102  whenever changes are made to the PF. The MSO  120  preferably encrypts the PF using the encryption device  134  before transmission. The MA  150  decrypts the PF and stores the PF (as shown at  164 ) in the memory  153 . 
   The MSO  120  may optionally notify the receiver  154  of a current version of the PF using the XAIT  156 . When the receiver  154  detects a mismatch between a current version of the PF  164  (or no PF) and the current PF version in the XAIT  156 , the receiver  154  contacts the MSO  120  and requests the newer PF version. The MSO  120  sends the newer PF version to the MA  150 , which decrypts the PF and begins operating with the newer PF version. Alternately, when changes to the PF are made by the manufacturer, the MSO and/or the consumer, the MSO  120  can automatically download the new PF to the MA  150 . 
   A customer may select a cable channel, games or other content using a remote control (RC)  168  (which generates a signal that is received by RC receiver  169 ). The customer may also select a cable channel, games or other content using a panel control  170  on a display  172 , the set top box  102 - 1 , or the integrated TV  102 - 2 . The customer may also adjust audio outputs  176  and interface with other input/output devices  178  using the same or other controls. 
   A resource manager  180  manages host resources  182  such as a tuner  184 , a graphics plane  186 , an audio/video decoder  188 , background devices  190  and any other resources. The resource manager  180  manages contention for the resources  182  by applications  192  such as the electronic program guide (EPG), premium channels, impulse pay-per-view (IPPV), video-on-demand (VOD), interactive sports, game shows, web access and features such as e-mail, chat, and instant messaging, interactive games, and/or services such as shopping (television commerce, or “T-Commerce”), home banking, and personal video recorders (PVR). An event manager (EM)  194  handles events using one or more tables, as will be described further below. In  FIG. 4B , the PF  164  may include an MSO section  196 , a manufacturer section  198 , a customer section  199 , and/or other sections. 
   Referring now to  FIG. 5 , an example illustrating service provisioning according to the prior art is shown. The RC  168  sends a change channel request, which is received by the RC receiver  169 . The change channel request is transmitted over the data bus to the event manager  194 . The event manager  194  includes a table of applications, such as the EPG  192 - 1 , APP 1  and APP 2 , that have registered for the change channel event. The event manager  194  transmits the change channel event to the EPG  192 - 1 , APP 1  and APP 2 . 
   The EPG  192 - 1  requests the tuner  184  if needed from the RM  180 . If the EPG  192 - 1  already has the tuner  184  resource, the EPG  192 - 1  calls the tuning API. Before the POD  104  decodes the channel, the POD  104  (which listens for tuning APIs) sends a request — Channel — access message for the appropriate channel to the MSO  120 . If approved, the MSO  120  sends the EMM back to the POD  104 , which decodes the channel. If the EMM is not received, the channel is tuned but not decoded. As was described above, this service provisioning method provides access on a channel level only. 
   Referring now to  FIG. 6 , an example illustrating service provisioning according to the present invention is shown. The MA  150  consults the PF  164  before granting access to the channel  182 . The MA  150  has access to privileged API&#39;s such as application filtering and upgrade, system reboot, resource conflict, event handling, error handling and system functions. In a preferred embodiment, the PF is XML-based program that is downloaded via the POD OOB connection into FLASH memory and the MA is Java-based. While XML and Java are disclosed, any other suitable languages can be used. 
   The MA  150  is an unbound application with privileges. The MA  150  manages the life cycle of all OCAP™ applications, including itself. The MA  150  provides resource contention, registers unbound applications with an applications database, validates the starting all applications, identifies system errors, and reboots the system. The MA  150  can change copy protection bits and output resolution using OCAP™ interfaces. The MA  150  may also filter user input events and change their value before sending them to their final destination. Therefore, the MA  150  can enable and disable keys on the RC  168  or other controls  170 , which will enable and disable functions. 
   In  FIG. 6 , the RC  168  sends a change channel request, which is received by the RC receiver  169 . The change channel request is transmitted over the bus to the event manager  194 . The event manager  194  includes a table of applications that have registered for the change channel event. The MA  150  can override the APP/Event table in the event manager  194 . While the table shown in  FIG. 6  shows the table including MA  150  for the channel change event instead of EPG, APP 1  and APP 2 , the table need not be overwritten as shown. The MA  150  may simply override the current values in the table or otherwise disable the EM for these events and applications. 
   The event manager  194  transmits the change channel event to the MA  150 . The MA  150  consults the PF  164 . If the PF  164  allows the customer to select the channel (and/or other content and/or other resource), the MA forwards the channel change event to the EPG  192 - 1 . Alternatively, the MA can instruct the EM to forward the change channel event directly to the EPG  192 - 1 . Operation continues as described above with respect to  FIG. 5 . 
   Referring now to  FIG. 7 , the present invention also allows resource access to be controlled by the MA  150  and PF  164 . Before granting access to a resource, the MA  150  checks the PF  164 . If the PF  164  allows the application  192  access to the resource, the MA  176  sends an access — approved signal back to the RM  174 . Otherwise, the MA  176  sends an access — denial signal to the RM  174 . 
   The MA  150  also resolves resource contention based on the PF  164 . The application  192 - 3  may currently have a resource such as the tuner  184 , the graphics plane  186 , the audio/video decoder  188 , the background devices  190  and/or any other resource. The application  192 - 2  may request the resource(s) that are currently being used by the application  192 - 3 . The application  192 - 4  may currently have a resource such as the tuner  184 , the graphics plane  186 , the audio/video decoder  188 , the background devices  190  and/or any other resource. The application  192 - 5  may request the resource(s) that are currently being used by the application  192 - 4 . The MA  150  and the PF  164  resolve the conflicts. 
   The MA  150  and the PF  164  may resolve the resource contention based on business relationships. In other words, the MSO  120  may define the MSO section  196  of the PF  164  to resolve resource contention in favor of a business partner. For example, when a first application requests a resource to tune to a particular channel such as Speed™ and another application such as the browser requests the tuner for another reason (and/or already has the resource), the first application will receive the resource. 
   Referring now to  FIG. 8 , exemplary methods for downloading MAs and PFs are shown generally at  200 . Control begins with step  202 . In step  204 , control determines whether the host includes a resident MA. If not, control runs the executive application (EA) in step  206 . In step  208 , control checks the XAIT and VCT and downloads the MA from the MSO on the designated channel. Step  208  may be performed by having the host send the MSO a need — MA message. The MSO responds to the need — MA message by sending the MA. The host stores the MA in memory and then loads the MA into FLASH memory. If the MA is already resident, control runs the MA in step  214 . 
   In step  218 , the host may determine whether the PF is the latest version. If a version match does not occur, the host takes steps to download the PF in step  220 . Step  220  may be performed by having the host send the MSO a need — latest — PF message. The MSO responds to the need — latest — PF message by sending the latest PF version. The host stores the PF in memory and loads the PF into flash memory. Alternatively, the MSO may automatically send the PF when changes to the PF occur. 
   Control continues with step  224  where the host determines whether the MA is the latest version (typically using the XAIT). If the MA is not the latest version, the host tunes to the channel identified in the VCT and downloads the latest MA version in step  228 . Steps  224  and  228  may be performed in a manner that is similar to steps  218  and  220  described above. The host manages resources using the MA and PF in step  230 . 
   Referring now to  FIG. 9A , steps of a method for managing resource contention using the PF  164  is shown generally at  280 . Control begins with step  282 . In step  284 , control determines whether an application (APP) has requested a resource. If not, control loops back to step  284 . If the APP requests a resource, control continues with step  286  where the RM determines whether there is contention for the resource. If not, the RM grants the application the resource in step  288  and continues with step  284 . Otherwise, the RM sends a message to the MA. The MA, in turn, reads the PF to determine whether the resource contention is resolved by the PF in step  292 . For example, the MSO section of the PF may resolve the contention based on business relationship criteria. 
   In step  294 , the MA sends the resource contention resolution to the RM. Alternately, the PF may send the resource contention resolution directly to the RM. The MA may resolve the contention and/or send a not — covered message if the PF does not address the contention. In the not — covered case, the RM may resolve the resource contention using a default rule. In step  296 , the RM resolves the contention. 
   Referring now to  FIG. 9B , the RM also checks with the PF before granting access to a resource even when there is no contention. In step  302 , the RM checks with the MA (which checks with the PF) to determine whether the PF allows the application to use the resource. If not, the RM denies the resource to the application in step  304 . 
   The PF and MA according to the present invention allow finer control over service provisioning and improved resource contention in the digital cable network  100 . The PF and MA allow service provisioning with finer granularity than the channel level provided by the OCAP™ specification. 
   Referring now to  FIG. 10 , an example implementation is shown. A single consumer residence includes STB 1 , STB 2  and STB 3 . STB 1  is located in a controlled environments such as the parents bedroom. STB 2  is located in one child&#39;s bedroom. STB 3  is located in another child&#39;s bedroom. 
   Service provisioning according to the present invention allows control beyond the channel level. In particular, STB 1  is granted full access to basic channels, three premium channels and games all at times by the MSO and customer PF. STB 2  and STB 3  are granted full access to all basic channels three premium channels and games at all times by the MSO as well. However, the customer PF limits access of STB 2  to basic channels during certain times, to some premium channels during certain times, and to other premium channels during certain times and for games with no violent content. The customer PF limits access of STB 3  to basic channels during certain times, to some premium channels during certain times at certain ratings levels, and to all games during certain times. The customer may also define spending limits for total services and/or individual services. 
   As can be appreciated by the foregoing, the digital cable system according to the present invention offers finer granularity of control. The digital cable system allows the creation of tiers of service. The MA can be used to collect usage statistics, which can be used by the consumer for service provisioning. For example, the consumer can set spending limits for pay-per-view or gaming services and/or total time watched from anywhere on the Internet. Program ratings levels can also be controlled by the consumer. 
   In addition, the MSO can remotely disable or reboot the host. For example, the MSO can disable or reboot the host when the customer as an unpaid bill, the policy file has been compromised, the host is under some kind of intrusion, or the MSO does not receive the heartbeat of the MA. In addition, when a consumer has multiple hosts, billing detail can be defined for each host. 
   Referring now to  FIG. 11A , a MA  340  according to the prior art includes a fraud control module  342  that includes a hash function generator and that stores a hash value. The MA  340  reads a certificate, signature and hash file  344  that is embedded in a receiver  345  over a data bus  346 . The hash file  344  enumerates a list of hash values for blocks of information within the receiver  345 . A hash function generator  347  of the MA  340  reads blocks of data over the data bus  346  and computes the hash value. The fraud control module  342  compares the computed hash value to a hash value  348  in an encrypted file. The MA  340  takes appropriate action such as terminating service and sending notification to the MSO when a mismatch occurs. 
   Referring now to  FIG. 11B , control begins in step  352 . In step  356 , control waits for a fraud — check request to be made by the MA, the MSO or the manufacturer and/or the fraud — check request may be time based or event based. If the fraud — check request is received, the MA reads blocks of data over the data bus and computes the hash value in step  358 . In step  360 , the MA compares the computed hash value with the hash value stored in an encrypted file. In step  364 , control determines whether there is a match. If not, the MA takes appropriate action such as but not limited to terminating service, contacting the MSO, or any other suitable action. 
   As can be appreciated, by sending data over the exposed data bus  346  and by repeatedly computing the same hash function in the MA  340 , the conventional system has an increased probability of being fraudulently accessed by hackers. 
   Referring now to  FIG. 12A , the MA  150  includes a fraud control module  374  that generates a fraud request. The receiver  154  includes a hash function generator  375  that generates hash values using one or more hash functions. The memory blocks that are used by the hash function generator  375  may also be varied. The hash function generator  375  receives the hash function request over the data bus  376 . The hash function generator  375  generates the hash function using memory blocks in memory  377 . The hash function generator  375  generates a hash value that is transmitted to the fraud control module  374 . The fraud control module  374  in the MA  150  compares the generated hash value with a hash value that is stored in encrypted form in either the MA  150  or the PF  164 . The hash value may be stored in the manufacturers section of the PA. 
   Referring now to  FIG. 12B , a fraudulent access identification method according to the present invention is shown at  380 . Control begins in step  352 . In step  356 , control waits for a fraud — check request to be made by the MA, the MSO or the manufacturer and/or the fraud — check request may be time based or event based. If the fraud — check request is received, the MA sends a message to the receiver to compute the hash value and transmit the resulting hash value to the MA in step  382 . In step  384 , the MA compares the computed hash value with the hash value stored in an encrypted file and/or in the PF. In step  364 , control determines whether there is a match. If not, the MA takes appropriate action such as but not limited to terminating service, contacting the MSO, or any other suitable action. 
   As can be appreciated, by reducing data transmission over the exposed data bus  346  and shielding the hash function computation in the receiver, the fraudulent access identification system according to the present invention has a reduced probability of being fraudulently accessed by hackers. 
   Referring now to  FIG. 13A , the MA  150  includes the fraud control module  374  that generates the fraud request. The receiver  154  includes the hash function generator  375  that generates multiple different hash functions. The hash function generator  375  receives the hash function request over the data bus  376 . 
   The MA sends a hash function selector identifying one of a plurality of hash functions implemented in the receiver and/or a data selector for selecting the memory blocks to use. The hash function selector and data selector can be randomly selected from the possible hash functions and data blocks. The hash function generator  375  generates the hash function using the selected hash function and selected memory blocks in memory  377 . The hash function generator  375  generates the hash value that is transmitted to the fraud control module  374 . The fraud control module  374  in the MA  150  compares the generated hash value with the hash value that is stored and that corresponds to the hash value selector and data selector that is used. The hash value, the hash function identification and/or memory blocks may be stored in the MA  150 , the PF  164  and/or in the manufacturers section of the PF  164 . 
   Referring now to  FIG. 13B , a fraudulent access identification method according to the present invention is shown at  400 . Control begins in step  352 . In step  356 , control waits for a fraud — check request to be made by the MA, the MSO or the manufacturer and/or the fraud — check request may be time based or event based. In step  404 , the MA identifies the hash function to be used in the hash function selector and/or the memory blocks in the data selector  154 . 
   If the fraud — check request is received, the MA sends a message to the receiver to compute the hash value and transmit the resulting hash value to the MA in step  382 . In step  384 , the MA compares the computed hash value with the hash value stored in an encrypted file or in the PF. In step  364 , control determines whether there is a match. If not, the MA takes appropriate action such as but not limited to terminating service, contacting the MSO, or any other suitable action. 
   As can be appreciated, increasing the number of hash functions and changing the memory block numbers will increase the complexity of the hash value calculation and reduce the likelihood of fraudulent access. 
   Those skilled in the art can now appreciate from the foregoing description that the broad teachings of the present invention can be implemented in a variety of forms. Therefore, while this invention has been described in connection with particular examples thereof, the true scope of the invention should not be so limited since other modifications will become apparent to the skilled practitioner upon a study of the drawings, the specification and the following claims.