TITLE

High security use of bank cards and system therefore

DESCRIPTION

FIELD OF THE INVENTION The present invention relates to a method of using a bank card and to a system therefore that highly increase security.

BACKGROUND OF THE INVENTION

Electronic financial transactions have significantly changed the process of commercial transactions. In fact, transactions which previously required physical transfer of money, are now performed electronically by means for example of computer systems and communication networks.

Today, electronic financial transactions are generally performed using bank cards (e.g. magnetic cards or chip cards) issued by financial institutes or banks. The electronic financial transfer processing can be generally implemented according to, at least, three different ways.

A first way is based on Automatic Teller Machines (ATM). Specifically, an ATM is an electronic computerized telecommunication device that allows a bank's customer to directly use a secure method of communication to access his/her bank account, order or make cash withdrawals or check balances without the need for a human bank teller. Many ATMs also allow people to deposit cash or cheques, transfer money between bank accounts, top up mobile phones' pre-paid accounts or even buy postage stamps. A second way is based on credit card system. Specifically, a credit card system is a type of retail transaction settlement and credit system, named after the small plastic card issued to users of the system. A third way is the Point-Of-Sale, commonly known simply as POS. By means of this mechanism users can pay using their bank cards (e.g. debit cards). Electronic financial transactions involve a lot of security issues.

In order to prevent improper use of a bank card, patent application WO 01/67402 proposes a method for issuing and distributing personalized tokens, comprising the steps of issuing a personalized token, together with a PIN and an activation code, the token having an operational status which is either active when the token is enabled for use, delivering the issued token and the corresponding PIN to an intended user of the token, the status of the token being set to be inactive prior to the delivery thereof, separately delivering the corresponding activation code to the intended user of the token, submitting the activation code and the PIN, upon receipt thereof, by means of a user access facility, altering the operational status of the token to be active if the

submitted activation code is valid.

SUMMARY OF THE INVENTION

The solution according to WO 01/67402 should be applied when the card is issued i.e. by the entity that issues the card (e.g. by a bank or a specialised entity). Therefore it can not be easily applied to existing cards and additionally it requires a change to the present card system.

The Applicant has noticed that today, a rapidly increasing problem is related to the bank cards cloning especially magnetic cards. Magnetic card cloning process is very simple and cost effective for people acting illegally. Usually, debiting devices (ATM and/or POS) are illegally modified or replaced in order to retrieve magnetic card information (e.g. account number and PIN for debit card, number, expiration date and so on for credit card). These data can be used to build a new fake magnetic card (clone). A similar problem exists also for chip cards even if it is more difficult to clone a chip card than a magnetic card.

The clones and/or the associated data can be used e.g. for buying products, for withdrawing money, in e-commerce applications in order to steal money and performing financial frauds. The Applicant has noticed that a need exists for a solution aimed at reducing the risk tied to cloning of bank cards.

Specifically, the Applicant has noticed that a need exists to realize a system able to both reduce the exposure to risk of financial losses due to bank cards cloning, without introducing a new type of card (compatibility with the current deployed and legacy infrastructure), and detect the use of fake cards in order to provide a device for example to the bank to activate anti-fraud and legal procedures.

For the purpose of the present invention, with the term "bank card" (also known as a client card) we intend a card or a token, either magnetic or chip type, typically compliant with the ISO 7810 standard, which allows users to perform electronic financial transactions. The card can be issued by a bank, credit union or building society and its primary uses can be at an ATM for deposits, withdrawals, account information and other types of transactions, often through interbank networks at a branch, as identification for user transactions, and at a point of sale (POS) retail merchant network. In countries that don't have debit cards proper, such as Canada, an ATM card is also known as a debit card. For the purpose of the present invention, with the term "financial operator" we intend a bank or a credit union or a building society or in general any of those entities that issue

bank cards, e.g. debit cards and/or credit cards.

The Applicant has found that this and other problems can be solved by means of a method and a system to avoid unauthorized use of lost or stolen or fake (e.g. cloned) bank cards through dynamically and repeatedly enabling and disabling the bank card when needed; preferably, secure communication channels and/or devices have to be used for such operations.

The present invention provides that by means of electronic devices the bank card is enabled by its user by means of a communication device, typically a mobile telephone terminal, at least one financial transaction is then carried out by its user through the bank card by means of a payment or cash device (the enablement of said bank card being electronically checked at the same time), and finally the bank card is disabled till when its user decides to use the bank card again. In this way even if the bank card is lost or cloned damages can be avoided or at least highly reduced. The management of the enablement and disablement of the bank card is carried out by a service Application Server typically executing a service software application.

The service Application Server may have a database storing information relating to bank cards and their holder and is adapted to receive messages from users for enabling and typically also disabling bank cards and to correspondingly update at least a database storing information relating to bank cards and their enablement status. The two databases may be integrated into a single database and stored in a single computer. Alternatively, they are separate and preferably stored in different and remote computers; one of the computers is the service Application Server and may be of a telecommunication operator and the other of the computers may be of a financial operator (e.g. a bank). The method according to the present invention can be implemented in many different ways.

