WO2022092918A1 - 초광대역 통신을 이용한 결제 방법 및 장치 - Google Patents

초광대역 통신을 이용한 결제 방법 및 장치 Download PDF

Info

Publication number
WO2022092918A1
WO2022092918A1 PCT/KR2021/015481 KR2021015481W WO2022092918A1 WO 2022092918 A1 WO2022092918 A1 WO 2022092918A1 KR 2021015481 W KR2021015481 W KR 2021015481W WO 2022092918 A1 WO2022092918 A1 WO 2022092918A1
Authority
WO
WIPO (PCT)
Prior art keywords
payment
information
message
uwb
transaction information
Prior art date
Application number
PCT/KR2021/015481
Other languages
English (en)
French (fr)
Inventor
조성규
윤강진
한세희
류영선
Original Assignee
삼성전자 주식회사
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 삼성전자 주식회사 filed Critical 삼성전자 주식회사
Priority to KR1020237018293A priority Critical patent/KR20230104650A/ko
Priority to US18/034,241 priority patent/US20230394463A1/en
Priority to EP21886912.1A priority patent/EP4224395A4/en
Priority to CN202180073550.4A priority patent/CN116508044A/zh
Publication of WO2022092918A1 publication Critical patent/WO2022092918A1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/325—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wireless networks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/14—Payment architectures specially adapted for billing systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3224—Transactions dependent on location of M-devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327—Short range or proximity payments by means of M-devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3825—Use of electronic signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0872—Generation of secret information including derivation or calculation of cryptographic keys or passwords using geo-location information, e.g. location data, time, relative position or proximity to other entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H04L9/3213—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02—Services making use of location information
    • H04W4/029—Location-based management or tracking services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/80—Services using short range communication, e.g. near-field communication [NFC], radio-frequency identification [RFID] or low energy communication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q2220/00—Business processing using cryptography
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04B—TRANSMISSION
    • H04B1/00—Details of transmission systems, not covered by a single one of groups H04B3/00 - H04B13/00; Details of transmission systems not characterised by the medium used for transmission
    • H04B1/69—Spread spectrum techniques
    • H04B1/7163—Spread spectrum techniques using impulse radio
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/08—Randomization, e.g. dummy operations or using noise
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless
    • H04L2209/805—Lightweight hardware, e.g. radio-frequency identification [RFID] or sensor

