Methods and device for data exchange

FIELD: radio engineering.

SUBSTANCE: for authentication of data exchange, identifier of decoder receiver is used, based on number of smart-card and gate is used, made with possible receipt of data from receiver-decoder, which are sent via non-network protocol and transformation of these data to inter-network protocol for their following transfer to internet service provider.

EFFECT: higher efficiency.

2 cl, 10 dwg

The present invention relates to a method and device for exchanging data between the user device such as a receiver-decoder, and a remote device, which may be, for example, the system of accounting records for the use of the Internet or the provider of Internet services.

Receiver-decoders are used for receiving and/or decoding signals such as television signals that can be transmitted in analog or digital form. In the case of digital transmission digital channels are encoded in the digital data stream at the transmitter side and decoded on the receiver side by using a receiver-decoder, which can either be found in the digital set-top box for TV (DSTB), or integrated TV. In the case of analog transmission at the subscriber may be used by the receiver-decoder for converting the transmitted signals into a format that can be displayed on the TV screen.

Receivers-decoders typically have a processor that can execute programs, called application. An example of an application that can be executed on the receiver-decoder is an application to access the Internet, which can provide the subscriber access to the Internet with this receiver-decoder.

To reduce the cost of receivers-decoders is x design strive to simplify. Because of this, it can be difficult if you want to use the receiver-decoder to communicate with a remote network such as the Internet. In particular, connecting to the Internet requires the use of internetwork protocols and authentication that may be difficult to achieve in relation to the receiver-decoder. For example, some receivers-decoders may not be able to return data in a format suitable for direct connection to the Internet. Such receivers-decoders are referred to as non-IP-enabled".

According to the first aspect of the present invention proposes a method of authenticating communication between a receiver-decoder and a remote server to provide access to a network, including the use of authentication data exchange some ID mentioned receiver-decoder, and the said identifier based on the identifier used to access broadcast services.

Through the use of the present invention, the authentication communication between the receiver-decoder and a remote server may be based on a unique identifier of the receiver-decoder already have this receiver decoder that can reduce the requirements to the receiver-decoder. Receivers-decoders cha is the fact supply a unique identifier for access to the broadcast services, and this ID is a convenient tool to identify the receiver-decoder.

Preferably the said identifier is stored on a removable component, such as a smart card.

Preferably the said identifier independent from the registration identifier for the network logon (login). Due to this, the receiver-decoder can be simplified, since the above identity can be easier than the registration ID to log in to the network, which usually is a complex multi-character identifier, to facilitate learning by the user. Another drawback of the registration IDs is that they can from time to time to change or for access to different services may require more than one identity; the present invention can provide the capability of associating (remote server) of a single identifier transmitted by the receiver-decoder ID for the network, which may change or multiple identifiers for the network. This feature of the present invention can be implemented independently.

Preferably the said identifier is based on a certain number, unique for each smart card. The term "smart card", as used in this tech is those covers, but not limited to, any card device on the basis of chip, or an object with similar purpose and performance, and is equipped with, for example, a microprocessor and/or memory device. This term also covers devices with non-card physical form, such as a device in the form of a key, similar to those often used in television systems using decoders.

Mentioned the remote server may be a server to access the Internet, or it can be system of accounting records for the use of the Internet or a server of any other type, for example, to access a remote network of any type.

Using the above-mentioned identifier of the receiver-decoder system of maintaining accounts for the use of the Internet can create a user account to use the Internet. To create the account mentioned the identifier can be compared with the system of accounting records for the use of the Internet with the saved list of IDs of the receivers-decoders, which can create accounts to use the Internet.

Mentioned the remote server may include means for data transmission to the provider of Internet services, and the proposed method to include grant given what's mentioned account for the use of the Internet provider of Internet services, for the organization between the receiver-decoder and provider of Internet services, bidirectional data transmission channel.

The above-mentioned identifier may be accompanied by data that identifies the data channel, which should be used for data transmission between the receiver-decoder and a remote server. Thus, the receiver-decoder can set the data transmission channel, which should be used for data transmission; for example, as a reverse channel can be used with satellite channel.

In one preferred embodiment of the present invention, the registration data (login) have the following form:

login={the number of smart cards} {the type of services},

where "type of service" (type of service - TOS) can determine the channels through which should result in the transfer of data, for example, pointing to the case when the responses of some type to the subscriber terminal must transmit the satellite.

In one preferred embodiment of the present invention mentioned the remote server provides the receiver-decoder network access, with some network protocols, and data generated by the receiver-decoder is converted into data compatible with said network protocols, in a location remote from the receiver-decoder. Thus, the receiver-decoder, to the of which is not provided with the aforementioned network protocols, it may, however, communicate with the said network. Mentioned the network may be, for example, the Internet, and the network Protocol may be, for example, TCP/IP. Mentioned the remote location may, for example, be located at the operator, who may be keeping system of accounts for use of the Internet.

Preferably, said data is converted in the above-mentioned compatible with network protocols data gateway, located between the said receiver-decoder and a remote server.

In one preferred embodiment of the present invention mentioned above, the network includes multiple remote devices, and said converted data is sent to the mentioned gateway in one of these remote devices specified in the above-mentioned data, providing a data transmission channel between the receiver-decoder and the specified remote device.