According to a first preferred embodiment of the present invention, a user can enable and/or disable his/her bank card by means of a secure application installed on his/her mobile phone or PDA [Personal Digital Assistant] or directly installed on his/her SIM card. The secure application, i.e. a client component, can communicate directly and securely with a server component of the service Application Server, for instance by means of protected (i.e. encrypted, signed and integrity-protected) or unprotected SMS or application messages sent through a secure IP channel (for instance SSL, TLS, SSH, IPsec) over a mobile network such as GPRS or EDGE or UMTS or HSDPA. The secure communications between the client and the server software components are aimed at dynamically enabling and disabling the user's bank card, in terms of electronic

transactions capabilities. In particular, the user's bank card is always disabled ("sleeping status") and cannot be used for electronic transactions until it is enabled ("active status"). This status change can be requested by the user through an explicit activation performed by means of the mobile phone or the SIM-based application. Moreover, this activation can be associated with activation attributes; for instance, in order to let the card active for a pre-determined time window or for a specified number of transactions.

According to a second preferred embodiment of the present invention, the user can enable and/or disable his/her bank card sending an unprotected SMS to a phone number provided by the bank or by the credit card provider and tied to a service Application Server comprising a server software component. According to this embodiment, the SMS in sent in clear text form in order e.g. to cover also users equipped with legacy mobile devices or SIM cards, whose application layer is not or cannot be customized. The server component processes the received request and changes the status of the card specified in the request.

According to a third preferred embodiment the user can enable and disable his/her bank card calling a phone number provided by the bank or by the credit card provider and tied to a service Application Server comprising a server software component of an IVR [Interactive Voice Response] system. In this case also, the server component processes the received request and changes the status of the card specified in the user request.

According to a fourth preferred embodiment the user can enable and disable his/her bank card accessing a bank home page through the appropriate authentication procedures. It is to be noted that advantageously these embodiments can be combined; in fact, a user may be interested in different possibilities in different situations. For example, if a user is in a country where it is not possible to send an SMS through mobile phones for enabling his/her bank card or when the battery of his/her mobile phone has no charge and can not be used for enabling his/her bank card, he/she may wish to make a phone call or to connect to the internet for the same purpose.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will become more apparent from the following description to be considered in conjunction with the annexed drawing in which: Figure 1 show time diagrams for different embodiment of the present invention, Figure 2 shows a general architecture combining different possibilities for implementing the present invention,

Figure 3 shows the general architecture for a first embodiment of the present invention,

Figure 4 shows the enable request sequence diagram for a first embodiment of the present invention,

Figure 5 shows the enable request flow chart for a first embodiment of the present invention,

Figure 6 shows the received enable SMS flow chart for a first embodiment of the present invention,

Figure 7 shows the general architecture for a second embodiment of the present invention,

Figure 8 shows the enable request sequence diagram for a second embodiment of the present invention,

Figure 9 shows the general architecture for a third embodiment of the present invention, F Fiigguurree 1 100 shows the enable request sequence diagram for a third embodiment of the present invention,

Figure 1 1 shows the general architecture for a fourth embodiment of the present invention, and

Figure 12 shows the enable request sequence diagram for a fourth embodiment of the present invention.

It is to be understood that the following description and the annexed drawings are not to be interpreted as limitations of the present invention but simply as exemplifications.

DETAILED DESCRIPTION OF THE INVENTION

As already said, unauthorized use of lost or stolen or fake bank cards may be avoided through dynamically and repeatedly enabling and disabling the bank card by its user when needed.

According to the prior art, a bank card is enabled by a bank entity at the request of its user after that the bank card has been provided to him/her. Thereafter, the bank card may be statically blocked by the bank entity at the request by its user in case that e.g. it is lost or stolen and it can not be used any longer. The card may also be blocked when the user or the issuer have collected enough evidence that the card has been cloned, i.e. when one or more fraudulent transactions have already been processed. According to the present invention, the bank card is enabled by its user when he/she wants to use it; this can be for each financial transaction, for a specified number of transactions, or for a period of time during which one or more financial transactions may be carried out. Enablement of the card increase its security of use especially if the

enabling action is securely connected to its rightful user by means of e.g. a security code.

