CN116508044A - 使用超宽带通信的支付方法和装置 - Google Patents

使用超宽带通信的支付方法和装置 Download PDF

Info

Publication number
CN116508044A
CN116508044A CN202180073550.4A CN202180073550A CN116508044A CN 116508044 A CN116508044 A CN 116508044A CN 202180073550 A CN202180073550 A CN 202180073550A CN 116508044 A CN116508044 A CN 116508044A
Authority
CN
China
Prior art keywords
payment
information
message
uwb
transaction information
Prior art date
Legal status (The legal status 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 status listed.)
Pending
Application number
CN202180073550.4A
Other languages
English (en)
Inventor
赵成奎
尹康镇
韩世熙
柳永善
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Samsung Electronics Co Ltd
Original Assignee
Samsung Electronics Co Ltd
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 Samsung Electronics Co Ltd filed Critical Samsung Electronics Co Ltd
Publication of CN116508044A publication Critical patent/CN116508044A/zh
Pending legal-status Critical Current

Links

Classifications

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

Abstract

本发明公开了一种使用UWB通信提供支付服务的方法和装置。本公开的方法包括以下操作：发送用于发起UWB测距的发起消息；从至少一个用户终端接收用于发起消息的响应消息；向基于所述响应消息选择的第一用户设备发送用于支付的交易信息消息；接收来自所述第一用户设备的与所述交易信息消息对应的支付信息消息。

Description

使用超宽带通信的支付方法和装置
技术领域
本公开涉及支付方法，更具体地，涉及使用UWB的支付方法和设备。
背景技术
因特网正在从人类创建和消费信息的人类中心的连接网络发展到在物或其它分布式组件之间通信和处理信息的物联网(IoT)网络。另一种出现的技术是万联网(IoE)，它是通过例如与云服务器的连接的大数据处理技术和IoT技术的组合。实施IoT需要例如传感技术、有线/无线通信和网络基础设施、服务接口和安全技术的技术元件。最近正在进行的物到物连接的的研究是关于传感器联网、机器到机器(M2M)或机器类型通信(MTC)的技术。
在IoT环境中，可以提供收集和分析由彼此连接的事物生成的数据的智能因特网技术(IT)服务，以创建人类生活的新价值。通过常规信息技术(IT)技术和各种行业的转换或集成，IoT可以具有各种应用，例如智能家居、智能建筑物、智能城市、智能汽车或连接的汽车、智能电网、保健或智能电器行业、或现有技术的医疗服务。
随着无线通信系统发展为提供各种服务，需要一种有效地提供这种服务的方法。例如，可以使用测距技术来测量使用超宽带(UWB)的电子设备之间的距离。UWB是一种在基带中使用几GHz或更大的非常宽的频带而不使用无线载波无线通信技术。
发明内容
技术问题
本公开提供了一种用于在远程位置处由UWB处理离线支付的方法。此外，本公开提供了一种在使用UWB时保持低支付复杂度和高安全性的支付方法。
技术方案
根据本公开的一个方面，一种由使用UWB通信提供支付服务的支付设备提供支付服务的方法可以包括：发送用于发起UWB测距的发起消息，从至少一个用户设备接收用于所述发起消息的响应消息，向基于所述响应消息选择的第一用户设备发送用于支付的交易信息消息，以及从所述第一用户设备接收对应于所述交易信息消息的支付信息消息。
作为一个实施例，该方法还可以包括：基于所述响应消息来确定关于所述至少一个用户终端的位置信息；基于所述位置信息来生成用于所述至少一个用户终端的用户列表；以及基于所述用户列表来选择具有支付意图的所述第一用户设备。
根据本公开的另一方面，一种由用户设备提供使用UWB通信的支付服务的方法可以包括：接收用于发起来自支付设备的范围的UWB的发起消息，向所述支付设备发送对所述发起消息的响应消息，从所述支付设备接收用于支付的交易信息消息，以及向所述支付设备发送对应于所述交易信息消息的支付信息消息。
作为一个实施例，该方法还可以包括基于交易信息消息执行支付的认证。
根据本公开的另一方面，使用UWB通信提供支付服务的支付设备可以包括收发器和连接到收发器的控制器。所述控制器可经配置以传输用于起始UWB测距的起始消息，从至少一个用户装置接收对所述起始消息的响应消息，向基于所述响应消息选择的第一用户装置传输用于支付的交易信息消息，以及从所述第一用户装置接收对应于所述交易信息消息的支付信息消息。
根据本公开的另一方面，使用UWB通信提供支付服务的用户设备可以包括收发器和连接到收发器的控制器。所述控制器可经配置以接收用于从支付装置发起UWB测距的发起消息，将用于所述发起消息的响应消息传输到所述支付装置，从所述支付装置接收用于支付的交易信息消息，以及将对应于所述交易信息消息的支付信息消息传输到所述支付装置。
作为一个实施例，发起消息可以包括用于标识支付设备或与支付设备相关联的商店的信息以及与用于在基于竞争的测距模式中测距的UWB的竞争窗口有关的信息。
作为一个实施例，与竞争窗口相关的信息可以包括指示是否存在指示竞争窗口的持续时间的竞争窗口大小信息的标志信息。
作为实施例，当标志信息被设置为第一值时，竞争窗口大小信息可能不存在于发起消息中，并且当标志信息被设置为第二值时，竞争窗口大小信息可能存在于发起消息中。
作为一个实施例，响应消息可以包括用于标识发送响应消息的用户设备的信息。
作为一个实施例，交易信息消息可以包括用于获得交易信息的支付或链接信息的交易信息，并且包括关于交易金额、商家名称、商家ID、定单号、支付协议、发货地址、支付单的地址、允许的卡品牌或再次交易中的至少一个的信息。
作为一个实施例，交易信息消息可以包括用于加密交易信息消息的第一随机数和基于交易信息和第一随机数生成的第一签名信息。
作为一个实施例，支付信息消息可以包括用于获得支付信息的支付信息和链接信息。支付信息可以包括关于卡号、截止日期、认证服务、购买的总货币、金额、记帐信息或令牌中的至少一个的信息。
作为实施例，支付信息消息可以进一步包括用于加密支付信息消息的第二随机数和基于支付信息，第一随机数和第二随机数生成的第二签名信息。
作为实施例，用于UWB通信的加扰时间戳序列(STS)配置可以对应于静态STS配置。用于静态STS配置的静态STS的值可以基于卖主ID的值来生成。
作为实施例，用于UWB通信的测距帧配置可以对应于STS分组(SP)1配置。UWB测距的测距模式(调度模式)可以对应于基于竞争的测距模式。
根据本公开的一个方面，一种由支付设备使用UWB通信来处理与用户设备的支付的方法可以包括：发送用于UWB测距的发起消息，从至少一个用户终端接收对所述发起消息的响应消息，向所选择的第一用户设备发送用于支付的交易信息消息，以及从所述第一用户设备接收对应于所述交易信息消息的支付信息消息。
作为实施例，该方法还可以包括：基于对发起消息的响应消息来确定关于所述至少一个用户终端的位置信息；基于所述位置信息来生成用于所述至少一个用户终端的用户列表；以及基于所述用户列表来选择所述第一用户设备。
根据本公开的另一方面，一种由用户设备使用UWB通信处理与支付设备的支付的方法可以包括：从支付设备接收针对UWB的发起消息，向所述支付设备发送针对所述发起消息的响应消息，从所述支付设备接收用于支付的交易信息消息，以及向所述支付设备发送对应于所述交易信息消息的支付信息消息。
根据本公开的另一个方面，使用UWB通信处理用户设备的支付，支付设备可以包括收发器和连接到收发器的控制器，所述控制器可经配置以传输用于UWB测距的起始消息，从至少一个用户终端接收用于所述起始消息的响应消息，将用于支付的交易信息消息传输到选定的第一用户装置，以及从所述第一用户装置接收对应于所述交易信息消息的支付信息消息。
根据本公开的另一方面，利用使用UWB通信的支付设备处理支付的用户设备可以包括收发器和连接到收发器的控制器，所述控制器可经配置以接收来自支付装置的针对UWB的起始消息，将对所述起始消息的响应消息传输到所述支付装置，从所述支付装置接收用于支付的交易信息消息，以及将对应于所述交易信息消息的支付信息消息传输到所述支付装置。
作为一个实施例，发起消息可以包括用于标识与支付设备相关联的商店的信息以及与UWB测距相关联的竞争窗口有关的信息。
作为一个实施例，与竞争窗口相关的信息可以包括指示是否存在指示竞争窗口大小的竞争窗口大小信息的标志信息。
作为实施例，当标志信息被设置为第一值时，竞争窗口大小信息可能不存在于发起消息中，并且当标志信息被设置为第二值时，竞争窗口大小信息可能存在于发起消息中。
作为实施例，可以包括用于标识发送响应消息的用户设备的信息。
作为一个实施例，交易信息消息可以包括用于获得交易信息的支付或链接信息的交易信息，并且包括关于交易金额、商家名称、商家ID、定单号、支付协议、发货地址、支付单的地址、允许的卡品牌或再次交易中的至少一个的信息。
作为一个实施例，支付信息消息可以包括用于获得支付信息的支付信息和链接信息。支付信息可以包括例如关于卡号、截止日期、认证服务、购买的总货币、金额、记帐信息或令牌中的至少一个的信息。
有益效果
根据使用本公开的UWB的支付方法，可以在远程距离处处理离线支付并且保持低支付复杂度和高安全性。
附图说明
图1示出了示例性支付系统；
图2示出了根据本公开的实施例的使用UWB的支付系统的示例；
图3示出了根据本公开的实施例的使用UWB的支付系统的另一示例；
图4示出了根据本公开的实施例的使用UWB的支付方法；
图5示出了使用图4的使用UWB的支付方法的示例性支付场景；
图6示出了根据本公开的另一实施例的使用UWB的支付方法；
图7示出了根据本公开的另一实施例的使用UWB的支付方法；
图8示出了根据本公开的实施例的用于由支付设备使用UWB来处理支付的方法；
图9示出了根据本公开的实施例的用于由用户设备使用UWB来处理支付的方法；
图10是示出根据本公开的实施例的支付设备的结构的视图；
图11是示出根据本公开的实施例的用户设备的结构的视图；以及
图12示出了根据本公开的实施例的使用UWB的支付系统的示例结构。
具体实施方式
在下文中，将参考附图详细描述本公开的实施例。
在描述实施例时，省略了本领域中已知且与本发明不直接相关的技术的描述，这是为了进一步阐明本公开的要点而不使其不清楚。
出于相同的原因，一些元件可能被夸大或示意性地示出。每个元件的尺寸不一定反映元件的实际尺寸。在所有附图中，相同的附图标记用于表示相同的元件。
通过以下结合附图所描述的实施例，可以理解本公开的优点和特征以及用于实现本公开的优点和特征的方法。然而，本发明不限于本文所公开的实施例，并且可以对其进行各种改变。本文所公开的实施例仅用于向本领域的普通技术人员告知本公开的类别。本发明仅由所附权利要求限定。在整个说明书中，相同的附图标记表示相同的元件。
应当理解，每个流程图中的框和流程图的组合可以由计算机程序指令来执行。由于计算机程序指令可以被配备在通用计算机、专用计算机或其它可编程数据处理设备的处理器中，因此通过计算机或其它可编程数据处理设备的处理器执行的指令生成用于执行结合每个流程图的块所描述的功能的装置。由于计算机程序指令可以被存储在计算机可用或计算机可读存储器中，计算机可用或计算机可读存储器可以被定向到计算机或其它可编程数据处理设备以便以指定的方式实现功能，因此存储在计算机可用或计算机可读存储器中的指令可以产生包括指令装置的产品，所述指令装置用于执行结合每个流程图中的块所描述的功能。由于计算机程序指令可以被配备在计算机或其它可编程数据处理设备中，因此生成由计算机作为一系列操作步骤执行的过程的指令在计算机或其它可编程数据处理设备上执行，并且操作计算机或其它可编程数据处理设备可以提供用于执行结合每个流程图中的框所描述的功能的步骤。
此外，每个块可以表示包括用于执行指定逻辑功能的一个或多个可执行指令的模块，段或代码的一部分。此外，还应当注意，在一些替换执行示例中，在块中提到的功能可以以不同的顺序发生。例如，连续示出的两个块可以基本上同时执行，或者根据相应的功能以相反的顺序执行。
如本文所用，术语“单元”意指软件元件或硬件元件，例如现场可编程门阵列(FPGA)或专用集成电路(ASIC)。单元起到一定的作用。然而，术语“单元”不限于意味着软件或硬件元件。“单元”可以被配置在存储介质中，该存储介质可以被寻址或者可以被配置为再现一个或多个处理器。因此，作为示例，“单元”包括诸如软件元素、面向对象的软件元素、类元素和任务元素、进程、函数、属性、过程、子例程、程序代码段、驱动器、固件、微代码、电路、数据、数据库、数据架构、表、阵列和变量的元素。在元件或“单元”中提供的功能可以与附加元件组合，或者可以被分成子元件或子单元。此外，可以实现元件或“单元”以再现设备或安全多媒体卡中的一个或多个CPU。根据本公开的实施例，“....单元”可以包括一个或多个处理器。
如这里所使用的，术语“终端”或“设备”也可以被称为移动站(MS)、用户设备(UE)、用户终端(UT)、终端、无线终端、接入终端(AT)、用户单元、用户站(SS)、无线设备、无线通信设备、无线发射/接收单元(WTRU)、移动节点或移动节点、或者可以称为其它术语。终端的各种实施例可以包括蜂窝电话、具有无线通信能力的智能电话、具有无线通信能力的个人数字助理(PDA)、无线调制解调器、具有无线通信能力的便携式计算机、具有无线通信能力的捕获/记录/拍摄/拍摄/拍摄设备(例如数码相机)、具有无线通信能力的游戏播放器、具有无线通信能力的音乐存储和回放家用电器、能够无线因特网接入和浏览的因特网家用电器、或包含这些能力的组合的便携式单元或终端。此外，终端可以包括机器对机器(M2M)终端和机器类型通信(MTC)终端/设备，但不限于此。在本公开中，终端可以被称为电子设备或简单地被称为设备。
在下文中，将参考附图描述本公开的工作原理。当确定本公开的主题不清楚时，可以跳过已知功能或配置的详细描述。这里使用的术语是考虑本公开中的功能来定义的，并且可以根据用户或操作者的意图或实践用其它术语来代替。因此，应该基于整个公开内容来定义这些术语。
在此使用的术语被提供用于更好地理解本公开，并且可以对其进行改变而不背离本公开的技术精神。
“应用专用文件(ADF)”可以是例如应用数据结构中的数据结构，其可以是应用或应用特定数据。
“应用协议数据单元(APDU)”可以是当与UWB设备中的应用数据结构通信时使用的命令和响应。
“应用特定数据”可以是例如具有根级和应用级的文件结构，包括UWB控制者信息和UWB会话所需的UWB会话数据。
“控制器”可以是定义和控制测距控制消息(RCM)(或控制消息)的测距设备。
“受控者”可以是使用从控制器接收的RCM(或控制消息)中的测距参数的测距设备。
与“静态STS”不同，“动态加扰时间戳序列(STS)模式”可以是在测距会话期间不重复STS的操作模式。在该模式中，STS可以由测距设备管理，并且生成STS的测距会话密钥可以由安全组件管理。
“小应用程序”可以是例如在安全组件上执行的包括UWB参数和服务数据的应用程序。在本公开中，小应用程序可以是由FIRA联盟的规范(以下称为FIRA/FIRA标准)定义的FIRA小应用程序。
“测距设备”可以是能够执行UWB测距的设备。在本公开中，测距设备可以是在IEEE802.15.4z中定义的增强测距设备(ERDEV)或由FIRA定义的FIRA设备。测距设备可以被称为UWB设备。
“启用UWB的应用”可以是用于UWB服务的应用。例如，启用UWB的应用可以是使用框架API来配置用于UWB会话的OOB连接器、安全服务和/或UWB服务的应用。在本公开中，“启用UWB的应用程序”可以缩写为应用程序或UWB应用程序。启用UWB的应用可以是由FIRA定义的启用FIRA的应用。
“框架”可以是提供对简档、单个UWB配置和/或通知的访问的组件。“框架”可以是例如逻辑软件组件的集合，所述逻辑软件组件包括简档管理器、OOB连接器、安全服务和/或UWB服务。在本公开中，框架可以是由FIRA定义的FIRA框架。
“OOB连接器”可以是用于在测距设备之间建立带外(OOB)连接(例如，BLE连接)的软件组件。在本公开中，OOB连接器可以是由FIRA定义的FIRA OOB连接器。
“配置文件”可以是先前定义的一组UWB和OOB配置参数。在本公开中，配置文件可以是由FIRA定义的FIRA配置文件。
“配置文件管理器”可以是实现在测距设备上可用的配置文件的软件组件。在本公开中，配置文件管理器可以是由FIRA定义的FIRA配置文件管理器。
“服务”可以是向终端用户提供服务的用例的实现。
“智能测距设备”可以是可以实现可选框架API的测距设备。在本公开中，智能测距设备可以是由FIRA定义的FIRA智能设备。
“全局专用文件(GDF)”可以是包括建立USB会话所需的数据的应用特定数据的根级。
“框架API”可以是由启用UWB的应用程序用来与框架通信的API。
“发起者”可以是发起测距交换的测距设备。
“对象标识符(OID)”可以是应用数据结构中的ADF的标识符。
“带外(OOB)”可以是不使用UWB作为基础无线技术的数据通信。
“测距数据集(RDS)”可以是在需要保护机密性、真实性和完整性时建立UWB会话所需的数据(例如，UWB会话密钥，会话ID等)。
“响应器”可以是在测距交换中响应于发起者的测距设备。
“STS”可以是用于增加测距时间标记的完整性和准确性的加密序列。STS可以从测距会话密钥生成。
“安全信道”可以是防止过听和篡改的数据信道。
“安全组件”可以是具有定义的安全级别的实体(例如，SE或TEE)，所述定义的安全级别与UWBS接口，以便例如在使用动态STS时向UWBS提供RDS。
“安全元件(SE)”可以是防篡改的安全硬件组件，其可以用作测距设备中的安全组件。
“安全测距”可以基于通过强加密操作生成的STS进行测距。
“安全服务”可以是用于与安全组件(例如安全元件或可信执行环境(TEE))接口的软件组件。
“服务小应用程序”可以是处理服务特定事务的安全组件上的小应用程序。
“服务数据”可以是由需要在两个测距设备之间传送以实现服务的服务提供商定义的数据。
“服务提供商”可以是定义并提供向最终用户提供特定服务所需的硬件和软件的实体。
“静态STS模式”是在会话期间重复STS的操作模式，并且不需要由安全组件管理。
“安全UWB服务(SUS)小应用程序”可以是SE上的小应用程序，其与小应用程序通信以检索实现与其它测距设备的安全UWB会话所需的数据。SUS小应用程序可以向UWBS传送相应的数据(信息)。
“UWB服务”可以是提供对UWBS的接入的软件组件。
“UWB会话”可以是从控制器和被控制者开始通过UWB通信直到通信停止的时间段。UWB会话可以包括测距，数据传输，或测距和数据传输两者。
“UWB会话ID”可以是标识在控制器和控制器之间共享的UWB会话的ID(例如，32位整数)。
“UWB会话密钥”可以是用于保护UWB会话的密钥。UWB会话密钥可用于生成与UWB会话(或UWB会话ID)映射的STS。在本公开中，UWB会话密钥可以是UWB测距会话密钥(URSK)，并且可以缩写为会话密钥。
“UWB子系统(UWBS)”可以是实现UWB PHY和MAC层规范的硬件组件。UWBS可以具有到框架的接口和到安全组件的接口以搜索RDS。在本公开中，UWB PHY和MAC规范可以是例如由参考IEEE 802.15.4/4z的FIRA定义的FIRA PHY和FIRA MAC规范。
在下文中，将参考附图详细描述本发明的实施例。此外，尽管结合本发明的实施例描述了使用UWB的支付系统，但是作为示例，本发明的实施例也可以应用于具有类似技术背景或特征的其它支付系统。例如，可以在其中包括使用蓝牙的支付系统。此外，在本领域普通技术人员的确定下，本发明的实施例可以在不显著偏离本发明的范围的范围内进行修改，并且这种修改可以应用于其它通信系统。
当确定本发明的主题不清楚时，可以跳过对已知技术或功能的详细描述。这里使用的术语是考虑本公开中的功能来定义的，并且可以根据用户或操作者的意图或实践用其它术语来代替。因此，应该基于整个公开内容来定义这些术语。
图1示出了示例性支付系统。
图1的支付系统100可以是例如使用要求短距离联系的支付方案(例如近场通信(NFC)支付方案)作为离线支付方案的支付系统。
参照图1，支付系统100可以包括：用户设备110、用于在线支付的支付网关120、用于离线支付的支付设备(例如，销售点(POS)终端)130、收单方设备140、卡网络150和/或发卡方设备160。作为一个实施例，支付系统100还可以包括在收单方设备140和卡网络150之间的增值网络170作为可选组件。
支付系统100可以使用在线支付方案和离线支付方案作为支付方案。支付系统100可以通过支付网关120通过预定的在线支付方案执行在线支付。此外，支付系统100可通过支付装置130(例如POS终端)使用预定离线支付方案(例如NFC支付方案)来执行离线支付。
在图1的示例中，收单方设备140可以用来获得单据并代表联营商店处理支付。发卡方设备160是发卡方(例如，银行或卡公司)的设备，其发卡并且可以通过经由卡网络150与收单方设备140通信来执行用于支付的处理操作。
如在图1的支付系统100中，当通过诸如需要短距离联系的NFC支付方案的支付方案执行离线支付时，出现需要短距离联系(例如，在10cm内加标签)的技术限制。此外，还可能发生服务限制，其中用户应当将用户设备(例如，智能电话)转移到商店所有者进行支付。
因此，需要一种新类型的离线支付方案，其能够通过启用与需要短距离联系的支付方案相关的远程通信(例如，在几米的距离内的通信)来执行离线支付而无需标记电话或将电话转移到商店所有者。此外，这种新型的离线支付方案需要通过使用远程通信执行离线支付来解决出现的安全性和支付复杂性问题。此外，与使用NFC支付方案的传统离线支付方案相比，新类型的离线支付方案需要与传统支付系统兼容以仅影响支付装置的前端操作(例如，支付装置与用户装置之间的操作)，而不影响支付装置的后端操作。
本公开假设新类型的离线支付方案是使用UWB通信的离线支付方案，并且描述了其各种实施例。然而，本领域的普通技术人员将明白，本公开的各种实施例不限于仅应用于使用UWB通信的离线支付方案，而是根据实施例也可应用于使用具有与UWB通信的那些通信方案(例如，蓝牙)类似的功能或特性的通信方案(例如，蓝牙)的离线支付方案。
图2说明根据本发明实施例的使用UWB的支付系统的实例。
例如，图2的支付系统200可以是使用支付协议(支付服务/支付应用)的支付系统，该支付协议能够仅使用在具有UWB通信能力的用户设备与支付设备之间的UWB会话中的通信来执行离线支付。图2的实施例的支付协议可以被称为第一支付协议、UWB协议、UWB支付协议或完全支付协议。将图2的实施例的支付协议与图3的实施例的支付协议进行比较，图3的实施例在用户设备和支付网关之间的因特网周期中使用通信，以及在用户设备和支付设备之间的UWB会话中使用通信用于离线支付。
参照图2，支付系统200可以包括：用户设备210、用于在线支付的支付网关220、用于离线支付的支付设备(例如，UWB销售点(POS)终端)230、收单方设备240、卡网络250和/或发卡方设备260。在图2的实施例中，用于支付收单方设备240、卡网络250和发卡方设备260的操作和角色可以与以上通过图1的实施例描述的那些相同。
支付系统200可以通过支付网关220通过预定的在线支付方案执行在线支付。图2的实施例的在线支付方案可以与例如图1的实施例的在线支付方案相同。
此外，支付系统200可使用通过支付装置230(例如，UWB POS终端)预定的支付协议(例如，完全支付协议)来执行离线支付。例如，支付系统200可以通过UWB会话执行UWB测距过程、交易过程和/或支付过程。本公开的UWB测距过程可以遵循例如在“IEEE 802.15.4/z标准”和“FIRA联盟的UWB技术标准”中规定的测距过程。例如，UWB测距过程可以是遵循例如在“IEEE 802.15.4/z标准”和“FIRA联盟的UWB技术标准”中规定的单侧(SS)双向测距(TWR)方案或双侧(DS)方案的过程。
对于使用UWB的离线支付，支付设备230应该能够通过UWB测距准确地识别用户设备(用户)210的位置和距离，并且用户设备(用户)210应该能够准确地识别和认证支付设备230。此外，支付复杂度应该通过准确地识别用户支付的意图的方案来最小化。此外，诸如卡信息的用户信息在支付过程期间不应该被暴露，并且需要更高的安全性。下面参考每个附图描述用于满足这些要求的各种实施例。下面参考例如图4和5描述使用图2的支付系统和支付协议的各种实施例。
图3示出了根据本公开的实施例的使用UWB的支付系统的另一示例。
与例如图2的实施例的支付协议不同，图3的支付系统300可以是使用支付协议(支付服务/支付应用)的支付系统，所述支付协议使用在用户装置与支付网关之间的因特网会话中的通信，以及在用户装置与支付装置之间的UWB会话中的通信，用于离线支付。
图3的实施例的支付协议仅通过UWB会话传送离线支付所需的最小信息，因此与当使用图2的实施例的支付协议时相比，可以简化用于离线支付的UWB通信中的通信。此外，由于使用图3的实施例的支付协议，在线支付可以容易地通过通过UWB会话传送的信息来执行，从而扩展支付覆盖。图3的实施例的支付协议可以被称为第二支付协议或简化的支付协议。
参照图3，支付系统300可以包括：用户设备310、用于在线支付的支付网关320、用于离线支付的支付设备(例如，UWB销售点(POS)终端)330、收单方设备340、卡网络350和/或发卡方设备360。在图3的实施例中，用于支付收单方设备340、卡网络350和发卡方设备360的操作和角色可以与以上通过图1的实施例描述的那些相同。
支付系统300可以通过支付网关320通过预定的在线支付方案执行在线支付。图3的实施例的在线支付方案可以与例如图1的实施例的在线支付方案相同。或者，图3的实施例的在线支付方案可以是进一步使用通过UWB会话传送的信息的新型在线支付方案。因此，可以容易地在支付系统300中执行离线支付。
此外，支付系统300可使用通过支付装置330(例如，UWB POS终端)预定的支付协议(例如，简化的支付协议)来执行离线支付。例如，与图2的实施例相比，支付系统300可以通过UWB会话，使用通过至少一个因特网会话(例如，用户设备310和支付网关320之间的因特网会话和/或支付网关320和支付设备330之间的因特网会话)传送的信息来执行简化的交易过程和/或简化的支付过程。因此，可以降低支付系统300进行离线支付的支付复杂度。
如图3的实施例中的支付方案的使用可以为考虑费用的支付设备和支付网关提供宽范围的选择。
下面参考例如图4和图7描述使用图3的支付系统和支付协议的各种实施例。
图4示出了根据本公开的实施例的使用UWB的支付方法。
具体而言，图4的实施例示出了使用UWB的离线支付方法的示例。
在图4的实施例中，用户设备410和支付设备420对应于能够进行UWB通信的设备。例如，用户设备和支付设备可以是根据包括由“IEEE 802.15.4标准”和“FIRA联盟UWB技术标准”规定的MAC层和PHY层的协议栈实现的设备。例如，用户设备410和/或支付设备420可以是通过UWB通信提供支付服务(应用)的UWB设备(例如，在IEEE 802.15.4z中定义的增强测距设备(ERDEV)或在FIRA中定义的FIRA设备)。
此外，在图4的实施例中，在用于安全性的加扰时间戳序列(STS)生成模式(方法)中，可以使用静态STS生成模式(方法)，而不是动态STS生成模式(方法)。换句话说，图4的实施例中用于UWB通信(或UWB会话)的STS配置(UWB STS配置)可以对应于静态STS配置。在这种情况下，基于由UWB命令接口(UCI)为特定支付应用(服务/协议)(例如，三星支付(Samsung Pay))配置的VENDOR_ID字段和STATIC_STS_CONFIG字段生成的STS可以用于UWB通信(UWB测距)。作为一个实施例，VENDOR_ID字段可以包括供应商标识符，STATIC_STS_CONFIG字段可以包括静态STS配置的值。在本公开中，STATIC_STS_CONFIG字段可以被称为STATIC_STS_IV字段。这种STS生成过程及其相关过程可以参考例如“IEEE 802.15.4/z标准”和“FIRA联盟的UWB技术标准”中规定的过程来执行。
图4的实施例的过程可以是当在用户设备410上启动使用UWB支付的支付应用时执行的过程。
<操作4010和启动消息>
参照图4，支付设备420可以发送用于UWB测距的发起消息(4010)。作为一个实施例，支付设备420可以广播发起消息。
作为实施例，发起消息可以包括用于标识与支付设备相关联的商店的信息(例如，商店的名称)和/或与UWB测距相关联的竞争窗口有关的信息(例如，竞争窗口大小和/或指示竞争窗口的存在的信息)。
作为实施例，发起消息可以是在“IEEE 802.15.4z标准”和“FIRA联盟的UWB MAC标准”中规定的测距发起消息(UWB消息/RFRAME)。例如，发起消息可以是当测距帧(RFRAME)配置被设置为STS分组配置结构1(SP1)时配置的测距发起消息(SP1 RFRAME)。在这种情况下，发起消息可以包括用于UWB测距的至少一条信息(例如，指示发起消息的传输时间的传输时间戳)。在本公开中，STS分组配置结构1(SP1)配置可以具有这样的配置，其中在传送RFRAME(或UWB消息)的STS分组(PHY分组)中，STS(或STS字段)跟随帧开始分隔符(SFD)字段。对于SP1配置的描述，可以参考“IEEE 802.15.4z标准”和“FIRA联盟标准”。
作为实施例，具有SP1配置的发起消息(SP1发起消息/SP1测距发起消息)可以包括MAC报头、包括至少一个有效载荷信息元素(IE)的MAC有效载荷、和/或MAC页脚。
作为一个实施例，发起消息可以包括报头IE和/或有效载荷IE。下面的表1和表2示出了发起消息的有效载荷IE的示例。
[表1]
[表2]
参考表1和表2，发起消息可以包括有效载荷IE，该有效载荷IE包括长度字段(信息)、组ID字段(信息)、类型字段(信息)和/或内容字段(信息)。作为实施例，内容字段可以包括供应商组织唯一标识符(OUI)字段、UWB消息ID字段、竞争窗口大小存在字段、商店名称字段和/或竞争窗口大小字段。下面描述每个字段。如表2所示，商店名称字段可以被称为StoreName.mPOS。
长度字段指示内容字段的大小(长度)。
组ID字段指示相应IE的类型。例如，在发起消息的情况下，可以将组ID字段设置为指示供应商特定的嵌套IE的值(例如，2)。
类型字段指示相应IE的类型。例如，在类型字段中，IE的类型可以被设置为指示有效载荷IE的值(例如，1)。
供应商OUI字段指示供应商的OUI。供应商OUI字段可以是例如包括供应商的唯一值的字段，该唯一值定义基于IEEE标准的消息以确保所定义的消息的唯一性。例如，在本公开中，可将卖主OUI字段设置为指示三星OUI和/或FIRA OUI的值。
UWB消息ID字段可以是指示对应的有效载荷IE是哪个消息的字段。例如，在发起消息的情况下，UWB消息ID字段可以被设置为指示发起消息的值。
竞争窗口大小存在字段指示竞争窗口大小字段是否存在。例如，当竞争窗口大小字段不存在于内容字段(或发起消息)中时，可以将竞争窗口大小字段设置为第一值(例如，0)。或者，当竞争窗口大小字段存在于内容字段(或发起消息)中时，可以将竞争窗口大小字段设置为第二值(例如，1)。在本公开中，竞争窗口大小存在字段可以被称为标志信息。
商店名称字段表示商店的名称。例如，商店名称字段可以被设置为指示与支付设备420相关联的商店(例如，使用支付设备420的商店)的名称的值。
竞争窗口大小字段指示竞争窗口的持续时间。例如，竞争窗口大小字段可以指示以ms为单位的竞争窗口的持续时间。作为一个实施例，当UWB测距的测距模式是基于竞争的测距模式时，竞争窗口大小字段可以被包括在发起消息中。当竞争窗口大小字段被包括在发起消息中时，每个用户设备410可以通过在竞争窗口大小字段所指示的竞争窗口的持续时间内发送响应消息来执行基于竞争的测距。
<操作4020和响应消息>
用户设备410可以向支付设备420发送对发起消息的响应消息(4020)。作为实施例，接收发起消息的每个用户设备410可以向支付设备420单播响应消息。
作为实施例，当发起消息包括竞争窗口大小字段时，用户设备410可以在由竞争窗口大小字段指示的竞争窗口的持续时间内向支付设备发送响应消息。因此，用户设备410可以与其他用户设备执行基于竞争的测距。
作为实施例，响应消息可以包括用于标识用户设备410的信息(例如，用户设备(移动设备)的名称或ID)。
作为实施例，响应消息可以是在“IEEE 802.15.4z标准”和“FIRA联盟的UWB MAC标准”中规定的测距响应消息(UWB消息/RFRAME)。例如，发起消息可以是与测距发起消息(SP1RFRAME)相对应的测距响应消息(SP1 RFRAME)，所述测距发起消息(SP1RFRAME)是在将测距帧(RFRAME)配置设置为加扰时间戳序列(STS)分组配置结构1(SP1)时配置的。在这种情况下，响应消息可以包括用于UWB测距的至少一条信息(例如，指示从发起消息的接收到向其发送响应消息的时间的响应时间信息和/或指示响应消息的发送时间的发送时间戳)。
作为实施例，具有SP1配置的响应消息(SP1响应消息/SP1测距响应消息)可以包括MAC头、包括至少一个有效载荷信息元素(IE)的MAC有效载荷、和/或MAC页脚。
作为一个实施例，响应消息可以包括报头信息元素(IE)和/或有效载荷IE。下面的表3和表4示出了响应消息的有效载荷信息元素(IE)的示例。
[表3]
[表4]
参考表3和表4，响应消息可以包括有效载荷IE，该有效载荷IE包括长度字段(信息)、组ID字段(信息)、类型字段(信息)和/或内容字段(信息)。作为实施例，内容字段可以包括供应商OUI字段、UWB消息ID字段和设备名称字段(信息)。在本公开中，设备名称字段可以被称为RandomID.Device。
表3和4中的响应消息的长度字段、组ID字段、类型字段、厂商OUI字段和UWB消息ID字段的定义和描述可以对表1的发起消息的长度字段、组ID字段、类型字段、厂商OUI字段和UWB消息ID字段的定义和描述进行。同时，表3和表4的UWB消息ID字段可以被设置为指示响应消息的值。
表3和表4的响应消息在内容字段中包括设备名称字段。设备名称字段指示用户设备的名称。例如，如表3所示，设备名称字段可以被设置为指示用户的移动设备的名称的值。例如，如表4所示，移动设备的名称可以是移动设备的随机ID。支付设备420可以通过设备名称字段识别已经发送了响应消息的用户设备410。
参考表4，响应消息(或内容字段)可以进一步包括临时字段(Random.Device)和/或密码字段(Cryptogram.Device)。临时(nonce)字段可以包括用于生成会话密钥的随机数。密码字段可以包括用于认证随机数的数据。
作为一个实施例，支付设备420可以确定关于使用预定测距方法(例如SS-TWR或DS-TWR方案)基于响应消息识别的用户设备的位置信息(例如用户设备410和支付设备420之间的相对距离)，并且提供基于位置信息生成的用户设备(用户)列表。例如，支付设备420可以基于响应消息计算每个用户设备的范围，以确定位置信息并提供基于位置信息按距离排序的用户设备(用户)的列表。在这种情况下，在用户设备(用户)中，只有在距支付设备420的预定距离内的用户设备(用户)可以被包括在用户设备(用户)列表中。可以从这样提供的列表中的用户设备中选择一个用户设备。例如，根据预定方案，可以选择图4的用户设备410作为具有支付意图的用户设备。
<操作4030和交易信息消息>
支付装置420可将用于支付(例如，离线支付)的交易信息消息传输到选定用户装置410(4030)。作为一个实施例，支付设备420可以通过带内或带外连接发送交易信息消息。换句话说，支付设备420可以通过UWB通信/会话(带内通信/会话)或非UWB通信/会话(带外通信/会话)发送交易信息消息。
作为实施例，交易信息消息可以是在“FIRA联盟的UWB MAC标准”中规定的UWB消息。
在一个实施例中，交易信息消息可以包括用于离线支付的交易信息。交易信息可以包括关于例如金额(货币、价格或税收)、商家名称、商家ID、定单号、支付协议、发货地址、支付单的地址、允许的卡品牌和/或再次交易的信息。这样，交易信息消息包括完整交易信息的情况可以被称为“完全实现的交易”。下面的表5示出了在完全实现的交易情况下包括在交易信息消息中的交易信息的示例。
[表5]
参考表5，交易信息可以包括关于商家名称、金额(货币、价格或税收)、商家ID、定单号、发货地址、记帐地址、地址可见性选项、支付协议、商家国家代码和/或支持的卡品牌的信息。
在另一个实施例中，交易信息消息可以包括用于获得交易信息的链接信息(例如，统一资源定位符(URL))。这样，交易信息消息包括用于获得交易信息而不是完整交易信息的链接信息的情况可以被称为“简化交易”。在执行简化事务的情况下，可以减少传输开销，因为可以通过UWB通信只发送用于支付的最小信息。下面参考图6和图7描述简化事务处理情况的示例。
下面的表6示出了在简化交易情况下包括在交易信息消息中的链接信息的示例。
[表6]
项目 类型(传统) UWB
链接(URL) N/A 64字节
作为一个实施例，事务信息消息可以包括报头IE和/或有效载荷IE。下面的表7和8示出了事务信息消息的有效载荷IE的示例。包括下表7和表8的有效载荷IE的交易信息消息可以是例如在完全实现的交易情况中使用的交易信息消息。
[表7]
[表8]
参考表7和表8，交易信息消息可以包括有效载荷IE，该有效载荷IE包括长度字段(信息)、组ID字段(信息)、类型字段(信息)和/或内容字段(信息)。
作为一个实施例，如表7所示，内容字段可以包括供应商OUI字段、UWB消息ID字段、随机询问字段(信息)(randPoS)、签名字段和/或事务信息字段。在另一个实施例中，如表8所示，内容字段可以包括供应商OUI字段、UWB消息ID字段、临时字段(Random.mPOS)、消息认证码字段(MAC.mPOS)和/或加密的二进制长对象(blob)字段(加密的事务信息)。
表7的随机询问字段、签名字段和交易信息字段可以是用于分别提供与表8的临时字段、消息认证码字段和加密的二进制长对象(blob)字段相同或相似的功能的字段。表7中的RrandPos可对应于表8中的Random.mPos。表7中的随机PoS可以对应于表8中的StoreName.mPOS。表7中的终端信息(终端信息/Term.Info.)可以对应于表8中的Random.Device。
表7和表8中的交易信息消息的长度字段、组ID字段、类型字段、供应商OUI字段和UWB消息ID字段的定义和描述可以对表1的发起消息的长度字段、组ID字段、类型字段、供应商OUI字段和UWB消息ID字段的定义和描述进行。同时，表7和表8的UWB消息ID字段可以被设置为指示事务信息消息的值。
表7的随机询问字段指示事务信息消息的加密(密文)的随机询问(随机数)。例如，随机询问字段可以被设置为指示用于加密交易信息和/或包括在交易信息字段中的终端信息的随机询问(randPoS)的值。例如，表7的随机询问(randPoS)可以对应于用于生成包括在表8的临时字段中的会话密钥的随机数(Random.mPOS)。在本公开中，随机询问可以被称为第一随机数、第一随机询问、randPos或Random.mPos。
表7的签名字段可以包括消息认证码(MAC)信息和/或交易信息消息的签名信息。消息认证码信息例如可以是表8的消息认证码中的基于哈希/密码的消息认证码(基于哈希的MAC(HMAC)/基于密码的MAC(CMAC))，或者表7的签名字段中的基于哈希的消息认证码。
作为一个实施例，基于哈希的消息认证码(HMAC)可以是基于交易信息字段(加密的二进制长对象(blob)字段)或randPos(Random.mPos)中包括的交易信息和/或终端信息(Random.Device)以及使用预定哈希算法的对称密钥生成的值。例如，基于哈希的消息认证码可以是使用级联了randPos/Random.mPos、事务信息、终端信息(Random.Device)和对称秘钥值而获得的值作为预定HMAC函数的输入值而生成的哈希值(例如，表7的(randPoS||Transaction info||Term.Info.,Symmetric key)的HMAC哈希值)。表7的(randPoS||Transaction info||Term.Info.,Symmetric key)的HMAC哈希值可以对应于表8的HMAC(Symmetric key,StoreName.mPOS|Encypted Blob|Random.Device)。
作为一个实施例，基于密码的消息认证码(CMAC)可以是基于交易信息和/或终端信息(Random.Device)生成的值，所述终端信息(Random.Device)包括在交易信息字段(加密的二进制长对象(blob)字段)或randPos/Random.mPos以及对称密钥中，使用预定的密码算法。例如，基于密码的消息认证码可以是使用通过级联了randPos/Random.mPos、交易信息、终端信息(Random.Device)和对称密钥值而获得的值作为预定义CMAC函数的输入值来生成的值(例如，表8的CMAC(Symmetric key,StoreName.mPOS|Encypted Blob|Random.Device))。
作为一个实施例，终端信息(Random.Device)的值可以是例如包括在表4的临时字段中的值。
作为实施例，签名信息可以是基于基于交易信息和/或终端信息(Random.Device)生成的哈希值生成的值，所述终端信息(Random.Device)包括在交易信息字段(加密的二进制长对象(blob)字段)和使用预定签名算法的随机Pos/Random.mPos中。例如，签名信息可以是通过将签名函数应用于通过对级联了randPos/Random.mPos、事务信息和终端信息(Random.Device)获得的值应用哈希函数而生成的哈希值(例如，表7的签名(Hash(randPos,Transaction info,Terminal Info)))。
<操作4040和支付信息消息>
用户设备410可以向支付设备420发送对应于交易信息消息的支付信息消息(4040)。
作为实施例，支付信息消息可以是在“FIRA联盟的UWB MAC标准”中规定的UWB消息。
在一个实施例中，支付信息消息可以包括用于离线支付的支付信息(例如，卡信息)。支付信息消息可以包括例如卡号、截止日期、认证服务(Auth service)、购买的总货币、金额、记帐信息(Info)和/或令牌。这样，支付信息消息包括完整支付信息的情况可以被称为“完全实现的支付”。下面的表9示出了在完全实现的支付情况下包括在支付信息消息中的交易信息的示例。
[表9]
项目 类型(传统) UWB
卡号 字符串型 32字节
到期日 字符串型 4字节
认证服务 字符串型 32字节
购买的总货币、金额 字符串型 8字节
记账信息 字符串型 48字节
令牌 字符串型 16字节
其他 字符串型 48字节
参考表9，支付信息消息可以包括例如卡号、到期日、认证服务(认证服务)、购买的总货币、金额、记帐信息(信息)和/或令牌。
在另一个实施例中，支付信息消息可以包括用于获得支付信息的链接信息(例如，统一资源定位符(URL))。这样，支付信息消息包括用于获得支付信息而不是完整支付信息的链接信息的情况可以被称为“简化支付”。在执行简化支付的情况下，可以减少传输开销，因为可以通过UWB通信仅发送用于支付的最小信息。下面参考图7描述简化支付情况的示例。
下面的表10示出了在简化交易情况下包括在支付信息消息中的链接信息的示例。
[表10]
项目 类型(传统) UWB
链接(URL) N/A 64字节
作为一个实施例，支付信息消息可以包括报头IE和/或有效载荷IE。下面的表11和12示出了支付信息消息的有效载荷IE的示例。包括下表11和12的有效载荷IE的支付信息消息可以是例如在完全实现的支付情况中使用的支付信息消息。
[表11]
[表12]
参考表11和表12，支付信息消息可以包括有效载荷IE，该有效载荷IE包括长度字段(信息)、组ID字段(信息)、类型字段(信息)和/或内容字段(信息)。
作为一个实施例，如表11所示，内容字段可以包括供应商OUI字段、UWB消息ID字段、随机询问字段(信息)(等级电话)、签名字段和/或支付信息字段。在另一个实施例中，如表12所示，内容字段可以包括供应商OUI字段、UWB消息ID字段、消息认证码字段(MAC.DEVICE)和/或加密的二进制长对象(blob)字段。表11的签名字段和支付字段可以是分别用于提供与表12的消息认证码字段和加密的二进制长对象(blob)字段相同或相似的功能的字段。
表11和表12中的支付信息消息的长度字段、组ID字段、类型字段、供应商OUI字段和UWB消息ID字段的定义和描述可以对表1的发起消息的长度字段、组ID字段、类型字段、供应商OUI字段和UWB消息ID字段的定义和描述进行。同时，表11和表12的UWB消息ID字段可以被设置为指示支付信息消息的值。
表11的随机询问字段指示用于支付信息消息的加密(密码)的随机询问(随机数)。例如，随机询问字段可以被设置为指示用于加密包括在支付信息字段中的支付信息的随机询问的值。表8的随机询问可以被称为第二随机数、第二随机询问、随机电话或随机设备。
表11的签名字段可以包括用于支付信息消息的消息认证码信息和/或签名信息。消息认证码信息例如可以是表12的消息认证码中的基于哈希/密码的消息认证码(基于哈希的MAC(HMAC)/基于密码的MAC(CMAC))，或者表11的签名字段中的基于哈希的消息认证码。
在一个实施例中，如表11所示，基于哈希的消息认证码可以是基于对称密钥，设备信息(设备信息)和支付信息(包括在支付信息字段(加密的二进制长对象(blob)字段)、randPhone/Random.Device和/或randPos/Random.mPos中)使用预定哈希算法生成的值。例如，如表11所示，基于哈希的消息认证码可以是使用通过级联randPhone/Random.Device、randPos/Random.mPos、支付信息和设备信息(设备信息)以及对称密钥获得的值作为预定义的HMAC函数的输入值而生成的哈希值(例如，(randPhone||randPoS||Payment info||Device Info,Symmetric key)的HMAC哈希值)。作为另一个示例，如表12所示，基于哈希的消息认证码可以是使用包括在加密二进制长对象(blob)字段中的支付信息和对称密钥值作为预定HMAC函数的输入值来生成的哈希值(例如，HMAC(symmetric key,encryptedblob))。
作为一个实施例，基于密码的消息认证码可以是使用包括在加密的二进制长对象(blob)值和对称密钥值中的支付信息作为预定CMAC函数的输入值而生成的值(例如，HMAC(symmetric key,encrypted blob))。
作为一个实施例，随机设备的值可以是例如包括在表4的临时字段中的值。
作为一个实施例，签名信息可以是基于包括在支付信息字段、randPos/Random.mPos和randPhone/Random.Device中的设备信息和/或支付信息生成的哈希值使用预定义的签名算法而生成的值。例如，签名信息可以是通过将签名函数应用到通过对级联了randPhone/Random.Device、andPos/Random.mPos、支付信息和终端信息获得的值应用哈希函数生成的哈希值而生成的值(例如，签名(Hash(randPhone||randPoS||Payment info||Device Info)))。
表11的设备信息(设备信息)可以包括用于识别例如用户设备的信息和/或秘密值。作为一个实施例，设备信息可以被包括在包括支付信息消息的MAC帧的报头中。
支付信息字段可以包括支付信息。作为一个实施例，支付信息可以包括卡信息，例如卡号(例如，主账号)。
接收支付信息消息的支付设备可以基于包括在支付信息消息中的信息来完成支付过程。同时，支付装置与后端组件(收单方或发行方装置)之间的支付处理过程遵循已知过程，并且省略其详细描述。
上面结合图4描述的发起消息，响应消息，事务信息消息和/或支付信息消息可以对应于在例如“IEEE 802.15.4/z标准”或“FIRA联盟UWB MAC技术标准”中定义的MAC帧或包括在MAC帧的有效载荷中的消息。在这种情况下，MAC帧的报头的结构可以如下表13所示。
[表13]
参考表13，MAC帧头(MAC头)可以包括帧控制字段和源地址字段。帧控制字段的示例可以在下面的表14中示出。
[表14]
图5示出了使用图4的使用UWB的支付方法的示例性支付场景。在图5的实施例中，没有描述以上参考图4的实施例描述的那些实施例。图5的用户设备510和支付设备520可以对应于图4的用户设备410和支付设备520。
参考图5，支付设备520可以发送用于UWB测距的发起消息(5010)。例如，支付设备520可以使用未加密的广播方案在预定的周期广播发起消息而不进行加密。作为实施例，发起消息可以包括用于标识与支付设备相关联的商店的信息(例如，商店名称(例如，星巴克(Starbucks)))。
用户设备510可以基于包括在发起消息中的信息向用户提供关于商店的信息。例如，如图5所示，用户设备520可以向用户提供消息，例如“你(John)在星巴克”。
用户设备510可以向支付设备520发送对发起消息的响应消息(5020)。例如，用户设备510可以对响应消息进行加密，并使用加密的单播方案将其单播到支付设备520。作为实施例，响应消息可以包括用于标识用户设备的信息(例如，用户设备(移动设备)的名称或ID)。
支付设备520可以确定关于用户设备510的位置信息(例如，用户设备和支付设备之间的相对距离)，并且向商店时钟提供基于位置信息生成的用户设备(用户)列表。例如，如图5所示，在从John、Lucy和Tim中的每一个的用户设备接收到响应消息时，支付设备520可以通过根据基于该响应消息的预定UWB测距方案计算到每个用户设备的距离(距离)来确定位置信息，并且根据位置信息按距离排序向商店职员提供用户列表，例如“[客户列表]1.John 2.Lucy 3.Tim”。在这种情况下，商店职员可以识别用户列表，识别位于最短距离的用户，并执行从用户获得订单的过程(图5的[点单])。订单过程可以是如图5所示的面对面离线执行的过程，但不限于此，也可以是在线非面对面执行的过程。
支付设备520可以向所选择的用户设备510发送用于离线支付的交易信息消息(5030)。例如，支付设备520可以使用加密的单播方案对响应消息进行加密，并将其单播到所选择的用户设备。为此，如图5所示，支付设备520可以向商店职员提供消息，例如“发送交易信息”。所选择的用户设备510可以是已经完成上述订购过程的用户的用户设备。作为一个实施例，交易信息消息可以包括用于获得交易信息的交易信息或链接信息。
基于交易信息消息中包括的信息，用户设备510可以向用户提供用于支付的信息。例如，用户设备510可以向用户提供消息，例如“美式咖啡花费3美元,选择您的卡,同意！”。基于交易信息。因此，用户可以识别所提供的消息并执行认证过程(例如，指纹认证)。
用户设备510可以向支付设备520发送用于离线支付的支付信息消息(5040)。例如，用户设备510可以使用加密的单播方案对支付信息消息进行加密，并将其单播到支付设备520。为此，如图5所示，用户设备510可以提供消息，例如“发送支付信息”。到用户。作为一个实施例，支付信息消息可以包括用于获得支付信息的支付信息或链接信息。
支付设备520可以基于包括在支付信息消息中的信息来处理支付过程。
图6示出了根据本公开的另一实施例的使用UWB的支付方法。
具体而言，图6的实施例表示在UWB会话中发送用于获得事务信息的链路信息而不是在UWB会话中发送用于离线支付的完整事务信息的简化事务情况的示例。
在图6的实施例中，假设云设备630作为支付设备620和用户设备610之间的中间宿主起作用。作为实施例，云设备630可以是例如由用于在线支付的支付设备操作的设备，诸如支付网关，但不限于此。此外，在图6的实施例中，假设已经完成了上述UWB测距过程和用户设备610用于支付的选择。
参照图6，在操作1中，支付设备620可以将要上载的交易信息发送到云设备630。在这种情况下，令牌(例如，一次性令牌)可以与交易信息一起被发送。作为一个实施例，交易信息可以是上面结合表5描述的交易信息。下面的表15示出了包括交易信息的示例数据结构。
[表15]
示例4交易请求结构
在操作2中，云设备630可以存储所接收的交易信息和令牌，并且可以生成用于获得交易信息并将其发送到支付设备620的链接信息(例如，URL)。因此，支付设备620可以从云设备630接收用于获得交易信息的链接信息。
在操作3中，支付设备620可以将接收到的链路信息包括在交易信息消息中，并通过UWB通信将其发送到用户设备610。作为一个实施例，包括在交易信息消息中的链接信息可以是上面参考表6描述的链接信息。
在操作4中，用户设备610可以使用接收到的链接信息向云设备630发送用于检索交易信息的请求。
在操作5中，云设备630可以基于链接信息检索存储的交易信息，并且可以向用户设备610发送包括交易信息和令牌的数据。因此，用户设备610可以从云设备630接收包括交易信息和令牌的数据。
在操作6中，用户设备610可以将接收到的令牌包括在支付信息消息中并通过UWB通信将其发送到支付设备620。作为一个实施例，支付信息消息可以是包括上面参考表11和表12描述的有效载荷IE的支付信息消息。
图7示出了根据本公开的另一实施例的使用UWB的支付方法。
具体地，图7的实施例表示以下示例：1)在UWB会话中发送用于获得交易信息的链路信息的简化交易情况，而不是在UWB会话中发送用于离线支付的完整交易信息；以及2)在UWB会话中发送用于获得支付信息的链路信息的简化支付情况，而不是在UWB会话中发送完整支付信息。
在图7的实施例中，假设云设备730作为支付设备720和用户设备710之间的中间宿主起作用。作为实施例，云设备730可以是例如由用于在线支付的支付设备操作的设备，诸如支付网关，但不限于此。此外，在图7的实施例中，假设已经完成了上述UWB测距过程和用户设备710用于支付的选择。
参照图7，在操作1中，支付设备720可以将要上载的交易信息发送到云设备730。在这种情况下，令牌(Token_ti)可以与交易信息一起被发送。
在操作2中，云设备730可以存储所接收的交易信息和令牌，并且可以生成用于获得交易信息并将其发送到支付设备720的链接信息(例如，URL)。因此，支付设备720可以从云设备730接收用于获得交易信息的链接信息。
在操作3中，支付设备720可以将接收到的链路信息包括在交易信息消息中，并通过UWB通信将其发送到用户设备710。作为一个实施例，包括在交易信息消息中的链接信息可以是上面参考表6描述的链接信息。
在操作4中，用户设备710可以使用接收到的链接信息向云设备730发送用于检索交易信息的请求。
在操作5中，云设备730可以基于链接信息来检索所存储的交易信息，并且可以向用户设备710发送包括交易信息和令牌的数据。因此，用户设备710可以从云设备730获得包括交易信息和令牌的数据。
在操作6中，用户装置710可将待上载的支付信息传输到云装置730。在这种情况下，在操作7中，云设备730可以存储所接收的支付信息，生成用于获得支付信息的链接信息(例如，URL)，并将其发送到用户设备710。作为一个实施例，支付信息可以是上面参考表9描述的支付信息。下面的表16示出了包括支付信息的示例数据结构。
[表16]
示例6商家解密授权请求
在操作8中，用户设备710可以将接收到的链路信息包括在支付信息消息中，并通过UWB通信将其发送到支付设备720。作为一个实施例，包括在支付信息消息中的链接信息可以是上面参考表10描述的链接信息。
在操作9中，用户设备720可以使用接收到的链接信息向云设备730发送用于检索支付信息的请求。
在操作10中，云设备730可以基于链接信息来检索所存储的支付信息，并且可以将包括支付信息的数据发送到支付设备720。因此，支付设备720可以从云设备730接收包括支付信息的数据。
图8说明根据本发明实施例的用于由支付装置使用UWB来处理支付的方法。
在图8的实施例中，没有描述上面参考图2至7描述的那些实施例。例如，上面结合图2至图7描述的每个消息中包括的发起消息，响应消息，交易信息消息，支付信息消息和信息的描述可以被应用于要参考图8描述的每个消息中包括的发起消息、响应消息、交易信息消息、支付信息消息和信息，因此下面没有给出重复的描述。
在图8的实施例中，用于UWB(UWB通信或会话)的STS配置可以对应于静态STS配置，并且可以基于卖主ID的值来生成用于静态STS配置的静态STS的值。此外，在图8的实施例中，用于UWB通信的测距帧配置可以对应于STS分组(SP)1配置。此外，在图8的实施例中，UWB测距的测距模式(调度模式)可以是基于竞争的测距模式。
参照图8，支付设备可以发送用于发起UWB测距的发起消息(8010)。例如，支付设备可以广播发起消息。
作为实施例，发起消息可以是SP1测距发起消息(SP1 RFRAME)。
作为实施例，发起消息可以包括用于标识支付设备或与支付设备相关联的商店的信息(例如，商店的名称)和/或与基于竞争的测距模式UWB测距相关联的竞争窗口有关的信息(例如，竞争窗口大小和/或指示竞争窗口的存在的信息)。
支付设备可以从至少一个用户设备接收对发起消息的响应消息(8020)。
作为实施例，响应消息可以是SP1测距响应消息(SP1 RFRAME)。
作为实施例，响应消息可以包括用于标识用户设备的信息(例如，用户设备(移动设备)的名称或ID)。在这种情况下，可以基于从至少一个用户终端接收的响应消息来确定关于至少一个用户终端的位置信息。例如，支付设备可以基于从至少一个用户终端接收的响应消息，使用预置UWB测距方案来计算每个用户设备的范围(距离)，并确定位置信息(例如，支付设备和相应用户设备之间的相对距离)。此外，可以基于位置信息生成用户设备(用户)列表。例如，支付设备可以生成用户设备(用户)列表，其基于位置信息以距离的顺序枚举用户设备(用户)。
支付设备可以向基于响应消息选择的用户设备发送用于支付的交易信息消息(例如，离线支付)(8030)。例如，支付设备可以根据预定标准选择包括在生成的用户设备列表中的一个用户设备。因此，可以选择具有支付意图的用户设备。
作为一个实施例，支付设备可以通过带内或带外连接发送交易信息消息。
在一个实施例中，交易信息消息可以包括用于离线支付的交易信息。交易信息可以包括关于例如金额(货币，价格或税收)、商家名称、商家ID、定单号、支付协议、发货地址、支付单的地址、允许的卡品牌和/或再次交易的信息。
在另一个实施例中，交易信息消息可以包括用于获得交易信息的链接信息(例如，统一资源定位符(URL))。在这种情况下，可以减少传输开销，因为可以通过UWB通信只发送用于支付的最小信息。
作为一个实施例，交易信息消息可以包括用于加密交易信息消息的第一随机数和基于交易信息和第一随机数生成的第一签名信息。
作为一个实施例，交易信息消息可以具有SP1 RFRAME配置。
支付设备可以从用户设备接收对应于交易信息消息的支付信息消息(8040)。
在一个实施例中，支付信息消息可以包括用于离线支付的支付信息(例如，卡信息)。支付信息消息可以包括例如卡号、截止日期、认证服务(Auth service)、购买的总货币、金额、记帐信息(Info)和/或令牌。
在另一个实施例中，支付信息消息可以包括用于获得支付信息的链接信息(例如，统一资源定位符(URL))。在这种情况下，可以减少传输开销，因为可以通过UWB通信只发送用于支付的最小信息。
作为一个实施例，支付信息消息还可以包括用于加密支付信息消息的第二随机数，以及基于支付信息、第一随机数和第二随机数生成的第二签名信息。
作为一个实施例，支付信息消息可以具有SP1 RFRAME配置。
接收支付信息消息的支付设备可以基于包括在支付信息消息中的信息来完成支付过程。
图9示出了根据本公开的实施例的用于由用户设备使用UWB来处理支付的方法。
在图9的实施例中，没有描述上面参考图2至图8描述的那些实施例。例如，上面结合图2至图8描述的每个消息中包括的发起消息、响应消息、交易信息消息、支付信息消息和信息的描述可以被应用于要参考图9描述的每个消息中包括的发起消息、响应消息、交易信息消息、支付信息消息和信息，因此下面没有给出重复的描述。
在图9的实施例中，用于UWB(UWB通信)的STS配置可以对应于静态STS配置，并且可以基于卖主ID的值来生成用于静态STS配置的静态STS的值。此外，在图9的实施例中，用于UWB通信的测距帧配置可以对应于STS分组(SP)1配置。此外，在图9的实施例中，UWB测距的测距模式(调度模式)可以是基于竞争的测距模式。
参考图9，用户设备可以接收用于发起UWB测距的发起消息(9010)。
作为实施例，发起消息可以是SP1测距发起消息(SP1 RFRAME)。
作为实施例，发起消息可以包括用于标识支付设备或与支付设备相关联的商店的信息(例如，商店的名称)和/或与基于竞争的测距模式UWB测距相关联的竞争窗口有关的信息(例如，竞争窗口大小和/或指示竞争窗口的存在的信息)。
用户设备可以向支付设备发送对发起消息的响应消息(9020)。
作为实施例，响应消息可以是SP1测距响应消息(SP1 RFRAME)。
作为实施例，响应消息可以包括用于标识用户设备的信息(例如，用户设备(移动设备)的名称或ID)。在这种情况下，可以基于从用户终端接收的响应消息来确定关于用户终端的位置信息。例如，支付设备可以基于从用户终端接收的响应消息使用预置UWB测距方案来计算用户设备的范围(距离)，并确定位置信息(例如，支付设备与相应用户设备之间的相对距离)。此外，可以基于位置信息生成用户设备(用户)列表。例如，支付设备可以生成用户设备(用户)列表，该列表基于位置信息以距离的顺序枚举具有响应消息的用户设备(用户)。因此，可以选择具有支付意图的用户设备。
用户设备可以从支付设备接收用于离线支付的交易信息消息(8030)。例如，接收交易信息消息的用户设备可以是根据预定标准从用户设备列表中选择的用户设备。作为一个实施例，用户设备可以基于交易信息消息执行用于支付的认证。
在一个实施例中，交易信息消息可以包括用于离线支付的交易信息。交易信息可以包括关于例如金额(货币，价格或税收)、商家名称、商家ID、定单号、支付协议、发货地址、支付单的地址、允许的卡品牌和/或再次交易的信息。
在另一个实施例中，交易信息消息可以包括用于获得交易信息的链接信息(例如，统一资源定位符(URL))。在这种情况下，可以减少传输开销，因为可以通过UWB通信只发送用于支付的最小信息。
作为一个实施例，交易信息消息可以包括用于加密交易信息消息的第一随机数和基于交易信息和第一随机数生成的第一签名信息。
作为一个实施例，交易信息消息可以具有SP1 RFRAME配置。
用户设备可以向支付设备发送与交易信息消息相对应的支付信息消息(8040)。
在一个实施例中，支付信息消息可以包括用于离线支付的支付信息(例如，卡信息)。支付信息可以包括例如卡号、截止日期、认证服务、购买的总货币、金额、记帐信息(Info)和/或令牌。
在另一个实施例中，支付信息消息可以包括用于获得支付信息的链接信息(例如，统一资源定位符(URL))。在这种情况下，可以减少传输开销，因为可以通过UWB通信只发送用于支付的最小信息。
作为一个实施例，支付信息消息还可以包括用于加密支付信息消息的第二随机数，以及基于支付信息、第一随机数和第二随机数生成的第二签名信息。
作为一个实施例，支付信息消息可以具有SP1 RFRAME配置。
接收支付信息消息的支付设备可以基于包括在支付信息消息中的信息来完成支付过程。
图10是说明根据本发明实施例的支付装置的结构的视图。
在本公开中，支付设备可以是通过UWB通信提供支付服务的UWB设备(例如，在IEEE802.15.4z中定义的增强测距设备(ERDEV)或在FIRA中定义的FIRA设备)。
参照图10，支付设备可以包括收发器1010、控制器1020和存储单元1030。在本公开中，控制器可以被定义为电路或专用集成电路或至少一个处理器。
收发器1010可以向/从其它网络实体发送/接收信号。收发器1010可以使用例如UWB通信向用户设备发送/从用户设备接收用于离线支付的数据。
根据一个实施例，控制器1020可以控制支付设备的整体操作。例如，控制器1020可以控制块间信号流以执行根据上述流程图的操作。具体地，控制器1020可以控制上面参考图2至图9描述的支付设备的支付处理过程的操作。
存储单元1030可以存储经由收发器1010发送/接收的信息和经由控制器1020生成的信息中的至少一个。例如，存储单元1030可以存储用于使用以上参考图2至图9描述的UWB进行支付处理的信息和数据。
图11是示出根据本公开的实施例的用户设备的结构的视图。
在本公开中，用户设备可以是通过UWB通信提供支付服务的UWB设备(例如，在IEEE802.15.4z中定义的增强测距设备(ERDEV)或在FIRA中定义的FIRA设备)。
参照图11，支付设备可以包括收发器1110、控制器1120和存储单元1130。在本公开中，控制器可以被定义为电路或专用集成电路或至少一个处理器。
收发器1110可以向其它网络实体发送信号和从其它网络实体接收信号。收发器1110可以使用例如UWB通信向/从支付设备发送/接收用于离线支付的数据。
根据一个实施例，控制器1120可以控制用户设备的整体操作。例如，控制器1120可以控制块间信号流以执行根据上述流程图的操作。具体地，控制器1120可以控制上面参考图2至图9描述的用户设备的支付处理过程的操作。
存储单元1130可以存储经由收发器1110发送/接收的信息和经由控制器1120生成的信息中的至少一个。例如，存储单元1130可以存储用于使用以上参考图2至图9描述的UWB进行支付处理的信息和数据。
图12示出了根据本公开的实施例的使用UWB的支付系统的示例结构。
参照图12，支付系统可以包括用户设备1210和能够进行UWB通信的支付设备1220。用户设备1210和支付设备1220可以使用UWB通信执行上面结合图2到9描述的支付(离线)操作。
用户设备1210和支付设备1220可以分别具有包括服务层1211和1221，应用层1212和1222,MAC层1213和1223,PHY层1214和1224以及安全层1215和1222的协议栈。
MAC层1213和1223以及PHY层1214和1224可以是用于UWB通信的基于UWB的MAC层(UWB MAC)和PHY层(UWB PHY)，并且可以遵循例如在IEEE 802.15.4/z标准或“FIRA联盟UWBMAC技术标准”中规定的内容。此外，MAC层1213和1223以及PHY层1214和1224可以对应于用于支持除UWB通信之外的通信方案的MAC层和PHY层。例如，MAC层1213和MAC层1223以及PHY层1214和PHY层1224可以对应于支持5G通信和/或蓝牙通信的基于5G通信和/或蓝牙的MAC和PHY层。
服务层1211和服务层1221可以定义包括本公开的支付服务和基于位置的服务的服务特性。此外，应用层1212和应用层1222以及安全层1215和安全层1225可以指定用于发现UWB设备和服务的机制，用于以相互兼容的方式实现设备的机制，以及相互兼容的安全要求。服务层1211和服务层1221，应用层1212和应用层1222，以及安全层1215和安全层1225可以遵循例如FIRA联盟技术标准中指定的内容。
在上述具体实施例中，根据所提出的具体实施例，包括在本公开中的组件以单数或复数形式来表示。然而，单数或复数形式被选择为对于为便于描述而建议的上下文是足够的，并且本公开不限于单数或复数组分。如本文所用，单数形式“一个”、“一种”和“该”旨在也包括复数形式，除非上下文另外清楚地指示。
尽管上面已经描述了本公开的具体实施例，但是在不脱离本公开的范围的情况下，可以对其进行各种改变。因此，本发明的范围不应限于上述实施例，而应由所附权利要求书及其等效物界定。

Claims (15)

1.一种由支付设备使用UWB通信提供支付服务的方法，所述方法包括：
发送用于发起UWB测距的发起消息；
从至少一个用户设备接收所述发起消息的响应消息；
向基于所述响应消息选择的第一用户设备发送用于支付的交易信息消息；以及
从所述第一用户设备接收与所述交易信息消息对应的支付信息消息。
2.如权利要求1所述的方法，还包括：
基于所述响应消息确定所述至少一个用户终端的位置信息；
基于所述位置信息为所述至少一个用户终端生成用户列表；以及
基于所述用户列表选择具有支付意图的所述第一用户设备。
3.如权利要求1所述的方法，其中，所述发起消息包括：用于识别所述支付设备或与所述支付设备相关联的商店的信息、以及与基于竞争的测距模式中的所述UWB测距的竞争窗口有关的信息。
4.如权利要求3所述的方法，其中，与所述竞争窗口有关的信息包括指示是否存在竞争窗口大小信息的标志信息，所述竞争窗口大小信息指示所述竞争窗口的持续时间。
5.如权利要求4所述的方法，其中，当所述标志信息被设置为第一值时，所述竞争窗口大小信息不存在于所述发起消息中，并且当所述标志信息被设置为第二值时，所述竞争窗口大小信息存在于所述发起消息中。
6.如权利要求1所述的方法，其中，所述响应消息包括用于识别发送所述响应消息的用户设备的信息。
7.如权利要求1所述的方法，其中，所述交易信息消息包括用于获得交易信息的所述支付或链接信息的所述交易信息，并且包括关于交易金额、商家名称、商家ID、定单号、支付协议、配送地址、付款单的地址、允许的卡品牌或再次交易中的至少一个信息。
8.如权利要求7所述的方法，其中，所述交易信息消息包括用于加密所述交易信息消息的第一随机数、以及基于所述交易信息和所述第一随机数生成的第一签名信息。
9.根据权利要求1所述的方法，其中，所述交易信息消息包括用于获得所述支付信息的支付信息和链接信息，以及
其中，所述支付信息包括关于卡号、截止日期、认证服务、购买的总货币、金额、记帐信息或令牌中的至少一个的信息。
10.如权利要求9所述的方法，其中，所述支付信息消息还包括用于加密所述支付信息消息的第二随机数，以及基于所述支付信息、所述第一随机数和所述第二随机数生成的第二签名信息。
11.如权利要求1所述的方法，其中，所述UWB通信的加扰时间戳序列STS配置对应于静态STS配置，
其中，基于卖家ID的值生成所述静态STS配置的静态STS的值，
其中，所述UWB通信的测距帧配置对应于STS分组(SP)1配置，
其中，所述UWB测距的测距模式(调度的模式)与基于竞争的测距模式相对应。
12.一种由用户设备使用UWB通信提供支付服务的方法，所述方法包括：
从支付设备接收用于发起UWB测距的发起消息；
向所述支付设备发送所述发起消息的响应消息；
从所述支付设备接收用于支付的交易信息消息；以及
向所述支付设备发送与所述交易信息消息对应的支付信息消息。
13.如权利要求12所述的方法，其中，还包括基于所述交易信息消息对支付进行认证。
14.一种使用UWB通信提供支付服务的支付设备，包括：
收发器；以及
控制器，连接到所述收发器且经配置以：
发送用于发起UWB测距的发起消息；
从至少一个用户设备接收所述发起消息的响应消息；
向基于所述响应消息选择的第一用户设备发送用于支付的交易信息消息；以及
从所述第一用户设备接收与所述交易信息消息对应的支付信息消息。
15.一种使用UWB通信提供支付服务的用户设备，包括：
收发器；以及
控制器，连接到所述收发器且经配置以：
从支付设备接收用于发起UWB测距的发起消息；
向所述支付设备发送所述发起消息的响应消息；
从所述支付设备接收用于支付的交易信息消息；以及
向所述支付设备发送与所述交易信息消息对应的支付信息消息。
CN202180073550.4A 2020-10-30 2021-10-29 使用超宽带通信的支付方法和装置 Pending CN116508044A (zh)

Applications Claiming Priority (3)

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

Publications (1)

Publication Number Publication Date
CN116508044A true CN116508044A (zh) 2023-07-28

Family

ID=81384127

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202180073550.4A Pending CN116508044A (zh) 2020-10-30 2021-10-29 使用超宽带通信的支付方法和装置

Country Status (5)

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

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115002660B (zh) * 2022-05-27 2024-01-23 深圳市汇顶科技股份有限公司 Uwb通信方法、芯片及设备

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8478300B2 (en) * 2005-12-20 2013-07-02 Microsoft Corporation Proximity service discovery in wireless networks
KR20110050609A (ko) * 2011-04-27 2011-05-16 주식회사 비즈모델라인 초광대역 통신을 이용한 결제 방법
KR102616860B1 (ko) * 2016-02-05 2023-12-21 삼성전자주식회사 근거리 통신을 이용한 결제 시스템 및 방법
US11184153B2 (en) * 2018-07-05 2021-11-23 Apple Inc. Ultra wideband secure ranging
WO2020050555A1 (en) * 2018-09-07 2020-03-12 Samsung Electronics Co., Ltd. Method for uwb transaction and electronic device therefor
KR102594360B1 (ko) * 2018-12-07 2023-10-27 삼성전자주식회사 무선 통신 시스템에서 레인징을 수행하기 위한 방법 및 장치

Also Published As

Publication number Publication date
KR20230104650A (ko) 2023-07-10
EP4224395A1 (en) 2023-08-09
US20230394463A1 (en) 2023-12-07
WO2022092918A1 (ko) 2022-05-05
EP4224395A4 (en) 2023-11-15

Similar Documents

Publication Publication Date Title
CN110502887B (zh) 电子支付方法和装置
TWI655875B (zh) Method for establishing wireless communication connection, communication master device, communication slave device, server and system
KR100922906B1 (ko) 구별 랜덤 첼린지들을 사용하는 부트스트랩 인증
US11943617B2 (en) Method for acquiring access rights to conditional access content
JP2019512192A (ja) セキュアデバイス機能へのオンラインアクセスの妥当性検査
AU2016247689A1 (en) Technique for managing profile in communication system
KR20160124648A (ko) 프로파일 다운로드 및 설치 장치
US20220295269A1 (en) Network access authentication method and device
CN104137618A (zh) 经由对等链路的共享网络访问
US20160328714A1 (en) Method and apparatus for authenticating payment related information in mobile communication system
US20160210612A1 (en) Rapid in Person Transactions Via Mobile Device
CN103577983A (zh) 一种脱机消费电子货币的圈存方法
CN104700262A (zh) 一种基于nfc移动终端和pos终端的支付系统
KR20160084680A (ko) Iot 디바이스 인증 방법, iot 디바이스 인증 수행 방법, 사용자 단말 및 인증 서버
US20160005036A1 (en) Hce token secure delivery without data connectivity
CN116508044A (zh) 使用超宽带通信的支付方法和装置
AU2017228450A1 (en) Mid-range reader interactions
WO2017206680A1 (zh) 点对点转账系统和方法
KR20220155867A (ko) Uwb 보안 레인징을 수행하기 위한 방법 및 장치
CN112862488A (zh) 数据的签名方法、装置、电子设备及计算机可读存储介质
US20240086890A1 (en) Payment method and device using ultra-wideband communication
EP4274285A1 (en) Method and device for secure ranging based on ultra-wideband communication
CN113193923B (zh) 一种远程测试方法，设备及系统
US20220398581A1 (en) Transaction method and device using uwb communication
KR101922540B1 (ko) 비콘 아이디 검증방법

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination