Method and apparatus for registering terminal as digital key of vehicle

Abstract

An operation method of a terminal for performing owner pairing with a vehicle in a wireless communication system, according to one embodiment of the present disclosure, comprises the steps of: using a first communication method to establish a connection required for the owner pairing with the vehicle; using the first communication method to receive, from the vehicle, a first message including information indicating a communication method for performing owner pairing; and performing mutual authentication with the vehicle on the basis of information indicating the communication method for performing owner pairing. Embodiments of the present disclosure can include various other embodiments.

Description

Method and device for registering a terminal as a digital key of a vehicle

[0001] The present disclosure relates to a method and device for registering a terminal as a digital key of a vehicle, and more particularly, to a technology proposing a method and device for registering a terminal as a digital key of a vehicle using near-field communication (NFC) and Bluetooth (BLE) communication, or only Bluetooth communication.

[0002] The Internet is evolving from a human-centric network where humans create and consume information to an Internet of Things (IoT) network where information is exchanged and processed between distributed components such as objects. The Internet of Everything (IoE) technology, which combines IoT technology with big data processing technology through connections to cloud servers, is also emerging. To implement the IoT, technological elements such as sensing technology, wired and wireless communication and network infrastructure, service interface technology, and security technology are required. Recently, technologies such as sensor networks for connecting objects, machine-to-machine (M2M) communication, and machine-type communication (MTC) are being researched.

[0003] In an IoT environment, intelligent IT (Internet Technology) services can be provided that collect and analyze data generated from connected objects, creating new value in human life. IoT, through the convergence and integration of existing IT (information technology) technologies with various industries, can be applied to fields such as smart homes, smart buildings, smart cities, smart or connected cars, smart grids, healthcare, smart appliances, and advanced medical services.

[0004] Meanwhile, with the proliferation of personalized electronic devices such as smartphones and tablet PCs, technologies for security and authentication using digital keys are being developed. One approach to this digital key technology is to integrate digital keys into mobile devices, such as smartphones, using wireless communication technologies like Near Field Communication (NFC). In other words, a digitized virtual key, or digital key, is inserted into the mobile device, and the user of the mobile device can use this digital key to replace physical keys for opening and closing doors, vehicle doors, control, and access. However, security and authentication are crucial when using digital keys, necessitating a highly secure key registration method for key use.

[0005] The present disclosure proposes a method and device for registering a terminal as a car key using near-field communication (NFC) and Bluetooth (BLE) communication, or only Bluetooth communication.

[0006] According to one embodiment of the present disclosure, a method of operating a terminal for performing owner pairing with a vehicle in a wireless communication system includes: establishing a connection necessary for owner pairing with the vehicle using a first communication method; receiving a first message from the vehicle using the first communication method, the first message including information indicating a communication method for performing owner pairing; and performing mutual authentication with the vehicle based on the information indicating the communication method for performing the owner pairing.

[0007] According to one embodiment of the present disclosure, a method for operating a vehicle that performs owner pairing with a terminal in a wireless communication system includes: forming a connection necessary for owner pairing with the terminal using a first communication method; transmitting a first message including information indicating a communication method for performing owner pairing to the terminal using the first communication method; and performing mutual authentication with the terminal based on the information indicating the communication method for performing the owner pairing.

[0008] According to one embodiment of the present disclosure, a terminal for performing owner pairing with a vehicle in a wireless communication system includes a transceiver; and at least one processor; wherein the at least one processor is configured to form a connection necessary for owner pairing with the vehicle using a first communication method, receive a first message including information indicating a communication method for performing owner pairing from the vehicle using the first communication method, and perform mutual authentication with the vehicle based on the information indicating the communication method for performing the owner pairing.

[0009] According to one embodiment of the present disclosure, a vehicle performing owner pairing with a terminal in a wireless communication system comprises: a transceiver; and at least one processor; wherein the at least one processor is configured to establish a connection necessary for owner pairing with the terminal using a first communication method, transmit a first message including information indicating a communication method for performing owner pairing to the terminal using the first communication method, and perform mutual authentication with the terminal based on the information indicating the communication method for performing the owner pairing.

[0010] A terminal according to an embodiment of the present disclosure can conveniently register the terminal as a car key by simultaneously utilizing near-field communication (NFC) and Bluetooth (BLE) communication.

[0011] A terminal according to an embodiment of the present disclosure can provide high stability in terms of security while improving user convenience by utilizing only Bluetooth (BLE) communication.

[0012] Figure 1a is an exemplary architecture of a user terminal.

[0013] Figure 1b is a flowchart for explaining the owner pairing procedure for registering a terminal as a car key.

[0014] Figure 2 is a flowchart for explaining the pairing procedure for registering a terminal as a car key using only NFC.

[0015] Figure 3 (a) is a flowchart for explaining a pairing procedure using only NFC.

[0016] FIG. 3 (b) is a flowchart for explaining a pairing procedure sequentially utilizing NFC and BLE according to an embodiment of the present disclosure.

[0017] FIGS. 4A and 4B are flowcharts for explaining a pairing procedure sequentially utilizing NFC and BLE according to an embodiment of the present disclosure.

[0018] FIG. 5 is a drawing for explaining a system key derivation operation of a pairing procedure sequentially utilizing NFC and BLE according to an embodiment of the present disclosure.

[0019] FIGS. 6A, 6B, and 6C are drawings for explaining an owner pairing procedure of a pairing procedure sequentially utilizing NFC and BLE according to an embodiment of the present disclosure.

[0020] FIG. 7 is a diagram for explaining a BLE Advertising message when establishing a BLE connection in a pairing procedure sequentially utilizing NFC and BLE according to an embodiment of the present disclosure.

[0021] FIG. 8 is a drawing for explaining a select command that a vehicle transmits to an electronic device when establishing a BLE connection in a pairing procedure that sequentially utilizes NFC and BLE according to an embodiment of the present disclosure.

[0022] FIG. 9 is a diagram for explaining the verification procedure of each user in a pairing procedure sequentially utilizing NFC and BLE according to an embodiment of the present disclosure.

[0023] Figure 10 (a) is a flowchart for explaining a pairing procedure using BLE and UWB.

[0024] Figure 10 (b) is a flowchart for explaining a pairing procedure sequentially utilizing BLE and NFC according to an embodiment of the present disclosure.

[0025] Figure 11a is a flowchart for explaining a pairing procedure using BLE and UWB.

[0026] FIG. 11b is a flowchart for explaining a pairing procedure sequentially utilizing BLE and NFC according to an embodiment of the present disclosure.

[0027] FIG. 12 is a flowchart for explaining a pairing procedure sequentially utilizing BLE and NFC according to an embodiment of the present disclosure.

[0028] FIG. 13 is a diagram for explaining BLE advertisement data in a pairing procedure sequentially utilizing BLE and NFC according to an embodiment of the present disclosure.

[0029] FIG. 14 is a drawing for explaining a message transmitted by a terminal in a pairing procedure sequentially utilizing BLE and NFC according to an embodiment of the present disclosure.

[0030] Figure 15 (a) is a flowchart for explaining a pairing procedure using BLE and UWB.

[0031] Figure 15 (b) is a flowchart for explaining a pairing procedure using only BLE according to an embodiment of the present disclosure.

[0032] FIG. 16 is a flowchart for explaining a pairing procedure using only BLE according to an embodiment of the present disclosure.

[0033] FIG. 17 is a diagram for explaining BLE advertisement data in a pairing procedure using only BLE according to an embodiment of the present disclosure.

[0034] FIG. 18 is a drawing for explaining a message transmitted by a terminal in a pairing procedure sequentially utilizing BLE and NFC according to an embodiment of the present disclosure.

[0035] FIGS. 19A and 19B are diagrams for explaining information about the pairing capability of a vehicle according to an embodiment of the present disclosure.

[0036] Figure 20 is a flowchart showing an operation method of a terminal according to an embodiment of the present disclosure.

[0037] FIG. 21 is a flowchart showing an operation method of a vehicle according to an embodiment of the present disclosure.

[0038] FIG. 22 is a structural diagram showing the structure of an electronic device according to an embodiment of the present disclosure.

[0039] Hereinafter, embodiments of the present disclosure will be described in detail with reference to the attached drawings.

[0040] In describing the embodiments, descriptions of technical details that are well known in the technical field to which the present disclosure pertains and are not directly related to the present disclosure will be omitted. This is to convey the gist of the present disclosure more clearly without obscuring it by omitting unnecessary explanations.

[0041] For the same reason, some components in the attached drawings are exaggerated, omitted, or schematically depicted. Furthermore, the dimensions of each component do not entirely reflect its actual size. Identical or corresponding components in each drawing are assigned the same reference numbers.

[0042] The advantages and features of the present disclosure, and methods for achieving them, will become clearer with reference to the embodiments described below in detail together with the accompanying drawings. However, the present disclosure is not limited to the embodiments disclosed below and may be implemented in various different forms. The embodiments of the present disclosure are provided only to make the present disclosure complete and to fully inform those skilled in the art of the scope of the disclosure, and the present disclosure is defined only by the scope of the claims. Like reference numerals refer to like elements throughout the specification.

[0043] At this time, it will be understood that each block of the processing flowchart drawings and combinations of the flowchart drawings can be performed by computer program instructions. These computer program instructions can be installed in a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing equipment, so that the instructions executed by the processor of the computer or other programmable data processing equipment create a means for performing the functions described in the flowchart block(s). These computer program instructions can also be stored in a computer-available or computer-readable memory that can direct a computer or other programmable data processing equipment to implement the functions in a specific manner, so that the instructions stored in the computer-available or computer-readable memory can also produce a manufactured item that includes an instruction means for performing the functions described in the flowchart block(s). Since the computer program instructions may be installed on a computer or other programmable data processing device, a series of operational steps may be performed on the computer or other programmable data processing device to create a computer-executable process, so that the instructions that cause the computer or other programmable data processing device to perform the steps for performing the functions described in the flowchart block(s) may also be able to provide steps for performing the functions described in the flowchart block(s).

[0044] Additionally, each block may represent a module, segment, or portion of code that contains one or more executable instructions for performing a specific logical function(s). It should also be noted that in some alternative implementation examples, the functions described in the blocks may occur out of order. For example, two blocks depicted in succession may actually be executed substantially concurrently, or the blocks may sometimes be executed in reverse order, depending on their respective functions.

[0045] Here, the term '~ unit' used in the present embodiment means software or hardware components such as FPGA (Field Programmable Gate Array) or ASIC (Application Specific Integrated Circuit), and the '~ unit' performs certain roles. However, the '~ unit' is not limited to software or hardware. The '~ unit' may be configured to be on an addressable storage medium and may be configured to play one or more processors. Accordingly, according to some embodiments, the '~ unit' includes components such as software components, object-oriented software components, class components, and task components, processes, functions, properties, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and variables. The functions provided within the components and '~ units' may be combined into a smaller number of components and '~ units' or further separated into additional components and '~ units'. Additionally, the components and '~parts' may be implemented to activate one or more CPUs within the device or secure multimedia card. Furthermore, according to some embodiments, the '~parts' may include one or more processors.

[0046] The term 'terminal' or 'device' used herein may refer to a mobile station (MS), user equipment (UE), user terminal (UT), wireless terminal, access terminal (AT), terminal, subscriber unit (SS), subscriber station (SS), wireless device, wireless communication device, wireless transmit / receive unit (WTRU), mobile node, mobile, or other terms. Various embodiments of the terminal may include a cellular telephone, a smart phone having a wireless communication function, a personal digital assistant (PDA) having a wireless communication function, a wireless modem, a portable computer having a wireless communication function, a photographing device such as a digital camera having a wireless communication function, a gaming device having a wireless communication function, a music storage and playback home appliance having a wireless communication function, an internet home appliance capable of wireless internet access and browsing, as well as portable units or terminals integrating combinations of such functions. In addition, the terminal may include, but is not limited to, an M2M (Machine to Machine) terminal, an MTC (Machine Type Communication) terminal / device. In this specification, the terminal may also be referred to as an electronic device or simply a device.

[0047] The operating principles of the present disclosure are described in detail below with reference to the attached drawings. In the following description of the present disclosure, detailed descriptions of related known functions or configurations will be omitted if they are deemed to unnecessarily obscure the gist of the present disclosure. Furthermore, the terms described below are defined based on the functions of the present disclosure and may vary depending on the intent or custom of the user or operator. Therefore, their definitions should be based on the overall content of this specification.

[0048] Hereinafter, embodiments of the present disclosure will be described in detail with reference to the accompanying drawings. While the embodiments of the present disclosure will be described below using a communication system utilizing UWB as an example, the embodiments of the present disclosure may also be applied to other communication systems with similar technical backgrounds or characteristics. For example, these may include communication systems utilizing Bluetooth or Zigbee. Accordingly, the embodiments of the present disclosure may be applied to other communication systems with some modifications, as determined by a person skilled in the art, without significantly departing from the scope of the present disclosure.

[0049] Additionally, when describing the present disclosure, detailed descriptions of related functions or configurations will be omitted if they are deemed to unnecessarily obscure the gist of the present disclosure. Furthermore, the terms described below are defined based on the functions of the present disclosure and may vary depending on the intent or custom of the user or operator. Therefore, their definitions should be based on the contents of this specification.

[0050] Generally, wireless sensor network technologies are broadly categorized into Wireless Local Area Network (WLAN) and Wireless Personal Area Network (WPAN) technologies based on their sensing range. WLAN is a technology based on IEEE 802.11 that allows access to a backbone network within a radius of approximately 100 meters. WPAN, on the other hand, is a technology based on IEEE 802.15, and includes technologies such as Bluetooth, ZigBee, and ultra-wideband (UWB). A wireless network implementing these wireless network technologies may consist of multiple electronic devices.

[0051] According to the FCC (Federal Communications Commission) definition, UWB can refer to a wireless communication technology that uses a bandwidth of 500 MHz or more, or a bandwidth corresponding to a center frequency of at least 20%. UWB can also refer to the band itself in which UWB communications are applied. UWB enables secure and accurate ranging between devices. This allows for relative position estimation based on the distance between two devices, or precise position estimation of a device based on the distance from a fixed device (of known location).

[0052] Certain terms used in the following description are provided to aid in understanding the present disclosure, and the use of such specific terms may be changed to other forms without departing from the technical spirit of the present disclosure.

[0053] A "digital key" refers to digital credentials used to authenticate access to a vehicle.

[0054] "Owner device" refers to a terminal of a vehicle owner. In this disclosure, unless otherwise specified, the terminal refers to the owner device.

[0055] A "friend device" refers to a terminal that can communicate through the same vehicle OEM server as the owner device.

[0056] "Owner pairing (OP)" refers to the process of pairing an owner's device with a vehicle. Owner pairing can use NFC, BLE, or UWB communication.

[0057] “Transaction operation” refers to an operation in which a terminal exchanges service data with another terminal.

[0058] "Applet" refers to a small program with simple functions written in the Java language, or a program included in a web page that performs a small function.

[0059] "SPAKE2+ (simplified password authenticated key exchange)" refers to a password-authenticated key exchange protocol implemented between two parties. SPAKE2+ is an enhanced version of the PAKE protocol, as only one party has knowledge of the password.

[0060] For convenience of explanation, this disclosure uses terms and names defined in the digital key-related standards defined by the Car Connectivity Consortium (CCC), among the existing communication standards. However, this disclosure is not limited to these terms and names and can be equally applied to wireless communication networks conforming to other standards.

[0061] In addition, when explaining the present disclosure, if it is determined that a specific description of a related public notice function or configuration may unnecessarily obscure the gist of the present disclosure, the detailed description is omitted.

[0062] Various embodiments of the present disclosure are described below with reference to the attached drawings.

[0063] Figure 1a is an exemplary architecture of a terminal.

[0064] In the present disclosure, the terminal may be one of various types of terminals. For example, the terminal may be a portable device (e.g., UE, smartphone, wearable device, tag device) or a stationary device (e.g., door lock, anchor device, etc.).

[0065] Referring to FIG. 1A, the terminal (100) may include a BLE module (103), a UWB module (105), an NFC component (110), a Secure Element (or equivalent) (115), a Digital Key Applet (120), a Digital Key Framework (125), a Vehicle OEM App (130), and a Native App (135).

[0066] The BLE (Bluetooth) module (103) refers to an entity that manages Bluetooth communication between a terminal and a vehicle. The BLE module (103) may be part of at least one integrated circuit or a combo chip solution. The functions of the BLE module (103) are as follows.

[0067] - Communicate with the vehicle for owner pairing, transactions with other terminals, and digital key transactions (lock / unlock, engine start, RKE, etc.)

[0068] - Communicate with the vehicle to establish secure ranging via UWB

[0069] - Communicate with the vehicle for remote transactions, allowing the device to initiate on-demand functions (e.g. lock / unlock, etc.)

[0070] - Communicate with the vehicle to send notifications, notify of status information changes, and transmit signals.

[0071] - Third party vehicles (3 rd Communicate with vehicles for data transfer for OEM (Original equipment manufacturer) applications

[0072] The UWB module (105) refers to an entity that manages a UWB ranging session. The UWB module (105) may be part of at least one integrated circuit or combo chip solution. The functions of the BLE module (103) are as follows.

[0073] - Communicates with the vehicle for secure ranging to safely determine the distance between the device and the vehicle to support secure distance measurement for manual entry and manual engine start functions.

[0074] NFC configuration (110) refers to an entity that manages NFC communication between a terminal and another terminal or vehicle. The functions of NFC configuration (110) are as follows.

[0075] - Operates in card emulation mode required for contactless transactions

[0076] - Operates in host card emulation mode, which is required for owner pair configuration.

[0077] Secure Element (or equivalent) (115) is a module related to a security element within a terminal and may include the following functions.

[0078] - Java Card (example) and global platform support, GP (global platform) defined Controller Authority Security Domain-based SE (secure element) Root available

[0079] - Modification of global platform card specifications and expansion of global platform contactless

[0080] - Support for standard symmetric and asymmetric encryption

[0081] - Host Digital Key Applet

[0082] - Ability to distinguish between communication between wired and non-contact interfaces

[0083] Digital Key Applet (120) refers to a small application that manages and controls digital keys within a terminal. Digital Key Applet (120) provides the following services.

[0084] - Hosts Digital Keys (one applet instance provides Digital Key functionality for all vehicle OEMs)

[0085] - Implementation related to (fast and standard) transactions

[0086] - Support for privacy protection

[0087] - Store immobilizer tokens when required to access other data related to vehicles, offline credentials, access profiles, and digital keys.

[0088] - Verify the authenticity of the vehicle

[0089] - Check the certificate chain of your friend's public key

[0090] The Digital Key Framework (125) refers to a module that performs owner pairing, digital key sharing, and management within the terminal. The Digital Key Framework (125) provides common digital key service functions through a set of OS-specific APIs for vehicle OEM apps. These APIs are described in the developer documentation for each OS platform.

[0091] The Vehicle OEM App (130) is a module related to an application provided by the vehicle manufacturer. The main functions of the app are supported by default on the terminal. The Vehicle OEM App (130) may be optionally included. The main functions of the Vehicle OEM App (130) are as follows.

[0092] - Supports the same features as the basic app and vehicle OEM-specific features

[0093] - Provides vehicle OEM server and ID&V

[0094] - Retrieve the owner pairing password

[0095] - Key management with non-standard access profiles

[0096] The Native App (135) provides a device-native UI (user interface), such as digital key generation, digital key termination and deletion, and digital key activation / deactivation. The Native App (135) displays a list of all issued owner and friend digital keys.

[0097] Figure 1b is a flowchart illustrating an owner pairing procedure for registering a terminal as a car key.

[0098] The owner pairing procedure illustrated in FIG. 1b may include an owner pairing procedure based on the CCC owner pairing protocol.

[0099] Referring to Figure 1b, phase 0 is a preparation phase, in which the terminal prepares the DK applet and can store the terminal certificate (140). Phase 1 is a pairing procedure initiation phase, in which the owner pairing password issued to the vehicle owner by the vehicle manufacturer can be entered into the terminal (150).

[0100] Step 2 (phase 2) is a first session via an NFC reader, in which, after verifying the Owner Pairing password, the terminal generates a digital key and exchanges a vehicle certificate and a digital key certificate (160). Step 3 (phase 3) is a second session via an NFC reader, in which mutual authentication between the terminal and the vehicle can be performed based on the certificate exchanged in step 2 (170). Step 4 (phase 3) is a step for terminating the pairing procedure, in which an immobilizer token required for performing an action such as an engine start can be issued (180). In one embodiment, step 4 (phase 3) may be optionally included.

[0101] Figure 2 is a flowchart illustrating the owner pairing procedure for registering a terminal as a car key using only NFC.

[0102] Specifically, FIG. 2 is a drawing illustrating phase 2 and phase 3 described in FIG. 1, and the terminal (250) is an owner device of a vehicle (200).

[0103] In step 201, the vehicle (200) may transmit a DK framework select to the terminal (250). In step 202, the vehicle (200) and the terminal (250) may create a secure channel. In step 203, the vehicle (200) may transmit data necessary for generating a digital key to the terminal (250). In step 204, the terminal (250) may generate a digital key in the Secure Element.

[0104] In step 205, the terminal (250) can transmit a certificate signed by the terminal (250) and the vehicle (200) to the vehicle (200). In step 206, the vehicle (200) can verify the data of the digital key certificate, extract the public key (PK) of the terminal from the digital key certificate, and store the public key of the terminal together with the vehicle owner's access rights.

[0105] In step 207, the vehicle (200) and the terminal (250) can select a digital key framework. Additionally, in step 208, the vehicle (200) and the terminal (250) can perform mutual authentication.

[0106] In the above Fig. 2, steps 201 to 206 are included in phase 2 of Fig. 1b, and steps 207 to 208 in Fig. 2 are included in phase 3 of Fig. 1b. When the operation illustrated in Fig. 2 is implemented in a vehicle and a terminal, steps 201 to 206 included in phase 2 may take approximately 11.557 sec, and steps 207 to 208 included in phase 3 may take approximately 4.166 sec.

[0107] When performing owner pairing using NFC, as shown in Fig. 2, a long NFC tagging time may be required between the vehicle and the terminal. This means that the data exchanged between the vehicle and the terminal during owner pairing is bulky, requiring reductions in both the time and data size required for owner pairing. Therefore, the present disclosure proposes a method for enhancing user convenience and shortening pairing time by utilizing Bluetooth communication in owner pairing using only NFC.

[0108] Figure 3 (a) is a flowchart for explaining a pairing procedure using only NFC.

[0109] Figure 3 (b) illustrates the same owner pairing procedure for registering the terminal as a car key as illustrated in Figure 1b, with phase 2 being detailed.

[0110] Referring to Figure 3, phase 0 is a preparation phase, in which the terminal prepares the DK applet and can store the terminal certificate (300). Phase 1 is a pairing procedure initiation phase, in which the owner pairing password issued to the vehicle owner by the vehicle manufacturer can be entered into the terminal (305).

[0111] Phase 2 is the first session via an NFC reader, where, after verifying the Owner Pairing password, the terminal generates a digital key and exchanges a vehicle certificate and a digital key certificate. This is described in detail in Fig. 3, and in phase 2-1, the vehicle can select a digital key frame (310). In addition, in phase 2-2, the vehicle and the terminal can form a SPAKE2+ (simplified password authenticated key exchange) channel (315). SPAKE2+ (simplified password authenticated key exchange) refers to a password authentication key exchange protocol implemented between two parties as described above, and SPAKE2+ functions as a secure channel.

[0112] In phase 2-3, the vehicle and the terminal can generate a digital key and exchange a digital key certificate and a vehicle certificate (320). In phase 3, mutual authentication is performed based on the certificate, and in phase 4, an immobilizer token required for performing an action such as engine start can be issued (325).

[0113] FIG. 3 (b) is a flowchart for explaining a pairing procedure sequentially utilizing NFC and BLE according to an embodiment of the present disclosure.

[0114] Steps 0 (330), 1 (335), 2-1 (340), and 4 (370) illustrated in (b) of Fig. 3 are identical to steps 0 (300), 1 (305), 2-1 (310), and 4 (325) of (a) of Fig. 3, and thus their descriptions are omitted. That is, the owner pairing procedure using NFC and BLE sequentially starts owner pairing with NFC triggering, but owner pairing can be performed via BLE from step 2-2 onwards. Therefore, the user does not need to tag the vehicle's pad (e.g., wireless charging pad) during the owner pairing step using BLE.

[0115] In phase 2-2, the vehicle and the terminal can form a SPAKE2+ channel and derive a system key (345). After phase 2-2, in order to initiate BLE communication, a BLE LL (link layer) connection can be established and owner pairing can be performed through the BLE GATT (generic attribute) profile flow (350). In phase 2-3, a digital key can be generated through BLE communication and a digital certificate and a vehicle certificate can be exchanged (355). In phase 3, the vehicle and the terminal can perform certificate-based mutual authentication (360) and dashboard verification (370).

[0116] FIGS. 4A and 4B are flowcharts for explaining a pairing procedure sequentially utilizing NFC and BLE according to an embodiment of the present disclosure.

[0117] Specifically, FIGS. 4a and 4b are drawings explaining step 2-2 (phase 2) (345) to step 4 (phase 4) (370) described in (b) of FIG. 3, and the terminal (450) is an owner device of a vehicle (400).

[0118] At step 401, the vehicle (400) and the terminal (450) can initiate an NFC transaction.

[0119] In step 402, the vehicle (400) may transmit the selected DK framework AID (application identifier) ​​to the terminal (450). In step 403, the vehicle (400) and the terminal (450) may form a SPAKE2+ (simplified password authenticated key exchange) channel. SPAKE2+ (simplified password authenticated key exchange) refers to a password authentication key exchange protocol executed between two parties as described above, and SPAKE2+ functions as a secure channel.

[0120] In steps 404 and 405, the vehicle (400) and the terminal (450) can deviate each system key. A more detailed description is provided later in FIG. 5.

[0121] At step 406, the vehicle (400) and the terminal (450) can transmit and receive an owner pairing control flow. A more detailed description is provided later in FIG. 6.

[0122] In step 407, the terminal (450) may notify the user to tag-off the terminal through a UI or vibration of the device, etc. Step 407 may be performed after step 408 or 409.

[0123] In step 408, the vehicle (400) may establish a BLE LL (link layer) connection and perform owner pairing through the BLE GATT (generic attribute) profile flow to initiate BLE communication (408). That is, the procedure for BLE communication may begin from step 408. A more detailed description will be provided later in FIG. 7.

[0124] In step 409, the vehicle (400) may select and transmit a BLE digital key framework AID (application identifier) ​​to the terminal (450). A more detailed description is provided later in FIG. 8.

[0125] In step 410, the terminal (450) can search for a SPAKE2+ key corresponding to the matching session ID. In step 411, the vehicle (400) can transmit data necessary for generating a digital key to the terminal (450). The data may be encrypted with SPAKE2+. In step 412, the terminal (450) can generate a digital key.

[0126] In step 413, when the terminal (450) transmits the generated digital key to the vehicle (400), the vehicle (400) can read the digital key.

[0127] In step 414, the vehicle (400) can verify the data of the digital key certificate, extract the public key (PK) of the terminal from the digital key certificate, and store the public key of the terminal together with the vehicle owner's access rights.

[0128] At step 415, the vehicle (400) may notify the terminal (450) that BLE pairing is ready.

[0129] At step 416, the vehicle (400) and the terminal (450) can set up BLE pairing and encryption operations.

[0130] At step 417, the terminal (450) may request a standard transaction from the vehicle (400).

[0131] In step 418, the vehicle (400) and the terminal (450) can perform mutual authentication of step 3 (360) of (b) of FIG. 3.

[0132] Steps 419 to 423 relate to Dashboard verification (365) after step 3 (360) of (b) of FIG. 3.

[0133] In step 419, the vehicle (400) and the terminal (450) can pop up the key derivation. In steps 420 and 421, the vehicle (400) and the terminal (450) can pop up the digital key-related information on the dashboard of the vehicle and the screen of the terminal, respectively. In step 422, the vehicle (400) can receive user confirmation input through the dashboard.

[0134] In step 423, the vehicle (400) may perform verification of the terminal (450). If verification of the terminal fails, it is considered as a failure of owner pairing, and related information may be deleted, user notification may be issued, related history may be saved, etc., and subsequent actions may not be performed.

[0135] In step 424, the vehicle (400) and the terminal (450) may perform an owner pairing termination (in the BLE session). Step 424 may be optionally included.

[0136] FIG. 5 is a drawing for explaining a system key derivation operation of a pairing procedure sequentially utilizing NFC and BLE according to an embodiment of the present disclosure.

[0137] More specifically, the contents related to steps 404 and 405 of FIG. 5 are described.

[0138] In steps 404 and 405 of FIG. 4, when the vehicle and the terminal each derive a system key, a Kble_OP_sessionId can be additionally generated. The generated Kble_OP_sessionId can be included in the Owner Pairing Phase 2: SPAKE2+ Flow and Certificate Exchange section of CCC standard 19.5.1. The vehicle can later add the Kble_OP_sessionId to the field of the BLE Adv packet and to the BLE DK framework AID select field.

[0139] FIGS. 6A, 6B, and 6C are drawings for explaining an owner pairing procedure of a pairing procedure sequentially utilizing NFC and BLE according to an embodiment of the present disclosure.

[0140] FIGS. 6A, 6B, and 6C are diagrams specifically illustrating the owner pairing control flow related to step 406 of FIG. 4. The vehicle (600) and terminal (650) of FIG. 6 may include the vehicle (400) and terminal (450) of FIG. 4.

[0141] In step 610, the vehicle (600) can transmit an owner pairing control flow command to the terminal (650). That is, the vehicle (600) can transmit information including "proceed with Owner Pairing over BLE" to the terminal in the OP CONTROL FLOW command. For example, referring to the table for the P1 parameter in the OP_CONTORL_FLOW illustrated in FIG. 6b, the vehicle (600) can indicate "continue flow" by setting P1=10h. In addition, referring to the table for the OP_CONTORL_FLOW P2 parameter illustrated in FIG. 6c, the vehicle (600) can indicate "continue Owner Pairing over BLE" by setting P2=04h.

[0142] At step 620, the terminal (650) may transmit an owner pairing control flow response (i.e., acknowledge) to the vehicle (600).

[0143] FIG. 7 is a diagram for explaining a BLE Advertising message when establishing a BLE connection in a pairing procedure sequentially utilizing NFC and BLE according to an embodiment of the present disclosure.

[0144] Fig. 7 relates to an operation of establishing a BLE LL (link layer) connection related to step 408 of Fig. 4. When a vehicle performs a handover from NFC to BLE, it may transmit Kble_OP_sessionId by including it in a BLE Advertising message. In one embodiment, as illustrated in Fig. 7, the data field (e.g., AdvData of ADV_IND) of a BLE Advertising message transmitted from the vehicle to the automotive terminal may include Kble_OP_sessionId, which is 4 bytes long. If the terminal has not performed the previous step of owner pairing via NFC, the advertising including Kble_OP_sessionId may be ignored.

[0145] FIG. 8 is a drawing for explaining a select command that a vehicle transmits to a terminal when establishing a BLE connection in a pairing procedure that sequentially utilizes NFC and BLE according to an embodiment of the present disclosure.

[0146] Figure 8 relates to the operation of the vehicle selecting the AID of the BLE digital key framework from the terminal in step 409 of Figure 4. When selecting the digital key framework as BLE, the vehicle can clearly indicate that it is a selection for a subsequent step linked to a specific session of the NFC owner pairing currently in progress by adding Kble_OP_sessionId to the SELECT command transmitted to the terminal.

[0147] FIG. 9 is a diagram for explaining the verification procedure of each user in a pairing procedure sequentially utilizing NFC and BLE according to an embodiment of the present disclosure.

[0148] FIG. 9 relates to a procedure in which a vehicle and a terminal verify a user on the dashboard and display in steps 419 to 423 of FIG. 4.

[0149] That is, as shown in Figure 4, existing NFC only transmits and receives session IDs for BLE, and the main owner pairing procedure is performed via BLE. Therefore, a procedure is required to confirm that the terminal belongs to the owner within the vehicle. Accordingly, it is confirmed that the vehicle and the terminal have the same authentication number (pop-up key), and the user (owner) can confirm this through the vehicle's dashboard.

[0150] The vehicle and the terminal can secure the same pop-up key. In one embodiment, the vehicle (or terminal) can generate a pop-up key and then transmit it to the terminal (or vehicle). In another embodiment, when the vehicle and the terminal generate a system key such as SPAKE2+ in steps 404 and 405 of FIG. 4, they can each additionally generate a pop-up key. In another embodiment, when the vehicle and the terminal perform mutual authentication using a certificate in step 418 of FIG. 4, they can each additionally generate a pop-up key.

[0151] Afterwards, a pop-up key can be displayed on the screen (900) of the terminal (920) and a pop-up key can be displayed on the dashboard (910) of the vehicle (930). If the displayed authentication numbers of the two devices are the same, the user taps the accept (or continue) button (940) on the dashboard (910) of the vehicle, and in this case, the verification process through the pop-up keys of the vehicle and the terminal can be completed.

[0152] Figure 10 (a) is a flowchart for explaining a pairing procedure using BLE and UWB.

[0153] Referring to (a) of Fig. 10, phase 0 is a preparation phase, in which the terminal prepares a digital key applet and can store a terminal certificate (1000). Phase 1 is a pairing procedure initiation phase, in which a BLE LL (link layer) connection is established and owner pairing can be performed through a BLE GATT (generic attribute) profile flow (1005).

[0154] Phase 2: The terminal generates a digital key and can exchange a vehicle certificate and a digital key certificate (1010).

[0155] Afterwards, the vehicle and the terminal can perform a UWB key exchange operation for UWB communication for precise positioning (1015). That is, the vehicle and the terminal can perform UWB ranging secret key derivation (URSK (UWB ranging secret key) derivation), capability exchange, time synchronization, and secure ranging setup operations. Afterwards, the vehicle can detect whether the terminal is inside the vehicle by using a localization algorithm through the UWB ranging operation in UWB communication (1020).

[0156] In phase 3, mutual authentication is performed based on the certificate, and in phase 4, an immobilizer token can be issued (1025). Phase 4 may be optionally included.

[0157] Figure 10 (b) is a flowchart for explaining a pairing procedure sequentially utilizing BLE and NFC according to an embodiment of the present disclosure.

[0158] Unlike (a) of FIG. 10, (b) of FIG. 10 can perform phase 3 and phase 4 using NFC rather than UWB communication. That is, prior to phase 3, which performs certificate verification for mutual authentication between the vehicle and the terminal, user authentication using NFC can be performed to confirm that the terminal is present in the vehicle and to prevent man-in-the-middle (MITM) attacks.

[0159] Referring to Fig. 10(b), phase 0 is a preparation phase, in which the terminal prepares the DK applet and can store the terminal certificate (1030). Phase 1 is a pairing procedure initiation phase, in which a BLE LL (link layer) connection is established and owner pairing can be performed through the BLE GATT (generic attribute) profile flow (1035).

[0160] In phase 2, the terminal generates a digital key and can exchange a vehicle certificate and a digital key certificate (1040).

[0161] In phase 3, the vehicle and the terminal perform mutual authentication based on a certificate using NFC communication (1045), and in phase 4, an immobilizer token can be issued (1050). Phase 4 may be optionally included.

[0162] Figure 11a is a flowchart for explaining a pairing procedure using BLE and UWB.

[0163] FIG. 11A is a diagram specifically illustrating the operation of FIG. 10A. Step 1120 corresponds to phase 0 of FIG. 10A, and step 1130 corresponds to phase 1 and phase 2 of FIG. 10A, illustrating the operation in BLE communication. Step 1140 corresponds to preparing UWB ranging in BLE communication, and corresponds to the UWB key exchange (1020) of FIG. 10A. Step 1150 corresponds to performing UWB ranging in UWB communication, and step 1160 corresponds to phase 3 and phase 4 of FIG. 10A.

[0164] FIG. 11b is a flowchart for explaining a pairing procedure sequentially utilizing BLE and NFC according to an embodiment of the present disclosure.

[0165] FIG. 11B is a diagram related to the operation of FIG. 10B. Step 1170 corresponds to phase 0 of FIG. 10B, and step 1180 corresponds to phase 1 and phase 2 of FIG. 10B, and is an operation related to owner pairing and handover to NFC. Step 1190 corresponds to phase 3 of FIG. 10B, and is an operation for performing owner pairing in NFC communication. Step 1195 corresponds to phase 4 of FIG. 10B. The operations included in each phase are described in detail in FIG. 12.

[0166] FIG. 12 is a flowchart for explaining a pairing procedure sequentially utilizing BLE and NFC according to an embodiment of the present disclosure.

[0167] FIG. 12 is a diagram specifically explaining the pairing procedure sequentially utilizing BLE and NFC of FIG. 11b. The vehicle (1200) and terminal (1250) of FIG. 12 may be, for example, the vehicle (1100) and terminal (1110) of FIG. 11b.

[0168] Step 1201 is included in step 1180 of FIG. 11B, and in step 1201, the vehicle (1200) may transmit a BLE Advertising message (e.g., BLE ADV_IND) to the terminal (1250). The vehicle (1200) may transmit the BLE Advertising message to the terminal (1250) including information indicating BLE Owner pairing without UWB capability.

[0169] In step 1202, the terminal (1250) checks whether the Owner pairing does not involve UWB capability, and if so, can proceed to the next step.

[0170] In step 1203, the vehicle (1200) and the terminal (1250) establish a BLE LL (link layer) connection and can perform owner pairing through the BLE GATT (generic attribute) profile flow.

[0171] In step 1204, the terminal (1250) may transmit a Command Complete SubEvent to the vehicle (1200). In this case, the terminal (1250) may request owner pairing from the vehicle (1200). In step 1205, the terminal (1250) may establish a SPAKE2+ channel, exchange a vehicle certificate and a digital key certificate, and generate a digital key. In step 1206, the vehicle (1200) may transmit a Command Complete Subevent to the terminal (1250). In this case, the vehicle (1200) may notify the terminal (1250) of BLE_Pairing_Ready. In step 1207, the vehicle (1200) and the terminal (1250) may set up BLE pairing and encryption operations.

[0172] At step 1208, the terminal (1250) may transmit a Command Complete Subevent to the vehicle (1200). In this case, the terminal (1250) may request an NFC standard transaction for BLE owner pairing without UWB capability from the vehicle (1200).

[0173] In step 1209, the terminal (1250) may notify the user to tag the terminal through a UI or vibration of the device, etc. In step 1210, the terminal (1250) may be placed on the NFC pad of the vehicle by the user.

[0174] In step 1211, a vehicle (1200) and a terminal (1250) perform mutual authentication based on a certificate using NFC communication, and an immobilizer token can be issued in step 1212. Step 1212 may be optionally included.

[0175] FIG. 13 is a diagram for explaining BLE advertisement data in a pairing procedure sequentially utilizing BLE and NFC according to an embodiment of the present disclosure.

[0176] More specifically, FIG. 13 describes the contents related to step 1201 of FIG. 12.

[0177] As shown in FIG. 12, a vehicle that supports BLE+NFC Owner Pairing can send an advertisement for Owner Pairing by adding information that means “Supports BLE Owner Pairing using NFC even without UWB.” In one embodiment, as shown in FIG. 13, a data field (e.g., AdvData of ADV_IND) of a BLE Advertising message transmitted from a vehicle to an automobile terminal can include BLE OP without UWB support of 1 byte length. In one embodiment, a terminal without UWB can receive a BLE Advertisement and proceed with subsequent steps such as a BLE connection connection request only if it supports BLE+NFC Owner Pairing.

[0178] FIG. 14 is a drawing for explaining a message transmitted by a terminal in a pairing procedure sequentially utilizing BLE and NFC according to an embodiment of the present disclosure.

[0179] More specifically, FIG. 14 describes the contents related to step 1208 of FIG. 12.

[0180] When performing BLE+NFC Owner Pairing as shown in Fig. 12, step 1205 of Fig. 12

[0181] After forming a SPAKE2+ channel and exchanging vehicle certificates and digital key certificates, the terminal can request the vehicle to proceed with the NFC verification step to perform subsequent verification procedures via NFC.

[0182] FIG. 14 illustrates a list of command_status within a command complete subevent message. In one embodiment, the terminal may transmit command_status by indicating Request_NFC_standard transaction_for_BLE_OP_w / o_UWB. Accordingly, the terminal may request an NFC standard transaction in phase 3 and subsequent stages of owner pairing for BLE owner pairing without UWB by using Request_NFC_standard transaction_for_BLE_OP_w / o_UWB.

[0183] Figure 15 (a) is a flowchart for explaining a pairing procedure using BLE and UWB.

[0184] Referring to (a) of Fig. 15, phase 0 is a preparation phase, in which the terminal prepares the DK applet and can store the terminal certificate (1500). Phase 1 is a pairing procedure initiation phase, in which a BLE LL (link layer) connection is established and owner pairing can be performed through the BLE GATT (generic attribute) profile flow (1505).

[0185] Phase 2 allows the terminal to generate a digital key (DK), transmit the key, and verify the digital key (DK) and public key (PK) (1510).

[0186] Afterwards, the vehicle and the terminal can perform a UWB key exchange operation for UWB communication for precise positioning (1515). That is, the vehicle and the terminal can perform UWB ranging secret key derivation (URSK (UWB ranging secret key) derivation), capability exchange, time synchronization, and secure ranging setup operations. Afterwards, the vehicle can detect whether the terminal is inside the vehicle using a localization algorithm through the UWB ranging operation in UWB communication (1520).

[0187] In phase 3, mutual authentication is performed based on the certificate, and in phase 4, an immobilizer token can be issued (1525). Phase 4 may be optionally included.

[0188] Figure 15 (b) is a flowchart for explaining a pairing procedure using only BLE according to an embodiment of the present disclosure.

[0189] Unlike (a) of FIG. 15, (b) of FIG. 15 can perform the owner pairing procedure using only BLE communication without using UWB communication. In one embodiment, after step 3 (phase 3) of performing certificate verification for mutual authentication between the vehicle and the terminal, the presence of the terminal within the vehicle can be confirmed, and user authentication can be performed using verification on the vehicle's dashboard to prevent man-in-the-middle (MITM) attacks.

[0190] Referring to Figure 15(b), phase 0 is a preparation phase, in which the terminal prepares a digital key applet and can store a terminal certificate (1530). Phase 1 is a pairing procedure initiation phase, in which a BLE LL (link layer) connection is established and owner pairing can be performed through a BLE GATT (generic attribute) profile flow (1535).

[0191] Phase 2: The terminal generates a digital key and can exchange a vehicle certificate and a digital key certificate (1540).

[0192] In phase 3, the vehicle and terminal perform mutual authentication based on a certificate using NFC communication (1545), and the vehicle and terminal can perform dashboard verification (1550). In phase 4, an immobilizer token can be issued (1550). Phase 4 may be optionally included.

[0193] FIG. 16 is a flowchart for explaining a pairing procedure using only BLE according to an embodiment of the present disclosure.

[0194] Figure 16 is a drawing specifically explaining the pairing procedure using only BLE of Figure 15b.

[0195] In step 1601, the vehicle (1600) may transmit a BLE Advertising message (e.g., BLE ADV_IND) to the terminal (1650). The vehicle (1600) may transmit to the terminal (1650) information indicating BLE Owner pairing without UWB capability in the BLE Advertising message.

[0196] In step 1602, the terminal (1650) checks whether the Owner pairing does not involve UWB capability, and if so, can proceed to the next step.

[0197] In step 1603, the vehicle (1600) and the terminal (1650) establish a BLE LL (link layer) connection and can perform owner pairing through the BLE GATT (generic attribute) profile flow.

[0198] In step 1604, the terminal (1650) may transmit a Command Complete SubEvent to the vehicle (1600). In this case, the terminal (1650) may request owner pairing from the vehicle (1600). In step 1605, the terminal (1650) may establish a SPAKE2+ channel, exchange a vehicle certificate and a digital key certificate, and generate a digital key. In step 1606, the vehicle (1600) may transmit a Command Complete Subevent to the terminal (1650). In this case, the vehicle (1600) may notify the terminal (1650) of BLE_Pairing_Ready. In step 1607, the vehicle (1600) and the terminal (1650) may set up BLE pairing and encryption operations.

[0199] At step 1608, the terminal (1650) may transmit a Command Complete Subevent to the vehicle (1600). In this case, the terminal (1650) may request a standard transaction for BLE owner pairing without UWB capability from the vehicle (1600).

[0200] In step 1609, the vehicle (1600) and the terminal (1650) can perform mutual authentication using a BLE session. In steps 1610 and 1611, the vehicle (1600) and the terminal (1650) can pop up the digital key-related information on the dashboard of the vehicle (1600) and the screen of the terminal (1650), respectively. In step 1612, the vehicle (1600) can receive user confirmation input through the dashboard.

[0201] In step 1613, the vehicle (1600) may perform verification of the terminal (1650). If verification of the terminal fails, it is considered as a failure of owner pairing, and related information may be deleted, user notification may be issued, related history may be saved, etc., and subsequent actions may not be performed.

[0202] In step 1614, the vehicle (1600) and the terminal (1650) may issue an immobilizer token. Step 1614 may be optionally included.

[0203] FIG. 17 is a diagram for explaining BLE advertisement data in a pairing procedure using only BLE according to an embodiment of the present disclosure.

[0204] More specifically, FIG. 17 describes the contents related to step 1601 of FIG. 16.

[0205] As shown in FIG. 16, a vehicle that supports BLE-only owner pairing can send an advertisement for Owner Pairing by adding information that means, "Supports BLE-only Owner Pairing using BLE even without UWB." In one embodiment, as shown in FIG. 17, a BLE Advertising message transmitted from a vehicle to an automobile terminal can include a BLE-only Owner Pairing capability of 1 byte in length in a data field (e.g., AdvData of ADV_IND). In one embodiment, a terminal without UWB can receive a BLE Advertisement and proceed with subsequent steps, such as a BLE connection connection request, only if it supports BLE-only Owner Pairing.

[0206] FIG. 18 is a drawing for explaining a message transmitted by a terminal in a pairing procedure sequentially utilizing BLE and NFC according to an embodiment of the present disclosure.

[0207] More specifically, FIG. 18 describes the contents related to step 1608 of FIG. 16.

[0208] When performing BLE Only Owner Pairing as shown in FIG. 16, after forming a SPAKE2+ channel in step 1605 of FIG. 16 and exchanging a vehicle certificate and a digital key certificate, the terminal (1650) can transmit a signal to the vehicle (1600) to proceed with BLE Owner Pairing.

[0209] FIG. 18 illustrates a list of command_status within a command complete subevent message. As an example, a terminal (1650) may transmit command_status by indicating Request_BLE_Only_Owner_pairing. Accordingly, the terminal may request owner pairing of only BLE without UWB using Request_BLE_Only_Owner_pairing. In addition, the terminal (1650) may additionally request dashboard verification.

[0210] FIGS. 19A and 19B are diagrams for explaining information about the pairing capability of a vehicle according to an embodiment of the present disclosure.

[0211] FIG. 19a considers a case where a vehicle (1900) supports both order pairing using only BLE and BLE+NFC owner pairing, and the vehicle (1900) can include vehicle owner pairing capability (Vehicle OP Capability) information in a BLE advertisement message.

[0212] In step 1901, a vehicle (1900) may transmit a BLE Advertising message (e.g., BLE ADV_IND) to a terminal (1950). The BLE Advertising message may include vehicle owner pairing capability (Vehicle OP Capability) information.

[0213] In step 1902, the terminal (1950) can proceed with subsequent procedures only if it confirms the vehicle owner pairing capability and the terminal also supports it.

[0214] Figure 19b illustrates the contents related to step 1901 of Figure 19a. In one embodiment, as illustrated in Figure 19b, a vehicle may include a 1-byte long Vehicle OP capability in the data field (e.g., AdvData of ADV_IND) of a BLE Advertising message transmitted by the vehicle to the automotive terminal. In one embodiment, the Vehicle OP capability may represent a bitmap identical to the bitwise "OR" of the supported vehicle owner pairing functions.

[0215] Figure 20 is a flowchart showing an operation method of a terminal according to an embodiment of the present disclosure.

[0216] The terminal of Fig. 20 is an owner device of a vehicle and performs owner pairing with the vehicle. In one embodiment, a terminal performing owner pairing with a vehicle in a wireless communication system can establish a connection necessary for owner pairing with the vehicle using a first communication method in step 2010. In step 2020, the terminal can receive a first message from the vehicle using the first communication method, including information indicating a communication method for performing owner pairing. In step 2030, the terminal can perform mutual authentication with the vehicle based on the information indicating the communication method for performing the owner pairing.

[0217] In one embodiment, if the information indicating the communication method for performing the owner pairing indicates a second communication method, the terminal may receive a session identifier of the second communication method from the vehicle. In one embodiment, if the information indicating the communication method for performing the owner pairing indicates a second communication method, the terminal may transmit a second message requesting an authentication procedure using the second communication method to the vehicle.

[0218] In one embodiment, the terminal may display a pop-up number associated with the vehicle on the display. In one embodiment, if the first communication method is Bluetooth and the information indicating the communication method for performing the owner pairing indicates that only the first communication method is to be used, the pop-up number associated with the vehicle may be displayed on the display.

[0219] FIG. 21 is a flowchart showing an operation method of a vehicle according to an embodiment of the present disclosure.

[0220] The vehicle of Fig. 21 performs owner pairing with a terminal, which is an owner device. In one embodiment, a vehicle performing owner pairing with a terminal in a wireless communication system may, in step 2110, form a connection necessary for owner pairing with the terminal using a first communication method. In step 2120, the vehicle may transmit a first message including information indicating a communication method for performing owner pairing to the terminal using the first communication method. In step 2130, the vehicle may perform mutual authentication with the terminal based on the information indicating the communication method for performing the owner pairing.

[0221] In one embodiment, if the information indicating the communication method for performing the owner pairing indicates a second communication method, the vehicle may transmit a session identifier of the second communication method to the terminal. In one embodiment, if the information indicating the communication method for performing the owner pairing indicates a second communication method, the vehicle may receive a second message from the terminal requesting an authentication procedure using the second communication method.

[0222] In one embodiment, the vehicle may display a pop-up number associated with the terminal on the display. In one embodiment, the vehicle may display a pop-up number associated with the terminal on the display when the first communication method is Bluetooth and the information indicating the communication method for performing the owner pairing indicates that only the first communication method is used.

[0223] FIG. 22 is a structural diagram showing the structure of an electronic device according to an embodiment of the present disclosure.

[0224] The electronic device of FIG. 22 may include the electronic device and vehicle of the present disclosure.

[0225] An electronic device according to one embodiment of the present disclosure may include a processor (2220) that controls the overall operation of the electronic device, a transceiver (2200) including a transmitter and a receiver, and a memory (2210). Of course, the electronic device is not limited to the above example, and the electronic device may include more or fewer components than the configuration illustrated in FIG. 22.

[0226] According to one embodiment of the present disclosure, the transceiver (2200) can transmit and receive signals with network entities or other electronic devices (e.g., terminals or vehicles). The signals transmitted and received with the electronic devices can include control information and data. In addition, the transceiver (2200) can receive signals through a wireless channel, output them to the processor (2220), and transmit the signals output from the processor (2220) through the wireless channel.

[0227] According to one embodiment of the present disclosure, the processor (2220) can control an electronic device to perform any one of the operations described above. Meanwhile, the processor (2220), the memory (2210), and the transceiver (2200) do not necessarily have to be implemented as separate modules, and can of course be implemented as a single component in the form of a single chip. In addition, the processor (2220) and the transceiver (2200) can be electrically connected. In addition, the processor (2220) can be an Application Processor (AP), a Communication Processor (CP), a circuit, an application-specific circuit, or at least one processor.

[0228] According to one embodiment of the present disclosure, the memory (2210) can store data such as basic programs, application programs, and setting information for the operation of the electronic device. In particular, the memory (2210) provides the stored data upon request of the processor (2220). The memory (2210) can be configured as a storage medium or a combination of storage media such as a ROM, a RAM, a hard disk, a CD-ROM, and a DVD. In addition, there can be a plurality of memories (2210). In addition, the processor (2220) can perform the above-described embodiments based on a program for performing the above-described embodiments of the present disclosure stored in the memory (2210).

[0229] In the specific embodiments of the present invention described above, components included in the invention are expressed in the singular or plural form depending on the specific embodiment presented. However, the singular or plural expressions are selected to suit the presented situation for convenience of explanation, and the present invention is not limited to singular or plural components. Even components expressed in the plural form may be composed of singular elements, or even components expressed in the singular form may be composed of plural elements.

[0230] While the detailed description of the present invention has described specific embodiments, it is clear that various modifications are possible without departing from the scope of the present invention. Therefore, the scope of the present invention should not be limited to the described embodiments, but should be defined not only by the scope of the following claims but also by equivalents thereof.

Claims

1. In a method of operating a terminal that performs vehicle and owner pairing in a wireless communication system, A step of establishing a connection required for owner pairing using the above vehicle and the first communication method; A step of receiving a first message including information indicating a communication method for performing owner pairing using the first communication method from the vehicle; and A method characterized by comprising: a step of performing mutual authentication with the vehicle based on information indicating a communication method for performing the owner pairing.

2. In paragraph 1, A method further comprising: a step of receiving a session identifier of the second communication method from the vehicle, when the information indicating the communication method for performing the owner pairing indicates a second communication method.

3. In paragraph 1, A method characterized by further comprising: a step of transmitting a second message requesting an authentication procedure using the second communication method to the vehicle when the information indicating the communication method for performing the owner pairing indicates a second communication method.

4. In paragraph 1, The above first communication method is Bluetooth, A method characterized by further comprising: a step of displaying a pop-up number related to the vehicle on a display when the information indicating the communication method for performing the owner pairing indicates using only the first communication method.

5. In a method of operating a vehicle that performs owner pairing with a terminal in a wireless communication system, A step of forming a connection required for owner pairing using the terminal and the first communication method; A step of transmitting a first message including information indicating a communication method for performing owner pairing using the first communication method to the terminal; and A method characterized by comprising: a step of performing mutual authentication with the terminal based on information indicating a communication method for performing the owner pairing.

6. In paragraph 5, A method characterized by further comprising: a step of transmitting a session identifier of the second communication method to the terminal when the information indicating the communication method for performing the owner pairing indicates a second communication method.

7. In Article 5, A method characterized by further comprising: a step of receiving a second message requesting an authentication procedure using the second communication method from the terminal when the information indicating the communication method for performing the owner pairing indicates a second communication method.

8. In paragraph 5, The above first communication method is Bluetooth, A method characterized by further comprising: a step of displaying a pop-up number related to the terminal on a display when the information indicating the communication method for performing the owner pairing indicates using only the first communication method.

9. In a terminal performing vehicle and owner pairing in a wireless communication system, Transmitter and receiver; and comprising at least one processor; wherein the at least one processor comprises: Forming a connection required for owner pairing using the above vehicle and the first communication method, Receive a first message including information indicating a communication method for performing owner pairing using the first communication method from the vehicle, and A terminal configured to perform mutual authentication with the vehicle based on information indicating a communication method for performing the owner pairing.

10. In paragraph 9, at least one processor, A terminal further configured to receive a session identifier of the second communication method from the vehicle when the information indicating the communication method for performing the owner pairing indicates a second communication method.

11. In paragraph 9, at least one processor, A terminal further configured to transmit a second message requesting an authentication procedure using the second communication method to the vehicle when the information indicating the communication method for performing the owner pairing indicates a second communication method.

12. In the 9th paragraph, at least one processor, The above first communication method is Bluetooth, A terminal further characterized in that, when the information indicating the communication method for performing the owner pairing indicates that only the first communication method is used, the terminal is further configured to display a pop-up number related to the vehicle on the display.

13. In a vehicle performing terminal and owner pairing in a wireless communication system, Transmitter and receiver; and comprising at least one processor; wherein the at least one processor comprises: Establish a connection required for owner pairing using the above terminal and the first communication method, Transmitting a first message including information indicating a communication method for performing owner pairing using the first communication method to the terminal, and A vehicle characterized in that it is configured to perform mutual authentication with the terminal based on information indicating a communication method for performing the above owner pairing.

14. In paragraph 13, at least one processor, If the information indicating the communication method for performing the owner pairing indicates a second communication method, the session identifier of the second communication method is transmitted to the terminal, and A vehicle further configured to receive a second message requesting an authentication procedure using the second communication method from the terminal.

15. In the 13th paragraph, the at least one processor, The above first communication method is Bluetooth, A vehicle characterized in that, when information indicating a communication method for performing the owner pairing indicates that only the first communication method is used, a pop-up number related to the terminal is displayed on the display.

Images