MXPA00003213A - Modem control - Google Patents

Abstract

A modem device driver, particularly for use in a receiver/decoder (2020) for a digital broadcast system in which received signals are passed through a receiver to the receiver/decoder and thence to a television set. The receiver/decoder is controlled by a virtual machine (4007) which includes a run time engine (4008). The receiver/decoder includes a plurality of interfaces to external units, and logical driver devices for the interfaces. A device driver (500) for controlling a modem interface comprises a buffer memory (503) for receiving messages, a control memory (502) for storing control parameters, and a logic unit (501) for controlling the device driver and the flow of messages. The logic unit includes a comparator (511) for matching Event, ACK, and NACK patterns stored in the control memory against the end of messages stored in the buffer memory.

Description

MODEM CONTROL The present invention relates to modems, and more specifically to remote modem control. Find a particular application in the interconnection of application programs with physical devices, particularly, but not exclusively, in the context of receivers / decoders for digital transmission systems. The term "receiver / decoder" used herein may connote a receiver to receive encoded or uncoded signals, for example, television and / or radio signals, which may be broadcast or transmitted by some other element. The term may also connote a decoder to decode the received signals. The embodiments of these receivers / decoders may include an integral decoder with the receiver for decoding the received signals, for example, in a "top box", such as a decoder operating in combination with a physically separate receiver, or including this decoder functions additional, such as a web browser, a video recorder, or a television. The advent of digital transmission systems intended primarily to transmit television signals, particularly, but not exclusively, satellite television systems, has opened the possibility of using these systems for other purposes. One of these is to provide interactivity with the end user. As used herein, the term "digital transmission system" includes any transmission system for transmitting or broadcasting, for example, primarily digital audio-visual or multimedia data. Although the present invention is particularly applicable to a digital broadcast television system, the invention may also be applicable to a fixed telecommunications network for multimedia Internet applications, to a closed circuit television and so on. The term "digital television system" includes, for example, any satellite, terrestrial, cable and other system. The present invention finds a specific application in a digital transmission television system, wherein the received signals are passed through a receiver to a receiver / decoder, and from there to a television set. The receiver / decoder (also known as a top box or STB) decodes an MPEG-type signal compressed into a television signal for the television set. This is controlled by a remote controller manual device, through an interface in the receiver / decoder. One way to provide the interactivity described above is to execute an application in the receiver / desire-difier through which the television signal is received. It is desirable to enable a variety of applications to communicate with a variety of physical devices in a transparent manner. Our pending applications PCT / EP97- / 02115 and PCT / EP97 / 02116 describe systems in which one or more applications can be downloaded through an upper box (STB), and can communicate with physical devices in the STB, such as parallel interfaces and in series, and smart card readers, by means of a device unit for each device, and a global administrator of the devices. In accordance with the present invention, it has been proposed to provide the capability for an upper box to be interconnected with a variety of different signal channels, such as modem, a serial channel, a parallel channel, an MPEG channel (signal from compressed and encoded video), card scan readers, and so on. The top box includes a virtual machine that includes a runtime machine. The virtual machine is coupled with a device manager, which in turn is coupled with the physical interfaces of the different channels by means of the devices and the units of the devices. The term MPEG refers to the data transmission standards developed by the working group of the International Standards Organization, "Motion Pictures Expert Group", and in particular, but not exclusively, the MPEG-2 standard developed for digital television applications, and stipulated in documents ISO 13818-1, ISO 13818-2, ISO 13818-3 and ISO 13818 -4. In the context of the present patent application, the term includes all variants, modifications, or developments of MPEG formats applicable to the digital data transmission layer. As noted above, one of the preferred channels is a modem. The main object of the present invention is to provide improved control of this modem. This is achieved by providing an improved device unit for controlling the modem. For the present purposes, the precise nature of any distinctions between devices and device units is not important, and the term "device unit", as used herein, should be construed to include any form of interface between the hardware and the device. an application, unless the context requires otherwise. According to the invention, there is provided a device unit for controlling and communicating with a modem which comprises a buffer for receiving and storing messages from the modem, a control memory for storing control parameters, and a logic unit for controlling the unit of the device and the message flow, wherein the logic unit includes a comparator for coupling the patterns stored in the control memory against the messages stored in the buffer, in order to generate a signal to be sent to an administrator. devices coupled with the device unit. The device manager will normally be configured to control a plurality of device units, and pass messages between the device units and one or more applications, but the term "device manager" is intended to encompass any entity that can control the device unit; it can be a control application itself. Other significant features of the invention will become clearer from the following detailed description and from the claims. The apparatus is most preferably implemented as a device driver in a receiver / decoder, for example for a digital transmission system, as described in a pending applications PCT / EP97 / 02106 - 02117. In this implementation, the drive device it can operate under the control of an application, through the device manager, providing a convenient and flexible configuration to control the unit of the device. The preferred application is executed in an interpreted language, and the unit of the device is preferably compiled. Preferably, the comparator compares the stored patterns against a predetermined final section of the message. The patterns may be of a plurality of types, and there may be a plurality of patterns of the same type. These types of patterns can include Events, ACKs (positive econo- mies), and NACKs (negative acknowledgments), the generated signal indicating the type of coupled pattern. The unit of the device can be configured to send the signal to the device manager, by adding it to the message received through the modem. Commands can be passed between the device unit and the device manager in the form of Calls, which set the parameters on the device unit, IOs, which send control signals and data to the device units and Events, which indicates the detection of patterns or the reception of the message or transmission problems to the device manager. A form of Call command comprises at least one pattern setting command to define one or more patterns that must be searched by the comparator. There are preferably three subtypes of pattern establishment commands that define the patterns to be searched for, with a pattern setting the command for each type of pattern. The or at least one pattern setting command can be configured to define a plurality of patterns to be coupled, each pattern having an associated event signal that will be generated upon detection of the corresponding pattern. The patterns to be searched can be stored in respective sub-areas of the control memory. In an alternative way, the patterns to be searched can be stored in a single continuous area of the control memory. In one embodiment, when a plurality of couplings are present, only the last coupling is actuated. In an alternative way, when a plurality of couplings are presented, the type according to a priority sequence previously determined between the different coupling types is indicated. The functions of the device unit can be implemented in the hardware, for example, in a dedicated integrated circuit; This can provide a better operating speed. Preferably, however, at least some of the device unit is implemented in the software, preferably executed by the processing element that executes the application; this allows for greater flexibility, requires fewer components, and allows the device unit to be updated more easily. The present invention extends to a method for controlling and communicating with a modem using a device unit comprising an intermediate improvement and a control memory, this method comprising the steps of: receiving and storing messages from the modem in the buffer memory; storing the control parameters in the control memory, and coupling the patterns stored in the control memory against the messages stored in the buffer memory, to generate a signal to be sent to a device manager coupled with the unit of the device. Any of the above characteristics can be combined with each other, in any appropriate combination. The characteristics of the apparatus can be applied to aspects of the method, and vice versa. The preferred features of the present invention will now be described, purely by way of example, with reference to the accompanying drawings, in which: Figure 1 is a schematic diagram of the receiver / decoder interfaces. Figure 2 is a functional block diagram of the receiver / decoder. Figure 3 shows the general logical organization of the present unit of the device. Figure 4 shows in more detail the logical organization of the pattern handling aspects of the present device unit. Figure 5 illustrates the structure and storage of messages.