In Fig.1A transaction T1 is preceded by an enablement EN-1 (e.g. an enabling action by its user) and is followed by a disablement DIS-1 (e.g. a disabling action by its user or a default timeout), while transaction T2 is immediately preceded by an enablement EN-2 (e.g. an enabling action by its user) and is immediately followed by a disablement DIS-2 (e.g. an disabling action by its user). Nobody can immediately use the bank card before time EN-1 and between time DIS-1 and time EN-2 and after time DIS-2 even if he/she holds an original card and even more if he/she holds a fake card (or clone). In Fig.1 B, three transactions T3 and T4 and T5 are carried out between an enablement EN-3 (e.g. an enabling action by its user) and a disablement DIS-3 (e.g. an disabling action by its user). Nobody can immediately use the bank card before time EN-3 and after time DIS-3 even if he/she holds an original card and even more if he/she holds a fake card (or clone). Financial transactions T1 , T2, T3, T4, T5 may correspond for example to the payment through a credit card by means of a payment device or the payment through a debit card by means of a payment device (e.g. a POS device) or the withdrawal of an amount of money by means of a debit card through a cash device (e.g. an ATM device). The present invention is implemented by means of electronic devices, i.e. the enablement and disablement is carried out electronically.

Fig.2 shows a general architecture combining different possibilities for implementing the present invention. Several components are involved. At the user-side a plurality of different devices can be used to manage the bank card status: a mobile phone, a PDA [Personal Digital Assistance], a PC [Personal Computer], a normal telephone (i.e. with wired connection to the telephone network). Each device can use one or more different user service-interfaces; for example, using a mobile phone, a user can manage his/her bank card by means of SMS messages or an IP channel or voice communication. These user service-interfaces can interact with a service Application Server (connected or provided with a Users Database) through corresponding specific connectors, i.e. an SMS-C Connector, a Web Connector, an IVR [Interactive Voice Response] Connector; the core of the invention is implemented in the Application Server. Specifically, the service Application Server receives a request to change the bank card status from at least one of the connectors, processes it and sends a formatted change status request to a bank entity application. When the bank card status is changed, a

notification may be sent to the user. This notification can use one (or more) communication channel; the communication channel can be the same of the request or can be different from the request. For example, if the request has been sent by means of SMS, the notification can be sent by means of SMS too and/or by means of an e- mail message.

The service Application Server interacts with a Financial Operator, specifically with a computer executing a Financial Operator Application, in order to let the request of change of status of the bank card be effective on financial transactions. In Fig.2, the following messages are highlighted: CSR : Change Status Request (between the service provider and the financial operator);

UCSR : User Change Status Request (between the user and the service provider); CSC : Change Status Confirmation (between the service provider and the financial operator); UCSN : User Change Status Notification (between the user and the service provider);

URV : User Registration Verification.

The request to change the bank card status can be of the "reverse status" type (i.e. at the reception of a request the status of the card is reversed e.g. from "enabled" to "disabled" or vice versa) or, more typically, of the "set status" type (i.e. the request specifies the status to be assigned to the card). In both cases, the corresponding processing of the request is not very different.

The present invention can be seen as a security service to be offered to financial operators (banks or bank card issue entities) for increasing the security in using their bank cards.

It is worth noting that the present invention may be implemented and operated even without any change to the present credit card payment system and to the present cash withdrawal system or electronic payments. In fact, the electronic devices for these present systems provide for checking the status of the bank cards used for financial transactions. The present invention allows to dynamically change the status of the bank cards only by its rightful user.

THE METHOD

In general, method according to the present invention allows a user to safely use his/her bank card, the bank card being associated to a card identification number; it comprises in sequence the steps performed by means of electronic devices of:

A) enabling the bank card by the user through said card identification number by

means of a communication device,

B) carrying out at least one financial transaction by the user through the bank card by means of a payment or cash device, wherein the enablement of said bank card is electronically checked, and C) disabling the bank card.

The check at step B may be carried out by means of any card identification number. An easy choice can consist in using as card identification number the number appearing on the front of any bank card; it is clear that the choice is not very safe even if secure communication channels and/or a secure communication devices are used for implementing the method. An alternative and preferable choice can consist in using code associated to the bank card but different from the one appearing on the front of the bank card; the correspondence between the code and the bank card may be known to the entity managing the service according to the present invention (for example a telecom operator) or to the financial operator only. The present invention can not be applied in those cases when the payment through e.g. a credit card is not carried out by means of an electronic device and therefore no real-time check can be carried out; in these cases the traditional check of the signature and identity card should be applied. The management of the enablement and of the disablement of said bank card is carried out by a service Application Server typically through a service software application running in the service Application Server.

The service Application Server may be associated to a communication operator or a financial operator, or a "security service" operator, i.e. an entity independent from the communication operator and the financial operator. The service Application Server can be directly involved in the real-time check of the enablement of the bank cards in combination with a financial operator; alternatively, only the financial operator is directly involved in this real-time check and the service Application Server simply communicates with the financial operator or notifies the enablement and disablement requests by users regarding the status of bank cards to the financial operator when they are changed by the user and independently from whether and when a financial transaction is carried out.

Typically, for the purpose of the method according to the present invention, a financial operator software application (at the financial operator or security operator) is provided and is in communication (directly or indirectly) with the service software application. As it will be better explained in the following, these two software applications manage two own databases.

The service software application and the financial operator software application run usually on different and remote computers.

