Method of electronic device providing ranging-based service and electronic device

Abstract

According to an embodiment, a method of providing a ranging-based service, which is performed by an electronic device, can include transmitting information related to service data from a service application installed in the electronic device to a framework, the information related to the service data including a service deployment situation and information about a storage location of the service data; receiving first data from a reader device when the electronic device approaches the reader device; establishing a secure channel with the reader device using information stored in a common applet identified based on the first data, the common applet being installed in a secure component of the electronic device; and transmitting the service data to the reader device based on second data received from the reader device.

Description

Technical Field

[0001] This disclosure relates to an electronic device and a method for providing distance-based services using the electronic device. Background Technology

[0002] The Internet has evolved from a human-centric network of connections through which humans generate and consume information to an Internet of Things (IoT) network that exchanges and processes information among distributed components such as objects. The Internet of Everything (IoE) technology has also emerged, combining big data processing technologies with IoT technologies via connections to cloud servers and the like. To realize the IoT, technological factors such as sensing technologies, wired / wireless communications, network infrastructure, service interface technologies, and security technologies are required. Recent research has focused on connectivity technologies between objects, such as sensor networks, machine-to-machine (M2M) communication, or machine-type communication (MTC).

[0003] In the IoT environment, by collecting and analyzing data generated from connected objects, smart internet technology (IT) services can be provided to create new value for people's lives. IoT can be applied to various fields, such as smart homes, smart buildings, smart cities, smart cars or connected cars, smart grids, healthcare, smart home appliances, or high-tech medical services, through the integration and combination of existing information technology (IT) with various industries.

[0004] As wireless communication systems have evolved to offer a variety of services, an efficient method for providing those services is needed. For example, in Media Access Control (MAC), ranging techniques can be used to measure the distance between electronic devices by using ultra-wideband (UWB). UWB is a wireless communication technology that uses an ultra-wide bandwidth of several GHz or more in the baseband without using a radio carrier. Summary of the Invention

[0005] Technical issues

[0006] There is a need for a method that allows electronic devices that use ranging technology to provide ranging-based services to communicate securely with another electronic device through a secure channel and exchange data quickly and efficiently.

[0007] Solution to the problem

[0008] According to embodiments of this disclosure, a method for providing a ranging-based service performed by an electronic device may include: sending information related to service data from a service application installed in the electronic device to a framework, the information related to the service data including service deployment information and information about the storage location of the service data; receiving first data from a reader device when the electronic device approaches a reader device; establishing a secure channel with the reader device using information stored in a public applet identified based on the first data, the public applet being installed in a security component of the electronic device; and sending the service data to the reader device via the secure channel based on second data received from the reader device. Attached Figure Description

[0009] Figure 1 This illustrates the security threats that may occur when providing universal access services.

[0010] Figure 2 A general digital key management system is shown.

[0011] Figure 3 An example of a data model stored in a small application installed in a security component, according to an embodiment, is shown.

[0012] Figure 4 An example of ranging-based service processing according to an embodiment is shown.

[0013] Figure 5 An example of a data model stored in a small application installed in a security component, according to an embodiment, is shown.

[0014] Figure 6 An example of ranging-based service processing according to an embodiment is shown.

[0015] Figure 7 An example of ranging-based service processing according to an embodiment is shown.

[0016] Figure 8 An application programming interface (API) for setting up service files and sending them from a service application to a framework is shown according to an embodiment.

[0017] Figure 9 An API for notifying a service deployment method and sending data from a service application to a framework, according to an embodiment, is shown.

[0018] Figure 10 This is a flowchart illustrating a method for providing a distance-based service performed by an electronic device according to an embodiment.

[0019] Figure 11 A block diagram of an electronic device according to an embodiment is shown.

[0020] Figure 12 A block diagram of a security component according to an embodiment is shown. Detailed Implementation

[0021] Best mode

[0022] According to one aspect of this disclosure, a method for providing a ranging-based service performed by an electronic device may include: sending information related to service data from a service application installed in the electronic device to a framework, the information related to the service data including service deployment information and information about the storage location of the service data; receiving first data from a reader device when the electronic device approaches a reader device; establishing a secure channel with the reader device using information stored in a public applet identified based on the first data, the public applet being installed in a security component of the electronic device; and sending the service data to the reader device via the secure channel based on second data received from the reader device.

[0023] In embodiments of this disclosure, the service deployment scenario may include at least one of a first scenario, a second scenario, and a third scenario. In the first scenario, the service data is stored in a public applet installed in the security component. In the second scenario, the service data is stored in a traditional applet installed in the security component. In the third scenario, the service data is stored in a service application.

[0024] In embodiments of this disclosure, when the service deployment is the first case, the information regarding the storage location of the service data may include the identifier of a public applet installed in the security component, the first data may include the identifier of the public applet installed in the security component, and the second data may include the tag value of the service data.

[0025] In embodiments of this disclosure, when the service deployment is the second scenario, the information regarding the storage location of the service data may include the identifier of a traditional applet, the first data may include the identifier of a public applet installed in a security component, and the second data may include the identifier of a traditional applet.

[0026] In embodiments of this disclosure, when the service deployment is the third scenario, the information regarding the storage location of the service data may include the identifier of the service application, the first data may include the identifier of a public applet installed in the security component, and the second data may include the identifier of the service application.

[0027] In embodiments of this disclosure, when the service deployment is the second scenario, sending service data to the reader device may include: receiving a command application data unit (APDU) and an identifier of a traditional mini-application from the reader device; sending the command APDU from the framework to the traditional mini-application via a public mini-application; in response to the command APDU, sending a response APDU from the traditional mini-application to the framework via a public mini-application; and sending a response APDU including service data to the reader device.

[0028] In embodiments of this disclosure, when the service deployment is the third scenario, sending service data to the reader device may include: receiving a command application programming interface (API) from the reader device; sending the command API from the framework to the service application; responding to the command API by sending a response API from the service application to the framework; and sending a response API including service data to the reader device.

[0029] In embodiments of this disclosure, the method may further include sending at least one of service file configuration information and key information for establishing a secure channel from the service application to the framework.

[0030] In embodiments of this disclosure, the information stored in a public app and used to establish a secure channel may include parameters and session keys for ultra-wideband (UWB) ranging.

[0031] In embodiments of this disclosure, the method may further include performing ranging by sending to and receiving from the reader device ranging frames comprising scrambled timestamp sequence (STS) codes generated using a session key.

[0032] According to another aspect of this disclosure, an electronic device for providing a ranging-based service may include: a communication interface configured to communicate with a reader device; a security component configured to store information required to establish a secure channel with the reader device; and at least one processor connected to the communication interface and the security component, and configured to execute program instructions stored in a memory to perform the following steps: sending information related to service data from a service application installed in the electronic device to a frame, the information related to the service data including service deployment information and information about the storage location of the service data; controlling the communication interface to receive first data from the reader device when the electronic device approaches the reader device; establishing a secure channel with the reader device by using information stored in a public applet identified based on the first data, the public applet being installed in the security component; and controlling the communication interface to send service data to the reader device based on second data received from the reader device.