B SECTORS OF THE RECEIVER / DECODER To assist in the understanding of the device unit, the preferred platform on which the device unit operates, our digital transmission receiver / decoder, will be briefly described first. Referring to Figure 1, a receiver / decoder 2020 or upper box is schematically illustrated for use in a digital interactive television system, where the unit of the mode device is intended to be installed. Details of an appropriate digital interactive television system can be found in our pending PCT / EP97 / 02106-02117 applications, to which reference should be made, and whose disclosures are incorporated herein by reference. For ease of reference, the parts described in greater detail in the aforementioned descriptions are generally designated by the reference numerals used in those descriptive memories. As described in more detail in the aforementioned descriptions, referring to Figure 1, the receiver / decoder 2020 includes several interfaces; specifically, a 4028 tuner for MPEG signal flow, a 4030 serial interface, a parallel 4032 interface, and two 4036 card readers, one for a smart card that is part of the system, and one for bank cards (used to make payments, banking at home and similar). The receiver / decoder also includes an interface 4034 with a back channel in modem 4002 to the product of the television signal, such that the user can indicate preferences and the like back to the product of the television signal (program ). The receiver also comprises a Run Time Machine 4008, a Device Manager 4068, and a plurality of Devices 4062 and device units 4060, for executing one or more applications 4056 (see Figure 2). For the purposes of this specification, an application is a piece of a computer code for controlling high-level preference functions of the receiver / decoder 2020. For example, when the end user places the focus of a remote controller on an object of button that looks on the screen of the television set 2022, and presses a validation key, the sequence of instructions associated with the button is executed. An interactive application proposes menus and executes commands at the request of the end user, and provides data related to the purpose of the application. The applications can be resident applications, that is, they can be stored in the ROM (or FLASH memory or other non-volatile memory) of the receiver / decoder 2020, or they can be transmitted and downloaded into the RAM or flash memory of the receiver / decoder 2020. Some examples of applications, described in greater detail in the aforementioned applications, are: A Start Application, which is an adaptive collection of modules that enable the 2020 receiver / decoder to be immediately operational in the MPEG-2 environment. A Startup Application, which allows any application, whether downloaded or resident, to run on the receiver / decoder 2020. A Program Guide, which is an interactive application that gives complete information about programming. A Pay per View application that is an interactive service available on each PPV channel of digital television package, to enable the end user to purchase the current event. A PC download application, which makes it possible for an end user to download computer software using the PC download application. An application of Scrolling Finder, comprising a cyclic video transmission of images, navigating the end user through the buttons on the screen.

