WO2024085694A1 - 초광대역 통신을 이용하여 결제 서비스를 제공하는 방법 및 장치 - Google Patents

초광대역 통신을 이용하여 결제 서비스를 제공하는 방법 및 장치 Download PDF

Info

Publication number
WO2024085694A1
WO2024085694A1 PCT/KR2023/016292 KR2023016292W WO2024085694A1 WO 2024085694 A1 WO2024085694 A1 WO 2024085694A1 KR 2023016292 W KR2023016292 W KR 2023016292W WO 2024085694 A1 WO2024085694 A1 WO 2024085694A1
Authority
WO
WIPO (PCT)
Prior art keywords
uwb
payment
ranging
service
identifier
Prior art date
Application number
PCT/KR2023/016292
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 삼성전자 주식회사
Publication of WO2024085694A1 publication Critical patent/WO2024085694A1/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/08—Payment architectures
    • G06Q20/16—Payments settled via telecommunication 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
    • 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

Definitions

  • This disclosure relates to UWB communication, and more specifically, to a method and device for providing a payment service using UWB communication.
  • the Internet is evolving from a human-centered network where humans create and consume information to an IoT (Internet of Things) network that exchanges and processes information between distributed components such as objects.
  • IoT Internet of Things
  • IoE Internet of Everything
  • sensing technology wired and wireless communication and network infrastructure, service interface technology, and security technology are required.
  • technologies such as sensor network, Machine to Machine (M2M), and MTC (Machine Type Communication) for connection between objects are being researched.
  • M2M Machine to Machine
  • MTC Machine Type Communication
  • IoT Internet Technology
  • IT Internet Technology
  • IoT through the convergence and combination of existing IT (information technology) technology and various industries, includes smart homes, smart buildings, smart cities, smart cars or connected cars, smart grids, health care, smart home appliances, advanced medical services, etc. It can be applied in the field of
  • ranging technology that measures the distance between electronic devices using UWB (Ultra Wide Band) may be used.
  • This disclosure discloses a method of providing payment services using UWB communication.
  • a method of operating a first ultra wide band (UWB) device includes UWB indicating a payment method supported for a payment service between the first UWB device and the second UWB device.
  • the advertising message may be structured according to the BLE advertising message format. According to one embodiment, the advertising message may be structured according to the UWB advertising message format.
  • the UWB payment identifier includes information indicating Downlink Time Difference of Arrival (DL-TDoA) support, information indicating competition-based ranging support, and in-band (in -band) may include any one of information indicating UWB payment transaction support and RFU (reserved future use).
  • DL-TDoA Downlink Time Difference of Arrival
  • competition-based ranging support information indicating competition-based ranging support
  • in-band in-band
  • RFU reserved future use
  • location information (retail identifier) where the payment service is performed may include at least one of name information of the retail store where the payment service is performed and type information of the retail store.
  • the advertising message further includes UWB configuration information
  • the UWB configuration information includes at least one of a UWB session ID, service ID, UWB configuration ID, channel number, and device role. can do.
  • the Payment Profile Manager within the framework of the first UWB device may control the first UWB device to use a plurality of UWB ranging methods simultaneously or sequentially. .
  • the payment profile manager may set up a state transition diagram for processing the plurality of UWB ranging methods.
  • the method of operating the first UWB device includes a payment area (payment- An operation to set an available zone may be further included.
  • a first ultra wide band (UWB) device includes a transceiver; and a control unit.
  • the control unit includes UWB payment identifier indicating a payment method supported for payment service between the first UWB device and the second UWB device, and location information where the payment service is performed ( An advertising message including a retail identifier may be received from the second UWB device.
  • the control unit may perform UWB ranging based on the UWB payment identifier and location information where the payment service is performed (retail identifier).
  • the control unit may perform a payment transaction based on the UWB ranging result.
  • the method and device according to an embodiment of the present disclosure can provide a payment service using UWB communication.
  • FIG. 1 illustrates an example architecture of a UWB device according to one embodiment of the present disclosure.
  • Figure 2 shows an example configuration of a framework included in an electronic device supporting UWB-based services according to an embodiment of the present disclosure.
  • Figure 3a shows the structure of a UWB MAC frame according to an embodiment of the present disclosure.
  • Figure 3b shows the structure of a UWB PHY packet according to an embodiment of the present disclosure.
  • Figure 4 shows an example of a ranging block structure according to an embodiment of the present disclosure.
  • Figure 5 shows an architecture including a customer device, a merchant device, and a payment infrastructure according to an embodiment of the present disclosure.
  • Figure 6 shows an example of a payment-available zone according to an embodiment of the present disclosure.
  • FIG. 7 is a diagram for explaining a ranging block structure according to an embodiment of the present disclosure.
  • FIGS. 8A and 8B are diagrams for explaining the operation of devices for Tap-Free payment according to an embodiment of the present disclosure.
  • Figure 9 shows a payment transaction data exchange procedure during ranging according to an embodiment of the present disclosure.
  • FIG. 10 illustrates a payment transaction data exchange procedure using data transfer or sessions according to an embodiment of the present disclosure.
  • Figure 11 shows an example of a state transition diagram according to an embodiment of the present disclosure.
  • Figure 12 shows an example of direct communication for a payment procedure according to an embodiment of the present disclosure.
  • Figure 13 shows an example of indirect communication for a payment procedure according to an embodiment of the present disclosure.
  • Figure 14 shows the structure of a first UWB device, according to an embodiment of the present disclosure.
  • Figure 15 shows the structure of a second UWB device, according to an embodiment of the present disclosure.
  • each block of the processing flow diagrams and combinations of the flow diagram diagrams can be performed by computer program instructions.
  • These computer program instructions can be mounted on a processor of a general-purpose computer, special-purpose computer, or other programmable data processing equipment, so that the instructions performed through the processor of the computer or other programmable data processing equipment are described in the flow chart block(s). It creates the means to perform functions.
  • These computer program instructions may also be stored in computer-usable or computer-readable memory that can be directed to a computer or other programmable data processing equipment to implement a function in a particular manner, so that the computer-usable or computer-readable memory
  • the instructions stored in may also be capable of producing manufactured items containing instruction means to perform the functions described in the flow diagram block(s).
  • Computer program instructions can also be mounted on a computer or other programmable data processing equipment, so that a series of operational steps are performed on the computer or other programmable data processing equipment to create a process that is executed by the computer, thereby generating a process that is executed by the computer or other programmable data processing equipment. Instructions that perform processing equipment may also provide steps for executing the functions described in the flow diagram 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). Additionally, it should be noted that in some alternative execution examples it is possible for the functions mentioned in the blocks to occur out of order. For example, it is possible for two blocks shown in succession to be performed substantially at the same time, or it may be possible for the blocks to be performed in reverse order depending on the corresponding function.
  • ' ⁇ unit' used in this embodiment refers to 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.
  • the ' ⁇ part' may be configured to reside in an addressable storage medium and may be configured to reproduce on one or more processors. Therefore, according to some embodiments, ' ⁇ part' refers to components such as software components, object-oriented software components, class components, and task components, processes, functions, properties, and processes. Includes scissors, subroutines, segments of program code, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and variables.
  • components and 'parts' may be combined into a smaller number of components and 'parts' or may be further separated into additional components and 'parts'. Additionally, components and 'parts' may be implemented to regenerate one or more CPUs within a device or a secure multimedia card. Additionally, according to some embodiments, ' ⁇ unit' may include one or more processors.
  • terminal' or 'device' used in this specification refers to a mobile station (MS), user equipment (UE), user terminal (UT), wireless terminal, access terminal (AT), terminal, and subscriber unit. It may be referred to as a Subscriber Unit, a Subscriber Station (SS), a wireless device, a wireless communication device, a Wireless Transmit/Receive Unit (WTRU), a mobile node, a mobile, or other terms.
  • Various embodiments of the terminal include a cellular phone, a smart phone with a wireless communication function, a personal digital assistant (PDA) with a wireless communication function, a wireless modem, a portable computer with a wireless communication function, and a digital camera with a wireless communication function.
  • PDA personal digital assistant
  • the terminal may include devices, gaming devices with wireless communication functions, music storage and playback home appliances with wireless communication functions, Internet home appliances capable of wireless Internet access and browsing, as well as portable units or terminals that integrate combinations of such functions.
  • the terminal may include, but is not limited to, an M2M (Machine to Machine) terminal and an MTC (Machine Type Communication) terminal/device.
  • M2M Machine to Machine
  • MTC Machine Type Communication
  • the terminal may be referred to as an electronic device or simply a device.
  • wireless sensor network technology is largely divided into wireless LAN (Wireless Local Area Network; WLAN) technology and wireless personal area network (WPAN) technology depending on recognition distance.
  • WLAN Wireless Local Area Network
  • WPAN wireless personal area network
  • wireless LAN is a technology based on IEEE 802.11 and is a technology that can connect to the backbone network within a radius of about 100m.
  • wireless private networks are technologies based on IEEE 802.15 and include Bluetooth, ZigBee, and ultra wide band (UWB).
  • a wireless network in which this wireless network technology is implemented may be comprised of a plurality of electronic devices.
  • UWB can refer to a wireless communication technology that uses a bandwidth of 500 MHz or more, or has a bandwidth of 20% or more corresponding to the center frequency. UWB may also refer to the band itself to which UWB communication is applied. UWB enables safe and accurate ranging between devices. Through this, UWB enables relative position estimation based on the distance between two devices or accurate position estimation of a device based on its distance from fixed devices (where the position is known).
  • FCC Federal Communications Commission
  • ADF Application Dedicated File
  • Application Protocol Data Unit may be a command and response used when communicating with the Application Data Structure within a UWB device.
  • Application specific data may be, for example, a file structure with a root level and an application level containing 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
  • the controller can define and control ranging features by transmitting a control message.
  • Controlee may be a ranging device that uses ranging parameters in the RCM (or control message) received from the controller. Controlee can use the same ranging features as set through control messages from Controller.
  • “Dynamic STS (Scrambled Timestamp Sequence) mode” may be an operation mode in which STS is not repeated during a ranging session. In this mode, STS is managed by the ranging device, and the ranging session key that creates the STS can be managed by the Secure Component.
  • Applet may be, for example, an applet running on the Secure Component containing UWB parameters and service data.
  • the Applet may be a FiRa Applet.
  • Ranging Device may be a device capable of performing UWB ranging.
  • the Ranging Device may be an Enhanced Ranging Device (ERDEV) or a FiRa Device defined in IEEE 802.15.4z.
  • Ranging Device may be referred to as a UWB device.
  • UWB-enabled Application may be an application for UWB service.
  • a UWB-enabled Application may be an application that uses the Framework API to configure an OOB Connector, Secure Service, and/or UWB service for a UWB session.
  • UWB-enabled Application may be abbreviated as application or UWB application.
  • a UWB-enabled Application may be a FiRa-enabled Application.
  • Framework may be a component that provides access to the Profile, individual UWB settings, and/or notifications.
  • the 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 FiRa Framework.
  • OOB Connector may be a software component for establishing an out-of-band (OOB) connection (e.g., BLE connection) between Ranging Devices.
  • OOB out-of-band
  • the OOB Connector may be FiRa OOB Connector.
  • Profile may be a predefined set of UWB and OOB configuration parameters.
  • the Profile may be a FiRa Profile.
  • Profile Manager may be a software component that implements profiles available on the Ranging Device.
  • the Profile Manager may be FiRa Profile Manager.
  • Service may be the 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.
  • Global Dedicated File may be the root level of application specific data containing data required to establish a USB session.
  • 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.
  • the initiator can initiate a ranging exchange by sending the first RFRAME (Ranging Exchange Message).
  • Object Identifier may be an identifier of the ADF within the application data structure.
  • Out-Of-Band (OOB)” is an underlying wireless technology and may be data communication that does not use UWB.
  • RDS Rastering Data Set
  • UWB session key e.g., UWB session key, session ID, etc.
  • session ID e.g., session ID, etc.
  • “Responder” may be a Ranging Device that responds to the Initiator in a ranging exchange.
  • the Responder can respond to the ranging exchange message received from the Initiator.
  • STS may be an encrypted sequence to increase the integrity and accuracy of ranging measurement timestamps. STS can be generated from the ranging session key.
  • “Secure Channel” may be a data channel that prevents overhearing and tampering.
  • “Secure Component” is an entity (e.g., Secure Element (SE) or Trusted Execution Environment (TEE)) with a defined level of security that interfaces with the UWBS for the purpose of providing RDS to the UWBS, e.g., when dynamic STS is used. ) can be.
  • SE Secure Element
  • TEE Trusted Execution Environment
  • SE may be a tamper-resistant secure hardware component that can be used as a Secure Component in a Ranging Device.
  • “Secure Ranging” may be ranging based on an STS generated through strong encryption operations.
  • “Secure Service” may be a software component for interfacing with a Secure Component such as a Secure Element or TEE.
  • Service Applet may be an applet on the Secure Component that handles service-specific transactions.
  • Service Data may be data defined by the Service Provider that needs to be transferred between two ranging devices to implement a service.
  • Service Provider may be an entity that defines and provides hardware and software required to provide specific services to end-users.
  • Static STS mode is an operation mode in which STS repeats 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 a secure UWB session with another ranging device. Additionally, SUS Applet can transmit the data (information) to UWBS.
  • SUS Secure UWB Service
  • UWB Service may be a software component that provides access to UWBS.
  • UWB Session may be the period from when the Controller and Controllee start communicating via UWB until they stop communicating.
  • a UWB Session may include ranging, data forwarding, or both ranging/data forwarding.
  • UWB Session ID may be an ID (e.g., 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.
  • UWB Session Key can be used to create STS.
  • the UWB Session Key may be UWB Ranging Session Key (URSK), and may be abbreviated as session key.
  • URSK UWB Ranging Session Key
  • UWB Subsystem may be a hardware component that implements the UWB PHY and MAC layer (specification).
  • UWBS can have an interface to the Framework and an interface to the Secure Component to retrieve the RDS.
  • a “UWB message” may be a message containing a payload information element (IE) transmitted by a UWB device (eg, ERDEV).
  • IE payload information element
  • Payload IE may be an IE included in the MAC payload of a UWB MAC frame.
  • the MAC payload may include one or multiple Payload IEs.
  • “Scheduled based ranging” may be used for ranging rounds in which controllers are scheduled by the controller to transmit ranging frames (RFRAMEs) and/or measurement reports in different ranging slots.
  • Scheduling-based ranging may also be referred to as time-scheduled ranging.
  • the scheduling mode in which scheduling-based ranging is used may be referred to as time-scheduled mode.
  • Contention based ranging can be used when the controller does not know the MAC addresses of controllers participating in a UWB session (ranging session).
  • the controller may be the initiator and may perform ranging with other unknown UWB devices.
  • the scheduling mode in which contention-based ranging is used may be referred to as Contention-based mode.
  • Contention-based ranging can be used for a ranging round in which the controller determines the size of the contention access period (CAP) and informs the CAP size through a ranging control message.
  • CAP may be referred to as a contention window or contention window period.
  • the UWB device can operate as a controller and initiator, in which case the ranging control phase (RCP) and ranging initiation phase (RIP) are performed in one step (e.g. , RIP).
  • the allocation of CAP size can determine the CAP period for the responder(s) participating in the ranging round in units of ranging slots.
  • Each responder can randomly determine a slot within the CAP to transmit a ranging response message (RRM).
  • RRM ranging response message
  • Messages used in contention-based ranging can use SP1 as the RFRAME setting.
  • Hybrid ranging can be used when there are known controls and unknown controls. As described above, a known control may be a control for which the controller knows the MAC address of the control, and an unknown control may be a control for which the controller does not know the MAC address of the control. Hybrid ranging may be referred to as hybrid-based ranging. The scheduling mode in which hybrid ranging is used may be referred to as Hybrid-based Mode.
  • the controller can perform ranging in a scheduling-based mode with known controls and in a contention-based mode with unknown controls.
  • a ranging round may include a ranging control phase (RCP) and a ranging phase (RP).
  • the RP may include a contention free period (CFP) for scheduling-based ranging (access) and a contention access period (CAP) for contention-based ranging (access).
  • CCP contention free period
  • CAP contention access period
  • RRM ranging management message
  • Downlink Time Difference of Arrival is one or more tag devices (DT-Tag) based on a DL-TDoA message (DTM) received from at least one anchor device (DT-anchor). It may be a positioning method to estimate one's location.
  • the anchor device transmits or broadcasts the DTM, and the tag device passively receives the DTM, thereby preventing the location of the tag device from being exposed.
  • the anchor device can precisely measure its own DTM transmission time and the reception time of the received DTM.
  • the anchor device may include the transmission time in the DTM it transmits or broadcasts.
  • the tag device can measure the reception time of all DTMs it receives and estimate its own location using the reception timestamp and the coordinates of the acquired anchor devices.
  • DL-TDoA may be classified as a type of one way ranging, like Uplink TDoA.
  • DL-TDoA may be referred to as DL-TDoA localization.
  • Anchor device may be a UWB device deployed at a specific location to provide positioning services.
  • an anchor device may be a UWB device installed by a service provider on an indoor wall, ceiling, or structure to provide an indoor positioning service.
  • an anchor device may be a device that transmits a DTM that a tag device can use to calculate location based on TDoA localization (DL-TDoA localization).
  • anchor devices are divided into Initiator anchors and Responder anchors depending on the order and role of transmitting messages and can participate in the ranging round.
  • the anchor device may be referred to as a UWB anchor or UWB anchor device, and the anchor device of DL-TDoA may be referred to as a DL-TDoA anchor or DT-anchor.
  • “Initiator anchor” may announce the start of a TDoA ranging round (DL-TDoA ranging round).
  • the Initiator anchor can initiate a DL-TDoA ranging round by sending an initiation message and schedule the transmission time of the Responder anchor(s). For example, the Initiator anchor can schedule a ranging slot in which Responder anchor(s) operating in the same ranging round sends a response message (response DTM).
  • the initiation message may be referred to as an Initiator DTM, Poll message, Poll DTM, first DTM, etc.
  • the initiator anchor may be referred to as an initiator UWB anchor, an initiator anchor device, an initiator DT-anchor, etc.
  • the Initiator anchor may additionally deliver a final message (Final DTM) after receiving the response from the Responder anchor(s).
  • the Initiator anchor can additionally transmit a Final DTM after all Responder anchors in the same cluster transmit a response message (response DTM) in the DL-TDoA ranging round.
  • the termination message may be referred to as Final DTM, Third DTM, etc.
  • a DL-TDoA network may have at least one reference initiator anchor.
  • Reference initiator anchor is an initiator anchor that serves as a global time reference for inter-cluster synchronization and can establish a common ranging block structure for the DL-TDoA network to operate.
  • Reference initiator anchor may be referred to as master anchor or global anchor.
  • “Responder anchor” may be a UWB anchor that responds to the initiation message of the Initiator anchor.
  • the Responder anchor can respond to the Initiator anchor using a response message.
  • the response message may be referred to as Responder DTM, Response DTM, Second DTM, etc.
  • Responder anchor may be referred to as Responder UWB anchor, Responder UWB anchor device, Responder anchor device, etc.
  • Tag device can estimate its own location (e.g., geographical coordinates) using TDoA measurements based on the DTM received from the anchor device in DL-TDoA.
  • the tag device may know the location of the anchor device in advance.
  • Tag devices may be referred to as UWB tags, user devices, and UWB tag devices, and DL-TDoA tag devices may be referred to as DL-TDoA Tags and DT-Tags.
  • the tag device can receive the message transmitted by the anchor device and measure the reception time of the message.
  • the tag device can acquire the geographic coordinates of the anchor device through an in-band or out-band method.
  • the tag device may skip the ranging block if the location update rate is lower than what is supported by the network.
  • Cluster may refer to a set of anchor devices covering a specific area.
  • a cluster may refer to a set of anchor devices that exchange DTM to provide location services to at least one tag device.
  • a cluster may consist of an Initiator anchor and at least one Responder anchor.
  • One anchor device can operate in one or more clusters.
  • an anchor device that operates as an Initiator anchor in some clusters may operate as a Responder anchor in other clusters.
  • the area of the cluster may be a space formed by anchor devices constituting the cluster.
  • multiple clusters can be configured to provide positioning services to user devices.
  • a cluster may also be referred to as a cell.
  • AoA is the angle of arrival of the received signal and can be expressed as a relative angle such as AoA azimuth and AoA elevation.
  • the measuring device is a mobile phone with a display
  • the Y axis is the vertical display axis of the phone
  • the X axis is the horizontal display axis of the phone
  • the Z axis is the phone display axis.
  • the AoA azimuth angle may be the relative angle between the input signal projected on the XZ plane and the Z axis
  • the AoA elevation angle may be the relative angle between the input signal and the XZ plane.
  • the controller initiator can measure the AoA azimuth for RRM and transmit the measured AoA azimuth through a UCI notification message.
  • the responder can measure the AoA azimuth for the RIM message and transmit the measured AoA azimuth through RRRM.
  • the controller initiator can measure the AoA elevation for RRM and transmit the measured AoA elevation through a UCI notification message.
  • the responder can measure the AoA elevation for the RIM message and transmit the measured AoA elevation through RRRM.
  • the Observer can measure AoA azimuth and AoA elevation for AoA measurement messages.
  • Data Message Payload Information Element may be a payload IE used to transmit data generated from an application, applet, or other data source by including it in a UWB message. there is.
  • the data message payload IE may also be simply referred to as a data message.
  • the data message payload IE can be combined with the ranging payload IE (Ranging Payload IE) as shown in FIG. 23 to become part of the PHY Payload of the UWB message.
  • the data message payload IE may consist of, or include part of, a Vendor OUI, UWB Message Identifier (UWB Message ID), Data Message Type (DM Type), and content field.
  • UWB Message ID UWB Message ID
  • DM Type Data Message Type
  • the content of the message included in the Content field may vary. If the value of the data message type (DM Type) field is 0x0, the content field may include general application data. The content field may additionally include the length of the delivered application data. The content field may also include a MAC Data Service Data Unit (MDSDU), which is data generated above the MAC layer of the UWB Subsystem and delivered to the MAC, as a payload.
  • MDSDU MAC Data Service Data Unit
  • the content field may include a Data Transfer Phase Control Message (DTPCM).
  • DTPCM Data Transfer Phase Control Message
  • FIG. 1 illustrates an example architecture of a UWB device according to one embodiment of the present disclosure.
  • the UWB device 100 may be an electronic device that supports UWB communication.
  • the UWB device 100 may be a ranging device that supports UWB ranging.
  • the Ranging Device may be an Enhanced Ranging Device (ERDEV) or FiRa Device defined in IEEE 802.15.4z.
  • ERPEV Enhanced Ranging Device
  • FiRa Device defined in IEEE 802.15.4z.
  • UWB device 100 can interact with other UWB devices through a UWB session.
  • the UWB device 100 may implement a first interface (Interface #1), which is an interface between the UWB-enabled Application 110 and the UWB Framework 120, and the first interface may be implemented as a UWB-enabled interface on the UWB device 100. Allows application 110 to use the UWB capabilities of UWB device 100 in a predetermined manner.
  • the first interface may be a Framework API or a proprietary interface, but is not limited thereto.
  • the UWB device 100 may implement a second interface (Interface #2), which is an interface between the UWB Framework 110 and the UWB subsystem (UWBS) 130.
  • the second interface may be, but is not limited to, UCI (UWB Command Interface) or a proprietary interface.
  • the UWB device 100 may include a UWB-enabled Application 110, a Framework (UWB Framework) 120, and/or a UWBS 130 including a UWB MAC Layer and a UWB Physical Layer. there is. Depending on the embodiment, some entities may not be included in the UWB device, or additional entities (eg, security layer) may be further included.
  • the UWB-enabled Application 110 may trigger establishment of a UWB session by the UWBS 130 using the first interface. Additionally, the UWB-enabled Application 110 can use one of the predefined profiles. UWB-enabled Application 110 may use the first interface to handle related events such as service discovery, ranging notifications, and/or error conditions.
  • Framework 120 may provide access to Profile, individual UWB settings and/or notifications. Additionally, the Framework 120 may support at least one of the following functions: a function for UWB ranging and transaction performance, a function to provide an interface to an application and the UWBS 130, or a function to estimate the location of the device 100. Framework 120 may be a set of software components. As described above, the UWB-enabled Application 110 may interface with the Framework 120 through a first interface, and the Framework 120 may interface with the UWBS 130 through a second interface.
  • the UWB-enabled Application 110 and/or Framework 120 may be implemented by an application processor (AP) (or processor). Accordingly, in the present disclosure, the operation of the UWB-enabled Application 110 and/or Framework 120 may be understood as being performed by the AP (or processor).
  • the framework may be referred to as an AP or processor.
  • UWBS 130 may be a hardware component including a UWB MAC Layer and a UWB Physical Layer. UWBS 130 performs UWB session management and can communicate with UWBS of other UWB devices. UWBS 130 can interface with the Framework 120 through a second interface and obtain secure data from the Secure Component. In one embodiment, the Framework (or application processor) 120 may transmit a command to the UWBS 130 through UCI, and the UWBS 130 may send a response to the command to the Framework 120. It can be delivered to . UWBS 130 may deliver notification to Framework 120 through UCI.
  • Figure 2 shows an example configuration of a framework included in an electronic device supporting UWB-based services according to an embodiment of the present disclosure.
  • Framework 200 of FIG. 2 may be an example of UWB framework 120 of FIG. 1 .
  • the framework 200 in FIG. 2 may be, for example, the FiRa Framework.
  • the framework 200 may be a set of logical software components.
  • a UWB-enabled Application can interface with the framework through the framework API provided by the framework 200.
  • the framework 200 may include Profile Manager 210, OOB Connector 220, Secure Service 230, and/or UWB Service 240. However, depending on the embodiment, some components may be omitted or additional components may be included.
  • the Profile Manager component 210 can manage Profile(s) available on the Ranging Device (UWB device).
  • Profile may be a set of parameters required to establish a successful UWB session between Ranging Devices (UWB devices).
  • the profile may include parameters indicating which secure channel (e.g., OOB secure channel) is used, UWB/OOB configuration parameters, parameters indicating whether the use of a particular security component is mandatory, and/or a file in the ADF. It may contain parameters related to the structure.
  • Profile Manger can abstract UWB and OOB configuration parameters from UWB-enabled applications.
  • the OOB Connector component 220 may be a component for establishing OOB connections between Ranging Devices (UWB devices).
  • UWB devices Ranging Devices
  • the Secure Service component 230 may play a role in interfacing with security components such as Secure Element (SE) or Trusted Execution Environment (TEE).
  • SE Secure Element
  • TEE Trusted Execution Environment
  • the security component may be a component that interfaces with the UWBS to deliver UWB ranging data to the UWBS.
  • UWB Service component 240 may be a component that provides access to UWBS.
  • Figure 3a shows the structure of a UWB MAC frame according to an embodiment of the present disclosure.
  • the UWB MAC frame may be abbreviated as MAC frame or frame.
  • a UWB MAC frame may be used to convey UWB-related data (eg, UWB messages, ranging messages, control information, service data, application data, etc.).
  • the UWB MAC frame may include a MAC header (MHR), MAC payload, and/or MAC footer (MFR).
  • MHR MAC header
  • MFR MAC footer
  • the MAC header may include a Frame Control field, Sequence Number field, Destination Address field, Source Address field, Auxiliary Security Header field, and/or at least one Header IE field. Depending on the embodiment, some of the above-mentioned fields may not be included in the MAC header, and additional field(s) may be further included in the MAC header.
  • the Frame Control field includes a Frame Type field, a Security Enabled field, a Frame Pending field, an AR field (Ack Request field), a PAN ID Compression field (PAN ID Present field), a Sequence Number Suppression field, an IE Present field, and a Destination field. It may include an Addressing Mode field, a Frame Version field, and/or a Source Addressing Mode field. Depending on the embodiment, some of the above-mentioned fields may not be included in the Frame Control field, and additional field(s) may be further included in the Frame Control field.
  • the Frame Type field can indicate the type of frame.
  • the type of frame may include data type and/or multipurpose type.
  • the Security Enabled field may indicate whether the Auxiliary Security Header field exists.
  • the Auxiliary Security Header field may contain information required for security processing.
  • the Frame Pending field may indicate whether the device transmitting the frame has more data for the recipient. In other words, the Frame Pending field can indicate whether there is a pending frame for the recipient.
  • the AR field may indicate whether an acknowledgment of reception of the frame is required from the receiver.
  • the PAN ID Compression field may indicate whether the PAN ID field exists.
  • the Sequence Number Suppression field can indicate whether the Sequence Number field exists.
  • the Sequence Number field may indicate a sequence identifier for the frame.
  • the IE Present field may indicate whether the Header IE field and Payload IE field are included in the frame.
  • the Destination Addressing Mode field may indicate whether the Destination Address field includes a short address (eg, 16 bits) or an extended address (eg, 64 bits).
  • the Destination Address field can indicate the address of the recipient of the frame.
  • the Frame Version field can indicate the version of the frame.
  • the Frame Version field can be set to a value indicating IEEE std 802.15.4z-2020.
  • the Source Addressing Mode field indicates whether the Source Address field exists, and if the Source Address field exists, whether the Source Address field contains a short address (e.g., 16 bits) or an extended address (e.g., 64 bits). can do.
  • the Source Address field can indicate the address of the originator of the frame.
  • the MAC payload may include at least one Payload IE field.
  • the Payload IE field may include Vendor Specific Nested IE.
  • the MAC footer may include an FCS field.
  • the FCS field may include a 16-bit CRC or a 32-bit CRC.
  • Figure 3b shows the structure of a UWB PHY packet according to an embodiment of the present disclosure.
  • UWB PHY packets may be referred to as PHY packets, PHY PDUs (PPDUs), and frames.
  • the PPDU may include a synchronization header (SHR), a PHY header (PHR), and a PHY payload (PSDU).
  • the PSDU includes a MAC frame, and as shown in FIG. 4, the MAC frame may include a MAC header (MHR), MAC payload, and/or MAC footer (MFR).
  • the synchronization header part may be referred to as a preamble, and the part including the PHY header and PHY payload may be referred to as the data part.
  • the synchronization header is used for synchronization for signal reception and may include a SYNC field and a start-of-frame delimiter (SFD).
  • the SYNC field may be a field containing a plurality of preamble symbols used for synchronization between transmitting and receiving devices.
  • the preamble symbol can be set through one of predefined preamble codes.
  • the SFD field may be a field that indicates the end of the SHR and the start of the data field.
  • the PHY header may provide information about the composition of the PHY payload.
  • the PHY header may include information about the length of the PSDU, information indicating whether the current frame is an RFRAME (or a Data Frame), etc.
  • the PHY layer of the UWB device may include an optional mode to provide reduced on-air time for high density/low power operation.
  • the UWB PHY packet may include an encrypted sequence (i.e., STS) to increase the integrity and accuracy of the ranging measurement timestamp.
  • STS may be included in the STS field of the UWB PHY packet and may be used for security ranging.
  • the STS field is not included in the PPDU (SP0 packet).
  • SP setting is 1 (SP1)
  • the STS field is located immediately after the SFD (Start of Frame Delimiter) field and before the PHR field (SP1 packet).
  • SP configuration 2 SP2
  • the STS field is located after the PHY payload (SP2 packet).
  • SP setting 3 SP3
  • the STS field is located immediately after the SFD field, and the PPDU does not include the PHR and data fields (PHY payload) (SP3 packet). That is, for SP3, the PPDU does not include PHR and PHY payload.
  • each UWB PHY packet may include RMARKER to define the reference time, and RMARKER is the transmission time, reception time, and reception time of the ranging message (frame) in the UWB ranging procedure. /Or may be used to obtain a time interval.
  • Figure 4 shows an example of a ranging block structure according to an embodiment of the present disclosure.
  • one ranging block includes at least one ranging round, and each ranging round may include at least one ranging slot.
  • one ranging block includes N ranging rounds (e.g., ranging round 0 to ranging round index N-1), and ranging round #0 is M ranging slots. (For example, ranging slot 0 to ranging slot M).
  • the ranging block refers to the time period for ranging.
  • a ranging round is a period of sufficient duration to complete one entire ranging-measurement cycle (ranging cycle) involving a set of ranging devices participating in a ranging exchange. It can be.
  • the ranging slot may be a sufficient period for transmission of at least one ranging frame (RFRAME) (eg, ranging start/response/final message, etc.).
  • RFRAME ranging start/response/final message, etc.
  • the average time between successive ranging rounds may be constant.
  • the ranging mode is an interval-based mode
  • the time between successive ranging rounds can be changed dynamically.
  • the interval-based mode can adopt a time structure with adaptive spacing.
  • a ranging block can be abbreviated as a block
  • a ranging round can be abbreviated as a round
  • a ranging slot can be abbreviated as a slot.
  • This disclosure proposes an upper layer operation to support a tap-free payment service using at least one UWB ranging method (defined by the FiRa consortium).
  • the UWB ranging method includes time-scheduled two way ranging (TWR), contention-based two way ranging (TWR), and one-way ranging (OWR) downlink tdoa. (time difference of arrival) ranging method, OWR uplink tdoa ranging method, OWR for AoA measurement ranging method, hybrid ranging, data transfer during ranging , and a data transfer phase.
  • TWR time-scheduled two way ranging
  • TWR contention-based two way ranging
  • OWR one-way ranging
  • a tap-free payment service refers to UWB rather than contact-based or contactless payment such as IC (Integrated Circuit) cards or NFC (Near Field Communication). Based on the ranging result, the customer device (or user device) and merchant device (or clerk device) recognize the distance from each other, go through a certain authentication process, and then use the UWB channel. It can refer to a service that performs payment by exchanging data for direct payment or online payment (in-app, in-app payment).
  • a customer device is a UWB-enabled device of a customer visiting a store, and can implement the functions necessary to operate a tap-free payment service according to embodiments of the present disclosure.
  • a payment application may be an application installed on a customer terminal for a tap-free payment service.
  • the Payment Applet may be an applet that runs on the Secure Element for a tab-free payment service.
  • Payment Infrastructure may be infrastructure deployed in stores capable of out of band (OOB) and UWB functions.
  • the payment infrastructure may be linked to a backend payment server through which customer terminals can perform payment transactions.
  • the merchant device supports the UWB function and may be a UWB-enabled device with a Point of Sale (PoS) function.
  • PoS Point of Sale
  • Example 1 Discovery between a seller terminal (or clerk terminal) and a customer terminal (or user terminal) using UWB by simultaneously or sequentially using a plurality of UWB ranging methods; A process in which the seller terminal and the customer terminal perform UWB ranging or UWB secure ranging; Process of performing payment protocol through UWB channel;
  • the Payment Profile Manager may be implemented in an application or operating system (OS) of a customer terminal or a seller terminal.
  • the Payment Profile Manager may be an object that can transmit commands to UWBS or its parent object.
  • the function of processing the plurality of UWB ranging methods may be managed and/or performed in the Payment Profile Manager or an application of its upper layer in the form of a state transition diagram.
  • Example 2 Method of defining a payment-available zone; And a method of setting and utilizing the payment area on a customer terminal and/or a seller terminal.
  • the payment area can be defined based on the distance measured through UWB ranging between the seller terminal and the customer terminal and the measured AoA (Angle of Arrival).
  • Example 3 A method of minimizing interference between a plurality of UWB sessions by aligning a plurality of seller terminals and a plurality of UWB anchors in a store based on one reference UWB session.
  • Example 4 Setting a payment service identifier for service identification and a retail identifier for providing store information.
  • the payment service identifier may be an identifier that refers to a list of multiple UWB ranging methods managed by the Payment Profile Manager and a state transition diagram composed of these.
  • the main objective of the FiRa Tap-Free Payment Profile is to provide a technical solution including a set of essential UWB features and OOB mechanisms to support Tap-Free payment services.
  • Figure 5 shows an architecture including a customer device, a merchant device, and a payment infrastructure according to an embodiment of the present disclosure.
  • the architecture 500 includes a customer device 510, a payment gateway 520, a payment network 530, and a payment infrastructure 540. and a vendor device 550.
  • Customer device 510 includes a payment application (or FiRa-enabled application) 511, a framework (or FiRa framework) 512, a secure element 513, an OOB subsystem 514, and a UWB subsystem 515. may include.
  • the customer device 510 may serve as an observer role and receive at least one of BLE advertisements and UWB advertisements.
  • the framework 512 includes a profile manager 512-2 including a payment profile manager 512-1, a secure service 512-3, a UWB service 512-4, a FiRa OOB connector 512-5, and OOB service 512-6.
  • the payment application 511 may be connected to the profile manager 512-2 through a framework API.
  • Payment profile manager 512-1 may initiate and/or manage multiple UWB sessions simultaneously or sequentially using various ranging methods.
  • the ranging method is TWR, DL-TDoA. It may include at least one of UL-TDoA for AoA measurement, OWR, hybrid ranging, and data transmission during a ranging session.
  • the secure element 513 may include a payment applet 513-1, a FiRa applet 513-2, and a SUS applet 513-3.
  • the FiRa applet (513-2) can be connected to the SUS applet (513-3) through the SUS internal API.
  • the SUS applet 513-3 can be connected to the UWB subsystem 515 through the SUS external API.
  • the payment applet 513-1 can perform payment transactions supported by the payment service provider.
  • the payment applet 513-1 can manage authentication credentials and encryption keys to establish a secure channel with the seller terminal 550.
  • Payment infrastructure 540 may include an OOB subsystem 541, at least one advertiser 542, at least one DT-anchor 543, and at least one UT-anchor 544.
  • Merchant device 550 may include an application/framework 551, OOB subsystem 552, secure element 553, and UWB subsystem 554.
  • the secure element 553 may include a payment applet 553-1 and a FiRa applet 553-2.
  • Figure 6 shows an example of a payment-available zone according to an embodiment of the present disclosure.
  • the seller device 610 has a payment area to perform a payment transaction with at least one customer device 620 among the plurality of customer devices 620, 630, 640, and 650. can be set.
  • the seller device 610 provides an AoA azimuth ( ⁇ ) measured by the seller device 610 and/or at least one customer device (at least one of 620, 630, 640, and 650) and a distance (d) according to the result of the TWR. You can set the payment area based on .
  • the customer device 660 can set its own payment area to limit the space where payment transactions are valid.
  • the customer device 660 may set a payment area based on the AoA azimuth ( ⁇ ) measured by the seller device 670 and/or the customer device 660 and the distance (d) according to the result of the TWR.
  • the payable zone is based on at least one of a range of AoA azimuth and/or AoA elevation values measured by the merchant device and/or the customer device, and the distance between the customer device and the merchant device as a result of the TWR. can be decided.
  • the payment available area may be set by a payment service provider.
  • a payment area can be set for each seller device in the store, and information about the payment area is delivered to the customer device through a BLE advertisement packet or UWB advertisement message. It can be.
  • a payment transaction may be performed only when both the customer device and the merchant device are within a payment enabled area.
  • At least one UWB session may be coordinated to prevent collisions and interference between merchant devices and UWB devices in the payment infrastructure.
  • at least one of the merchant devices or UWB devices may operate as a time reference provider or time reference device based on a reference time to align a plurality of UWB sessions in the store. there is.
  • the time reference provider will have the application configuration parameter, SESSION_TIME_BASE [UCI v2.0], set to 0b0 (reference time base activation) with a value of octet 0, and other merchant devices and UWB devices in the payment infrastructure. They can set their SESSION_TIME_BASE to the value of octet 1, 0b1, i.e. disabled, and set octets 1-5 of SESSION_TIME_BASE to the session handle of the reference session created by the time reference provider.
  • SESSION_TIME_BASE [UCI v2.0]
  • the reference time base is the reference initiator DT-Anchor [MAC v2.0]. It can be created by .
  • FIG. 7 is a diagram for explaining a ranging block structure according to an embodiment of the present disclosure.
  • merchant devices (Merchant Device 1 to Merchant Device 4) and customer devices (Customer Device 1 to Customer Device 3) send control messages and DL-TDoA for competition.
  • Messages and/or data may be transmitted and received in a first contention free period (CFP), a contention period (CP) for a response message to contention access, and a second CFP for a payment transaction.
  • CFP contention free period
  • CP contention period
  • second CFP for a payment transaction.
  • the first merchant device may be set as a reference time device.
  • a first customer device (Customer Device 1) accesses a first merchant device (Merchant Device 1)
  • a second customer device (Customer Device 2) accesses a third merchant device (Merchant Device 3)
  • a third customer device (Customer Device 3) can be accessed by a second merchant device (Merchant Device 2).
  • the first CFP provides navigation services that are not tracked by merchant devices and/or UWB anchors in the payment infrastructure to user devices or customer devices in the store; and/or the first CFP is used to transmit a Ranging Initiation Message (RIM) including a control message for contention-based ranging;
  • RIM Ranging Initiation Message
  • CP can be used by customer devices to respond to the RIM with CM for contention-based ranging.
  • customer devices can randomly select the ranging slot used to respond to one of the RIMs corresponding to the merchant device attempting to establish UWB sessions for a payment transaction.
  • the second CFP may be used for payment transactions.
  • Merchant devices may adjust the start time of the CFP for payment transaction sessions based on a reference time base and appropriate time offset values configured by the store manager.
  • FIGS. 8A and 8B are diagrams for explaining the operation of devices for Tap-Free payment according to an embodiment of the present disclosure.
  • the system for Tap-Free payment includes a user device (or customer device), a first seller device, a second seller device, a K seller device (where K is an integer of 3 or more), and May include payment infrastructure.
  • the payment infrastructure automatically wakes up the UWBS of the customer device and uses OOB mechanisms (e.g. , BLE) can be used.
  • OOB mechanisms e.g. , BLE
  • the customer device is provided with a payment service identifier, a list of retail identifiers, and UWB ranging methods used to complete a payment transaction proceeding with the Tap-Free payment service. At least one of the order information can be obtained.
  • the customer device may obtain the at least one piece of information through a BLE advertisement packet from a BLE device deployed in a store or a UWB advertisement message transmitted by a UWB advertiser.
  • the BLE advertising packet or UWB advertising message may include the following information:
  • Payment service identifier can be used to identify a specific payment service. By using the payment service identifier, the customer device can recognize the supported payment application, the set of required UWB functionality, and the supported payment transaction protocol. The payment service identifier may also be associated with supported encryption algorithms and security protocols that may be used to set up a UWB secure ranging and/or secure data transfer session between the customer device and the merchant device.
  • the retail store identifier can be used to identify the store.
  • the retail store identifier may be, for example, a store name or a service provider name.
  • the customer device may perform at least one of the following procedures:
  • UWB session(s) Prepare to initiate a set of UWB session(s) and/or UWB ranging methods using the appropriate UWB configuration parameter sets mapped to the payment service identifier.
  • UWB session(s) may be initialized.
  • One of the payment applications supported by the store can be automatically launched.
  • the default payment application may be automatically started in the background.
  • the customer device may execute a payment application installed in the customer device.
  • the payment application may turn on UWBS on the customer device.
  • the payment application will satisfy the following requirements.
  • the payment application may be a FiRa-supported application defined in the FiRa CSML standard.
  • the payment application can start UWB service through the framework APIs defined in the FiRa CSML standard.
  • the payment application can receive BLE advertising packets based on the FiRa OOB (Out-Of-Band) channels that support the BLE advertising.
  • FiRa OOB Out-Of-Band
  • the payment application may start the UWB service corresponding to the information included in the BLE advertisement packet received through the FiRa OOB channel.
  • the payment application can access the FiRa payment profile manager using the framework API.
  • the payment application may register itself with the FiRa framework via the FIRAServiceInit API as defined in section 10.3.1 of the FiRa CSML standard before starting its first Tap-Free payment service.
  • the payment application uses the FIRAServiceInit() function with the following parameters:
  • the customer device may initiate in-band service discovery through the payment application.
  • the merchant devices and/or payment infrastructure may transmit in-band service discovery messages, and the customer device may receive the in-band service discovery messages to identify a service and prepare for subsequent procedures.
  • the payment infrastructure may support an untracked navigation service for the customer device to estimate its location within the store as a background operation.
  • the untracked navigation service supported in the payment infrastructure provides the positioning accuracy required by the store, such as 1) determining which seller device is closest among a plurality of seller devices in the store. 2) sufficient positioning accuracy, or 2) sufficient positioning accuracy to identify the table number/area in which the customer device is located,
  • a recommended distance between two adjacent merchant devices or check-out counters can be specified to clearly distinguish between the two devices under a certain precision.
  • the customer devices and merchant devices may detect each other based on two-way ranging.
  • the customer device may select one merchant device (or a UWB device in the payment infrastructure) to perform secure ranging.
  • the merchant device or UWB device in the payment infrastructure
  • may select one customer device to perform secure ranging e.g., an employee manually verifies the device device/user identifier.
  • competition-based ranging may be used when discovering seller devices.
  • the seller device may act as a controller/initiator of contention-based ranging. If there are multiple vendor devices, the vendor devices may initiate UWB sessions in line with the reference session created by the time reference device using appropriate time offsets to prevent collisions between UWB messages from the vendor devices.
  • the customer device can act as a controllee/responder for contention-based ranging. The customer device may respond to one of the merchant devices in the payment area.
  • an in-band secure ranging setup procedure may be performed.
  • the customer device and the seller device can establish a secure ranging session and safely perform a payment transaction through the secure ranging session.
  • the customer device and merchant device/payment infrastructure may establish a UWB secure ranging session via either in-band or OOB methods.
  • the customer device and merchant device/payment infrastructure will perform UWB secure ranging before performing a payment transaction.
  • the customer device may request user intent/confirmation before performing the payment transaction.
  • the customer device and the merchant device may perform payment transactions with a level of security sufficient to meet the security requirements required by the service provider.
  • the customer device may perform an online in-app payment method to complete the payment process.
  • Figure 9 shows a payment transaction data exchange procedure during ranging according to an embodiment of the present disclosure.
  • a data transfer procedure may be performed during ranging at the payment transaction stage.
  • the customer device and the merchant device may exchange data about the payment protocol during TWR.
  • data transfer during ranging can be used as a ranging method.
  • the customer device may transmit a control message scheduling a ranging slot for ranging to the seller device.
  • the customer device may transmit a ranging initiation message (RIM) and an APDU command message to the merchant device.
  • the seller device may transmit a ranging response message (RRM) and an APDU response message to the customer device.
  • RRM ranging response message
  • the customer device may transmit a ranging final message to the merchant device.
  • the customer device may transmit a ranging result report message to the seller device.
  • the customer device and the seller device may perform operations 911 to 919 that are the same or substantially the same as operations 901 to 909.
  • FIG. 10 illustrates a payment transaction data exchange procedure using data transfer or sessions according to an embodiment of the present disclosure.
  • the customer device and the merchant device may exchange data for the payment protocol through a dedicated session or stage for data transfer.
  • the customer device and the seller device may establish a data transfer-only session or a data transfer step as a secondary session in the hybrid session.
  • the customer device may transmit a control message type 3 to the merchant device scheduling ranging slots for steps within the hybrid session.
  • the customer device may transmit a control message type 1 scheduling a ranging slot for ranging to the seller device.
  • the customer device may transmit the RIM to the merchant device.
  • the merchant device may transmit the RRM to the customer device.
  • the customer device may transmit a ranging final message to the seller device.
  • the seller device may transmit a ranging result report message to the customer device.
  • the customer device may transmit a data transfer control message to the merchant device scheduling ranging slots for data transfer.
  • the customer device may transmit an APDU command message to the merchant device.
  • the seller device may transmit an APDU response message to the customer device.
  • a hybrid session may be used including a data transfer step.
  • a data transfer only session may be used in operations 1019 to 1023.
  • the customer device may transmit a data transfer control message to the merchant device scheduling ranging slots for data transfer.
  • the customer device may transmit an APDU command message to the merchant device.
  • the seller device may transmit an APDU response message to the customer device.
  • feature profiles and device profiles may be defined to support FiRa Tap-Free payment service.
  • Table 1 lists the required technical features that must be implemented between customer and vendor devices.
  • Figure 11 shows an example of a state transition diagram according to an embodiment of the present disclosure.
  • the payment profile manager can manage the state transition diagram to sequentially execute various ranging methods step by step.
  • the state transition occurs through a user's activity through the user interface of the payment application or through successful completion of a procedure that must be performed in the current state using an ongoing ranging method.
  • the payment service identifier may specify a state transition diagram that includes criteria for state transitions and a set of ranging methods used by the states.
  • the idle state 1101 can transition to the Standby state 1103 based on FiRaServiceActivate().
  • the Standby state 1103 transitions to the Activate OWR state 1105 (e.g., OWR for AoA or DL-TDoA), and the Activate OWR state 1105 is contention-based ranging. It may transition to the state 1107 of activating the hybrid session along with the step.
  • the state 1107 of activating the hybrid session with the contention-based ranging step may transition to the state 1109 of activating the data transfer step to the STS.
  • the state 1109 activating the data transfer step to the STS may transition to the secure ranging and data transfer state 1111 to the STS.
  • At least one Payment Application configuration may be set by the payment application on the customer device through the FIRAServiceinit() API.
  • the payment application configuration may include service configuration, UWB configuration, and OOB configuration.
  • the profile ID of the Tap-Free payment profile in Service Configuration may be “XX”.
  • the profile ID value may be broadcast during the device and service discovery phase.
  • the profile ID value can be used in the FIRAServiceinit () API.
  • Object ServiceConfiguration for service configuration is configured as shown in Table 2.
  • Object ServiceConfiguration for UWB configuration is configured as shown in Table 3.
  • all other parameters in the UWB configuration are configurable by the FiRa support application provider using the FIRAServiceinit () API or the FiRa UWB framework.
  • OOB configuration Object ServiceConfiguration for OOB configuration (OOB configuration) is configured as shown in Table 4.
  • the BLE Advertisement Message Format used for payment services may be configured as shown in Table 5.
  • the Length field indicates the number of octets for all subsequent data in the BLE advertising message.
  • the Data Type field indicates values according to Bluetooth SIG standard allocation numbers.
  • the Company Identifier field indicates the FiRa consortium identifier assigned by the Bluetooth SIG.
  • the UWB indication data field indicates encoded UWB-related bitmap information.
  • the UWB Configuration field indicates information about the UWB configuration required to start the UWB service.
  • the user device starts activating UWBS using the corresponding parameters contained in this field.
  • the Service Specific Information field indicates information related to a specific UWB payment service. According to one embodiment, the value of the service specific information will be formatted according to Table 6.
  • the advertiser when UWB advertising is used to provide payment service information and retail store information, the advertiser will send an AoA measurement message with a data message payload IE containing the content defined by Table 7.
  • the UWB Advertisement Message Format may be configured as shown in Table 7.
  • the content of Advertisement Data included in the UWB advertisement message format may be structured as shown in Table 8.
  • a secure channel may be used to set up an encryption-supported communication channel between a payment applet on a merchant device and a customer device.
  • public keys may follow the format defined in Table 8 of Global Platform Confidential Card Content Management Card Specification v2.3 - Amendment A, Version 1.2.
  • ECDH is the Ephemeral Unified Model, C(2e,2s, ECC CDH) as defined in NIST Special Publication 800-56A Revision 3 - Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography.
  • keys and data for the secure channel protocol may be configured as shown in Table 9.
  • ECDH is a Full Unified Model, C(2e, 2s, ECC CDH) method as defined in NIST Special Publication 800-56A Revision 3 - Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography.
  • the key derivation was performed according to NIST SP 800-108 in counter mode using AES128 CMAC for PRF.
  • the PRF used in the KDF will be CMAC as specified in NIST 800-38B, used with a total output length of 16 bytes.
  • the input data is structured using the following fields as defined in NITS SP800-108. It should be noted that it is permissible to define a different order from that proposed in the standard as long as it is clearly defined.
  • a certificate format may be established that is used to authenticate a merchant device and establish secure ranging between a customer device and a merchant device.
  • the certificate format is for the secure channel protocol and may follow an X.509 certificate or may be the format specified in Table 10.
  • Figure 12 shows an example of direct communication for a payment procedure according to an embodiment of the present disclosure.
  • a secure channel may be established between a UWB enabled wallet application and a terminal.
  • the terminal may verify the certificate of the UWB-enabled wallet application while the secure channel is established.
  • the certificate may include ID.Wallet and ID.Device, allowing backend systems (e.g., acquirer, issuer) to identify a specific UWB-enabled wallet application.
  • the terminal may transmit identification information about the wallet (ID.Wallet) to the acquirer.
  • the acquirer may transmit supported wallet information and a nonce to the terminal.
  • the nonce is a random number used for one-time use, and the nonce may be an approved code or number from the acquirer.
  • the nonce can be mapped to the ID.Wallet and ID.Device along with transaction information of the acquirer's system.
  • the terminal may transmit at least one of transaction information, MAC.TI, and nonce to the UWB-enabled wallet application.
  • the UWB-enabled wallet application may perform a user authentication procedure.
  • the UWB-enabled wallet application can transmit payment information and MAC.PI to the terminal.
  • the MAC.TI may be calculated based on Equation 1.
  • the MAC.PI may be calculated based on Equation 2.
  • Padding fixes the AES block size and can be performed according to section 6.3 of RFC 5652.
  • the terminal may transmit at least one of Amount, token, and cryptogram to the acquirer.
  • the acquirer may transmit result information about the payment transaction to the terminal.
  • the terminal may transmit result information about the payment transaction to the UWB-enabled wallet application.
  • transaction information and payment information are exchanged through the secure channel, and the terminal may receive acknowledgment by forwarding the decrypted payment information to a backend system such as the acquirer and/or issuer.
  • the transaction may be completed through a message containing final result information.
  • the transaction information may be personal information transmitted from the terminal to a UWB-enabled wallet application.
  • the transaction information may include at least one field defined in Table 11.
  • the payment information may be personal information transmitted from a UWB-enabled wallet application to the terminal in encrypted format through a secure channel.
  • payment information may include at least one field defined in Table 12.
  • Figure 13 shows an example of indirect communication for a payment procedure according to an embodiment of the present disclosure.
  • the UWB channel can only be used for secure ranging from a technical perspective.
  • security ranging may be performed to verify payment transactions.
  • the remaining information for payment such as transaction information and payment information, may be exchanged in the background using general Internet communication, and/or Cloud to Cloud (C2C) communication.
  • C2C Cloud to Cloud
  • the wallet application on the mobile and the PoS may establish a secure channel.
  • the wallet application can transmit certificates (including ID.Wallet and ID.Device) to PoS.
  • PoS may generate a tID (or transaction ID).
  • PoS can transmit transaction information, ID.Wallet, and ID.Device to the seller server.
  • the seller server may transmit transaction information, ID.Wallet, ID.Device, and Nonce to the wallet server (authorized by the acquirer).
  • the wallet server may transmit a push message requesting payment to the wallet application.
  • the wallet server and the wallet application may exchange transaction information.
  • the wallet application may perform a payment operation through user input (eg, fingerprint).
  • the wallet application may transmit a payment confirmation message to the wallet server.
  • the wallet application may perform PoS and security ranging to verify the authenticity of transaction information.
  • the wallet server may transmit payment information to the seller server.
  • the seller server may transmit payment information to the acquirer/issuer.
  • Figure 14 shows the structure of a first UWB device, according to an embodiment of the present disclosure.
  • the first UWB device may be an electronic device that corresponds to the UWB device of FIG. 1, includes a UWB device, or includes a part of a UWB device.
  • the first UWB device may be a customer device (or user device) for the UWB-based payment service described in FIGS. 1 to 13.
  • the first UWB device may include a transceiver 1410, a control unit 1420, and a storage unit 1430.
  • the control unit may be defined as a circuit or application-specific integrated circuit or at least one processor.
  • the transceiver unit 1410 can transmit and receive signals with other entities.
  • the control unit 1420 may control the overall operation of the customer device (or user device) according to the embodiment proposed in this disclosure.
  • the control unit 1420 may control signal flow between each block to perform operations according to the flowchart described above.
  • the control unit 1420 may control, for example, the operation of the first UWB device described with reference to FIGS. 1 to 13.
  • the storage unit 1430 may store at least one of information transmitted and received through the transmitting and receiving unit 1410 and information generated through the control unit 1420.
  • the storage unit 1430 may store information and data necessary for the method described with reference to FIGS. 1 to 13, for example.
  • the control unit 1420 includes UWB payment identifier indicating a payment method supported for payment service between the first UWB device and the second UWB device, and location information where the payment service is performed.
  • An advertising message including (retail identifier) may be received from the second UWB device.
  • the control unit 1420 may perform UWB ranging based on the UWB payment identifier and the location information where the payment service is performed (retail identifier).
  • the control unit 1420 may perform a payment transaction based on the UWB ranging result.
  • the advertising message may be structured according to the BLE advertising message format. According to one embodiment, the advertising message may be structured according to the UWB advertising message format.
  • the UWB payment identifier includes information indicating Downlink Time Difference of Arrival (DL-TDoA) support, information indicating competition-based ranging support, and in-band (in -band) may include any one of information indicating UWB payment transaction support and RFU (reserved future use).
  • DL-TDoA Downlink Time Difference of Arrival
  • competition-based ranging support information indicating competition-based ranging support
  • in-band in-band
  • RFU reserved future use
  • location information (retail identifier) where the payment service is performed may include at least one of name information of the retail store where the payment service is performed and type information of the retail store.
  • the advertising message further includes UWB configuration information
  • the UWB configuration information includes at least one of a UWB session ID, service ID, UWB configuration ID, channel number, and device role. can do.
  • the Payment Profile Manager within the framework of the first UWB device may control the first UWB device to use a plurality of UWB ranging methods simultaneously or sequentially. .
  • the payment profile manager may set up a state transition diagram for processing the plurality of UWB ranging methods.
  • control unit 1420 determines a payment-available zone based on at least one of an angle of arrival (AoA) azimuth, a range of AoA altitude values, and a distance value according to the result of TWR. You can set it.
  • AoA angle of arrival
  • Figure 15 shows the structure of a second UWB device, according to an embodiment of the present disclosure.
  • the second UWB device may be an electronic device that corresponds to the UWB device of FIG. 1, includes a UWB device, or includes a part of a UWB device.
  • the second UWB device may be, for example, a merchant device for a UWB-based payment service.
  • the second UWB device may include a transceiver 1510, a control unit 1520, and a storage unit 1530.
  • the control unit may be defined as a circuit or application-specific integrated circuit or at least one processor.
  • the transceiver unit 1510 can transmit and receive signals with other entities.
  • the control unit 1520 may control the overall operation of the electronic device according to the embodiment proposed in this disclosure.
  • the control unit 1520 may control signal flow between each block to perform operations according to the flowchart described above.
  • the control unit 1520 may control, for example, the operation of the second UWB device described with reference to FIGS. 1 to 13.
  • the storage unit 1530 may store at least one of information transmitted and received through the transmitting and receiving unit 1510 and information generated through the control unit 1520.
  • the storage unit 1530 may store information and data necessary for the method described with reference to FIGS. 1 to 13, for example.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (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)
  • Finance (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

본 개시는 UWB 통신을 이용하여 서비스를 제공하는 방법을 개시한다. 본 개시의 일 실시예에 따른 제1 UWB(ultra wide band) 장치의 동작 방법은, 상기 제1 UWB 장치와 제2 UWB 장치 간 결제 서비스(payment service)를 위해 지원되는 결제 방식을 지시하는 UWB 결제 식별 정보(UWB payment identifier), 및 상기 결제 서비스가 수행되는 위치 정보(retail identifier)를 포함하는 광고 메시지(advertisement message)를 상기 제2 UWB 장치로부터 수신하는 동작; 상기 UWB 결제 식별 정보(UWB payment identifier) 및 상기 결제 서비스가 수행되는 위치 정보(retail identifier)에 기반하여 UWB 레인징(ranging)을 수행하는 동작; 및 상기 UWB 레인징 결과에 기반하여 결제 거래(payment transaction)를 수행하는 동작을 포함한다.

Description

초광대역 통신을 이용하여 결제 서비스를 제공하는 방법 및 장치
본 개시는 UWB 통신에 관한 것으로, 보다 상세하게는 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 통신을 이용하여 결제 서비스를 제공하는 방법을 개시한다.
본 개시의 일 실시예에 따른, 제1 UWB(ultra wide band) 장치의 동작 방법은, 상기 제1 UWB 장치와 제2 UWB 장치 간 결제 서비스(payment service)를 위해 지원되는 결제 방식을 지시하는 UWB 결제 식별 정보(UWB payment identifier), 및 상기 결제 서비스가 수행되는 위치 정보(retail identifier)를 포함하는 광고 메시지(advertisement message)를 상기 제2 UWB 장치로부터 수신하는 동작; 상기 UWB 결제 식별 정보(UWB payment identifier) 및 상기 결제 서비스가 수행되는 위치 정보(retail identifier)에 기반하여 UWB 레인징(ranging)을 수행하는 동작; 및 상기 UWB 레인징 결과에 기반하여 결제 거래(payment transaction)를 수행하는 동작을 포함할 수 있다.
일 실시예에 따라, 상기 광고 메시지는 BLE 광고 메시지 포맷(advertisement message format)에 따라 구성될 수 있다. 일 실시예에 따라, 상기 광고 메시지는 UWB 광고 메시지 포맷에 따라 구성될 수 있다.
일 실시예에 따라, 상기 UWB 결제 식별 정보(UWB payment identifier)는, DL-TDoA(Downlink Time Difference of Arrival) 지원을 지시하는 정보, 경쟁-기반 레인징 지원을 지시하는 정보, 인-밴드(in-band) UWB 결제 거래 지원을 지시하는 정보, 및 RFU(reserved future use) 중에서 어느 하나를 포함할 수 있다.
일 실시예에 따라, 상기 결제 서비스가 수행되는 위치 정보(retail identifier)는 상기 결제 서비스가 수행되는 소매점의 명칭 정보 및 상기 소매점의 타입 정보 중에서 적어도 하나를 포함할 수 있다.
일 실시예에 따라, 상기 광고 메시지는 UWB 구성 정보(UWB Configuration)를 더 포함하고, 상기 UWB 구성 정보는, UWB 세션 ID, 서비스 ID, UWB 구성 ID, 채널 번호, 및 장치 역할 중에서 적어도 하나를 포함할 수 있다.
일 실시예에 따라, 상기 제1 UWB 장치의 프레임워크(Framework) 내 결제 프로필 매니저(Payment Profile Manager)는 상기 제1 UWB 장치가 복수의 UWB 레인징 방법들을 동시에 또는 순차적으로 사용하도록 제어할 수 있다.
일 실시예에 따라, 상기 결제 프로필 매니저는 상기 복수의 UWB 레인징 방법들을 처리하기 위한 상태 변이 다이어그램(state transition diagram)을 설정할 수 있다.
일 실시예에 따라, 상기 제1 UWB 장치의 동작 방법은, AoA(angle of arrival) 방위각, AoA 고도 값의 범위, 및 TWR의 결과에 따른 거리 값 중에서 적어도 하나에 기반하여 결제 가능 구역(payment-available zone)을 설정하는 동작을 더 포함할 수 있다.
본 개시의 일 실시예에 따른, 제1 UWB(ultra wide band) 장치는, 송수신기; 및 제어부를 포함한다. 상기 제어부는, 상기 제1 UWB 장치와 제2 UWB 장치 간 결제 서비스(payment service)를 위해 지원되는 결제 방식을 지시하는 UWB 결제 식별 정보(UWB payment identifier), 및 상기 결제 서비스가 수행되는 위치 정보(retail identifier)를 포함하는 광고 메시지(advertisement message)를 상기 제2 UWB 장치로부터 수신할 수 있다. 상기 제어부는, 상기 UWB 결제 식별 정보(UWB payment identifier) 및 상기 결제 서비스가 수행되는 위치 정보(retail identifier)에 기반하여 UWB 레인징(ranging)을 수행할 수 있다. 상기 제어부는, 상기 UWB 레인징 결과에 기반하여 결제 거래(payment transaction)를 수행할 수 있다.
본 개시의 실시예에 따른 방법 및 장치는 UWB 통신을 이용하여 결제 서비스를 제공할 수 있다.
도 1은 본 개시의 일 실시예에 따른 UWB 장치의 예시적인 아키텍쳐를 나타낸다.
도 2는 본 개시의 일 실시예에 따른 UWB 기반 서비스를 지원하는 전자 장치에 포함된 프레임워크의 예시적인 구성을 나타낸다.
도 3a는 본 개시의 일 실시예에 따른 UWB MAC 프레임의 구조를 나타낸다.
도 3b는 본 개시의 일 실시예에 따른 UWB PHY 패킷의 구조를 나타낸다.
도 4는 본 개시의 일 실시예에 따른 레인징 블록 구조의 일 예를 나타낸다.
도 5는 본 개시의 일 실시예에 따른 고객 장치, 판매자 장치, 및 결제 인프라를 포함하는 아키텍쳐를 도시한다.
도 6은 본 개시의 일 실시예에 따른 결제 가능 구역(payment-available zone)의 예시를 나타낸다.
도 7은 본 개시의 일 실시예에 따른 레인징 블록 구조를 설명하기 위한 도면이다.
도 8a 및 도 8b는 본 개시의 일 실시예에 따른 Tap-Free 결제를 위한 장치들의 동작을 설명하기 위한 도면이다.
도 9는 본 개시의 일 실시예에 따른 레인징 동안 결제 거래 데이터 교환 절차를 나타낸다.
도 10은 본 개시의 일 실시예에 따라 데이터 전달 또는 세션을 사용하는 결제 거래 데이터 교환 절차를 나타낸다.
도 11은 본 개시의 일 실시예에 따른 상태 천이 다이아그램의 일 예시를 나타낸다.
도 12는 본 개시의 일 실시예에 따른 결제 절차를 위한 직접 통신의 일 예시를 나타낸다.
도 13은 본 개시의 일 실시예에 따른 결제 절차를 위한 간접 통신의 일 예시를 나타낸다.
도 14는 본 개시의 일 실시예에 따른, 제1 UWB 장치의 구조를 나타낸다.
도 15는 본 개시의 일 실시예에 따른, 제2 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) 단말/디바이스를 포함할 수 있으나, 이에 한정되는 것은 아니다. 본 명세서에서 상기 단말은 전자 장치 또는 단순히 장치라 지칭할 수도 있다.
이하 첨부된 도면을 참조하여 본 개시의 동작 원리를 상세히 설명한다. 하기에서 본 개시를 설명함에 있어 관련된 공지 기능 또는 구성에 대한 구체적인 설명이 본 개시의 요지를 불필요하게 흐릴 수 있다고 판단되는 경우에는 그 상세한 설명을 생략할 것이다. 그리고 후술되는 용어들은 본 개시에서의 기능을 고려하여 정의된 용어들로서 이는 사용자, 운용자의 의도 또는 관례 등에 따라 달라질 수 있다. 그러므로 그 정의는 본 명세서 전반에 걸친 내용을 토대로 내려져야 할 것이다.
이하 본 개시의 실시 예를 첨부한 도면과 함께 상세히 설명한다. 이하에서는 UWB를 이용하는 통신 시스템을 일례로서 본 개시의 실시예를 설명하지만, 유사한 기술적 배경 또는 특성을 갖는 여타의 통신 시스템에도 본 개시의 실시예가 적용될 수 있다. 예를 들어, 블루투스 또는 지그비를 이용하는 통신 시스템 등이 이에 포함될 수 있을 것이다. 따라서, 본 개시의 실시예는 숙련된 기술적 지식을 가진 자의 판단으로써 본 개시의 범위를 크게 벗어나지 아니하는 범위에서 일부 변형을 통해 다른 통신시스템에도 적용될 수 있다.
또한, 본 개시를 설명함에 있어서 관련된 기능 혹은 구성에 대한 구체적인 설명이 본 개시의 요지를 불필요하게 흐릴 수 있다고 판단된 경우 그 상세한 설명은 생략한다. 그리고 후술되는 용어들은 본 개시에서의 기능을 고려하여 정의된 용어들로서 이는 사용자, 운용자의 의도 또는 관례 등에 따라 달라질 수 있다. 그러므로 그 정의는 본 명세서 전반에 걸친 내용을 토대로 내려져야 할 것이다.
일반적으로 무선 센서 네트워크 기술은 인식 거리에 따라 크게 무선랜(Wireless Local Area Network; WLAN) 기술과 무선 사설망(Wireless Personal Area Network; WPAN) 기술로 구분된다. 이때, 무선랜은 IEEE 802.11에 기반한 기술로서, 반경 100m 내외에서 기간망(backbone network)에 접속할 수 있는 기술이다. 그리고, 무선 사설망은 IEEE 802.15에 기반한 기술로서, 블루투스(Bluetooth), 지그비(ZigBee), 초광대역 통신(ultra wide band; UWB) 등이 있다. 이러한 무선 네트워크 기술이 구현되는 무선 네트워크는 복수의 전자 장치들로 이루어질 수 있다.
FCC (Federal Communications Commission)의 정의에 따르면, UWB는 500MHz 이상의 대역폭을 사용하거나, 또는 중심 주파수에 대응하는 대역폭이 20% 이상인 무선통신 기술을 의미할 수 있다. UWB는 UWB 통신이 적용되는 대역 자체를 의미할 수도 있다. UWB는 장치들 간의 안전하고 정확한(secure and accurate) 레인징을 가능하게 한다. 이를 통해, UWB는 두 장치 간의 거리에 기반한 상대적 위치 추정 또는 (위치가 알려진) 고정 장치들로부터의 거리에 기반한 장치의 정확한 위치 추정을 가능하게 한다.
이하의 설명에서 사용되는 특정 용어들은 본 개시의 이해를 돕기 위해서 제공된 것이며, 이러한 특정 용어의 사용은 본 개시의 기술적 사상을 벗어나지 않는 범위에서 다른 형태로 변경될 수 있다.
"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일 수 있다. Controller는 제어 메시지를 전송함으로써 레인징 특징들(ranging features)을 정의 및 제어할 수 있다.
"Controlee"는 Controller로부터 수신된 RCM (또는, 제어 메시지)내의 레인징 파라미터를 이용하는 Ranging Device일 수 있다. Controlee는 Controller로부터 제어 메시지를 통해 설정된 것과 같은 레인징 특징들을 이용할 수 있다.
"Dynamic STS(Scrambled Timestamp Sequence) mode"는 "Static STS"와 달리, STS가 레인징 세션 동안 반복되지 않는 동작 모드일 수 있다. 이 모드에서 STS는 Ranging device에서 관리되고, STS를 생성하는 Ranging Session Key는 Secure Component에 의해 관리될 수 있다.
"Applet"는 예컨대, UWB 파라미터들과 서비스 데이터를 포함하는 Secure Component 상에서 실행되는 applet일 수 있다. Applet은 FiRa Applet일 수 있다.
"Ranging Device"는 UWB 레인징을 수행할 수 있는 장치일 수 있다. 본 개시에서, Ranging Device는 IEEE 802.15.4z에 정의된 Enhanced Ranging Device (ERDEV) 또는 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-enabled Application일 수 있다.
"Framework"는 Profile에 대한 access, 개별 UWB 설정 및/또는 통지를 제공하는 컴포넌트일 수 있다. Framework는 예컨대, Profile Manager, OOB Connector, Secure Service 및/또는 UWB 서비스를 포함하는 논리적 소프트웨어 컴포넌트(logical software components)의 집합(collection)일 수 있다. Framework는 FiRa Framework일 수 있다.
"OOB Connector"는 Ranging Device 간의 OOB(out-of-band) 연결(예컨대, BLE 연결)을 설정하기 위한 소프트웨어 컴포넌트일 수 있다. OOB Connector는 FiRa OOB Connector일 수 있다.
"Profile"은 UWB 및 OOB 설정 파라미터(configuration parameter)의 미리 정의된 세트일 수 있다. Profile은 FiRa Profile일 수 있다.
"Profile Manager"는 Ranging Device에서 이용가능한 프로필을 구현하는 소프트웨어 컴포넌트일 수 있다. Profile Manager는 FiRa Profile Manager일 수 있다.
"Service"는 end-user에 서비스를 제공하는 use case의 implementation일 수 있다.
"Smart Ranging Device"는 옵셔널한 Framework API를 구현할 수 있는 Ranging Device 일 수 있다. Smart Ranging Device는 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일 수 있다. Initiator는 첫 번째 RFRAME (레인징 교환 메시지)를 전송함으로써 레인징 교환을 개시할 수 있다.
"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일 수 있다. Responder는 Initiator로부터 수신된 레인징 교환 메시지에 응답할 수 있다.
"STS"는 레인징 측정 타임스탬프(ranging measurement timestamps)의 무결성 및 정확도(integrity and accuracy)를 증가시키기 위한 암호화된 시퀀스(ciphered sequence)일 수 있다. STS는 레인징 세션 키로부터 생성될 수 있다.
"Secure Channel"는 overhearing 및 tampering을 방지하는 데이터 채널일 수 있다.
"Secure Component"은 예컨대, dynamic STS가 사용되는 경우에, UWBS에 RDS를 제공하기 위한 목적으로 UWBS와 인터페이싱하는 정의된 보안 레벨을 갖는 엔티티(예컨대, SE (Secure Element) 또는 TEE(Trusted Execution Environment))일 수 있다.
"SE"는 Ranging Device 내 Secure Component로서 사용될 수 있는 tamper-resistant secure hardware component일 수 있다.
"Secure Ranging"은 강한 암호화 동작을 통해 생성된 STS에 기초한 레인징일 수 있다.
"Secure Service"는 Secure Element 또는 TEE와 같은 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는 STS를 생성하기 위해 사용될 수 있다. UWB Session Key는 UWB Ranging Session Key(URSK)일 수 있고, 세션 키로 약칭될 수 있다.
"UWB Subsystem(UWBS)"는 UWB PHY 및 MAC 레이어(스펙)를 구현하는 하드웨어 컴포넌트일 수 있다. UWBS는 Framework에 대한 인터페이스 및 RDS를 검색하기 위한 Secure Component에 대한 인터페이스를 가질 수 있다.
“UWB 메시지”는 UWB 장치(예컨대, ERDEV)에 의해 전송되는 payload IE(information element)를 포함하는 메시지일 수 있다.
"Payload IE”는 UWB MAC frame의 MAC payload에 포함되는 IE일 수 있다. MAC payload는 하나 또는 복수 개의 Payload IE를 포함할 수 있다.
“스케쥴링 기반 레인징(scheduled based ranging)”은 컨트롤리들이 상이한 레인징 슬롯에서 레인징 프레임(RFRAME) 및/또는 측정 리포트를 전송하기 위해 컨트롤러에 의해 스케쥴링되는 레인징 라운드를 위해 사용될 수 있다. 스케쥴링 기반 레인징은 Time-scheduled ranging으로 지칭될 수도 있다. 스케쥴링 기반 레인징이 사용되는 스케쥴링 모드(Scheduling Mode)는 Time-scheduled mode로 지칭될 수 있다.
“경쟁 기반 레인징(contention based ranging)”은 컨트롤러가 UWB 세션(레인징 세션)에 참여하는 컨트롤리들의 MAC address를 알지 못하는 경우에 사용될 수 있다. 경쟁 기반 레인징에서, 컨트롤러는 initiator일 수 있고, 다른 모르는(unknown) UWB 장치와 레인징을 수행할 수 있다. 경쟁 기반 레인징이 사용되는 스케쥴링 모드는 Contention-based mode로 지칭될 수 있다.
경쟁 기반 레인징은 컨트롤러가 경쟁 접속 기간(Contention Access Period: CAP)의 사이즈를 결정하고, 레인징 제어 메시지를 통해 CAP 사이즈를 알려주는 레인징 라운드에 대해 사용될 수 있다. CAP는 경쟁 윈도우 또는 경쟁 윈도우 기간으로 지칭될 수 있다.
Contention-based mode에서, UWB 장치가 컨트롤러 및 initiator로 동작할 수 있고, 이 경우, 레인징 제어 단계(ranging control phase: RCP)와 레인징 개시 단계(ranging initiation phase: RIP)는 하나의 단계(예컨대, RIP)로 병합될 수 있다. 레인징 단계(ranging phase: RP)에서 CAP 사이즈의 할당은 해당 레인징 라운드에 참여하는 responder(들)을 위한 CAP 기간을 레인징 슬롯 단위로 결정할 수 있다. 각 responder는 레인징 응답 메시지(ranging response message: RRM)을 전송하기 위해 CAP 내에서 한 슬롯을 랜덤하게 결정할 수 있다. 경쟁 기반 레인징에서 사용되는 메시지들은 SP1을 RFRAME 설정으로 사용할 수 있다.
“하이브리드 레인징(hybrid ranging)”는 알고 있는(known) 컨트롤리와, 모르는(unknown) 컨트롤리가 있는 경우에 사용될 수 있다. 상술한 것처럼, known 컨트롤리는 컨트롤러가 컨트롤리의 MAC address를 알고 있는 컨트롤리일 수 있고, unknown 컨트롤리는 컨트롤러가 컨트롤리의 MAC address를 모르는 컨트롤리일 수 있다. 하이브리드 레인징은 하이브리드 기반 레인징으로 지칭될 수 있다. 하이브리드 레인징이 사용되는 스케쥴링 모드는 Hybrid-based Mode로 지칭될 수 있다.
Hybrid-based Mode에서, 컨트롤러는 known 컨트롤리와는 스케쥴링 기반 모드로, 그리고, unknown 컨트롤리와는 경쟁 기반 모드로 레인징을 수행할 수 있다.
Hybrid-based Mode에서, 레인징 라운드는 레인징 제어 단계(RCP) 및 레인징 단계(RP)를 포함할 수 있다. RP는 스케쥴링 기반 레인징(접속)을 위한 경쟁 프리 기간(contention free period: CFP) 및 경쟁 기반 레인징(접속)을 위한 경쟁 접속 기간(CAP)을 포함할 수 있다. Hybrid-based Mode의 RCP에서 사용되는 제어 메시지(레인징 제어 메시지)는 레인징 관리 메시지(Ranging Management Message: RMM)로 지칭될 수 있다.
“Downlink Time Difference of Arrival(DL-TDoA: DT)”는 하나 또는 복수 개의 태그 장치(DT-Tag)가 적어도 하나 이상의 앵커 장치(DT-anchor)로부터 수신된 DL-TDoA 메시지(DTM)에 기초하여 자신의 위치를 추정하는 포지셔닝 방법일 수 있다. DL-TDoA에서, 앵커 장치는 DTM을 전송 또는 브로드캐스트하고, 태그 장치는 수동적으로 DTM을 수신함으로써, 태그 장치의 위치가 노출되는 것을 방지할 수 있다.
DL-TDoA에서, 앵커 장치는 스스로의 DTM 전송 시간과 수신된 DTM의 수신 시간을 정밀하게(precisely) 측정할 수 있다. 앵커 장치는 전송 또는 브로드캐스트하는 DTM에 전송 시간을 포함시킬 수 있다. 태그 장치는 수신하는 모든 DTM의 수신 시간을 측정하고 수신 타임스탬프와 획득한 앵커 장치들의 좌표들을 활용하여 자신의 위치를 추정할 수 있다. DL-TDoA는 Uplink TDoA와 같이 one way ranging의 일종으로 분류될 수도 있다. DL-TDoA는 DL-TDoA localization으로 지칭될 수 있다.
"Anchor device"는 측위 서비스를 제공하기 위해 특정 위치에 배치된 UWB 장치일 수 있다. 예를 들면, 앵커 장치는 실내 측위 서비스를 제공하기 위해서 서비스 제공자가 실내의 벽, 천장, 구조물 등에 설치한 UWB 장치일 수 있다. DL-TDoA에서, 앵커 장치는 태그 장치가 TDoA localization(DL-TDoA localization)를 기반으로 위치를 계산하는 데 사용할 수 있는 DTM을 전송하는 장치일 수 있다. DL-TDoA에서, 앵커 장치는 메시지를 송신하는 순서와 역할에 따라서 Initiator 앵커, Responder 앵커로 구분되어 레인징 라운드에 참여할 수 있다. 앵커 장치는 UWB 앵커, UWB 앵커 장치로 지칭될 수 있고, DL-TDoA의 앵커 장치는 DL-TDoA 앵커, DT-anchor로 지칭될 수 있다.
"Initiator anchor"는 TDoA 레인징 라운드 (DL-TDoA 레인징 라운드)의 개시를 알릴 수 있다. DL-TDoA에서, Initiator anchor는 개시 메시지를 전송함으로써, DL-TDoA 레인징 라운드를 개시할 수 있고, Responder 앵커(들)의 전송 시간을 스케쥴링할 수 있다. 예를 들면, Initiator 앵커는 동일한 레인징 라운드에서 동작하는 Responder 앵커(들)이 응답 메시지(response DTM) 하는 레인징 슬롯을 스케줄링할 수 있다. 개시 메시지는 Initiator DTM, Poll 메시지, Poll DTM, 제1 DTM 등으로 지칭될 수 있다. Initiator anchor는 Initiator UWB 앵커, Initiator 앵커 장치, initiator DT-anchor 등으로 지칭될 수 있으며,
Initiator 앵커는 Responder 앵커(들)의 응답을 수신한 후 종료 메시지(Final DTM)를 추가로 전달할 수도 있다. Initiator 앵커는 동일한 클러스터의 모든 Responder anchor가 DL-TDoA 레인징 라운드에서 응답 메시지(response DTM)을 전송한 후 Final DTM을 추가로 전송할 수 있다. 종료 메시지는 Final DTM, 제3 DTM 등으로 지칭될 수 있다.
DL-TDoA 네트워크에는 최소한 하나의 기준(reference) initiator 앵커가 있을 수 있다. Reference initiator 앵커는 initiator 앵커로 클러스터 간 동기화(inter-cluster synchronization)를 위한 글로벌 시간 참조 역할을 하며, DL-TDoA 네트워크가 작동하기 위한 공통의 레인징 블록 구조를 설정할 수 있다. Reference initiator 앵커는 마스터 앵커, 글로벌 앵커로 지칭될 수 있다.
"Responder anchor"는 Initiator 앵커의 개시 메시지에 응답하는 UWB 앵커일 수 있다. Responder 앵커는 응답 메시지를 이용하여 Initiator 앵커에 응답할 수 있다. 응답 메시지는 Responder DTM, Response DTM, 제2 DTM 등으로 지칭될 수 있다. Responder anchor는 Responder UWB 앵커, Responder UWB 앵커 장치, Responder 앵커 장치 등으로 지칭될 수 있다.
“Tag device”는 DL-TDoA에서 앵커 장치로부터 수신한 DTM을 기반으로 TDoA 측정을 사용하여 자신의 위치(예컨대, geographical coordinates)를 추정할 수 있다. 태그 장치는 앵커 장치의 위치를 미리 알고 있을 수 있다. Tag 장치는 UWB 태그, 사용자 장치, UWB 태그 장치로 지칭될 수 있고, DL-TDoA의 태그 장치는 DL-TDoA Tag, DT-Tag로 지칭될 수 있다.
태그 장치는 앵커 장치에 의해 전송된 메시지를 수신하고, 메시지의 수신 시간을 측정할 수 있다. 태그 장치는 in-band 도는 out-band 방법을 통해 앵커 장치의 지리적 좌표를 획득할 수 있다. 태그 장치는 위치 업데이트 속도가 네트워크에서 지원하는 것보다 낮은 경우 레인징 블록을 스킵할 수 있다.
"Cluster"(클러스터)는 특정 영역을 커버하는 앵커 장치의 집합을 의미할 수 있다. DL-TDoA에서, 클러스터는 적어도 하나의 태그 장치에 위치 서비스를 제공하기 위하여 DTM을 교환하는 앵커 장치의 집합을 의미할 수 있다. 클러스터는 Initiator 앵커와 적어도 하나의 Responder 앵커들로 구성될 수 있다.
하나의 앵커 장치는 하나 이상의 클러스터에서 동작할 수 있다. 이러한 경우, 일부 클러스터에서 Initiator 앵커로 작동하는 앵커 장치가 다른 클러스터에서는 Responder 앵커로 작동할 수 있다. 클러스터의 영역은 클러스터를 구성하는 앵커 장치들이 이루는 공간일 수 있다. 넓은 영역에 대한 측위 서비스를 지원하기 위해서 복수 개의 클러스터를 구성하여 사용자 장치에 측위 서비스를 제공할 수 있다. 클러스터는 셀(cell)로 지칭될 수도 있다.
“AoA”는 수신 신호의 도달 각도로서, AoA azimuth 및 AoA elevation와 같은 상대적인 각도로 표현될 수 있다. 예컨대, 측정 장치가 디스플레이를 갖는 모바일 폰이고, Y 축이 상기 폰의 수직 디스플레이 축(vertical display axis)이고, X 축이 상기 폰의 수평 디스플레이 축(horizontal display axis)이고, Z 축이 폰 디스플레이에 직교한다고 가정될 수 있다. 이 경우, AoA azimuth 각도는 XZ 평면 상에 투영된(projected) 입력 신호와 Z 축 사이의 상대적인 각도일 수 있고, AoA elevation 각도는 입력 신호와 XZ 평면 사이의 상대적인 각도일 수 있다.
TWR의 경우, 컨트롤러(initiator)는 RRM에 대한 AoA azimuth를 측정할 수 있고, UCI 통지 메시지를 통해 측정된 AoA azimuth를 전송할 수 있다. 컨트롤리(responder)는 RIM 메시지에 대한 AoA azimuth를 측정할 수 있고, RRRM을 통해 측정된 AoA azimuth를 전송할 수 있다.
TWR의 경우, 컨트롤러(initiator)는 RRM에 대한 AoA elevation을 측정할 수 있고, UCI 통지 메시지를 통해 측정된 AoA elevation을 전송할 수 있다. 컨트롤리(responder)는 RIM 메시지에 대한 AoA elevation을 측정할 수 있고, RRRM을 통해 측정된 AoA elevation을 전송할 수 있다.
OWR의 경우, Observer는 AoA 측정 메시지에 대한 AoA azimuth 및 AoA elevation을 측정할 수 있다.
“데이터 메시지 페이로드 IE (Data Message Payload Information Element, DM Payload IE) ”는 애플리케이션, 애플릿 또는 기타 데이터 소스로부터 생성된 데이터를 UWB 메시지에 포함시켜 전송하기 위해 사용되는 페이로드 IE (Payload IE)일 수 있다. 본 개시에서 데이터 메시지 페이로드 IE는 간단하게 데이터 메시지라고도 불릴 수 있다. 데이터 메시지 페이로드 IE는 도 23과 같이 레인징 페이로드 IE (Ranging Payload IE)와 결합하여 UWB 메시지의 PHY Payload의 일부가 될 수 있다.
데이터 메시지 페이로드 IE는 Vendor OUI, UWB 메시지 식별자 (UWB Message Identifier, UWB Message ID), 데이터 메시지 타입 (Data Message Type, DM Type), 컨텐츠 필드로 구성되거나 그 일부를 포함할 수 있다.
데이터 메시지 타입에 따라서 컨텐트 (Content) 필드 내 포함되는 메시지의 내용이 달라질 수 있다. 데이터 메시지 타입 (DM Type) 필드의 값이 0x0 인 경우, 컨텐트 필드는 일반적인 애플리케이션 데이터를 포함할 수 있다. 컨텐트 필드는 전달되는 애플리케이션 데이터의 길이를 추가로 포함할 수도 있다. 컨텐트 필드는 UWB Subsystem의 MAC 레이어 상위에서 생성되어 MAC으로 전달되는 데이터인 MAC Data Service Data Unit (MDSDU)를 Payload로써 포함할 수도 있다.
데이터 메시지 페이로드 IE의 데이터 메시지 타입 (DM Type) 필드의 값이 0x1인 경우, 컨텐트 (content) 필드는 Data Transfer Phase Control Message (DTPCM)을 포함할 수 있다.
그리고, 본 개시를 설명함에 있어서, 관련된 공지기능 또는 구성에 대한 구체적인 설명이 본 개시의 요지를 불필요하게 흐릴 수 있다고 판단된 경우, 그 상세한 설명은 생략한다.
이하 첨부된 도면을 참고하여 본 개시의 다양한 실시예들을 설명한다.
도 1은 본 개시의 일 실시예에 따른 UWB 장치의 예시적인 아키텍쳐를 나타낸다.
UWB 장치(100)는 UWB 통신을 지원하는 전자 장치일 수 있다. UWB 장치(100)는 예컨대, UWB 레인징을 지원하는 Ranging Device일 수 있다. 일 실시예에서, Ranging Device는 IEEE 802.15.4z에 정의된 Enhanced Ranging Device (ERDEV) 또는 FiRa Device일 수 있다.
도 1의 실시예에서, UWB 장치(100)는 UWB 세션을 통해 다른 UWB 장치와 상호작용(interact)할 수 있다.
또한, UWB 장치(100)는 UWB-enabled Application(110)과 UWB Framework(120) 간의 인터페이스인 제1 인터페이스(Interface #1)를 구현할 수 있고, 제1 인터페이스는 UWB 장치(100) 상의 UWB-enabled application(110)이 미리 정해진 방식으로 UWB 장치(100)의 UWB 성능들을 사용할 수 있게 해준다. 일 실시예에서, 제1 인터페이스는 Framework API 또는 proprietary interface일 수 있으나, 이에 한정되지 않는다.
또한, UWB 장치(100)는 UWB Framework(110)와 UWB 서브시스템(UWBS)(130) 간의 인터페이스인 제2 인터페이스(Interface #2)를 구현할 수 있다. 일 실시예에서, 제2 인터페이스는 UCI(UWB Command Interface) 또는 proprietary interface일 수 있으나, 이에 한정되지 않는다.
도 1을 참조하면, UWB 장치(100)는 UWB-enabled Application(110), Framework(UWB Framework)(120), 및/또는 UWB MAC Layer와 UWB Physical Layer를 포함하는 UWBS(130)를 포함할 수 있다. 실시예에 따라서는, 일부 엔티티가 UWB 장치에 포함되지 않거나, 추가적인 엔티티(예컨대, 보안 레이어)가 더 포함될 수 있다.
UWB-enabled Application(110)은 제1 인터페이스를 이용하여 UWBS(130)에 의한 UWB 세션의 설정을 트리거링할 수 있다. 또한, UWB-enabled Application(110)은 미리 정의된 프로필(profile) 중 하나를 사용할 수 있다. UWB-enabled Application(110)은 제1 인터페이스를 사용하여, 서비스 발견(Service discovery), 레인징 통지(Ranging notifications), 및/또는 에러 컨디션(Error conditions)과 같은 관련 이벤트를 다룰 수 있다.
Framework(120)는 Profile에 대한 access, 개별 UWB 설정 및/또는 통지를 제공할 수 있다. 또한, Framework(120)는 UWB 레인징 및 트랜잭션 수행을 위한 기능, 어플리케이션 및 UWBS(130)에 대한 인터페이스 제공 기능 또는 장치(100)의 위치 추정 기능과 같은 기능 중 적어도 하나를 지원할 수 있다. Framework(120)는 소프트웨어 컴포넌트의 집합일 수 있다. 상술한 것처럼, UWB-enabled Application(110)은 제1 인터페이스를 통해 프레임워크(120)와 인터페이싱할 수 있고, 프레임워크(120)는 제2 인터페이스를 통해 UWBS(130)와 인터페이싱할 수 있다.
한편, 본 개시에서, UWB-enabled Application(110) 및/또는 Framework(120)는 어플리케이션 프로세서(AP)(또는, 프로세서)에 의해 구현될 수 있다. 따라서, 본 개시에서, UWB-enabled Application(110) 및/또는 Framework(120)의 동작은 AP(또는, 프로세서)에 의해 수행되는 것으로 이해될 수 있다. 본 개시에서, 프레임워크는 AP, 프로세서로 지칭될 수 있다.
UWBS(130)는 UWB MAC Layer와 UWB Physical Layer를 포함하는 하드웨어 컴포넌트일 수 있다. UWBS(130)는 UWB 세션 관리를 수행하고, 다른 UWB 장치의 UWBS와 통신할 수 있다. UWBS(130)는 제2 인터페이스를 통해 Framework(120)와 인터페이싱할 수 있고, Secure Component로부터 보안 데이터를 획득할 수 있다. 일 실시예에서, Framework(또는, 어플리케이션 프로세서)(120)는 UCI를 통해서 명령(command)을 UWBS(130)로 전송할 수 있고, UWBS(130)는 명령에 대한 응답(response)를 Framework(120)에 전달할 수 있다. UWBS(130)는 UCI를 통해 Framework(120)에 통지(notification)을 전달할 수도 있다.
도 2는 본 개시의 일 실시예에 따른 UWB 기반 서비스를 지원하는 전자 장치에 포함된 프레임워크의 예시적인 구성을 나타낸다.
도 2의 프레임워크(200)는 도 1의 UWB 프레임워크(120)의 일 예일 수 있다. 도 2의 프레임워크(200)는 예컨대, FiRa Framework일 수 있다.
프레임워크(200)는 논리적 소프트웨어 컴포넌트(logical software component)의 집합일 수 있다. UWB-enabled Application는 프레임워크(200)에 의해 제공되는 프레임워크 API를 통해 프레임워크와 인터페이싱할 수 있다.
도 2을 참조하면, 프레임워크(200)는 Profile Manger(210), OOB Connector(220), Secure Service(230) 및/또는 UWB Service(240)를 포함할 수 있다. 다만, 실시예에 따라 일부 컴포넌트가 생략되거나, 추가적인 컴포넌트를 더 포함할 수 있다.
Profile Manger 컴포넌트(210)는 Ranging Device(UWB 장치) 상에서 이용가능한 Profile(s)을 관리할 수 있다. Profile은 Ranging Device(UWB 장치) 사이에 성공적인 UWB 세션을 설정(establish)하기 위해 요구되는 파라미터들의 집합일 수 있다. 예를 들면, 프로필은 어떤 보안 채널(예컨대, OOB 보안 채널)이 사용되는지를 나타내는 파라미터, UWB/OOB 설정 파라미터, 특정 보안 컴포넌트의 사용이 맨데토리(mandatory)인지를 나타내는 파라미터 및/또는 ADF의 파일 구조와 관련된 파라미터를 포함할 수 있다. 또한, Profile Manger는 UWB-enabled Application로부터의 UWB 및 OOB 구성 파라미터를 추상화할 수 있다.
OOB Connector 컴포넌트(220)는 Ranging Device(UWB 장치) 사이의 OOB 연결을 설정하기 위한 컴포넌트일 수 있다.
Secure Service 컴포넌트(230)는 Secure Element (SE) 또는 Trusted Execution Environment (TEE)와 같은 보안 컴포넌트와 인터페이싱하는 역할을 수행할 수 있다. 보안 컴포넌트는 UWBS에 UWB 레인징 데이터를 전달하기 위해 UWBS와 인터페이싱하는 컴포넌트일 수 있다.
UWB Service 컴포넌트(240)는 UWBS에 대한 액세스를 제공하는 컴포넌트일 수 있다.
도 3a는 본 개시의 일 실시예에 따른 UWB MAC 프레임의 구조를 나타낸다.
도 3a의 실시예에서, UWB MAC 프레임은 MAC 프레임 또는 프레임으로 약칭될 수 있다. 실시예로서, UWB MAC 프레임은 UWB 관련 데이터(예컨대, UWB 메시지, 레인징 메시지, 제어 정보, 서비스 데이터, 어플리케이션 데이터 등)를 전달하기 위해 사용될 수 있다.
도 3a를 참조하면, UWB MAC 프레임은 MAC 헤더(MHR), MAC 페이로드 및/또는 MAC footer(MFR)를 포함할 수 있다.
(1) MAC 헤더
MAC 헤더는 Frame Control 필드, Sequence Number 필드, Destination Address 필드, Source Address 필드, Auxiliary Security Header 필드, 및/또는 적어도 하나의 Header IE 필드를 포함할 수 있다. 실시예에 따라서, 상술한 필드들 중 일부가 MAC 헤더에 포함되지 않을 수도 있고, 추가적인 필드(들)이 MAC 헤더에 더 포함될 수도 있다.
일 실시예에서, Frame Control 필드는 Frame Type 필드, Security Enabled 필드, Frame Pending 필드, AR 필드(Ack Request 필드), PAN ID Compression 필드(PAN ID Present 필드), Sequence Number Suppression 필드, IE Present 필드, Destination Addressing Mode 필드, Frame Version 필드, 및/또는 Source Addressing Mode 필드를 포함할 수 있다. 실시예에 따라서, 상술한 필드들 중 일부가 Frame Control 필드에 포함되지 않을 수도 있고, 추가적인 필드(들)이 Frame Control 필드에 더 포함될 수도 있다.
각 필드에 대한 설명은 다음과 같다.
Frame Type 필드는 프레임의 타입을 지시할 수 있다. 실시예로서, 프레임의 타입은 data 타입 및/또는 Multipurpose 타입을 포함할 수 있다.
Security Enabled 필드는 Auxiliary Security Header 필드가 존재하는지를 지시할 수 있다. Auxiliary Security Header 필드는 security processing을 위해 요구되는 정보를 포함할 수 있다.
Frame Pending 필드는 프레임을 전송하는 장치가 수신자(recipient)를 위한 더 많은 데이터를 가지고 있는지 여부를 지시할 수 있다. 즉, Frame Pending 필드는 수신자를 위한 pending frame이 있는지를 알려줄 수 있다.
AR 필드(Ack Request 필드)는 프레임의 수신에 대한 acknowledgment이 수신자로부터 요구되는지를 지시할 수 있다.
PAN ID Compression 필드(PAN ID Present 필드)는 PAN ID 필드가 존재하는지를 지시할 수 있다.
Sequence Number Suppression 필드는 Sequence Number 필드가 존재하는지를 지시할 수 있다. Sequence Number 필드는 프레임에 대한 시퀀스 식별자를 지시할 수 있다.
IE Present 필드는 Header IE 필드 및 Payload IE 필드가 프레임에 포함되는지를 지시할 수 있다.
Destination Addressing Mode 필드는 Destination Address 필드가 short address (예컨대, 16 비트)를 포함하는지 또는 extended address (예컨대, 64 비트)를 포함하는지를 지시할 수 있다. Destination Address 필드는 프레임의 수신자(recipient)의 주소를 지시할 수 있다.
Frame Version 필드는 프레임의 버전을 지시할 수 있다. 예컨대, Frame Version 필드는 IEEE std 802.15.4z-2020를 지시하는 값으로 설정될 수 있다.
Source Addressing Mode 필드는 Source Address 필드가 존재하는지 여부, 및 Source Address 필드가 존재하는 경우, Source Address 필드가 short address (예컨대, 16 비트)를 포함하는지 또는 extended address (예컨대, 64 비트)를 포함하는지를 지시할 수 있다. Source Address 필드는 프레임의 발신자(originator)의 주소를 지시할 수 있다.
(2) MAC 페이로드
MAC 페이로드는 적어도 하나의 Payload IE 필드를 포함할 수 있다. 일 실시예에서, Payload IE 필드는 Vendor Specific Nested IE를 포함할 수 있다.
(3) MAC 푸터(footer)
MAC footer는 FCS 필드를 포함할 수 있다. FCS 필드는 16 비트의 CRC 또는 32 비트의 CRC를 포함할 수 있다.
도 3b는 본 개시의 일 실시예에 따른 UWB PHY 패킷의 구조를 나타낸다.
도 3b의 파트 (a)는 STS 패킷 설정이 적용되지 않은 UWB PHY 패킷의 예시적인 구조를 나타내고, 도 4의 파트 (b)는 STS 패킷 설정이 적용된 UWB PHY 패킷의 예시적인 구조를 나타낸다. UWB PHY 패킷은 PHY 패킷, PHY PDU(PPDU), 프레임으로 지칭될 수 있다.
도 3b의 파트 (a)를 참조하면, PPDU는 동기 헤더(SHR), PHY 헤더(PHR) 및 PHY 페이로드(PSDU)를 포함할 수 있다. PSDU는 MAC 프레임을 포함하고, 도 4에서와 같이, MAC 프레임은 MAC 헤더(MHR), MAC 페이로드 및/또는 MAC footer(MFR)를 포함할 수 있다. 동기 헤더 부분(part)은 프리앰블로 지칭될 수 있고, PHY 헤더 및 PHY 페이로드를 포함하는 부분은 데이터 부분으로 지칭될 수 있다.
동기 헤더는 신호 수신을 위한 동기화에 사용되며, SYNC 필드 및 SFD(start-of-frame delimiter)를 포함할 수 있다.
SYNC 필드는 송/수신 장치 간의 동기화를 위해 사용되는 복수의 프리앰블 심볼을 포함하는 필드일 수 있다. 프리앰블 심볼은 미리 정의된 프리앰블 코드들 중 하나를 통해 설정될 수 있다.
SFD 필드는 SHR의 끝(end) 및 데이터 필드의 시작을 지시하는 필드일 수 있다.
PHY 헤더는 PHY 페이로드의 구성에 대한 정보를 제공할 수 있다. 예를 들면, PHY 헤더는 PSDU의 길이에 대한 정보, 현재 프레임이 RFRAME인지(또는, Data Frame인지)를 지시하는 정보 등을 포함할 수 있다.
한편, UWB 장치의 PHY 레이어는 높은 density/낮은 전력 동작을 위해 감소된 on-air time을 제공하기 위한 옵셔널 모드를 포함할 수 있다. 이 경우, UWB PHY 패킷은 레인징 측정 타임스탬프의 integrity 및 accuracy를 증가시키기 위한, 암호화된 시퀀스(즉, STS)를 포함할 수 있다. STS는 UWB PHY 패킷의 STS 필드에 포함될 수 있고, 보안 레인징을 위해 사용될 수 있다.
도 3b의 파트 (b)를 참조하면, STS 패킷(SP) 설정 0인 경우(SP0), STS 필드는 PPDU에 포함되지 않는다(SP0 패킷). SP 설정 1인 경우(SP1), STS 필드는 STS는 SFD(Start of Frame Delimiter) 필드의 바로 뒤 및 PHR 필드의 앞에 위치된다(SP1 패킷). SP 설정 2인 경우(SP2), STS 필드는 PHY 페이로드 뒤에 위치된다(SP2 패킷). SP 설정 3인 경우(SP3), STS 필드는 SFD 필드 바로 뒤에 위치되고, PPDU는 PHR 및 데이터 필드(PHY 페이로드)를 포함하지 않는다(SP3 패킷). 즉, SP3의 경우, PPDU는 PHR 및 PHY 페이로드를 포함하지 않는다.
도 3b의 파트 (b)에 도시된 것처럼, 각 UWB PHY 패킷은 기준 시간을 정의하기 위한 RMARKER를 포함할 수 있고, RMARKER는 UWB 레인징 절차에서 레인징 메시지(프레임)의 송신 시간, 수신 시간 및/또는 시간 구간을 획득하기 위해 사용될 수 있다.
도 4는 본 개시의 일 실시예에 따른 레인징 블록 구조의 일 예를 나타낸다.
도 4를 참조하면, 하나의 레인징 블록은 적어도 하나의 레인징 라운드를 포함하고, 각 레인징 라운드는 적어도 하나의 레인징 슬롯을 포함할 수 있다. 예를 들면, 도시된 것처럼, 하나의 레인징 블록은 N 개의 레인징 라운드(예: 레인징 라운드 0 내지 레인징 라운드 인덱스 N-1)를 포함하고, 레인징 라운드 #0은 M개의 레인징 슬롯(예: 레인징 슬롯 0 내지 레인징 슬롯 M)을 포함할 수 있다.
레인징 블록은 레인징을 위한 time period를 지칭한다. 레인징 라운드는 레인징 교환에 참여하는 레인징 장치들의 세트가 관여하는 하나의 전체 레인징-측정 사이클(entire range-measurement cycle)(레인징 사이클)을 완성하기 위한 충분한 기간(period of sufficient duration)일 수 있다. 레인징 슬롯은 적어도 하나의 레인징 프레임(RFRAME)(예컨대, 레인징 개시/응답/파이널 메시지 등)의 전송을 위한 충분한 기간일 수 있다.
한편, 레인징 모드가 block-based mode인 경우, 연속된 레인징 라운드 사이의 평균 시간(mean time)은 상수(constant)일 수 있다. 또는, 레인징 모드가 interval-based mode 인 경우, 연속된 레인징 라운드 사이의 시간은 동적으로 변경될 수 있다. 즉, interval-based mode는 adaptive한 간격(spacing)을 갖는 시간 구조를 채택할 수 있다.
레인징 블록은 블록으로, 레인징 라운드는 라운드로, 레인징 슬롯은 슬롯으로 약칭될 수 있다.
본 개시에서는 (FiRa consortium 에서 정의하는) 적어도 하나의 UWB 레인징 방법(ranging method)를 사용하여 탭-프리 결제 서비스(tap-free payment service)를 지원하기 위한 상위 레이어의 동작을 제안한다.
일 실시예에 따라, 상기 UWB 레인징 방법은, 시간-스케줄링 TWR 레인징(Time-scheduled two way ranging), 경쟁-기반 TWR(Contention-based two way ranging), OWR(One-way ranging) downlink tdoa (time difference of arrival) 레인징 방법, OWR uplink tdoa 레인징 방법, AoA 측정 레인징 방법(measurement ranging method)을 위한 OWR, 하이브리드 레인징(Hybrid ranging), 레인징 동안 데이터 전송(Data transfer during ranging), 및 데이터 전송 단계(Data transfer phase) 중에서 어느 하나로 구현될 수 있다.
탭-프리 결제 서비스(tap-free payment service)는, IC(Integrated Circuit) 카드나 NFC(Near Field Communication)와 같은 접촉-기반(contact-based) 또는 접촉이 없는 결제(contactless payment)가 아닌, UWB 레인징 결과 값을 기반으로 고객 단말(Customer Device)(또는 사용자 단말)과 판매자 단말(Merchant Device)(또는 점원 단말)이 서로의 거리를 인지하고, 소정의 인증 절차를 거친 후, UWB 채널을 통해 직접 결제 또는 온라인 결제(인 앱, in-app 결제)를 위한 데이터 교환을 하여 결제를 수행하는 서비스를 지칭할 수 있다.
고객 단말(Customer Device)은 매장을 방문하는 고객의 UWB 지원 장치로, 본 개시의 실시예들에 따른 탭-프리 결제 서비스를 운영하는 데 필요한 기능을 구현할 수 있다. 결제 어플리케이션(Payment Application)은 탭-프리 결제 서비스를 위해 고객 단말에 설치된 어플리케이션일 수 있다.
결제 애플릿(Payment Applet)은 탭-프리 결제 서비스를 위한 보안 요소(Secure Element)에서 실행되는 애플릿일 수 있다.
결제 인프라(Payment Infrastructure)는 OOB(out of band) 및 UWB 기능이 가능한 매장에 배포된 인프라일 수 있다. 상기 결제 인프라는 고객 단말이 결제 거래를 수행할 수 있는 백엔드 결제 서버(backend payment server)와 연동될 수 있다.
판매자 단말(Merchant Device)은 UWB 기능을 지원하며 PoS(Point of Sale) 기능을 구비하는 UWB 지원 장치일 수 있다.
본 개시에서 제안하는 (실시예 1) 내지 (실시예 4)는 다음과 같다.
(실시예 1) 복수의 UWB 레인징 방법(ranging method)을 동시에 또는 순차적으로 사용하여 UWB를 이용한 판매자 단말(또는 점원 단말)과 고객 단말(또는 사용자 단말) 사이의 발견 과정(discovery); 판매자 단말과 고객 단말이 UWB 레인징 또는 UWB 시큐어 레인징(secure ranging)을 수행하는 과정; UWB 채널을 통한 결제 프로토콜을 수행하는 과정;
- 상기 과정을 수행하는 1) 고객 단말, 2) 점원 단말, 3) 매장의 UWB 인프라
- 상기 기능을 지원하는 기능들이 구현된 고객 단말(또는 사용자 단말)의 FiRa 프레임워크(Framework) 내 결제 프로필 매니저(Payment Profile Manager); 결제 프로필 매니저(Payment Profile Manager)는 고객 단말 또는 판매자 단말의 어플리케이션 또는 OS(operating system) 내에 구현될 수 있다. 결제 프로필 매니저(Payment Profile Manager)는 UWBS에 명령어를 전달할 수 있는 객체 또는 그 상위 객체일 수 있다.
- 상기 복수의 UWB 레인징 방법을 처리하는 기능은 상태 변이 다이어그램(state transition diagram) 형태로 결제 프로필 매니저(Payment Profile Manager) 또는 그 상위 레이어의 어플리케이션에서 관리 및/또는 수행될 수 있다.
(실시예 2) 결제 가능 구역(payment-available zone)을 정의하는 방법; 및 상기 결제 가능 구역을 고객 단말 및/또는 판매자 단말에 설정 및 활용하는 방법.
- 상기 결제 가능 구역은 판매자 단말과 고객 단말 간의 UWB 레인징을 통해 측정된 거리와 측정된 AoA (Angle of Arrival)을 기반으로 정의될 수 있다.
(실시예 3) 매장 내 복수의 판매자 단말들과 복수의 UWB 앵커들을 하나의 레퍼런스 UWB 세션을 기준으로 정렬하여 복수의 UWB 세션 간 간섭을 최소화하는 방법.
(실시예 4) 서비스 식별을 위한 결제 서비스(payment service) 식별자, 및 매장 정보 제공을 위한 매장 식별자 (retail identifier) 설정.
- 결제 서비스(Payment service) 식별자는 결제 프로필 매니저(Payment Profile Manager)가 관리하는 복수의 UWB 레인징 방법의 리스트와 이들로 구성된 상태 천이 다이어그램(state transition diagram)을 지칭하는 식별자일 수 있다.
FiRa Tap-Free 결제 프로필의 주요 목적은 Tap-Free 결제 서비스를 지원하는 필수 UWB 기능 및 OOB 메커니즘 세트를 포함한 기술 솔루션을 제공하는 점이다.
도 5는 본 개시의 일 실시예에 따른 고객 장치, 판매자 장치, 및 결제 인프라를 포함하는 아키텍쳐를 도시한다.
도 5를 참조하면, 아키텍쳐(500)는 고객 장치(510), 결제 게이트웨이(520), 결제 네트워크(530), 결제 인프라(540). 및 판매자 장치(550)를 포함할 수 있다.
고객 장치(510)는 결제 어플리케이션(또는 FiRa-enabled 어플리케이션)(511), 프레임워크(또는 FiRa 프레임워크)(512), 보안 요소(513), OOB 서브시스템(514), UWB 서브시스템(515)를 포함할 수 있다.
고객 장치(510)는 관찰자 역할(observer role)로서 BLE advertisement 및 UWB Advertisement 중에서 적어도 하나를 수신할 수 있다.
프레임워크(512)는 결제 프로필 매니저(512-1)를 포함하는 프로필 매니저(512-2), 시큐어 서비스(512-3), UWB 서비스(512-4), FiRa OOB 커넥터(512-5), 및 OOB 서비스(512-6)를 포함할 수 있다. 결제 어플리케이션(511)은 프로필 매니저(512-2)와 프레임워크 API를 통해 연결될 수 있다.
결제 프로필 매니저(512-1)는 다양한 레인징 방법을 사용하여 동시에 또는 순차적으로 여러 UWB 세션을 시작 및/또는 관리할 수 있다. 일 실시예에 따라, 레인징 방법은 TWR, DL-TDoA. AoA 측정을 위한 UL-TDoA, OWR, 하이브리드 거리 측정, 및 거리 측정 세션 중 데이터 전송 중에서 적어도 하나를 포함할 수 있다.
보안 요소(513)는 결제 애플릿(513-1), FiRa 애플릿(513-2), 및 SUS 애플릿(513-3)을 포함할 수 있다. FiRa 애플릿(513-2)은 SUS 내부 API를 통해 SUS 애플릿(513-3)과 연결될 수 있다. SUS 애플릿(513-3)은 SUS 외부 API를 통해 UWB 서브시스템(515)과 연결될 수 있다.
결제 애플릿(513-1)은 결제 서비스 제공자가 지원하는 결제 거래를 수행할 수 있다. 결제 애플릿(513-1)은 인증을 위한 자격 증명과 암호화 키를 관리하여 판매자 단말(550)과의 보안 채널을 설정할 수 있다.
결제 인프라(540)는 OOB 서브시스템(541), 적어도 하나의 어드벌타이저(542), 적어도 하나의 DT-앵커(543), 및 적어도 하나의 UT-앵커(544)를 포함할 수 있다.
판매자 장치(550)는 어플리케이션/프레임워크(551), OOB 서브시스템(552), 보안 요소(553), 및 UWB 서브시스템(554)를 포함할 수 있다. 보안 요소(553)는 결제 애플릿(553-1), 및 FiRa 애플릿(553-2)을 포함할 수 있다.
도 6은 본 개시의 일 실시예에 따른 결제 가능 구역(payment-available zone)의 예시를 나타낸다.
도 6의 (a)를 참조하면, 판매자 장치(610)는 복수의 고객 장치들(620, 630, 640, 650) 중에서 적어도 하나의 고객 장치(620)와 결제 거래를 수행할 수 있도록 결제 가능 구역을 설정할 수 있다. 판매자 장치(610)은, 판매자 장치(610) 및/또는 적어도 하나의 고객 장치(620, 630, 640, 650 중에서 적어도 하나)에서 측정한 AoA 방위각(θ) 및 TWR의 결과에 따른 거리(d)에 기반하여 결제 가능 구역을 설정할 수 있다.
도 6의 (b)를 참조하면, 고객 장치(660)는 자체적으로 결제 가능 구역을 설정하여 결제 거래가 유효한 공간을 제한할 수 있다. 고객 장치(660)는, 판매자 장치(670) 및/또는 고객 장치(660)에서 측정한 AoA 방위각(θ) 및 TWR의 결과에 따른 거리(d)에 기반하여 결제 가능 구역을 설정할 수 있다.
일 실시예에 따라, 결제 가능 구역은 판매자 장치 및/또는 고객 장치에서 측정한 AoA 방위각 및/또는 AoA 고도 값의 범위, 및 TWR의 결과로서 고객 장치와 판매자 장치 사이의 거리 중에서 적어도 하나에 기반하여 결정될 수 있다.
일 실시예에 따라, 결제 가능 구역은 결제 서비스 제공자(payment service provider)에 의해 설정될 수 있다. 이 경우, 매장 내 각 판매자 장치 별로 결제 가능 구역이 설정될 수 있고, 상기 결제 가능 구역에 대한 정보는 BLE 광고 패킷(BLE advertisement packet), 또는 UWB 광고 메시지(UWB advertisement message)를 통해 고객 장치로 전달될 수 있다.
일 실시예에 따라, 결제 거래는 고객 장치와 판매지 장치가 모두 결제 가능 구역 내에 있는 경우에만 수행될 수 있다.
한편, 결제 인프라스트럭쳐에서 판매자 장치들과 UWB 장치들 간 충돌 및 간섭을 방지하기 위해 적어도 하나의 UWB 세션이 조정될 수 있다. 결제 인프라스트럭쳐에서 판매자 장치들 또는 UWB 장치들 중 적어도 하나는 매장에서 복수의 UWB 세션들을 정렬하기 위해 기준 시간 기반으로 시간 기준 제공자(time reference provider) 또는 시간 기준 장치(time reference device)로 동작할 수 있다.
일 실시예에 따라, 시간 기준 제공자는 옥텟 0의 값으로 0b0(기준 시간 기반 활성화)로 설정된 어플리케이션 구성 파라미터, SESSION_TIME_BASE [UCI v2.0]를 가질 것이고, 결제 인프라스트럭쳐에서 다른 판매자 장치들 및 UWB 장치들은 그들의 SESSION_TIME_BASE를 옥텟 1의 값으로서, 0b1, 즉 비활성화됨(disabled)으로 설정하고, SESSION_TIME_BASE의 옥텟 1-5를 시간 기준 제공자에 의해 생성된 기준 세션의 세션 핸들(Session Handle)로 설정할 수 있다.
매장이 트래킹되지 않은 네비게이션 서비스 [untracked navigation Profile]를 고객 장치들로 제공하기 위해 DL-TDoA 네트워크를 배포할 경우, 기준 시간 베이스(reference time base)는 기준 개시자 DT-Anchor [MAC v2.0]에 의해 생성될 수 있다.
도 7은 본 개시의 일 실시예에 따른 레인징 블록 구조를 설명하기 위한 도면이다.
도 7을 참조하면, UWB Tap-Free 결제 서비스를 위해 판매자 장치들(Merchant Device 1 ~ Merchant Device 4) 및 고객 장치들(Customer Device 1 ~ Customer Device 3)은, 경쟁을 위한 제어 메시지 및 DL-TDoA를 위한 제1 CFP(contention free period), 경쟁 액세스에 대한 응답 메시지를 위한 CP(contention period), 및 결제 거래(payment transaction)를 위한 제2 CFP에서 메시지 및/또는 데이터를 송수신할 수 있다.
제1 판매자 장치(Merchant Device 1)는 기준 시간 장치로 설정될 수 있다. 제1 고객 장치(Customer Device 1)는 제1 판매자 장치(Merchant Device 1)로 액세스하고, 제2 고객 장치(Customer Device 2)는 제3 판매자 장치(Merchant Device 3)로 액세스하고, 제3 고객 장치(Customer Device 3)는 제2 판매자 장치(Merchant Device 2)로 액세스할 수 있다.
<판매자 장치의 브로드캐스팅을 위한 제1 CFP>
제1 CFP는 결제 인프라스트럭쳐에서 판매자 장치 및/또는 UWB 앵커들에 의해 트래킹되지 않은 네비게이션 서비스를 매장 내 사용자 장치 또는 고객 장치들로 제공; 및/또는 제1 CFP는 경쟁-기반 레인징을 위한 제어 메시지를 포함하는 레인징 개시 메시지(Ranging Initiation Message: RIM)를 송신하기 위해 사용;
<고객 장치들의 응답을 위한 CP>
CP는 고객 장치들이 경쟁-기반 레인징을 위해 CM으로 상기 RIM에 응답하기 위해 사용될 수 있다. CP에서, 고객 장치들은 결제 거래를 위한 UWB 세션들을 수립하는 것을 시도하는 판매자 장치에 상응하는 RIM들 중 하나에 응답하는 데 사용되는 레인징 슬롯을 랜덤하게 선택할 수 있다.
<결제 거래를 위한 제2 CFP>
상기 제2 CFP는 결제 거래들을 위해 사용될 수 있다. 판매자 장치들은 기준 시간 베이스와 매장 관리자에 의해 구성된 적합한 시간 오프셋 값들에 기반하여 결제 거래 세션들에 대한 CFP의 시작 시간을 조정할 수 있다.
도 8a 및 도 8b는 본 개시의 일 실시예에 따른 Tap-Free 결제를 위한 장치들의 동작을 설명하기 위한 도면이다.
도 8a 및 도 8b를 참조하면, Tap-Free 결제를 위한 시스템은 사용자 장치(또는 고객 장치), 제1 판매자 장치, 제2 판매자 장치, 제K 판매자 장치(여기서, K는 3 이상의 정수), 및 결제 인프라스트럭쳐를 포함할 수 있다.
서비스 초기화 단계(service initialization phase) 내 801 동작에서, 상기 결제 인프라스트럭쳐는 상기 고객 장치의 UWBS를 자동으로 웨이크업(wakeup)하고 매장의 정보를 상기 고객 장치로 제공하기 위해 OOB 메커니즘들(예를 들어, BLE)의 사용을 지원할 수 있다.
서비스 초기화 단계에서, 상기 고객 장치는 결제 서비스의 식별자(payment service identifier), 매장의 식별자(retail identifier) 리스트, 및 Tap-Free 결제 서비스로 진행되는 결제 거래를 완료하기 위해 사용되는 UWB 레인징 방법들의 순서 정보 중에서 적어도 하나를 획득할 수 있다. 상기 고객 장치는 매장에 배치된 BLE 장치로부터 BLE 광고 패킷이나 UWB 어드버타이저에 의해 송신된 UWB 광고 메시지를 통해 상기 적어도 하나의 정보를 획득할 수 있다.
일 실시예에 따라, 상기 BLE 광고 패킷 또는 UWB 광고 메시지는 다음 정보를 포함할 수 있다:
* 결제 서비스 식별자: 상기 결제 서비스 식별자는 특정 결제 서비스를 식별하기 위해 사용될 수 있다. 상기 결제 서비스 식별자를 사용함으로써, 상기 고객 장치는 지원되는 결제 어플리케이션, 요구되는 UWB 기능성들의 집합, 지원되는 결제 거래 프로토콜을 인식할 수 있다. 상기 결제 서비스 식별자는 상기 고객 장치 및 판매자 장치 간의 UWB 보안 레인징 및/또는 보안 데이터 전달 세션을 셋업하기 위해 사용될 수 있는 지원되는 암호화 알고리즘 및 보안 프로토콜과도 연관될 수 있다.
* 소매점 식별자: 상기 소매점 식별자는 매장을 식별하기 위해 사용될 수 있다. 상기 소매점 식별자는 예를 들어, 매장 이름 또는 서비스 제공자의 명칭일 수 있다.
상기 BLE 광고 패킷을 수신할 경우, 상기 고객 장치는 다음 절차들 중 적어도 하나를 수행할 수 있다:
1. 상기 결제 서비스 식별자에 매핑된 적합한 UWB 구성 파라미터 집합들을 사용하여 UWB 세션(들) 및/또는 UWB 레인징 방법들의 집합을 시작할 준비를 한다. 사용자가 적합한 결제 어플리케이션을 시작할 때, UWB 세션(들)이 초기화될 수 있다.
2. 상기 매장에 의해 지원되는 상기 결제 어애플리케이션들 중 하나를 자동으로 시작할 수 있다. 사용자에 의해 결제 어플리케이션이 디폴트 애플리케이션으로 구성될 경우, 상기 디폴트 결제 애플리케이션이 백그라운드에서 자동으로 시작될 수 있다.
서비스 초기화 단계 내 802 동작에서, 상기 고객 장치는 상기 고객 장치 내에 설치된 결제 애플리케이션을 실행할 수 있다. 상기 결제 애플리케이션은 상기 고객 장치에서 UWBS를 턴 온할 수 있다.
일 실시예에 따라, 상기 결제 애플리케이션은 다음의 요구 사항들을 만족시킬 것이다.
* 상기 결제 애플리케이션은 FiRa CSML 표준에 정의되어 있는 FiRa 지원 애플리케이션일 수 있다.
* 상기 결제 애플리케이션은 FiRa CSML 표준에 정의되어 있는 프레임워크 API들을 통해 UWB 서비스를 시작할 수 있다.
* 상기 결제 애플리케이션은 상기 BLE 광고를 지원하는 상기 FiRa OOB(Out-Of-Band) 채널들에 기반하여 BLE 광고 패킷을 수신할 수 있다.
* 상기 결제 애플리케이션은 상기 FiRa OOB 채널을 통해 수신된 상기 BLE 광고 패킷에 포함되어 있는 정보에 상응하는 상기 UWB 서비스를 시작할 수 있다.
* 상기 결제 애플리케이션은 상기 프레임워크 API를 사용하여 FiRa 결제 프로파일 관리자에 액세스할 수 있다.
* 상기 결제 애플리케이션은 그것의 첫 번째 Tap-Free 결제 서비스를 시작하기 전에 FiRa CSML 표준의 섹션 10.3.1에 정의되어 있는 바와 같이 FIRAServiceInit API를 통해 FiRa 프레임워크에 그 자신을 등록할 수 있다.
상기 결제 애플리케이션은 다음 파라미터들과 함께 FIRAServiceInit() 함수를 사용한다:
* FiRa CSML 표준의 섹션 10.3.1.1에 정의된 ServiceConfiguration
* FiRa CSML 표준의 섹션 10.3.1.2에 정의된 UWBConfiguration
* FiRa CSML 표준의 섹션 10.3.1.3에 정의된 OOBConfiguration
서비스 초기화 단계 내 803 동작에서, 상기 고객 장치는 상기 결제 어플리케이션을 통해 인-밴드 서비스 발견(in-band service discovery)을 시작할 수 있다. 상기 판매자 장치들 및/또는 결제 인프라스트럭쳐는 인-밴드 서비스 발견 메시지들을 송신할 수 있고, 상기 고객 장치는 상기 인-밴드 서비스 발견 메시지들을 수신하여 서비스를 식별하고 다음 절차들을 준비할 수 있다.
보안 레인징 준비 단계(secure ranging preparation phase) 내 804 동작에서, 상기 결제 인프라스트럭쳐는 상기 고객 장치가 매장 내부에서 위치를 백그라운드 동작으로 추정하도록 트래킹되지 않은 네비게이션 서비스를 지원할 수 있다. 상기 결제 인프라스트럭쳐에서 지원되는 상기 트래킹되지 않은 네비게이션 서비스는 상기 매장에 의해 요구되는 포지셔닝(positioning) 정확도, 예를 들어 1) 상기 매장에서 복수의 판매자 장치들 중에서 어떤 판매자 장치가 가장 가까운지 결정하기에 충분한 포지셔닝 정확도, 또는 2) 고객 장치가 위치하고 있는 테이블 번호/영역을 식별하기에 충분한 포지셔닝 정확도를 제공할 수 있다,
일 실시예에 따라, 두 개의 인접한 판매자 장치들 또는 체크-아웃 카운터들 사이의 권장 거리를 명시하여 특정 정밀도 하에서 두 개의 장치들을 명확하게 구별할 수 있다.
보안 레인징 준비 단계 내 805 동작에서, 상기 고객 장치들 및 판매자 장치들(또는 상기 결제 인프라스트럭쳐에서 UWB 장치들)은 양방향 레인징(two-way ranging)에 기반하여 서로를 검출할 수 있다.
보안 레인징 준비 단계에서 복수의 판매자 장치들이 존재하면, 806 동작에서, 상기 고객 장치는 보안 레인징을 수행하기 위해 하나의 판매자 장치(또는 상기 결제 인프라스트럭쳐에서 UWB 장치)를 선택할 수 있다. 복수의 장치들을 검출할 경우(예를 들어, 사용자 장치가 UI에 디스플레이된 판매자 장치들 중 하나의 판매자 장치를 선택하거나, 또는 상기 사용자 장치가 결제 절차를 진행하는 것을 원하는 판매자 장치들 중 하나를 가리키는 경우). 동시에, 상기 판매자 장치(또는 상기 결제 인프라스트럭쳐에서 UWB 장치)는 보안 레인징을 수행하기 위해 하나의 고객 장치를 선택할 수 있다(예를 들어, 직원이 상기 디바이스 장치/사용자 식별자를 수동으로 확인).
보안 레인징 준비 단계에서, 판매자 장치 발견 시 경쟁-기반 레인징이 사용될 수 있다. 판매자 장치는 경쟁-기반 레인징의 컨트롤러(controller)/개시자(initiator)로서 동작할 수 있다. 복수의 판매자 장치들이 존재할 경우, 판매자 장치들은 판매자 장치들로부터의 UWB 메시지들 간의 충돌을 방지하기 위해 적합한 시간 오프셋들을 사용하여 시간 기준 장치에 의해 생성된 기준 세션에 맞춰 UWB 세션들을 개시할 수 있다. 고객 장치는 경쟁-기반 레인징의 컨트롤리(controllee)/응답자(responder)로서 동작할 수 있다. 상기 고객 장치는 결제 가능 구역에서 판매자 장치들 중 하나에 응답할 수 있다.
보안 레인징 준비 단계에서, 판매자 장치 선택 시, 하나를 초과하는 판매자 장치들이 존재할 경우, 고객 장치에 의해 발견될 수 있다.
보안 레인징 준비 단계에서, 인-밴드 보안 레인징 셋업 절차가 수행될 수 있다. 상기 고객 장치와 상기 판매자 장치는 보안 레인징 세션을 수립하고, 보안 레인징 세션을 통해 결제 거래를 안전하게 수행할 수 있다.
보안 레인징 단계(secure ranging phase) 내 807 동작에서, 상기 고객 장치 및 판매자 장치/결제 인프라스트럭쳐는 인-밴드 또는 OOB 방법들 중 하나를 통해 UWB 보안 레인징 세션을 수립할 수 있다. 상기 고객 장치 및 판매자 장치/결제 인프라스트럭쳐는 결제 거래를 수행하기 전에 UWB 보안 레인징을 수행할 것이다.
결제 거래 단계(payment transaction phase) 내 808 동작에서, 상기 고객 장치는 결제 거래를 수행하기 전에 사용자 의도/확인을 요구할 수 있다. 상기 고객 장치와 상기 판매자 장치는 서비스 제공자에 의해 요구되는 보안 요구 사항들을 충족하기에 충분한 보안 레벨으로 결제 거래를 수행할 수 있다.
결제 거래 단계 내 809 동작에서, 상기 고객 장치는 결제 절차를 마무리하기 위해 온라인 인-앱 결제(online in-app payment) 방법을 수행할 수 있다.
도 9는 본 개시의 일 실시예에 따른 레인징 동안 결제 거래 데이터 교환 절차를 나타낸다.
결제 거래 단계에서 레인징 동안 데이터 전달(Data Transfer) 절차가 수행될 수 있다. 고객 장치와 판매자 장치는 TWR 동안 결제 프로토콜에 대한 데이터를 교환할 수 있다. 이 경우, 레인징 동안 데이터 전달은 레인징 방법으로 사용될 수 있다.
901 동작에서, 고객 장치는 레인징을 위한 레인징 슬롯을 스케줄링하는 제어 메시지를 판매자 장치로 전송할 수 있다.
903 동작에서, 고객 장치는 RIM(ranging initiation messate) 및 APDU command 메시지를 판매자 장치로 전송할 수 있다. 905 동작에서, 판매자 장치는 RRM(ranging response message) 및 APDU response 메시지를 고객 장치로 전송할 수 있다.
907 동작에서, 고객 장치는 레인징 최종 메시지(ranging final message)를 판매자 장치로 전송할 수 있다. 909 동작에서, 고객 장치는 레인징 결과 리포트 메시지(ranging result report message)를 판매자 장치로 전송할 수 있다.
이후, 고객 장치와 판매자 장치는 901 동작 내지 909 동작과 동일하거나 실질적으로 동일한 911 동작 내지 919 동작을 수행할 수 있다.
도 10은 본 개시의 일 실시예에 따라 데이터 전달 또는 세션을 사용하는 결제 거래 데이터 교환 절차를 나타낸다.
고객 장치와 판매자 장치는 데이터 전달을 위한 전용 세션 또는 단계를 통해 결제 프로토콜을 위한 데이터를 교환할 수 있다. 상기 고객 장치와 판매자 장치는 데이터 전달 전용 세션 또는 데이터 전달 단계를 하이브리드 세션에서 세컨더리 세션(secondary session)으로 수립할 수 있다.
1001 동작에서, 고객 장치는 하이브리드 세션 내 단계들을 위한 레인징 슬롯을 스케줄링하는 control message type 3를 판매자 장치로 전송할 수 있다. 1003 동작에서, 고객 장치는 레인징을 위한 레인징 슬롯을 스케줄링하는 control message type 1을 판매자 장치로 전송할 수 있다.
1005 동작에서, 고객 장치는 RIM을 판매자 장치로 전송할 수 있다. 1007 동작에서, 판매자 장치는 RRM을 고객 장치로 전송할 수 있다. 1009 동작에서, 고객 장치는 레인징 파이널 메시지를 판매자 장치로 전송할 수 있다. 1011 동작에서, 판매자 장치는 레인징 결과 리포트 메시지를 고객 장치로 전송할 수 있다.
1013 동작에서, 고객 장치는 데이터 전달을 위한 레인징 슬롯을 스케줄링하는 데이터 전달 제어 메시지(data transfer control message)를 판매자 장치로 전송할 수 있다. 1015 동작에서, 고객 장치는 APDU command 메시지를 판매자 장치로 전송할 수 있다. 1017 동작에서, 판매자 장치는 APDU response 메시지를 고객 장치로 전송할 수 있다.
일 실시예에 따라, 1003 동작 내지 1017 동작에서, 데이터 전달 단계를 포함하여 하이브리드 세션이 사용될 수 있다.
다른 실시예에 따라, 상기 하이브리드 세션 대신, 1019 동작 내지 1023 동작에서 데이터 전달 전용 세션(data transfer only session)이 사용될 수 있다.
1019 동작에서, 고객 장치는 데이터 전달을 위한 레인징 슬롯을 스케줄링하는 데이터 전달 제어 메시지(data transfer control message)를 판매자 장치로 전송할 수 있다. 1021 동작에서, 고객 장치는 APDU command 메시지를 판매자 장치로 전송할 수 있다. 1023 동작에서, 판매자 장치는 APDU response 메시지를 고객 장치로 전송할 수 있다.
일 실시예에 따라, FiRa Tap-Free 결제 서비스를 지원하기 위해 특징 프로파일과 디바이스 프로파일이 정의될 수 있다.
표 1은 고객 장치와 판매자 장치 간 수행되어야 하는 요구되는 기술 특징들을 리스트한다.
[표 1]
Figure PCTKR2023016292-appb-img-000001
도 11은 본 개시의 일 실시예에 따른 상태 천이 다이아그램의 일 예시를 나타낸다.
FiRa 프레임 네트워크에서 결제 프로파일 관리자는 다양한 레인징 방법들을 단계별로 순차적으로 실행하기 위해 상태 천이 다이어그램을 관리할 수 있다. 상기 상태 천이는 상기 결제 애플리케이션의 사용자 인터페이스를 통한 사용자의 활동 또는 진행 중인 레인징 방법을 사용하여 현재 상태에서 수행되어야 하는 절차의 성공적인 완료를 통해 발생된다.
일 실시예에 따라, 결제 서비스 식별자는 상태들에 의해 사용되는 레인징 방법들의 집합 및 상태 천이들의 기준들을 포함하는 상태 천이 다이어그램을 명시할 수 있다.
도 11을 참조하면, idle 상태(1101)는 FiRaServiceActivate()에 기반하여 Standby 상태(1103)로 천이할 수 있다. Standby 상태(1103)는 OWR 활성화 상태(Activate OWR)(1105)(예를 들어, AoA를 위한 OWR 또는 DL-TDoA)로 천이하고, OWR 활성화 상태(Activate OWR)(1105)는 컨텐션 기반 레인징 단계와 함께 하이브리드 세션을 활성화 하는 상태(1107)로 천이할 수 있다.
판매자 장치가 결제 가능 구역 내에서 감지되면, 컨텐션 기반 레인징 단계와 함께 하이브리드 세션을 활성화 하는 상태(1107)는 STS로 데이터 전달 단계를 활성화하는 상태(1109)로 천이할 수 있다.
인증된 판매자 장치와 보안 레인징이 수립되면, STS로 데이터 전달 단계를 활성화하는 상태(1109)는 보안 레인징 및 STS로 데이터 전달 상태(1111)로 천이할 수 있다.
한편, 고객 장치에서 결제 애플리케이션에 의해 FIRAServiceinit() API를 통해 적어도 하나의 결제 애플리케이션 구성(Payment Application configuration)이 설정될 수 있다.
상기 결제 애플리케이션 구성은 서비스 구성(Service Configuration), UWB 구성(UWB configuration), 및 OOB 구성(OOB configuration)을 포함할 수 있다.
일 실시예에 따라, 서비스 구성(Service Configuration)에서 Tap-Free 결제 프로파일의 프로파일 ID는 "XX"일 수 있다. 프로파일 ID 값은 장치 및 서비스 발견 단계에서 브로드캐스팅될 수 있다. 프로파일 ID 값은 FIRAServiceinit () API에서 사용될 수 있다.
일 실시예에 따라, 서비스 구성(Service Configuration)에 대한 Object ServiceConfiguration은 표 2와 같이 구성될 있다.
[표 2]
Figure PCTKR2023016292-appb-img-000002
일 실시예에 따라, UWB 구성(UWB configuration)에 대한 Object ServiceConfiguration은 표 3과 같이 구성될 있다.
[표 3]
Figure PCTKR2023016292-appb-img-000003
일 실시예에 따라, UWB 구성(UWB configuration)에서 모든 다른 파라미터들은 FIRAServiceinit () API 또는 FiRa UWB 프레임워크를 사용하여 FiRa 지원 애플리케이션 제공자에 의해 구성 가능하다.
일 실시예에 따라, OOB 구성(OOB configuration)에 대한 Object ServiceConfiguration은 표 4와 같이 구성될 있다.
[표 4]
Figure PCTKR2023016292-appb-img-000004
일 실시예에 따라, 결제 서비스를 위해 사용되는 BLE 광고 메시지 포맷(BLE Advertisement Message Format)은 표 5와 같이 구성될 수 있다.
[표 5]
Figure PCTKR2023016292-appb-img-000005
Figure PCTKR2023016292-appb-img-000006
표 5에서, 길이(Length) 필드는 상기 BLE 광고메시지 내의 모든 후속 데이터에 대한 옥텟들의 개수를 지시한다.
표 5에서, 데이터 타입(Data Type) 필드는 Bluetooth SIG 표준 할당 번호들에 따른 값을 지시한다.
표 5에서, 회사 식별자(Company Identifier) 필드는 Bluetooth SIG에 의해 할당한 FiRa 컨소시엄 식별자를 지시한다.
표 5에서, UWB 지시 데이터(UWB indication data) 필드는 인코딩된 UWB 관련 비트맵 정보를 지시한다.
표 5에서, UWB 구성(UWB Configuration) 필드는 상기 UWB 서비스를 시작하기 위해 요구되는 UWB 구성에 대한 정보를 지시한다. 상기 사용자 장치는 이 필드에 포함되어 있는 상응하는 파라미터들을 사용하여 UWBS를 활성화하기 시작한다.
표 5에서, 서비스 특정 정보(Service Specific Information) 필드는 특정 UWB 결제 서비스와 관련되는 정보를 지시한다. 일 실시예에 따라, 상기 서비스 특정 정보의 값은 표 6에 따라 형식화될 것이다.
[표 6]
Figure PCTKR2023016292-appb-img-000007
일 실시예에 따라, UWB 광고가 결제 서비스 정보 및 소매점 정보를 제공하기 위해 사용될 때, 애드버타이저는 표 7에 의해 정의되는 콘텐트를 포함하는 데이터 메시지 페이로드 IE와 함께 AoA 측정 메시지를 전송할 것이다.
일 실시예에 따라, UWB 광고 메시지 포맷(UWB Advertisement Message Format)은 표 7과 같이 구성될 수 있다.
[표 7]
Figure PCTKR2023016292-appb-img-000008
일 실시예에 따라, UWB 광고 메시지 포맷에 포함되는 Advertisement Data의 콘텐트는 표 8과 같이 구성될 수 있다.
[표 8]
Figure PCTKR2023016292-appb-img-000009
본 개시에서 보안 채널은 판매자 장치와 고객 장치에서 결제 애플릿 간 암호화로 지원되는 통신 채널 수립을 셋업하기 위해 사용될 수 있다.
일 실시예에 따라, 공용 키들(Public keys)은 Global Platform Confidential Card Content Management Card Specification v2.3 - Amendment A, Version 1.2의 표 8에 정의되어 있는 형식을 따를 수 있다.
ECDH는 NIST Special Publication 800-56A Revision 3 - Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography 에 정의되어 있는 바와 같은 Ephemeral Unified Model, C(2e,2s, ECC CDH)이다.
일 실시예에 따라, 보안 채널 프로토콜을 위한 키들 및 데이터는 표 9와 같이 구성될 수 있다.
[표 9]
Figure PCTKR2023016292-appb-img-000010
<암호화 알고리즘, 키 사용 및 도출>
ECDH는 NIST Special Publication 800-56A Revision 3 - Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography 에 정의되어 있는 바와 같은 Full Unified Model, C(2e, 2s, ECC CDH) 방식이다.
상기 ECDH로부터의 메시지 인증 코드 및 AES 인크립션 키(encryption key)를 생성하기 위한 키 도출은 추출-후-확장 키-도출 2단계 접근 방식을 사용하는 NIST SP 800-56C 를 사용할 것이다.
- 랜덤 추출에 대해서, 그것은 메시지 인증 코드에 대해 AES128-CMAC를 사용할 것이다.
- 상기 키 도출은 PRF에 대한 AES128 CMAC를 사용하는 카운터 모드에서 NIST SP 800-108에 따라 수행된. 상기 KDF에서 사용되는 PRF는 전체 16바이트 출력 길이와 함께 사용되는, NIST 800-38B에 명시되어 있는 바와 같은 CMAC일 것이다.
상기 입력 데이터는 NITS SP800-108에 정의되어 있는 바와 같은 다음 필드들을 사용하여 구성된다. 명확하게 정의되는 한 표준에서 제안된 것과 다른 순서를 정의하는 것이 허락된다는 것에 유의하여야만 할 것이다.
- 2 바이트들 레이블, 상기 키의 목적을 구분함
- 인크립션에 대해서는 0x0001로 설정 (K-ENC)
- 메시지 인증에 대해서는 0x0000로 설정 (K-MAC)
- 2 바이트들 카운터, 128 비트들 키들이 생성될 경우에만 항상 0x1010로 설정
- 2 바이트들 길이, 128 비트들 키들이 생성될 경우에만 항상 0x8080로 설정
- 10 바이트들 콘텍스트, 모두 0x00로 설정
일 실시예에 따라, 판매자 장치를 인증하고 고객 장치와 판매자 장치 사이에 보안 레인징을 수립하기 위해 사용되는 증명서 포맷이 설정될 수 있다. 상기 증명서 포맷은 보안 채널 프로토콜을 위한 것으로서, X.509 증명서를 따를 수 있거나 또는 표 10에 명시되어 있는 포맷일 수 있다.
[표 10]
Figure PCTKR2023016292-appb-img-000011
도 12는 본 개시의 일 실시예에 따른 결제 절차를 위한 직접 통신의 일 예시를 나타낸다.
도 12를 참조하면, 1201 동작에서, UWB 지원 지갑 애플리케이션(UWB enabled wallet application)과 단말 간 보안 채널(secure channel)이 수립될 수 있다. 일 실시예에 따라, 단말은 상기 보안 채널이 수립되는 동안 UWB 지원 지갑 애플리케이션의 증명서를 검증할 수 있다. 상기 증명서에는, 백엔드 시스템들(예를 들어, 획득자(acquirer), 발급자(issuer))이 특정 UWB 지원 지갑 애플리케이션을 식별할 수 있도록 하는 ID.Wallet 및 ID.Device가 포함될 수 있다.
1203 동작에서, 단말은 지갑에 대한 식별 정보(ID.Wallet)를 획득자(acquirer)로 전송할 수 있다. 1205 동작에서, 획득자(acquirer)는 지원되는 지갑 정보(supported wallet) 및 넌스(Nonce)를 단말로 전송할 수 있다.
일 실시예에 따라, 넌스(Nonce)는 일회용으로 사용되는 난수이며, 넌스(Nonce)는 획득자(Acquirer)로부터의 승인된 코드 또는 번호일 수 있다. 넌스(Nonce)는 획득자의 시스템의 거래 정보와 함께 상기 ID.Wallet 및 ID.Device에 매핑될 수 있다.
1207 동작에서, 단말은 거래 정보, MAC.TI, 및 넌스(Nonce) 중에서 적어도 하나를 UWB 지원 지갑 애플리케이션으로 전송할 수 있다. 1209 동작에서, UWB 지원 지갑 애플리케이션은 사용자 인증 절차를 수행할 수 있다. 1211 동작에서, UWB 지원 지갑 애플리케이션은 결제 정보, MAC.PI를 단말로 전송할 수 있다.
일 실시예에 따라, 상기 MAC.TI 는 수학식 1에 기반하여 연산될 수 있다.
[수학식 1]
Figure PCTKR2023016292-appb-img-000012
일 실시예에 따라, 상기 MAC.PI 는 수학식 2에 기반하여 연산될 수 있다.
[수학식 2]
Figure PCTKR2023016292-appb-img-000013
패딩은 AES 블록 사이즈를 고정하는 것이며, RFC 5652의 섹션 6.3에 따라 수행될 수 있다.
1213 동작에서, 단말은 Amount, 토큰, 암호(cryptogram) 중에서 적어도 하나를 획득자로 전송할 수 있다. 1215 동작에서, 획득자는 결제 거래에 대한 결과 정보를 단말로 전송할 수 있다. 1217 동작에서, 단말은 결제 거래에 대한 결과 정보를 UWB 지원 지갑 애플리케이션으로 전송할 수 있다.
일 실시예에 따라, 거래 정보 및 결제 정보는 상기 보안 채널을 통해 교환되며, 단말은 디크립트된 결제 정보를 획득자 및/또는 발행자와 같은 백엔드 시스템으로 포워드하여 승인(acknowledge)을 수신할 수 있다. 마지막 결과 정보를 포함하는 메시지를 통해 상기 거래가 완료될 수 있다.
일 실시예에 따라, 거래 정보는 단말로부터 UWB 지원 지갑 애플리케이션으로 송신되는 개인 정보일 수 있다. 일 실시예에 따라, 상기 거래 정보는 표 11에 정의된 적어도 하나의 필드를 포함할 수 있다.
[표 11]
Figure PCTKR2023016292-appb-img-000014
일 실시예에 따라, 결제 정보는 보안 채널을 통한 인크립트된 형식으로 UWB 지원 지갑 애플리케이션으로부터 단말로 송신되는 개인 정보일 수 있다. 일 실시예에 따라, 결제 정보는 표 12에 정의된 적어도 하나의 필드를 포함할 수 있다.
[표 12]
Figure PCTKR2023016292-appb-img-000015
도 13은 본 개시의 일 실시예에 따른 결제 절차를 위한 간접 통신의 일 예시를 나타낸다.
간접 결제 거래에서, UWB 채널은 기술적인 측면에서 보안 레인징을 위해서만 사용될 수 있다. 상기 보안 채널이 수립된 후, 보안 레인징이 결제 거래를 확인하기 위해 수행될 수 있다. 거래 정보 및 결제 정보와 같은 결제를 위한 나머지 정보는 일반적인 인터넷 통신, 및/또는 클라우드 대 클라우드(Cloud to Cloud: C2C) 통신을 사용하여 백그라운드 상에서 교환될 수 있다.
도 13을 참조하면, 1301 동작에서, 모바일 상의 지갑 애플리케이션과 PoS는 보안 채널을 수립할 수 있다. 1303 동작에서, 지갑 어플리케이션은 인증서(ID.Wallet, ID.Device 포함)를 PoS로 전송할 수 있다. 1305 동작에서, PoS 는 tID(또는 거래 ID)를 생성할 수 있다. 1307 동작에서, PoS는 거래 정보, ID.Wallet, ID.Device를 판매자 서버로 전송할 수 있다. 1309 동작에서, 판매자 서버는 거래 정보, ID.Wallet, ID.Device, Nonce를 (획득자에 의해 허가된) 지갑 서버로 전송할 수 있다.
1311 동작에서, 지갑 서버는 결제를 요청하는 push 메시지를 지갑 어플리케이션으로 전송할 수 있다. 1313 동작에서, 지갑 서버와 지갑 어플리케이션은 거래 정보를 교환할 수 있다. 1315 동작에서, 지갑 애플리케이션은 사용자 입력(예를 들어, 지문)을 통해 결제 동작을 수행할 수 있다. 1317 동작에서, 지갑 어플리케이션은 결제 컨펌 메시지를 지갑 서버로 전송할 수 있다.
1319 동작에서, 지갑 애플리케이션은 거래 정보의 진위를 확인하기 위해 PoS와 보안 레인징을 수행할 수 있다. 1321 동작에서, 지갑 서버는 결제 정보를 판매자 서버로 전송할 수 있다. 1323 동작에서, 판매자 서버는 결제 정보를 획득자/발급자로 전송할 수 있다.
도 14은 본 개시의 일 실시예에 따른, 제1 UWB 장치의 구조를 나타낸다.
도 14의 실시예에서, 제1 UWB 장치는 도 1의 UWB 장치에 해당하거나 또는 UWB 장치를 포함하거나, 또는 UWB 장치의 일부를 포함하는 전자 장치일 수 있다. 제1 UWB 장치는 도 1 내지 도 13에서 전순한 UWB 기반 결제 서비스를 위한 고객 장치(또는 사용자 장치)일 수 있다.
도 14를 참고하면, 제1 UWB 장치는 송수신부(1410), 제어부(1420), 저장부(1430)을 포함할 수 있다. 본 개시에서 제어부는, 회로 또는 어플리케이션 특정 통합 회로 또는 적어도 하나의 프로세서라고 정의될 수 있다.
송수신부(1410)는 다른 엔티티와 신호를 송수신할 수 있다.
제어부(1420)는 본 개시에서 제안하는 실시예에 따른 고객 장치(또는 사용자 장치)의 전반적인 동작을 제어할 수 있다. 예를 들어, 제어부(1420)는 상기에서 기술한 순서도에 따른 동작을 수행하도록 각 블록 간 신호 흐름을 제어할 수 있다. 구체적으로, 제어부(1420)는, 예컨대, 도 1 내지 도 13을 참조하여 설명한 제1 UWB 장치의 동작을 제어할 수 있다.
저장부(1430)는 상기 송수신부(1410)를 통해 송수신되는 정보 및 제어부 (1420)을 통해 생성되는 정보 중 적어도 하나를 저장할 수 있다. 예를 들어, 저장부(1430)는 예컨대, 도 1 내지 도 13을 참조하여 설명한 방법을 위해 필요한 정보 및 데이터를 저장할 수 있다.
제어부(1420)는, 제1 UWB 장치와 제2 UWB 장치 간 결제 서비스(payment service)를 위해 지원되는 결제 방식을 지시하는 UWB 결제 식별 정보(UWB payment identifier), 및 상기 결제 서비스가 수행되는 위치 정보(retail identifier)를 포함하는 광고 메시지(advertisement message)를 상기 제2 UWB 장치로부터 수신할 수 있다. 제어부(1420)는 상기 UWB 결제 식별 정보(UWB payment identifier) 및 상기 결제 서비스가 수행되는 위치 정보(retail identifier)에 기반하여 UWB 레인징(ranging)을 수행할 수 있다. 제어부(1420)는 상기 UWB 레인징 결과에 기반하여 결제 거래(payment transaction)를 수행할 수 있다.
일 실시예에 따라, 상기 광고 메시지는 BLE 광고 메시지 포맷(advertisement message format)에 따라 구성될 수 있다. 일 실시예에 따라, 상기 광고 메시지는 UWB 광고 메시지 포맷에 따라 구성될 수 있다.
일 실시예에 따라, 상기 UWB 결제 식별 정보(UWB payment identifier)는, DL-TDoA(Downlink Time Difference of Arrival) 지원을 지시하는 정보, 경쟁-기반 레인징 지원을 지시하는 정보, 인-밴드(in-band) UWB 결제 거래 지원을 지시하는 정보, 및 RFU(reserved future use) 중에서 어느 하나를 포함할 수 있다.
일 실시예에 따라, 상기 결제 서비스가 수행되는 위치 정보(retail identifier)는 상기 결제 서비스가 수행되는 소매점의 명칭 정보 및 상기 소매점의 타입 정보 중에서 적어도 하나를 포함할 수 있다.
일 실시예에 따라, 상기 광고 메시지는 UWB 구성 정보(UWB Configuration)를 더 포함하고, 상기 UWB 구성 정보는, UWB 세션 ID, 서비스 ID, UWB 구성 ID, 채널 번호, 및 장치 역할 중에서 적어도 하나를 포함할 수 있다.
일 실시예에 따라, 상기 제1 UWB 장치의 프레임워크(Framework) 내 결제 프로필 매니저(Payment Profile Manager)는 상기 제1 UWB 장치가 복수의 UWB 레인징 방법들을 동시에 또는 순차적으로 사용하도록 제어할 수 있다.
일 실시예에 따라, 상기 결제 프로필 매니저는 상기 복수의 UWB 레인징 방법들을 처리하기 위한 상태 변이 다이어그램(state transition diagram)을 설정할 수 있다.
일 실시예에 따라, 제어부(1420)는, AoA(angle of arrival) 방위각, AoA 고도 값의 범위, 및 TWR의 결과에 따른 거리 값 중에서 적어도 하나에 기반하여 결제 가능 구역(payment-available zone)을 설정할 수 있다.
도 15는 본 개시의 일 실시예에 따른, 제2 UWB 장치의 구조를 나타낸다.
도 15의 실시예에서, 제2 UWB 장치는 도 1의 UWB 장치에 해당하거나 또는 UWB 장치를 포함하거나, 또는 UWB 장치의 일부를 포함하는 전자 장치일 수 있다. 제2 UWB 장치는 예컨대, UWB 기반 결제 서비스를 위한 판매자 장치일 수 있다.
도 15를 참고하면, 제2 UWB 장치는 송수신부(1510), 제어부(1520), 저장부(1530)을 포함할 수 있다. 본 개시에서 제어부는, 회로 또는 어플리케이션 특정 통합 회로 또는 적어도 하나의 프로세서라고 정의될 수 있다.
송수신부(1510)는 다른 엔티티와 신호를 송수신할 수 있다.
제어부(1520)은 본 개시에서 제안하는 실시예에 따른 전자 장치의 전반적인 동작을 제어할 수 있다. 예를 들어, 제어부(1520)는 상기에서 기술한 순서도에 따른 동작을 수행하도록 각 블록 간 신호 흐름을 제어할 수 있다. 구체적으로, 제어부(1520)는, 예컨대, 도 1 내지 도 13을 참조하여 설명한 제2 UWB 장치의 동작을 제어할 수 있다.
저장부(1530)는 상기 송수신부(1510)를 통해 송수신되는 정보 및 제어부 (1520)을 통해 생성되는 정보 중 적어도 하나를 저장할 수 있다. 예를 들어, 저장부(1530)는 예컨대, 도 1 내지 도 13을 참조하여 설명한 방법을 위해 필요한 정보 및 데이터를 저장할 수 있다.
상술한 본 개시의 구체적인 실시 예들에서, 본 개시에 포함되는 구성 요소는 제시된 구체적인 실시 예에 따라 단수 또는 복수로 표현되었다. 그러나, 단수 또는 복수의 표현은 설명의 편의를 위해 제시한 상황에 적합하게 선택된 것으로서, 본 개시가 단수 또는 복수의 구성 요소에 제한되는 것은 아니며, 복수로 표현된 구성 요소라 하더라도 단수로 구성되거나, 단수로 표현된 구성 요소라 하더라도 복수로 구성될 수 있다.
한편 본 개시의 상세한 설명에서는 구체적인 실시 예에 관해 설명하였으나, 본 개시의 범위에서 벗어나지 않는 한도 내에서 여러 가지 변형이 가능함은 물론이다. 그러므로 본 개시의 범위는 설명된 실시 예에 국한되어 정해져서는 아니 되며 후술하는 특허청구의 범위뿐만 아니라 이 특허청구의 범위와 균등한 것들에 의해 정해져야 한다.

Claims (15)

  1. 제1 UWB(ultra wide band) 장치의 동작 방법에 있어서,
    상기 제1 UWB 장치와 제2 UWB 장치 간 결제 서비스(payment service)를 위해 지원되는 결제 방식을 지시하는 UWB 결제 식별 정보(UWB payment identifier), 및 상기 결제 서비스가 수행되는 위치 정보(retail identifier)를 포함하는 광고 메시지(advertisement message)를 상기 제2 UWB 장치로부터 수신하는 동작;
    상기 UWB 결제 식별 정보(UWB payment identifier) 및 상기 결제 서비스가 수행되는 위치 정보(retail identifier)에 기반하여 UWB 레인징(ranging)을 수행하는 동작; 및
    상기 UWB 레인징 결과에 기반하여 결제 거래(payment transaction)를 수행하는 동작을 포함하는 것을 특징으로 하는 방법.
  2. 제1항에 있어서,
    상기 광고 메시지는 BLE 광고 메시지 포맷(advertisement message format)에 따라 구성되거나,
    상기 광고 메시지는 UWB 광고 메시지 포맷에 따라 구성되는 것을 특징으로 하는 방법.
  3. 제1항에 있어서, 상기 UWB 결제 식별 정보(UWB payment identifier)는,
    DL-TDoA(Downlink Time Difference of Arrival) 지원을 지시하는 정보, 경쟁-기반 레인징 지원을 지시하는 정보, 인-밴드(in-band) UWB 결제 거래 지원을 지시하는 정보, 및 RFU(reserved future use) 중에서 어느 하나를 포함하는 것을 특징으로 하는 방법.
  4. 제1항에 있어서,
    상기 결제 서비스가 수행되는 위치 정보(retail identifier)는 상기 결제 서비스가 수행되는 소매점의 명칭 정보 및 상기 소매점의 타입 정보 중에서 적어도 하나를 포함하는 것을 특징으로 하는 방법.
  5. 제1항에 있어서, 상기 광고 메시지는 UWB 구성 정보(UWB Configuration)를 더 포함하고,
    상기 UWB 구성 정보는, UWB 세션 ID, 서비스 ID, UWB 구성 ID, 채널 번호, 및 장치 역할 중에서 적어도 하나를 포함하는 것을 특징으로 하는 방법.
  6. 제1항에 있어서,
    상기 제1 UWB 장치의 프레임워크(Framework) 내 결제 프로필 매니저(Payment Profile Manager)는 상기 제1 UWB 장치가 복수의 UWB 레인징 방법들을 동시에 또는 순차적으로 사용하도록 제어하는 것을 특징으로 하는 방법.
  7. 제6항에 있어서, 상기 결제 프로필 매니저는 상기 복수의 UWB 레인징 방법들을 처리하기 위한 상태 변이 다이어그램(state transition diagram)을 설정하는 것을 특징으로 하는 방법.
  8. 제1항에 있어서,
    AoA(angle of arrival) 방위각, AoA 고도 값의 범위, 및 TWR의 결과에 따른 거리 값 중에서 적어도 하나에 기반하여 결제 가능 구역(payment-available zone)을 설정하는 동작을 더 포함하는 것을 특징으로 하는 방법.
  9. 제1 UWB(ultra wide band) 장치에 있어서,
    송수신기; 및
    제어부를 포함하고, 상기 제어부는,
    상기 제1 UWB 장치와 제2 UWB 장치 간 결제 서비스(payment service)를 위해 지원되는 결제 방식을 지시하는 UWB 결제 식별 정보(UWB payment identifier), 및 상기 결제 서비스가 수행되는 위치 정보(retail identifier)를 포함하는 광고 메시지(advertisement message)를 상기 제2 UWB 장치로부터 수신하고,
    상기 UWB 결제 식별 정보(UWB payment identifier) 및 상기 결제 서비스가 수행되는 위치 정보(retail identifier)에 기반하여 UWB 레인징(ranging)을 수행하고,
    상기 UWB 레인징 결과에 기반하여 결제 거래(payment transaction)를 수행하는 것을 특징으로 하는 장치.
  10. 제9항에 있어서,
    상기 광고 메시지는 BLE 광고 메시지 포맷(advertisement message format)에 따라 구성되거나,
    상기 광고 메시지는 UWB 광고 메시지 포맷에 따라 구성되는 것을 특징으로 하는 장치.
  11. 제9항에 있어서, 상기 UWB 결제 식별 정보(UWB payment identifier)는,
    DL-TDoA(Downlink Time Difference of Arrival) 지원을 지시하는 정보, 경쟁-기반 레인징 지원을 지시하는 정보, 인-밴드(in-band) UWB 결제 거래 지원을 지시하는 정보, 및 RFU(reserved future use) 중에서 어느 하나를 포함하는 것을 특징으로 하는 장치.
  12. 제9항에 있어서,
    상기 결제 서비스가 수행되는 위치 정보(retail identifier)는 상기 결제 서비스가 수행되는 소매점의 명칭 정보 및 상기 소매점의 타입 정보 중에서 적어도 하나를 포함하는 것을 특징으로 하는 장치.
  13. 제9항에 있어서, 상기 광고 메시지는 UWB 구성 정보(UWB Configuration)를 더 포함하고,
    상기 UWB 구성 정보는, UWB 세션 ID, 서비스 ID, UWB 구성 ID, 채널 번호, 및 장치 역할 중에서 적어도 하나를 포함하는 것을 특징으로 하는 장치.
  14. 제9항에 있어서,
    상기 제1 UWB 장치의 프레임워크(Framework) 내 결제 프로필 매니저(Payment Profile Manager)는 상기 제1 UWB 장치가 복수의 UWB 레인징 방법들을 동시에 또는 순차적으로 사용하도록 제어하는 것을 특징으로 하는 장치.
  15. 제9항에 있어서, 상기 제어부는,
    AoA(angle of arrival) 방위각, AoA 고도 값의 범위, 및 TWR의 결과에 따른 거리 값 중에서 적어도 하나에 기반하여 결제 가능 구역(payment-available zone)을 설정하는 것을 특징으로 하는 장치.