[0033] In embodiments of this disclosure, when the service deployment is a first case where the service data is stored in a public applet installed in a security component, the information about the storage location of the service data may include an identifier of the public applet installed in the security component, the first data may include the identifier of the public applet installed in the security component, and the second data may include the tag value of the service data.

[0034] In embodiments of this disclosure, when the service deployment is the second case where service data is stored in a legacy app installed in a security component, information about the storage location of the service data may include an identifier of the legacy app, the first data may include an identifier of a public app installed in the security component, and the second data may include an identifier of the legacy app.

[0035] In embodiments of this disclosure, when the service deployment is a third scenario where service data is stored in a service application, information about the storage location of the service data may include an identifier of the service application, the first data may include an identifier of a public applet installed in a security component, and the second data may include an identifier of the service application.

[0036] According to another aspect of this disclosure, a computer-readable recording medium having thereon recorded a program for performing a method for providing a ranging-based service executed by an electronic device is provided, wherein the method includes: sending information related to service data from a service application installed in the electronic device to a frame, the information related to the service data including service deployment information and information about the storage location of the service data; receiving first data from a reader device when the electronic device approaches the reader device; establishing a secure channel with the reader device using information stored in a public applet identified based on the first data, the public applet being installed in a security component of the electronic device; and sending the service data to the reader device via the secure channel based on second data received from the reader device.

[0037] Open mode

[0038] In the following, embodiments of the present disclosure will be described in detail with reference to the accompanying drawings to enable those skilled in the art to perform the disclosure without difficulty. However, the present disclosure may be embodied in many different forms and should not be construed as limited to the embodiments described herein. Furthermore, for the sake of clarity in describing the present disclosure, portions unrelated to the description have been omitted, and similar reference numerals have been assigned to similar elements throughout the specification.

[0039] Although the terms used herein are generally used and chosen in consideration of their function, the meanings of the terms may vary depending on the intent of those skilled in the art, legal precedent, or the emergence of new technologies. Therefore, these terms should not be defined by their simple expression, but rather on their meaning and the context in which they are defined throughout this disclosure.

[0040] Furthermore, terms such as "first" or "second" may be used to describe various elements, but these elements should not be limited by these terms. These terms are only used to distinguish one element from another.

[0041] Furthermore, the terminology used herein is for describing specific embodiments and is not intended to limit the scope of this disclosure. Singular expressions also include plural meanings, provided they are not contradictory to the context. Additionally, throughout this specification, when a component is referred to as being "connected to" another component, it can be "directly connected to" the other component or "electrically connected to" the other component via an intermediate element. Furthermore, when an element is referred to as "comprising" a component, the element can additionally include other components, rather than exclude them, unless specifically stated otherwise.

[0042] As used herein, the term "the" and other similar designations may include both singular and plural forms. Furthermore, when the order of operations according to the method of this disclosure is not explicitly specified in the description, the operations may be performed in an appropriate order. This disclosure is not limited to the order of the described operations.

[0043] As used herein, the term "key" refers to a digitized virtual key that a user can use to control or access a device. This disclosure relates to a method for providing ranging-based services using a key, and hereinafter, the term "key" may be referred to as a "digital key," a "smart key," or a "session key."

[0044] As used herein, phrases such as “in an embodiment” do not necessarily refer to the same embodiment of this disclosure.

[0045] Embodiments of this disclosure can be represented by block components and various processing operations. All or some of these functional blocks can be implemented by a variety of hardware and / or software components performing a specific function. For example, the functional blocks of this disclosure can be implemented using one or more microprocessors, or by using circuit elements for the intended function. For example, the functional blocks of this disclosure can be implemented using various programming or scripting languages. Functional blocks can be implemented as algorithms executed by one or more processors. Furthermore, this disclosure can employ related techniques for electronic configuration, signal processing, and / or data processing, etc.

[0046] Furthermore, the connecting lines or components shown in the diagram are merely examples of functional and / or physical or electrical connections. In actual devices, connections between components can be represented by a variety of replaceable or addable functional, physical, or electrical connections.

[0047] Generally, wireless network technologies are mainly divided into Wireless Local Area Network (WLAN) and Wireless Personal Area Network (WPAN) technologies based on their recognition range. Here, WLAN based on IEEE 802.11 is a technology for accessing the backbone network within a 100m radius. In addition, WPAN based on IEEE 802.15 includes Bluetooth, ZigBee, and Ultra Wideband (UWB), among others.

[0048] UWB can refer to a short-range, high-speed wireless communication technology using a wide bandwidth of several GHz or more, low spectral density, and short pulse width (1 to 4 nanoseconds (nsec)) in baseband mode, or it can directly refer to the frequency band in which UWB communication is applied. The following describes methods for providing ranging-based services between electronic devices using UWB communication schemes; however, these are merely examples, and various wireless communication methods can be applied to the methods of providing ranging-based services disclosed herein.

[0049] Electronic devices according to embodiments of this disclosure may include fixed or mobile terminals implemented as computer devices, and may communicate with other devices and / or servers using wireless or wired communication schemes. For example, electronic devices may include, but are not limited to, smartphones, mobile terminals, laptop computers, digital broadcasting terminals, personal digital assistants (PDAs), portable multimedia players (PMPs), navigation systems, touchscreen personal computers (PCs) (SlatePCs), tablet PCs, digital televisions (TVs), desktop computers, refrigerators, projectors, automobiles, smart cars, digital door locks, printers, etc.

[0050] Various embodiments of this disclosure relate to techniques for media access control (MAC) based on device-to-device (D2D) communication.

[0051] D2D communication refers to a method of direct communication between geographically adjacent electronic devices without using infrastructure such as base stations. The electronic devices can communicate in a one-to-one, one-to-many, or many-to-many manner. Unlicensed frequency bands, such as Wi-Fi Direct, UWB, and Bluetooth, can be used in D2D communication. Alternatively, licensed frequency bands can be used to improve the frequency utilization efficiency of cellular systems. Although D2D communication is limited to machine-to-machine (M2M) communication or machine-to-machine intelligent communication, in this disclosure, D2D communication refers not only to communication between electronic devices with communication capabilities but also to communication between various types of electronic devices with communication capabilities, such as smartphones or personal computers.

[0052] Various embodiments of this disclosure relate to the aforementioned D2D communication-based MAC and require measuring the distance between electronic devices for MAC purposes. In this case, UWB ranging technology can be used to measure the distance between electronic devices. For example, when using a digital key stored in a user terminal to open and close a vehicle door (or front door), the vehicle (or door lock) can perform a secure ranging with the user terminal using the digital key, and measure the distance between the user terminal and the vehicle (or door lock) based on the result of the secure ranging. The vehicle (or door lock) can determine whether the vehicle door (or front door) is open / closed based on the distance to the user terminal. In this disclosure, the term "access service" which provides various services as electronic devices approach each other can be used with the same meaning as "range-based service" which uses ranging technology to measure the distance between electronic devices and provides various services based on the measured distance.

[0053] This disclosure will be described in detail below with reference to the accompanying drawings.