A Telecompras application, which makes it possible to transmit offers of items for sale to the receiver / decoder 2020, and which are displayed on television 2022, and which make it possible for the user to select a particular item to buy it. The applications are stored in the memory locations of the receiver / decoder 2020, and are represented as resource files. The resource files comprise files of graphical object description units, variable block unit files, instruction sequence files, application files, and data files, as described in greater detail in the aforementioned descriptive memories. In the MPEG data stream, each module comprises a group of MPEG tables. Each MPEG table can be formatted as a number of sections. In the MPEG data stream, each section has a "size" of up to 4 kbytes. For data transfer via the serial port and in parallel, for example, the modules are similarly divided into tables and sections, varying the size of the section with the means of transport. The modules are transported in the data stream MPEG in the form of data packets of typically 188 bytes within the respective types of data streams, for example, video data streams, audio data streams, and teletext data streams. Each packet is preceded by a 13-bit packet identifier (PID), one PID for each packet transported in the MPEG data stream. A program map table (PMT table) contains a list of the different data streams, and defines the content of each data stream according to the respective PID. In addition to the programs, certain PIDs can be assigned to the applications or other data contained in the data stream, with the PID identified using the PMT table. The decoder contains a memory divided into a RAM volume, a FLASH volume, and a ROM volume, but this physical organization is distinct from the logical organization. The memory can be further divided into memory volumes associated with the different interfaces. From one point of view, memory can be considered as part of the hardware; from another point of view, the memory can be considered as supporting or containing the entire system shown apart from the hardware. The system can be considered as centered on a runtime machine 4008 that is part of a virtual machine 4007. This is coupled to the applications on one side (the "high level" side), and on the other side (the "low level" side), by means of different intermediate logic units discussed below, with the 4061 hardware of the receiver / decoder. The hardware of the receiver / decoder can be considered as including the different ports or interfaces as discussed above (the 2030 interface for the 2026 handset, the MPEG 4028 interface, the 4030 serial interface, the 4032 parallel interface, the interphase interfaces the card readers 4036, and the interface 4034 for the back channel in modem 4002). With reference to Figure 2, different applications 4057 are coupled to unit 4007; some of the most commonly used applications may be more or less permanently resident in the system, as indicated in 4057, while others will be downloaded to the system, for example, from the MPEG data stream, or from other ports, as require The unit 4007 includes, in addition to the runtime machine 4008, some resident library functions 4006, which include a toolbox 4058. The library contains several functions in C language used by the machine 4008. These include data manipulation. , such as compression, expansion, or comparison of data structures, line drawing, and so on. The library 4006 also includes information about firmware 4061 in the receiver / decoder 2020, such as the hardware and software version numbers, and the available RAM space, and a function used when a new 4062 device is downloaded. they can be downloaded to the library, stored in the FLASH or RAM memory. The runtime machine 4008 is coupled with a device manager 4068, which is coupled with a set of devices 4062, which are coupled with the device units 4060, which in turn are coupled with the ports or interfaces. In broad terms, a device unit can be considered as defining a logical interface, in such a way that two different device units can be coupled to a common physical port. A device will typically be attached to more than one device unit; if a device is coupled to a single device unit, the device will normally be designed to incorporate the total functionality required for communication, so that the need for a separate device unit is obviated. Certain devices can communicate with each other. As will be described later, there are three forms of communication from the 4062 devices to the runtime machine: by means of variables, buffer zones, and events that are passed to a set of event rows. Each function of the receiver / decoder 2020 is represented as a device 4062. The devices can be local or remote. Local 4064 devices include smart cards, SCART connector signals, modem, serial and parallel interfaces, an MPEG audio and video player, and an MPEG section and table extractor. Remote 4066 devices, executed at a remote location, differ from local devices where the authority or system designer must define a port and a procedure, rather than a device and a device unit provided and designed by the manufacturer of the device. receiver / decoder. When a new 4062 device is created, it can be installed in the existing receivers / decoders 2020, by downloading the relevant application 4056 from the transmission center. This download is made to the receiver / decoder 2120 by an application 4056, which verifies the hardware and software versions, and if they are correct, loads the software module that represents the new device 4062, and asks for a procedure from the library 4006 to install the new device code inside the firmware (in Flash memory). This can provide a flexible and secure installation of new functions within the receiver / decoder 2020 if it affects the rest of the software. The device manager 4068 is a common software interface between the application 4056 and the specific functions of the receiver / decoder 2020. The device manager 4068 controls access to the devices 4062, declares the reception of an unexpected event, and manages the memory shared. The run-time machine 4008 is run under the control of the microprocessor and a common application programming interface. They are installed in each receiver / decoder 2020, in such a way that all the receivers / decoders 2020 are identical from the point of view of the application. The machine 4008 executes the 4056 applications in the receiver / decoder 2020. It executes interactive applications 4056, and receives events from outside the receiver / decoder 2020, displays graphics and text, calls the devices for services, and uses the functions of the library 4006 connected to the machine 4008 for a specific computation. The runtime machine 4008 is an executable code installed in each receiver / decoder 2020, and includes an interpreter to interpret and execute the applications. The 4008 machine can be adapted to any operating system, including a single task operating system (such as MS-DOS). Machine 4008 is based on process sequencing units (which take different events, such as one click, to perform different actions), and contains its own programmer to manage the rows of events from the different hardware interfaces. It also handles the display of graphics and text. A process sequencing unit comprises a set of action groups. Each event causes the process sequencer unit to move from its current action group to another action group, depending on the character of the event, and execute the actions of the new action group. The machine 4008 comprises a code loader for loading and unloading applications 4056 in the memory 2028 of the receiver / decoder. Only the necessary code is loaded into the RAM or Flash memory, in order to ensure optimal use. The downloaded data is verified by authentication mechanism, to prevent any modification of an application 4056, or the execution of any unauthorized application. The machine 4008 further comprises a decompressor. When you compress the application code (a form of intermediate code) to save space and quickly download from the MPEG-2 transport stream, or by means of an integrated receiver / decoder mode, the code must be decompressed before loading it into RAM. The machine 4008 also comprises an interpreter to interpret the code of the application, in order to update different variable values, and determine the changes of state, and an error verifier. Before using the services of any 4062 device, a program (such as a sequence of application instructions) must be declared as a "client", that is, a logical path to the 4062 device or 4068 device manager The administrator gives the client a customer number that is referenced in all accesses to the device. A device 4062 can have several clients, the number of clients for each device 4062 being specified depending on the type of device 4062. A client is introduced to the device 4062 by a procedure "Device: Open Channel". This procedure assigns a customer number to the customer. A client can be taken from the client list of the 4068 device manager using a "Device: Close Channel" procedure. The access to the devices 4062 provided by the device manager 4068 can be synchronous or asynchronous. For synchronous access, a "Device: Call" procedure is used. This is a means to access the data, which are immediately available, or a functionality that does not involve waiting for the desired response. For asynchronous access, a "Device: I / O" procedure is used. This is a means to access the data, which involves waiting for a response, for example, scanning the tuner frequencies to find a multiplex, or getting back a table from the MPEG stream. When the requested result is available, an event is placed in the row of the machine to signal its arrival. An additional procedure "Device: Event" provides a means to manage unexpected events. As noted above, the main cycle of the runtime machine is coupled with a variety of process sequencing units, and when the main cycle encounters an appropriate event, the control is temporarily transferred to one of the process sequencing units. Accordingly, it can be seen that the basic system provides a platform that has considerable flexibility to enable an application to communicate with a variety of devices.