As the method according to the present invention may be adapted to manage bank cards associated to different financial operators, the service software application running in the service Application Server may be adapted to select the financial operator software application to communicate with according to the card identification number specified by the user request.

Step A and/or step C may comprise the transmission of the card identification number to said service Application Server for enabling and/or disabling the bank card; the card identification number may be transmitted in clear format or in coded/masked format; the coded/masked format may be unnecessary if the transmission is through a secure communication channel, but it can be adopted in order to both increase the security. If there is a client application in charge of sending SMSs, this one can be protected by means of an access PIN requirement. Step A and/or step C may comprise the transmission of a security code, such as a PIN code, to said ; this reduces the possibility that the bank card is enabled or disabled by a person different from the rightful user of the bank card.

The security code may be implicit in the enabling and/or disabling action by the user. For example, if these actions are carried out by means of a telephone, the phone number or the IMSI code may be used for this purpose; anyway, this implies that enabling and disabling can be made only through one or more specific telephones (e.g. home fixed phone and user's mobile phone); it may be provided that the authorised telephones may be changed by the bank entity at the request of the user. The present invention may provide different operation commands to be transmitted to the service Application Server, in particular a enable command and a disable command and a block command and a query command; in this way, the service Application Server can easily determine the wish of the user and the user can easily manage his/her bank cards. It is apparent that through the present invention the user can manage more than one bank cards as they are identified by different card identification numbers.

The block command according to the present invention represents a very easier and quicker way to block the bank card with respect to the present way. It is to be understood that, after a block command, the bank card is disabled; at the most, the bank card can be enabled again not by the user but only by the bank entity that issued it.

The enable command may specify an enablement period of time; in this way, for

example, the bank card can be used from the time of reception of the enable command by the service Application Server for the specified period of time.

Step A and/or said step C is typically carried out by a user by means of a communication terminal to be put in communication with said service Application Server. The most comfortable communication terminal to be used by a user in any place (wherever in the world), e.g. during shopping, is a telephone terminal, in particular a mobile telephone.

The disabling of the bank card according to step C may be carried out by the service

Application Server upon request by a user. The disabling of the bank card according to step C may be carried out by the bank card issue entity or by a payment or cash device. This possibility is useful if the enablement of the bank card should be valid for one financial transaction only; in fact, when the entity or the device establishes that the financial transaction has been successfully completed it can proceed to disable the bank card. The disabling of the bank card according to step C may be carried out by the service

Application Server automatically after a period of time from the enablement of the card.

This period of time may be predetermined e.g. by the bank card issue entity, in particular one day (i.e. shopping day) or two hours (i.e. typical shopping session) or five minutes (i.e. typical financial transaction time). In this case, it may be provided that the user can subsequently change this predetermined period of time.

This period of time may be preset by the user for example when he/she requests the bank card; it may be provided that this preset period of time may be subsequently changed by the bank entity at the request of the user.

This period of time may be set by the user when he/she enables the bank card; the user may be interested in a shopping day or in a shopping session or in a single financial transaction.

The disabling possibilities described above can be advantageously combined; for example, the card is disabled automatically if the user does not disable it manually within a predetermined time period. Step A and/or step C may be carried out by means of transmission of one or more telephone text messages, in particular SMS and/or MMS.

Said step A and/or step C may be carried out by means of transmission of one or more voice messages.

These messages may be encrypted. They may be additionally signed by said user so that their content and their author are authenticated.

Step A and/or step C may be carried by means of an Internet connection or similar data

network connection; in particular, this communication may advantageously be encrypted for security reasons.

The communication possibilities described above can be advantageously combined; for example, the card may be enabled by means of telephone text messages, voice messages and data messages (from a data network connection). In all cases a secure communication channel may be advantageous.

The enabling and/or disabling of the bank card according to step A and/or step C may be confirmed to the user, in particular to the communication device used by the user to carry out the corresponding action. It may be provided that, in any case, a telephone text messages is transmitted to the mobile phone of the user; therefore, double confirmation is not excluded.

The disabling of the bank card according to step C may be notified to the user, in particular to a communication device of the user; this is especially useful when disablement is carried out automatically by the service Application Server or by a bank entity or by a payment or cash device. The communication channel and/or the communication devices for notification may be predetermined by the bank entity or preset by the user for example when he/she requests the bank card. It is quite convenient both for the confirmation and for the notification that telephone text messages directed to a mobile phone are used. If a query command is provided, for the reply to the query command, i.e. the status of the bank card (e.g. enabled, disabled, blocked), the same considerations apply as for the confirmation of a enable or disable or block command.

THE SYSTEM Typically, the method according to the present invention is used and specifically adapted to carry out the method according to the present invention.

In general, the system comprises a service Application Server having a first database storing information relating to bank cards (e.g. card identification number) and their holder (e.g. telephone number, PIN code); the service Application Server executes a service software application that is adapted to receive messages from users for enabling bank cards and to correspondingly update at least a second database storing private and/or significant information relating to bank cards (e.g. account number, real card identification number, virtual card identification number involved during the users' requests) and their enablement status (e.g. status). The first database and the second database may be integrated into a single database stored in a single computer.

Alternatively, the first database and the second database are separate and stored in

different and preferably remote computers.

According to typical embodiments of the present invention, there is a service software application adapted to manage the first database and a financial operator software application adapted to manage the second database; the service software application and the financial operator software application are adapted to communicate.

The service software application and the financial operator software application may be stored in different and preferably remote computers.

As already said, the service Application Server is adapted to receive messages from users for enabling bank cards and to correspondingly update at least said second database.

The service Application Server may be adapted also to receive messages from users for disabling bank cards and to correspondingly update at least said second database. The service Application Server may be adapted also to receive messages from users for blocking bank cards and correspondingly update at least said second database. The database of the service Application Server may be quite small and be used only as a temporary storage of information to be forwarded to e.g. a financial operator or can be large and be used to permanently store information for the system that can be provided at any time for example to users, bank entities (in general financial operator), payment devices or cash devices. The messages used by the system according to the present invention may be telephone text messages, in particular SMS and/or MMS.

The messages used by the system according to the present invention may be voice messages. The messages used by the system according to the present invention may be data messages in a dataflow from a data network connection.

The service Application Server may adapted to decrypt said messages. The service Application Server may be further adapted to authenticate said messages. The service Application Server may be adapted to automatically disable a bank card and accordingly update at least its database after a period of time from its enablement. This period of time may be associated to a whole database and stored e.g. in the service Application Server; this is typically the case when the period of time is predetermined (either by the financial operator or the provider of this service). This period of time may be associated to a bank card and stored in a suitable database (this means that different card may be associated to different periods of time); this is typically the case when the period of time is preset by the user.

This period of time may be specified by a user in an enablement message and is

stored in a suitable database; this storage is a temporary storage that last for a limited period of time.

According to typical embodiments of the present invention, the service Application Server interfaces from one side with the users and on the other sides with financial operators.

It is worth noting that the method and the system according to the present invention may be effectively implemented through specifically adapted communication devices, in particular mobile telephone terminals, or specifically adapted subscriber identification modules (e.g. SIM or USIM) associated to communication devices; these may be used by the users, i.e. the rightful holder of bank cards.

These devices or modules will store and run an application, in particular a client application, adapted to communicate with an application, in particular a server application (e.g. the above mentioned service software application), stored an running at the service Application Server. The main tasks of the client application is to interface with the user and to format and send the necessary messages.

Indeed, the method and the system according to the present may be implemented even without any specifically adapted communication device for the users.

FIRST EMBODIMENT The architecture according to a first embodiment of the present invention is shown in Fig.3 and comprises: a Client Application installed on a mobile terminal, for instance a Java/C/C++ application for mobile platform or a SIM application installed on a SIM card (for instance a Javacard application or a SAT-SIM Application Toolkit applet); - a Short Message Service Centre (SMS-C) Gateway to manage the incoming and outgoing short messages; a Short Message Service Centre (SMS-C) Connector to manage the communication between the SMS-C Gateway and the service Application Server; a service Application Server for core service that can be located for example, as said before, at a financial or telecom operator's data centre; a Users Database where information about the users of the service are stored, e.g. MSISDN [Mobile Station International ISDN Number], authentication data, card identifier numbers ... ; a Financial Operator Application. In order to use this security service according to the present invention for one or more bank cards, a user subscribes it providing for example to the service provider some

data that can comprise his phone number (or a list of phone numbers) and/or his bank account number and/or his bank card number. It may be advantageously provided that a unique card identification number (virtual and different from the card number embossed on the bank card) and authentication data will be generated in this phase and stored in the Users Database in order to use them for this service.

In this scenario, the user, in order to change the status of his bank card, selects, from a menu application installed on his communication terminal, the application representing the client component at the user-side (Figures 2 and 3). In order to increase the security level of the service, the application can be configured to request to the user the insertion of a PIN. Only if the inserted PIN is correct, the application displays the menu with all managed bank cards. If the PIN is incorrect, the user can try again until the maximum number of attempts has been achieved. The user selects the card and another menu is displayed with the available choice. When the user has selected his choice, the application formats a short message (SMS) with a body containing for example an "activation request code" and a "card identifier" and sends it to a predefined number. The SMS-C Server configured into the used phone number receives the SMS and, by means of the Connector component, formats a request to the service Application Server, providing <MSISDN, message body > of the incoming SMS. The service Application Server firstly checks if the MSISDN belongs to a valid subscriber, verifies the authenticity and/or the integrity of the request and then elaborates the input data in order to perform the appropriate change status request toward the Financial Operator Application. A notification of the result of the request is sent back to the SMS-C gateway, that forwards this one by means of a SMS to the Client Application. Finally, the result is displayed to the user. The bank card will be enabled just temporally. If not disabled by the user, the bank card will remain active just for a preconfigured time period (for example the day of the request). When this configured period has lapsed the bank card is deactivated again and an informative message (SMS) may be sent to the user e.g. by the Application Service. If the user wish to disable his bank card, he selects the specific menu entry (Disable Card). The steps will be the same of the previous case.

If the user wish to know his bank card status, he selects the specific menu entry (Get Card Status). The steps will be the same of the previous case. In this case the user will receive an SMS containing the status (enabled/disabled/blocked) of the selected bank card e.g. from the Application Service.

If the user's bank card is lost or stolen, the user can block it definitively by means of the

Client Application, selecting the appropriate menu entry (Block Card). If the user has more than one bank card, he/she can register each of these ones. If each Financial Operator will use the same Telecommunication Operator, a single application can be used to manage all the bank cards involved. The Financial Operator should deploy a registration service.

Fig.4 shows the enable request sequence diagram; the same sequence applies also to a disable request.

The Client Application can be configured in order to handle several bank cards. This client component can be: - a SAT - SIM Application Toolkit (SAT) applet installed directly on the user's SIM, a C/C++/Java (or other similar programming language) application, installed directly on user's mobile device. The functionalities offered by the Client Application are:

Authenticate the user by means of a PIN - Select from a first menu a subscribed bank card

Select one of the following commands:

1. Enable Bank Card

2. Disable Bank Card

3. Get Bank Card Status 4. Block Bank Card

- Change the PIN or the number of attempts if requested by the server component.

The user's bank cards are always set as disabled, so nobody can use them. When the user should use his bank cards he can temporally enable them by means of the client application. Once the appropriate menu entry has been chosen, the application automatically formats a short message containing the following data: an activation request code (ARC, identifying the command enable, disable,...) a request identifier (ReqlD, a progressive number or a random number incremented or generated at each new activation request, introduced to prevent reply attacks) - the bank card identifier (Cl), this will be the identifier used to select the user's bank card at application side. The introduction of this identifier permits not to involve the account number or credit card number of the user in the communication.

The short message (SMS) used during the communication can be: - encrypted by means of a pre-configured application cryptographic key Kreqencr (if the SMS has been generated by the client) or decrypted by means of a

Krespencr (if the request of a SMS has been generated by the Financial Operator's application) signed by means of a pre-configured application cryptographic key Kreqmac(if the SMS has been generated by the client) or verified a Krespmac (if the request of a SMS has been generated by the Financial Operator's application).

Each user has several different keys. The first set (Kreqencr, Kreqmac) is unique for each user and can be involved during the request generation to achieve message privacy, integrity and authenticity. The second set can be specific to each user or shared with the other subscribers, and it is used during the notification reception (Krespencr, Krespmac). These keys are stored within the mobile terminal or onto the SIM card.

The first implementation, based on encryption, introduces a higher security level ensuring confidentiality, integrity and authentication of the transmitted data. The second mechanism, instead, is able to guarantee only message authentication and integrity, achieving also a non repudiation property if a public key algorithm is used (such as RSA, ECC, etc.), although the SMS is in clear-text form. The encryption and the signature of the message can use different algorithm (3DES, AES, HMAC, RSA, ECC, etc .). The application can require a user authentication in order to avoid un-authorized request. The authentication mechanism can be based on a PIN input. After a preconfigured number of failed attempts, the application can block further access attempts and prevent further use until a new unblock message will be sent by the server component. In Fig.5 a flow chart of the client application when an enable request is performed is shown; the same flow chart applies also to a disable request.

The client application should handle three different message types, as reported in the following table:

The received enable SMS flow chart is shown in Fig.6.

The SMS-C gateway is the network element in the mobile network able to deliver SMS messages. It is installed in the telcom operator's data centre. When it receives an incoming SMS from a mobile phone directed to a specific number (associated to the service according to the present invention), it forwards it to the SMS-C Connector. When it receives an incoming request containing < MSISDN , data> from the SMS-C Connector, it creates and sends a SMS with a body containing the input data to the specified MSISDN. The SMS-C Connector component implements the communication interface between the Application Service (core of the service) and the SMS-C Gateway. It is an application deployed by the operator. The SMS-C Connector should: process the SMS data received from SMS-C Gateway in order to format the input data for the service Application Server. The data form is <MSISDN, DATA>. The MSISDN is extracted from the data stream produced by the SMS-C Gateway; process the incoming data <MSISDN, data> from the service Application Server and format the input data for the SMS-C Gateway.

The communication channel between each involved component is protected (for instance using Virtual Private Network protocols, such as SSL, TLS, SSH, IPsec, protected Web Service and so on).

The service Application Server implements the core of the service. When it receives, on a protected channel, an incoming request from SMS-C Connector in this form <MSISDN, data>, it performs the following steps: 1. Verify if the MSISDN is stored in the Users Database

2. Verify the authenticity of the request and if applied decrypts the message

3. Verify that the incoming request identifier matches with the expected stored value

4. Check the activation request code

5. Format the request for the Financial Operator Application. This request can have this form <MSISDN, Cl, activation request>

In order to perform decryption/signature verification, the Users Database contains the application cryptographic KReqencr/ KReqmac .

When it receives, on a protected channel, an incoming request from the Financial Operator in this form <MSISDN, message data, message_type>, it performs the following steps:

1. Select the MSISDN

2. Check the message type (Table 1 )

3. Format the request data

4. Encrypt/sign the request data with the Krespencr/ Krespmac key When the Financial Operator's application receives an incoming change status request with this form <MSISDN, Cl, activation request>, the following steps are performed:

1. Select the card in the database of the issued cards by means of the couple <phone number, Cl>

2. Verify the actual state of the card 3. Perform the operation specified by the Activation Request Code

4. Generate the response for the application service with the result of the operation containing this informations < message data, message_type>

When this application should deliver an information message to a user, it formats a request with this form <MSISDN, message data, message_type> towards the service Application Server

SECOND EMBODIMENT

The architecture according to a second embodiment of the present invention is shown in Fig.7 and comprises: - a SMS-C Server - a SMS-C Connector a service Application Server for core service and that can be located , as said before, at a financial operator's or telecom operator's data centre; a Users Database where information of the users are stored (e.g MSISDN [Mobile Station International ISDN Number], authentication data, card identification numbers ... ); a Financial Operator Application.

This embodiment differs from the previous one because it does not involve any specific client application. In this case the user can communicate with the server component sending SMS without involving encryption or signature. The encryption is not end-to- end but it is typically limited to the radio link and based on the security mechanism natively provided by the GSM or UMTS network . The user should format a SMS inserting, at least, these three fields:

- a code identifying the requested function, for instance:

1. Enable Bank Card

2. Disable Bank Card 3. Block Bank Card

4. Get Bank Card Status

- a code identifying the bank card

- a PIN code

If the user has more than one bank card, he/she can register one, more or all of them. To manage the status of each bank card the user should send a SMS to the number provided by the Financial Operator which has issued the bank card.

Fig.8 shows the enable request sequence diagram; the same sequence applies also to a disable request.

In this embodiment, the SMS-C Gateway component has the same role described in the previous case.

In this embodiment, the SMS-C Connector component has the same role described in the previous case.

The service Application Server implements the core of the service.

When it receives, on a protected channel, an incoming request from SMS-C Connector in this form <MSISDN, data>, it performs the following steps:

1. Verify if the MSISDN is stored in the Users Database

2. Verify the PIN inserted in the message body

3. Format the request for the Financial Operator Application; this request can have this form <MSISDN, Cl, activation request> When it receives, on a protected channel, an incoming request from the Financial Operator in this form <MSISDN, message data>, it performs the following steps:

1. Select the MSISDN

2. Format the requested data

When the Financial Operator application receives an incoming change status request with this form <MSISDN, Cl, activation request>, the following steps are performed:

1. Select the card in the database of the issued cards by means of the couple

<phone number, Cl>

2. Verify the actual state of the card

3. Perform the operation specified by the Activation Request Code

4. Generate the response for the application service containing the result of the operation.

When this application should deliver an information message to a user, it formats a request with this form < MSISDN, message data> towards the service Application Server.

THIRD EMBODIMENT The architecture according to a third embodiment of the present invention is shown in Fig.9 and comprises: an Interactive Voice Response (IVR) Server; an Interactive Voice Response (IVR) Connector; a service Application Server that can be located, as said before, at a financial operator's or telecom operator's data centre; a User Database where information of the users are stored (e.g MSISDN [Mobile Station International ISDN Number], authentication data, card identification numbers ... ); a Financial Operator Application. In this embodiment no specific client application is involved; the user request a bank card status change dialling a specific phone number provided by the Financial Operator. An interactive voice response (IVR) system is hooked up to this number and provides speech messages heading the users; in particular, the user is asked to insert, by means of the phone's keypad, the card identifier (Cl) and the secret personal Identification number (PIN). If the authentication is successful, the user can select one of the following actions from the voice menu proposed by the IVR system:

1. Enable Bank Card

2. Disable Bank Card

3. Block Bank Card 4. Get Bank Card Status.

Fig.10 shows the enable request sequence diagram; the same sequence diagram applies also to a disable request.

The Interactive Voice Response [IVR] is a system based on a text-to speech application able to reproduce text message (defined in VoiceXML file) in a voice message. In this embodiment, it defines the user interface of the overall proposed architecture.

When the user calls the service phone number, the inserted card identifier and PIN are forwarded to the IVR connector application.

When the procedure is completed, it reproduces to the waiting user the response message, provided in the specific VoiceXML file by the IVR connector. When the user makes a phone call to the specified service number, the IVR Connector performs the following steps: during the user authentication step, formats the authentication request <card identifier, PIN, ReqlD> for the service Application Server and obtains the result; card identifier number Cl and PIN are provided by the IVR system, while the variable ReqlD is introduced by the IVR connector to prevent replay attacks after the user selection, formats the activation request (ARC) <CI, ReqlD, ARC>. Instead, when it receives the request's result, it formats the voiceXML response file for the text-to-speech application, as depicted in Fig.9.

The service Application Server defines and implements the core of the service. When it receives, on a protected channel, an incoming authentication request, it verifies that the card identifier is associated to a valid subscriber, check the PIN, stores the Sessionld variable and produces the result reproduced by the IVR application to the user by means of speech.

When the user performs his choice, the service Application Server formats the request <CI, ARC> to the Financial Operator, waiting for the result. The obtained result is forwarded to the IVR Connector.

When the Financial Operator Application receives an incoming change status request with this form <CI, ARC>, the following steps are performed:

1. bank card selection from database of the issued cards by means of the card identifier

2. bank card status verification

3. bank card status updating according to the received activation code

4. result generation and forwarding to the service Application Server.

FOURTH EMBODIMENT The architecture according to a fourth embodiment of the present invention is shown in Fig.11 and comprises:

- a Web Application; a Web Application Connector;

- a service Application Server for core service; - a Users Database;

- a Financial Operator's Application.

The user can request a bank card status change through its personal web banking account. To get access to the web application the user should authenticate himself by means of the security procedures chosen by the bank (for example username/password). If the authentication is successful, the user accesses to his homepage and can select:

1. select bank card

2. activation request:

Enable Bank Card Disable Bank Card - Block Bank Card

- Get Bank Card Status and perform the enablement request.

The user can register each of his bank cards to the service. The Financial Operators interested in the service for their Clients should provide a secure website for the service from which the user can manage bank cards issued by it.

Fig.12 shows the enable request sequence diagram; the same sequence applies also to a disable request.

The Web Application is the user interface for this embodiment. It can be developed using the web service technology. In order to change the bank card status the user should access to his homepage, provided by this web application. To get access to this web application, the user should authenticate himself by means of the security procedures chosen by the bank (for example username/password). The web application forwards the user credentials to the web application connector, as depicted in Fig.12. If the authentication is successful user can select from his homepage the bank card and the activation request previously reported. The web application forwards <CI, ACR, Reqld> to the Web Application Connector. The Reqld variable has been generated by the Web Application Connector and has been set by this component in the Web Application.

The Web Application Connector can also be a web application developed using Web Service technology, for example. It receive requests from the user interface represented by the Web Application and prepares the right message for the service Application Server. In particular:

1. during the user authentication this application generates a ReqlD to prevent reply attacks, creates and forwards, on a protected channel, the request containing <username, password, ReqlD> for service Application Server; afterwards, it forwards the authentication result to the user interface application and sets to this

one the ReqlD variable;

2. when the user has been authenticated and has performed the card and activation request code selection, this application formats the request < Cl, ACR, ReqlD> to forward, on a protected channel, to the service Application Server; afterwards, it forwards the request result to the user interface application.

The service Application Server defines and implements the core of the service. When it receives, on a protected channel, an incoming authentication request, it verifies the user credentials, stores the ReqlD variable and produces the authentication result. When the user performs his/her choice, the application service verifies if the user has subscribed the selected bank card, if the ReqlD is yet active and then formats the request <CI, ACR> to the financial institute, waiting for the result. The obtained result is forwarded to the Web Application Connector with the ReqlD.

When the Financial Operator Application receives an incoming change status request with this form <CI, ACR>, the following steps are performed:

1. bank card selection from database of the issued cards by means of the card identifier

2. bank card status verification

3. bank card status updating according to the received activation request code 4. result generation and forwarding to the service Application Server.

COMPLEX EMBODIMENT

The architecture according to Fig.2 corresponds to the combination of the embodiments of Fig.3, Fig.7, Fig.9, Fig.1 1 and their features.

In this figure, the same reference signs and names are used as those used in the above mentioned figures.

For these reasons, no detailed description is provided herein as unnecessary.

It is worth noting that a similar combination of features is realistic in a real environment when bank cards are used as in general different users have different needs; additionally, even the same users may have different needs in different situations. Additionally, it is worth noting that in Fig.2 only one Financial Operator is shown, but the present invention may be applied also in those cases where a number of financial operator offer to their clients the security service according to the present invention.

Finally, it is worth noting that the service Application Server of the embodiment of Fig.2 is associated to a telecom operator or to a "security service" operator; anyway, in other embodiments of the present invention, the service Application Server is associated to a financial operator, i.e. the security service is directly provided by the financial operator

for its bank cards or at least for the bank cards of the those clients who are interested (and pay) for the additional security service.