PCT/KR2023/016292 2022-10-19 2023-10-19 초광대역 통신을 이용하여 결제 서비스를 제공하는 방법 및 장치 WO2024085694A1 (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR10-2022-0135016 2022-10-19
KR20220135016 2022-10-19

Publications (1)

Publication Number Publication Date
WO2024085694A1 true WO2024085694A1 (ko) 2024-04-25

Family

ID=90738189

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2023/016292 WO2024085694A1 (ko) 2022-10-19 2023-10-19 초광대역 통신을 이용하여 결제 서비스를 제공하는 방법 및 장치

Country Status (1)

Country Link
WO (1) WO2024085694A1 (ko)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20110050609A (ko) * 2011-04-27 2011-05-16 주식회사 비즈모델라인 초광대역 통신을 이용한 결제 방법
KR20200028827A (ko) * 2018-09-07 2020-03-17 삼성전자주식회사 Uwb 트랜잭션을 위한 방법 및 전자 장치
US20210312424A1 (en) * 2020-04-01 2021-10-07 Mastercard International Incorporated Ultra-wideband-enabled devices and systems
KR20210149532A (ko) * 2020-06-02 2021-12-09 현대모비스 주식회사 Uwb 레인징 디바이스 및 이를 이용한 uwb 레인징 방법
KR102433674B1 (ko) * 2021-08-24 2022-08-18 주식회사 서비스월드 Uwb를 이용한 유료도로 결제시스템

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20110050609A (ko) * 2011-04-27 2011-05-16 주식회사 비즈모델라인 초광대역 통신을 이용한 결제 방법
KR20200028827A (ko) * 2018-09-07 2020-03-17 삼성전자주식회사 Uwb 트랜잭션을 위한 방법 및 전자 장치
US20210312424A1 (en) * 2020-04-01 2021-10-07 Mastercard International Incorporated Ultra-wideband-enabled devices and systems
KR20210149532A (ko) * 2020-06-02 2021-12-09 현대모비스 주식회사 Uwb 레인징 디바이스 및 이를 이용한 uwb 레인징 방법
KR102433674B1 (ko) * 2021-08-24 2022-08-18 주식회사 서비스월드 Uwb를 이용한 유료도로 결제시스템

Similar Documents

Publication Publication Date Title
WO2020117012A1 (en) Method and device for transmitting and receiving data via uwb in wireless communication system
WO2018074892A1 (ko) 블루투스 기술을 이용하여 데이터를 송수신하기 위한 방법 및 장치
WO2022139514A1 (en) Method and device for device discovery using uwb
WO2020141868A1 (en) Framework of secure ranging without phy payload
WO2020145741A1 (en) Ranging-specific mac service and pib attributes for ieee 802.15.4z
WO2023101429A1 (en) Method and device for ultra wide band (uwb) communication
WO2022039354A1 (en) Electronic device and method, performed by electronic device, of obtaining location information
WO2020184923A1 (en) Framework and methods to control exchange of ranging result
WO2021112646A1 (ko) 무선 통신 시스템에서 근거리 무선 통신을 이용한 오디오 데이터 전송 방법 및 이에 대한 장치
WO2019031870A1 (ko) 블루투스 저전력 에너지 기술을 이용하여 음성 인식 서비스를 호출하기 위한 방법 및 장치
WO2022260493A1 (en) Method and device for providing uwb service
WO2024085694A1 (ko) 초광대역 통신을 이용하여 결제 서비스를 제공하는 방법 및 장치
WO2022092918A1 (ko) 초광대역 통신을 이용한 결제 방법 및 장치
WO2023003434A1 (en) Method and device for ultra-wideband communication
WO2019199049A1 (ko) 무선 통신 시스템에서 디바이스를 제어하기 위한 방법 및 이를 위한 장치
WO2023282706A1 (en) Method and device for uwb communication
WO2021162336A1 (ko) 무선 통신 시스템에서 비연결 애셋 트래킹을 위한 인증 방법, 장치, 컴퓨터 프로그램 및 그 기록 매체
WO2023224379A1 (ko) Uwb 통신을 위한 방법 및 장치
WO2024014849A1 (ko) 초광대역 통신을 이용하여 서비스를 제공하는 방법 및 장치
WO2023096429A1 (en) Ultra-wideband device fop transmitting/receiving multiple packets and method for operating same
WO2024122674A1 (ko) 초광대역통신 세션을 관리하는 방법 및 장치
WO2022260497A1 (en) Method and device for performing uwb ranging
WO2024014836A1 (en) Method and device for providing service using uwb communication
WO2023096422A1 (en) Method and device for ultra wide band communication
WO2023101435A1 (ko) 협대역 채널을 이용하여 데이터를 전송하는 초광대역 장치 및 이의 동작 방법