MODEM DEVICE UNIT The precise details of the implementation of the different functions, and the distribution between hardware and software, are a matter of choice for the implementer, and will not be described in detail. however, it is noted that there are dedicated integrated circuits capable of performing the operations required in the present commercially available device unit, or can be easily designed, and can be used as the basis for a hardware accelerator, or more preferably, can be used. modify to produce a dedicated hardware accelerator, to implement several of the required operations, thereby reducing the processing power required to run the software. However, the required operations can be implemented in the software if sufficient processing power is available. The unit of the device can be considered to comprise a series of individually accessible functional units, each of which will be referred to hereinbelow as a "command". Each command is interconnected with an application under the control of the 4068 device manager, by means of one of the three standard procedures mentioned above, which are common for other devices. The information can be passed between an application and the device by means of parameter tables. For ease of reference, the three basic procedures are briefly summarized below: 1) Device: Call. This procedure can be used by an application to perform synchronous commands or data transfer. The execution of the application is suspended until the control is returned when the operation has been completed by the unit of the device; this allows operations that must be performed in strict sequence to be controlled in a reliable manner. 2) Device: 1/0. This procedure allows asynchronous operation. That is, an application can send a request for a particular data transfer or function to be performed by the device unit, and the execution of the application can continue while the data transfer or function is performed by the device unit . 3) Device: Event. The event trap function makes it possible for the device to point events to an application, and for the application to take a particular action in response to the event, regardless of the code that the application is executing at the time the event is signaled; effectively, the application is interrupted. Events can be prioritized. Events can be used to signal events that occur in the interface, such as a busbar reset, or to provide asynchronous command monitoring, for example, signaling the completion of a requested data transfer. The present device unit is shown as the block 500 (Figure 3), which comprises a logical unit 501, a control memory 502, and a buffer 503. These two memories are logically different, but both are part of the same memory physical (more specifically, the buffer will be part of the RAM, and the control memory can be part of the RAM or FLASH). The device unit is coupled with the device manager 4068, and with the modem 550 interface, as shown. Each command will form a part of the logical unit 501, and can operate on portions of the control and / or intermediate memory. In broad terms, the modem works in the narrow sense of modulating and demodulating signals made by a modem unit, which can be incorporated into the interface 550, or can be connected to it. The control and administration of the information flowing through the interface, apart from these narrow modem functions, is done by the unit of the device 500. As described above, the communication between the devices / device units and the administrator of 4068 devices is done through three types of procedures: Call IOs, and Events. For the procedures used by the device 500 unit, Calls are used to send different parameters from the application through the device manager to the device unit; the IOs are used to send commands from the application through the device manager to the device unit; and Events are used to send messages from the device unit via the device manager to an application. The commands provided in a device embodying the invention will now be described. Each command can be accessed by an application by passing a command identifier as a parameter through one of the three previous standard procedures. It is not necessary to provide all the commands described below, and the functions of the commands can be altered. Although the commands can be provided or altered in an independent manner, as will be appreciated, certain synergistic benefits of the combined functionality provided by the described commands accumulate. The commands will be described in terms of the features and functions provided by each command, along with optional and preferable features. With the information given and the specifications provided, the actual implementation of these features should be direct to an expert in the field, and the precise details are left to the implementer. As an example, each command could be implemented in the software, preferably written in the programming language C, and preferably compiled to run on the processor used to run the application; however, the device unit can be run on a separate processor, and some or all of the commands can be implemented using dedicated hardware. The Call 10 commands can signal information, or pass parameters back to an application, by setting values in a parameter table stored in memory, whose address is passed to the device. In more detail, the procedures or commands used are as follows: Device: Call Set: set buffer sizes of intermediate zone, stopwatch delays. Set Comm: sets the data size (from 5 to 8 bits), parity, transmission speed. Set Car: sets the pause and delay character. Set control: enable / disable the signal sent to remote equipment. Set pattern: sets the patterns to be searched. Device 10: Command: sends a command to the unit of the device without interpretation. Send: send the data to the unit of the device. Action: send a command to the unit of the device with interpretation. Disconnect: disconnects the unit from the device. Device: Event. Receive: indicates receipt of a message. Off: indicates a transmission problem. A procedure also contains an error code to report back, and (with the exception of the Event procedure: disabled), a call report, to report back from the device unit to the device manager. Also, a Call procedure or 10 contains a memory address where you will find the information that is being sent (parameters, etc.). The functions of most of these commands are largely conventional. However, the present system contains a special command, the Call command, Set Pattern. This command defines one or more patterns that are to be searched by the logical unit 501. The command contains a memory address, and the memory contains, starting that address a series of patterns. (More specifically, the first location in the memory contains the number of patterns, followed by the individual patterns, and each individual pattern in the memory includes a header that gives the length of that pattern). In general, three different types of pattern can be established, to generate Events, ACKs (positive acknowledgments), and NACKs (negative acknowledgments). Of course, it would be possible to include the three pattern types in the same command, with the header of each pattern identifying the type of that pattern. However, it is preferred to use three sub-forms of command, for all three pattern types. Therefore, the ACK and NACK patterns, which may be required to detect a reliable reception of a command by the modem, are preferably set using dedicated commands, and all other patterns are used to trigger an event, assigned to each pattern a number to make it possible for the patterns to be distinguished. These commands establish a memory area 510 (Figure 4) in the control memory 502; this memory zone has three segments, which contain the Event, ACK, and NACK patterns, respectively. The logic unit 501 contains a comparing unit 511 which is coupled to this memory area. The memory area 510 may consist of the memory areas specified by the three Set Pattern commands. In this case, the three segments of the memory area can be physically in different regions of the memory. The comparing unit 511 will have to store the start addresses of the three segments, and access the different patterns, use the number of patterns (as stored at the beginning of each segment), and the lengths of the individual patterns, to determine The precise locations of the patterns, and access to each of them in turn as required. In an alternative way, the comparing unit 511 can initialize the memory by setting the memory area 510 as a pattern table at a previously determined location. When a message is received, it is passed to a buffer area in buffer 503. This memory is divided into a plurality of buffer areas 512, such that the message may occupy more than one buffer area.; Nevertheless, the message space is logically continuous for any individual message. If pattern matching is being performed, the comparator 511 searches for the last 32 characters of the message to be coupled with any of the patterns stored in the memory area 510. If a match is found, then the match type is written (Event, ACK, or NACK) in the header of the message as it was stored in the buffer zone, and / or some appropriate action is taken by the device unit. It should be noted that ACK and NACK pattern detection can be used to detect expected modem responses, for example, when commands are being sent while the modem is offline. Other signals from the modem are coupled with a separate list of patterns, and used to trigger events; for this reason, the establishment of the ACK and NACK patterns is preferably done in an independent way from the establishment of a list of patterns corresponding to unexpected events, or other messages from the modem. In this way, it is possible for an application to communicate with any of a variety of modems. For example, many modems can generally conform to a standard, such as the Hayes standard, for sequences of instructions and responses, but may have additional features, for which a proprietary response sequence is generated. In such a case, the ACK and NACK patterns will be set to the standard patterns, and the response sequences corresponding to the additional characteristics can be assigned to the event signals. Figure 5 shows a message 520 resident in the buffer 503. The message consists of a header 521 and a body 522. In this case, the message is physically divided between two buffer zones 512 and 512 '. The comparator 520 performs pattern matching (i.e., searches for a match with the patterns stored in the memory area 510), over the last 32 character region 523 of the body 522 of the message. The nature of any match found is inserted into the message header 521 in the buffer. It is possible that there is more than one agreement, in two ways. First, two patterns of the same type can be presented (in different positions in the last 32 characters of the message). This double agreement can be ignored, that is, it can be treated as a single concordance. Second, two concordances of different types can be presented (again, in different positions in the last 32 characters). Depending on the circumstances, the comparator 511 can be configured to indicate the type of match according to a predetermined priority sequence between the different types of matches, or which of the patterns is closer to the end of the message. In Command mode, that is, when the modem parameters are being set, this technique can be used to send a command message to the device unit. In a message it is interpreted by the unit of the device, and it is not sent through the interface until, for example, a data server. For each command sent, the unit of the device looks for a pattern in the return message, and responds to the unit of the device in accordance with the same. In this mode, it is also possible to receive a message through the interface if you have sent a command. This can happen, for example, if a ring voltage is detected. The device unit must also look for a pattern in the list of event patterns in that case. In online mode, the modem is connected to a data server, and it is possible to receive messages from this server. The device unit searches for a pattern in the last 32 characters received from the data server. The above commands and events are merely illustrative, and the invention can be implemented in a variety of ways, and in particular, some commands can be combined with others that perform similar functions, or some can be omitted in simplified implementations. The hardware and software implementations of each of the functions can be mixed freely, both between commands and within a single command. It will be readily understood that the functions performed by hardware, computer software, and the like, are performed on, or using, electrical signals and the like. Software implementations can be stored in the ROM, or they can be stored or patched in the FLASH. It will be understood that the present invention has been described above purely by way of example, and that modifications of the detail may be made within the scope of the invention. Each feature disclosed in the description, and (where appropriate) in the claims and drawings, may be provided in an independent manner, or in any appropriate combination.

