EP4655677A1

EP4655677A1 - Access device interaction method using multiple user devices

Info

Publication number: EP4655677A1
Application number: EP25757138.0A
Authority: EP
Inventors: Yuexi Chen; Hendy Wong; Sarah Jane M. GALAMAY
Original assignee: Visa International Service Association
Current assignee: Visa International Service Association
Priority date: 2024-03-28
Filing date: 2025-03-26
Publication date: 2025-12-03
Also published as: CN121039644A; WO2025207809A1; EP4655677A4

Abstract

A method of testing a software application on a first user device is disclosed. The method includes determining that a transceiver application on the first user device is unable to communicate with a first near field communication (NFC) application programming interface (API) associated with a first NFC hardware in the first user device. The method also includes forming a data connection between the first user device and a second user device with a second NFC API associated with a second NFC hardware in the second user device, and conducting one or more interactions between the software application and an access device via the second user device and the second NFC API associated with the second NFC hardware. The second user device communicates with the access device via NFC.

Description

ACCESS DEVICE INTERACTION METHOD USING MULTIPLE USER DEVICES

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application is a PCT application which claims priority to U.S. Provisional Patent Application No. 63/570,974, filed on March 28, 2024, which is herein incorporated by reference in its entirety for all purposes.

BACKGROUND

[0002] User devices such as mobile phones can be used as contactless devices to access secure locations, obtain resources (during payments), and the like. They can communicate with access devices using a short range communication protocol such as NFC (near field communication). User devices can have NFC hardware which may include NFC chips and NFC antennas, which allow them to communicate with the access devices using NFC. In some cases, an NFC hardware API (application programming interface) may allow applications on the user devices to communicate with the NFC hardware.

[0003] Some user devices may have operating systems, which require “entitlement” before the NFC hardware API and the NFC hardware can be accessed or used by applications on the user devices. The requirement of entitlement presents logistical difficulties for the development and testing of applications and SDKs (software development kits) that are to be used on the user devices. For example, an entitlement may only allow NFC interface access to applications on user devices when they are in the European Union. However, the development of the application and/or SDK may be performed in the United States, and testing of the application may be conducted in Singapore. In this scenario, because of the entitlement requirement, the development and testing of the application and/or SDK may be difficult or impossible to perform. Further, in certain situations, a party who develops an application (e.g., an HCE or Host Card Emulation application) and/or an SDK may not want to call the NFC hardware API on the mobile device. For example, an application such as an HCE application and a corresponding SDK may not yet be compatible with the NFC hardware API or may have other issues with the NFC hardware API.

[0004] Embodiments of the invention address these and other problems, individually and collectively.

BRIEF SUMMARY

[0005] Novel and inventive techniques are disclosed to enable the development and testing of software (e.g., an HCE application and an SDK) without directly calling an NFC hardware API on user device such as a smart phone to access NFC hardware. Embodiments of the invention can bypass any entitlement requirement (such as when entitlement is not available or is invalid) needed to access the NFC hardware on the user device.

[0006] One embodiment is related to a method of testing a software application on a first user device, the method comprising: determining, by the first user device comprising the software application, that a transceiver application on the first user device is unable to communicate with a first near field communication (NFC) application programming interface (API) associated with a first NFC hardware in the first user device; forming a data connection between the first user device and a second user device with a second NFC API associated with a second NFC hardware in the second user device; and conducting one or more interactions between the software application and an access device via the second user device and the second NFC API associated with the second NFC hardware, wherein the second user device communicates with the access device via NFC.

[0007] Another embodiment of the invention includes a first user device comprising: a processor; and a computer readable medium comprising code, executable by the processor for performing a method comprising: determining, by a software application on the first user device, that a transceiver application on the first user device is unable to communicate with a first near field communication (NFC) application programming interface (API) associated with a first NFC hardware in the first user device; forming a data connection between the first user device and a second user device with a second NFC API associated with a second NFC hardware in the second user device; and conducting one or more interactions between the software application and an access device via the second user device and the second NFC API associated with the second NFC hardware, wherein the second user device communicates with the access device via NFC.

[0008] Another embodiment of the invention includes a method comprising: forming a data connection between a first user device and a second user device with a second NFC API associated with a second NFC hardware in the second user device, after the first user device determines that an application comprising a transceiver application on the first user device is unable to communicate with a first near field communication (NFC) application programming interface (API) associated with a first NFC hardware in the first user device; and performing one or more NFC interactions with an access device using the second NFC API associated with the second NFC hardware in the second user device while communicating with the application in the first user device.

[0009] Another embodiment of the invention includes a second user device comprising a processor, and a computer readable medium. The computer readable medium comprising code, executable by the processor, for performing a method. The method comprises: forming a data connection between a first user device and a second user device with a second NFC API associated with a second NFC hardware in the second user device, after the first user device determines that an application comprising a transceiver application on the first user device is unable to communicate with a first near field communication (NFC) application programming interface (API) associated with a first NFC hardware in the first user device; and performing one or more NFC interactions with an access device using the second NFC API associated with the second NFC hardware in the second user device while communicating with the application in the first user device.

[0010] These and other embodiments of the invention are described in further detail below with reference to the Figures.

BRIEF DESCRIPTION OF THE DRAWINGS

[0011] FIG. 1 is a block diagram illustrating a host card emulation (HCE) application and SDK for card emulation in a production configuration, according to certain embodiments. [0012] FIG. 2 is a block diagram illustrating debugging and testing an HCE application and SDK using a proxy device for card emulation, according to certain embodiments.

[0013] FIG. 3 shows a block diagram of an exemplary user device according to an embodiment.

[0014] FIG. 4 shows a block diagram of an access device according to an embodiment.

DETAILED DESCRIPTION

[0015] Before discussing specific embodiments of the invention, some descriptions of some terms may be helpful.

[0016] A “credential” may be any suitable information that serves as reliable evidence of worth, ownership, identity, or authority. A credential may be a string of numbers, letters, or any other suitable characters, as well as any object or document that can serve as confirmation. Examples of credentials include value credentials, identification cards, certified documents, access cards, passcodes, and other login information, etc.

[0017] A “user device” may be any suitable device that a user can interact with (e.g., a payment card or mobile phone). User devices may be in any suitable form. Some examples of user devices include cards (e.g., payment cards such as credit, debit, or prepaid cards) with magnetic stripes or contactless elements (e.g., including contactless chips and antennas), cellular phones (smart phones) wearable devices (smart watches, smart rings, smart glasses, etc.) PDAs, personal computers (PCs), tablet computers, bodily implant devices, and the like. In some embodiments, where a user device is a mobile device, the mobile device may include a display, a memory, a processor, a computer-readable medium, and any other suitable component.

[0018] An “SDK” or may be a software development kit, which can be a collection of software development tools that can be present in an installable package that allows any applications that download the kit to enable the functions written in the kit. The functions present in an SDK may vary. For example, one SDK may have authentication software. Another SDK may have token processing software. [0019] A “server computer” may include a powerful computer or cluster of computers. For example, the server computer can be a large mainframe, a minicomputer cluster, or a group of servers functioning as a unit. In one example, the server computer may be a database server coupled to a web server. The server computer may be coupled to a database and may include any hardware, software, other logic, or combination of the preceding for servicing the requests from one or more client computers. The server computer may comprise one or more computational apparatuses and may use any of a variety of computing structures, arrangements, and compilations for servicing the requests from one or more client computers.

[0020] A “processor” may include a device that processes something. In some embodiments, a processor can include any suitable data computation device or devices. A processor may comprise one or more microprocessors working together to accomplish a desired function. The processor may include a CPU comprising at least one high-speed data processor adequate to execute program components for executing user and/or system-generated requests. The CPU may be a microprocessor such as AMD's Athlon, AMD Ryzen, AMD Threadripper, Duron and/or Opteron; IBM and/or Motorola's PowerPC; IBM's and Sony's Cell processor; Intel's Celeron, Itanium, Pentium, Xeon, and/or XScale; and/or the like processor(s).

[0021] A “memory” may be any suitable device or devices that can store electronic data. A suitable memory may comprise a non-transitory computer readable medium that stores instructions that can be executed by a processor to implement a desired method. Examples of memories may comprise one or more memory chips, disk drives, etc. Such memories may operate using any suitable electrical, optical, and/or magnetic mode of operation.

[0022] A “token” may be a substitute value for a credential. A token may be a string of numbers, letters, or any other suitable characters. Examples of tokens include access tokens such as payment tokens, data that can be used to access secure systems or locations, etc.

[0023] A "payment token” may include an identifier for a payment account that is a substitute for an account identifier, such as a primary account number (PAN) and/or an expiration date. For example, a token may include a series of alphanumeric characters that may be used as a substitute for an original account identifier. For example, a token “4900 0000 0000 0001” may be used in place of a PAN “4147 0900 0000 1234.” In some embodiments, a token may be “format preserving” and may have a numeric format that conforms to the account identifiers used in existing transaction processing networks (e.g., ISO 8583 financial transaction message format). In some embodiments, a token may be used in place of a PAN to initiate, authorize, settle or resolve a payment transaction or represent the original credential in other systems where the original credential would typically be provided. In some embodiments, a token value may be generated such that the recovery of the original PAN or other account identifier from the token value may not be computationally derived. Further, in some embodiments, the token format may be configured to allow the entity receiving the token to identify it as a token and recognize the entity that issued the token.

[0024] “Tokenization” is a process by which sensitive data is replaced with substitute data. For example, a real credential (e.g., a primary account number (PAN)) may be tokenized by replacing the real account identifier with a substitute number that may be associated with the real credential. Further, tokenization can be applied to any other information to substitute the underlying information with a token. “Token exchange” or “de-tokenization” can be a process of restoring the data that was substituted during tokenization. For example, a token exchange may include replacing a payment token with its associated primary account number (PAN). Further, de- tokenization or token exchange may be applied to any other information to retrieve the substituted information from a token. In some embodiments, token exchange can be achieved via a transactional message, such as an ISO message, an application programming interface (API), or another type of web interface (e.g., web request).

[0025] A “token service computer” can include a system that that services tokens. In some embodiments, a token service computer can facilitate requesting, determining (e.g., generating) and/or issuing tokens, as well as maintaining an established mapping of tokens to primary account numbers (PANs) in a repository (e.g., token vault). In some embodiments, the token service computer may establish a token assurance level for a given token to indicate the confidence level of the token to PAN binding. The token service computer may include or be in communication with a token vault where the generated tokens are stored. The token service computer may support token processing of payment transactions submitted using tokens by de- tokenizing the token to obtain the actual PAN. [0026] An “application” may be computer code or other data stored on a computer readable medium (e.g., memory element or secure element) that may be executable by a processor to complete a task.

[0027] An “access device” may be any suitable device for obtaining access to a resource. An access device may generally be located in any suitable location, such as at the location of a merchant. An access device may be in any suitable form. Some examples of access devices include POS devices, cellular phones, PDAs, personal computers (PCs), tablet PCs, hand-held specialized readers, set-top boxes, electronic cash registers (ECRs), automated teller machines (ATMs), virtual cash registers (VCRs), kiosks, security systems, access systems, Websites, and the like. An access device may use any suitable contact or contactless mode of operation to send or receive data from, or associated with, a payment device and/or a user mobile device.

[0028] As used herein, terms such “first,” “second,” “third,” etc. are used to delineate features or steps and are not intended to imply a particular order.

[0029] FIG. 1 is a block diagram illustrating an interaction between a first user device 30 comprising an HCE application 34 and an access device 40 (e.g., a contactless POS device). The HCE application 34 comprises an HCE SDK 32 and an NFC transceiver application 36. In the interaction, entitlement 31 is present and the HCE SDK 32 may access a first NFC interface (e.g., a first NFC API and NFC hardware 38), such that the first user device 30 can communicate with an access device 40 via NFC.

[0030] It is noted that embodiments of the invention are not limited to the specific types of software applications or components in FIG. 1 (and FIG. 2). For example, although the use of “HCE” is described in detail, embodiments of the invention can be used to test applications that have any suitable function including, but not limited to, data access applications, identity applications, secure location access applications, etc. Further, although an “APDll” socket server and APDll messages are described in detail, embodiments are not limited thereto. The socket server may process any other suitable type of message. Still further, although an “SDK” is described in FIGs. 1-2, embodiments of the invention can be used for other types of software components. [0031] Card emulation technology such as Host Card Emulation (HCE) can emulate a smartcard on a user device (e.g., a smartphone) to allow a mobile application running on the user device to conduct contactless transactions. In the card emulation environment, a mobile application can access the contactless interface of the user device via the operating system (OS) of the user device without involving a secure element. As compared to secure element implementations, the card emulation approach reduces the technical and commercial complexities for entities such as issuers and/or payment processors, because issuers and/or payment processors can provision account credentials and payment functionalities to a mobile application on a portable communication device without having to obtain access to a secure element through a mobile network operator.

[0032] During a contactless interaction between a user device that has HCE functionality and an access device, the user device can transmit a credential and a cryptogram, or a token and a token cryptogram, to the access device via NFC in a series of messages exchanges (without the use of a secure element). The access device can then generate an authorization request message and transmit it to an authorizing entity computer (e.g., an issuer computer) via a processing network for authorization.

[0033] In FIG. 1 , the first user device 30 can be a smartphone, which may include an HCE application 34 on a computer readable medium. The HCE application 34 in the first user device 30 can comprise an HCE SDK 32 and a near field communication (NFC) transceiver application 36. The first user device 30 can also comprise a first NFC interface, which may include the first NFC API and hardware 38. The first NFC interface can be separate from the HCE application 34. The NFC transceiver application 36 in the HCE application 34 can communicate with the first NFC API and NFC hardware 38 if entitlement 31 is present.

[0034] The entitlement 31 can be present in an operating system of the first user device 30. The entitlement 31 may or may not be valid for a particular application on the first user device 30. For example, in some cases, the entitlement 31 may not be valid for an application when the first user device 30 is outside of a predefined region (e.g., a particular country or set of countries). [0035] In some cases, a first party (e.g., a payment processor such as Visa) may develop the HCE SDK 32 running on the OS (operating system) and define the interface requirements of the NFC transceiver application 36. The NFC transceiver application 36 and the HCE SDK 32 can produce application protocol data unit (APDll) commands and response payloads that can be exchanged with the access device 40. In an example, a second party (e.g., an issuer such as a European bank with the required entitlement 31 ) may develop and manage the HCE application 34, even though the HCE SDK 32 and the NFC transceiver application 36 are developed or defined by the first party. A third party (e.g., a mobile phone developer or manufacturer) may develop or manufacture the NFC interface (e.g., the NFC API and hardware 38) in the first user device 30 (e.g., a first smartphone).

[0036] In some embodiments, the HCE application 34 incorporating the HCE SDK 32 and the NFC transceiver application 36 developed by the second party may call the NFC API in the first NFC API and hardware 38 on behalf of the first party. As a result, the HCE SDK 32 can perform NFC communications with the access device 40 using the NFC transceiver application 36 the entitlement 31 is present and valid for the second party.

[0037] FIG. 2 is a block diagram of a system including the first user device 30, a second user device 50, and an access device 60. FIG. 2 illustrates the debugging and testing an HCE application 44 and an SDK 42 using a proxy device for card emulation, according to certain embodiments. The configuration in FIG. 2 may be used when an entitlement is not available, or an entitlement is present but not valid. Because an entitlement for the first user device 30 is not available or not valid, the NFC transceiver application cannot communicate with the NFC interface in the first user device 30.

[0038] For example, as noted above, an entitlement may only allow NFC interface access in the European Economic Area while the development of the HCE (host card emulation) application is executed in the United States and testing is executed in another country such as Singapore. Also, in certain situations, a party who develops an application (e.g., an HCE application) and SDK (e.g., software application) may not want to directly call the hardware API of the operating system (OS) running on the mobile device. For example, an application such as an HCE application and a corresponding SDK may not yet be compatible with the hardware API or may have other issues with the hardware API.

[0039] As noted above, the debugging and testing of the HCE SDK 32 in the first user device 30, which may be a first smartphone, may be performed via a proxy device, which can be a second user device 50. The second user device 50 can be a second smartphone. The second user device 50 can include a socket server such as an APDll socket server 52 capable of communicating with an NFC interface (e.g., the second NFC API and hardware 56) on the same second user device 50 without the need for an entitlement. The second user device 50 can be developed by a fourth party (i.e., another mobile phone developer or manufacturer). In some embodiments, the first user device 30 and the second user device 50 can have different operating systems, different NFC hardware, and/or different APIs. For example, the first user device 30 can use an iOS™ operating system, while the second user device 50 can use an Android™ operating system. Thus, the second user device 50 may not have the same entitlement requirements as the first user device 30.

[0040] A method for debugging and testing the HCE SDK 32 on the first user device 30 via the second user device 50 with a socket server such as the APDll socket server 52, is described below. A socket server can be a server application that listens to a specific port waiting for connection requests from a client such as the first user device 30. When a connection request arrives, the first user device 30 and the second user device 50 establish a dedicated connection (e.g., an Internet connection) over which they can communicate. During the connection process, the first user device 30 can be assigned a local port number, and binds a socket to it. The first user device 30 talks to the second user device 50 by writing to the socket and getting information from the second user device 50 by reading from it.

[0041] At step 1 , the NFC transceiver application 36 running on the first user device 30 determines that that the entitlement to access the first NFC API and hardware 38 is missing or invalid. Therefore, the NFC transceiver application 36 may not call the first NFC API and hardware 38 to do card emulation for an NFC communication with the access device 40. The NFC API may be a first NFC API and the NFC hardware may be first NFC hardware. [0042] At step 2, the first user device and the second user device form a data connection. More specifically, the NFC transceiver application 36 then communicates with the APDll socket server 52 running on the second user device 50 via a network connection (e.g., an Internet connection using TCP/IP) using a pre-configured credential (e.g., IP address, port number, user name, password, certificate, etc.). The NFC transceiver application 36 can communicate with the second user device 50 via a network interface and/or long range communication antenna in the first user device 30 that is different from the first NFC hardware in the first NFC API and hardware 38. The second user device 50 can have a device NFC system API 54 and a second NFC API and hardware.

[0043] At step 3, once connected, the APDll socket server 52 running on the second user device 50 can start a card emulation session by calling the second NFC API and hardware 56 via the device NFC system API 54. In this case, the NFC transceiver application 36 and/or the APDll socket server 52 does not have to have entitlement before access to the second NFC API and hardware 56 is permitted. This is because the operating system of the second user device 50 may not have the same entitlement requirements as the operating system in the first user device 30.

[0044] At step 4, a developer or a tester taps the second user device 50 to the access device 40, or otherwise places the second user device 50 near the access device 40 (e.g., within 1 cm) for debugging and testing.

[0045] At step 5, the second user device 50 establishes an NFC communication with the access device 40. Then, one or more communications between the HCE SDK 32 in the HCE application 34 in the first user device 30 and the access device 40 are then passed via the NFC transceiver application 36, and the APDU socket server 52, the device NFC system API 54, and the second NFC second NFC API and hardware 56 in the second user device 50. The communications between the HCE SDK 32 and the access device 40 may be recorded by the HCE SDK 32, the access device 40, or a separate analysis computer in communication with the first user device 30 and/or the access device 40. The recorded data can be later analyzed for development or repair of the software.

[0046] At step 6, during some of the communications or message exchanges between the first user device 30 and the access device 40, the access device 40 sends APDll commands to the second user device 50, which is in card emulation mode. Examples of APDll commands include, but are not limited to the following: SELECT PPSE, SELECT AID, GET PROCESSING OPTIONS, and READ RECORD.

[0047] At step 7, the NFC API and hardware 56 sends the received APDU commands to the APDU socket server 52 via the device NFC system API 54 on the second user device 50.

[0048] At step 8, the APDU socket server 52 forwards the received APDU commands to the NFC transceiver application 36 on the first user device 30 via the established network connection.

[0049] At step 9, the NFC transceiver application 36 sends the received APDU commands to the HCE SDK 32.

[0050] At step 10, responsive to receiving the APDU commands, the HCE SDK 32 returns APDU responses to the NFC transceiver application 36.

[0051] At step 11 , the NFC transceiver application 36 returns the APDU response to the APDU socket server 52 on the second user device 50 via the established network connection.

[0052] At step 12, the APDU socket server 52 returns the APDU responses to the NFC API and hardware 56 of the second user device 50 via the device NFC system API 54.

[0053] At step 13, the second user device 50 returns the APDU responses to the access device 40.

[0054] In embodiments of the invention, steps 1 -13 can be repeated as many times as desired to facilitate testing. In some embodiments, hundreds or thousands of transaction scenarios can be run to determine if the HCE SDK 32 and the access device 40 are interacting as expected. Errors or other performance output data can be gathered and stored by the first user device 30, the access device 40, or an analysis computer (not shown) in communication with the first user device 30 or the access device 40 for later analysis. [0055] In some embodiments, the APDll socket server 52 in the second user device 50 may include, but is not limited to, the following commands: runSocketServer(), lncomingHandler(), and processCommandApdu().

[0056] As mentioned above, the NFC transceiver application 36 in the first user device 30 can communicate with the access device 40 if entitlement is present in the first user device, as discussed in FIG. 1 , or without an entitlement, as discussed in FIG. 2. In some embodiments, the NFC transceiver application 36 may be developed with three possible options.

[0057] In a first option, called auto-detection mode, the NFC transceiver application 36 reads the entitlement eligibility indicator from the first user device 30. If the indicator is true, then the NFC transceiver application 36 uses the NFC API and hardware 38 in the first user device 30 for card emulation as described above with respect to FIG. 1 . Otherwise, it uses a proxy device such as the second user device 50 for card emulation as described above with respect to FIG. 2.

[0058] In a second option, which may be characterized as a manual configuration mode, the NFC transceiver application 36 reads a configuration in the HCE application 34 (e.g., database entry, JSON file), to determine whether to use the NFC API and hardware 38 or a proxy device (e.g., the second user device 50) for card emulation.

[0059] In a third option, involving recompilation of the HCE application 34, there can be two classes, class A and class B. Class A implements the NFC transceiver application 36 using the NFC API and hardware 38 for card emulation. Class B causes the NFC transceiver application to communicate with a proxy device such as the second user device 50 for card emulation. The HCE application 34 can choose to compile with an SDK with Class A in a product scenario or with an SDK with Class B in testing scenario.

[0060] Based on the three options described above, an example operation of NFC transceiver logic is shown below. For example, in auto-detection mode, during a first step, the NFC transceiver application 36 on the first user device 30 (e.g., an iOS device) may verify if the first user device 30 is eligible to use CardSession (i.e., whether the indicator is true or false) based on its location by performing the following three sub-steps: Check NFCReaderSession.readingAvailable to ensure that the device supports card sessions with NFC.

Check CardSession. isSupported to ensure that the device supports card sessions with NFC.

Check CardSession. isEligible to verify that the system supports card session use in the current environment.

[0061] If all values in the above three sub-steps are true (i.e. , an entitlement is available), the processing for NFC transceiver application 36 proceeds to a second step using the first user device 30 CardSession APIs for card emulation by performing the following sub-steps: a. Create a card session over events from the session’s eventstream.

NFCPresentmentlntentAssertion.acquire()

CardSession() b. Start the session to acquire necessary system resources.

CardSession. Event.sessionStarted c. The application acquires the NFC resource, and the device detects the RF field of an NFC reader.

CardSession. Event. readerDetected() d. Start card emulation on the first detection of an external reader (e.g., in an access device) and be ready to handle APDlls from the reader.

CardSession. startEmulation() e. After starting emulation, the reader can communicate with the emulated card in the first user device 30, and emulation triggers the system. f. Begin receiving and processing APDlls from the event stream. g. Process the APDll payload in each event, generate a response, and send it with a response. h. If the reader disconnects, this may be because of the device moving away from the reader.

CardSession. Event. readerDeselected() i. Stop card emulation. This shuts down the RF interface and cuts off the RF connection with a reader.

CardSession. startEmulation() j. Clean up system resources. invalidate()

[0062] If any of the conditions in the sub-steps of the first step return false, the processing for NFC transceiver application proceeds to a third step using a proxy device such as the second user device 50 with the APDll socket server 52 running on the second user device 50 (e.g., an Android device) to perform card emulation, by performing the following sub-steps: a. Establish socket connection. b. Once sockets are connected, the second user device starts card emulation. c. Tap the second user device to contactless access device. d. Contactless access device sends APDll commands to the second user device. e. The second user device’s APDll socket server 52 forwards the APDU commands to the first user device 30 using the socket server connection. f. The APDU socket server 52 and NFC transceiver application 36 call the HCE SDK 32 and forward APDU commands. g. The HCE SDK 32 returns APDU responses to the NFC transceiver application 36 and the APDU socket server 52. h. The APDU socket server 52 on the second user device 50 returns the APDU responses to the contactless access device 40. [0063] FIG. 3 illustrates a user device 300 according to an embodiment. User device 300 may include device hardware 304 coupled to a system memory 302.

[0064] Device hardware 304 may include a processor 306, a short range antenna 314, a long range antenna 316, input elements 310, a user interface 308, and output elements 312 (which may be part of the user interface 308). Examples of input elements may include microphones, keypads, touchscreens, sensors, etc. Examples of output elements may include speakers, display screens, and tactile devices. The processor 306 can be implemented as one or more integrated circuits (e.g., one or more single core or multicore microprocessors and/or microcontrollers), and is used to control the operation of user device 300. The processor 306 can execute a variety of programs in response to program code or computer-readable code stored in the system memory 302, and can maintain multiple concurrently executing programs or processes.