[0054] Figure 1 This illustrates the security threats that may occur when providing access services.

[0055] like Figure 1 As shown, legitimate user 10 and reader device 20 can perform authentication and ranging using D2D communication. In this scenario, when the access service providing system relies on the ranging results of legitimate user 10 and reader device 20 without using a key to guarantee the authentication of legitimate user 10, a security attack is possible. Specifically, attacker 30 can attack the ranging process by recording signals sent from legitimate user 10 and replaying those signals on reader device 20. By replaying the recorded signals, attacker 30 can deceive reader device 20 into believing that legitimate user 10 is within the permitted access range, thereby gaining access to reader device 20.

[0056] Therefore, it may be necessary to configure security protocols based on pre-shared keys to reduce potential security threats when providing access services. According to pre-shared key-based security protocols, ranging security levels can be improved by exchanging encrypted data using pre-shared keys.

[0057] Each access service provider can have a unique method for generating secure channels based on symmetric keys to protect security. Therefore, the security key used to generate secure channels is considered a core asset that should not be shared with other entities (e.g., other access service providers, other enterprises, or other servers).

[0058] To securely provide access services based on mobile devices, the mobile device stores important information (e.g., keys for generating secure channels) in its secure components (e.g., secure elements or trusted execution environments (TEEs)). A TEE can refer to a secure execution environment provided by a secure region within a processor, where the normal and secure regions are separated from each other.

[0059] A communication scheme using secure channels is a method that allows mobile devices to securely access services, and it is necessary to generate fast and secure sessions without exposing the key values ​​used to protect the corresponding communication parts to the outside world.

[0060] For example, to achieve secure ranging using a UWB communication scheme, key UWB parameters, including the UWB session key, can be exchanged via a Bluetooth-level secure channel.

[0061] Figure 2 A general digital key management system is shown.

[0062] Company A's backend server 21 can issue keys and store them in a secure area 203 within the security component 210 of the mobile device 200. In this case, only a dedicated application 201 provided by Company A can access the secure area 203, where a small application (or trusted application (TA) provided by Company A) is installed, and use the stored key.

[0063] The security component 210 of the mobile device 200 can establish a secure channel with the device 23 that provides access services related to Company A by using a key stored in the secure area 203, and perform secure communication through the established secure channel.

[0064] Meanwhile, Company B's backend server 22 can issue a separate key and store that separate key in a separate secure area 204 within the security component 210 of the mobile device 200. Only a dedicated application 202 provided by Company B can access the secure area 204, where a small application (or TA) provided by Company B is installed, and use the stored key.

[0065] The security component 210 of the mobile device 200 can establish a secure channel with the device 24 that provides access services related to Company B by using a key stored in the secure area 204, and perform secure communication through the established secure channel.

[0066] like Figure 2 As shown, applications or mini-applications provided by a regular access service provider (or a backend server providing the access service) independently establish communication channels with the other device and connect to it independently through these channels to exchange UWB-related parameters or send service-related data. For example, electronic device 200 can exchange UWB-related parameters or send service-related data via Bluetooth Low Energy (BLE) module 205. Because Company A and Company B manage separate keys using mini-applications installed in separate security zones, application 202 provided by Company B cannot access Company A's mini-application in security zone 203 created by Company A's backend server 21. Therefore, Company A and Company B can each protect their security by using mini-applications installed in separate security zones. However, in the aforementioned related technologies, since each access service establishes its own security channel, delays may occur, and data exchange efficiency may be reduced.

[0067] This disclosure provides a method for securely transmitting at least one of UWB-related parameters or service-related data via a secure channel established with a peer device by a public applet in mobile device 200 (e.g., a FiRa applet based on a standard document defined by the FiRa Alliance). Furthermore, according to various embodiments of this disclosure, a method is provided in which an access service providing application sends information to a framework regarding the deployment of supported services and necessary parameters, and the framework supports the access service based on the information sent.

[0068] Therefore, according to various embodiments of this disclosure, multiple access services are allowed to share a secure channel between two devices, thereby reducing the latency required to establish a secure channel and improving data exchange efficiency.

[0069] The ranging-based service provided in this disclosure can be implemented according to various embodiments based on the method of using applets in a security component and the location of storage service application data. According to a first embodiment, a public applet in the security component can manage all basic data, including data related to secure ranging, as well as service application data.

[0070] According to the second and third embodiments, the public applet in the security component can be used to enhance existing applications by using secure ranging via UWB. According to the second and third embodiments, the public applet in the security component is used to establish a UWB session, but the application's own data transactions can be performed outside the public applet. However, the public applet can be used to provide a secure channel between two devices. The public applet can be used to provide a secure channel between two devices, enabling the devices to exchange UWB session parameters, and service-related transactions based on ranging are bound to the UWB session.

[0071] According to an embodiment, a public applet within the security component can be used to establish UWB sessions and support service application data. The public applet, according to the embodiment, can manage UWB secure ranging functionality and maintain service application data. Figure 3 An example of the data model used according to this embodiment is shown.

[0072] Figure 3 An example of a data model stored in a public applet installed in a security component, according to an embodiment, is shown.

[0073] An Application-Specific File (ADF) owned by the access service provider may include service application-specific service data. According to an embodiment, the service data may be stored in a security component. When a service transaction occurs, the reader device can retrieve the service data from the security component. In this case, a tag value indicating service application-specific service data can be determined based on a ranging-based service-related standard (e.g., the FiRa service standard).

[0074] For example, in the case of physical access control services, service data can be access credentials. Therefore, a reader device (e.g., a door lock) can retrieve access credentials from an access credential device (e.g., a user terminal) and perform an authentication process with the electronic device based on the retrieved access credentials.

[0075] In the following text, reference will be made to Figure 4 Description of use according to embodiments Figure 3 The process by which the data model-based service provision system exchanges distance-based service-related data. Figure 4 An example of ranging-based service processing according to an embodiment is shown.

[0076] Before describing the ranging-based service processing according to the embodiments, the structure of the ranging-based service provision system will be described.

[0077] First, install Figure 4The service application 410 in the electronic device 400 is an application that provides ranging-based services and can be connected to the UWB subsystem 450 via frame 420. Furthermore, the service application 410 can use out-of-band (OOB) module 440 to establish a service-specific OOB connection to a peer device. The OOB connection can be used to negotiate configuration information for the ranging session with the peer device. For example, the OOB connection may include a connection using a BLE communication scheme, a connection using a near-field communication (NFC) communication scheme, or any other available connection between the two devices.

[0078] Framework 420 can be an application that supports ranging-based services. Framework 420 can manage the UWB configuration information and OOB configuration information required to successfully establish a UWB session with a peer device, establish an OOB connection with the peer device, interact with the security component 430, and interact with the UWB subsystem 450. For example, framework 420 can be a system development kit (SDK) installed on the Android operating system.

[0079] Framework 420 can provide an application programming interface (API) for external entities (e.g., access service provider servers, company-specific backend servers, etc.) to access security component 430 through service application 410, and can provide functions such as access control and command translation for accessing security component 430.