According to the second aspect of the present invention proposes a method of transmitting data from a supporting namiseeve Protocol user terminal in one of the many supporting Internet Protocol remote devices, including data transfer operations using nemislevme Protocol of the mentioned user terminal to the gateway, and mentioned data is e include a message and specify the addressee of this message, from among the aforementioned multiple remote devices, conversion of such data in the above-mentioned gateway in the data, using the aforementioned Protocol, and transmission of such data, using the aforementioned Protocol, referred gateway to the specified remote device destination, providing a data transmission channel between the said user's terminal and the specified remote device. The mentioned user terminal may be a receiver-decoder.

It is also proposed a method for exchanging data between the receiver-decoder and the remote network in which the protocols necessary to communicate with said remote network, implemented in some remote from the receiver-decoder.

From the receiver-decoder to the gateway using nemislevme Protocol can be sent a message that triggers the closing of the above-mentioned data transmission channel, and the above-mentioned gateway, in turn, reports to the specified remote device a closing command, using the aforementioned Protocol. Preferably, before the above-mentioned data transmission channel gateway performs authentication of the identity of the receiver-decoder.

According to a third aspect of the present invention a device for authenticating communication between a receiver-de the Oder and the remote server to provide access to some network, contains a tool (e.g., system, server, or gateway) to use for authentication communicate some ID mentioned receiver-decoder, and the said identifier based on the identifier used to access broadcast services. The above-mentioned identifier may be accompanied by data that identifies the data channel, which should be used for data transmission between the receiver-decoder and a remote server.

Mentioned the remote server may provide the receiver-decoder network access, with some network protocols, while the proposed device can include means (e.g., system, server, or gateway) to transform the data generated by the receiver-decoder, the data compatible with said network protocols.

Preferably the proposed device is a gateway located between the said receiver-decoder and a remote server.

Preferably the said network includes many remote devices and said gateway is arranged to transfer referred to the converted data to one of the mentioned multiple remote devices specified in the above-mentioned data, providing a data transmission channel between the receiver-decoder and the specified deletion is authorized by the device.

According to a fourth aspect of the present invention offers a gateway to transfer data received from the supporting namiseeve Protocol user terminal, in one of the many supporting Internet Protocol remote devices containing

the tool (e.g., input) for receiving transmitted from the above-mentioned user terminal using nemislevme Protocol data comprising a message indicating the recipient of this message from among the aforementioned multiple remote devices;

the tool (e.g., Converter) to convert the received data in the data using the aforementioned Protocol; and

the tool (e.g., output) to transfer such data using the aforementioned Protocol, the specified remote device destination, providing a data transmission channel between the said user's terminal and the specified remote device.

The proposed gateway can have multiple ports, I / o, each of which is intended for connection with the corresponding remote device.

