System, method, and computer-accessible medium for blocking malicious EMV transactions
Patent Information
- Application Number
- JP2022522736
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- Priority Date
- 2019-10-15
- Filing Date
- 2020-10-08
- Publication Date
- 2025-06-02
- Estimated Expiration
- 2040-10-08
AI Technical Summary
Existing systems fail to prevent malicious applications from accessing and executing data from EMV cards via short-range wireless communication, leading to security vulnerabilities and potential fraudulent transactions.
Implementing a system where a non-contact smart card generates digital tags, such as Android Application Record (AAR) tags, which launch authorized applications on a mobile device when detected, thereby preventing unauthorized access to sensitive information.
Enhances security by ensuring only authorized applications can access EMV card data, blocking malicious software and reducing fraudulent transactions.
Smart Images

Figure 00000019_0000 
Figure 00000020_0000 
Figure 00000021_0000
Abstract
Description
Cross-reference to Related Applications
[0001] This application claims priority to U.S. Patent Application No. 16 / 653,305, filed October 15, 2019, and now U.S. Patent No. 10,755,262, issued August 25, 2020, the disclosure of which is hereby incorporated by reference in its entirety.
Technical Field
[0002] The present disclosure generally relates to preventing the activation of unwanted applications and the execution of unauthorized transactions. More specifically, the present disclosure relates to interfering with the activity of an application by blocking user data received via near-field communication.
Background Art
[0003] Portable electronic devices such as smartphones, tablets, and laptop computers are ubiquitous. These devices often support multiple wireless communication means, including near-field communication (NFC) with data communication established within a near-field communication field.
[0004] Europay, MasterCard, and Visa (「EMV」) standard-based cards are smart cards that store information on a magnetic strip (for backward compatibility with older machines) and additionally on an integrated circuit. EMV cards are smart cards, also referred to as chip cards or IC cards. These include cards that need to be physically inserted into a reader. They also include contactless cards that can be read at close range using near-field communication (NFC) technology. EMV is a payment method based on an industry standard (technical standard) for smart payment cards and the payment terminals and automated teller machines that accept them.
[0005] A typical credit card consists of a contactless chip, allowing credit card transactions to occur without the user swiping the card or physically inserting it into a credit card reader. The contactless chip enables wireless and contactless communication with the appropriate device for easy credit card use. For example, NFC can be used to make wireless payments.
[0006] However, many credit cards are configured to allow access to encoded credit card information by any suitable receiving device. This can lead to security issues, especially in the context of mobile devices that can read data from contactless chips. For example, a mobile device with an NFC reader can read credit card information from the card chip. This means that whenever the credit card is within range of the mobile device's NFC field, the mobile device can read the information on the card.
[0007] Malicious software exists that can be installed on a mobile device without the user being aware of its presence. This malicious software can be used to access information on smart cards. This software may also be embedded as part of the code of other legitimate applications. In this case, whenever a credit card comes into (intentional or unintentional) proximity to the mobile device, the malicious software may cause the mobile device to read information from the credit card. In certain mobile device operating systems, such as the Android operating system, certain applications may be started or opened in the presence of an NFC field generated by certain cards, such as smart cards, bank cards, ID cards, membership cards, credit cards, debit cards, and gift cards. For example, when the Android operating system detects an NFC field, an application can use the detection of the field to launch itself (in the background or otherwise without the user's knowledge) and communicate with the card to obtain certain information. Therefore, sensitive user credit card information can be stolen by malicious software configured to listen for and wait for NFC fields generated by certain smart cards to retrieve information from a credit card (or other device). Once stolen, this information is stored on the user's device by the malicious software. Subsequently, this information may be transmitted to a server by malicious software without the user's knowledge and used for fraudulent purposes, such as carrying out scams and illegal transactions.
[0008] Therefore, it may be beneficial to provide exemplary systems, methods, and computer-accessible media that prevent malicious applications from executing EMV transactions. [Overview of the project]
[0009] Exemplary embodiments of this disclosure provide systems, methods, and computer-accessible media that can facilitate preventing malicious activity and malicious software from taking action based on received or intercepted data.
[0010] Embodiments of the present disclosure provide a method comprising: storing an applet configured to generate a digital tag on a first device; receiving a request for information on the first device; configuring the digital tag so that the reception of the digital tag by the second device causes an application to be launched on the second device; and issuing the digital tag from the first device.
[0011] Embodiments of the present disclosure provide a system that includes a contactless smart card and a user device configured to automatically request user information of the contactless smart card when physically close to the contactless smart card, receive a digital tag from the contactless smart card, and respond to the tag by launching an application associated with the received tag.
[0012] Embodiments of the present disclosure provide a contactless card comprising a processor, a communication interface, and a non-temporary computer-accessible medium storing computer-executable instructions. When instructions are executed by the processor, the contactless card is configured to perform a procedure including receiving a request for information via the communication interface and issuing an NFC Data Exchange Format (NDEF) tag, where the tag is configured as an Android Application Record (AAR) tag. The tag is associated with an applet stored on the contactless credit card. The tag is associated with at least one of (i) an application or (ii) an input on a first device and is configured to launch the application when received by the first device.
[0013] Further features of the disclosed design and the advantages provided thereby are described in more detail below with reference to specific exemplary embodiments shown in the accompanying drawings. [Brief explanation of the drawing]
[0014] [Figure 1] Figure 1 is a diagram illustrating a first device according to an exemplary embodiment of the present disclosure. [Figure 2] Figure 2 illustrates a user device according to an exemplary embodiment of the present disclosure. [Figure 3] Figure 3 is a flowchart of the method according to an exemplary embodiment of the present disclosure. [Figure 4] Figure 4 is a flowchart of the method according to an exemplary embodiment of the present disclosure. [Figure 5] Figure 5 is a flowchart of the method according to an exemplary embodiment of the present disclosure. [Figure 6] Figure 6 is a flowchart of a method according to an exemplary embodiment of the present disclosure. [Figure 7] Figure 7 is a diagram of a system according to an exemplary embodiment of the present disclosure. [Modes for carrying out the invention]
[0015] The following description of embodiments provides non-limiting representative examples that refer to figures specifically to illustrate features and teachings of different aspects of the invention. It should be apparent from the description of embodiments that the embodiments described can be carried out separately or in combination with other embodiments. Those skilled in the art will be able to learn and understand the different aspects of the invention described. The description of embodiments should facilitate the understanding of the invention to the extent that other embodiments, not specifically covered but within the knowledge of those skilled in the art who have read the description of embodiments, will be understood to be consistent with the application of the invention.
[0016] Exemplary systems, methods, and computer-accessible media may be provided that facilitate the blocking of malicious transactions based on data received from any NFC-enabled data source. For example, information encoded on a user's EMV-based credit card can be read by a mobile device or other similar device when the credit card is physically close to the device. Credit cards are often encoded to provide digital information to a device without any configuration, and therefore the information on the card can be read by any software installed on a digital device. However, credit cards can also be encoded to include, for example, a digital tag. When a credit card is close to a device, the digital tag can first be read by a mobile device.
[0017] A digital tag can be configured to launch an application identified by the digital tag on a mobile device when read by the mobile device. The launched application can, for example, prevent unauthorized access to requested information. The launched application can be configured to, for example, prevent other applications on the mobile device from accessing the requested information. The application associated with the digital tag can be installed on the mobile device by the user. The tag can be generated according to the NFC Data Exchange Format (NDEF) specification. The NDEF tag can further be configured as an Android Application Record (AAR) launch tag. An AAR launch tag can be associated with or registered with a specific application (e.g., an authorized or intended application) by the operating system installed on the mobile device. When an AAR launch tag is received by a mobile device, the mobile device can prioritize launching the associated application. In some examples, the launch of an associated application can prevent the launch of other applications in response to the mobile device receiving the AAR launch tag.
[0018] Applications associated with digital tags can be configured to perform a variety of functions. For example, an application can send a notification to the user when it has been launched more than a predetermined number of times within a given period. An application can also create a list of other applications installed on the device. Any other functions commonly associated with applications on an operating system, such as applications on the Android operating system, can be programmed into the device. Furthermore, digital tags can provide association, timing, and interference parameters regarding the association, ordering, timing control, and interaction between a specified application and other applications. Implementing and customizing these parameters can improve customization, operation, data protection, device security, and user experience.
[0019] The exemplary embodiments of this disclosure offer numerous advantages. Malicious and otherwise unauthorized applications can be installed on a device and configured to launch whenever a communication signal, such as a contactless communication field (e.g., an NFC field), is detected. The digital tags described herein can be used to prevent the launch of malicious or other unauthorized applications and to restrict their execution to only one or more authorized applications. For example, the digital tags described herein can be used to prevent a malicious application from reading or querying information (e.g., account information or other sensitive information) when an NFC signal is detected. This improves security and gives users greater control over the applications running on the device. As illustrated by the exemplary embodiments of this disclosure, user control can be further enhanced by parameters such as execution prioritization and association, timing, and interference.
[0020] FIG. 1 is a diagram illustrating a first device 100. The first device can be any device capable of storing information so as to access the stored information. The first device 100 may be capable of storing a record 101. The first device may also have a processor 102. The processor 102 can be any suitable, commercially available, or custom-designed processing circuit. The first device may have a communication interface 103 capable of generating a first device communication field 104. Also, the first device may have a memory 105 capable of including one or more applications or applets capable of executing the functions described herein. Examples of the first device 100 can include any device capable of including a record 101 and communicating via the communication interface 103. Examples include any NFC device such as a payment card, credit card, debit card, user ID card, mobile phone, smartphone, RFID card, tablet, or computer.
[0021] Also, the first device 100 can be a smart card having any suitable smart card operating system stored in the first device 100. For example, the operating system can be stored in the memory 105. The card operating system can be executed using the processor 102 of the first device 100. Two examples of operating systems available for smart cards include the JavaCard and MULTOS card operating systems. The card operating system enables the development of on-card applications of programs that need to be executed within a secure environment of the smart card chip, such as chip activation, issuance, file control, and data load management. By installing a specific application in the card operating system, for example, an NDEF tag can be generated according to certain parameters. These generated tags can be stored in the record 101.
[0022] Record 101 can contain any information accessible by the appropriate computing device. Record 101 can be stored in memory 105. Record 101 can be stored in any appropriate data type, including Boolean, byte, cbyte, date, decimal, integer, long, numeric, string, or any combination of these data types. Record 101 can also be stored as delimited data, fixed data, or mixed data. Record 101 can contain multiple data, and may contain metadata corresponding to all of them. The record may also contain custom data types or data fields. Non-exclusive examples of data may include information such as the identifier number of the first device, credit card number, personal account number (PAN), username associated with the first device, expiration date of the first device, Card Verification Value (CVV) code, text string, and telephone number.
[0023] Record 101 can also be stored in a way that makes data exchangeable via the NFC Data Exchange Format (NDEF), which enables information exchange between any compatible NFC device and another NFC device or tag. NDEF is strictly a message format. It is a binary message encapsulation format that enables exchange between NFC-enabled devices. An NDEF message can contain a payload of any type and size. The NDEF data format can be used to store and exchange information such as Unified Resource Identifiers (URIs) and plain text using commonly understood formats. The NDEF data format can further support the exchange of NDEF messages as a mechanism that enables the exchange of NDEF records. Each NDEF record can contain a structure that identifies the content of the record, as well as its size. An NDEF record can contain two components at a basic level: a record type used to provide context for the payload data, and the payload data itself. Together, these two components represent the action performed by the device upon receiving the NDEF record. A single NDEF message can contain multiple NDEF records. NDEF tags themselves can be created dynamically. For example, an NDEF tag can be generated at runtime by an applet stored in the memory 105 of the first device 100. For example, an NDEF tag can be obtained based on data introduced from a random number generator or an external source. The NDEF tag is read when the card, or a chip contained within the card, is exposed to a properly aligned magnetic field and a request for a specific NDEF message is issued.
[0024] Record 101 can be further configured and stored as an Android Application Record (AAR) launch tag. The AAR launch tag is a type of NDEF record and is used by Google's Android operating system to indicate to the NFC device which application should be used to handle the NFC tag. The AAR launch tag includes package attributes that can identify the Android application that handles or processes the NFC tag. The package attributes can identify the Android application that is launched in response to the tag.
[0025] Memory 105 may be read-only memory, write-once / read-multiple memory, or read / write memory, such as RAM, ROM, and EEPROM, and the first device 100 may include one or more of these memories. Read-only memory may be programmable as read-only at the factory, or it may be programmable only once. If it is programmable only once, it can be read many times after being written to once. Write-once / read-multiple memory may be programmed at some point after the memory chip leaves the factory. Once the memory is programmed, it cannot be rewritten but can be read many times. Read / write memory can be programmed and reprogrammed many times after the factory. Read / write memory can also be read many times after the factory. The memory of the first device 100 can be programmed with instructions to generate a record 101. The record 101 may further include a digital tag that can be generated based on the instructions contained in memory 105. The memory of the first device 200 may also include instructions stored as special applets, such as JavaCard applets. For example, memory 105 may include one or more applets configured to generate one or more NDEF tags, one or more of which may be further configured to be one or more AAR launch tags associated with one or more Android applications. Thus, memory 105 can be modified as needed to change which Android application on an Android device is launched in response to the receipt of a tag. In another example, memory 105 may be configured to generate digital tags that are compatible with different operating systems or different applications.
[0026] Memory 105 can store other information, such as a user identifier. Record 101 can also be included in memory 105. Other information, such as a user identifier, algorithm, and cryptographic key, can also be stored in memory 105. Memory 105 can be divided into several zones, each having a different security level. Processor 102 can track which memory addresses belong to which zone and the access status of each zone. In an exemplary embodiment, memory 105 can be divided into four zones: a secret zone (such as secure elements), a confidential zone, a usage zone, and a public zone.
[0027] The communication interface 103 can be any suitable technology capable of transmitting or receiving data over long distances. Examples of such technologies include, for example, Wi-Fi®, WLAN, RF, radio, IR, Bluetooth®, RFID, Near Field Communication (NFC), or any combination thereof, or other suitable architectures or systems that facilitate the communication of signals, data, and / or messages. Similarly, any suitable hardware-level and software-level algorithms can be selected to enable data transfer on the first device communication field 104. The first device communication field can be generated by the communication interface 103. Examples of algorithms include asynchronous connectionless protocols, synchronous connection-oriented links, link management protocols, host controller interfaces, or low-energy link layers. Information can be communicated using the NDEF data exchange format. This format allows for the exchange of both NDEF messages and NDEF records. The NDEF data format enables the exchange of NDEF records. Each NDEF record may include a structure that identifies the content and size of the record. An NDEF record can essentially contain two components: a record type used to provide context for the payload data, and the payload data itself. Together, these two components represent the actions the device performs when it receives an NDEF record.
[0028] Figure 2 is a diagram illustrating the user device 200. Non-limiting examples of the user device 200 include personal computers, laptops, tablets, e-readers, mobile phones, NFC readers, or smartphones. The user device 200 may include a display 201, a user interface 202, memory 203, a processor 204, and a user device communication interface 205 having a user device communication field 206. The user device 200 may further include one or more operating systems, such as the Android operating system, and one or more applications or applets capable of performing the functions described herein.
[0029] Memory 203 may be read-only memory, write-once / read-multiple memory, or read / write memory, such as RAM, ROM, and EEPROM, and user device 200 may include one or more of these memories. Read-only memory may be programmable as read-only at the factory, or it may be programmable only once. If it is programmable only once, it can be read multiple times after being written to. Write-once / read-multiple memory may be programmed at some point after the memory chip leaves the factory. Once programmed, the memory cannot be rewritten but can be read multiple times. Read / write memory can be programmed and reprogrammed multiple times after leaving the factory. Also, read / write memory can be read multiple times.
[0030] Memory 203 can be further configured to install an operating system or special instructions. The installed operating system can then be further configured to install additional compatible software, such as applications or programs. Examples of commercial operating systems include, for example, Android, iOS, Windows, Debian, Linux, and Linux variations such as Ubuntu. Special-purpose operating systems can also be installed in memory 203. As another example, multiple operating systems can be installed in memory 203, allowing users of user device 200 to select the operating system they wish to use.
[0031] The display 201 can be selected from any suitable two-dimensional or three-dimensional display, such as a light-emitting diode, liquid crystal display, digital light-processing display, or organic light-emitting diode display. The user interface 202 can be selected from any suitable user input device, such as a touchpad, touchscreen, mechanical switch, natural language user interface, click wheel, QWERTY keyboard, mouse, gesture recognition, or capacitive touchscreen.
[0032] The user device communication interface 205 can be any suitable technology capable of transmitting or receiving data over long distances. Examples of such technologies include, for example, Wi-Fi, WLAN, RF, radio, IR, Bluetooth, RFID, near-field communication (NFC), or any combination thereof, or other suitable architectures or systems that facilitate the communication of signals, data, and / or messages. Similarly, any suitable hardware-level and software-level algorithms can be selected to enable data transfer over the user device communication field 206. The user device communication field 206 can be generated by the user device communication interface 205. Examples of algorithms include asynchronous connectionless protocols, synchronous connection-oriented links, link management protocols, host controller interfaces, or low-energy link layers. Information can be communicated using the NDEF data exchange format. This format allows for the exchange of both NDEF messages and NDEF records. NDEF messages are a further mechanism for the exchange of NDEF records.
[0033] The first device 100 and the user device 200 can also communicate with each other using a network. The network may be any means, mechanism, protocol, or path that enables the transfer of information between the first device 100 and the user device 200, including but not limited to Wi-Fi, WLAN, RF, radio, IR, Bluetooth, cellular, near-field communication, SMS, MMS, telephone, any combination thereof, or any other suitable architecture or system that facilitates the communication of signals, data, and / or messages. The first device and the user device can communicate over a single network or multiple networks.
[0034] In an exemplary embodiment, the first device 100 may be energized when it approaches an NFC reader, which may be included in a user device 200. The NFC reader may emit a magnetic field that can energize the first device 100 (e.g., a smart card) through its inductance. Once powered in this manner or otherwise, the first device may emit an NFC signal. Upon detecting an NFC signal emitted by the first device 100, the user device 200 may automatically attempt to read an NDEF message by sending an NDEF request to the first device 100. The first device 100 may accept the request from the user device 200 and respond with an NDEF message. The NDEF message may further include at least one record, which is an AAR activation tag.
[0035] When the first device 100 and the user device 200 are physically close to each other, the user device can request information from the first device. In response to the request, the first device can transfer an NDEF tag, which may contain one or more records including an AAR activation tag, to the user device 200. The first device can also be configured to automatically transmit information to any user device 200 that can receive information from the first device 100. This can be done, for example, when the first device communication field 104 overlaps with the user device communication field 206. This transfer of information between the first device and the user device can be achieved by the means described above.
[0036] The first device 100 may be configured to include, for example, a credit card number, as well as related information such as a CVV number, username, and expiration date. The first device 100 may also be configured to transfer this information to the user device 200 using NFC or a similar medium. This information can be accessed by any second device when the two devices are physically close together. As described above, malicious software that may be installed on the user device 200 can listen for or wait for NFC signals from the first device 100 to access the information transmitted from the first device 100 via NFC signals. In some examples where malicious software is installed on the user device 200, information may be obtained in the background without the user's knowledge and used by the malicious software on the user device 200 to facilitate and execute fraudulent activities or transactions.
[0037] In other examples, malicious software may be installed on a second user device (not shown in Figure 2) which may be positioned in close proximity to the first device 100. In these examples, if the second user device is positioned close enough to the first device 100 so that it can read NFC or other signals provided by the first user device, the malicious software on the second user device may, when not hindered by the AAR activation tag, facilitate and execute fraudulent acts or transactions based on the signals read.
[0038] As described above, AAR activation tags generated by one or more applets on a contactless card can be configured to activate one or more specified applications. In some embodiments, the AAR activation tags can be scanned or checked by a security server or security application to identify all applications specified by the tag. In some examples, one or more applications designated to be activated by the AAR activation tag may be configured to retrieve all applications associated with the AAR activation tag. Once identified, the server can perform a security review of the applications. In this review, the applications may be scanned and checked for malicious elements (e.g., known software viruses) and capabilities that exceed system or security rules (e.g., unauthorized data access, unauthorized data export, unauthorized internal or external communication).
[0039] In some embodiments, an application can send a list of other applications installed on the operating system to a security server or security application. The security server or security application can use this information, which may be collected from multiple devices, to screen for malicious software. For example, the server can maintain a list of software known to be malicious. The server may, for example, simulate or emulate software from the list to reproduce in software the process of sending information from the first device 100 in the manner described herein, and observe whether various applications are listening to information received from the first device 100 and sending it to another source. The server may send a notification to the user of the first device, either to or through the launched application, or by any other means, that the device contains software that matches the list of suspected malicious software maintained by the server. If the security review is successfully completed, the application can be launched. If the security review identifies one or more security issues, or potential security issues, the launch of the application may be prevented or postponed until the issues are resolved. In some examples, when a client device receives a notification from the server, it may generate an alert or display to the user. In other examples, the server may present notifications to the user through other means (e.g., pop-up notifications, text messages, email, or phone calls). Alerts and notifications may provide one or more messages indicating that the application will not launch. In some examples, alerts and notifications may provide security information related to the application that will not launch.
[0040] In some embodiments, the first device 100 may further be configured to include a tag, such as an AAR tag, in its record 101, which is attached to the information normally transmitted by the first device. The AAR tag may be configured to launch an application specified by the AAR tag when received by a user device. This tag may be configured to be sent first to the user device 200 before any other sensitive information contained in the first device 100 is transferred. Only the application specified by the AAR launch tag can be launched on the user device 200 (or any second device) upon receipt of the tag. The operating system of the user device 200 may be configured to allow only the launched application, or any other designated application, to access the additional information transmitted by the first device 100. By launching this application first, it is possible to prevent a second application from being launched in response to the presence of the NFC field. Thus, a malicious application (or other malicious software) cannot read the information transmitted by the first device 100 because its launch or execution is prevented or stopped by the launch of the application specified by the AAR tag. The first device 100 can also be configured to include or generate a set of tags so that the process of launching the application is compatible between the operating system and the user device. Therefore, stronger protection can be designed for the data contained in the first device 100.
[0041] For example, a user can tap a payment card (e.g., device 100) on the back of an Android phone (e.g., user device 200) or store the card in the phone wallet located right next to the phone's NFC reader. An application programmed to read the EMV applet on the card to read the credit card number, personal information, card verification value (CVV) code, and expiration date from the card may be installed on the phone. This application may be maliciously installed disguised as another type of software, such as a game, social networking application, or entertainment application. Malicious applications may also be injected into the code of legitimate applications. These malicious applications can run in the background, invisible to the user, and read the card information. The read information may be uploaded to a backend server and collected for fraudulent use. To prevent this, additional software can be installed on the card's chip, as described in the illustrated embodiment, to prevent other applications on reading devices other than the card issuer's application from reading the payment card. The protective software generates an NFC NDEF message containing one or more NDEF records. One of these NDEF records could be an AAR launch tag, configured so that the operating system on the reading device launches the card issuer's application on the reading device, preventing the launch or further operation of other applications on the reading device. For example, the Android operating system is configured so that only one application can read information from Android system memory at a time. By launching the card issuer's application, it is possible to prevent malicious third-party applications from secretly launching, rather than being launched by the user, to read IC card data when the card is stored next to an NFC-enabled Android device.Therefore, any information contained in the smart card, or that can be transmitted from the smart card to the user device 200, is intercepted by the first-party application.
[0042] Adding an NDEF record to a smart card may not prevent an application already launched by the user on user device 200 from accessing or requesting information on first device 100. An application on Android OS can be launched automatically in the presence of an event such as the presence of an NFC signal. If no application is open or otherwise inactive on user device 200, an exemplary embodiment of the AAR launch tag of this disclosure launches the specified application on user device 200. Furthermore, the AAR launch tag may be configured to prevent any application other than the specified application from opening or otherwise becoming active. The AAR launch tag may be configured to prevent any application other than the specified application from opening or otherwise becoming active, regardless of the state of the specified application. This can be achieved, for example, through the operating system of user device 200, such as Android OS. For example, if user device 200 is active and the NFC radio is active, the NFC radio of user device 200 may be configured to be activated by the manufacturer of user device 200. For example, the NFC radio on user device 200 can be activated when the user device's screen is active and the user device is unlocked. In some examples, user device 200 may be an Android device, and the NFC radio may be configured to be activated only when the Android screen is on and the device is unlocked. However, if an application is already running, the user of user device 200 is not prohibited from accessing or using that application.
[0043] As an example, a user may place their NFC-enabled credit card (e.g., device 100) in their coin purse or wallet. Throughout the day, a valid credit card may enter a proximity state for NFC communication with the user's personal device or other NFC-enabled user devices. The user may have their own device with the Android operating system installed. The NFC-enabled credit card may further be configured to include a tag in record 101, such as an AAR launch tag configured to launch a specific application, for example, a financial server provider (or other service provider) application associated with the credit card, on the user's device. If the specific application is not already installed on the user's device, the tag may further be configured to launch the Android device application store (e.g., Google Play Store) or another similar platform so that the specified application can be installed on the user's device.
[0044] An NDEF tag or AAR record may consist of the package name of a specific Android application. Therefore, upon receiving a specific AAR record or NDEF tag, the operating system or Android operating system will launch the specified application when a contactless card is tapped on the phone. If the specified application is not currently installed on the Android device, the system will launch the Google Play Store to a page where the specified application can be downloaded and installed on the Android device.
[0045] The digital tag within the first device 100 may be further configured so that the user device 200 can access a server and download the application associated with the tag received from the first device 100. This can be achieved by including information in the first device 100 that identifies a specific application. The server may be a standard, commercially used server well-known for communicating with devices over a network. In one example, the tag within the first device can interface a dedicated application with the server and allow it to download the application. One example of such a dedicated application is the Google Play Store on the Android® OS. Other examples of such applications include the App Store for the iOS® operating system and the Microsoft Store, which enables the download of Windows® applications. Yet another example is the Canonical Store and Ubuntu Software Center for the Ubuntu® operating system. In addition, there are package managers specific to various operating systems.
[0046] In the example where the dedicated application is the Google Play Store, the server may be hosted by Google®. If the application is not installed on the user's device, receiving a digital tag may launch the Google Play Store to a page related to the application. One or more of these pages may display a button to download and install the application on the user's device. When the user clicks the button, the application is downloaded, and during the download and subsequent installation, the Google Play Store user interface may display a "busy" state. Once complete, the "busy" state is cleared, and the user interface may present another button to launch the application. Furthermore, this button may be presented by the user's device in the form of an application icon displayed on the Android desktop, allowing the user to launch the application from the desktop.
[0047] In some embodiments, record 101 may further specify additional parameters related to the launch of this application. These embodiments may relate to association, timing, and interference parameters. For example, association parameters may include the identification of one or more applications to be launched in addition to the application specified by the AAR tag, and the identification of a sequence for launching one or more additional applications. Exemplary sequences include, but are not limited to, linear sequences (e.g., one application after another), concurrent launches, and completion-triggered launches (e.g., launching a second application only after a previously launched first application has closed and / or completed an operation, launching an application only after all other previously launched applications have closed and / or performed a specific operation, and launching an application only after one or more operations have completed, regardless of whether one or more operations are related to or performed by other launched applications).
[0048] As another example, time parameters can specify time-related aspects of application launch. For example, time parameters can include a specified time to launch the application specified by the AAR launch tag, a specified time to launch one or more additional applications, a time interval between application launches, and a time delay that prevents the launch of one or more additional applications following the launch of the application specified by the AAR launch tag. As yet another example, the application specified by the AAR launch tag may only be launched after a specified period of time has elapsed without user input from the user device, or when a specific specified input (e.g., a specific keystroke or touchscreen input) is received.
[0049] As another example, interference parameters can specify the effect a launched application has on one or more other applications. For instance, interference parameters can cause an application specified by an AAR launch tag to be launched, and then suspend the execution of one or more applications for a predetermined period of time until a specific action is performed by the launched application, until the launched application signals that other applications can resume execution, or until the launched application is closed. Interference parameters can also completely close one or more applications.
[0050] Therefore, by using association parameters, time parameters, and interference parameters, it is possible to control which applications can be executed, the timing and order of their execution, and, in particular, the ability to interfere with the operation of other applications during critical periods of operation for a specific application. This can improve the performance and operation of the first device 100 and the user device 200, and also improve data security and user experience.
[0051] Figure 3 is a flowchart of a method 300 for transferring information from a first device 100 to a user device 200 in an exemplary embodiment of the present invention. The method begins in step 305, where an applet is stored in the first device 100 and configured to generate a collection of digital tags. The collection of tags may be as described above, and the collection may include at least one AAR launch tag. In some examples, these tags may be generated once in advance and may be static. In these examples, it is not necessary to use an applet to generate the digital tags. In other examples, the collection of tags may be created dynamically, for example, based on the current operational state of the first device 100, the user device 200, and any applet or application running on them.
[0052] In step 305, the communication field 104 of the first device 100 may enter a communication field generated by the user device 200, such as an NFC communication field or another contactless communication field. In step 310, the first device 100 may receive a request for information. In some examples, this step may occur when the first device communication field 104 overlaps with another communication field. For example, an NDEF file is read when a card / chip is exposed to a properly aligned magnetic field. In another example, this step may occur when an NFC device within the first device 100 is activated in the presence of an external field or device, such as the user device 200 or another device.
[0053] In step 315, the first device 100 can generate one or more digital tags. In this step, the first device 100 may include additional information along with the one or more digital tags. Examples of additional information transmitted with the digital tags may include user information or credit card information. In step 320, one or more digital tags may be configured to associate with at least one application so that when the issued tag is received on the second device, it launches the relevant application on the second device. The tag configuration may also be done in a manner that corresponds to the NDEF format. The tag may further be configured to be an AAR launch tag that can specify a particular action that the operating system of the user device 200 should take when the AAR tag is received. In step 325, one or more digital tags may be configured to include one or more association parameters, one or more time parameters, and / or one or more interference parameters.
[0054] In step 330, one or more digital tags may be sent from the first device 100 to the user device 200. In step 335, upon receiving one or more digital tags, the user device 200 may launch one or more designated applications as specified by the AAR launch tag. In an example where a collection of tags is sent, the AAR launch tag may be the first tag read by the user device 200. In step 340, if one or more association parameters, one or more time parameters, and / or one or more interference parameters exist, they may be executed by the user device 200.
[0055] Figure 4 illustrates a method of exchanging information. Method 400 begins in step 405, when user device 200 is in physical proximity to first device 100, and information is requested from first device 100. This can occur when user device 200 recognizes the presence of first device 100 through the overlap of the communication fields of first device 100 and user device 200. This can also occur when the software of user device 200 recognizes the presence of an external communication field of user device 200. In step 410, a digital tag is received from first device 100. This digital tag may contain information requested by user device 200 from first device 100. In some examples, the digital tag may contain additional information not requested by user device 200. For example, the digital tag may contain one or more association parameters, one or more time parameters, and / or one or more interference parameters. In any case, the information may be in the form of one or more records, each record which may be used in an unauthorized manner by a malicious application.
[0056] In step 415, an application associated with a digital tag may be launched by the user device 200 in response to the received tag. For example, the launched application may be defined by the metadata or dedicated fields of the received tag. The launched application may then read other information sent from the first device to the user device, such as credit card information or other personal information, as well as any association parameters, time parameters, and interference parameters. Thus, the application can intercept other information sent to the user device at launch and prevent other applications on the user device from accessing that information. Furthermore, the application can prevent other applications from running without the user specifically requesting and / or authorizing their execution. Advantageously, this prevents the execution of applications containing malicious applications without the user's permission or knowledge. In step 420, the application may read any additional information or parameters and act based on them.
[0057] Figure 5 shows an embodiment of the present invention, Method 500. The method begins in step 505, when a user device (e.g., user device 200) is in physical proximity to the first device, and information is requested from the first device (e.g., first device 100). This may occur when user device 200 recognizes the presence of the first device by the overlap of the communication fields of the first device 100 and user device 200. This may also occur when software within user device 200 recognizes the presence of an external communication field of user device 200. In step 510, a digital tag is received from the first device 100. This digital tag may be information requested from the first device 100 by the second device 100. In some examples, the digital tag may include additional information not requested by user device 200. In any case, the information may be in the form of one or more records, each record which may be used in an unauthorized manner by a malicious application. This digital tag may be platform or operating system specific. In step 515, the application associated with the emitted digital tag may be launched in response to the received tag. For example, in the Android operating system, the launched application can be defined by the metadata or a dedicated field of the received tag. In step 520, if the second device cannot find the application specified by the emitted digital tag, it may launch a package manager or application manager, such as the Google Play Store, to allow the user of the user device to identify and download the specified application. In step 525, the application specified by the emitted digital tag may be downloaded and / or installed by the user device. This allows the device to automatically install the specified application if it does not already exist on the device.
[0058] Figure 6 shows an embodiment of the present invention, Method 600. The method can be started in step 605, in which an applet is stored on a first device (e.g., first device 100), and the applet is configured to generate a collection of digital tags. These tags can be pre-generated, in which case the applet may optionally not be used to generate the digital tags (i.e., the digital tags can be stored in the memory of the first device without the need for creation by the applet). In some examples, the collection of digital tags may include additional information such as user account information and / or user identification information, and the collection of digital tags may further include one or more parameters such as association parameters, time parameters, and interference parameters.
[0059] In step 610, a signal is transmitted from the first device in the form of a near-field wireless communication field. This can be transmitted in response to an external trigger such as an electric field, or the first device 100 may be in a state where it is always transmitting a signal. In step 615, the first device 100 can receive a request for information. This step can take the form of, for example, the activation of an NFC device within the first device 100 in the presence of an external field or device. This can also occur if the first device communication field (e.g., the first device communication field 104) overlaps with other communication fields.
[0060] In step 620, the first device 100 can issue a digital tag, which is configured to conform to the NDEF data format specification and further configured to be an Android Application Record (AAR) tag. In this step, the first device 100 can transmit additional information along with the digital tag. Examples of additional information transmitted with the digital tag include user information or credit card information, and parameters such as association parameters, time parameters, and interference parameters. In step 625, the issued tag may be configured to associate with at least one of (i) an application or (ii) an input on the second device, such that the application is launched on the second device upon receipt of the tag.
[0061] Figure 7 shows a block diagram of an exemplary embodiment of the System 700 according to the Disclosure that can be used to perform the procedures described below. For example, the exemplary procedures according to the Disclosure described herein can be performed by a processing arrangement and / or computing device (e.g., a computer hardware device) 705. Such a processing / computing device 705 may be, but is not limited to, a whole or part of a computer / processor 710 that includes, for example, one or more microprocessors and can use instructions stored in a computer-accessible medium (e.g., RAM, ROM, hard drive, or other storage device).
[0062] As shown in Figure 7, for example, a computer-accessible medium 715 (e.g., a storage device such as a hard disk, floppy disk, memory stick, CD-ROM, RAM, ROM, or a collection thereof) can be provided (e.g., in a manner that allows communication with the processing unit 705). The computer-accessible medium 715 may contain executable instructions 220. In addition, or instead, a storage device 725 may be provided separately from the computer-accessible medium 715, which can provide instructions to configure the processing unit 705 to perform certain exemplary procedures, processes, and methods, such as those described above herein.
[0063] Furthermore, the exemplary processing unit 705 may or may include input / output ports 735, which may include, for example, wired networks, wireless networks, the internet, intranets, data acquisition probes, sensors, etc. As shown in Figure 7, the exemplary processing unit 705 can communicate with an exemplary display device 730, which, according to certain exemplary embodiments of this disclosure, may be, for example, a touchscreen configured to input information to the processing unit in addition to outputting information from the processing unit. Furthermore, the exemplary display device 730 and / or storage device 725 may be used to display and / or store data in a user-accessible and / or user-readable format.
[0064] Throughout this specification and the claims, the following terms have the meanings expressly associated herein, unless the context clearly indicates otherwise. The term "or" is intended to mean inclusive "or." Furthermore, the terms "a," "an," and "the" are intended to mean one or the plural, unless otherwise specified or unless the context clearly indicates that they are directed toward the singular.
[0065] This specification contains numerous specific details. However, it will be understood that implementations of the disclosed technology may be carried out without these specific details. In other instances, well-known methods, structures, and techniques are not described in detail so as not to obscure the understanding of this specification. References to “several examples,” “other examples,” “one example,” “example,” “various examples,” “one embodiment,” “embodiment,” “several embodiments,” “exemplary embodiments,” “various embodiments,” “one implementation,” “implementation,” “exemplary implementation,” “various implementations,” “several implementations,” etc., indicate that implementations of the technology described and disclosed in this manner may include certain functions, structures, or characteristics, but not all implementations necessarily include certain functions, structures, or characteristics. Furthermore, repeated use of the phrases “in one example,” “in one embodiment,” or “in one implementation” may, but does not necessarily refer to the same example, embodiment, or implementation.
[0066] Where used herein, unless otherwise specified, the use of ordinal adjectives such as “first,” “second,” “third,” etc., to describe a common object simply indicates that different instances of a similar object are being referred to, and is not intended to imply that the objects described in this way must be in a given order, temporally, spatially, sequentially, or in any other way.
[0067] While specific embodiments of the disclosed technology have been described in relation to those currently considered to be the most practical and diverse embodiments, it should be understood that the disclosed technology is not to be limited to the disclosed embodiments, but rather is intended to cover a variety of modifications and equivalent arrangements included in the appended claims. Certain terms are used herein, but these are used in a general and descriptive sense only and not for limiting purposes.
[0068] The description in this specification uses examples to disclose specific implementations of the disclosed technology, including the best mode, and to enable anyone skilled in the art to implement specific implementations of the disclosed technology, including manufacturing any device or system, using any incorporated method. The patentable scope of specific implementations of the disclosed technology is defined in the claims and may include other examples that may arise for a person skilled in the art. Such other examples are intended to be included in the claims if they have structural elements that are not different from the language of the claims, or if they include equivalent structural elements that are not substantially different from the language of the claims.
Claims
1. storing an applet configured to generate a digital tag on a smart card; receiving, at said smart card, a request for the requested information after entering a communication field generated by the smartphone; associating the digital tag with at least one of (i) an application or (ii) an input on the smartphone such that receipt of the digital tag by the smartphone launches an application on the smartphone upon successful completion of a security review; and issuing the digital tag from the smart card, wherein the digital tag is configured to restrict the requested information to be accessible only by the application to prevent unauthorized access to the requested information; prompting the security review of the application prior to the launch via the digital tag; and Preventing the launch of the application when the security review is not successfully completed. A method comprising:
2. the application is configured to prevent other applications on the smartphone from accessing the requested information. The method of claim 1.
3. The smart card is a contactless credit card. The method of claim 1.
4. the smart card emits a near field communication field; The method of claim 1.
5. the smartphone includes an Android-based operating system; The method of claim 1.
6. the applet is configured to generate at least one digital tag according to the NFC Data Exchange Format (NDEF) specification; The method of claim 5.
7. and wherein the at least one digital tag according to the NDEF specification is further configured to be an Android Application Record (AAR) activation tag. The method of claim 6.
8. a contactless smart card; a user device application; The user device application automatically requesting the required information from the contactless smart card after the contactless smart card enters a communication field generated by a user device; receiving a digital tag from said contactless smart card, wherein: the digital tag is configured to launch an application associated with the digital tag upon successful completion of a security review; and the digital tag is configured to restrict the requested information to be accessible only by the application to prevent unauthorized access to the requested information; performing the security review of the application associated with the digital tag prior to the launch of the application; and configured to prevent the application associated with the digital tag from launching if the security review is not successfully completed. system.
9. the digital tag is configured to launch the application associated with the digital tag when the user device is inactive; The system of claim 8.
10. the digital tag is configured to launch the application associated with the digital tag when the display of the user device is inactive; The system of claim 8.
11. The application associated with the digital tag is further configured to launch when the user device has not received user input for a predetermined period of time. The system of claim 10.
12. the user device is configured to include an Android-based operating system; The system of claim 10.
13. the user device is configured to launch the application associated with the digital tag in response to an NFC Data Exchange Format (NDEF) tag or an Android Application Record (AAR) launch tag; The system of claim 11.
14. The system of claim 13 , wherein the user device is further configured to launch an application manager in response to the NDEF tag if the application associated with the digital tag is not present on the system.
15. The application manager is a Google Play Store. The system of claim 14.
16. the user device is further configured to download and install the application associated with the digital tag from the Google Play Store; The system of claim 14.
17. a processor; a communication interface; a non-transitory computer-accessible medium having computer-executable instructions stored thereon, the instructions being configured, when executed by the processor, to perform procedures including: receiving a request for information via the communication interface after entering a near field communication (NFC) communication field generated by the smartphone; and issuing an NFC Data Exchange Format (NDEF) tag; The NDEF tag is configured to be an Android Application Record (AAR) tag; The NDEF tag is configured to be associated with an applet stored on the contactless card, and the NDEF tag is configured to be associated with an application on the smartphone; The NDEF tag is configured to launch the application associated with the NDEF tag upon receipt by the smartphone and successful completion of a security review. Contactless card.
18. the failure to successfully complete the security review includes the detection of a software virus; The method of claim 1.
19. the failure of the security review to complete successfully includes the detection of a function that breaks a security rule; The system of claim 8.
20. Successful completion of the security review includes the detection of no software viruses and no detection of features that break through security rules.
18. The contactless card of claim 17.