ITMI20110394A1 - SYSTEM AND METHOD FOR THE MANAGEMENT OF REMOTE DEVICE OPERATIONS. - Google Patents

Description

SYSTEM AND METHOD FOR THE MANAGEMENT OF REMOTE DEVICE OPERATIONS

DESCRIPTION

The present invention is part of the field of remote transaction management, with particular reference to the management of dispositive operations via mobile devices and networks.

Effective information management is a strategic imperative for individuals who need to operate in real time. Important operations, such as delicate economic transactions or management of personal data that require the prompt intervention of the user, must now be managed more and more often not only from home or from the office, but also and above all in situations of mobility, especially through use of commonly used devices, such as smartphones or PC tablets.

The intervention required by the user for the execution of this type of transaction can also consist of a series of various and complex configuration operations that may require non-trivial timing and high levels of attention.

Technologies are known in the state of the art which allow the exchange of information between a user using a portable device and a remote server which, duly configured, alerts said user to the occurrence of certain conditions. For example, it is possible for a user to become aware, by receiving an email or an SMS, of the fact that their credit card has been used and to intervene, in the event of fraudulent use, by informing the competent authority. Once the credit card is passed to a POS, a special risk center intervenes by notifying the operation to the server which in turn informs the legitimate holder. Of course, failure to receive the message and the consequent untimely intervention will cause serious economic damage as potential criminals will be able to use the credit card undisturbed.

More generally, the main banking institutions are equipped with home banking applications that allow affiliated users to carry out information and dispositive operations on their current account, for example sending a bank transfer, via a web interface (internet banking) , and in recent years these interfaces have also been made available to users of mobile devices (mobile banking).

In general terms, users connect to banking systems by accessing a network (computer and / or mobile phone), via a web interface, such as a browser, enter their credentials, and, once logged in, perform the desired transactions by interacting with the interface, for example by filling in online forms and launching commands. Some types of transactions require user-system interactions involving a number of steps. All these interactions take place in online mode, that is to say in the presence of an Internet connection, via a computer or cellular network, which is always active.

The adoption of mobile banking systems has brought advantages both to banks and to the customers of credit institutions: for the bank, the adoption of these services involves the expansion of the customer target, as well as a reduction in labor costs; customers, on the other hand, benefit from greater convenience, that is, access that is not geographically or temporally limited, of mobile banking services and their lower cost compared to off-line services.

However, the mobile banking systems known in the art are not free from drawbacks: in fact, in the event of any disturbances that affect the network connection, such as absence or weakness of the field or lack of available bandwidth, the transactions may not be successful; this entails the need for the user to access his home banking or trading platform again at a later time, and to repeat the operations until adequate signal conditions exist. This situation will therefore cause serious inconvenience for the user who is forced to repeat the same operations over and over again, often with no load, and to constantly monitor the level of the signal and the band.

From this it is clear that these technologies, although important, are however limited as they do not protect against the risks inherent in the characteristics of the communication channel with the remote server. It is therefore a deeply felt need in the art to provide new systems and methods for the management of such operations which allow a safe and fast iteration between user and system regardless of the state of the communication network.

The aim of the present invention is to overcome the limitations of the prior art highlighted above, devising a system and a method which allow to manage transactions remotely via a mobile device even in conditions of weak or absent signal.

Within this aim, the object of the present invention is to provide a method and system for the remote management of transactions which combines a simple and intuitive user interface with a low management load required by the user.

A further object of the present invention is to provide a method and system for the management of remote transactions which guarantees ACID and secure transactions.

Not least object of the present invention is to provide a system and a method which is simple to implement and apply, easily integrated with existing software and hardware devices, and at low costs.

This task, these aims and others which will become clearer from the description of the present invention are achieved by a system for the management of remote transactions, comprising at least one server configured to communicate through a cellular network and a plurality of terminals each equipped with at least one telephone card associated with a telephone number reachable through the cellular network, each terminal being also provided with a user interface for displaying data and for selecting commands, characterized in that the server and the plurality of terminals comprise means of communication through SMS formatted on the basis of a proprietary protocol and by the fact that the terminals include means for the automatic conversion of the information encoded in the SMS messages into information that can be viewed in the user interface and for the automatic conversion of commands given by the user into encoded information. on the basis of the proprietary protocol and intended for the server.

