ITRM20010507A1 - TECHNIQUE OF ACCESS TO COMPANY SERVICES, VIA THE MOBILE PHONE NETWORK, USING INTERNET PROTOCOLS. - Google Patents

Description

2 DESCRIPTION

2.1 Field in which the invention is carried out

The present invention refers in general to remote automated services provided by companies to their customers or their employees, more particularly it deals with a series of procedures implemented on integrated network architectures, which allow the provision of services (e.g. services banking, logistics, transport, etc.) using different enabling technologies, made available by a cellular telephone network (SMS, SIM Tool Kit, WAP) and the most common internet protocols (HTTP, E-MAIL, FTP, etc. ).

2.2 Acronyms and definitions

ASCII American Standard Cod for Information Interchange

B2C Business To Consumer

B2E Business To Employee

CGI Common Gateway Interface

CS Service Center

FTP File Transfer Protocol

GW Gateway

HTML Hyper Text Mark-up language

HTTP Hyper Text File Transfer Protocol

ODBC Open Data base Connectivity

OTA Over the Air

QoS Quality of Service

SM Short Message

SMS-C Short Message Service Center

UCP Universa! Computer Protocol

URL Unifòrm Resource Locator

VAS Value Added Service

WAP Wireless Application Protocol

MS Mobile Station

2.3 State of the Technique

In the last decade, the development and exponential growth of the Internet has made it possible for public access to information / transactions, at a distance, of a commercial and financial nature. Thus, new forms of distance information, purchase, sale, trade in general of goods and services have emerged. This type of operation is currently referred to as "e-business". Above all, the increase in the number of people using the internet has made this type of activity extremely popular. Banks, insurance companies, transport companies have made significant investments in this area in an attempt to make their services accessible remotely by customers and employees, thus developing B2C and B2E services.

E-business has spread primarily in the world of fixed networks and then on the INTERNET network.

The recent technological developments of the WIRELESS networks of mobile radio operators have given a further boost to the development of these services.

In fact, a series of developments have been made to allow access to the same services both via the Internet and therefore with a computer and via a mobile terminal (access to information anywhere and in any place). In addition, a whole series of new services with peculiarities linked to mobile networks have been created (for example, location services). Generally, for mobile access to e-business, companies must create new applications compared to those created for access from the INTERNET. This is because the protocols of the mobile network are generally different from those used on fixed networks, as these protocols are optimized for the lowest transmission band and for the level of presentation of the contents typical of a mobile phone display.

2.4 Objectives and requirements of the application

The purpose of the present invention is to use the short message technology to access company services by means of protocols typical of the INTERNET network, without therefore forcing companies to develop applications other than those already available for the INTERNET. The same company application used to give remote access to services on the INTERNET can be used to give the same services on a mobile phone. The company's information system can be connected to the system object of the present invention by means of INTERNET network protocols such as HTTP, FTP, SMTP.

The end user of the service can use any terminal capable of sending / receiving short messages.

It is also possible to simplify the use of the service to the user by using the Sim Toolkit technology which avoids the user having to type long strings of text on the terminal. The system object of the present invention allows the end user to use 2 types of services: clean and push.

Clean type services

The pulì type services provide for requests for information sent by the user of the service to the company, by means of suitable short messages sent to a number of the GSM network associated with that company. Each query by the user can correspond to one or more answers from the company.

The messages that are generated by users to access a specific company service can be subjected to a syntactic check. If the syntax is correct, the application forwards the request to the company, otherwise an appropriate error message returns to the Qiente. It is important to point out that the user of the service can also belong to a different cellular telephone operator.

Push type services

Push-type services require the company, spontaneously, to send information to the user (without having to take into account who is the operator of the mobile radio network to which the user belongs).

More generally, the service provides for the transmission of information to a list of GSM mobile phones.

The user has the possibility to activate / deactivate the service (on company systems) through the use of a specific message.

The data sent by the company to the application is subjected to a syntactic check. If the syntax is correct, the application continues processing, otherwise it generates an appropriate error message and processing is stopped.

In addition to the push and clean services, there are other services that the system is able to offer.

Flow Control Services (Status Report)

When you send a short message, cellular networks allow you to know (through notification messages) if the message has been delivered to the recipient or queued waiting to be delivered to the user.

The system of the present invention is able to manage all the notifications that the cellular network sends to it. It can also make the set of notifications in which it is interested available to the company, both for clean and push type services.

Management services

The management services can allow the network operator:

* to check and manage the status of the processes;

* to act on some configuration parameters to customize the service, based on the needs of a given company.

These services are accessible through a client / server architecture in order to allow access from a remote location.

Architectural services

The system object of the invention is structured in such a way as to guarantee:

- modularity

- parametricity

- scalability

- configurability

- platform independence

Application Monitoring Services

In services where good reliability and availability is required, monitoring is an indispensable tool for the immediate identification of any anomalies.

The end-to-end monitoring of the service adapts to the characteristics of the service. For monitoring the service, a controller user is defined that adapts to the service. By means of an appropriate automaton composed of a cellular device capable of sending short messages, the service is accessed to verify that everything is working correctly. The time intervals between one access and the next can be dynamically varied.

Depending on the service itself, a series of types of monitoring are available. In the case of sending and waiting for messages from the company, the user controlling the automaton sends a message to the service and receives a series of messages in return.

If the access of the automaton is based on a particular syntax of the message, it is necessary for the Company Manager, the Service provider, to agree this message with the operator. In general we can have two cases for the tracking message:

* The automaton control user sends a message belonging to the set of messages of the service for which one of the procedures already present within the service itself is used. * It is not possible to use one of the messages defined for the service, it is necessary for the service provider to define a particular service that manages the monitoring.

Similarly, we can have two cases for the company's reply message to the automaton's request message.

* The Company replies with a message belonging to the protocol of the service for which one of the procedures already present within the service itself is used, therefore the return message will be the one provided for by the protocol itself.

* The Company Client builds an ad hoc procedure for monitoring the application. In this case, for maximum control it may be sufficient for the company to respond with the echo of the message received. This may require the company to set up its own application to recognize the controlling user either on a telephone number basis or on a sent message basis.

The above is useful for monitoring clean type services. The system object of this patent is however able to monitor also push type services.

The controlling user expects a message from the company at regular intervals. The company must provide precise information on the message it intends to send periodically.

Reliability services

The patented system guarantees data consistency in case of failures or crashes SW and HW.

The SW / HW architecture can include replication or dustering mechanisms in order to guarantee service delivery in the event of failure.

For sensitive system data, the Backup policies typical of the network manager's operation can be followed.

2.5 Description of functional specifications relating to an embodiment.

The invention will be more clearly defined and the objects listed above and others will have due importance from the reading of the following description relating to specific embodiments of the invention with reference to the attached figures in which:

FIGURE 1 is the indicative scheme of the system architecture;

FIGURE 2 is a diagram relating to a particular application according to the present invention;

FIGURE 3 is a diagram relating to a different functionality of the application of Figure 2. It should be emphasized that the invention is not limited to the embodiments described, and the person skilled in the art will easily identify, on the basis of the teaching contained in the attached claims, subsequent implementations dependent on the main ones described above.

In Rg. 1 shows a diagram generated in the network structure relating to the present invention. The information system of Company 1 works with system 2 residing at the cellular telephone network operator for the various Push, Pulì and Report status operations. These operations allow the provision of services to the generic user 4 through the access network 3.

The double arrow symbol that interconnects the company information system 1 with the network operator's system 2 and the latter with the cellular network itself, indicates an interoperability relationship between the various entities and above all highlights the action active connection (to be understood not only in the sense of communication management) carried out by the system object of the invention of the cellular network operator.

2.6 Communication vs the company in HTTP

2.6.1 Description of the service

2.6.1.111 service

The service allows a company to send SM messages to mobile terminals and to receive messages from them, through the use of an HTTP-based software interface.

In particular, the pulì service allows the mobile user to request information from the company by sending an appropriately structured SM message; the company responds to the user with an SM message containing the requested information.

The push service allows the company, on its own initiative, to send SM messages containing information to the mobile user.

The HTTP software interface can be configured to make the notification on the outcome of the SM message delivery available to the company, to manage the activation of the service for the mobile user, and to provide a HELP service with the syntax of the commands that can be used and their description.

2.6.1.2 Logical architecture

The service involves the interaction of the following systems:

• Mobile terminal

• GSM network of the operator

• Operator infrastructure

• Client company

The operator's infrastructure is the system that allows the provision of VAS services using various enabling technologies supported by the GSM network (SM, WAP, IVR, Internet, etc. ..).

The HTTP software interface resides in the operator's infrastructure and acts as an HTTP Client for the company that assumes the role of web server.

2.6.1.3 Clean service

The pulì service is characterized by the following logical steps:

• The mobile terminal sends an SM message to the company;

• the system translates the SM message into the web page address (URL) associated with the requested service, to be sent to the company using the HTTP (GET) protocol; • the company replies to the URL received by sending to the system in HTTP mode, an HTML page containing the text of the reply and the recipient (telephone number of the terminal; alternatively, the User Code that is assigned following the activation of the service can be indicated );

• the system processes the HTML page received and forwards an SM message containing the reply text to the recipient.

2.6.1.3.1 Request for information from the mobile user

The use of the pulì service by a mobile terminal takes place by sending an appropriately structured SM message to a particular number that identifies the company.

There is a maximum time to receive the reply from the company; after this time without having obtained the requested information, the system sends a courtesy message to the terminal due to the temporary unavailability of the service.

To facilitate the use of the service, the company has the possibility of making a Help service available to the mobile user; this service, managed by the system, can be called up from the terminal via an SM message and provides the list of commands, a description of the same and the relative syntax.

2.6. 1.3.2 Communication between the system and the company

The communication of the mobile operator's systems to the company takes place through the establishment of a session over the HTTP protocol.

The request for information made by the terminal via an SM message is translated into a URL request to the company server. The HTTP software interface residing in the operator's infrastructure therefore takes care of generating the URL to be sent to the company server, based on the format of the SM message and the information indicated in the configuration form.

On the format of the SM message generated by the terminal, if indicated in the configuration form by the company, the HTTP software interface performs a syntactic check in order to differentiate the URL to be invoked according to the SM received; if an anomaly is found, the interface sends an appropriate error message to the terminal and does not perform any GET to the company's web server. The error message sent is configurable and is agreed between the company and the operator.

Following the URL request, the company extracts the information from its information systems and sends the response to the HTTP interface through an HTML page characterized by a series of configurable TAGs agreed with the company in which the appropriate information is contained (text, number telephone number, possible message identifier ...).

For each query from the terminal, the company can respond with one or more SM messages.

2.6. 1.3.3 The sending of information to the terminal

The HTTP interface receives the HTML page sent by the company containing the requested information and converts it into a response SM message addressed to the mobile user.

If requested by the company, the HTTP interface provides notification of the delivery outcome for the messages sent

The GSM network sends the SM message until it is delivered or at the end of a time interval established and configurable within the HTTP interface (Validity Period: VP).

2.6. 1.4 PUSH service

The push service is characterized by the following steps:

• the system sends the company, with an agreed periodicity, the address of an appropriate HTML page using the HTTP protocol (GET);

• the company, following the URL received, responds by sending the system, in HTTP mode, an HTML page containing:

o the text of one or more messages and the identifiers of the recipients if the company wishes to provide the push service;

o an indication that you do not want to provide the push service (you have no information to send);

• the system processes the HTML page received and, depending on its content, forwards the SM messages contained in the HTML page to the recipients.