Definitions

  • the present disclosure relates to a payment method, and more particularly, to a payment method and apparatus using UWB.
  • the Internet is evolving from a human-centered connection network where humans create and consume information, to an Internet of Things (IoT) network that exchanges and processes information between distributed components such as objects.
  • IoT Internet of Things
  • IoE Internet of Everything
  • sensing technology wired/wireless communication and network infrastructure, service interface technology, and security technology
  • M2M Machine to Machine
  • MTC Machine Type Communication
  • an intelligent IT (Internet Technology) service that collects and analyzes data generated from connected objects and creates new values in human life can be provided.
  • IoT through convergence and compounding between existing IT (information technology) technology and various industries, is a smart home, smart building, smart city, smart car or connected car, smart grid, health care, smart home appliance, advanced medical service, etc. can be applied in the field of
  • UWB Ultra Wide Band
  • UWB is a wireless communication technology that uses a very wide frequency band of several GHz or more in a baseband without using a wireless carrier.
  • the present disclosure provides a method for processing offline payment at a distance using UWB.
  • the present disclosure provides a payment method that maintains low payment complexity and high security while using UWB.
  • a method of a payment device for providing a payment service using UWB communication includes: transmitting an initiation message for initiating UWB ranging; receiving, from at least one user device, a response message to the initiation message; transmitting a transaction information message for payment to the first user device selected based on the response message; and receiving a payment information message corresponding to the transaction information message from the first user device.
  • the method includes: determining location information for the at least one user terminal based on the response message; generating a user list for the at least one user terminal based on the location information; and selecting the first user device having a payment intent based on the user list.
  • a method of a user device for providing a payment service using UWB communication includes: receiving an initiation message for initiating UWB ranging from the payment device; transmitting a response message to the initiation message to the payment device; receiving a transaction information message for payment from the payment device; and transmitting a payment information message corresponding to the transaction information message to the payment device.
  • the method may further include performing authentication for payment based on the transaction information message.
  • a payment device for providing a payment service using UWB communication includes: a transceiver; and a control unit connected to the transceiver, wherein the control unit: transmits an initiation message for initiating UWB ranging, and sends a response message to the initiation message from at least one user device may be configured to receive, transmit a transaction information message for payment to the selected first user device based on the response message, and receive a payment information message corresponding to the transaction information message from the first user device there is.
  • a user device for providing a payment service using UWB communication includes: a transceiver; and a control unit connected to the transceiver, wherein the control unit: receives an initiation message for initiating UWB ranging from the payment device, and sends a response message to the payment device ), receive a transaction information message for payment from the payment device, and transmit a payment information message corresponding to the transaction information message to the payment device.
  • the initiation message includes information for identifying the payment device or a store associated with the payment device and information related to a contention window for UWB ranging in a contention-based ranging mode. may include
  • the information related to the contention window may include flag information indicating whether contention window size information indicating the duration of the contention window exists.
  • the contention window size information when the flag information is set to a first value, the contention window size information does not exist in the initiation message, and when the flag information is set to a second value, the contention window size information may exist in the initiation message there is.
  • the response message may include information for identifying a user device that has transmitted the response message.
  • the transaction information message includes transaction information for the payment or link information for obtaining the transaction information, and includes the transaction amount, merchant name, merchant ID, and order number. ), a payment protocol, a shipping address, an address for a payment sheet, and information about at least one of an allowed card brand or recurring.
  • the transaction information message may include a first random number for encryption of the transaction information message, and first signature information generated based on the transaction information and the first random number.
  • the payment information message includes payment information and link information for obtaining the payment information, wherein the payment information includes a card number, expiration date, authentication service, and total currency purchased. , information about at least one of a purchased total currency, amount, billing information, or a token.
  • the payment information message further includes a second random number for encryption of the payment information message, and second signature information generated based on the payment information, the first random number and the second random number can do.
  • the STS (Scrambled Timestamp Sequence) setting for the UWB communication corresponds to a static STS setting, and the static STS value for the static STS setting is to be generated based on the value of the VENDOR ID.
  • the ranging frame configuration for the UWB communication corresponds to the STS packet (SP) 1 configuration
  • the ranging mode of the UWB ranging is a contention-based ranging mode. may be applicable.
  • a method of a payment device for processing a payment with a user device using UWB communication includes: transmitting an initiation message for UWB ranging; receiving, from at least one user terminal, a response message to the initiation message; transmitting a transaction information message for payment to the selected first user device; and receiving a payment information message corresponding to the transaction information message from the first user device.
  • the method includes: determining location information for the at least one user terminal based on a response message to the initiation message; generating a user list for the at least one user terminal based on the location information; and selecting the first user device based on the user list.
  • a method of a user device for processing a payment with a payment device using UWB communication includes: receiving an initiation message for UWB ranging from the payment device; transmitting a response message to the initiation message to the payment device; receiving a transaction information message for payment from the payment device; and transmitting a payment information message corresponding to the transaction information message to the payment device.
  • a payment device for processing a payment with a user device using UWB communication includes: a transceiver; and a control unit connected to the transceiver, wherein the control unit: transmits an initiation message for UWB ranging, and receives a response message to the initiation message from at least one user terminal and transmit a transaction information message for payment to the selected first user device, and receive a payment information message corresponding to the transaction information message from the first user device.
  • a user device for processing a payment with a payment device using UWB communication includes: a transceiver; and a control unit connected to the transceiver, wherein the control unit: receives an initiation message for UWB ranging from the payment device, and sends a response message to the payment device to the payment device and transmit, receive a transaction information message for payment from the payment device, and transmit a payment information message corresponding to the transaction information message to the payment device.
  • the initiation message may include information for identifying a store associated with a payment device and information relating to a contention window associated with the UWB ranging.
  • the information related to the contention window may include flag information indicating whether contention window size information indicating the size of the contention window exists.
  • the contention window size information when the flag information is set to a first value, the contention window size information does not exist in the initiation message, and when the flag information is set to a second value, the contention window size information may exist in the initiation message there is.
  • information for identifying the user device that transmitted the response message may be included.
  • the transaction information message includes transaction information for the payment or link information for obtaining the transaction information, and includes the transaction amount, merchant name, merchant ID, and order number. ), a payment protocol, a shipping address, an address for a payment sheet, and information about at least one of an allowed card brand or recurring.
  • the payment information message includes payment information and link information for obtaining the payment information
  • the payment information includes, for example, a card number, an expiration date, an authentication service, and a purchased It may include information about at least one of a total currency, a purchased total currency, amount, billing information, or a token.
  • offline payment can be processed from a distance, and low payment complexity and high security can be maintained.
  • FIG. 1 illustrates an exemplary payment system.
  • FIG. 2 illustrates an example of a payment system using UWB according to an embodiment of the present disclosure.
  • FIG. 3 illustrates another example of a payment system using UWB according to an embodiment of the present disclosure.
  • FIG. 4 illustrates a payment method using UWB according to an embodiment of the present disclosure.
  • FIG. 5 shows an exemplary payment scenario using the payment method using UWB of FIG. 4 .
  • FIG. 6 illustrates a payment method using UWB according to another embodiment of the present disclosure.
  • FIG. 7 illustrates a payment method using UWB according to another embodiment of the present disclosure.
  • FIG. 8 illustrates a method of processing a payment by a payment device using UWB according to an embodiment of the present disclosure.
  • FIG 9 illustrates a method for a user device to process a payment using UWB according to an embodiment of the present disclosure.
  • FIG. 10 is a diagram illustrating a structure of a payment device according to an embodiment of the present disclosure.
  • FIG. 11 is a diagram illustrating a structure of a user device according to an embodiment of the present disclosure.
  • FIG. 12 shows an exemplary architecture of a payment system using UWB according to an embodiment of the present disclosure.
  • each block of the flowchart diagrams and combinations of the flowchart diagrams may be performed by computer program instructions.
  • These computer program instructions may be embodied in a processor of a general purpose computer, special purpose computer, or other programmable data processing equipment, such that the instructions performed by the processor of the computer or other programmable data processing equipment are not described in the flowchart block(s). It creates a means to perform functions.
  • These computer program instructions may also be stored in a computer-usable or computer-readable memory that may direct a computer or other programmable data processing equipment to implement a function in a particular manner, and thus the computer-usable or computer-readable memory.
  • the instructions stored in the flow chart block(s) may also be possible for the instructions stored in the flow chart block(s) to produce an article of manufacture containing instruction means for performing the function described in the flowchart block(s).
  • the computer program instructions may also be mounted on a computer or other programmable data processing equipment, such that a series of operational steps are performed on the computer or other programmable data processing equipment to create a computer-executed process to create a computer or other programmable data processing equipment. It may also be possible that instructions for performing the processing equipment provide steps for performing the functions described in the flowchart block(s).
  • each block may represent a module, segment, or portion of code that includes one or more executable instructions for executing specified logical function(s). It should also be noted that in some alternative implementations it is also possible for the functions recited in blocks to occur out of order. For example, two blocks shown one after another may in fact be performed substantially simultaneously, or it may be possible that the blocks are sometimes performed in a reverse order according to a corresponding function.
  • ' ⁇ unit' used in this embodiment means software or hardware components such as FPGA (Field Programmable Gate Array) or ASIC (Application Specific Integrated Circuit), and ' ⁇ unit' performs certain roles do.
  • '-part' is not limited to software or hardware.
  • ' ⁇ ' may be configured to reside on an addressable storage medium or may be configured to refresh one or more processors.
  • ' ⁇ part' refers to components such as software components, object-oriented software components, class components, and task components, and processes, functions, properties, and programs. Includes procedures, subroutines, segments of program code, drivers, firmware, microcode, circuitry, data, databases, data structures, tables, arrays, and variables.
  • components and ' ⁇ units' may be combined into a smaller number of components and ' ⁇ units' or further separated into additional components and ' ⁇ units'.
  • components and ' ⁇ units' may be implemented to play one or more CPUs in a device or secure multimedia card.
  • ' ⁇ unit' may include one or more processors.
  • the term 'terminal' or 'device' is a mobile station (MS), user equipment (UE), user terminal (UT), wireless terminal, access terminal (AT), terminal, subscriber unit. may be referred to as a (Subscriber Unit), Subscriber Station (SS), wireless device, wireless communication device, Wireless Transmit/Receive Unit (WTRU), mobile node, mobile or other terms.
  • Various embodiments of the terminal include a cellular phone, 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, and a digital camera having a wireless communication function.
  • PDA personal digital assistant
  • the terminal may include a machine to machine (M2M) terminal and a machine type communication (MTC) terminal/device, but is not limited thereto.
  • M2M machine to machine
  • MTC machine type communication
  • the terminal may be referred to as an electronic device or simply a device.
  • An “Application Dedicated File (ADF)” may be, for example, a data structure in an Application Data Structure that may host an application or application specific data.
  • Application Protocol Data Unit may be a command and a response used when communicating with the Application Data Structure in the UWB device.
  • application specific data may be, for example, a file structure having a root level and an application level including UWB control information and UWB session data required for a UWB session.
  • Controller may be a Ranging Device that defines and controls Ranging Control Messages (RCM) (or control messages).
  • RCM Ranging Control Messages
  • Controllee may be a ranging device using a ranging parameter in the RCM (or control message) received from the controller.
  • “Dynamic Scrambled Timestamp Sequence (STS) mode” may be an operation mode in which STS is not repeated during a ranging session. In this mode, the STS is managed by the Ranging device, and the Ranging Session Key that generates the STS can be managed by the Secure Component.
  • STS Dynamic Scrambled Timestamp Sequence
  • Applet may be, for example, an application executed on a Secure Component including UWB parameters and service data.
  • the Applet may be a FiRa Applet defined by a specification of a FiRa consortium (hereinafter, FiRa/FiRa standard).
  • Ranging Device may be a device capable of performing UWB ranging.
  • the Ranging Device may be an Enhanced Ranging Device (ERDEV) defined in IEEE 802.15.4z or a FiRa Device defined by FiRa.
  • the Ranging Device may be referred to as a UWB device.
  • UWB-enabled Application may be an application for UWB service.
  • the UWB-enabled Application may be an application using a Framework API for configuring an OOB Connector, a Secure Service, and/or a UWB service for a UWB session.
  • UWB-enabled Application may be abbreviated as an application or a UWB application.
  • UWB-enabled Application may be a FiRa-enabled Application defined by FiRa.
  • a “Framework” may be a component that provides access to Profiles, individual UWB settings and/or notifications.
  • “Framework” may be a collection of logical software components including, for example, Profile Manager, OOB Connector, Secure Service, and/or UWB service.
  • the Framework may be a FiRa Framework defined by FiRa.
  • OOB Connector may be a software component for establishing an out-of-band (OOB) connection (eg, BLE connection) between Ranging Devices.
  • OOB Connector may be a FiRa OOB Connector defined by FiRa.
  • Profile may be a predefined set of UWB and OOB configuration parameters.
  • Profile may be a FiRa Profile defined by FiRa.
  • Profile Manager may be a software component that implements a profile available on the Ranging Device.
  • the Profile Manager may be a FiRa Profile Manager defined by FiRa.
  • Service may be an implementation of a use case that provides a service to an end-user.
  • Smart Ranging Device may be a ranging device that can implement an optional Framework API.
  • the Smart Ranging Device may be a FiRa Smart Device defined by FiRa.
  • GDF Global Dedicated File
  • Framework API may be an API used by a UWB-enabled Application to communicate with the Framework.
  • “Initiator” may be a Ranging Device that initiates a ranging exchange.
  • OID Object Identifier
  • Out-Of-Band (OOB)” may be data communication that does not use UWB as an underlying wireless technology.
  • RDS Raster Data Set
  • UWB session key e.g., UWB session key, session ID, etc.
  • a “Responder” may be a Ranging Device that responds to an Initiator in a ranging exchange.
  • STS may be a ciphered sequence for increasing the integrity and accuracy of ranging measurement timestamps.
  • the STS may be generated from the ranging session key.
  • a “Secure Channel” may be a data channel that prevents overhearing and tampering.
  • a “Secure Component” may be an entity (eg, SE or TEE) with a defined security level that interfaces with UWBS for the purpose of providing RDS to UWBS, eg, when dynamic STS is used.
  • Secure Element may be a tamper-resistant secure hardware component that can be used as a Secure Component in the Ranging Device.
  • “Secure Ranging” may be ranging based on STS generated through a strong encryption operation.
  • a “Secure Service” may be a software component for interfacing with a Secure Component, such as a Secure Element or a Trusted Execution Environment (TEE).
  • a Secure Component such as a Secure Element or a Trusted Execution Environment (TEE).
  • TEE Trusted Execution Environment
  • Service Applet may be an applet on a Secure Component that handles service specific transactions.
  • Service Data may be data defined by a service provider that needs to be transferred between two ranging devices to implement a service.
  • a “Service Provider” may be an entity that defines and provides hardware and software required to provide a specific service to an end-user.
  • Static STS mode is an operation mode in which STS is repeated during a session, and does not need to be managed by the Secure Component.
  • a “Secure UWB Service (SUS) Applet” may be an applet on the SE that communicates with the applet to retrieve data needed to enable secure UWB sessions with other ranging devices.
  • the SUS Applet may transmit the corresponding data (information) to UWBS.
  • UWB Service may be a software component that provides access to UWBS.
  • UWB Session may be a period from when the Controller and the Controllee start communication through UWB until the communication stops.
  • a UWB Session may include ranging, data transfer, or both ranging/data transfer.
  • UWB Session ID may be an ID (eg, a 32-bit integer) that identifies the UWB Session, shared between the controller and the controller.
  • UWB Session Key may be a key used to protect the UWB Session.
  • the UWB Session Key may be used to create an STS mapped with a UWB Session (or UWB Session ID).
  • the UWB Session Key may be a UWB Ranging Session Key (URSK), and may be abbreviated as a session key.
  • URSK UWB Ranging Session Key
  • UWB Subsystem may be a hardware component implementing UWB PHY and MAC layers (specifications).
  • UWBS may have an interface to Framework and an interface to Secure Component to search for RDS.
  • the UWB PHY and MAC specifications may be, for example, FiRa PHY and FiRa MAC specifications defined by FiRa referring to IEEE 802.15.4/4z.
  • FIG. 1 illustrates an exemplary payment system.
  • the payment system 100 of FIG. 1 may be, for example, a payment system that uses a payment method that requires close contact, such as an NFC (Near Field Communication) payment method as an offline payment method.
  • NFC Near Field Communication
  • a payment system 100 includes a user device 110 , a payment gateway 120 for online payment, and a payment device for offline payment (eg, a point of sales (POS) terminal) ( 130 ), an acquirer device 140 , a card network 150 , and/or a card issuer device 160 .
  • the payment system 100 may further include a Value Added Network 170 between the acquirer device 140 and the card network 150 in an optional configuration.
  • the payment system 100 may use an online payment method and an offline payment method as a payment method.
  • the payment system 100 may perform online payment using a predetermined online payment method through the payment gateway 120 .
  • the payment system 100 may perform an offline payment using a predetermined offline payment method (eg, an NFC payment method) through the payment device 130 such as a POS terminal.
  • a predetermined offline payment method eg, an NFC payment method
  • the acquirer device 140 may perform a role of purchasing a slip and processing a payment on behalf of an affiliated store.
  • the card issuer device 160 is a device of an issuer (eg, a bank, a card company) that issues a card, and may communicate with the acquirer device 140 through the card network 150 to perform a processing operation for payment.
  • an issuer eg, a bank, a card company
  • this new type of offline payment method needs to solve the problems of security and payment complexity caused by performing offline payment using telecommunication.
  • this new type of offline payment method may affect only the operation of the frontend of the payment device (eg, the operation between the payment device and the user device), in contrast to the offline payment method using the existing NFC payment method.
  • compatibility with the existing payment system needs to be maintained.
  • this new type of offline payment method is an offline payment method using UWB communication, and various embodiments will be described.
  • various embodiments of the present disclosure are not limited to being applied only to the offline payment method using UWB communication, and depending on the embodiment, offline payment using a communication method (eg, Bluetooth) having functions and characteristics similar to UWB communication. It is obvious to those skilled in the art that it can be applied to the method as well.
  • a communication method eg, Bluetooth
  • FIG. 2 illustrates an example of a payment system using UWB according to an embodiment of the present disclosure.
  • the payment system 200 of FIG. 2 uses, for example, a payment protocol (payment service/payment application) that can perform offline payment using only communication of a UWB section (session) between a user device capable of UWB communication and a payment device. It may be a payment system used.
  • the payment protocol of the embodiment of FIG. 2 may be referred to as a first payment protocol, a UWB protocol, a UWB payment protocol, or a full payment protocol.
  • the payment protocol of the embodiment of FIG. 2 is compared with the payment protocol of the embodiment of FIG. 3 using communication in the Internet section between the user device and the payment gateway as well as communication in the UWB section between the user device and the payment device for offline payment.
  • the payment system 200 includes a user device 210 , a payment gateway 220 for online payment, and a payment device for offline payment (eg, UWB point of sales (POS) terminal). 230 , an acquirer device 240 , a card network 250 and/or a card issuer device 260 .
  • POS point of sales
  • the operations and roles of the acquirer device 240 , the card network 250 , and the card issuer device 260 for payment may be the same as those described above through the embodiment of FIG. 1 .
  • the payment system 200 may perform online payment using a predetermined online payment method through the payment gateway 220 .
  • the online payment method of the embodiment of FIG. 2 may be the same as, for example, the online payment method of the embodiment of FIG. 1 .
  • the payment system 200 may perform offline payment using a predetermined payment protocol (eg, a complete payment protocol) through the payment device 230 such as a UWB POS terminal.
  • a predetermined payment protocol eg, a complete payment protocol
  • the payment system 200 may perform a UWB ranging procedure, a transaction procedure, and/or a payment procedure through the UWB section.
  • the UWB ranging procedure of the present disclosure may follow the ranging procedure specified in, for example, "IEEE 802.15.4/z standard" and "UWB technical standard of FiRa consortium".
  • the UWB ranging procedure is a single side (SS)-two way ranging (TWR) scheme or a double side (DS) scheme specified in, for example, "IEEE 802.15.4/z standard” and "UWB technical standard of FiRa consortium” )-TWR method may be followed.
  • SS single side
  • DS double side
  • the payment device 230 For offline payment using UWB, the payment device 230 must be able to accurately identify the location and distance of the user device (user) 210 through UWB ranging, and the user device (user) 210 is the payment device (230) must be accurately identified and authenticated.
  • payment complexity should be minimized through a method of accurately understanding the intention of the user to make a payment.
  • user information such as card information should not be exposed during the payment process, and security should be excellent.
  • FIG. 3 illustrates another example of a payment system using UWB according to an embodiment of the present disclosure.
  • the payment system 300 of FIG. 3 for example, differently from the payment protocol of the embodiment of FIG. 2 , for offline payment, not only the communication of the UWB section (session) between the user device and the payment device, but also the user device and the payment gateway It may be a payment system using a payment protocol (payment service/payment application) using communication between the Internet sections.
  • a payment protocol payment service/payment application
  • the payment protocol of the embodiment of Fig. 3 since only the minimum information necessary for offline payment is transmitted through the UWB section, communication in the UWB section for offline payment is simplified compared to the case of using the payment protocol of the embodiment of Fig. 2 can be
  • the payment protocol of the embodiment of FIG. 3 when used, online payment can be easily performed through information transmitted through the UWB section, so that payment coverage can be expanded.
  • the payment protocol of the embodiment of FIG. 3 may be referred to as a second payment protocol or a simplified payment protocol.
  • the payment system 300 includes a user device 310 , a payment gateway 320 for online payment, and a payment device for offline payment (eg, UWB point of sales (POS) terminal). 330 , an acquirer device 340 , a card network 350 and/or a card issuer device 360 .
  • POS point of sales
  • the operations and roles of the acquirer device 340 , the card network 350 , and the card issuer device 360 for payment may be the same as those described above through the embodiment of FIG. 1 .
  • the payment system 300 may perform online payment using a predetermined online payment method through the payment gateway 320 .
  • the online payment method of the embodiment of FIG. 3 may be, for example, the same as the online payment method of the embodiment of FIG. 1 .
  • the online payment method of the embodiment of FIG. 3 may be a new type of online payment method that additionally uses information transmitted through the UWB section. Through this, offline payment of the payment system 300 may also be easily performed.
  • the payment system 300 may perform offline payment using a predetermined payment protocol (eg, a simplified payment protocol) through the payment device 330 such as a UWB POS terminal.
  • a predetermined payment protocol eg, a simplified payment protocol
  • the payment system 300 includes at least one internet section (eg, an internet section between the user device 310 and the payment gateway 320 and/or an internet section between the payment gateway 320 and the payment device 330)
  • a simplified transaction procedure and/or a simplified payment procedure may be performed through the UWB section compared to the method of FIG. 2 . Through this, it is possible to reduce payment complexity for offline payment of the payment system 300 .
  • FIG. 3 Various embodiments using the payment system and payment protocol of FIG. 3 will be described below with reference to, for example, FIGS. 4 to 7 .
  • FIG. 4 illustrates a payment method using UWB according to an embodiment of the present disclosure.
  • FIG. 4 shows an example of an offline payment method using UWB.
  • the user device 410 and the payment device 420 correspond to devices capable of UWB communication.
  • the user device and the payment device may be devices implemented according to a protocol stack including a MAC layer and a PHY layer defined by "IEEE 802.15.4 standard” and "UWB technical standard of FiRa consortium”.
  • the user device 410 and/or the payment device 420 is a UWB device that provides a payment service (application) using UWB communication (eg, Enhanced Ranging Device (ERDEV) defined in IEEE 802.15.4z) or FiRa Device defined by FiRa).
  • a payment service application
  • UWB communication eg, Enhanced Ranging Device (ERDEV) defined in IEEE 802.15.4z
  • FiRa Device defined by FiRa
  • a static STS generation mode (method) may be used instead of a dynamic STS generation mode (method).
  • the STS configuration (UWB STS configuration) for UWB communication (or UWB session) of the embodiment of FIG. 4 may correspond to the static STS configuration.
  • the STS generated based on the VENDOR_ID field and the STATIC_STS_CONFIG field set by UCI (UWB Command Interface) for a specific payment application (service/protocol) (eg, Samsung Pay) is used for UWB communication (UWB ranging).
  • the VENDOR_ID field may include an identifier of a vendor
  • the STATIC_STS_CONFIG field may include a value for static STS configuration.
  • the STATIC_STS_CONFIG field may be referred to as a STATIC_STS_IV field.
  • the STS generation procedure and related procedures may be performed with reference to, for example, procedures stipulated in "IEEE 802.15.4/z standard" and "UWB technical standard of FiRa consortium".
  • the procedure of the embodiment of FIG. 4 may be a procedure performed when a payment application for payment using UWB is started in the user device 410 .
  • the payment device 420 may transmit an initiation message for UWB ranging ( 4010 ). As an embodiment, the payment device 420 may broadcast an initiation message.
  • the initiation message may include information for identifying a store associated with the payment device (eg the name of the store) and/or contention window related information associated with UWB ranging (eg, the size of the contention window). , and/or information indicating the existence of a contention window).
  • the initiation message may be a Ranging Initiation Message (UWB message/RFRAME) defined in "IEEE 802.15.4z standard" and "UWB MAC standard of FiRa consortium".
  • the initiation message may be a Ranging Initiation Message (SP1 RFRAME) configured when a ranging frame (RFRAME) configuration is set to an STS Packet Configuration structure 1 (SP1).
  • the initiation message may include at least one piece of information used for UWB ranging (eg, a transmission timestamp indicating a transmission time of the initiation message).
  • the STS in the STS Packet Configuration structure 1 (SP1) configuration, in the STS packet (PHY packet) carrying the RFRAME (or UWB message), the STS (or the STS field) is a start-of-frame delimiter (SFD). It may be a construct that follows a field. For a description of the SP1 configuration, refer to "IEEE 802.15.4z Specification” and “FiRa Consortium Specification”.
  • an initiation message with SP1 configuration may include a MAC header, a MAC payload including at least one payload IE (information element), and/or a MAC footer. there is.
  • the initiation message may include a header IE and/or a payload IE.
  • Tables 1 and 2 below show an example of the payload IE of the initiation message.
  • the initiation message may include a payload IE including a length field (information), a group ID field (information), a type field (information), and/or a content field (information).
  • the content field may include a vendor organizationally unique identifier (OUI) field, a UWB message ID field, a competition window size presence field, a store name field, and/or a competition window size field.
  • UUI vendor organizationally unique identifier
  • UWB message ID field a competition window size presence field
  • a store name field may be referred to as StoreName.mPOS.
  • the length field indicates the size (length) of the content field.
  • the group ID field indicates the type of the corresponding IE.
  • the group ID field may be set to a value (eg, 2) indicating a vendor specific nested IE.
  • the type field indicates the type of the corresponding IE.
  • the type field may be set to a value (eg, 1) indicating that the type of the IE is a payload IE.
  • the vendor OUI field indicates an OUI of a vendor.
  • the vendor OUI field may be, for example, a field including a unique value of a vendor defining a message in order to ensure the uniqueness of messages defined based on the IEEE standard.
  • the vendor OUI field may be set to a value indicating Samsung OUI and/or FiRa OUI.
  • the UWB message ID field may be a field indicating which message the corresponding payload IE is.
  • the UWB message ID field may be set to a value indicating the initiation message.
  • the contention window size presence field indicates whether a contention window size field exists. For example, when the contention window size field does not exist in the content field (or in the initiation message), the contention window size field may be set to a first value (eg, 0). Alternatively, when the contention window size field is present in the content field (or initiation message), the contention window size field may be set to a second value (eg, 1). In this disclosure, the contention window size presence field may be referred to as flag information.
  • the store name field indicates the name of the store.
  • the store name field may be set to a value indicating the name of a store associated with the payment device 420 (eg, a store using the payment device 420 ).
  • the contention window size field indicates a time duration of the contention window.
  • the contention window size field may indicate the duration of the contention window in ms.
  • the contention window size field may be included in the initiation message when the ranging mode of UWB ranging is a contention-based ranging mode.
  • each user equipment 410 may perform contention-based ranging by sending a response message within the period of the contention window indicated by the contention window size field.
  • the user device 410 may transmit a response message to the initiation message to the payment device 420 ( 4020 ).
  • each user device 410 receiving the initiation message may unicast a response message to the payment device 420 .
  • the user device 410 may transmit a response message to the payment device within a period of the contention window indicated by the contention window size field. Through this, the user equipment 410 can perform contention-based ranging with other user equipments.
  • the response message may include information for identifying the user device 410 (eg, a name or ID of the user device (mobile device)).
  • the response message may be a Ranging Response Message (UWB message/RFRAME) defined in "IEEE 802.15.4z standard" and "UWB MAC standard of FiRa consortium".
  • the initiation message may be a Ranging Response Message (SP1 RFRAME) corresponding to a Ranging Initiation Message configured when a ranging frame (RFRAME) configuration is set to a Scrambled Timestamp Sequence (STS) Packet Configuration structure 1 (SP1).
  • the response message includes at least one piece of information used for UWB ranging (eg, response time information indicating a time from reception of an initiation message to transmission of a corresponding response message and/or transmission of a response message). transmission timestamp indicating time).
  • a response message with SP1 configuration may include a MAC header, at least one payload IE (MAC payload including (information element), and/or MAC footer).
  • SP1 Response Message/SP1 Ranging Response Message may include a MAC header, at least one payload IE (MAC payload including (information element), and/or MAC footer).
  • the response message may include a header information element (IE) and/or a payload IE.
  • IE header information element
  • Tables 3 and 4 below show an example of a payload IE (information element) of a response message.
  • the response message may include a payload IE including a length field (information), a group ID field (information), a type field (information), and/or a content field (information).
  • the content field may include a vendor OUI field, a UWB message ID field, and a device name field (information).
  • the device name field may be referred to as RandomID.Device.
  • Definitions and descriptions of the length field, group ID field, type field, vendor OUI field, and UWB message ID field of the response message in Tables 3 and 4 are the length field, group ID field, type field, and vendor of the initiating message in Table 1. You can refer to the definition and description of the OUI field and the UWB message ID field. Meanwhile, the UWB message ID field of Tables 3 and 4 may be set to a value indicating a response message.
  • the response messages of Tables 3 and 4 include a device name field in the content field.
  • the device name field indicates the name of the user device.
  • the device name field may be set to a value indicating the name of the user's mobile device.
  • the name of the mobile device may be a random ID for the mobile device.
  • the payment device 420 may identify the user device 410 that has transmitted the response message.
  • the response message may further include a Nonce field (Random.Device) and/or a Cryptogram field (Cryptogram.Device).
  • the Nonce field may include a random number for generating a session key.
  • the Cryptogram field may include data for authenticating a random number.
  • the payment device 420 may use a predetermined ranging method (eg, SS-TWR or DS-TWR scheme) to provide location information (eg, user device) for the identified user device based on the response message.
  • a predetermined ranging method eg, SS-TWR or DS-TWR scheme
  • location information eg, user device
  • the relative distance between the 410 and the payment device 420 may be determined, and a list of user devices (users) generated based on the location information may be provided.
  • the payment device 420 determines location information by calculating a range for each user device based on the response message, and a list of user devices (users) arranged in order of distance based on the location information can provide In this case, among the user devices (users), only the user devices (users) within a predetermined distance from the payment device 420 may be included in the list of user devices (users). One user device among the user devices in the list thus provided may be selected. For example, according to a predetermined scheme, the user device 410 of FIG. 4 may be selected as the user device having a payment intent.
  • the payment device 420 may transmit a transaction information message for payment (eg, offline payment) to the selected user device 410 ( 4030 ).
  • the payment device 420 may transmit the transaction information message through an in-band or out-of-band connection. That is, the payment device 420 may transmit the transaction information message through UWB communication/session (in-band communication/session) or non-UWB communication/session (out-of-band communication/session).
  • the transaction information message may be a UWB Message defined in "UWB MAC Specification of FiRa Consortium".
  • the transaction information message may include transaction information for offline payment.
  • Transaction information may include, for example, an amount (currency, price, tax), merchant name, merchant ID, order number, payment protocol, and shipping address (shipping). address), an address to a payment sheet, allowed card brands, and/or information about recurring.
  • an amount currency, price, tax
  • merchant name merchant name
  • merchant ID merchant ID
  • order number order number
  • payment protocol shipping address
  • address shipping address
  • transaction information includes merchant name, amount (currency, price, tax), seller ID, order number, product shipping address ( shipping address), billing address, address visibility option, payment protocol, merchant country code, and/or supported card brand.
  • the transaction information message may include link information (eg, a uniform resource locator (URL)) for obtaining the transaction information.
  • link information eg, a uniform resource locator (URL)
  • the transaction information message includes link information for obtaining transaction information instead of complete transaction information may be referred to as a “simplified transaction”.
  • simple transaction since only minimal information for payment can be transmitted through UWB communication, there is an advantage in that the transmission overhead is reduced. An example of this simplified transaction case will be described below with reference to FIGS. 6 and 7 .
  • Table 6 shows an example of link information included in the transaction information message in the case of a simplified transaction case.
  • the transaction information message may include a header IE and/or a payload IE.
  • Tables 7 and 8 below show an example of a payload IE of a transaction information message.
  • the transaction information message including the payload IE of Tables 7 and 8 below may be, for example, a transaction information message used in the case of a fully implemented transaction case.
  • the transaction information message may include a payload IE including a length field (information), a group ID field (information), a type field (information) and/or a content field (information). .
  • the content field includes a vendor OUI field, a UWB message ID field, a random challenge field (information) (randPoS), a signature field and/or a transaction information field. can do.
  • the content field includes a vendor OUI field, a UWB message ID field, a Nonce field (Random.mPOS), a message authentication code field (MAC.mPOS) and/or an Encrypted Blob field (Encrypted Transaction info). ) may be included.
  • the random challenge field, signature field, and transaction information field of Table 7 may be fields used to provide the same or similar functions to the Nonce field, message authentication code field, and Encrypted Blob field of Table 8, respectively.
  • randPos of Table 7 may correspond to Random.mPoS of Table 8
  • randomPoS of Table 7 may correspond to StoreName.mPOS of Table 8
  • Definitions and descriptions of the length field, group ID field, type field, vendor OUI field, and UWB message ID field of the transaction information message in Tables 7 and 8 are the length field, group ID field, type field, You can refer to the same definitions and descriptions of the vendor OUI field and the UWB message ID field. Meanwhile, the UWB message ID field of Tables 7 and 8 may be set to a value indicating a transaction information message.
  • the random challenge field of Table 7 indicates a random challenge (random number) for encryption of a transaction information message.
  • the random challenge field may be set to a value indicating a random challenge (randPoS) used to encrypt transaction information and/or terminal information included in the transaction information field.
  • the random challenge (randPoS) of Table 7 may correspond to a random number (Random.mPOS) for generating a session key included in the Nonce field of Table 8.
  • the random challenge may be referred to as a first random number, a first random challenge, randPos, Random.mPoS.
  • the signature field of Table 7 may include message authentication code (MAC) information and/or signature information for the transaction information message.
  • the message authentication code information may include, for example, a hash-based message authentication code, such as in the signature field of Table 7, or a hash-based MAC (HMAC), such as in the message authentication code of Table 8. /Cipher-based MAC (CMAC)).
  • the hash-based message authentication code uses a predetermined hash algorithm to generate transaction information and/or terminal information included in randPos (Random.mPoS), transaction information field (Encypted Blob field), and/or terminal information (Random.Device). ), and a value generated based on a symmetric key.
  • the hash-based message authentication code is generated by concatenating randPos/Random.mPoS, transaction information, and terminal information (Random.Device) and a symmetric key value as an input value of a predefined HMAC function. It may be a hash value (eg, HMAC Hash of (randPoS
  • Term. Info., Symmetric key) of Table 7 may correspond to the HMAC (Symmetric key, StoreName.mPOS
  • the cipher-based message authentication code uses a predetermined cipher algorithm, randPos/Random.mPoS, transaction information included in the transaction information field (Encypted Blob field), and/or terminal information (Random.Device) , and may be a value generated based on a symmetric key.
  • the cipher-based message authentication code is generated by concatenating randPos/Random.mPoS, transaction information, and terminal information (Random.Device) and a symmetric key value as an input value of a predefined CMAC function. It may be a value (eg, CMAC (Symmetric key, StoreName.mPOS
  • the value of the terminal information may be, for example, a value included in the Nonce field of Table 4.
  • the signing information is stored in the transaction information and/or terminal information (Random.Device) included in the randPos/Random.mPoS and the transaction information field (Encypted Blob field) using a predefined electronic signature algorithm. It may be a value generated based on a hash value generated based on the hash value.
  • signing information is generated by applying a signature function to a hash value generated by applying a hash function to a value that concatenates randPos/Random.mPoS, transaction information, and terminal information (Random.Device) value (eg, Signing (Hash(randPoS
  • the user device 410 may transmit a payment information message corresponding to the transaction information message to the payment device 420 ( 4040 ).
  • the payment information message may be a UWB Message defined in "UWB MAC Specification of FiRa Consortium".
  • the payment information message may include payment information (eg, card information) for offline payment.
  • the payment information message may include, for example, card number, expiration date, authentication service, total currency purchased, amount, billing info and/or token. may include
  • a case in which the payment information message includes complete payment information may be referred to as a “fully implemented payment”.
  • Table 9 below shows an example of transaction information included in the payment information message in the case of a fully implemented payment case.
  • the payment information message is a card number, expiration date, authentication service (auth service), total currency purchased, amount (purchased total currency, amount), billing information (billing info) and / or It may include a token.
  • the payment information message may include link information (eg, a uniform resource locator (URL)) for obtaining payment information.
  • link information eg, a uniform resource locator (URL)
  • the payment information message includes link information for obtaining payment information instead of complete payment information may be referred to as "simplified payment”.
  • simplified payment since only minimal information for payment can be transmitted through UWB communication, there is an advantage in that transmission overhead is reduced. An example of this simplified payment case will be described below with reference to FIG. 7 .
  • Table 10 below shows an example of link information included in the payment information message in the case of a simplified payment case.
  • the payment information message may include a header IE and/or a payload IE.
  • Tables 11 and 12 below show an example of the payload IE of the payment information message.
  • the payment information message including the payload IE of Tables 11 and 12 below may be, for example, a payment information message used in the case of a fully implemented payment case.
  • the payment information message may include a payload IE including a length field (information), a group ID field (information), a type field (information) and/or a content field (information). .
  • the content field may include a vendor OUI field, a UWB message ID field, and a random challenge field (information) (randPhone)), a signature field and/or a payment information field.
  • the content field may include a vendor OUI field, a UWB message ID field, a message authentication code field (MAC.DEVICE), and/or an Encrypted Blob field.
  • the signature field and the payment information field of Table 11 may be fields used to provide the same or similar functions to the message authentication code field and the Encrypted Blob field of Table 12, respectively.
  • Definitions and descriptions of the length field, group ID field, type field, vendor OUI field, and UWB message ID field of the payment information message in Tables 11 and 12 are the length field, group ID field, type field, You can refer to the definition and description of the vendor OUI field and the UWB message ID field. Meanwhile, the UWB message ID field of Tables 11 and 12 may be set to a value indicating a payment information message.
  • the random challenge field of Table 11 indicates a random challenge (random number) for encryption of the payment information message.
  • the random challenge field may be set to a value indicating a random challenge used to encrypt payment information included in the payment information field.
  • the random challenge of Table 8 may be referred to as a second random number, a second random challenge, randPhone, Random.Device, and the like.
  • the signature field of Table 11 may include message authentication code information and/or signing information for the payment information message.
  • the message authentication code information is, for example, a hash-based message authentication code, such as in the signature field of Table 11, or a hash-based MAC (HMAC), such as in the message authentication code of Table 12. /Cipher-based MAC (CMAC)).
  • the hash-based message authentication code uses a predetermined hash algorithm, randPhone/Random.Device, randPos/Random.mPoS, payment information included in the payment information field (Encrypted Blob field) , may be a value generated based on Device Info and/or a symmetric key.
  • the hash-based message authentication code is a value obtained by concatenating randPhone/Random.Device, randPos/Random.mPoS, payment information and device information and a symmetric key value in advance.
  • Device Info, Symmetric key) a hash value generated as an input value of the defined HMAC function.
  • Device Info, Symmetric key) a hash value generated as an input value of the defined HMAC function.
  • the hash-based message authentication code is a hash value (eg, HMAC (Symmetric) key, Encrypted Blob).
  • the cipher-based message authentication code may be a value generated by using the payment information and the symmetric key value included in the Encrypted Blob field as input values of a predefined CMAC function (eg, symmetric key, encrypted blob (HMAC)).
  • a predefined CMAC function eg, symmetric key, encrypted blob (HMAC)
  • the value of Random.Device may be, for example, a value included in the Nonce field of Table 4.
  • the signing information is generated based on payment information and/or device information included in the randPhone/Random.Device, randPos/Random.mPoS, and payment information fields using a predefined electronic signature algorithm. It may be a value generated based on a hash value.
  • the signing information is obtained by applying a hash function to a value obtained by concatenating randPhone/Random.Device, randPos/Random.mPoS, payment information, and terminal information by applying a signature function to the generated hash value. It may be a generated value (eg, Signing (Hash(randPhone
  • Device info of Table 11 may include, for example, information for identifying a user device and/or a secret value.
  • the device information may be included in a header of a MAC frame including a payment information message.
  • the payment information field may include payment information.
  • the payment information may include card information such as a card number (eg, primary account number).
  • the payment device may complete a payment procedure based on information included in the payment information message. Meanwhile, since the payment processing procedure between the payment device and the components (acquirer and issuer devices) of the rear stage follows a known procedure, a detailed description thereof will be omitted in the present disclosure.
  • the above-described initiation message, response message, transaction information message and/or payment information message is a MAC frame defined in, for example, "IEEE 802.15.4/z Specification” and "UWB MAC Technical Specification of FiRa Consortium". or may be a message included in the payload of the MAC frame.
  • the structure of the header of the MAC frame may be as shown in Table 13 below.
  • the header (MAC header) of the MAC frame may include a Frame Control field and a source address field.
  • An example of the Frame Control field may be shown in Table 14 below.
  • Frame Type 3 0b001: Data Security Enabled One 0b0: Auxiliary Security Header is not present 0b1: Auxiliary Security Header is present Frame Pending One 0b0: No pending frame for the recipient 0b1: More frame will be followed for the recipient AR One 0b0: No ACK frame is required PAN ID Compression One 1: Destination PAN ID field and Source PAN ID field are not present Reserved One N/A Sequence Number Suppression One 0b1: Sequence number field is not present IE Present One 0b1: Header IE and/or Payload IE are contained in the frame Destination Addressing Mode 2 0b00: Destination address field is not present Frame Version 2 0b10: IEEE Std 802.15.4 Source Addressing Mode 2 0b10: Source address field contains short address
  • FIG. 5 shows an exemplary payment scenario using the payment method using UWB of FIG. 4 .
  • the user device 510 and the payment device 520 of FIG. 5 may correspond to the user device 410 and the payment device 520 of FIG. 4 .
  • the payment device 520 may transmit an initiation message for UWB ranging ( 5010 ).
  • the payment device 520 may broadcast the initiation message at a predetermined period without encrypting the initiation message by using an unencrypted/broadcasting method.
  • the initiation message may include information for identifying a store associated with the payment device (eg, the name of the store (eg, Starbucks)).
  • the user device 510 may provide information about the store to the user based on the information included in the initiation message. For example, as shown in FIG. 5 , the user device 520 may provide a message such as “You (John) are in Starbucks” to the user.
  • the user device 510 may transmit a response message to the initiation message to the payment device 520 ( 5020 ).
  • the user device 510 may encrypt the response message using an encrypted/unicast method and unicast the response message to the payment device 520 .
  • the response message may include information for identifying the user device (eg, name, ID of the user device (mobile device)).
  • the payment device 520 determines location information (eg, a relative distance between the user device and the payment device) for the user device 510 based on the response message, and determines the location information of the user device (user) generated based on the location information. You can provide the list to the store clerk. For example, as shown in FIG. 5 , when a response message is received from each of the user devices of John, Lucy, and Tim, the payment device 520 receives each response message according to a predefined UWB ranging scheme based on the response message.
  • location information eg, a relative distance between the user device and the payment device
  • the clerk may check the list of users, identify the closest user, and perform a procedure of receiving an order from the user (the [Take order] procedure of FIG. 5 ).
  • the corresponding order procedure may be a procedure performed offline face-to-face, but is not limited thereto, and may be a procedure performed online non-face-to-face.
  • the payment device 520 may transmit a transaction information message for offline payment to the selected user device 510 ( 5030 ). For example, the payment device 520 may encrypt the response message using an encrypted/unicast method and unicast the response message to the selected user device. To this end, as shown in FIG. 5 , the payment device 520 may provide a message such as “Sends transaction info.” to the clerk.
  • the selected user device 510 may be a user device of a user whose order procedure has been completed.
  • the transaction information message may include transaction information or link information for obtaining transaction information.
  • the user device 510 may provide information for payment to the user based on information included in the transaction information message. For example, the user device 510 may provide the user with a message such as “Americano costs $3, Select your card, Auth!” based on the transaction information. Through this, the user may check the provided message and perform an authentication procedure (eg, fingerprint authentication).
  • an authentication procedure eg, fingerprint authentication
  • the user device 510 may transmit a payment information message for offline payment to the payment device 520 ( 5040 ).
  • the user device 510 may encrypt the payment information message using an encrypted/unicast method and unicast the payment information message to the payment device 520 .
  • the user device 510 may provide a message such as “Sends payment info.” to the user.
  • the payment information message may include payment information or link information for obtaining payment information.
  • the payment device 520 may process a payment procedure based on information included in the payment information message.
  • the cloud device 630 serves as an intermediary between the payment device 620 and the user device 610 .
  • the cloud device 630 may be, for example, a device operated by a payment device for online payment, such as a payment gateway, but is not limited thereto.
  • a payment gateway such as a payment gateway
  • the payment device 620 may transmit transaction information to be uploaded to the cloud device 630 .
  • a token eg, one-time token
  • the transaction information may be the transaction information described above with reference to Table 5.
  • Table 15 below shows an example of a data structure including transaction information.
  • the cloud device 630 may store the received transaction information and token, generate link information (eg, URL) used to obtain the transaction information, and transmit it to the payment device 620 .
  • the payment device 620 may receive link information used to obtain transaction information from the cloud device 630 .
  • the payment device 620 may transmit the received link information to the user device 610 through UWB communication by including the received link information in the transaction information message.
  • the link information included in the transaction information message may be the link information described above with reference to Table 6.
  • the user device 610 may transmit a request for retrieving transaction information to the cloud device 630 using the received link information.
  • the cloud device 630 may search for stored transaction information based on the link information and transmit data including the transaction information and the token to the user device 610 . Through this, the user device 610 may receive data including transaction information and a token from the cloud device 630 .
  • FIG. 7 illustrates a payment method using UWB according to another embodiment of the present disclosure.
  • the cloud device 730 serves as an intermediary between the payment device 720 and the user device 710 .
  • the cloud device 730 may be, for example, a device operated by a payment device for online payment, such as a payment gateway, but is not limited thereto.
  • a payment gateway such as a payment gateway
  • the payment device 720 may transmit transaction information to be uploaded to the cloud device 730 .
  • the token Token_ti may be transmitted together with transaction information.
  • the cloud device 730 may store the received transaction information and token, generate link information (eg, URL) used to obtain the transaction information, and transmit it to the payment device 720 .
  • the payment device 720 may receive link information used to obtain transaction information from the cloud device 730 .
  • the payment device 720 may transmit the received link information to the user device 710 through UWB communication by including the received link information in the transaction information message.
  • the link information included in the transaction information message may be the link information described above with reference to Table 6.
  • the user device 710 may transmit a request for retrieving transaction information to the cloud device 730 by using the received link information.
  • the cloud device 730 may search for stored transaction information based on the link information and transmit data including the transaction information and the token to the user device 710 . Through this, the user device 710 may obtain data including transaction information and a token from the cloud device 730 .
  • the user device 710 may transmit payment information to be uploaded to the cloud device 730 .
  • the cloud device 730 may store the received payment information, generate link information (eg, URL) used to obtain the payment information, and transmit it to the user device 710 .
  • the payment information may be the payment information described above with reference to Table 9. Table 16 below shows an example of a data structure including payment information.
  • the user device 710 may include the received link information in the payment information message and transmit it to the payment device 720 through UWB communication.
  • the link information included in the payment information message may be the link information described above with reference to Table 10.
  • the payment device 720 may transmit a request for searching for payment information to the cloud device 730 using the received link information.
  • the cloud device 730 may search for stored payment information based on the link information and transmit data including the payment information to the payment device 720 .
  • the payment device 720 may receive data including payment information from the cloud device 730 .
  • the STS setting for UWB corresponds to a static STS setting
  • the static STS value for the static STS setting is generated based on the value of the VENDOR ID.
  • the ranging frame configuration for UWB communication may correspond to STS packet (SP) 1 configuration.
  • the ranging mode of UWB ranging may be a contention-based ranging mode.
  • the payment device may transmit an initiation message for initiating UWB ranging ( 8010 ).
  • the payment device may broadcast an initiation message.
  • the initiation message may include information for identifying a payment device or a store associated with the payment device (eg the name of the store) and/or a contention window associated with UWB ranging in contention-based ranging mode. ) related information (eg, the size of the contention window, and/or information indicating the existence of the contention window).
  • the response message may include information for identifying the user device (eg, the name or ID of the user device (mobile device)).
  • location information on the at least one user terminal may be determined based on a response message received from the at least one user terminal.
  • the payment device calculates a range (distance) for each user device using a preset UWB ranging method based on a response message received from at least one user terminal to obtain location information (eg, a payment device and a corresponding relative distance between user devices).
  • a list of user devices (users) may be generated based on location information.
  • the payment device may generate a list of user devices (users) listing each user device (users) in order of distance, based on the location information.
  • the payment device may transmit the transaction information message through an in-band or out-of-band connection.
  • the transaction information message may include link information (eg, a uniform resource locator (URL)) for obtaining the transaction information.
  • link information eg, a uniform resource locator (URL)
  • the transaction information message may include a first random number for encryption of the transaction information message, and first signature information generated based on the transaction information and the first random number.
  • the transaction information message may have an SP1 RFRAME setting.
  • the payment information message may include payment information (eg, card information) for offline payment.
  • the payment information message may include, for example, card number, expiration date, authentication service, total currency purchased, amount, billing info and/or token. may include
  • the payment information message may have an SP1 RFRAME setting.
  • the payment device may complete a payment procedure based on information included in the payment information message.
  • the user device may transmit a response message to the initiation message to the payment device ( 9020 ).
  • the response message may be an SP1 Ranging Response Message (SP1 RFRAME).
  • SP1 RFRAME SP1 Ranging Response Message
  • the response message may include information for identifying the user device (eg, the name or ID of the user device (mobile device)).
  • location information on the user terminal may be determined based on a response message received from the user terminal.
  • the payment device calculates a range (distance) for the user device using a preset UWB ranging method based on a response message received from the user terminal to obtain location information (eg, relative between the payment device and the user device) distance) can be determined.
  • a list of user devices (users) may be generated based on location information.
  • the payment device may generate a list of user devices (users) listing each user device (users) that have transmitted the response message in order of distance, based on the location information. Through this, a user device having a payment intention may be selected.
  • the user device may receive a transaction information message for offline payment from the payment device ( 8030 ).
  • the user device receiving the transaction information message may be a user device selected from the list of user devices according to a predetermined criterion.
  • the user device may perform authentication for payment based on the transaction information message.
  • the transaction information message may include transaction information for offline payment.
  • Transaction information may include, for example, an amount (currency, price, tax), merchant name, merchant ID, order number, payment protocol, and shipping address (shipping). address), an address to a payment sheet, allowed card brands, and/or information about recurring.
  • the transaction information message may include a first random number for encryption of the transaction information message, and first signature information generated based on the transaction information and the first random number.
  • the transaction information message may have an SP1 RFRAME setting.
  • the user device may transmit a payment information message corresponding to the transaction information message to the payment device ( 8040 ).
  • the payment information message may include payment information (eg, card information) for offline payment.
  • Payment information includes, for example, card number, expiration date, authentication service (auth service), total currency purchased, amount (purchased total currency, amount), billing information (billing info) and/or token (token) may include
  • the payment information message may include link information (eg, a uniform resource locator (URL)) for obtaining payment information.
  • link information eg, a uniform resource locator (URL)
  • the payment information message may have an SP1 RFRAME setting.
  • the payment device may complete a payment procedure based on information included in the payment information message.
  • the payment device may be a UWB device that provides a payment service using UWB communication (eg, an Enhanced Ranging Device (ERDEV) defined in IEEE 802.15.4z or a FiRa Device defined by FiRa).
  • UWB communication eg, an Enhanced Ranging Device (ERDEV) defined in IEEE 802.15.4z or a FiRa Device defined by FiRa.
  • ELDEV Enhanced Ranging Device
  • FiRa Device defined by FiRa
  • the payment device may include a transceiver 1010 , a control unit 1020 , and a storage unit 1030 .
  • the controller may be defined as a circuit or an application specific integrated circuit or at least one processor.
  • the transceiver 1010 may transmit/receive signals to and from other network entities.
  • the transceiver 1010 may transmit/receive data for offline payment to/from the user device using, for example, UWB communication.
  • the controller 1020 may control the overall operation of the payment device according to the embodiment proposed in the present disclosure.
  • the controller 1020 may control a signal flow between blocks to perform an operation according to the above-described flowchart.
  • the controller 1020 may control, for example, the operation of the payment processing procedure of the payment device described with reference to FIGS. 2 to 9 .
  • FIG. 11 is a diagram illustrating a structure of a user device according to an embodiment of the present disclosure.
  • the payment device may include a transceiver 1110 , a control unit 1120 , and a storage unit 1130 .
  • the controller may be defined as a circuit or an application specific integrated circuit or at least one processor.
  • the controller 1120 may control the overall operation of the user device according to the embodiment proposed in the present disclosure.
  • the controller 1120 may control a signal flow between blocks to perform an operation according to the above-described flowchart.
  • the controller 1120 may control, for example, the operation of the payment processing procedure of the user device described with reference to FIGS. 2 to 9 .
  • the storage unit 1130 may store at least one of information transmitted/received through the transceiver 1110 and information generated through the control unit 1120 .
  • the storage unit 1130 may store information and data for payment processing using UWB described with reference to FIGS. 2 to 9 .
  • FIG. 12 shows an exemplary architecture of a payment system using UWB according to an embodiment of the present disclosure.
  • a payment system may include a user device 1210 and a payment device 1220 capable of UWB communication.
  • the user device 1210 and the payment device 1220 may perform the above-described operation for payment (offline) with reference to FIGS. 2 to 9 using UWB communication.
  • the user device 1210 and the payment device 1220 have service layers 1211 and 1221, application layers 1212 and 1222, MAC layers 1213 and 1223, PHY layers 1214 and 1224 and security layers 1215, respectively. 1225).
  • MAC layers 1213 and 1223 and PHY layers 1214 and 1224 are UWB-based MAC layers (UWB MAC) and PHY layers (UWB PHY) for UWB communication, for example, IEEE 802.15.4/4z standard and FiRa consortium. It can follow the contents stipulated in the technical standard of
  • the MAC layers 1213 and 1223 and the PHY layers 1214 and 1224 may correspond to the MAC layer and the PHY layer for supporting a communication method other than UWB communication.
  • the MAC layers 1213 and 1223 and the PHY layers 1214 and 1224 may correspond to a MAC layer and a PHY layer based on 5G communication and/or Bluetooth to support 5G communication and/or Bluetooth communication.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Finance (AREA)
  • Signal Processing (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)

Abstract

본 개시는 UWB 통신을 이용하여 결제 서비스를 제공하는 방법 및 장치를 개시한다. 본 개시의 방법은 UWB 레인징을 개시하기 위한 개시 메시지를 전송하는 동작; 적어도 하나의 사용자 단말로부터, 상기 개시 메시지에 대한 응답 메시지를 수신하는 동작; 상기 응답 메시지에 기초하여 선택된 제1 사용자 장치로 결제를 위한 트랜잭션 정보 메시지를 전송하는 동작; 및 상기 제1 사용자 장치로부터 상기 트랜잭션 정보 메시지에 대응하는 결제 정보 메시지를 수신하는 동작을 포함한다.

Description

초광대역 통신을 이용한 결제 방법 및 장치
본 개시는 결제 방법에 관한 것으로, 보다 상세하게는 UWB를 이용한 결제 방법 및 장치에 관한 것이다.
인터넷은 인간이 정보를 생성하고 소비하는 인간 중심의 연결 망에서, 사물 등 분산된 구성 요소들 간에 정보를 주고 받아 처리하는 IoT (Internet of Things, 사물 인터넷) 망으로 진화하고 있다. 클라우드 서버 등과의 연결을 통한 빅데이터 (Big data) 처리 기술 등이 IoT 기술에 결합된 IoE(Internet of Everything) 기술도 대두되고 있다. IoT를 구현하기 위해서는, 센싱 기술, 유무선 통신 및 네트워크 인프라, 서비스 인터페이스 기술, 및 보안 기술과 같은 기술 요소 들이 요구된다. 최근에는 사물간의 연결을 위한 센서 네트워크(sensor network), 사물 통신 (Machine to Machine, M2M), MTC(Machine Type Communication) 등의 기술이 연구되고 있다.
IoT 환경에서는 연결된 사물들에서 생성된 데이터를 수집, 분석하여 인간의 삶에 새로운 가치를 창출하는 지능형 IT(Internet Technology) 서비스가 제공될 수 있다. IoT는, 기존의 IT(information technology) 기술과 다양한 산업 간의 융합 및 복합을 통하여, 스마트홈, 스마트 빌딩, 스마트 시티, 스마트 카 혹은 커넥티드 카, 스마트 그리드, 헬스 케어, 스마트 가전, 첨단의료서비스 등의 분야에 응용될 수 있다.
무선 통신 시스템의 발전에 따라 다양한 서비스를 제공할 수 있게 됨으로써, 이러한 서비스들을 효과적으로 제공하기 위한 방안이 요구되고 있다. 예를 들어, UWB(Ultra Wide Band)를 이용하여 전자 디바이스들 간의 거리를 측정하는 레인징(ranging) 기술이 사용될 수 있다. UWB는, 무선 반송파를 사용하지 않고 기저 대역에서 수 GHz이상의 매우 넓은 주파수 대역을 사용하는 무선 통신 기술이다.
본 개시는 UWB를 이용하여 원거리에서 오프라인 결제를 처리할 수 있는 방법을 제공한다. 또한, 본 개시는 UWB를 이용하면서도 낮은 결제 복잡도와 높은 보안성을 유지하는 결제 방법을 제공한다.
본 개시의 일 양상에 따른 UWB 통신을 이용한 결제 서비스를 제공하는 결제 장치의 방법은, UWB 레인징을 개시하기 위한 개시 메시지(initiation message)를 전송하는 동작; 적어도 하나의 사용자 장치로부터, 상기 개시 메시지에 대한 응답 메시지(response message)를 수신하는 동작; 상기 응답 메시지에 기초하여 선택된 제1 사용자 장치로 결제를 위한 트랜잭션 정보 메시지를 전송하는 동작; 및 상기 제1 사용자 장치로부터 상기 트랜잭션 정보 메시지에 대응하는 결제 정보 메시지를 수신하는 동작을 포함할 수 있다.
실시예로서, 상기 방법은 상기 응답 메시지에 기초하여, 상기 적어도 하나의 사용자 단말에 대한 위치 정보를 결정하는 동작; 상기 위치 정보에 기초하여, 상기 적어도 하나의 사용자 단말에 대한 사용자 리스트를 생성하는 동작; 및 상기 사용자 리스트에 기초하여 결제 의도(intent)를 갖는 상기 제1 사용자 장치를 선택하는 동작을 더 포함할 수 있다.
본 개시의 다른 양상에 따른, UWB 통신을 이용한 결제 서비스를 제공하는 사용자 장치의 방법은 상기 결제 장치로부터 UWB 레인징을 개시하기 위한 개시 메시지(initiation message)를 수신하는 동작; 상기 결제 장치로 상기 개시 메시지에 대한 응답 메시지(response message)를 전송하는 동작; 상기 결제 장치로부터 결제를 위한 트랜잭션 정보 메시지를 수신하는 동작; 및 상기 결제 장치로 상기 트랜잭션 정보 메시지에 대응하는 결제 정보 메시지를 전송하는 동작을 포함할 수 있다.
실시예로서, 상기 방법은 상기 트랜잭션 정보 메시지에 기초하여 결제를 위한 인증을 수행하는 동작을 더 포함할 수 있다.
본 개시의 또 다른 양상에 따른, UWB 통신을 이용한 결제 서비스를 제공하는 결제 장치는 송수신부; 및 상기 송수신부에 연결된 제어부를 포함하며, 상기 제어부는: UWB 레인징을 개시하기 위한 개시 메시지(initiation message)를 전송하고, 적어도 하나의 사용자 장치로부터, 상기 개시 메시지에 대한 응답 메시지(response message)를 수신하고, 상기 응답 메시지에 기초하여 선택된 제1 사용자 장치로 결제를 위한 트랜잭션 정보 메시지를 전송하고, 그리고, 상기 제1 사용자 장치로부터 상기 트랜잭션 정보 메시지에 대응하는 결제 정보 메시지를 수신하도록 구성될 수 있다.
본 개시의 또 다른 양상에 따른, UWB 통신을 이용한 결제 서비스를 제공하는 사용자 장치는 송수신부; 및 상기 송수신부에 연결된 제어부를 포함하며, 상기 제어부는: 상기 결제 장치로부터 UWB 레인징을 개시하기 위한 개시 메시지(initiation message)를 수신하고, 상기 결제 장치로 상기 개시 메시지에 대한 응답 메시지(response message)를 전송하고, 상기 결제 장치로부터 결제를 위한 트랜잭션 정보 메시지를 수신하고, 그리고, 상기 결제 장치로 상기 트랜잭션 정보 메시지에 대응하는 결제 정보 메시지를 전송하도록 구성될 수 있다.
실시예로서, 상기 개시 메시지는 상기 결제 장치 또는 상기 결제 장치와 연관된 상점(store)을 식별하기 위한 정보 및 경쟁-기반(contention-based) 레인징 모드의 상기 UWB 레인징을 위한 경쟁 윈도우와 관련된 정보를 포함할 수 있다.
실시예로서, 상기 경쟁 윈도우와 관련된 정보는, 상기 경쟁 윈도우의 기간을 지시하는 경쟁 윈도우 사이즈 정보가 존재하는지 여부를 지시하는 플래그 정보를 포함할 수 있다.
실시예로서, 상기 플래그 정보가 제1 값으로 설정된 경우, 상기 경쟁 윈도우 사이즈 정보가 개시 메시지 내에 존재하지 않으며, 상기 플래그 정보가 제2 값으로 설정된 경우, 상기 경쟁 윈도우 사이즈 정보가 개시 메시지 내에 존재할 수 있다.
실시예로서, 상기 응답 메시지는 상기 응답 메시지를 전송한 사용자 장치를 식별하기 위한 정보를 포함할 수 있다.
실시예로서, 상기 트랜잭션 정보 메시지는 상기 결제를 위한 트랜잭션 정보 또는 상기 트랜잭션 정보를 획득하기 위한 링크 정보를 포함하고, 상기 트랜잭션 액수(amount), 판매자(merchant) 이름, 판매자 ID, 주문 번호(order number), 결제 프로토콜, 물건 발송 주소(shipping address), 결제 시트(payment sheet)에 대한 주소, 허용된(allowed) 카드 브랜드 또는 리커링(recurring) 중 적어도 하나에 대한 정보를 포함할 수 있다.
실시예로서, 상기 트랜잭션 정보 메시지는, 상기 트랜잭션 정보 메시지의 암호화를 위한 제1 랜덤 넘버, 및 상기 트랜잭션 정보와 상기 제1 랜덤 넘버에 기초하여 생성된 제1 서명 정보를 포함할 수 있다.
실시예로서, 상기 결제 정보 메시지는 결제 정보 및 상기 결제 정보를 획득하기 위한 링크 정보를 포함하고, 상기 결제 정보는 카드 번호, 만료 일(expiration date), 인증 서비스(auth service), 구매된 전체 통화, 금액(purchased total currency, amount), 빌링 정보(billing info) 또는 토큰(token) 중 적어도 하나에 대한 정보를 포함할 수 있다.
실시예로서, 상기 결제 정보 메시지는, 상기 결제 정보 메시지의 암호화를 위한 제2 랜덤 넘버, 및 상기 결제 정보, 상기 제1 랜덤 넘버와 제2 랜덤 넘버에 기초하여 생성된 제2 서명 정보를 더 포함할 수 있다.
실시예로서, 상기 UWB 통신에 대한 STS(Scrambled Timestamp Sequence) 설정은 정적(static) STS 설정에 해당하며, 상기 정적 STS 설정에 대한 정적 STS의 값은 벤더(VENDOR) ID의 값에 기초하여 생성될 수 있다.
실시예로서, 상기 UWB 통신에 대한 레인징 프레임 설정은 STS packet(SP) 1 설정에 해당하며, 상기 UWB 레인징의 레인징 모드(scheduled mode)는 경쟁-기반(contention-based) 레인징 모드에 해당할 수 있다.
본 개시의 일 양상에 따른, UWB 통신을 이용하여 사용자 장치와 결제를 처리하는 결제 장치의 방법은, UWB 레인징을 위한 개시 메시지(initiation message)를 전송하는 동작; 적어도 하나의 사용자 단말로부터, 상기 개시 메시지에 대한 응답 메시지(response message)를 수신하는 동작; 선택된 제1 사용자 장치로 결제를 위한 트랜잭션 정보 메시지를 전송하는 동작; 및 상기 제1 사용자 장치로부터 상기 트랜잭션 정보 메시지에 대응하는 결제 정보 메시지를 수신하는 동작을 포함할 수 있다.
실시예로서, 상기 방법은 상기 개시 메시지에 대한 응답 메시지에 기초하여, 상기 적어도 하나의 사용자 단말에 대한 위치 정보를 결정하는 동작; 상기 위치 정보에 기초하여, 상기 적어도 하나의 사용자 단말에 대한 사용자 리스트를 생성하는 동작; 및 상기 사용자 리스트에 기초하여 상기 제1 사용자 장치를 선택하는 동작을 더 포함할 수 있다.
본 개시의 다른 양상에 따른, UWB 통신을 이용하여 결제 장치와 결제를 처리하는 사용자 장치의 방법은 상기 결제 장치로부터 UWB 레인징을 위한 개시 메시지(initiation message)를 수신하는 동작; 상기 결제 장치로 상기 개시 메시지에 대한 응답 메시지(response message)를 전송하는 동작; 상기 결제 장치로부터 결제를 위한 트랜잭션 정보 메시지를 수신하는 동작; 및 상기 결제 장치로 상기 트랜잭션 정보 메시지에 대응하는 결제 정보 메시지를 전송하는 동작을 포함할 수 있다.
본 개시의 또 다른 양상에 따른, UWB 통신을 이용하여 사용자 장치와 결제를 처리하는 결제 장치는 송수신부; 및 상기 송수신부에 연결된 제어부를 포함하며, 상기 제어부는: UWB 레인징을 위한 개시 메시지(initiation message)를 전송하고, 적어도 하나의 사용자 단말로부터, 상기 개시 메시지에 대한 응답 메시지(response message)를 수신하고, 선택된 제1 사용자 장치로 결제를 위한 트랜잭션 정보 메시지를 전송하고, 그리고, 상기 제1 사용자 장치로부터 상기 트랜잭션 정보 메시지에 대응하는 결제 정보 메시지를 수신하도록 구성될 수 있다.
본 개시의 또 다른 양상에 따른, UWB 통신을 이용하여 결제 장치와 결제를 처리하는 사용자 장치는 송수신부; 및 상기 송수신부에 연결된 제어부를 포함하며, 상기 제어부는: 상기 결제 장치로부터 UWB 레인징을 위한 개시 메시지(initiation message)를 수신하고, 상기 결제 장치로 상기 개시 메시지에 대한 응답 메시지(response message)를 전송하고, 상기 결제 장치로부터 결제를 위한 트랜잭션 정보 메시지를 수신하고, 그리고, 상기 결제 장치로 상기 트랜잭션 정보 메시지에 대응하는 결제 정보 메시지를 전송하도록 구성될 수 있다.
실시예로서, 상기 개시 메시지는 결제 장치와 연관된 상점(store)을 식별하기 위한 정보 및 상기 UWB 레인징과 연관된 경쟁 윈도우와 관련된 정보를 포함할 수 있다.
실시예로서, 상기 경쟁 윈도우와 관련된 정보는, 상기 경쟁 윈도우와 관련된 정보는 경쟁 윈도우의 사이즈를 지시하는 경쟁 윈도우 사이즈 정보가 존재하는지 여부를 지시하는 플래그 정보를 포함할 수 있다.
실시예로서, 상기 플래그 정보가 제1 값으로 설정된 경우, 상기 경쟁 윈도우 사이즈 정보가 개시 메시지 내에 존재하지 않으며, 상기 플래그 정보가 제2 값으로 설정된 경우, 상기 경쟁 윈도우 사이즈 정보가 개시 메시지 내에 존재할 수 있다.
실시예로서, 상기 응답 메시지를 전송한 사용자 장치를 식별하기 위한 정보를 포함할 수 있다.
실시예로서, 상기 트랜잭션 정보 메시지는 상기 결제를 위한 트랜잭션 정보 또는 상기 트랜잭션 정보를 획득하기 위한 링크 정보를 포함하고, 상기 트랜잭션 액수(amount), 판매자(merchant) 이름, 판매자 ID, 주문 번호(order number), 결제 프로토콜, 물건 발송 주소(shipping address), 결제 시트(payment sheet)에 대한 주소, 허용된(allowed) 카드 브랜드 또는 리커링(recurring) 중 적어도 하나에 대한 정보를 포함할 수 있다.
실시예로서, 상기 결제 정보 메시지는 결제 정보 및 상기 결제 정보를 획득하기 위한 링크 정보를 포함하고, 상기 결제 정보는 예컨대, 카드 번호, 만료 일(expiration date), 인증 서비스(auth service), 구매된 전체 통화, 금액(purchased total currency, amount), 빌링 정보(billing info) 또는 토큰(token) 중 적어도 하나에 대한 정보를 포함할 수 있다.
본 개시의 UWB를 이용한 결제 방법에 따르면, 원거리에서 오프라인 결제를 처리할 수 있고, 낮은 결제 복잡도와 높은 보안성을 유지할 수 있다.
도 1은 예시적인 결제 시스템을 나타낸다.
도 2는 본 개시의 실시예에 따른 UWB를 이용하는 결제 시스템의 일 예를 나타낸다.
도 3은 본 개시의 실시예에 따른 UWB를 이용하는 결제 시스템의 다른 예를 나타낸다.
도 4는 본 개시의 실시예에 따른 UWB를 이용하는 결제 방법을 나타낸다.
도 5는 도 4의 UWB를 이용하는 결제 방법을 이용한 예시적인 결제 시나리오를 나타낸다.
도 6은 본 개시의 다른 실시예에 따른 UWB를 이용하는 결제 방법을 나타낸다.
도 7은 본 개시의 또 다른 실시예에 따른 UWB를 이용하는 결제 방법을 나타낸다.
도 8은 본 개시의 실시예에 따른 결제 장치가 UWB를 이용하여 결제를 처리하는 방법을 나타낸다.
도 9는 본 개시의 실시예에 따른 사용자 장치가 UWB를 이용하여 결제를 처리하는 방법을 나타낸다.
도 10은 본 개시의 일 실시예에 따른 결제 장치의 구조를 도시한 도면이다.
도 11은 본 개시의 일 실시예에 따른 사용자 장치의 구조를 도시한 도면이다.
도 12는 본 개시의 일 실시예에 따른 UWB를 이용한 결제 시스템의 예시적인 아키텍쳐를 나타낸다.
이하, 본 개시의 실시 예를 첨부된 도면을 참조하여 상세하게 설명한다.
실시 예를 설명함에 있어서 본 개시가 속하는 기술 분야에 익히 알려져 있고 본 개시와 직접적으로 관련이 없는 기술 내용에 대해서는 설명을 생략한다. 이는 불필요한 설명을 생략함으로써 본 개시의 요지를 흐리지 않고 더욱 명확히 전달하기 위함이다.
마찬가지 이유로 첨부된 도면에 있어서 일부 구성요소는 과장되거나 생략되거나 개략적으로 도시되었다. 또한, 각 구성요소의 크기는 실제 크기를 전적으로 반영하는 것이 아니다. 각 도면에서 동일한 또는 대응하는 구성요소에는 동일한 참조 번호를 부여하였다.
본 개시의 이점 및 특징, 그리고 그것들을 달성하는 방법은 첨부되는 도면과 함께 상세하게 후술되어 있는 실시 예들을 참조하면 명확해질 것이다. 그러나 본 개시는 이하에서 개시되는 실시 예들에 한정되는 것이 아니라 서로 다른 다양한 형태로 구현될 수 있으며, 단지 본 개시의 실시 예들은 본 개시가 완전하도록 하고, 본 개시가 속하는 기술분야에서 통상의 지식을 가진 자에게 개시의 범주를 완전하게 알려주기 위해 제공되는 것이며, 본 개시는 청구항의 범주에 의해 정의될 뿐이다. 명세서 전체에 걸쳐 동일 참조 부호는 동일 구성 요소를 지칭한다.
이때, 처리 흐름도 도면들의 각 블록과 흐름도 도면들의 조합들은 컴퓨터 프로그램 인스트럭션들에 의해 수행될 수 있음을 이해할 수 있을 것이다. 이들 컴퓨터 프로그램 인스트럭션들은 범용 컴퓨터, 특수용 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비의 프로세서에 탑재될 수 있으므로, 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비의 프로세서를 통해 수행되는 그 인스트럭션들이 흐름도 블록(들)에서 설명된 기능들을 수행하는 수단을 생성하게 된다. 이들 컴퓨터 프로그램 인스트럭션들은 특정 방식으로 기능을 구현하기 위해 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비를 지향할 수 있는 컴퓨터 이용 가능 또는 컴퓨터 판독 가능 메모리에 저장되는 것도 가능하므로, 그 컴퓨터 이용가능 또는 컴퓨터 판독 가능 메모리에 저장된 인스트럭션들은 흐름도 블록(들)에서 설명된 기능을 수행하는 인스트럭션 수단을 내포하는 제조 품목을 생산하는 것도 가능할 수 있다. 컴퓨터 프로그램 인스트럭션들은 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비 상에 탑재되는 것도 가능하므로, 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비 상에서 일련의 동작 단계들이 수행되어 컴퓨터로 실행되는 프로세스를 생성해서 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비를 수행하는 인스트럭션들은 흐름도 블록(들)에서 설명된 기능들을 실행하기 위한 단계들을 제공하는 것도 가능할 수 있다.
또한, 각 블록은 특정된 논리적 기능(들)을 실행하기 위한 하나 이상의 실행 가능한 인스트럭션들을 포함하는 모듈, 세그먼트 또는 코드의 일부를 나타낼 수 있다. 또, 몇 가지 대체 실행 예들에서는 블록들에서 언급된 기능들이 순서를 벗어나서 발생하는 것도 가능함을 주목해야 한다. 예컨대, 잇달아 도시되어 있는 두 개의 블록들은 사실 실질적으로 동시에 수행되는 것도 가능하고 또는 그 블록들이 때때로 해당하는 기능에 따라 역순으로 수행되는 것도 가능할 수 있다.
이때, 본 실시 예에서 사용되는 '~부'라는 용어는 소프트웨어 또는 FPGA(Field Programmable Gate Array) 또는 ASIC(Application Specific Integrated Circuit)과 같은 하드웨어 구성요소를 의미하며, '~부'는 어떤 역할들을 수행한다. 그렇지만 '~부'는 소프트웨어 또는 하드웨어에 한정되는 의미는 아니다. '~부'는 어드레싱할 수 있는 저장 매체에 있도록 구성될 수도 있고 하나 또는 그 이상의 프로세서들을 재생시키도록 구성될 수도 있다. 따라서, 일부 실시 예에 따르면 '~부'는 소프트웨어 구성요소들, 객체지향 소프트웨어 구성요소들, 클래스 구성요소들 및 태스크 구성요소들과 같은 구성요소들과, 프로세스들, 함수들, 속성들, 프로시저들, 서브루틴들, 프로그램 코드의 세그먼트들, 드라이버들, 펌웨어, 마이크로코드, 회로, 데이터, 데이터베이스, 데이터 구조들, 테이블들, 어레이들, 및 변수들을 포함한다. 구성요소들과 '~부'들 안에서 제공되는 기능은 더 작은 수의 구성요소들 및 '~부'들로 결합되거나 추가적인 구성요소들과 '~부'들로 더 분리될 수 있다. 뿐만 아니라, 구성요소들 및 '~부'들은 디바이스 또는 보안 멀티미디어카드 내의 하나 또는 그 이상의 CPU들을 재생시키도록 구현될 수도 있다. 또한 일부 실시 예에 따르면, '~부'는 하나 이상의 프로세서를 포함할 수 있다.
본 명세서에서 사용하는 용어 '단말' 또는 '기기'는 이동국(MS), 사용자 장비(UE; User Equipment), 사용자 터미널(UT; User Terminal), 무선 터미널, 액세스 터미널(AT), 터미널, 가입자 유닛(Subscriber Unit), 가입자 스테이션(SS; Subscriber Station), 무선 기기(wireless device), 무선 통신 디바이스, 무선 송수신 유닛(WTRU; Wireless Transmit/Receive Unit), 이동 노드, 모바일 또는 다른 용어들로서 지칭될 수 있다. 단말의 다양한 실시 예들은 셀룰러 전화기, 무선 통신 기능을 가지는 스마트 폰, 무선 통신 기능을 가지는 개인 휴대용 단말기(PDA), 무선 모뎀, 무선 통신 기능을 가지는 휴대용 컴퓨터, 무선 통신 기능을 가지는 디지털 카메라와 같은 촬영장치, 무선 통신 기능을 가지는 게이밍 장치, 무선 통신 기능을 가지는 음악저장 및 재생 가전제품, 무선 인터넷 접속 및 브라우징이 가능한 인터넷 가전제품뿐만 아니라 그러한 기능들의 조합들을 통합하고 있는 휴대형 유닛 또는 단말기들을 포함할 수 있다. 또한, 단말은 M2M(Machine to Machine) 단말, MTC(Machine Type Communication) 단말/디바이스를 포함할 수 있으나, 이에 한정되는 것은 아니다. 본 명세서에서 상기 단말은 전자장치 또는 단순히 장치라 지칭할 수도 있다.
이하 첨부된 도면을 참조하여 본 개시의 동작 원리를 상세히 설명한다. 하기에서 본 개시를 설명함에 있어 관련된 공지 기능 또는 구성에 대한 구체적인 설명이 본 개시의 요지를 불필요하게 흐릴 수 있다고 판단되는 경우에는 그 상세한 설명을 생략할 것이다. 그리고 후술되는 용어들은 본 개시에서의 기능을 고려하여 정의된 용어들로서 이는 사용자, 운용자의 의도 또는 관례 등에 따라 달라질 수 있다. 그러므로 그 정의는 본 명세서 전반에 걸친 내용을 토대로 내려져야 할 것이다.
이하의 설명에서 사용되는 특정 용어들은 본 개시의 이해를 돕기 위해서 제공된 것이며, 이러한 특정 용어의 사용은 본 개시의 기술적 사상을 벗어나지 않는 범위에서 다른 형태로 변경될 수 있다.
"Application Dedicated File (ADF)"는 예를 들면, 어플리케이션이나 어플리케이션 특정 데이터(application specific data)를 호스팅(hosting)할 수 있는 Application Data Structure 내의 데이터 구조일 수 있다.
"Application Protocol Data Unit(APDU)"는 UWB 장치 내의 Application Data Structure와 통신하는 경우에 사용되는 명령(command) 및 응답(response)일 수 있다.
"application specific data"는 예컨대, UWB 세션을 위해 요구되는 UWB 컨트롤리 정보 및 UWB 세션 데이터를 포함하는 루트 레벨과 어플리케이션 레벨을 갖는 파일 구조일 수 있다.
"Controller"는 Ranging Control Messages (RCM) (또는, 제어 메시지)를 정의 및 제어하는 Ranging Device일 수 있다.
"Controllee"는 Controller로부터 수신된 RCM (또는, 제어 메시지)내의 레인징 파라미터를 이용하는 Ranging Device일 수 있다.
"Dynamic STS(Scrambled Timestamp Sequence) mode"는 "Static STS"와 달리, STS가 레인징 세션 동안 반복되지 않는 동작 모드일 수 있다. 이 모드에서 STS는 Ranging device에서 관리되고, STS를 생성하는 Ranging Session Key는 Secure Component에 의해 관리될 수 있다.
"Applet"는 예컨대, UWB 파라미터들과 서비스 데이터를 포함하는 Secure Component 상에서 실행되는 어플리케이션일 수 있다. 본 개시에서, Applet은 FiRa 컨소시엄의 스펙(이하, FiRa/FiRa 규격)에 의해 정의된 FiRa Applet일 수 있다.
"Ranging Device"는 UWB 레인징을 수행할 수 있는 장치일 수 있다. 본 개시에서, Ranging Device는 IEEE 802.15.4z에 정의된 Enhanced Ranging Device (ERDEV) 또는 FiRa에 의해 정의된 FiRa Device일 수 있다. Ranging Device는 UWB device로 지칭될 수 있다.
"UWB-enabled Application"는 UWB 서비스를 위한 어플리케이션일 수 있다. 예를 들면, UWB-enabled Application는 UWB 세션을 위한, OOB Connector, Secure Service 및/또는 UWB 서비스를 구성하기 위한 Framework API를 이용하는 어플리케이션일 수 있다. 본 개시에서, "UWB-enabled Application"는 어플리케이션 또는 UWB 어플리케이션으로 약칭될 수 있다. UWB-enabled Application은 FiRa에 의해 정의된 FiRa-enabled Application일 수 있다.
"Framework"는 Profile에 대한 access, 개별 UWB 설정 및/또는 통지를 제공하는 컴포넌트일 수 있다. "Framework"는 예컨대, Profile Manager, OOB Connector, Secure Service 및/또는 UWB 서비스를 포함하는 논리적 소프트웨어 컴포넌트(logical software components)의 집합(collection)일 수 있다. 본 개시에서, Framework는 FiRa에 의해 정의된 FiRa Framework일 수 있다.
"OOB Connector"는 Ranging Device 간의 OOB(out-of-band) 연결(예컨대, BLE 연결)을 설정하기 위한 소프트웨어 컴포넌트일 수 있다. 본 개시에서, OOB Connector는 FiRa에 의해 정의된 FiRa OOB Connector일 수 있다.
"Profile"은 UWB 및 OOB 설정 파라미터(configuration parameter)의 미리 정의된 세트일 수 있다. 본 개시에서, Profile은 FiRa에 의해 정의된 FiRa Profile일 수 있다.
"Profile Manager"는 Ranging Device에서 이용가능한 프로필을 구현하는 소프트웨어 컴포넌트일 수 있다. 본 개시에서, Profile Manager는 FiRa에 의해 정의된 FiRa Profile Manager일 수 있다.
"Service"는 end-user에 서비스를 제공하는 use case의 implementation일 수 있다.
"Smart Ranging Device"는 옵셔널한 Framework API를 구현할 수 있는 Ranging Device 일 수 있다. 본 개시에서, Smart Ranging Device는 FiRa에 의해 정의된 FiRa Smart Device일 수 있다.
"Global Dedicated File(GDF)"는 USB 세션을 설정하기 위해 필요한 데이터를 포함하는 application specific data의 root level일 수 있다.
"Framework API"는 Framework와 통신하기 위해 UWB-enabled Application에 의해 사용되는 API일 수 있다.
"Initiator"는 레인징 교환(ranging exchange)을 개시하는 Ranging Device일 수 있다.
"Object Identifier(OID)"는 application data structure 내의 ADF의 식별자일 수 있다.
"Out-Of-Band(OOB)"는 하위(underlying) 무선 기술로서 UWB를 사용하지 않는 데이터 통신일 수 있다.
"Ranging Data Set(RDS)"는 confidentiality, authenticity 및 integrity가 보호될 필요가 있는 UWB 세션을 설정하기 위해 요구되는 데이터(예컨대, UWB 세션 키, 세션 ID 등)일 수 있다.
"Responder"는 레인징 교환에서 Initiator에 응답하는 Ranging Device일 수 있다.
"STS"는 레인징 측정 타임스탬프(ranging measurement timestamps)의 무결성 및 정확도(integrity and accuracy)를 증가시키기 위한 암호화된 시퀀스(ciphered sequence)일 수 있다. STS는 레인징 세션 키로부터 생성될 수 있다.
"Secure Channel"는 overhearing 및 tampering을 방지하는 데이터 채널일 수 있다.
"Secure Component"은 예컨대, dynamic STS가 사용되는 경우에, UWBS에 RDS를 제공하기 위한 목적으로 UWBS와 인터페이싱하는 정의된 보안 레벨을 갖는 엔티티(예컨대, SE 또는 TEE)일 수 있다.
"Secure Element(SE)"는 Ranging Device 내 Secure Component로서 사용될 수 있는 tamper-resistant secure hardware component일 수 있다.
"Secure Ranging"은 강한 암호화 동작을 통해 생성된 STS에 기초한 레인징일 수 있다.
"Secure Service"는 Secure Element 또는 TEE(Trusted Execution Environment)와 같은 Secure Component와 인터페이싱하기 위한 소프트웨어 컴포넌트일 수 있다.
"Service Applet"은 서비스 특정 트랜잭션을 다루는 Secure Component 상의 applet일 수 있다.
"Service Data"는 service를 구현하기 위해 두 ranging device 간에 전달될 필요가 있는 Service Provider에 의해 정의된 데이터일 수 있다.
"Service Provider"는 end-user에게 특정 서비스를 제공하기 위해 요구되는 하드웨어 및 소프트웨어를 정의하고 제공하는 엔티티일 수 있다.
"Static STS mode"는 STS가 세션 동안 반복되는 동작 모드로서, Secure Component에 의해 관리될 필요가 없다.
"Secure UWB Service(SUS) Applet"은 다른 Ranging device와 보안 UWB 세션을 가능하게 하기 위해 필요한 데이터를 검색하기 위해, applet과 통신하는 SE 상의 applet일 수 있다. 또한, SUS Applet은 해당 데이터(정보)를 UWBS로 전달할 수 있다.
"UWB Service"는 UWBS에 대한 접속(access)을 제공하는 소프트웨어 component일 수 있다.
"UWB Session"은 Controller 및 Controllee가 UWB를 통해 통신을 시작할때부터 통신을 정지할 때까지의 기간일 수 있다. UWB Session은 레인징, 데이터 전달 또는 레인징/데이터 전달 둘 모두를 포함할 수 있다.
"UWB Session ID"는 컨트로러와 컨트롤리 사이에 공유되는, UWB Session을 식별하는 ID(예컨대, 32 비트의 정수)일 수 있다.
"UWB Session Key"는 UWB Session을 보호하기 위해 사용되는 키일 수 있다. UWB Session Key는 UWB Session(또는, UWB Session ID)와 맵핑된 STS를 생성하기 위해 사용될 수 있다. 본 개시에서, UWB Session Key는 UWB Ranging Session Key(URSK)일 수 있고, 세션 키로 약칭될 수 있다.
"UWB Subsystem(UWBS)"는 UWB PHY 및 MAC 레이어(스펙)를 구현하는 하드웨어 컴포넌트일 수 있다. UWBS는 Framework에 대한 인터페이스 및 RDS를 검색하기 위한 Secure Component에 대한 인터페이스를 가질 수 있다. 본 개시에서, UWB PHY 및 MAC 스펙은 예컨대, IEEE 802.15.4/4z를 참조하는 FiRa에 의해 정의된 FiRa PHY 및 FiRa MAC 스펙일 수 있다.
이하 본 개시의 실시 예를 첨부한 도면과 함께 상세히 설명한다. 이하에서는 UWB를 이용하는 결제 시스템을 일례로서 본 개시의 실시예를 설명하지만, 유사한 기술적 배경 또는 특성을 갖는 여타의 결제 시스템에도 본 개시의 실시예가 적용될 수 있다. 예를 들어, 블루투스를 이용하는 결제 시스템 등이 이에 포함될 수 있을 것이다. 따라서, 본 개시의 실시예는 숙련된 기술적 지식을 가진 자의 판단으로써 본 개시의 범위를 크게 벗어나지 아니하는 범위에서 일부 변형을 통해 다른 통신시스템에도 적용될 수 있다.
또한, 본 개시를 설명함에 있어서 관련된 기능 혹은 구성에 대한 구체적인 설명이 본 개시의 요지를 불필요하게 흐릴 수 있다고 판단된 경우 그 상세한 설명은 생략한다. 그리고 후술되는 용어들은 본 개시에서의 기능을 고려하여 정의된 용어들로서 이는 사용자, 운용자의 의도 또는 관례 등에 따라 달라질 수 있다. 그러므로 그 정의는 본 명세서 전반에 걸친 내용을 토대로 내려져야 할 것이다.
도 1은 예시적인 결제 시스템을 나타낸다.
도 1의 결제 시스템(100)은 예를 들면, 오프라인 결제 방식으로 NFC (Near Field Communication) 결제 방식과 같은 근거리 접촉(contact)이 필요한 결제 방식을 이용하는 결제 시스템일 수 있다.
도 1을 참조하면, 결제 시스템(100)은 사용자 장치(110), 온라인 결제를 위한 결제 게이트웨이(payment gateway)(120), 오프라인 결제를 위한 결제 장치(예컨대, POS(point of sales) 단말)(130), 매입사(acquirer) 장치(140), 카드 네트워크(card network)(150) 및/또는 카드 발급자(issuer) 장치(160)를 포함할 수 있다. 실시예로서, 결제 시스템(100)은 매입사(acquirer) 장치(140)와 카드 네트워크(150) 사이에 부가가치 통신 네트워크(Value Added Network)(170)를 옵셔널한 구성으로 더 포함할 수 있다.
결제 시스템(100)은 결제 방식으로 온라인 결제 방식 및 오프라인 결제 방식을 이용할 수 있다. 결제 시스템(100)은 결제 게이트웨이(120)를 통해 미리 결정된 온라인 결제 방식을 이용하여 온라인 결제를 수행할 수 있다. 또한, 결제 시스템(100)은 POS 단말과 같은 결제 장치(130)를 통해 미리 결정된 오프라인 결제 방식(예컨대, NFC 결제 방식)을 이용하여 오프라인 결제를 수행할 수 있다.
도 1의 예시에서, 매입사 장치(140)는 가맹점을 대신하여 전표를 매입하고 결제를 처리하는 역할을 수행할 수 있다. 카드 발급자 장치(160)는 카드를 발급하는 발급자(예컨대, 은행, 카드사)의 장치로서, 카드 네트워크(150)를 통해 매입사 장치(140)와 통신하여 결제를 위한 처리 동작을 수행할 수 있다.
도 1의 결제 시스템(100)에서처럼, 근거리 접촉이 필요한 NFC 결제 방식과 같은 결제 방식을 이용하여 오프라인 결제를 수행하는 경우, 반드시 근거리 접촉(예컨대, 10cm 이내의 태깅)이 필요하다는 기술적 제약이 발생한다. 또한, 사용자가 결제를 위해 점주에게 사용자 장치(예컨대, 스마트 폰)을 전달해야 하는 서비스 측면의 제약도 발생할 수 있다.
따라서, 이러한 근거리 접촉이 필요한 결제 방식에 대비하여, 상대적으로 원거리 통신(예컨대, 수 m 거리의 통신)이 가능하여 점주에게 폰을 전달하거나, 태깅을 하지 않고 오프라인 결제를 수행할 수 있는 새로운 유형의 오프라인 결제 방식이 필요하다. 나아가, 이 새로운 유형의 오프라인 결제 방식은 원거리 통신을 이용해 오프라인 결제를 수행함으로써 발생되는 보안 및 결제 복잡도 문제를 해결할 필요가 있다. 또한, 이 새로운 유형의 오프라인 결제 방식은, 기존의 NFC 결제 방식 등을 이용한 오프라인 결제 방식에 대비하여, 결제 장치의 앞단(frontend)의 동작(예컨대, 결제 장치와 사용자 장치 간의 동작)에만 영향을 미칠 뿐, 결제 장치의 뒷단(backend)의 동작에는 영향을 미치지 않아, 기존 결제 시스템과의 호환성이 유지되어야 할 필요가 있다.
본 개시에서는 이 새로운 유형의 오프라인 결제 방식이 UWB 통신을 이용하는 오프라인 결제 방식인 것으로 가정하고, 다양한 실시예들을 설명한다. 다만, 본 개시의 다양한 실시예들이 UWB 통신을 이용하는 오프라인 결제 방식에만 적용되는 것으로 한정되는 것은 아니며, 실시예에 따라서는 UWB 통신과 유사한 기능 및 특성을 갖는 통신 방식(예컨대, 블루투스)을 이용하는 오프라인 결제 방식에도 적용될 수 있음은 통상의 기술자에게 자명하다.
도 2는 본 개시의 실시예에 따른 UWB를 이용하는 결제 시스템의 일 예를 나타낸다.
도 2의 결제 시스템(200)은 예를 들면, UWB 통신이 가능한 사용자 장치와 결제 장치 간의 UWB 구간(세션)의 통신만을 이용하여 오프라인 결제를 수행할 수 있는 결제 프로토콜(결제 서비스/결제 어플리케이션)을 이용하는 결제 시스템일 수 있다. 도 2의 실시예의 결제 프로토콜은 제1 결제 프로토콜, UWB 프로토콜, UWB 결제 프로토콜 또는 완전(full) 결제 프로토콜로 지칭될 수 있다. 도 2의 실시예의 결제 프로토콜은 오프라인 결제를 위해, 사용자 장치와 결제 장치 간의 UWB 구간의 통신 뿐만 아니라, 사용자 장치와 결제 게이트웨이 간의 인터넷 구간의 통신을 이용하는 도 3의 실시예의 결제 프로토콜과 비교된다.
도 2을 참조하면, 결제 시스템(200)은 사용자 장치(210), 온라인 결제를 위한 결제 게이트웨이(payment gateway)(220), 오프라인 결제를 위한 결제 장치(예컨대, UWB POS(point of sales) 단말)(230), 매입사(acquirer) 장치(240), 카드 네트워크(card network)(250) 및/또는 카드 발급자(issuer) 장치(260)를 포함할 수 있다. 도 2의 실시예에서, 결제를 위한 매입사 장치(240), 카드 네트워크(250) 및 카드 발급자 장치(260)의 동작 및 역할은 도 1의 실시예를 통해 상술한 내용과 동일할 수 있다.
결제 시스템(200)은 결제 게이트웨이(220)를 통해 미리 결정된 온라인 결제 방식을 이용하여 온라인 결제를 수행할 수 있다. 도 2의 실시예의 온라인 결제 방식은 예컨대, 도 1의 실시예의 온라인 결제 방식과 동일할 수 있다.
또한, 결제 시스템(200)은 UWB POS 단말과 같은 결제 장치(230)를 통해 미리 결정된 결제 프로토콜(예컨대, 완전 결제 프로토콜)을 이용하여 오프라인 결제를 수행할 수 있다. 예를 들면, 결제 시스템(200)은 UWB 구간을 통해 UWB 레인징(ranging) 절차, 트랜잭션(transaction) 절차 및/또는 결제(payment) 절차를 수행할 수 있다. 본 개시의 UWB 레인징 절차는 예컨대, "IEEE 802.15.4/z 규격" 및 "FiRa 콘소시움의 UWB 기술 규격"에 규정된 레인징 절차를 따를 수 있다. 예를 들면, UWB 레인징 절차는 예컨대, "IEEE 802.15.4/z 규격" 및 "FiRa 콘소시움의 UWB 기술 규격"에 규정된 SS(single side)-TWR(two way ranging) 방식 또는 DS(double side)-TWR 방식을 따르는 절차일 수 있다.
UWB를 이용한 오프라인 결제를 위해, 결제 장치(230)는 UWB 레인징을 통해 사용자 장치(사용자)(210)의 위치 및 거리를 정확하게 식별할 수 있어야 하며, 사용자 장치(사용자)(210)는 결제 장치(230)를 정확하게 식별 및 인증할 수 있어야 한다. 또한, 결제하려는 사용자의 의도를 정확히 파악하는 방식을 통해 결제 복잡도가 최소화 되어야 한다. 또한, 결제 과정에서 카드 정보와 같은 사용자 정보가 노출되지 말아야 하며, 보안성이 우수해야 한다. 이러한 요구사항들을 만족시키기 위한 다양한 실시예들에 대하여는 각 도면을 참조하여 이하에서 설명한다. 그리고, 도 2의 결제 시스템 및 결제 프로토콜을 이용하는 다양한 실시예에 대하여는 예컨대, 도 4 내지 5 등을 참조하여 이하에서 설명한다.
도 3은 본 개시의 실시예에 따른 UWB를 이용하는 결제 시스템의 다른 예를 나타낸다.
도 3의 결제 시스템(300)은 예를 들면, 도 2의 실시예의 결제 프로토콜과 상이하게, 오프라인 결제를 위해, 사용자 장치와 결제 장치 간의 UWB 구간(세션)의 통신 뿐만 아니라, 사용자 장치와 결제 게이트웨이 간의 인터넷 구간의 통신을 이용하는 결제 프로토콜(결제 서비스/결제 어플리케이션)을 이용하는 결제 시스템일 수 있다.
도 3의 실시예의 결제 프로토콜을 이용하는 경우, 오프라인 결제에 필요한 최소한의 정보만이 UWB 구간을 통해 전달되기 때문에, 도 2의 실시예의 결제 프로토콜을 이용하는 경우에 비해 오프라인 결제를 위한 UWB 구간의 통신이 단순화 될 수 있다. 또한, 도 3의 실시예의 결제 프로토콜을 이용하는 경우, UWB 구간을 통해 전달된 정보를 통해, 온라인 결제도 용이하게 수행될 수 있어, 결제 커버리지가 확대될 수 있다. 도 3의 실시예의 결제 프로토콜은 제2 결제 프로토콜 또는 단순화된(simplified) 결제 프로토콜으로 지칭될 수 있다.
도 3을 참조하면, 결제 시스템(300)은 사용자 장치(310), 온라인 결제를 위한 결제 게이트웨이(payment gateway)(320), 오프라인 결제를 위한 결제 장치(예컨대, UWB POS(point of sales 단말))(330), 매입사(acquirer) 장치(340), 카드 네트워크(card network)(350) 및/또는 카드 발급자(issuer) 장치(360)를 포함할 수 있다. 도 3의 실시예에서, 결제를 위한 매입사 장치(340), 카드 네트워크(350) 및 카드 발급자 장치(360)의 동작 및 역할은 도 1의 실시예를 통해 상술한 내용과 동일할 수 있다.
결제 시스템(300)은 결제 게이트웨이(320)를 통해 미리 결정된 온라인 결제 방식을 이용하여 온라인 결제를 수행할 수 있다. 도 3의 실시예의 온라인 결제 방식은 예컨대, 도 1의 실시예의 온라인 결제 방식과 동일할 수 있다. 또는, 도 3의 실시예의 온라인 결제 방식은 UWB 구간을 통해 전달된 정보를 추가적으로 이용하는 새로운 유형의 온라인 결제 방식일 수 있다. 이를 통해, 결제 시스템(300)의 오프라인 결제도 용이하게 수행될 수 있다.
또한, 결제 시스템(300)은 UWB POS 단말과 같은 결제 장치(330)를 통해 미리 결정된 결제 프로토콜(예컨대, 단순화된 결제 프로토콜)을 이용하여 오프라인 결제를 수행할 수 있다. 예를 들면, 결제 시스템(300)은 적어도 하나의 인터넷 구간(예컨대, 사용자 장치(310)와 결제 게이트웨이(320) 간의 인터넷 구간 및/또는 결제 게이트웨이(320)와 결제 장치(330) 간의 인터넷 구간)을 통해 전달된 정보를 이용하여, UWB 구간을 통해 도 2의 실시의 방식에 비해 단순화된 트랜잭션(transaction) 절차 및/또는 단순화된 결제(payment) 절차를 수행할 수 있다. 이를 통해, 결제 시스템(300)의 오프라인 결제를 위한 결제 복잡도를 줄일 수 있다.
도 3의 실시예와 같은 결제 방식을 이용하는 경우, 수수료를 고려한 결제 장치 및 결제 게이트웨이에 대한 다양한 선택의 폭을 제공할 수 있게 된다.
도 3의 결제 시스템 및 결제 프로토콜을 이용하는 다양한 실시예에 대하여는 예컨대, 도 4 내지 7을 참조하여 이하에서 설명한다.
도 4는 본 개시의 실시예에 따른 UWB를 이용하는 결제 방법을 나타낸다.
구체적으로, 도 4의 실시예는 UWB를 이용하는 오프라인 결제 방법의 일 예를 나타낸다.
도 4의 실시예에서, 사용자 장치(410)와 결제 장치(420)는 UWB 통신이 가능한 장치에 해당한다. 예를 들면, 사용자 장치와 결제 장치는 "IEEE 802.15.4 규격" 및 "FiRa 콘소시움의 UWB 기술 규격"에 의해 규정된 MAC 레이어와 PHY 레이어를 포함하는 프로토콜 스택에 따라 구현된 장치일 수 있다. 예를 들면, 사용자 장치(410) 및/또는 결제 장치(420)는 UWB 통신을 이용하여 결제 서비스(어플리케이션)을 제공하는 UWB 장치(예컨대, IEEE 802.15.4z에 정의된 Enhanced Ranging Device (ERDEV) 또는 FiRa에 의해 정의된 FiRa Device)일 수 있다.
또한, 도 4의 실시예에서는, 보안을 위한 STS(Scrambled Timestamp Sequence) 생성 모드(방법) 중, dynamic STS 생성 모드(방법)가 아닌, static STS 생성 모드(방법)가 사용될 수 있다. 다시 말해, 도 4의 실시예의 UWB 통신(또는, UWB 세션)을 위한 STS 설정(UWB STS 설정)이 static STS 설정에 해당할 수 있다. 이 경우, 특정 결제 어플리케이션(서비스/프로토콜)(예컨대, 삼성 페이)를 위해 UCI (UWB Command Interface)에 의해 설정된 VENDOR_ID 필드 및 STATIC_STS_CONFIG 필드에 기초하여 생성된 STS가 UWB 통신(UWB 레인징)을 위해 이용될 수 있다. 실시예로서, VENDOR_ID 필드는 vendor의 식별자를 포함할 수 있고, STATIC_STS_CONFIG 필드는 스태틱 STS 설정을 위한 값을 포함할 수 있다. 본 개시에서, STATIC_STS_CONFIG 필드는 STATIC_STS_Ⅳ 필드로 지칭될 수도 있다. 이러한 STS 생성 절차 및 이와 관련된 절차는 예컨대, "IEEE 802.15.4/z 규격" 및 "FiRa 콘소시움의 UWB 기술 규격"에 규정된 절차를 참조하여 수행될 수 있다.
도 4의 실시예의 절차는, UWB를 이용한 결제를 위한 결제 어플리케이션이 사용자 장치(410)에서 시작된 경우에 수행되는 절차일 수 있다.
<동작 4010 및 개시 메시지>
도 4를 참조하면, 결제 장치(420)는 UWB 레인징을 위한 개시 메시지(initiation message)를 전송할 수 있다(4010). 실시예로서, 결제 장치(420)는 개시 메시지를 브로드캐스팅할 수 있다.
실시예로서, 개시 메시지는 결제 장치와 연관된 상점(store)을 식별하기 위한 정보(예컨대, 상점의 이름) 및/또는 UWB 레인징과 연관된 경쟁 윈도우(contention window) 관련 정보(예컨대, 경쟁 윈도우의 사이즈, 및/또는 경쟁 윈도우의 존재를 알려주는 정보)를 포함할 수 있다.
실시예로서, 개시 메시지는 "IEEE 802.15.4z 규격" 및 "FiRa 콘소시움의 UWB MAC 규격"에 규정되는 Ranging Initiation Message(UWB 메시지/RFRAME)일 수 있다. 예를 들면, 개시 메시지는 RFRAME(ranging frame) 구성이 SP1(STS Packet Configuration structure 1)로 설정된 경우에 구성되는 Ranging Initiation Message(SP1 RFRAME)일 수 있다. 이 경우, 개시 메시지는 UWB 레인징을 위해 사용되는 적어도 하나의 정보(예컨대, 개시 메시지의 전송 시간을 지시하는 전송 타임스탬프)를 포함할 수 있다. 본 개시에서, SP1(STS Packet Configuration structure 1) 구성은, RFRAME(또는, UWB 메시지)를 전달하는 STS 패킷(PHY 패킷)에서, STS(또는, STS 필드)가 SFD(start-of-frame delimiter) 필드에 후행하는 구성일 수 있다. SP1 구성에 대한 설명은 "IEEE 802.15.4z 규격" 및 "FiRa 콘소시움의 규격"을 참조할 수 있다.
실시예로서, SP1 설정을 갖는 개시 메시지(SP1 Initiation Message/SP1 Ranging Initiation Message)는 MAC 헤더, 적어도 하나의 페이로드 IE(information element)를 포함하는 MAC 페이로드, 및/또는 MAC footer를 포함할 수 있다.
실시예로서, 개시 메시지는 헤더 IE 및/또는 페이로드 IE를 포함할 수 있다. 아래 표 1 및 표 2는 개시 메시지의 페이로드 IE 의 일 예를 보여준다.
Figure PCTKR2021015481-appb-T000001
Figure PCTKR2021015481-appb-T000002
표 1 및 표 2를 참조하면, 개시 메시지는 길이 필드(정보), 그룹 ID 필드(정보), 유형 필드(정보) 및/또는 컨텐트 필드(정보)를 포함하는 페이로드 IE를 포함할 수 있다. 실시예로서, 컨텐트 필드는 벤더(vendor) OUI 필드(organizationally unique identifier), UWB 메시지 ID 필드, 경쟁 윈도우 사이즈 프리젠스(presence) 필드, 상점 이름 필드, 및/또는 경쟁 윈도우 사이즈 필드를 포함할 수 있다. 각 필드에 대한 설명은 아래와 같다. 표 2에서와 같이, 상점 이름 필드는 StoreName.mPOS로 지칭될 수 있다.
길이 필드는 컨텐트 필드의 사이즈(길이)를 지시한다.
그룹 ID 필드는 해당 IE의 타입을 지시한다. 예를 들면, 개시 메시지의 경우, 그룹 ID 필드는 vendor specific nested IE를 지시하는 값(예컨대, 2)으로 설정될 수 있다.
유형 필드는 해당 IE의 유형을 지시한다. 예를 들면, 유형 필드는 IE의 유형이 페이로드 IE를 지시하는 값(예컨대, 1)으로 설정될 수 있다.
벤더 OUI 필드는 벤더의 OUI를 지시한다. 벤더 OUI 필드는 예컨대, IEEE 표준을 기반으로 정의된 메시지들의 고유성을 보장받기 위하여, 메시지를 정의하는 Vendor의 고유한 값을 포함하는 필드일 수 있다. 예를 들면, 본 개시의 경우, 벤더 OUI 필드는 Samsung OUI 및/또는 FiRa OUI를 지시하는 값으로 설정될 수 있다.
UWB 메시지 ID 필드는 해당 payload IE가 어떠한 메시지인지를 지시하는 필드일 수 있다. 예를 들면, 개시 메시지의 경우, UWB 메시지 ID 필드는 개시 메시지를 지시하는 값으로 설정될 수 있다.
경쟁 윈도우 사이즈 프리젠스 필드는 경쟁 윈도우 사이즈 필드가 존재하는지 여부를 지시한다. 예를 들면, 경쟁 윈도우 사이즈 필드가 컨텐트 필드(또는, 개시 메시지)에 존재하지 않는 경우, 경쟁 윈도우 사이즈 필드는 제1 값(예컨대, 0)으로 설정될 수 있다. 또는, 경쟁 윈도우 사이즈 필드가 컨텐트 필드(또는, 개시 메시지)에 존재하는 경우, 경쟁 윈도우 사이즈 필드는 제2 값(예컨대, 1)으로 설정될 수 있다. 본 개시에서, 경쟁 윈도우 사이즈 프리젠스 필드는 플래그 정보로 지칭될 수 있다.
상점 이름 필드는 상점의 이름을 지시한다. 예를 들면, 상점 이름 필드는 결제 장치(420)와 연관된 상점(예컨대, 결제 장치(420)를 사용하는 상점)의 이름을 지시하는 값으로 설정될 수 있다.
경쟁 윈도우 사이즈 필드는 경쟁 윈도우의 기간(time duration)을 지시한다. 예를 들면, 경쟁 윈도우 사이즈 필드는 경쟁 윈도우의 기간을 ms 단위로 지시할 수 있다. 실시예로서, 경쟁 윈도우 사이즈 필드는 UWB 레인징의 레인징 모드가 경쟁-기반(contention-based) 레인징 모드인 경우에 개시 메시지에 포함될 수 있다. 경쟁 윈도우 사이즈 필드가 개시 메시지에 포함된 경우, 각 사용자 장치(410)는 경쟁 윈도우 사이즈 필드에 의해 지시된 경쟁 윈도우의 기간 이내에 응답 메시지를 전송함으로써 경쟁-기반 레인징을 수행할 수 있다.
<동작 4020 및 응답 메시지>
사용자 장치(410)는, 개시 메시지에 대한 응답 메시지(response message)를 결제 장치(420)로 전송할 수 있다(4020). 실시예로서, 개시 메시지를 수신한 각 사용자 장치(410)는 결제 장치(420)로 응답 메시지를 유니캐스팅할 수 있다.
실시예로서, 개시 메시지에 경쟁 윈도우 사이즈 필드가 포함된 경우, 사용자 장치(410)는 경쟁 윈도우 사이즈 필드에 의해 지시되는 경쟁 윈도우의 기간 내에 응답 메시지를 결제 장치로 전송할 수 있다. 이를 통해, 사용자 장치(410)는 다른 사용자 장치와 경쟁-기반 레인징을 수행할 수 있다.
실시예로서, 응답 메시지는 사용자 장치(410)를 식별하기 위한 정보(예컨대, 사용자 장치(모바일 장치)의 이름 또는 ID)를 포함할 수 있다.
실시예로서, 응답 메시지는 "IEEE 802.15.4z 규격" 및 "FiRa 콘소시움의 UWB MAC 규격"에 규정되는 Ranging Response Message(UWB 메시지/RFRAME)일 수 있다. 예를 들면, 개시 메시지는 RFRAME(ranging frame) 구성이 SP1(STS(Scrambled Timestamp Sequence) Packet Configuration structure 1)로 설정된 경우에 구성되는 Ranging Initiation Message에 대응하는 Ranging Response Message(SP1 RFRAME)일 수 있다. 이 경우, 응답 메시지는 UWB 레인징을 위해 사용되는 적어도 하나의 정보(예컨대, 개시 메시지를 수신하고, 이에 대응하는 응답 메시지를 전송하기까지의 시간을 지시하는 응답 시간 정보 및/또는 응답 메시지의 전송 시간을 지시하는 전송 타임스탬프)를 포함할 수 있다.
실시예로서, SP1 설정을 갖는 응답 메시지(SP1 Response Message/SP1 Ranging Response Message)는 MAC 헤더, 적어도 하나의 페이로드 IE((information element)를 포함하는 MAC 페이로드, 및/또는 MAC footer를 포함할 수 있다.
실시예로서, 응답 메시지는 헤더 IE(information element) 및/또는 페이로드 IE를 포함할 수 있다. 아래 표 3 및 표 4는 응답 메시지의 페이로드 IE (information element)의 일 예를 보여준다.
Figure PCTKR2021015481-appb-T000003
Figure PCTKR2021015481-appb-T000004
표 3 및 표 4를 참조하면, 응답 메시지는 길이 필드(정보), 그룹 ID 필드(정보), 유형 필드(정보) 및/또는 컨텐트 필드(정보)를 포함하는 페이로드 IE를 포함할 수 있다. 실시예로서, 컨텐트 필드는 벤더 OUI 필드, UWB 메시지 ID 필드, 및 장치 이름 필드(정보)를 포함할 수 있다. 본 개시에서, 장치 이름 필드는 RandomID.Device로 지칭될 수 있다.
표 3 및 표 4의 응답 메시지의 길이 필드, 그룹 ID 필드, 유형 필드, 벤더 OUI 필드 및 UWB 메시지 ID 필드에 대한 정의 및 설명은 표 1의 개시 메시지의 길이 필드, 그룹 ID 필드, 유형 필드, 벤더 OUI 필드 및 UWB 메시지 ID 필드에 대한 정의 및 설명을 참조할 수 있다. 한편, 표 3 및 표 4의 UWB 메시지 ID 필드는 응답 메시지를 지시하는 값으로 설정될 수 있다.
표 3 및 표 4의 응답 메시지는 컨텐트 필드에 장치 이름 필드를 포함한다. 장치 이름 필드는 사용자 장치의 이름을 지시한다. 예를 들면, 표 3에서와 같이, 장치 이름 필드는 사용자의 모바일 장치의 이름을 지시하는 값으로 설정될 수 있다. 예컨대, 표 4에서와 같이, 모바일 장치의 이름은 모바일 장치에 대한 랜덤 ID일 수 있다. 이 장치 이름 필드를 통해, 결제 장치(420)는 응답 메시지를 전송한 사용자 장치(410)를 식별할 수 있다.
표 4를 참조하면, 응답 메시지(또는, 컨텐트 필드)는 Nonce 필드(Random.Device) 및/또는 Cryptogram 필드(Cryptogram.Device)를 더 포함할 수 있다. Nonce 필드는 세션 키를 생성하기 위한 랜덤 넘버를 포함할 수 있다. Cryptogram 필드는 랜덤 넘버를 인증하기 위한 데이터를 포함할 수 있다.
실시예로서, 결제 장치(420)는, 미리 결정된 레인징 방법(예컨대, SS-TWR 또는 DS-TWR 방식)을 이용하여, 응답 메시지를 기초로 식별된 사용자 장치에 대한 위치 정보(예컨대, 사용자 장치(410)와 결제 장치(420) 간의 상대적 거리)를 결정하고, 위치 정보를 기초로 생성된 사용자 장치(사용자)의 리스트를 제공할 수 있다. 예를 들면, 결제 장치(420)는 응답 메시지에 기초하여 각 사용자 장치에 대한 레인지(range)를 계산하여 위치 정보를 결정하고, 위치 정보를 기초로 거리 순으로 정렬된 사용자 장치(사용자)의 리스트를 제공할 수 있다. 이 경우, 사용자 장치(사용자)들 중, 결제 장치(420)로부터 미리 결정된 거리 이내에 있는 사용자 장치(사용자)만이 사용자 장치(사용자) 리스트에 포함될 수 있다. 이렇게 제공된 리스트 내의 사용자 장치들 중 한 사용자 장치가 선택될 수 있다. 예를 들면, 미리 결정된 방식에 따라, 도 4의 사용자 장치(410)가 결제 의도를 갖는 사용자 장치로서 선택될 수 있다.
<동작 4030 및 트랜잭션 정보 메시지>
결제 장치(420)는 선택된 사용자 장치(410)로 결제(예컨대, 오프라인 결제)를 위한 트랜잭션 정보 메시지를 전송할 수 있다(4030). 실시예로서, 결제 장치(420)는 트랜잭션 정보 메시지를 인밴드(in-band) 또는 아웃오브밴드(out-of-band) 연결을 통해 전송할 수 있다. 즉, 결제 장치(420)는 트랜잭션 정보 메시지를 UWB 통신/세션(in-band 통신/세션) 또는 비-UWB 통신/세션(out-of-band 통신/세션)을 통해 전송할 수 있다.
실시예로서, 트랜잭션 정보 메시지는 "FiRa 콘소시움의 UWB MAC 규격"에 규정되는 UWB Message일 수 있다.
일 실시예에서, 트랜잭션 정보 메시지는 오프라인 결제를 위한 트랜잭션 정보를 포함할 수 있다. 트랜잭션 정보는 예컨대, 액수(amount)(화폐(currency), 가격(price), 세금(tax)), 판매자(merchant) 이름, 판매자 ID, 주문 번호(order number), 결제 프로토콜, 물건 발송 주소(shipping address), 결제 시트(payment sheet)에 대한 주소, 허용된(allowed) 카드 브랜드 및/또는 리커링(recurring)에 대한 정보를 포함할 수 있다. 이처럼, 트랜잭션 정보 메시지가 완전한(complete) 트랜잭션 정보를 포함하는 케이스는 "fully implemented transaction"으로 지칭될 수 있다. 아래 표 5는 fully implemented transaction 케이스의 경우에 트랜잭션 정보 메시지에 포함되는 트랜잭션 정보의 일 예를 보여준다.
Figure PCTKR2021015481-appb-T000005
표 5를 참조하면, 트랜잭션 정보는 판매자(merchant) 이름, 액수(amount)(화폐(currency), 가격(price), 세금(tax)), 판매자 ID, 주문 번호(order number), 물건 발송 주소(shipping address), 결제 주소(billing address), 주소 비져빌리티 옵션(address visibility option), 결제 프로토콜, 판매자 국가 코드, 및/또는 지원되는(supported) 카드 브랜드에 대한 정보를 포함할 수 있다.
다른 실시예에서, 트랜잭션 정보 메시지는 트랜잭션 정보를 획득하기 위한 링크 정보(예컨대, URL (uniform resource locator))을 포함할 수 있다. 이처럼, 트랜잭션 정보 메시지가 완전한 트랜잭션 정보 대신에, 트랜잭션 정보를 획득하기 위한 링크 정보를 포함하는 케이스는 "simplified transaction"으로 지칭될 수 있다. simplified transaction을 수행하는 경우, UWB 통신을 통해, 결제를 위한 최소한의 정보만이 전송될 수 있기 때문에, 전송 오버헤드가 감소하는 이점이 있다. 이 simplified transaction 케이스의 일 예에 대하여는 도 6 및 7을 참조하여 이하에서 설명한다.
아래 표 6은 simplified transaction 케이스의 경우에 트랜잭션 정보 메시지에 포함되는 링크 정보의 일 예를 보여준다.
Figure PCTKR2021015481-appb-T000006
실시예로서, 트랜잭션 정보 메시지는 헤더 IE 및/또는 페이로드 IE를 포함할 수 있다. 아래 표 7 및 표 8은 트랜잭션 정보 메시지의 페이로드 IE의 일 예를 보여준다. 아래 표 7 및 표 8의 페이로드 IE를 포함하는 트랜잭션 정보 메시지는 예컨대, fully implemented transaction 케이스의 경우에 사용되는 트랜잭션 정보 메시지일 수 있다.
Figure PCTKR2021015481-appb-T000007
Figure PCTKR2021015481-appb-T000008
표 7 및 표 8을 참조하면, 트랜잭션 정보 메시지는 길이 필드(정보), 그룹 ID 필드(정보), 유형 필드(정보) 및/또는 컨텐트 필드(정보)를 포함하는 페이로드 IE를 포함할 수 있다.
일 실시예로서, 표 7에서와 같이, 컨텐트 필드는 벤더 OUI 필드, UWB 메시지 ID 필드, 랜덤 챌린지(random challenge) 필드(정보)(randPoS), 서명(signature) 필드 및/또는 트랜잭션 정보 필드를 포함할 수 있다. 다른 실시예에서, 표 8에서와 같이, 컨텐트 필드는 벤더 OUI 필드, UWB 메시지 ID 필드, Nonce 필드(Random.mPOS), 메시지 인증 코드 필드(MAC.mPOS) 및/또는 Encrypted Blob 필드(Encrypted Transaction info)를 포함할 수 있다.
표 7의 랜덤 챌린지 필드, 서명 필드 및 트랜잭션 정보 필드는 각각 표 8의 Nonce 필드, 메시지 인증 코드 필드 및 Encrypted Blob 필드와 동일 또는 유사한 기능을 제공하기 위해 사용되는 필드일 수 있다. 표 7의 randPos는 표 8의 Random.mPoS에 대응할 수 있고, 표 7의 randomPoS는 표 8의 StoreName.mPOS에 대응할 수 있고, 표 7의 단말 정보(Terminal Info/Term.Info.)는 표 8의 Random.Device에 대응할 수 있다.
표 7 및 표 8의 트랜잭션 정보 메시지의 길이 필드, 그룹 ID 필드, 유형 필드, 벤더 OUI 필드 및 UWB 메시지 ID 필드에 대한 정의 및 설명은 표 1의 개시 메시지의 길이 필드, 그룹 ID 필드, 유형 필드, 벤더 OUI 필드 및 UWB 메시지 ID 필드에 대한 정의 및 설명과 동일을 참조할 수 있다. 한편, 표 7 및 표 8의 UWB 메시지 ID 필드는 트랜잭션 정보 메시지를 지시하는 값으로 설정될 수 있다.
표 7의 랜덤 챌린지 필드는 트랜잭션 정보 메시지에 대한 암호화(cryptogram)을 위한 랜덤 챌린지(랜덤 넘버)를 지시한다. 예를 들면, 랜덤 챌린지 필드는 트랜잭션 정보 필드에 포함되는 트랜잭션 정보 및/또는 단말(terminal) 정보를 암호화 하기 위해 사용되는 랜덤 챌린지(randPoS)를 지시하는 값으로 설정될 수 있다. 예컨대, 표 7의 랜덤 챌린지(randPoS)는 표 8의 Nonce 필드에 포함되는 세션 키를 생성하기 위한 랜덤 넘버(Random.mPOS)에 해당할 수 있다. 본 개시에서, 랜덤 챌린지는 제1 랜덤 넘버, 제1 랜덤 챌린지, randPos, Random.mPoS로 지칭될 수 있다.
표 7의 서명(signature) 필드는 트랜잭션 정보 메시지에 대한 메시지 인증 코드(message authentication code: MAC) 정보 및/또는 서명(signing) 정보를 포함할 수 있다. 메시지 인증 코드 정보는 예컨대, 표 7의 서명(signature) 필드에서와 같은, 해시 기반 메시지 인증 코드 또는 표 8의 메시지 인증 코드에서와 같은, 해시/사이퍼 기반 메시지 인증 코드(hash-based MAC(HMAC)/Cipher-based MAC(CMAC))일 수 있다.
실시예로서, 해시 기반 메시지 인증 코드(HMAC)는 미리 결정된 해시 알고리즘을 이용하여, randPos(Random.mPoS), 트랜잭션 정보 필드(Encypted Blob 필드)에 포함되는 트랜잭션 정보 및/또는 단말 정보(Random.Device), 그리고 시메트릭 키(symmetric key)를 기초로 생성된 값일 수 있다. 예를 들면, 해시 기반 메시지 인증 코드는 randPos/Random.mPoS, 트랜잭션 정보 및 단말 정보(Random.Device)를 결합(concatenate)한 값과 symmetric key 값을 미리 정의된 HMAC 함수의 입력 값으로 하여 생성된 해시 값(예컨대, 표 7의 HMAC Hash of (randPoS||Transaction info||Term. Info., Symmetric key))일 수 있다. 표 7의 HMAC Hash of (randPoS||Transaction info||Term. Info., Symmetric key)는 표 8의 HMAC(Symmetric key, StoreName.mPOS | Encypted Blob | Random.Device)에 대응할 수 있다.
실시예로서, 사이퍼 기반 메시지 인증 코드(CMAC)는 미리 결정된 사이퍼 알고리즘을 이용하여, randPos/Random.mPoS, 트랜잭션 정보 필드(Encypted Blob 필드)에 포함되는 트랜잭션 정보 및/또는 단말 정보(Random.Device), 그리고, 시메트릭 키(symmetric key)를 기초로 생성된 값일 수 있다. 예를 들면, 사이퍼 기반 메시지 인증 코드는 randPos/Random.mPoS, 트랜잭션 정보 및 단말 정보(Random.Device)를 결합(concatenate)한 값과 symmetric key 값을 미리 정의된 CMAC 함수의 입력 값으로 하여 생성된 값(예컨대, 표 8의 CMAC(Symmetric key, StoreName.mPOS | Encypted Blob | Random.Device))일 수 있다.
실시예로서, 단말 정보(Random.Device)의 값은 예컨대, 표 4의 Nonce 필드에 포함된 값일 수 있다.
실시예로서, 서명(signing) 정보는 미리 정의된 전자 서명 알고리즘을 이용하여, randPos/Random.mPoS 및 트랜잭션 정보 필드(Encypted Blob 필드)에 포함되는 트랜잭션 정보 및/또는 단말 정보(Random.Device)에 기초하여 생성된 해시 값을 기초로 생성된 값일 수 있다. 예를 들면, 서명(signing) 정보는 randPos/Random.mPoS, 트랜잭션 정보 및 단말 정보(Random.Device)를 결합(concatenate)한 값에 해시 함수를 적용하여 생성된 해쉬 값에 서명 함수를 적용하여 생성된 값(예컨대, 표 7의 Signing (Hash(randPoS||Transaction info||Terminal Info)))일 수 있다.
<동작 4040 및 결제 정보 메시지>
사용자 장치(410)는 결제 장치(420)로 트랜잭션 정보 메시지에 대응하는 결제 정보 메시지를 전송할 수 있다(4040).
실시예로서, 결제 정보 메시지는 "FiRa 콘소시움의 UWB MAC 규격"에 규정되는 UWB Message일 수 있다.
일 실시예에서, 결제 정보 메시지는 오프라인 결제를 위한 결제 정보(예컨대, 카드 정보)를 포함할 수 있다. 결제 정보 메시지는 예컨대, 카드 번호, 만료 일(expiration date), 인증 서비스(auth service), 구매된 전체 통화, 금액(purchased total currency, amount), 빌링 정보(billing info) 및/또는 토큰(token)을 포함할 수 있다. 이처럼, 결제 정보 메시지가 완전한(complete) 결제 정보를 포함하는 케이스는 "fully implemented payment"로 지칭될 수 있다. 아래 표 9는 fully implemented payment 케이스의 경우에 결제 정보 메시지에 포함되는 트랜잭션 정보의 일 예를 보여준다.
Figure PCTKR2021015481-appb-T000009
표 9를 참조하면, 결제 정보 메시지는 카드 번호, 만료 일(expiration date), 인증 서비스(auth service), 구매된 전체 통화, 금액(purchased total currency, amount), 빌링 정보(billing info) 및/또는 토큰(token)을 포함할 수 있다.
다른 실시예에서, 결제 정보 메시지는 결제 정보를 획득하기 위한 링크 정보(예컨대, URL (uniform resource locator))을 포함할 수 있다. 이처럼, 결제 정보 메시지가 완전한 결제 정보 대신에, 결제 정보를 획득하기 위한 링크 정보를 포함하는 케이스는 "simplified payment"으로 지칭될 수 있다. simplified payment 을 수행하는 경우, UWB 통신을 통해, 결제를 위한 최소한의 정보만이 전송될 수 있기 때문에, 전송 오버헤드가 감소하는 이점이 있다. 이 simplified payment 케이스의 일 예에 대하여는 도 7을 참조하여 이하에서 설명한다.
아래 표 10은 simplified payment 케이스의 경우에 결제 정보 메시지에 포함되는 링크 정보의 일 예를 보여준다.
Figure PCTKR2021015481-appb-T000010
실시예로서, 결제 정보 메시지는 헤더 IE 및/또는 페이로드 IE를 포함할 수 있다. 아래 표 11 및 표 12는 결제 정보 메시지의 페이로드 IE의 일 예를 보여준다. 아래 표 11 및 표 12의 페이로드 IE를 포함하는 결제 정보 메시지는 예컨대, fully implemented payment 케이스의 경우에 사용되는 결제 정보 메시지일 수 있다.
Figure PCTKR2021015481-appb-T000011
Figure PCTKR2021015481-appb-T000012
표 11 및 표 12를 참조하면, 결제 정보 메시지는 길이 필드(정보), 그룹 ID 필드(정보), 유형 필드(정보) 및/또는 컨텐트 필드(정보)를 포함하는 페이로드 IE를 포함할 수 있다.
일 실시예로서, 표 11에서와 같이, 컨텐트 필드는 벤더 OUI 필드, UWB 메시지 ID 필드, 및 랜덤 챌린지 필드(정보)(randPhone)), 서명(signature) 필드 및/또는 결제 정보 필드를 포함할 수 있다. 다른 실시예에서, 표 12에서와 같이, 컨텐트 필드는 벤더 OUI 필드, UWB 메시지 ID 필드, 메시지 인증 코드 필드(MAC.DEVICE) 및/또는 Encrypted Blob 필드를 포함할 수 있다. 표 11의 서명 필드 및 결제 정보 필드는 각각 표 12의 메시지 인증 코드 필드 및 Encrypted Blob 필드와 동일 또는 유사한 기능을 제공하기 위해 사용되는 필드일 수 있다.
표 11 및 표 12의 결제 정보 메시지의 길이 필드, 그룹 ID 필드, 유형 필드, 벤더 OUI 필드 및 UWB 메시지 ID 필드에 대한 정의 및 설명은 표 1의 개시 메시지의 길이 필드, 그룹 ID 필드, 유형 필드, 벤더 OUI 필드 및 UWB 메시지 ID 필드에 대한 정의 및 설명을 참조할 수 있다. 한편, 표 11 및 표 12의 UWB 메시지 ID 필드는 결제 정보 메시지를 지시하는 값으로 설정될 수 있다.
표 11의 랜덤 챌린지 필드는 결제 정보 메시지에 대한 암호화(cryptogram)을 위한 랜덤 챌린지(랜덤 넘버)를 지시한다. 예를 들면, 랜덤 챌린지 필드는 결제 정보 필드에 포함되는 결제 정보를 암호화 하기 위해 사용되는 랜덤 챌린지를 지시하는 값으로 설정될 수 있다. 표 8의 랜덤 챌린지는 제2 랜덤 넘버, 제2 랜덤 챌린지, randPhone, Random.Device 등으로 지칭될 수 있다.
표 11의 서명(signature) 필드는 결제 정보 메시지에 대한 메시지 인증 코드 정보 및/또는 서명(signing) 정보를 포함할 수 있다. 메시지 인증 코드 정보는 예컨대, 표 11의 서명(signature) 필드에서와 같은, 해시 기반 메시지 인증 코드 또는 표 12의 메시지 인증 코드에서와 같은, 해시/사이퍼 기반 메시지 인증 코드(hash-based MAC(HMAC)/Cipher-based MAC(CMAC))일 수 있다.
일 실시예에서, 표 11에서와 같이, 해시 기반 메시지 인증 코드는 미리 결정된 해시 알고리즘을 이용하여, randPhone/Random.Device, randPos/Random.mPoS, 결제 정보 필드(Encrypted Blob 필드)에 포함되는 결제 정보, 장치 정보(Device Info) 및/또는 시메트릭 키(symmetric key)를 기초로 생성된 값일 수 있다. 예를 들면, 표 11에서와 같이, 해시 기반 메시지 인증 코드는 randPhone/Random.Device, randPos/Random.mPoS, 결제 정보 및 장치 정보(Device info)를 결합(concatenate)한 값과 symmetric key 값을 미리 정의된 HMAC 함수의 입력 값으로 하여 생성된 해시 값(예컨대, HMAC Hash of (randPhone||randPoS||Payment info||Device Info, Symmetric key)))일 수 있다. 다른 예를 들면, 표 12에서와 같이, 해시 기반 메시지 인증 코드는 Encrypted Blob 필드에 포함되는 결제 정보와 symmetric key 값을 미리 정의된 HMAC 함수의 입력 값으로 하여 생성된 해시 값(예컨대, HMAC(Symmetric key, Encypted Blob)일 수 있다.
실시예로서, 사이퍼 기반 메시지 인증 코드는 Encrypted Blob 필드에 포함되는 결제 정보와 symmetric key 값을 미리 정의된 CMAC 함수의 입력 값으로 하여 생성된 값(예컨대, HMAC(Symmetric key, Encypted Blob)일 수 있다.
실시예로서, Random.Device의 값은 예컨대, 표 4의 Nonce 필드에 포함된 값일 수 있다.
실시예로서, 서명(signing) 정보는 미리 정의된 전자 서명 알고리즘을 이용하여, randPhone/Random.Device, randPos/Random.mPoS, 결제 정보 필드에 포함되는 결제 정보 및/또는 장치 정보에 기초하여 생성된 해시 값을 기초로 생성된 값일 수 있다. 예를 들면, 서명(signing) 정보는 randPhone/Random.Device, randPos/Random.mPoS, 결제 정보 및 단말 정보를 결합(concatenate)한 값에 해시 함수를 적용하여 생성된 해쉬 값에 서명 함수를 적용하여 생성된 값(예컨대, Signing (Hash(randPhone||randPoS||Payment info||Device Info)))일 수 있다.
표 11의 장치 정보(Device info)는 예컨대, 사용자 장치를 식별하기 위한 정보 및/또는 비밀 값을 포함할 수 있다. 실시예로서, 장치 정보는 결제 정보 메시지를 포함하는 MAC 프레임의 헤더에 포함될 수도 있다.
결제 정보 필드는 결제 정보를 포함할 수 있다. 실시예로서, 결제 정보는 카드 번호(예컨대, primary account number)와 같은 카드 정보를 포함할 수 있다.
결제 정보 메시지를 수신한 결제 장치는 결제 정보 메시지에 포함된 정보에 기초하여, 결제 절차를 완료할 수 있다. 한편, 결제 장치와 뒷단의 구성 요소들(acquirer, issuer 장치들) 간의 결제 처리 절차는 공지된 절차를 따르므로 본 개시에서 자세한 설명은 생략한다.
도 4를 참조하여, 상술한 개시 메시지, 응답 메시지, 트랜잭션 정보 메시지 및/또는 결제 정보 메시지는 예컨대, "IEEE 802.15.4/z 규격" 및 "FiRa 콘소시움의 UWB MAC 기술 규격"에 정의된 MAC 프레임에 해당하거나, MAC 프레임의 페이로드에 포함되는 메시지일 수 있다. 이 경우, MAC 프레임의 헤더의 구조는 아래 표 13과 같을 수 있다.
Octets: 2 2
Frame Control Source Address
MAC header
표 13을 참조하면, MAC 프레임의 헤더(MAC 헤더)는 Frame Control 필드 및 소스 어드레스 필드를 포함할 수 있다. Frame Control 필드의 일 예는 아래 표 14와 같을 수 있다.
Field Size (bits) Notes
Frame Type 3 0b001: Data
Security Enabled 1 0b0: Auxiliary Security Header is not present
0b1: Auxiliary Security Header is present
Frame Pending 1 0b0: No pending frame for the recipient
0b1: More frame will be followed for the recipient
AR 1 0b0: No ACK frame is required
PAN ID Compression 1 1: Destination PAN ID field and Source PAN ID field are not present
Reserved 1 N/A
Sequence Number Suppression 1 0b1: Sequence number field is not present
IE Present 1 0b1: Header IE and/or Payload IE are contained in the frame
Destination Addressing Mode 2 0b00: Destination address field is not present
Frame Version 2 0b10: IEEE Std 802.15.4
Source Addressing Mode 2 0b10: Source address field contains short address
도 5는 도 4의 UWB를 이용하는 결제 방법을 이용한 예시적인 결제 시나리오를 나타낸다. 도 5의 실시예에서는, 도 4의 실시예를 참조하여 설명한 내용과 중복된 설명은 생략한다. 도 5의 사용자 장치(510) 및 결제 장치(520)는 도 4의 사용자 장치(410) 및 결제 장치(520)에 대응할 수 있다.
도 5를 참조하면, 결제 장치(520)는 UWB 레인징을 위한 개시 메시지(initiation message)를 전송할 수 있다(5010). 예를 들면, 결제 장치(520)는 비암호화/브로드캐스팅 방식(unencrypted broadcast)을 이용하여, 개시 메시지를 암호화 하지 않고, 미리 정해진 주기로 브로드캐스팅할 수 있다. 실시예로서, 개시 메시지는 결제 장치와 연관된 상점(store)을 식별하기 위한 정보(예컨대, 상점의 이름(예: Starbucks))를 포함할 수 있다.
사용자 장치(510)는 개시 메시지에 포함된 정보에 기초하여, 사용자에게 상점에 관한 정보를 제공할 수 있다. 예를 들면, 도 5에 도시된 바와 같이, 사용자 장치(520)는 " You (John) are in Starbucks"와 같은 메시지를 사용자에게 제공할 수 있다.
사용자 장치(510)는, 개시 메시지에 대한 응답 메시지(response message)를 결제 장치(520)로 전송할 수 있다(5020). 예를 들면, 사용자 장치(510)는 암호화/유니캐스트 방식(encrypted unicast)을 이용하여 응답 메시지를 암호화 하여 결제 장치(520)로 유니캐스팅할 수 있다. 실시예로서, 응답 메시지는 사용자 장치를 식별하기 위한 정보(예컨대, 사용자 장치(모바일 장치)의 이름, ID)를 포함할 수 있다.
결제 장치(520)는 응답 메시지에 기초하여, 사용자 장치(510)에 대한 위치 정보(예컨대, 사용자 장치와 결제 장치 간의 상대적 거리)를 결정하고, 위치 정보를 기초로 생성된 사용자 장치(사용자)의 리스트를 상점의 점원에게 제공할 수 있다. 예를 들면, 도 5에 도시된 것처럼, John, Lucy, Tim의 각 사용자 장치로부터 응답 메시지가 각각 수신된 경우, 결제 장치(520)는 응답 메시지에 기초하여 미리 정의된 UWB 레인징 방식에 따라 각 사용자 장치에 대한 레인지(거리)를 계산하여 위치 정보를 결정하고, 위치 정보를 기초로 거리 순으로 정렬된, "[Client list] 1.John 2.Lucy 3.Tim"와 같은 사용자의 리스트를 점원에게 제공할 수 있다. 이 경우, 점원은 사용자의 리스트를 확인하고, 가장 근거리에 위치하는 사용자를 확인하고, 해당 사용자로부터 주문을 받는 절차(도 5의 [Take order] 절차)를 수행할 수 있다. 해당 주문 절차는 도 5에 도시된 것처럼, 오프라인 상에서 대면으로 수행되는 절차일 수 있으나, 이에 한정되지 아니하고 온라인 상에서 비대면으로 수행되는 절차일 수도 있다.
결제 장치(520)는 선택된 사용자 장치(510)로, 오프라인 결제를 위한 트랜잭션 정보 메시지를 전송할 수 있다(5030). 예를 들면, 결제 장치(520)는 암호화/유니캐스트 방식(encrypted unicast)을 이용하여 응답 메시지를 암호화하여 선택된 사용자 장치로 유니캐스팅할 수 있다. 이를 위해, 도 5에 도시된 것처럼, 결제 장치(520)는 "Sends transaction info."와 같은 메시지를 점원에게 제공할 수 있다. 선택된 사용자 장치(510)는 상술한 주문 절차가 완료된 사용자의 사용자 장치일 수 있다. 실시예로서, 트랜잭션 정보 메시지는 트랜잭션 정보 또는 트랜잭션 정보를 획득하기 위한 링크 정보를 포함할 수 있다.
사용자 장치(510)는 트랜잭션 정보 메시지에 포함된 정보를 기초로, 결제를 위한 정보를 사용자에게 제공할 수 있다. 예를 들면, 사용자 장치(510)는 트랜잭션 정보를 기초로 "Americano costs $3, Select your card, Auth!"과 같은 메시지를 사용자에게 제공할 수 있다. 이를 통해, 사용자는 제공된 메시지를 확인하여, 인증 절차(예컨대, 지문 인증)를 수행할 수 있다.
사용자 장치(510)는 결제 장치(520)로 오프라인 결제를 위한 결제 정보 메시지를 전송할 수 있다(5040). 예를 들면, 사용자 장치(510)는 암호화/유니캐스트 방식(encrypted unicast)을 이용하여 결제 정보 메시지를 암호화하여, 결제 장치(520)로 유니캐스팅할 수 있다. 이를 위해, 도 5에 도시된 것처럼, 사용자 장치(510)는 "Sends payment info."와 같은 메시지를 사용자에게 제공할 수 있다. 실시예로서, 결제 정보 메시지는 결제 정보 또는 결제 정보를 획득하기 위한 링크 정보를 포함할 수 있다.
결제 장치(520)는 결제 정보 메시지에 포함된 정보에 기초하여 결제 절차를 처리할 수 있다.
도 6은 본 개시의 다른 실시예에 따른 UWB를 이용하는 결제 방법을 나타낸다.
구체적으로, 도 6의 실시예는 오프라인 결제를 위해 완전한 트랜잭션 정보를 UWB 구간에서 전송하는 대신, 트랜잭션 정보를 획득하기 위한 링크 정보를 UWB 구간에서 전송하는 simplified transaction 케이스의 일 예를 나타낸다.
도 6의 실시예에서는, 클라우드(cloud) 장치(630)가 결제 장치(620)와 사용자 장치(610) 간의 중간자 역할을 수행하는 것으로 가정한다. 실시예로서, 클라우드 장치(630)는 예컨대, 결제 게이트웨이와 같은, 온라인 결제를 위한 결제 장치에 의해 운영되는 장치일 수 있으나, 이에 한정되지 않는다. 또한, 도 6의 실시예에서는, 상술한 UWB 레인징 절차 및 결제를 위한 사용자 장치(610)의 선택이 이미 완료된 것으로 가정한다.
도 6을 참조하면, 동작 1에서, 결제 장치(620)는 클라우드 장치(630)로 업로드 될 트랜잭션 정보를 전송할 수 있다. 이 경우, 토큰(예컨대, one-time token)이 트랜잭션 정보와 함께 전송될 수 있다. 실시예로서, 트랜잭션 정보는 표 5를 참조하여 상술한 트랜잭션 정보일 수 있다. 아래 표 15는 트랜잭션 정보를 포함하는 데이터 구조의 일 예를 보여준다.
Figure PCTKR2021015481-appb-T000013
동작 2에서, 클라우드 장치(630)는 수신된 트랜잭션 정보 및 토큰을 저장하고, 트랜잭션 정보를 획득하기 위해 사용되는 링크 정보(예컨대, URL)을 생성하여, 결제 장치(620)로 전송할 수 있다. 이를 통해, 결제 장치(620)는 트랜잭션 정보를 획득하기 위해 사용되는 링크 정보를 클라우드 장치(630)로부터 수신할 수 있다.
동작 3에서, 결제 장치(620)는 수신된 링크 정보를 트랜잭션 정보 메시지에 포함하여, UWB 통신을 통해 사용자 장치(610)로 전송할 수 있다. 실시예로서, 트랜잭션 정보 메시지에 포함되는 링크 정보는 표 6을 참조하여 상술한 링크 정보일 수 있다.
동작 4에서, 사용자 장치(610)는 수신된 링크 정보를 이용하여 클라우드 장치(630)로 트랜잭션 정보를 검색하기 위한 요청을 전송할 수 있다.
동작 5에서, 클라우드 장치(630)는 링크 정보에 기초하여 저장된 트랜잭션 정보를 검색하고, 트랜잭션 정보 및 토큰을 포함하는 데이터를 사용자 장치(610)로 전송할 수 있다. 이를 통해, 사용자 장치(610)는 트랜잭션 정보 및 토큰을 포함하는 데이터를 클라우드 장치(630)로부터 수신할 수 있다.
동작 6에서, 사용자 장치(610)는 수신된 토큰을 결제 정보 메시지에 포함하여, UWB 통신을 통해 결제 장치(620)로 전송할 수 있다. 실시예로서, 결제 정보 메시지는 표 11 및 12를 참조하여 상술한 페이로드 IE를 포함하는 결제 정보 메시지일 수 있다.
도 7은 본 개시의 또 다른 실시예에 따른 UWB를 이용하는 결제 방법을 나타낸다.
구체적으로, 도 7의 실시예는 1) 오프라인 결제를 위해 완전한 트랜잭션 정보를 UWB 구간에서 전송하는 대신, 트랜잭션 정보를 획득하기 위한 링크 정보를 UWB 구간에서 전송하는 simplified transaction 케이스 및 2) 완전한 결제 정보를 UWB 구간에서 전송하는 대신, 결제 정보를 획득하기 위한 링크 정보를 UWB 구간에서 전송하는 simplified payment 케이스의 일 예를 나타낸다.
도 7의 실시예에서는, 클라우드(cloud) 장치(730)가 결제 장치(720)와 사용자 장치(710) 간의 중간자 역할을 수행하는 것으로 가정한다. 실시예로서, 클라우드 장치(730)는 예컨대, 결제 게이트웨이와 같은, 온라인 결제를 위한 결제 장치에 의해 운영되는 장치일 수 있으나, 이에 한정되지 않는다. 또한, 도 7의 실시예에서는, 상술한 UWB 레인징 절차 및 결제를 위한 사용자 장치(710)의 선택이 이미 완료된 것으로 가정한다.
도 7을 참조하면, 동작 1에서, 결제 장치(720)는 클라우드 장치(730)로 업로드 될 트랜잭션 정보를 전송할 수 있다. 이 경우, 토큰(Token_ti)이 트랜잭션 정보와 함께 전송될 수 있다.
동작 2에서, 클라우드 장치(730)는 수신된 트랜잭션 정보 및 토큰을 저장하고, 트랜잭션 정보를 획득하기 위해 사용되는 링크 정보(예컨대, URL)을 생성하여, 결제 장치(720)로 전송할 수 있다. 이를 통해, 결제 장치(720)는 트랜잭션 정보를 획득하기 위해 사용되는 링크 정보를 클라우드 장치(730)로부터 수신할 수 있다.
동작 3에서, 결제 장치(720)는 수신된 링크 정보를 트랜잭션 정보 메시지에 포함하여, UWB 통신을 통해 사용자 장치(710)로 전송할 수 있다. 실시예로서, 트랜잭션 정보 메시지에 포함되는 링크 정보는 표 6을 참조하여 상술한 링크 정보일 수 있다.
동작 4에서, 사용자 장치(710)는 수신된 링크 정보를 이용하여 클라우드 장치(730)로 트랜잭션 정보를 검색하기 위한 요청을 전송할 수 있다.
동작 5에서, 클라우드 장치(730)는 링크 정보에 기초하여 저장된 트랜잭션 정보를 검색하고, 트랜잭션 정보 및 토큰을 포함하는 데이터를 사용자 장치(710)로 전송할 수 있다. 이를 통해, 사용자 장치(710)는 트랜잭션 정보 및 토큰을 포함하는 데이터를 클라우드 장치(730)로부터 획득할 수 있다.
동작 6에서, 사용자 장치(710)는 클라우드 장치(730)로 업로드 될 결제 정보를 전송할 수 있다. 이 경우, 동작 7에서, 클라우드 장치(730)는 수신된 결제 정보를 저장하고, 결제 정보를 획득하기 위해 사용되는 링크 정보(예컨대, URL)을 생성하여, 사용자 장치(710)로 전송할 수 있다. 실시예로서, 결제 정보는 표 9를 참조하여 상술한 결제 정보일 수 있다. 아래 표 16은 결제 정보를 포함하는 데이터 구조의 일 예를 보여준다.
Figure PCTKR2021015481-appb-T000014
동작 8에서, 사용자 장치(710)는 수신된 링크 정보를 결제 정보 메시지에 포함하여, UWB 통신을 통해 결제 장치(720)로 전송할 수 있다. 실시예로서, 결제 정보 메시지에 포함되는 링크 정보는 표 10을 참조하여 상술한 링크 정보일 수 있다.
동작 9에서, 결제 장치(720)는 수신된 링크 정보를 이용하여 클라우드 장치(730)로 결제 정보를 검색하기 위한 요청을 전송할 수 있다.
동작 10에서, 클라우드 장치(730)는 링크 정보에 기초하여 저장된 결제 정보를 검색하고, 결제 정보를 포함하는 데이터를 결제 장치(720)로 전송할 수 있다. 이를 통해, 결제 장치(720)는 결제 정보를 포함하는 데이터를 클라우드 장치(730)로부터 수신할 수 있다.
도 8은 본 개시의 실시예에 따른 결제 장치가 UWB를 이용하여 결제를 처리하는 방법을 나타낸다.
도 8의 실시예에서는, 도 2 내지 7을 참조하여 상술한 내용과 중복된 설명은 생략한다. 예를 들면, 도 2 내지 7을 참조하여 상술한 개시 메시지, 응답 메시지, 트랜잭션 정보 메시지, 결제 정보 메시지 및 각 메시지에 포함되는 정보에 대한 설명은 도 8에서 설명할 개시 메시지, 응답 메시지, 트랜잭션 정보 메시지, 결제 정보 메시지 및 각 메시지에 포함되는 정보에도 적용될 수 있는 바, 중복된 설명은 생략한다.
도 8의 실시예에서, UWB(UWB 통신 또는 세션)에 대한 STS 설정은 정적(static) STS 설정에 해당하며, 정적 STS 설정에 대한 정적 STS의 값은 벤더(VENDOR) ID의 값에 기초하여 생성될 수 있다. 또한, 도 8의 실시예에서, UWB 통신에 대한 레인징 프레임 설정은 STS packet(SP) 1 설정에 해당할 수 있다. 또한, 도 8의 실시예에서, UWB 레인징의 레인징 모드(scheduled mode)는 경쟁-기반 레인징 모드일 수 있다.
도 8를 참조하면, 결제 장치는 UWB 레인징을 개시하기 위한 개시 메시지(initiation message)를 전송할 수 있다(8010). 예를 들면, 결제 장치는 개시 메시지를 브로드캐스팅할 수 있다.
실시예로서, 개시 메시지는 SP1 Ranging Initiation Message (SP1 RFRAME)일 수 있다.
실시예로서, 개시 메시지는 결제 장치 또는 결제 장치와 연관된 상점(store)을 식별하기 위한 정보(예컨대, 상점의 이름) 및/또는 경쟁-기반 레인징 모드의 UWB 레인징과 연관된 경쟁 윈도우(contention window) 관련 정보(예컨대, 경쟁 윈도우의 사이즈, 및/또는 경쟁 윈도우의 존재를 알려주는 정보)를 포함할 수 있다.
결제 장치는, 적어도 하나의 사용자 장치로부터, 개시 메시지에 대한 응답 메시지(response message)를 수신할 수 있다(8020).
실시예로서, 응답 메시지는 SP1 Ranging Response Message (SP1 RFRAME)일 수 있다.
실시예로서, 응답 메시지는 사용자 장치를 식별하기 위한 정보(예컨대, 사용자 장치(모바일 장치)의 이름 또는 ID)를 포함할 수 있다. 이 경우, 적어도 하나의 사용자 단말에 대한 위치 정보가, 적어도 하나의 사용자 단말로부터 수신된 응답 메시지를 기초로 결정될 수 있다. 예를 들면, 결제 장치는 적어도 하나의 사용자 단말로부터 수신된 응답 메시지에 기초하여 미리 설정된 UWB 레인징 방식을 이용하여 각 사용자 장치에 대한 레인지(거리)를 계산하여 위치 정보(예컨대, 결제 장치와 해당 사용자 장치 간의 상대적 거리)를 결정할 수 있다. 또한, 사용자 장치(사용자)의 리스트가 위치 정보를 기초로 생성될 수 있다. 예를 들면, 결제 장치는 위치 정보를 기초로, 각 사용자 장치(사용자)를 거리 순으로 나열하는 사용자 장치(사용자)의 리스트를 생성할 수 있다.
결제 장치는 응답 메시지에 기초하여 선택된 사용자 장치로 결제(예컨대, 오프라인 결제)를 위한 트랜잭션 정보 메시지를 전송할 수 있다(8030). 예를 들면, 결제 장치는 생성된 사용자 장치의 리스트에 포함된 한 사용자 장치를 미리 결정된 기준에 따라 선택할 수 있다. 이를 통해, 결제 의도를 갖는 사용자 장치가 선택될 수 있다.
실시예로서, 결제 장치는 트랜잭션 정보 메시지를 인밴드(in-band) 또는 아웃오브밴드(out-of-band) 연결을 통해 전송할 수 있다.
일 실시예에서, 트랜잭션 정보 메시지는 오프라인 결제를 위한 트랜잭션 정보를 포함할 수 있다. 트랜잭션 정보는 예컨대, 액수(amount)(화폐(currency), 가격(price), 세금(tax)), 판매자(merchant) 이름, 판매자 ID, 주문 번호(order number), 결제 프로토콜, 물건 발송 주소(shipping address), 결제 시트(payment sheet)에 대한 주소, 허용된(allowed) 카드 브랜드 및/또는 리커링(recurring)에 대한 정보를 포함할 수 있다.
다른 실시예에서, 트랜잭션 정보 메시지는 트랜잭션 정보를 획득하기 위한 링크 정보(예컨대, URL (uniform resource locator))을 포함할 수 있다. 이 경우, UWB 통신을 통해, 결제를 위한 최소한의 정보만이 전송될 수 있기 때문에, 전송 오버헤드가 감소하는 이점이 있다.
실시예로서, 트랜잭션 정보 메시지는, 트랜잭션 정보 메시지의 암호화를 위한 제1 랜덤 넘버, 및 트랜잭션 정보와 제1 랜덤 넘버에 기초하여 생성된 제1 서명 정보를 포함할 수 있다.
실시예로서, 트랜잭션 정보 메시지는 SP1 RFRAME 설정을 가질 수 있다.
결제 장치는 사용자 장치로부터 트랜잭션 정보 메시지에 대응하는 결제 정보 메시지를 수신할 수 있다(8040).
일 실시예에서, 결제 정보 메시지는 오프라인 결제를 위한 결제 정보(예컨대, 카드 정보)를 포함할 수 있다. 결제 정보 메시지는 예컨대, 카드 번호, 만료 일(expiration date), 인증 서비스(auth service), 구매된 전체 통화, 금액(purchased total currency, amount), 빌링 정보(billing info) 및/또는 토큰(token)을 포함할 수 있다.
다른 실시예에서, 결제 정보 메시지는 결제 정보를 획득하기 위한 링크 정보(예컨대, URL (uniform resource locator))을 포함할 수 있다. 이 경우, UWB 통신을 통해, 결제를 위한 최소한의 정보만이 전송될 수 있기 때문에, 전송 오버헤드가 감소하는 이점이 있다.
실시예로서, 결제 정보 메시지는, 상기 결제 정보 메시지의 암호화를 위한 제2 랜덤 넘버, 및 결제 정보, 제1 랜덤 넘버와 제2 랜덤 넘버에 기초하여 생성된 제2 서명 정보를 더 포함할 수 있다.
실시예로서, 결제 정보 메시지는 SP1 RFRAME 설정을 가질 수 있다.
결제 정보 메시지를 수신한 결제 장치는 결제 정보 메시지에 포함된 정보에 기초하여, 결제 절차를 완료할 수 있다.
도 9는 본 개시의 실시예에 따른 사용자 장치가 UWB를 이용하여 결제를 처리하는 방법을 나타낸다.
도 9의 실시예에서는, 도 2 내지 8을 참조하여 상술한 내용과 중복된 설명은 생략한다. 예를 들면, 도 2 내지 8을 참조하여 상술한 개시 메시지, 응답 메시지, 트랜잭션 정보 메시지, 결제 정보 메시지 및 각 메시지에 포함되는 정보에 대한 설명은 도 9에서 설명할 개시 메시지, 응답 메시지, 트랜잭션 정보 메시지, 결제 정보 메시지 및 각 메시지에 포함되는 정보에도 적용될 수 있는 바, 중복된 설명은 생략한다.
도 9의 실시예에서, UWB(UWB 통신)에 대한 STS 설정은 정적(static) STS 설정에 해당하며, 정적 STS 설정에 대한 정적 STS의 값은 벤더(VENDOR) ID의 값에 기초하여 생성될 수 있다. 또한, 도 9의 실시예에서, UWB 통신에 대한 레인징 프레임 설정은 STS packet(SP) 1 설정에 해당할 수 있다. 또한, 도 9의 실시예에서, UWB 레인징의 레인징 모드(scheduled mode)는 경쟁-기반 레인징 모드일 수 있다.
도 9를 참조하면, 사용자 장치는 UWB 레인징을 개시하기 위한 개시 메시지(initiation message)를 수신할 수 있다(9010).
실시예로서, 개시 메시지는 SP1 Ranging Initiation Message (SP1 RFRAME)일 수 있다.
실시예로서, 개시 메시지는 결제 장치 또는 결제 장치와 연관된 상점(store)을 식별하기 위한 정보(예컨대, 상점의 이름) 및/또는 경쟁-기반 레인징 모드의 UWB 레인징과 연관된 경쟁 윈도우(contention window) 관련 정보(예컨대, 경쟁 윈도우의 사이즈, 및/또는 경쟁 윈도우의 존재를 알려주는 정보)를 포함할 수 있다.
사용자 장치는, 결제 장치로, 개시 메시지에 대한 응답 메시지(response message)를 전송할 수 있다(9020).
실시예로서, 응답 메시지는 SP1 Ranging Response Message (SP1 RFRAME)일 수 있다.
실시예로서, 응답 메시지는 사용자 장치를 식별하기 위한 정보(예컨대, 사용자 장치(모바일 장치)의 이름 또는 ID)를 포함할 수 있다. 이 경우, 사용자 단말에 대한 위치 정보가, 사용자 단말로부터 수신된 응답 메시지를 기초로 결정될 수 있다. 예를 들면, 결제 장치는 사용자 단말로부터 수신된 응답 메시지에 기초하여 미리 설정된 UWB 레인징 방식을 이용하여 사용자 장치에 대한 레인지(거리)를 계산하여 위치 정보(예컨대, 결제 장치와 해당 사용자 장치 간의 상대적 거리)를 결정할 수 있다. 또한, 사용자 장치(사용자)의 리스트가 위치 정보를 기초로 생성될 수 있다. 예를 들면, 결제 장치는 위치 정보를 기초로, 응답 메시지를 전송한 각 사용자 장치(사용자)를 거리 순으로 나열하는 사용자 장치(사용자)의 리스트를 생성할 수 있다. 이를 통해, 결제 의도를 갖는 사용자 장치가 선택될 수 있다.
사용자 장치는 결제 장치로부터 오프라인 결제를 위한 트랜잭션 정보 메시지를 수신할 수 있다(8030). 예를 들면, 트랜잭션 정보 메시지를 수신한 사용자 장치는 미리 결정된 기준에 따라 사용자 장치의 리스트로부터 선택된 사용자 장치일 수 있다. 실시예로서, 사용자 장치는 트랜잭션 정보 메시지에 기초하여 결제를 위한 인증을 수행할 수 있다.
일 실시예에서, 트랜잭션 정보 메시지는 오프라인 결제를 위한 트랜잭션 정보를 포함할 수 있다. 트랜잭션 정보는 예컨대, 액수(amount)(화폐(currency), 가격(price), 세금(tax)), 판매자(merchant) 이름, 판매자 ID, 주문 번호(order number), 결제 프로토콜, 물건 발송 주소(shipping address), 결제 시트(payment sheet)에 대한 주소, 허용된(allowed) 카드 브랜드 및/또는 리커링(recurring)에 대한 정보를 포함할 수 있다.
다른 실시예에서, 트랜잭션 정보 메시지는 트랜잭션 정보를 획득하기 위한 링크 정보(예컨대, URL (uniform resource locator))을 포함할 수 있다. 이 경우, UWB 통신을 통해, 결제를 위한 최소한의 정보만이 전송될 수 있기 때문에, 전송 오버헤드가 감소하는 이점이 있다.
실시예로서, 트랜잭션 정보 메시지는, 트랜잭션 정보 메시지의 암호화를 위한 제1 랜덤 넘버, 및 트랜잭션 정보와 제1 랜덤 넘버에 기초하여 생성된 제1 서명 정보를 포함할 수 있다.
실시예로서, 트랜잭션 정보 메시지는 SP1 RFRAME 설정을 가질 수 있다.
사용자 장치는 결제 장치로 트랜잭션 정보 메시지에 대응하는 결제 정보 메시지를 전송할 수 있다(8040).
일 실시예에서, 결제 정보 메시지는 오프라인 결제를 위한 결제 정보(예컨대, 카드 정보)를 포함할 수 있다. 결제 정보는 예컨대, 카드 번호, 만료 일(expiration date), 인증 서비스(auth service), 구매된 전체 통화, 금액(purchased total currency, amount), 빌링 정보(billing info) 및/또는 토큰(token)을 포함할 수 있다.
다른 실시예에서, 결제 정보 메시지는 결제 정보를 획득하기 위한 링크 정보(예컨대, URL (uniform resource locator))을 포함할 수 있다. 이 경우, UWB 통신을 통해, 결제를 위한 최소한의 정보만이 전송될 수 있기 때문에, 전송 오버헤드가 감소하는 이점이 있다.
실시예로서, 결제 정보 메시지는, 상기 결제 정보 메시지의 암호화를 위한 제2 랜덤 넘버, 및 결제 정보, 제1 랜덤 넘버와 제2 랜덤 넘버에 기초하여 생성된 제2 서명 정보를 더 포함할 수 있다.
실시예로서, 결제 정보 메시지는 SP1 RFRAME 설정을 가질 수 있다.
결제 정보 메시지를 수신한 결제 장치는 결제 정보 메시지에 포함된 정보에 기초하여, 결제 절차를 완료할 수 있다.
도 10은 본 개시의 일 실시예에 따른 결제 장치의 구조를 도시한 도면이다.
본 개시에서, 결제 장치는 UWB 통신을 이용하여 결제 서비스를 제공하는 UWB 장치(예컨대, IEEE 802.15.4z에 정의된 Enhanced Ranging Device (ERDEV) 또는 FiRa에 의해 정의된 FiRa Device)일 수 있다.
도 10를 참고하면, 결제 장치는 송수신부 (1010), 제어부 (1020), 저장부 (1030)을 포함할 수 있다. 본 개시에서 제어부는, 회로 또는 어플리케이션 특정 통합 회로 또는 적어도 하나의 프로세서라고 정의될 수 있다.
송수신부 (1010)는 다른 네트워크 엔티티와 신호를 송수신할 수 있다. 송수신부(1010)는 예컨대, UWB 통신을 이용하여 사용자 장치와 오프라인 결제를 위한 데이터를 송수신할 수 있다.
제어부 (1020)은 본 개시에서 제안하는 실시예에 따른 결제 장치의 전반적인 동작을 제어할 수 있다. 예를 들어, 제어부 (1020)는 상기에서 기술한 순서도에 따른 동작을 수행하도록 각 블록 간 신호 흐름을 제어할 수 있다. 구체적으로, 제어부(1020)는, 예컨대, 도 2 내지 9를 참조하여 설명한 결제 장치의 결제 처리 절차의 동작을 제어할 수 있다.
저장부(1030)는 상기 송수신부 (1010)를 통해 송수신되는 정보 및 제어부 (1020)을 통해 생성되는 정보 중 적어도 하나를 저장할 수 있다. 예를 들어, 저장부 (1030)는 예컨대, 도 2 내지 9를 참조하여 설명한 UWB를 이용한 결제 처리를 위한 정보 및 데이터를 저장할 수 있다.
도 11은 본 개시의 일 실시예에 따른 사용자 장치의 구조를 도시한 도면이다.
본 개시에서, 사용자 장치는 UWB 통신을 이용하여 결제 서비스를 제공하는 UWB 장치(예컨대, IEEE 802.15.4z에 정의된 Enhanced Ranging Device (ERDEV) 또는 FiRa에 의해 정의된 FiRa Device)일 수 있다.
도 11을 참고하면, 결제 장치는 송수신부 (1110), 제어부 (1120), 저장부 (1130)을 포함할 수 있다. 본 개시에서 제어부는, 회로 또는 어플리케이션 특정 통합 회로 또는 적어도 하나의 프로세서라고 정의될 수 있다.
송수신부 (1110)는 다른 네트워크 엔티티와 신호를 송수신할 수 있다. 송수신부(1110)는 예컨대, UWB 통신을 이용하여 결제 장치와 오프라인 결제를 위한 데이터를 송수신할 수 있다.
제어부 (1120)은 본 개시에서 제안하는 실시예에 따른 사용자 장치의 전반적인 동작을 제어할 수 있다. 예를 들어, 제어부 (1120)는 상기에서 기술한 순서도에 따른 동작을 수행하도록 각 블록 간 신호 흐름을 제어할 수 있다. 구체적으로, 제어부(1120)는, 예컨대, 도 2 내지 9를 참조하여 설명한 사용자 장치의 결제 처리 절차의 동작을 제어할 수 있다.
저장부(1130)는 상기 송수신부 (1110)를 통해 송수신되는 정보 및 제어부 (1120)을 통해 생성되는 정보 중 적어도 하나를 저장할 수 있다. 예를 들어, 저장부 (1130)는 예컨대, 도 2 내지 9를 참조하여 설명한 UWB를 이용한 결제 처리를 위한 정보 및 데이터를 저장할 수 있다.
도 12는 본 개시의 일 실시예에 따른 UWB를 이용한 결제 시스템의 예시적인 아키텍쳐를 나타낸다.
도 12를 참조하면, 결제 시스템은 UWB 통신이 가능한 사용자 장치(1210) 및 결제 장치(1220)를 포함할 수 있다. 사용자 장치(1210)와 결제 장치(1220)는 UWB 통신을 이용하여 도 2 내지 9를 참조하여 상술한 결제(오프라인)를 위한 동작을 수행할 수 있다.
사용자 장치(1210) 및 결제 장치(1220)는 각각 서비스 레이어(1211,1221), 어플리케이션 레이어(1212,1222), MAC 레이어(1213,1223), PHY 레이어(1214,1224) 및 security 레이어(1215,1225)를 포함하는 프로토콜 스택을 가질 수 있다.
MAC 레이어(1213,1223) 및 PHY 레이어(1214,1224)는 UWB 통신을 위한 UWB 기반의 MAC 레이어(UWB MAC) 및 PHY 레이어(UWB PHY)로서, 예컨대, IEEE 802.15.4/4z 표준 및 FiRa 콘소시움의 기술 표준에 규정된 내용을 따를 수 있다. 또한, MAC 레이어(1213,1223) 및 PHY 레이어(1214,1224)는 UWB 통신 이외의 통신 방식을 지원하기 위한 MAC 레이어 및 PHY 레이어에 해당할 수도 있다. 예를 들면, MAC 레이어(1213,1223) 및 PHY 레이어(1214,1224)는 5G 통신 및/또는 블루투스 통신을 지원하기 위한 5G 통신 및/또는 블루투스 기반의 MAC 레이어 및 PHY 레이어에 해당할 수도 있다.
서비스 레이어(1211,1221)는 본 개시의 결제 서비스, 위치 기반 서비스 등을 포함하는 서비스를 위한 특성을 정의할 수 있다. 또한, 어플리케이션 레이어(1212,1222) 및 security 레이어(1215,1225)는 UWB 장치 및 서비스의 발견을 위한 메카니즘, 상호 호환적인 방식으로 장치들을 구현하기 위한 메카니즘, 및 상호 호환적인 보안 요구사항들을 지정할 수 있다. 서비스 레이어(1211,1221), 어플리케이션 레이어(1212,1222) 및 security 레이어(1215,1225)는 예컨대, FiRa 콘소시움의 기술 표준에 규정된 내용을 따를 수 있다.
상술한 본 개시의 구체적인 실시 예들에서, 본 개시에 포함되는 구성 요소는 제시된 구체적인 실시 예에 따라 단수 또는 복수로 표현되었다. 그러나, 단수 또는 복수의 표현은 설명의 편의를 위해 제시한 상황에 적합하게 선택된 것으로서, 본 개시가 단수 또는 복수의 구성 요소에 제한되는 것은 아니며, 복수로 표현된 구성 요소라 하더라도 단수로 구성되거나, 단수로 표현된 구성 요소라 하더라도 복수로 구성될 수 있다.
한편 본 개시의 상세한 설명에서는 구체적인 실시 예에 관해 설명하였으나, 본 개시의 범위에서 벗어나지 않는 한도 내에서 여러 가지 변형이 가능함은 물론이다. 그러므로 본 개시의 범위는 설명된 실시 예에 국한되어 정해져서는 아니 되며 후술하는 특허청구의 범위뿐만 아니라 이 특허청구의 범위와 균등한 것들에 의해 정해져야 한다.

Claims (15)

  1. UWB 통신을 이용한 결제 서비스를 제공하는 결제 장치의 방법에 있어서,
    UWB 레인징을 개시하기 위한 개시 메시지(initiation message)를 전송하는 동작;
    적어도 하나의 사용자 장치로부터, 상기 개시 메시지에 대한 응답 메시지(response message)를 수신하는 동작;
    상기 응답 메시지에 기초하여 선택된 제1 사용자 장치로 결제를 위한 트랜잭션 정보 메시지를 전송하는 동작; 및
    상기 제1 사용자 장치로부터 상기 트랜잭션 정보 메시지에 대응하는 결제 정보 메시지를 수신하는 동작을 포함하는, 방법.
  2. 제1항에 있어서,
    상기 응답 메시지에 기초하여, 상기 적어도 하나의 사용자 단말에 대한 위치 정보를 결정하는 동작;
    상기 위치 정보에 기초하여, 상기 적어도 하나의 사용자 단말에 대한 사용자 리스트를 생성하는 동작; 및
    상기 사용자 리스트에 기초하여 결제 의도(intent)를 갖는 상기 제1 사용자 장치를 선택하는 동작을 더 포함하는, 방법.
  3. 제1항에 있어서,
    상기 개시 메시지는 상기 결제 장치 또는 상기 결제 장치와 연관된 상점(store)을 식별하기 위한 정보 및 경쟁-기반(contention-based) 레인징 모드의 상기 UWB 레인징을 위한 경쟁 윈도우와 관련된 정보를 포함하는, 방법.
  4. 제3항에 있어서,
    상기 경쟁 윈도우와 관련된 정보는,
    상기 경쟁 윈도우의 기간을 지시하는 경쟁 윈도우 사이즈 정보가 존재하는지 여부를 지시하는 플래그 정보를 포함하는 방법.
  5. 제4항에 있어서,
    상기 플래그 정보가 제1 값으로 설정된 경우, 상기 경쟁 윈도우 사이즈 정보가 개시 메시지 내에 존재하지 않으며,
    상기 플래그 정보가 제2 값으로 설정된 경우, 상기 경쟁 윈도우 사이즈 정보가 개시 메시지 내에 존재하는, 방법.
  6. 제1항에 있어서,
    상기 응답 메시지는 상기 응답 메시지를 전송한 사용자 장치를 식별하기 위한 정보를 포함하는, 방법.
  7. 제1항에 있어서,
    상기 트랜잭션 정보 메시지는 상기 결제를 위한 트랜잭션 정보 또는 상기 트랜잭션 정보를 획득하기 위한 링크 정보를 포함하고,
    상기 트랜잭션 액수(amount), 판매자(merchant) 이름, 판매자 ID, 주문 번호(order number), 결제 프로토콜, 물건 발송 주소(shipping address), 결제 시트(payment sheet)에 대한 주소, 허용된(allowed) 카드 브랜드 또는 리커링(recurring) 중 적어도 하나에 대한 정보를 포함하는, 방법.
  8. 제7항에 있어서,
    상기 트랜잭션 정보 메시지는,
    상기 트랜잭션 정보 메시지의 암호화를 위한 제1 랜덤 넘버, 및
    상기 트랜잭션 정보와 상기 제1 랜덤 넘버에 기초하여 생성된 제1 서명 정보를 포함하는, 방법.
  9. 제1항에 있어서,
    상기 결제 정보 메시지는 결제 정보 및 상기 결제 정보를 획득하기 위한 링크 정보를 포함하고,
    상기 결제 정보는 카드 번호, 만료 일(expiration date), 인증 서비스(auth service), 구매된 전체 통화, 금액(purchased total currency, amount), 빌링 정보(billing info) 또는 토큰(token) 중 적어도 하나에 대한 정보를 포함하는, 방법.
  10. 제9항에 있어서,
    상기 결제 정보 메시지는,
    상기 결제 정보 메시지의 암호화를 위한 제2 랜덤 넘버, 및
    상기 결제 정보, 상기 제1 랜덤 넘버와 제2 랜덤 넘버에 기초하여 생성된 제2 서명 정보를 더 포함하는, 방법.
  11. 제1항에 있어서,
    상기 UWB 통신에 대한 STS(Scrambled Timestamp Sequence) 설정은 정적(static) STS 설정에 해당하며, 상기 정적 STS 설정에 대한 정적 STS의 값은 벤더(VENDOR) ID의 값에 기초하여 생성되며,
    상기 UWB 통신에 대한 레인징 프레임 설정은 STS packet(SP) 1 설정에 해당하며,
    상기 UWB 레인징의 레인징 모드(scheduled mode)는 경쟁-기반(contention-based) 레인징 모드에 해당하는, 방법.
  12. UWB 통신을 이용한 결제 서비스를 제공하는 사용자 장치의 방법에 있어서,
    상기 결제 장치로부터 UWB 레인징을 개시하기 위한 개시 메시지(initiation message)를 수신하는 동작;
    상기 결제 장치로 상기 개시 메시지에 대한 응답 메시지(response message)를 전송하는 동작;
    상기 결제 장치로부터 결제를 위한 트랜잭션 정보 메시지를 수신하는 동작; 및
    상기 결제 장치로 상기 트랜잭션 정보 메시지에 대응하는 결제 정보 메시지를 전송하는 동작을 포함하는, 방법.
  13. 제12항에 있어서,
    상기 트랜잭션 정보 메시지에 기초하여 결제를 위한 인증을 수행하는 동작을 더 포함하는, 방법.
  14. UWB 통신을 이용한 결제 서비스를 제공하는 결제 장치에 있어서,
    송수신부; 및
    상기 송수신부에 연결된 제어부를 포함하며, 상기 제어부는:
    UWB 레인징을 개시하기 위한 개시 메시지(initiation message)를 전송하고,
    적어도 하나의 사용자 장치로부터, 상기 개시 메시지에 대한 응답 메시지(response message)를 수신하고,
    상기 응답 메시지에 기초하여 선택된 제1 사용자 장치로 결제를 위한 트랜잭션 정보 메시지를 전송하고, 그리고,
    상기 제1 사용자 장치로부터 상기 트랜잭션 정보 메시지에 대응하는 결제 정보 메시지를 수신하도록 구성되는, 결제 장치.
  15. UWB 통신을 이용한 결제 서비스를 제공하는 사용자 장치에 있어서,
    송수신부; 및
    상기 송수신부에 연결된 제어부를 포함하며, 상기 제어부는:
    상기 결제 장치로부터 UWB 레인징을 개시하기 위한 개시 메시지(initiation message)를 수신하고,
    상기 결제 장치로 상기 개시 메시지에 대한 응답 메시지(response message)를 전송하고,
    상기 결제 장치로부터 결제를 위한 트랜잭션 정보 메시지를 수신하고, 그리고,
    상기 결제 장치로 상기 트랜잭션 정보 메시지에 대응하는 결제 정보 메시지를 전송하도록 구성되는, 사용자 장치.
PCT/KR2021/015481 2020-10-30 2021-10-29 초광대역 통신을 이용한 결제 방법 및 장치 WO2022092918A1 (ko)

Priority Applications (4)

Application Number Priority Date Filing Date Title
KR1020237018293A KR20230104650A (ko) 2020-10-30 2021-10-29 초광대역 통신을 이용한 결제 방법 및 장치
US18/034,241 US20230394463A1 (en) 2020-10-30 2021-10-29 Payment method and device using ultra-wideband communication
EP21886912.1A EP4224395A4 (en) 2020-10-30 2021-10-29 PAYMENT METHOD AND DEVICE USING ULTRA-WIDEBAND (UWB) COMMUNICATION
CN202180073550.4A CN116508044A (zh) 2020-10-30 2021-10-29 使用超宽带通信的支付方法和装置

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR20200142927 2020-10-30
KR10-2020-0142927 2020-10-30

Publications (1)

Publication Number Publication Date
WO2022092918A1 true WO2022092918A1 (ko) 2022-05-05

Family

ID=81384127

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2021/015481 WO2022092918A1 (ko) 2020-10-30 2021-10-29 초광대역 통신을 이용한 결제 방법 및 장치

Country Status (5)

Country Link
US (1) US20230394463A1 (ko)
EP (1) EP4224395A4 (ko)
KR (1) KR20230104650A (ko)
CN (1) CN116508044A (ko)
WO (1) WO2022092918A1 (ko)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023226325A1 (zh) * 2022-05-27 2023-11-30 深圳市汇顶科技股份有限公司 Uwb通信方法、芯片及设备
WO2024196198A1 (ko) * 2023-03-23 2024-09-26 삼성전자 주식회사 초광대역 통신을 이용하여 복수의 전자 장치들 간 결제 서비스를 제공하는 방법 및 장치

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20080085843A (ko) * 2005-12-20 2008-09-24 마이크로소프트 코포레이션 제1 장치와 근접한 거리 내에 있는 제2 장치에 의해제공되는 서비스를 액세스하기 위한 방법 및 컴퓨터판독가능 매체
KR20110050609A (ko) * 2011-04-27 2011-05-16 주식회사 비즈모델라인 초광대역 통신을 이용한 결제 방법
KR20170093510A (ko) * 2016-02-05 2017-08-16 삼성전자주식회사 근거리 통신을 이용한 결제 시스템 및 방법
US20200014526A1 (en) * 2018-07-05 2020-01-09 Apple Inc. Ultra Wideband Secure Ranging
KR20200070054A (ko) * 2018-12-07 2020-06-17 삼성전자주식회사 무선 통신 시스템에서 레인징을 수행하기 위한 방법 및 장치

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020050555A1 (en) * 2018-09-07 2020-03-12 Samsung Electronics Co., Ltd. Method for uwb transaction and electronic device therefor

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20080085843A (ko) * 2005-12-20 2008-09-24 마이크로소프트 코포레이션 제1 장치와 근접한 거리 내에 있는 제2 장치에 의해제공되는 서비스를 액세스하기 위한 방법 및 컴퓨터판독가능 매체
KR20110050609A (ko) * 2011-04-27 2011-05-16 주식회사 비즈모델라인 초광대역 통신을 이용한 결제 방법
KR20170093510A (ko) * 2016-02-05 2017-08-16 삼성전자주식회사 근거리 통신을 이용한 결제 시스템 및 방법
US20200014526A1 (en) * 2018-07-05 2020-01-09 Apple Inc. Ultra Wideband Secure Ranging
KR20200070054A (ko) * 2018-12-07 2020-06-17 삼성전자주식회사 무선 통신 시스템에서 레인징을 수행하기 위한 방법 및 장치

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP4224395A4 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023226325A1 (zh) * 2022-05-27 2023-11-30 深圳市汇顶科技股份有限公司 Uwb通信方法、芯片及设备
WO2024196198A1 (ko) * 2023-03-23 2024-09-26 삼성전자 주식회사 초광대역 통신을 이용하여 복수의 전자 장치들 간 결제 서비스를 제공하는 방법 및 장치

Also Published As

Publication number Publication date
EP4224395A1 (en) 2023-08-09
KR20230104650A (ko) 2023-07-10
CN116508044A (zh) 2023-07-28
EP4224395A4 (en) 2023-11-15
US20230394463A1 (en) 2023-12-07

Similar Documents

Publication Publication Date Title
WO2020197221A1 (ko) 통신 방법 및 통신 디바이스
WO2018008943A1 (en) Method and device for managing security according to service in wireless communication system
WO2020204505A1 (ko) 엣지 컴퓨팅 서비스를 위한 방법 및 그의 전자 장치
WO2016167536A1 (en) Method and apparatus for managing a profile of a terminal in a wireless communication system
WO2016178548A1 (ko) 프로파일 제공 방법 및 장치
WO2017052136A1 (ko) 이동 통신 시스템에서 프로파일 다운로드 방법 및 장치
WO2022092918A1 (ko) 초광대역 통신을 이용한 결제 방법 및 장치
EP3284274A1 (en) Method and apparatus for managing a profile of a terminal in a wireless communication system
WO2018199597A1 (en) Electronic device and proximity discovery method thereof
WO2022139514A1 (en) Method and device for device discovery using uwb
WO2019216739A1 (en) Security protection method and apparatus in wireless communication system
WO2021091186A1 (ko) Ue policy 전달을 위한 네트워크 제어 방안
WO2011155734A2 (ko) 다른 장치와 통신 하는 방법 및 통신 기기
WO2016013846A1 (ko) 무선 통신 시스템에서 요청 메시지를 처리하기 위한 방법 및 이를 위한 장치
WO2021241849A1 (ko) 에지 컴퓨팅 서비스를 수행하는 전자 장치 및 전자 장치의 동작 방법
WO2017007132A1 (ko) 암호화된 통신 세션의 모니터링 방법, 장치 및 시스템
WO2020184995A1 (ko) Euicc 단말을 변경하는 방법 및 장치
WO2022265123A1 (ko) 초광대역 통신을 수행하기 위한 방법 및 장치
WO2022250500A1 (en) Method and apparatus for configuring medium access control (mac) address for ultra-wideband (uwb) communication
WO2021060904A1 (ko) 무선 통신 시스템에서 통신을 수행하는 방법 및 장치
WO2022149874A1 (en) Method and system of authentication and authorization in an msgin5g server
WO2022245109A1 (en) Method and device for performing uwb secure ranging
WO2022260495A1 (en) Method and device for performing uwb ranging
WO2020171475A1 (ko) 무선 통신 시스템의 기기변경 방법 및 장치
WO2016048054A2 (ko) 데이터 통신 보안을 위한 방법, 장치 및 시스템

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21886912

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 202180073550.4

Country of ref document: CN

ENP Entry into the national phase

Ref document number: 2021886912

Country of ref document: EP

Effective date: 20230504

ENP Entry into the national phase

Ref document number: 20237018293

Country of ref document: KR

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE