RU2263409C2 - Methods and device for data exchange - Google Patents

Abstract

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

Description

The present invention relates to methods and apparatus for exchanging data between a user device, such as a receiver / decoder, and a remote device, which may be, for example, an account management system for using the Internet or an Internet service provider.

Receiver decoders are used to receive and / or decode signals, such as television signals, that can be transmitted in analog or digital form. In the case of digital transmission, digital channels are encoded into the digital data stream on the transmitter side and decoded on the receiver side using a receiver-decoder, which can be located either in a digital television set-top box (DSTB) or in an integrated television. In the case of analogue transmission, a subscriber-decoder can be used to convert the transmitted signals into a format that can be displayed on a TV screen.

Receiver decoders typically have a processor on which programs called applications can run. An example of an application that can be executed on a receiver / decoder is an Internet access application that can provide a subscriber with access to the Internet using this receiver / decoder.

To reduce the cost of receiver-decoders, their design is sought to simplify. Because of this, it may be difficult to use a receiver / decoder to exchange data with a remote network, such as the Internet. In particular, Internet connection requires the use of Internet protocols and authentication, which can be difficult to apply to the receiver-decoder. For example, some receiver / decoders may not be able to output data in a format suitable for a direct connection to the Internet. Such receiver / decoders are referred to as non-IP-enabled.

According to a first aspect of the present invention, there is provided a method for authenticating data exchange between a receiver-decoder and a remote server for providing access to a certain network, comprising using for authentication data exchange a certain identifier of said receiver-decoder, said identifier being based on an identifier used to access broadcast services .

Through the use of the present invention, authentication of the data exchange between the receiver-decoder and the remote server can be based on the use of some unique identifier of the receiver-decoder that this receiver-decoder already has, which can reduce the requirements on the receiver-decoder. Receiver decoders often provide a unique identifier for accessing broadcast services, and such an identifier is a convenient means for identifying a given receiver / decoder.

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

Preferably, said identifier is independent of the login identifier for the network. Due to this, the receiver-decoder can be simplified, since the said identifier can be simpler than the registration identifier for entering the network, which is usually a complex multi-character identifier, to facilitate its memorization by the user. Another disadvantage of registration identifiers is that they may change from time to time, or more than one identifier may be required to access various services; the present invention can provide the possibility of correlation (in a remote server) of a single identifier transmitted by the receiver-decoder, with the identifier for the network, which may change, or with several identifiers for the network. This feature of the present invention can be implemented independently.

Preferably, said identifier is based on a number unique to each smart card. The term "smart card" as used in this text covers, but is not limited to, any card device based on a microcircuit, or an object with a similar purpose and performance, equipped with, for example, a microprocessor and / or storage device. This term also encompasses devices having a physical form other than the card, for example, key-shaped devices, similar to those often used in television systems using decoders.

Said remote server may be a server for accessing the Internet, or it may be an account management system for using the Internet, or a server of any other type, for example, for access to a remote network of any type.

Using the said receiver-decoder identifier, the account management system for using the Internet can create an account for the user to use the Internet. To create an account, said identifier can be compared by an account management system for using the Internet with a stored list of identifiers for receiver-decoders that can create accounts for using the Internet.

The said remote server may comprise means for transmitting data to the Internet service provider, and the proposed method includes the operation of providing data to said account for use by the Internet service provider, for organizing a bi-directional data transmission channel between the receiver-decoder and the Internet service provider.

Said identifier may be accompanied by data identifying a data channel that should be used to transfer data between the receiver-decoder and the remote server. Thus, the receiver-decoder can specify the data channel, which should be used for data transmission; for example, a satellite channel may be used as the return channel.

In one preferred embodiment of the present invention, the login data has the following form:

login = {smart card number} {service type},

where the “type of services” (TOS) can determine the channels over which data should be transmitted, for example, indicating the case when a satellite should transmit responses of some type to the subscriber terminal.

In one preferred embodiment of the present invention, said remote server provides the receiver / decoder with access to a network having some network protocols, and the data output by the receiver / decoder is converted to data compatible with said network protocols, at a location remote from the receiver - decoder. Thus, a receiver / decoder that is not equipped with said network protocols can, however, exchange data with said network. The network may be, for example, the Internet, and the network protocol may be, for example, TCP / IP. Said remote location may, for example, be located at an operator who may have an account management system for using the Internet.

Preferably, said data is converted to said data compatible with network protocols by a gateway located between said receiver-decoder and a remote server.

In one preferred embodiment of the present invention, said network includes a plurality of remote devices, and said converted data is transmitted by said gateway to one of said remote devices indicated in said data, thereby organizing a data channel between the receiver-decoder and said remote device.

According to a second aspect of the present invention, there is provided a method for transmitting data from a non-network protocol supporting user terminal to one of a plurality of remote network-protocol supporting devices, including data transfer operations using said non-network protocol from said user terminal to a gateway, said data including some message and indicate the addressee of this message from among the plurality of remote devices, converted I said data in said gateway to data using said Internet protocol, and transmitting said data using said Internet protocol, from said gateway in said remote destination device, thus arranging the data channel between said user terminal and said remote device. Said user terminal may be a receiver / decoder.

A method for exchanging data between a receiver-decoder and a remote network is also proposed, in which the protocols necessary for exchanging data with said remote network are implemented at a location remote from the receiver-decoder.

From the receiver-decoder to the gateway using the aforementioned non-network protocol, a message can be transmitted initiating the closure of the data channel, and the gateway, in turn, sends a close command to the specified remote device using the above-mentioned Internet protocol. Preferably, before organizing said data channel, the gateway authenticates the identity of the receiver / decoder.

According to a third aspect of the present invention, there is provided a device for authenticating data exchange between a receiver-decoder and a remote server for providing access to some network, comprising means (for example, a system, server or gateway) for using for authentication of data exchange some identifier of said receiver-decoder, wherein said identifier is based on an identifier used to access broadcast services. Said identifier may be accompanied by data identifying a data channel that should be used to transfer data between the receiver-decoder and the remote server.

Said remote server may provide the receiver / decoder with access to a network having some network protocols, and the proposed device may comprise means (for example, a system, server or gateway) for converting data output by the receiver / decoder into data compatible with said network protocols .

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

Preferably, said network includes a plurality of remote devices, and said gateway is configured to transmit said converted data to one of said plurality of remote devices indicated in said data, thereby organizing a data channel between the receiver-decoder and said remote device.

According to a fourth aspect of the present invention, there is provided a gateway for transmitting data received from a non-network protocol supporting user terminal to one of a plurality of remote network protocol-supporting devices, comprising

means (for example, input) for receiving data transmitted from said user terminal using said non-network protocol, including some message and indicating the addressee of this message from among the plurality of remote devices;

means (for example, a converter) for converting the received data into data using said Internet protocol; and

means (for example, output) for transmitting said data using said Internet protocol to said remote destination device, thereby organizing a data channel between said user terminal and said remote device.

The proposed gateway may have multiple input / output ports, each of which is designed to connect to a corresponding remote device.

The proposed gateway may include means (for example, a recognition device) for recognizing a message from a user terminal that initiates the closure of said data channel; and means (e.g., output) for transmitting a close command to said remote device.

The present invention also provides a method and apparatus, essentially as they are described with reference to the figures of the drawings and illustrated by them.

The attributes of one aspect may be applied to other aspects; likewise, the features of the methods can be applied to aspects related to devices, and vice versa.

Preferred features of the present invention will be described below, by way of example only and with reference to the drawings in 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 levels of the user equipment shown in figure 3;

5 is an architecture of an Internet access system; and

6 - the main elements of the account management system for using the Internet;

7 is a part of the configuration of the Internet access system in the case when the receiver-decoder is not IP-supporting;

Fig.8 is the protocol levels of the system shown in Fig.7;

FIG. 9 schematically illustrates a protocol used for exchanging data between user equipment and a gateway in the system of FIG. 7; and

FIG. 10 schematically illustrates a protocol used for exchanging data between user equipment and a gateway in the system shown in FIG. 7 when performing authentication.

Figure 1 shows a system 1 of digital television in General. The present invention uses primarily the conventional digital television system 2, in which an MPEG-2 compression system is used to transmit compressed digital signals. More specifically, the MPEG-2 compressor 3 in the broadcast center receives a stream of digital signals (usually a stream of video signals). The compressor 3 is connected to the scrambler 4 multiplexer via connection 5.

The multiplexer 4 receives many additional input signals, composes the transport stream and transmits the compressed digital signals to the transmitter 6 of the broadcast center via connection 7, which, of course, can take a wide variety of forms, including telecommunication channels. The transmitter 6 transmits electromagnetic signals through the channel 8 "Earth-satellite" to the satellite transponder 9, where they are processed electronically; from there, they are transmitted by broadcasting via satellite-to-Earth virtual channel 10 to the ground receiver 12, usually in the form of a plate, owned or leased by the end user. Of course, other transport channels for data transmission are also possible, such as terrestrial broadcasting networks, cable transmission channels, combined cable-satellite connections, telephone networks, etc.

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

In a multi-channel system, the multiplexer 4 processes the audio and video information obtained from several parallel sources, and interacts with the transmitter 6 to broadcast this information on the corresponding number of channels. In addition to audiovisual information, messages, or applications, or any other kind of digital data can be introduced into some or all of these channels, interspersed with transmitted digital audio and video information.

A conditional access system 15 connected partially to the broadcast center and partially to the decoder is connected to the multiplexer 4 and the receiver-decoder 13. It allows the end user to access digital television broadcasts of one or more broadcast providers. A smart card capable of decrypting messages related to commercial offers (i.e., one or more television programs sold by the broadcast provider) may be installed in the receiver / decoder 13. Using the decoder 13 and the smart card, the end user can buy commercial offers either in the subscription mode or in the pay-per-view mode (PPV mode).

As mentioned above, the programs transmitted by the system are scrambled by the multiplexer 4, and the parameters and encryption keys applied to this particular transmission are determined by the conditional access system 15. The transmission of scrambled data in this way is well known in the field of pay-TV systems. Typically, the scrambled data is transmitted together with a control word intended to descramble this data, and the control word itself is encrypted with a so-called working key and transmitted in encrypted form.

Said scrambled data and the encrypted control word are then received by the decoder 13 having access to the equivalent of the said working key stored on the smart card installed in the decoder to decrypt the encrypted control word and then descramble the transmitted data. The subscriber who has paid for the subscription will receive, for example, in the EMM transmitted for the current month (rights management message or access control message), the working key needed to decrypt the encrypted control word, which, in turn, is necessary to view the transmission.

The interactive system 16, also connected to the multiplexer 4 and the receiver-decoder 13 and also located partially in the broadcast center and partially in the decoder, allows the end user to interact interactively with various applications through the modem return channel 17. This modem return channel can also be used for messaging with the conditional access system 15.

The physical interfaces of the receiver-decoder 13 are used to download data. As shown in FIG. 2, the receiver-decoder 13 contains, for example, six devices for downloading data: a serial interface 30, a parallel interface 32, a modem 34, two card readers 36 and a tuner 38 MPEG streams.

The broadcasting and reception system in question is also used to provide Internet services such as Web browsing and e-mail. The application executed by the receiver-decoder 13 allows the receiver-decoder to access Internet services and display Web pages and e-mail messages either on the TV 14 or through a computer connected to the receiver-decoder 13.

With reference to FIG. 3, an Internet access system will be generally described below. The user equipment 20 (which includes the receiver / decoder) is connected to the operator 22 via a public switched telephone network 24 (PSTN). The user equipment transmits to the operator 22 a request to transmit therein specific data, for example, a specific web page or email. The operator accepts this request and transmits it to the Internet Service Provider (ISP) 26. In response to this request, the ISP provides the operator with a response that may contain the requested Web page received from Internet 27, or the e-mail message available for this ISP subscriber. The operator transmits this response to the broadcast center 28, where it is introduced into the MPEG bitstream, for example, as a private section, transmitted by transmitter 6 and received by receiver 12, as described above. In the case where the receiver-decoder is "IP-enabled", i.e. equipped with protocols for receiving data from the Internet, information can be transmitted as an IP frame of the MPEG bitstream, i.e. in IP format. If the receiver-decoder is not "IP-capable", then the data is transmitted in some other way, for example, as a private MPEG section. The user equipment 20 extracts this response from the MPEG bitstream and displays it on a TV or monitor connected to a computer. Alternatively, this response may be transmitted to user equipment 20 via PSTN 24.

Figure 4 shows the software levels of user equipment 20. The application layer contains a Web browser and an application for working with e-mail (email program), which can be used as standard applications such as Netscape or Microsoft Internet Explorer and Outlook Express, or any application specifically designed to run on the receiver- decoder. Below the application layer are the HTTP layer, the socket layer, the TCP / IP layer, the PPP / SLIP layer and the driver layer. The driver level is modified, differing from the browser that is normally executed on a PC, in that it is divided into a modem driver for communication with the PSTN 24 using a user equipment modem, and a tuner driver for exchanging data through a 4028 tuner to receive an MPEG stream.

It is possible to use user equipment 20 of various configurations. In one configuration, the PC is not used, and all user software runs on the receiver-decoder 13. In this configuration, the receiver-decoder 13 communicates with the PSTN 24 either via an internal modem or an external modem and a serial port. Receiver-decoder 13 can receive Internet responses in a bitstream received from the ground-based receiver 12. The user interface (for user and system interaction) is provided by a remote control or keyboard, as well as a TV connected to the receiver-decoder 13. In this TCP configuration / The IP layer shown in FIG. 4 may not be available, in which case the necessary protocols are implemented by the gateway hosted by the operator, as will be described below.

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

In yet another configuration, the PC is connected to the PSTN 24 via its internal or external modem. In this configuration, the receiver-decoder 13 may be in the form of a separate device, or may be represented by an expansion card or a removable card for a PC connected to its ISA or PCI bus.

5 shows the architecture of an Internet access system. As shown in FIG. 5, an Internet account management system (IAMS) 50 is connected to an Internet service provider (ISP) 26 providing services such as web browsing and e-mail. IAMS 50 is also connected to a subscriber management system (SMS) 60, which controls subscribers and sends to IAMS requests to provide or deny access to Internet services. The receiver / decoder 13 is connected to the IAMS via an internal modem, a public switched telephone network (PSTN) 24, a network access server (NAS) 56, and a gateway 58.

SMS is also connected to a Subscriber Authorization Authority (SAS) 61, which issues permissions and processes subscriber orders for broadcast services, such as broadcast television services. SMS works in parallel with SAS and IAMS systems and ensures the consistency of these two systems. Information exchange between SMS and SAS and SMS and IAMS is carried out using real-time TCP / IP connections using batch files.