The terminal can provide a listener module configured to intercept all incoming SMS and identify SMS formatted according to the proprietary protocol, as well as means for extracting information encoded in the aforementioned SMS messages and the relative display of the information on the screen, also for the on-screen presentation of a user command choice to be sent in response to the communication.

Advantageously, the terminal comprises means for the automatic coding of the response in an SMS message, which can be sent to the server and / or inserted in the queue of outgoing messages from the terminal.

The intended aim and objects are also obtained by a method for managing transactions remotely, comprising the steps which consist in configuring a server to communicate through a cellular network with a plurality of terminals, each equipped with at least one telephone card associated with a telephone number reachable through the cellular network and being also provided with a user interface for displaying data and for selecting commands to be sent to the server; make communications from the server to the terminals through SMS formatted on the basis of a proprietary protocol; automatically converting the information encoded in the aforementioned SMS messages into information that can be viewed in the user interface; converting commands given by the terminals into information coded on the basis of the proprietary protocol and destined for at least one server.

Further characteristics and advantages of the invention will become clearer from the description of a preferred but not exclusive embodiment of the system and method for filing documents, illustrated by way of non-limiting example in the accompanying drawings in which:

Figure 1 is a block diagram relating to the system architecture according to the present invention;

figure 2 is a flow diagram illustrating an embodiment of the client-side information exchange method according to the present invention;

Figure 3 is a flowchart illustrating an embodiment of the server-side information exchange method according to the present invention;

Figure 4 is a block diagram illustrating a possible format of an SMS message used in the system according to the present invention;

figures 5a-5d show a possible sequence of messages exchanged between user, client and server according to a first embodiment of the method according to the invention;

Figures 6a-6e show a possible sequence of messages exchanged between user, client and server according to a second embodiment of the method according to the invention;

Figures 7a-7e show a possible sequence of messages exchanged between user, client and server according to a third embodiment of the method according to the invention.

Figure 1 shows a client-server type architecture comprising a client 1 connected via a telecommunication network 3 to a remote server 2.

The term "Client" refers to a portable computer such as a Smartphone or a tablet-PC.

The telecommunication network 3 is a traditional cellular network, for example of the GSM or UMTS type, which allows in particular to exchange SMS type messages through a communication channel that connects the server 2 with the Client 1.

The term server means any electronic device and related applications able to receive, process and send SMS to the Client and to interact with a Back End Core 10 from which events come in response to which a communication is triggered between Client and server, as described later.

Client 1 as exemplified in Figure 1 comprises three modules.

A first listener module 4 runs in the background on client 1 and listens continuously. The listener module 4 is responsible for recognizing the arrival of a new SMS.

The listener module 4 is preferably able to discern, through an analysis of the formatting of an incoming SMS message, whether the type of incoming SMS is intended for application 6 or not. If so, the listener module 4 provides for take the incoming message and pass it to a parser module 5; otherwise, the message will be handled along the normal Client 1 operating system management chain.

The parser module 5 is configured for the analysis of the SMS message identified as intended for the application in order to extract its content and forward it to the application 6.

The module 6, generically defined "application module", is able to process the information as supplied by the parser 5 and to display, through a suitable window 11 on the terminal of the Client 1, a certain output. This output, possibly accompanied by an audio signal, draws the user's attention by proposing an action to be taken. The application module 6 is also configured to process the input received from the user and to suitably format it for sending to the server 2, as will be illustrated in greater detail below.

The server 2 as exemplified in Figure 1 comprises two modules. The communicator module 7 is an application capable of processing the SMS coming from the Client and generating for the client 1 both the SMS notifying an event, structured in a specific format, and the SMS stimulated by the user's response. The interface module 8 is an interface towards the Back End Core 10 system, through which the server 2, through a communication channel 9, receives the events and information necessary to package a response for the client 1.

The Back End Core 10 is a system configured on the basis of the business logic of the company to which it belongs, for example a banking system, and is able to interact both with Client 1, via server 9, and with other channels communication, such as, for example, the Web. The Back End Core 10 is configured to generate events that include a plurality of operations that are notified in real time, i.e. as soon as they are available, and without requiring client intervention ("push" mode).

The operation of the system according to the invention will now be described, in its client component, with reference to Figure 2.