The proposed gateway may include a means (e.g., a recognition device for recognition of a certain message from the user terminal initiating akrita mentioned data transmission channel; and means (e.g., output) to send close command to the specified remote device.

According to the present invention a method and apparatus essentially as described with reference to figures of the drawings, and illustrates them.

The features of one aspect may be applied to other aspects; similarly, the characteristics of the methods can be applied to aspects of the device, and Vice versa.

Below will be described the preferred features of the present invention, solely as an example and with reference to the figures of drawings, on which:

figure 1 - architecture of a typical digital television system;

figure 2 - schematic representation of the receiver-decoder;

figure 3 - system access to the Internet in General;

figure 4 - software level of the user equipment shown in Fig 3;

5 is a system architecture access to the Internet; and

6 - the basic elements of the system for maintenance of accounts for use of the Internet;

Fig.7 - part system configuration access to the Internet when the receiver-decoder is not IP-enabled;

Fig - Protocol levels of the system shown in Fig.7;

figure 9 schematically illustrates the Protocol used to exchange data between the user equipment and a gateway in the system shown in Fig.7; and

figure 10 schematically illustrates the Protocol used to exchange data between the user equipment and a gateway in the system shown in Fig.7, when performing the authentication.

Figure 1 shows a system 1 for digital television in General. In the present invention is mainly used conventional system 2 digital television, in which to transmit compressed digital signals applied compression system MPEG-2. Specifically, MPEG-2 compressor 3 in the broadcast center receives a stream of digital signals (typically a stream of video signals). The compressor 3 is connected to the MUX-scrambler 4 by connecting 5.

The multiplexer 4 receives many additional input signals, assembles transport stream and transmits the compressed digital signals in the transmitter 6 of the broadcast center via a connection 7, which, of course, can take a wide variety of forms, including telecommunication links. The transmitter 6 transmits electromagnetic signals on channel 8 "Earth-satellite to satellite transponder 9, where they are processed by electronic means; from there they are transmitted by broadcast virtual channel 10 "satellite-to-Ground terrestrial receiver 12, usually in the form of plates, owned or leased by the end user. Possible, of course, other transport channels for lane is giving data such as a network of terrestrial broadcasting, cable transmission, the combined cable and satellite connection, telephone network, etc.

The signals received by the receiver 12, are transmitted in a combined receiver-decoder 13, owned or leased by the end user and is connected to the TV 14 end user. The receiver-decoder 13 decodes the compressed MPEG-2 signal in the television signal to the television 14. Although figure 1 receiver-decoder is shown as a separate unit, it can be part of an integrated digital TV. The term "receiver-decoder as used in this paper covers both the separate receiver-decoder, such as a set-top box for TV (STB)and TV with a built-in receiver-decoder.

In a multichannel system, the multiplexer 4 handles audio and video information received from multiple sources, and communicates with the transmitter 6 to broadcast this information on the appropriate number of channels. In addition to audio-visual information in some or all of these channels can be entered messages, or applications, or digital data of any other kind, interspersed with the transmitted digital audio and video information.

To the multiplexer 4 and the receiver-decoder 13 is connected, the system 15 is conventionally what about access posted by partially in the broadcast center, and part of the decoder. It allows the end user to access the digital TV of one or more providers of broadcasting. In the receiver-decoder 13 can be mounted smart card is able to interpret the messages related to the commercial offerings (i.e. to one or more television programs that are sold by the provider of the broadcast). Using the decoder 13 and the smart card end-user can buy a commercial offer or subscription mode or in the mode of payment for a view (PPV-mode).

As mentioned above, given by the system program scribblenauts multiplexer 4, and the parameters and encryption keys used to this particular transfer, determined by the system 15 conditional access. Transmission of scrambled data in this manner is well known in the field of pay-TV. Usually scrambled data is transmitted together with the control word destined for diskriminirovaniya these data, and self control word is encrypted by using the so-called working key and transmitted in encrypted form.

Mentioned scrambled data and the encrypted control word is then accepted by the decoder 13, having access to the equivalent mentioned what about the working key, stored on a smart card installed in the decoder to decrypt the encrypted control word and then descrambling the transferred data. Paid for a subscription, the subscriber will receive, for example, passed on this month EMM (message control rights, or communication access control), a work key for decoding the encrypted control word, which, in turn, is necessary for watching.

Interactive system 16, also connected to the multiplexer 4 and the receiver-decoder 13 and also placed partially in the broadcast center, and part of the decoder allows the end user to communicate interactively with various applications via modem back channel 17. This modem back channel may also be used for messaging system 15 conditional access.

To load data, use the physical interfaces of the receiver-decoder 13. As shown in figure 2, the receiver-decoder 13 includes, for example, six devices to download data: serial interface 30, a parallel interface 32, a modem 34, the two devices 36 card reader and the tuner 38 MPEG stream.

The system of the broadcasting and reception is also used to provide Internet services, such as viewing Web pages (Web browsing) and electronic is electronic mail. Performed by the receiver-decoder 13, the application allows the receiver-decoder to access Internet services and display Web pages and e-mail messages or on the TV 14, or through a computer connected to the receiver-decoder 13.

With reference to figure 3 below will be in the General form described system of access to the Internet. Equipment 20 user (which includes a receiver-decoder) is connected with the operator 22 via the public switched telephone network 24 (PSTN). The user equipment transmits to the operator 22 a transfer request in specific data, for example, certain Web pages or e-mail. The operator takes the request and passes it to the Internet service provider (ISP) 26. In response to this request, the ISP provides the operator with an answer that may contain the requested Web page, retrieved from the Internet 27, or e-mail message available for this subscriber from an ISP. The operator transmits the response to the center 28 of broadcasting, where it is introduced into the MPEG bit-stream, for example, in the form of private section shall be transmitted by the transmitter 6 and received by the receiver 12, as described above. In the case when the receiver-decoder is "IP-enabled", i.e. provided with a Protocol for receiving data from the Internet, information can be transmitted as an IP frame bitstream MPEG, i.e. in the IP format. If the receiver-decoder is not what is "IP-enabled", then the data is transmitted in some other way, such as MPEG private section. Equipment 20 user retrieves the response from the MPEG bit-stream and displays it on the TV or connected to the computer monitor. Alternatively, the response can be transmitted to the equipment 20 user through the PSTN 24.

Figure 4 shows the software level equipment 20 of the user. The application tier contains the Web browser and the application for e-mail (mail program), which can be used in standard applications, such as Netscape or Microsoft Internet Explorer and Outlook Express, or any application specifically designed to run on the receiver-decoder. Under the application level are the HTTP level, sockets, TCP/IP level, PPP/SLIP-level and driver level. The level of modified drivers, differing from the browser in the usual way running on a PC, the fact that it is divided into the modem driver for communication with the PSTN 24 via modem user equipment, and driver tuner for data exchange via the tuner 4028 for receiving the MPEG stream.

You can use equipment 20 different user configurations. In one of the configurations of the PC is not used, and all the user software running on the receiver Deco the ore 13. In this configuration, the receiver-decoder 13 is associated with the PSTN 24 or via an internal modem or external modem and serial port. The receiver-decoder 13 can take online answers in the bit stream received from the ground receiver 12. A user interface for user interaction and system) is operated by remote control or keyboard, as well as a TV, connected to the receiver-decoder 13. In this configuration, TCP/IP level, as shown in figure 4, may be absent, and in this case, the required protocols are implemented by a gateway that is hosted by the operator, as will be described below.

In another configuration provides personal computer (PC), a parallel port which is connected to the parallel port 32 of the receiver-decoder 13 (or, alternatively, a serial port which is connected to the serial port 30 of the receiver-decoder 13). In this case, the upper software layers, shown in figure 4, are performed on the PC, and the remaining lower software levels are performed on the receiver-decoder 13. The user interface is provided by a keyboard and monitor connected to the PC.

In another configuration of the PC connected to the PSTN 24 through its internal or external modem. In this configuration, the receiver-decoder 13 may and the ot view of a single device, or may be represented by an expansion card or a removable card for a PC that is connected to the ISA bus or PCI.