Gateway 58 allows users to access real-time Internet services. Such services include mail services for sending and receiving mail and other services that may be provided by ISP 26, as well as user support and reminder services provided by IAMS. In terms of its functions, Gateway 58 is a message router, making it possible to exchange data with various systems using a single modem connection. In cases where the receiver-decoder is not equipped with TCP / IP protocols for communication with the ISP, this gateway also implements the protocols necessary for the receiver-decoder to communicate with the ISP. In this case, the receiver-decoder 13 communicates with the ISP through the gateway 58, as shown by line 59 in FIG. 5. If the receiver-decoder is equipped with the necessary protocols, communication with the ISP is carried out directly, as shown in FIG. 5 by the dashed line 57. The gateway includes a communication server and an e-mail dispatcher.

ISP interface 66 allows you to duplicate (copy) each change in the user account that occurs in IAMS, in the user account of ISP 26, which is responsible for hosting Internet services such as the mail service. It should be noted that all information related to subscriber accounts for using the Internet is centralized in IAMS, which is responsible for managing TV and Internet settings. IAMS also manages the connection between Internet parameters and TV parameters, interacting with the subscriber management system (SMS) 60. SMS 60 manages the rights of subscribers and transmits requests to IAMS requesting granting subscribers access rights or denying subscribers access to Internet services.

In order to create an account in the IAMS system, first the subscriber from the receiver-decoder 13 sends to IAMS 50 a request for a new account, together with information such as the requested e-mail address and selected settings. IAMS checks to see if this smart card number is in the list of smart card numbers received from the Subscriber Management System (SMS) 60, corresponding to subscribers for which accounts for using the Internet can be opened. Then, IAMS sends to the ISP a request to create an account for using the Internet. After creating the account, the ISP returns the corresponding confirmation, as well as the password, to IAMS. Initially, the password is defined by SMS, but later it can be changed by the subscriber. IAMS account information (password, e-mail address and Internet parameters) is stored in IAMS together with the smart card number of this subscriber. IAMS informs the subscriber that an account has been created for him. After that, the subscriber can send mail to the mail server 28 and receive mail from it.

6 shows the basic elements of IAMS. The main functions of IAMS are as follows:

- maintaining and maintaining a centralized list of mail account settings tied to subscriber settings, such as a smart card number;

- Granting rights to access or denial of access to Internet services for a subscriber by SMS request;

- Set up accounts for using the Internet at the request of subscribers (support for subscribers);

- a reminder service, in which an email user can record (schedule) an event and receive a reminder about it by e-mail at the time this event occurs;

- a copy service that allows you to copy updated IAMS content to an appropriate server, such as ISP.

At the IAMS center is a relational database management system (RDBMS) 70 containing information about subscribing to Internet services and mail accounts stored in the data storage device 72. Interface 74 for exchanging data with SMS provides the ability to transfer information between IAMS and SMS, so that IAMS can be provided with up-to-date information about subscribers who have been granted access to email services or who have been denied such access. The support server 76 allows the subscriber to work with his mail account and change it in accordance with his preferences. Server 78 reminders provides the subscriber the opportunity to work with a list of events. The event is tied to the subscriber's mail account. The subscriber can record an event and receive an automatic reminder for a certain predetermined number of days before the event occurs through an automatically generated e-mail message. An interface 84 for communicating with an email notification system enables the email notification system (EMNS) 62 to find user settings related to user notification in the IAMS RDBMS 70 for transmitting a notification message via satellite (OTA). The secondary server 80 allows the administrator to check the presence and status of the subscriber or email user in IAMS. Copy server 82 copies the updated contents of the RDBMS 70 of the IAMS system to the account management system of the Internet service provider.

Requests transmitted to the IAMS from the receiver / decoder 13 are forwarded by the gateway 58 to the corresponding part of the IAMS, such as a support server (for working with mail accounts) and a reminder server (for working with reminders).

The Internet access system described above allows broadcast service providers to provide Internet services as well. The operator of such a system maintains and maintains accounts for using the Internet independently of Internet service providers, so that it is not tied to any particular Internet service provider. By linking subscriptions to broadcast services and subscriptions to Internet services with each other, you can combine the processing of accounts for these two types of services and their management, which can reduce the amount of computation required compared to the case when the accounts are kept separate, while the subscriber can billing combined for these two services.

IAMS is described in more detail in a parallel application, entitled "Internet Subscriber Management" and filed in the name of the applicant of this application, the contents of which are incorporated into this application by reference. The e-mail notification system is described in more detail in the parallel application, entitled "Method and Apparatus for use with E-mail" and filed in the name of the applicant of this application, the contents of which are incorporated into this application by reference.

Below, with reference to FIGS. 7-10, the configuration of the Internet access system for the case where the receiver-decoder does not support the Internet protocol will be described. Turning to Fig. 7, there is shown a part of the system depicted entirely in Fig. 5, with details of some of its aspects; receiver-decoder 13 is a receiver of the type mentioned above, i.e. not equipped with the TCP / IP protocol, necessary for direct communication with ISP 26. Accordingly, data is exchanged via gateway 58 for a digital set-top box for television (DSTB). The support server 76 and the reminder server 78 are shown in this figure as separate elements of the IAMS 50, and in this embodiment, data is sent to each of them via a communication line 76a or 78a, respectively.

For any data exchange between the receiver-decoder 13 and any remote server that you want to access, four subsystems are of practical interest. This is the receiver / decoder 13, NAS 56, the gateway 58, and the remote server, which in this embodiment can be either a support server 76, a reminder server 78, or a mail server 64. PSTN 24 is virtually transparent to data. In this embodiment, access to the mail server 64 is through the interface 66 and ISP 26, but this is not necessary, and access to the mail server 64 can be done directly through the gateway 58. Moreover, although it is shown in the figure as one block, the mail server 64 can consist of two separate blocks: the first is for sending email (this can be, for example, an SMTP server), and the second is for receiving email (it can be, for example, an IMAP server). In this configuration, the gateway 58 can communicate with these two blocks forming the mail server through two separate ports.

With reference to FIG. 8, we describe various protocol layers with which each of the four subsystems described above operates. As can be seen from Fig. 8, the receiver-decoder 13 has the following four protocol layers (starting from the highest): the application layer protocol (which will depend on the application), which may be, for example, SMTP, IMAP or the like; gateway protocol (the level used for data exchange between the receiver-decoder and the gateway, described in more detail below); PP4 protocol and modem level, such as v22 or v42bis. The use of the last two levels is well known in the art.

NAS 56 has one protocol layer and is used to convert the modem level (used to communicate with the PSTN 24) to the TCP / IP protocol.

Gateway 58 has three operational protocol layers (starting with the highest): the level of the gateway protocol, the level of the PP4 protocol, and TCP / IP.

Finally, the remote server will typically have two protocol layers: the upper layer is the application layer protocol, and the lower layer is TCP / IP.

Thus, the gateway protocol provides the gateway 58 with the ability to respond to messages and, as appropriate, identify the recipient of the data to which they are intended and transmit this data to this recipient. This protocol also allows the receiver / decoder 13 to initiate various operations between the gateway 58 and the remote server. In this embodiment, the gateway 58 is responsible for sending SMTP or IMAP data to the mail server 64; sending data support server 76, which may include requests to create new accounts; sending data reminders to the server 78, which may include requests to record new events; composing messages that should be transmitted to the receiver-decoder 13, based on data received from any of the mentioned servers: mail server 64, support server 76, or reminder server 78, and ensuring the transmission of such messages. In addition, said gateway is capable of authenticating a receiver / decoder.

We describe the data exchange between the receiver-decoder 13 and the gateway 58 at a low level. In the first step, a modem connection is established between receiver / decoder 13 and NAS 56 via PSTN 24. Any suitable modem standard, such as v22 or v42bis, can be used. At this stage, between the receiver-decoder 13 and the NAS 56 at the modem level, a connection is established to establish a data channel. After that, NAS 56 organizes the data channel with gateway 58 at the level of the TCP protocol. After that, the gateway 58 transmits to the receiver-decoder 13 a marker representing a certain predetermined sequence of characters. The receipt of such a marker by the receiver-decoder 13 notifies him of the presence of the gateway 58; Thus, between the receiver-decoder 13 and the gateway 58, a data channel is organized at the level of the gateway protocol.

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

It should be noted that in this embodiment, the gateway protocol allows you to organize a single TCP channel with the corresponding remote server. In other words, in this embodiment, at any given time, the receiver-decoder 13 cannot be connected simultaneously with more than one remote server. However, the receiver-decoder 13 can establish and disconnect a connection with various remote servers without the need to re-arrange the data transmission channel between itself and the gateway 58 each time.

It should also be noted that in the present embodiment, the level of the gateway protocol does not perform any actions aimed at correcting errors - lower level protocols (modem and TCP) provide data transportation, and higher level protocols (application protocols) provide error handling.

Let us describe the general structure of messages when exchanging data using the gateway protocol. The structure of each message includes the following fields:

{protocol version} {command identifier} {data length} [parameters],

where the required fields are indicated in curly brackets and optional fields in square brackets.

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

The Protocol Version (PRT) field contains one byte indicating the protocol version.

The Command Identifier (CI) field contains two bytes and indicates the type of this message. Various types of messages will become apparent from the following descriptions of communication events.

The data length (DL) field is two bytes long and indicates the total length of the parameter field attached to the message (if any). Due to this, the parameter field can have a variable length. In the absence of attached parameter fields, this field contains a null value.

The parameter field is encoded in the Type Length Value (TLV) format and contains any necessary parameters used with this message. There are three categories of parameters that can be used both individually and in combination with each other, depending on the type of message. In other words, the type of message determines the presence of a particular parameter field. It is understood that some messages (for example, a connection initialization command message (MG_RCNX)) can be used without any parameters.