At step 100, the listener module 4 of client 1, once executed, is constantly waiting, in the background, for new SMS; in particular in step 110 the listener module 4 checks whether a new SMS message has arrived; if the message has not arrived, it returns to step 100 of listening in the background.

If, on the other hand, at step 110 the listener module 4 detects that a new SMS message has arrived, after checking that the SMS message is intended for application 6, it forwards it to the parser module 5.

At step 120, the parser 5 analyzes the SMS received and, if, at step 130, it recognizes it as a valid SMS for the application 6, it extracts the relevant information from it and forwards them to this application module; at step 140 the application module 6 processes this information in a manner that will be illustrated in greater detail below. If, on the other hand, at step 130 the SMS message is not recognized as intended for application module 6, the system returns to step 100, waiting for new SMS messages.

Following the processing carried out in step 140, in step 150 the application module 6 displays in the window 11 of the Client 1 a message proposing to the user an action to be taken.

Following input from the user (step 160), the system performs step 170, in which the user's choice is processed in the background. In particular, the application module 6 packages an SMS message comprising the choice made by the user for sending to the server 2, according to methods which will be described in detail below. As soon as the conditions exist, in particular as soon as a sufficient field is detected for the coupling of the terminal 1 to the cellular network 3, an SMS containing the user's command is sent to the server 2 (step 180).

At step 190 the Client waits for the receipt of a possible response from server 2 or confirmation of the receipt of the message, which can in turn be displayed. Once the management of a message is finished, the system returns to step 100, listening for the arrival of a new message.

The operation of the system according to the invention will now be described, in its server component, with reference to Figure 3.

At step 200 server 3 is waiting for events generated by the Back End Core 10.

In case of notification of a new event (step 210), communicated by the Back End Core 10 through the appropriate communication channel 9 to the interface module 8 of server 2, server 2 performs step 215, which consists in generating, from part of the communicator module 7, based on the information contained in the notified event, an SMS message in a specific format. At step 220 the SMS message generated at step 215 is sent to Client 1.

Server 2 then waits for a response from Client 1. Following receipt of the response from Client (step 230), at step 240 the communicator module 8 processes and sends a transaction to the Back End Core 10, comprising the instructions sent by Client 1 in the reply SMS message. This transaction, which essentially consists of an operation generated by events that require an interaction with the Client, is interpreted by server 2 and translated into a format that can be understood by the Back End Core 10.

At step 250, with methods similar to those adopted in steps 215 and 220, server 2 packages the response received from the Back End Core 10 in the form of an SMS message, which is finally sent to Client 1. Server 2 returns to step 100 and it therefore waits for other events.

The system according to the invention can be, by way of non-limiting example, used in the management of banking operations, financial trading operations or, in general, operations concerning payment with credit cards and the like, as will be illustrated below with reference to some possible embodiments.

Preliminarily, with reference to Figure 4, a possible embodiment of an SMS message format, common to the various embodiments, will be illustrated; as previously illustrated, Client 1 and server 2 communicate via SMS messages, in particular at steps 180, 220 and 250 previously described.

The SMS message 15 illustrated in Figure 4 comprises a header 20 and a body 30.

The header 20 can comprise a field 21 containing information identifying the application, for example a first predefined string which will be interpreted by the listener module 4 as the signal that the SMS 15 received is intended for the application module 6. The header 20 it may further comprise a field 22 containing information identifying the type of transaction, for example a second predefined string which will be interpreted by the parser 5 as indicating the type of action requested, such as the request for authorization to carry out a pre-set transfer.

The body 30 can comprise a data field 31, an amount field 32 and a status field 33.

The data field 31 includes information specific to the type of transaction indicated by field 22; for example, in the case of a bank transfer, it may include information relating to the beneficiary and the purpose of the transfer, while in the case of a. trading may contain information relating to a stock to be sold or bought.

The amount field 32 includes information relating to the amount associated with the transaction to be authorized.

The status field 33 is a flag type field, that is, it contains information relating to the status of the transaction; the content of this field depends on the type of transaction, i.e. on the content of field 22, and may include, depending on the type of transaction, values that can be interpreted as 'pending approval', 'approved', 'not approved', 'sell', 'buy', 'hold', and so on.

With reference to figures 5a - 5c, a possible embodiment of a method for carrying out a pre-set transfer, for example using a traditional Web platform, or a transfer made at regular intervals by the user, will now be described, according to the present invention.

At the end of a payment deadline, the Back End Core 10 prepares the notification of the deadline to client 1 by sending a report to server 2.

To this end, on the basis of a predefined communication protocol, the server 2 packages an SMS message 15, comprising a header 20 and a body 30, as previously illustrated with reference to Figure 4.

Note that even the same user could request operations from server 2, for example to synchronize the information on his device with the information he has entered using the Web platform. Also in this case the Back End Core sends a series of information to server 2 which in turn, after having properly encoded it, will send it to Client 1 via SMS.

A possible example of a message formatted according to the rules described above is illustrated in Figure 5a.

Specifically, as regards header 20, field 21 includes a unique identifier of the application ('ΒΙΖ'), and field 22 includes a unique identifier of the type of transaction ('ID112'), or in this case of the request for authorization to make a pre-set bank transfer.

The body field, on the other hand, includes identification data of the bank transfer for which authorization is requested: in particular field 31 includes the IBAN of the beneficiary and the purpose of the transfer, and field 32 includes the amount of the transfer; finally, field 33 includes the current status of the transaction, in this case 'pending', that is, awaiting authorization.

Client 1 then receives a message of this type from server 2 at step 110. Listener module 4 locates the SMS message and forwards it to parser module 5.

The parser module 5, analyzing the BIZID112 header component, identifies the message as coming from server 2 and relative to a pre-set transfer type transaction. The parser 5 then goes on to examine the body of the message and finds that a bank transfer in favor of the beneficiary whose IBAN is IT12345678901234567 for the payment of a school installment worth 1000 euros is waiting to be authorized.

The parser module 5 then forwards the information extracted from the message to the application module 6. The application module 6 generates a screen 11 on the terminal of the Client 1 indicating to the user that a transfer operation to a specific beneficiary (IT12345678901234567), for a specific reason (school installment) and of a specific entity (EUR1000.00) is awaiting authorization. In a preferred embodiment, the user is offered three possibilities: accept the transaction, reject it or modify its amount.

A possible example of screen 11 generated starting from the SMS message of Figure 5a is illustrated in Figure 5b.

In all three cases, the application module 6 will perform the processing and generation of the message to be sent in response to the server in the background. Figure 5c illustrates three possible response messages, corresponding to the three possible choices that can be made by the user. Note that in all three cases the only component to be modified is a portion of the body, in particular the status field 33 in case of acceptance or rejection of the transaction, while in case of modification of the amount the field will also be modified amount 32.

Once the message has been received from Client 1, the communicator module 7 on server 2, analyzing the header 20 (BIZID112) recognizes the origin of the SMS message and the associated transaction, processes this information and forwards it to the Back End Core 10 via the interface module 8 and the communication channel 9. The server 2 is able to recognize the user by virtue of a plurality of associations, made for example by assigning a specific identification to the user number.

In the event that the user has decided to change the amount of the transfer, the Back End Core 10 will try to perform the operation and will communicate the result to server 2.

In this case the communicator module 7 on server 2 will generate a notification SMS to the customer, informing him of the outcome of the amount modification operation, for example as illustrated in figure 5d.

With reference to figures 6a - 6e, a possible embodiment of a method for the authorization of transactions carried out by credit card according to the present invention will now be described. These transactions may include, by way of non-limiting example, the purchase of an asset through traditional channels, with the consequent use of a POS, or a purchase on the Internet by entering the identification codes of the credit card in a specific form.

Also in this case the Back End Core 10 signals the successful operation to server 2, which prepares the signaling to Client 1.

To this end, on the basis of a predefined communication protocol, the server 2 packages an SMS message 15, comprising a header 20 and a body 30, as previously illustrated with reference to Figure 4.

Specifically, as regards the header 20, the field 21 comprises a unique identifier of the application and the field 22 comprises a unique identifier of the type of transaction, that is, of the request for authorization to perform a credit card operation.

The body field, on the other hand, includes the information associated with the transaction for which authorization is requested: in particular, field 31 includes an identification of the seller, field 32 includes the amount of the transaction; finally, field 33 includes the status of the transaction, in this case 'pending', that is, awaiting authorization.

A possible example of a message formatted according to the rules described above is illustrated in Figure 6a.

Client 1 then receives a message of this type from server 2 at step 110. Listener module 4 locates the SMS message and forwards it to parser module 5.

The parser module 5, analyzing the header component (BIZID44), identifies the message as coming from server 2 and relating to a transaction of the type authorization for payment by credit card. The parser 5 then goes on to examine the body of the message and finds that a payment in favor of www.alitalia.it for an amount of 344 euros is waiting to be authorized.

The parser module 5 then forwards the information extracted from the message to the application module 6. The application module 6 processes this information and generates a screen 11 on the terminal of Client 1 indicating the user the details of the transaction awaiting authorization. In a preferred embodiment, the user is offered two possibilities: to accept the transaction or to reject it.

A possible example of screen 11 generated starting from the SMS message of Figure 6a is illustrated in Figure 6b.

In both cases the application module 6 will perform the processing and generation of the message to be sent in response to the server in the background.

If the user authorizes the transaction, the response message generated by client 1 will be formatted as indicated in figure 6c. If the operation is rejected, the message generated by client 1 will instead be formatted as indicated in figure 6d.

Note that in both cases the only component to be modified is a portion of the body, in particular the status 33 field.

At this point the application module 6, generated the SMS, will wait until there is a signal strong enough to allow it to be sent. The sent message is received by the server 2 which analyzes the header of the message to associate the SMS with the client identified for example by the telephone number and with the operation. Once the identification operations have been carried out, the application processes the message by extracting the user's decision. This information, properly processed, will be forwarded to the interface module 8 which in turn will forward it to the Back End Core 10 using channel 9. Once the notification is received by the Back End Core 10, the server 2 will forward the response to the Client 1 through a message such as the one shown in Figure 6e.

With reference to figures 7a - 7e, a possible embodiment of a method for managing a trading operation according to the present invention will now be described.

By way of example, server 2 can be configured in order to inform Client 1 that the value of a certain set of actions has fallen below a certain threshold. In this case the Back End Core 10 generates a notification event, based on the preset configuration on the trading platform, which is forwarded to server 2 via communication channel 9 and received by server 2 itself via interface module 8. The communicator module 7 processes the event and generates an SMS as shown in figure 7a. Specifically, it indicates that a specific action (PIRELLI PBS) has reached a value (4.87) lower than that of the preset threshold.

Client 1 then receives from server 2 at step 110 a message like the one illustrated in Figure 7a. Listener module 4 locates the SMS message and forwards it to parser module 5.

The parser module 5, analyzing the header component (BIZID27), identifies the message as coming from server 2 and relating to a transaction of the type of trading operation. The parser 5 then passes to examine the body of the message and detects that the action identified as PIRELLI PBS has reached the value 4.87.

The parser module 5 then forwards the information extracted from the message to the application module 6. The application module 6 processes this information and generates a screen 11 on the terminal of the Client 1 indicating the user the details of the trading operation for which authorization is requested. In a preferred embodiment, the user is offered two possibilities: to sell the stock or to keep it.

A possible example of screen 11 generated starting from the SMS message of Figure 7a is illustrated in Figure 7b.

In both cases the application module 6 will perform the processing and generation of the message to be sent in response to the server in the background.

If the user chooses to sell, the response message generated by Client 1 will be formatted as indicated in figure 7c. If you decide not to sell, the message generated by Client 1 will instead be formatted as indicated in figure 7d.

Note that in both cases the only component to be modified is a portion of the body, in particular the status 33 field.

At this point the application module 6, generated the SMS, will wait for a sufficiently strong signal to allow it to be sent. The sent message is received by the server 2 which analyzes the header of the message to associate the SMS with the Client, for example via the telephone number and the type of transaction. Once the identification operations have been carried out, the application processes the message by extracting the user's decision. This information, adequately processed, will be forwarded to the interface module 8 which in turn will forward it to the Back End Core 10 using channel 9. Once the notification is received by the Back End Core 10, the server 2 will forward the response to the Client 1 via a message such as the one shown in Figure 7e.

It has thus been shown that the present invention achieves the intended aim and objects. In particular, we have seen how the system and the method thus conceived allow to overcome the qualitative limits of the known art thanks to the fact that the communication protocol adopted between Client and server is the SMS protocol, and to the fact that both Client and servers take charge of any absence of the field and manage the repeated sending of notification and disposition messages in a transparent manner to the user. In other words, the system according to the invention is capable of operating in offline mode, managing the timing of communications as a function of field conditions, while at the same time guaranteeing the user the security of transactions and releasing him from the repeated management of operations.

