Communication processing device, communication processing system, communication control method, and program

Abstract

The present invention allows a user terminal, such as a smartphone, having a plurality of IC card applications to perform a settlement process with a settlement device such as a ticket gate or a store terminal, the settlement process using data for communication other than NFC communication, such as UWB communication. A settlement terminal transmits, to a user terminal, a select command specifying a communication relay application of the user terminal as a communication partner. The communication relay application of the user terminal stores, in a select response to the select command, a protocol parameter including a unique identifier of an effective application for executing a settlement process via communication with the settlement terminal, and transmits the select response to the settlement terminal. The settlement terminal uses the protocol parameter including the unique identifier of the effective application to execute communication with the effective application, thereby executing the settlement process.

Description

Communications processing device, communications processing system, communications control method, and program

[0001] The present disclosure relates to a communication processing device, a communication processing system, a communication control method, and a program, and more particularly to a communication processing device, a communication processing system, a communication control method, and a program that enable communication between an IC card app installed on a user terminal such as a smartphone and a payment terminal via various communication paths such as UWB communication to perform payment processing and the like.

[0002] In recent years, the use of mobile devices such as smartphones with cashless payment functions has been expanding. By using a mobile device with cashless payment functions, it becomes possible to easily pay for purchases, meals, etc., or ride trains and buses without carrying cash.

[0003] For example, when passing through a ticket gate at a station, a user takes out a user terminal such as a smartphone from their pocket or bag and holds it over a reader / writer (R / W) attached to the ticket gate, and the user terminal and the reader / writer at the ticket gate perform near-field communication to perform the payment process.

[0004] Currently, most communications between user terminals such as smartphones and reader / writers (R / W) are performed in accordance with the NFC (Near Field Communication) standard, which is one of the short-range wireless communication standards.

[0005] The NFC standard is further subdivided into several different sub-standards, such as Type A, Type B, and Type-F. Type-F is a communications standard used by FeliCa (registered trademark), a contactless IC card technology developed by Sony, and is widely used for communications between various electronic money IC cards, user terminals such as smartphones with IC card apps installed, and reader / writers (R / W).

[0006] Type-F NFC communication uses commands specific to Type-F. By using these Type-F commands, even if multiple different IC card apps are installed on a user device such as a smartphone, it is possible to select one IC card app from the installed apps and make a payment.

[0007] Specifically, for example, when a user terminal on which two applications, a transportation IC card application and a distribution IC card application, are installed is held close to a reader / writer (R / W) at a railway ticket gate, the reader / writer (R / W) at the railway ticket gate will send a Type-F specific command to the user terminal.

[0008] Based on the results of this command analysis, the user terminal selects a transportation IC card application that performs the payment processing required to pass through the railway ticket gate, and then performs communication and payment processing between the selected transportation IC card application and the reader / writer (R / W) at the railway ticket gate. In this way, the selection and application processing of the IC card application is realized by using Type-F specific commands.

[0009] However, these Type-F specific commands have been standardized as commands that can be used in NFC communication, and have not been standardized for use in other communication methods.

[0010] For example, the Type-F specific commands cannot be used in UWB (Ultra Wide Band) communication, which is an ultra-wideband wireless communication, or in BLE (Bluetooth Low Energy) communication, which is a low-power consumption Bluetooth (registered trademark) communication.

[0011] Therefore, even if a user terminal and a payment terminal (R / W) at a ticket gate, store, etc. attempt to perform payment processing using UWB communication or BLE communication other than NFC communication, there is a problem in that the user terminal cannot select the correct IC card application that corresponds to the payment terminal from the multiple IC card applications installed on the user terminal and perform payment processing, because this is not defined as a standard function.

[0012] UWB communication and BLE communication have a wider communication range than NFC communication, so that, for example, wireless communication can be performed between a user terminal and the ticket gate R / W when the user passes through a ticket gate without having to take out the user terminal, such as a smartphone, from their pocket or bag. This type of payment system is called a touchless payment system.

[0013] Conventional technologies that disclose touchless payment systems include, for example, Patent Document 1 (International Publication No. WO2019 / 049623) and Patent Document 2 (US Patent No. US8856045).

[0014] However, as mentioned above, Type-F specific commands that enable selection of one app from multiple IC card apps have the problem that they cannot smoothly perform touchless payments using UWB communication or BLE communication, as their use with communication standards other than NFC communication is not defined as a standard specification.

[0015] The present applicant previously filed a patent application in Patent Document 3 (International Publication No. WO 2022 / 064878) as a configuration for solving this problem. Patent Document 3 discloses a configuration in which, when a user terminal receives UWB communication data from a payment terminal (R / W) at a ticket gate, a store, or the like, a UWB communication-compatible app on the user terminal searches whether an IC card app capable of processing payments via UWB communication is stored in the user terminal, and performs processing based on the search results.

[0016] When an IC card application capable of processing payments via UWB communication is detected in a user terminal, the UWB communication-compatible application acquires the ID of the IC card application and notifies the payment terminal. The payment terminal then communicates with the IC card application using the acquired ID to perform the payment.

[0017] However, this configuration requires a UWB communication compatible application on the user terminal to perform search processing and notification processing of search results, and there is a possibility that processing delays will occur due to these new data processing and communication processing.

[0018] International Publication No. WO2019 / 049623 U.S. Patent No. US8856045 International Publication No. WO2022 / 064878

[0019] The present disclosure has been made in consideration of the above-mentioned problems, for example, and aims to provide a communication processing device, a communication processing system, a communication control method, and a program that make it possible to select an IC card app corresponding to the payment terminal and quickly process payments, etc., even when using communication other than NFC communication.

[0020] A first aspect of the present disclosure is a communication processing device having a communication relay application that generates and transmits a response packet in response to a received packet from an external device, the response packet storing protocol parameters including a unique identifier of an IC card application that communicates with the external device and performs data processing.

[0021] Furthermore, a second aspect of the present disclosure is a communication processing system having a user terminal and a payment terminal, wherein the payment terminal transmits a select command to the user terminal specifying the communication relay app of the user terminal as a communication partner, the communication relay app of the user terminal stores a protocol parameter including a unique identifier of a valid app that executes payment processing by communicating with the payment terminal in a select response to the select command and transmits the response to the payment terminal, and the payment terminal is in a communication processing system that communicates with the valid app using the protocol parameter including the unique identifier of the valid app to execute payment processing.

[0022] Furthermore, a third aspect of the present disclosure is a communication control method executed in a communication processing device, wherein the communication processing device has a communication relay application that executes relay processing of communication data according to a UWB (Ultra Wide Band) communication method, and the communication relay application generates and transmits a response packet that stores protocol parameters including a unique identifier of an IC card application that communicates with the external device and executes data processing in response to a packet received from the external device.

[0023] Furthermore, a fourth aspect of the present disclosure is a communication control method executed in a communication processing system having a user terminal and a payment terminal, in which the payment terminal transmits a select command to the user terminal specifying the communication relay app of the user terminal as a communication partner, the communication relay app of the user terminal stores a protocol parameter including a unique identifier of a valid app that executes payment processing by communication with the payment terminal in a select response to the select command and transmits the response to the payment terminal, and the payment terminal communicates with the valid app using the protocol parameter including the unique identifier of the valid app to execute payment processing.

[0024] Furthermore, a fifth aspect of the present disclosure is a program for causing a communication processing device to execute communication processing, wherein the communication processing device has a communication relay application that executes relay processing of communication data according to a UWB (Ultra Wide Band) communication method, and the program causes the communication relay application to execute processing to generate and transmit a response packet that stores protocol parameters including a unique identifier of an IC card application that communicates with and processes data with the external device in response to a received packet from the external device.

[0025] The program of the present disclosure is, for example, a program that can be provided in a computer-readable format via a storage medium or a communication medium to an information processing device or a computer system capable of executing various program codes. By providing such a program in a computer-readable format, processing according to the program is realized on the information processing device or the computer system.

[0026] Further objects, features, and advantages of the present disclosure will become apparent from the following detailed description of the embodiments of the present disclosure and the accompanying drawings. Note that in this specification, a system refers to a logical collective configuration of multiple devices, and is not limited to devices that are located within the same housing.

[0027] According to one embodiment of the present disclosure, a configuration is realized that enables a user terminal, such as a smartphone, having multiple IC card apps to perform payment processing with a payment device, such as a ticket gate or store terminal, using communication data other than NFC, such as UWB communication. Specifically, for example, the payment terminal sends a select command to the user terminal specifying the user terminal's communication relay app as the communication partner, and the user terminal's communication relay app stores a protocol parameter including a unique identifier of a valid app that executes payment processing via communication with the payment terminal in a select response to the select command and sends the response to the payment terminal. The payment terminal communicates with the valid app using the protocol parameter including the unique identifier of the valid app to execute the payment processing. This configuration realizes a configuration that enables a user terminal, such as a smartphone, having multiple IC card apps to perform payment processing with a payment device, such as a ticket gate or store terminal, using communication data other than NFC, such as UWB communication. Note that the effects described in this specification are merely exemplary and are not limiting, and additional effects may also be present.

[0028] 1 is a diagram illustrating an example of an IC card application stored in a user terminal. FIG. 1 is a diagram illustrating an example of the configuration of a secure element (SE) inside a user terminal. FIG. 2 is a diagram illustrating an example of the configuration of a user terminal and a payment terminal that perform payment processing via NFC communication. FIG. 3 is a diagram illustrating an example of the software stack of a secure element of a user terminal. FIG. 4 is a diagram illustrating an example of the configuration of a user terminal and a payment terminal of the present disclosure. FIG. 5 is a diagram illustrating an example of the software stack of a secure element of a user terminal of the present disclosure. FIG. 6 is a diagram illustrating an example of an IC card application stored in a user terminal of the present disclosure and example of attribute information of the IC card application. FIG. 7 is a diagram illustrating example attribute information of a UWB communication relay application in a user terminal of the present disclosure. FIG. 8 is a diagram illustrating an example of a correspondence relationship between an IC card application and a UWB communication relay application stored in a user terminal of the present disclosure. FIG. 9 is a diagram illustrating an example of a service-compatible valid application registration table stored in a memory in a user terminal of the present disclosure. FIG. 10 is a diagram illustrating an example of setting a service-compatible valid application. FIG. 11 is a sequence diagram illustrating a processing sequence of a process executed by a user terminal of the present disclosure. FIG. 12 is a sequence diagram illustrating a processing sequence of a process executed by a user terminal of the present disclosure. FIG. 10 is a diagram illustrating an example of the data configuration of a select command sent from a payment terminal to a user terminal. FIG. 11 is a diagram illustrating an example of the data configuration of a select response sent from a user terminal to a payment terminal. FIG. 12 is a sequence diagram illustrating a processing sequence of a process executed by a user terminal of the present disclosure. FIG. 13 is a diagram illustrating an example of the configuration of packets transmitted and received between a payment terminal and a user terminal. FIG. 14 is a sequence diagram illustrating a processing sequence of a process executed by a user terminal of the present disclosure. FIG. 15 is a sequence diagram illustrating a processing sequence of a process executed by a user terminal of the present disclosure. FIG. 16 is a sequence diagram illustrating a processing sequence of a process executed by a user terminal of the present disclosure.Fig. 1 is a diagram illustrating a specific example of processing executed between a user terminal and a payment terminal of the present disclosure. Fig. 2 is a diagram illustrating a specific example of processing executed between a user terminal and a payment terminal of the present disclosure. Fig. 3 is a diagram illustrating a specific sequence example of processing executed between a user terminal and a payment terminal of the present disclosure. Fig. 4 is a diagram illustrating a specific sequence example of processing executed between a user terminal and a payment terminal of the present disclosure. Fig. 5 is a diagram illustrating a flowchart illustrating a processing sequence of processing executed by a user terminal of the present disclosure. Fig. 6 is a diagram illustrating an example of the hardware configuration of a communication processing device that constitutes a user terminal or a payment terminal.

[0029] The following describes in detail the communication processing device, communication processing system, communication control method, and program of the present disclosure with reference to the drawings. The description will be made according to the following items: 1. Example of usage configuration of IC card app in user terminal 2. Overview of IC card app selection and payment processing using Type-F commands in NFC communication 3. Example configuration and processing of communication processing device of the present disclosure 4. Example configuration of apps in a secure element of a communication processing device (user terminal) of the present disclosure 5. Sequence of processing executed by a communication processing device of the present disclosure 5-(1) Registration processing sequence of a service-compatible enabled app 5-(2) Communication sequence between a service-compatible UWB communication relay app of a user terminal and a payment terminal 5-(3) Communication sequence between a service-compatible enabled app (enabled IC card app) of a user terminal and a payment terminal 5-(4) Communication sequence when there is only one service-compatible enabled app (enabled IC card app) of a user terminal 6. Configuration for preventing duplicate payment processing by an NFC communication unit and a UWB communication unit 7. 7. Processing sequence when a communication processing device (user terminal) according to the present disclosure receives a select command (SELECT command) from a payment terminal 8. Example hardware configuration of a communication processing device 9. Summary of the configuration according to the present disclosure

[0030] [1. Example of a configuration for using an IC card application in a user terminal] First, an example of a configuration for using an IC card application in a user terminal will be described.

[0031] Nowadays, various IC card applications are installed and used on user terminals such as smartphones. There are various types of IC card applications, such as electronic money applications, transportation IC card applications, and distribution IC card applications issued by supermarkets and the like.

[0032] FIG. 1 is a diagram showing an example of IC card applications installed on a user terminal 10 of a certain user. As shown in FIG. 1, a plurality of different IC card applications are installed on the user terminal 10, such as a smartphone. FIG. 1 shows an example in which the following four types of IC card applications are installed: Transportation IC card A application 11A Transportation IC card B application 11B Distribution IC card P application 11P Distribution IC card Q application 11Q

[0033] These are IC card apps provided by different service providers. A user performs near-field communication by bringing a user terminal 10, such as a smartphone, close to a reader / writer installed at a store or ticket gate managed by each service provider. The reader / writer performs a process to deduct a predetermined fee from the charge recorded in the memory of the user terminal 10 or from a pre-linked bank account or a managed account of a credit card company. In other words, it rewrites the charge amount, etc.

[0034] These IC card applications are installed, for example, in a secure element (SE) configured in the user terminal 10, and record secure data such as balance information corresponding to each IC card application in a secure memory configured in the secure element (SE), and further perform processes such as updating the balance information in accordance with payment processes, etc.

[0035] Fig. 2 shows an example of the configuration of a secure element (SE) 20 configured within the user terminal 10. As shown in Fig. 2, the secure element (SE) 20 has multiple IC card applications 11 described with reference to Fig. 1 and a secure memory 22 that records balance information and the like corresponding to each IC card application.