The first type of parameter (REMOTE_SERVER) is used to identify the remote server and contains an integer indicating whether the identified STMP server is part of mail server 64, IMAP is part of mail server 64, support server 76 or reminder server 78. In this embodiment, the length of this parameter is two bytes. Modifications are possible in which this parameter can be used to identify other or additional servers.

The second type of parameter (DATA BLOCK) is used to place data received from the corresponding remote server, or data to be transferred to it. This parameter has a variable length defined by the "data length" field, and this means that data packets do not need to have a predefined length. Only the maximum length of this parameter is predefined.

The third type of parameter (ERROR CODE) is used to indicate the error state. It can be used, for example, to indicate that the gateway is not able to establish a connection with the specified remote server, that the connection to the remote server was interrupted, that an error was detected in the message received from the receiver-decoder 13, that after the command from the receiver-decoder 13 no data was received from the remote server, or that the authentication failed. In this embodiment, the length of this parameter is two bytes.

In a modification of the present embodiment, a fourth type of parameter may be used, containing information used for authentication.

Below with reference to Fig.9 will be described a typical sequence of operations for the exchange of data characteristic of the usual data exchange on the data channel of the protocol layer of the gateway protocol. It schematically shows the messages transmitted between the receiver-decoder 13 and the gateway 58, together with the corresponding events occurring between the gateway 58 and the selected remote server, for a certain period of time (the time increases towards the bottom of the page).

The first sequence of events shown (e1) is the procedure for connecting the receiver-decoder to the specified remote server at the gateway protocol level. The receiver-decoder 13 transmits a connection request message 1000 (MG_CNX) containing two parameters — the REMOTE SERVER parameter indicating the server with which it wishes to exchange data and the DATA BLOCK parameter containing data intended for the specified remote server (if those are available). This initiates the gateway performing two operations, together indicated by arrow 1001 in this figure, namely, establishing a connection with the specified server through the corresponding communication line and transmitting the data (if any) contained in the "DATA BLOCK" parameter of this to the specified server messages.

After the sequence of operations described above, the remote server transmits the data 1002 to the gateway 58 for subsequent transmission to the receiver / decoder 13. The gateway encodes them into the message "data exchange with the remote server" 1003 (MG_REMOTE), which has one parameter field, namely the "DATA BLOCK" field , which contains the data, and transmits this message to the receiver-decoder 13. Thus, the connection is established.

The second sequence of events shown (e2) is a typical sequence of data exchange operation. This sequence begins with the transmission by the receiver-decoder 13 of the message "data exchange with a remote server" (MG_OTHER), containing in the field "BLOCK_DATA" the data intended for this server. As it becomes clear, at each point in time, the receiver-decoder 13 exchanges data with only one remote server and, therefore, since this server is already defined in the connection-establishing message (e2), it is no longer necessary to indicate it during normal data exchange. The receipt of this data exchange message 1004 by the gateway 58 initiates the transfer by the gateway of the data contained in the message to said remote server, which is indicated by arrow 1005.

After that, said remote server can transmit data to a receiver-decoder (indicated by 1006, 1007), as described above.

We will describe with reference to the exchange of data indicated by 1008a, 1008b and 1009, another feature of the considered embodiment of the present invention. Mentioned message "data exchange with a remote server" (MG_REMOTE), which was transmitted from the gateway 58 to the receiver-decoder 13, includes a minimum data packet size. Therefore, the gateway 58 will not transmit messages to the receiver-decoder 13 until a certain predetermined minimum amount of data (in fact, a threshold value) is received from the remote server or until a predetermined period of time elapses after receiving the last data from this remote server (in fact - until a timeout occurs). Thus, although the arrow 1008a indicates the transfer of data from the remote server to the gateway 58, the amount of this data is less than the predefined threshold value, and therefore, no message is transmitted to the receiver / decoder 13 thereafter. Then there is another data transfer (arrow 1008b) from the remote server to the gateway 58. Based on the results of this transfer, a sufficient amount of data is received in the gateway 58, and, as a result, it transmits a data exchange message 1009, which includes data from both data transfer operations 1008a and 1008b. Similarly, a data exchange message is transmitted to the receiver / decoder 13 as soon as the amount of data received by the gateway 58 from the remote server exceeds a certain maximum value. In this case, one data exchange operation between the remote server and the gateway 58 may lead to the exchange of several messages between the gateway 58 and the receiver-decoder 13.

In the present embodiment, said time limit (timeout) is 200 ms, said minimum threshold amount of data is 128 bytes, and said maximum threshold amount of data is 512 bytes.

Although not shown in this figure, it may happen that for some predetermined time interval, which in this embodiment is 5 seconds, the gateway 58 does not receive any data from the remote server. In this case, the gateway transmits to the receiver / decoder 13 the message "gateway detected an error" (MG_ERROR) containing a parameter field of the type "ERROR_CODE", the contents of which indicate the occurrence of such an event. Subsequent actions will be determined by the receiver-decoder 13 and may include, for example, the transmission of a connection initialization message (MG_RCNX), in response to which the gateway 58 closes the TCP connection with the remote server.