2.6.1.4.1 Communication between the company and the operator's systems

The push type service enables the company to send information, on its own initiative, to one or more user terminals.

The HTTP interface, at set time intervals, polls the customer information system, through a specified URL. In response to this request, the client sends a page in HTML format containing the messages to be sent and the list of recipients.

If there are no messages to send, the company responds with an HTML page in which it indicates to the ITnterfacda this situation by inserting the relative return code (Return Code) within a configurable tag.

Following the URL request, the company extracts the information from its information systems and sends the response to the HTTP interface through an HTML page that may have:

• fixed format: characterized by a single application tag which contains, according to an established format, the messages and recipients;

• configurable format: characterized by a template containing various application tags whose description is defined in the configuration module.

2.6. 1.4.2 Sending information to MS

The HTTP interface receives the HTML page sent by the company containing the information to be sent requests and converts it into a SM message addressed to the mobile terminal.

If requested by the company, the HTTP interface provides notification of the outcome of the delivery for the messages sent.

The GSM network sends the SM message until it is delivered or at the end of a time interval established and configurable within the HTTP interface (Validity Period: VP).

2.6. 1.5 Notification of the service provided

The HTTP software interface is able to manage notifications relating to SM messages sent by the company to the mobile terminal; the interface makes available to the company all the notifications to which it is interested, both for the push type and for the pulì type services.

2.6. 1.5.1 Status Report for PUSH service

The corporate customer, if interested in knowing the outcome of the delivery of SM messages, requests the Status Report in two ways:

• Status Report in real time;

• Status Report at the end of the sending session.

If the Company is interested in real-time notification of successful or non-delivery of push messages, each message sent to the HTTP interface must be accompanied by a unique identifier (id-B). This identifier can be established both to the single MS and to a message for a list of MS. In this last case, it is identified by the following string:

separator user id-B

where is it :

• user is the phone number of the MS or the user code assigned at activation (MSISDN or User Code)

• separatone is a configurable character.

For example, if we are dealing with a service without activation, the value of id-B is 10992 and the separator character H is the following identifier to be used to identify the SM with the company:

03356000000: 10992

When the HTTP interface proceeds to transmit the message to an SMS-C of the GSM network, it waits for a confirmation accompanied by an identification for that SM. Each SMS-C, having received a message, returns a Time Stamp, which together with the recipient's MSISDN represent, within that SMS-C, the key to uniquely identify that message. This pair plus an SMS-C identifier constitute a message identifier within the application (id-A).

The HTTP interface, upon receipt of the GSM network confirmation, must memorize the association between the identifier assigned by the company (id-B) and the identifier (id-A) received from the network.

Upon receipt of the report from the SMS-C, accompanied by the identifier of the message to which the report refers, the HTTP interface obtains id-A, through which it goes back to the identifier given to the message by the company: ( id-B) or its extension MSISDN / User Code, id-B. Through URL llnterfacda HTTP transmits the pair of information (report, id-B or its extension) to the corporate customer.

The company guarantees the uniqueness of the identifiers generated (id-B).

In the case of notification through the Status Report at the end of the session, the HTTP interface produces a report file containing the outcome of the delivery of each SM message taken over by the GSM network.

The GSM network, for each SM message, indicates whether it has taken charge or not. If an SM message is not taken over, its transmission is definitively failed and will never be delivered to the MS (this case should be considered as a negative report).

Otherwise, the GSM network sends the SM message until it is delivered or the Validity Period expires (VP: time interval that can be configured within the application). Therefore each SM message, during the transmission phase, assumes several states (to be transmitted, discarded, taken over, delivered, delivery failed). Llnterfacda HTTP keeps track of the status of the various SM messages, deeming the relative session closed only when it has received the result relating to the delivery of all the expected messages.

To avoid stale situation, a maximum session duration time (and therefore waiting for the various reports) is foreseen equal to the set Validity Period plus a certain configurable Delta. At the end of this interval, the session is considered closed anyway and, for each SM message, the last known state is considered definitive.

When the session is closed, the HTTP interface makes the report file available in an appropriate directory and sends a URL to the company to inform it of the presence of the Status Report; the company will take this file via FTP and delete it at the end of the transfer.

2.6.1.5.2 Status Report for PULL service

If the corporate customer is interested in receiving the delivery notification for replies sent to the MS, each reply HTML page must contain a unique identifier for each message contained therein.

Upon receipt of the delivery notification, the HTTP interface transmits to the company an appropriate notification URL for each recipient of a specific message, containing the delivery date, the outcome and identification of the message itself.

2.6. 1.6 Management policies

The HTTP software interface is able to manage the activation and deactivation requests, for both the pulì and push services, made directly by the MS. The operating modes of the activation / deactivation service managed by the HTTP interface are as follows:

• the corporate customer assigns a unique identification code (user code) to any user of the pulì or push services;

• the user, through the MS, requests the activation of the service by sending an appropriate SM to the company, containing the activation command, the user code assigned to him and the password assigned to him by the company;

_

• the HTTP interface in receiving the activation request SM message, invokes the relative URL (activation URL) to the web server containing the information typed by the user;

• The company responds with an HTML page in which it indicates to the interface if the user code and password are correct (usually a tag containing a RETURN CODE);

• the HTTP interface, in case of successful activation, records the association between the user code and the telephone number of the MS. It still responds to the user with a successful or failed activation SM message.

• the activation remains valid until the MS requests the deactivation, by sending an appropriate SM, or requests a new activation on the same MS, or requests the same activation from another MS.

A message is expected that allows the MS to deactivate the PUSH service.

The advantages of using the enable / disable service provided by the HTTP interface are as follows:

• The company provides the mobile terminal with the possibility of activating or deactivating the cleaning or push service at any time without developing ad hoc code lines;

• The company communicates with the terminal only by referring to the user code assigned to it; the HTTP interface takes care of remapping the user code with the last telephone number activated on the push or pulì service;

• it is the HTTP interface that filters the communication between the company and the terminal; the push or clean service will be provided only if it refers to an activated user code.

The company is responsible for generating unique user codes and passwords to communicate to its customers.

2.6.2 SOFTWARE INTERFACE

2.6.2.1 Nomenclature standard of the Notification File of the services provided

Below is the nomenclature standard adopted for the Status Report file at the end of the session for Push services, according to the Extended Backus-Naur Form (EBNF) notation:

<ReportFlleName> :: = <PrefixReportFileName> (<TimeStamp> <Pagld>)? <SufflxReportFileName>

where is it:

<PrefixReportFileName> is a constant string defined in the configuration module.

<TìmeStamp> is used in the case of Push service through HTML page in fixed format. It assumes the same value of the TimeStamp indicated in the first line of the corresponding HTML Push page (format: YYYYMMDDhhmmssmmmm).

<PagId> is used in the case of Push service through HTML page in template format. It assumes the identification value of the corresponding HTML page (Pagld) indicated by the company; in its absence the company uses a progressive number.

<SuffixReportFileName> is a constant string defined in the configuration module.

2. 6. 2.2 Data structure

2.6.2.2.1 Customization of the communication between the company's systems and those of the operator

In the URL that the interface sends to the company and in the HTML response page, in addition to the request for a service by the terminal and the sending of information by the company to the terminal, it is possible to specify some information regarding the methods to be used for sending the SM message to the mobile user.

In the configuration module it is possible both to establish the identification string for each piece of information, and to indicate which information is compulsorily reported in the communication between the HTTP software interface and the company.

The information contained in the communication between the company and the operator concerns:

• Outcome of the operation, where by operation we mean the request for a PUSH page (also intended as a response to PULL). The result will be positive (0, ok) if the page contains messages with the relative recipients, negative (1, ko) if there are no messages to send.

• User code, that code provided when activating the service. We indicate this code with User Code. Alternatively, the telephone number of the recipient indicated with MSISDN can be used directly.

• Message identifier, used for the management of Status Reports.

We indicate this identifier with Msgld. This information must be present only if the Status Reports are managed.

• Page identifier, identifier that the application can use to request the company to delete the HTML page once it has been acquired. This information may not be present if the company automatically removes the page, once returned in response to an HTTP GET. We indicate this identifier with Pagld.

Below is a list of the information accepted with an indication of its mandatory nature:

ORC Operation Return Code N.A. optional

2.6.2.3 SM message

Below is the syntax of the SM message, sent or received by MS, according to the Extended Backus-Naur Form (EBNF) notation.

2.6.2.4 Communication from the operator to the client company

Below is the syntax of the URL used for the interview by the operator's systems towards those of the corporate customer, according to the Extended Backus-Naur Form (EBNF) notation.

Communication between the operator's systems and those of the company takes place via the http GET method; the company performs the server functions while the operator's systems perform the client functions.

The HTTP interface manages the configuration data relating to the communication towards the company client and the construction methods of the TJRL; the name of the commands, the name and number of parameters provided for each command, the additional information to be included in the communication, can be configured by the customer.

Here are some examples of the construction of the TJRL.

Example 1

If the SM message typed by the MS is:

NUM F

ITJRL built by innterfacda is as follows:

In this example the SM message typed by the MS contains more parameters than those declared in the configuration form, it is assumed that the last parameter sent is composed of more than one token separated by spaces. Consequently, the URL sent will contain in the last parameter, the various tokens concatenated with the character "% 20" according to the HTTP standard.

Example 2

In the case of push type services, the URL to be invoked to the company to detect the presence of SM messages to be forwarded could be:

The time interval for polling is defined from the configuration module.

Example 3

If the company requires the production of:

• Status Report for PULL messages

• Status Report in real time for PUSH,

must specify the URL to be invoked as soon as the Status Report is available for a message.

Below is an example of a URL for the notification of the Status Report with the related parameters:

In this example:

• the identifier of the message is: id-msg

• the outcome of the report is: Y

• the delivery date is: 260498151023

indicating that the message was delivered (Y stands for yes, otherwise it has N) on April 26, 1998 at 15:10:23.

Please note that in case of delivery with negative outcome (outcome = N) the time-stamp will report the expiry date of the message's Validity Period.

Example 4

If the company requests the production of the Status Report at the end of the session, ItlRL to be invoked to notify the presence of the report file will be:

2. 6.2. 5 Communication from the company's systems to those of the operator Below is the syntax of the document in HTML format used for communication between company and operator via HTTP, according to the Extended Backus-Naur Form (EBNF) notation.

<Number Value> :: = [0-9] +

In the case of Push-type services, the company can send the requested information to the terminal using an HTML page with a configurable tag, containing the text relating to the messages to be sent with the recipient's address.

In the following examples it is assumed that you have configured the parameters used as follows:

A possible response HTML page will be constructed as follows:

example 1

As an alternative to the HTML page of the previous example, it is possible to define the syntax of the page itself by configuring an appropriate template that allows greater flexibility:

The separator character between recipient and message need not necessarily be the "l" character. This character is in fact configurable.

example 5

In the previous example, we have a message identifier for each text / recipient pair.

example 6

In the previous example, the message identifier is attached to the message text and not to the text / recipient pair. In this case the identifier in question must be accompanied by the MSISDN to obtain its uniqueness.

The format of the company's replies in the case of Pulì-type services is also configurable. In addition to the simple format that requires the response page to be of the type:

It is possible to define more complex formats, as is the case for Push services. Here is an example:

The company's response can also consist of an empty page, in which only the opening and closing tags of the page are present; in this case no SM message will be sent to the MS:

2.6.2.6 Status Report notification file at the end of the session

Below is the syntax of the notification file used in the case of Push service with Status Report at the end of the session, according to the Extended Backus-Naur Form (EBNF) notation

1 R assumed value coincides with 1 present value notes first line of Pueh page.

'Date and time of writing the message.

example 1

if the company prepares an HTML page in fixed format as follows:

A possible report file will be constructed as follows:

example 2

if the company employee prepares an HTML page in template format as follows:

A possible report file will be constructed as follows:

2.6. 2.7 Command syntax

The syntax of the commands for the exchange of information between the operator and the company refers to the operating mode of the HTTP protocol; the company takes on server functionality while the operator's systems take on dient functionality

2.6. 2.8 Messages and Return Codes

The messages and return codes are those relating to the HTTP service of the environment in which you operate.

2.7 Communication to the company via FTP

2.7.1 Description of the service

2.7.1.111 service

The company agent transfers, in FTP (put) mode, to the operator's systems a file in ASCII format containing a set of messages and a list of MS numbers to which the messages are intended.

The system processes the file in ASCII format forwarded by the company by forwarding the messages to the relative recipients in SM mode.

If requested by the company, the system makes available, in FTP (get) mode, a file in ASCII format containing a report on the processing of the message file.

2.7. 1.2 Logical architecture

The service involves the interaction of the following systems:

• Mobile terminal

GSM network

• Operator infrastructure

• Company customer

the operator's infrastructure is the system that allows the provision of VAS services using various enabling technologies supported by the GSM network (SM, WAP, IVR, Internet, etc. ..).

2.7. 1.3 Service Request

The Company Customer transfers the information to be transmitted to the system in FTP mode, listed in a special ASCII file.

The ASd file groups a set of messages and lists of MS numbers to which the messages are intended; the data is organized in the files with an established criterion and syntax that makes it possible to distinguish what to send and to whom.

For data exchange via FTP, it uses the services offered by the Operating System.

The company does the following:

• Prepare ASCII file with messages locally.

• Make an FTP connection to the operator's system, providing the username and the relative authentication password specifically defined for the corporate customer.

• Transmits the file via FTP (put) in a specific directory of the system (<InputDirectory>) agreed in advance (however modifiable by configuration).

• Close the FTP session.

The name of the file to be transmitted must be constructed according to a pre-established nomenclature standard, through which it is also possible to assign a priority level for processing the files.

In the first line of the file it is possible to provide a series of parameters relating to the company, the date of preparation of the file, the period of validity of the message and the request for notification; these parameters (eg OAdC, VP, etc.) are defined in the configuration module, described below, but can be overwritten at the level of the single transmitted file. For each of these parameters the interface assumes the value possibly supplied in the first line of the files or, in its absence, the value specified in the configuration module.

To prevent the software interface from processing the file before the end of its transfer, the corporate customer assigns a temporary name to the file. At the end of the FTP transfer, the corporate customer renames the file from temporary to final so that the latter can be handled by the interface.

2. 7. 1.4 Provision of the service

The software interface does the following:

• Periodically checks the <XnputDirectory> for the presence of the file.

• Move the file to a working directory for processing.

• Proceeds to send all the MS contained in it.

This cycle (checking the presence of the file, moving the file and sending the SMs contained) is performed with a time period (polling interval of the <InputDirectory>) established in the configuration module of the software interface.

2.7. 1.5 Notification of the service provided

For each file transmitted, the corporate customer has the possibility to request information regarding the delivery of messages. This information (report file) is divided into two or more levels of detail according to the needs of the company.

In this regard, the software interface performs the following operations:

• Collect in the report file, in a working directory, the result of the message forwarding.

• Move the generated report file to a specific directory on the system (<OutputDirectory>) agreed in advance (in any case modifiable from configuration)

• Proceeds to send all the MS contained in it.

The company manager carries out the following operations:

• Get the report file via FTP (get) from <OutputDirectory>.

• Delete the report file after reading from <OutputDirectory>.

The interface collects the outcome of the forwarding of messages for a pre-established, configurable and unique time for all requests possibly produced by the company.

2.7. 1.6 Management policies

2.7.1.6.1 Processing priority of the SM message file

The FTP software interface checks for the presence in the <IntputDlrectory> of the SM message file to be processed; if there are multiple SM message files, the FTP interface starts processing the files according to the priority order established by the Company Customer: first the SM message files with priority 9 (maximum priority) and then the SM message files lowest priority up to zero priority (lowest priority).

The zero-priority SM message file is still processed by the FTP interface before the no-priority SM message file.

In case of SM message files without priority indication, or with priority of the same level, the FTP interface processes the files according to the creation date: first the SM message files with an older date and then the files with the most recent date. recent.

2.7.1.6.2 Static management and dynamic management

The management policies in the provision of the service, in relation to a specific message file, depend on the following temporal quantities:

• File creation date (to)

It is the system date in the <InputDirectory> relative to the transmitted file.

• Validity Period (VP)

Max time interval, expressed in seconds, within which to forward a specific message. The VP is defined in the configuration module but can be overwritten at the level of the single transmitted file

• Minimum Validity Period (VP ^ ,,)

Minimum value of VP that can be assigned to a message. The VPmm is defined in the configuration module but can be overwritten at the level of the single transmitted file.

• Time interval for processing the file (Stw)

It is the time interval that the interface takes to scan and process the requests for forwarding messages. Its max value is established to be equal to the value assumed by VP.

• Time interval for processing a message (δtem)

It is the time interval that the interface takes to scan and process the forwarding request of a single message.

There are two management policies:

Static management

Static management occurs when:

In the case of static management, all messages relating to the same file are sent to the MS recipients with the same VP value, whether it is set in the file or, in its absence, in the configuration module.

This implies that the messages will remain in the GSM network for a time equal to at most:

with respect to the date of creation of the file.

Dynamic management

In the case of dynamic management, the VP assigned to a message relating to the same file is a function of the message processing time. Go and say:

Where is it:

. VP (i) is the value of VP assigned to the i-th message

* Stem (i) is the elapsed time interval from time to to processing the i-th message

Dynamic management occurs when:

That is to say that, over time, the PV of the messages is decremented and the sending is stopped as soon as its value reaches the value of VPmln.

This implies that the messages will remain in the GSM network for a time equal to at most:

With respect to the t3⁄4 date of creation of the file.

If VPmin = 0 the messages will remain in the GSM network for a time equal to at most:

In other words, the dynamic management guarantees a maximum time for the messages to remain in the GSM network exactly equal to the value of the defined VP.

Both in the case of static management and in the case of dynamic management, if the processing of the messages is not completed within the interval 5tef = VP from the date of creation of the file, the processing is interrupted and no longer continued.

Furthermore, the messages of a file that lies in the <InputDirectoiy> for a time interval 5t> 5tef will never be sent as they are considered expired. This situation can occur when the interface has to process many files with higher priority or older than the file in question.

2.7.2 SOFTWARE INTERFACE

2.7.2. 1 SM Message File Nomenclature Standard

Below is the nomenclature standard adopted for the SM message file, according to the Extended Backus-Naur Form (EBNF) notation.

>)? <SuffixSMFileName>

where is it:

<PrefixSMFileName> is a constant string defined among the parameters of the configuration module. The interface only processes files whose name begins with this prefix. To avoid processing a file whose transfer is not completed, you must transfer the object file with a different name (e.g. TMP_ <PrefixFileName> <PriorityTag> <InputFileName>). Only at the end of the transfer can the message file name begin with <PrefìxFìleName> if you want it to be taken into consideration.

<PrioiityID> is a constant string defined among the configuration module parameters whose presence in the name indicates the assignment to the files of a certain priority indicated by the value of <PrìorityValue>

<PriorityValue> is a digit (0..9) indicating the priority given to the file. Zero is the lowest priority, nine the highest.

<SuffixSMFileName> is the free part of the file name

In forming the SM message file name, the PrioritylD and PriorityValue strings represent optional fields; Qiente Company uses these fields in the file name if it intends to indicate the priority with which the FTP interface will process the SM message files.

Example 1 (SM message file with priority indication):

CSP l_PRY9_Notizie_d i_Borsa

it is a priority 9 file.

Example 2 (SM message file without priority indication):

CSPl_Greeting_Messages

it is an unpriority file. Note that the FTP interface first processes a zero-priority file of a file with no priority indication.

2.7.2.2 Nomenclature standard of the Notification File of the service provided

Below is the nomenclature standard adopted for the notification file, according to the Extended Backus-Naur Form (EBNF) notation.

where is it:

it is a constant string defined among the parameters of the configuration module.

they assume the same values

defined for the name of the message file transferred from the company. This allows you to associate the report file with the corresponding data file.

2.7.2.3 Data structure

2.7.2.3.1 SM message file

Below is the syntax of the ASCII file for communication via SM, according to the Extended Backus-Naur Form (EBNF) notation.

The possible values to be assigned to the Status Report request are:

• N, to not request Status Report

• Y, to request the Status Report on two levels of detail:

or Y, successful, message delivered

or N, unsuccessful, undelivered message, or message for which no positive notification was received.

• D, to request the Status Report on more than two levels of detail:

o Y: successful

o V: negative result due to expired VP;

o I: negative result due to out of operation ';

o P: negative result due to permanent error in the Send;

o N: negative result for negative notification from SMS-C;

o U: outcome unknown despite SM sent.

Here are some examples.

Example 1 (the above parameters are not defined at the input file level):

The first line of the file may contain a string indicating the name of the company, or a short number (OAdC) configured on the GSM network and associated with that company. In this example we used a generic name "Test" followed by a timestamp.

The message to be sent consists of a single line on the input file. The maximum length of the message must be 160 characters; otherwise, the string will be truncated.

In this example, the OAdC, SR, VP and VPmin parameters do not appear, so those defined in the application configuration module are used.

Example 2 (the above parameters are defined at the input file level):

2. 7. 2.4 Notification file of the service provided

Below is the syntax of the notification file, according to the Extended Backus-Naur Form (EBNF) notation.

The Report file therefore groups together all the results relating to the sending of the various messages contained in the data file to which this report refers.

The FTP interface considers the message sending session closed when the validity time of the last message sent plus a delta value (configurable and unique for all sessions) has elapsed.

Next to each recipient for which the notification has not been received, the session end time-stamp is shown followed by the string

", Λ / 1, in the case of a two-level Status Report, Y and N

", U", in the case of a detailed Status Report.

Example:

if the company transfers via FTP the file Prova_19991121030522999.txt \\ whose content is:

/

A possible report file will be constructed as follows:

2. 7. 2. 5 Command syntax

The command to establish an FTP session is generally the following:

ftp [hostname]

where hostname specifies the symbolic name or ΙΊΡ address of the machine you want to connect to.

Then you need to log in by typing the user and password provided by the operator.

To close the FTP session the command is generally the following:

bye

2.7. 2. 6 Command to forward the SM message file

Once the FTP connection with the system is established, the command to send the message file is generally the following:

put <MSGfilename>

2.7. 2. 7 Command to acquire the notification file of the service provided

Once the FTP connection with the system has been established, the command to download the notification file of the service provided is generally the following:

get <RPT filename>

2.7. 2.8 Messages and Return Codes

The messages and return codes are those relating to the TCP / IP FTP service of the environment in which you operate.

2.8 Communication to the company in SMTP

2.8.1 Description of the service

2.8. 1.1 XI service

The service allows a Company to send SM messages to MS and to receive messages from MS.

In the first case:

• The company sends an e-mail, in SMTP mode, addressed to a specific mailbox of the operator's system and containing the message and the recipient's identification;

• the operator's system processes the e-mail received and routes the message contained to the recipient in SM mode;

• if requested by the company, the system generates an e-mail notification through which the company is informed about the outcome of the message delivery;

In the second case:

• the MS sends an SM message to a particular number which, within the system, identifies the company;

• the system sends an e-mail containing the sender's identification and the text of the message to a specific company mailbox.

Within an appropriate configuration module, described below, the company provides the information and methods for correct forwarding of the email message.

2.8.1.2 Logical architecture

The service involves the interaction of the following systems:

• Mobile terminal

• GSM network

• Operator infrastructure

• Diente Company

The operator's infrastructure is the system that allows the provision of VAS services using various enabling technologies supported by the GSM network (SM, WAP, IVR, Internet, etc.). The SMTP software interface described in this document is resident in the operator's infrastructure and has a mailbox to which the company directs e-mail messages.

2.8.1.3 Request for service

2.8.1.3.1 Sending an SM message to MS

The company sends to the mailbox of the software interface, via SMTP protocol, an appropriately structured e-mail message: in the first part, header of the e-mail message, the company specifies all the information used by the system to send correctly the message; in the second part of the e-mail message, the company reports the text of the message itself.

The information contained in the header of the e-mail message that the company must necessarily provide concerns:

• Sender (From) contains the company's e-mail address;

• Recipient (To) contains the e-mail address of the SMTP software interface;

• SM recipient contains IMSISDN recipient of the SM message.

The company can specify in the header of the e-mail message additional information, not mandatory, which allows to indicate to the SMTP software interface the methods to be used for sending the SM message.

The e-mail message cannot contain attachments; the text of the e-mail message cannot exceed the current limit of an SM message.

2.8.1.3.2 Receiving an SM message from MS

The MS composes the text of the message, without exceeding the current length limit, and sends the SM message to a particular number which, within the system, identifies the recipient company customer.

Within the text of the message, an e-mail address of the recipient company can be specified, to which the message will be sent directly. This e-mail address, alternative to the standard company address, has value only for the SM message within which it is contained; e-mail messages subsequently sent, unless otherwise indicated by the MS, will be forwarded to the standard e-mail address of the Company Customer.

2.8. 1.4 Provision of services

2.8. 1.4.1 Translation of an SM message into an e-mail

The SMTP software interface receives all SM messages addressed to a specific company.

An appropriately structured e-mail message is generated for each SM message: in the first part, header of the e-mail message, the operator specifies all the information used to send the message correctly; in the second part of the e-mail message. The information contained in the header of the emaii message that the operator must necessarily provide concerns:

• Sender (From) contains the e-mail address of the SMTP software interface;

• Recipient (To) contains the company's e-mail address;

• Subject contains the subject of the e-mail message.

The operator's system can specify additional, non-mandatory information in the e-mail message header, the presence of which depends on the indications provided by the company in the configuration form.

Alternatively to the use of the e-mail address indicated in the configuration form, the SMTP interface can manage the evaluation of the recipient (To) of the e-mail message by reading the company address directly in the text of the SM message.

In any case, the SMTP software interface does not perform any syntactic contrailo on the text part of an SM message.

2.8. 1.4.2 Translation of an e-mail in an SM message

The software interface receives the appropriately structured e-mail message sent by the company, containing the identification of the recipient and the text of the SM message.

If no error is found in the e-mail, the interface performs the appropriate conversions and routes the message to the recipient.

If the interface detects an error, it sends an error e-mail to the Company Customer with an indication of the error found. No syntactic check is performed on the text part of an e-mail message coming from the company.

The text of the e-mail constitutes, with the current length limitations, the content of the SM message.

2.8.1.5 Notification of the service provided

In the case of sending SM messages to the MS, the Company Customer can request the interface to generate an e-mail notification through which the company will be informed of the outcome of the delivery of the aforementioned message (delivered or not delivered).

2.8.2 SOFTWARE INTERFACE

2.8.2.1 Data structure

2.8.2. 1.1 Custom headers of e-mail messages

In the header of the e-mail it is possible to specify additional information, Custom Header, regarding the methods to be used for sending the SM message.

Through the use of Custom Header the following sending methods are allowed:

• sending an SM message in date format instead of text,

• sending an SM message with a validity period,

• request for notification.

The text of an e-mail message, forwarded via the SMTP protocol, requires the exclusive presence of text characters. The procedure for inserting a message in date format in the text of the e-mail is as follows:

• the company inserts in the e-mail message the appropriate custom headers (PID and / or DCS), described below, to instruct the SMTP software interface to correctly interpret the text of the message; in this way the presence of given characters will not compromise the forwarding of the e-maii message;

• the company transforms the message from date format to text format by encoding each byte of the original message with two characters representing the corresponding esadedmaie encoding of the bytes to be transmitted;

• the company forwards an e-mail to the SMTP software interface, the text of which contains the message represented in the aforementioned format;

• the SMTP software interface converts the received message into the original date format before sending it to the MS.

In case of receipt of an e-mail message in datar format.

• the MS sends the SM message in date format to the SMTP software interface;

• the SMTP software interface transforms the message from date format to text format by encoding each byte of the original message with two characters representing the corresponding hexadecimal encoding of the byte to be transmitted;

• the company, in order to correctly interpret the message received, converts the message itself from hexadecimal format to original date format

The validity period of an SM message represents the maximum time interval, expressed in seconds, within which a given message will be forwarded.

In the configuration form it is possible both to establish the identification string of each Custom Header, and to indicate which Custom Headers are compulsorily reported in the e-mail messages generated by the SMTP software interface.

For Custom Headers not directly specified in the e-mail message, the default value in the configuration form is used.

Below is the list of Custom Headers with the indication of the mandatory nature of the e-mail messages:

2.8. 2.2 E-mail message from the company to the operator

Below is the syntax of the e-mail used for company communication to the operator's systems via SMTP, according to the Extended Backus-Naur Form (EBNF) notation.

<SP> :: = 0x20

Here are some examples.

It is assumed that the SMTP software interface is configured with the following parameters to be set in the configuration module:

The diagram of figure 2 relates to an example of translation of e-mail into SM message: Example 1

The SMTP software interface receives an e-mail from the company as follows:

Upon receipt of such an e-mail (SMTP software interface prepares an SM message for the MS with MSISDN 00393356339999, with the text "Message for 03356339999", and with

SM parameters set as follows:

For parameters that are not specified in the e-mail, the default value set in the configuration form is used.

Example 2

The SMTP software interface receives an e-mail from the company as follows:

The SMTP software interface prepares an SM message for the MS with MSISDN 00393356339999, with the text "Message", and with the SM parameters set as follows:

2.8. 2.3 E-mail message from the operator's systems to the company's systems

Below is the syntax of the e-mail used for communication from the operator's systems to the company via SMTP, according to the Extended Backus-Naur Form (EBNF) notation.

Here are some examples.

Yes assumes that the SMTP software interface is configured with the following parameters to be set in the configuration module:

lnterfacda SMTP software inserts in the e-mail sent to the company only the custom heders for which the presence in the configuration form has been expressly requested; In this example the company has defined and requested, through the appropriate tags, the following custom headers: X-AdC, X-OadC, X-DCS, X-VP, X-PID.

The diagram of figure 3 relates to an example of translation of SM message into e-mail:

Example 1

The SMTP software interface receives an SM message whose parameters are set as follows:

Example 2

The SMTP software interface receives an SM message characterized by the following parameters:

From the example you can see that the text of the e-mail is set as a hexadecimal string of characters (representation in hexadetimal).

This is indicated by the DCS field value of 246.

The conversion of an MO to hexadecimal representation is necessary to prevent the presence of non-printable characters in the MO from preventing the correct sending of the e-mail.

Example 3

The SMTP software interface receives an SM message characterized by the following parameters:

The tags to be included in the e-mail are set by the configuration module.

2.8. 2.4 E-mail notification of the service provided

Below is the syntax of the notification e-mail addressed by the operator's systems to the company's systems via SMTP, according to the Extended Backus-Naur Form (EBNF) notation.

Example 1

It is assumed that the SMTP software interface is configured with the following parameters to be set in the configuration module:

The SMTP interface prepares an SM message for the MS with MSISDN 00393356339999, with the text "Mail with notification request", and with the SM parameters set as follows:

• AdC = 00393356339999

• NRq = l

When the message is delivered to the MS, the SMTP interface will prepare a delivery e-mail and send it to the company.

The created e-mail will look like this:

Obviously in the event that it was not possible to deliver the SM message in the specified VP, the reply e-mail for the company will be a delivery e-mail that has not happened as follows:

2.8.2.5 Error emails from the operator's systems to the company

Below is the syntax of the error e-mail addressed by the operator's system to the company via SMTP, according to the Extended Backus-Naur Form (EBNF) notation.

<Mail> :: = <HeaderxContent>

2.8. 2.6 Subject field of the E-mail message

The SMTP software interface provides an indication of the type of e-mail sent to the Qiente Company in the subject of the e-mail itself (Subject field).

In this way the e-mail message, the e-mail notification of successful delivery, the e-mail notification of non-delivery and the error e-mail will be recognizable by its own particular subject.

Oò will allow the company to adopt the appropriate management policy of the different types of e-mails received based on the filter operated on the Subject field indicated by the SMTP software interface.

2.8.2.7 Command syntax

2.8. 2.7.1 E-mail forwarding

The methods for forwarding an e-mail message are those typical of the messaging system used:

• email dient;

• SMTP service API.

2.8.2.7.2 Email reading

The methods of reading an e-mail message are the typical ones of the messaging system used:

• Email client;

• SMTP service API.

2.8.2.7.3 Messages and return codes

The messages and return codes are those relating to the messaging system used.

2.9 Communication to the company in SOCKET

2.9.1 Description of the service

2.9. 1.1 The service

The service allows dialogue between the Company and the Terminal through the use of SM messages. The interview is made possible by a software interface based on SOCKET connection and proletarian protocol, resident within the SYSTEM, which manages the SM messages coming from MS, translating them into specific requests addressed to the company and managing the information coming from the 'company by translating them into SM messages sent directly to the MS.

The service is configured according to the following characteristics:

• clean service - allows the MS to request information from the company by sending an appropriately structured SM message; the company responds to the MS with an SM message containing the requested information.

• push service - allows the company, on its own initiative, to send SM messages containing information to the MS.

The technical activities carried out by the company for the realization of the service concern:

• preparation of the connection with the operator's SYSTEM by communicating to the operator the IP addresses assigned to his system;

• creation of the dialogue layer with the TCP software interface using the communication application protocol described in this document and based on TCP / IP with a Socket connection.

2.9.1.2 Logical architecture

The service involves the interaction of the following systems:

• Mobile terminal

• GSM network

• Operator infrastructure

• Company systems

The company's information system will be connected to the operator's infrastructure with a dedicated 64 Kbps CDN line plus a backup line (again 64 kbps CDN), thus guaranteeing maximum reliability and safety. These lines will be certified at the POP of the operator closest to the company and the connection to the SYSTEM will be created through a router, certified at the company, but installed, configured and managed by the operator.

The operator's infrastructure is the system that allows the provision of VAS services using various enabling technologies supported by the GSM network (SM, WAP, IVR, Internet, etc. ..).

The TCP software interface described in this document is resident on the SYSTEM; the main features provided are:

• conversion of SM messages from MS into strings formatted according to the socket-based protocol;

• conversion of strings formatted according to the socket-based protocol into SM messages to be sent to the MS;

• Storage of the information necessary for the tracking of messages in transit on the SYSTEM;

• management of the UCP protocol towards the SMS-C of the GSM network.

The types of messages exchanged are:

• SM messages sent by the MS to the company requesting for clean transactions;

• SM messages sent by the company to the MS in response to a clean transaction;

• SM messages sent by the company to the MS for push transactions:

• Status Report (SR) messages sent to the company by the TCP interface for the notification of the result of the last delivery attempt, made by the GSM network, of the SM message to the MS.

2.9. 1.3 Connection between the company's systems and the operator

The application protocol used to interface the company and the operator's system is based on TCP / IP with socket connection. This choice is due to reasons of performance and greater robustness / reliability in establishing the transmission channel; it is possible to confirm or not the successful transmission (ACK / NAK).

The following figure illustrates the flow of information (character strings) exchanged between the operator's systems and the company.

The company is assigned on the system by the operator a port for the creation of the connection that allows the sending of SM messages towards the MS; the company provides a port for forwarding SM messages addressed by the MS to the short number associated with the service. Ultimately, two connections will be established with the following configurations:

• communication from the operator to the company: IP address and destination port of the client company where the connection is made and the information flow is sent (SM messages from MS and Status Report) connected to the IP address of the machine with source port dynamic type;

• communication from the company to the operator's systems: machine IP address and destination port where the connection is made and the information flow is sent (SM messages to MS) connected to the IP address of the machine Customer Company with dynamic or predefined source port

The destination ports are always defined in advance when configuring the application.

The protocol envisages as the first operation the connection between the operator's systems and the company and vice versa is established; subsequently the exchange flows for SM messages from MS, SM messages to MS and Status Report can be activated. The company acts as a Client in case of SM messages to be sent to MS; it then establishes the connection on the Socket for SM messages and then submits the sending commands.

The company's systems behave as servers in case of SM messages coming from MS or Status Report; the TCP interface will then establish the connection on the Socket for SM messages or Status Report and then submit the sending or notification commands.

For performance reasons, the Socket connection between the company's systems and the operator's systems is made through the One-way Socket mode. This means that the operator makes two connections available: one is used to forward the MS received from MS to the company; the other to receive the command for delivering SM messages to the MS. It should be noted that the relative ACK / NAK will be sent on the same connection on which the SM message or the Status Report was sent. The company and the system therefore communicate through two separate doors.

Once the connection is established, messages can be exchanged. Supported requests are of three types:

• SM message from MS: the TCP interface sends a Deliver command to the company;

• Status Report: the system sends a StatusReport command to the company;

• SM message from the company: the company sends a Submit command of an SM message to the system.

At the end of the message exchange operations, the Client will close the connection. In order not to decrease performance, it is advisable to make as few connections / disconnections as possible (for example in cases of extraordinary maintenance, in cases of malfunctions, etc.).

All the data of the streams are transmitted and received according to the ASCII encoding with the exception of the message text which is transmitted in internal format (ie no transcoding table is applied to the data).

If no activity is recorded on the connection, this is closed and restored to the core of an SM message coming from MS.

2.9. 1.4 PULL service

2.9. 1.4.1 Request for information from MS

The use of the pulì service by an MS takes place by sending an appropriately structured SM message to a particular number that identifies the company.

In the event that the company's system is not connected to the operator's SYSTEM, it is possible to request the TCP interface to send a courtesy response to the MS who send SM messages to the short number established by the company. The courtesy dj response can be configured as desired.

2.9.1.4.2 Communication between the operator and the company

The request for information made by MS via SM message is translated by the TCP software interface into a string formatted according to the socket-based application protocol described below.

Subsequently, the TCP interface sends the formatted string to the local port of the company system configured for the management of SM messages coming from MS. From this same port, the TCP interface expects a confirmation message (ACK or NAK) from the company. Receipt of the confirmation enables the system to forward to the company any subsequent formatted character string containing an additional SM message (synchronous mode).

The ACK or NAK must be sent by the company within a set maximum time (currently 55 sec.); at the end of this timeout the SYSTEM considers the SM message not delivered and applies retry policies. During the retry phases, the message is repeated with the same information content to the company. The retry policy is repeated for a period of time determined by the validity time assigned to the message when it is sent from the MS. If the value is not entered, the validity time is currently 48 hours.

Following the receipt of the formatted character string containing the SM messages coming from MS, the company extracts the information from its information systems and sends the response, contained in a new character string formatted according to the socket-based application protocol, to the local SYSTEM port configured for the management of SM messages to be sent to the MS.

From this same port the company system expects a confirmation message (ACK or NAK) from the SYSTEM. Receipt of the confirmation enables the company system to submit to the operator's SYSTEM any subsequent string of characters containing a new SM message (synchronous mode).

2.9. 1.4.3 Sending information to MS

The TCP interface receives the character string from the company's system containing the requested information and converts it into a response SM message addressed to the MS.

2.9.1.5 PUSH service

2.9. 1.5.1 Communication between the operator's systems and the company

The company that intends to use a push service sends a character string containing the message text, formatted according to the socket-based application protocol, on the SYSTEM local port configured for the management of SM messages to be sent to the MS.

From this same port the company system expects a confirmation message (ACK or NAK) from the SYSTEM. Receipt of the confirmation enables the company system to submit to the SYSTEM any subsequent string of characters containing a new SM message (synchronous mode).

2.9.1.5.2 Sending information to MS

Upon receipt of the formatted character string, the TCP interface extracts the text message it contains and sends it to the recipient MS in the form of an SM message.

2.9. 1.6 Notification of the service provided

In the case of SM messages sent by the company to the MS in response to requests from the MS (clean service) or on its own initiative (push service), the company can request the TCP interface for notification of the successful delivery of the messages ( Status Report).

The TCP interface sends a sequence of characters formatted according to the Socket application protocol, containing the Status Report, on the local port of the company system configured for the management of SM messages coming from MS. From this same port, the TCP interface expects a confirmation message (ACK or NAK) from the company. Receiving the confirmation enables the TCP interface to submit a possible subsequent Status Report message to the company (synchronous mode).

The ACK or NAK must be sent within a set maximum time (currently 55 sec.); when this timeout expires, the TCP interface considers the message not delivered and applies retry policies. In this situation, the message is repeated with the same information content to the company.

2.9. 1.7 Management policies

Since the connection is made between the company and the operator's systems through a series of routers, it is not possible to guarantee the arrival at the destination of a request on a single IP packet as the size of each IP packet is managed by the Network Infrastructures. the company must be prepared to receive requests on multiple IP packets.

Correct management should include the continuous reading on the Socket and the identification of a request through the detection of the application identification field followed by the effective length of the request.

2.9.2 SOFTWARE INTERFACE

2.9.2.1 Application protocol based on Socket connection

the application protocol used is of the TLV type, that is Tag-Length-Value. In practice, each field is defined by the presence of three elements:

• Tag: label of the field with a fixed length of 4 ASCII characters

• Length: length of the fixed length field value of 4 ASCII numeric characters

• Value: value of the field

For example, to indicate a telephone number (in our case 03356330176) to which to send a SM message, the following structure must be prepared:

Where ADC is the field tag. The <SP> character represents the padding space character if the label has a length of less than 4 characters.

Each information packet exchanged between the company and SISTEMA is represented in the form of ASCII strings.

2.9.2.2 Data structure

2.9.2.2.1 Communication between the company's systems and the operator

Below is the structure of the messages used for the conversation between the company and the operator, according to the Extended Backus-Naur Form (EBNF) notation.

The following table explains the meaning of the elements of the message structure:

2.9.23 General description of the parameters

A certain number of usable parameters are defined for the types of requests that can be exchanged between the company and the operator. Some of these parameters are optional, others are required. The absence of at least one of the mandatory parameters produces a NAK indicating a particular error code.

For the parameters defined as optional, the company decides whether or not to ask for them to be sent.

The company, in the analysis of the labels of the requests, must be "case insensitive"; in any case, the parameter is sent in the format (uppercase / lowercase) indicated in the relative table.

Parameter labels are always expressed with four ASCII characters; when the label is expressed with less than four characters it is "completed on the right" with the character biank.

All the usable parameters are described below for each type of request.

OadC The parameter indicates a numerical value, represented in ASCII, which contains the telephone number of the MS in the case of SM messages from the MS, or the short number associated with the company in the case of SM messages from the company.

AdC The parameter indicates a numerical value, represented in ASCII, which contains the telephone number of the MS in the case of SM messages addressed to the MS, or the short number associated with the company in the case of messages addressed to the company.

scts The parameter indicates the date and time of acceptance of the message by SMS-C. It is expressed in the following format: ddmmyyhhmmss.

• dd: day in two digits expressed with a numeric value in the interval 01 .. 31

• mm: month in two digits expressed with numeric value) included in the interval 01 .. 12

• yy: year in two digits expressed with numerical value 00 .. 99

• hh: hours in two digits expressed with a numerical value in the interval 00 .. 23

• mm: minutes in two digits expressed with a numeric value in the interval 00 .. 59

• ss: seconds in two digits expressed with a numeric value in the interval 00..59

A valid value can be, for example: 160200235950 which corresponds to February 16, 2000 at 11 pm, 59 minutes and 50 seconds.

EC The parameter contains the error code for NAK type messages.

DSCT The parameter contains the date and time of the last attempt to deliver the message to the MS. The format is the same as the sere parameter.

VP The parameter indicates the maximum time within which SMS-C must try to send the message. The numerical value will be expressed in minutes. If this parameter is omitted, the default parameter inserted in the service configuration form described below is used.

NRq The parameter is inserted in the submit message to indicate a Status Report request. The possible numerical values are: • "0" to submit without a Status Report request

• "1" to submit with a Status Report request

If this parameter is omitted, the default parameter entered in the configuration is used

DST The parameter represents the Delivery Status of an SM message sent to the MS; it appears in the Status Report messages. For further information please refer to [2]. The possible numerical values are:

• "0" for delivered: the message has been delivered

• "2" for not delivered: the message was not delivered within the validity period

If this parameter is omitted, the default parameter inserted in the service configuration form described below is used.

MSG It is the text message sent to the MS or received by the MS. The maximum length is fixed at 160 characters. Messages with a longer length will be rejected.

Log The parameter contains information necessary for tracking.

It is used in messages sent by the company to the operator's SYSTEM and contains information necessary for tracking. The content of this parameter is not encrypted and is not sent to the MS. This information is made available to the operator's Assistance and Maintenance systems to support the corresponding company systems. The information to be entered in this field will be defined together with the company.As an example, the LOG parameter could be represented in a transaction by the following values:

Where it could be assumed that inside the string 01010004VISA:

• code 0101 is the label that indicates the identification of the instrument used for payment

• 0004 the length of the instrument identifier

»VISA: the instrument used for payment

Inside the string 0102000812345678:

• the code 0102 is the label that indicates the identifier of the customer's transaction

• 0008 ia length of the transaction ID

• 12345678 identification of the transaction

In this way, while not entering into the merits of the transaction, it is possible to have tools to support the company that allow, in a fast and efficient way, to keep track of the evolution of a transaction.

The following describes whether the parameters are mandatory or not for each type of request exchanged between the company and the TCP interface:

DELIVER

Parameters that the company receives following an SM message from MS:

An example of a deliver message is the following (<SP> represents the space character):

ACK (Deliver)

There are no ACK parameters following an SM message from MS.

An example of an ACK message is as follows:

TM0003ACK

NAK (Deliver)

Parameters that the company can send as NAK following an MS message from MS:

An example of a NAK message is the following (<SP> represents the space character):

SUBMIT

Parameters that the company indicates to send an SM message to the MS:

An example of a submit message is the following (<SP> represents the space character):

ÀCK (Submit)

Parameters that the company can receive as ACK following an SM message sent to the MS:

An example of an ACK message is as follows:

If the Status Report is requested, these two parameters must be used to identify which SM request message the received Status Report refers to. NAK (Submit)

Parameters that the company can receive as NAK following an MS message sent to the MS:

An example of a NAK message is the following (<SP> represents the space character):

STATUS REPORT

Parameters that the company receives following a Status Report operation:

ϋη example of a Status Report message is the following (<SP> represents the space character):

ACK (Status Report)

There are no parameters.

An example of an ACK message is the following:

NAK (Status Report)

Parameters that the company can receive as NAK following a notification request for an SM message sent to the MS:

An example of a NAK message is the following (<SP> represents the space character):

2.9.2.4 Examples of requests

By way of example, information flows are indicated for the various types of requests with an indication of the direction of the flow:

MS message sent by MS company:

From the operator's system to the company

From the company to the operator's SYSTEM

SM message sent by the company to the MS:

From Company to Operator Systems

From company to operator systems

SM message sent by company to MS with request for Status Report:

From Company to Operator Systems

From

From operator systems to company

From company to operator systems

2.Θ.2.5 Error codes

The error codes that are associated with the NACK, based on the value, are identified in:

• Temporary: the message will be repeated with the retry policies

• Permanent: the message will no longer be repeated

If the company uses a NAK without an error code definition, the TCP interface uses a permanent error code.

In order to simplify development and testing activities, it is generally recommended to adopt the following policy:

Submit

• an ACK indicates that the message has been forwarded to the GSM network. This does not mean that it will be delivered. The certainty of delivery or not will only be obtained with a Status Report (if required). A message may not be delivered if the MS is unreachable for the validity time associated with the message

• a NACK indicates that the message was not delivered. Normally the error code could be one of the following: 24, 55, 56 and

Deliver

• an ACK confirms the acknowledgment of the message

• a NACK indicates that the message will not be taken over. With regard to the error code to indicate, the following values are recommended:

4: Temporary error code (the message will be repeated)

17: Permanent error code (the message will not be repeated)

Below is the entire list of error codes that can be sent by the operator's SYSTEM to the company in response to submit requests.

Claims (59)

CLAIMS 1. Technique for accessing company services from the WIRELESS network characterized by the fact of integrating protocols and applications, respectively of the internet network and the cellular telephone network, cooperating for communication between the company and the end user, intervening the cellular telephone network operator as agent of information transfer and protocol conversion: - in requests for information - clean type services - sent by the user in the form of SM messages to the company, - in the sending of spontaneous information - push-type services - from the company to the user, who acquires them in the form of Sm messages, - in the management of notifications of message deliveries both for push-type services and for type cleaned. 2. Technique for accessing company services from WIRELESS network by means of HTTP communication protocol according to claim 1 characterized by the fact of allowing the reception of SM messages from mobile terminals and sending of SM messages from the company to said mobile terminals through the use of a software interface based on HTTP, providing: I - a clean service that allows the mobile user to request information from the company by sending an appropriately structured SM message, to which the company replies at least with an SM message containing the requested information, II- a push service that allows the company, on its own initiative, to send SM messages containing information to the mobile user, and ΙΠ- a notification service on the outcome of the delivery of the SM message. 3. Technique for accessing company services from WIRELESS network by means of HTTP communication protocol according to claims 1 and 2 characterized by providing for the interaction of the following systems: - mobile terminal, - GSM network of the operator, - operator infrastructure, - client company, using said operator infrastructure the various enabling technologies supported by the GSM network such as SM, WAP, IVR, Internet and a resident HTTP software interface, operating as an HTTP client towards the company capable of providing the typical services of a web server. 4. Technique for accessing company services from WIRELESS network by means of HTTP communication protocol according to claims 1, 2 and 3, characterized by the fact that the following operational steps are foreseen in the context of the pulì service: I- the mobile terminal sends an SM message to the company; Π- the software interface translates the SM message into the web page address or URL, associated with the requested service, to be sent to the company using the HTTP (GET) protocol; ΙΠ- the company responds to the URL received, sending to the system in HTTP mode, an HTML page containing the text of the response and the recipient; IV- the software interface processes the HTML page received and forwards an SM message containing the text of the reply to the recipient. 5. Technique for accessing company services from WIRELESS network using HTTP communication protocol according to claims 1, 2, 3 and 4 characterized by the fact that the mobile terminal accesses the pulì service by sending a structured SM message to a particular number that identifies the company, by activating a procedure for counting a maximum time for receiving the response from the company, the system committing itself, after this time without having obtained the requested information, to send a message to the terminal warning of the temporary unavailability of the service . 6. Technique for accessing company services from WIRELESS network using HTTP communication protocol according to claims 1, 2, 3 and 4 characterized by the fact that each communication from the mobile operator's systems to the company takes place through the establishment of a session on HTTP protocol, being: I - the request for information implemented by the terminal via SM message, translated into a URL request to the company server, taking care of the HTTP software interface residing in the operator's infrastructure to generate the URL to be sent to the company server based on the format of the SM message and the information given in the configuration form, II- performed a syntactic check via the HTTP software interface, on the format of the SM message generated by the terminal, in order to differentiate the URL to be invoked according to the SM received, and if an anomaly is found, send an appropriate error message to the terminal, without carrying out any GET to the company's web server; ΙΠ- extracted following the URL request, by the company, the information from its information systems and sending the response to the HTTP interface through an HTML page characterized by a series of configurable TAGs agreed with the company in which they are contained appropriate information such as text, telephone number, any identification of the message. 7. Technique for accessing company services from WIRELESS network by means of HTTP communication protocol according to claims 1, 2, 3 and 4 characterized by the fact that when sending information to the terminal: I- the HTTP interface that receives the HTML page, sent by the company, containing the requested information, converts it into an SM response message addressed to the mobile user; II- the GSM network sends the SM message until its delivery or until the expiry of a time interval, Validity Period, established and configurable within the HTTP interface; ΠΙ - if requested by the company, the HTTP interface provides notification of the delivery outcome for the messages sent. 8. Technique for accessing company services from WIRELESS network by means of HTTP communication protocol according to claims 1, 2 and 3 characterized by the fact that the following operating steps are foreseen within the PUSH service: I - the system sends the company, with an agreed periodicity, the address of an appropriate HTML page using the HTTP protocol (GET); Π- the company, following the URL received, responds by sending to the system, in HTTP mode, an HTML page containing: i - the text of one or more messages and the identifiers of the recipients if the company wishes to provide the push service; or ii- the indication that you do not want to provide the push service; ΠΙ- the system processes the received HTML page and, depending on its content, forwards the SM messages contained in the HTML page to the recipients. 9. Technique for accessing company services from WIRELESS network using HTTP communication protocol according to claims 1, 2 and 8 characterized by the fact that following the request for the URL, the company extracts the information from its information systems and sends the response to the HTTP interface through an HTML page that has: - fixed format, characterized by a single application tag within which messages and recipients are contained, according to an established format, or - configurable format, characterized by a template containing various application tags whose description is defined in the configuration module. 10. Technique for accessing company services from WIRELESS network using HTTP communication protocol according to claims 1, 2 and 8 characterized by the fact of managing a status report for each SM message sent by the company to the mobile terminal through an HTTP software interface, making available to the company the set of notifications in which he is interested, both for push-type and pulì-type services. 11. Technique for accessing company services from a WIRELESS network using HTTP communication protocol according to claims 1, 2 and 10 characterized by the fact that for notification in the Push type service, if the company Customer is interested in real-time notification of occurred or failure to deliver the message, each message sent to the HTTP interface is accompanied by a unique identifier (id-B), associated both to the single MS and to a message for a list of MS, in this last case, said identifier being identified by the string: separator user id-B, hence the HTTP interface that proceeds with the transmission of the message to an SMS-C of the GSM network expects a confirmation from this accompanied by an identifier for said SM, and each SMS-C, having received a message, returns a Time Stamp, which together with the recipient's MSISDN represent, within that SMS-C, the key to uniquely identify said message, constituting this pair, together with an SMS-C identifier, an id-A message identifier within the application, and by the fact that the HTTP interface, upon receiving the confirmation of the GSM network, stores the association between the identifier assigned by the company id-B and Γ identifier id-A received from the network, therefore , upon receipt of the report from the SMS-C, accompanied by the identifier of the message to which the report refers, the HTTP interface id-A, through which it goes back to the identifier given to the message by the company, (id-B) or its extension ne MSISDN / User Code, id-B, by transmitting the HTTP interface, the pair of information, reports, id-B or its extension via URL to the corporate customer. 12. Technique for accessing company services from WIRELESS network using HTTP communication protocol according to claims 1, 2 and 10 characterized by the fact that for notification in the Push type service, in the event that the notification itself occurs through Status Report at the end of the session , the HTTP interface produces a report file containing the outcome of the delivery of each SM message taken over by the GSM network, indicating the GSM network, for each SM message, whether or not it is being taken over, or providing, in otherwise, to send the SM message until delivery of the same or until the expiration of the Validity Period, thus defining for each SM message, during the transmission phase, its status and keeping track of the HTTP interface of the status of each message SM, for which the relative session is considered closed only when the outcome relating to the delivery of all the expected messages is acquired, and by the fact that upon closing the session ne, the HTTP interface makes the report file available in an appropriate directory and sends a URL to the company to inform it of the presence of the Status Report, therefore the company is able to take this file via FTP and delete it at the end of the transfer. 13. Technique for accessing company services from WIRELESS network using HTTP communication protocol according to claims 1, 2, 3 and 4 characterized by the fact that for the corporate customer interested in receiving the delivery notification for replies sent to the MS, each HTML page response contains a unique identifier for each message contained therein, transmitting the HTTP interface to the company, upon receipt of the delivery notification, an appropriate notification URL for each recipient of a specific message, containing the date delivery, the outcome and the identifier of the message itself. 14. Technique for accessing company services from WIRELESS network using HTTP communication protocol according to claims 1, 2, 3, 4 and 8 characterized by the fact of arranging the activation and deactivation requests, for both clean and push services, made directly from the MS, providing the following operating modes of the activation / deactivation service managed by the HTTP interface: I- the company customer assigns a unique identification code or user code to any user of the pulì or push services; Π - the user, through the MS, requests the activation of the service by sending an SM to the company, containing the activation command, the user code assigned to him and the password assigned to him by the company; ΙΠ- the HTTP interface in receiving the activation request SM message, invokes the relative activation URL, to the web server containing the information typed by the user; IV - the company replies with an HTML page in which it indicates to the interface if the user code and password are correct; V- the HTTP interface, in case of successful activation, records the association between the user code and the telephone number of the MS, responding in any case to the user with a successful or failed activation SM message. VI - the activation remains valid until the MS requests the deactivation, by sending an appropriate SM, or requests a new activation on the same MS, or requests the same activation from another MS. 15. Technique for accessing company services from WIRELESS network using HTTP communication protocol according to claims 1, 2 and 3 characterized by the fact that the personalization of the communication between the company's systems and those of the operator, in the URL that the interface sends to the company and in the HTML response page, by specifying, together with the request for a service by the terminal and together with the sending of information by the company to the terminal, further information regarding the methods to be used for the sending the SM message to the mobile user, both by establishing the identification string for each piece of information, and by indicating which information is compulsorily reported in the communication between the HTTP software interface and the company, in the configuration form, said information contained in the communication between the company and the operator including: I - the outcome of the operation, where by operation we mean the request for a PUSH page (possibly as a response to a PULL), the outcome being positive (0, ok) if the page contains messages with the relative recipients, negative (1, ko) if there are no messages to send. II - the user code, or user code provided when activating the service, alternatively using, directly, the telephone number of the recipient indicated with MSISDN. IH - the Msgld message identifier, used for the management of the Status Reports, this information being present only if the Status Reports are managed. IV- the page identifier, or Pagld, that the application can use to request the company to delete the HTML page once acquired, this information may not be present if the company automatically removes the page, once returned in response to an HTTP GET. 16. Technique for accessing company services from WIRELESS network by means of HTTP communication protocol according to claims 1, 2 and 3 characterized by using the following syntax for the SM message, sent or received by MS, <SP> :: = 0x20 17. Technique for accessing company services from a WIRELESS network using HTTP communication protocol according to claims 1, 2 and 3 characterized by the fact of using the following syntax for the URL used, in the interview, by the operator's systems towards those of the corporate customer : 18. Technique for accessing company services from WIRELESS network using HTTP communication protocol according to claims 1, 2 and 3 characterized by the fact of implementing the communication between the operator's systems and those of the company through http GET procedures, performing the the server functionalities and the operator systems the client functionalities, attributing to the HTTP interface the management of the configuration data relating to the communication to the company customer and the methods of construction of the URL and being configurable by the customer the name of the commands, the name and number of parameters provided for each command, the additional information to be included in the communication. 19. Technique for accessing company services from WIRELESS network using HTTP communication protocol according to claims 1, 2 and 3 characterized by using the following syntax for the document in HTML format used for communication between company and operator via HTTP: 20. Technique for accessing company services from WIRELESS network using HTTP communication protocol according to claims 1, 2, 3 and 13 characterized by using the following notification file syntax relating to a Push service with Status Report at the end of the session: 21. Technique for accessing company services from WIRELESS network using FTP communication protocol according to claim 1 characterized by the fact of including interworking procedures between the mobile terminal, the GSM network, the operator's infrastructure and the company customer for the management of the following operational phases: I - the corporate customer transfers, in FTP (put) mode, to the network operator's systems a file in ASCII format containing a set of messages and a list of MS numbers to which the messages are intended, II- the system processes the file in ASCII format forwarded by the company by forwarding the messages to the relative recipients in SM mode, III the system makes available, if requested by the company in FTP (get) mode, a file in ASCII format containing a report on the processing of the message file, said operator infrastructure constituting the system that allows the service to be provided using the various enabling technologies supported by the GSM network such as SM, WAP, IVR, Internet. 22. Technique for accessing company services from a WIRELESS network using the FTP communication protocol according to claims 1 and 21 characterized by arranging that in the service request phase, the Company Customer transfers the information to be transmitted to the system in FTP mode, listed in a appropriate ASCE file, which groups together a set of messages and lists of MS numbers to which the messages are intended; the data being organized in the file with established criteria and syntax, said company carrying out the operations relating to: - locally prepare the ASCII file with the messages, - make an FTP connection to the operator's system, providing the usemame and the relative authentication password specifically defined for the corporate customer, - transmit via FTP (put) the file in a specific directory (<InputDirectory>) of the system, agreed in advance and in any case modifiable by configuration, - close the FTP session, and by the fact that the name of the file to be transmitted is constructed according to a pre-established nomenclature standard, with which a priority level of processing the file is assigned, since it is possible to provide a series of parameters related to the company, such as the date of preparation of the file, the validity period of the message or the request for notification. 23. Technique for accessing company services from WIRELESS network by means of FTP communication protocol according to claims 1 and 21 characterized by the fact that in order to prevent the software interface from processing the file before the end of its transfer, the corporate customer proceeds to assign a temporary name to the file, and at the end of the FTP transfer, the company customer himself proceeds to rename the file from temporary to definitive so that the latter can be handled by the interface. 24. Technique for accessing company services from WIRELESS network using FTP communication protocol according to claims 1 and 21 characterized in that the software interface performs the following operations for the provision of the service: I- periodically check the <InputDirectory> for the presence of the file, Π- move the file to a working directory for processing, ΙΠ- proceeds to send all the MS contained therein, these operations being performed with a time period established in the software interface configuration module. 25. Technique for accessing company services from WIRELESS network using FTP communication protocol according to claims 1 and 21 characterized by the fact that for the notification operations of the service provided for each file transmitted, the company customer can request information regarding the delivery of messages, the software interface being set up to perform the following operations: I- collect in the report file, in a working directory, the result of the message forwarding, Π- move the generated report file to a special directory, <OutputDirectoiy>, of the system, defined in advance and in any case modifiable by configuration, ΓΠ- proceed with sending all the MS contained therein, and, in turn, the Customer is a company predisposed to: i- get the report file via FTP (get) from the <OutputDirectory>, ii- delete the report file after reading from the <OutputDirectoiy>. 26. Technique for accessing company services from WIRELESS network by means of FTP communication protocol according to claims 1 and 21 characterized by the fact of managing the processing priority of SM message files, checking, the FTP software interface, the presence in the <IntputDirectoiy > of the SM message file to be processed and if there are more SM message files, starting to process the files according to the order of priority established by the Company Customer, since the SM message files are without priority indication, or with priority of the same level, processed according to the creation date. 27. Technique for accessing company services from WIRELESS network using FTP communication protocol according to claims 1, 21 and 26 characterized by the fact of managing the provision of the service, relative to a specific message file, on the basis of the following time quantities: * File creation date (to), * Validity Period (VP) within which to forward a specific message, * Minimum Validity Period (VPmin), as the minimum value of VP that can be assigned to a message, * Time interval for processing the file (δtef) as the time interval that the interface takes to scan and process the requests for forwarding messages, * Time interval for processing a message (δtem) as the time interval that the interface takes to scan and process the request for forwarding a single message. 28. Technique for accessing company services from WIRELESS network using FTP communication protocol according to claims 1, 21, 26 and 27 characterized by the fact of using a static management in the provision of the service by arranging the equality between the validity period VP and the validity minimum period VPmin, since all the messages relating to the same file are sent to the MS recipients with the same VP value, whether it is set in the file or, in its absence, in the configuration module, these messages remain in the GSM network for an even time at most to: compared to the file creation date. 29. Technique for accessing company services from WIRELESS network by means of FTP communication protocol according to claims 1, 21, 26 and 27 characterized by the fact of dynamically managing the VP assigned to a message relating to the same file as a function of the processing time of the messages like VP (i) = VP - 5tem (i) being * VP (i) the value of VP assigned to the i-th message * 5tem (i) the time interval elapsed from the 3⁄4 time to processing the i-th message and the validity period VP being greater than the minimum validity period VPmin therefore, over time, the VP of the messages is decreased and the dispatch is interrupted as soon as its value reaches the value of VPmin, thereby remaining the messages in the GSM network for a time equal to more than: with respect to the date of creation of the file. 30. Technique for accessing company services from WIRELESS network using FTP communication protocol according to claims 1 and 21 characterized by the fact of operating in the SM message file with the following syntax, lue>)? <SuffixSMFileName>; being <PrefixSMFileName> a constant string defined among the parameters of the configuration module, so that the interface only processes files whose name begins with this prefix, hence, in order to avoid processing a file whose transfer is not completed , the file in question is transferred with a different name and only at the end of the transfer the name of the message file, started with <PrefixFileName>, is assigned for processing; <PriorityID> a constant string defined among the configuration module parameters whose presence in the name indicates the assignment to the file of a certain priority indicated by the value of <PriorityValue>; <PriorityValue> a digit indicating the priority given to the file; <SuffixSMFileName> the free part of the file name. 31. Technique for accessing company services from WIRELESS network by means of FTP communication protocol according to claims 1 and 21 characterized by the fact of operating with the following syntax for the notification file: rityValue>)? <SuffixSMFileName> 32. Technique for accessing company services from the WIRELESS me network by means of the FTP communication protocol according to claims 1 and 21 characterized in that it operates with the following syntax of 34. Technique for accessing company services from the WIRELESS network by means of the SMTP communication protocol according to claim 1, characterized by the fact of including interworking procedures between the mobile terminal, the GSM network, the infrastructure of the operator and the company customer and by arranging the '' sending of SM messages to MS through the following operating phases: I- the company sends an e-mail, in SMTP mode, addressed to a specific mailbox of the network operator's system and containing the message and the recipient's identification; Π - the operator's system processes the e-mail received and routes the message contained in the recipient in SM mode; ΙΠ- if requested by the company, the system generates an e-mail notification through which the company is informed about the outcome of the message delivery; and from the fact that the reception of SM messages from MS takes place by arranging that: i- the MS sends an SM message to a particular number which, within the system, identifies the company; ii- the system sends an email containing the sender's identification and the text of the message to a specific mailbox of the company; constituting said operator infrastructure the system that allows the service to be provided using the various enabling technologies supported by the GSM network such as SM, WAP, IVR, Internet, and a dedicated SMTP software interface, residing in the operator's infrastructure, the unit that makes available the mailbox to which the company directs the e-mail messages. 35. Technique for accessing company services from WIRELESS network using SMTP communication protocol according to claims 1 and 34 characterized by the fact that when requesting the service for sending an SM message to MS, the company addresses the mailbox of the software interface , via SMTP protocol, an appropriately structured e-mail message, specifying in the first part, relating to the header of the e-mail message, all the information used by the system to send the message correctly and entering, the company, the text of the actual message, in the second part of the e-mail message, the information contained in the header of the e-mail message, which the company sends, including at least the fields: * Sender (From) with the company's e-mail address; * Recipient (To) with the e-mail address of the SMTP software interface; * SM recipient with the recipient MSISDN of the SM message. 36. Technique for accessing company services from WIRELESS network using SMTP communication protocol according to claims 1 and 34 characterized by the fact that in the procedure of receiving an SM message from MS, the latter composes the text of the SM message, sends it to a particular number that, within the system, identifies the customer, the recipient company, possibly being specified in the text of the message an e-mail address of the recipient company, to which the message is sent directly, this e-mail address -mail, alternative to the standard company address, having value only for the SM message within which it is contained. 37. Technique for accessing company services from WIRELESS network using SMTP communication protocol according to claims 1 and 34 characterized by the fact that in the provision of the service for the translation of an SM message into e-mail, the SMTP software interface that receives the messages SM addressed to a specific company, for each SM message generate an appropriately structured e-mail message, specifying the operator in the first part of the e-mail message header, all the information used to send the message correctly such as: * Sender (From) contains the e-mail address of the SMTP software interface; * Recipient (To) contains the company's e-mail address; * Subject contains the subject of the e-mail message and in the second part the actual text relating to the e-mail message. 38. Technique for accessing company services from WIRELESS network using SMTP communication protocol according to claims 1, 34 and 37 characterized by the fact that as an alternative to using the e-mail address indicated in the configuration form, the SMTP interface manages the evaluation of the recipient (To) of the e-mail message by reading the company address directly in the text of the SM message. 39. Technique for accessing company services from WIRELESS network using SMTP communication protocol according to claims 1 and 34 characterized by the fact that in the phase of providing the service for the translation of an e-mail into an SM message, the software interface receives the e-mail message, appropriately structured, sent by the company, containing the identification of the recipient and the text of the SM message, constituting the text of the mail the text of the SM message, carries out the appropriate conversions and routes the message to the recipient, if no error is found in the e-mail, send an error e-mail to the Customer Company with an indication of the error found, if the interface detects an error. 40. Technique for accessing company services from the WIRELESS network using the SMTP communication protocol according to claims 1 and 34 characterized by the fact that for Γ sending SM messages to the MS, the Company Customer can request the interface to generate an e-mail notification by which the company is informed of the outcome of the delivery of the aforementioned message. 41. Technique for accessing company services from WIRELESS network using SMTP communication protocol according to claims 1 and 34 characterized by the fact of specifying additional Custom Header information regarding the methods to be used for sending the SM message allowing the following sending methods: * sending an SM message in date format instead of text; * sending an SM message with a validity period; * notification request, with the following indications relating to mandatory: 42. Technique for accessing company services from WIRELESS network using SMTP communication protocol according to claims 1 and 34 characterized by the fact of specifying additional Custom Header information in the header of the e-mail message, regarding the methods for sending the SM message in date format instead of text providing that in the sending phase: I - the company inserts the appropriate custom headers in the e-mail message to indicate to the SMTP software interface to correctly interpret the message text; II - the company transforms the message from date format to text format by encoding each byte of the original message with two characters representing the corresponding hexadecimal encoding of the byte to be transmitted; ΙΠ- the company forwards an e-mail to the SMTP software interface, the text of which contains the message represented in the aforementioned format; IV- the SMTP software interface converts the received message into the original date format before sending it to the MS; and by the fact that when receiving an e-mail message in date format: i- the MS sends the SM message in date format to the SMTP software interface; ii- the SMTP software interface transforms the message from date format to text format by encoding each byte of the original message with two characters representing the corresponding hexadecimal encoding of the byte to be transmitted; ii- the company, in order to correctly interpret the message received, converts the message itself from hexadecimal format to original date format 43. Technique for accessing company services from WIRELESS network using SMTP communication protocol according to claims 1 and 34 characterized by the fact that when sending an email message from the company to the operator's systems the syntax of the e-mail used for communication includes the following fields: 44. Technique for accessing company services from WIRELESS network using SMTP communication protocol according to claims 1 and 34 characterized by the fact that when sending an email message from the operator's systems to the company's systems, the syntax provides for the use of the following fields: <Mail> :: = <HeaderxContent> 45. Technique for accessing company services from WIRELESS network using SMTP communication protocol according to claims 1 and 34 characterized by the fact that in the sending of e-mail notification of the service provided, the syntax of the notification protocol addressed by the operator's systems to company systems via SMTP, provide the following fields: 46. Technique for accessing company services from WIRELESS network with communication protocol by means of SOCKET according to claim 1 characterized by the fact of including interworking procedures between the mobile terminal, the GSM network, the operator's infrastructure and the company customer, making that company and terminal communicate through the use of SM messages through a software interface based on SOCKET connection and proprietary protocol, residing within the SYSTEM, which manages the SM messages coming from MS translating them into specific requests addressed to the company and to manage the information coming from the company by translating them into SM messages sent directly to the MS, configuring a service according to the following procedures: I - a clean service that allows the MS to request information from the company by sending an appropriately structured SM message, the company responding to the MS with an SM message containing the requested information, and Π - a push service that allows the company, on its own initiative, to send SM messages containing information to the MS, and by the fact of i- prepare the connection with the operator's SYSTEM by communicating to the operator the IP addresses assigned to his system; and ii- create the dialogue layer with the TCP software interface using a dedicated communication application protocol based on TCP / IP with a Socket connection, the system infrastructure that allows these VAS services to be provided using the various technologies enabling supported by the GSM network such as, SM, WAP, IVR, Internet. 47. Technique for accessing company services from WIRELESS network with communication protocol through SOCKET according to claims 1 and 46 characterized by the fact that the TCP software interface resident on the SYSTEM implements the main functions relating to: I- conversion of SM messages coming from MS in strings formatted according to the socket-based protocol, Π- conversion of strings formatted according to the socket-based protocol into SM messages to be sent to the MS, ΙΠ- Storage of the information necessary for the tracking of messages in transit on the SYSTEM, IV- management of the UCP protocol towards the SMS-C of the GSM network; arranging for the exchange of the following types of messages: the SM messages sent by the MS to the requesting company for clean transactions; ii- SM messages sent by the company to the MS in response to a clean transaction; iii- SM messages sent by the company to the MS for push transactions: iv- Status Report (SR) messages sent to the company by the TCP interface for the notification of the result of the last delivery attempt, made by the GSM network, of the SM message to the MS. 48. Technique for accessing company services from WIRELESS network with communication protocol by means of SOCKET according to claims 1 and 46 characterized by implementing the following flow of information in the connection between the company's systems and the operator 49. Technique of access to company services from WIRELESS network with communication protocol through SOCKET according to claims 1 and 46 characterized by the fact of assigning, to the company, in the connection between the company's systems and the operator, a door , on the operator system, for the realization of the connection which allows the sending of messages SM towards the MS; the company by providing a port for forwarding SM messages addressed by the MS to the number short associated with the service, establishing two connections with the following configurations: I - communication from the operator to the company: IP address and destination port of the client company where the connection is made and the information flow is sent, - SM messages from MS and Status Report - connected to the IP address of the machine with dynamic source port; II- communication from company to operator systems: machine IP address and destination port where the connection is made and the information flow is sent (SM messages to MS) connected to the IP address of the machine Customer Company with dynamic source port or default. 50. Technique for accessing company services from WIRELESS network with communication protocol through SOCKET according to claims 1 and 46 characterized by the fact that the protocol provides, in the connection between the company's systems and the operator, as the first operation that the connection between the operator's systems and the company and vice versa, that the exchange flows for SM messages from MS, SM messages to MS and Status Report are subsequently activated; the company acting as a client in case of SM messages to be sent to MS, thus establishing the connection on the Socket for SM messages and then submitting the sending commands; the company's systems acting, on the other hand, as a server in case of SM messages coming from MS or Status Report, being therefore the TCP interface to establish the connection on the socket for SM messages or Status Report and then to submit the sending or notification commands. 51. Technique for accessing company services from WIRELESS network with communication protocol through SOCKET according to claims 1 and 46 characterized by the fact of making said socket connection, in the connection between the company's systems and the operator, through the One-way Socket mode , providing the operator, two connections, one used to forward the SM received from MS to the company, the other to receive the command for the delivery of SM messages to the MS, the relative ACKs / NAKs being sent on the same connection on which the SM message or the Status Report was sent. 52. Technique for accessing company services from WIRELESS network with communication protocol by means of SOCKET according to claims 1 and 46 characterized by the fact that in the provision of a clean service the request for information from MS takes place by sending an appropriately structured SM message to a particular number that identifies the company, and in the event that the company system is not connected to the operator's SYSTEM, the TCP interface is enabled to send a courtesy response to the MS who send SM messages to the short number associated with the 'agency. 53. Technique for accessing company services from WIRELESS network with communication protocol through SOCKET according to claims 1 and 46 characterized by the fact that in the provision of a clean service for communication between the operator and the company: I - the request for information made by MS via SM message, is translated by the TCP software interface into a string formatted according to the application protocol and then the TCP interface sends the formatted string to the location of the company system configured for management of SM messages coming from MS, from this same port the TCP interface expecting a confirmation message (ACK or NAK) from the company, enabling, the receipt of the confirmation, the system to forward to the company any subsequent string of formatted characters containing an additional SM message; Π- the ACK or NAK is sent by the company within a predetermined maximum time, after which the SYSTEM considers the SM message not delivered and applies retry policies; ΙΠ- following receipt of the formatted character string containing the SM messages from MS, the company extracts the information from its information systems and sends the response, contained in a new character string formatted according to the socket-based application protocol, on the locai pores: of the SYSTEM configured for the management of SM messages to be sent to the MS; IV - expecting a confirmation message from the system of the company (ACK or; NAK) from the SYSTEM, the receipt of the confirmation enables the system of the company to submit a possible subsequent string of characters to the SYSTEM of the operator containing a new SM message. 54. Technique for accessing company services from WIRELESS network with communication protocol through SOCKET according to claims 1 and 46 characterized by the fact that in the provision of a clean service for sending information to MS, the TCP interface, which receives the character string from the company system containing the requested information, converts said string into a response SM message addressed to the MS. 55. Technique for accessing company services from WIRELESS network with communication protocol through SOCKET according to claims 1 and 46 characterized by the fact that, in the provision of a PUSH service for communication between the operator's systems and the company, the 'company sends a character string containing the message text, formatted according to the Socket-based application protocol, on the SYSTEM local port configured for the management of SM messages to be sent to the MS, expecting a confirmation message from this same port (ACK or NAK) by the SYSTEM, the receipt of the confirmation, enabling the company system to submit to the SYSTEM any subsequent string of characters containing a new SM message. 56. Technique for accessing company services from WIRELESS network with communication protocol through SOCKET according to claims 1 and 46 characterized by the fact that for the notification of the service provided in the case of SM messages sent by the company to the MS in response to requests from the MS (clean service) or on its own initiative (push service), the company requests the TCP interface for notification of the successful delivery of messages (Status Report), sending, the TCP interface, a sequence of characters formatted according to the socket application protocol, containing the Status Report, on the location of the company system configured for the management of SM messages coming from MS, expecting, the TCP interface, from this same port, a confirmation message (ACK or NAK) from part of the company, the receipt of the confirmation enabling the TCP interface to submit a possible subsequent Status Report message to the company. 57. Technique for accessing company services from WIRELESS network with communication protocol by means of SOCKET according to claims 1 and 46 characterized by the fact that the software interface for the application protocol based on socket connection is based on a Tag-Length-Value syntax, each field being defined by the presence of three elements: * Tag: fixed length field label of n ASCII characters * Length: length of the fixed length field value of n ASCII numeric characters * Value: value of the field 58. Technique for accessing company services from WIRELESS network with communication protocol by means of SOCKET according to claims 1 and 46 characterized by the fact that the data structure in the communication between the company's systems and the operator expect a syntax like: 59. Technique for accessing company services from WIRELESS network with communication protocol through SOCKET according to claims 1 and 46 characterized by the fact that a defined number of usable parameters is used for the types of requests that can be exchanged between the company and the operator , optional or mandatory, the absence of at least one of the mandatory parameters producing a NAK indicating a particular error code, these usable parameters including: OadC, indicates a numerical value, represented in ASCII, which contains the telephone number of the MS in the case of SM messages from the MS, or the short number associated with the company in the case of SM messages from the company; AdC, indicates a numerical value, represented in ASCII, which contains the telephone number of the MS in the case of SM messages addressed to the MS, or the short number associated with the company in the case of messages addressed to the company; SCTS, indicates the date and time of acceptance of the message by SMS-C, expressed in the following format: ddmmyyhhmmss; EC, contains the error code for NAK type messages. DSCT, contains date and time of the last attempt to deliver the message to the MS, being the same format as the SCTS parameter; VP, indicates the maximum time within which SMS-C attempts to send the message, if omitted, the default parameter entered in the configuration module is used; NRq, is inserted in the submit message to indicate a Status Report request, if it is omitted, the default parameter entered in the configuration form is used; DST, represents the Delivery Status of an SM message sent to the MS; if it is omitted, the default parameter inserted in the configuration module is used; MSG, is the text message sent to the MS or received by the MS; Log, contains information necessary for tracking, being used in messages sent by the company to the operator's SYSTEM to contain information necessary for tracking.