Figure 5 presents the system architecture of access to the Internet. As shown in figure 5, the system of accounting records for the use of the Internet (IAMS - Internet account management system 50 is connected to the Internet service provider (ISP) 26, which provides services such as browsing and e-mail. IAMS 50 is also connected to the control system subscribers (SMS) 60 managing subscribers and transmitting in IAMS requested to provide or deny access to Internet services. The receiver-decoder 13 is connected with IAMS via internal modem, switched telephone network (PSTN) 24, server 56 network access storage (NAS) gateway 58.

SMS is also connected to the validation system subscribers (SAS) 61, permitting and processing orders subscribers to the broadcast services, such as broadcast television services. SMS operates in parallel with the systems SAS and IAMS and ensures the consistency of these two systems. The exchange of information between SMS and SAS and SMS and IAMS is done using TCP/IP connections, real-time, using command files.

Gateway 58 allows users to access Internet services in real-time. Such services include e-mail services to send the Cai and receive email and other services which may be provided ISP 26, as well as supporting service user and service reminders provided by the system IAMS. From the point of view of its functions, the gateway 58 is a message router, making possible the exchange of data between various systems using a single modem connection. In those cases, when the receiver-decoder does not have TCP/IP to communicate with the ISP, this gateway also implements the protocols required by the receiver-decoder to communicate with the ISP. In this case, the receiver-decoder 13 is associated with the ISP through the gateway 58, as shown by line 59 figure 5. If the receiver-decoder equipped with the necessary protocols, communication with the ISP directly, as shown in figure 5 by the dotted line 57. The gateway includes a server communication Manager e-mail (e-mail dispatcher).

The interface 66 ISP allows you to duplicate (copy) each change in the user account, which occurs in IAMS, a user account from an ISP 26 responsible for the hosting of Internet services, such as postal service. It should be noted that all information relating to the accounts of subscribers to use the Internet, centralized in IAMS, which is responsible for managing TV and Internet settings. IAMS also manages communication between the Internet settings and TV settings, interacting with the control system is placed subscribers (SMS) 60. SMS 60 controls the rights of subscribers and passes IAMS requests, requesting the provision of subscribers ' rights to access or refusal to subscribers to access Internet services.

In order to create an account in the system IAMS, the first subscriber receiver-decoder 13 passes in IAMS 50 request for a new account, together with such information as the requested e-mail address, and the selected settings. IAMS checks whether the number of the smart card in the list of smart card received from a system subscriber management (SMS) 60 corresponding to the subscribers, which can be opened accounts for the use of the Internet. Then IAMS passes in ISP prompted to create an account to use the Internet. After creating an account ISP returns in IAMS confirmation and password. Initially, the password is defined SMS, but later it can be changed by the subscriber. Account data IAMS (password, e-mail address and Internet settings) are stored in IAMS together with the number of the smart card of the subscriber. IAMS informs the subscriber about the fact that he created the account. After that, the subscriber can send the mail to the mail server 28 and receive mail from it.

Figure 6 shows the basic elements of IAMS. The main functions of IAMS are the following:

- maintain and support center is savannaha list of mail accounts bound to the parameters of the subscribers, such as a smart card;

- the granting of rights of access or denial of access to Internet services to the subscriber upon request SMS;

- account settings to use the Internet at the request of subscribers (subscribers);

service reminders, in which the e-mail user can write (outline) any event and get a reminder about it through e-mail messages at the time of occurrence of this event;

service copy allows you to copy the updated content IAMS in the appropriate server, such as the ISP.

In the center of the IAMS system is the relational database management (RDBMS) 70 containing information about subscribing to Internet services and email accounts stored in your device 72 data storage. The interface 74 to communicate with the SMS provides the ability to transfer information between IAMS and SMS, so that IAMS can be supplied with fresh information about subscribers who have been granted access to postal services, or who have been denied such access. The server 76 support allows a subscriber to access their email account and change it according to your preferences. The server 78 reminders gives the subscriber the opportunity to work with a list of events. The event privative who is to mail subscriber account. The subscriber can record any event and you will receive an automatic reminder for a certain pre-specified number of days prior to this event through an automatically generated e-mail messages. The interface 84 to communicate with the system notification e-mail system provides a notification e-mail (EMNS) 62 the ability to find custom settings related to user notification, RDBMS 70 system IAMS, to send notification messages via satellite (OTA). The auxiliary server 80 allows the administrator to check the status of a subscriber or user e-mail in IAMS. The server 82 copy copies the updated content RDBMS 70 system IAMS in the system of maintaining accounts provider of Internet services.

Requests sent in IAMS from the receiver-decoder 13, are sent by the gateway 58 in the corresponding part IAMS, such as server support (for mail accounts) and the server reminders (for reminders).

The above system of access to the Internet allows providers of broadcasting services to also provide Internet services. The operator of such system maintains and supports account to use the Internet regardless of the Internet service providers-the servants, so it is not tied to any particular provider of Internet services. By linking subscription broadcasting services and subscriptions to Internet services with each other it is possible to combine the processing of accounts for the services of these two species and management that can reduce the amount of required calculations in comparison with the case where the accounts are maintained separately, the subscriber may be combined account for these two services.

In more detail, the system IAMS described in concurrently pending application entitled "Internet Subscriber Management " and filed on behalf of the applicant of the present application, the contents of which are incorporated in this application by reference. System notification e-mail described in more detail in concurrently pending application entitled "Method and Apparatus for use with E-mail" and filed on behalf of the applicant of the present application, the contents of which are incorporated in this application by reference.

Below with reference to Fig.7-10 will be described the configuration of the system access to the Internet for the case when the receiver-decoder does not support Internet Protocol. Refer to Fig.7, which shows a part of the system can be completely seen on figure 5, detailing some of its aspects; the receiver-decoder 13 is a receiver of the above-mentioned type, i.e. not provided with the TCP/IP Protocol is required for direct connection to ISP 26. Accordingly, the data communication is carried out through the gateway 58 to the digital TV (DSTB). The server 76 support and server 78 reminders shown in the figure as separate items IAMS 50, and in this embodiment, the data sent to each line 76A or 78A, respectively.

Any exchange of data between the receiver-decoder 13 and any remote server to which you want to access, practical interest are the four subsystems. This is the receiver-decoder 13, 56 NAS gateway 58 and the remote server, which in this embodiment can be either a server 76 support, or the server 78 reminders, or mail server 64. PSTN 24 is virtually transparent to the data. In this embodiment, access to the mail server 64 via the interface 66 and ISP 26, but this is not necessary, and access to the mail server 64 can be carried out directly through the gateway 58. Moreover, although it is shown in the figure as a single unit, the mail server 64 may consist of two separate blocks: the first is to send e-mail (this can be, for example, the SMTP server), and the second to receive e-mail (this can be, for example, the IMAP server). In this configuration, the gateway 58 may communicate with the two blocks forming the mail server cher the C two separate port.

Describe with reference to Fig different Protocol levels that each of the above four subsystems. As is evident from Fig, the receiver-decoder 13 has four hierarchical levels (starting with the highest): the application layer Protocol (which will depend on the application), which may be, for example, SMTP, IMAP, or the like, the Protocol gateway (the level used for communication between the receiver-decoder and the gateway, described in more detail below); the Protocol RR and the level of the modem, such as the v22 or v42bis. Using the last two levels.

NAS 56 has one Protocol level and is used to convert a level of the modem (used for communication with the PSTN 24) in the Internet Protocol TCP/IP.

Gateway 58 has three working Protocol level (starting with the highest): level gateway Protocol, the Protocol level RR and TCP/IP.

Finally, the remote server will usually have two hierarchical levels: the upper level Protocol application-level and lower-level TCP/IP.

Thus, the Protocol gateway provides the gateway 58 the opportunity to respond to messages and, where appropriate, to identify the recipient of the data which they are intended, and to transmit these data to the recipient. This Protocol also provides the receiver-decoder 13 is the opportunity to initiate various operations between the gateway 58 and a remote server. In this embodiment, the gateway 58 is responsible for the direction of the SMTP or IMAP data to the mail server 64; direction in the server 76 support data, which may include requests to create new accounts; direction in the server 78 Dunning data, which may include requests to write new events; preparation of messages that must be transmitted to the receiver-decoder 13, on the basis of data obtained from any of these servers: mail server 64, server 76 support, or the server 78 reminders, and providing for the transfer of such messages. In addition, the gateway can authenticate the receiver-decoder.

Describe the communication between the receiver-decoder 13 and the gateway 58 at a low level. In the first phase between the receiver-decoder 13 and the NAS 56 establishes a modem connection through the PSTN 24. Can be used any suitable modem standard, for example v22 or v42bis. At this stage between the receiver-decoder 13 and 56 NAS-level modem is the procedure for establishing the connection for the organization of the data transmission channel. After that NAS 56 organizes the data transmission channel with the gateway 58 at the TCP Protocol level. After that, the gateway 58 transmits to the receiver-decoder 13 a token representing a certain predefined sequence symbol is C. Receiving such a token receiver-decoder 13 informs him about the availability of the gateway 58; thus, between the receiver-decoder 13 and the gateway 58 is organized data link Protocol-level gateway.

In fact, organized at the level Protocol gateway data transmission channel is under the control of the receiver-decoder 13. It is the receiver decoder must request the channel, before they can be messaging. In addition initiated to close this channel separation procedure (described below) is initiated by the receiver-decoder 13.

It should be noted that in this embodiment, the Protocol gateway allows you to organize only one TCP channel with the appropriate remote server. In other words, in this embodiment, at any given point in time, the receiver-decoder 13 cannot be connected simultaneously to more than one remote server. However, the receiver-decoder 13 can establish and terminate the connection with the various remote servers without the necessity to re-organize the data transmission channel between itself and the gateway 58.

It should also be noted that in this embodiment, the Protocol-level gateway does not perform any actions aimed at the correction of errors, protocols lower ur the init (modem and TCP) provide transportation data and the higher Protocol layers (application protocols) provide error.

Describe the General structure of the messages in the Protocol gateway. The structure of each message includes the following fields:

{Protocol version} {ID command} {length of data} [settings],

where in curly brackets are mandatory fields, and in square brackets are optional.

The message structure is the same, regardless of whether the message from the receiver-decoder 13 or gateway 58. Fields contain binary code, the significant bits are first.

The "Protocol version" (PRT) contains one byte indicating the version of the Protocol.

The "command ID" (CI) contains two bytes and specifies the type of this message. Different types of messages will become clear from the following descriptions of the events data exchange.

Field data length (DL) has a length of two bytes and specifies the total length is attached to the message parameter fields (if any). Thanks to the options field may have a variable length. In the absence of a join field parameters this field contains a null value.

The options field is encoded in the format of "type-length-value (Type Length Value TLV) and contains all necessary parameters used with this message. There are three ka is of egorie parameters which can be used both separately and in combination with each other, depending on the message type. In other words, the message type determines the presence of certain parameter fields. It is clear that some messages (for example, the message-command initialize connection (MG_RCNX)) can be used without any parameters.

The first type of parameter (ADALENYCOREE) is used to identify the remote server and contains some integer that indicates whether the identified server STMP part of the mail server 64, IMAP part of the mail server 64, the server 76 support or server 78 reminders. In the present embodiment, the length of this parameter is two bytes. Possible modifications in which this parameter can be used to identify other or additional servers.

The second type of parameter (BLOGGANG) is used for host data received from the corresponding remote server, or data that is to be transferred to it. This parameter has a variable length defined by the field "data length", and this means that the data packets do not need to have pre-specified length. A preset is just the maximum length of this parameter.

The third type of parameter (error code) is used to oboznacheniyalari errors. It can be used, for example, to specify that the gateway is not able to establish a connection with the specified remote server that the connection with the remote server broke that obtained from the receiver-decoder 13 message an error was detected that after the command from the receiver-decoder 13 from the remote server no data has been received, or that authentication has been completed with negative results. In the present embodiment, the length of this parameter is two bytes.

In the modification under consideration may not apply the fourth type of the parameter containing the information used for authentication.

Below with reference to figure 9 will be described a typical sequence of operations of the communication characteristic of the conventional communication data link level Protocol gateway. It schematically shows the messages passed between the receiver-decoder 13 and the gateway 58, together with the relevant events occurring between the gateway 58 and the selected remote server for some period of time (the time increases toward the bottom of the page).

The first shows the sequence of events (E1) is the procedure of connection of the receiver-decoder to the specified remote server Protocol-level gateway. P is amnic decoder 13 passes requesting the connection message 1000 (MG_CNX), contains two parameters, the parameter "ADALENYCOREE", indicating the server with which it wants to communicate, and the parameter "BLOGGANG"containing data destined for a specific remote server (if any). This triggers the execution of the gateway two operations together are marked on the figure by the arrow 1001, namely the connection with the specified server via the corresponding communication line and transmission via the communication line to the specified server mentioned data (if any)contained in the parameter "BLOGGANG the message.

After the above sequence of operations, the remote server sends data 1002 in the gateway 58 for subsequent forwarding to the receiver-decoder 13. The gateway encodes the message "communication with the remote server 1003 (MG_REMOTE), with one field parameters, namely the field "BLOGGANG", which contains said data, and transmits this message to the receiver-decoder 13. Thus a connection is established.

The second shows the sequence of events (E2) is a typical sequence of operation of the communication. This sequence begins with the transmission of a receiver-decoder 13 message "communication with the remote server" (MG_OTHER)containing the field "BLOGGANG data destined for the server. the AK will become clear, each time the receiver-decoder 13 communicates with only one remote server and, therefore, since this server is already defined in the initiating message (E2), it is not necessary to specify during normal data exchange. The reception of this message 1004 data exchange gateway 58 initiates the transmission gateway is contained in the data message in said remote server, as indicated by arrow 1005.

After that mentioned the remote server may transmit data to the receiver-decoder (denoted by position 1006, 1007), as described above.

Describe with reference to the communication indicated by the positions a, I and 1009, another feature of this version of the implementation of the present invention. The mentioned message "communication with the remote server" (MG_REMOTE), which was transmitted from the gateway 58 in the receiver-decoder 13 includes the minimum data packet size. Therefore, the gateway 58 will not transmit the message to the receiver-decoder 13 to until you mentioned the remote server is not received in a predefined minimum amount of data (actually, a threshold value) or until some pre-specified period of time after receiving the last data from the remote server (in fact - until timeout). Thus, although the arrow a marked the transfer of data from the remote server in the gateway 58, the volume of data is less than the previously mentioned predetermined threshold value, and therefore, in the receiver-decoder 13 then not transmitted any messages. Then there is another data transfer (arrow 1008b) from the remote server in the gateway 58. According to the results of this program in the gateway 58 is accepted by a sufficient number of data, and, as a consequence, it passes the message 1009 communication, which include both data transfer operations, a and 1008b. Similarly, in the receiver-decoder 13 is transferred message data exchange as soon as the amount of data received by the gateway 58 from the remote server, will exceed a certain maximum value. In this case, one operation of the data exchange between the remote server and the gateway 58 can lead to the exchange of multiple messages between the gateway 58 and receiver-decoder 13.

In the present embodiment, the above-mentioned time limit (timeout) is 200 MS, referred to the minimum threshold amount of data is 128 bytes, and the above-mentioned maximum threshold amount of data is 512 bytes.

Although it is not shown in this figure, it may happen that for some predefined time interval, to the which in this embodiment is 5 seconds, gateway 58 does not receive from the remote server any data. In this case, the gateway transmits to the receiver-decoder 13 message "gateway error found" (MG_ERROR)that contains a field of type parameters "error code", the contents of which indicates the occurrence of such event. Next steps will be determined by the receiver-decoder 13 and may include, for example, a message "initializing connection" (MG_RCNX), in response to which the gateway 58 closes the TCP connection with the remote server.

As mentioned above, these error messages can follow and for other events, such as the inability to establish a connection with the remote server, the connection is lost with the remote server, or it contains an error message that was received from the remote server. The latter case may include receiving gateway 58 from the remote server data of an unknown type, wrong length, unacceptable values or with an unknown Protocol version.

Again referring to figure 9, we describe a disconnect event from the remote server (E3). This event is triggered by the receiver-decoder 13 that conveys the message "disconnect" (MG_DCNX) 1020. This message may include data that must be transmitted to the remote server, the option "BLOGGANG". The command and data are transmitted to the remote server (arrow 1021), and then the gateway 5 is waiting for confirmation and response data 1022 (if proposed). After that, the gateway 58 is disconnected from the remote server (1023) and transmits to the receiver-decoder 13 1024 message containing the received data, if any. Although it is not shown in this figure (as associated with low-level Protocol), the receiver-decoder 13 can then close the connection at the level of the modem. After that, the gateway 58 will be notified by the NAS server 56 for closing the TCP connection.

Below with reference to figure 10 will be described authentication procedure provided by gateway Protocol. This procedure can be used for various services, such as support services, to the organization of the transmission channel data. Gateway 58 has information about which servers require authentication before granting access, and, when he receives the message "connection request" (MG_CNX) 1100 with respect to such server, it responds with the message "authentication request" (MG_AUTHEB_REQ) 1101. Is requesting authentication of the message does not include any parameters. After that, the receiver-decoder 13 must comply with the appropriate message 1102 "authentication". This message has a parameter that contains authentication data, which may be, for example, a smart card, as described in more detail below. These authentication data can be transmitted in the type parameter "BLOGGANG" or in one of modificati is under consideration implementation of the present invention, in a separate parameter type.

If the gateway 58 finds this authentication information is correct, the authentication result is positive (as schematically represented by the event 1103), and the gateway 58 connects 1104 with the specified remote server. On the positive result of the authentication gateway 58 reports by passing messages 1106 communication, which will include any data 1105 received from the remote server in response to the connection establishment. In case of negative authentication result is transmitted to the error message (MG_ERROR), with the parameter indicating the error as described above.

Let us return to the system shown in figure 5; we can distinguish two separate types of accounts to access Internet services, etc. by using a receiver-decoder 13, namely the so-called "account connection account) and the so-called "account to use the services (directory account). In each account, the compounds can contain multiple accounts for use of the services.

The connection account is the basis on which the subscriber may access the operator's network. The operator allocates to each subscriber one account connection, although it may correspond to several protocols for the connection is to be placed, as described in more detail below. The authentication procedure such account is implemented at the network level and will also be described in more detail below.

Let us now describe the steps performed during registration (logging-in the user connecting to the system using the account connection. It is clear that in order for the user can be identified, transmitted during the registration data must be unique. In the present embodiment, this is accomplished by using the so-called MSD-rooms, which is at least partially derived from the smart card number of the user equipment. In addition, when registering, the user must specify the data transfer Protocol, which can be different depending on, for example, if the user tries to gain access through a modem connection over a telephone line connected to your computer (using, for example, product MediaWebPC company Canal+), or the receiver-decoder of the type usually referred to as "set-top box for a television" set-top box). In the case of using a modem to dial the protocols used can be, for example, the protocols PAP, CHAP, or PPP.

Thus, the registration data (login information) include MSD-number of the user, field, identify yousee the type of user terminal, field that identifies the type of response data, which should be applied, field indicating the version number of the client equipment, and in the appropriate case, the domain name of so-called service remote authentication user dial-in service (RADIUS). Registration information will also include the password. In the present embodiment, these data have the following format:

login={msn_} {typereal} {tipoteca} {version} [@__RADIUS]

We will explain now in more detail each of the above-mentioned fields.

Field msn_ in turn consists of the following sequence of fields:

{_msn}={RSMC} {RSMN} {instruments}

The first of the fields MSN-data contains the code replaceable security module (removable security module code - RSMC), identifying the type of smart card. This identifier may include data indicating one or more aspects of the technical device card, manufacturer and commercial operator, provided this map to the user. In the present embodiment, this field has a length of two bytes and can contain four digits.

The second of the fields MSN-data contains the number of the replaceable security module (removable security module number - RSMN). This field contains the code that identifies the smart card while using it. This code is preferably pre-defined post the provider of this smart card is unique, allowing, thus, to uniquely identify its user. In the present embodiment, the length of this field is four bytes, and it may contain fifteen digits.

The last field (instruments) contains control data that can be calculated by any known method; for example, it may be a checksum.

Let us now describe the field "typereal". As explained above, the terminal may be a variant of the so-called "set-top boxes for TV", or it may be a computer equipped with a modem. This field takes the value "P" for terminal type PC (PC) and a value of "T" for terminal type "top box for a television" set-top box). It is clear that this field can determine the terminal type and, more specifically, the definition of this field provides the possibility of further expansion by defining complementary and alternative types of terminals.