[0036] The example shown in Figure 2 is an example of a secure memory 22 in which four electronic money balance record areas are set corresponding to the four IC card applications described with reference to Figure 1. The electronic money A balance record area 22A is a balance information record area corresponding to the transportation IC card A application 11A. The electronic money B balance record area 22B is a balance information record area corresponding to the transportation IC card B application 11B. The electronic money P balance record area 22P is a balance information record area corresponding to the distribution system IC card P application 11P. The electronic money Q balance record area 22Q is a balance information record area corresponding to the distribution system IC card Q application 11Q.

[0037] In this way, the user terminal 10 has a secure memory 22 in which an electronic money balance recording area is set up in which balance information corresponding to the IC card applications provided by each service provider is individually recorded.

[0038] When a user brings a user terminal 20 such as a smartphone close to a reader / writer installed at a store or ticket gate managed by each service provider, the reader / writer executes a process to rewrite the balance information in the balance recording area corresponding to the service provider. This process allows a predetermined usage fee to be reduced, a charge to be made, etc. These processes are performed on a service provider basis.

[0039] [2. Overview of IC card application selection and payment processing using Type-F commands in NFC communication] Next, an overview of IC card application selection and payment processing using Type-F commands in NFC communication, which is currently widely used, will be described.

[0040] 3 is a block diagram showing an example configuration of a user terminal 10 such as a smartphone and a payment terminal 50. The payment terminal 50 is a device including a reader / writer (R / W) installed, for example, at a ticket gate at a station or in a store, and performs near-field communication with the user terminal 10 such as a smartphone to perform payment processing.

[0041] A user terminal 10 such as a smartphone and a payment terminal 50 perform wireless communication in accordance with the Type-F standard of the NFC (Near Field Communication) standard, which is one of the short-range wireless communication standards, to perform payment processing.

[0042] As mentioned above, the NFC standard is subdivided into several different sub-standards, such as Type A, Type B, and Type-F. Type-F is a communications standard used by FeliCa (registered trademark), a contactless IC card technology system developed by Sony.

[0043] 3, the user terminal 10 includes a secure element 20 and an NFC communication unit 31. The payment terminal 50 includes a payment terminal controller 51 and an NFC communication unit 52.

[0044] The secure element 20 of the user terminal 10 has a command analysis unit 32 and an IC card application group 33. The IC card application group 33 is made up of a plurality of IC card applications, and is made up of various IC card applications such as the transportation IC card applications and distribution IC card applications described with reference to Figures 1 and 2.

[0045] When the NFC communication unit 31 of the user terminal 10 and the NFC communication unit 52 of the payment terminal 50 come within a predetermined distance, for example, within a few centimeters, wireless communication is initiated between the communication units. That is, wireless communication is initiated in accordance with the NFC standard, which is one of the short-range wireless communication standards.

[0046] First, a polling signal is output from NFC communication unit 52 of payment terminal 50 under the control of payment terminal controller 51 of payment terminal 50. This polling signal is a signal for detecting a communication terminal with which to communicate. This polling signal includes Type-F specific commands defined in the above-mentioned Type-F standard.

[0047] When the NFC communication unit 31 of the user terminal 10 receives a polling signal including a Type-F unique command, it inputs the received signal to the command analysis unit 32 in the secure element 20. The command analysis unit 32 in the secure element 20 analyzes the polling signal including the Type-F unique command received from the payment terminal 50.

[0048] Command analysis unit 32 analyzes the Type-F specific command included in the polling signal and generates IC card application specification information (AID: Application ID) according to the type of payment terminal. For example, if analysis of the Type-F specific command reveals that payment terminal 50 is a ticket gate device for railway company A, command analysis unit 32 generates IC card application specification information (AID) for an IC card application that can be used for payment processing for railway company A. According to the analysis result of command analysis unit 32, one IC card application is selected from IC card application group 33 and launched.

[0049] Thereafter, the selected IC card application performs NFC communication with the payment terminal 50 via the NFC communication unit 31, and executes a series of processes required for the payment process, such as authentication processing, balance confirmation processing, usage fee debit processing, balance update processing, etc.

[0050] Fig. 4 is a diagram showing an example of a software stack of the secure element (SE) 20. As shown in Fig. 4, the software stack of the secure element (SE) 20 has a configuration in which a hardware (HW) layer is set at the bottom, a secure element OS (SE-OS) layer is set above that, and an application layer made up of various applications is set at the top.

[0051] The lowest hardware (HW) layer includes, for example, a secure memory within the secure element and a communication unit outside the secure element, that is, the NFC communication unit 31 shown in FIG.

[0052] 3 is located between the lowest hardware (HW) layer and the secure element OS (SE-OS) layer. That is, part of the processing of the command analysis unit 32 is executed in the hardware (HW) layer, and part is executed in the secure element OS (SE-OS) layer.

[0053] The top application layer is made up of various IC card applications a to n included in the IC card application group 33 shown in Fig. 3. The IC card applications a to n in the top application layer access the secure memory in the secure element and the communication unit outside the secure element via the secure element OS (SE-OS) layer to update memory data and perform communication processing with external devices.

[0054] As described above, command analysis unit 32 receives and analyzes the polling signal including the Type-F unique command transmitted by payment terminal 50 via NFC communication unit 31. Command analysis unit 32 analyzes the Type-F unique command included in the polling signal and generates IC card application designation information (AID: Application ID).

[0055] The IC card application specification information (AID) generated by the command analysis unit 32 is passed to the secure element OS (SE-OS), and the secure element OS (SE-OS) selects and launches one IC card application from the application layer, which is the highest layer, that corresponds to the IC card application specification information (AID) generated by the command analysis unit 32.

[0056] Then, one selected IC card application performs NFC communication between the secure element OS (SE-OS) and the payment terminal 50 via the NFC communication unit 31, and executes a series of processes required for payment processing, such as authentication processing, balance confirmation processing, usage fee debit processing, balance update processing, etc.

[0057] As mentioned above, Type-F is a lower-level standard of the NFC standard used in FeliCa (registered trademark), a contactless IC card technology method developed by Sony, and is widely used in communications between various electronic money IC cards, user terminals such as smartphones with IC card apps installed, and reader / writers (R / W).

[0058] This Type-F NFC communication enables IC app selection processing by analyzing polling signals containing Type-F-specific commands. For example, when a user terminal on which both a transportation IC card app and a retail IC card app are installed is held close to a reader / writer (R / W) at a railway ticket gate, the command analysis unit 32 shown in FIG. 3 analyzes the polling signal containing Type-F-specific commands transmitted from the reader / writer (R / W) at the railway ticket gate to the user terminal. Based on the analysis results, a transportation IC card app that performs the payment processing required to pass through the railway ticket gate is selected, and communication and payment processing between the selected transportation IC card app and the reader / writer (R / W) at the railway ticket gate become possible.

[0059] 3 and 4 can analyze communication packets that comply with the communication packet format defined in the Type-F communication standard, which is a lower-level standard of the NFC communication standard, but cannot analyze packets with a different format. In other words, the command analysis unit 32 cannot analyze communication packets with a packet format different from the NFC-Type-F standard.

[0060] For example, UWB (Ultra Wide Band) communication, which is an ultra-wideband wireless communication, and BLE (Bluetooth Low Energy) communication, which is a low-power Bluetooth (registered trademark) communication, use communication packets in a format different from the packet format defined by the NFC Type-F communication standard. The command analysis unit 32 shown in FIG. 3 cannot analyze packets in such different formats.

[0061] Therefore, even if a user terminal and a payment terminal (R / W) at a ticket gate, store, etc. communicate using UWB communication or BLE communication other than NFC communication, it is not possible to select one IC card app from multiple IC card apps installed on the user terminal that corresponds to the type of payment terminal and perform processing.

[0062] Furthermore, since UWB communication and BLE communication have a wider communication range than NFC communication, it is possible to perform wireless communication between a user terminal and the ticket gate side R / W when the user passes through the ticket gate, for example, without the user having to take out the user terminal, such as a smartphone, that is in their pocket or bag.

[0063] The configuration of the present disclosure enables a user to select one IC card application from multiple IC card applications installed on a user terminal and perform processing, even when UWB communication or BLE communication other than NFC communication is used. The configuration and processing of the present disclosure will be described below.

[0064] 3. Configuration and Processing Example of a Communication Processing Device According to the Present Disclosure Next, a configuration and processing example of a communication processing device according to the present disclosure will be described.

[0065] FIG. 5 is a block diagram showing an example configuration of a user terminal 100 which is a communication processing device of the present disclosure, and a payment terminal 200 which communicates with the user terminal 100.

[0066] The payment terminal 200 is a device including a reader / writer (R / W) installed at, for example, a ticket gate at a station or in a store, and performs payment processing by performing near-field communication with a user terminal 100 such as a smartphone.

[0067] The user terminal 100, such as a smartphone, and the payment terminal 200 each have three different communication units. That is, the user terminal 100 shown in Fig. 5 has an NFC communication unit 111, a UWB communication unit 112, and a BLE communication unit 113. Similarly, the payment terminal 200 also has an NFC communication unit 211, a UWB communication unit 212, and a BLE communication unit 213.

[0068] As described with reference to FIG. 3, wireless communication is performed between the NFC communication unit 111 of the user terminal 100 and the NFC communication unit 211 of the payment terminal 200 in accordance with the Type-F standard of the NFC (Near Field Communication) standard, which is one of the short-range wireless communication standards.

[0069] Between the UWB communication unit 112 of the user terminal 100 and the UWB communication unit 212 of the payment terminal 200, UWB (Ultra Wide Band) communication, which is an ultra-wideband wireless communication, is performed.

[0070] UWB communication is a communication standard defined in IEEE 802.15.4z, and the allowable communication distance is, for example, approximately 10 meters. The UWB communication standard also defines a "secure ranging" method that analyzes device locations while maintaining security. "Secure ranging" is a technology that enables secure measurement of the distance and angle between communicating devices by sending and receiving encrypted data using a shared key.

[0071] When the user terminal 100 approaches within a UWB communication range (approximately 10 m), the payment terminal 200 detects the user terminal 100 via UWB communication and starts secure ranging of the user terminal 100, and then performs processing to continuously analyze the position of the user terminal 100. The specific processing sequence will be explained later.

[0072] BLE (Bluetooth Low Energy) communication, which is a low-power consumption type Bluetooth (registered trademark) communication, is executed between the BLE communication unit 113 of the user terminal 100 and the BLE communication unit 213 of the payment terminal 200.

[0073] The allowable communication distance for BLE communication varies slightly depending on the class, but is approximately several tens of meters. BLE communication is a communication method suitable for device detection, establishment of communication connections, and data communication within a range of several tens of meters. The BLE communication standard defines an ADV_IND packet (General Advertising Indication packet) as a broadcast packet for device detection.

[0074] When the user terminal 100 approaches within a BLE communication range (several tens of meters), the payment terminal 200 can detect the user terminal 100 through BLE communication and establish BLE communication with the user terminal 100.

[0075] 5 , the user terminal 100 has an NFC communication unit 111, a UWB communication unit 112, and a BLE communication unit 113, as well as these three communication units, a user terminal controller (DH: Device Host) 101, and a secure element 120. The payment terminal 200 has an NFC communication unit 211, a UWB communication unit 212, and a BLE communication unit 213, as well as these three communication units, and a payment terminal controller 201.

[0076] The secure element 120 of the user terminal 100 has an IC card application group 121 made up of multiple IC card applications, a command analysis unit 122, and a UWB communication relay application 123. The IC card application group 121 stores various IC card applications such as the transportation IC card applications and distribution IC card applications described with reference to Figures 1 and 2.

[0077] The NFC communication performed between the NFC communication unit 111 of the user terminal 100 and the NFC communication unit 211 of the payment terminal 200 is the same as the process described above with reference to Fig. 3. That is, when the NFC communication unit 111 of the user terminal 100 and the NFC communication unit 211 of the payment terminal 200 come close to each other within a predetermined distance, for example, several centimeters, wireless communication according to the NFC standard is started.

[0078] The user terminal 100 and payment terminal 200 shown in Figure 5 have a BLE communication unit and a UWB communication unit in addition to an NFC communication unit, and when the distance between the user terminal 100 and the payment terminal 200 is within a few meters to a few tens of meters, communication via these communication units becomes possible.

[0079] Even when UWB communication is used, the user terminal 100 of the present disclosure has a configuration that enables processing similar to the IC card application selection processing using Type-F specific commands used in NFC communication described with reference to Fig. 3. Specifically, the UWB communication relay application 123 in the secure element 120 of the user terminal 100 shown in Fig. 5 analyzes the UWB communication data transmitted from the payment terminal 200, enabling communication between the payment terminal 200 and an IC card application compatible with the payment terminal.

[0080] The UWB communication relay application 123 analyzes the UWB communication data (SELECT Command) sent from the payment terminal 200, selects an IC card application that will perform payment processing with the payment terminal 200, and sends a SELECT Response to the payment terminal 200 that stores protocol parameters including a unique identifier corresponding to the selected IC card application.

[0081] Thereafter, the payment terminal 200 communicates with the selected IC card application using a protocol parameter including the unique identifier of the selected IC card application stored in the select response received from the UWB communication relay application 123 of the user terminal 100, and executes the payment process.

[0082] The UWB communication relay application 123 of the user terminal 100 is configured by UWB communication relay applications for each service. That is, as shown in Fig. 5, it is configured by UWB communication relay applications for each service, such as a UWB communication relay application for service 1, a UWB communication relay application for service 2, ... a UWB communication relay application for service n.

[0083] The services are, for example, the following services: (A) Transportation Company A (Service 1) (B) Transportation Company B (Service 2) (C) Distribution Company C (Service 3) (D) Distribution Company D (Service 4) (E) Electronic Money Company E (Service 5)

[0084] For example, when the user terminal 100 communicates with the payment terminal of (A) transportation company A (service 1), the service 1 compatible UWB communication relay app 123-1 analyzes the UWB communication data sent from the payment terminal of transportation company A (service 1) and executes a process to select an IC card app from the IC card app group 121 that will perform payment processing for transportation company A (service 1).

[0085] In addition, when the user terminal 100 communicates with the payment terminal of (C) distribution company C (service 3), the service 3 compatible UWB communication relay app 123-3 analyzes the UWB communication data sent from the payment terminal of distribution company C (service 3) and executes a process to select an IC card app from the IC card app group 121 that will perform payment processing for distribution company C (service 3).

[0086] The details of the IC card application selection process and the payment process sequence using the UWB communication relay applications 123-1 to 123-n will be explained later.

[0087] Fig. 6 is a diagram showing an example of a software stack of the secure element (SE) 120 of the user terminal 100 shown in Fig. 5. As shown in Fig. 6, the software stack of the secure element (SE) 120 has a configuration in which a hardware (HW) layer is set at the bottom, a secure element OS (SE-OS) layer is set above that, and an application layer made up of various applications is set at the top.