[0080] OOB module 440 may be a communication module configured to establish an OOB connection with reader device 460, and UWB subsystem 450 may be a communication module configured to perform secure ranging with reader device 460.

[0081] The security component 430 may be hardware connected to the UWB subsystem 450 to send data for UWB ranging to the UWB subsystem 450.

[0082] In the security component 430 of the electronic device 400 according to the embodiment, a public applet for providing distance-based services and managing data related to safe distance measurement can be installed.

[0083] According to an embodiment, the access service provider (or the backend server providing the access service) can store important information (such as an ADF) in a public applet 470 within the security component 430 via framework 420. The ADF may include at least one of UWB session key, UWB capability information, and service data.

[0084] According to an embodiment, the electronic device 400 can perform secure communication and secure ranging with the reader device 460 based on information included in the ADF stored in the public applet 470. The reader device 460 may be, for example, a device that provides physical access services, such as a door lock.

[0085] Electronic device 400 can use OOB module 440 to perform secure communication with reader device 460 via, for example, NFC, BLE, or other connectivity schemes. For example, electronic device 400 can perform mutual authentication with reader device 460 via OOB module 440, and based on the mutual authentication, send the UWB session key or information related to the UWB session key stored in public applet 470 to reader device 460 via OOB module 440. Furthermore, according to the embodiment, electronic device 400 can use the UWB session key or information related to the UWB session key for UWB secure ranging with reader device 460. For example, electronic device 400 can generate a scrambled timestamp sequence (STS) code using the UWB session key stored in public applet 470 or information related to the UWB session key, and perform UWB secure ranging based on the generated STS code. (Refer to above) Figure 4 The descriptions of the various components of the provided electronic device 400 can also be applied to Figure 6 Electronic devices 600 and Figure 7 The electronic device 700, and the description provided above will be omitted.

[0086] like Figure 4 As shown, according to embodiments of this disclosure, an ADF including service data can be stored in a public applet of a security component. According to an embodiment, in operation S401, service application 410 can notify framework 420 that service application data (i.e., service data) is maintained in public applet 470. The API used to notify the public applet 470 of the maintenance of service application data may include at least one of an identifier AID indicating public applet 470, service ADF, a tag value of the service application data, and a value of the service application data.

[0087] When the electronic device 400 approaches the reader device 460, during operation S402, the reader device 460 can send an Application Data Unit (APDU) including the identifier of the public applet 470 (i.e., Select (Public Applet AID)) to select the public applet 470. Furthermore, the reader device 460 can send an APDU including the tag value of the ADF or service data (i.e., Get Data (Application ADF / Service Data Tag)) to retrieve data.

[0088] Electronic device 400 can establish a secure channel with reader device 460 using information included in the ADF (Application Function Data) in public app 470. Electronic device 400 can identify service data stored in public app 470 based on service tag values ​​received from reader device 460, and send the service data to reader device 460 through the established secure channel. Based on the sent service data, mutual authentication between electronic device 400 and reader device 460 can be performed.

[0089] Electronic device 400 can perform mutual authentication via OOB module 440 and negotiate UWB capability parameters and UWB session keys between security component 430 and reader device 460. After negotiation, the UWB capability parameters and UWB session keys can be stored in public applet 470. By using the ADF stored in public applet 470, UWB subsystem 450 can trigger a UWB secure ranging session. Electronic device 400 can generate an STS code using the UWB session key stored in public applet 470 and perform UWB secure ranging based on the generated STS code.

[0090] For example, according to Figure 4 In the illustrated embodiment, service application 410 may support the following APIs.

[0091] FiRa service deployment (1. Service data label, service data value)

[0092] Service application 410 can send this API to framework 420 to notify framework 420 to operate according to deployment 1, and send the service data tags and service data values ​​to framework 420. This API can... Figure 4 The operation is sent in S401. However, this embodiment is not limited to... Figure 4 The example shown illustrates this, and the API can send data in various operations (e.g., key supply operations) depending on the implementation method.

[0093] In addition, service application 410 can also send the identifier AID of the public applet storing service data to framework 420. (See below for reference.) Figure 9 Describe the API in more detail.

[0094] Meanwhile, according to another embodiment, a public applet in the security component is used to establish a UWB session, but the data transactions of the application itself can be performed outside the public applet. Figure 5 It shows the basis with Figure 3 and 4 The embodiments shown are different examples of data models stored in a small application installed in a security component.

[0095] like Figure 5 As shown, the public app 500 in the security component according to the embodiment can maintain an ADF, which includes a UWB session key 512 and UWB capability-related parameters 511 for establishing a UWB secure ranging session. Figure 5 The example shown is the same as Figure 3 The difference in the example shown is that service data 513 is maintained in a conventional applet 501. Service data 513 maintained in conventional applet 501 can be sent via a secure channel established between public applets. Conventional applet 501 can refer to a unique applet provided by each service application, which differs from the new public applets proposed in this disclosure.

[0096] According to an embodiment, in order to send the APDU of the legacy applet 501 to the reader device, API FiRa_TUNNEL_REQ (APDU) and FiRa_TUNNEL_RES (APDU) can be processed by the framework and sent and received between the common applets in the framework and the security component.

[0097] In the following text, reference will be made to Figure 6 Description of usage according to embodiments as follows Figure 5 The data model shown illustrates the process for exchanging service-related data based on ranging. Figure 6 An example of ranging-based service processing according to an embodiment is shown.

[0098] Figure 6 The illustrated embodiments and Figure 4 The difference in the illustrated embodiment lies in the internal parameters of the API message sent from service application 610 to framework 620. Furthermore, the difference in the embodiment lies in the messages sent in operations S603, S604, S605, S606, and S607.

[0099] First, in operation S601, service application 610 can notify framework 620 that it needs to send service data from legacy app 680 in security component 630 via a secure channel. The API sent from service application 610 to framework 620 needs to be sent together with the AID value of legacy app 680.

[0100] In operation S602, when the electronic device 600 approaches the reader device 660, in order to select the common app 670 in the security component 630, the reader device 660 may send an APDU including the identifier of the common app 670 (i.e., selection (common app AID)), an APDU for selecting the ADF (i.e., selection (ADF)), and an APDU for mutual authentication. The reader device 660 can establish a secure channel by using the ADF in the common app 670.

[0101] In operation S603, reader device 660 sends a command APDU (C-APDU) along with an APDU for selecting legacy app 680 (i.e., selection (legacy app AID)) to legacy app 680 via OOB module 640.

[0102] In operation S604, the framework 620 sends the APDU command FIRA_TUNNEL_REQ() to the public small application 670.

[0103] In operation S605, the public application 670 sends the C-APDU received from the frame 620 to the traditional application 680.

[0104] In operation S606, the legacy application 680 sends a response APDU (R-APDU) to the public application 670 in response to the C-APDU.

[0105] In operation S607, public application 670 can send R-APDU and service application data to framework 620 by using FIRA_TUNNEL_RES().

[0106] During operation S608, frame 620 sends R-APDU to reader device 660. Based on the service application data sent via R-APDU, mutual authentication between electronic device 600 and reader device 660 can be performed.