Claims (29)

1. A device unit for controlling and communicating with a modem which comprises a buffer for receiving and storing messages from the modem, a control memory for storing control parameters, and a logic unit for controlling the device unit and the flow of the device. messages, wherein the logic unit includes a comparator for coupling the patterns stored in the control memory against the messages stored in the buffer, in order to generate a signal to be sent to a device manager coupled with the unit of the device.

A device unit according to claim 1, wherein the comparator compares the stored patterns against a previously determined final section of the message.

3. A device unit according to claim 1 or 2, wherein the patterns are of a plurality of types, and there may be a plurality of patterns of the same type.

4. A device unit according to claim 3, wherein the types of patterns comprise Events, ACKs (positive acknowledgments), and NACKs (negative acknowledgments), the generated signal indicating the type of coupled pattern.

5. A device unit according to claim 4, wherein the device unit sends the signal to the device manager, adding it to the message received through the modem.

A device unit according to claim 4 or 5, wherein the commands are passed between the device unit and the device manager in the form of Calls, which establish parameters in the unit of the device, IOs, which send control signals and data to the units of devices, and Events, which indicate the detection of patterns or reception of messages or transmission problems to the device manager.

A device unit according to claim 6, wherein a form of Call command comprises at least one pattern setting command to define one or more patterns to be searched by the comparator.

A device unit according to claim 7, wherein there are three subtypes of pattern establishment commands that define patterns to be searched, a pattern establishment command for each type of pattern.

A device unit according to claim 7 or 8, wherein the or at least one pattern setting command is configured to define a plurality of patterns to be coupled, each pattern having an associated event signal that it will be generated by detecting the corresponding pattern.

10. A device unit according to any of claims 4 to 9, wherein the patterns to be searched are stored in respective sub-areas of the control memory.

11. A device unit according to any of claims 4 to 9, wherein the patterns to be searched are stored in a single continuous area of the control memory.

12. A device unit according to any of the preceding claims, wherein, when a plurality of matches are presented, only the last match is acted upon.

A device unit according to any of claims 1 to 11, wherein, when a plurality of matches are presented, the type according to a previously determined priority sequence between the different match types is indicated.

14. A receiver / decoder incorporating a device unit according to any of the foregoing claims.

15. A method for controlling and communicating with a modem using a device unit comprising a buffer and a control memory, this method comprising the steps of: receiving and storing messages from the modem in the buffer; store the control parameters in the control memory; and coupling the patterns stored in the control memory against the messages stored in the buffer memory, to generate a signal to send to a device manager coupled to the unit of the device.

16. A method according to claim 15, wherein the stored patterns are compared against a predetermined final section of the message.

17. A method according to claim 15 or 16, wherein the patterns are of a plurality of types, and there may be a plurality of patterns of the same type.

18. A method according to claim 17, wherein the types of patterns comprise Events, ACKs (positive acknowledgments), and NACKs (negative acknowledgments), indicating the generated signal the type of coupled pattern.

19. A method according to claim 18, wherein the device unit sends the signal to the device manager, adding it to the message received through the modem.

20. A method according to claim 18 or 19, wherein the commands are passed between the device unit and the device manager in the form of Call-das, which establish parameters in the unit of the device, IOs, which send control signals and data to the units of devices, and Events, which indicate the detection of patterns or reception of messages or transmission problems to the device manager.

21. A method according to claim 20, wherein a form of Call command comprises at least one pattern setting command to define one or more patterns to be searched in the control memory.

22. A method according to claim 21, wherein there are three subtypes of pattern establishment commands that define patterns to be searched, a pattern establishment command for each type of pattern.

23. A method according to claim 21 or 22 wherein the or at least one pattern setting command is configured to define a plurality of patterns to be coupled, each pattern having an associated event signal that will be generated at detect the corresponding pattern. 2 .

A method according to any of claims 21 to 23, wherein the patterns to be searched are stored in respective sub-areas of the control memory.

25. A method according to any of claims 21 to 23, wherein the patterns to be searched are stored in a single continuous area of the control memory.

26. A method according to any of claims 15 to 25, wherein, when a plurality of matches are presented, only the last match is acted upon.

27. A method according to any of claims 15 to 25, wherein, when a plurality of matches are presented, the type according to a priority sequence previously determined between the different match types is indicated.

28. A device unit for controlling and communicating with a modem substantially as described herein.

29. A method for controlling and communicating with a modem using a device unit substantially as described herein.