It has also been shown that the invention is practical, since it simply requires the installation of a client-side application, which can be downloaded via the Internet, and the interposition of a server between the client and the Back End Core, without modifying the operating logic of the pre-existing Back End Core systems.

Furthermore, the evident advantage of the invention consists in the use of the SMS channel for communication, which allows to operate off-line, limiting the need for connection to the moment of sending or receiving SMS, thus exploiting the SMS feature. to be able to be transmitted with minimal use of network resources and also with little field. Furthermore, the client application uses the SMS format for communication but does not require the user to enter text in an SMS message, taking care of translating commands into SMS format that are easily imparted by the user by means of a graphical interface, maximizing the practicality of use for the user and eliminating the possibility of error typical of applications that also allow remote commands to be given by means of SMS.

Clearly, numerous modifications will be clear and can be readily carried out by the person skilled in the art without departing from the scope of the present invention.

For example, the skilled in the art will easily understand that, even if for simplicity of presentation in the present description all the information is transmitted in clear text, it can be suitably and advantageously encrypted by adopting technologies known in the art.

It is also evident that the inventive concept underlying the present invention is independent of the actual implementation of the software modules, which can be made in any language and on any hardware platform, as well as as firmware applicable to modern electronic devices.

Therefore, the scope of the claims should not be limited by the illustrations or preferred embodiments illustrated in the description in the form of examples, but rather the claims should encompass all of the patentable novelty features that reside in the present invention, including all features. characteristics that would be treated as equivalent by the person skilled in the art.

Claims (10)

CLAIMS 1) Remote transaction management system, comprising at least one server (2) configured to communicate through a cellular network (3) and a plurality of terminals (1) each equipped with at least one telephone card associated with a reachable telephone number through said cellular network (3), each terminal being provided with a user interface for displaying data and for selecting commands, characterized in that said server (2) and said plurality of terminals (1) comprise means of communication via SMS (15) formatted on the basis of a proprietary protocol and by the fact that said terminals (1) comprise means (5, 6) for the automatic conversion of the information encoded in said SMS (15) into information that can be displayed in said user interface and for the automatic conversion of said commands into coded information on the basis of said proprietary protocol and intended for said at least one server (2). 2) System according to claim 1, characterized in that said terminals (1) comprise a listener module (4) configured to intercept all incoming SMS and identify SMS (15) formatted according to said proprietary protocol. 3) System according to claim 2, characterized in that said terminals (1) comprise means (5) for extracting information encoded in said SMS (15) formatted according to said proprietary protocol. 4) System according to claim 3, characterized in that said terminals (1) comprise means (6) for displaying said information and for displaying a user command choice to be sent in response to said server (2) . 5) System according to claim 4, characterized in that said terminals (1) comprise means (6) for the automatic coding of said reply in an SMS message (15). 6) System according to claim 5, characterized in that said terminals (1) comprise means for sending said SMS message (15) to said server (2) and / or for inserting said SMS message (15) in the outgoing message queue. 7) Terminal (1) for the system according to any one of the preceding claims. 8) Method for managing transactions remotely, including the steps that consist in: - configuring a server (2) to communicate through a cellular network (3) with a plurality of terminals (1), each equipped with at least one telephone card associated with a telephone number reachable through said cellular network (3), each terminal ( 1) being further provided with a user interface for displaying data and for selecting commands to be sent to said server (2); - making communications (220) from said server (2) to said terminals (1) through SMS (15) formatted on the basis of a proprietary protocol; - automatically converting (140, 150) the information encoded in said SMS (15) into information that can be displayed in said user interface; - convert (170) said commands given by said terminals (1) into information coded on the basis of said proprietary protocol and intended for said at least one server (2). 9) Method according to claim 8, further comprising the steps which consist in: - intercepting (100, 110, 120), by said plurality of terminals (1), all incoming SMS; And - identifying (130) the SMS (15) formatted according to said proprietary protocol. 10) Method according to claim 8 or 9, further comprising the steps which consist in: - coding said information on the basis of said proprietary protocol for sending to said at least one server (2) by means of an SMS message (15); And put said SMS (15) in the outgoing message queue.