Method and system for restricting access to user resources6732179Abstract A user's set top box (STB), or other client, executes a shell and has an application programming interface (API) by which certain features of the client can be controlled. The client is in communication with a walled garden proxy server (WGPS), which controls access to a walled garden. The walled garden contains links to one or more servers providing network-based services. The client sends a request to the WGPS to access a service provided by a site in the garden. To provide the service, the site sends the client a message containing code calling a function in the API. The WGPS traps the message from the site and looks up the site in a table to determine the access control list (ACL) for the site. The ACL is a bit-map that specifies which functions of the client's API can be invoked by code from the site. The WGPS includes the ACL in the header of the hypertext transport protocol (HTTP) message to the client. The shell receives the message and extracts the ACL. The shell uses the ACL to determine whether the code has permission to execute any called functions in the API. If the code lacks permission, the shell stops execution and sends a message to the site indicating that the site lacks permission. Otherwise, the shell allows the code to call the function. Claims We claim: Description BACKGROUND
Walled Garden Permissions Table
URL Prefix User Agent WG ACL Affiliation
http:// . . . DCT-5000 010111 0110
http:// . . . DCT-5000 010101 0100
http:// . . . DCT-5000 011101 0001
. . . . . . . . . . . .
http:// . . . DCT-5000 110101 1000
The permissions table is preferably indexed by URL prefix. The URL Prefix field preferably holds a URL string long enough to uniquely identify the walled garden site having the associated permissions. For example, the URLs "http://disney.com/company/index.html" and "http://disney.com/company/about/index.html" will both match a table entry with the URL prefix "http://disney.com/company/." This technique allows different permissions to be assigned to different subtrees of a site's content. The User Agent field preferably holds a string identifying the type of browser used by the user. For example, the User Agent field may indicate that the user is using a DCT-5000 STB. Alternatively, the field may indicate that the user is using NETSCAPE NAVIGATOR, MICROSOFT INTERNET EXPLORER, or any other type of browser. Since different user agents may have different API sets and capabilities, sites in the walled garden may have separate permissions table entries for each type of user agent. The client 112 identifies the user agent when it sends a HTTP request to the WGPS 414. The Walled Garden Access Control List (WG ACL) field preferably contains a bit-map, or ACL, indicating to which client APIs the walled garden sites having the given URL prefix can access. The mapping from bit position to API function is arbitrary and extensible. A value of zero preferably means the site does not have permission to invoke the corresponding API function or functions, and a value of one preferably means the site does have permission to invoke the corresponding API function or functions. The Affiliation field identifies the particular walled garden 420 or MSO to which the ACL pertains. The exemplary walled garden 420 illustrated in FIG. 4 contains two walled garden application servers (WGAS's) 422A-B, a walled garden front end server (WGFS) 424, and a walled garden virtual private network (VPN) termination point 426 (WGVPNTP) interconnected by a walled garden network (WGN) 428. The WGN 428 is preferably a closed network and essentially performs as a local area network coupling the various types of walled garden servers with the WGPS 414. A WGAS 422 is preferably a web server or some other form of server that provides web-like functionality to a user. A WGAS 422A may contain all of the hardware and storage necessary to provide a service to a user. Alternatively, the WGAS 422B may be coupled to a remote application database 430 via a dedicated network connection 432. This latter embodiment may be preferred, for example, when the WGAS 422B acts as an interface to a large database of information and the entity managing the WGAS 422B does not wish to replicate the contents of the database within the walled garden 420. The WGFS 424 provides a frontend interface for backend servers located elsewhere on the Internet 130 or otherwise in communication with WGFS 424. For example, a WGFS 424 may be used when a large organization wishing to have a presence in the walled garden 420 leases server space from the ISP or other entity managing the walled garden. The WGFS 424 provides an access point in the walled garden 420 through which the clients can access the backend servers. The WGVPNTP 426 allows an organization to maintain a presence in the walled garden 420 using remote servers. The ISP or other entity managing the walled garden 420 establishes a VPN 434 over the Internet 130 connecting the WGVPNTP 426 with a remote WGAS 436. The remote WGAS 436 communicates through the WGVPNTP 426 to perform the same functions as a local WGAS 422. Each unique service within the walled garden 420 is preferably identified by a unique "plot number." The client 112 preferably identifies a specific walled garden service with the URL "http://wg/<plot-number>/ . . . . " The plot number is preferably used as an index into the ticket and identifies a value specifying whether the user has access to the service. A walled garden service is typically implemented on a single server. However, a single server can support multiple walled garden services. Accordingly, a server may be identified by more than one plot number, with each plot number mapping to a different site residing on the server. A single service can also reside on multiple servers, such as when load balancing is being employed. In this case, a single plot number may resolve to more than one server. The GS 416 controls access to a policy server (PS) 438. The GS 416 preferably receives communications from the client 112 in the form of XML and/or forms via HTTP over SSL and translates the communications into database transactions using protocols such as lightweight directory access protocol (LDAP), SQL, and open database connectivity (ODBC). The GS 416 passes the transactions to the PS 438 and the PS 438 accesses a database 440 of user authorization and authentication information in response. The database contains a list of users, walled gardens, and services in particular walled gardens 420 available to the users. The database 440 does not need to be centralized and, in one embodiment, is distributed on a regional basis. The GS 416 communicates with the PS 438 to authenticate a user's identity and issue the client a ticket specifying the walled gardens and services that the user can access. The GS 416 preferably encrypts the ticket using a secret key shared with the WGPS 424 in order to limit potential attacks on the ticket by the user. The user's client 112 stores the ticket and presents it to the WGPS 414 when seeking to access a walled garden 420. The Internet server 418 is essentially the same as the WGPS 414, except that the Internet server 418 controls access to the Internet 130 at large rather than to the walled garden 420. In a preferred embodiment, the Internet server 418 has a database 444 for holding permissions indicating web sites that users can access and client API functions that the web sites can access. A client accesses the Internet 130 by presenting a ticket to the Internet server 418 specifying the Internet sites to which the user has access. In one embodiment, the ticket specifies the URLs using regular expression pattern matching. The database 444 also identifies poisoned tickets. The keymaster 442 provides encryption keys to the GS 416, WGPS 414, and Internet Server 418. Preferably, the keymaster 442 has SSL links, or some other form of secure communication links, to the servers 414, 416, 418. The keymaster 442 generates pseudo-random encryption keys and securely passes the keys to the servers 414, 416, 418. The servers 414, 416, 418 use the keys to encrypt and decrypt the tickets. In a preferred embodiment, the servers 414, 416, 418 use symmetric encryption and use the same key to encrypt and decrypt tickets, although other encryption systems can be used. Each key is valid for a predetermined time period. The keymaster 442 issues a new key to the servers 414, 416, 418 at the expiration of the previous key. Each key is preferably indexed so that the keys can be individually identified. The entities illustrated in FIG. 4 are not necessarily physically separate or executing on dedicated computer systems. For example, the walled garden network and the network connecting the various servers may actually be a single network that is logically divided into separate networks. Moreover, the various servers, such as the WGPS 414, GS 416, and PS 438, may actually be integrated into the proxy server 410 or another computer system. Likewise, the various databases 415, 440 may be implemented on a single database. Conversely, the functionality ascribed to a single network, server, or database in the description of FIG. 4 may actually be performed by multiple networks, servers, and/or databases, respectively. Thus, FIG. 4 illustrates logical entities and logical interconnections between the entities according to a preferred embodiment of the present invention. However, alternative embodiments of the present invention may have different physical structures. FIG. 5 is a high-level block diagram of a computer system 500 for performing as one or more of the servers, such as the WGPS 414 and/or the PS 428, illustrated in FIG. 4. Illustrated are at least one processor 502 coupled to a bus 504. Also coupled to the bus 504 are a memory 506, a storage device 508, a keyboard 510, a graphics adapter 512, a pointing device 514, and a network adapter 516. A display 518 is coupled to the graphics adapter 512. The at least one processor 502 may be any general-purpose processor such as an INTEL x86 compatible- or SUN MICROSYSTEMS SPARC compatible-central processing unit (CPU). The storage device 508 may be any device capable of holding large amounts of data, like a hard drive, compact disk read-only memory (CD-ROM), DVD, or some form of removable storage device. The memory 506 holds instructions and data used by the processor 502. The pointing device 514 may be a mouse, track ball, light pen, touch-sensitive display, or other type of pointing device and is used in combination with the keyboard 510 to input data into the computer system 500. The graphics adapter 512 displays images and other information on the display 518. The network adapter 516 couples the computer system 500 to a local or wide area network. Program modules 520 for performing the functionality of the server, according to one embodiment of the present invention, are stored on the storage device 508, loaded into the memory 506, and executed by the processor 502. Alternatively, hardware or software modules may be stored elsewhere within the computer system 500. In one embodiment of the present invention, one or more of the illustrated servers are implemented using redundant hardware to create a high-availability computer system. As is known in the art, an advantage of a high-availability computer system is a reduced risk of system failure. FIG. 6 is a flow diagram illustrating transactions among the client 112, WGPS 414, GS 416, and keymaster 442 according to a preferred embodiment of the present invention. The illustrated transaction sequence represents only one of many possible sequences of transactions. In FIG. 6, a horizontal arrow represents a transaction where the primary flow of information is in the direction of the arrow. The slash across the transaction illustrates the protocol used to transmit the data, typically either HTTP or the SSL. In addition, FIG. 7 is a flow diagram illustrating transactions between the WGPS 414, GS 416, and keymaster 442 that may occur independently of the transactions of FIG. 6. Initially, the user uses the UI on the client 112 to request 610 access to a service in the walled garden 420. For example, the client 112 may generate a UI on the TV 110. The user, using the UI and an input device such as an IR keyboard, requests access to the service through the web browsing software 324 executing on the client 112. Alternatively, the client 112 may be coupled to or integrated into a computer system and the user may use web browsing software to request access to a web site in the walled garden 420. As mentioned above, the request 610 from the client 112 to the WGPS 414 preferably takes the form of a URL such as "http://wg/<plot number>/ . . . . " In one embodiment, the user visits a web page or portal that references, either directly or indirectly, all of the available walled garden services. When the user selects a link to a particular service, the web page directs the client 112 to the proper URL. The WGPS 414 receives the request 610 and determines from the URL that the client is attempting to access a restricted service in the walled garden 420. Assume, however, that this request 610 is the first request from the client 112 to the WGPS 414. As a result, the client 112 did not include a ticket with the request 610. Therefore, the WGPS 414 denies 611 access to the walled garden 420 and sends a HTTP 407 response to challenge 612 the client 112 to supply the ticket in a subsequent request. The client 112 receives the challenge 612. Preferably, the web browser then passes control to an authorization dynamic link library (DLL) executing on the client 112. The authorization DLL creates the appropriate UI to let the user authenticate himself or herself to the client 112. The authorization DLL then establishes a SSL connection with the GS 416 and makes a request 616 for the ticket by sending the user authentication information, as well as the Box ID of the client 112, across the SSL connection. The GS 416 authenticates the user by validating 618 the authentication information against the information in the database 440. If the validation 618 is successful, the GS 416 preferably constructs 620 the ticket. As shown in FIG. 8, the ticket 800 preferably includes the Box ID 810 of the client 112 requesting the ticket, a version number 812, an expiration date 814 (or duration when the ticket is valid), an affiliation 815, and a set of bits representing the access rights of the user 816. The version number 812 is preferably a control number used by the GS 416 to ensure that the WGPS 414 properly interprets the ticket 800. The expiration date 814 can be any time in the future or a time span when the ticket 800 is valid and may range, for example, from a few minutes to a few hours. The affiliation indicates the particular walled garden 420 or MSO to which the ticket 800 pertains. The set of bits representing the access rights of the user 816 are preferably organized such that certain bits correspond to certain servers, sites, or services within the walled garden 420. In one embodiment of the present invention, the bits representing the access rights 816 are run length encoded (RLE) to reduce the storage size of the field. Other information, such as the IP address of the client 112 and a timestamp may also be stored in the ticket 800. As shown in FIG. 7, the keymaster 442 occasionally shares 710 a secret key with the GS 416 and the WGPS 414 via an SSL connection. Returning to FIG. 6, the GS 416 preferably uses a symmetric encryption technique to encrypt 622 the ticket 800, T, with the shared secret key to produce an encrypted ticket, T'. In an alternative embodiment, the GS 416 encrypts only the portion of the ticket containing the bits representing the user access rights 816. The WGPS 414 uses the decryption key, which is preferably identical to the encryption key, to decrypt the ticket 800. In one embodiment of the present invention, this encryption is performed using the data encryption standard (DES). However, other embodiments of the present invention may use different encryption techniques, including techniques where the encryption and decryption keys differ. The resulting encrypted ticket is passed 624 to the client 112. The client 112 preferably stores the encrypted ticket internally. Since the client 112 does not have access to the secret key shared by the keymaster 442, GS 4416, and WGPS 414, the client cannot decrypt or alter the ticket. If, for any reason, the GS 416 decides to invalidate or revoke a ticket, the GS 416 poisons the ticket by sending 712 an invalidity notice to the WGPS 414 as shown in FIG. 7. The WGPS 414 treats a request to access the walled garden 420 made by a client with a poisoned ticket as if no ticket had been included. Returning to FIG. 6, the client 112 again sends a HTTP request to the WGPS 414 requesting access to a service in the walled garden 420. This time, however, the client 112 includes the encrypted ticket with the HTTP request in an "Authorization" header. The WGPS 414 receives the ticket with the request and determines 628 whether the ticket grants the user access to the walled garden 420 and walled garden service. To make this determination, the WGPS 414 uses the timestamp to determine the secret key used to encrypt the ticket. Then, the WGPS 414 uses the secret key to decrypt the ticket. Next, the WGPS 414 compares the Box ID in the ticket with the Box ID of the requesting client to ensure that the ticket was received from the correct client 112. The WGPS 414 also checks the expiration date in the ticket to ensure that the ticket is still valid and compares the ticket with the information in its database 415 to ensure that the ticket has not been poisoned. If the above tests are satisfied, then the WGPS 414 examines the affiliation 815 and the set of bits representing the access rights of the user 816 to determine whether the user has rights to the specified walled garden 420 service. To make the latter determination, the WGPS 414 extracts the plot number from the HTTP request and uses it as an index into the set of bits 816 in the ticket 800. Preferably, the value of the indexed bit specifies whether the user is authorized to access the walled garden 420 service or site having the given plot number. This embodiment is preferred because it minimizes the overhead utilized to determine whether the ticket allows access. Of course, alternative embodiments of the present invention may use different techniques to encode the user access rights in the ticket. The WGPS 414 then either grants or denies 630 access to the user. If the WGPS 414 grants access, then it allows the user request 626 to reach the walled garden 420 service having the specified plot number. Accordingly, the specified URL from the walled garden server will be served to the client 112. In this case, the client 112 downloads and executes the JAVA, HTML, XML, and/or JAVASCRIPT code providing the service as described below. Preferably, the downloaded code is not persistently stored in the client 112. If the WGPS 414 denies access, then it sends a HTTP status 407 response to the client 112 with an HTTP header indicating the reason for denying access. Typically, the client 112 will respond to this denial by requesting 616 a new ticket from the PS 438. FIG. 9 is a flow diagram illustrating transactions among a Walled Garden Server (WGS) 910, the WGPS 414, and the client 112 according to a preferred embodiment of the present invention when the WGS responses to an client request for a service. The WGS 910, which may be any of the server types described above, sends 912 a message to the client 112 via HTTP. The message contains code in JAVASCRIPT invoking one or more of the functions in the APIs implemented in the shell 326 of the client 112. Other embodiments of the present invention may use languages other than JAVASCRIPT or other invocation methods, such as MACROMEDIA FLASH, to call API functions. The message from the WGS 910 to the client 112 necessarily passes through the WGPS 414. Preferably, a proxy plug-in on the WGPS 414 traps all messages from WGS' to clients in order to attach an ACL to each message. When the WGPS 414 traps a message, it examines 914 the header provided by the WGS 910 for any potential security violations. For example, the WGPS 414 strips any improper headers off the message to protect against masquerading or spoofing by the WGS 910. Then, the WGPS 414 looks up 916 the corresponding entry in the Walled Garden Permissions Table stored in the database 415 and retrieves the ACL for the given service, affiliation, and user agent. The WGPS 414 inserts 918 the ACL into the message from the WGS 910 to the client 112 as an HTTP header. In one embodiment of the present invention, the ACL is inserted into a "athmAPIAuth" header, although other headers or transport mechanisms can be used as well. In addition, the WGPS 414 can place information in the header that further limits the permissions contained in the ACL. For example, the WGPS 414 can restrict the WGS 910 to accessing channel guide data for the current time only, for the next hour, for the next day or week, etc. Similarly, the WGPS 414 can restrict the WGS 910 to accessing channel guide data for only a certain channel or network. The WGPS 414 preferably implements these additional limitations by placing additional fields in the HTTP header. After the headers are inserted, the WGPS 414 passes 920 the message to the client 112. The shell 326 executing on the client 112 extracts the ACL, affiliations, and any other permissions from the headers and determines 922 whether the data grant the WGS 910 access to the API functions called by the attendant code. The shell 326 codifies the mapping from bit positions in the ACL to API functions and enforces the access control. If the ACL does not allow a called API function to be executed, then the shell 326 preferably returns 924 the FAIL_FUNCTION_NOT_AUTHORIZED message to the application or program that invoked the API function. Otherwise, the shell 326 returns 924 the result of the function invocation. In summary, the present invention is an authentication and authorization method and system that lets individual users access one or more of the services within the walled garden 420. The client 112 authentication procedure allows individual users to be authenticated. In addition, the GS 416, PS 438, and associated database 440 can authorize a unique set of access rights for each user. The WGPS 414 ensures that only authenticated and authorized users are allowed to access servers within the walled garden 420. Moreover, the design of the system, including the ticket and shared secret key, provides an efficient implementation, thereby keeping a relatively light processing load on the GS 416 and PS 438. In addition, the present invention enhances the services provided by the walled garden 420 by allowing WGS' to access the APIs of the clients. The Walled Garden Permissions table stored in the database 415 of the WGPS 414 allows the access rights of a WGS to be controlled with a fine degree of granularity with respect to functions, time, and channels/networks. By using the method and system described herein, a service provider or other entity can sell subscriptions or other forms of access rights to one or more services within the walled garden 420. For example, an ISP can sell subscriptions to tiers of services, much like subscriptions to tiers of television channels are sold. In addition, the ISP can sell the right to access the client 112 APIs to the operators of the WGS'. APPENDIX Channel Up Syntax [Status]=TV.ChannelUp( ) Parameters Status The return status value from the ChannelUp method. The return status value will be one of the following: SUCCESS--The tune completed successfully FAIL_INVALID_CHANNEL--The tune failed because of an invalid channel number FAIL_PARENTAL_CONTROL--The tune failed because of parental control and a valid Parental Control PIN was not entered FAIL_CHANNEL_NOT_AUTHORIZED--The tune failed because the channel was not authorized by the CA system FAIL_FUNCTION_NOT_AUTHORIZED--The tune failed because the function invocation was not authorized by the CA system FAIL_NOT_PURCHASED--The tune failed because the channel carried an IPPV event and it was not purchased Channel Down Syntax [Status]=TV.ChannelDown( ) Parameters Status The return status value will be one of the following: SUCCESS--The tune completed successfully FAIL_INVALID_CHANNEL--The tune failed because of an invalid channel number FAIL_PARENTAL_CONTROL--The tune failed because of parental control and a valid Parental Control PIN was not entered FAIL_CHANNEL_NOT_AUTHORIZED--The tune failed because the channel was not authorized by the CA system FAIL_FUNCTION_NOT_AUTHORIZED--The tune failed because the function invocation was not authorized by the CA system FAIL_NOT_PURCHASED--The tune failed because the channel carried an IPPV event and it was not purchased Direct Channel Specification Syntax [Status]=TV.TuneChannel(Channel) Parameters Channel A numeric value that specifies the channel number. Status The return status value will be one of the following: SUCCESS--The tune completed successfully FAIL_INVALID_CHANNEL--The tune failed because of an invalid channel number FAIL_PARENTAL_CONTROL--The tune failed because of parental control and a valid Parental Control PIN was not entered FAIL_CHANNEL_NOT_AUTHORIZED--The tune failed because the channel was not authorized by the CA system FAIL_FUNCTION_NOT_AUTHORIZED--The tune failed because the function invocation was not authorized by the CA system FAIL_NOT_PURCHASED--The tune failed because the channel carried an IPPV event and it was not purchased Remark The TuneChannel method tunes to the specified channel number. Get Current Channel Syntax [Status]=TV.GetCurrentChannel(Channel) Parameters Channel A numeric value that returns the current channel number. Status The return status value from the TuneChannel method. The return status value will be one of the following: SUCCESS--The function completed successfully FAIL_INVALID_CHANNEL--The tune failed because of an invalid channel number Channel Map Access Channel map access allows applications to inquiry about the details of the channel line-up (aka channel map) currently available in the set-top. Access to the service information, i.e. station call letters and network identifiers are available through the channel map access. Syntax [Status ]=ChannelMap.ChannelToNetwork (Channel, Network, Station) Parameters Channel A numeric value that specifies the channel number. Network A string value that returns the broadcast network name. Station A string value that returns the local station name. Status The return status value will be one of the following: SUCCESS--The function completed successfully FAIL_INVALID_CHANNEL--The function failed because of an invalid channel number FAIL_FUNCTION_NOT_AUTHORIZED--The function failed because the function invocation was not authorized by the CA system Syntax [Status]=ChannelMap.NetworkToChannel (Network, Channel, Station) Parameters Network A string value that specifies the broadcast network name. Channel A numeric value that returns the channel number. Station A string value that returns the local station name. Status The return status value from the NetworkToChannel method. The return status value will be one of the following: SUCCESS--The function completed successfully FAIL_INVALID_CHANNEL--The function failed because of an invalid channel number FAIL_FUNCTION_NOT_AUTHORIZED--The function failed because the function invocation was not authorized by the CA system Remark The NetworkToChannel method returns the channel number and station name for the specified network name. If there are more than one channel that carries the specified network name, only the first channel map entry is returned. Syntax [Status]=ChannelMap.ChannelRange (MinChannel, MaxChannel) Parameters MinChannel A numeric value that returns the minimum channel number. MaxChannel A numeric value that returns the maximum channel number. Status The return status value from the ChannelRange method. The return status value will be one of the following: SUCCESS--The function completed successfully FAIL_FUNCTION_NOT_AUTHORIZED--The function failed because the function invocation was not authorized by the CA system Remark The ChannelRange method returns the minimum and maximum channel numbers supported by the channel map provided by the cable system. EPG Data Access EPG Data Access allows applications to inquiry details of the program guide data. The EPG Data Access is controlled by the following attributes: Access to schedule information (program name, start time, end time, and rating) Access to editorial information (program description, etc.) Access to PPV information (pricing, etc.) Dividing up schedule information (current time; next hour, next day, etc.) Control access on a source by source basis (only access guide data for a particular network) Schedule Information Syntax [Status]=EPG.GetScheduleInfo (Channel, RelativeTime, ProgramName, StartTime, EndTime, Rating) Parameters Channel A numeric value that specifies the channel number for which schedule information is requested RelativeTime A numeric value that specifies the relative time in minutes from the current time for which schedule information is requested ProgramName A string value that returns the program name of the program that occurs on the specified channel at the specified relative time. StartTime A numeric value that returns the start time of the program that occurs on the specified channel at the specified relative time. EndTime A numeric value that returns the end time of the program that occurs on the specified channel at the specified relative time. Status The return status value will be one of the following: SUCCESS--The function completed successfully FAIL_FUNCTION_NOT_AUTHORIZED--The function failed because the function invocation was not authorized by the CA system FAIL_TIME NOT_AUTHORIZED--The function failed because access to schedule information at the specified relative time was not authorized by the CA system FAIL_CHANNEL_NOT_AUTHORIZED--The function failed because access to schedule information on the specified channel was not authorized by the CA system Remark The GetScheduleInfo method returns the program name, start time, end time, and rating of the program that is on the specified channel at the specified relative time. Program Information Syntax [Status]=EPG.GetProgramInfo (Channel, RelativeTime, ProgramDescription) Parameters Channel A numeric value that specifies the channel number for which schedule information is requested Relative Time A numeric value that specifies the relative time in minutes from the current time for which schedule information is requested ProgramDescription A string value that returns the detailed program description of the program that occurs on the specified channel at the specified relative time. Status The return status value from the GetProgramInfo method. The return status value will be one of the following: SUCCESS--The function completed successfully FAIL_FUNCTION_NOT_AUTHORIZED--The function failed because the function invocation was not authorized by the CA system FAIL_TIME_NOT_AUTHORIZED--The function failed because access to schedule information at the specified relative time was not authorized by the CA system FAIL_CHANNEL_NOT_AUTHORIZED--The function failed because access to schedule information on the specified channel was not authorized by the CA system Remark The GetProgramInfo method returns the detailed program description of the program that is on the specified channel at the specified relative time. Pay-Per-View Information Syntax [Status]=EPG.GetPPVInfo (Channel, RelativeTime, IsPPV, Price) Parameters Channel A numeric value that specifies the channel number for which schedule information is requested RelativeTime A numeric value that specifies the relative time in minutes from the current time for which schedule information is requested IsPPV A boolean value that indicates if specified program that occurs on the specified channel at the specified relative time is a PPV event. A value of TRUE indicates that it is a PPV event, a value of FALSE indicates that it is not a PPV event. Price A string value that returns the price of the PPV event that occurs on the specified channel at the specified relative time. A value of NULL is returned if the specified program is not a PPV event. Status The return status value from the GetScheduleInfo method. The return status value will be one of the following: SUCCESS--The function completed successfully FAIL_FUNCTION_NOT_AUTHORIZED--The function failed because the function invocation was not authorized by the CA system FAIL_TIME_NOT_AUTHORIZED--The function failed because access to schedule information at the specified relative time was not authorized by the CA system FAIL_CHANNEL_NOT_AUTHORIZED--The function failed because access to schedule information on the specified channel was not authorized by the CA system Remark The GetPPVInfo method returns the PPV status and price of the program that is on the specified channel at the specified relative time. Instantiation Of Standard UI Elements The Channel Banner Syntax [Status ]=UI.DisplayChannelBanner ( ) Parameters Status The return status value will be one of the following: SUCCESS--The function completed successfully FAIL_FUNCTION_NOT_AUTHORIZED--The function failed because the function invocation was not authorized by the CA system Remark The DisplayChannelBanner method causes the NavShell Foundation to display the NavShell channel banner as an overlay. The channel banner will automatically be taken down after its time-out period has been reached. The Extras Menu Syntax [Status]=UI.DisplayExtrasMenu (NumberOfEntries, MenuEntries, EntrySelected) Parameters NumberOfEntries A numeric value that specifies the number of menu entries contained in the MenuEntries array MenuEntries An array of string values that specify the text for each of menu entries to be displayed in the Extras Menu EntrySelected A numeric value that returns the index of menu, entry selected by the viewer from the MenuEntries array Status The return status value from the DisplayExtrasMenu method. The return status value will be one of the following: SUCCESS--The function completed successfully FAIL_FUNCTION_NOT_AUTHORIZED--The function failed because the function invocation was not authorized by the CA system FAIL_VIEWER_EXIT--The function failed because the viewer pressed the EXIT key FAIL_DIALOG_TIMEOUT--The function failed because the time-out period for the viewer identification dialog box expires before the viewer makes a selection Remark The DisplayExtrasMenu method causes the NavShell Foundation to display the NavShell extras menu as an overlay. The viewer may then select among the entries specified by the MenuEntries array. When the viewer selects one of the menu entries, the corresponding index is returned. The extras menu will automatically be taken down after its time-out period has been reached. Viewer Accounts Number of Viewer Accounts Syntax [Status]=GetNumberOfViewers (NumberOfViewers) Parameters NumberOfViewers A numeric value that returns the number of viewer accounts that have been defined for the household. Status The return status value will be one of the following: SUCCESS--The function completed successfully FAIL_FUNCTION_NOT_AUTHORIZED--The function failed because the function invocation was not authorized by the CA system Remark The GetNumberOfViewers method returns the number of viewer accounts defined for the set-top household. A return value of one indicates that only the Default_Viewer is defined for the household. Viewer Names Syntax [Status]=GetViewerName (ViewerNumber, ViewerName) Parameters ViewerNumber A numeric value that specifies which viewer name is being requested. This value must be in the range 1 to the value returned by GetNumberOfViewers inclusive. ViewerName A string value that returns the name for the specified viewer. Status The return status value from the GetViewerName method. The return status value will be one of the following: SUCCESS--The function completed successfully FAIL_FUNCTION_NOT_AUTHORIZED--The function failed because the function invocation was not authorized by the CA system FAIL_INDEX_NOT_VALID--The function failed because specified ViewerNumber was outside the valid range Remark The GetViewerName method returns the viewer name for the specified viewer. Viewer Privileges Syntax [Status]=GetViewerPrivileges (ViewerNumber, TVAccess, WebAccess, IPPVEnabled, EmailEnabled, WalletEnabled) Parameters ViewerNumber A numeric value that specifies which viewer name is being requested. This value must be in the range 1 to the value returned by GetNumberOfViewers inclusive. TVAccess A boolean value that returns whether the specified viewer's TV viewing access is restricted WebAccess A boolean value that returns whether the specified viewer's Web browsing access is restricted Status The return status value from the GetViewerPrivileges method. The return status value will be one of the following: SUCCESS--The function completed successfully. FAIL_FUNCTION_NOT_AUTHORIZED--The function failed because the function invocation was not authorized by the CA system FAIL_INDEX_NOT_VALID--The function failed because specified ViewerNumber was outside the-valid range Remark The GetViewerPrivileges method returns the viewer privileges for the specified viewer. Viewer Parental Controls Syntax [Status]=GetViewerParentalControls (ViewerNumber, TVRating, MovieRating, WebAccess, EmallAccess) Parameters ViewerNumber A numeric value that specifies which viewer name is being requested. This value must be in the range 1 to the value returned by GetNumberOfViewers inclusive. TVRating A string value that returns the specified viewer's TV rating parental control setting MovieRating A string value that returns the specified viewer's MPAA rating parental control setting Status The return status value from the GetViewerParentalControls method. The return status value will be one of the following: SUCCESS--The function completed successfully FAIL_FUNCTION_NOT_AUTHORIZED--The function failed because the function invocation was not authorized by the CA system FAIL_INDEX_NOT_VALID--The function failed because specified ViewerNumber was outside the valid range Remark The GetViewerParentalControls method returns the viewer parental control settings for the specified viewer. Viewer Identification Syntax [Status]=ViewerIdentification (Message, Viewer) Parameters Message A string value that specifies the message text displayed in the viewer identification dialog box. Viewer A string value that returns the viewer name entered by the viewer. The viewer name will be one of the viewer accounts associated with the household. Status The return status value from the ViewerIdentification method. The return status value will be one of the following: SUCCESS--The function completed successfully FAIL_FUNCTION NOT_AUTHORIZED--The function failed because the function invocation was not authorized by the CA system FAIL_INVALID_PIN--The function failed because the viewer entered an invalid PIN for the selected viewer FAIL_VIEWER_EXIT--The function failed because the viewer pressed the EXIT key FAIL_DIALOG_TIMEOUT--The function failed because the time-out period for the viewer identification dialog box expires before the viewer makes a selection Remark The ViewerIdentification method displays a viewer identification dialog box with the specified text message. The viewer then can select the desired viewer from the list of available viewers associated with the household and enter the appropriate PIN for that viewer to identify himself. The ViewerIdentification method then returns the name of the viewer selected. The viewer can also press the EXIT key to terminate the viewer identification dialog box without selecting a viewer, or they can let the dialog box time-out, or enter an invalid PIN. These conditions are returned in the Status return value. In households where only a single viewer account has been created, the viewer does not have the option of selecting among multiple viewers, but must still enter a valid PIN. The viewer name returned when the correct PIN is entered is Default Viewer. E-wallet and Buy-sequence E-Wallet Purchase Syntax [Status]=EwalletPurchase (NumberOfPurchaseOptions, PurchaseOptions, SelectedOption, Buyer, Shipto) Parameters NumberOfPurchaseOptions A numeric value that specifies the number of purchase options contained in the PurchaseOptions array. PurchaseOptions An array of string values that specifies the message text for each purchase option that is available in the E-wallet purchase transaction dialog box. The first entry in this array is the default option displayed. SelectedOption A numeric value that returns the index of purchase option selected by the viewer from the PurchaseOptions array. Status The return status value will be one of the following: SUCCESS--The function completed successfully FAIL_FUNCTION_NOT_AUTHORIZED--The function failed because the function invocation was not authorized by the CA system FAIL_INVALID_PIN--The function failed because the viewer entered an invalid PIN for the selected viewer FAIL_VIEWER_EXIT--The function failed because the viewer pressed the EXIT key FAIL_DIALOG_TIMEOUT--The function failed because the time-out period for the viewer identification dialog box expires before the viewer makes a selection Remark The EwalletPurchase method displays an E-Wallet purchase transaction dialog box with the specified array of purchase options. The viewer then can select the desired purchase option from the list of available purchase options. The EwalletPurchase method then returns the index of the viewer selected purchase option, the name of the viewer that is performing the purchase, and the name of the person to which the purchase will be shipped. The viewer can also press the EXIT key to terminate the E-Wallet purchase transaction dialog box without selecting a purchase option, or they can let the dialog box time-out, or enter an invalid PIN. These conditions are returned in the Status return value. In households where only a single viewer account has been created, the viewer does not have the option of selecting among multiple viewers who is performing the purchase, but must still enter a valid PIN. The viewer name returned when the correct PIN is entered is Default Viewer. Reminders Set Reminder Syntax [Status]=Rem.SetReminder (RelativeDay, TimeOfDay, ReminderMessage, ForUser, ReminderURL) Parameters RelativeDay A numeric value that specifies the number of days in the future at which the reminder is to be triggered. TimeOfDay A numeric value that specifies the time of day on the day specified by RelativeDay at which the reminder is to be triggered. ReminderMessage A string value that specifies the message text displayed in the TV Notice dialog box. ReminderURL A string value that specifies the URL that is accessed when the viewer selects "Yes" in the TV Notice dialog box. ForUser A string value that specifies the viewer name for whom the reminder is intended. The viewer name must be one of the viewer accounts associated with the household. Status The return status value from the SetReminder method. The return status value will be one of the following: SUCCESS--The function completed successfully FAIL_FUNCTION_NOT_AUTHORIZED--The function failed because the function invocation was not authorized by the CA system FAIL_INVALID_VIEWER--The function failed because the specified viewer name is not a valid viewer of the household FAIL_REMINDER_CONFLICT--The function failed because there is an existing reminder set that conflicts with the specified time for the requested reminder. Remark The SetReminder method sets a reminder for the specified viewer that displays the specified reminder message when the reminder is triggered. The specified URL is displayed if the viewer elects to act on the reminder when it occurs. The reminder is displayed as a TV Notice. Display TV Notice This method allows the content provider to simulate a reminder by directly displaying the TV Notice dialog box immediately, rather than setting a reminder and waiting for the reminder to be triggered. Syntax [Status ]=Rem.DisplayTVNotice (NoticeMessage, NoticeURL) Parameters NoticeMessage A string value that specifies the message text displayed in the TV Notice dialog box. NoticeURL A string value that specifies the URL that is accessed when the viewer selects "Yes" in the TV Notice dialog box. Status The return status value will be one of the following: SUCCESS--The function completed successfully FAIL_FUNCTION_NOT_AUTHORIZED--The function failed because the function invocation was not authorized by the CA system FAIL_INVALID_VIEWER--The function failed because the specified viewer name is not a valid viewer of the household Remark The SetReminder method sets a reminder for the specified viewer that displays the specified reminder message when the reminder is triggered. The specified URL is displayed if the viewer elects to act on the reminder when it occurs. The reminder is displayed as a TV Notice. Printing Syntax [Status]=PrintPage ( ) Parameters Status The return status value from the DisplayTVNotice method. The return status value will be one of the following: SUCCESS--The function completed successfully FAIL_FUNCTION_NOT_AUTHORIZED--The function failed because the function invocation was not authorized by the CA system FAIL_PRINTER_ERROR--The function failed because of an error on the printer Remark The PrintPage method prints the current page displayed on the TV.
|
Same subclass Same class Consider this |
||||||||||