[0088] The lowest hardware (HW) layer includes, for example, a secure memory within the secure element and a communication unit outside the secure element, that is, the NFC communication unit 111 and UWB communication unit 112 shown in FIG.

[0089] 5 is located between the lowest hardware (HW) layer and the secure element OS (SE-OS) layer. That is, part of the processing of the command analysis unit 122 is executed in the hardware (HW) layer, and part is executed in the secure element OS (SE-OS) layer.

[0090] The top application layer includes various IC card applications a to n included in IC card application group 121 shown in Fig. 5, and UWB communication relay application 123. As mentioned above, UWB communication relay application 123 is made up of UWB communication relay applications for each service. That is, as shown in Fig. 6, it is made up of UWB communication relay applications for each service, such as UWB communication relay application 123-1 for service 1 to UWB communication relay application 123-n for service n.

[0091] The IC card applications a to n in the top application layer and the service-compatible UWB communication relay applications 123-1 to n access the secure memory within the secure element and the communication unit outside the secure element via the secure element OS (SE-OS) layer to perform memory data update processing and communication processing with external devices.

[0092] The command analysis unit 122 of the secure element 120 shown in Fig. 5 analyzes a polling signal including a Type-F unique command received from the payment terminal 200 via the NFC communication unit 111, extracts IC card application designation information of the Type-F unique command, and selects and activates one IC card application from multiple IC card applications stored in the secure element 120. This processing is the same as that of the conventional configuration shown in Fig. 3.

[0093] 5, the UWB communication relay application 123 of the secure element 120 further analyzes the UWB communication data transmitted from the payment terminal 200 and executes an IC card application selection process. By performing this process, it becomes possible to perform payment processing via UWB communication before NFC communication can be started.

[0094] An outline of the communication sequence executed between user terminal 100 and payment terminal 200 shown in FIG. 5 will be described.

[0095] Payment terminal controller 201 of payment terminal 200 controls communication between each of the communication units, NFC communication unit 211, UWB communication unit 212, and BLE communication unit 213, of payment terminal 200. Payment terminal controller 201 first broadcasts an Advertise packet, which is a packet requesting user terminal detection and establishment of a BLE communication connection, from BLE communication unit 213. The BLE communication standard defines an ADV_IND packet (General Advertising Indication packet) as a broadcast packet for device detection.

[0096] When the user terminal 100 enters a BLE communication area and receives an advertising packet transmitted by the payment terminal 200, the user terminal 100 transmits a response packet including a user terminal identifier to the payment terminal 200. The payment terminal 200 detects the user terminal 100 by acquiring the user terminal identifier from the response packet transmitted by the user terminal 100.

[0097] When the user terminal is detected, the payment terminal 200 then starts a location identification process for the user terminal 100. The payment terminal controller 201 of the payment terminal 200 uses UWB (Ultra Wide Band) communication to perform the location identification process for the user terminal 100.

[0098] As mentioned above, UWB communication specifies a "secure ranging" method that analyzes device locations while maintaining security. "Secure ranging" is a technology that enables secure measurement of the distance and angle between communicating devices by sending and receiving encrypted data using a shared key.

[0099] When the payment terminal 200 detects a user terminal via BLE communication, it outputs a UWB communication signal to identify the location of the detected user terminal 100, establishes communication between the UWB communication unit 212 of the payment terminal 200 and the UWB communication unit 112 of the user terminal 100, and continuously performs the location identification process for the user terminal 100.

[0100] In secure ranging via UWB communication, UWB communication unit 212 of payment terminal 200 analyzes data on ToA (Time of Arrival) and AoA (Angle of Arrival). ToA (Time of Arrival) corresponds to the transmission and reception time of a UWB signal, and payment terminal controller 201 of payment terminal 200 analyzes the distance from payment terminal 200 to user terminal 100 based on this time.

[0101] AoA (Angle of Arrival) is angle information at which a transmission signal from user terminal 100 is input to payment terminal 200. Payment terminal controller 201 of payment terminal 200 analyzes the direction of user terminal 100 based on this angle. Payment terminal controller 201 of payment terminal 200 identifies the position of user terminal 100 by analyzing ToA and AoA.

[0102] After detecting the user terminal 100, the payment terminal controller 201 of the payment terminal 200 continues to execute the user terminal location identification process until the payment process starts or ends, for example, until the user passes through the ticket gate where the payment terminal 200 is installed.

[0103] In parallel with performing secure ranging via UWB communication, payment terminal controller 201 of payment terminal 200 selects an IC card application via UWB communication and communicates with the IC card application to perform payment processing and the like.

[0104] An overview of the sequence for selecting an IC card application via UWB communication and the communication process with the IC card application will be described below. First, payment terminal 200 initiates UWB communication with UWB communication relay application 123 in secure memory 120 of user terminal 100. For example, assume that payment terminal 200 is the payment terminal 200 of transportation company A (service 1). Payment terminal 200 of transportation company A (service 1) initiates UWB communication with service 1-compatible UWB communication relay application 123-1 in secure memory 120.

[0105] When UWB communication between the payment terminal 200 of transportation company A (service 1) and the service 1-compatible UWB communication relay app 123-1 of the user terminal 100 is successful, the service 1-compatible UWB communication relay app 123-1 of the user terminal 100 then refers to the service-compatible valid app registration table stored in the memory of the user terminal 100.

[0106] The service-compatible valid application registration table stores information about valid applications for each service, i.e., IC card applications for each service that can process payments via UWB communication. Specifically, the table stores protocol parameters including unique identifiers of valid applications (valid IC card applications) required for communication with the service-compatible valid applications.

[0107] The service 1 compatible UWB communication relay app 123-1 of the user terminal 100 obtains protocol parameters including the unique identifier of the valid app (valid IC card app) required for communication between the payment terminal 200 of transportation company A (service 1) and the valid app (valid IC card app) compatible with service 1 from the service compatible valid app registration table, and transmits the protocol parameters to the payment terminal 200 of transportation company A (service 1).

[0108] The payment terminal 200 of transportation company A (service 1) receives protocol parameters required for communication with a valid application (valid IC card application) compatible with service 1 from the service 1 compatible UWB communication relay application 123-1 of the user terminal 100, and uses the received protocol parameters to communicate with the valid application (valid IC card application) compatible with service 1 and perform payment processing.

[0109] The payment process involves a series of processes, such as authentication, balance confirmation, usage fee withdrawal, and balance update. The specific process sequences will be described in detail later.

[0110] The UWB communication relay application 123 set in the user terminal 100 of the present disclosure is set as a service-based application on the application layer, as shown in Figure 6. These applications have the advantage that they can be installed at any time on a user terminal such as a smartphone without changing the hardware or the SE-OS (Secure Element Operating System). In other words, like the IC card application on the top application layer shown in Figure 6, users can freely install and uninstall them.

[0111] As mentioned above, the communication distance of UWB communication is, for example, approximately 10 m, which differs from NFC communication, which has a communication distance of a few centimeters, and communication is possible even if the user terminal 100 is not in close proximity to the payment terminal 200.

[0112] Therefore, by installing the UWB communication relay app 123 on the user's smartphone (user terminal 100), the smartphone carried in the user's bag can perform payment processing via UWB communication with the payment terminal installed at the ticket gate within a specific range from the ticket gate, for example, a few meters away, and the user can perform payment processing and pass through the ticket gate without taking out the user terminal such as the smartphone carried in the bag.

[0113] The same applies when making payments using a payment terminal at a store, etc.; users can complete the payment process while approaching and passing by the store's payment terminal, without having to hold their user terminal, such as a smartphone, over the store's payment terminal.

[0114] 4. Example of the Configuration of an Application in a Secure Element of a Communication Processing Device (User Terminal) According to the Present Disclosure Next, an example of the configuration of an application in a secure element of a communication processing device (user terminal) according to the present disclosure will be described.

[0115] Fig. 7 is a diagram illustrating an example of IC card applications in the IC card application group 121 of the secure element 120 of the user terminal 100 shown in Fig. 5, and the attribute information set for each IC card application. Note that the IC card applications shown in Fig. 7 are just an example, and the IC card applications stored in each user terminal will have different settings.

[0116] 7 shows an example in which the following IC card applications are stored in the IC card application group 121: (A) IC card application for transportation business A (service ID=1) (a1) Card 1 (a2) Card 2 (a3) ​​Card 3 (B) IC card application for electronic money business B (service ID=2) (b1) Card 4 (b2) Card 5 (C) IC card application for electronic money business C (service ID=3) (c1) Card 6

[0117] These six IC card applications (cards 1 to 6) are stored (installed) as IC card applications in the IC card application group 121 of the secure element 120 of the user terminal 100 shown in FIG.

[0118] Each IC card application has the following information recorded as its attribute information: (Attribute Information 1) Service ID (Attribute Information 2) AID (Application ID) (Attribute Information 3) IC card unique identifier (IDm)

[0119] (Attribute information 1) The service ID is an identifier for a service that can be received using the IC card app. For example, a "Transportation Company A compatible IC card app" allows a user to receive a service for using transportation facilities such as trains and buses managed by Transportation Company A, and the service ID for this service is service ID = 1. As shown in Figure 7, the same service ID is set for the three types of card apps of the "Transportation Company A compatible IC card app," namely, (a1) Card 1, (a2) Card 2, and (a3) ​​Card 3.

[0120] (Attribute information 2) AID (application ID) is an identifier that indicates the application type of the IC card application. A different AID (application ID) is set for each of the three types of card applications, (a1) Card 1, (a2) Card 2, and (a3) ​​Card 3, of the "Transportation Company A Compatible IC Card Application" shown in FIG. 7. These three card applications, (a1) Card 1, (a2) Card 2, and (a3) ​​Card 3, offer the same available services, but have different processing programs set as applications.

[0121] (Attribute information 3) The IC card unique identifier (IDm) is an IC card unique identifier (IDm) associated with an IC card application. The IC card unique identifier (IDm) is a unique identifier of the IC card application installed in the user terminal 100, and is a different identifier for each application installed in the user terminal, even if the applications are of the same type. In contrast, the application ID (AID) is an ID that is set according to the type of application, and the same ID (AID) is set for applications of the same type even if the user terminal 100 is different.

[0122] In this way, the following information is recorded in each IC card application as attribute information of the IC card application: (Attribute Information 1) Service ID (Attribute Information 2) AID (Application ID) (Attribute Information 3) IC card unique identifier (IDm)

[0123] Like the IC card application, the UWB communication relay application 123 is also an application stored in the secure element (SE) 120, and like the IC card application, has an application ID (AID).

[0124] 8 shows an example of setting the application ID (AID) of the UWB communication relay application 123. As explained above, the UWB communication relay application 123 is made up of UWB communication relay applications 123-1 to 123-n for each service, and a different application ID (AID) is set for each of these UWB communication relay applications 123-1 to 123-n for each service.

[0125] For example, the UWB communication relay application 123-1 corresponding to service 1 has AID=CNT1, the UWB communication relay application 123-2 corresponding to service 2 has AID=CNT2, ... the UWB communication relay application 123-n corresponding to service n has AID=CNTn. In this way, a different application ID (AID) is set for each UWB communication relay application for each service.

[0126] As mentioned above, the services are, for example, the following services: (A) Transportation Business Operator A (Service ID = 1) (B) Electronic Money Business Operator B (Service ID = 2) (C) Electronic Money Business Operator C (Service ID = 3)

[0127] The correspondence between the UWB communication relay application for each service and the IC card application for each service will be described with reference to FIG.

[0128] The right side of Fig. 9 shows IC card applications for each image service stored in the IC card application group 121 described above with reference to Fig. 7. That is, (A) IC card application for transportation business A (service ID = 1) (a1) Card 1 (a2) Card 2 (a3) ​​Card 3 (B) IC card application for electronic money business B (service ID = 2) (b1) Card 4 (b2) Card 5 (C) IC card application for electronic money business C (service ID = 3) (c1) Card 6

[0129] These multiple IC card applications are stored in an IC card application group 121 of the secure element 120 of the user terminal 100 .

[0130] The left side of Fig. 9 shows UWB communication relay applications 123-1 to 123-2 for multiple services within UWB communication relay application 123. In the example shown in Fig. 9, (A) UWB communication relay application 123-1 for transportation business A (service ID = 1) and (B) UWB communication relay application 123-2 for electronic money business B (service ID = 2) are shown as UWB communication relay applications for these two services.

[0131] (C) A UWB communication relay app compatible with electronic money provider C (service ID=3) is not stored. This is because the service-compatible UWB communication relay app is an app that, when multiple service-compatible IC card apps are stored (installed) in user terminal 100, has the role of selecting one IC card app that communicates with payment terminal 200 and performs payment, and notifying payment terminal 200 of that selection. Therefore, if only one service-compatible IC card app is stored (installed) in user terminal 100, the service-compatible UWB communication relay app is not necessary.

[0132] In addition to (c1) Card 6 shown in Figure 9 as an IC card application compatible with (C) electronic money provider C (service ID = 3), if a new IC card application, namely (c2) Card 7, is installed, UWB communication relay application 123-3 compatible with (C) electronic money provider C (service ID = 3) is also installed along with the installation process of this new IC card application.

[0133] In the example shown in Figure 9, there are three IC card applications compatible with (A) transportation business A (service ID = 1): (a1) card 1 to (a3) ​​card 3. There are also two IC card applications compatible with (B) electronic money business B (service ID = 2): (b1) card 4 to (b2) card 5.

[0134] When the user terminal 100 communicates with the payment terminal of transportation company A (service ID = 1), the UWB communication relay app 123-1 compatible with transportation company A (service ID = 1) analyzes the UWB communication data sent from the payment terminal of transportation company A and selects the IC card app that will perform payment processing for transportation company A from three IC card apps (a1) Card 1 to (a3) ​​Card 3 that are compatible with transportation company A (service ID = 1).

[0135] When user terminal 100 communicates with the payment terminal of electronic money provider B (service ID = 2), UWB communication relay application 123-2 compatible with electronic money provider B (service ID = 2) analyzes the UWB communication data sent from the payment terminal of electronic money provider B and performs a process of selecting an IC card application to perform payment processing for electronic money provider B from two IC card applications compatible with electronic money provider B (service ID = 2), (b1) Card 4 to (b2) Card 5.

[0136] In this way, UWB communication relay applications 123-1 to 123-n corresponding to each service execute a process for selecting a payment terminal for each service and an IC card application that will actually execute the payment process. The IC card application selection process executed by UWB communication relay applications 123-1 to 123-n corresponding to each service is executed by referring to a "service-compatible valid application registration table" stored in the memory of user terminal 100.

