Patent Grant
9143493
The present disclosure relates generally to communication systems having a primary service provider and a supplemental service provider, and more particularly, to a method and system for establishing communication between a user device and a gateway device so that communication between the user device or partner service provider may be performed.
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.
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. The partner service provider is enabled to communicate various services to users of the primary service provider.
In one aspect of the invention, a method of configuring a port of a gateway device includes restarting or rebooting a user receiving device, communicating a multicast packet to the gateway device, communicating a port forwarding status to the user receiving device from the gateway device, locating an open port at the gateway device in response to the port forwarding status, communicating an open port signal from the gateway device to the user receiving device indicating an open port on the gateway device and listening to the open port from the user receiving device.
In a further aspect of the invention, a method includes configuring a port of a gateway device to communicate with a user receiving device, registering the user receiving device with a locator module through the port, determining the location of a user receiving device from a partner service using the locator module and forming a peer-to-peer connection between the partner service provider and the user receiving device.
In yet another aspect of the invention, a system includes a user receiving device, a user device locator module and a gateway device having a port configured to communicate with a user receiving device. The user receiving device registers with the user device locator module through the port. The user device locator module determines the location of a user receiving device. The partner service provider and the user receiving device form a peer-to-peer connection in response to the location data.
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.
The drawings described herein are for illustration purposes only and are not intended to limit the scope of the present disclosure in any way.
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
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
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
The partner service provider 80 may include the program guide cache 84 as set forth above. The cache 84 is illustrated in
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
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
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
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
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
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
Referring now to
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
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
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
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
Referring now to
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
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
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
Referring now to
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
Referring to both
Referring now to
Referring now to
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
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
Referring now to
In step 1814, authentication of the identity of the requester 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 requester is not authenticated using the eToken, step 1818 generates an error message. In step 1816, if the requester is authenticated, step 1820 determines whether the requester 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 requester 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 requester. In addition, the user receiving device may receive primary service data or signals.
Referring now to
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.
| Number | Name | Date | Kind |
|---|---|---|---|
| 4322745 | Saeki et al. | Mar 1982 | A |
| 4694490 | Harvey et al. | Sep 1987 | A |
| 5301245 | Endoh | Apr 1994 | A |
| 5421031 | De Bey | May 1995 | A |
| 5442389 | Blahut et al. | Aug 1995 | A |
| 5506902 | Kubota | Apr 1996 | A |
| 5544161 | Bigham et al. | Aug 1996 | A |
| 5701582 | DeBey | Dec 1997 | A |
| 5734853 | Hendricks et al. | Mar 1998 | A |
| 5878141 | Daly et al. | Mar 1999 | A |
| 5917481 | Rzeszewski et al. | Jun 1999 | A |
| 6115074 | Ozkan et al. | Sep 2000 | A |
| 6175362 | Harms et al. | Jan 2001 | B1 |
| 6229540 | Tonelli et al. | May 2001 | B1 |
| 6253375 | Gordon et al. | Jun 2001 | B1 |
| 6289314 | Matsuzaki et al. | Sep 2001 | B1 |
| 6289455 | Kocher et al. | Sep 2001 | B1 |
| 6381747 | Wonfor et al. | Apr 2002 | B1 |
| 6424717 | Pinder et al. | Jul 2002 | B1 |
| 6510519 | Wasilewski et al. | Jan 2003 | B2 |
| 6519693 | Debey | Feb 2003 | B1 |
| 6529680 | Broberg | Mar 2003 | B1 |
| 6543053 | Li et al. | Apr 2003 | B1 |
| 6574795 | Carr | Jun 2003 | B1 |
| 6636966 | Lee et al. | Oct 2003 | B1 |
| 6748080 | Russ et al. | Jun 2004 | B2 |
| 6792618 | Bendinelli et al. | Sep 2004 | B1 |
| 6801528 | Nassar | Oct 2004 | B2 |
| 6816596 | Peinado et al. | Nov 2004 | B1 |
| 6824051 | Reddy et al. | Nov 2004 | B2 |
| 6839757 | Romano et al. | Jan 2005 | B1 |
| 6885660 | Inbar et al. | Apr 2005 | B2 |
| 6889208 | Okabe et al. | May 2005 | B1 |
| 6934963 | Reynolds et al. | Aug 2005 | B1 |
| 6961858 | Fransdonk | Nov 2005 | B2 |
| 6983319 | Lu et al. | Jan 2006 | B1 |
| 6993499 | Gagnon et al. | Jan 2006 | B2 |
| 6993782 | Newberry et al. | Jan 2006 | B1 |
| 7003791 | Mizutani | Feb 2006 | B2 |
| 7016498 | Peinado et al. | Mar 2006 | B2 |
| 7027460 | Iyer et al. | Apr 2006 | B2 |
| 7032236 | Ozkan et al. | Apr 2006 | B1 |
| 7035827 | Ezaki | Apr 2006 | B2 |
| 7054447 | Price, III | May 2006 | B1 |
| 7069312 | Kostic et al. | Jun 2006 | B2 |
| 7073073 | Nonaka et al. | Jul 2006 | B1 |
| 7137006 | Grandcolas et al. | Nov 2006 | B1 |
| 7191335 | Maillard | Mar 2007 | B1 |
| 7194757 | Fish et al. | Mar 2007 | B1 |
| 7194759 | Chess et al. | Mar 2007 | B1 |
| 7203311 | Kahn et al. | Apr 2007 | B1 |
| 7327931 | Frantz | Feb 2008 | B2 |
| 7356584 | Yip | Apr 2008 | B2 |
| 7370342 | Ismail et al. | May 2008 | B2 |
| 7496540 | Irwin et al. | Feb 2009 | B2 |
| 7546623 | Ramraz et al. | Jun 2009 | B2 |
| 7668838 | Baio et al. | Feb 2010 | B2 |
| 7895341 | Schlacht et al. | Feb 2011 | B2 |
| 8001565 | Kahn et al. | Aug 2011 | B2 |
| 8295268 | Tanaka et al. | Oct 2012 | B2 |
| 8364823 | Cromwell et al. | Jan 2013 | B2 |
| 20010037452 | Go et al. | Nov 2001 | A1 |
| 20010047516 | Swain et al. | Nov 2001 | A1 |
| 20020019984 | Rakib | Feb 2002 | A1 |
| 20020026640 | Graan | Feb 2002 | A1 |
| 20020026643 | Ewen et al. | Feb 2002 | A1 |
| 20020051539 | Okimoto et al. | May 2002 | A1 |
| 20020054752 | Wood et al. | May 2002 | A1 |
| 20020056118 | Hunter et al. | May 2002 | A1 |
| 20020067914 | Schumann et al. | Jun 2002 | A1 |
| 20020095679 | Bonini | Jul 2002 | A1 |
| 20020198846 | Lao | Dec 2002 | A1 |
| 20030031184 | Cunetto et al. | Feb 2003 | A1 |
| 20030037006 | Maruyama et al. | Feb 2003 | A1 |
| 20030046702 | Sasaki | Mar 2003 | A1 |
| 20030066884 | Reddy et al. | Apr 2003 | A1 |
| 20030095791 | Barton et al. | May 2003 | A1 |
| 20030121047 | Watson et al. | Jun 2003 | A1 |
| 20030163684 | Fransdonk | Aug 2003 | A1 |
| 20030167392 | Fransdonk | Sep 2003 | A1 |
| 20030188316 | DePrez | Oct 2003 | A1 |
| 20030212997 | Hejna, Jr. | Nov 2003 | A1 |
| 20040034771 | Edgett et al. | Feb 2004 | A1 |
| 20040039905 | Leoutsarakos | Feb 2004 | A1 |
| 20040049796 | Briggs | Mar 2004 | A1 |
| 20040078828 | Parchman et al. | Apr 2004 | A1 |
| 20040083487 | Collens et al. | Apr 2004 | A1 |
| 20040117430 | Bazot et al. | Jun 2004 | A1 |
| 20040139228 | Takeda et al. | Jul 2004 | A1 |
| 20040139480 | Delpuch et al. | Jul 2004 | A1 |
| 20040177369 | Akins, III | Sep 2004 | A1 |
| 20040233897 | Yamaguchi et al. | Nov 2004 | A1 |
| 20040237100 | Pinder et al. | Nov 2004 | A1 |
| 20040250293 | Ryal et al. | Dec 2004 | A1 |
| 20050050333 | Yeap et al. | Mar 2005 | A1 |
| 20050055724 | Atad et al. | Mar 2005 | A1 |
| 20050066353 | Fransdonk | Mar 2005 | A1 |
| 20050086173 | Kalwit | Apr 2005 | A1 |
| 20050086683 | Meyerson | Apr 2005 | A1 |
| 20050102506 | Pica et al. | May 2005 | A1 |
| 20050125540 | Szu et al. | Jun 2005 | A1 |
| 20050152287 | Yokomitsu et al. | Jul 2005 | A1 |
| 20050235361 | Alkove et al. | Oct 2005 | A1 |
| 20050262573 | Bo et al. | Nov 2005 | A1 |
| 20060031472 | Rajavelu et al. | Feb 2006 | A1 |
| 20060036847 | Bush et al. | Feb 2006 | A1 |
| 20060037037 | Miranz | Feb 2006 | A1 |
| 20060046744 | Dublish et al. | Mar 2006 | A1 |
| 20060056397 | Aizu et al. | Mar 2006 | A1 |
| 20060117342 | Park et al. | Jun 2006 | A1 |
| 20060120309 | Bigras et al. | Jun 2006 | A1 |
| 20060168663 | Viljoen et al. | Jul 2006 | A1 |
| 20060174127 | Kalavade et al. | Aug 2006 | A1 |
| 20060179489 | Mas Ribes | Aug 2006 | A1 |
| 20060195881 | Segev et al. | Aug 2006 | A1 |
| 20060218620 | Nadarajah et al. | Sep 2006 | A1 |
| 20060242322 | Williams et al. | Oct 2006 | A1 |
| 20070021053 | Marrah | Jan 2007 | A1 |
| 20070100701 | Boccon-Gibod et al. | May 2007 | A1 |
| 20070124602 | Wald et al. | May 2007 | A1 |
| 20070130286 | Hopmann et al. | Jun 2007 | A1 |
| 20070160142 | Abrams | Jul 2007 | A1 |
| 20070160198 | Orsini et al. | Jul 2007 | A1 |
| 20070162748 | Okayama et al. | Jul 2007 | A1 |
| 20070214103 | Manthoulis | Sep 2007 | A1 |
| 20070217434 | Welbourn | Sep 2007 | A1 |
| 20070233879 | Woods et al. | Oct 2007 | A1 |
| 20070240193 | Sie et al. | Oct 2007 | A1 |
| 20070265970 | Kahn et al. | Nov 2007 | A1 |
| 20070266026 | Aravamudan et al. | Nov 2007 | A1 |
| 20070274327 | Kaarela et al. | Nov 2007 | A1 |
| 20080098450 | Wu et al. | Apr 2008 | A1 |
| 20080112405 | Cholas et al. | May 2008 | A1 |
| 20080235513 | Foster et al. | Sep 2008 | A1 |
| 20080256615 | Schlacht et al. | Oct 2008 | A1 |
| 20080289009 | Lee et al. | Nov 2008 | A1 |
| 20090059945 | Yokomitsu et al. | Mar 2009 | A1 |
| 20090094317 | Venkitaraman | Apr 2009 | A1 |
| 20090129301 | Belimpasakis | May 2009 | A1 |
| 20090207905 | Tomita | Aug 2009 | A1 |
| 20090216623 | Hendricks et al. | Aug 2009 | A1 |
| 20100175092 | Kikinis et al. | Jul 2010 | A1 |
| 20100180322 | Finn et al. | Jul 2010 | A1 |
| 20100241748 | Ansari et al. | Sep 2010 | A1 |
| Number | Date | Country |
|---|---|---|
| 1176826 | Jan 2002 | EP |
| 1176827 | Jan 2002 | EP |
| 9918729 | Apr 1999 | WO |
| 2007074359 | Jul 2007 | WO |
| Entry |
|---|
| WanDevice:1 Device Template Version 1.01 for UPnP Version 1.0, Nov. 12, 2001, by Ulhas Warrier and Prakash Iyer. |
| Selen: UPnP security in Internet gateway devices, 2006. retrieved from http://www.tml.tkk.fi/Publications/C/21/Selen—ready.pdf. |
| Secure Socket Layer (SSL), 2000, retrieved from http://searchsecurity.techtarget.com/definition/Secure-Sockets-Layer-SSL. |
| Fiedler et al., Reliable VoIP services using a peer-to-peer Intranet, proceedings of the Eight IEEE International Symposium on Multmedia (ISM'06). |
| WANIPConnection:1 Service template version 1.01 for UPnp, Nov. 2001. |
| Foldoc definition of HTTP. |
| UpnP-hacks, http://www.upnp-hacks.org/igd.html, 2006-2011. |
| Pennerath, Frederic; Marynissen, Gert; “WANConnectionDevice:1 Device Template Version 1.01”; UPNP Forum; Nov. 12, 2001; XP002521778; retrieved from the Internet: URL:http://www.upnp.org/standardizeddcps/documents/UPnP—IGD—WANDevice%201.0.pdf; Section 2.4.16. |
| Contributors: Allegro Software Development Corporation, Conexant Systems, Inc., Intel Corporation, Microsoft Corporation, Motorola, Nokia Corporation, Philips Electronics, Pioneer, Sony Electronics; “UPnP Device Architecture 1.0”; UPNP Forum; Jul. 20, 2006; XP002521777; retrieved from the Internet: URL:http://www.upnp-ic.org/resources/UPnP—device—architecture—docs/UPnP-DeviceArchitecture-v1—0-20060720.pdf; p. 3, lines 8-18. |
| Vogel, Hans-Jorg; Weyl, Benjamin; Eichler, Stephan; “Federation Solutions for Inter-and Intradomain Security in Next-Generation Mobile Service Platforms”; AEU International Journal of Electronics and Communications; Elsevier, Jena, DE; vol. 60, No. 1; Jan. 2, 2006; pp. 13-19; XP025183729; ISSN: 1434-8411 [retrieved on Jan. 2, 2006]; Section 3. |
| International Search Report and Written Opinion dated Apr. 22, 2009 in International Application No. PCT/US2008/087665 filed Dec. 19, 2008 by Kapil Chaudhry. |
| Cox, Richard V. et al.; “Scanning the Technology—On the Applications of Multimedia Processing to Communications”; May 1998; IEEE vol. 86, No. 5; pp. 755-824. |
| Mehta, Mehul et al.; “Reconfigurable Terminals: An Overview of Architectural Solutions”; Aug. 2001; IEEE Communications Magazine; pp. 82-89. |
| White, Ron; “How Computers Work”; Millennium Edition, 1999; Que Corporation; Indianapolis, Indiana, US; all pages. |
| Derfler, Frank J., Jr. and Freed, Les; “How Networks Work”; Bestseller Edition, 1996; Ziff-Davis Press; Emeryville, California, US; all pages. |
| Gralla, Preston; “How the Internet Works”; Millenium Edition, 1999; Que Corporation; Indianapolis, Indiana, US; all pages. |
| Muller, Nathan J.; “Desktop Encyclopedia of the Internet”; 1999; Artech House, Inc.; Norwood, Massachusetts, US; all pages. |
| Tsubakiyama, Hideki and Koga, Keiichiro; “Security for Information Data Broadcasting System with Conditional-Access Control”; IEEE; 1993; pp. 164-170. |
| Ebu Project Group B/CA; “Functional Model of a Conditional Access System”; EBU Technical Review; Jun. 10, 1995; pp. 64-77. |
| Ma, Huang and Shin, Kang G.; “Multicast Video on Demand Services”; ACM SIGCOMM Computer Communications Review; vol. 32, Issue 1; Jan. 2002; pp. 31-43; ACM Press; New York, New York, US. |
| Tantaoui, Mounir A.; Hua, Kien A.; Sheu, Simon; “Interaction with Broadcast Video”; International Multimedia Conference Proceedings of the 10th ACM International Conference on Multimedia; pp. 29-38; ACM Press; New York, New York, US; 2002 ISBN: 1-58113-620-X. |
| Griwodz, Carsten; Merkel, Oliver; Dittmann, Jana; Steinmetz, Ralf; “Protecting VoD the Easier Way”; International Multimedia Conference Proceedings of the 6th ACM International Conference on Multimedia; pp. 21-28; ACM Press; New York, New York, US; 2002 ISBN: 0-201-30990-4. |
| Anonymous; “PKCS #1 v2.1: RSA/Cryptography Standard”; Jun. 14, 2002; RSA Laboratories; 61 pages. |
| Number | Date | Country | |
|---|---|---|---|
| 20090164579 A1 | Jun 2009 | US |
