A method, device and system for payment through smart glasses

Abstract

This application discloses a method, device, and system for payment via smart glasses, relating to the field of terminal technology. It enables rapid payment via smart glasses while ensuring secure payment authentication. The entire payment process eliminates the need for complex voice interaction, significantly improving payment efficiency and enhancing user experience. In this application, a communication connection is established between the user device and the smart glasses. The user device stores the trusted possession authentication status of the smart glasses, which is saved after the user device verifies the smart glasses. The user device receives a first payment request from the smart glasses carrying pending payment information. After determining that the trusted possession authentication status of the smart glasses is valid, the user device sends a second payment request carrying pending payment information to the server and, based on the server's payment response, sends a message indicating successful payment to the smart glasses.

Description

Technical Field

[0001] This application relates to the field of terminal technology, and in particular to a method, device and system for making payments through smart glasses. Background Technology

[0002] With the rapid development of mobile payment technology, payment terminals have gradually expanded from handheld smart devices such as smartphones to various IoT wearable smart devices to adapt to hands-free and convenient payment scenarios. Among them, smart glasses, as a typical IoT wearable smart device, integrate functions such as image acquisition, wireless communication, human-computer interaction, and embedded data processing, and have the potential to become a new type of mobile payment terminal, making it an important research and development direction in the field of terminal technology.

[0003] However, to ensure payment security, conventional smart glasses-based payment methods rely on users' voice commands to trigger the payment process and require cloud-based voice verification before the payment can be completed. This solution suffers from drawbacks such as long transaction times, low efficiency, and user acceptance barriers, resulting in a poor user experience. Summary of the Invention

[0004] This application provides a method, device, and system for making payments through smart glasses. It enables fast payments through smart glasses while ensuring payment authentication security. The entire payment process does not require complex voice interaction, which can significantly improve payment interaction efficiency and effectively enhance user experience.

[0005] To achieve the above objectives, this application adopts the following technical solution: Firstly, a method for making payments via smart glasses is provided. This method is applied to a user device, which establishes a communication connection with the smart glasses. The user device stores the trusted possession authentication status of the smart glasses, which is stored after the user device verifies the smart glasses. The method may include: receiving a first payment request from the smart glasses, the first payment request carrying pending payment information; determining that the trusted possession authentication status of the smart glasses is valid; sending a second payment request to a server, the second payment request carrying pending payment information; and sending a message indicating successful payment to the smart glasses based on the server's payment response.

[0006] Through the technical solution provided in the first aspect, the user device establishes a communication connection with the smart glasses. The user device pre-stores the trusted possession authentication status of the smart glasses. When the user uses the smart glasses to make a payment, the user device can receive a first payment request from the smart glasses carrying payment information. Based on the pre-stored trusted possession authentication status of the smart glasses, the user device quickly determines whether the status is valid. After confirming that the trusted possession authentication status of the smart glasses is valid, the user device can send the valid status and a second payment request carrying payment information to the server. The server performs risk verification on the payment authorization of the smart glasses. After the risk verification is passed, the server can process the payment. After the server successfully completes the payment, the user device can send a message indicating successful payment to the smart glasses based on the server's payment success response. The solution provided in this application pre-adds smart glasses as a trusted possession of the user device and saves the trusted possession authentication status of the smart glasses. When using smart glasses for payment, it is only necessary to determine whether the smart glasses have payment authorization based on the pre-saved trusted possession authentication status of the smart glasses. This enables fast payment through smart glasses while ensuring payment identity verification security. The entire payment process does not require complex voice interaction, which can significantly improve payment interaction efficiency and effectively improve user experience.

[0007] As an example, in the fields of identity authentication and trusted interaction, a trusted possession refers to a physical carrier that a device (such as smart glasses, smartwatches, and smart helmets) can legally and securely possess and can serve as the basis for identity verification, authorization verification, and trusted interaction. Specifically, smart glasses, as a trusted possession of a user device, have a trusted possession authentication status that includes both valid and invalid states. When a user uses smart glasses to make a payment, if the trusted possession authentication status of the smart glasses is valid, then the smart glasses have payment authorization; if the trusted possession authentication status of the smart glasses is invalid, then the smart glasses do not have payment authorization.

[0008] As an example, the first payment request refers to an instruction message sent by the smart glasses to the user device to trigger the payment process. This instruction message may include, but is not limited to, pending payment information and the identifier of the smart glasses. Optionally, the instruction message may also include status indication information indicating that the trusted possession authentication status of the smart glasses on the smart glasses side is valid. The pending payment information may be a payment code, which can be a QR code, barcode, or other form of graphic encoding; this application does not limit this. The pending payment information may include, but is not limited to, the amount, merchant number and / or merchant name, and order number; this application does not limit this either.

[0009] As an example, the second payment request refers to a payment request message sent by the user device that can be processed in the background. This payment request message can be used to trigger the server to perform risk verification and payment processing. The payment request message may include, but is not limited to, pending payment information, the identifier of the smart glasses, and the identifier of the user device. Optionally, the payment request message may also include information indicating that the trusted possession authentication status of the smart glasses is valid. The pending payment information may include, but is not limited to, the amount, merchant number and / or merchant name, and order number; this application does not limit this.

[0010] As one possible implementation, before sending the second payment request to the server, the method further includes determining whether the current time falls within the available time corresponding to the valid state. It can be understood that before the user device sends the second payment request to the server, it also needs to determine whether the current time falls within the available time corresponding to the valid state; if the current time does not fall within the available time corresponding to the valid state, then the smart glasses do not have payment authorization. Thus, by managing the lifecycle of its valid state, the system can avoid the risk of long-term validity after a successful verification, preventing the smart glasses from being lost or stolen and misused.

[0011] As an example, the available time mentioned above may include, but is not limited to: the start time, end time, and duration of the valid state.

[0012] As one possible implementation, before receiving the first payment request, the method further includes: the user device verifying the smart glasses, using one or more of the following methods: verification code, account synchronization, Bluetooth pairing, fingerprint, password, facial features, and voice features; after successful verification, the smart glasses are added as a trusted possession of the user device, and the trusted possession authentication status of the smart glasses is saved as valid. It can be understood that before a user uses the smart glasses for payment, the user device can verify the smart glasses, and after successful verification, add the smart glasses as a trusted possession of the user device and save its trusted possession authentication status as valid. The methods by which the user device verifies the smart glasses can include one or more of the above. Thus, on the one hand, by verifying the smart glasses, adding them as a trusted possession of the user device after successful verification, and saving their trusted possession authentication status, when using the smart glasses for payment, it is only necessary to determine whether the smart glasses have payment permissions based on the pre-saved trusted possession authentication status. This allows for fast payment through the smart glasses while ensuring payment authentication security. The entire payment process does not require complex voice interaction, significantly improving payment interaction efficiency and effectively enhancing the user experience. On the other hand, by using one or more of the above verification methods, the security of payments can be further improved. At the same time, users can choose different verification methods according to their own habits, which effectively improves the user experience.

[0013] As one possible implementation, the above verification occurs when the user device establishes a communication connection with the smart glasses. It is understood that the user device can verify the smart glasses while establishing a communication connection.

[0014] As one possible implementation, after the above verification is successful, the method further includes: the user device sending the trusted possession authentication status of the smart glasses to the smart glasses. It can be understood that after the user device verifies the smart glasses and obtains the trusted possession authentication status, it can not only save the trusted possession authentication status of the smart glasses on the user device, but also synchronize the trusted possession authentication status of the smart glasses to the smart glasses, which can also save it. Thus, by synchronously updating the trusted possession authentication status of the smart glasses on both the user device and smart glasses sides, the authentication status on both sides can be kept consistent, improving payment security and facilitating unified management. For example, if the smart glasses are lost, the valid status can be canceled on the user device side, the trusted possession authentication status of the smart glasses becomes invalid, and the smart glasses will synchronously update its saved trusted possession authentication status to the invalid state, preventing the risk of misuse after the smart glasses are lost or stolen.

[0015] As one possible implementation, the above method includes: receiving status indication information from the smart glasses, the status indication information indicating that the trusted possession authentication status of the smart glasses is valid; determining that the trusted possession authentication status of the smart glasses is valid includes: determining that the trusted possession authentication status of the smart glasses is valid based on the status indication information. It is understood that the smart glasses can also store the trusted possession authentication status of the smart glasses. When the user device determines that the trusted possession authentication status of the smart glasses is valid, the smart glasses can send the valid status stored on the smart glasses side to the user device after confirming that the trusted possession authentication status stored on the smart glasses side is valid. The user device can then determine that the trusted possession authentication status of the smart glasses is valid based on this status indication information. This reduces the computational overhead and power consumption on the user device side, reduces the user device's reliance on real-time network connectivity, significantly improves payment interaction efficiency, and effectively improves the user experience.