[0137] FIG. 10 shows a specific example of the "service-compatible valid application registration table" stored in the memory of the user terminal 100.

[0138] 10, the service-compatible valid application registration table registers information about a "valid application" for each service. A "valid application" is one IC card application selected for each service as an IC card application that performs payment processing.

[0139] The service-compatible valid application registration table stores information about one valid application for each service, specifically, protocol parameters required for communication with the valid application, i.e., protocol parameters including a unique identifier of the valid application (valid IC card application).

[0140] The user can select and change which of the multiple IC card applications corresponding to one service will be the active application (application for executing payment processing). Information about one active application corresponding to each service selected by the user is registered in a "service-compatible active application registration table." Therefore, when the user changes the active application corresponding to a certain service, the registered data in the "service-compatible active application registration table" is also changed in accordance with the active application change process.

[0141] In the "Service-Compatible Valid Application Registration Table" shown in Figure 10, the following IC card applications are registered as valid applications: An IC card application with an IC card unique identifier: IDm = a2 as a valid application compatible with service 1 An IC card application with an IC card unique identifier: IDm = b1 as a valid application compatible with service 2 An IC card application with an IC card unique identifier: IDm = c1 as a valid application compatible with service 3 These IC card applications are examples of applications registered as valid applications.

[0142] That is, an example is shown in which the IC card applications marked with a star (★) shown in FIG. 11 are registered as valid applications for each service.

[0143] The registered data in the "service-compatible valid application registration table" will be described with reference to Fig. 10. As described above, the "service-compatible valid application registration table" registers information about one valid application per service selected from each service, specifically, the following information as protocol parameters required for communication with the valid application: (a) System code (SCn) (b) IC card unique identifier (IDm) (c) Response time descriptor (PMm) (d) Application ID (AID)

[0144] (a) System code (SCn) is code information that identifies an application used to perform communication processing and payment processing corresponding to the service.

[0145] (b) The IC card unique identifier (IDm) is an IC card unique identifier (IDm) associated with an IC card application. The IC card unique identifier (IDm) is a unique identifier of the IC card application installed on the user terminal 100, and is a different identifier for each application installed on the user terminal, even if the applications are of the same type. In contrast, the application ID (AID) is an ID set according to the type of application, and the same ID (AID) is set for the same type of application even if the user terminal 100 is different.

[0146] (c) Response time descriptor (PMm) is an identifier used to calculate the response time for communication data in service-related communication processing and payment processing. (d) Application ID (AID) is an identifier indicating the application type of the IC card application.

[0147] The "service-compatible valid application registration table" records each of the data (a) to (d) for one valid application per service selected from each service. These data are protocol parameters required for communication between the payment terminal 200 compatible with each service and the IC card application.

[0148] 5. Processing Sequence Executed by the Communication Processing Device of the Present Disclosure Next, a processing sequence executed by the communication processing device of the present disclosure will be described.

[0149] The following processing sequences will be explained in order: (1) Registration processing sequence for a service-compatible valid application (2) Communication sequence between a service-compatible UWB communication relay application of a user terminal and a payment terminal (3) Communication sequence between a service-compatible valid application (valid IC card application) of a user terminal and a payment terminal (4) Processing sequence when there is only one service-compatible valid application (valid IC card application) of a user terminal

[0150] (5-(1) Registration Processing Sequence of Service-Compatible Valid Applications) First, the "(1) Registration Processing Sequence of Service-Compatible Valid Applications to the User Terminal by the User" will be described.

[0151] This process selects one valid application per service from the IC card applications corresponding to each service stored in the IC card application group 121 in the secure element (SE) 120, i.e., one IC card application that communicates with the payment terminal of each service to perform payment processing, and records it in the table previously described with reference to Figure 10, i.e., the "service-compatible valid application registration table," so that it can be used as an IC card application that can be used for payment via UWB communication.

[0152] The data registration process for the "service-enabled application registration table" may be configured to be executed in response to a user request in accordance with the sequence described with reference to FIG. 12, or may be configured to be executed automatically by the UWB communication relay application 123 without user instruction.

[0153] 12 is a sequence diagram illustrating a process sequence for registering a valid application corresponding to a service to a user terminal by a user. The example of the process sequence for registering a valid application corresponding to a service shown in FIG. 12 is a process sequence for registering card 2 (AID=12) as a valid card for transportation business A (service ID=1) shown in FIG. 11.

[0154] Figure 12 shows a user 150 on the far left and a user terminal 100 on the right, and the components of the user terminal 100 are, from left to right, a user terminal controller (intra-DH communication control unit) 101, a service 1 compatible UWB communication relay application 123-1, an IC card 1 application (AID = 11) 121-1, an IC card 2 application (AID = 12) 121-2, and an IC card 3 application (AID = 13) 121-3.

[0155] The details of each process in steps S101 to S104 shown in Fig. 12 will be explained in order. (Steps S101 to S102) First, in step S101, user 150 inputs a valid card registration request to set the valid card application for transportation company A (service ID = 1) to card 2 application (AID = 12).

[0156] This process is executed, for example, when the user installs a new IC card application compatible with service 1 on the user terminal.

[0157] The user displays information about the newly installed IC card application on the display unit of the user terminal 100, and inputs a registration request to register the displayed IC card application as a "valid application" in the user terminal 100. For example, the user taps an icon that displays "Register as a valid application for service 1."

[0158] This tap process causes the attribute information of the IC card app being displayed on the display unit of the user terminal 100 to be read from the IC card app, and in step S102, it is input to the service 1 compatible UWB communication relay app 123-1 via the user terminal controller (DH communication control unit) 101.

[0159] In this example, it is assumed that the IC card 2 application (AID=12) 121-2 with application identifier (AID)=12 is designated as a valid application.

[0160] (Step S103) Next, in step S103, the service 1 compatible UWB communication relay application 123-1 checks the existence of the IC card 2 application (AID=12) designated by the user.

[0161] In step S103, the service 1 compatible UWB communication relay application 123-1 refers to the IC card application group 121 of the secure element (SE) 120 to check whether or not the IC card 2 application (AID=12) exists.

[0162] If the existence of IC card 2 application (AID=12) is confirmed, the process proceeds to step S104. On the other hand, if the existence of IC card 2 application (AID=12) is not confirmed, the process does not proceed to step S104, but outputs an error message to the display unit of user terminal 100 and ends the process.

[0163] (Step S104) If it is confirmed that the IC card 2 application (AID=12) requested by the user to be registered as a UWB communication applicable card exists, the process proceeds to step S104.

[0164] In this case, in step S104, the service 1 compatible UWB communication relay application 123-1 registers information (protocol parameters) regarding the IC card 2 application (AID=12) in the table previously described with reference to Figure 10, i.e., the "service compatible valid application registration table."

[0165] That is, the card 2 application (AID=12) is registered in the service-compatible valid application registration table as a valid card application for transportation company A (service ID=1). Through this table registration process, the IC card 2 application (AID=12) is validated as an IC card application that can process payments via UWB communication.

[0166] (5-(2) Communication Sequence Between Service-Compatible UWB Communication Relay App of User Terminal and Payment Terminal) Next, "(2) Communication Sequence Between Service-Compatible UWB Communication Relay App of User Terminal and Payment Terminal" will be described.

[0167] Referring to FIG. 13 and subsequent figures, "(2) Communication sequence between service-compatible UWB communication relay application of user terminal and payment terminal" will be described.

[0168] 13 and subsequent sequence diagrams show payment terminal 200 on the far left and user terminal 100 on the right. The components of payment terminal 200 are, from left to right, payment terminal controller 201, UWB communication unit 212, and BLE communication unit 213.

[0169] On the other hand, the components of the user terminal 100 are shown, from left to right, as follows: a BLE communication unit 113, a UWB communication unit 112, a secure element OS (SE-OS) 120, a service 1 compatible UWB communication relay application 123-1, an IC card 2 application (AID=12) 121-2, and a user terminal controller (intra-DH communication control unit) 101.

[0170] Details of the processes from step S201 onwards shown in Fig. 13 onwards will be described in order. (Step S201) First, in step S201, payment terminal controller 201 of payment terminal 200 broadcasts an Advertise packet from BLE communication unit 213, which is a packet requesting user terminal detection and establishment of a BLE communication connection.

[0171] As described above, the BLE communication standard defines an ADV_IND packet (General Advertising Indication packet) as a broadcast packet for device detection. In step S201, the payment terminal 200 broadcasts an Advertise packet from the BLE communication unit 213.

[0172] (Step S202) When the user terminal 100 enters a BLE communication coverage area (for example, several tens of meters) and receives the advertising packet transmitted by the payment terminal 200, in step S202, the user terminal 100 transmits a response packet including a user terminal identifier to the payment terminal 200. The payment terminal 200 detects the user terminal 100 by acquiring the user terminal identifier from the response packet transmitted by the user terminal 100.

[0173] When the user terminal is detected, the payment terminal 200 then performs a process of acquiring user terminal position analysis data from the user terminal 100 in order to start the position identification process for the user terminal 100 .

[0174] As described above, the payment terminal controller 201 of the payment terminal 200 uses UWB (Ultra Wide Band) communication to perform the location identification process for the user terminal 100 .

[0175] (Steps S203 to S205) Next, in step S203, payment terminal controller 201 of payment terminal 200 starts user terminal location identification processing using UWB communication with UWB communication unit 112 of user terminal 100 via UWB communication unit 212.

[0176] As mentioned above, UWB communication specifies a "secure ranging" method that analyzes device locations while maintaining security. "Secure ranging" is a technology that enables secure measurement of the distance and angle between communicating devices by sending and receiving encrypted data using a shared key.

[0177] When the payment terminal 200 detects a user terminal via BLE communication in steps S201 to S202, in step S203 it outputs a UWB communication signal to identify the position of the detected user terminal 100, establishes communication between the UWB communication unit 212 of the payment terminal 200 and the UWB communication unit 112 of the user terminal 100, starts the position identification process for the user terminal 100, and then continuously executes the user terminal position identification process.

[0178] As described above, UWB communication unit 212 of payment terminal 200 analyzes data on ToA (Time of Arrival) and AoA (Angle of Arrival) during secure ranging via UWB communication. ToA (Time of Arrival) corresponds to the transmission and reception time of a UWB signal, and payment terminal controller 201 of payment terminal 200 analyzes the distance from payment terminal 200 to user terminal 100 based on this time.

[0179] AoA (Angle of Arrival) is angle information at which a transmission signal from user terminal 100 is input to payment terminal 200. Payment terminal controller 201 of payment terminal 200 analyzes the direction of user terminal 100 based on this angle. Payment terminal controller 201 of payment terminal 200 identifies the position of user terminal 100 by analyzing ToA and AoA.

[0180] After detecting the user terminal 100, the payment terminal controller 201 of the payment terminal 200 continues to execute the user terminal location identification process until the payment process starts or ends, for example, until the user passes through the ticket gate where the payment terminal 200 is installed.

[0181] In parallel with performing secure ranging via UWB communication, payment terminal controller 201 of payment terminal 200 selects an IC card application via UWB communication and communicates with the IC card application to perform payment processing and the like.

[0182] (Step S211) Next, the processing from step S211 onwards shown in Fig. 14 will be described. In step S211, payment terminal controller 201 of payment terminal 200 outputs a communication request packet to communicate with service 1 compatible UWB communication relay application 123-1 of user terminal 100 by UWB communication via UWB communication unit 212.

[0183] This communication request packet is a UWB communication packet that stores a SELECT command that records the application ID (AID=CNT1) of the UWB communication relay application 123-1 that supports service 1. The SELECT command is a command defined in ISO 7816-4, and stores the application ID (AID) of the application that is the target of the communication request in the packet, requesting the specified application as the communication partner.

[0184] 16 shows an example of the structure of a UWB communication packet storing a select command (SELECT command) transmitted from payment terminal 200 to user terminal 100 in step S211. The SELECT command is a packet transmitted from payment terminal 200 to user terminal 100 to specify an application in the user terminal with which to communicate, and has an APDU-defined packet structure equivalent to the select command (APDU SELECT command) shown in FIG.

[0185] The select command (APDU SELECT command) shown in Fig. 16 has a packet structure conforming to the APDU (Application Protocol Data Unit) defined as a packet frame usable in UWB communications. Note that the APDU is a packet frame structure defined in ISO 7816-4 and is a packet frame structure usable in UWB communications.

[0186] The data section (Data) of this packet stores the AID of the application designated by the payment terminal 200 as the communication partner, that is, in this processing example, the application ID (AID=CNT1) of the service 1 compatible UWB communication relay application 123-1.

[0187] (Step S212) When the UWB communication unit 112 of the user terminal 100 receives the SELECT command packet transmitted from the payment terminal 200 in step S211, the UWB communication unit 112 passes the received packet to the secure element (SE-OS) 120.

[0188] The secure element (SE-OS) 120 recognizes the SELECT command in the packet and obtains the application ID (AID=CNT1) of the communication request target application stored in the packet. This AID is the application ID (AID=CNT1) of the service 1 compatible UWB communication relay application 123-1. The secure element (SE-OS) 120 selects and launches the application corresponding to this AID=CNT1, i.e., the service 1 compatible UWB communication relay application 123-1.

[0189] (Step S213) In step S212, the service 1 compatible UWB communication relay application 123-1, which was started by the application selection and start process by the secure element (SE-OS) 120, in step S213 references the service compatible valid application registration table (see FIG. 10) stored in the memory of the user terminal 100 and acquires registration information (protocol parameters) of the valid card application compatible with service 1. That is, it acquires the registration information (protocol parameters: SC=SC1, IDm=a2, PMm=PMm2) of the valid card application compatible with service 1.

[0190] (Step S214) Next, in step S214 shown in FIG. 15, the service 1 compatible UWB communication relay application 123-1 stores the registration information (protocol parameters SC=SC1, IDm=a2, PMm=PMm2) of the valid application (valid IC card application) compatible with service 1 in the activation response (SELECT response) packet of the service 1 compatible UWB communication relay application and transmits it.

[0191] As explained above, a "valid application (valid IC card application)" is one IC card application selected in correspondence with each service as an IC card application that performs payment processing.

[0192] (Step S215) In step S215, the secure element (SE-OS) 120 receives the startup response (SELECT response) from the service 1 compatible UWB communication relay application 123-1 and transmits the startup response (SELECT response) generated by the service 1 compatible UWB communication relay application 123-1 to the payment terminal 200 via the UWB communication unit 112.

[0193] FIG. 17 shows an example of the packet configuration of a select response (SELECT response) as a start-up response that is generated by service 1 compatible UWB communication relay application 123-1 in step S214 and transmitted to payment terminal 200 in step S215.