Field tipoteca allows you to determine the method by which the user will be transmitted response data. In the present embodiment, this field is set to "M"when all the response data must be routed through the modem, and the value "S", when the transfer response data must occur via satellite, and via modem channels. Again, the possibility of further expansion in what is relates to methods of transmitting response data.

Field "version" allows you to pass data about the version of the receiver-decoder 13 in the network. In the present embodiment, by default, this field is set to "01".

Optional field "__RADIUS allows you to send a custom request for authentication to a third party (third party) authentication server, which can make possible the provision of the relevant third party gateways, for example, different service providers.

Registration information will also include the "password"field, max length of which in the present embodiment, amounts to 14 alphanumeric characters.

Let us come back and describe the account for use of the services, which is the basis for access to specific Internet services, for example, proxy server with authentication, e-mail, conferences, etc. the Account of the subscriber for use of the services linked to the account connection. However, unlike the account connection, authentication account to use the services occurs at the application level.

As mentioned above, account for the use of the services allows you to use various Internet-Serisi using receiver-decoder 13. Account for use of the services will typically SOS is Oyat from

ID and password;

- one or more so-called "mail aliases" (e-mail aliases);

in appropriate cases, other data relevant to the proposed subscriber services.

Mentioned ID (if applicable in combination with the password) is used to control subscriber access to various services ISP, for example, access to the mailbox of the subscriber. Other examples are access to sensitive Web sites, directories, access control services, certificates, registration for participation in the "mailing list" (mailgroup), etc.

The above-mentioned identifier can also be used to get an email address in the format "ID@domain", in which case you may need to use the subscriber of his / her password to access the mailbox identified by the specified ID.

Mentioned mail aliases, enable the receiving mail server e-mail address "pseudonym@domain".

In one embodiment, the implementation of one account connections can be linked to multiple accounts for use of the services (the so-called "family membership"). In this case, the user can initially specify the number of accounts for use of the services, which is th can be created for each account connection although it should be noted that each ID and the alias must be unique.

The term "receiver-decoder"or "decoder", as used herein, may mean a receiver for receiving both encoded and unencoded signals, such as television and/or radio signals that can be transmitted by broadcast or in any other way. This term can also denote a decoder for decoding received signals. Options such receivers-decoders may include a decoder, combined with the receiver, for decoding the received signals, as, for instance, in the set-top box for a television" set-top box, decoder, operating in combination with a physically separate receiver, or decoder, equipped with additional functions such as a Web browser, or combined with other devices such as a recorder or the TV.

Naturally, the present invention was described above on purely illustrative example, and without departing from the scope of the present invention, various modifications are possible.

Each feature disclosed in the description of the invention, and (in appropriate cases) in the claims and in the drawings can be implemented in ezavisimo or in any suitable combination.

Described in the claims the item numbers serve only for illustration and should not be construed as having any limiting effect on the scope of the claims.