[0016] As one possible implementation, before the user device and smart glasses establish a communication connection, the trusted possession authentication status of the smart glasses is in an invalid state. The reasons for this invalid state include one or more of the following: the smart glasses are disconnected from the user device, the duration of the connection between the smart glasses and the user device exceeds a time threshold, the distance between the smart glasses and the user device exceeds a distance threshold, or the smart glasses are not being worn. It can be understood that when the user device and smart glasses have not established a communication connection, the user device has not yet verified the smart glasses, and the trusted possession authentication status of the smart glasses is invalid. The reasons for the trusted possession authentication status of the smart glasses changing from valid to invalid can include, but are not limited to: the smart glasses are disconnected from the user device, the duration of the connection between the smart glasses and the user device exceeds a time threshold, the distance between the smart glasses and the user device exceeds a distance threshold, or the smart glasses are not being worn. When the smart glasses lose communication with the user device, to prevent the risk of loss or misuse due to theft, the trusted possession authentication status of the smart glasses will automatically be updated to an invalid state. Similarly, when the connection between the smart glasses and the user device exceeds a certain duration threshold, the trusted possession authentication status will automatically be updated to an invalid state to prevent loss or misuse due to theft. Furthermore, when the smart glasses are not being worn, the trusted possession authentication status will automatically be updated to an invalid state to prevent loss or misuse due to theft. This further enhances payment security.

[0017] As an example, the reasons mentioned above that cause the trusted possession authentication status of smart glasses to be automatically updated to an invalid state include: the trusted possession authentication status of smart glasses stored on the user device side and the smart glasses side being synchronously updated to an invalid state.

[0018] As one possible implementation, in response to the second operation of canceling the valid state, the trusted possession authentication status of the smart glasses is changed to an invalid state. It is understood that users can choose to cancel the valid state and change the trusted possession authentication status of the smart glasses to an invalid state according to their own usage habits. This can meet different user needs and improve the user experience.

[0019] As an example, the second operation to cancel the valid state mentioned above may include, but is not limited to: clicking a preset button on the smart glasses application interface of the user device, clicking a preset button on the settings interface of the user device, or clicking a preset button on the smart glasses.

[0020] As one possible implementation, adding smart glasses as a trusted holder of a user device includes: in response to a third operation, adding the smart glasses as a trusted holder of the user device. The third operation may include, but is not limited to: clicking a preset button on the smart glasses application interface of the user device, clicking a preset button on the user device's settings interface, or clicking a preset button on the smart glasses. Thus, before using the smart glasses for payment, users can add the smart glasses as a trusted holder of the user device in advance and save the trusted holder authentication status of the smart glasses according to their needs. When using the smart glasses for payment, users only need to verify the pre-saved trusted holder authentication status of the smart glasses to confirm their payment authorization. This allows for fast payment through the smart glasses while ensuring payment authentication security. The entire payment process does not require complex voice interaction, significantly improving payment interaction efficiency and effectively enhancing the user experience. It should be noted that the preset buttons on the smart glasses application interface corresponding to the second operation are different from the preset buttons on the smart glasses application interface corresponding to the third operation; the preset buttons on the user device settings interface corresponding to the second operation are different from the preset buttons on the user device settings interface corresponding to the third operation; and the preset buttons on the smart glasses corresponding to the second operation are different from the preset buttons on the smart glasses corresponding to the third operation.

[0021] Secondly, a method for making payments via smart glasses is provided. The method is applied to smart glasses that have a communication connection with a user device. The method includes: in response to a first operation on the smart glasses, obtaining payment information; sending a first payment request to the user device, the first payment request carrying the payment information; and receiving a message from the user device indicating successful payment.

[0022] Through the technical solution provided in the second aspect, the smart glasses establish a communication connection with the user device. When the user uses the smart glasses to make a payment, the smart glasses respond to the first operation and can obtain the payment information. After obtaining the payment information, it can send a first payment request containing the payment information to the user device. After the user device and the server complete the above-mentioned operations such as valid status confirmation, risk verification, and payment processing in the first aspect, it receives a message from the user device indicating successful payment. The advantages and effects of the second aspect can be referred to the description of the first aspect above, and will not be repeated here.

[0023] As one possible implementation, the first operation described above is an operation for quickly triggering payment. This first operation includes: clicking a preset payment button, long-pressing a preset payment button, triggering payment with a preset facial expression, and triggering payment with a preset body movement. It is understood that, compared to the existing technology of triggering payment via voice commands, the one or more simple and quick payment triggering operations provided in this application can not only meet the needs of different users but also improve payment interaction efficiency and effectively enhance the user experience.

[0024] As an example, the above-mentioned operation of clicking the preset payment button may include, but is not limited to: single-clicking the preset payment button, double-clicking the preset payment button; preset facial expression triggering operation may include, but is not limited to: blinking twice in succession, nodding, shaking the head; preset body movement triggering operation may include, but is not limited to: palm facing the smart glasses, completing continuous hand movements according to a preset sliding trajectory.

[0025] As one possible implementation, the above method further includes: receiving the trusted possession authentication status of the smart glasses from the user device, wherein the trusted possession authentication status of the smart glasses is valid; and saving the trusted possession authentication status of the smart glasses as valid. It can be understood that after the user device verifies the smart glasses and obtains the trusted possession authentication status of the smart glasses, it can also synchronize the trusted possession authentication status of the smart glasses with the smart glasses, and the smart glasses can save it. The advantages and effects of this feature can be referred to the description of a possible implementation in the first aspect above, and will not be repeated here.

[0026] As one possible implementation, the above method includes: sending status indication information to a user device, the status indication information indicating that the trusted possession authentication status of the smart glasses is valid. It is understood that the smart glasses may also store the trusted possession authentication status of the smart glasses. When the user device determines that the trusted possession authentication status of the smart glasses is valid, the smart glasses can, after determining that the trusted possession authentication status stored on the smart glasses side is valid, send this valid status to the user device. The user device can then determine that the trusted possession authentication status of the smart glasses is valid based on this status indication information. The advantages and effects of this feature can be referred to the description of a possible implementation in the first aspect above, and will not be repeated here.

[0027] As one possible implementation, the trusted possession authentication status of the smart glasses also includes the available time corresponding to the valid status. It can be understood that after the user device determines that the trusted possession authentication status of the smart glasses is valid, it also needs to determine whether the current moment is within the available time corresponding to that valid status; if the current moment is not within the available time corresponding to that valid status, then the smart glasses do not have payment authorization. The advantages and effects of this feature can be referred to the description of a possible implementation in the first aspect mentioned above, and will not be repeated here.

[0028] As one possible implementation, before the smart glasses establish the communication connection with the user device, the trusted possession authentication status of the smart glasses is in an invalid state. The reasons for this invalid state include one or more of the following: the smart glasses are disconnected from the user device, the duration of the connection between the smart glasses and the user device exceeds a time threshold, the distance between the smart glasses and the user device exceeds a distance threshold, or the smart glasses are not being worn. It is understood that when the user device and the smart glasses have not established a communication connection, the user device has not yet verified the smart glasses, and the trusted possession authentication status of the smart glasses is invalid. The reasons for the trusted possession authentication status of the smart glasses changing from an valid state to an invalid state may include, but are not limited to: the smart glasses are disconnected from the user device, the duration of the connection between the smart glasses and the user device exceeds a time threshold, the distance between the smart glasses and the user device exceeds a distance threshold, or the smart glasses are not being worn. When the duration of connection between the smart glasses and the user device exceeds a certain threshold, the trusted possession authentication status of the smart glasses will automatically be updated to an invalid state to prevent the risk of loss, theft, or misuse. Similarly, when the distance between the smart glasses and the user device exceeds a certain distance threshold, the trusted possession authentication status will automatically be updated to an invalid state to prevent the risk of loss, theft, or misuse. Furthermore, when the smart glasses are not being worn, the trusted possession authentication status will automatically be updated to an invalid state to prevent the risk of loss, theft, or misuse. The advantages and effects of this feature can be found in the description of a possible implementation in the first aspect mentioned above, and will not be repeated here.

[0029] Thirdly, this application provides a user equipment comprising: a transceiver, one or more memories, and one or more processors. The transceiver is used to communicate with other devices, and the memories are used to store program code, including computer program instructions. When the computer program instructions are executed by the user equipment, the user equipment performs the method described in the first aspect and any of its possible design embodiments.

[0030] Fourthly, this application provides smart glasses, which include: a transceiver, one or more memories, and one or more processors. The transceiver is used to communicate with other devices, and the memories are used to store program code, including computer program instructions. When the computer program instructions are executed by a user device, the smart glasses cause the smart glasses to implement the method described in the second aspect and any of its possible design embodiments.

[0031] Fifthly, this application provides a payment system via smart glasses, the system comprising a user device, smart glasses, and a server. The user device is used to implement the method described in the first aspect and any possible design thereof, and the smart glasses are used to implement the method described in the second aspect and any possible design thereof.

[0032] In a sixth aspect, this application provides a readable storage medium storing a program and / or instructions that, when executed by a processor, implement the method as described in any possible implementation of the first or second aspect.

[0033] In a seventh aspect, this application provides a program product containing instructions that, when the program product is run on a user device, causes the user device to implement the method as described in the first aspect and any possible implementation thereof; and when the program product is run on smart glasses, causes the smart glasses to implement the method as described in the second aspect and any possible implementation thereof.

[0034] Eighthly, this application provides a chip system including processing circuitry and a storage medium storing program instructions; when executed by the processing circuitry, the program instructions implement the methods described in the first aspect and / or the second aspect and any possible implementation thereof. The chip system may be composed of chips or may include chips and other discrete devices. Attached Figure Description

[0035] Figure 1 A system architecture diagram of a conventional smart glasses-based payment method provided for embodiments of this application; Figure 2 A scenario diagram illustrating a method for making payments via smart glasses, provided as an embodiment of this application; Figure 3 This is a schematic diagram of the hardware structure of a user equipment provided in an embodiment of this application; Figure 4 A schematic diagram of the hardware structure of smart glasses provided in an embodiment of this application; Figure 5 A system architecture diagram of a method for making payments via smart glasses provided in this application embodiment; Figure 6 A flowchart illustrating a method for making payments via smart glasses, provided as an embodiment of this application; Figure 7 A schematic diagram illustrating a first operation provided in an embodiment of this application; Figure 8 A schematic diagram of an interface for a third operation provided in an embodiment of this application; Figure 9A flowchart illustrating the synchronous update of the trusted possession authentication status of smart glasses on both the user device side and the smart glasses side, provided as an embodiment of this application; Figure 10 This is a schematic diagram of a chip system provided in an embodiment of this application. Detailed Implementation

[0036] The technical solutions of the embodiments of this application will be described below with reference to the accompanying drawings. In the description of the embodiments of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B; "and / or" in this text is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Furthermore, in the description of the embodiments of this application, "multiple" refers to two or more than two.

[0037] Hereinafter, the terms "first," "second," etc., are used only to distinguish different descriptive objects and do not limit the position, order, priority, quantity, or content of the described objects. For example, when the descriptive object is a "payment request," "first payment request" and "second payment request" do not imply whether the "payment requests" are the same. The use of ordinal numbers and other prefixes used to distinguish descriptive objects in the embodiments of this application does not constitute a limitation on the described objects. The description of the described objects is given in the claims or the context of the embodiments, and should not be construed as creating unnecessary limitations due to the use of such prefixes.

[0038] Furthermore, in the embodiments of this application, "connection" can be a direct connection or an indirect connection; in addition, it can refer to an electrical connection or a communication connection; for example, the connection of two electrical components A and B can refer to A and B being directly connected, or it can refer to A and B being indirectly connected through other electrical components or connection media, or it can refer to A and B being indirectly connected through other communication devices or communication media, as long as it enables communication between A and B.

[0039] With the rapid development of mobile payment technology, payment terminals have expanded from handheld smart devices such as smartphones to various IoT wearable smart devices such as smart glasses, in order to adapt to handsless and convenient payment scenarios. Among them, developing smart glasses as mobile payment terminals has become an important development direction in the field of terminal technology.

[0040] Conventional smart glasses-based payment methods primarily rely on voice commands. For an example, please refer to [link / reference needed]. Figure 1 , Figure 1This application provides a system architecture diagram for a conventional smart glasses-based payment method. The system includes smart glasses, a main device, and a server. The smart glasses may include, but are not limited to, an image acquisition module, an audio acquisition module, an audio playback module, and a data transmission module. The main device may include, but is not limited to, a voiceprint recording service and a data transmission module. The server may include, but is not limited to, a risk control service, a payment service, and a data transmission module. This method is based on voiceprint authentication technology. During the payment process, the smart glasses' audio acquisition module collects the user's voiceprint information in real time and transmits it to the connected main device (such as a smartphone or tablet) via its data transmission module. The main device's voiceprint recording service receives the voiceprint information from the smart glasses and uploads it to the server via its data transmission module. The server then compares and authenticates the information. Only after successful authentication can the payment transaction be completed.

[0041] As an example, please refer to Figure 1 The specific implementation process of conventional smart glasses-based payment methods may include, but is not limited to: S1, Voice wake-up device.

[0042] Users can wake up the smart glasses with their voice. The smart glasses use their audio acquisition module to collect the user's voiceprint information in real time, and then transmit the collected voiceprint information to the connected main device through their data transmission module. For example, a user can say a wake word, such as "Hello glasses, I want to pay." After the smart glasses collect this wake word through their audio acquisition module, they can recognize the user's intent through the wake word and transmit it to the connected main device through their data transmission module, thus activating the main device's payment application.

[0043] S2, Start scanning.

[0044] After activating the payment application on both the smart glasses and the main device, the user needs to point the glasses at the QR code containing payment information. The smart glasses then capture the QR code image information through their image acquisition module and transmit it to the connected main device through their data transmission module. For example, the smart glasses can use voice prompts, such as "Please look at the QR code," to guide the user to adjust their head posture so that the QR code image information is within their field of vision. The smart glasses then capture the QR code image information through their image acquisition module and transmit it to the main device through their data transmission module for decoding.

[0045] S3. Confirmation of payment information.

[0046] After the main device decodes the QR code image information, it can obtain specific payment information (such as merchant information, payment amount, etc.). The main device can then transmit the payment information to the server and smart glasses via its data transmission module. The smart glasses can then confirm the payment information to the user via voice announcement. For example, the smart glasses can announce the confirmation information via its audio announcement module, such as "Pay XXX yuan to XXX". After hearing the payment information, the user can speak a confirmation command, such as "Confirm payment".

[0047] S4, voiceprint core.

[0048] The audio acquisition module of the smart glasses collects the user's voiceprint information in real time, and transmits the voiceprint information containing confirmation instructions to the main device through its data transmission module. The voiceprint recording service of the main device can receive the voiceprint information containing confirmation instructions from the smart glasses, and upload the voiceprint information to the server through its data transmission module. The server then uses the voiceprint information to verify the user's identity.

[0049] S5. Payment result feedback.

[0050] After receiving payment and voiceprint information from the main device, the server's data transmission module can collaborate with the payment service and risk control service to complete transaction security verification. Specifically, the risk control service compares the voiceprint information to verify user identity and simultaneously verifies the accuracy of the payment information. Based on the verification result of the risk control service, the server can return the final payment result. If the risk control verification passes, the payment service will initiate a deduction request to the bank system. After successful deduction, the server can return the "payment successful" result to the main device through the data transmission module, which then forwards it to the smart glasses. The smart glasses can then inform the user of the final payment result as "payment successful" through their audio broadcast module. If the risk control verification fails, no deduction request will be initiated. The server will directly return the "payment failed" result to the main device through the data transmission module, which then forwards it to the smart glasses. The smart glasses can then inform the user of the final payment result as "payment failed" through their audio broadcast module.

[0051] As mentioned above, conventional payment methods based on smart glasses involve multiple voice interaction steps, such as voice wake-up of the device, initiating scanning, confirmation of payment information, and voiceprint verification. This results in a lengthy overall transaction process from the user's intention to pay to receiving confirmation of successful payment. In scenarios requiring efficient payment, such as supermarkets, fast food restaurants, and highway toll stations, this voice-based payment method significantly reduces payment efficiency. Furthermore, most users still have reservations about using voice payment in public places, resulting in limited acceptance and psychological and operational barriers in actual use. Ultimately, this leads to a poor user experience when using smart glasses for payments.

[0052] To address the aforementioned problems, this application provides a method for making payments via smart glasses, which can be applied to, for example... Figure 2 In the application scenario shown, the user device (such as a smartphone) establishes communication connections with both the smart glasses and the server. The user device pre-stores the trusted possession authentication status of the smart glasses. When the user makes a payment through the smart glasses, the user device can quickly determine whether the pre-stored trusted possession authentication status is valid. After confirming that the trusted possession authentication status of the smart glasses is valid, the user device can send the valid status and a payment request carrying the payment information to the server, which then performs subsequent risk verification and payment processing. Compared to conventional smart glasses-based payment methods, the solution provided in this application pre-adds the smart glasses as a trusted possession of the user device. When using the smart glasses for payment, it only needs to determine whether the smart glasses have payment permissions based on the pre-stored trusted possession authentication status. This allows for fast payment through smart glasses while ensuring payment authentication security. The entire payment process does not require complex voice interaction, significantly improving payment interaction efficiency and effectively enhancing the user experience.

[0053] For example, the user device provided in this application embodiment may specifically be a smartphone, tablet computer, handheld computer, in-vehicle computer, personal computer (PC), personal digital assistant (PDA), augmented reality (AR) device, virtual reality (VR) device, etc. This application embodiment does not impose any limitation on the specific type of user device. For example, the user device may be such as... Figure 2 The smartphone shown.

[0054] As an example, the method provided in this application embodiment can also be applied to other IoT wearable smart devices besides smart glasses, such as smartwatches, smart helmets, etc.

[0055] As an example, user devices and smart glasses can communicate via Bluetooth, Wireless Fidelity (WF), or Wi-Fi. Communication connections can be established through methods such as Wi-Fi and near-field communication (NFC); ​​user equipment and servers can communicate via mobile communication networks, Wi-Fi, etc. Communication connections can be established using methods such as Fi and USB network sharing.

[0056] The embodiments of this application will now be described in detail with reference to the accompanying drawings. Please refer to... Figure 3 and Figure 4 , Figure 3 This is a schematic diagram of the hardware structure of a user equipment provided in an embodiment of this application. Figure 4 This is a schematic diagram of the hardware structure of a smart glasses provided in an embodiment of this application.

[0057] like Figure 3 As shown, the user equipment may include, but is not limited to: processor 310, external memory interface 320, internal memory 321, universal serial bus (USB) interface 330, charging management module 340, power management module 341, battery 342, antenna 1, antenna 2, mobile communication module 350, wireless communication module 360, audio module 370, speaker 370A, receiver 370B, microphone 370C, headphone jack 370D, sensor module 380, button 390, motor 391, indicator 392, camera 393, display screen 394, and subscriber identification module (SIM) card interface 395.

[0058] The aforementioned sensor module 380 may include sensors such as pressure sensors, gyroscope sensors, barometric pressure sensors, magnetic sensors, accelerometers, distance sensors, proximity sensors, fingerprint sensors, temperature sensors, touch sensors, ambient light sensors, and bone conduction sensors.

[0059] It is understood that the structure illustrated in this embodiment does not constitute a specific limitation on the user equipment. In other embodiments, the user equipment may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0060] Processor 310 may include one or more processing units, such as: application processor (AP), modem processor, graphics processing unit (GPU), image signal processor (ISP), controller, memory, video codec, digital signal processor (DSP), baseband processor, and / or neural network processing unit (NPU), etc. Different processing units may be independent devices or integrated into one or more processors.

[0061] The controller can serve as the nerve center and command center of the user equipment. Based on the instruction opcode and timing signals, the controller generates operation control signals to control the fetching and execution of instructions.

[0062] The processor 310 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 310 is a cache memory. This memory can store instructions or data that the processor 310 has just used or that are used repeatedly. If the processor 310 needs to use the instruction or data again, it can retrieve it directly from the memory. This avoids repeated accesses, reduces the waiting time of the processor 310, and thus improves the efficiency of the system.

[0063] In some embodiments of this application, the processor 310 is used to determine that the trusted possession authentication status of the smart glasses is valid; and according to the payment response from the server, instructs the wireless communication module 360 ​​to send a message indicating successful payment to the smart glasses.

[0064] In some embodiments of this application, the processor 310 is also used for the user equipment to verify the smart glasses; after successful verification, the smart glasses are added as a trusted possession of the user equipment, and the trusted possession authentication status of the smart glasses is saved as valid.

[0065] In some embodiments of this application, the processor 310 is also configured to determine that the current time is within the available time corresponding to the valid state.

[0066] In some embodiments of this application, the processor 310 is further configured to determine, based on status indication information, that the trusted possession authentication status of the smart glasses is the valid status.

[0067] In some embodiments of this application, the processor 310 is also configured to modify the trusted possession authentication status of the smart glasses to an invalid status in response to a second operation that cancels the valid status.

[0068] In some embodiments of this application, the processor 310 is also configured to add the smart glasses as a trusted holder of the user device in response to a third operation.

[0069] The wireless communication function of the user equipment can be implemented through antenna 1, antenna 2, mobile communication module 350, wireless communication module 360, modem processor, and baseband processor.

[0070] The wireless communication module 360 ​​can provide solutions for wireless communication applications on user devices, including wireless local area networks (WLAN) (such as Wi-Fi networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), NFC, and infrared (IR) technologies. The wireless communication module 360 ​​can be one or more devices integrating at least one communication processing module. The wireless communication module 360 ​​receives electromagnetic waves via antenna 2, performs frequency modulation and filtering of the electromagnetic wave signal, and sends the processed signal to processor 310. The wireless communication module 360 ​​can also receive signals to be transmitted from processor 310, perform frequency modulation and amplification, and convert them into electromagnetic waves for radiation via antenna 2.

[0071] In some embodiments, the user equipment's antenna 1 is coupled to the mobile communication module 150, and the antenna 2 is coupled to the wireless communication module 160, enabling the user equipment to communicate with the network and other devices via wireless communication technology.

[0072] In some embodiments of this application, the wireless communication module 360 ​​is used to receive a first payment request from the smart glasses and send a second payment request to the server.

[0073] In some embodiments of this application, the wireless communication module 360 ​​is also used to send the trusted possession authentication status of the smart glasses to the smart glasses.

[0074] In some embodiments of this application, the wireless communication module 360 ​​is also used to receive status indication information from the smart glasses.

[0075] Display screen 394 is used to display images, videos, etc. Display screen 394 includes a display panel. The display panel can be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), a quantum dot light-emitting diode (QLED), etc.

[0076] User devices can achieve shooting functions through ISP, camera 393, video codec, GPU, display 394, and application processor.

[0077] The ISP (Image Signal Processor) processes data fed back from the camera 393. For example, when taking a picture, the shutter is opened, and light is transmitted through the lens to the camera's image sensor. The light signal is converted into an electrical signal, and the image sensor transmits this electrical signal to the ISP for processing, transforming it into a visible image. The ISP can also perform algorithmic optimizations on image noise and brightness. Furthermore, the ISP can optimize parameters such as exposure and color temperature for the shooting scene.

[0078] Camera 393 is used to capture still images or videos. An object passes through the lens, generating an optical image that is projected onto a photosensitive element. This photosensitive element can be a charge-coupled device (CCD) or a complementary metal-oxide-semiconductor (CMOS) phototransistor. The photosensitive element converts the light signal into an electrical signal, which is then passed to an ISP (Image Signal Processor) for conversion into a digital image signal. The ISP outputs the digital image signal to a DSP (Digital Signal Processor) for further processing. The DSP converts the digital image signal into standard image signals in formats such as RGB and YUV.

[0079] The external storage interface 320 can be used to connect an external storage card, such as a Micro SD card, to expand the storage capacity of the user device 300. The external storage card communicates with the processor 310 through the external storage interface 320 to perform data storage functions. For example, music, video, and other files can be saved on the external storage card.

[0080] Internal memory 321 can be used to store computer executable program code, which includes instructions. Processor 310 executes various functional applications and data processing of user equipment 300 by running the instructions stored in internal memory 321. For example, in this embodiment, processor 310 can execute instructions stored in internal memory 321, which may include a program storage area and a data storage area.

[0081] The program storage area can store the operating system and at least one application program required for a function (such as sound playback, image playback, etc.). The data storage area can store data created during the use of the user device 300. In addition, the internal memory 321 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, universal flash storage (UFS), etc.

[0082] User equipment can implement audio functions such as music playback and recording through audio module 370, speaker 370A, receiver 370B, microphone 370C, headphone jack 370D, and application processor.

[0083] For details regarding the charging management module 340, power management module 341, battery 342, antenna 1, antenna 2, mobile communication module 350, audio module 370, sensor module 380, button 390, motor 391, indicator 392, and SIM card interface 395, please refer to conventional technologies.

[0084] like Figure 4 As shown, smart glasses may include, but are not limited to: processor 410, internal memory 420, charging management module 430, power management module 431, battery 432, antenna 1 and antenna 2, mobile communication module 440, wireless communication module 450, audio module 460, speaker 460A, microphone 460B, sensor module 470, button 480, and camera 490.

[0085] The buttons 480 include a power button, volume buttons, an image capture button, a fingerprint recognition button, a facial feature capture button, a facial expression recognition button, a body motion recognition button, and a preset payment button. Buttons 480 can be mechanical or touch-sensitive. The smart glasses can receive button input and generate key signal inputs related to user settings and function control.

[0086] In some embodiments of this application, button 480 can be used to quickly trigger payment.

[0087] In some embodiments of this application, the processor 410 is configured to obtain payment information in response to a first operation on the smart glasses.

[0088] In some embodiments of this application, the processor 410 is also used to save the trusted possession authentication status of the smart glasses as valid.

[0089] In some embodiments of this application, the wireless communication module 450 is used to send a first payment request to the user equipment and receive a message from the user equipment indicating that the payment was successful.

[0090] In some embodiments of this application, the wireless communication module 450 is also used to receive the trusted possession authentication status of the smart glasses from the user device.

[0091] In some embodiments of this application, the wireless communication module 450 is also used to send status indication information of the smart glasses to the user equipment.

[0092] For a detailed description of each hardware structure, please refer to the above description of the hardware structure of the user equipment; it will not be repeated here.

[0093] For example, Figure 5 This application provides a system architecture diagram for a method of making payments via smart glasses, which can be applied to, for example... Figure 2 The application scenario shown includes smart glasses, user devices, and a server. The smart glasses may include, but are not limited to: an image acquisition module 501, a data transmission module 502, a unified identity authentication module 503, and a secure storage module 504; the user devices may include, but are not limited to: a data transmission module 505, a unified identity authentication module 506, and a secure storage module 507; and the server may include, but is not limited to: a data transmission module 508, a payment service 509, and a risk control service 510.

[0094] As an example, the image acquisition module 501 in smart glasses can acquire information such as a QR code image containing payment information, user facial expressions, and user body movements.

[0095] The data transmission module 502 of the smart glasses can send the data collected by the image acquisition module 501 and the trusted possession authentication status (i.e., status indication information) of the smart glasses to the data transmission module 505 of the user device. It can also receive data sent by the user device (such as the trusted possession authentication status of the smart glasses, messages indicating successful payment, etc.).

[0096] The unified identity authentication module 503 of the smart glasses can determine that the trusted possession authentication status of the smart glasses is valid; it can also manage the trusted possession authentication status of the smart glasses.

[0097] The secure storage module 504 of the smart glasses can use encrypted storage to save the authentication status of the trusted holder of the smart glasses. The unified identity authentication module 503 and the secure storage module 504 of the smart glasses are optional modules and can be selectively configured according to actual needs.

[0098] As an example, the data transmission module 505 of the user device can engage in bidirectional data interaction with the smart glasses and the server. That is, the user device can receive data from the smart glasses and the server, and can also send data to the smart glasses and the server. For example, the data transmission module 505 of the user device can receive a first payment request from the smart glasses; send a second payment request to the server; send the trusted possession authentication status of the smart glasses to the smart glasses; and receive status indication information from the smart glasses, etc.

[0099] The unified identity authentication module 506 of the user device can determine that the trusted possession authentication status of the smart glasses is valid; it can also cooperate with the unified identity authentication module 503 on the smart glasses side to complete the cross-device valid status confirmation; and it can also manage the trusted possession authentication status of the smart glasses.

[0100] The user device's secure storage module 507 can use encrypted storage to save the trusted possession authentication status of the smart glasses.

[0101] In one possible implementation, the data interaction between the smart glasses and the user device employs a distributed security mechanism between devices to ensure secure data transmission. Specifically, this can involve: before data interaction, the user device can verify the smart glasses to ensure their legitimacy and trustworthiness; during data transmission, encryption algorithms can be used to prevent data from being stolen, tampered with, or forged in the transmission link; and within both the smart glasses and the user device, a trusted execution environment is used to isolate and securely process data such as the smart glasses' trusted ownership authentication status, keys, and device identifiers, preventing the leakage of critical data.

[0102] It should be noted that the above description of the distributed security mechanism between devices is merely illustrative, and this application does not limit its specific implementation.

[0103] As an example, the server's data transmission module 508 can receive data sent by the user device (such as the trusted possession authentication status of smart glasses, second payment requests, etc.) and can also return payment results to the user device.

[0104] The server's payment service 509 can provide capabilities such as payment order generation, payment channel integration, pending payment information processing, and transaction execution, and can receive payment requests from user devices and complete payment processing.

[0105] The server's risk control service 510 can perform risk verification on the payment permissions of smart glasses based on the trusted possession authentication status of smart glasses, second payment requests carrying payment information, device identifiers of smart glasses and user devices, historical data, etc., providing risk control and security verification support for payment service 509.

[0106] The specific responsibilities and interaction flows of each of the above modules and services will be explained in detail below. For example, as shown... Figure 6 The diagram shows a flowchart of a payment method using smart glasses according to an embodiment of this application. This method can be applied to a payment system comprising a user device, smart glasses, and a server. The user device establishes communication connections with both the smart glasses and the server. The user device and the smart glasses pre-store the trusted possession authentication status of the smart glasses, which is saved after the user device verifies the smart glasses. The method may include steps S601-S604: S601, the smart glasses respond to the first operation performed on the smart glasses by obtaining payment information.

[0107] When a user needs to make a payment through smart glasses, they can perform a first operation on the smart glasses. In response to this first operation, the smart glasses can obtain the payment information through their image acquisition module 501.

[0108] As an example, the first operation described above is an operation used to quickly trigger payment. The first operation may include, but is not limited to: clicking a preset payment button, long-pressing a preset payment button, sliding on a preset payment button (such as single-finger / two-finger / three-finger sliding), a preset facial expression trigger operation, and a preset body movement trigger operation. Specifically, clicking the preset payment button may include, but is not limited to: single-clicking the preset payment button, double-clicking the preset payment button; preset facial expression trigger operations may include, but are not limited to: blinking twice consecutively, nodding, shaking the head; preset body movement trigger operations may include, but are not limited to: having the palm facing the smart glasses, and performing continuous hand movements according to a preset sliding trajectory.

[0109] It should be noted that the first operation described above is merely illustrative. The first operation can also be performed at other locations on the smart glasses, such as sliding the temple or frame with one, two, or three fingers. This application does not limit this to any particular operation. Compared to conventional payment methods that require voice interaction, the simple and quick payment triggering method provided in this application not only meets the needs of different users but also improves payment interaction efficiency and effectively enhances the user experience.

[0110] As an example, the aforementioned payment information may be a QR code, which may be a QR code, barcode, or other form of graphic encoding. This application does not limit this. The payment information may include, but is not limited to: amount, merchant number and / or merchant name, and order number. This application does not limit this.

[0111] For example, such as Figure 7 As shown, when a user needs to make a payment through smart glasses, they can click the preset payment button on the smart glasses (i.e., the first operation). In response to the first operation, the smart glasses can capture an image of the payment code containing the payment information through its image acquisition module 501.

[0112] It should be noted that the first operation listed above is only an example. In a specific implementation, other first operations can be used to trigger the smart glasses to obtain payment information, and this application does not limit this. Furthermore, Figure 7 The shape, size, and position of the preset payment button shown are for illustrative purposes only and can be flexibly set in specific implementations. This application does not limit them.

[0113] S602, The smart glasses send the first payment request to the user device.

[0114] After obtaining the payment information in step S601, the smart glasses can send a first payment request carrying the aforementioned payment information to the user device through its data transmission module 502.

[0115] As an example, the first payment request refers to an instruction message sent by the smart glasses to the user device to trigger the payment process. This instruction message may include, but is not limited to, information about the payment to be made and the identifier of the smart glasses. Optionally, the instruction message may also include status indication information indicating that the trusted possession authentication status of the smart glasses on the smart glasses side is valid.

[0116] Correspondingly, the data transmission module 505 of the user equipment can receive a first payment request from the smart glasses carrying payment information. For a description of the first payment request, please refer to the relevant description in step S602 above; it will not be repeated here.

[0117] As an example, after receiving a first payment request from the smart glasses containing payment information, the user device can send the payment information to the server. The server can determine the amount, merchant number and / or merchant name, order number, etc., in the payment information based on the received payment information, and verify the validity of the payment information. The server then sends a confirmation message containing the amount, merchant number and / or merchant name, and order number back to the user device, which in turn sends it to the smart glasses. After receiving the confirmation message, the smart glasses can notify the user of the confirmation message via voice broadcast.

[0118] In one possible implementation, after receiving the confirmation information, the smart glasses may only notify the user of the confirmation information, and then the user device will execute step S603.

[0119] In another possible implementation, after receiving the confirmation information, the smart glasses can notify the user of the confirmation information, receive the user's feedback on the confirmation information, send the feedback to the user device, and then the user device executes step S603.

[0120] The aforementioned payment information can be a QR code, which can be a QR code, barcode, or other form of graphic encoding. The smart glasses can convert the collected QR code into a string and send it to the user's device; the user's device forwards it to the server, where the server parses it and performs the aforementioned verification operation based on the parsing result.

[0121] It should be noted that the content included in the above confirmation information is merely illustrative. In actual implementation, the confirmation information may contain more or less content, and this application does not limit this. Furthermore, after receiving the confirmation information, the smart glasses may notify the user of the confirmation information through other means besides voice broadcasting, and this application does not limit this as well.

[0122] In one possible implementation, before the user device receives the first payment request from the smart glasses, the user device can verify the smart glasses. Upon successful verification, the user device can add the smart glasses as a trusted holder and save its trusted holder authentication status as valid in the user device's secure storage module 507. This verification occurs when the user device and the smart glasses establish a communication connection; that is, before establishing a communication connection, the smart glasses' trusted holder authentication status is invalid.

[0123] As an example, in the fields of identity authentication and trusted interaction, a trusted object refers to a physical carrier that a device (such as smart glasses, smartwatches, and smart helmets) can legally and securely possess and can serve as the basis for identity verification, authorization verification, and trusted interaction. Specifically, smart glasses, as a trusted object of a user device, have a trusted object authentication status that includes both valid and invalid states. When a user uses smart glasses to make a payment, if the trusted object authentication status of the smart glasses is valid, then the smart glasses have payment authorization; if the trusted object authentication status of the smart glasses is invalid, then the smart glasses do not have payment authorization.

[0124] As an example, methods for user devices to verify smart glasses may include, but are not limited to: verification codes, account synchronization, Bluetooth pairing, fingerprints, passwords, facial features, and voice features. Using one or more of these verification methods can further enhance payment security. Furthermore, users can choose different verification methods according to their own habits, effectively improving the user experience.

[0125] As an example, after the user device successfully verifies the smart glasses, the user can perform a third operation. In response to this third operation, the user device can add the smart glasses as a trusted possession of the user device. This third operation may include, but is not limited to: clicking a preset button on the user device's smart glasses application interface, clicking a preset button on the user device's settings interface, or clicking a preset button on the smart glasses.

[0126] For example, such as Figure 8 As shown in (a), before the user device receives the first payment request from the smart glasses, the user can click the "Add as Trusted Holder" button (i.e., the third operation) in the smart glasses application on the user device. Then, the user device's display interface will pop up as shown in (a). Figure 8 The verification options shown in (b) can include, but are not limited to: verification code verification, fingerprint verification, and password verification; assuming the user selects password verification, the following pop-up will appear on the screen: Figure 8 In the password input box shown in (c), the user can pass verification after entering the correct password; as shown in (c). Figure 8 As shown in (d), after verification, the user device's display interface can prompt the user that "the smart glasses have been successfully added as a trusted holder of the user device, and its trusted holder authentication status has been saved as valid."

[0127] In one possible implementation, after the above verification is successful, the user device can not only store the trusted possession authentication status (here referring to the valid status) of the smart glasses in the user device's secure storage module 507, but also send the trusted possession authentication status of the smart glasses to the smart glasses through its data transmission module 505. Correspondingly, the smart glasses can receive the trusted possession authentication status of the smart glasses from the user device and store it in the smart glasses' secure storage module 504. In this way, by synchronously updating the trusted possession authentication status of the smart glasses on both the user device and smart glasses sides, the authentication status on both sides can be kept consistent, improving payment security and facilitating unified management.

[0128] For example, if the smart glasses are lost, the user can cancel the valid status on the user device side. Simultaneously, the smart glasses will update the stored trusted possession authentication status to invalid status to prevent the risk of the smart glasses being lost or stolen and misused.

[0129] In one possible implementation, to prevent the risk of smart glasses being lost or stolen and misused, the trusted possession authentication status of the smart glasses will be automatically updated to an invalid state when one or more of the following situations occur: the smart glasses are disconnected from the user device, the duration of the connection between the smart glasses and the user device exceeds a duration threshold, the distance between the smart glasses and the user device exceeds a distance threshold, or the smart glasses are not being worn.

[0130] As an example, the automatic update of the trusted possession authentication status of the smart glasses to an invalid state includes: the trusted possession authentication status of the smart glasses stored on the user device side and the smart glasses side being synchronously updated to an invalid state.

[0131] As an example, please refer to Figure 9 The process of synchronously updating the trusted possession authentication status of the smart glasses on both the user device side and the smart glasses side may include S901-S906: S901: The user unlocks the user device and establishes a communication connection between the user device and the smart glasses.

[0132] S902, The user equipment determines that the distance between the smart glasses and the user equipment does not exceed the distance threshold, and the smart glasses are being worn by the user.

[0133] As an example, when the distance between the smart glasses and the user device exceeds a distance threshold or when the smart glasses are not being worn by the user, the user device cannot verify the smart glasses, add them as a trusted possession of the user device, or send the trusted possession authentication status of the smart glasses to the smart glasses.

[0134] S903. The user equipment verifies the smart glasses, adds them as a trusted holder of the user equipment, and saves the trusted holder authentication status of the smart glasses as valid.

[0135] S904, The user equipment sends the valid status to the smart glasses.

[0136] S905. The smart glasses maintain the trusted possession authentication status of the smart glasses as valid.

[0137] S906. When the trusted possession authentication status of the smart glasses in the user device or smart glasses fails, the trusted possession authentication status of the smart glasses on the other side is updated synchronously.

[0138] As an example, when the trusted possession authentication status of the smart glasses changes from valid to invalid due to a disconnection between the smart glasses and the user device, the trusted possession authentication status of the smart glasses can be updated back to valid by executing steps S907-A to S910-A: S907-A: The user equipment reminds the user that the smart glasses have lost connection with the user equipment and the trusted possession authentication status of the smart glasses has failed.

[0139] S908-A: The user unlocks the user device and re-establishes the communication connection between the user device and the smart glasses.

[0140] S909-A, The user equipment determines that the distance between the smart glasses and the user equipment does not exceed the distance threshold, and the smart glasses are being worn by the user.

[0141] S910-A, The trusted holder authentication status of the smart glasses for user equipment updates is now valid.

[0142] After step S910-A, the trusted possession authentication status on the smart glasses side can be updated to a valid status by repeating steps S94-S905.

[0143] As another example, when the trusted possession authentication status of the smart glasses changes from valid to invalid due to the duration of the connection between the smart glasses and the user device exceeding a duration threshold, the trusted possession authentication status of the smart glasses can be updated back to valid by executing steps S907-B to S910-B: S907-B: If the user equipment reminds the user that the duration of the connection between the smart glasses and the user equipment exceeds a time threshold, the trusted possession authentication status of the smart glasses will be invalidated.

[0144] S908-B: The user unlocks the user device and re-establishes the communication connection between the user device and the smart glasses.

[0145] S909-B, The user equipment determines that the distance between the smart glasses and the user equipment does not exceed the distance threshold, and the smart glasses are being worn by the user.

[0146] S910-B, The trusted holder authentication status of the smart glasses for user equipment updates is now valid.

[0147] After step S910-B, the trusted possession authentication status on the smart glasses side can also be updated to a valid status by repeating steps S904-S905.

[0148] As another example, when the trusted possession authentication status of the smart glasses changes from valid to invalid due to the distance between the smart glasses and the user device exceeding the distance threshold, the user device can remind the user that the distance between the smart glasses and the user device exceeds the distance threshold, and the trusted possession authentication status of the smart glasses is invalid. After receiving the reminder, the user can adjust the distance between the smart glasses and the user device so that the distance between the two is less than or equal to the distance threshold; and unlock the user device again to re-establish the communication connection between the user device and the smart glasses. After confirming that the distance between the smart glasses and the user device does not exceed the distance threshold and that the smart glasses are worn by the user, the user device updates the trusted possession authentication status of the smart glasses to valid. Then, steps S904-S905 can be repeated to synchronously update the trusted possession authentication status on the smart glasses side to valid as well.

[0149] As another example, when the trusted possession authentication status of the smart glasses changes from valid to invalid due to the smart glasses not being worn, the user device can remind the user that the smart glasses are not being worn and the trusted possession authentication status of the smart glasses is invalid. After receiving the reminder, the user can put on the smart glasses again, unlock the user device, and re-establish the communication connection between the user device and the smart glasses. After confirming that the distance between the smart glasses and the user device does not exceed the distance threshold and that the smart glasses are being worn by the user, the user device updates the trusted possession authentication status of the smart glasses to valid. Then, steps S904-S905 can be repeated to synchronously update the trusted possession authentication status on the smart glasses side to valid as well.