[0194] The SELECT response is a response packet to the SELECT command described above with reference to Fig. 16. That is, the SELECT response is sent from the user terminal 100 to the payment terminal 200 as a response packet to the SELECT command sent by the payment terminal 200 to the user terminal 100 in order to specify an application in the user terminal with which to communicate.

[0195] This SELECT response has a packet configuration equivalent to the select response (APDU SELECT response) shown in Fig. 17. The select response (APDU SELECT response) shown in Fig. 17 also has a packet configuration conforming to the APDU (Application Protocol Data Unit) defined as a packet frame that can be used in UWB communications.

[0196] The service 1 compatible UWB communication relay application 123-1 stores in this packet the registration information (protocol parameters) of the valid application (valid IC card application) compatible with service 1 obtained from the service compatible valid application registration table (see Figure 10) stored in the memory of the user terminal 100.

[0197] That is, the following protocol parameters, which are registration information of valid applications (valid IC card applications) corresponding to service 1, are acquired and stored: (a) System code (SCn) = SC1 (b) IC card unique identifier (IDm) = a2 (c) Response time descriptor (PMm) = PMm2 These parameters are parameters registered in the service-compatible valid application registration table described above with reference to FIG. 10, and are registration information of valid applications (valid IC card applications) corresponding to service 1.

[0198] 17 is sent to payment terminal 200 via UWB communication unit 112 of user terminal 100. This SELECT response is then input to payment terminal controller 201 via UWB communication unit 212 of payment terminal 200, and payment terminal controller 201 analyzes the SELECT response received from user terminal 100 and starts communication with a valid application (IC card 2 application) of user terminal 100 that is compatible with service 1 to perform payment processing.

[0199] All information (protocol parameters) required for communication between the payment terminal 200 and the valid application (IC card 2 application) compatible with service 1 of the user terminal 100 can be obtained from the SELECT response received from the user terminal 100, so the payment terminal 200 can communicate with the valid application (IC card 2 application) compatible with service 1 of the user terminal 100 and perform payment processing without any problems.

[0200] (5-(3) Communication sequence between a service-enabled valid application (valid IC card application) of a user terminal and a payment terminal) Next, "(3) Communication sequence between a service-enabled valid application (valid IC card application) of a user terminal and a payment terminal" will be described.

[0201] Referring to FIG. 18, a communication sequence between a service-enabled valid application (valid IC card application) of a user terminal and a payment terminal will be described.

[0202] 18 shows a payment terminal 200 on the far left and a user terminal 100 on the right. The components of the payment terminal 200 are, from left to right, a payment terminal controller 201, a UWB communication unit 212, and a BLE communication unit 213.

[0203] On the other hand, the components of the user terminal 100 are shown, from left to right, as follows: a BLE communication unit 113, a UWB communication unit 112, a secure element OS (SE-OS) 120, a service 1 compatible UWB communication relay application 123-1, an IC card 2 application (AID=12) 121-2, and a user terminal controller (intra-DH communication control unit) 101.

[0204] The processing from step S221 onwards shown in Fig. 18 will be described in order. At the start of step S221, the payment terminal 200 and the user terminal 100 have established a UWB communication session, and the payment terminal 200 is continuing the user terminal location confirmation processing using UWB communication.

[0205] (Step S221) First, in step S221, the payment terminal controller 201 of the payment terminal 200 refers to the user terminal position confirmation result obtained through UWB communication to check whether the user terminal 100 has entered within a predetermined distance, for example, inside a ticket gate, and if so, starts the processing from step S222 onwards (payment processing).

[0206] The processing of steps S222 to S224 is a payment processing, in which APDU packets are repeatedly sent and received between the payment terminal 200 and the user terminal 100. For example, APDU packets are repeatedly sent and received between the payment terminal 200 and the user terminal 100 in order to execute a series of processes such as authentication processing, balance confirmation processing, usage fee debit processing, and balance update processing.

[0207] That is, the following steps S222 to S224 are repeatedly executed: (Step S222) = sending a command from the payment terminal 200 to the user terminal 100; (Step S223) = executing the command in the user terminal 100; (Step S224) = sending the command execution result from the user terminal 100 to the payment terminal 200;

[0208] Between the payment terminal controller 201 of the payment terminal 200 and the valid card application (AID = 12) compatible with service 1, the above steps S222 to S224 are repeatedly executed to execute a series of processes required for payment processing, such as authentication processing, balance confirmation processing, usage fee debit processing, balance update processing, etc.

[0209] The command transmission process from payment terminal 200 to user terminal 100 in step S222 and the command execution result transmission process from user terminal 100 to payment terminal 200 in step S224 are performed using APDU packets. That is, transmission and reception of APDU packets is repeatedly performed for each process unit, such as authentication process, balance confirmation process, usage fee debit process, and balance update process.

[0210] An example of the configuration of an APDU packet used in the command transmission process in step S222 and the command execution result transmission process in step S224 will be described with reference to Fig. 19. Fig. 19 shows the following two APDU packets: (a) APDU packet for command transmission (APDU (Type-F) command packet) (b) APDU packet for command execution result transmission (APDU (Type-F) response packet)

[0211] As mentioned above, the APDU packet is a communication packet conforming to the APDU (Application Protocol Data Unit) defined as a packet frame that can be used in UWB communication.

[0212] The (a) command transmission APDU packet (APDU (Type-F) command packet) shown in Figure 19 is an APDU packet used to transmit a command from the payment terminal 200 to the user terminal 100 in (step S222) of the sequence diagram shown in Figure 18.

[0213] A Type-F command is stored in the data section of this (a) command transmission APDU packet (APDU (Type-F) command packet). That is, a Type-F command used in payment processing in NFC communication is stored. Note that the Type-F command stored in the data section is a command for each process to be executed during payment processing, such as a command to request execution of authentication processing or a command to request execution of balance confirmation processing.

[0214] The processes in (Step S222) to (Step S224) in the sequence diagram shown in FIG. 18 will be described in order.

[0215] (Step S222) In step S222, the payment terminal controller 201 of the payment terminal 200 generates an APDU packet (APDU (Type-F) command packet) shown in Figure 19(a) in which Type-F commands such as a command to request execution of authentication processing and a command to request execution of balance confirmation processing are stored in the data section, and sends it to the valid card application (AID = 12) compatible with service 1 of the user terminal 100.

[0216] The APDU packet (APDU (Type-F) command packet) sent from the payment terminal 200 is received by the UWB communication unit 112 of the user terminal 100, and is passed from the secure element OS 120 to the service 1 compatible UWB communication relay application 123-1.

[0217] Note that a communication connection used for transmitting and receiving the select command and select response in steps S211 to S215 in Figures 14 and 15 described above is set between payment terminal controller 201 of payment terminal 200 and service 1 compatible UWB communication relay application 123-1 of user terminal 100, and using this communication connection, the APDU packet (APDU (Type-F) command packet) transmitted by payment terminal 200 is received by service 1 compatible UWB communication relay application 123-1 of user terminal 100. Note that the transmission and reception in steps S211 to S215 may be triggered by step S221 in Figure 18.

[0218] When sending and receiving the select command and select response in steps S211 to S215 of Figures 14 and 15 described above, the service 1 compatible UWB communication relay application 123-1 of the user terminal 100 refers to the "service compatible valid application registration table" and transfers the APDU packet (APDU (Type-F) command packet) received from the payment terminal 200 to the IC card 2 application (AID = 12) 121-2, which is a confirmed valid application (valid IC card application) compatible with service 1.

[0219] (Step S223) In step S223, the valid card application (AID=12) of the user terminal 100 that is compatible with service 1 analyzes the APDU packet (APDU (Type-F) command packet) shown in FIG. 19(a) received from the payment terminal 200, obtains the Type-F command stored in the data section, and executes processing according to the command.

[0220] (Step S224) In step S224, the valid card application (AID=12) for service 1 of the user terminal 100 generates an APDU packet storing the command execution result in step S223 and transmits it to the payment terminal 200.

[0221] An APDU packet containing the command execution results generated by the valid card application (AID = 12) compatible with service 1 of the user terminal 100 is transmitted to the payment terminal 200 via the service 1 compatible UWB communication relay application 123-1 and UWB communication unit 112 of the user terminal 100.

[0222] In step S224, the APDU packet generated by the valid card application (AID=12) for service 1 of the user terminal 100 is the command execution result transmission APDU packet (APDU (Type-F) response packet) shown in FIG. 19(b).

[0223] The command execution result (Type-F response) in step S223 is stored in the data section of the command execution result transmission APDU packet (APDU (Type-F) response packet) shown in Figure 19(b). The Type-F response stored in the data section of the APDU (Type-F) response packet is execution result data for the processing unit executed during the payment processing, such as the execution result of the authentication processing or the execution result of the balance confirmation processing.

[0224] In this way, in steps S222 to S224 shown in FIG. 18, between the payment terminal controller 201 of the payment terminal 200 and the valid card application (AID=12) compatible with service 1, the APDU packet (APDU (Type-F) command packet) shown in FIG. 19(a) and the APDU packet for transmitting the command execution result (APDU (Type-F) response packet) shown in FIG. 19(b) are repeatedly sent and received to execute a series of processes required for payment processing, such as authentication processing, balance confirmation processing, usage fee debit processing, balance update processing, etc.

[0225] When the series of processes in steps S222 to S224 are completed, the payment terminal controller 201 of the payment terminal 200 confirms the completion of communication processing with the IC card application and data processing required for payment processing or user entry permission confirmation processing, etc., and terminates the processing.

[0226] In addition, if the payment terminal 200 is configured to control, for example, a ticket gate, once the series of processes from steps S222 to S224 are completed, a process is performed to open the gate door, allowing the user to pass through.

[0227] In this way, the processing of the present disclosure establishes a communication path between payment terminal controller 201 of payment terminal 200 and service 1 compatible UWB communication relay application 123-1 of user terminal 100 by transmitting and receiving a select command and a select response in steps S211 to S215 of Figures 14 and 15, and uses this communication path to transfer the APDU (Type-F) command packet (see Figure 19 (a)) sent from payment terminal controller 201 of payment terminal 200 to IC card application 121-2, which is a valid application (AID = 12) compatible with service 1, via service 1 compatible UWB communication relay application 123-1 of user terminal 100.

[0228] By performing such processing, it becomes possible to quickly start communication between the service-compatible active app of the user terminal 100 and the payment terminal 200, and it becomes possible to reliably carry out service-compatible payment processing, etc. without delay.

[0229] The example described with reference to Figures 13 to 19 is an example of processing corresponding to service 1, that is, a processing example in which payment processing is performed using IC card application 121-2, which is a valid application (AID = 12) corresponding to service 1 registered in the "Service Compatible Valid Application Registration Table" shown in Figure 10, and is an example that uses service 1 compatible UWB communication relay application 123-1.

[0230] 13 to 19 are also executed for services other than service 1. For example, when performing payment processing using an IC card application corresponding to a valid application (AID=21) compatible with service 2 registered in the "service-compatible valid application registration table" shown in Fig. 10, processing is performed using service 2-compatible UWB communication relay application 123-2.

[0231] However, the process of selecting a valid application compatible with the service using the service-compatible UWB communication relay application 123 may be configured to be executed only when there are multiple IC card applications compatible with one service.

[0232] When there is only one IC card application compatible with one service, for example, the IC card application compatible with (C) electronic money provider C (service ID=3) currently in the service described above with reference to Figure 9 is only one, that of card 6 (AID=31). In such a case, processing is possible without using the service-compatible UWB communication relay application 123. The processing sequence for such a case will be described below.

[0233] (5-(4) Communication sequence when the user terminal has only one service-compatible valid application (valid IC card application)) Next, we will explain ``(4) Communication sequence when the user terminal has only one service-compatible valid application (valid IC card application).''

[0234] Referring to FIG. 20 and subsequent figures, a communication sequence between the user terminal 100 and the payment terminal 200 when the user terminal has only one service-enabled valid application (valid IC card application) will be described.

[0235] 20 shows a payment terminal 200 on the far left and a user terminal 100 on the right. The components of the payment terminal 200 are, from left to right, a payment terminal controller 201, a UWB communication unit 212, and a BLE communication unit 213.

[0236] On the other hand, components of the user terminal 100 are shown, from the left, as follows: a BLE communication unit 113, a UWB communication unit 112, a secure element OS (SE-OS) 120, an IC card 6 application (AID=31) 121-6, and a user terminal controller (intra-DH communication control unit) 101. Note that the "Service 3 compatible UWB communication relay application 123-3" indicated by the dotted line is not used, or does not exist.

[0237] Details of the processing from step S301 onwards shown in Fig. 20 onwards will be explained in order. (Step S301) First, in step S301, payment terminal controller 201 of payment terminal 200 broadcasts an Advertise packet from BLE communication unit 213, which is a packet requesting user terminal detection and establishment of a BLE communication connection.

[0238] As described above, the BLE communication standard defines an ADV_IND packet (General Advertising Indication packet) as a broadcast packet for device detection. In step S301, the payment terminal 200 broadcasts an Advertise packet from the BLE communication unit 213.

[0239] (Step S302) When the user terminal 100 enters a BLE communication coverage area (for example, several tens of meters) and receives the advertising packet transmitted by the payment terminal 200, in step S302, the user terminal 100 transmits a response packet including a user terminal identifier to the payment terminal 200. The payment terminal 200 detects the user terminal 100 by acquiring the user terminal identifier from the response packet transmitted by the user terminal 100.

[0240] When the user terminal is detected, the payment terminal 200 then performs a process of acquiring user terminal position analysis data from the user terminal 100 in order to start the position identification process for the user terminal 100 .

[0241] As described above, the payment terminal controller 201 of the payment terminal 200 uses UWB (Ultra Wide Band) communication to perform the location identification process for the user terminal 100 .

[0242] (Steps S303 to S305) Next, in step S303, payment terminal controller 201 of payment terminal 200 starts user terminal location identification processing using UWB communication with UWB communication unit 112 of user terminal 100 via UWB communication unit 212.

[0243] As mentioned above, UWB communication specifies a "secure ranging" method that analyzes device locations while maintaining security. "Secure ranging" is a technology that enables secure measurement of the distance and angle between communicating devices by sending and receiving encrypted data using a shared key.

[0244] When the payment terminal 200 detects a user terminal via BLE communication in steps S301 to S302, in step S303 it outputs a UWB communication signal to identify the position of the detected user terminal 100, establishes communication between the UWB communication unit 212 of the payment terminal 200 and the UWB communication unit 112 of the user terminal 100, starts the position identification process for the user terminal 100, and then continuously executes the user terminal position identification process.

[0245] As described above, UWB communication unit 212 of payment terminal 200 analyzes data on ToA (Time of Arrival) and AoA (Angle of Arrival) during secure ranging via UWB communication. ToA (Time of Arrival) corresponds to the transmission and reception time of a UWB signal, and payment terminal controller 201 of payment terminal 200 analyzes the distance from payment terminal 200 to user terminal 100 based on this time.

