Patent Application
20150149291
Not Applicable
Not Applicable
The magnetic stripe card technology invented by IBM in 1950 is still widely used around the world. There have been many attempts to introduce new technologies that enhance the level of security and improve the client-transaction process but these technologies require significant investment in new infrastructure. Thus, the simple magnetic strip reader continues to be used, being the dominant method utilized for consumer transactions.
There are countless point of sale (POS), automatic teller machines (ATM), electronic locks, and other machines that use regular magnetic card readers. Replacing all these terminals to support some of the proposed systems, and upgrading all client software associated with those systems, will incur in costs proportional to those millions of terminals, in addition to the cost of updating the equipment used by the consumers in the point-of-sale.
One example of a recent attempt of redefining the POS operation is the near-field-communication (NFC) technology using smartphones. While NFC is a significant enhancement over previous technologies, its adoption rate should be low, and costs high, for both consumers and businesses. The POS in the NFC technology is required to have an antenna, a software, a new reader, and a new communication system used just for this purpose, without the guarantee that the consumer will be using it during a purchase.
On the other hand, the current magnetic cards used by almost every consumer in the world are extremely simplistic: the data on these cards can be easily read, opening the opportunity for numerous crimes. Criminals can easily clone these cards by installing magnetic skimmers at ATMs, or by hacking the personal information of a consumer.
In some transactions, a personal identification number (PIN) is required from the consumer, helping to authenticate this consumer as the proper owner of the card.
While this method is an enhancement over a simple magnetic strip, it is neither consistently implemented (it is not required for credit cards) nor is it perfect (PINs can be stolen). A skimmed magnetic card, paired with a stolen pin, is a serious vulnerability of this authentication process.
In order to overcome this authentication vulnerability, usually a store clerk asks the consumer for additional identification in form of a document (identification card, passport). In this case, the personal privacy of the user is violated. Moreover this is not a perfect method of identification either: it is neither consistently implemented or reliable, and its success rate varies with the training of the employees, and their hability of identifying fraud.
There have been some attempts to unify the various magnetic cards that a consumer might carry, but none of them fully addresses the concerns outlined above. The problems inherent in these systems are described below:
U.S. Pat. No. 8,313,037 refers to a system that teaches the users how to clone their own cards, storing the card's pictures and data in their cell phones. The first problem of this invention is that users must have a magnetic card reader and a device to capture the images of the cards. The invention requires to connect the reader to a computer or mobile device to allow it to read the data of multiple cards; users have to capture a picture of each card (both front and back), associate all this information to each card that has been read, and to keep all of that information stored on the mobile device. The invention does not consider the possibility of receiving or accessing the card pictures and data remotely, what would avoid the need to receive a physical card from the financial institution. For example, all card information could be received directly from the bank through the Internet as data, saving the costs of creating and mailing the card to the user, as well as preventing any loss or theft of the card, but this option, as said before, is not covered by U.S. Pat. No. 8,313,037.
U.S. Pat. No. 8,313,037 also has a security flaw, since the data is stored in the cellular device, making the device itself a primary target for viruses to steal its contents, and for theft of the device itself. This patent doesn't consider the possibility of only temporarily storing the content, as the entire system described depends upon the cellular device storing that content.
U.S. Pat. No. 8,313,037 has also an usage flaw, as it only describes methods by which the user would manually interact with the hardware elements, pushing buttons or initializing the process via software stored in the cellular device. This patent doesn't consider the possibility of automatically detecting the swiping action of the device; it doesn't preserve the user's expected credit card like experience, requiring several extra steps.
Finally, regarding U.S. Pat. No. 8,313,037, this invention is limited to 3 possible configurations of the coils used to simulate magnetic fields, instead of discussing a flexible and easy to manufacture design, for example the process discussed in U.S. Pat. No. 4,791,283.
U.S. Pat. No. 7,828,214 refers to a method of connecting a magnetic stripe simulator to various “intelligent devices”, but does not consider a magnetic unit that could be retractable into the device. Also, while the patent does describe a method of authentication and approval using the network, the patent still requires to store the data in the “intelligent device”, subjecting the mobile device to problems of theft, hacking, and viral infiltration.
U.S. Pat. No. 4,605,844 refers to a solution similar to a smart-card. However, the main purpose of the patent is to power the Central Processing Unit (CPU) built into the smart-card wirelessly, as well as discussing the transmission of information via magnetic flux. This patent doesn't include communication with a smart device that can perform all the intelligence of the transaction via network communications. Instead, this patent requires to store all the intelligence and data in the smart-card. Also it does not include user and card identification required by in-store clerks.
So far, there is no invention that provides a way for consumers to perform their POS transactions through an intelligent device like a smartphone without carrying multiple cards or storing the card information in a device. There is no invention that uses cloud computing to direct the transaction and using encrypted cache data.
Also, there is no invention that provides a device that accurately simulates a magnetic stripe card, activating the swiping action using accelerometers, timers, voice command, gestures, or touch-screen actions.
Moreover, there is no invention that determines the current location of the device, determining, and limiting areas where specific cards may be used to perform transactions.
Nowadays banks send millions of cards every year. There is a cost involving the production of these cards that involves the use of plastic materials, added by the cost of packaging and delivery. These cards are usually delivered through regular mail, what takes time. There is no mechanism of digitally providing the information contained in the cards, saving time and money, and also reducing the environmental impact of the use of plastics and paper.
This invention describes a system able to perform financial transactions using Automated Teller Machine (ATM), Point of Sales (POS) or any type of operation involving magnetic card readers through a simulation of magnetic stripe cards (like debit, credit, prepaid and gift cards) and cloud computing, resolving all problems mentioned in the “background of the invention” of this patent.
The present invention also defines a mechanism of how to store, manage and authenticate multiple magnetic cards in clouding computing, carrying a single magnetic card simulator, enabling the user to perform operations through a mobile device selecting different cards named as virtual cards.
It uses applications or web applications where the users can keep representations of the virtual cards. These applications are called virtual wallets.
This system increases the security and allows to add new features without changes in the software or hardware used in ATMs or POS. It also stores the magnetic card data in a cloud computing system instead of using a physical device like FLASH, ROM, SD card, hard disk or any other kind of peripheral that stores data in the device.
The magnetic stripe card simulator is represented physically through a peripheral fixed or retractable on its own, or can be done using a separated peripheral able to communicate with a mobile device using wireless or wired communication.
When the user receives a credit, debit, pre-paid or gift card from a financial institution, store or service provider, the clouding server receives the essential information of the card with all data that exists in a regular card, e.g., expiration date, issue date, name in the card, security code and the data that would be saved in the stripped magnetic portion of the card.
Once the cloud receives the user information, a message is sent to the user's mobile device asking if the user accepts the card. This message might be received through a native application or an application downloaded in the device, a web application or any other regular mechanism to receive data, e.g., SMS, MMS, EMS, email, Bluetooth, NFC, http, https, sockets or content share.
If the card is accepted, the cloud receives a notification confirming the acceptance, and the user is able to use the “virtual card”.
Considering that the user is receiving the information digitally, different levels and types of encryption and authenticated methods can be applied on this process.
The users using a mobile device or computer can also initiate the process to receive the card. In this case, the user can apply to and receive the virtual card, or simply check if the financial institute has virtual cards available for him/her proving that the financial institution system is able to receive applications for virtual cards and to attend the users on demand.
It is important to clarify that the messages used in this process of virtual card acceptance are not necessarily synchronous but can be asynchronous in order to resolve latency issues in processing information or being part of a security mechanism.
Only minimum information should be stored in the mobile device to allow the user to see the card in the display but if the financial institution allows, a cache can be stored obeying different kind of security policies.
During this process of “virtual card” acceptance, the card provider might ask the users to set passwords or any other methods to increase the security of the transaction, for example, using token rings. The card provider may simply set the regular password or security methods used by the user or require no action. If nothing is required, the users will use the “virtual cards” as any other credit card, in other words, no password or any other input to increase the security will be required.
At this point, five problems are resolved:
The user can select the virtual card using a graphical interface through a web application, downloadable or native application installed in the mobile device, and complete the transaction in a POS or ATM simply by pressing a button or touching a graphical or textual component in the screen, like graphical buttons in the display.
Considering that most mobile devices as smartphones and tablets contain microphones, cameras, gravity and accelerometer sensors, the system can use these peripherals and request different input signals in order to start the transaction, for example, a small slap in the device, a command voice, a shake, sound or face recognition or simply the software can start the transition as soon the user enters the password, or after the virtual card is chosen if no security is required.
Then the mobile device communicates with the magnetic card simulator. The magnetic card simulator converts the digital data into magnetic fields that are created when the coils are excited.
The communication between the mobile device and the magnetic card simulator can be done through wired or wireless communication, or direct from the mobile device when the magnetic card simulator and the mobile device comprise a single component or retractile mechanism.
The magnetic card simulator can assume three different formats:
It is not necessary to swipe the card in all of those card configurations described above since the magnetic fields invert their orientations during the transmission of the data card, simulating the swiping process. If the user swipes the magnetic card simulator here is no impact in the functionality, because the magnetic field variation is uniform along the surface of the device.
Once the magnetic card data is sent to the card reader through the magnetic pulses generated by the magnetic card simulators, the transaction proceeds as any operation done using regular cards.
To enhance the system performance in case no data connection is available, the system might send periodically encrypted data that will be stored in the mobile device. This data is cached and might be encrypted. In case no data connection is available the data is decrypted and the user will be able to use the virtual card anyways. The system defines the periodicity that data is transmitted with or without different encryptions, and how long the cached data will last in the mobile device according to the requirements of the card provider. The card provider can change the cache policy based on location, for example, in case the user is overseas and limited data connection, allowing the cache to assume different life periods and remain stored longer.
The invention defines a system based in cloud computing to manage multiple magnetic cards, allowing the usage of all of them using a single magnetic card simulator.
The user has option to accept or reject the offer or request. The response message (USER— CARD_RESP) carries the decision and can be transmitted using the same mechanism of message receive, for example SMS, or can use a different mechanism to transport the response message.
In this case it is important to notice that the response does not need to be synchronous and the message transmitted might be encrypted and decrypted by the mobile device or computer unit according to financial institute requirements.
If user does not accept the card, the response message (USER_CARD_RESP) carries the decision and the cloud servers are informed the card was reject and the process is terminated.
However, once the user accepts the card sending the response message (USER_CARD_RESP), the server will process and respond with a new message (CLOUD_CONFIRMS_CARD), informing if the card was activated or not. This will avoid problems when the user responds asynchronously after a long period and some restriction occurred during this time preventing the user to keep the virtual card on his virtual wallet. A common example of this situation could be a credit rejection due to new event on user's credit report or simply expiration defined by the system or financial institute. If the card was accepted by user and server, the virtual wallet represented by the application or web application in the mobile device or computer unit, will store the new information as a new virtual card.
After the confirmation message from server is sent (CLOUD_CONFIRMS_CARD), Server is expected to receive a message from user (USER_CONFIRM_RESP) informing that the confirmation was processed.
A small portion of the card information sent by message (CLOUD_MIN_INFO_CARD) might be stored in the virtual wallet, such as the card image bitmap, expiration date, security code and issue date. These information received is used when user accesses the virtual wallet and choose the card. However crucial information as the magnetic stripe data, PIN code and/or passwords are not stored and are kept in the cloud.
When a minimal information is received it is possible to respond with a message (USER_ASKS_CACHED_POLICY). This message might be used as acknowledge of minimal card received and if the cached operation is allowed, the policy might be received by message (CLOUD_CACHED_POLICY_RESP) that can contains how the cache policy will work or if simply no cache policy is applicable.
The cached operation allows the user to utilize the virtual card when there is no connectivity available. The cache policy determines how long the cached data will be stored in the device, what kind of encryption and data is used, the location/area where the user is allowed to use the card, if a local PIN or password or any other type of authentication process will be required. If no cache policy is allowed, the user will not be able to use the virtual card if there is no connectivity.
If PIN and passwords settings are required, additional messages (CLOUD_SET_PIN) and responses messages from the user (USER_PIN_RESP) as acknowledgment messages (CLOUD_ACK_RESP) might be used with different types of encryptions and processes.
If virtual card is approved the user might be prompted with the credit limit and the user can accept or not the virtual card. If accepted the same messages sequences represented by the sequence diagram ACCEPTANCE in the
When connectivity is available the logic sequence is the one represented in
Note that the authentication might be a sequence of numeric digits (PIN), password, face recognition (in case of mobile devices or computers with cameras), or any other type of authentication required. It is possible to require that the user enter more than one input data to perform the authentication, for example, some institutional banks in Brazil require not only the PIN but also an additional password.
The graphical interface must follow the authentication policy, allowing to the user to enter the data input required.
Once the authenticated message is sent, the cloud responds with a message (CLOUD_AUTHENTICATION_RESP) accepting or not this authentication.
If the authentication fails, the user might be prompted again until the maximum number of attempts is reached like a loop process. If the user fails in all the attempts, the operation is aborted and the cloud might be informed to lock the virtual card if the financial institution has this requirement.
If the authentication is accepted, the same message (CLOUD_AUTHENTICATION_RESP) might contain the magnetic card data that will be used to excite the coils of the card simulator. The data received might be encrypted and on this case the application must be able to decrypt and parse to have the raw bits sequence available. A separated message could be used to retrieve the magnetic stripes data, however, the same message (CLOUD_AUTHENTICATION_RESP) was used due to performance issues.
Once the data is available, the simulator of magnetic card is able to be excited. A timer is started and it is used to limit the period that the coils of the simulator card will remain excited.
If an authentication process is required, the user is prompted and asked for a sequence of numeric digits (PIN), password, face recognition (in case of mobile devices or computers with cameras), or any other type of authentication available. A combination of PIN, password, or different input might be required as well. For example, the cache might require a password, e.g. a PIN number.
If the authentication fails during a cached operation, the system might prompt the user to enter the authentication data again until the maximum number of attempts is reached; if all attempts fail, the operation might be blocked and the virtual card might be locked locally, what means that the virtual card will remain located in the phone until a cloud operation is performed with success in case of connectivity present, or will remain locked according to the rules received during the cache operation or the rules established by the financial institution through the cloud server.
In both operations using cloud messages or cached data, when the communication flows right and when the user passed all required authentication processes, the magnetic stripe data is ready to be used exciting the magnetic card simulators.
There are different types of magnetic card simulators in the market and basically they are substantiated in coil induction. The present invention does not limit the use with specific types of magnetic card simulators. We explain the most common types In order to illustrate how the cards work and interact with the present invention.
The first type of magnetic card is represented by
In this simulator each coil is connected to a driver 71, responsible to transform the magnetic card data received digitally into analog current pulses, which generate magnetic fields on the pole. This digital to analog converter present in the driver, drives the current orientation and, consequently, the magnetic field generated has the orientation changed.
The data and driver management are controlled by a microcontroller 72 in the embodiment. This microcontroller might receive the data from the mobile device or computer unit using wired or wireless communications.
The second type of magnetic card simulator supported by this system is represented by
Regarding the user interface provided by the application or web-application, the virtual wallet is able to suggest what is the best virtual card to use based on the balance available or other user preferences. To determine the balance available, the virtual wallet might consult the cloud services or save the balance available of different virtual cards locally in the device.
The user interface mentioned might also, allow the user to cancel one or more virtual cards, requesting the cancellation directly to the cloud services instead of waiting for the user to call the institution and the need to have human interaction for such operation. Authentication and personal info confirmation might be required as well during this cancellation process,
When a determined virtual card has cached operations approved by the financial or service provider, it is possible to change the cache policies periodically including encryption algorithm, or by system or user demand, in order to increase the security of the system and making more difficult the attack by common hack techniques. For example, every day when the mobile device or computer unit is idle, the software might communicate with the cloud server and receive a new key, changing the encryption applied in the caches totally transparent to the user, increasing the security of the system.