[0065] The long range antenna 316 may include one or more RF transceivers and/or connectors that can be used by user device 300 to communicate with other devices and/or to connect with external networks. The user interface 308 can include any combination of input and output elements to allow a user to interact with and invoke the functionalities of user device 300. The short range antenna 809 may be configured to communicate with external entities through a short range communication medium (e.g., using Bluetooth, Wi-Fi, infrared, NFC, etc.). The long range antenna 819 may be configured to communicate with a remote base station and a remote cellular or data network, over the air.

[0066] The system memory 302 can be implemented using any combination of any number of non-volatile memories (e.g., flash memory) and volatile memories (e.g., DRAM, SRAM), or any other non-transitory storage medium, or a combination thereof media. The system memory 302 may store computer code, executable by the processor 306, for performing any of the functions described herein.

[0067] For example, the computer readable medium may comprise code, executable by the processor 306 to perform a method comprising: determining, by the first user device comprising the software application, that a transceiver application on the first user device is unable to communicate with a first near field communication (NFC) application programming interface (API) associated with a first NFC hardware in the first user device; forming a data connection between the first user device and a second user device with a second NFC API associated with a second NFC hardware in the second user device; and conducting one or more interactions between the software application and an access device via the second user device and the second NFC API associated with the second NFC hardware, wherein the second user device communicates with the access device via near field communications (NFC).

[0068] In another example, the computer readable medium may comprise code, executable by the processor 306 to perform a method comprising: forming a data connection between a first user device and a second user device with a second NFC API associated with a second NFC hardware in the second user device, after the first user device determines that an application comprising a transceiver application on the first user device is unable to communicate with a first near field communication (NFC) application programming interface (API) associated with a first NFC hardware in the first user device; and performing one or more NFC interactions with an access device using the second NFC API associated with the second NFC hardware in the second user device while communicating with the application in the first user device.

[0069] The system memory 302 may also store a transaction initiation module 302A, an application 302B (e.g., an HCE application comprising an SDK and an NFC transceiver module), an authentication module 302C, credentials/tokens 302D, a communication module 302E, a socket server 302F, an NFC hardware API 302G, and an operating system 302H, The transaction initiation module 302A may include instructions or code initiating and conducting a transaction with an external device such as an access device or a processing computer. It may include code, executable by the processor 306, for forming a local connection or otherwise interacting with an external access device. The application 302B can allow a user to perform unique functions using the user device 300. For example, the application 302B can be the above-described HCE application with the SDK and the NFC transceiver application. The authentication module 302C may comprise code, executable by the processor 306, to authenticate a user. This can be performed using user secrets (e.g., passwords) or user biometrics. The communication module 302E can comprise code, executable by the processor 306 to perform communication functions. The socket server 302F and the NFC hardware API 302G are described above. The operating system 302H can include or not include one or more entitlements to use an NFC interface in the user device 300.

[0070] FIG. 4 shows a block diagram showing components in an exemplary access device 400. The access device 400 may comprise a processor 402. It may also comprise a computer readable medium 404, a short range communication interface 406, a long range communication interface 414, and a data storage 410 operationally coupled to the processor 402. The computer readable medium 404 may store code or instructions for allowing access device 400 to operate in the manner described herein.

[0071] The computer readable medium 404 may further comprises one or more APIs 404A, a transaction authorization module 404B, an authentication module 404C, and a cryptography module 404D. The APIs 404A may comprise software which will allow the access device 400 to communicate with an external computer. The transaction authorization module may comprise software, executable by the processor 402, to perform authorization processing. The authentication module 404C may comprise code, executable by the processor 402, to authenticate users or user devices. The cryptography module 404D may comprise code, executable by the processor 402, to perform cryptographic operations.

[0072] Any of the software components or functions described in this application may be implemented as software code to be executed by a processor using any suitable computer language such as, for example, Java, C, C++, C#, Objective-C, Swift, or scripting language such as Perl or Python using, for example, conventional or object-oriented techniques. The software code may be stored as a series of instructions or commands on a computer readable medium for storage and/or transmission, suitable media include random access memory (RAM), a read only memory (ROM), a magnetic medium such as a hard-drive or a floppy disk, or an optical medium such as a compact disk (CD) or DVD (digital versatile disk), flash memory, and the like. The computer readable medium may be any combination of such storage or transmission devices.

[0073] Such programs may also be encoded and transmitted using carrier signals adapted for transmission via wired, optical, and/or wireless networks conforming to a variety of protocols, including the Internet. As such, a computer readable medium according to an embodiment of the present invention may be created using a data signal encoded with such programs. Computer readable media encoded with the program code may be packaged with a compatible device or provided separately from other devices (e.g., via Internet download). Any such computer readable medium may reside on or within a single computer product (e.g., a hard drive, a CD, or an entire computer system), and may be present on or within different computer products within a system or network. A computer system may include a monitor, printer, or other suitable display for providing any of the results mentioned herein to a user.

[0074] The above description is illustrative and is not restrictive. Many variations of the invention will become apparent to those skilled in the art upon review of the disclosure. The scope of the invention should, therefore, be determined not with reference to the above description, but instead should be determined with reference to the pending claims along with their full scope or equivalents.

[0075] One or more features from any embodiment may be combined with one or more features of any other embodiment without departing from the scope of the invention.

[0076] As used herein, the use of "a," "an," or "the" is intended to mean "at least one," unless specifically indicated to the contrary.

Claims

WHAT IS CLAIMED IS:

1 . A method of testing a software application on a first user device, the method comprising: determining, by the first user device comprising the software application, that a transceiver application on the first user device is unable to communicate with a first near field communication (NFC) application programming interface (API) associated with a first NFC hardware in the first user device; forming a data connection between the first user device and a second user device with a second NFC API associated with a second NFC hardware in the second user device; and conducting one or more interactions between the software application and an access device via the second user device and the second NFC API associated with the second NFC hardware, wherein the second user device communicates with the access device via near field communications (NFC).

2. The method of claim 1 , wherein the second user device comprises a socket server, which communicates with the transceiver application in the data connection, wherein the data connection is a network connection.

3. The method of claim 1 , wherein determining that the transceiver application on the first user device is unable to communicate with the first NFC API is a result of lacking permission to access the first NFC API.

4. The method of claim 1 , wherein the data connection is an Internet data connection.

5. The method of claim 1 , wherein the first user device is a first smartphone and the second user device is a second smartphone.

6. The method of claim 5, wherein the first user device and the second user device have different operating systems, APIs, and/or NFC hardware.

7. The method of claim 1 , wherein the software application comprises an SDK (software development kit) and the transceiver application, the transceiver application being an NFC transceiver application.

8. The method of claim 1 , wherein the second user device comprises an APDll socket server, which communicates with the transceiver application in the data connection, wherein the data connection is a network connection.

9. The method of claim 1 , wherein the one or more interactions are test interactions designed to test the software application on the first user device.

10. The method of claim 1 , wherein the one or more interactions involve the transmission and receipt of one or more APDll commands and APDll responses.

11. A first user device comprising: a processor; and a computer readable medium comprising code, executable by the processor for performing a method comprising: determining, by a software application on the first user device, that a transceiver application on the first user device is unable to communicate with a first near field communication (NFC) application programming interface (API) associated with a first NFC hardware in the first user device; forming a data connection between the first user device and a second user device with a second NFC API associated with a second NFC hardware in the second user device; and conducting one or more interactions between the software application and an access device via the second user device and the second NFC API associated with the second NFC hardware, wherein the second user device communicates with the access device via near field communications (NFC).

12. The first user device of claim 11 , wherein determining that the transceiver application on the first user device is unable to communicate with the first NFC API is a result of lacking permission to access the first NFC API.

13. The first user device of claim 11 , wherein the data connection is an Internet data connection.

14. The first user device of claim 11 , wherein the software application comprises an SDK (software development kit).

15. The first user device of claim 11 , wherein the first user device is a smartphone.

16. The first user device of claim 11 , wherein the one or more interactions involve the transmission and receipt of one or more APDll commands and APDll responses.

17. A method comprising: forming a data connection between a first user device and a second user device with a second NFC API associated with a second NFC hardware in the second user device, after the first user device determines that an application comprising a transceiver application on the first user device is unable to communicate with a first near field communication (NFC) application programming interface (API) associated with a first NFC hardware in the first user device; and performing one or more NFC interactions with an access device using the second NFC API associated with the second NFC hardware in the second user device while communicating with the application in the first user device.

18. The method of claim 17, wherein the data connection is an Internet data connection.

19. The method of claim 17, wherein the application also comprises a software development kit (SDK).

20. The method of claim 17, wherein the first user device is a first smart phone and the second user device is a second smart phone.