US20090165105A1 - Method and apparatus for communicating between a user device and a user device locating module to allow a partner service to be provided to a user device - Google Patents

Method and apparatus for communicating between a user device and a user device locating module to allow a partner service to be provided to a user device Download PDF

Info

Publication number
US20090165105A1
US20090165105A1 US11/960,951 US96095107A US2009165105A1 US 20090165105 A1 US20090165105 A1 US 20090165105A1 US 96095107 A US96095107 A US 96095107A US 2009165105 A1 US2009165105 A1 US 2009165105A1
Authority
US
United States
Prior art keywords
user
data
identifier
communicating
user device
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
US11/960,951
Other versions
US8789149B2 (en
Inventor
Kapil Chaudhry
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
DirecTV LLC
Original Assignee
Individual
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Individual filed Critical Individual
Priority to US11/960,951 priority Critical patent/US8789149B2/en
Assigned to THE DIRECTV GROUP, INC. reassignment THE DIRECTV GROUP, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: CHAUDHRY, KAPIL
Publication of US20090165105A1 publication Critical patent/US20090165105A1/en
Application granted granted Critical
Publication of US8789149B2 publication Critical patent/US8789149B2/en
Assigned to DIRECTV, LLC reassignment DIRECTV, LLC ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: THE DIRECTV GROUP, INC.
Assigned to CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH, AS COLLATERAL AGENT reassignment CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH, AS COLLATERAL AGENT SECURITY AGREEMENT Assignors: DIRECTV, LLC
Assigned to THE BANK OF NEW YORK MELLON TRUST COMPANY, N.A. AS COLLATERAL AGENT reassignment THE BANK OF NEW YORK MELLON TRUST COMPANY, N.A. AS COLLATERAL AGENT SECURITY AGREEMENT Assignors: DIRECTV, LLC
Assigned to THE BANK OF NEW YORK MELLON TRUST COMPANY, N.A., AS COLLATERAL AGENT reassignment THE BANK OF NEW YORK MELLON TRUST COMPANY, N.A., AS COLLATERAL AGENT SECURITY AGREEMENT Assignors: DIRECTV, LLC
Active legal-status Critical Current
Adjusted expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/16Implementing security features at a particular protocol layer
    • H04L63/166Implementing security features at a particular protocol layer at the transport layer

Definitions

  • the present disclosure relates generally to communication systems having a primary service provider and user receiving device, and more particularly, to a method and system for registering the user device at the locator module to communicate to allow the partner service provider to communicate with the user receiving device.
  • Communication systems such as pay communication systems include a primary service provider and a user device.
  • the user device is typically provided with authorization to communicate with the primary service provider and receive services therefrom.
  • One example of such a system is a satellite television system such as DIRECTV®.
  • Conditional access is provided at the user device in the form of a card to allow the user device to receive signals from the primary service provider.
  • Allowing other service providers to interact with and provide different services that supplement the primary service, may be desirable.
  • the supplemental service provider may not know if the user device is in communication with the supplemental service provider.
  • the ports that the communication device communicates over or the IP address of the user device, or both may be subject to change.
  • the present disclosure allows a user device to establish a communication port at a gateway device. By establishing a port the user device may then connect to different devices or services such as a partner service provider. Partner services may be offered to a provided to user device associated with the primary service provider.
  • a method includes forming a secure connection between a user receiving device and a user device locator module, communicating user identifier data to the user device locator module from the user receiving device, communicating port data from the user receiving device to the user device locator module, authenticating the user data from the user device locator module and after authenticating, registering the port data at the user device locator module.
  • a system in yet another aspect of the invention, includes a user device locator module and a user receiving device forming a secure connection with the user device locator module.
  • the user receiving device communicates user identifier data and port data to the user device locator module.
  • An authentication module authenticates the user data from the user device locator module and generates an authentication signal.
  • the user device locator module registers the port data at the user device locator module in response to the authentication signal.
  • FIG. 1 is a block diagrammatic view of a satellite communication system according to the present disclosure.
  • FIG. 2 is a block diagrammatic view illustrating further details of a partner service provider and the connection to a primary service provider.
  • FIG. 3 is a flow diagram of a process for authentication between a partner service and a primary service provider.
  • FIG. 4 is a flowchart of a method for establishing communication between a partner service provider and a primary service provider and requesting program guide data.
  • FIG. 5 is a flowchart of a method for configuring a user to communicate to the partner service provider and the primary service provider.
  • FIG. 6 is a flowchart of the authentication process described in FIG. 5 .
  • FIG. 7 is a method for requesting a linear program guide.
  • FIG. 8 is a flowchart of a method for remote booking from a user device.
  • FIG. 9 is a flowchart of a method for providing content to a user network device.
  • FIG. 10 is a flowchart of a method for establishing a user receiving device into the system.
  • FIG. 11 is a flowchart of a method for communicating between a user receiving device and a partner service provider.
  • FIG. 12 is a layout view of a system having distributed user device locator modules in communication with various partners and user receiving devices.
  • FIG. 13 is a high-level schematic view of a portion of the system illustrated in FIG. 12 .
  • FIG. 14 is a flowchart of a method for communicating between a partner and a user receiving device.
  • FIG. 15 is a flowchart of the method for initiating a gateway device port forwarding as set forth in FIG. 14 .
  • FIG. 16 is a method for registering a user device with a locator module as set forth in FIG. 14 .
  • FIG. 17 is a sequence diagram of the look-up web service sequence.
  • FIG. 18 is a flowchart of a method for communicating between a locator module and a user device.
  • FIG. 19 is a flowchart of a method for retrieving a key from a user device.
  • module refers to an Application Specific Integrated Circuit (ASIC), an electronic circuit, a processor (shared, dedicated, or group) and memory that execute one or more software or firmware programs, a combinational logic circuit, and/or other suitable components that provide the described functionality.
  • ASIC Application Specific Integrated Circuit
  • processor shared, dedicated, or group
  • memory that execute one or more software or firmware programs, a combinational logic circuit, and/or other suitable components that provide the described functionality.
  • the phrase at least one of A, B, and C should be construed to mean a logical (A or B or C), using a non-exclusive logical or. It should be understood that steps within a method may be executed in different order without altering the principles of the present disclosure.
  • DIRECTV® broadcast services and systems are readily applicable to disclosed systems and methods.
  • Such systems include wireless terrestrial distribution systems, wired or cable distribution systems, cable television distribution systems, Ultra High Frequency (UHF)/Very High Frequency (VHF) radio frequency systems or other terrestrial broadcast systems (e.g., Multi-channel Multi-point Distribution System (MMDS), Local Multi-point Distribution System (LMDS), etc.), Internet-based distribution systems, cellular distribution systems, power-line broadcast systems, any point-to-point and/or multicast Internet Protocol (IP) delivery network, and fiber optic networks.
  • UHF Ultra High Frequency
  • VHF Very High Frequency
  • MMDS Multi-channel Multi-point Distribution System
  • LMDS Local Multi-point Distribution System
  • IP Internet Protocol
  • fiber optic networks fiber optic networks.
  • the different functions collectively allocated among a service provider and integrated receiver/decoders (IRDs) as described below can be reallocated as desired without departing from the intended scope of the present patent.
  • the satellite television broadcast system 10 includes a satellite 12 that receives content or programming from a primary service provider 14 . More specifically, the primary service provider 14 includes a content system 16 that generates uplink signals 20 corresponding to content through an uplink antenna 18 .
  • the uplink signals 20 may be television signals and more specifically digital television signals.
  • the uplink antenna 18 communicates the uplink signals 20 to the satellite 12 which in turn generates downlink signals 22 .
  • the downlink signals 22 are communicated to a receiving antenna 24 on a user receiving device 26 .
  • the user device 26 is primarily associated with and receives services from the primary service provider which may be in the form of signals or primary service data.
  • a secondary or partner provider may also provide services (data et al.) to the user device.
  • the user receiving device may receive both television signals such as satellite television signals and data from the partner service provider (partner service data).
  • partner service may be voicemail data.
  • the uplink signals 20 and downlink signals 22 may be referred to as communication signals.
  • Communication signals are wireless communication signals and may include various types of entertainment content, traffic, weather, hazardous material warnings, advertising material, and the like. As mentioned above, this system may be suitable for wired systems such as cable televisions and terrestrial wireless systems.
  • the user receiving device 26 may include a satellite television receiver, set top box or a digital video recorder.
  • the satellite television receiver may also be referred to as an integrated receiver decoder.
  • other types of user devices may be used such as a cable television set top box.
  • Other types of user devices may include a mobile device such as a lap top computer, cellular phone, personal digital assistant, a portable media player or an automotive-based television receiving device.
  • the user device may be a fixed user device in the case of a satellite television set top box or a mobile user device. Both fixed and mobile devices may be used in a system.
  • the primary service provider 14 may also include an account/billing web service 30 and an authentication server 32 .
  • the authentication server 32 may include an encrypted token (eToken) web service 32 A and a setup web service 32 B.
  • the eToken web service 32 A may be used to generate and validate eTokens. The generation and validation process will be further described below.
  • the setup web service 32 B may be used to setup or establish information so that an eToken may be generated. The set-up process will be described further below.
  • the primary service provider 14 may also include a conditional access management system 34 .
  • the conditional access management system 34 may be used to grant conditional access to various programming as well as provide recording commands to the user device 26 as will be described below.
  • the primary service provider 14 may also include a data web service 36 .
  • the data web service 36 may include a programming guide web service 36 A, a key service or server 36 B and a remote booking web service 36 C.
  • the program guide web service 36 A may be used to generate program guide data and information regarding various programming that is available.
  • the program guide web service 36 A may generate custom programming guide information based upon the subscription to which a user is subscribed.
  • the program guide web service 36 A may also provide generic or non-customized content when specific user attributes are not known. When user attributes such as location and subscription information are known, only the content available to the particular subscriber may be included in the program guide. Additional content may be provided for advertising purposes. Thus, channel data for particular channels may be provided in the program guide.
  • the program guide web service 36 A may generate program guide data for both linear and non-linear content.
  • Linear content are television shows broadcasted at a particular time and a particular channel.
  • Network television programming is an example.
  • Non-linear content is programming that is not tied to a particular time such as on-demand content that can be requested at the user's discretion.
  • the customer care web service 36 B may be used to generate and provide users with various types of help mechanisms to resolve technical issues.
  • the remote booking web service 36 C may be used to generate remote booking commands or recording instructions as will be described below.
  • the remote booking commands or recording instructions may be transmitted through the uplink antenna 18 to the satellite 12 and downlinked through the downlink signal 22 to an antenna 24 on the user device 26 .
  • a remote booking command may then initiate the user device 26 to store content broadcast by the satellite 12 thereon.
  • the user device 26 is in communication with the primary service provider 14 through a network 40 .
  • the network 40 may be a secured network or use a secure protocol.
  • the network 40 may include a broadband network through which the user device 26 communicates with the primary service provider 14 .
  • the network 40 may be a wired network such as a public-switched telephone network (PSTN) or a broadband Internet network.
  • PSTN public-switched telephone network
  • the network may be wireless such as a cellular or wireless Internet system.
  • the broadband network may communicate wired, wirelessly or a combination of both.
  • the user device 26 may include a wireless antenna 42 for communicating with an antenna 44 of a router 46 which, in turn, is in communication with the network 40 .
  • the router 46 may also have a wired connection between the user device, the router 46 , and the network 40 .
  • the router 46 may also be called an Internet Gateway Device (IGD) or simply a gateway.
  • IGD Internet Gateway Device
  • the user device 26 may be associated with a display 50 for displaying content and programming, as well as displaying various types of user commands, or the like.
  • the display 50 may be a television or display integrated into the device.
  • the display 50 may include speakers for an audio display.
  • the display 50 may be used for displaying primary content from a primary service provider and secondary content from a secondary service provider.
  • the user device 26 may include a user interface 52 , such as a keyboard, remote control, or the like, for selecting and entering various types of information by the user.
  • the user device 26 may also include a conditional access module 54 that allows the user to access the programming provided from the content system 16 .
  • the conditional access module 54 may be referred to as an access card.
  • the conditional access module 54 may include various activation codes without which the user device is not activated.
  • the conditional access module 54 may include a conditional access module identifier such as a number or a code.
  • the user device 26 may also include a network interface 56 for interfacing with the network 40 .
  • the network interface 56 may communicate wirelessly through the antenna 42 or through a direct connection such as an Ethernet connection.
  • the network interface 56 may be but is not limited to a wireless broadband interface, a broadband interface, a modem-type interface or a public-switched telephone network interface.
  • the user device 26 may also include a storage device 58 .
  • the storage device 58 may store various content received from the primary service provider therein. The content may be received through the satellite 12 or through the network 40 through the network interface 56 .
  • the storage device 58 may be a hard disk drive or memory chip-based device.
  • the storage device 58 may be referred to as a digital video recorder.
  • the user device 26 may communicate with a user device locator module 70 through the network 40 .
  • the user device 26 may send the IP address of the user device, the port and the type of service offered on the ports to the user device locator module 70 .
  • the user device encryption key may be provided from the user device 26 to the user device locator module 70 .
  • the user device locator module 70 may be a stand-alone device or it may be incorporated into the primary service provider 14 .
  • the user device locator module 70 may also be in communication with the authentication server 32 .
  • the user device locator module 70 may include a look-up web service 72 , a validation module 74 and a look-up delegate module 76 .
  • the user device locator module 70 may be used to provide set top box port registration information from the user device. That is, the user device locator module 70 may include the IP address, port, service offered on the ports and the user device encryption key stored therein.
  • the primary service provider 14 may be in communication with a partner service provider 80 .
  • the partner service provider 80 may include a partner web application 82 , a program guide cache 84 , and a setup web page module 86 .
  • the partner web application 82 may generate various types of web content.
  • the partner web application 82 may generate a homepage-type display.
  • the homepage display may receive information from the program guide cache 84 to fill a TV listing portion of the homepage display.
  • the setup web page module 86 may be used to setup various types of user network devices to communicate with the partner service provider 14 as will be described below.
  • the system may also include a user network device 90 that includes a display 92 associated therewith.
  • the user network device 90 may be a web browsing device such as a portable computer, a personal digital assistant, a portable video player, an automotive-based user device, or the like.
  • the user network device 90 may receive various data from the partner service provider 80 which may include a web page.
  • the display 92 may be used for displaying various program guide information, along with other information provided by the partner service provider.
  • the other information may include financial information, weather information, voicemail information, or other types of information.
  • the partner service provider 80 may provide the content to be displayed on a website in various manners together with or in addition to the program guide information or other information.
  • An intermediate web provider 94 may also be included in the system.
  • the intermediate web provider 94 may be used for communication between the primary service provider 14 and the user network device 90 .
  • the intermediate web provider 94 may be used to receive content or content clips from the primary service provider and store them therein.
  • the user device 90 may obtain the content or content clips from the intermediate web provider 94 through the network 40 as will be further described below.
  • the intermediate web provider 94 may also communicate with the partner service provider 80 . Rather than talking or communicating directly with the intermediate web provider 94 , the user network device 90 may communicate with the partner service provider 80 and then to the intermediate web provider 94 . This may allow another type of service to have access to the content on the intermediate web provider 94 .
  • An interactive video guard (IVG) iChannel server 96 may be used to communicate between the user device 26 and the primary service provider 14 . More specifically, the network interface 56 may be used to communicate between the IVG iChannel server 96 and a setup receiver identifier service module 32 C.
  • the IVG iChannel server 96 may be one of various types of connections.
  • the IVG module is used as a secure connection between the user-receiving device 26 and the primary service provider 14 .
  • the secure connection is identified as reference numeral 98 in FIG. 1 . It should be noted that the secure connection 98 may be part of the network 40 . That is, the secure connection may be an HTTPS connection between the user device 26 and the primary service provider 14 .
  • the secure connection 98 may also be a public-switch telephone network connection.
  • the network interface 56 may act as a modem or a broadband internet-type connection.
  • the setup receiver ID service 32 C which is disposed within the authentication server 32 , is used for authenticating the user device 26 . This will be described further below.
  • the partner service provider 80 may include a router or VPN hardware 100 .
  • the router 100 may communicate with a router 102 at the primary service provider 14 .
  • the program guide web service 36 A of FIG. 1 may include a program guide database 104 .
  • the partner service provider 80 may include the program guide cache 84 as set forth above.
  • the cache 84 is illustrated in FIG. 2 as two devices.
  • the program guide web service 36 A described in FIG. 1 as being within the primary service provider 14 may also be provided within the partner service provider 80 .
  • the program guide web service and cache 84 may communicate with the user network device 90 through respective firewalls 108 A and 108 B.
  • the program guide data may be communicated from the program guide database 104 through the router 102 to the router 100 and stored within the program guide web service and cache 84 .
  • a virtual private network tunnel 110 may be established between the router 100 and router 102 for transferring the data therethrough.
  • the program guide web service and cache 84 may each be in parallel with a firewall 108 A and 108 B.
  • the output of the program web service and cache 84 may be provided to the partner web interface 112 .
  • the partner web interface 112 may be used to direct program guide data to the user network device 90 .
  • a flow diagram having the setup page module 86 , the authentication server 32 having the setup service 32 B and the eToken service 32 A, the data web service 36 , and the account/billing web service 30 is illustrated.
  • a first-time user of the partner service web application may provide various identifying data to an account setup page.
  • an account setup page may be initiated for a first-time user. Initiation of the setup page may also take place if the user requests data or requests an encrypted token from the data web service 36 for the first time.
  • Identifiers prompted for entry at the setup page may include a site identifier which is the identifier of the partner service provider, a site user ID which is the partner's user ID.
  • the site ID may be the login identifier of the particular customer for the partner service provider.
  • An internal identifier may also be provided, such as an account number that corresponds to the primary service provider account of the user.
  • Other identifying information may include the customer's first name, last name, phone number and last bill amount provided by the primary service provider.
  • the information mentioned above may be provided at a setup web page that identifies the user as a new user.
  • the user network device 90 of FIG. 1 may be used to enter the information corresponding to the user.
  • the site identifier may be provided by the particular partner service provider.
  • the site identifier may be predetermined through an established arrangement with the primary service provider.
  • step 200 after the user enters the various information into the setup web page, the information is communicated from the partner service provider, and, in particular, the setup web page to the setup web service 32 B.
  • the information may be communicated through the network 40 of FIG. 1 .
  • the account/billing web service 30 may receive the information at the primary service provider 14 through the network 40 .
  • the various information such as the internal identifier or account identifier may be provided to the account/billing service 30 .
  • the process may be first started by validating or authenticating the site identifier provided by the partner service provider. Thereafter, the internal account or ID may be authenticated.
  • a status signal is communicated to the setup web service 32 B.
  • the status may include a non-authenticated status.
  • an encrypted token or eToken may be generated at the setup web service 32 B in step 206 .
  • the eToken may be formed using various combinations of identifiers but may include a site identifier, a site user identifier, and a DIRECTV® internal identifier or account identifier.
  • the eToken may also have an expiration date and/or time specified therein.
  • the expiration date may have a current date time in which the eToken was formed and an elapsed time through which the eToken is valid.
  • the elapsed time may be in seconds that are counted from the current time when the eToken is formed.
  • the lifespan of the eToken is set forth.
  • eToken may be returned without modification if the eToken is still valid. If the expiration time has expired, re-authentication may be required and a new token may be generated with an updated expiration date and time.
  • the partner service provider may also be used to obtain various data from the data web service 36 of the primary service provider 14 .
  • the partner service provider will thus not have individual customer or user information associated therewith. Therefore, the site identifier may be provided and dummy values or no values at all for the specific user information described above may be communicated to the setup web service 32 B. If the site ID is a valid site ID as determined in the setup web service 32 B, an eToken is generated using the site ID and dummy values if needed in step 212 .
  • the web service or web application 82 in FIG. 1 of the partner service provider 80 may generate a web service request.
  • the web service request may initiate from the user using the website from the partner service provider 80 .
  • the web service request may be a request for data.
  • a web service request may initiate from the partner service provider itself so that various information may be received, such as program guide data.
  • the web service request is provided and may include the eToken, a site identifier, a site user identifier and a web service method.
  • the web service request may be provided from the partner service provider and may be communicated to the data web service 36 of the primary service provider 14 . Communication of the web service request may take place through the network 40 .
  • the information such as the site ID, the site user ID and the eToken may be communicated to the eToken web service 32 A at the primary service provider 14 .
  • Authentication may decrypt the eToken and ensure that the site ID and the site user ID correspond with the site ID and the site user ID of the eToken. Authentication will be further described below.
  • the eToken and internal or account identifier may be returned once the authentication takes place in step 216 .
  • the return signal may return back to the web service 36 .
  • the web service 36 may then generate a web service response in step 220 .
  • the web service response may include an updated eToken if the eToken was expired and data from the web service 36 .
  • a method for establishing communication between a partner service provider and the primary service provider and requesting program guide data is set forth in more detail. The method also applies to non-program guide data requests as well.
  • a request for an eToken is generated at a partner site using partner identification such as the site identifier. Dummy values may also be used to replace expected variables corresponding to other types of formats and devices.
  • the request for an eToken is communicated to the authentication web service.
  • the eToken is generated and provided to the partner site from the authentication server. The generating and communicating of the eToken is performed in response to authenticating or validating the site ID or any other identifiers provided.
  • step 316 a request or data from the partner to the program guide web service is performed using the eToken.
  • step 318 the request for program guide data is validated at the authentication web service.
  • step 320 the validation results are provided to the program guide web service.
  • step 322 if the results indicate the request is not valid, then step 322 ends the process. If a valid request was generated in step 322 , step 326 generates a new eToken at the authentication web service.
  • the revising of the eToken may be an optional step and may be performed when an eToken has expired. However, a new eToken could be generated at each request.
  • step 328 the status, the new eToken and the program guide data may be communicated to the partner device.
  • step 330 the various data as received from the data web service of the primary service provider may be communicated to the user network device.
  • step 412 if the user is a first-time user, step 414 is performed.
  • step 414 the primary provider customer is directed to the setup page hosted by the partner. That is, the user device has setup information provided thereto.
  • step 416 information identifying the user is provided through the network user device. As mentioned above, this may include the name, address, telephone number, account or other type of identifier, or the like.
  • step 418 identifying information is provided from the setup page to the setup web service. That is, the information is communicated from the partner service provider to the primary service provider.
  • step 420 the site identifier is validated.
  • step 422 if the site identifier of the partner service provider is not valid, step 424 generates an error message. If the site is valid, step 426 compares the account ID and the user identifiers. In step 428 , a status message is returned in response to the comparison performed in step 426 .
  • step 430 if the information is not valid, an error message is generated in step 424 .
  • step 430 if the user information is valid, step 432 generates an eToken at the authentication server 32 of the primary service device 14 of FIG. 1 .
  • step 434 the eToken is communicated to the partner service provider 80 . More specifically, the eToken may be provided to the setup page module 86 .
  • the partner web application and/or the setup web page module may receive the eToken.
  • the user information and the eToken are associated together. Thus, the user may only have to perform the setup web page service one time.
  • Step 440 may be performed if step 412 indicates that the user has registered before. Also, step 440 is performed after step 438 .
  • the web service request from the user network device 90 of FIG. 1 is generated.
  • the web service's request is communicated to the eToken web service 32 A in the primary service provider 14 from the partner service provider 80 .
  • the request is authenticated.
  • the web service responds by generating various data and communicating the data from the primary service provider 14 to the partner service provider 80 and ultimately to the user network device 90 .
  • step 510 an eToken is received at the eToken web service 32 A.
  • the eToken arrives from the partner service provider 80 through the network 40 .
  • the eToken may arrive through one of the data web services 36 .
  • step 512 if the site ID of the partner service provider is not a valid partner site identifier, step 514 generates an error signal.
  • step 516 is performed. The site ID is then compared to the site ID that was encrypted into the eToken.
  • the eToken is decrypted to determine the site ID formed therein. If the site ID is not equal to the site ID retrieved from the eToken, step 514 is again performed. If the site ID is equal to the site ID from the eToken, step 518 is performed. In step 518 , the site user ID is compared to the site user ID from the decrypted eToken. If the site ID is not equal to the site ID it retrieved from the eToken, step 514 generates an error signal. In step 518 , if the site ID is equal to the eToken site user ID, step 520 is performed. In step 520 , if the expiration time is greater than the current time, the eToken is returned in step 522 .
  • step 520 if the expiration time is greater than the current date and time, step 524 is performed. In step 524 , if the expiration time is less than or equal to the current date and time, step 526 is performed. Step 526 authenticates the eToken internal identifier. If the eToken internal identifier is not valid in step 528 , an error message is returned in step 530 .
  • step 532 updates the eToken expiration time.
  • step 534 the updated eToken is returned and the internal ID is communicated to the web service.
  • step 536 a web service response is generated.
  • step 538 the updated eToken is communicated to the partner service provider 80 .
  • step 610 an eToken for the user is obtained through the partner site.
  • step 612 additional data such as the zip code and subscribed services may also be retrieved. The additional data may be retrieved using the setup web page module 86 .
  • step 614 a request for the programming guide using the eToken, the site identifier, the site user identifier and the site listing start time may be generated at the partner service provider.
  • step 616 the request and associated data may be communicated to the program guide web service 36 A.
  • step 618 the eToken may then be communicated to the authentication server 32 where it is authenticated.
  • step 624 if the eToken is valid, step 624 communicates a guide listing response according to the user from the programming guide web service. That is, specific subscription data may be obtained from the account billing web service 30 to inform the program guide web service 36 as to the subscriptions and location of the user network device.
  • the program guide in step 624 may return channel object data, schedule object data, program object data and user device data which correspond[s] to information regarding the integrated receiver decoder or set top box. The data may be used to provide a program guide to the user network device 90 .
  • the channel object data may include the primary visible content channels valid between the listing start date and the end date.
  • the channel data may include channels provided by the primary service provider as well as turnaround channels provided by the primary service provider.
  • the channel object may comprise various information such as a channel key which is a unique key made up of the content channel identifier and the channel start time that identifies the channel instance.
  • the content channel identifier specifies the identifier for the content channel.
  • the channel start time and channel end time specify the starting and ending time that the channel is valid. Certain channels may be valid indefinitely and some channels may be valid only for a predetermined amount of time.
  • the channel object may also include a channel object identifier. This specifies the content key in the provider system that maps to the content channel identifier.
  • a major channel number and minor channel number may also be used as an identifier.
  • a market identifier corresponding to a designated marketing area corresponding to the Nielsen® geographic data may also be set forth. National broadcast channels may not specify a market identifier.
  • a source identifier may also be provided for the channel. For example, various sources for the channel identifier may be provided including Tribune Media Services.
  • the station ID may also be provided in the channel object.
  • a short name and long name corresponding to the call letters or the channel may be provided.
  • a description, category, service type, codec type, network affiliation, channel logo ID and authorization code may also be provided.
  • the authorization code may correspond to fully subscribed, partially subscribed, not subscribed or not applicable. The authorization code may allow users to view information if the information has been subscribed to.
  • Schedule data may also be provided which includes the air time for a particular program, the duration that includes the length of time that the program will air, an authorization code similar to those described above including subscribed, not subscribed and not applicable, and a blackout code to determine if the content may be blacked out.
  • Program data may also be provided.
  • Program data may use a program reference identifier that is used to uniquely identify the program record and its contents.
  • the program title, the episode title or the sports team's name may also be provided.
  • a theatrical release year, original air date, a description describing the program content may also be provided.
  • a secondary identifier such as a tribune media services identifier may also be provided in the program data.
  • a category, label such as a category or genre may also be provided. The relevance of the category label may also be categorized.
  • An in-guide flag may also be provided which indicates whether or not the label should appear with the program description on the screen.
  • a credit, contribution, last name, first name, source type and network/syndicater-type may also be provided.
  • Indicators may also be provided as to whether the program is in color, provides a secondary audio program, whether the program is a repeat, a premiere or a finale and whether the program is live, taped or taped delay. Other information may include whether the content is subtitled, letterboxed and the ratings of the particular content.
  • An advisory may also be provided in the program data. An advisory may correspond to motion picture advisories.
  • a television advisory may also be provided for television content that includes TVY7, TVPG, TV14, TVMA.
  • a close-captioning indicator, a high definition indicator, an AC3 audio content indicator, a Dolby surround sound indicator, pay-per-view data, an all-day ticket data or a descriptive video service data may also be provided.
  • IRD data or set top box data may also be returned to the partner service provider. This information may be used to schedule a recording from the user network device.
  • the partner service provider may use the IRD or user device information to target specific IRDs corresponding to the subscriber's account.
  • the IRD or user device information may include a receiver ID that identifies the partner service receivers.
  • the access card identifier may also be provided.
  • the model number of the user device, the manufacturer of the user device and the location within the customer's premises may also be provided.
  • the various numbers of receiving devices or user devices may be provided with a customer account. Therefore, a specific user device may be specified.
  • the receiving device data may also include a remote booking allowed flag. This flag may indicate whether or not remote booking is allowed.
  • step 626 the guide listings are returned that include the local channels, national channels and subscribed channels and the various data described above.
  • step 628 a program may be requested using the channel detail, the program detail and the user device data.
  • Remote booking is used to allow the user network device to request the storage device of the user device to store a broadcast program or content.
  • an eToken is received at the partner site from the primary service provider, and, more particularly, eToken web service 32 A of FIG. 1 .
  • the user access card ID is obtained at the partner site. This may be obtained when a request for program guide data or other data is provided as mentioned above.
  • the program guide data is also received at the partner site. As mentioned above, various types of channel data, object data, program data and receiver device data may be obtained.
  • remote booking requests including eToken, access card identifier and recording data may be generated.
  • the remote booking request may be communicated from the partner site to the primary provider.
  • a conditional access packet may be generated at the primary service provider.
  • the conditional access packet may be communicated to the user device.
  • the conditional access packet may be a recording instruction for a particular program at a particular time on a particular channel.
  • a response data may be generated from the primary service provider to the partner service provider.
  • the response data may include a successful transmission of a conditional access packet to indicate that the user device may record the information within the storage device 58 .
  • a new eToken with a new timestamp may be provided from the primary service provider and, in particular, the eToken web service 32 A with a new timestamp. As mentioned above, a new timestamp may be provided if the previous timestamp has expired.
  • the content may be recorded according to the recording request or conditional access packet as described above.
  • the content is then able to be used and/or played back at the convenience of the user of the user device.
  • the clips may be recorded or saved from a live event such as a football game or other event.
  • the clips may be highlights of important events and thus may be only a small portion of a particular event.
  • clips of a live event are generated.
  • the live event clips may be generated in the primary service provider or may be generated elsewhere and communicated to the primary service provider.
  • a plurality of clips is communicated to an intermediate web provider.
  • the clips may be provided to the intermediate web provider in response to a query from the intermediate web provider if more current clips are available.
  • the clips may also automatically be provided to the intermediate web provider.
  • an identifier from a user network device is communicated to the intermediate web provider.
  • the user network device may communicate various identifier-type information including an account number or other type of login and/or password.
  • the user device is authenticated.
  • the user device may be authenticated at the intermediate web provider, or the identifier data may be communicated to the primary service provider.
  • the network device is authenticated.
  • the service options to receive the content may be determined. For football clips, for example, the user may be required to subscribe to a Sunday football package. Both the authenticating and the verifying may take place either at the intermediate web provider or at the primary service provider. Both the authentication and verification may take place at the same time.
  • step 920 if the user network device is not verified or authenticated, step 922 ends the process.
  • step 924 communicates a content list to the user network device from the intermediate web provider.
  • the content list may include a list of a number of the most recent NFL clips, in carrying forward with the example set forth above. For example, a list of five may be provided.
  • step 926 content may be selected from the list to form a selection at the user network device.
  • step 928 the selection is communicated to the intermediate web provider.
  • step 930 the content corresponding to the selection is communicated to the user network device.
  • the content may be displayed on the user network device. That is, the content video may be played back through the user network device.
  • the user network device may be various types of devices, including a mobile phone or other type of web-enabled device. It should be noted that the content list in FIG. 9 may be continually updated and thus the content list may be continually provided to the user network devices.
  • the receiving device generates a setup request using a site ID, a receiver ID and a receiver card ID.
  • the site ID is the site identifier for the particular DIRECTV® partner. This may be a numeric identifier, alphanumeric identifier or alphabetic identifier.
  • the receiver identifier may also be referred to as a site user identifier.
  • the user ID may be the serial number of the particular receiver within the home associated with a particular account.
  • the receiver card ID is the identification number associated with the particular conditional access module or access card.
  • a connection to the primary service provider 14 is requested.
  • the request may be a request to setup or establish a connection.
  • An interactive video guard connection may be established so that the connection is secure.
  • step 1012 establishes a connection with an IVG iChannel server 96 of FIG. 1 .
  • the IVG iChannel server 96 may also be located within the primary service provider 14 .
  • the IVG iChannel server 96 is a standalone device.
  • the secure connection 98 between the IVG iChannel server 96 and the user device 26 and the IVG iChannel server 96 and the primary service provider 14 may be established through a secure connection through the network 40 .
  • step 1014 the request is communicated from the IVG iChannel server 96 to the primary service provider 14 .
  • the site identifier may be confirmed in step 1016 .
  • the site identifier may be confirmed by determining if the number or identifier is a valid identifier.
  • step 1020 if the site identifier is not confirmed, the system ends in step 1022 .
  • An error message may be sent to the user receiving device that authentication is not possible. Further, the system may ask for re-entry of certain information or start the process again at step 1010 .
  • step 1024 it is determined whether an eToken for the user receiving device exists. If an eToken does not exist for the user receiving device, step 1026 determines whether there is an account associated with the site identifier. If there is not an account with the site identifier, step 1028 is performed in which an error signal or error flag may be generated. If there is an account associated with the account identifier in step 1030 , the account identifier is retrieved. The account identifier may be the account number associated with the particular user.
  • an eToken is generated.
  • the eToken is generated by encrypting various data into the binary-encrypted token.
  • the site ID, the user receiving device ID, the account identifier obtained in step 1030 and an internal DIRECTV®-registered user identifier may also be encrypted into the eToken. However, not all of the above-mentioned components may be placed into the encrypted token. Further, an expiration date and/or time may be provided in the encrypted token. This time value defines the lifespan of the authentication of the eToken. If the expiration time has expired, an expired eToken message may be returned.
  • the eToken is returned and the account identifier is returned to the iChannel server.
  • the eToken and the account identifier are communicated to the user receiving device from the iChannel server.
  • step 1040 determines whether the eToken has expired. If the eToken has not expired, the system continues in step 1034 where the eToken is returned.
  • step 1050 determines whether an active account is still associated with the eToken. If an active account is not associated with the eToken, step 1050 ends the process. If an active account is associated with the eToken, an eToken is generated in step 1032 . Thereafter, steps 1034 and 1036 are provided which communicate the eToken back to the user receiving device 26 .
  • the user receiving device is ready to communicate with the partner service provider 80 of FIG. 1 .
  • Various types of data may be exchanged between the partner service provider 80 and the user device 26 . It is likely that the bulk of the data will be providing a service from the partner service provider 80 to the user device 26 .
  • the partner service provider 80 may be a telecom provider providing voicemail or other types of data service that may be used in conjunction with the display 50 associated with the user device 26 of FIG. 1 .
  • the eToken is received at the partner service provider 80 .
  • a request for data, a request to communicate or other type of communication is initiated at the user receiving device.
  • the eToken arrives through the network 40 in addition to other data.
  • step 1112 if the site ID of the user device is not valid, step 1114 generates an error message signal.
  • step 1112 if the site ID is a valid site ID, step 1116 is performed. The site ID is then compared to the site ID that was encrypted into the eToken in step 1116 . That is, the eToken is decrypted to determine the site ID formed therein. If the site ID is not equal to the site ID retrieved from the eToken, step 1114 is again performed.
  • step 1118 is performed.
  • the receiver ID is compared to the receiver ID from the decrypted eToken. If the site ID is not equal to the site ID it is retrieved from the eToken, step 1114 generates an error signal.
  • step 1118 if the site ID is equal to the eToken site user ID, step 1120 is performed. In step 1120 , if the expiration time is greater than the current time, the eToken is returned in step 1122 .
  • step 1120 if the expiration time is greater than the current date and time, step 1124 is performed. In step 1124 , it is determined whether the site ID is a generic partner type or a specific partner type. If the ID is a generic type, a generic flag is returned in step 1126 . In step 1124 , if the site ID is not a generic type, meaning a specific user, step 118 returns an account identifier.
  • step 1130 if the expiration time is less than or equal to the current date and time, step 1132 is performed. In step 1132 , an expired error message is returned.
  • step 1134 determines whether or not the eToken is valid. If the eToken is not valid, step 1136 returns an error message. In step 1134 , if the eToken is valid, step 1140 establishes communication between the partner site and the user receiving device. In step 1142 , data may then be exchanged between the two devices. That is, the set top box or user receiving device may directly exchange data with the partner service provider. As mentioned above, various services, such as telecom services, may be provided. One example is that voicemail may then be communicated to the user device 26 by using the user interface 52 and display 50 as illustrated in FIG. 1 .
  • the map 1210 represents a geographical area having a plurality of locator modules 70 .
  • a plurality of locator modules 70 may be used to distribute the load across the geographic area. However, as illustrated in FIG. 1 , only one locator module 70 may be used.
  • Each locator module 70 may be located in a particular region of the geographic area.
  • a plurality of user devices 26 may be associated with each locator module 70 . That is, when a connection is desired between a user receiving device 26 and the locator module 70 , the locator module 70 closest to the user receiving device 26 may be chosen for communicating. An alternative one or several user locator modules 70 may also be tried in the case of a slow connection or no connection between the user receiving device 26 and the locator module 70 .
  • partner service providers 80 may also be in communication with the user device locator module 70 .
  • Various numbers of partner service providers 80 may be provided throughout the geographic area. As illustrated, four partner service providers 80 are illustrated each in communication with a different user device locator module 70 .
  • the locator modules 70 may be connected to an internal network 1310 .
  • the internal network 1310 may be private.
  • the internal network 1310 may be part of, but isolated from, other portions of the locator module 70 by firewalls 1312 .
  • the network 1310 may include an account database 1314 and a key server or service 1316 .
  • Firewalls 1312 may set up a demilitarized zone (DMZ) to prevent unauthorized access from the Internet into the partner private network 1310 .
  • DMZ demilitarized zone
  • the locator modules 70 may be servers that have an outfacing public IP address connected to the Internet or the network 40 to provide user device registration, look-up service and a key retrieval service.
  • the firewalls 1312 may thus prevent unauthorized access to the account database 1314 and the key server or service 1316 .
  • the key server 1316 and the account database 1314 may have an internal non-public IP address sub-net that may be used to exchange information between the server 70 and the internal databases.
  • the locator modules 70 may be located in remote uplink facilities used to collect local channels and uplink them to the satellite 12 .
  • the locator module 70 may have the internal private network in communication with the primary service provider 14 and in particular the authentication server therein.
  • the authentication server 32 may be used to verify or authenticate requests by verifying or authenticating the eTokens therein.
  • the user receiving devices 26 may be provided with a listing of all the locator modules 70 as well as their IP addresses.
  • the locator module 70 with the closest geographic location may be chosen by the user receiving device 26 .
  • the option of trying various other locator modules 70 may be provided. By geographically distributing the locator modules 70 , application performance and load spread may be improved.
  • FIG. 14 a method for registering data with the locator module 70 is illustrated. There are three main steps in the process. The first two of the three steps will be described in FIGS. 15 and 16 in further detail.
  • the first step is FIG. 1410 in which the determination of a communication port is performed by initiating an Internet Gateway Device (IGD) port forwarding sequence. After port forwarding is performed, step 1412 the user device registers with the locator module 70 . Thereafter, step 1414 monitors for public IP address changes.
  • IGD Internet Gateway Device
  • step 1410 the process starts when the user receiving device is rebooted or restarted.
  • the user receiving device may be a television receiving device such as a satellite television receiving device.
  • the user receiving device will attempt to locate the Internet Gateway Device (IGD) such as a home router or gateway ( 46 of FIG. 1 ).
  • the user receiving device will determine whether the router of FIG. 1 is universal plug and play (UPnP) capable.
  • a UPnP multicast packet is generated at the user receiving device and transmitted to the router or IGD 46 .
  • step 1514 if a response is generated by the IGD, the IGD is UPnP compatible and step 1516 is performed.
  • the available services are communicated to the user receiving device.
  • the available services may include a public IP address, a port forwarding service, or the like.
  • the user receiving device locates an open port. This may be performed if the gateway or router device lists port forwarding as one of the available services. The user receiving device may attempt to locate an open port on the gateway device either through a port scan or arbitrarily picking an open port and configuring the gateway device by performing a port forwarding command as specified in the UPnP protocol.
  • the gateway device when an open port has been successfully determined, the gateway device notifies or communicates a message indicating the port has been open to accept incoming connections.
  • step 1522 once a port has been chosen, the user receiving device starts a listening service on the forwarding port.
  • the gateway or router 46 may not be universal pug and play compatible.
  • a manual configuration of a forwarding port on the Internet Gateway Device, such as the router may be performed.
  • the same port used as the forwarding port in step 1530 may be configured on the user receiving device.
  • the port may be used to communicate partner service data to the user receiving device and communicate signals from the user receiving device.
  • the partner service data may be received in addition to primary service data or signals.
  • step 1612 a secure connection between the locator module 70 and the user receiving device through the gateway device is performed.
  • This may be a secure sockets layer (SSL) type connection.
  • registration data may be communicated from the user receiving device to the locator module that includes port information.
  • the data provided from the user receiving device may include user device data including a site identifier that identifies the user device as an individual user device rather than a partner service provider.
  • a site user identifier such as a receiver identifier, may also be provided.
  • the receiver identifier may include a serial number or model number of the user receiving device 26 .
  • An encrypted token may also be provided from the user device to the locator module.
  • the encrypted token may be formed as described above and may include various types of encrypted data such as the site identifier, the site user identifier or receiver user identifier and the expiration date of the encrypted token.
  • port information such as an IP address, port forwarding data, an access card identifier, a receiver identifier, a service identifier and a service description may also be provided to the locator module.
  • the locator module may cross-reference the data provided in step 1614 against an account database.
  • the account database may reside within the locator module or may reside within the authentication server 32 of the primary service provider.
  • the eToken web service 32 A may be used to authenticate the web service
  • the setup web service 32 B may be used to setup and verify the information.
  • the account/billing web service 30 may also be used to determine billing information.
  • step 1618 the locator module determines if the user device is associated with a valid customer and whether the account is in good standing. Again, this step may be performed at the locator module or at the primary service provider.
  • step 1620 if the customer is a valid customer and the account is not in good standing, step 1622 terminates the process.
  • step 1624 registers the user device within the locator module 70 .
  • step 1626 the secure connection is no longer needed and thus the secure connection is terminated.
  • the locator module After registration of the user device with the locator module, other devices or services such as the partner service provider are able to locate the user receiving device and communicate services or partner service data thereto.
  • a look-up request is generated from the partner service provider 80 or other type of requester. It should be noted that the requester may also be another user device 26 that seeks access to another user receiving device.
  • a look-up request generated in step 1710 is provided to the look-up web service 72 .
  • the header of the request may be validated in the validation module 74 of the locator module 70 .
  • a validation status is returned from the validation module 74 to the look-up web service 72 .
  • a validation failure signal is communicated from the look-up web service 72 to the partner service provider 80 or other requester if validation fails.
  • a delegate request for processing is provided to the look-up delegate 76 .
  • the request may include an eToken that is authenticated at the authentication web service 32 in step 1720 .
  • the authentication of an eToken is described above.
  • the encrypted token may be decrypted and its contents compared to other transmitted data.
  • the authentication web service 32 may return an authentication failure signal to the partner service provider 80 .
  • step 1720 if the authentication is successful, step 1724 is performed that retrieves the results if the authentication succeeds.
  • step 1726 a valid result set is returned to the look-up web service 72 .
  • the look-up web service after receiving the valid result set in step 1726 , returns the result set to the partner service provider in step 1728 .
  • step 1810 when a requester such as a partner service provider 80 or another user receiving device 26 desires direct communication with another user receiving device, a secure link between the requester and the locator module is formed.
  • An SSL connection may be formed between the locator module and the requestor.
  • step 1812 a request is communicated to the locator module.
  • the request may include a site identifier, such as the partner service provider identifier, and a site user identifier.
  • the site user identifier may correspond to the partner service provider identifier for the particular user receiving device.
  • An eToken may also be provided.
  • Data such as a service identifier and a receiver identifier may also be provided.
  • step 1814 authentication of the identity of the requestor may be performed.
  • the authentication may take place by comparing the eToken to the information provided. That is, by decrypting the eToken and comparing the eToken values to the site ID and the user ID, authentication may take place.
  • step 1816 if the requestor is not authenticated using the eToken, step 1818 generates an error message.
  • step 1816 if the requestor is authenticated, step 1820 determines whether the requestor is authorized to receive user device data by comparing the request against a known list of services and receiver identifiers. If the request is not valid in step 1822 , step 1818 is performed in which an error message is generated.
  • step 1824 After step 1822 , if the request is valid, step 1824 returns a response with various parameters. Once the response is generated, a peer-to-peer connection may be formed directly between the requester and the user receiving device in step 1826 .
  • the requestor may be a partner service provider communicating partner service data to the user receiving device.
  • the user receiving device may also communicate data to the requestor. In addition, the user receiving device may receive primary service data or signals.
  • the user receiving device and the partner service provider 80 may communicate using a key.
  • the process described above in FIG. 18 may be modified to perform key retrieval.
  • the requestor may make a secure connection to the locator server.
  • authentication data may be provided to the locator module from the requestor.
  • the locator or the authentication data may include a site identifier which may be a numeric or alphanumeric or alphabetical site identifier.
  • a site user ID such as the partner service provider user identifier may be provided.
  • An encrypted token may also be provided.
  • the locator module may individually or through the primary service provider 14 verify the requester eToken to verify the identity of the requester in step 1914 .
  • step 1916 if the identity is not verified, an error signal is generated in 1918 . If the requester is verified in step 1916 , a public key of the user receiving device is communicated to the requestor. In step 1922 , a secure connection is terminated once the public key is provided. In step 1924 , communication between the user device and the requester, such as a partner service provider, may be provided using the key. Thus, using the key the various data may be encrypted and decrypted.
  • UDP user datagram protocol
  • partner service provider data may then be provided in addition to primary service data.

Abstract

A system and method for communicating between a user device locator module and a user receiving device includes forming a secure connection with the user device locator module. The user receiving device communicates user identifier data and port data to the user device locator module. An authentication module authenticates the user data from the user device locator module and generates an authentication signal. The user device locator module registers the port data at the user device locator module in response to the authentication signal.

Description

    TECHNICAL FIELD
  • The present disclosure relates generally to communication systems having a primary service provider and user receiving device, and more particularly, to a method and system for registering the user device at the locator module to communicate to allow the partner service provider to communicate with the user receiving device.
  • BACKGROUND
  • The statements in this section merely provide background information related to the present disclosure and may not constitute prior art.
  • Communication systems such as pay communication systems include a primary service provider and a user device. The user device is typically provided with authorization to communicate with the primary service provider and receive services therefrom. One example of such a system is a satellite television system such as DIRECTV®. Conditional access is provided at the user device in the form of a card to allow the user device to receive signals from the primary service provider.
  • Allowing other service providers to interact with and provide different services that supplement the primary service, may be desirable. However, the supplemental service provider may not know if the user device is in communication with the supplemental service provider. In a broadband-type of communication system, the ports that the communication device communicates over or the IP address of the user device, or both, may be subject to change.
  • SUMMARY
  • The present disclosure allows a user device to establish a communication port at a gateway device. By establishing a port the user device may then connect to different devices or services such as a partner service provider. Partner services may be offered to a provided to user device associated with the primary service provider.
  • In one aspect of the invention, a method includes forming a secure connection between a user receiving device and a user device locator module, communicating user identifier data to the user device locator module from the user receiving device, communicating port data from the user receiving device to the user device locator module, authenticating the user data from the user device locator module and after authenticating, registering the port data at the user device locator module.
  • In yet another aspect of the invention, a system includes a user device locator module and a user receiving device forming a secure connection with the user device locator module. The user receiving device communicates user identifier data and port data to the user device locator module. An authentication module authenticates the user data from the user device locator module and generates an authentication signal. The user device locator module registers the port data at the user device locator module in response to the authentication signal.
  • Further areas of applicability will become apparent from the description provided herein. It should be understood that the description and specific examples are intended for purposes of illustration only and are not intended to limit the scope of the present disclosure.
  • DRAWINGS
  • The drawings described herein are for illustration purposes only and are not intended to limit the scope of the present disclosure in any way.
  • FIG. 1 is a block diagrammatic view of a satellite communication system according to the present disclosure.
  • FIG. 2 is a block diagrammatic view illustrating further details of a partner service provider and the connection to a primary service provider.
  • FIG. 3 is a flow diagram of a process for authentication between a partner service and a primary service provider.
  • FIG. 4 is a flowchart of a method for establishing communication between a partner service provider and a primary service provider and requesting program guide data.
  • FIG. 5 is a flowchart of a method for configuring a user to communicate to the partner service provider and the primary service provider.
  • FIG. 6 is a flowchart of the authentication process described in FIG. 5.
  • FIG. 7 is a method for requesting a linear program guide.
  • FIG. 8 is a flowchart of a method for remote booking from a user device.
  • FIG. 9 is a flowchart of a method for providing content to a user network device.
  • FIG. 10 is a flowchart of a method for establishing a user receiving device into the system.
  • FIG. 11 is a flowchart of a method for communicating between a user receiving device and a partner service provider.
  • FIG. 12 is a layout view of a system having distributed user device locator modules in communication with various partners and user receiving devices.
  • FIG. 13 is a high-level schematic view of a portion of the system illustrated in FIG. 12.
  • FIG. 14 is a flowchart of a method for communicating between a partner and a user receiving device.
  • FIG. 15 is a flowchart of the method for initiating a gateway device port forwarding as set forth in FIG. 14.
  • FIG. 16 is a method for registering a user device with a locator module as set forth in FIG. 14.
  • FIG. 17 is a sequence diagram of the look-up web service sequence.
  • FIG. 18 is a flowchart of a method for communicating between a locator module and a user device.
  • FIG. 19 is a flowchart of a method for retrieving a key from a user device.
  • DETAILED DESCRIPTION
  • The following description is merely exemplary in nature and is not intended to limit the present disclosure, application, or uses. For purposes of clarity, the same reference numbers will be used in the drawings to identify similar elements. As used herein, the term module refers to an Application Specific Integrated Circuit (ASIC), an electronic circuit, a processor (shared, dedicated, or group) and memory that execute one or more software or firmware programs, a combinational logic circuit, and/or other suitable components that provide the described functionality. As used herein, the phrase at least one of A, B, and C should be construed to mean a logical (A or B or C), using a non-exclusive logical or. It should be understood that steps within a method may be executed in different order without altering the principles of the present disclosure.
  • While the following disclosure is made with respect to example DIRECTV® broadcast services and systems, it should be understood that many other delivery systems are readily applicable to disclosed systems and methods. Such systems include wireless terrestrial distribution systems, wired or cable distribution systems, cable television distribution systems, Ultra High Frequency (UHF)/Very High Frequency (VHF) radio frequency systems or other terrestrial broadcast systems (e.g., Multi-channel Multi-point Distribution System (MMDS), Local Multi-point Distribution System (LMDS), etc.), Internet-based distribution systems, cellular distribution systems, power-line broadcast systems, any point-to-point and/or multicast Internet Protocol (IP) delivery network, and fiber optic networks. Further, the different functions collectively allocated among a service provider and integrated receiver/decoders (IRDs) as described below can be reallocated as desired without departing from the intended scope of the present patent.
  • Further, while the following disclosure is made with respect to the delivery of content (e.g., television (TV), movies, games, music videos, etc.), it should be understood that the systems and methods disclosed herein could also be used for delivery of any media content type, for example, audio, music, data files, web pages, games, etc. Additionally, throughout this disclosure reference is made to data, information, programs, movies, assets, video data, etc., however, it will be readily apparent to persons of ordinary skill in the art that these terms are substantially equivalent in reference to the example systems and/or methods disclosed herein. As used herein, the term title or program will be used to refer to, for example, a media content type such as a movie itself and not the name of the movie.
  • Referring now to FIG. 1, a satellite television broadcast system 10 is illustrated. The satellite television broadcast system 10 is illustrated by way of example. However, the present disclosure is not so limited hereto as mentioned above. The television broadcast system 10 includes a satellite 12 that receives content or programming from a primary service provider 14. More specifically, the primary service provider 14 includes a content system 16 that generates uplink signals 20 corresponding to content through an uplink antenna 18. The uplink signals 20 may be television signals and more specifically digital television signals. The uplink antenna 18 communicates the uplink signals 20 to the satellite 12 which in turn generates downlink signals 22. The downlink signals 22 are communicated to a receiving antenna 24 on a user receiving device 26. Although only one user receiving device 26 is illustrated, several user devices may be provided in the system 10. The user device 26 is primarily associated with and receives services from the primary service provider which may be in the form of signals or primary service data. As will be described below, a secondary or partner provider may also provide services (data et al.) to the user device. In the present example, the user receiving device may receive both television signals such as satellite television signals and data from the partner service provider (partner service data). For example, the partner service may be voicemail data. The uplink signals 20 and downlink signals 22 may be referred to as communication signals. Communication signals are wireless communication signals and may include various types of entertainment content, traffic, weather, hazardous material warnings, advertising material, and the like. As mentioned above, this system may be suitable for wired systems such as cable televisions and terrestrial wireless systems.
  • The user receiving device 26 may include a satellite television receiver, set top box or a digital video recorder. The satellite television receiver may also be referred to as an integrated receiver decoder. Of course, other types of user devices may be used such as a cable television set top box. Other types of user devices may include a mobile device such as a lap top computer, cellular phone, personal digital assistant, a portable media player or an automotive-based television receiving device. Thus, the user device may be a fixed user device in the case of a satellite television set top box or a mobile user device. Both fixed and mobile devices may be used in a system.
  • The primary service provider 14 may also include an account/billing web service 30 and an authentication server 32. The authentication server 32 may include an encrypted token (eToken) web service 32A and a setup web service 32B. The eToken web service 32A may be used to generate and validate eTokens. The generation and validation process will be further described below. The setup web service 32B may be used to setup or establish information so that an eToken may be generated. The set-up process will be described further below.
  • The primary service provider 14 may also include a conditional access management system 34. The conditional access management system 34 may be used to grant conditional access to various programming as well as provide recording commands to the user device 26 as will be described below.
  • The primary service provider 14 may also include a data web service 36. The data web service 36 may include a programming guide web service 36A, a key service or server 36B and a remote booking web service 36C.
  • The program guide web service 36A may be used to generate program guide data and information regarding various programming that is available. The program guide web service 36A, as will be described below, may generate custom programming guide information based upon the subscription to which a user is subscribed. The program guide web service 36A may also provide generic or non-customized content when specific user attributes are not known. When user attributes such as location and subscription information are known, only the content available to the particular subscriber may be included in the program guide. Additional content may be provided for advertising purposes. Thus, channel data for particular channels may be provided in the program guide.
  • The program guide web service 36A may generate program guide data for both linear and non-linear content. Linear content are television shows broadcasted at a particular time and a particular channel. Network television programming is an example. Non-linear content is programming that is not tied to a particular time such as on-demand content that can be requested at the user's discretion.
  • The customer care web service 36B may be used to generate and provide users with various types of help mechanisms to resolve technical issues.
  • The remote booking web service 36C may be used to generate remote booking commands or recording instructions as will be described below. The remote booking commands or recording instructions may be transmitted through the uplink antenna 18 to the satellite 12 and downlinked through the downlink signal 22 to an antenna 24 on the user device 26. A remote booking command may then initiate the user device 26 to store content broadcast by the satellite 12 thereon.
  • The user device 26 is in communication with the primary service provider 14 through a network 40. The network 40 may be a secured network or use a secure protocol. The network 40 may include a broadband network through which the user device 26 communicates with the primary service provider 14. The network 40 may be a wired network such as a public-switched telephone network (PSTN) or a broadband Internet network. The network may be wireless such as a cellular or wireless Internet system. The broadband network may communicate wired, wirelessly or a combination of both. For example, the user device 26 may include a wireless antenna 42 for communicating with an antenna 44 of a router 46 which, in turn, is in communication with the network 40. The router 46 may also have a wired connection between the user device, the router 46, and the network 40. The router 46 may also be called an Internet Gateway Device (IGD) or simply a gateway.
  • The user device 26 may be associated with a display 50 for displaying content and programming, as well as displaying various types of user commands, or the like. The display 50 may be a television or display integrated into the device. The display 50 may include speakers for an audio display. The display 50 may be used for displaying primary content from a primary service provider and secondary content from a secondary service provider.
  • The user device 26 may include a user interface 52, such as a keyboard, remote control, or the like, for selecting and entering various types of information by the user. The user device 26 may also include a conditional access module 54 that allows the user to access the programming provided from the content system 16. The conditional access module 54 may be referred to as an access card. The conditional access module 54 may include various activation codes without which the user device is not activated. The conditional access module 54 may include a conditional access module identifier such as a number or a code.
  • The user device 26 may also include a network interface 56 for interfacing with the network 40. For example, the network interface 56 may communicate wirelessly through the antenna 42 or through a direct connection such as an Ethernet connection. The network interface 56 may be but is not limited to a wireless broadband interface, a broadband interface, a modem-type interface or a public-switched telephone network interface.
  • The user device 26 may also include a storage device 58. The storage device 58 may store various content received from the primary service provider therein. The content may be received through the satellite 12 or through the network 40 through the network interface 56. The storage device 58 may be a hard disk drive or memory chip-based device. The storage device 58 may be referred to as a digital video recorder.
  • After the user device 26 is authenticated with the primary provider 14, the user device 26 may communicate with a user device locator module 70 through the network 40. The user device 26 may send the IP address of the user device, the port and the type of service offered on the ports to the user device locator module 70. Also, the user device encryption key may be provided from the user device 26 to the user device locator module 70. The user device locator module 70 may be a stand-alone device or it may be incorporated into the primary service provider 14. The user device locator module 70 may also be in communication with the authentication server 32.
  • The user device locator module 70 may include a look-up web service 72, a validation module 74 and a look-up delegate module 76.
  • The user device locator module 70 may be used to provide set top box port registration information from the user device. That is, the user device locator module 70 may include the IP address, port, service offered on the ports and the user device encryption key stored therein.
  • The primary service provider 14 may be in communication with a partner service provider 80. The partner service provider 80 may include a partner web application 82, a program guide cache 84, and a setup web page module 86. The partner web application 82 may generate various types of web content. For example, the partner web application 82 may generate a homepage-type display. The homepage display may receive information from the program guide cache 84 to fill a TV listing portion of the homepage display.
  • The setup web page module 86 may be used to setup various types of user network devices to communicate with the partner service provider 14 as will be described below.
  • The system may also include a user network device 90 that includes a display 92 associated therewith. The user network device 90 may be a web browsing device such as a portable computer, a personal digital assistant, a portable video player, an automotive-based user device, or the like. The user network device 90 may receive various data from the partner service provider 80 which may include a web page. The display 92 may be used for displaying various program guide information, along with other information provided by the partner service provider. The other information may include financial information, weather information, voicemail information, or other types of information. The partner service provider 80 may provide the content to be displayed on a website in various manners together with or in addition to the program guide information or other information.
  • An intermediate web provider 94 may also be included in the system. The intermediate web provider 94 may be used for communication between the primary service provider 14 and the user network device 90. The intermediate web provider 94 may be used to receive content or content clips from the primary service provider and store them therein. The user device 90 may obtain the content or content clips from the intermediate web provider 94 through the network 40 as will be further described below.
  • The intermediate web provider 94 may also communicate with the partner service provider 80. Rather than talking or communicating directly with the intermediate web provider 94, the user network device 90 may communicate with the partner service provider 80 and then to the intermediate web provider 94. This may allow another type of service to have access to the content on the intermediate web provider 94.
  • An interactive video guard (IVG) iChannel server 96 may be used to communicate between the user device 26 and the primary service provider 14. More specifically, the network interface 56 may be used to communicate between the IVG iChannel server 96 and a setup receiver identifier service module 32C. The IVG iChannel server 96 may be one of various types of connections. The IVG module is used as a secure connection between the user-receiving device 26 and the primary service provider 14. The secure connection is identified as reference numeral 98 in FIG. 1. It should be noted that the secure connection 98 may be part of the network 40. That is, the secure connection may be an HTTPS connection between the user device 26 and the primary service provider 14. The secure connection 98 may also be a public-switch telephone network connection. Thus, the network interface 56 may act as a modem or a broadband internet-type connection.
  • The setup receiver ID service 32C, which is disposed within the authentication server 32, is used for authenticating the user device 26. This will be described further below.
  • Referring now to FIG. 2, a partner service provider 80 is illustrated in further detail. The partner service provider 80 may include a router or VPN hardware 100. The router 100 may communicate with a router 102 at the primary service provider 14. The program guide web service 36A of FIG. 1 may include a program guide database 104.
  • The partner service provider 80 may include the program guide cache 84 as set forth above. The cache 84 is illustrated in FIG. 2 as two devices. The program guide web service 36A described in FIG. 1 as being within the primary service provider 14, may also be provided within the partner service provider 80. The program guide web service and cache 84 may communicate with the user network device 90 through respective firewalls 108A and 108B.
  • The program guide data may be communicated from the program guide database 104 through the router 102 to the router 100 and stored within the program guide web service and cache 84. A virtual private network tunnel 110 may be established between the router 100 and router 102 for transferring the data therethrough. By providing the program web service and cache 84 at the partner service provider 80, delays due to network connections may be reduced since the user network device 90 will not have to wait for program guide data to be transferred through the network between the primary service provider 14 and the partner service provider 80.
  • The program guide web service and cache 84 may each be in parallel with a firewall 108A and 108B. The output of the program web service and cache 84 may be provided to the partner web interface 112. The partner web interface 112 may be used to direct program guide data to the user network device 90.
  • Referring now to FIG. 3, a flow diagram having the setup page module 86, the authentication server 32 having the setup service 32B and the eToken service 32A, the data web service 36, and the account/billing web service 30 is illustrated. In step 200, a first-time user of the partner service web application may provide various identifying data to an account setup page. Thus, an account setup page may be initiated for a first-time user. Initiation of the setup page may also take place if the user requests data or requests an encrypted token from the data web service 36 for the first time. Identifiers prompted for entry at the setup page may include a site identifier which is the identifier of the partner service provider, a site user ID which is the partner's user ID. For example, the site ID may be the login identifier of the particular customer for the partner service provider. An internal identifier may also be provided, such as an account number that corresponds to the primary service provider account of the user. Other identifying information may include the customer's first name, last name, phone number and last bill amount provided by the primary service provider. The information mentioned above may be provided at a setup web page that identifies the user as a new user. The user network device 90 of FIG. 1 may be used to enter the information corresponding to the user. The site identifier may be provided by the particular partner service provider. The site identifier may be predetermined through an established arrangement with the primary service provider.
  • In step 200, after the user enters the various information into the setup web page, the information is communicated from the partner service provider, and, in particular, the setup web page to the setup web service 32B. The information may be communicated through the network 40 of FIG. 1.
  • In step 202, the account/billing web service 30 may receive the information at the primary service provider 14 through the network 40. The various information such as the internal identifier or account identifier may be provided to the account/billing service 30. The process may be first started by validating or authenticating the site identifier provided by the partner service provider. Thereafter, the internal account or ID may be authenticated.
  • In step 204, once the site identifier and the internal or account identifier are authenticated, a status signal is communicated to the setup web service 32B. The status may include a non-authenticated status.
  • If the status is positive, meaning the authentication has taken place, an encrypted token or eToken may be generated at the setup web service 32B in step 206. The eToken may be formed using various combinations of identifiers but may include a site identifier, a site user identifier, and a DIRECTV® internal identifier or account identifier. The eToken may also have an expiration date and/or time specified therein. The expiration date may have a current date time in which the eToken was formed and an elapsed time through which the eToken is valid. The elapsed time may be in seconds that are counted from the current time when the eToken is formed. Thus, the lifespan of the eToken is set forth. In subsequent authentication requests, if the expiration time is still valid, authentication may not be necessary. The eToken may be returned without modification if the eToken is still valid. If the expiration time has expired, re-authentication may be required and a new token may be generated with an updated expiration date and time.
  • In step 210, the partner service provider may also be used to obtain various data from the data web service 36 of the primary service provider 14. The partner service provider will thus not have individual customer or user information associated therewith. Therefore, the site identifier may be provided and dummy values or no values at all for the specific user information described above may be communicated to the setup web service 32B. If the site ID is a valid site ID as determined in the setup web service 32B, an eToken is generated using the site ID and dummy values if needed in step 212.
  • After the eTokens have been returned in steps 206 and 212, the web service or web application 82 in FIG. 1 of the partner service provider 80 may generate a web service request. The web service request may initiate from the user using the website from the partner service provider 80. The web service request may be a request for data. In addition, a web service request may initiate from the partner service provider itself so that various information may be received, such as program guide data. In step 214, the web service request is provided and may include the eToken, a site identifier, a site user identifier and a web service method. The web service request may be provided from the partner service provider and may be communicated to the data web service 36 of the primary service provider 14. Communication of the web service request may take place through the network 40.
  • In step 216, the information such as the site ID, the site user ID and the eToken may be communicated to the eToken web service 32A at the primary service provider 14. Authentication may decrypt the eToken and ensure that the site ID and the site user ID correspond with the site ID and the site user ID of the eToken. Authentication will be further described below. In step 218, the eToken and internal or account identifier may be returned once the authentication takes place in step 216. The return signal may return back to the web service 36. The web service 36 may then generate a web service response in step 220. The web service response may include an updated eToken if the eToken was expired and data from the web service 36.
  • Referring now to FIG. 4, a method for establishing communication between a partner service provider and the primary service provider and requesting program guide data is set forth in more detail. The method also applies to non-program guide data requests as well. In step 310, a request for an eToken is generated at a partner site using partner identification such as the site identifier. Dummy values may also be used to replace expected variables corresponding to other types of formats and devices. In step 312, the request for an eToken is communicated to the authentication web service. In step 314, the eToken is generated and provided to the partner site from the authentication server. The generating and communicating of the eToken is performed in response to authenticating or validating the site ID or any other identifiers provided. In step 316, a request or data from the partner to the program guide web service is performed using the eToken. In step 318, the request for program guide data is validated at the authentication web service. In step 320, the validation results are provided to the program guide web service. In step 322, if the results indicate the request is not valid, then step 322 ends the process. If a valid request was generated in step 322, step 326 generates a new eToken at the authentication web service. The revising of the eToken may be an optional step and may be performed when an eToken has expired. However, a new eToken could be generated at each request.
  • In step 328, the status, the new eToken and the program guide data may be communicated to the partner device. In step 330, the various data as received from the data web service of the primary service provider may be communicated to the user network device.
  • Referring now to FIG. 5, a method of configuring a user to communicate to the partner service provider and the primary service provider 14 is illustrated. In step 412, if the user is a first-time user, step 414 is performed. In step 414, the primary provider customer is directed to the setup page hosted by the partner. That is, the user device has setup information provided thereto. In step 416, information identifying the user is provided through the network user device. As mentioned above, this may include the name, address, telephone number, account or other type of identifier, or the like. In step 418, identifying information is provided from the setup page to the setup web service. That is, the information is communicated from the partner service provider to the primary service provider. In step 420, the site identifier is validated. In step 422, if the site identifier of the partner service provider is not valid, step 424 generates an error message. If the site is valid, step 426 compares the account ID and the user identifiers. In step 428, a status message is returned in response to the comparison performed in step 426. In step 430, if the information is not valid, an error message is generated in step 424. In step 430, if the user information is valid, step 432 generates an eToken at the authentication server 32 of the primary service device 14 of FIG. 1. In step 434, the eToken is communicated to the partner service provider 80. More specifically, the eToken may be provided to the setup page module 86.
  • In step 436, the partner web application and/or the setup web page module may receive the eToken. In step 438, the user information and the eToken are associated together. Thus, the user may only have to perform the setup web page service one time. Step 440 may be performed if step 412 indicates that the user has registered before. Also, step 440 is performed after step 438. In step 440, the web service request from the user network device 90 of FIG. 1 is generated. In step 442, the web service's request is communicated to the eToken web service 32A in the primary service provider 14 from the partner service provider 80. In step 444, the request is authenticated. In step 446, the web service responds by generating various data and communicating the data from the primary service provider 14 to the partner service provider 80 and ultimately to the user network device 90.
  • Referring now to FIG. 6, the authentication process described briefly in step 444 of FIG. 5 is set forth in more detail. In step 510, an eToken is received at the eToken web service 32A. Ultimately, the eToken arrives from the partner service provider 80 through the network 40. The eToken may arrive through one of the data web services 36. In step 512, if the site ID of the partner service provider is not a valid partner site identifier, step 514 generates an error signal. In step 512, if the partner site is a valid partner site, step 516 is performed. The site ID is then compared to the site ID that was encrypted into the eToken. That is, the eToken is decrypted to determine the site ID formed therein. If the site ID is not equal to the site ID retrieved from the eToken, step 514 is again performed. If the site ID is equal to the site ID from the eToken, step 518 is performed. In step 518, the site user ID is compared to the site user ID from the decrypted eToken. If the site ID is not equal to the site ID it retrieved from the eToken, step 514 generates an error signal. In step 518, if the site ID is equal to the eToken site user ID, step 520 is performed. In step 520, if the expiration time is greater than the current time, the eToken is returned in step 522.
  • In step 520, if the expiration time is greater than the current date and time, step 524 is performed. In step 524, if the expiration time is less than or equal to the current date and time, step 526 is performed. Step 526 authenticates the eToken internal identifier. If the eToken internal identifier is not valid in step 528, an error message is returned in step 530.
  • If the eToken internal ID is valid, step 532 updates the eToken expiration time. In step 534, the updated eToken is returned and the internal ID is communicated to the web service. In step 536, a web service response is generated.
  • In step 538, the updated eToken is communicated to the partner service provider 80.
  • Referring now to FIG. 7, a method for requesting a linear program guide is performed. In step 610, an eToken for the user is obtained through the partner site. In step 612, additional data such as the zip code and subscribed services may also be retrieved. The additional data may be retrieved using the setup web page module 86. In step 614, a request for the programming guide using the eToken, the site identifier, the site user identifier and the site listing start time may be generated at the partner service provider. In step 616, the request and associated data may be communicated to the program guide web service 36A. In step 618, the eToken may then be communicated to the authentication server 32 where it is authenticated. If the eToken is not valid, an error message is generated in step 622. In step 620, if the eToken is valid, step 624 communicates a guide listing response according to the user from the programming guide web service. That is, specific subscription data may be obtained from the account billing web service 30 to inform the program guide web service 36 as to the subscriptions and location of the user network device. The program guide in step 624 may return channel object data, schedule object data, program object data and user device data which correspond[s] to information regarding the integrated receiver decoder or set top box. The data may be used to provide a program guide to the user network device 90.
  • The channel object data may include the primary visible content channels valid between the listing start date and the end date. The channel data may include channels provided by the primary service provider as well as turnaround channels provided by the primary service provider. The channel object may comprise various information such as a channel key which is a unique key made up of the content channel identifier and the channel start time that identifies the channel instance. The content channel identifier specifies the identifier for the content channel. The channel start time and channel end time specify the starting and ending time that the channel is valid. Certain channels may be valid indefinitely and some channels may be valid only for a predetermined amount of time. The channel object may also include a channel object identifier. This specifies the content key in the provider system that maps to the content channel identifier. A major channel number and minor channel number may also be used as an identifier. A market identifier corresponding to a designated marketing area corresponding to the Nielsen® geographic data may also be set forth. National broadcast channels may not specify a market identifier. A source identifier may also be provided for the channel. For example, various sources for the channel identifier may be provided including Tribune Media Services. The station ID may also be provided in the channel object. A short name and long name corresponding to the call letters or the channel may be provided. A description, category, service type, codec type, network affiliation, channel logo ID and authorization code may also be provided. The authorization code may correspond to fully subscribed, partially subscribed, not subscribed or not applicable. The authorization code may allow users to view information if the information has been subscribed to.
  • Schedule data may also be provided which includes the air time for a particular program, the duration that includes the length of time that the program will air, an authorization code similar to those described above including subscribed, not subscribed and not applicable, and a blackout code to determine if the content may be blacked out.
  • Program data may also be provided. Program data may use a program reference identifier that is used to uniquely identify the program record and its contents. The program title, the episode title or the sports team's name may also be provided. A theatrical release year, original air date, a description describing the program content may also be provided. A secondary identifier such as a tribune media services identifier may also be provided in the program data. A category, label such as a category or genre may also be provided. The relevance of the category label may also be categorized. An in-guide flag may also be provided which indicates whether or not the label should appear with the program description on the screen. A credit, contribution, last name, first name, source type and network/syndicater-type may also be provided. Indicators may also be provided as to whether the program is in color, provides a secondary audio program, whether the program is a repeat, a premiere or a finale and whether the program is live, taped or taped delay. Other information may include whether the content is subtitled, letterboxed and the ratings of the particular content. An advisory may also be provided in the program data. An advisory may correspond to motion picture advisories. A television advisory may also be provided for television content that includes TVY7, TVPG, TV14, TVMA. A close-captioning indicator, a high definition indicator, an AC3 audio content indicator, a Dolby surround sound indicator, pay-per-view data, an all-day ticket data or a descriptive video service data may also be provided.
  • IRD data or set top box data may also be returned to the partner service provider. This information may be used to schedule a recording from the user network device. The partner service provider may use the IRD or user device information to target specific IRDs corresponding to the subscriber's account. The IRD or user device information may include a receiver ID that identifies the partner service receivers. The access card identifier may also be provided. The model number of the user device, the manufacturer of the user device and the location within the customer's premises may also be provided. The various numbers of receiving devices or user devices may be provided with a customer account. Therefore, a specific user device may be specified. The receiving device data may also include a remote booking allowed flag. This flag may indicate whether or not remote booking is allowed.
  • In step 626, the guide listings are returned that include the local channels, national channels and subscribed channels and the various data described above. In step 628, a program may be requested using the channel detail, the program detail and the user device data.
  • Referring now to FIG. 8, a detailed method for remote booking is set forth. Remote booking is used to allow the user network device to request the storage device of the user device to store a broadcast program or content. In step 810, an eToken is received at the partner site from the primary service provider, and, more particularly, eToken web service 32A of FIG. 1. In step 812, the user access card ID is obtained at the partner site. This may be obtained when a request for program guide data or other data is provided as mentioned above. In step 814, the program guide data is also received at the partner site. As mentioned above, various types of channel data, object data, program data and receiver device data may be obtained. In step 816, remote booking requests, including eToken, access card identifier and recording data may be generated. In step 818, the remote booking request may be communicated from the partner site to the primary provider. In step 820, a conditional access packet may be generated at the primary service provider.
  • In step 822, the conditional access packet may be communicated to the user device. The conditional access packet may be a recording instruction for a particular program at a particular time on a particular channel. In step 824, a response data may be generated from the primary service provider to the partner service provider. The response data may include a successful transmission of a conditional access packet to indicate that the user device may record the information within the storage device 58. After step 824, a new eToken with a new timestamp may be provided from the primary service provider and, in particular, the eToken web service 32A with a new timestamp. As mentioned above, a new timestamp may be provided if the previous timestamp has expired.
  • In step 828, the content may be recorded according to the recording request or conditional access packet as described above. The content is then able to be used and/or played back at the convenience of the user of the user device.
  • Referring now to FIG. 9, a method for reviewing content such as recorded clips of live events is set forth. In this example, the clips may be recorded or saved from a live event such as a football game or other event. The clips may be highlights of important events and thus may be only a small portion of a particular event. In step 910, clips of a live event are generated. The live event clips may be generated in the primary service provider or may be generated elsewhere and communicated to the primary service provider.
  • In step 912, a plurality of clips is communicated to an intermediate web provider. The clips may be provided to the intermediate web provider in response to a query from the intermediate web provider if more current clips are available. The clips may also automatically be provided to the intermediate web provider.
  • In step 914, an identifier from a user network device is communicated to the intermediate web provider. The user network device may communicate various identifier-type information including an account number or other type of login and/or password. In step 916, the user device is authenticated. The user device may be authenticated at the intermediate web provider, or the identifier data may be communicated to the primary service provider. In step 916, the network device is authenticated. In step 918, the service options to receive the content may be determined. For football clips, for example, the user may be required to subscribe to a Sunday football package. Both the authenticating and the verifying may take place either at the intermediate web provider or at the primary service provider. Both the authentication and verification may take place at the same time.
  • In step 920, if the user network device is not verified or authenticated, step 922 ends the process. In step 920, if the user network device has been verified and authenticated, step 924 communicates a content list to the user network device from the intermediate web provider. The content list may include a list of a number of the most recent NFL clips, in carrying forward with the example set forth above. For example, a list of five may be provided.
  • In step 926, content may be selected from the list to form a selection at the user network device. In step 928, the selection is communicated to the intermediate web provider. In step 930, the content corresponding to the selection is communicated to the user network device.
  • In step 932, the content may be displayed on the user network device. That is, the content video may be played back through the user network device. As mentioned above, the user network device may be various types of devices, including a mobile phone or other type of web-enabled device. It should be noted that the content list in FIG. 9 may be continually updated and thus the content list may be continually provided to the user network devices.
  • Referring now to FIGS. 1 and 10, a method for authenticating a user-receiving device such as a satellite set top box receiving device 26 is set forth. In step 1010, the receiving device generates a setup request using a site ID, a receiver ID and a receiver card ID. The site ID is the site identifier for the particular DIRECTV® partner. This may be a numeric identifier, alphanumeric identifier or alphabetic identifier. The receiver identifier may also be referred to as a site user identifier. The user ID may be the serial number of the particular receiver within the home associated with a particular account. The receiver card ID is the identification number associated with the particular conditional access module or access card.
  • In step 1012, a connection to the primary service provider 14 is requested. The request may be a request to setup or establish a connection. An interactive video guard connection may be established so that the connection is secure. First, step 1012 establishes a connection with an IVG iChannel server 96 of FIG. 1. The IVG iChannel server 96 may also be located within the primary service provider 14. As illustrated, the IVG iChannel server 96 is a standalone device. Also, the secure connection 98 between the IVG iChannel server 96 and the user device 26 and the IVG iChannel server 96 and the primary service provider 14 may be established through a secure connection through the network 40.
  • In step 1014, the request is communicated from the IVG iChannel server 96 to the primary service provider 14. The site identifier may be confirmed in step 1016. The site identifier may be confirmed by determining if the number or identifier is a valid identifier. In step 1020, if the site identifier is not confirmed, the system ends in step 1022. An error message may be sent to the user receiving device that authentication is not possible. Further, the system may ask for re-entry of certain information or start the process again at step 1010.
  • If the site identifier has been confirmed, step 1024 is performed. In step 1024, it is determined whether an eToken for the user receiving device exists. If an eToken does not exist for the user receiving device, step 1026 determines whether there is an account associated with the site identifier. If there is not an account with the site identifier, step 1028 is performed in which an error signal or error flag may be generated. If there is an account associated with the account identifier in step 1030, the account identifier is retrieved. The account identifier may be the account number associated with the particular user.
  • In step 1032, an eToken is generated. The eToken is generated by encrypting various data into the binary-encrypted token. The site ID, the user receiving device ID, the account identifier obtained in step 1030 and an internal DIRECTV®-registered user identifier may also be encrypted into the eToken. However, not all of the above-mentioned components may be placed into the encrypted token. Further, an expiration date and/or time may be provided in the encrypted token. This time value defines the lifespan of the authentication of the eToken. If the expiration time has expired, an expired eToken message may be returned. In step 1034, the eToken is returned and the account identifier is returned to the iChannel server. In step 1036, the eToken and the account identifier are communicated to the user receiving device from the iChannel server.
  • Referring back to step 1024, if the eToken for the user identifier does exist, the eToken is retrieved in step 1040. After step 1040, step 1042 determines whether the eToken has expired. If the eToken has not expired, the system continues in step 1034 where the eToken is returned.
  • Referring back to step 1042, if the eToken has expired, the system determines whether an active account is still associated with the eToken. If an active account is not associated with the eToken, step 1050 ends the process. If an active account is associated with the eToken, an eToken is generated in step 1032. Thereafter, steps 1034 and 1036 are provided which communicate the eToken back to the user receiving device 26.
  • Referring now to FIG. 11, once the eToken has been provided to the user receiving device, the user receiving device is ready to communicate with the partner service provider 80 of FIG. 1. Various types of data may be exchanged between the partner service provider 80 and the user device 26. It is likely that the bulk of the data will be providing a service from the partner service provider 80 to the user device 26. For example, the partner service provider 80 may be a telecom provider providing voicemail or other types of data service that may be used in conjunction with the display 50 associated with the user device 26 of FIG. 1. In step 110, the eToken is received at the partner service provider 80.
  • A request for data, a request to communicate or other type of communication is initiated at the user receiving device. Ultimately, the eToken arrives through the network 40 in addition to other data. In step 1112, if the site ID of the user device is not valid, step 1114 generates an error message signal. In step 1112, if the site ID is a valid site ID, step 1116 is performed. The site ID is then compared to the site ID that was encrypted into the eToken in step 1116. That is, the eToken is decrypted to determine the site ID formed therein. If the site ID is not equal to the site ID retrieved from the eToken, step 1114 is again performed. If the site ID is equal to the site ID from the eToken, step 1118 is performed. In step 1118, the receiver ID is compared to the receiver ID from the decrypted eToken. If the site ID is not equal to the site ID it is retrieved from the eToken, step 1114 generates an error signal. In step 1118, if the site ID is equal to the eToken site user ID, step 1120 is performed. In step 1120, if the expiration time is greater than the current time, the eToken is returned in step 1122.
  • In step 1120, if the expiration time is greater than the current date and time, step 1124 is performed. In step 1124, it is determined whether the site ID is a generic partner type or a specific partner type. If the ID is a generic type, a generic flag is returned in step 1126. In step 1124, if the site ID is not a generic type, meaning a specific user, step 118 returns an account identifier.
  • In step 1130, if the expiration time is less than or equal to the current date and time, step 1132 is performed. In step 1132, an expired error message is returned.
  • After step 1132, step 1134 determines whether or not the eToken is valid. If the eToken is not valid, step 1136 returns an error message. In step 1134, if the eToken is valid, step 1140 establishes communication between the partner site and the user receiving device. In step 1142, data may then be exchanged between the two devices. That is, the set top box or user receiving device may directly exchange data with the partner service provider. As mentioned above, various services, such as telecom services, may be provided. One example is that voicemail may then be communicated to the user device 26 by using the user interface 52 and display 50 as illustrated in FIG. 1.
  • Referring now to FIG. 12, a map 1210 of the Continental United States is illustrated. The map 1210 represents a geographical area having a plurality of locator modules 70. A plurality of locator modules 70 may be used to distribute the load across the geographic area. However, as illustrated in FIG. 1, only one locator module 70 may be used. Each locator module 70 may be located in a particular region of the geographic area. A plurality of user devices 26 may be associated with each locator module 70. That is, when a connection is desired between a user receiving device 26 and the locator module 70, the locator module 70 closest to the user receiving device 26 may be chosen for communicating. An alternative one or several user locator modules 70 may also be tried in the case of a slow connection or no connection between the user receiving device 26 and the locator module 70.
  • Various partner service providers 80 may also be in communication with the user device locator module 70. Various numbers of partner service providers 80 may be provided throughout the geographic area. As illustrated, four partner service providers 80 are illustrated each in communication with a different user device locator module 70.
  • Referring now to FIG. 13, only one partner 80 and only one user device 26 is illustrated in communication with three user device locator modules 70 through the network 40 for simplicity. As illustrated in FIG. 12, various numbers of partners 80 and various numbers of user devices 26 may be interconnected. The locator modules 70 may be connected to an internal network 1310. The internal network 1310 may be private. The internal network 1310 may be part of, but isolated from, other portions of the locator module 70 by firewalls 1312. The network 1310 may include an account database 1314 and a key server or service 1316. Firewalls 1312 may set up a demilitarized zone (DMZ) to prevent unauthorized access from the Internet into the partner private network 1310. The locator modules 70 may be servers that have an outfacing public IP address connected to the Internet or the network 40 to provide user device registration, look-up service and a key retrieval service. The firewalls 1312 may thus prevent unauthorized access to the account database 1314 and the key server or service 1316. The key server 1316 and the account database 1314 may have an internal non-public IP address sub-net that may be used to exchange information between the server 70 and the internal databases. The locator modules 70 may be located in remote uplink facilities used to collect local channels and uplink them to the satellite 12. The locator module 70 may have the internal private network in communication with the primary service provider 14 and in particular the authentication server therein. The authentication server 32 may be used to verify or authenticate requests by verifying or authenticating the eTokens therein.
  • Referring to both FIGS. 12 and 13, the user receiving devices 26 may be provided with a listing of all the locator modules 70 as well as their IP addresses. The locator module 70 with the closest geographic location may be chosen by the user receiving device 26. However, the option of trying various other locator modules 70 may be provided. By geographically distributing the locator modules 70, application performance and load spread may be improved.
  • Referring now to FIG. 14, a method for registering data with the locator module 70 is illustrated. There are three main steps in the process. The first two of the three steps will be described in FIGS. 15 and 16 in further detail. The first step is FIG. 1410 in which the determination of a communication port is performed by initiating an Internet Gateway Device (IGD) port forwarding sequence. After port forwarding is performed, step 1412 the user device registers with the locator module 70. Thereafter, step 1414 monitors for public IP address changes.
  • Referring now to FIG. 15, step 1410 is illustrated in further detail. In step 1510, the process starts when the user receiving device is rebooted or restarted. As mentioned above, the user receiving device may be a television receiving device such as a satellite television receiving device. In step 1512, the user receiving device will attempt to locate the Internet Gateway Device (IGD) such as a home router or gateway (46 of FIG. 1). The user receiving device will determine whether the router of FIG. 1 is universal plug and play (UPnP) capable. A UPnP multicast packet is generated at the user receiving device and transmitted to the router or IGD 46. In step 1514, if a response is generated by the IGD, the IGD is UPnP compatible and step 1516 is performed.
  • In step 1516, the available services are communicated to the user receiving device. The available services may include a public IP address, a port forwarding service, or the like.
  • In step 1518, the user receiving device locates an open port. This may be performed if the gateway or router device lists port forwarding as one of the available services. The user receiving device may attempt to locate an open port on the gateway device either through a port scan or arbitrarily picking an open port and configuring the gateway device by performing a port forwarding command as specified in the UPnP protocol. In step 1520, when an open port has been successfully determined, the gateway device notifies or communicates a message indicating the port has been open to accept incoming connections.
  • In step 1522, once a port has been chosen, the user receiving device starts a listening service on the forwarding port.
  • Referring back to step 1514, if a response has not been received, the gateway or router 46 may not be universal pug and play compatible. In step 1530, a manual configuration of a forwarding port on the Internet Gateway Device, such as the router, may be performed. In step 1532, the same port used as the forwarding port in step 1530 may be configured on the user receiving device.
  • Once configured, the port may be used to communicate partner service data to the user receiving device and communicate signals from the user receiving device. The partner service data may be received in addition to primary service data or signals.
  • Referring now to FIG. 16, step 1412 of FIG. 14 is illustrated in further detail. In step 1612, a secure connection between the locator module 70 and the user receiving device through the gateway device is performed. This may be a secure sockets layer (SSL) type connection. In step 1614, registration data may be communicated from the user receiving device to the locator module that includes port information. The data provided from the user receiving device may include user device data including a site identifier that identifies the user device as an individual user device rather than a partner service provider. A site user identifier, such as a receiver identifier, may also be provided. The receiver identifier may include a serial number or model number of the user receiving device 26. An encrypted token may also be provided from the user device to the locator module. The encrypted token may be formed as described above and may include various types of encrypted data such as the site identifier, the site user identifier or receiver user identifier and the expiration date of the encrypted token.
  • Also, in step 1614 port information such as an IP address, port forwarding data, an access card identifier, a receiver identifier, a service identifier and a service description may also be provided to the locator module. In step 1616, the locator module may cross-reference the data provided in step 1614 against an account database. The account database may reside within the locator module or may reside within the authentication server 32 of the primary service provider. For example, the eToken web service 32A may be used to authenticate the web service, whereas the setup web service 32B may be used to setup and verify the information. Further, the account/billing web service 30 may also be used to determine billing information.
  • In step 1618, the locator module determines if the user device is associated with a valid customer and whether the account is in good standing. Again, this step may be performed at the locator module or at the primary service provider. In step 1620, if the customer is a valid customer and the account is not in good standing, step 1622 terminates the process. In step 1620, if the customer is a valid customer and the account is in good standing, step 1624 registers the user device within the locator module 70. In step 1626, the secure connection is no longer needed and thus the secure connection is terminated.
  • After registration of the user device with the locator module, other devices or services such as the partner service provider are able to locate the user receiving device and communicate services or partner service data thereto.
  • Referring now to FIG. 17, a sequence diagram of the look-up web service is illustrated. In step 1710, a look-up request is generated from the partner service provider 80 or other type of requester. It should be noted that the requester may also be another user device 26 that seeks access to another user receiving device. A look-up request generated in step 1710 is provided to the look-up web service 72. In step 1712, the header of the request may be validated in the validation module 74 of the locator module 70. In step 1714, a validation status is returned from the validation module 74 to the look-up web service 72. A validation failure signal is communicated from the look-up web service 72 to the partner service provider 80 or other requester if validation fails. In step 1718, if validation is successful, a delegate request for processing is provided to the look-up delegate 76. The request may include an eToken that is authenticated at the authentication web service 32 in step 1720. The authentication of an eToken is described above. In short, the encrypted token may be decrypted and its contents compared to other transmitted data. If authentication fails in step 1720, the authentication web service 32 may return an authentication failure signal to the partner service provider 80. In step 1720, if the authentication is successful, step 1724 is performed that retrieves the results if the authentication succeeds. In step 1726, a valid result set is returned to the look-up web service 72. In step 1728, the look-up web service, after receiving the valid result set in step 1726, returns the result set to the partner service provider in step 1728.
  • Referring now to FIG. 18, further details of FIG. 17 are set forth. In step 1810, when a requester such as a partner service provider 80 or another user receiving device 26 desires direct communication with another user receiving device, a secure link between the requester and the locator module is formed. An SSL connection may be formed between the locator module and the requestor. In step 1812, a request is communicated to the locator module. The request may include a site identifier, such as the partner service provider identifier, and a site user identifier. The site user identifier may correspond to the partner service provider identifier for the particular user receiving device. An eToken may also be provided. Data such as a service identifier and a receiver identifier may also be provided.
  • In step 1814, authentication of the identity of the requestor may be performed. The authentication may take place by comparing the eToken to the information provided. That is, by decrypting the eToken and comparing the eToken values to the site ID and the user ID, authentication may take place. In step 1816, if the requestor is not authenticated using the eToken, step 1818 generates an error message. In step 1816, if the requestor is authenticated, step 1820 determines whether the requestor is authorized to receive user device data by comparing the request against a known list of services and receiver identifiers. If the request is not valid in step 1822, step 1818 is performed in which an error message is generated. After step 1822, if the request is valid, step 1824 returns a response with various parameters. Once the response is generated, a peer-to-peer connection may be formed directly between the requester and the user receiving device in step 1826. The requestor may be a partner service provider communicating partner service data to the user receiving device. The user receiving device may also communicate data to the requestor. In addition, the user receiving device may receive primary service data or signals.
  • Referring now to FIG. 19, the user receiving device and the partner service provider 80 may communicate using a key. Thus, the process described above in FIG. 18 may be modified to perform key retrieval. In step 1910, the requestor may make a secure connection to the locator server. In step 1912, authentication data may be provided to the locator module from the requestor. The locator or the authentication data may include a site identifier which may be a numeric or alphanumeric or alphabetical site identifier. A site user ID such as the partner service provider user identifier may be provided. An encrypted token may also be provided. The locator module may individually or through the primary service provider 14 verify the requester eToken to verify the identity of the requester in step 1914. In step 1916, if the identity is not verified, an error signal is generated in 1918. If the requester is verified in step 1916, a public key of the user receiving device is communicated to the requestor. In step 1922, a secure connection is terminated once the public key is provided. In step 1924, communication between the user device and the requester, such as a partner service provider, may be provided using the key. Thus, using the key the various data may be encrypted and decrypted. One example is that a user datagram protocol (UDP) datagram may be encrypted. Thereafter, partner service provider data may then be provided in addition to primary service data.
  • Those skilled in the art can now appreciate from the foregoing description that the broad teachings of the disclosure can be implemented in a variety of forms. Therefore, while this disclosure includes particular examples, the true scope of the disclosure 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.

Claims (32)

1. A method comprising:
forming a secure connection between a user receiving device and a user device locator module;
communicating user identifier data to the user device locator module from the user receiving device;
communicating port data from the user receiving device to the user device locator module;
authenticating the user data from the user device locator module; and
after authenticating, registering the port data at the user device locator module.
2. A method as recited in claim 1 further comprising prior to forming a secure connection, configuring a port of a gateway device so that the user receiving device listens thereto.
3. A method as recited in claim 1 wherein forming a secure connection between a user receiving device and a user device locator module comprises forming a secure sockets layer connection between a user receiving device and a user device locator module.
4. A method as recited in claim 1 wherein communicating user identifier data to the user device locator module from the user receiving device comprises communicating user identifier data to the user device locator module from a television receiving device.
5. A method as recited in claim 1 wherein communicating user identifier data to the user device locator module from the user receiving device comprises communicating user identifier data to the user device locator module from a satellite television receiving device.
6. A method as recited in claim 1 wherein authenticating comprises authenticating the user data by communicating between the user receiving device locator module and an authentication server of a primary service provider.
7. A method as recited in claim 1 wherein communicating port data comprises communicating an IP address.
8. A method as recited in claim 1 wherein communicating port data comprises communicating an IP address, forwarding port data and an access card identifier.
9. A method as recited in claim 1 wherein communicating port data comprises communicating an IP address, forwarding port data, an access card identifier and a receiver identifier.
10. A method as recited in claim 1 wherein communicating port data comprises communicating an IP address, forwarding port data, an access card identifier, a receiver identifier and a service description.
11. A method as recited in claim 1 wherein authenticating comprises communicating a request for authentication from the user device locator module to an authentication server;
authenticating the user data at the authentication server and generating authentication data at the authentication server; and
communicating the authentication data to the user device locator module.
12. A method as recited in claim 11 wherein communicating a request for authentication comprises communicating a user device identifier to the authentication server.
13. A method as recited in claim 11 wherein communicating a request for authentication comprises communicating a site identifier to the authentication server.
14. A method as recited in claim 11 wherein communicating a request for authentication comprises communicating a site identifier and a user device identifier to the authentication server.
15. A method as recited in claim 11 wherein communicating a request for authentication comprises communicating an encrypted token to the authentication server.
16. A method as recited in claim 11 wherein communicating a request for authentication comprises communicating an encrypted token, a site identifier and a user device identifier to the authentication server.
17. A method as recited in claim 1 further comprising communicating partner service data to the user receiving device and communicating primary service data to the user receiving device.
18. A system comprising:
a user device locator module;
a user receiving device forming a secure connection with the user device locator module and communicating user identifier data and port data to the user device locator module; and
an authentication module authenticating the user data from the user device locator module and generating an authentication signal;
said user device locator module registering the port data at the user device locator module in response to the authentication signal.
19. A system as recited in claim 18 wherein the port data comprises an IP address.
20. A system as recited in claim 18 wherein the port data comprises an IP address, forwarding port data and an access card identifier.
21. A system as recited in claim 18 wherein the port data comprises an IP address, forwarding port data, an access card identifier and a receiver identifier.
22. A system as recited in claim 18 wherein the port data comprises an IP address, forwarding port data, an access card identifier, a receiver identifier and a service description.
23. A system as recited in claim 18 wherein the user device locator module communicates a request for authentication to the authentication server;
said authentication server authenticating the user data, generating authentication data and communicating the authentication data to the user device locator module.
24. A system as recited in claim 23 wherein the request for authentication comprises a user device identifier.
25. A system as recited in claim 23 wherein the request for authentication comprises a site identifier.
26. A system as recited in claim 23 wherein the request for authentication comprises a site identifier and a user device identifier.
27. A system as recited in claim 23 wherein the request for authentication comprises an encrypted token.
28. A system as recited in claim 23 wherein the request for authentication comprises an encrypted token, a site identifier and a user device identifier.
29. A system as recited in claim 18 wherein the user receiving device comprises a television receiving device.
30. A system as recited in claim 18 wherein the user receiving device comprises a satellite television receiving device.
31. A system as recited in claim 18 further comprising a primary service provider communicating primary service data to the user receiving device.
32. A system as recited in claim 31 further comprising a partner service provider communicating partner service data to the user receiving device in response to the port data.
US11/960,951 2007-12-20 2007-12-20 Method and apparatus for communicating between a user device and a user device locating module to allow a partner service to be provided to a user device Active 2032-05-28 US8789149B2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US11/960,951 US8789149B2 (en) 2007-12-20 2007-12-20 Method and apparatus for communicating between a user device and a user device locating module to allow a partner service to be provided to a user device

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US11/960,951 US8789149B2 (en) 2007-12-20 2007-12-20 Method and apparatus for communicating between a user device and a user device locating module to allow a partner service to be provided to a user device

Publications (2)

Publication Number Publication Date
US20090165105A1 true US20090165105A1 (en) 2009-06-25
US8789149B2 US8789149B2 (en) 2014-07-22

Family

ID=40790307

Family Applications (1)

Application Number Title Priority Date Filing Date
US11/960,951 Active 2032-05-28 US8789149B2 (en) 2007-12-20 2007-12-20 Method and apparatus for communicating between a user device and a user device locating module to allow a partner service to be provided to a user device

Country Status (1)

Country Link
US (1) US8789149B2 (en)

Cited By (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090320103A1 (en) * 2008-06-24 2009-12-24 Microsoft Corporation Extensible mechanism for securing objects using claims
US20100235902A1 (en) * 2009-03-13 2010-09-16 Juniper Networks, Inc. Server protection from distributed denial of service attacks
WO2010145291A1 (en) * 2009-11-05 2010-12-23 中兴通讯股份有限公司 Method and system for realizing identifier and locator separation
US20110035794A1 (en) * 2008-04-25 2011-02-10 Huawei Technologies Co., Ltd. Method and entity for authenticating tokens for web services
US20110047596A1 (en) * 2009-08-21 2011-02-24 Verizon Patent And Licensing, Inc. Keystroke logger for unix-based systems
CN102036228A (en) * 2009-09-29 2011-04-27 中兴通讯股份有限公司 Method and system for realizing terminal handover
US20130307785A1 (en) * 2011-01-27 2013-11-21 Panasonic Corporation Network control system, control apparatus, controlled apparatus, and apparatus control method
US8656154B1 (en) * 2011-06-02 2014-02-18 Zscaler, Inc. Cloud based service logout using cryptographic challenge response
US8689004B2 (en) 2010-11-05 2014-04-01 Microsoft Corporation Pluggable claim providers
US20140337958A1 (en) * 2009-12-29 2014-11-13 Akamai Technologies, Inc. Security framework for http streaming architecture
US20150326560A1 (en) * 2010-12-23 2015-11-12 Microsoft Technology Licensing, Llc Registration and network access control
US20200120172A1 (en) * 2018-10-10 2020-04-16 NEC Laboratories Europe GmbH Method and system for synchronizing user identities
US20210243501A1 (en) * 2010-07-12 2021-08-05 Time Warner Cable Enterprises Llc Apparatus and methods for content management and account linking across multiple content delivery networks

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9742767B1 (en) 2014-09-25 2017-08-22 Google Inc. Systems, methods, and media for authenticating multiple devices
US20160149775A1 (en) * 2014-11-23 2016-05-26 Dennis Cheung Determining physical location of a networked computing device

Citations (40)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6229540B1 (en) * 1996-02-23 2001-05-08 Visionael Corporation Auditing networks
US20020026643A1 (en) * 2000-05-12 2002-02-28 Henry Ewen Data transmission system and method
US20030031184A1 (en) * 2001-08-13 2003-02-13 Sbc Technology Resources, Inc. Authentication for use of high speed network resources
US20030095791A1 (en) * 2000-03-02 2003-05-22 Barton James M. System and method for internet access to a personal television service
US20040034771A1 (en) * 2002-08-13 2004-02-19 Edgett Jeff Steven Method and system for changing security information in a computer network
US20040039905A1 (en) * 2002-08-26 2004-02-26 Axxian Technologies Inc. Method and apparatus for sharing data between a server and a plurality of clients
US20040117430A1 (en) * 2002-10-10 2004-06-17 International Business Machines Corporation Method and systems for protecting subscriber identification between service and content providers
US6801528B2 (en) * 2002-07-03 2004-10-05 Ericsson Inc. System and method for dynamic simultaneous connection to multiple service providers
US20040233897A1 (en) * 2003-04-18 2004-11-25 Keisuke Yamaguchi System and method for controlling communication using device ID
US6839757B1 (en) * 1999-04-28 2005-01-04 2Wire, Inc. System and method for automatically discovering accessible services on a computer network and providing automatic access thereto
US20050050333A1 (en) * 2003-08-27 2005-03-03 Bce Inc. System and method for secure broadcast
US20050086683A1 (en) * 2003-06-24 2005-04-21 Randy Meyerson Multiple entity control of access restrictions for media playback
US6885660B2 (en) * 2000-04-09 2005-04-26 Lead Ip Systems Ltd. End to end network communication
US20050152287A1 (en) * 2004-01-09 2005-07-14 Matsushita Electric Industrial Co., Ltd. IP device, management server, and network system
US6983319B1 (en) * 2001-04-06 2006-01-03 Permeo Technologies, Inc. Dynamic port management
US20060031472A1 (en) * 2004-06-30 2006-02-09 Anand Rajavelu Network data analysis and characterization model for implementation of secure enclaves within large corporate networks
US20060036847A1 (en) * 2004-08-10 2006-02-16 Pure Networks, Inc. Service licensing and maintenance for networks
US20060046744A1 (en) * 2004-08-27 2006-03-02 Microsoft Corporation System and method for enforcing location privacy using rights management
US20060056397A1 (en) * 2004-09-15 2006-03-16 Kabushiki Kaisha Toshiba Access management apparatus, program and remote start-up method of terminal device
US7027460B2 (en) * 2001-12-21 2006-04-11 Intel Corporation Method and system for customized television viewing using a peer-to-peer network
US7054447B1 (en) * 2000-09-01 2006-05-30 Pgp Corporation Method and apparatus for periodically removing invalid public keys from a public key server
US20060117342A1 (en) * 2004-11-30 2006-06-01 Park Pyung K Method for acquiring channel information and registering for reception of multicast based IP TV broadcasting in access network
US7069312B2 (en) * 2002-12-06 2006-06-27 Microsoft Corporation Network location signature for disambiguating multicast messages in dual-IP stack and/or multi-homed network environments
US20060174127A1 (en) * 2004-11-05 2006-08-03 Asawaree Kalavade Network access server (NAS) discovery and associated automated authentication in heterogenous public hotspot networks
US20060242322A1 (en) * 2005-04-25 2006-10-26 Microsoft Corporation Trans-network roaming and resolution with web services for devices
US7137006B1 (en) * 1999-09-24 2006-11-14 Citicorp Development Center, Inc. Method and system for single sign-on user access to multiple web servers
US7194759B1 (en) * 2000-09-15 2007-03-20 International Business Machines Corporation Used trusted co-servers to enhance security of web interaction
US20070162748A1 (en) * 2006-01-06 2007-07-12 Masataka Okayama Apparatus for Encrypted Communication on Network
US20070214103A1 (en) * 2006-03-10 2007-09-13 Sbc Knowledge Ventures L.P. System and method for providing content over a communications network
US20070217434A1 (en) * 2006-03-14 2007-09-20 Aastra Technologies Ltd. Method for configuring remote IP phones
US20070266026A1 (en) * 2006-03-06 2007-11-15 Murali Aravamudan Methods and systems for selecting and presenting content based on user preference information extracted from an aggregate preference signature
US20070274327A1 (en) * 2006-05-23 2007-11-29 Kari Kaarela Bridging between AD HOC local networks and internet-based peer-to-peer networks
US7356584B2 (en) * 2003-03-03 2008-04-08 Microsoft Corporation Optimization of service provider load balancing
US20080112405A1 (en) * 2006-11-01 2008-05-15 Chris Cholas Methods and apparatus for premises content distribution
US20080235513A1 (en) * 2007-03-19 2008-09-25 Microsoft Corporation Three Party Authentication
US20090129301A1 (en) * 2007-11-15 2009-05-21 Nokia Corporation And Recordation Configuring a user device to remotely access a private network
US20090207905A1 (en) * 2006-08-10 2009-08-20 Sony Corporation Communication processing device, data communication system, method, and computer program
US7668838B2 (en) * 2006-03-28 2010-02-23 Yahoo! Inc. Providing event information to third party event applications
US20100180322A1 (en) * 2005-09-20 2010-07-15 Cisco Technology, Inc. System and method for floating port configuration
US20100241748A1 (en) * 2006-12-29 2010-09-23 Prodea Systems , Inc. System and method for providing network support services and premises gateway support infrastructure

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050125540A1 (en) 2003-12-08 2005-06-09 Oliver Szu Home portal router
US7827252B2 (en) 2004-12-07 2010-11-02 Cisco Technology, Inc. Network device management
US20070237133A1 (en) 2005-10-07 2007-10-11 Steven Woods System and method for providing content, applications, services and digital media to users in a peer-to-peer network
US20070153812A1 (en) 2005-12-29 2007-07-05 John Kemp Dynamic discovery of a network service on a mobile device

Patent Citations (40)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6229540B1 (en) * 1996-02-23 2001-05-08 Visionael Corporation Auditing networks
US6839757B1 (en) * 1999-04-28 2005-01-04 2Wire, Inc. System and method for automatically discovering accessible services on a computer network and providing automatic access thereto
US7137006B1 (en) * 1999-09-24 2006-11-14 Citicorp Development Center, Inc. Method and system for single sign-on user access to multiple web servers
US20030095791A1 (en) * 2000-03-02 2003-05-22 Barton James M. System and method for internet access to a personal television service
US6885660B2 (en) * 2000-04-09 2005-04-26 Lead Ip Systems Ltd. End to end network communication
US20020026643A1 (en) * 2000-05-12 2002-02-28 Henry Ewen Data transmission system and method
US7054447B1 (en) * 2000-09-01 2006-05-30 Pgp Corporation Method and apparatus for periodically removing invalid public keys from a public key server
US7194759B1 (en) * 2000-09-15 2007-03-20 International Business Machines Corporation Used trusted co-servers to enhance security of web interaction
US6983319B1 (en) * 2001-04-06 2006-01-03 Permeo Technologies, Inc. Dynamic port management
US20030031184A1 (en) * 2001-08-13 2003-02-13 Sbc Technology Resources, Inc. Authentication for use of high speed network resources
US7027460B2 (en) * 2001-12-21 2006-04-11 Intel Corporation Method and system for customized television viewing using a peer-to-peer network
US6801528B2 (en) * 2002-07-03 2004-10-05 Ericsson Inc. System and method for dynamic simultaneous connection to multiple service providers
US20040034771A1 (en) * 2002-08-13 2004-02-19 Edgett Jeff Steven Method and system for changing security information in a computer network
US20040039905A1 (en) * 2002-08-26 2004-02-26 Axxian Technologies Inc. Method and apparatus for sharing data between a server and a plurality of clients
US20040117430A1 (en) * 2002-10-10 2004-06-17 International Business Machines Corporation Method and systems for protecting subscriber identification between service and content providers
US7069312B2 (en) * 2002-12-06 2006-06-27 Microsoft Corporation Network location signature for disambiguating multicast messages in dual-IP stack and/or multi-homed network environments
US7356584B2 (en) * 2003-03-03 2008-04-08 Microsoft Corporation Optimization of service provider load balancing
US20040233897A1 (en) * 2003-04-18 2004-11-25 Keisuke Yamaguchi System and method for controlling communication using device ID
US20050086683A1 (en) * 2003-06-24 2005-04-21 Randy Meyerson Multiple entity control of access restrictions for media playback
US20050050333A1 (en) * 2003-08-27 2005-03-03 Bce Inc. System and method for secure broadcast
US20050152287A1 (en) * 2004-01-09 2005-07-14 Matsushita Electric Industrial Co., Ltd. IP device, management server, and network system
US20060031472A1 (en) * 2004-06-30 2006-02-09 Anand Rajavelu Network data analysis and characterization model for implementation of secure enclaves within large corporate networks
US20060036847A1 (en) * 2004-08-10 2006-02-16 Pure Networks, Inc. Service licensing and maintenance for networks
US20060046744A1 (en) * 2004-08-27 2006-03-02 Microsoft Corporation System and method for enforcing location privacy using rights management
US20060056397A1 (en) * 2004-09-15 2006-03-16 Kabushiki Kaisha Toshiba Access management apparatus, program and remote start-up method of terminal device
US20060174127A1 (en) * 2004-11-05 2006-08-03 Asawaree Kalavade Network access server (NAS) discovery and associated automated authentication in heterogenous public hotspot networks
US20060117342A1 (en) * 2004-11-30 2006-06-01 Park Pyung K Method for acquiring channel information and registering for reception of multicast based IP TV broadcasting in access network
US20060242322A1 (en) * 2005-04-25 2006-10-26 Microsoft Corporation Trans-network roaming and resolution with web services for devices
US20100180322A1 (en) * 2005-09-20 2010-07-15 Cisco Technology, Inc. System and method for floating port configuration
US20070162748A1 (en) * 2006-01-06 2007-07-12 Masataka Okayama Apparatus for Encrypted Communication on Network
US20070266026A1 (en) * 2006-03-06 2007-11-15 Murali Aravamudan Methods and systems for selecting and presenting content based on user preference information extracted from an aggregate preference signature
US20070214103A1 (en) * 2006-03-10 2007-09-13 Sbc Knowledge Ventures L.P. System and method for providing content over a communications network
US20070217434A1 (en) * 2006-03-14 2007-09-20 Aastra Technologies Ltd. Method for configuring remote IP phones
US7668838B2 (en) * 2006-03-28 2010-02-23 Yahoo! Inc. Providing event information to third party event applications
US20070274327A1 (en) * 2006-05-23 2007-11-29 Kari Kaarela Bridging between AD HOC local networks and internet-based peer-to-peer networks
US20090207905A1 (en) * 2006-08-10 2009-08-20 Sony Corporation Communication processing device, data communication system, method, and computer program
US20080112405A1 (en) * 2006-11-01 2008-05-15 Chris Cholas Methods and apparatus for premises content distribution
US20100241748A1 (en) * 2006-12-29 2010-09-23 Prodea Systems , Inc. System and method for providing network support services and premises gateway support infrastructure
US20080235513A1 (en) * 2007-03-19 2008-09-25 Microsoft Corporation Three Party Authentication
US20090129301A1 (en) * 2007-11-15 2009-05-21 Nokia Corporation And Recordation Configuring a user device to remotely access a private network

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
Cox et al., On the Applications of Multimedia Processing to Communications, May 1998, IEEE Vol. 86, No. 5, Pages 755-824. *
Mehta et al., Reconfigurable Terminals: An Overview of Architectural Solutions, August 2001, IEEE Communications Magazine Pages 82-89 *

Cited By (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110035794A1 (en) * 2008-04-25 2011-02-10 Huawei Technologies Co., Ltd. Method and entity for authenticating tokens for web services
US9769137B2 (en) 2008-06-24 2017-09-19 Microsoft Technology Licensing, Llc Extensible mechanism for securing objects using claims
US20090320103A1 (en) * 2008-06-24 2009-12-24 Microsoft Corporation Extensible mechanism for securing objects using claims
US8990896B2 (en) * 2008-06-24 2015-03-24 Microsoft Technology Licensing, Llc Extensible mechanism for securing objects using claims
US8650631B2 (en) * 2009-03-13 2014-02-11 Juniper Networks, Inc. Server protection from distributed denial of service attacks
US20100235902A1 (en) * 2009-03-13 2010-09-16 Juniper Networks, Inc. Server protection from distributed denial of service attacks
US20110047596A1 (en) * 2009-08-21 2011-02-24 Verizon Patent And Licensing, Inc. Keystroke logger for unix-based systems
US8418227B2 (en) * 2009-08-21 2013-04-09 Verizon Patent And Licensing, Inc. Keystroke logger for Unix-based systems
CN102036228A (en) * 2009-09-29 2011-04-27 中兴通讯股份有限公司 Method and system for realizing terminal handover
CN102056287A (en) * 2009-11-05 2011-05-11 中兴通讯股份有限公司 Method and system for realizing identity and location separation based on network
WO2010145291A1 (en) * 2009-11-05 2010-12-23 中兴通讯股份有限公司 Method and system for realizing identifier and locator separation
US20140337958A1 (en) * 2009-12-29 2014-11-13 Akamai Technologies, Inc. Security framework for http streaming architecture
US9485238B2 (en) * 2009-12-29 2016-11-01 Akamai Technologies, Inc. Security framework for HTTP streaming architecture
US11831955B2 (en) * 2010-07-12 2023-11-28 Time Warner Cable Enterprises Llc Apparatus and methods for content management and account linking across multiple content delivery networks
US20210243501A1 (en) * 2010-07-12 2021-08-05 Time Warner Cable Enterprises Llc Apparatus and methods for content management and account linking across multiple content delivery networks
US8689004B2 (en) 2010-11-05 2014-04-01 Microsoft Corporation Pluggable claim providers
US20150326560A1 (en) * 2010-12-23 2015-11-12 Microsoft Technology Licensing, Llc Registration and network access control
US9432359B2 (en) * 2010-12-23 2016-08-30 Microsoft Technology Licensing, Llc Registration and network access control
US20130307785A1 (en) * 2011-01-27 2013-11-21 Panasonic Corporation Network control system, control apparatus, controlled apparatus, and apparatus control method
US9971417B2 (en) 2011-01-27 2018-05-15 Panasonic Intellectual Property Management Co., Ltd. Network control system, control apparatus, controlled apparatus, and apparatus control method
US9348427B2 (en) * 2011-01-27 2016-05-24 Panasonic Intellectual Property Management Co., Ltd. Network control system, control apparatus, controlled apparatus, and apparatus control method
US8656154B1 (en) * 2011-06-02 2014-02-18 Zscaler, Inc. Cloud based service logout using cryptographic challenge response
US20200120172A1 (en) * 2018-10-10 2020-04-16 NEC Laboratories Europe GmbH Method and system for synchronizing user identities
US11843675B2 (en) * 2018-10-10 2023-12-12 Nec Corporation Method and system for synchronizing user identities

Also Published As

Publication number Publication date
US8789149B2 (en) 2014-07-22

Similar Documents

Publication Publication Date Title
US9143493B2 (en) Method and apparatus for communicating between a user device and a gateway device to form a system to allow a partner service to be provided to the user device
US8789149B2 (en) Method and apparatus for communicating between a user device and a user device locating module to allow a partner service to be provided to a user device
US8453251B2 (en) Method and system for securely communicating between a user network device, a primary service provider and a partner service provider
US10951674B2 (en) Public/private communications paths
US7774487B2 (en) Method and apparatus for checking the health of a connection between a supplemental service provider and a user device of a primary service provider
EP2553566B1 (en) Authentication and authorization for internet video client
US9407852B2 (en) Method and system for providing program guide data from a content provider to a user device through a partner service provider based upon user attributes
US8200968B2 (en) Method and apparatus for communicating between a requestor and a user receiving device using a user device locating module
US20090125950A1 (en) Method and system for authenticating a user device
US8621646B2 (en) Method and system for authenticating a user receiving device into a primary service provider system to communicate with a partner service provider
US9137018B2 (en) Method and system for providing a generic program guide data from a primary content provider to a user network device through a partner service provider
US20090165088A1 (en) Method and system for providing a content list and content clips to a user network device through an intermediate web provider
US8745654B1 (en) Method and system for managing digital rights for content
US8533852B2 (en) Method and system for securely communicating between a primary service provider and a partner service provider
US9692602B2 (en) Method and apparatus for mutually authenticating a user device of a primary service provider
US9794239B1 (en) Method and system for authenticating service providers to communicate with a primary service provider
US9532007B2 (en) Method and system for remotely requesting recording at a user network device for a user recording system
US9838727B1 (en) Method and system for discovering an identity provider
US9854308B1 (en) Method and system for authorizing user devices to communicate with a primary service provider using a limited number of streams
US8806198B1 (en) Method and system for authenticating a request
WO2009134721A1 (en) Method and system for searching content at a primary service provider through a partner service provider
US9313532B1 (en) Method and system for securely performing callbacks in a content distribution system
US9654829B1 (en) Method and system for retrieving data from multiple sources

Legal Events

Date Code Title Description
AS Assignment

Owner name: THE DIRECTV GROUP, INC.,CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:CHAUDHRY, KAPIL;REEL/FRAME:021907/0550

Effective date: 20071219

Owner name: THE DIRECTV GROUP, INC., CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:CHAUDHRY, KAPIL;REEL/FRAME:021907/0550

Effective date: 20071219

STCF Information on status: patent grant

Free format text: PATENTED CASE

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 4TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1551)

Year of fee payment: 4

AS Assignment

Owner name: DIRECTV, LLC, CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:THE DIRECTV GROUP, INC.;REEL/FRAME:057018/0460

Effective date: 20210728

AS Assignment

Owner name: CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH, AS COLLATERAL AGENT, NEW YORK

Free format text: SECURITY AGREEMENT;ASSIGNOR:DIRECTV, LLC;REEL/FRAME:057695/0084

Effective date: 20210802

AS Assignment

Owner name: THE BANK OF NEW YORK MELLON TRUST COMPANY, N.A. AS COLLATERAL AGENT, TEXAS

Free format text: SECURITY AGREEMENT;ASSIGNOR:DIRECTV, LLC;REEL/FRAME:058220/0531

Effective date: 20210802

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 8TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1552); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

Year of fee payment: 8

AS Assignment

Owner name: THE BANK OF NEW YORK MELLON TRUST COMPANY, N.A., AS COLLATERAL AGENT, TEXAS

Free format text: SECURITY AGREEMENT;ASSIGNOR:DIRECTV, LLC;REEL/FRAME:066371/0690

Effective date: 20240124