As mentioned above, similar error messages can follow other events, such as an inability to connect to a remote server, loss of connection to a remote server, or an error message received from a remote server. The latter case may include the receipt by the gateway 58 from a remote server of data of an unknown type, the wrong length, unacceptable value, or having an unknown protocol version.

Referring again to Fig. 9, we describe an event of disconnection from a remote server (e3). This event is triggered by the receiver-decoder 13, transmitting the message "disconnect" (MG_DCNX) 1020. This message may include data that must be transmitted to the remote server, in the parameter "DATA BLOCK". This command and data are transmitted to the remote server (arrow 1021), and after that, the gateway 58 awaits confirmation and response data 1022 (if any). After that, the gateway 58 is disconnected from the remote server (1023) and transmits to the receiver-decoder 13 message 1024 containing the received data, if any. Although not shown in this figure (as associated with a low level protocol), the receiver-decoder 13 may then close the connection at the modem level. After that, the gateway 58 will be notified by the NAS 56 of the closure of the TCP connection.

Below, with reference to FIG. 10, the authentication procedure provided by the gateway protocol will be described. This procedure may be needed for various services, for example, support services, before organizing a data transmission channel. Gateway 58 has information about which servers require authentication before granting access, and when it receives a connection request message (MG_CNX) 1100 with respect to such a server, it responds with an authentication request message (MG_AUTHEB_REQ) 1101. Such an authentication request message does not include any parameters. After that, the receiver-decoder 13 should respond with the corresponding message 1102 "authentication". This message has a parameter containing authentication data, which may be, for example, a smart card number, as described in more detail below. This authentication data can be transmitted in a parameter of the "DATA_BLOCK" type or in one of the modifications of the considered embodiment of the present invention, in a parameter of a separate special type.

If the gateway 58 finds this authentication information correct, the authentication result will be positive (as schematically represented by event 1103), and the gateway 58 will establish a connection 1104 to the specified remote server. The gateway 58 reports a positive authentication result by sending a data exchange message 1106, which will include any data 1105 received from this remote server in response to a connection. In case of a negative authentication result, an error message (MG_ERROR) is transmitted, which has a parameter indicating the error, as described above.

Back to the system shown in FIG. 5; You can distinguish two separate types of accounts for access to Internet services, etc. using the receiver-decoder 13, namely the so-called "connection account" (connection account) and the so-called "account for the use of services" (directory account). Each connection account may contain several accounts for using the services.

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