1. The authentication method of data exchange between the receiver-decoder and a server to provide remote network access, including the use of authentication data exchange some ID mentioned receiver-decoder, and the said identifier based on the identifier used to access broadcast services.

2. The method according to claim 1 in which the said identifier is stored on a removable component of the above-mentioned receiver-decoder.

3. The method according to claim 1 in which the said identifier independent from the registration ID to log in to the network to be used with this receiver-decoder.

4. The method according to claim 1 in which the said identifier is based on a certain number that is unique to the smart card used with the said receiver-decoder.

5. The method according to claim 1 in which the mentioned remote server is a server for Internet access.

6. The method according to claim 1, in which the mentioned remote server is a system of maintaining accounts for the use of the Internet.

7. The method according to claim 6, in which the said system of accounting records and for the use of the Internet, using the above-mentioned identifier of the receiver-decoder creates a user account for Internet usage.

8. The method according to claim 7, in which the said identifier of the receiver-decoder is compared with the system of accounting records for the use of the Internet with the saved list of IDs of the receivers-decoders, which can create accounts to use the Internet.

9. The method according to claim 7 or 8, in which the mentioned remote server includes means for transmitting data to the provider of Internet services, including the operation of providing data to the said account for the use of the Internet provider of Internet services for the organization between the receiver-decoder and provider of Internet services, bidirectional data transmission channel.

10. The method according to claim 1 in which the said identifier is accompanied by data that identifies the data channel, which should be used for data transmission between the said receiver-decoder and a remote server.

11. The method according to claim 1, in which the mentioned remote server provides the receiver-decoder network access, with some network protocols, and data generated by the receiver-decoder is converted into data compatible with said network protocols, in a location remote from that which the receiver-decoder.

12. The method according to claim 11, in which said data is converted in the above-mentioned compatible with network protocols data gateway, located between the said receiver-decoder and a remote server.

13. The method according to item 12, in which the said network includes many remote devices and said converted data is sent to the mentioned gateway in one of these remote devices specified in the above-mentioned data, providing a data transmission channel between the receiver-decoder and the specified remote device.

14. The method according to item 13, characterized in that the above-mentioned receiver-decoder in the above-mentioned gateway using nemislevme Protocol message initiating the closing of the above-mentioned data transmission channel, and the above-mentioned gateway, in turn, reports to the specified remote device closure using Internet Protocol.

15. The method according to any of PP-14, characterized in that, before the above-mentioned data transmission channel gateway performs authentication of the identity of the receiver-decoder.

16. Device to authenticate the communication between the receiver-decoder and a server for providing access to a remote network that contains the tool to use for authentication data exchange nicotinoglycinate mentioned receiver-decoder, moreover, the above-mentioned identifier based on the identifier used to access the broadcast server.

17. The device according to clause 16, where the said identifier is accompanied by data that identifies the data channel, which should be used for data transmission between the receiver-decoder and a remote server.

18. The device according to clause 16, where the mentioned remote server provides the receiver-decoder network access, with some network protocols, while the said device comprises means for converting data generated by the receiver-decoder, the data compatible with said network protocols.

19. Device according to any one of p-18 in the form of a gateway located between the said primerica-decoder and a remote server.

20. The device according to claim 19, where the said network includes many remote devices and said gateway is arranged to transfer referred to the converted data to one of the mentioned multiple remote devices specified in the above-mentioned data, providing a data transmission channel between the receiver-decoder and the specified remote device.