[0107] After negotiating the UWB capability parameters and UWB session key between the security component 630 and the reader device 660 via the OOB module 640, the UWB capability parameters and UWB session key can be maintained in the public applet 670. The UWB subsystem 650 can trigger a UWB secure ranging session by using the ADF maintained in the public applet 670.

[0108] according to Figure 6 In the embodiment shown, service application 610 needs to support the following APIs.

[0109] FiRa service deployment (2, AID for traditional small applications)

[0110] Service application 610 can send an API to framework 620 to notify framework 620 to operate according to deployment scenario 2, and send the identifier AID of legacy app 680 to framework 620. The API can be sent in operation S601. However, this embodiment is not limited to... Figure 6 The example shown illustrates this, and the API can send data in various operations (e.g., key supply operations) depending on the implementation method.

[0111] In addition, service application 610 can also send the identifier AID of the public applet storing storage service data to framework 620. See below for reference. Figure 9 Describe the API in more detail.

[0112] according to Figure 6 In the illustrated embodiment, because the service data resides in legacy app 680, when reader device 660 selects legacy app 680 and sends a C-APDU, framework 620 needs to send the APDU to public app 670 using FIRA_TUNNEL_REQ() as described below. The following APIs need to be supported between framework 620 and public app 670.

[0113] FIRA_TUNNEL_REQ(APDU)

[0114] The API's function is to send APDUs from public applet 670 to traditional applet 680 selected by reader device 660.

[0115] FiRa_TUNNEL_RES(APDU)

[0116] In addition, the API's role is to send APDUs from traditional applets 680 to frameworks 620 via public applets 670.

[0117] Meanwhile, according to another embodiment, a public applet in the security component is used to establish a UWB session, but the application's own data transactions can be performed outside the security component.

[0118] Figure 7 An example of ranging-based service processing according to an embodiment is shown.

[0119] like Figure 7 As shown, the public applet 770 in the security component 730 according to the embodiment can maintain UWB session keys and UWB capability-related parameters, and can establish a secure channel. Figure 7 The example shown is the same as Figure 6 The difference in the example shown is that the service data is held in the service application 710 on the host, rather than in the security component 730. Therefore, the secure channel established via the public applet 770 can be used only to send UWB session-related parameters (e.g., UWB session keys, UWB capability parameters, etc.) and not service data. Service data can be sent via a non-secure channel.

[0120] Several APIs for personalized service applications can be used to manipulate the ADF in public applet 770. For example, the key used to establish a secure channel can be inserted into security component 730 by service application 710.

[0121] Figure 7 The service data transaction processing from service application 710 on the host is shown, which is the application processor.

[0122] According to an embodiment, in order to send an API for service application 710 to reader device 760, command API (C-API) in the form of FiRa_TUNNEL_REQ (API) and response API (R-API) in the form of FiRa_TUNNEL_RES (API) can be processed by framework 720 and sent and received between service application 710 and framework 720.

[0123] When the service application data transaction is successfully completed, the framework 720 can trigger the start of the UWB session.

[0124] Figure 7 The illustrated embodiments and Figure 4 and Figure 6 The illustrated embodiment differs in that the message sent from service application 710 to frame 720 does not transmit service data, but only informs frame 720 of the identifier of service application 710. Monitor 721 in frame 720 can continuously monitor whether a message indicating the ID of service application 710 has been sent from reader device 760. When a message indicating the ID of service application 710 is sent from reader device 760, frame 720 can send a C-API (i.e., a command targeting service data) to service application 710.

[0125] Figure 7 The illustrated embodiments and Figure 4 and Figure 6 The difference in the illustrated embodiment lies in the internal parameters of the API message sent from service application 710 to frame 720. Furthermore, the difference lies in the messages sent in operations S703, S704, and S705, and the addition of monitoring entity 721 to frame 720.

[0126] In operation S701, service application 710 can notify framework 720 that service data is stored in service application 710 by using the following API.

[0127] FiRa Service Deployment (3, AID of FiRa Service Applications)

[0128] Service application 710 can send an API to framework 720 to notify framework 720 to operate according to deployment scenario 3, and send the ID of service application 710 to framework 720. The API can... Figure 7 The operation is sent in S701. However, this embodiment is not limited to... Figure 7The example shown illustrates this, and the API can send data in various operations (e.g., key supply operations) depending on the implementation method. See below for reference. Figure 9 A more detailed description of the API.

[0129] In operation S702, reader device 760 can send APDU for establishing a secure channel to electronic device 700 by using ADF in public applet 770 in security component 730.

[0130] In detail, when the electronic device 700 approaches the reader device 760, in order to select the common applet 770 in the security component 730, the reader device 760 may send an APDU including the identifier of the common applet 770 (i.e., select (common applet AID)), an APDU for selecting the ADF ADF (i.e., select (ADF)), and an APDU for mutual authentication.

[0131] In operation S703, reader device 760 sends a C-API and an API for selecting service application 710 (i.e., selection (application ID)) to OOB module 740 of electronic device 700. When the C-API for service application data transactions is sent from reader device 760 to frame 720 via OOB module 740, the C-API is sent to service application 710.

[0132] After the service application 710 processes the C-API, in operation S705, the service application 710 sends an R-API, including the processing result, to the frame 720. In operation S706, the R-API, along with the service application data, is sent from the frame 720 to the reader device 760. Based on the sent service application data, mutual authentication between the electronic device 700 and the reader device 760 can be performed.

[0133] After negotiating the UWB capability parameters and UWB session key between the security component 730 and the reader device 760 via the OOB module 740, the UWB capability parameters and UWB session key are maintained in the public applet 770. The UWB subsystem 750 can trigger a UWB secure ranging session by using the ADF maintained in the public applet 770.

[0134] According to the various embodiments of this disclosure described above, a service application may support at least one of the APIs described below in order to notify the framework for the service application of file information. Configuration parameters for the APIs described below need to be sent to the framework supporting the corresponding service. Configuration parameters may include application configuration parameters for UWB session establishment as described in the UWB Command Interface (UCI) General Specification (e.g., paragraph 6.2 of the UCI General Specification). Configuration parameters may also include parameters related to BLE communication.

[0135] first, Figure 8 API 810, according to an embodiment, is shown for setting up service files and sending them from the service application to the framework.

[0136] like Figure 8 As shown, API 810 for setting service files may include parameters indicating whether the electronic device's role is that of a scanner or a promoter, and parameters indicating whether the role of the service to be provided is that of a server or a client. However, the values ​​of the API parameters used according to various embodiments of this disclosure are not limited to... Figure 8 The example shown.

[0137] Secondly, service applications installed on electronic devices can use APIs to provide keys to security components. These keys can then be used to establish secure channels between the security components of the electronic device and the corresponding security components of the device.

[0138] third, Figure 9 An API for notifying a service deployment method and sending data from a service application to a framework, according to an embodiment, is shown.

[0139] like Figure 9 As shown, API 910 for notifying service deployment methods may include parameters indicating service deployment status, parameters indicating service data storage location, and parameters indicating service data values.