[0246] AoA (Angle of Arrival) is angle information at which a transmission signal from user terminal 100 is input to payment terminal 200. Payment terminal controller 201 of payment terminal 200 analyzes the direction of user terminal 100 based on this angle. Payment terminal controller 201 of payment terminal 200 identifies the position of user terminal 100 by analyzing ToA and AoA.

[0247] After detecting the user terminal 100, the payment terminal controller 201 of the payment terminal 200 continues to execute the user terminal location identification process until the payment process starts or ends, for example, until the user passes through the ticket gate where the payment terminal 200 is installed.

[0248] In parallel with performing secure ranging via UWB communication, payment terminal controller 201 of payment terminal 200 selects an IC card application via UWB communication and communicates with the IC card application to perform payment processing and the like.

[0249] (Step S311) Next, the processing from step S311 onwards shown in Fig. 21 will be described. In step S311, payment terminal controller 201 of payment terminal 200 outputs a communication request packet to communicate with IC card 6 application (AID = 31) 121-6, which is a valid application for service 3 of user terminal 100, by UWB communication via UWB communication unit 212.

[0250] This communication request packet is a UWB communication packet storing a SELECT command that records the application ID (AID=31) of the IC card 6 application (AID=31) 121-6, which is a valid application for service 3.

[0251] As explained above, the SELECT command is a packet that the payment terminal 200 sends to the user terminal 100 to specify an application in the user terminal with which to communicate, and has an APDU-defined packet configuration that corresponds to the select command (APDU SELECT command) shown in FIG. 16 explained above.

[0252] The data section (Data) of this packet stores the AID of the application designated by the payment terminal 200 as the communication partner, that is, in this processing example, the application ID (AID=31) of the IC card 6 application (AID=31) 121-6, which is a valid application compatible with service 3.

[0253] (Step S312) When the UWB communication unit 112 of the user terminal 100 receives the SELECT command packet transmitted from the payment terminal 200 in step S311, the UWB communication unit 112 passes the received packet to the secure element (SE-OS) 120.

[0254] The secure element (SE-OS) 120 recognizes the SELECT command in the packet and obtains the application ID (AID=31) of the communication request target application stored in the packet. This AID is the application ID (AID=31) of the IC card 6 application (AID=31) 121-6, which is a service 3-enabled application. The secure element (SE-OS) 120 selects and launches the application corresponding to this AID=31, that is, the IC card 6 application (AID=31) 121-6, which is a service 3-enabled application.

[0255] (Step S313) In step S312, IC card 6 application (AID=31) 121-6, which is a valid application compatible with service 3 that was launched by the application selection and launch process by secure element (SE-OS) 120, references the service-compatible valid application registration table (see FIG. 10) stored in the memory of user terminal 100 and acquires registration information (protocol parameters) of the valid card application compatible with service 3. That is, it acquires registration information of the valid card application compatible with service 3 (protocol parameters: SC=SC3, IDm=c1, PMm=PMm6).

[0256] (Step S314) Next, in step S314 shown in FIG. 22, the IC card 6 application (AID=31) 121-6, which is a valid application compatible with service 3, stores the registration information of the valid card application compatible with service 3 (protocol parameters: SC=SC3, IDm=c1, PMm=PMm6) in the activation response (SELECT response) packet of the valid application compatible with service 3 and transmits it.

[0257] As explained above, a "valid application (valid IC card application)" is one IC card application selected in correspondence with each service as an IC card application that performs payment processing.

[0258] (Step S315) The secure element (SE-OS) 120, which has received a startup response (SELECT response) from the IC card 6 application (AID = 31) 121-6, which is a valid application for service 3, sends the startup response (SELECT response) generated by the IC card 6 application (AID = 31) 121-6, which is a valid application for service 3, to the payment terminal 200 via the UWB communication unit 112 in step S315.

[0259] This SELECT response is a response packet to the SELECT command described above with reference to FIG. 16, and has a packet configuration equivalent to the select response (APDU SELECT response) shown in FIG. 17 described above.

[0260] The IC card 6 application (AID=31) 121-6, which is a valid application compatible with service 3, stores in this packet the registration information (protocol parameters) of the valid application compatible with service 3 (valid IC card application) obtained from the service-compatible valid application registration table (see Figure 10) stored in the memory of the user terminal 100.

[0261] That is, the following protocol parameters, which are the registration information of the IC card 6 application (AID=31) 121-6, which is a valid application for service 3, are acquired and stored: (a) System code (SCn)=SC3 (b) IC card unique identifier (IDm)=c1 (c) Response time descriptor (PMm)=PMm6 These parameters are the parameters registered in the service-enabled application registration table described above with reference to FIG. 10, and are the registration information of the IC card 6 application (AID=31) 121-6, which is a valid application for service 3.

[0262] The SELECT response generated by IC card 6 application (AID=31) 121-6, which is a valid application for service 3, is sent to payment terminal 200 via UWB communication unit 112 of user terminal 100. This SELECT response is then input to payment terminal controller 201 via UWB communication unit 212 of payment terminal 200, and payment terminal controller 201 analyzes the SELECT response received from user terminal 100 and initiates communication with IC card 6 application (AID=31) 121-6, which is a valid application for service 3 of user terminal 100, to perform payment processing.

[0263] All of the information (protocol parameters) required for communication between the payment terminal 200 and the IC card 6 application (AID=31) 121-6, which is a service 3-compatible enabled application of the user terminal 100, can be obtained from the SELECT response received from the user terminal 100, so the payment terminal 200 can communicate with and process payments with the IC card 6 application (AID=31) 121-6, which is a service 3-compatible enabled application of the user terminal 100, without any problems.

[0264] Next, the processing from step S321 onwards shown in Fig. 23 will be described in order. At the start of step S321, the payment terminal 200 and the user terminal 100 have established a UWB communication session, and the payment terminal 200 is continuing the user terminal location confirmation processing using UWB communication.

[0265] (Step S321) First, in step S321, the payment terminal controller 201 of the payment terminal 200 refers to the user terminal position confirmation result obtained through UWB communication to check whether the user terminal 100 has entered within a predetermined distance, for example, inside a ticket gate, and if so, starts the processing from step S322 onwards (payment processing).

[0266] The processing of steps S322 to S324 is a payment processing, in which APDU packets are repeatedly sent and received between the payment terminal 200 and the user terminal 100. For example, APDU packets are repeatedly sent and received between the payment terminal 200 and the user terminal 100 in order to execute a series of processes such as authentication processing, balance confirmation processing, usage fee debit processing, and balance update processing.

[0267] That is, the following steps S322 to S324 are repeatedly executed: (Step S322) = sending a command from the payment terminal 200 to the user terminal 100; (Step S323) = executing the command in the user terminal 100; (Step S324) = sending the command execution result from the user terminal 100 to the payment terminal 200;

[0268] The above steps S322 to S324 are repeatedly executed between the payment terminal controller 201 of the payment terminal 200 and the IC card 6 application (AID = 31) 121-6, which is an application that is valid for service 3, to execute a series of processes necessary for payment processing, such as authentication processing, balance confirmation processing, usage fee debit processing, balance update processing, etc.

[0269] The command transmission process from payment terminal 200 to user terminal 100 in step S322 and the command execution result transmission process from user terminal 100 to payment terminal 200 in step S324 are performed using APDU packets. That is, transmission and reception of APDU packets is repeatedly performed for each process unit, such as authentication process, balance confirmation process, usage fee debit process, and balance update process.

[0270] The APDU packets used in the command transmission process in step S322 and the command execution result transmission process in step S324 are the following packets previously described with reference to Fig. 19: (a) APDU packet for command transmission (APDU (Type-F) command packet) (b) APDU packet for command execution result transmission (APDU (Type-F) response packet)

[0271] As mentioned above, the APDU packet is a communication packet conforming to the APDU (Application Protocol Data Unit) defined as a packet frame that can be used in UWB communication.

[0272] The following sequentially describes the processing from (Step S322) to (Step S324) in the sequence diagram shown in Fig. 23. (Step S322) In step S322, payment terminal controller 201 of payment terminal 200 generates an APDU packet (APDU (Type-F) command packet) shown in Fig. 19(a) having Type-F commands, such as a command to request execution of authentication processing or a command to request execution of balance confirmation processing, stored in the data section, and transmits the APDU packet to IC card 6 application (AID=31) 121-6, which is a service 3-compatible valid application of user terminal 100.

[0273] Note that a communication connection used for sending and receiving the select command and select response in steps S311 to S315 in Figures 21 and 22 described above is set between payment terminal controller 201 of payment terminal 200 and IC card 6 application (AID=31) 121-6, which is a service 3-enabled application in user terminal 100, and communication is performed using this communication connection. Note that the sending and receiving in steps S311 to S315 may be triggered by step S321 in Figure 23.

[0274] (Step S323) In step S323, the IC card 6 application (AID=31) 121-6, which is a valid application for service 3 of the user terminal 100, analyzes the APDU packet (APDU (Type-F) command packet) shown in FIG. 19(a) received from the payment terminal 200, obtains the Type-F command stored in the data section, and executes processing according to the command.

[0275] (Step S324) In step S324, IC card 6 application (AID=31) 121-6, which is a service 3 compatible valid application of user terminal 100, generates an APDU packet storing the command execution result in step S323 and transmits it to payment terminal 200.

[0276] An APDU packet containing the command execution results generated by IC card 6 application (AID=31) 121-6, which is a service 3 compatible valid application of user terminal 100, is transmitted to payment terminal 200 via UWB communication unit 112 of user terminal 100.

[0277] In this step S324, the APDU packet generated by the IC card 6 application (AID=31) 121-6, which is a service 3 compatible valid application of the user terminal 100, is the command execution result transmission APDU packet (APDU (Type-F) response packet) shown in Figure 19 (b).

[0278] The command execution result (Type-F response) in step S323 is stored in the data section of the command execution result transmission APDU packet (APDU (Type-F) response packet) shown in Figure 19(b). The Type-F response stored in the data section of the APDU (Type-F) response packet is execution result data for the processing unit executed during the payment processing, such as the execution result of the authentication processing or the execution result of the balance confirmation processing.

[0279] In this way, between the payment terminal controller 201 of the payment terminal 200 and the IC card 6 application (AID=31) 121-6, which is a valid application compatible with service 3, in steps S322 to S324 shown in FIG. 23, the APDU packet (APDU (Type-F) command packet) shown in FIG. 19(a) and the APDU packet for transmitting the command execution result (APDU (Type-F) response packet) shown in FIG. 19(b) are repeatedly sent and received to execute a series of processes required for payment processing, such as authentication processing, balance confirmation processing, usage fee debit processing, balance update processing, etc.

[0280] When the series of processes in steps S322 to S324 are completed, the payment terminal controller 201 of the payment terminal 200 confirms the completion of communication processing with the IC card application and data processing required for payment processing or user entry permission confirmation processing, etc., and terminates the processing.

[0281] In addition, if the payment terminal 200 is configured to, for example, control a ticket gate, once the series of processes from steps S322 to S324 are completed, a process is performed to open the gate door, allowing the user to pass through.

[0282] In the processing of this embodiment, a communication path is established between the payment terminal controller 201 of the payment terminal 200 and the IC card 6 application (AID=31) 121-6, which is a service 3-compatible valid application of the user terminal 100, by the sending and receiving processing of the select command and select response in steps S311 to S315 of Figures 21 and 22, and this communication path is used to send the APDU (Type-F) command packet (see Figure 19(a)) sent from the payment terminal controller 201 of the payment terminal 200 to the IC card 6 application (AID=31) 121-6, which is a service 3-compatible valid application of the user terminal 100, to execute the payment processing.

[0283] By performing such processing, it becomes possible to quickly start communication between the service-compatible active app of the user terminal 100 and the payment terminal 200, and it becomes possible to reliably carry out service-compatible payment processing, etc. without delay.

[0284] 6. Configuration for preventing duplicate payment processing, that is, payment processing by the NFC communication unit and payment processing by the UWB communication unit Next, a configuration for preventing duplicate payment processing, that is, payment processing by the NFC communication unit and payment processing by the UWB communication unit, will be described.

[0285] When both the user terminal 100 and the payment terminal 200 communicate using two communication sections, an NFC communication section and a UWB communication section, there is a possibility that the payment terminal 200 will perform double payment processing for one user terminal 100, namely, payment processing using the NFC communication section and payment processing using the UWB communication section.

[0286] The following describes a configuration for preventing such double payments. Fig. 24 is a diagram showing an example in which a user performs a payment process using the payment device at the ticket gate with the user terminal 100 and passes through the ticket gate, and shows the following two examples of payment process execution: (a) Example of payment process execution by NFC communication using the NFC communication unit; (b) Example of payment process execution by UWB communication using the UWB communication unit.

[0287] Figure 24 (a) is an example of payment processing executed by NFC communication using the NFC communication unit. When the user's user terminal 100 is held over the NFC communication unit (reader) 211 of the payment terminal (ticket gate) 200 before entering the UWB communication payment zone, the payment processing is executed by the NFC communication unit 211 before the UWB communication unit 212.

[0288] In contrast, Figure 24 (b) is an example in which payment processing is performed by the UWB communication unit 212 by entering the UWB communication payment zone before payment processing is performed by the NFC communication unit (reader) 211 of the payment terminal (ticket gate) 200.

[0289] When the user terminal 100 enters the UWB communication payment zone, the payment terminal (ticket gate) 200 determines whether the user terminal 100 has completed payment using the NFC communication unit (reader) 211, and if the payment has been completed, it cancels the payment processing using the UWB communication unit 212, and if the payment has not been completed, it executes the payment processing using the UWB communication unit 212.

[0290] Specifically, payment terminal controller 201 of payment terminal (ticket gate) 200 executes the following processing steps S01 to S03.

[0291] (Step S01) In step S01, after the user terminal 100 enters the UWB communication payment zone, the payment terminal controller 201 of the payment terminal (ticket gate) 200 receives the IC card unique identifier (IDm) of the ID card application for payment processing from the user terminal 100 via the UWB communication unit 212.

[0292] (Step S02) In step S02, the payment terminal controller 201 of the payment terminal (ticket gate) 200 performs a comparison process to determine whether the IC card unique identifier (IDm) of the ID card application for payment processing received from the user terminal 100 in step S01 matches the IC card unique identifier (IDm) of the ID card application for payment processing of the user terminal that the payment terminal 200 most recently executed the payment processing.