We now describe the actions that are performed when a user logs in when connecting to the system using a connection account. It is clear that in order for the user to be identified, the data transmitted during registration must be unique. In the present embodiment, this is achieved by using a so-called MSD number, which is at least partially derived from the smart card number of the user equipment. In addition, during registration, the user must specify a data transfer protocol, which may be different depending on, for example, whether the user is trying to access via a telephone line modem connected to a computer (using, for example, Canal +'s MediaWebPC product) , or a receiver / decoder of the type commonly referred to as a “set-top box”. If you use a modem for a telephone line connection, the protocols used can be, for example, PAP, CHAP, or PPP.

Thus, the login information includes the MSD number of the user, a field identifying the type of user terminal, a field specifying the type of response data to be used, a field indicating the version number of the client equipment, and, if applicable, the domain name the so-called remote telephone user authentication service (RADIUS). Registration data will also include a password. In this embodiment, this data has the following format:

login = {msn_number} {terminal_type} {response_type} {version} [@ domain_RADIUS_name]

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

The "msn_number" field in turn consists of the following sequence of fields:

{msn_number} = {RSMC} {RSMN} {chck}

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

The second of the MSN data fields contains the removable security module number (RSMN). This field contains code that identifies this smart card when using it. Such a code is preferably predefined by the supplier of this smart card and is unique, thus allowing uniquely identifying its user. In this embodiment, the length of this field is four bytes, and it can contain fifteen digits.

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

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

The "response_type" field allows you to determine the method by which response data will be transmitted to the user. In the present embodiment, this field assumes a value of "M" when all response data should be sent through a modem, and a value of "S" when transmission of response data should occur both via satellite and through modem channels. Again, the possibility of further expansion is provided with regard to the methods of transmitting response data.

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

The optional "RADIUS_domain_name" field allows you to send a user authentication request to a third-party (third-party) authentication server, which can make it possible to provide gateways to, for example, various service providers by the corresponding third-party.

The registration data will also contain a password field, the maximum length of which in the present embodiment is 14 alphanumeric characters.

Let us now go back and describe the account for using the services, which is the basis for access to certain Internet services, for example, proxy servers with identification, email, conferences, etc. Subscriber accounts for using the services are tied to the connection account. However, unlike the connection account, the authentication of the account to use the services occurs at the application level.

As mentioned above, an account for using services allows you to use various Internet services using a receiver / decoder 13. An account for using services will usually consist of

- identifier and password;

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

- as appropriate, other data related to the services offered to the subscriber.

The mentioned identifier (in combination with a password, if applicable) is used to control the subscriber’s access to various ISP services, for example, access to the subscriber’s mailbox. Other examples are access to confidential Web sites, directories, access control for services, certificates, registration for participation in the "mailing list" (mailgroup), etc.

The said identifier can also be used to obtain a postal address in the format "identifier @ domain", in which case the subscriber may need to use his password to access the mailbox identified by the specified identifier.

Mentioned mail aliases provide the ability to receive an email server with the address "alias @ domain".

In one embodiment, multiple accounts may be associated with a single connection account for using services (a so-called "family subscription"). In this case, the user can initially indicate the number of accounts for using the services that can be created for each connection account, although it should be noted that each identifier and alias must be unique.

The term “receiver-decoder”, or “decoder” as used in this text, can mean a receiver for receiving both encoded and unencoded signals, for example, television and / or radio signals that can be transmitted by broadcasting or any another way. This term may also mean a decoder for decoding received signals. Embodiments of such receiver-decoders may include a decoder combined with the receiver for decoding received signals, such as, for example, in a set-top box, a decoder that operates in conjunction with a physically separate receiver, or a decoder equipped with additional features, such as a Web browser, or combined with other devices, such as a recording device or TV.

Naturally, the present invention has been described above with a purely illustrative example, and various modifications are possible without departing from the scope of the present invention.

Each feature disclosed in the description of the invention, as well as (as appropriate) in the claims and in the drawings, may be implemented independently or in any suitable combination.

The item numbers given in the claims are for illustrative purposes only and should not be construed as having any limiting effect on the scope of the claims.

Claims (20)

1. A method of authenticating data exchange between a receiver-decoder and a server for providing access to a remote network, comprising using for authentication data exchange a certain identifier of said receiver-decoder, said identifier being based on an identifier used to access broadcast services. 2. The method according to claim 1, wherein said identifier is stored on a removable component of said receiver-decoder. 3. The method according to claim 1, wherein said identifier is independent of a registration identifier for entering the network used with this receiver-decoder. 4. The method according to claim 1, wherein said identifier is based on a number unique to the smart card used with said receiver-decoder. 5. The method according to claim 1, wherein said remote server is a server for accessing the Internet. 6. The method according to claim 1, wherein said remote server is an account management system for using the Internet. 7. The method according to claim 6, in which said account management system for using the Internet, using said receiver-decoder identifier, creates a user account for using the Internet. 8. The method according to claim 7, in which said receiver-decoder identifier is compared by an account management system for using the Internet with a stored list of receiver-decoder identifiers that can create accounts for using the Internet. 9. The method according to claim 7 or 8, wherein said remote server comprises means for transmitting data to an Internet service provider, including the operation of providing data to said account for use by an Internet service provider to organize between a receiver-decoder and an Internet service provider bidirectional data channel. 10. The method according to claim 1, wherein said identifier is accompanied by data identifying a data channel that should be used to transfer data between said receiver-decoder and a remote server. 11. The method according to claim 1, wherein said remote server provides the receiver / decoder with access to a network having some network protocols, and the data output by the receiver / decoder is converted to data compatible with said network protocols, at a location remote from this receiver-decoder. 12. The method according to claim 11, wherein said data is converted to said data compatible with network protocols by a gateway located between said receiver-decoder and a remote server. 13. The method of claim 12, wherein said network includes a plurality of remote devices and said transformed data is transmitted by said gateway to one of said remote devices indicated in said data, thereby organizing a data channel between the receiver-decoder and said remote device. 14. The method according to item 13, wherein a message is transmitted from said receiver / decoder to said gateway using a non-network protocol, initiating the closure of said data transmission channel, and said gateway, in turn, sends a closing command to said remote device, using the Internet protocol. 15. The method according to any one of paragraphs.12-14, characterized in that before the organization of the aforementioned data channel, the gateway authenticates the identity of the receiver-decoder. 16. A device for authenticating the exchange of data between a receiver-decoder and a server for providing access to a remote network, comprising means for using to authenticate the exchange of data of some identifier of said receiver-decoder, said identifier being based on the identifier used to access the broadcast servers. 17. The device according to clause 16, where the said identifier is accompanied by data identifying the data channel that should be used to transfer data between the receiver-decoder and the remote server. 18. The device according to clause 16, where the aforementioned remote server provides the receiver / decoder with access to a network having some network protocols, said device comprising means for converting data provided by the receiver / decoder into data compatible with said network protocols. 19. The device according to any one of paragraphs.16-18 in the form of a gateway located between the said application-decoder and the remote server. 20. The device according to claim 19, where the aforementioned network includes many remote devices and said gateway is configured to transmit said converted data to one of said many remote devices indicated in said data, thereby organizing a data channel between the receiver-decoder and the specified remote device.

Images