[0140] The parameters indicating the service deployment status can indicate which of the following deployment statuses—Deployment Status 1, Deployment Status 2-A, and Deployment Status 2-B—the service application uses. In this disclosure, Deployment Status 2-A and Deployment Status 2-B can be referred to as Deployment Status 2 and Deployment Status 3, respectively.

[0141] Deployment scenario 1 can be used in situations where public applets in the security component are used not only to establish UWB sessions but also to support service application data. Figure 4 The operation process is shown according to deployment scenario 1.

[0142] Deployment Scenario 2-A can be used when applications (or applets) within a security component utilize secure ranging over UWB. For example, in Deployment Scenario 2-A, service application data can be maintained within a traditional applet within the security component. Figure 6 The operational process is shown according to deployment scenario 2-A.

[0143] Deployment scenario 2-B can be used when applications on the host utilize secure ranging over UWB. For example, in deployment scenario 2-B, service application data can be maintained within the service application outside the security component. Figure 7 The operational process is shown according to deployment scenario 2-B.

[0144] When operating in Deployment Scenario 1, the parameter indicating the service data storage location can be the AID of the public mini-application, the ADF of the application's service provider, and the tag value of the service data. Alternatively, when operating in Deployment Scenario 2-A, the parameter indicating the service data storage location can be the AID of the traditional mini-application. Alternatively, when operating in Deployment Scenario 2-B, the parameter indicating the service data storage location can be the ID of the service application.

[0145] Figure 10 This is a flowchart illustrating a method for providing a distance-based service performed by an electronic device according to an embodiment.

[0146] In operation S1010, the electronic device according to embodiments of the present disclosure can send service data-related information from a service application installed in the electronic device to a framework. The service data-related information may include service deployment details and information about the storage location of the service data.

[0147] The service deployment scenario may include at least one of the following: scenario 1, scenario 2, and scenario 3. In scenario 1, the service data is stored in a public applet installed in the security component (i.e., deployment scenario 1). In scenario 2, the service data is stored in a traditional applet installed in the security component (i.e., deployment scenario 2-A). In scenario 3, the service data is stored in a service application (i.e., deployment scenario 2-B).

[0148] When the service deployment scenario is the first scenario, information about the storage location of the service data may include the identifier of the public applet installed in the security component. When the service deployment scenario is the second scenario, information about the storage location of the service data may include the identifier of the traditional applet. When the service deployment scenario is the third scenario, information about the storage location of the service data may include the identifier of the service application.

[0149] Furthermore, the electronic device according to the embodiment can also send at least one of service file configuration information and key information for establishing a secure channel from the service application to the framework.

[0150] In operation S1020, when the electronic device approaches the reader device, the electronic device can receive first data from the reader device. The first data may include the identifier of a public applet installed in the security component. For example, the electronic device can receive an APDU (i.e., Select (Apple Applet ID)) that includes the identifier of the public applet by using NFC or BLE communication schemes.

[0151] In operation S1030, the electronic device according to embodiments of the present disclosure can establish a secure channel with the reader device by using information stored in a public applet based on first data identification. The public applet may be an applet installed in the security component of the electronic device and used by multiple service applications for establishing the secure channel.

[0152] The information stored in the public app for secure channel establishment can be an ADF, which includes parameters for UWB ranging (e.g., UWB capability parameters) and a session key.

[0153] In operation S1040, the electronic device according to embodiments of the present disclosure can send service data to the reader device via a secure channel (or insecure channel) based on second data received from the reader device. For example, the electronic device can send service data to the reader device using NFC or BLE communication schemes.

[0154] When the service deployment is the first scenario (i.e., the service data is stored in a public applet within a secure component), the second data may include the tag value of the service data. The electronic device can identify the ADF corresponding to the tag value from the public applet based on the tag value received from the reader device, and establish a secure channel with the reader device using the identified ADF. In this case, the service data can be sent to the reader device through the secure channel established by the public applet.

[0155] When the service deployment is the second scenario (i.e., the service data is stored in a traditional applet within the security component), the second data may include the identifier of the traditional applet. The electronic device can receive a C-APDU and the identifier of the traditional applet from the reader device, and send the C-APDU from the framework to the traditional applet via the public applet within the security component. In response to the C-APDU, the security component of the electronic device can send an R-APDU from the traditional applet to the framework via the public applet. The electronic device can send an R-APDU including service data to the reader device. In this case, the service data can be sent to the reader device via a secure channel established by the public applet.

[0156] When the service deployment scenario is the third scenario (i.e., the service data is stored in a service application outside the security component), the second data may include the service application's identifier. The electronic device can receive a C-API and the service application's identifier from the reader device and send the C-API from the framework to the service application. In response to the C-API, the electronic device's service application can send an R-API to the framework. The electronic device can send an R-API including service data to the reader device. In this case, the service data resides outside the security component and can therefore be sent to the reader device through a channel other than the secure channel established by the security component.

[0157] Based on service application data sent from the electronic device to the reader device, mutual authentication between the electronic device and the reader device can be performed. After negotiating UWB capability parameters and the UWB session key via a secure channel, the electronic device maintains an ADF (Automatic Document Frame) containing the UWB capability parameters and the UWB session key in a public mini-application. The electronic device can trigger a UWB secure ranging session by using the ADF maintained in the public mini-application.

[0158] Electronic devices can perform ranging by sending and receiving ranging frames to and from a reader device in a UWB communication scheme, the ranging frames including STS codes generated by using a session key included in an ADF in a public applet.

[0159] Figure 11 A block diagram of an electronic device according to an embodiment is shown.

[0160] Electronic device 1100 according to embodiments of this disclosure may include, but is not limited to, personalized mobile devices, and may include various types of electronic devices. For example, electronic device 1100 may include smartphones, tablet PCs, PCs, cameras, wearable devices, etc.

[0161] Reference Figure 11 The electronic device 1100 may include a communication interface 1110, a memory 1120, a security component 1130, a processor 1140, and a bus 1150 that connects the components to each other.

[0162] Communication interface 1110 can perform wired / wireless communication with another device (e.g., an access service provider server or a reader device) or a network. For this purpose, communication interface 1110 may include a communication module supporting at least one of various wired / wireless communication methods. For example, the communication module may be in the form of a chipset, or it may be an adhesive / barcode (e.g., an adhesive including an NFC tag) that includes information necessary for communication.

[0163] Wireless communication may include at least one of, for example, cellular communication, Wi-Fi (Wireless Fidelity), Wi-Fi Direct, Bluetooth, BLE, UWB, or NFC. Wired communication may include at least one of, for example, Universal Serial Bus (USB) or High Definition Multimedia Interface (HDMI).

[0164] In one embodiment, the communication interface 1110 may include a communication module for short-range communication. For example, in addition to Wi-Fi, Wi-Fi Direct, Bluetooth, BLE, UWB, and NFC described above, the communication interface 1110 may include a communication module for performing various types of short-range communication, such as infrared communication or magnetic secure transmission (MST).

[0165] Various types of data, such as programs (e.g., applications) or files, can be installed and stored in memory 1120. Processor 1140 can access and use the data stored in memory 1120, or can store new data in memory 1120. In an embodiment, programs (e.g., service applications, frameworks) and data for managing digital keys can be installed and stored in memory 1120.

[0166] For example, memory 1120 may include at least one of flash memory, hard disk storage, multimedia card micro storage, card type memory (e.g., SD or XD memory), random access memory (RAM), static RAM (SRAM), read-only memory (ROM), electrically erasable programmable ROM (EEPROM), programmable read-only memory (PROM), magnetic storage, magnetic disk, and optical disk.

[0167] The electronic device 1100 according to an embodiment may include a security component 1130, which can perform processes such as generating, deleting, or managing key parameters, including those for controlling or accessing external devices, and can perform authentication on the digital keys. Furthermore, the security component can provide the functionality to securely manage digital keys by authenticating access to the digital keys by external entities (e.g., service provider servers or reader devices) and verifying their permissions. For example, the security component may include a secure element (SE) and / or a secure device element (TEE).

[0168] Security component 1130 is a separate secure storage device for electronic device 1100 and can only be accessed by authorized applications. Security component 1130 may be physically isolated from other hardware components. According to an embodiment, programs and data for managing the ADF (e.g., security domains, applets, etc.) may be installed and stored in security component 1130.

[0169] Processor 1140 controls the overall operation of electronic device 1100 and may include at least one processor, such as a central processing unit (CPU) or a GPU (graphics processing unit). Processor 1140 may control other components included in electronic device 1100 to perform range-based service operations. For example, processor 1140 may execute programs stored in memory 1120 and security component 1130, load files stored therein, or store new files therein.

[0170] According to an embodiment, the processor 1140 can send service data-related information from a service application installed in an electronic device to a framework. The service data-related information may be an API used to notify service deployment methods, including information about service deployment status and the storage location of service data.

[0171] The service deployment scenario may include at least one of a first scenario, a second scenario, and a third scenario, in which the service data is stored in a public applet installed in the security component, in the second scenario, the service data is stored in a traditional applet installed in the security component, and in the third scenario, the service data is stored in the service application.

[0172] When the service deployment scenario is the first scenario, information about the storage location of the service data may include the identifier of the public applet installed in the security component. When the service deployment scenario is the second scenario, information about the storage location of the service data may include the identifier of the traditional applet. When the service deployment scenario is the third scenario, information about the storage location of the service data may include the identifier of the service application.

[0173] In addition to the API for notifying service deployment methods, the processor 1140 according to the embodiment can also transmit at least one of the service file configuration API and the key provision API for establishing a secure channel from the service application to the framework.

[0174] When the electronic device 1100 approaches the reader device, the processor 1140 according to an embodiment can receive first data from the reader device. The first data may include an identifier of a public applet installed in a security component. For example, the electronic device 1100 can receive an APDU including the identifier of the public applet by using an NFC module or a BLE module included in the communication interface 1110.

[0175] According to an embodiment, processor 1140 can send first data to security component 1130. Security component 1130 can identify a public applet based on the first data and establish a secure channel with a reader device by using information stored in the identified public applet. The public applet can be an applet commonly used by multiple service applications of an electronic device for establishing a secure channel.

[0176] Information stored in public applications and used for secure channel establishment can include ADFs containing parameters for UWB ranging and session keys.

[0177] According to an embodiment, the processor 1140 can send service data to the reader device based on second data received from the reader device. For example, the processor 1140 can send the service data to the reader device using the NFC communication module or BLE communication module of the communication interface 1110.

[0178] When the service deployment is in the first scenario, the processor 1140 can receive the tag value of the service data as the second data from the reader device. The security component 1130 of the electronic device 1100 can identify the ADF in the public applet based on the tag value received from the reader device, and use the identified ADF to establish a secure channel with the reader device.

[0179] When the service deployment is in the second scenario, processor 1140 can receive the identifier of the legacy app as second data from the reader device. Processor 1140 can receive command APDUs and the legacy app identifier from the reader device. The framework of processor 1140 can send C-APDUs to the legacy app via the public app in security component 1130. In response to the C-APDU, security component 1130 can send R-APDUs from the legacy app to the framework via the public app. The framework of processor 1140 can send R-APDUs including service data to the reader device.

[0180] When the service deployment is in the third scenario, processor 1140 can receive the service application identifier as second data from the reader device. The frame of processor 1140 can receive the C-API and the service application identifier from the reader device and send the C-API from the frame to the service application. In response to the C-API, the service application can send an R-API to the frame. The frame of processor 1140 can send an R-API including service data to the reader device.

[0181] Based on service application data sent from electronic device 1100 to reader device, mutual authentication between electronic device 1100 and reader device can be performed. After negotiating UWB capability parameters and UWB session keys via a secure channel, electronic device 1100 maintains an ADF (Advanced Distribution Format) including the UWB capability parameters and UWB session key in a public applet within security component 1130. Electronic device 1100 can establish a UWB secure ranging session by using the ADF maintained in security component 1130. According to an embodiment, the UWB communication module of communication interface 1110 of electronic device 1100 can generate an STS (Search and Transaction) code by using the UWB session key included in the ADF maintained in the public applet, and send and receive ranging frames including the generated STS code, thereby performing ranging with the reader device.

[0182] Bus 1150 is a common data transmission channel that connects communication interface 1110, memory 1120, security component 1130 and processor 1140 to each other.

[0183] Figure 12 A block diagram of a security component 1130 according to an embodiment of the present disclosure is shown.

[0184] Reference Figure 12 The security component 1130 may include a communication interface 1210, a memory 1220, and a processor 1230.

[0185] According to the embodiment, security component 1130 is a separate secure storage device of electronic device 1100 and can only be accessed by authorized applications. For example, security component 1130 may include TEE, embedded SE (eSE), universal integrated circuit card (UICC), secure digital card (SD card), embedded UICC (eUICC), or a separate security processing unit (SPU) as a combination of hardware and software or employing a hardware method.

[0186] Communication interface 1210 can communicate with host 101 or another device (e.g., an access service providing server or a reader device). For this purpose, communication interface 1210 may include a communication module supporting at least one of various wired / wireless communication methods. Here, host 101 may be one of the devices included in electronic device 1100 and may include, for example, an application processor (AP), memory, etc. Communication interface 1210 may be a serial interface, such as ISO 7816, USB, Inter-Integrated Circuit (I2C), Serial Peripheral Interface (SPI), or Single-Wire Protocol (SWP), or any serial interface typically used for communication between two hardware devices. Furthermore, communication interface 1210 may be a wireless interface that directly connects an antenna to a hardware device, such as ISO 14443, Zigbee, or Bluetooth. Additionally, communication interface 1210 may be a parallel interface connected to the central bus of electronic device 1100, and in this case, may include a buffer for receiving commands and data from host 101.

[0187] Various types of data, such as programs (e.g., applets) or files, can be installed and stored in memory 1220. Processor 1230 can access and use the data stored in memory 1220, or can store new data in memory 1220. In an embodiment, programs and data for processing digital keys can be installed and stored in memory 1220. Memory 1220 can be a non-volatile memory device.

[0188] Processor 1230 controls the overall operation of security component 1130 and may include at least one processor, such as a CPU or GPU. Processor 1230 may control other components included in security component 1130 to perform operations for managing the ADF. For example, processor 1230 may execute a program stored in memory 1220, load a file stored therein, or store a new file therein. In one embodiment, processor 1230 may perform operations for managing the ADF by executing a program stored in memory 1220.

[0189] Despite Figure 11 Not shown, but the electronic device 1100 including the security component 1130 according to the embodiment may also include a frame. This frame is a service application concerning external entities accessing the security component 1130, acting as a gateway. The frame may provide APIs for external entities to access the security component 1130 and may provide functionality for accessing the security component 1130, such as access control and command translation. External entities may be, for example, security zone issuers, service providers, reader devices, and / or access service providing devices.

[0190] According to an embodiment, lightweight applications (e.g., applets or TAs) can be installed and executed in security component 1130. Applets can store ADFs (Application Documents) and provide services in security component 1130, such as using, deleting, and managing the stored ADFs. Applets can be pre-installed in security component 1130, or can be loaded or installed therein as needed.

[0191] Embodiments of this disclosure can be implemented as software (S / W) programs including instructions stored in a computer-readable storage medium.

[0192] A computer can recall stored instructions from a storage medium and operate based on the recalled instructions according to embodiments of the present disclosure, and may include an electronic device according to embodiments of the present disclosure.

[0193] Computer-readable storage media may be provided in the form of non-transitory storage media. Here, the term "non-transitory" simply means that the storage medium is a tangible device and does not include signals, but the term does not distinguish between data that is stored semi-permanently in the storage medium and data that is temporarily stored in the storage medium. For example, a non-transitory storage medium may include a buffer for temporarily storing data.

[0194] Furthermore, electronic devices or methods according to embodiments of this disclosure may be provided in computer program products. These computer program products can be traded as goods between a seller and a buyer.

[0195] Computer program products may include a switch program and a computer-readable recording medium storing the switch program. For example, a computer program product may include a product in the form of a switch program (e.g., a downloadable application) electronically distributed by an electronic device manufacturer or an electronic marketplace (e.g., Google Play Store, App Store). For electronic distribution, at least a portion of the switch program may be stored in a storage medium or temporarily generated. In this case, the storage medium may be a storage medium on the manufacturer's server or the electronic marketplace's server, or a relay server temporarily storing the switch program.

[0196] In a system consisting of a server and a terminal, the computer program product may include the storage medium of the server or the storage medium of the terminal. Alternatively, when a third device (e.g., a smartphone) is communicatively connected to the server or terminal, the computer program product may include the storage medium of the third device. Alternatively, the computer program product may include the S / W program itself, sent from the server to the terminal or the third device, or sent from the third device to the terminal.

[0197] In this scenario, one of the server, terminal, and third device may execute a computer program product to perform the method according to the embodiments disclosed herein. Alternatively, two or more of the server, terminal, and third device may execute a computer program product to perform the method according to the embodiments disclosed herein in a distributed manner.

[0198] For example, a server (e.g., a cloud server, an artificial intelligence server) can execute a computer program product stored on the server to control a terminal communicatively connected to the server to perform a method according to an embodiment disclosed herein.

[0199] As another example, a third device may execute a computer program product to control a terminal communicatively connected to the third device to perform a method according to an embodiment disclosed herein.

[0200] When a third device executes a computer program product, it may download the computer program product from a server and execute the downloaded computer program product. Alternatively, the third device may execute a computer program product provided in a pre-loaded state and perform the method according to the embodiments disclosed herein.

Claims

1. A method performed by an electronic device in a wireless communication system, the method comprising: Identify service deployment information from multiple service deployment scenarios related to the storage location of service data; A secure channel is established with the reader device based on a common mini-application installed in the security component of the electronic device. The reader device receives information for accessing service data, wherein the information for accessing service data is related to the identified service deployment status; as well as Based on the information used to access service data, the service data is sent to the reader device.

2. The method according to claim 1, wherein, The deployment of the aforementioned multiple services includes: In the first scenario, the service data is stored in the public mini-application; In the second scenario, the service data is stored in a mini-application installed within the security component, which is different from the public mini-application; and In the third scenario, the service data is stored in a service application installed in the electronic device.

3. The method according to claim 2, wherein, When the service deployment is the first scenario, the information used to access the service data includes the tag value of the service data.

4. The method according to claim 2, wherein, In the case where the service deployment is the second scenario, the information used to access the service data includes the identifier of the mini-application.

5. The method according to claim 2, wherein, In the case where the service deployment is the third scenario, the information used to access service data is related to the service application.

6. The method according to claim 2, wherein, If the service deployment scenario is the second scenario: Receiving the information for accessing service data from the reader device includes: The reader device receives a Command Application Data Unit (APDU) and an identifier of the mini-application, wherein the command APDU is sent from the public mini-application to the mini-application, and a response APDU is sent from the mini-application to the public mini-application; and Sending the service data to the reader device includes sending the response APDU, which includes the service data, to the reader device.

7. The method according to claim 5, further comprising: The service data is retrieved based on the information used to access the service data.

8. The method according to claim 1, wherein, The service deployment status is indicated by the service file configuration information, which is notified to the framework by the service application.

9. The method according to claim 1, wherein, The public mini-applications include information related to ultra-wideband (UWB) ranging.

10. The method according to claim 9 further includes performing ranging based on the UWB ranging-related information.

11. An electronic device in a wireless communication system, the electronic device comprising: transceiver; as well as At least one processor, coupled to the transceiver, is configured to: Identify service deployment information from multiple service deployment scenarios related to the storage location of service data; A secure channel is established with the reader device based on a common mini-application installed in the security component of the electronic device. The transceiver receives information for accessing service data from the reader device, wherein the information for accessing service data is related to the identified service deployment status; as well as Based on the information used to access service data, the service data is sent to the reader device via the transceiver.

12. The electronic device according to claim 11, wherein, In the first scenario where the service deployment is such that the service data is stored in the public mini-application, the information used to access the service data includes the tag value of the service data.

13. The electronic device according to claim 11, wherein, In the second scenario, where the service deployment is such that the service data is stored in a mini-application installed in the security component and is different from the public mini-application, the information used to access the service data includes the identifier of the mini-application.

14. The electronic device according to claim 11, wherein, In the third scenario, where the service deployment is such that the service data is stored in a service application installed in the electronic device, the information used to access the service data includes the identifier of the service application.

15. One or more computer-readable recording media having a program recorded thereon, the program being used to perform a method executed by an electronic device in a wireless communication system, the method comprising: Identify service deployment information from multiple service deployment scenarios related to the storage location of service data; A secure channel is established with the reader device based on a common mini-application installed in the security component of the electronic device. The reader device receives information for accessing service data, wherein the information for accessing service data is related to the identified service deployment status; as well as Based on the information used to access service data, the service data is sent to the reader device.

Images