[0293] (Step S03) In step S03, if the result of the comparison process in step S02 shows that the IC card unique identifier (IDm) of the ID card application for payment processing received from the user terminal 100 in step S01 matches the IC card unique identifier (IDm) of the ID card application for payment processing of the user terminal that executed the payment processing immediately before, the payment terminal controller 201 of the payment terminal (ticket gate) 200 determines that payment via NFC communication for the user terminal has been completed and cancels the payment processing via UWB communication.

[0294] On the other hand, if the IC card unique identifier (IDm) of the ID card application for payment processing received from user terminal 100 in step S01 does not match the IC card unique identifier (IDm) of the ID card application for payment processing of the user terminal that executed the payment processing immediately before, it is determined that payment via NFC communication for the user terminal has not been completed, and payment processing via UWB communication is executed. Note that this processing is based on the determination that the user terminal that executed the payment processing immediately before is a different user terminal of the preceding user.

[0295] This process makes it possible to prevent duplicate payments from being made to the same user terminal. Next, as shown in Figure 25, a payment sequence will be described for when two different users, user a and user b, enter payment terminal (ticket gate) 200 in succession.

[0296] 26 is a sequence diagram showing a payment terminal 200 installed at, for example, a ticket gate at a station on the left and a user terminal 100 such as a smartphone carried by a user passing through the ticket gate on the right, illustrating the communication sequence executed between these devices. Both the payment terminal 200 and the user terminal 100 are configured to be capable of two types of communication: NFC communication and UWB communication.

[0297] The upper right corner of Figure 26 shows an example in which two users a and b pass through a ticket gate using their respective user terminals a, 100a and b, 100b, to perform payment processing by communicating with the payment terminal 200, as previously explained with reference to Figure 25.

[0298] The payment terminal 200 needs to distinguish between the user terminals of each user attempting to pass through the ticket gate in succession, and perform payment processing via NFC communication or UWB communication for each user terminal only once to prevent duplicate payments.

[0299] The sequence diagram shown in Fig. 26 is a sequence diagram illustrating an example of a processing sequence that prevents such duplicate payments. Step S501 and the subsequent steps shown in the sequence of Fig. 26 will be described in order.

[0300] The sequence shown in Figure 26 is a sequence in which user a, who is a preceding user of users a and b who are attempting to pass through the ticket gate consecutively, brings user terminal a, 100a, close to the NFC communication unit 211 of the payment terminal 200 at the ticket gate and performs payment processing via NFC communication.

[0301] (Step S501) Before the processing of step S501, the payment terminal 200 attached to a ticket gate or the like simultaneously performs a discovery process using both the NFC communication unit and the UWB communication unit to detect whether there are any devices (user terminals) in the vicinity that can communicate.

[0302] The NFC communication unit executes a process of detecting a device (user terminal) capable of NFC communication, and the UWB communication unit executes a process of detecting a device (user terminal) capable of UWB communication.

[0303] In step S501, the NFC communication unit 211 of the payment terminal 200 outputs a polling signal via NFC communication, and the user terminal a, 100a of the preceding user a sends the protocol parameters (IDm1, PMm1) of the payment processing execution application (IC card application) of the system code (SC1) to the payment terminal as a polling response.

[0304] This process is a normal NFC communication process for transmitting and receiving a polling signal and a response.

[0305] (Step S502) In step S502, the payment terminal 200 executes payment processing via NFC communication with the payment processing execution IC card application (IDm1, PMm1) corresponding to the system code (SC1) of the user terminal a, 100a. Specifically, a Type-F command sequence is executed.

[0306] The Type-F command sequence is a sequence in which Type-F commands are sent and received via NFC communication to execute processes required for payment processing, such as authentication processing, balance confirmation processing, usage fee withdrawal processing, and balance update processing.

[0307] In step S502, the payment terminal 200 executes a Type-F command sequence with the payment processing execution IC card application (IDm1, PMm1) corresponding to the system code (SC1) of the user terminal a, 100a, to perform the payment processing.

[0308] Furthermore, the payment terminal 200 detects that the user terminal a, 100a, has entered the UWB communication payment zone during this payment processing period.

[0309] (Step S503) When the payment terminal 200 detects that the user terminal a, 100a has entered the UWB communication payment zone, in step S503, the payment terminal 200 transmits a request (SELECT command) to the user terminal a, 100a to communicate with the UWB communication relay application.

[0310] Furthermore, the UWB communication relay application of the user terminal a, 100a sends a SELECT response including protocol parameters (IDm1, PMm1) of the payment processing execution IC card application corresponding to the system code (SC1) of the user terminal a, 100a to the payment terminal.

[0311] (Step S504) Next, in step S504, the payment terminal controller 201 of the payment terminal 200 compares and collates the protocol parameters (IDm1, PMm1) of the payment processing execution IC card application in the SELECT response received from the user terminal a, 100a with the protocol parameters (IDm1, PMm1) of the payment processing completed IC card application recorded in memory.

[0312] The payment terminal controller 201 of the payment terminal 200 confirms that these protocol parameters (IDm1, PMm1) match, and stops the payment process via UWB communication with the user terminal a, 100a. Furthermore, the UWB communication with the user terminal a, 100a is disconnected.

[0313] (Step S505) Thereafter, in step S505, the payment terminal 200 resumes discovery of another device (user terminal).

[0314] This discovery process detects the user terminal b, 100b of the following user b, and the settlement process with the user terminal b, 100b is initiated.

[0315] In this way, if user a brings user terminal a, 100a close to the NFC communication unit 211 of the payment terminal 200 at the ticket gate to perform payment processing via NFC communication, even if user terminal a, 100a then enters a UWB communication payment zone and payment via UWB communication becomes possible, the payment terminal controller 201 of the payment terminal 200 can prevent double payment to user terminal a, 100a by executing the processing of step S504.

[0316] That is, in step S504, the payment terminal controller 201 of the payment terminal 200 compares and collates the protocol parameters (IDm1, PMm1) of the payment processing execution IC card application in the SELECT response received from the user terminal a, 100a with the protocol parameters (IDm1, PMm1) of the payment processed IC card application recorded in memory, confirms that these protocol parameters (IDm1, PMm1) match, determines that the user terminal a, 100a is a terminal that has executed the payment processing, cancels the payment processing via UWB communication, and further disconnects the UWB communication with the user terminal a, 100a.

[0317] These processes can prevent duplicate payments to the user terminals a and 100a.

[0318] Next, another example of a processing sequence that prevents duplicate payments will be described with reference to Fig. 27. As previously described with reference to Fig. 25, the upper right of Fig. 27 shows an example in which two users a and b use their respective user terminals a and 100a and b and 100b to perform payment processing via communication with the payment terminal 200 and pass through a ticket gate.

[0319] The sequence shown in Figure 27 is a sequence diagram when the following processing is executed. First, user a, who is a preceding user of users a and b who are trying to pass through the ticket gate consecutively, brings user terminal a (100a) close to the NFC communication unit 211 of the payment terminal 200 at the ticket gate and performs payment processing by NFC communication. Next, subsequent user b enters the UWB communication payment zone without bringing user terminal b (100b) close to the NFC communication unit 211 of the payment terminal 200 at the ticket gate.

[0320] In this case, since the user terminal b (100b) has not yet executed payment processing via NFC communication, the payment terminal 200 must execute payment processing via UWB communication with the user terminal b (100b). The sequence diagram shown in Figure 27 is a sequence diagram illustrating such processing. Each step from step S521 onwards shown in the sequence of Figure 27 will be explained in order.

[0321] (Step S521) Before the processing of step S521, the payment terminal 200 attached to a ticket gate or the like simultaneously performs a discovery process using both the NFC communication unit and the UWB communication unit to detect whether there are any devices (user terminals) in the vicinity that can communicate.

[0322] The NFC communication unit executes a process of detecting a device (user terminal) capable of NFC communication, and the UWB communication unit executes a process of detecting a device (user terminal) capable of UWB communication.

[0323] In step S521, the NFC communication unit 211 of the payment terminal 200 outputs a polling signal via NFC communication, and the user terminal a, 100a of the preceding user a sends the protocol parameters (IDm1, PMm1) of the payment processing execution application (IC card application) of the system code (SC1) to the payment terminal as a polling response.

[0324] This process is a normal NFC communication process for transmitting and receiving a polling signal and a response.

[0325] (Step S522) In step S522, the payment terminal 200 executes payment processing via NFC communication with the payment processing execution IC card application (IDm1, PMm1) corresponding to the system code (SC1) of the user terminal a, 100a. Specifically, a Type-F command sequence is executed.

[0326] The Type-F command sequence is a sequence in which Type-F commands are sent and received via NFC communication to execute processes required for payment processing, such as authentication processing, balance confirmation processing, usage fee withdrawal processing, and balance update processing.

[0327] In step S522, the payment terminal 200 executes a Type-F command sequence with the payment processing execution IC card application (IDm1, PMm1) corresponding to the system code (SC1) of the user terminal a, 100a, to perform the payment processing.

[0328] Furthermore, the payment terminal 200 detects that the user terminal b, 100b, has entered the UWB communication payment zone during this payment processing period.

[0329] (Step S523) When the payment terminal 200 detects that the user terminal b, 100b has entered the UWB communication payment zone, in step S523, the payment terminal 200 transmits a request for communication with the UWB communication relay application (SELECT command) to the user terminal b, 100b.

[0330] Furthermore, the UWB communication relay application of the user terminal b, 100b sends a SELECT response including protocol parameters (IDm2, PMm2) of the payment processing execution IC card application compatible with the system code (SC1) of the user terminal b, 100b to the payment terminal.

[0331] (Step S524) Next, in step S524, the payment terminal controller 201 of the payment terminal 200 compares and collates the protocol parameters (IDm2, PMm2) of the payment processing execution IC card application in the SELECT response received from user terminal b, 100b with the protocol parameters (IDm1, PMm1) of the payment processed IC card application recorded in memory.

[0332] The payment terminal controller 201 of the payment terminal 200 confirms that these protocol parameters do not match, continues UWB communication with the user terminal b, 100b, and further starts payment processing for the user terminal b, 100b.

[0333] In this way, if user a brings user terminal a, 100a close to the NFC communication unit 211 of the payment terminal 200 at the ticket gate to perform payment processing via NFC communication, and then user terminal b, 100b enters the UWB communication payment zone and payment via UWB communication becomes possible, the payment terminal controller 201 of the payment terminal 200 can distinguish between user terminal a, 100a and user terminal b, 100b by performing the processing of step S524, and can reliably perform payment processing for each.

[0334] That is, in step S524, the payment terminal controller 201 of the payment terminal 200 compares and collates the protocol parameters (IDm2, PMm2) of the payment processing execution IC card application in the SELECT response received from user terminal b, 100b with the protocol parameters (IDm1, PMm1) of the IC card application of user terminal a, 100a for which payment processing has been completed and which are recorded in memory, and confirms that these protocol parameters do not match. It then determines that user terminal b, 100b is a terminal for which payment processing has not been completed, continues UWB communication with user terminal b, 100b, and further executes payment processing for user terminal b, 100b.

[0335] By performing these processes, the user terminals a and 100a and b and 100b can be distinguished from each other and the settlement process can be reliably performed for each.

[0336] 7. Processing sequence when the communication processing device (user terminal) of the present disclosure receives a select command (SELECT command) from a payment terminal] Next, with reference to the flowchart shown in Fig. 28, a processing sequence when the UWB communication relay app of the user terminal 100 receives a select command (SELECT command), which is a communication request from the payment terminal 200, will be described. That is, the flowchart shown in Fig. 28 is a detailed sequence of the processing executed by the user terminal 100 in steps S211 to S224 shown in Figs. 14 to 18. The processing of each step in the flowchart shown in Fig. 28 will be described in order.

[0337] (Step S701) First, in step S701, the user terminal 100 receives a select command (SELECT command) (AID=CNTn) of the service-compatible UWB communication relay application from the payment terminal 200.

[0338] An example of the structure of a UWB communication packet storing this SELECT command has been described above with reference to Fig. 16. The SELECT command is a packet that payment terminal 200 transmits to user terminal 100 to specify an application in the user terminal with which to communicate, and has an APDU-defined packet structure equivalent to the select command (APDU SELECT command) shown in Fig. 16.

[0339] The data section (Data) of this packet stores the AID of the application designated by the payment terminal 200 as the communication partner, that is, in this processing example, the application ID (AID=CNT1) of the service 1 compatible UWB communication relay application 123-1.

[0340] (Step S702) Next, in step S702, the secure element (SE-OS) of the user terminal 100 selects and starts up a service-compatible UWB communication relay application (AID=CNTn).

[0341] (Step S703) Next, in step S703, the service-compatible UWB communication relay application of the user terminal 100 obtains the registration information (protocol parameters: SC, IDm, PMm) of the service-compatible valid IC card application from the service-compatible valid application registration table (= valid application compatible protocol parameter registration table).

[0342] The service-compatible UWB communication relay application refers to the service-compatible valid application registration table (see Figure 10) stored in the memory of the user terminal 100 to obtain the registration information (protocol parameters: SC, IDm, PMm) of the service-compatible valid IC card application.

[0343] (Step S704) Next, in step S704, the service-compatible UWB communication relay application of the user terminal 100 generates a response packet (SELECT response) that stores the registration information (protocol parameters: SC, IDm, PMm) of the service-compatible valid IC card application obtained from the service-compatible valid application registration table (= valid application-compatible protocol parameter registration table), and sends it to the payment terminal 200.

[0344] The SELECT response generated by the service-compatible UWB communication relay application of the user terminal 100 has the packet configuration previously described with reference to Fig. 17. The select response (APDU SELECT response) shown in Fig. 17 also has a packet configuration conforming to the APDU (Application Protocol Data Unit) defined as a packet frame that can be used in UWB communication.

[0345] The service-compatible UWB communication relay application stores in this packet the registration information (protocol parameters) of the valid application (valid IC card application) compatible with service 1, obtained from the service-compatible valid application registration table (see Figure 10) stored in the memory of the user terminal 100.

[0346] That is, the following protocol parameters, which are registration information for service-compatible valid applications (valid IC card applications), are acquired and stored: (a) System code (SCn) (b) IC card unique identifier (IDm) (c) Response time descriptor (PMm) These parameters are registered in the service-compatible valid application registration table described above with reference to FIG. 10, and are protocol parameters related to service-compatible valid applications (valid IC card applications).

[0347] 17 is transmitted to payment terminal 200 via UWB communication unit 112 of user terminal 100. This SELECT response is then input to payment terminal controller 201 via UWB communication unit 212 of payment terminal 200.

[0348] (Step S705) In step S705, the payment terminal 200 obtains the registration information (protocol parameters: SC, IDm, PMm) of the valid IC card application that corresponds to the service from the SELECT response received from the user terminal 100, and performs payment processing by direct communication with the valid IC card application that corresponds to the service using the obtained protocol parameters: SC, IDm, PMm.

[0349] Specifically, the payment terminal controller 201 of the payment terminal 200 analyzes the SELECT response received from the user terminal 100, and initiates communication with a valid application (valid IC card application) that corresponds to the service of the user terminal 100 to perform payment processing.

[0350] All information (protocol parameters) required for communication between the payment terminal 200 and the service-compatible valid application (valid IC card application) of the user terminal 100 can be obtained from the SELECT response received from the user terminal 100, so the payment terminal 200 can communicate with the service-compatible valid application (valid IC card application) of the user terminal 100 and perform payment processing without any problems.

[0351] 8. Hardware Configuration Example of Communication Processing Device Next, a hardware configuration example of a communication processing device that constitutes a user terminal or a payment terminal according to the present disclosure will be described.

[0352] FIG. 29 is a diagram illustrating an example of the hardware configuration of a communication processing device that constitutes a user terminal or a payment terminal according to the present disclosure.

[0353] The hardware configuration shown in Fig. 29 will be described. A CPU (Central Processing Unit) 501 functions as a control unit or data processing unit that executes various processes according to programs stored in a ROM (Read Only Memory) 502 or a storage unit 508. For example, it executes processes according to the sequences described in the above-mentioned embodiments. A RAM (Random Access Memory) 503 stores programs and data executed by the CPU 501. The CPU 501, ROM 502, and RAM 503 are interconnected by a bus 504.

[0354] The CPU 501 is connected to an input / output interface 505 via a bus 504, and an input unit 506 including various switches, a UI, a keyboard, a mouse, a microphone, a camera, etc., and an output unit 507 including a display, a speaker, etc. are connected to the input / output interface 505. The CPU 501 executes various processes in response to commands input from the input unit 506, and outputs the processed results to the output unit 507, for example.

[0355] The storage unit 508 connected to the input / output interface 505 is made up of, for example, a flash memory, a hard disk, etc., and stores various data and programs executed by the CPU 501. The communication unit 509 functions as a transmitter / receiver for data communication via Wi-Fi communication, Bluetooth (registered trademark) (BT) communication, UWB communication, and other networks such as the Internet and a local area network, and communicates with external devices.

[0356] A drive 510 connected to the input / output interface 505 drives a removable medium 511 such as a magnetic disk, an optical disk, a magneto-optical disk, or a semiconductor memory such as a memory card, and executes recording or reading of data.

[0357] [9. Summary of the Configuration of the Present Disclosure] The embodiments of the present disclosure have been described above in detail with reference to specific examples. However, it is obvious that those skilled in the art can modify or substitute the embodiments without departing from the gist of the present disclosure. In other words, the present invention has been disclosed in the form of examples and should not be interpreted as being limited. To determine the gist of the present disclosure, the claims should be taken into consideration.

[0358] The technology disclosed in this specification can be configured as follows: (1) A communication processing device having a communication relay application that generates and transmits, in response to a packet received from an external device, a response packet that stores protocol parameters including a unique identifier of an IC card application that communicates with the external device and executes data processing.

[0359] (2) The communication processing device according to (1), wherein the communication data between the external device and the communication processing device is communication data conforming to a UWB (Ultra Wide Band) communication method, and the communication relay application executes relay processing of the communication data conforming to the UWB communication method.

[0360] (3) The communication processing device according to (2), wherein the external device is a payment terminal that executes payment processing, and the communication processing device is a user terminal that communicates with the payment terminal.

[0361] (4) The communication relay app is a communication relay app corresponding to a service, and when multiple IC card apps that execute payment processing corresponding to the service are stored in the user terminal, the communication processing device described in (3) selects one valid app that executes the payment processing, generates a response packet that stores protocol parameters including a unique identifier of the selected valid app, and transmits the response packet to the payment terminal.

[0362] (5) The communication relay application refers to a service-compatible valid application registration table that registers protocol parameters including unique identifiers of valid applications compatible with each service, generates a response packet that stores protocol parameters including unique identifiers of the valid applications, and transmits the response packet to the payment terminal. (4) The communication processing device described above.

[0363] (6) The communication relay application acquires the protocol parameters (a) to (c) including unique identifiers of valid applications from the service-compatible valid application registration table, (a) a system code (SCn), (b) an IC card unique identifier (IDm), and (c) a response time descriptor (PMm), and generates a response packet storing the acquired protocol parameters and transmits the response packet to the payment terminal. The communication processing device according to (4) or (5).

[0364] (7) The communication processing device according to any one of (4) to (6), wherein the communication relay application stores protocol parameters including a unique identifier of the valid application in an APDU packet conforming to UWB (Ultra Wide Band) specifications and transmits the APDU packet to the payment terminal.

[0365] (8) The communication processing device described in any one of (4) to (7), wherein the user terminal receives a select command from the payment terminal that specifies the communication relay app as a communication partner, and the communication relay app stores a protocol parameter including a unique identifier of the valid app in a select response to the select command and transmits the response to the payment terminal.

[0366] (9) The communication processing device according to (8), wherein the select command and the select response are transmitted and received using an APDU packet defined in UWB (Ultra Wide Band).

[0367] (10) The communication processing device according to any one of (4) to (9), wherein communication between the payment terminal and an IC card application that executes payment processing is performed using APDU packets compliant with UWB (Ultra Wide Band) standards.

[0368] (11) The communication processing device according to any one of (4) to (10), wherein the IC card application receives, from the payment terminal, an APDU packet conforming to UWB (Ultra Wide Band) standards that stores a Type-F command conforming to NFC (Near Field Communication) standards in a data portion, and executes data processing in accordance with the Type-F command.

[0369] (12) The communication processing device according to (11), wherein the IC card application generates an APDU packet conforming to UWB (Ultra Wide Band) specifications, in which a result of data processing according to the Type-F command is stored in a data portion, and transmits the APDU packet to the payment terminal.

[0370] (13) A communication processing system having a user terminal and a payment terminal, wherein the payment terminal transmits a select command to the user terminal specifying the communication relay app of the user terminal as a communication partner, the communication relay app of the user terminal stores a protocol parameter including a unique identifier of a valid app that executes payment processing by communication with the payment terminal in a select response to the select command and transmits the response to the payment terminal, and the payment terminal uses the protocol parameter including the unique identifier of the valid app to communicate with the valid app and executes payment processing.

[0371] (14) The communication processing system according to (13), wherein the communication data between the user terminal and the payment terminal is communication data conforming to a UWB (Ultra Wide Band) communication method, and the communication relay application executes relay processing of the communication data conforming to the UWB communication method.

[0372] (15) A communication control method executed in a communication processing device, wherein the communication processing device has a communication relay application that executes relay processing of communication data according to a UWB (Ultra Wide Band) communication method, and the communication relay application generates and transmits a response packet that stores protocol parameters including a unique identifier of an IC card application that communicates with the external device and executes data processing in response to a packet received from the external device.

[0373] (16) A communication control method executed in a communication processing system having a user terminal and a payment terminal, wherein the payment terminal transmits a select command to the user terminal specifying the communication relay app of the user terminal as a communication partner, the communication relay app of the user terminal stores a protocol parameter including a unique identifier of a valid app that executes payment processing by communication with the payment terminal in a select response to the select command and transmits the response to the payment terminal, and the payment terminal communicates with the valid app using the protocol parameter including the unique identifier of the valid app to execute payment processing.

[0374] (17) A program for causing a communication processing device to execute communication processing, the communication processing device having a communication relay application that executes relay processing of communication data according to a UWB (Ultra Wide Band) communication method, the program causing the communication relay application to execute processing for generating and transmitting a response packet that stores protocol parameters including a unique identifier of an IC card application that executes communication with the external device and data processing, in response to a packet received from the external device.

[0375] Furthermore, the series of processes described in this specification can be executed by hardware, software, or a combination of both. When executing processes by software, a program recording the processing sequence can be installed and executed in the memory of a computer incorporated in dedicated hardware, or the program can be installed and executed on a general-purpose computer capable of executing various processes. For example, the program can be pre-recorded on a recording medium. In addition to installing the program from the recording medium to the computer, the program can also be received via a network such as a LAN (Local Area Network) or the Internet and installed on a recording medium such as an internal hard disk.

[0376] The various processes described in this specification may not only be executed in chronological order as described, but may also be executed in parallel or individually depending on the processing capabilities of the devices executing the processes or as needed. Furthermore, in this specification, a system refers to a logical collective configuration of multiple devices, and is not limited to devices that are all located in the same housing.

[0377] As described above, one embodiment of the present disclosure provides a configuration that enables a user terminal, such as a smartphone, having multiple IC card apps to perform payment processing with a payment device, such as a ticket gate or store terminal, using communication data other than NFC, such as UWB communication. Specifically, for example, the payment terminal sends a select command to the user terminal, specifying the user terminal's communication relay app as the communication partner, and the user terminal's communication relay app stores a protocol parameter including a unique identifier of a valid app that executes payment processing through communication with the payment terminal in a select response to the select command, and sends the response to the payment terminal. The payment terminal communicates with the valid app using the protocol parameter including the unique identifier of the valid app to execute the payment processing. This configuration provides a configuration that enables a user terminal, such as a smartphone, having multiple IC card apps to perform payment processing with a payment device, such as a ticket gate or store terminal, using communication data other than NFC, such as UWB communication.

[0378] DESCRIPTION OF SYMBOLS 10 User terminal 11 IC card application 20 Secure element (SE) 22 Secure memory 31 NFC communication unit 32 Command analysis unit 33 IC card application group 50 Payment terminal 51 Payment terminal controller 52 NFC communication unit 100 User terminal 101 User terminal controller (intra-DH communication control unit) 111 NFC communication unit 112 UWB communication unit 113 BLE communication unit 120 Secure element 121 IC card application group 122 Command analysis unit 123 UWB communication relay application 200 Payment terminal 201 Payment terminal controller 211 NFC communication unit 212 UWB communication unit 213 BLE communication unit 501 CPU 502 ROM 503 RAM 504 Bus 505 Input / output interface 506 Input unit 507 Output unit 508 Storage unit 509 Communication unit 510 Drive 511 Removable media

Claims

1. A communication processing device having a communication relay application that generates and transmits a response packet in response to a packet received from an external device, the response packet storing protocol parameters including a unique identifier of an IC card application that communicates with the external device and performs data processing.

2. The communication processing device according to claim 1, wherein the communication data between the external device and the communication processing device is communication data conforming to a UWB (Ultra Wide Band) communication method, and the communication relay application executes relay processing of the communication data conforming to the UWB communication method.

3. The communication processing device according to claim 2, wherein the external device is a payment terminal that executes payment processing, and the communication processing device is a user terminal that communicates with the payment terminal.

4. The communication processing device according to claim 3, wherein the communication relay application is a communication relay application corresponding to the service, and when the user terminal has stored thereon a plurality of IC card applications that execute payment processing corresponding to the service, the communication processing device selects one valid application that executes the payment processing, generates a response packet that stores protocol parameters including a unique identifier of the selected valid application, and transmits the response packet to the payment terminal.

5. The communication processing device according to claim 4, wherein the communication relay application references a service-compatible valid application registration table in which protocol parameters including unique identifiers of valid applications compatible with each service are registered, generates a response packet storing protocol parameters including unique identifiers of the valid applications, and transmits the response packet to the payment terminal.

6. The communication processing device according to claim 4, wherein the communication relay application acquires the protocol parameters (a) to (c) including unique identifiers of valid applications from the service-compatible valid application registration table: (a) system code (SCn); (b) IC card unique identifier (IDm); and (c) response time descriptor (PMm), and generates a response packet storing the acquired protocol parameters and transmits the response packet to the payment terminal.

7. The communication processing device according to claim 4, wherein the communication relay application stores protocol parameters including a unique identifier of the valid application in an APDU packet conforming to UWB (Ultra Wide Band) specifications and transmits the APDU packet to the payment terminal.

8. The communication processing device described in claim 4, wherein the user terminal receives a select command from the payment terminal that specifies the communication relay app as the communication partner, and the communication relay app stores protocol parameters including the unique identifier of the valid app in a select response to the select command and sends the response to the payment terminal.

9. The communications processing device according to claim 8, wherein the select command and the select response are transmitted and received using APDU packets compliant with UWB (Ultra Wide Band) standards.

10. The communication processing device according to claim 4, wherein communication between the payment terminal and an IC card application that executes payment processing is performed using APDU packets compliant with UWB (Ultra Wide Band) standards.

11. The communication processing device according to claim 4, wherein the IC card application receives from the payment terminal an APDU packet conforming to the UWB (Ultra Wide Band) standard that stores a Type-F command conforming to the NFC (Near Field Communication) standard in the data section, and executes data processing in accordance with the Type-F command.

12. The communications processing device according to claim 11, wherein the IC card application generates an APDU packet conforming to the UWB (Ultra Wide Band) standard, with the result of data processing in accordance with the Type-F command stored in the data section, and transmits the APDU packet to the payment terminal.

13. A communication processing system having a user terminal and a payment terminal, wherein the payment terminal transmits a select command to the user terminal specifying the communication relay app of the user terminal as the communication partner, the communication relay app of the user terminal stores a protocol parameter including a unique identifier of a valid app that executes payment processing by communicating with the payment terminal in a select response to the select command and transmits the response to the payment terminal, and the payment terminal communicates with the valid app using the protocol parameter including the unique identifier of the valid app to execute payment processing.

14. The communication processing system according to claim 13, wherein the communication data between the user terminal and the payment terminal is communication data conforming to the UWB (Ultra Wide Band) communication method, and the communication relay application executes relay processing of the communication data conforming to the UWB communication method.

15. A communication control method executed in a communication processing device, wherein the communication processing device has a communication relay application that executes relay processing of communication data in accordance with a UWB (Ultra Wide Band) communication method, and the communication relay application generates and transmits a response packet that stores protocol parameters including a unique identifier of an IC card application that communicates with the external device and executes data processing in response to a packet received from the external device.

16. A communication control method executed in a communication processing system having a user terminal and a payment terminal, wherein the payment terminal sends a select command to the user terminal specifying the communication relay app of the user terminal as the communication partner, the communication relay app of the user terminal stores a protocol parameter including a unique identifier of a valid app that executes payment processing by communicating with the payment terminal in a select response to the select command and sends the response to the payment terminal, and the payment terminal uses the protocol parameter including the unique identifier of the valid app to communicate with the valid app and execute the payment processing.

17. A program for causing a communication processing device to execute communication processing, the communication processing device having a communication relay application that executes relay processing of communication data in accordance with a UWB (Ultra Wide Band) communication method, the program causing the communication relay application to execute processing for generating and transmitting a response packet that stores protocol parameters including a unique identifier of an IC card application that communicates with the external device and executes data processing, in response to a packet received from the external device.

Images