[0150] It should be noted that the reasons listed above for causing the trusted possession authentication status of smart glasses to change from valid to invalid are merely illustrative examples, and this application does not limit them. Furthermore, the specific values ​​of the aforementioned duration threshold and distance threshold can be flexibly set according to the actual scenario; for example, the duration threshold can be 4 hours, and the distance threshold can be 10 meters. This application's embodiments do not limit these values ​​either.

[0151] In one possible implementation, users can choose to cancel the valid state and change the trusted possession authentication status of the smart glasses to an invalid state based on their own usage habits. Specifically, in response to the user's second operation of canceling the valid state, the trusted possession authentication status of the smart glasses is changed to an invalid state. This second operation of canceling the valid state may include, but is not limited to: clicking a preset button on the user's device's smart glasses application interface, clicking a preset button on the user's device's settings interface, or clicking a preset button on the smart glasses.

[0152] The illustration of the second operation can be found in [reference needed]. Figure 8 This will not be elaborated further here. It is important to note that the preset buttons on the smart glasses application interface corresponding to the second operation are different from those on the smart glasses application interface corresponding to the third operation; the preset buttons on the user device settings interface corresponding to the second operation are different from those on the user device settings interface corresponding to the third operation; and the preset buttons on the smart glasses corresponding to the second operation are different from those on the smart glasses corresponding to the third operation.

[0153] S603. The user equipment determines that the trusted possession authentication status of the smart glasses is valid and sends a second payment request to the server.

[0154] In one possible implementation, the method by which the user equipment determines that the trusted possession authentication status of the smart glasses is valid can be as follows: After receiving the first payment request from the smart glasses, the user equipment can read the pre-saved trusted possession authentication status of the smart glasses from its secure storage module 507 through its unified identity authentication module 506, and after determining that the trusted possession authentication status of the smart glasses is valid, send the valid status and a second payment request carrying the payment information to the server.

[0155] As an example, the second payment request refers to a payment request message sent by the user device that can be processed in the background. This payment request message can be used to trigger the server to perform risk verification and payment processing. The payment request message may include, but is not limited to, pending payment information, the identifier of the smart glasses, and the identifier of the user device. Optionally, the payment request message may also include information indicating that the trusted possession authentication status of the smart glasses is valid. The pending payment information may include, but is not limited to, the amount, merchant number and / or merchant name, and order number; this application does not limit this.

[0156] As an example, after the smart glasses send a first payment request carrying payment information to the user device, the process of the server parsing and confirming the payment information can be implemented in step S603. That is, the smart glasses can send only one payment request (such as a second payment request) to the user device. After the user device forwards the payment request to the server, the server can parse and confirm the payment information and further perform risk verification and payment processing.

[0157] In another possible implementation, the method by which the user device determines that the trusted possession authentication status of the smart glasses is valid can be as follows: the smart glasses can send status indication information to the user device. For example, after determining that the trusted possession authentication status stored on the smart glasses side is valid, the smart glasses can send this valid status (i.e., status indication information) to the user device. Correspondingly, the user device can receive the status indication information from the smart glasses, and after determining that the trusted possession authentication status of the smart glasses is valid based on this status indication information, it can send the valid status and a second payment request carrying payment information to the server. The status indication information is obtained by the smart glasses reading the pre-stored trusted possession authentication status of the smart glasses from its secure storage module 504 through its unified identity authentication module 503. This reduces the computational overhead and power consumption on the user device side, reduces the user device's dependence on real-time network connectivity, significantly improves payment interaction efficiency, and effectively enhances the user experience.

[0158] In another possible implementation, the user equipment can determine that the trusted possession authentication status of the smart glasses is valid by: the smart glasses reading the pre-stored trusted possession authentication status from its secure storage module 504 through its unified identity authentication module 503; after confirming that the trusted possession authentication status is valid, the user equipment directly forwards this valid status to the server; simultaneously, the user equipment sends a second payment request carrying payment information to the server. This eliminates the need for the user equipment to repeatedly perform the status confirmation operation, significantly reducing the computational overhead and power consumption on the user equipment side.

[0159] As an example, if the smart glasses determine that the trusted possession authentication status of the smart glasses is invalid, the smart glasses will not send this invalidation status to the server. Optionally, if the smart glasses determine that the trusted possession authentication status of the smart glasses is invalid, the smart glasses will not send this invalidation status to the server, and the smart glasses can send a first payment request to the user device. The user device can determine whether the trusted possession authentication status of the smart glasses is invalid based on the trusted possession authentication status of the smart glasses stored on the user device side. If the user device determines that the trusted possession authentication status of the smart glasses is invalid, the user device will not send this invalidation status and a second payment request carrying pending payment information to the server. Through dual status verification by the smart glasses and the user device, the security and reliability of payment can be further enhanced.

[0160] As an example, to avoid the prolonged validity of a valid state after a successful verification, and to prevent the risk of misuse after the smart glasses are lost or stolen, the user device and / or smart glasses can manage the lifecycle of the smart glasses' valid state. For instance, before the user device sends a second payment request to the server, the user device and / or smart glasses need to determine if the current time falls within the available time corresponding to the valid state. If the current time does not fall within the available time corresponding to the valid state, then the smart glasses do not have payment authorization. The available time may include, but is not limited to, the start time, end time, and duration of the valid state.

[0161] After the user device determines that the trusted possession authentication status of the smart glasses is valid, it sends a second payment request to the server. Correspondingly, the server's data transmission module 508 receives the valid status from the user device and the second payment request carrying the payment information. Then, the server can perform risk verification on the payment authorization of the smart glasses through its risk control service 510. After the risk verification is passed, the server can process the payment through its payment service 509. After the payment is processed, the server's data transmission module 508 can return the payment processing result to the user device.

[0162] As an example, the server's risk control service can perform risk verification on the payment permissions of smart glasses based on the trusted possession authentication status (meaning valid status), the second payment request carrying payment information, the device identifiers of the smart glasses and the user's device, historical data, etc., providing risk control and security verification support for the payment service. Specifically, the process of risk verification of payment permissions for smart glasses may include, but is not limited to: A1. Receive a second payment request from the user device, carrying payment information.

[0163] A2. Obtain the trusted possession authentication status (meaning the valid status) of the smart glasses, the device identifiers of the smart glasses and the user device; verify whether the smart glasses are a legitimate and authorized trusted possession of the user device.

[0164] In practical applications, the second payment request may not include the trusted possession authentication status of the smart glasses. In this case, the server does not need to execute A2.

[0165] A3. Check whether the current smart glasses have the payment function enabled and whether they have small-amount payment permissions.

[0166] In practical applications, the scenarios in which users make payments using smart glasses are not limited to small-amount payments, and this application does not make specific limitations in this regard.

[0167] A4. Output the risk level based on historical payment records, user habits, transaction frequency, amount range, etc.

[0168] For example, risk levels can include, but are not limited to: low risk level, medium risk level, and high risk level.

[0169] A5. Assuming the risk level is low, the payment service can be notified to complete the payment directly; assuming the risk level is medium, secondary verification, such as password confirmation or fingerprint confirmation, can be triggered; assuming the risk level is high, payment can be refused and the anomaly recorded, and a security alert can be pushed to the user's device and smart glasses.

[0170] A6. Send the risk verification result to the payment service and save the complete log for subsequent risk verification.

[0171] As an example, a server's payment service can provide capabilities such as payment order generation, payment channel integration, pending payment information processing, and transaction execution, receiving payment requests from user devices and completing payment processing. The specific payment processing procedure may include, but is not limited to: B1. Payment service parsing carries a second payment request containing pending payment information.

[0172] B2. Call the server's risk control service to complete the above risk verification process, and determine whether to continue the payment based on the risk verification results.

[0173] B3. For payment requests that pass risk verification, generate a payment order and record the order status, transaction information, device information, timestamp, etc.

[0174] B4. Verify the payment information in the payment order to ensure it is consistent with the requirements of the payment channel.

[0175] B5. Based on the payment order information and payment rules, connect to the corresponding payment channel and complete the deduction and other operations.

[0176] B6. Receive the transaction results returned by the payment channel and update the order status.

[0177] For example, the order status can be specifically: payment successful, payment failed, or payment is being processed.

[0178] B7. The final payment result and order information are sent to the data transmission module 508, which then returns them to the user device, completing the payment process.

[0179] It should be noted that the above risk verification process and payment processing process are merely illustrative descriptions, and this application does not limit their specific implementation process.

[0180] S604. The user equipment sends a message indicating successful payment to the smart glasses based on the server's payment response.

[0181] After the server successfully completes the payment, the user device can send a message indicating successful payment to the smart glasses based on the server's payment success response. Correspondingly, the smart glasses can receive the payment success message from the user device and notify the user that the payment has been successfully completed.

[0182] As an example, smart glasses can send payment success notifications to users through voice announcements, vibration alerts, and other means to indicate that the payment has been successfully completed.

[0183] In one possible implementation, after a server payment failure, the user device can send a message indicating payment failure to the smart glasses based on the server's payment response. Correspondingly, the smart glasses can receive the payment failure message from the user device and notify the user of the payment failure.

[0184] As an example, smart glasses can send notifications of payment failure to users through voice announcements, vibration alerts, or other means to inform them that the payment has failed.

[0185] In summary, the solution provided in this application pre-adds smart glasses as a trusted possession of the user device and saves the trusted possession authentication status of the smart glasses. When using smart glasses for payment, it is only necessary to determine whether the smart glasses have payment permissions based on the pre-saved trusted possession authentication status of the smart glasses. This enables fast payment through smart glasses while ensuring payment identity verification security. The entire payment process does not require complex voice interaction, which can significantly improve payment interaction efficiency and effectively improve user experience.

[0186] Other embodiments of this application provide a user equipment that may include a transceiver, one or more processors, and one or more memories. The transceiver is used to communicate with other devices, and the memory is used to store computer program code, including instructions. When the processor executes the instructions, the user equipment can perform various functions or steps performed by the user equipment in the above method embodiments. The structure of this user equipment can be referred to... Figure 3 The structure of the user equipment shown is illustrated.

[0187] Other embodiments of this application provide a smart glasses system, which may include a transceiver, one or more processors, and one or more memories. The transceiver is used to communicate with other devices, and the memory is used to store computer program code, including instructions. When the processor executes the instructions, the smart glasses can perform various functions or steps performed by the smart glasses in the above method embodiments. The structure of the smart glasses can be referred to... Figure 4 The structure of the smart glasses shown is illustrated.

[0188] Other embodiments of this application provide a payment system via smart glasses, the system including a user device, smart glasses, and a server, the user device, smart glasses, and server being used in conjunction to implement the various functions or steps in the above method embodiments.

[0189] This application also provides a chip system, such as... Figure 10 As shown, the chip system 1000 includes at least one processor 1001 and at least one interface circuit 1002. The processor 1001 and the interface circuit 1002 are interconnected via lines. For example, the interface circuit 1002 can be used to receive signals from other devices. As another example, the interface circuit 1002 can be used to send signals to other devices (e.g., the processor 1001). Exemplarily, the interface circuit 1002 can read instructions stored in memory and send those instructions to the processor 1001. The above-described chip system can be installed in a user device or smart glasses. When the instructions are executed by the processor 1001, the device equipped with the chip system (such as a user device and / or smart glasses) can perform the steps in the above embodiments. Of course, the chip system may also include other discrete components, which are not specifically limited in this application embodiment.

[0190] This application also provides a readable storage medium including a program and / or instructions. When the program and / or instructions are run on the user device, the user device performs the various functions or steps performed by the user device in the above method embodiment; when the program and / or instructions are run on the smart glasses, the smart glasses perform the various functions or steps performed by the smart glasses in the above method embodiment.

[0191] This application also provides a program product containing instructions, which, when run on a user device, causes the user device to perform various functions or steps performed by the user device in the above method embodiments; and when run on smart glasses, causes the smart glasses to perform various functions or steps performed by the smart glasses in the above method embodiments.

[0192] In this embodiment, the user equipment, smart glasses, readable storage medium, and program product or device containing instructions are all used to execute the corresponding methods provided above. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods provided above, and will not be repeated here.

[0193] Through the above description of the embodiments, those skilled in the art will understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0194] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0195] The units described as separate components may or may not be physically separate. A component shown as a unit can be one or more physical units; that is, it can be located in one place or distributed in multiple different locations. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0196] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0197] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, essentially or in other words, the parts that contribute to the prior art, or all or part of the technical solutions, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0198] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for making payments via smart glasses, characterized in that, The method is applied to a user equipment, which establishes a communication connection with smart glasses. The user equipment stores the trusted possession authentication status of the smart glasses. The trusted possession authentication status of the smart glasses is stored by the user equipment after verifying the smart glasses. The method includes: Receive a first payment request from the smart glasses, the first payment request carrying payment information; Once the trusted possession authentication status of the smart glasses is determined to be valid, a second payment request is sent to the server, the second payment request carrying the payment information to be made; Based on the server's payment response, a message indicating successful payment is sent to the smart glasses.

2. The method according to claim 1, characterized in that, Before sending the second payment request to the server, the method further includes: Determine that the current time falls within the available time corresponding to the effective state.

3. The method according to claim 1 or 2, characterized in that, Before receiving the first payment request, the method further includes: The user equipment verifies the smart glasses, and the verification method includes one or more of the following: verification code, account synchronization, Bluetooth pairing, fingerprint, password, facial features, and voice features; After the verification is successful, the smart glasses are added as a trusted holder of the user device, and the trusted holder authentication status of the smart glasses is saved as valid.

4. The method according to claim 3, characterized in that, The verification occurs when the user device establishes the communication connection with the smart glasses.

5. The method according to claim 3 or 4, characterized in that, After the verification is passed, the method further includes: The user equipment sends the trusted possession authentication status of the smart glasses to the smart glasses.

6. The method according to any one of claims 1-5, characterized in that, The method includes: Receive status indication information from the smart glasses, the status indication information indicating that the trusted possession authentication status of the smart glasses is valid; Determining that the trusted possession authentication status of the smart glasses is valid includes: Based on the status indication information, the trusted possession authentication status of the smart glasses is determined to be the valid status.

7. The method according to any one of claims 1-6, characterized in that, Before the user device establishes the communication connection with the smart glasses, the trusted holder authentication status of the smart glasses is invalid. The reasons for the invalid status include one or more of the following: the smart glasses are disconnected from the user device, the duration of the connection between the smart glasses and the user device exceeds a duration threshold, the distance between the smart glasses and the user device exceeds a distance threshold, or the smart glasses are not being worn.

8. The method according to any one of claims 1-7, characterized in that, In response to a second operation that cancels the valid state, the trusted possession authentication state of the smart glasses is modified to an invalid state.

9. The method according to any one of claims 3-6, characterized in that, Adding the smart glasses as a trusted holder of the user device includes: In response to the third operation, the smart glasses are added as a trusted holder of the user device.

10. A method for making payments via smart glasses, characterized in that, The method is applied to smart glasses, which establish a communication connection with a user device. The method includes: In response to a first operation on the smart glasses, payment information is obtained; Send a first payment request to the user equipment, wherein the first payment request carries the payment information to be paid; Receive a message from the user device indicating that the payment was successful.

11. The method according to claim 10, characterized in that, The first operation is an operation for quickly triggering payment, and the first operation includes: clicking the preset payment button, long-pressing the preset payment button, triggering the payment with a preset facial expression, and triggering the payment with a preset body movement.

12. The method according to claim 10 or 11, characterized in that, The method further includes: The system receives the trusted possession authentication status of the smart glasses from the user device, where the trusted possession authentication status of the smart glasses is valid. The trusted possession authentication status of the smart glasses is saved as the valid status.

13. The method according to any one of claims 10-12, characterized in that, The method includes: The system sends a status indication message to the user equipment, the status indication message indicating that the trusted possession authentication status of the smart glasses is valid.

14. The method according to claim 13, characterized in that, The trusted possession authentication status of the smart glasses also includes the available time corresponding to the valid status.

15. The method according to any one of claims 10-14, characterized in that, Before the smart glasses establish the communication connection with the user device, the trusted holder authentication status of the smart glasses is invalid. The reasons for the invalid status include one or more of the following: the smart glasses are disconnected from the user device, the duration of the connection between the smart glasses and the user device exceeds a duration threshold, the distance between the smart glasses and the user device exceeds a distance threshold, or the smart glasses are not being worn.

16. A user equipment, characterized in that, The user equipment includes: A transceiver is used to communicate with other devices. One or more memories are used to store computer program instructions; One or more processors are configured to execute the computer program instructions, causing the terminal device to implement the method as described in any one of claims 1-9.

17. A type of smart glasses, characterized in that, The smart glasses include: A transceiver is used to communicate with other devices. One or more memories are used to store computer program instructions; One or more processors are configured to execute the computer program instructions, causing the terminal device to implement the method as described in any one of claims 10-15.

Images