Data processing method based on mobile intelligent device and related device

Abstract

Embodiments of the present application provide a data processing method based on a mobile intelligent device and related equipment, the method comprising: driving a mobile intelligent device worn by a first object to perform multiple identity authentications on the first object according to a preset authentication period to obtain an identity authentication result; in response to the first object entering a payment scene, obtaining the identity authentication result from the mobile intelligent device, and determining identity confidence data of the first object according to the identity authentication result; obtaining payment confidence data of the payment scene, determining a payment strategy for the first object in the payment scene according to the identity confidence data of the first object and the payment confidence data of the payment scene; and performing payment processing for the first object in the payment scene according to the determined payment strategy. In this way, the payment security can be effectively improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a data processing method and related equipment based on mobile smart devices. Background Technology

[0002] With the development of payment technology, mobile smart devices (such as smart bracelets and smartphones) can be used for electronic payments in various scenarios, based on corresponding payment methods (such as QR code payment and NFC payment). For example, in a convenience store payment scenario, a wearable smart device worn by the user is brought close to the payment terminal to complete an electronic payment. However, in some electronic payment methods, identity authentication only occurs at the moment the payment is triggered. For example, NFC payment with a smart bracelet only performs one-time identity authentication during the activation phase or when the payment is initiated; subsequent payments do not require identity authentication. Thus, if the mobile smart device is lost and worn by another person, it can still be used for payments, affecting payment security. In addition, the current security of electronic payments relies on the data (such as passwords or biometrics) actively entered by the user to verify their identity. This data is easily forged or leaked, affecting payment security, and the level of security protection needs to be improved. Summary of the Invention

[0003] This application provides a data processing method and related equipment based on mobile smart devices, which can effectively improve payment security.

[0004] On one hand, embodiments of this application provide a data processing method based on a mobile smart device, including: The mobile smart device worn by the first object performs multiple identity authentications on the first object according to a preset authentication cycle, and obtains the identity authentication result. In response to the first object entering the payment scenario, the identity authentication result is obtained from the mobile smart device, and the identity confidence data of the first object is determined based on the identity authentication result; Obtain payment confidence data for the payment scenario, and determine the payment strategy for the first object in the payment scenario based on the identity confidence data of the first object and the payment confidence data of the payment scenario; According to the established payment strategy, payment processing is performed on the first object in the payment scenario.

[0005] On one hand, embodiments of this application provide a data processing apparatus based on a mobile smart device, including: The authentication unit is used to drive the mobile smart device worn by the first object to perform multiple identity authentications on the first object according to a preset authentication cycle, and obtain the identity authentication result. The determining unit is also used to, in response to the first object entering the payment scenario, obtain the identity authentication result from the mobile smart device, and determine the identity confidence data of the first object based on the identity authentication result; The determining unit is also used to acquire payment confidence data of the payment scenario, and to determine the payment strategy for the first object in the payment scenario based on the identity confidence data of the first object and the payment confidence data of the payment scenario; The payment unit is used to perform payment processing for the first object in a payment scenario according to a determined payment strategy.

[0006] On one hand, embodiments of this application provide a computer device, which includes: a processor adapted to execute a computer program; and a computer-readable storage medium storing the computer program, wherein when the computer program is executed by the processor, it implements the data processing method based on the mobile intelligent device described above.

[0007] On one hand, embodiments of this application provide a computer-readable storage medium storing a computer program, which is loaded by a processor and executed as described above for data processing based on a mobile smart device.

[0008] On the one hand, embodiments of this application provide a computer program product, which includes a computer program or computer instructions, and when the computer program or computer instructions are executed by a processor, they implement the above-described data processing method based on a mobile smart device.

[0009] In this embodiment, the mobile smart device worn by the first object can be driven to perform multiple identity authentications on the first object according to a preset authentication cycle to obtain the identity authentication result. This periodic identity authentication of the first object enables proactive and continuous identity monitoring of the first object wearing the mobile smart device, effectively improving the online identity monitoring capability for the wearer of the mobile smart device and preventing other objects from arbitrarily using the mobile smart device for payment in the event of loss. In response to the first object entering the payment scenario, the identity authentication result is obtained from the mobile smart device, and the identity confidence data of the first object is determined based on the identity authentication result; the payment confidence data of the payment scenario is obtained, and the payment strategy for the first object in the payment scenario is determined based on the identity confidence data of the first object and the payment confidence data of the payment scenario; and the payment processing is performed for the first object in the payment scenario according to the determined payment strategy. When a first party enters a payment scenario, it indicates their intention to pay. A payment strategy is determined by integrating both identity and payment confidence data. On one hand, the dynamic nature of the confidence data allows for more flexible formulation of a payment strategy tailored to the payment scenario and the first party, ensuring the security of payments made by the first party using a mobile smart device within the current payment scenario. On the other hand, integrating security measures at both the identity and payment scenario levels allows for a more comprehensive consideration of factors affecting payment security when formulating a payment strategy. Executing payment processing for the first party within the payment scenario based on this strategy effectively guarantees payment security. Attached Figure Description

[0010] Figure 1 This is an architectural diagram of a data processing system provided in an exemplary embodiment of this application; Figure 2 This is a flowchart illustrating a data processing method provided in an exemplary embodiment of this application; Figure 3 This is a schematic diagram of an identity authentication process provided in an exemplary embodiment of this application; Figure 4 This application provides an exemplary embodiment of a data processing workflow intent. Figure 5 This is a schematic diagram of another data processing process provided by an exemplary embodiment of this application; Figure 6a This is a schematic diagram of a payment interface provided in an exemplary embodiment of this application; Figure 6b This is a schematic diagram of a transaction details interface provided in an exemplary embodiment of this application; Figure 7This is a schematic diagram of a shared account management interface provided in an exemplary embodiment of this application; Figure 8 This is a schematic diagram of the structure of a data processing apparatus based on a mobile smart device provided in an exemplary embodiment of this application; Figure 9 This is a schematic diagram of the structure of a computer device provided in an exemplary embodiment of this application. Detailed Implementation

[0011] It should be noted that in the specific embodiments of this application, data related to biometrics and object identity are involved. When the above embodiments of this application are applied to specific products or technologies, permission or consent from the object is required, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0012] This application provides a data processing method based on a mobile smart device. In this method, the mobile smart device worn by a first object can be driven to perform multiple identity authentications on the first object according to a preset authentication cycle, obtaining the authentication result. By periodically authenticating the first object, proactive and continuous identity monitoring of the first object wearing the mobile smart device can be achieved, effectively improving the online identity monitoring capability for the wearer of the mobile smart device and preventing unauthorized use of the lost mobile smart device for payments. In response to the first object entering a payment scenario, the authentication result is obtained from the mobile smart device, and the first object's identity confidence data is determined based on the authentication result; payment confidence data for the payment scenario is obtained, and a payment strategy for the first object in the payment scenario is determined based on the first object's identity confidence data and the payment confidence data of the payment scenario; payment processing is then performed for the first object in the payment scenario according to the determined payment strategy. When a first party enters a payment scenario, it indicates their intention to pay. By comprehensively considering both identity and payment confidence data, a payment strategy is determined. On one hand, the dynamic nature of the confidence data allows for more flexible formulation of a payment strategy tailored to the specific payment scenario and the first party, ensuring the security of payments made by the first party using a mobile smart device within the current payment context. On the other hand, considering both identity and payment scenario security allows for a more comprehensive assessment of factors affecting payment security when developing a payment strategy. Executing payment processing for the first party within the payment scenario based on this strategy effectively guarantees payment security.

[0013] The architecture of the data processing system based on mobile smart devices provided in the embodiments of this application will be described below with reference to the accompanying drawings.

[0014] Please see Figure 1This is an architectural diagram of a data processing system based on a mobile smart device, provided in an exemplary embodiment of this application. Figure 1 As shown, the data processing system includes a mobile smart device 101, a payment terminal device 102, and a cloud settlement device 103.

[0015] The mobile intelligent device described in this application refers to an intelligent terminal device that can be worn by any object and moves with the object; such as Figure 1 The mobile smart device 101 in the illustrated system can be a mobile terminal device with payment functionality, and can also be referred to as a user device. The mobile smart device 101 can include, but is not limited to, smartphones, tablets, smart wearable devices (such as smartwatches, smart bracelets, etc.), and smart voice interaction devices, all of which have payment functionality. In addition to payment functionality, the mobile smart device 101 also possesses biometric sensing capabilities (implemented by sensors) and near-field communication capabilities (implemented by a near-field communication module). Through biometric sensing capabilities, it can continuously collect the biometric data of the subject (such as heart rate, gait, and body temperature) to facilitate identity authentication of the wearer of the mobile smart device.

[0016] Payment terminal device 102 refers to a terminal device used to accept payment vouchers from mobile smart device 101. This payment terminal device 102 includes, but is not limited to, scanning devices in subway turnstiles, point-of-sale (POS) terminals, or other payment terminals. Payment terminal device 102 can initiate payment requests, which are responded to and authorized by mobile smart device 101; the payment voucher is used to authorize the payment of a corresponding amount of digital assets. Cloud settlement device 103 refers to a device with settlement functions. This cloud settlement device 103 can belong to a settlement system; for example, it can be a server. Mobile smart device 101 can interact with cloud settlement device 103 through payment terminal device 102, or directly with cloud settlement device 103.

[0017] The following is a description of the data processing flow provided in the embodiments of this application performed by the mobile smart device 101, which roughly includes: S1, bind the identity of the reference object.

[0018] The reference object can be any object requesting identity binding. The mobile smart device 101 binding the reference object's identity includes: responding to the identity binding request, generating biometric baseline data for the reference object, and encrypting and storing the biometric baseline data. In this application, the biometric baseline data can also be called a biometric template. This biometric baseline data can be a multidimensional biometric vector, and the biometric features represented by the multidimensional biometric vector include, but are not limited to, heart rate features, gait features, and skin resistance.

[0019] Mobile smart device 101 can encrypt and store biometric baseline data in its own secure chip (SecureElement, or SE chip). The secure chip is a hardware security module within the mobile smart device, providing a physically isolated secure storage and computing environment that complies with security authentication standards. Besides storing biometric templates, the secure chip can also store sensitive data such as digital asset private keys and transaction credentials (e.g., payment vouchers). Mobile smart device 101 can also encrypt and store the biometric baseline data in a cloud device (e.g., a cloud settlement device or other cloud device) to back up the biometric baseline data and prevent authentication failure due to local loss on mobile smart device 101.

[0020] In one embodiment, the mobile smart device 101 is logged into a payment account. Binding the identity of the reference object also includes binding the biometric baseline data of the reference object to the payment account. By combining the generation and encrypted storage of the aforementioned biometric baseline data, a three-in-one identity verification of "object-device-account" can be achieved.

[0021] S2. Continuously authenticate the identity of the wearer of the mobile smart device 101.

[0022] The wearer of the mobile smart device 101 refers to the object wearing the mobile smart device 101. In this application, the wearer is used as the first object for illustration. In order to verify whether the first object is the reference object bound to the mobile smart device 101, continuous identity authentication can be performed on the first object to continuously detect the identity of the first object, that is, to verify whether the first object is the reference object.

[0023] Continuous authentication refers to the process of authenticating the first object once at a preset authentication interval, also known as continuous authentication. For example, if the preset authentication interval is 5 seconds, then the first object can be authenticated once every 5 seconds, or every 10 seconds is a cycle.

[0024] In one embodiment, regardless of the scenario in which the mobile smart device is located, the mobile smart device 101 can continuously monitor the multidimensional biometric data of the first object and perform identity authentication on the first object based on the detected multidimensional biometric data, so as to continuously authenticate the wearer of the mobile smart device in real time and determine whether the wearer's identity is the identity bound to the mobile smart device 101. In this way, the payment security of the mobile smart device can be more comprehensively guaranteed in any scenario.

[0025] In another embodiment, the mobile smart device 101 can detect whether it is in a preset scenario; if it is in a preset scenario, S2 is triggered. If it is not in a preset scenario, S2 is not executed. The mobile smart device 101 being in a preset scenario means that its geographical location information is within the geographical range corresponding to the preset scenario. The preset scenario refers to a scenario where the object may make a purchase, including but not limited to scenarios such as subway stations, supermarkets, convenience stores, and restaurants. In this approach, continuous authentication is performed on the first object only when the mobile smart device is in the preset scenario, rather than in any arbitrary scenario. This effectively saves the power consumption required for continuous authentication and ensures payment security in scenarios with a high probability of purchase.

[0026] In one embodiment, continuous identity authentication includes multiple identity authentications. Each time, the mobile smart device 101 can collect multidimensional biometric data of the first object and compare the multidimensional biometric data with the biometric baseline data of the reference object to obtain the identity authentication result.

[0027] In one implementation, biometric baseline data is encrypted and stored in both the mobile smart device 101 and the cloud device. When verifying the identity of the first object, if the biometric baseline data cannot be obtained from the mobile smart device 101, then the biometric baseline data can be obtained from the cloud device, thereby achieving dual protection for the acquisition of biometric baseline data.

[0028] S3. In response to the first object entering the payment scenario, obtain the payment confidence data of the payment scenario, and determine the identity confidence data of the first object based on the identity authentication result of the first object.

[0029] A first object entering a payment scenario can generate a target transaction. For example, if the payment scenario is a supermarket, the target transaction could be the transaction generated by the first object authorizing payment after making purchases in the supermarket; another example is a subway station, where the target transaction could be the transaction generated by the first object authorizing payment upon exiting the station; yet another example is a convenience store, where the target transaction could be the transaction generated by the first object authorizing payment after purchasing goods in the convenience store. Authorized payment can be understood as the mobile smart device 101 being within the preset sensing range of the payment terminal device 102. To determine whether the target transaction poses a payment risk, in one embodiment, the mobile smart device 101 can obtain a target identity authentication result from multiple identity authentication results obtained through continuous identity authentication. This target identity authentication result includes a confidence score, which can be used to determine the identity confidence data of the first object. The target identity authentication result can be the identity authentication result with the latest inter-authentication stamp or the identity authentication result with the highest confidence score. In this approach, the identity confidence data can be determined based on the latest identity authentication result, improving the reliability of the identity confidence data, or based on the identity authentication result with the highest recent confidence score, improving the credibility of the identity confidence data.

[0030] In another implementation, the confidence scores from multiple authentication results can be fused to obtain a fused confidence score as the identity confidence data for the first object. Alternatively, a reference authentication result can be selected from multiple authentication results, and its confidence scores can be fused to obtain a reference confidence score as the identity confidence data for the first object. The reference authentication result is the authentication result whose confidence score is greater than or equal to a preset confidence score threshold. This approach combines multiple authentication results to determine identity confidence data, improving the accuracy of the identity confidence data and avoiding false detections from a single authentication result that could compromise the original identity confidence data.

[0031] S4. Determine the payment strategy based on the payment confidence data and identity confidence data, and perform payment processing for the first object in the payment scenario according to the payment strategy.

[0032] The process of executing payment processing according to the payment strategy can be achieved through interaction between the mobile smart device 101 and the payment terminal device 102, or through interaction between the mobile smart device 101 and the cloud settlement device 103. The payment strategy is used to indicate whether to authorize the execution of payment processing for the first object in the payment scenario. If authorized, the mobile smart device 101 can generate a payment voucher according to the payment strategy and send the payment voucher to the payment terminal device 102.

[0033] Based on the network availability of payment terminal device 102, it can choose whether to interact with the settlement device to complete the payment processing. This includes: if the network of payment terminal device 102 is available, the payment voucher can be sent to the cloud settlement device 103, which will then perform payment settlement according to the voucher. After obtaining the settlement result, the payment terminal device 102 will return the result to the mobile smart device 101, thus completing the payment processing for the first object in the payment scenario. If the network of payment terminal device 102 is unavailable, the payment terminal device 102 can verify the signature of the payment voucher to control the execution of corresponding operations. Simultaneously, the mobile smart device 101 can directly update the balance of the payment account based on the payment voucher. The payment voucher and transaction data can also be packaged into a transaction record, stored locally, and marked as pending settlement. When the network of mobile smart device 101 changes from unavailable to available, the mobile smart device can directly send the transaction record marked as pending settlement to the cloud settlement device 103 for settlement processing.

[0034] The data processing system based on mobile smart devices provided in this application embodiment can use the identity authentication result generated by continuous identity authentication as the driving signal to connect payment triggering, risk decision-making, credential generation and payment execution into an automated link. The entire payment process does not require active operation, realizing a seamless experience of payment by wearing the device, while ensuring payment security.

[0035] The data processing method based on mobile smart devices provided in the embodiments of this application will be described next.

[0036] Please see Figure 2 This is a schematic flowchart illustrating a data processing method based on a mobile smart device, provided in an exemplary embodiment of this application. This data processing method based on a mobile smart device can be implemented using a computer device (such as...). Figure 1 The mobile smart device 101 in the system shown is used to perform the data processing method based on the mobile smart device, which may include the following.

[0037] S201. Drive the mobile smart device worn by the first object to perform multiple identity authentications on the first object according to the preset authentication cycle, and obtain the identity authentication result.

[0038] The preset authentication period defines the interval between identity authentication actions. For example, if the preset authentication period is 5 seconds, then identity authentication can be performed every 5 seconds. The interval between adjacent identity authentication actions is the duration defined by this preset authentication period. Based on the preset authentication period setting, the identity of the current wearer of the mobile smart device (here referring to the first object) can be continuously authenticated to monitor the identity of the current wearer of the mobile smart device in real time and proactively. This avoids security issues caused by wearers whose identities are not bound to the mobile smart device using the device for payment, thereby improving payment security.

[0039] In one implementation, the preset authentication period can dynamically change according to the type of scenario in which the mobile smart device is located. The scenario can include a first scenario and a second scenario, where the probability of consumption is higher in the first scenario than in the second scenario (e.g., a supermarket in the first scenario and a plaza in the second scenario). The first authentication period set when the mobile smart device is in the first scenario is shorter than the second authentication period set when it is in the second scenario. When the scenario changes from the first to the second scenario, the preset authentication period changes from the first to the second. Therefore, the preset authentication period can be set differently based on the scenario type, allowing for more frequent identity authentication in scenarios with a higher probability of consumption to ensure payment security, and reducing the frequency of identity authentication in scenarios with a lower probability of consumption to effectively reduce power consumption.

[0040] Compared to one-time identity authentication, this application can perform multiple identity authentications according to a preset authentication cycle, thereby continuously verifying the identity of the wearer of the mobile smart device at a fixed frequency (e.g., once every 5 seconds), which greatly improves security.

[0041] In one embodiment, the implementation steps of S201 may include the following steps S2011 and S2012: S2011. Drive the mobile smart device worn by the first object to collect the multidimensional biometric data of the first object N times continuously according to the preset authentication cycle; N is an integer greater than 1.

[0042] In one embodiment, whenever the authentication timestamp determined by the preset authentication period is reached, the mobile smart device can drive its built-in sensors to perform a collection. In this way, multidimensional biometric data can be actively collected by the mobile smart device autonomously driven by its built-in sensors, without relying on the first object to perform any active operation (such as pointing the mobile smart device at the first object's facial area), which can improve the convenience of collection.

[0043] Multidimensional biometric data can be used to describe physiological characteristics across multiple modalities. Here, "modality" refers to the data modality collected by different sensors. These modal physiological characteristics include, but are not limited to, heart rate variability (HRV), gait characteristics (step frequency / stride length / landing pattern), skin resistance (skin conductivity), and body temperature. Among these, heart rate variability is a unique physiological characteristic of the first individual. Data describing heart rate variability can include 12-dimensional feature parameters such as RMSSD (root mean square), SDNN (standard deviation), and LF / HF (low-frequency to high-frequency ratio). Multidimensional biometric data can include static and dynamic feature data. Static feature data describes static physiological characteristics, such as the aforementioned skin resistance and body temperature. Dynamic feature data describes dynamic physiological characteristics, such as the aforementioned heart rate variability and gait characteristics. By integrating multiple physiological characteristics through multidimensional biometric data for identity authentication, the accuracy of identity authentication can be effectively improved.

[0044] In one implementation, for any given collection of multidimensional biometric data, the mobile intelligent device can invoke its built-in sensors to collect the raw physiological signals of a first object, and perform feature extraction processing on the raw physiological signals of the first object to obtain a multidimensional biometric vector of the first object. This multidimensional biometric vector is then determined as the multidimensional biometric data of the first object. Alternatively, the multidimensional biometric vector can be normalized, and the normalized multidimensional biometric vector is used as the multidimensional biometric data. Therefore, the multidimensional biometric data can be either a multidimensional biometric vector (feature_current) or a normalized multidimensional biometric vector. For example, the multidimensional biometric data can be a 30-dimensional feature vector or a normalized 30-dimensional feature vector.

[0045] The raw physiological signals can include static physiological signals and motion physiological signals. The mobile intelligent device can include a first type of sensor and a second type of sensor. The mobile intelligent device can call the first type of sensor to collect the static physiological signals of the first subject. Static physiological signals refer to physiological signals in a resting state, such as the physiological signals of the first subject for 5 consecutive minutes in a resting state. The first type of sensor includes, but is not limited to, a PPG heart rate sensor, a skin resistance sensor, and a body temperature sensor. For example, using a PPG heart rate sensor (sampling rate 100Hz), a skin resistance sensor (10Hz), and a body temperature sensor (0.1Hz), the heart rate, skin resistance, and body temperature of the first subject for 5 consecutive minutes in a resting state can be collected, respectively. The mobile intelligent device can call the second type of sensor to collect the motion physiological signals of the first subject. Motion physiological signals refer to physiological signals in a motion state. The second type of sensor can be an IMU inertial sensor (including an accelerometer and a gyroscope). For example, using an IMU inertial sensor (accelerometer and gyroscope, 50Hz), the gait signals of the first subject walking 100 steps continuously can be collected. By collecting various physiological signals from the first object using the two types of sensors mentioned above, the richness of the original biological signals can be improved, and multidimensional biological feature data can be effectively constructed.

[0046] S2012. Compare the multidimensional biometric data collected each time with the biometric baseline data of the reference object to obtain N identity authentication results of the first object.

[0047] In one implementation, taking the comparison between the multidimensional biometric data collected in the i-th instance and the baseline biometric data of a reference object as an example, the comparison method includes: calculating the similarity between the multidimensional biometric data collected in the i-th instance and the baseline biometric data of the reference object to obtain the feature similarity; determining the confidence score of the first object based on the feature similarity; and adding the confidence score of the first object and the start time of the i-th authentication to the authentication result. The similarity calculation can be a cosine similarity calculation, and the expression for calculating the feature similarity can be as follows: similarity = dot(feature_current_normalized, template_baseline) / (||feature_current_normalized|| × ||template_baseline||) Here, similarity represents feature similarity, feature_current_normalized represents the normalized multidimensional biometric feature vector, and template_baseline represents the biometric feature baseline data.

[0048] Mobile smart devices can score feature similarity to obtain a confidence score for the first object.

[0049] match_score = similarity × 100 Here, match_score is the confidence score of the first object, also known as the matching score. This confidence score is used to indicate the probability that the first object is the reference object.

[0050] Understandably, each time multidimensional biometric data of the first object is collected, this multidimensional biometric data is compared with the baseline biometric data to obtain the authentication result for that instance. Since N consecutive collections are performed, N comparisons can be performed based on the N collected multidimensional biometric data, resulting in N authentication results. Each authentication result corresponds to one authentication, and each authentication result includes an authentication timestamp and a confidence score. Any one of the N authentication results is represented as the i-th authentication result, corresponding to the i-th authentication. The authentication timestamp in the i-th authentication result indicates the start time of the i-th authentication. The confidence score in the i-th authentication result indicates the probability that the first object is identified as the reference object in the i-th authentication, where i is a positive integer less than or equal to N.

[0051] In one implementation, the mobile smart device can pre-generate biometric baseline data for a reference object, which can be used in the continuous identity authentication process. The generation of the biometric baseline data for the reference object includes the following steps 1.1-1.2: Step 1.1: In response to the biometric binding request for the mobile smart device, drive the sensors in the mobile smart device to collect the raw baseline data of the reference object.

[0052] A biometric binding request is used to request the binding of biometric baseline data to a mobile smart device; it can also be called an identity binding request. It's understood that multiple biometric binding requests can be initiated, each requesting the binding of biometric baseline data of different objects to the mobile smart device. A single mobile smart device can be bound to the biometric baseline data of multiple objects, and multiple objects can use the same mobile smart device.

[0053] In response to the biometric binding request, the mobile smart device can drive its built-in sensors to acquire raw baseline data of a reference subject. This raw baseline data includes static baseline data and / or motion baseline data. The static baseline data describes at least one biological attribute of the reference subject in a resting state, and the motion baseline data describes at least one biological attribute of the reference subject in a moving state. The sensors can include a first type of sensor and a second type of sensor, where the first type of sensor is used to acquire static baseline data and the second type of sensor is used to acquire motion baseline data. For example, a PPG heart rate sensor (sampling rate 100Hz), a skin resistance sensor (10Hz), and a body temperature sensor (0.1Hz) can be used to acquire physiological signals of the reference subject for 5 consecutive minutes in a resting state (belonging to static baseline data). An IMU inertial sensor (accelerometer and gyroscope, 50Hz) can also be used to acquire gait signals of the reference subject walking 100 steps continuously (belonging to motion baseline data).

[0054] Step 1.2: Perform feature extraction processing on the original baseline data of the reference object to obtain the biometric baseline data of the reference object.

[0055] Based on the collected raw baseline data of the reference object, the mobile intelligent device can extract multidimensional biometric vectors from the raw baseline data and perform statistical analysis on the multidimensional biometric vectors to obtain biometric baseline data to describe the biometric characteristics of the reference object. For example, based on the above raw baseline data, a 30-dimensional biometric vector can be extracted. The specific dimensions include: 12 dimensions of HRV-related indicators (including time-domain and frequency-domain features such as RMSSD, SDNN, and pNN50), 10 dimensions of gait features (including gait frequency, stride length, peak vertical acceleration, gait symmetry, etc.), 6 dimensions of skin resistance features (mean SCL, SCR frequency, etc.), and 2 dimensions of body temperature features (mean and fluctuation amplitude). The mean [i] and standard deviation [i] of each dimension are calculated to form a 30-dimensional baseline template, template_baseline, which is the biometric baseline data.

[0056] The biometric baseline data generation method described in steps 1.1-1.2 above can automatically collect the original baseline data of the reference object from multiple dimensions through the sensors of a mobile smart device, and convert the original baseline data into a multi-dimensional biometric vector, thereby improving the richness and comprehensiveness of the biometric baseline data. The entire process does not require the reference object to actively input biometrics and is not affected by the objective environment, which can improve the convenience and accuracy of biometric collection.

[0057] After generating biometric baseline data for a reference subject, this data can be encrypted and stored in mobile smart devices and cloud devices. Encrypted storage refers to encrypting the biometric baseline data and storing the encrypted data. Encryption methods include, but are not limited to, symmetric encryption and hash encryption. Symmetric encryption methods include, for example, the AES-256-GCM encryption algorithm, and hash encryption methods include, for example, the SHA-256 encryption algorithm. By encrypting and storing sensitive data such as biometric baseline data, the security of sensitive data can be effectively guaranteed. Mobile smart devices can encrypt and store the biometric baseline data of the reference subject in their own security chip, specifically writing it to the non-volatile storage area (i.e., flash) of the security chip. This effectively ensures the security of the biometric baseline data, guaranteeing that the data is securely and completely retained even after power failure or unexpected system shutdown.

[0058] Optionally, the encryption method used for encrypted storage on the mobile smart device may be the same as or different from the encryption method used for encrypted storage on the cloud device. For example, the biometric baseline data (i.e., baseline template) of the reference object, after being encrypted with AES-256-GCM, can be written to the non-volatile storage area of ​​the SE security chip in the smart wearable device. Additionally, the SHA-256 hash value obtained after encrypting the biometric baseline data of the reference object using SHA-256 is uploaded to the cloud device. By using different encryption methods, the characteristics of different devices can be matched, balancing the efficiency and security of encrypted storage.

[0059] As described above, the biometric baseline data of the reference object is encrypted and stored in both the mobile smart device and the cloud device. Based on this, during the identity authentication process, the mobile smart device can obtain the biometric baseline data of the reference object for comparison. This acquisition can include retrieving the biometric baseline data of the reference object from the security chip of the mobile smart device. Depending on the specific location of the encrypted storage, the encrypted biometric baseline data of the reference object can be retrieved from the non-volatile storage area of ​​the security chip (i.e., the SE chip) of the mobile smart device, and then decrypted to obtain the reference object's biometric baseline data. In one embodiment, if the data is not retrieved from the security chip of the mobile smart device, the biometric baseline data of the reference object is retrieved from the cloud device. Specifically, the encrypted biometric baseline data of the reference object can be retrieved first, and then decrypted to obtain the reference object's biometric baseline data. Thus, by encrypting and storing the biometric baseline data through multiple devices, the completion of identity authentication can be effectively guaranteed, avoiding situations where identity authentication cannot be completed due to the loss of biometric baseline data locally on the mobile smart device.

[0060] In another implementation, if the biometric data of the first object is not obtained from the security chip of the mobile smart device, the multidimensional biometric data of the first object is sent to the cloud device. The cloud device then compares the reference object's baseline biometric data with the first object's multidimensional biometric data to obtain the authentication result, which is then returned to the mobile smart device. Thus, in the event that the mobile smart device loses the reference object's biometric data or does not store the reference object's biometric data, remote identity verification can be achieved through backup from the cloud device.

[0061] The continuous identity authentication shown in steps S2011 to S2012 above is a multimodal continuous authentication. By collecting multidimensional biometric data of the first object, and comparing the collected multidimensional biometric data with the pre-generated biometric baseline data of the reference object, it is possible to determine whether the first object is the reference object from multiple dimensions of biometric features, thereby improving the accuracy of identity authentication. Furthermore, continuous identity authentication allows identity authentication to continue, making it difficult to forge over a long period of time and providing strong anti-forgery capabilities.

[0062] The following table provides a data comparison illustration of various authentication methods: Table 1

[0063] As shown in Table 1, experiments have demonstrated that the multimodal continuous authentication method provided in this application has a lower false acceptance rate and false rejection rate, and stronger anti-counterfeiting capabilities compared to other authentication methods (including 4-digit PIN codes, single fingerprint recognition, and single face recognition).

[0064] In one embodiment, the identity authentication result includes a confidence score. The mobile smart device may also perform the following steps: when a preset update timestamp is reached, a reference identity authentication result is selected from N identity authentication results, wherein the confidence score included in the reference identity authentication result is greater than a preset score threshold; and the biometric baseline data of the reference object is updated based on the multidimensional biometric data used in the identity authentication process corresponding to the reference identity authentication result.

[0065] The preset update timestamp refers to the pre-set start time for updating biometric baseline data. This preset update timestamp can be determined based on a preset update cycle, such as 7 days, meaning that the biometric baseline data is updated every 7 days.

[0066] The N identity authentication results can be generated within a preset update period. If the current timestamp reaches the preset update timestamp, then identity authentication results with a confidence score greater than a preset score threshold can be selected from the N identity authentication results as reference identity authentication results. The number of reference identity authentication results can include M, where M is a positive integer less than or equal to N. In this way, these identity authentication results with high confidence scores can be used to update the reference object's biometric baseline data corresponding to the multidimensional biometric data used in the identity authentication process, ensuring the reliability of the updated biometric baseline data of the reference object.

[0067] In one implementation, multiple reference identity authentication results are included, and the update method may include: averaging the multidimensional biometric data used in the corresponding identity authentication process based on the reference identity authentication results to obtain average biometric data; then weightedly fusing the average biometric data with the reference object's biometric baseline data to obtain the updated biometric baseline data for the reference object. This process can be called an exponentially weighted moving average algorithm. The update expression for updating the reference object's biometric baseline data can be: template_baseline_new = 0.9 × template_baseline_old + 0.1 × recent_data_mean. Here, template_baseline_new is the updated biometric baseline data, template_baseline_old is the reference biometric baseline data, and recent_data_mean is the average biometric data. For example, the biometric baseline data (i.e., the baseline template) can be updated every 7 days using the multidimensional biometric data corresponding to the accumulated high-confidence scores (match_score not lower than 95 points).

[0068] In this approach, mobile smart devices periodically accumulate authentication results and use the high-confidence-score authentication results to adaptively update the reference object's biometric baseline data, adapting to the natural changes in the object's biometrics over time and ensuring the accurate updating of the reference object's biometric baseline data. Based on the updated reference object's biometric baseline data, authentication performed after a preset update timestamp can compare the updated reference object's biometric baseline data with the collected multidimensional feature data of the first object.

[0069] In one embodiment, based on the multidimensional biometric data or N identity authentication results collected each time, anomaly detection is performed on the first object to obtain anomaly detection results; if the anomaly detection results are used to indicate that the first object is abnormal, the payment function of the mobile smart device is locked, and an alarm notification message is pushed to the application associated with the payment function.

[0070] The multidimensional biometric data here can be the raw physiological signals collected by the sensor. After collecting the multidimensional biometric data of the first object each time, not only can identity authentication be performed, but also anomaly detection can be performed on the first object based on the multidimensional biometric data collected each time. The logic of anomaly detection can be: based on the multidimensional biometric data collected each time, determine the feature change data. If the trend of the feature change data is abnormal, it is determined that the first object has an anomaly. The obtained anomaly detection result is used to indicate that the first object has an anomaly.

[0071] For example, if the reading of the epidermal resistance sensor suddenly increases to more than 10 MΩ and lasts for 3 seconds (usually corresponding to the device being removed), or the HRV change rate exceeds 30% within 10 seconds (abnormal mutation of biometrics), a safety anomaly can be determined, and an anomaly detection result can be generated to indicate that there is an anomaly in the first object.

[0072] In one implementation, the logic for anomaly detection of a first object based on N authentication results may include: if the number of authentication results with confidence scores all below a preset threshold is greater than or equal to a preset number, a security anomaly is determined to exist, and an anomaly detection result indicating the first object is abnormal can be generated; conversely, if the number of authentication results with confidence scores all below the preset threshold is less than a preset number, no security anomaly is determined to exist, and an anomaly detection result indicating the first object is normal can be generated. For example, if the matching score (match_score) obtained from authentication within five consecutive preset authentication cycles (approximately 25 seconds) is all below 90, a security anomaly is determined to exist.

[0073] If an anomaly detection result indicates an anomaly in the first target device, to ensure payment security and prevent unauthorized payments via mobile smart devices, the payment function of the mobile smart device can be directly locked. Once locked, the payment function is in a locked state and unavailable; locking the payment function can also be understood as freezing it. Besides anomaly detection, this locking scenario can also include the following: during multiple identity authentication processes, if the confidence score obtained from the first authentication is lower than a preset confidence score threshold, authentication can be stopped, and the mobile smart device's payment function can be locked.

[0074] When multi-dimensional biometric data detects that a mobile smart device has been removed (a device anomaly) or that the wearer has been replaced (an object anomaly), the payment function of the mobile smart device can be automatically locked within a short period of time, fundamentally eliminating the risk of the mobile smart device being used arbitrarily after it is lost.

[0075] In addition to locking the payment function, alarm notifications can be pushed to the applications associated with the payment function to issue warnings to the managed objects of the mobile smart device. The applications associated with the payment function can be mini-programs or third-party applications that can run on other devices. By pushing alarm notifications, other objects that jointly manage the payment function can be notified of the security anomaly. For example, if the mobile smart device is a smart bracelet and the other device is a mobile phone bound to the smart bracelet, when an anomaly is detected in the first object during identity authentication, payment locking can be triggered within 0.5 seconds, thereby locking the payment function of the smart bracelet and pushing alarm notifications to the associated mobile mini-program. The smart device can also vibrate 3 times to alert the object.

[0076] In one implementation, the mobile smart device can respond to an unlock request for the payment function by obtaining unlock data, including but not limited to: password, facial data, and fingerprint data; verify identity based on the unlock data, and unlock the payment function of the mobile smart device after successful identity verification. In this approach, when the payment function is locked, it can be unlocked to allow its use, thus resolving situations where accidental locking renders the payment function unusable.

[0077] Based on the above implementation details, the following can be provided: Figure 3The schematic diagram of the identity authentication process shown includes the following steps: S301. In response to a biometric binding request for a mobile smart device, the sensors in the mobile smart device are driven to collect the original baseline data of the reference object. S302. Feature extraction processing is performed on the original baseline data of the reference object to obtain the biometric baseline data of the reference object. S303. The biometric baseline data of the reference object is encrypted and stored in the mobile smart device and the cloud device. S304. The mobile smart device worn by the first object is driven to continuously collect the multidimensional biometric data of the first object N times according to a preset authentication cycle; N is an integer greater than 1. S305. N comparisons are performed to obtain N identity authentication results of the first object. The biometric baseline data of the reference object can also be updated based on the N identity authentication results. S306. Anomaly detection is performed on the first object based on the N identity authentication results or multidimensional biometric data to obtain anomaly detection results. S307. It is determined whether the first object is abnormal. If so, S308 is executed to lock the payment function of the mobile smart device and push an alarm notification message to the application associated with the payment function.

[0078] S202. In response to the first object entering the payment scenario, obtain the identity authentication result from the mobile smart device, and determine the identity confidence data of the first object based on the identity authentication result.

[0079] The first object entering the payment scenario can refer to: the first object wearing a mobile smart device being within the preset sensing range of the payment terminal device in the payment scenario; wherein, the preset sensing range can be a preset radio frequency field strength (such as 3A / m) or a preset communication distance (such as 3 meters).

[0080] The first object entering the payment scenario can generate a target transaction. For example, if the payment scenario is a supermarket, the target transaction can refer to the transaction generated by the first object authorizing payment after shopping in the supermarket; or if the payment scenario is a subway station, the target transaction can refer to the transaction generated by the first object authorizing payment when exiting the station.

[0081] The preset sensing range of a payment terminal device within a payment scenario can be considered as authorized payment. For example, when an NFC radio frequency field strength exceeding 3A / m is detected, it indicates that the first object has entered the payment scenario for authorized payment. The mobile smart device can be passively woken up through electromagnetic induction and its NFC mode can be activated. No pre-pairing is required; it establishes an ISO-DEP channel with the payment terminal according to the ISO / IEC 14443-4 protocol, with a latency of no more than 0.3 seconds from trigger detection to communication readiness. As another example, if the preset communication distance is 3 meters, when the mobile smart device identifies a specific service UUID broadcast by the payment terminal device within a 50ms scanning window, and the communication distance estimated by RSSI signal strength (distance = 10^((txPower - rssi) / 20)) is less than 3 meters, it indicates that the first object can enter the payment scenario for authorized payment. The mobile smart device can activate BLE communication mode, actively initiate a GATT connection, and establish an encrypted channel, with a latency of no more than 2 seconds from identification to communication readiness.

[0082] In one embodiment, the mobile smart device can poll its own near-field communication (NFC) signal characteristics in a payment scenario according to a polling cycle. NFC signal characteristics refer to signal characteristics in a near-field communication environment, including either NFC or BLE communication signal characteristics. NFC is a near-field communication technology where the device is powered and communicates via an external radio frequency field, requiring no internal power supply. Its operating frequency and communication distance are fixed; for example, the operating frequency is 13.56MHz, the communication distance is <5cm, and the interaction latency is <0.3 seconds. NFC is a passive mode, requiring the user carrying the mobile smart device to actively bring it close to the sensing device for payment to be completed. BLE (Bluetooth Low Energy) supports beacon broadcast mode and encrypted connections. Its operating frequency, communication distance, and connection latency are also fixed; for example, Bluetooth Low Energy 5.2 operates at a frequency of 2.4GHz, has a communication distance of 1-3 meters, and a connection latency of <0.5 seconds. As can be seen, the communication distance of NFC is much shorter than that of BLE.

[0083] NFC communication signal characteristics refer to the signal characteristics in the NFC communication environment, such as the NFC field strength. BLE communication signal characteristics refer to the signal characteristics in the BLE communication environment, such as the BLE beacon. The polling period is, for example, 100 milliseconds. By polling the signal characteristics in the communication environment, near-field communication signal characteristics can be periodically detected, and the corresponding communication mode can be automatically activated based on the detected near-field communication signal characteristics without any intervention from the target object.

[0084] Based on the detected near-field communication signal characteristics, a near-field communication channel is established between the mobile smart device and the payment terminal device in the payment scenario. The near-field communication channel is matched with the near-field communication signal characteristics. In one embodiment, a communication mode matching the detected near-field communication signal characteristics can be determined, and a near-field communication channel between the mobile smart device and the payment terminal device in the payment scenario can be established according to the matching communication mode. In this approach, at the communication layer, communication signal characteristics can be automatically detected periodically, eliminating the threshold for active operation of objects at the physical layer.

[0085] For example, when an NFC radio frequency field strength exceeding 3 A / m is detected, the NFC communication mode is activated. The mobile smart device is passively woken up via electromagnetic induction, without prior pairing, and establishes an ISO-DEP channel with the payment terminal device in accordance with the ISO / IEC 14443-4 protocol. The delay from trigger detection to communication readiness is no more than 0.3 seconds. This NFC communication mode is suitable for payment scenarios where terminals are fixed and in close proximity, such as convenience stores and supermarket checkouts. For instance, when a smart wearable device worn on the wrist of the first user approaches the POS machine, NFC is automatically activated and the channel is established.

[0086] For example, when a mobile smart device identifies a specific service UUID broadcast by a payment terminal within a 50ms scanning window, and the communication distance estimated by RSSI signal strength (distance = 10^((txPower - rssi) / 20)) is less than 3 meters, the BLE communication mode is activated. The mobile smart device actively initiates a GATT connection and establishes an encrypted channel, with a latency of no more than 2 seconds from identification to communication readiness. This BLE communication mode is suitable for payment scenarios with slightly longer sensing distances, such as subway turnstiles and parking lot gates. Taking the subway morning rush hour scenario as an example, when a user walks to about 2 meters from the turnstile, BLE scanning identifies the service UUID broadcast by the turnstile and begins to establish a connection. By the time the user reaches the turnstile, the channel is already ready, and the entire process is seamless.

[0087] When the first object enters the payment scenario, it indicates that the first object has the intention to make a payment. To ensure payment security, the mobile smart device can read N identity authentication results of the first object from its own memory and determine the identity confidence data of the first object based on the N identity authentication results of the first object. The identity confidence data (BioScore) is used to indicate the probability that the first object is the reference object.

[0088] In one embodiment, the authentication results include N items, each including a confidence score. When determining the identity confidence data of the first object based on the authentication results, the mobile smart device may include either of the implementations shown in (a) and (b) below: (a) The identity confidence data of the first object is obtained by integrating N confidence scores.

[0089] The confidence scores from N identity authentication results are merged to obtain a merged confidence score; this merged confidence score is then used as the identity confidence data for the first object. In one implementation, the fusion method can be average calculation or weighted summation. When using weighted summation, the weight of each confidence score in each identity authentication result is positively correlated with the confidence score itself; the higher the confidence score, the higher the weight. Optionally, the weights of the confidence scores in the N identity authentication results are each within the range of 0-1.

[0090] In this approach, by fusing the fused confidence scores obtained from N identity authentications, the probability of the first object being the reference object can be assessed by comprehensively considering the results of N identity authentications, rather than relying on the confidence scores from a single identity authentication result. This can effectively improve the reliability of identity confidence data and avoid situations where an inaccurate confidence score from a single instance is directly used as identity confidence data.

[0091] (ii) Select a portion of the confidence score to obtain the identity confidence data of the first object. Specifically, any one of the following implementation methods (2.1) and (2.2) can be used.

[0092] (2.1) Each identity authentication result includes not only a confidence score but also an authentication timestamp.

[0093] Mobile smart devices can obtain a target identity authentication result from N identity authentication results. The target identity authentication result is either the identity authentication result with the largest authentication timestamp among the N identity authentication results, or the target identity authentication result is the identity authentication result with the highest confidence score among the N identity authentication results. The confidence score in the target identity authentication result is determined as the identity confidence data of the first object. Alternatively, the confidence score in the target identity authentication result is calibrated according to the time interval between the authentication timestamp and the current timestamp to obtain a calibrated confidence score, and the calibrated confidence score is determined as the identity confidence data of the first object.

[0094] The current timestamp refers to the time when the first object enters the payment scenario. The duration between the authentication timestamp and the current timestamp refers to the absolute time difference between them, also known as the authentication validity period, which measures the time elapsed between the authentication timestamp and the current timestamp. Different duration intervals can be matched with different calibration values; one time interval matches one calibration value, which can be an integer less than or equal to 0. The authentication validity period is positively correlated with the absolute calibration value (i.e., the absolute value of the calibration value): the longer the authentication validity period, the larger the absolute calibration value; the shorter the authentication validity period, the smaller the absolute calibration value. For example, if the authentication validity period is less than or equal to 30 seconds, the calibration value is 0; if the authentication validity period is between 30 and 120 seconds, the calibration value can be -10; and if the authentication validity period is greater than or equal to 120 seconds, the calibration value is -20.

[0095] Mobile smart devices can determine the target calibration value as the calibration value that matches the time interval of the authentication validity period, and then use the sum of the target calibration value and the confidence score in the target identity authentication result as the calibrated confidence score. This method is based on the confidence score (match_score) in the latest authentication result, and a penalty score can be applied to the confidence score according to this authentication timestamp to achieve calibration. Based on this setting, it avoids using overly outdated identity authentication results to determine the identity confidence data of the first object, thus improving the reliability of the identity confidence data.

[0096] (2.2) As another implementation method, the target authentication result can also be the authentication result with a confidence score greater than a preset confidence score threshold among N identity authentication results. If there are multiple target authentication results, the mobile smart device can fuse the confidence scores of multiple target authentication results to obtain a reference confidence score, and determine the reference confidence score as the identity confidence data of the first object. The fusion method can be average calculation or weighted fusion. In this method, by fusing high confidence scores, the accuracy of the identity confidence data of the first object can be improved.

[0097] S203, obtain payment confidence data for the payment scenario, and determine the payment strategy for the first object in the payment scenario based on the identity confidence data of the first object and the payment confidence data of the payment scenario.

[0098] In one embodiment, payment confidence data is used to indicate the probability of a payment risk event occurring on a mobile smart device in a payment scenario; the payment risk event refers to an event that affects payment security. Payment confidence data includes at least one of the following: behavioral confidence data, credit confidence data, and scenario confidence data. Obtaining payment confidence data for a payment scenario may include at least one of the following steps 3.1-3.3: Step 3.1: Determine the behavioral confidence data of mobile smart devices based on the transaction frequency and authenticity of the transactions.

[0099] Transaction frequency refers to the number of transactions initiated by the same device within a preset time period. A transaction frequency score is determined based on the relationship between the transaction frequency and the preset transaction frequency. Specifically, if the transaction frequency is less than the preset transaction frequency, a first transaction frequency score is assigned, which is a value less than 0. For example, if a mobile smart device initiates more than 5 transactions within 30 minutes, its transaction frequency score is -20.

[0100] Transaction authenticity can be indicated by the displacement speed between two adjacent transactions. Since adjacent transactions are sequential in time, the displacement speed can be determined based on the distance between their geographical locations and the time difference between their transactions. The authenticity score is then determined based on the relationship between this displacement speed and a preset displacement speed. Specifically, if the displacement speed is greater than the preset displacement speed, the transaction is considered fraudulent, and the transaction authenticity score is assigned as the first transaction authenticity score, which is a value less than 0, such as -20. The preset displacement speed can be the upper limit of the physical movement of the mobile smart device, for example, a preset displacement speed of 300 km / h.

[0101] By fusing transaction frequency scores and transaction authenticity scores, a behavioral score can be obtained, which is then defined as the Behavior Score. This Behavior Score is used to indicate the probability of abnormal transaction operations on mobile smart devices.

[0102] Step 3.2: Determine the credit confidence level of the payment account based on the abnormal transaction records of the payment account logged in on the mobile smart device and the identity binding status of the payment account.

[0103] In one implementation, a payment account can be assigned an initial account value (e.g., 50 points). Abnormal transaction records in the payment account refer to disputed historical transaction records, also known as historical dispute records. These abnormal transaction records include, for example, transactions that have been complained about or refunded. Different reward values ​​can be set according to the severity of the abnormal transaction records, such as -10 to -30 points. If there are no abnormal transaction records in the payment account, a reward value of 10 points can be set. The identity binding status of the payment account is used to indicate whether the payment account is bound to the identity information of an object, i.e., whether real-name authentication has been completed. A status score can be set based on the identity binding status of the payment account. If the identity binding status indicates that the payment account is bound to the identity information of an object, a first status score (e.g., 15) can be obtained; if the identity binding status indicates that the payment account is bound to the identity information of an object, a second status score (e.g., 0) can be obtained. Mobile smart devices can obtain a credit score based on the initial account value, reward value, and status score of a payment account. This credit score can be used as the credit score of the payment account. The higher the credit score, the higher the credit score of the payment account, and the lower the credit score, the lower the credit score of the payment account.

[0104] Step 3.3: Determine the scenario confidence data of the payment scenario based on the transaction information of the target transaction related to the mobile smart device in the payment scenario.

[0105] Scenario confidence data is used to indicate the credibility of a target transaction in a payment scenario. In one embodiment, based on transaction information related to the target transaction in a payment scenario using a mobile smart device, at least one dimension of transaction confidence can be determined. These at least one dimension of transaction confidence are then fused to obtain scenario confidence data for the payment scenario. The transaction information may include at least one of the following: transaction object, transaction size, transaction time, and transaction geographical location; the at least one dimension of transaction confidence includes at least one of the following: transaction object confidence, transaction size confidence, transaction time confidence, and transaction location confidence; the transaction object confidence indicates the probability that the target transaction's transaction object is an abnormal transaction object; the transaction size confidence indicates the probability that the target transaction's transaction size is abnormal; the transaction time confidence indicates the probability that the target transaction's transaction time is abnormal; and the transaction location confidence indicates the probability that the target transaction's transaction geographical location is abnormal.

[0106] In one implementation, if the transaction information includes a transaction object, the transaction object score can be determined based on the transaction object of the target transaction, and the transaction object score can be determined as the transaction object confidence level. Optionally, the transaction object confidence level can be determined based on whether the transaction object is an authorized transaction object. If the object identifier (e.g., merchant ID) of the transaction object is included in the preset object list, the transaction object score can be set as the first object score (e.g., 40 points). If it is not included in the preset object list, the transaction object score can be set as the second object score (e.g., 10 points).

[0107] In one implementation, if the transaction information includes the transaction size, a transaction size score can be determined based on the transaction amount of the target transaction, and this score can be used as the transaction size confidence level. Specifically, if the transaction amount is lower than a first amount, the transaction size score is set to a first size score (e.g., 0 points); if the transaction amount is higher than a second amount, the transaction size score is set to a second size score (e.g., -20 points). Since the first amount is less than the second amount, the first size score is greater than the second size score. That is, if the transaction amount is large, it can be determined that the target transaction may be abnormal, and a lower size score is set as an indication. A lower transaction size score indicates a higher probability of abnormality.

[0108] In one implementation, if the transaction information includes the transaction time, a transaction time score can be determined based on the time interval in which the target transaction's transaction time falls, and this score can be used as the transaction time confidence level. If the time interval in which the transaction time falls is an abnormal time interval (e.g., 0:00 to 6:00 AM), the transaction time score can be set as a first time score (e.g., -10 points). If the time interval in which the transaction time falls is a non-abnormal time interval, the transaction time score can be set as a second time score (e.g., 0 points). Here, a non-abnormal time interval refers to a time interval other than an abnormal time interval.

[0109] In one implementation, if the transaction information includes the transaction's geographical location, a location deviation score can be determined based on the location deviation between the target transaction's geographical location and a preset area, and this location deviation score can be used as the transaction location confidence level. The preset area refers to an area where the mobile smart device's dwell time exceeds a preset dwell time. For example, if a mobile smart device generates transactions in a certain area for 20 out of 30 days, then that area is the preset area, also known as the user's frequently visited area. The location deviation between the target transaction's geographical location and the preset area refers to whether the target transaction's geographical location is within the preset area. If it exceeds the boundary of the preset area, the location deviation score is set as a first location score (e.g., -10 points); if it is within the preset area, the location deviation score is set as a second location score (e.g., 10 points), where the second location score is greater than the first location score.

[0110] As described above, this application can assess transaction security in payment scenarios from multiple dimensions, obtaining multi-dimensional transaction confidence levels. These multi-dimensional transaction confidence levels are then fused to obtain scenario confidence data. The multiple multi-dimensional transaction confidence levels can include various aspects such as transaction object confidence, transaction size confidence, transaction time confidence, and transaction location confidence. For example, scenario confidence data can be obtained by fusing transaction object confidence, transaction size confidence, transaction time confidence, and transaction location confidence. This scenario confidence data can be a scenario score. This approach improves the accuracy of scenario confidence data and enhances the accuracy of transaction security detection. In one embodiment, determining the payment strategy for the first object in the payment scenario based on the identity trust data of the first object and the payment trust data of the payment scenario may include the following steps 4.1-4.2: Step 4.1: Conduct a risk assessment based on the identity confidence data of the first object and the scenario confidence data of the payment scenario to obtain the payment risk level of the target transaction in the payment scenario.

[0111] In one embodiment, a mobile smart device can perform a comprehensive risk assessment based on the identity trust data of a first object and the payment trust data of the payment scenario to obtain a comprehensive risk score for the target transaction. The comprehensive risk score indicates the degree of risk of the target transaction, and is negatively correlated with the degree of risk. A higher comprehensive risk score indicates a lower degree of risk for the target transaction, while a lower score indicates a higher degree of risk. The risk level corresponding to the score range in which the comprehensive risk score of the target transaction falls is determined as the payment risk level.

[0112] Mobile smart devices can weight identity and payment confidence data to obtain a comprehensive risk score for the target transaction. As described above, payment confidence data can include at least one of the following: behavioral confidence data, credit confidence data, and scenario confidence data. For example, if the payment confidence data includes behavioral confidence data, credit confidence data, and scenario confidence data, and each type of confidence data is a score, then the confidence data for each dimension can be weighted and summed according to the weight of each dimension to obtain the comprehensive risk score. The specific expression is as follows: RiskScore=SceneScore×w1+BioScore×w2+CreditScore×w3+BehaviorScore×w4 Among them, RiskScore represents the overall risk score, SceneScore represents the scene score (i.e., scene confidence data), w1 represents the weight of the scene dimension (e.g., 0.4), BioScore represents the biometric score (i.e., identity confidence data), w2 represents the weight of the biometric dimension (e.g., 0.3), CreditScore represents the credit score (i.e., credit confidence data), w3 represents the weight of the credit dimension (e.g., 0.2), BehaviorScore represents the behavior score (i.e., behavior confidence data), and w4 represents the weight of the behavior dimension (e.g., 0.1).

[0113] If the overall risk score of the target transaction is in the first scoring range, then the first risk level can be determined as the payment risk level. If the overall risk score of the target transaction is in the second scoring range, then the second risk level can be determined as the payment risk level. If the overall risk score of the target transaction is in the third scoring range, then the third risk level can be determined as the payment risk level.

[0114] The maximum value in the first scoring interval is less than the minimum value in the second scoring interval, and the maximum value in the second scoring interval is less than the minimum value in the third scoring interval. For example, when the comprehensive risk score (RiskScore) is not lower than 80, the payment risk level is the first risk level; when the comprehensive risk score (RiskScore) is between 60 and 80 (inclusive, exclusive), the payment risk level is the second risk level; and when the comprehensive risk score (RiskScore) is lower than 60, the payment risk level is the third risk level.

[0115] Step 4.2: Determine the payment strategy for the first party in the payment scenario based on the payment risk level of the target transaction.

[0116] In one embodiment, if the payment risk level of the target transaction is a first risk level, a first authorization rule is determined and added to the payment strategy for the first object in the payment scenario; if the payment risk level of the target transaction is a second risk level, a second authorization rule is determined and added to the payment strategy for the first object in the payment scenario; if the payment risk level of the target transaction is a third risk level, a third authorization rule is determined and added to the payment strategy for the first object in the payment scenario; wherein, the risk level corresponding to the first risk level is less than the risk level corresponding to the second risk level, and the risk level corresponding to the second risk level is less than the risk level corresponding to the third risk level.

[0117] The authorization rules include authorization status and payment limit. Authorization status indicates whether the mobile smart device's payment function is available, and the payment limit indicates the maximum allowed transaction amount. The authorization status in the first and second authorization rules both indicate that the mobile smart device's payment function is allowed. The authorization status in the third authorization rule indicates that the mobile smart device's payment function is prohibited. The payment limit in the first authorization rule is greater than the payment limit in the second authorization rule. The payment limit in the first authorization rule can be a preset payment limit, and the payment limit in the second authorization rule can be determined based on a preset ratio and a preset payment limit. For example, if the preset ratio is 50%, then the payment limit is 50% of the preset payment limit.

[0118] When a payment strategy includes a first authorization rule and a second authorization rule, the payment strategy can instruct that payment processing be authorized for the first object in the payment scenario. When a payment strategy includes a third authorization rule, the payment strategy can instruct that payment processing be refused for the first object in the payment scenario.

[0119] For example, if the payment risk level is the first risk level, the payment strategy indicates that the full amount will be automatically authorized; if the payment risk level is the second risk level, the payment strategy indicates that the payment will be automatically authorized but the payment amount will be limited to 50%; if the payment risk level is the third risk level, the payment strategy indicates that the payment will be rejected and a secondary confirmation request can be pushed through the mobile app. If the user completes the confirmation within 30 seconds, the payment will be re-initiated; otherwise, it will be considered a rejection.

[0120] To facilitate understanding of the above process, let's take the subway entry scenario as an example. When the first user walks to the vicinity of the subway station gate, after the BLE handshake is completed, the most recent confidence score (e.g., 96.9 points, within the last 18 seconds) can be read. Combined with the scenario score (the authorized user of Q subway) and the behavior score (no abnormalities), the comprehensive risk score RiskScore is calculated to be 88 points. At this time, the conditions for full automatic authorization are met, the payment amount in the payment strategy is the preset payment amount, and the authorization status indicates that the payment function is allowed to be used. The user is unaware of the entire process.

[0121] Based on the above logic, a comprehensive risk assessment can be conducted by integrating confidence data from multiple dimensions, such as payment scenario, identity, object credit, and behavioral characteristics. The payment risk level can then be determined based on the comprehensive risk score obtained from the assessment, and corresponding payment strategies can be configured accordingly. In this way, payment security is no longer guaranteed by a fixed password, but by the dynamic guarantee of the comprehensive confidence level of "this object wearing this device in this scenario at this moment," which can effectively ensure payment security.

[0122] By comprehensively evaluating multiple dimensions such as payment scenario, identity, creditworthiness, and behavioral characteristics in real time, a comprehensive risk score is obtained. Payment strategies can be dynamically adjusted based on this score to achieve dynamic risk control, balancing security and convenience. For example, Table 2 below illustrates the comparison data of the risk control strategies: Table 2

[0123] As shown in Table 2, which compares the different risk control strategies in terms of fraud detection rate, false alarm rate, and user experience, the risk control strategy based on dynamic multi-factor provided in this application, compared with the fixed limit, increases the fraud detection accuracy from 85% to 98.7%, reduces the false alarm rate from 8% to 1.5%, and improves the user experience from medium to excellent.

[0124] S204. In accordance with the determined payment strategy, perform payment processing for the first object in the payment scenario.

[0125] Due to the establishment of a near-field communication channel between mobile smart devices and payment terminal devices, payment scenarios can include NFC payment scenarios or BLE payment scenarios. The payment strategy can include a payment method, which can be either NFC or BLE payment. In NFC payment scenarios, the entire process takes no more than 0.5 seconds, while in BLE payment scenarios, the entire process takes no more than 2 seconds. These payment methods are 16 to 30 times more efficient than traditional QR code payments. Table 3 below shows a comparison of various data for different payment methods. Table 3

[0126] As shown in Table 3 above, the contactless payment of this application can significantly reduce the number of operation steps and average time consumption, and can also significantly improve efficiency; the payment action is less dependent on active operation, and can be completed even when hands are occupied, in motion, or in medical scenarios.

[0127] The data processing method based on mobile smart devices provided in this application embodiment can periodically authenticate the identity of the first object, enabling proactive and continuous identity monitoring of the first object wearing the mobile smart device. This effectively improves the online identity monitoring capability for the wearer of the mobile smart device and prevents unauthorized use by other objects for payment in the event of a lost mobile smart device. When the first object enters a payment scenario, it indicates that the first object has the intention to pay. By comprehensively considering both identity confidence data and payment confidence data, a payment strategy is determined. On the one hand, the dynamic nature of the confidence data allows for more flexible formulation of payment strategies adapted to the payment scenario and the first object, ensuring the security of the first object using the mobile smart device for payment in the current payment scenario. On the other hand, considering the security of both the identity dimension and the payment scenario dimension allows for a more comprehensive consideration of factors affecting payment security when formulating a payment strategy. Executing payment processing for the first object based on the payment strategy in the payment scenario effectively ensures payment security.

[0128] In one embodiment, a payment strategy can be used to indicate whether to authorize payment processing for a first object in a payment scenario. If the payment strategy indicates that payment processing should not be performed for the first object in a payment scenario, then the implementation of S204 may include: refusing to perform payment processing according to the payment strategy and sending secondary confirmation information to the application associated with the payment function. If the secondary confirmation information is rejected or timed out, the payment function of the mobile smart device can be locked. Timed out confirmation means that no confirmation operation for the secondary confirmation information is received within a preset time. If the secondary confirmation information is confirmed within the preset time, the payment processing can be re-executed.

[0129] In another embodiment, the payment strategy is used to instruct the execution of payment processing for the first object in a payment scenario. The implementation of S204 may include the following S2041 and S2043: S2041. Following the instructions of the determined payment strategy, obtain the transaction data of the target transaction in the payment scenario. The target transaction is the transaction generated when the first object enters the payment scenario.

[0130] The payment strategy includes an authorization status. When the payment strategy is used to instruct the execution of payment processing for a first object in a payment scenario, the authorization status indicates that the payment function of the mobile smart device is available. This allows the acquisition of transaction data for the target transaction in the payment scenario. This transaction data includes at least one of the following: a transaction object identifier (merchantID), a transaction amount, a transaction resource type, a transaction time (e.g., a millisecond-level Unix timestamp), a transaction sequence number (e.g., a 32-bit transaction sequence number txSeq), and a secure random number (nonce). The transaction asset refers to the data resource used for the transaction; the transaction sequence number has a monotonically increasing characteristic, incrementing by 1 for each payment and not returning to zero upon power failure; the secure random number is, for example, a 128-bit cryptographically secure random number, which can be used to prevent replay attacks.

[0131] S2042. Generate a payment voucher based on the transaction data of the target transaction, and send the payment voucher to the payment terminal device through a near-field communication channel, so that the payment terminal device can process the payment voucher according to the network status of the payment terminal device.

[0132] Mobile smart devices can call a security chip to generate payment credentials in an isolated environment, where external programs cannot access the intermediate process, ensuring that the construction of payment credentials is not interrupted.

[0133] In one implementation, generating a payment credential based on the transaction data of the target transaction may include the following: performing a hash calculation on the transaction data of the target transaction to obtain a transaction hash value; using the private key in the mobile smart device to sign the transaction hash value to obtain signature data; obtaining the device hash value of the mobile smart device; and encapsulating the transaction data, signature data, and device hash value of the mobile smart device into a payment credential.

[0134] Mobile smart devices can construct a transaction data structure TxData based on the transaction data of the target transaction. Hash calculations are then performed on the transaction data within TxData to obtain a transaction hash value. Next, the secure chip uses its internally stored private key to sign the transaction hash value, resulting in a signature data signature. This signature processing can be based on an Elliptic Curve Digital Signature Algorithm (ECDSA), such as the ECDSA-P256 digital signature used for signing and verifying transaction credentials. This signature processing ensures that the transaction is non-repudiable and tamper-proof. Since the private key used for signature processing can be generated and stored internally within the secure chip, and cannot be read or exported externally, the signature processing can also be completed within the isolated environment of the secure chip. This allows payment credential signing to be completed within the secure chip, ensuring the private key remains within the chip and guaranteeing its non-forgeability.

[0135] The device hash, also known as the device certificate hash (device_cert_hash), uniquely identifies a mobile smart device, indicating which device initiated the transaction. The transaction data for the target transaction exists in the form of a transaction data structure (TxData). The mobile smart device can encapsulate the transaction data structure TxData, the signature data (signature), and the device hash (device_cert_hash) into a payment credential (ARQC). This ARQC is composed of TxData, the signature, and the device hash.

[0136] Mobile smart devices can send payment credentials to payment terminal devices via the currently active near-field communication channel. The currently active near-field communication channel refers to the near-field communication channel established between the mobile smart device and the payment terminal device. The near-field communication channel can be an NFC channel or a BLE channel. If the currently active communication channel is an NFC channel, the payment credentials can be sent via SO-DEP APDU messages; if the currently active communication channel is a BLE channel, the payment credentials can be sent via GATTCharacteristicWrite operations.

[0137] In one embodiment, the payment terminal device can process the payment credential based on its own network status. The processing method, based on whether the network is available as indicated by the payment terminal device's network status, includes any of the following: (a) Online payment execution.

[0138] If the network status of the payment terminal device indicates that the network is available, the payment terminal device will send the payment voucher to the cloud settlement device, which will then process the payment settlement according to the payment voucher and return the settlement result to the payment terminal device.

[0139] When the network status of the payment terminal device indicates that the network is available (i.e., it has a network connection), after receiving the payment voucher, the payment terminal device can forward the payment voucher to the cloud settlement device through its own network. The cloud settlement device can be a device in the cloud settlement system that matches the type of transaction asset.

[0140] In one implementation, when the cloud-based settlement device performs payment settlement according to the payment voucher, it can verify the payment voucher. If the payment voucher is verified, the corresponding amount of digital resources is transferred from the payment account of the mobile smart device according to the payment voucher to obtain the settlement result. If the payment voucher is not verified, the cloud-based settlement device can directly return a settlement result indicating settlement failure to the payment terminal device.

[0141] Optionally, the verification of payment vouchers by the cloud-based settlement device may include at least one of the following: 1. Verifying the signature data in the payment voucher using the public key corresponding to the mobile smart device; wherein, the public key corresponds to the device certificate, and the validity of the signature data can be verified through the public key. 2. Verifying the monotonically increasing nature of the transaction sequence number in the payment voucher; the cloud-based settlement device can verify whether the transaction sequence number is strictly monotonically increasing based on existing transaction sequence numbers and the transaction sequence number in the payment voucher, thus preventing replay attacks. 3. Verifying whether the deviation between the transaction time in the payment voucher and the current time of the cloud-based settlement device is less than or equal to a preset duration. The current time of the cloud-based settlement device can be understood as the server time. The preset duration is, for example, 5 minutes. The absolute difference between the transaction time (timestamp) and the current time of the cloud-based settlement device can be used as the deviation duration. By verifying whether the deviation duration does not exceed the preset duration, the synchronization of processing the same transaction by each device can be maintained. 4. Verifying whether the balance in the payment account of the mobile smart device is greater than the transaction amount in the payment voucher; the balance in the payment account must not be less than the transaction amount in the payment voucher to effectively transfer resources and ensure successful payment. 5. Verify whether the payment limit of the payment account in the payment strategy is greater than the transaction amount in the payment voucher; the payment limit refers to the upper limit of the amount allowed to be paid in a single transaction. Only if the payment limit is greater than the transaction amount in the payment voucher can the validity of the payment be guaranteed.

[0142] Based on the above verification criteria, successful payment voucher verification may include the following: 1. The verification result of the signature data in the payment voucher indicates that the signature is valid; 2. The transaction sequence number in the payment voucher is monotonically increasing; 3. The deviation between the transaction time in the payment voucher and the current time of the cloud settlement device is less than or equal to a preset duration; 4. The transaction amount in the payment voucher is less than or equal to the balance in the payment account; 5. The transaction amount in the payment voucher is less than or equal to the payment limit of the payment account.

[0143] Once the payment voucher is verified, the cloud-based settlement device can perform atomic deductions. An atomic deduction means that the operation of deducting funds from the payment account balance in a cloud computing environment is atomic; that is, the entire deduction process either succeeds entirely or fails entirely. The deduction process includes calculating the new value based on the transaction amount in the payment voucher and the payment account balance, transferring the digital resources of the transaction amount from the payment account, and updating the account balance. The cloud-based settlement device can generate transaction records and write them to the blockchain, generating an immutable transaction hash (TxHash).

[0144] Cloud-based settlement devices can return settlement results to payment terminal devices. These results may include authorization information (such as an authorization code), indicating successful verification of the payment credential. Payment terminal devices can then send the settlement results to mobile smart devices via NFC or BLE channels; the mobile smart devices can then output payment results based on these results.

[0145] (ii) Offline payment execution.

[0146] If the network status of the payment terminal device indicates that the network is unavailable, the payment terminal device will verify the signature of the payment credential. In one embodiment, the payment terminal device can use a locally pre-stored device public key certificate to verify the signature of the payment credential. If the signature verification is successful, the payment terminal device can control the execution of corresponding operations. For example, if the payment terminal device is a subway gate, it can control the gate to open by verifying the signature of the payment credential when the network is unavailable. When the payment terminal device is in a network-free state, the offline payment verification loop can be completed collaboratively by the mobile smart device and the payment terminal device.

[0147] In one embodiment, in addition to sending the payment voucher to the payment terminal device for signature verification, the mobile smart device can also update the account balance of its payment account according to the payment voucher; and generate a transaction record based on the transaction data of the target transaction and the payment voucher. If the network status of the mobile smart device also indicates that the network is unavailable, the transaction record is set to a pending settlement state, and the pending settlement transaction record is encrypted and stored in the mobile smart device. If the network status of the mobile smart device indicates that the network is available, the transaction record can be directly sent to the cloud settlement device without being marked as pending settlement for encrypted storage. The cloud settlement device can verify the payment voucher and, after successful verification, process the settlement according to the transaction data.

[0148] Mobile smart devices can update the account balance of the payment account in an atomic transaction manner according to the payment amount in the payment voucher, and increment the Application Transaction Counter (ATC) in the payment voucher by 1. During this operation, the atomicity of the SE chip flash can be utilized to ensure that even if the device loses power unexpectedly during the execution process, the data consistency will not be affected.

[0149] The transaction data of the target transaction exists in the form of a transaction data structure TxData. Mobile smart devices can combine the transaction data structure TxData and payment vouchers into a transaction record and mark the transaction record as pending settlement, i.e., status="pending_settlement". The transaction record can be encrypted (e.g., AES-256 encryption) and appended to the flash storage area of ​​the SE chip.

[0150] For example, in a subway scenario, the payment terminal device is a subway gate. After the signature verification is successful, the gate can perform the opening action based on the opening command. During this process, no network access is required. From the establishment of communication between the mobile smart device and the payment terminal device to the opening of the gate, the end-to-end latency is no more than 0.5 seconds. The object can walk through without stopping. The mobile smart device vibrates once and can display the payment result on the screen. The payment result can be used to indicate that the offline payment was successful and the payment amount.

[0151] In one embodiment, before updating the account balance of the mobile smart device's payment account according to the payment voucher, the mobile smart device can detect whether the target transaction meets the offline payment conditions. If the offline payment conditions are met, the step of updating the account balance of the mobile smart device's payment account according to the payment voucher is triggered. The sum of the updated account balance and the payment amount in the payment voucher is equal to the account balance before the update.

[0152] The following are some of the conditions that a target transaction can meet for offline payment: 1. The balance in the mobile smart device's payment account is greater than the transaction amount of the target transaction. The payment account can include an offline transaction account, meaning that the balance of the offline transaction account is not less than the payment amount of this target transaction. 2. The transaction object of the target transaction is an authorized object of the mobile smart device. For example, the object identifier of the transaction object (such as a merchant ID) exists in the device's pre-set authorized object list. 3. The remaining storage space of the mobile smart device is greater than the data volume of the target transaction. The storage space can be sufficient to store the transaction records of the target transaction in the flash storage space of the mobile smart device's SE chip, for example, the number of pending settlement records in the flash storage space does not exceed 1000. 4. The payment limit of the mobile smart device's payment account is greater than the transaction amount of the target transaction. If any of the above conditions are not met, the payment process can be terminated and a reason message can be sent to the first object.

[0153] The aforementioned offline payment execution method applies to situations where the network is unavailable. For mobile smart devices without a network connection, transaction data can be encrypted and stored in the mobile smart device's security chip. This allows for automatic uploading to the cloud settlement device for settlement once the network is restored; this is also known as offline transaction temporary storage. When neither the payment terminal nor the mobile smart device has a network connection, the transaction can be completed by exchanging encrypted credentials via near-field communication (NFC). The transaction data is temporarily stored in each device and settled synchronously upon subsequent network connectivity; this can be called dual offline payment.

[0154] Based on the above embodiments, and depending on whether the network of the payment terminal device and the mobile smart device is available, payment processing based on payment credentials may include the contents shown in Table 4 below: Table 4

[0155] S2043. Output the payment result obtained by performing payment processing on the first object in the payment scenario.

[0156] In one implementation, if it is an online payment method, the mobile smart device can receive the settlement result returned by the cloud settlement device through the payment terminal device, or the mobile smart device can receive the settlement result directly returned by the cloud settlement device; based on the settlement result, the payment result obtained by performing payment processing on the first object in the payment scenario can be output.

[0157] In one implementation, if it is an offline payment method, the mobile smart device can receive the signature verification result, and if the signature verification result indicates that the signature verification is successful, it can perform an atomic deduction operation, and after the atomic deduction operation is successfully executed, it can output the payment result obtained by performing payment processing on the first object in the payment scenario.

[0158] In one implementation, after receiving the settlement result, the mobile smart device performs a preset physical vibration for a preset duration, such as 200 milliseconds. The payment result can then be displayed on the mobile smart device's screen. If the settlement result indicates successful settlement, then the payment result indicates successful payment and payment details (e.g., transaction amount); if the settlement result indicates failed settlement, then the payment result indicates payment failure. For example, in a convenience store NFC payment scenario, from the moment the first person wears the wearable device closes to the POS machine to receiving the payment success feedback, the entire process delay is no more than 1.5 seconds, requiring almost no manual operation.

[0159] In one implementation, whenever a cloud-based settlement device successfully settles a payment voucher, the cloud-based settlement device can obtain the transaction hash value of the transaction data in the payment voucher and upload the transaction hash value (e.g., SHA-256) to the blockchain network to achieve blockchain-based evidence storage of the transaction data, thereby ensuring that the transaction records are immutable and quickly identifying disputed transaction records.

[0160] In one implementation, based on the on-chain recording of transaction hashes, cloud-based settlement devices can automatically adjudicate disputed transaction records according to identity authentication logs (used to record identity authentication results) and device location trajectories, obtaining a ruling result. This ruling result indicates the winning party among the two parties involved in the transaction record, and the balance of the payment account can be updated based on the ruling result. For example, if the winning party is the seller, then the corresponding amount of digital resources needs to be paid from the payment account, and the balance of the payment account decreases. If the winning party is the buyer, then the corresponding amount of digital resources can be refunded to the payment account, and the balance of the payment account increases. Compared with manual investigation, the above adjudication method is less time-consuming and significantly improves efficiency; the identity authentication logs and device location trajectories, as a complete chain of evidence, are tamper-proof and their credibility is also improved. For example, the comparison data of dispute resolution methods shown in Table 5 below illustrates this: Table 5

[0161] As shown in Table 5, this application uses blockchain for dispute resolution, which has a shorter average processing time and higher credibility of evidence compared to traditional manual investigation and centralized database storage, thus balancing efficiency and reliability.

[0162] In one embodiment, the mobile smart device can detect its network status according to a detection cycle specified by a timed detection task, for example, detecting the network status of the mobile smart device every 30 seconds according to the timed detection task. If the network status of the mobile smart device indicates that the network is available, then the transaction records in the pending settlement state are retrieved from the mobile smart device. For example, when a subway train exits a tunnel or a vehicle exits an underground parking garage, the settlement process can be triggered immediately, which includes retrieving the transaction records in the pending settlement state.

[0163] When the network is unavailable, the corresponding transaction records are marked as pending settlement and stored in the mobile smart device. When the network of the mobile smart device changes from unavailable to available, some pending settlement transaction records will accumulate and remain unprocessed. Therefore, the mobile smart device can directly send the transaction records to the cloud settlement device, which will then process the transaction records according to the transaction records and return the settlement results corresponding to the transaction records to the mobile smart device. Based on the settlement results corresponding to the transaction records, the transaction records in the mobile smart device are updated.

[0164] The secure chip flash storage of mobile smart devices stores multiple transaction records, from which transactions awaiting settlement can be selected. If multiple transactions are awaiting settlement, they can be sorted in ascending order of their transaction numbers to obtain a sorted list. A batch settlement request is then constructed based on this sorted list and sent to the cloud settlement device. The cloud settlement device receives the sorted list and processes it sequentially, ensuring that settlement follows the order of transactions and preventing errors. For example, the sorted transaction records can be constructed as a JSON-formatted batch settlement request and uploaded to the cloud settlement device via HTTPS (TLS 1.3 protocol) using a POST method. The request header of the batch settlement request includes an HMAC-SHA256 signature to prevent tampering during transmission.

[0165] When processing transactions according to records, cloud-based settlement devices can verify these records. Upon successful verification, the device transfers the digital resources of the transaction amount from the payment account based on the payment voucher included in the transaction record. If multiple transaction records are pending settlement, the following verifications can be performed sequentially for each record: validity verification of signature data (e.g., ECDSA signature) → continuity verification of transaction sequence number txSeq (to prevent replay and missed transmission) → validity verification of transaction timestamp (within 7 days) → sufficiency verification of cloud balance. For transactions that pass verification (i.e., successful verification), the deduction can be processed, and the transaction record status can be updated from pending settlement to settled. For transactions that fail verification (i.e., verification fails), the transaction record status can be marked as failed, and the payment account balance can be updated based on the corresponding payment amount. The updated account balance is higher than the original account balance by the payment amount.

[0166] Mobile smart devices can receive settlement results returned by cloud-based settlement devices and update local transaction records based on these results, including but not limited to updating the status of transaction records and the number of transaction records. In one embodiment, updating transaction records in the mobile smart device based on the settlement result corresponding to a transaction record may include the following: if the settlement result corresponding to a transaction record indicates successful settlement, the pending settlement status of the transaction record is updated to a settled status, and the transaction record in the settled status is deleted. Based on this, transaction records that have completed settlement can be deleted from the mobile smart device to free up storage space used for storing transaction records. Optionally, deletion can be performed immediately after the status is updated to a settled status, or it can be performed after a preset time period (e.g., 24 hours).

[0167] If multiple pending transaction records have been processed, a settlement summary notification message can be pushed through the application associated with the payment function. This message indicates the number of offline transactions that have been settled and the total settlement amount. For example, the settlement summary notification message might read: "You have X offline transactions that have been settled, with a total deduction of Y." The user can view the transaction details for each transaction within the application. These details include, but are not limited to, the confidence score obtained from identity authentication, the communication method, and the settlement timestamp.

[0168] If the settlement result corresponding to the transaction record indicates settlement failure, the transaction status of the transaction record will be updated to failure status, and the balance in the payment account will be updated according to the transaction amount in the transaction record. The updated balance will be increased by the transaction amount compared to the amount before the update.

[0169] This application utilizes a closed-loop design that combines offline payment capabilities with automatic settlement. When a mobile smart device lacks a network connection, it automatically switches to the offline payment path. Once the network is restored, batch settlement is automatically completed without the recipient's awareness. Based on the offline payment method, it effectively and comprehensively covers weak / no-network scenarios. Through the offline account built into the mobile smart device's security chip (storing up to 1000 transactions, with a default limit of 500 yuan), it supports payment completion when neither the mobile smart device nor the payment terminal has a network connection. Automatic batch settlement occurs after network restoration, requiring no intervention from the recipient. Compared to mobile payment solutions that rely on real-time network connectivity, adding this offline payment capability effectively enhances the diversity of covered scenarios, expanding the coverage by approximately 30%. It enables comprehensive coverage in weak or no-network scenarios such as subway tunnels, underground parking lots, and hospital basements, avoiding payment failures caused by real-time network verification in these scenarios.

[0170] To facilitate understanding of the above embodiments, this application combines... Figure 4 The data processing interaction process shown herein provides a complete description of the embodiments illustrated in this application. The data processing interaction process may include the following steps.

[0171] Mobile smart devices can perform the following steps S11-S15: S11. Drive the mobile smart device worn by the first object to perform multiple identity authentications on the first object according to the preset authentication cycle, and obtain the identity authentication result.

[0172] S12. In response to the first object entering the payment scenario, obtain the identity authentication result from the mobile smart device, and determine the identity confidence data of the first object based on the identity authentication result.

[0173] S13. Obtain payment confidence data for the payment scenario, and determine the payment strategy for the first object in the payment scenario based on the identity confidence data of the first object and the payment confidence data of the payment scenario.

[0174] S14. Obtain the transaction data of the target transaction in the payment scenario according to the instructions of the determined payment strategy.

[0175] S15. Generate payment vouchers based on the transaction data of the target transaction.

[0176] Payment can be made by mobile smart devices interacting with other devices, depending on network availability. This can include the following two payment execution methods.

[0177] A. Online Payment. Online payment may include the following process: S16, The mobile smart device sends a payment voucher to the payment terminal device. S17, The payment terminal device sends the payment voucher to the cloud settlement device. S18a, The cloud settlement device verifies the payment voucher. S18b, After successful verification, the cloud settlement device settles the payment according to the payment voucher. S19a, The cloud settlement device returns the settlement result to the payment terminal device. S19b, Transaction data is uploaded to the blockchain. Specifically, the cloud settlement device sends the transaction data to the blockchain network to upload the transaction data to the blockchain. S20, The payment terminal device returns the settlement result to the mobile smart device. S21, The mobile smart device outputs the payment result.

[0178] B. Offline payment.

[0179] S22. The mobile smart device sends a payment voucher to the payment terminal device. S23. The payment terminal device verifies the payment voucher and obtains the signature verification result. S24. The payment account balance is updated, a transaction record is generated, and it is marked as pending settlement and stored encrypted. S25. The payment result is output.

[0180] Because of the existence of pending transaction records, mobile smart devices can also periodically clear locally stored pending transaction records. The automatic settlement process includes the following steps S26-S29: S26. The mobile smart device detects network availability and packages the pending transaction records into a batch settlement request. S27. The mobile smart device sends the batch settlement request (including multiple pending transaction records) to the cloud settlement device. S28. The cloud settlement device settles transactions in order. S29. Transaction data is uploaded to the blockchain; the cloud settlement device hashes the transaction data from successfully settled transaction records and sends it to the blockchain network for storage.

[0181] Through the above methods, the identity of the first party can be monitored in real time and continuously via periodic identity authentication. By combining the identity confidence data determined by the identity authentication results with the payment confidence data of the payment scenario, a payment strategy to ensure payment security can be determined, and seamless payment can be achieved in the payment scenario according to the payment strategy. Seamless payment refers to a payment method in which payment authentication and transaction are automatically completed through proximity sensing (such as NFC or BLE) while the first party is wearing a mobile smart device (such as a smart wearable device). In this method, there is no need for active operations such as entering a password or scanning a code. For example, in BLE mode, payment can be completed without even taking out the mobile smart device.

[0182] To facilitate understanding of the above embodiments, this application provides a schematic diagram of the entire data processing flow for illustration. See [link / reference]. Figure 5 The flowchart shown includes the following steps: Step 1: Biometric Template Initialization. This step can be performed once when an object is first bound to a device to establish the biometric baseline data required for subsequent continuous identity authentication. The mobile smart device can collect the resting and gait data of the reference object and extract multi-dimensional biometric vectors (such as 30-dimensional features) as biometric baseline data. The biometric baseline data is then encrypted and stored in the secure chip of the mobile smart device.

[0183] Step 2: Continuous Identity Authentication. This step can run continuously in the background of the mobile smart device. Identity authentication yields a confidence score (i.e., a matching score). If the confidence score is in the first score range (e.g., greater than or equal to 95), full authorization is granted. Full authorization means the payment function is available and the payment amount is the preset limit. If the confidence score is in the second score range (e.g., the second score range is [90, 95)), a preset percentage authorization is granted. A preset percentage authorization means the payment function is available, but the payment amount is set to a preset percentage (e.g., 50%). If the confidence score is in the third score range (e.g., less than 90), the payment function is locked, and an alarm notification is pushed. The payment function awaits unlocking.

[0184] Step 3: Payment Terminal Detection and Communication Switching. The device's main program continuously polls the communication environment every 100ms and automatically selects the communication mode based on the current signal characteristics, without requiring any user intervention.

[0185] Step 4: Dynamic Risk Scoring. When each payment is triggered, a comprehensive risk score can be calculated from biological, scenario, behavioral, and credit dimensions. A payment strategy is then formulated based on the comprehensive risk score, which may include setting payment limits and indicating whether to authorize payment functions.

[0186] Step 5: Payment voucher generation. The mobile smart device can use a private key to sign the transaction hash value of the transaction data within the secure chip, so the private key does not leave the secure chip.

[0187] Step 6: Online Payment. The payment voucher can be sent to the payment terminal device, which then submits it to the cloud settlement device. The cloud settlement device can verify the signature of the payment voucher and deduct the payment, and can also store the transaction hash value in the payment voucher on the blockchain.

[0188] Step 7: Offline Payment. Mobile smart devices can deduct digital resources from the offline payment account through atomic operations and encrypt the transaction record to the non-volatile storage area of ​​a secure chip for settlement.

[0189] Step 8: Automatic Settlement. During automatic settlement, transaction records can be uploaded to the cloud settlement device in batches according to the transaction number for verification. If the settlement is successful, the payment will be deducted; if the settlement fails, a refund will be issued. Settlement notifications can also be pushed to the system.

[0190] The payment process shown in steps 1-8 above achieves security, convenience, and full-scenario coverage through multimodal biometric continuous authentication, NFC / BLE converged communication and offline temporary storage, and dynamic risk limit coordination.

[0191] In one embodiment, a mobile smart device may display a payment interface containing a payment result in response to a first object entering a payment scenario. For example, as... Figure 6a The diagram shown is a screenshot of the payment interface. In addition to displaying "payment successful", the interface also shows the payment amount as 3, "offline payment", "transit location: xx city xx station", and the offline payment account balance as 232.

[0192] In one embodiment, a mobile smart device can respond to a push request by outputting a payment notification message in an application associated with the payment function. This payment notification message is used to notify the payment result. If the payment notification message is triggered, transaction details can be displayed, including at least one of the following: confidence score obtained from identity authentication, payment method, settlement time, transaction type, payment device type, etc. For example, such as... Figure 6b The diagram shown illustrates the transaction details interface. The transaction details information is displayed on the transaction details interface, which includes a transaction information display area and a security verification information display area. The transaction information display area shows the merchant name, transaction type, transaction time, payment method, and payment device. The security verification information display area shows the biometric authentication result and the risk assessment result.

[0193] The data processing solution provided in this application can be deployed in applications and combined with mobile smart device SDKs, payment accounts, application payment functions, and location services to provide users with a seamless payment experience across all scenarios through the biometric and near-field communication capabilities of mobile smart devices.

[0194] The following uses the subway station entry scenario and mobile smart devices as smart wearable devices as examples to describe the interaction logic and technical collaboration process. This scenario also covers: fully automatic payment without active operation and offline closed loop in the absence of network environment.

[0195] Overall, Subject A wore a smartwatch with a payment account linked to it and walked to the subway station at 8 a.m. on a weekday. Subject A's hand never left his pocket and he never looked at his wrist. However, the moment he passed through the turnstile, the turnstile opened automatically and the watch vibrated slightly, achieving a seamless payment without Subject A having to perform any operation.

[0196] (1) Before entering the station: The system has completed identity verification in the background.

[0197] While walking, Person A's watch continuously performed identity authentication in the background. Every 5 seconds, the device extracted biometric data and compared it to the baseline template written into the SE chip during initial binding. The current matching score was 96.9 (threshold ≥ 95), indicating the watch was worn by the highly trusted individual, and the payment function was fully authorized. This determination was completed before Person A approached the gate and was updated continuously. When he was approximately 2 meters from the gate, the watch's BLE scanning module identified the specific service UUID broadcast by the gate, automatically estimated the distance, and established an encrypted connection within 500 milliseconds. At this point, the system read the most recent authentication result (96.9 points, within 18 seconds), scene confidence data, behavioral confidence data, and credit confidence data, calculating a comprehensive risk score of 88 points, meeting the conditions for full automatic authorization. Throughout the entire process, Person A was completely unaware and continued walking.

[0198] (2) At the moment of passing through the gate: the voucher generation and offline payment are completed within 0.5 seconds.

[0199] When Object A's wrist enters the gate's sensing range, the SE chip immediately constructs transaction data internally (including merchant ID, transaction amount 3, millisecond-level timestamp, monotonically increasing sequence number txSeq=1247, and a 128-bit random nonce), performs ECDSA signing using the device's private key, assembles a payment credential TC, and sends it to the gate via BLE. At this time, the subway train is running in the tunnel section, and the gate is offline. The gate uses the locally cached device public key certificate to verify the TC signature. After successful verification, it directly controls the electromagnetic lock to open the gate. The entire verification process does not rely on any cloud requests. Simultaneously, the watch's SE chip atomically deducts the offline wallet balance (2^35→2^32), writes the encrypted transaction record to the SE chip's Flash, and marks it as "pending settlement." From the BLE handshake to the gate opening, the entire process takes less than 0.5 seconds, and Object A walks through directly without stopping.

[0200] (3) Feedback received by object A.

[0201] After passing through the gate, the watch vibrates once (a short vibration of 200 milliseconds), and the screen switches to the payment success interface. This payment interface can be as described above. Figure 5As shown, the payment interface displays the deduction amount of 3, merchant name (xx subway station), communication method (BLE offline), and current offline balance (232). Since this is an offline payment, an "offline" icon is displayed in the upper right corner of the interface, informing recipient A that this transaction will be automatically settled once the network is restored.

[0202] (4) After 10 minutes: The background will automatically settle the settlement, and object A does not need to intervene.

[0203] As the train exits the tunnel, the watch detects that the 4G network has been restored. A background scheduled task immediately triggers: it filters transaction records with status="pending_settlement" from the SE chip, sorts them by txSeq, and uploads them in batches to the cloud settlement system (also known as the cloud clearing system) via HTTPS (TLS 1.3), attaching an HMAC signature to the request header for tamper-proofing. After the cloud verifies the signature validity, txSeq continuity (to prevent replay), and timestamp validity, it executes the final deduction, writes the transaction hash to the blockchain for notarization, and returns a settlement success message. The device updates its local transaction status, deletes the record, and releases storage. User A receives a WeChat mini-program push notification: "You took the subway at xx station at 8:02, and 3.00 has been deducted, leaving a balance of 1255.00." User A can click the notification to view the complete transaction details, including biometric authentication confidence level, payment method, and settlement time.

[0204] Thus, a complete contactless payment process is completed from triggering to settlement, forming a closed loop: Object A never actively operated, and the system completed the entire chain of processing in the background, including identity verification, risk assessment, offline voucher generation, local deduction, and remote settlement. When in an NFC scenario with network access, such as a convenience store, the difference between the processes shown in (1)-(4) above lies in the communication layer and the settlement timing. NFC passive activation can replace BLE active sensing (completed in about 0.3 seconds), and the payment voucher is submitted to the cloud settlement device for verification and deduction in real time. There is no offline temporary storage step, and the payment notification arrives within 1 second. From the user experience perspective, both are characterized by "completing the process simply by bringing the wrist close, without any operation required".

[0205] In one embodiment, the mobile smart device can also respond to a shared account management operation by displaying a shared account management interface. This interface shows the shared account balance, number of members, number of bound devices, and each member's spending information. A shared account refers to at least one entity sharing the same account, such as multiple family members sharing a family account. In the shared account management interface, the administrator can view members' account balances, spending records, set limits and authorized objects for specific scenarios, receive real-time spending notifications, and remotely lock devices. In scenarios requiring family monitoring, family members can also view the monitored individual's spending records, account balance, and biometric authentication status through an application, and can set payment limits and remotely lock devices. For example, as... Figure 7 The diagram shows a shared account management interface for a family account. It displays the family account balance, number of members, and number of linked devices. Each member's spending is displayed in ascending order of spending time. This allows account management to be integrated into the payment process without affecting the lunch payment experience for the monitored individual.

[0206] Please see Figure 8 , Figure 8 This is a schematic diagram of the structure of a data processing device based on a mobile smart device, provided in an exemplary embodiment of this application. Figure 8 The data processing device 800 shown can be a computer program (including program code) running on a mobile smart device, and the data processing device 800 can be used to execute... Figure 2 Some or all of the steps in the method embodiments shown. Please refer to [link / reference]. Figure 8 The data processing device 800 may include the following units: The authentication unit 801 is used to drive the mobile smart device worn by the first object to perform multiple identity authentications on the first object according to a preset authentication cycle, and obtain the identity authentication result. The determining unit 802 is used to, in response to the first object entering the payment scenario, obtain the identity authentication result from the mobile smart device, and determine the identity confidence data of the first object based on the identity authentication result; The determining unit 802 is also used to obtain payment confidence data of the payment scenario, and determine the payment strategy for the first object in the payment scenario based on the identity confidence data of the first object and the payment confidence data of the payment scenario; Payment unit 803 is used to perform payment processing for the first object in a payment scenario according to a determined payment strategy.

[0207] In one embodiment, the authentication unit 801 is configured to: drive a mobile smart device worn by the first object to continuously collect multidimensional biometric data of the first object N times according to a preset authentication cycle; N is an integer greater than 1; compare the multidimensional biometric data collected each time with the biometric baseline data of a reference object to obtain N identity authentication results of the first object, one identity authentication result corresponds to one identity authentication, and each identity authentication result includes an authentication timestamp and a confidence score; wherein, any one of the N identity authentication results is represented as the i-th identity authentication result, and the i-th identity authentication result corresponds to the i-th identity authentication; the authentication timestamp included in the i-th identity authentication result is used to indicate the start time of the i-th identity authentication; the confidence score included in the i-th identity authentication result is used to indicate the probability that the first object is identified as the reference object in the i-th identity authentication, and i is a positive integer less than or equal to N.

[0208] In one embodiment, the acquisition unit 804 is configured to: in response to a biometric binding request for a mobile smart device, drive the sensors in the mobile smart device to acquire raw baseline data of a reference object; perform feature extraction processing on the raw baseline data of the reference object to obtain biometric baseline data of the reference object; and encrypt and store the biometric baseline data of the reference object in the mobile smart device and a cloud device; wherein the raw baseline data includes: static baseline data and / or motion baseline data; the static baseline data is used to describe at least one biological attribute of the reference object in a static state, and the motion baseline data is used to describe at least one biological attribute of the reference object in a motion state.

[0209] In one embodiment, the number of identity authentication results is N, one identity authentication result corresponds to one identity authentication, and each identity authentication result includes a confidence score. N is an integer greater than 1. The update unit 805 is used to: when the preset update timestamp is reached, filter out a reference identity authentication result from the N identity authentication results. The confidence score included in the reference identity authentication result is greater than a preset score threshold. Based on the reference identity authentication result, the biometric baseline data of the reference object is updated in the corresponding identity authentication process using multidimensional biometric data.

[0210] In one embodiment, the detection unit 806 is configured to: perform anomaly detection on the first object based on the multidimensional biometric data or N identity authentication results collected each time, and obtain anomaly detection results; if the anomaly detection results indicate that the first object is abnormal, then lock the payment function of the mobile smart device and push an alarm notification message to the application associated with the payment function.

[0211] In one embodiment, identity confidence data is used to indicate the probability that a first object is a reference object; the identity authentication results include N, and each identity authentication result includes a confidence score; the determining unit 802 is used to: fuse the confidence scores in the N identity authentication results to obtain a fused confidence score; and determine the fused confidence score as the identity confidence data of the first object.

[0212] In one embodiment, identity confidence data is used to indicate the probability that the first object is the reference object; the identity authentication result includes N identity authentication results, each of which includes an authentication timestamp and a confidence score; the determining unit 802 is used to: obtain a target identity authentication result from the N identity authentication results, wherein the target identity authentication result is the identity authentication result with the largest authentication timestamp among the N identity authentication results, or the target identity authentication result is the identity authentication result with the highest confidence score among the N identity authentication results; determine the confidence score in the target identity authentication result as the identity confidence data of the first object; or, calibrate the confidence score in the target identity authentication result according to the time interval between the authentication timestamp and the current timestamp to obtain a calibrated confidence score, and determine the calibrated confidence score as the identity confidence data of the first object.

[0213] In one embodiment, payment confidence data is used to indicate the probability of a payment risk event occurring on a mobile smart device in a payment scenario; the payment confidence data includes at least one of the following: behavioral confidence data, credit confidence data, and scenario confidence data; the determining unit 802 is used to: determine the behavioral confidence data of the mobile smart device based on the transaction frequency and transaction authenticity of the mobile smart device; the behavioral confidence data is used to indicate the probability of abnormal transaction operations on the mobile smart device; determine the credit confidence data of the payment account based on the abnormal transaction records of the payment account logged in on the mobile smart device and the identity binding status of the payment account; the credit confidence data is used to indicate the creditworthiness of the payment account; and determine the scenario confidence data of the payment scenario based on the transaction information of the target transaction related to the mobile smart device in the payment scenario, the scenario confidence data being used to indicate the probability that the target transaction in the payment scenario is an abnormal transaction.

[0214] In one embodiment, a first object enters a payment scenario and generates a target transaction; the determining unit 802 is configured to: perform risk assessment based on the identity confidence data of the first object and the payment confidence data of the payment scenario to obtain the payment risk level of the target transaction in the payment scenario; and determine the payment strategy for the first object in the payment scenario based on the payment risk level of the target transaction.

[0215] In one embodiment, the determining unit 802 is configured to: perform a comprehensive risk assessment based on the identity confidence data of the first object and the payment confidence data of the payment scenario to obtain a comprehensive risk score for the target transaction; the comprehensive risk score is used to indicate the risk level of the target transaction, and the comprehensive risk score is negatively correlated with the risk level of the target transaction; and determine the risk level corresponding to the score range in which the comprehensive risk score of the target transaction is located as the payment risk level.

[0216] In one embodiment, the determining unit 802 is configured to: if the payment risk level of the target transaction is a first risk level, determine a first authorization rule and add the first authorization rule to the payment strategy for the first object in the payment scenario; if the payment risk level of the target transaction is a second risk level, determine a second authorization rule and add the second authorization rule to the payment strategy for the first object in the payment scenario; if the payment risk level of the target transaction is a third risk level, determine a third authorization rule and add the third authorization rule to the payment strategy for the first object in the payment scenario; wherein, the risk level corresponding to the first risk level is less than the risk level corresponding to the second risk level, the risk level corresponding to the second risk level is less than the risk level corresponding to the third risk level, the authorization rule includes an authorization status and a payment limit, the authorization status in the first authorization rule and the authorization status in the second authorization rule both indicate that the payment function of the mobile smart device is allowed to be used, the authorization status in the third authorization rule indicates that the payment function of the mobile smart device is prohibited from being used, and the payment limit in the first authorization rule is greater than the payment limit in the second authorization rule.

[0217] In one embodiment, a payment strategy is used to instruct the execution of payment processing for a first object in a payment scenario; payment unit 803 is used to: obtain transaction data of a target transaction in the payment scenario according to the instructions of the determined payment strategy; the target transaction is a transaction generated when the first object enters the payment scenario; generate a payment voucher based on the transaction data of the target transaction, and send the payment voucher to the payment terminal device through a near-field communication channel, so that the payment terminal device processes the payment voucher according to the network status of the payment terminal device; and output the payment result obtained by executing payment processing for the first object in the payment scenario.

[0218] In one embodiment, the payment terminal device processes the payment voucher according to its network status, including: if the network status of the payment terminal device indicates that the network of the payment terminal device is available, the payment terminal device sends the payment voucher to the cloud settlement device, which then performs payment settlement according to the payment voucher and returns the settlement result to the payment terminal device; if the network status of the payment terminal device indicates that the network of the payment terminal device is unavailable, the payment terminal device performs signature verification on the payment voucher.

[0219] In one embodiment, if the network status of the payment terminal device indicates that the network of the payment terminal device is unavailable, and the network status of the mobile smart device indicates that the network of the mobile smart device is unavailable, then the payment unit 803 is further configured to: update the account balance of the payment account of the mobile smart device according to the payment voucher; generate a transaction record based on the transaction data of the target transaction and the payment voucher, and set the status of the transaction record to a pending settlement state; and encrypt and store the transaction record in the pending settlement state in the mobile smart device.

[0220] In one embodiment, the settlement unit 807 is configured to: if the network status of the mobile smart device indicates that the network of the mobile smart device is available, retrieve the transaction records in the pending settlement state from the mobile smart device; send the transaction records to the cloud settlement device, which performs settlement processing on the transaction records and returns the settlement result corresponding to the transaction records to the mobile smart device; and update the transaction records in the mobile smart device according to the settlement result corresponding to the transaction records.

[0221] It is understood that the specific functions of each unit of the data processing apparatus described in the embodiments of this application can be specifically implemented according to the methods in the above method embodiments, and the specific implementation process can be referred to the relevant descriptions in the above method embodiments, which will not be repeated here. In addition, the beneficial effects of using the same method will not be repeated here either.

[0222] An exemplary embodiment of this application also provides a structural schematic diagram of a computer device, which can be found in [reference needed]. Figure 9 The computer device may include a processor 901, an input device 902, an output device 903, and a memory 904. The processor 901, input device 902, output device 903, and memory 904 are connected via a bus. The memory 904 stores a computer-readable storage medium, including a computer program, and the processor 901 executes the computer program stored in the memory 904.

[0223] In one embodiment, the processor 901 executes the following operations by running a computer program in the memory 904: driving the mobile smart device worn by the first object to perform multiple identity authentications on the first object according to a preset authentication cycle, and obtaining the identity authentication result; in response to the first object entering a payment scenario, obtaining the identity authentication result from the mobile smart device, and determining the identity confidence data of the first object based on the identity authentication result; obtaining the payment confidence data of the payment scenario, and determining the payment strategy for the first object in the payment scenario based on the identity confidence data of the first object and the payment confidence data of the payment scenario; and performing payment processing for the first object in the payment scenario according to the determined payment strategy.

[0224] In one embodiment, the processor 901 is configured to: drive a mobile smart device worn by the first object to continuously collect multidimensional biometric data of the first object N times according to a preset authentication cycle; N is an integer greater than 1; compare the multidimensional biometric data collected each time with the biometric baseline data of a reference object to obtain N identity authentication results of the first object, one identity authentication result corresponds to one identity authentication, and each identity authentication result includes an authentication timestamp and a confidence score; wherein, any one of the N identity authentication results is represented as the i-th identity authentication result, and the i-th identity authentication result corresponds to the i-th identity authentication; the authentication timestamp included in the i-th identity authentication result is used to indicate the start time of the i-th identity authentication; the confidence score included in the i-th identity authentication result is used to indicate the probability that the first object is identified as the reference object in the i-th identity authentication, and i is a positive integer less than or equal to N.

[0225] In one embodiment, the processor 901 is configured to: respond to a biometric binding request for a mobile smart device, drive sensors in the mobile smart device to collect raw baseline data of a reference object; perform feature extraction processing on the raw baseline data of the reference object to obtain biometric baseline data of the reference object; and encrypt and store the biometric baseline data of the reference object in the mobile smart device and a cloud device; wherein the raw baseline data includes: static baseline data and / or motion baseline data; the static baseline data is used to describe at least one biological attribute of the reference object in a static state, and the motion baseline data is used to describe at least one biological attribute of the reference object in a motion state.

[0226] In one embodiment, the number of identity authentication results is N, one identity authentication result corresponds to one identity authentication, and each identity authentication result includes a confidence score. N is an integer greater than 1. The processor 901 is used to: when a preset update timestamp is reached, filter out a reference identity authentication result from the N identity authentication results. The confidence score included in the reference identity authentication result is greater than a preset score threshold. Based on the reference identity authentication result, the biometric baseline data of the reference object is updated in the corresponding identity authentication process using multidimensional biometric data.

[0227] In one embodiment, the processor 901 is configured to: perform anomaly detection on the first object based on the multidimensional biometric data or N identity authentication results collected each time, and obtain anomaly detection results; if the anomaly detection results indicate that the first object is abnormal, then lock the payment function of the mobile smart device and push an alarm notification message to the application associated with the payment function.

[0228] In one embodiment, the identity confidence data is used to indicate the probability that the first object is the reference object; the identity authentication results include N, and each identity authentication result includes a confidence score; the processor 901 is used to: fuse the confidence scores in the N identity authentication results to obtain a fused confidence score; and determine the fused confidence score as the identity confidence data of the first object.

[0229] In one embodiment, identity confidence data is used to indicate the probability that a first object is a reference object; the identity authentication result includes N identity authentication results, each of which includes an authentication timestamp and a confidence score; the processor 901 is configured to: obtain a target identity authentication result from the N identity authentication results, wherein the target identity authentication result is the identity authentication result with the largest authentication timestamp among the N identity authentication results, or the target identity authentication result is the identity authentication result with the highest confidence score among the N identity authentication results; determine the confidence score in the target identity authentication result as the identity confidence data of the first object; or, calibrate the confidence score in the target identity authentication result according to the time interval between the authentication timestamp and the current timestamp, obtain a calibrated confidence score, and determine the calibrated confidence score as the identity confidence data of the first object.

[0230] In one embodiment, payment confidence data is used to indicate the probability of a payment risk event occurring on a mobile smart device in a payment scenario; the payment confidence data includes at least one of the following: behavioral confidence data, credit confidence data, and scenario confidence data; the processor 901 is used to: determine the behavioral confidence data of the mobile smart device based on the transaction frequency and transaction authenticity of the mobile smart device; the behavioral confidence data is used to indicate the probability of abnormal transaction operations of the mobile smart device; determine the credit confidence data of the payment account based on the abnormal transaction records of the payment account logged in on the mobile smart device and the identity binding status of the payment account; the credit confidence data is used to indicate the creditworthiness of the payment account; and determine the scenario confidence data of the payment scenario based on the transaction information of the target transaction related to the mobile smart device in the payment scenario, the scenario confidence data being used to indicate the probability that the target transaction in the payment scenario is an abnormal transaction.

[0231] In one embodiment, a first object enters a payment scenario and generates a target transaction; the processor 901 is configured to: perform risk assessment based on the identity confidence data of the first object and the payment confidence data of the payment scenario to obtain the payment risk level of the target transaction in the payment scenario; and determine the payment strategy for the first object in the payment scenario based on the payment risk level of the target transaction.

[0232] In one embodiment, the processor 901 is configured to: perform a comprehensive risk assessment based on the identity confidence data of the first object and the payment confidence data of the payment scenario to obtain a comprehensive risk score for the target transaction; the comprehensive risk score is used to indicate the risk level of the target transaction, and the comprehensive risk score is negatively correlated with the risk level of the target transaction; and determine the risk level corresponding to the score range in which the comprehensive risk score of the target transaction is located as the payment risk level.

[0233] In one embodiment, the processor 901 is configured to: if the payment risk level of the target transaction is a first risk level, determine a first authorization rule and add the first authorization rule to the payment strategy for the first object in the payment scenario; if the payment risk level of the target transaction is a second risk level, determine a second authorization rule and add the second authorization rule to the payment strategy for the first object in the payment scenario; if the payment risk level of the target transaction is a third risk level, determine a third authorization rule and add the third authorization rule to the payment strategy for the first object in the payment scenario; wherein the risk level corresponding to the first risk level is less than the risk level corresponding to the second risk level, the risk level corresponding to the second risk level is less than the risk level corresponding to the third risk level, the authorization rule includes an authorization status and a payment limit, the authorization status in the first authorization rule and the authorization status in the second authorization rule both indicate that the payment function of the mobile smart device is allowed to be used, the authorization status in the third authorization rule indicates that the payment function of the mobile smart device is prohibited from being used, and the payment limit in the first authorization rule is greater than the payment limit in the second authorization rule.

[0234] In one embodiment, a payment strategy is used to instruct the execution of payment processing for a first object in a payment scenario; the processor 901 is used to: obtain transaction data of a target transaction in the payment scenario according to the instructions of the determined payment strategy; the target transaction is a transaction generated when the first object enters the payment scenario; generate a payment voucher based on the transaction data of the target transaction, and send the payment voucher to the payment terminal device through a near-field communication channel, so that the payment terminal device processes the payment voucher according to the network status of the payment terminal device; and output the payment result obtained by executing payment processing for the first object in the payment scenario.

[0235] In one embodiment, the payment terminal device processes the payment voucher according to its network status, including: if the network status of the payment terminal device indicates that the network of the payment terminal device is available, the payment terminal device sends the payment voucher to the cloud settlement device, which then performs payment settlement according to the payment voucher and returns the settlement result to the payment terminal device; if the network status of the payment terminal device indicates that the network of the payment terminal device is unavailable, the payment terminal device performs signature verification on the payment voucher.

[0236] In one embodiment, if the network status of the payment terminal device indicates that the network of the payment terminal device is unavailable, and the network status of the mobile smart device indicates that the network of the mobile smart device is unavailable, then the processor 901 is further configured to: update the account balance of the payment account of the mobile smart device according to the payment voucher; generate a transaction record based on the transaction data of the target transaction and the payment voucher, and set the status of the transaction record to a pending settlement state; and encrypt and store the transaction record in the pending settlement state in the mobile smart device.

[0237] In one embodiment, the processor 901 is configured to: if the network status of the mobile smart device indicates that the network of the mobile smart device is available, retrieve the transaction record in the pending settlement state from the mobile smart device; send the transaction record to the cloud settlement device, which performs settlement processing on the transaction record according to the transaction record and returns the settlement result corresponding to the transaction record to the mobile smart device; and update the transaction record in the mobile smart device according to the settlement result corresponding to the transaction record.

[0238] It should be understood that the computer device described in the embodiments of this application can execute the data processing method based on mobile intelligent devices described in the corresponding embodiments above, and can also execute the data processing device described in the corresponding embodiments above, which will not be repeated here. In addition, the beneficial effects of using the same method will not be repeated here either.

[0239] Furthermore, it should be noted that this application also provides a computer-readable storage medium, which stores a computer program, and the computer program includes program instructions. When the processor executes the above program instructions, it can execute the method in the corresponding embodiment of this application. Therefore, it will not be described in detail here.

[0240] According to one aspect of this application, a computer program product is provided, comprising a computer program stored in a computer-readable storage medium. A processor of a computer device reads the computer program from the computer-readable storage medium and executes the computer program, enabling the computer device to perform the methods described in the corresponding embodiments of this application; therefore, further details will not be provided here.

[0241] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This computer program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the methods described above. The computer-readable storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0242] The above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of this application. Those skilled in the art will understand that all or part of the processes for implementing the above embodiments and equivalent variations made in accordance with the claims of this application are still within the scope of this application.

Claims

1. A data processing method based on a mobile intelligent device, characterized in that, include: The mobile smart device worn by the first object performs multiple identity authentications on the first object according to a preset authentication cycle, and obtains the identity authentication result. In response to the first object entering the payment scenario, the identity authentication result is obtained from the mobile smart device, and the identity confidence data of the first object is determined based on the identity authentication result; Obtain payment confidence data for the payment scenario, and determine a payment strategy for the first object in the payment scenario based on the identity confidence data of the first object and the payment confidence data of the payment scenario. According to the determined payment strategy, payment processing is performed on the first object in the payment scenario.

2. The method as described in claim 1, characterized in that, The mobile smart device driven by the first object performs multiple identity authentications on the first object according to a preset authentication cycle to obtain identity authentication results, including: The mobile smart device worn by the first object is driven to collect the multidimensional biometric data of the first object N times in a preset authentication cycle; N is an integer greater than 1. Each collected multidimensional biometric data is compared with the biometric baseline data of the reference object to obtain N identity authentication results for the first object. Each identity authentication result corresponds to one identity authentication, and each identity authentication result includes an authentication timestamp and a confidence score. Wherein, any one of the N identity authentication results is represented as the i-th identity authentication result, and the i-th identity authentication result corresponds to the i-th identity authentication; the authentication timestamp included in the i-th identity authentication result is used to indicate the start time of the i-th identity authentication; the confidence score included in the i-th identity authentication result is used to indicate the probability that the i-th identity authentication determines the first object as the reference object, and i is a positive integer less than or equal to N.

3. The method as described in claim 1 or 2, characterized in that, The method further includes: In response to a biometric binding request for the mobile smart device, the sensors in the mobile smart device are driven to acquire raw baseline data of a reference object; The original baseline data of the reference object is subjected to feature extraction processing to obtain the biometric baseline data of the reference object; The biometric baseline data of the reference object is encrypted and stored in the mobile smart device and cloud device; The original baseline data includes: static baseline data and / or motion baseline data; the static baseline data is used to describe at least one biological attribute of the reference object in a static state, and the motion baseline data is used to describe at least one biological attribute of the reference object in a motion state.

4. The method as described in claim 3, characterized in that, The number of identity authentication results is N, with one authentication result corresponding to one authentication. Each authentication result includes a confidence score, where N is an integer greater than 1. The method further includes: When the preset update timestamp is reached, a reference identity authentication result is selected from the N identity authentication results. The confidence score included in the reference identity authentication result is greater than the preset score threshold. Based on the reference identity authentication result and the multidimensional biometric data used in the next identity authentication process, the biometric baseline data of the reference object is updated.

5. The method as described in claim 2, characterized in that, The method further includes: Based on the multidimensional biometric data collected each time or the N identity authentication results, anomaly detection is performed on the first object to obtain anomaly detection results; If the anomaly detection result indicates that the first object is abnormal, then the payment function of the mobile smart device is locked, and an alarm notification message is pushed to the application associated with the payment function.

6. The method as described in claim 1, characterized in that, The identity confidence data is used to indicate the probability that the first object is the reference object; the identity authentication results include N, and each identity authentication result includes a confidence score; Determining the identity confidence data of the first object based on the identity authentication result includes: The confidence scores from the N identity authentication results are merged to obtain a merged confidence score. The fused confidence score is determined as the identity confidence data of the first object.

7. The method as described in claim 1, characterized in that, The identity confidence data is used to indicate the probability that the first object is the reference object; the identity authentication result includes N identity authentication results, each of which includes an authentication timestamp and a confidence score; Determining the identity confidence data of the first object based on the identity authentication result includes: Obtain the target identity authentication result from the N identity authentication results, wherein the target identity authentication result is the identity authentication result with the largest authentication timestamp among the N identity authentication results, or the target identity authentication result is the identity authentication result with the highest confidence score among the N identity authentication results; The confidence score in the target identity authentication result is determined as the identity confidence data of the first object; or, the confidence score in the target identity authentication result is calibrated according to the time interval between the authentication timestamp and the current timestamp to obtain a calibrated confidence score, and the calibrated confidence score is determined as the identity confidence data of the first object.

8. The method as described in claim 1, characterized in that, The payment confidence data is used to indicate the probability of a payment risk event occurring on the mobile smart device in the payment scenario; the payment confidence data includes at least one of the following: behavioral confidence data, credit confidence data, and scenario confidence data; The acquisition of payment confidence data for the payment scenario includes at least one of the following: Based on the transaction frequency and authenticity of the mobile smart device, behavioral confidence data of the mobile smart device is determined; the behavioral confidence data is used to indicate the probability of abnormal transaction operations of the mobile smart device. Based on the abnormal transaction records of the payment account logged in on the mobile smart device and the identity binding status of the payment account, the credit confidence data of the payment account is determined; the credit confidence data is used to indicate the creditworthiness of the payment account. Based on the transaction information of the target transaction related to the mobile smart device in the payment scenario, scenario confidence data of the payment scenario is determined. The scenario confidence data is used to indicate the probability that the target transaction in the payment scenario is an abnormal transaction.

9. The method as described in claim 1, characterized in that, The first object enters the payment scenario and generates a target transaction; determining the payment strategy for the first object in the payment scenario based on the identity confidence data of the first object and the payment confidence data of the payment scenario includes: Risk assessment is performed based on the identity confidence data of the first object and the payment confidence data of the payment scenario to obtain the payment risk level of the target transaction in the payment scenario; Based on the payment risk level of the target transaction, a payment strategy is determined for the first object in the payment scenario.

10. The method as described in claim 9, characterized in that, The step of conducting a risk assessment based on the identity trust data of the first object and the payment trust data of the payment scenario to obtain the payment risk level of the target transaction in the payment scenario includes: A comprehensive risk assessment is performed based on the identity confidence data of the first object and the payment confidence data of the payment scenario to obtain a comprehensive risk score for the target transaction; the comprehensive risk score is used to indicate the risk level of the target transaction, and the comprehensive risk score is negatively correlated with the risk level of the target transaction; The risk level corresponding to the scoring range in which the comprehensive risk score of the target transaction falls is determined as the payment risk level.

11. The method as described in claim 9, characterized in that, The step of determining the payment strategy for the first object in the payment scenario based on the payment risk level of the target transaction includes: If the payment risk level of the target transaction is the first risk level, then the first authorization rule is determined and the first authorization rule is added to the payment strategy for the first object in the payment scenario; If the payment risk level of the target transaction is the second risk level, then a second authorization rule is determined and the second authorization rule is added to the payment strategy for the first object in the payment scenario; If the payment risk level of the target transaction is the third risk level, then the third authorization rule is determined and the third authorization rule is added to the payment strategy for the first object in the payment scenario; Wherein, the risk level corresponding to the first risk level is less than the risk level corresponding to the second risk level, the risk level corresponding to the second risk level is less than the risk level corresponding to the third risk level, the authorization rule includes authorization status and payment limit, the authorization status in the first authorization rule and the authorization status in the second authorization rule both indicate that the payment function of the mobile smart device is allowed to be used, the authorization status in the third authorization rule indicates that the payment function of the mobile smart device is prohibited from being used, and the payment limit in the first authorization rule is greater than the payment limit in the second authorization rule.

12. The method as described in claim 1, characterized in that, The payment strategy is used to instruct the authorization of payment processing for the first object in the payment scenario; the step of performing payment processing for the first object in the payment scenario according to the determined payment strategy includes: According to the instructions of the determined payment strategy, obtain the transaction data of the target transaction in the payment scenario; the target transaction is the transaction generated when the first object enters the payment scenario; A payment voucher is generated based on the transaction data of the target transaction, and the payment voucher is sent to the payment terminal device through a near-field communication channel, so that the payment terminal device can process the payment voucher according to the network status of the payment terminal device; Output the payment result obtained by performing payment processing on the first object in the payment scenario.

13. The method as described in claim 12, characterized in that, The payment terminal device processes the payment voucher according to its network status, including: If the network status of the payment terminal device indicates that the network of the payment terminal device is available, the payment terminal device sends the payment voucher to the cloud settlement device, which then performs payment settlement according to the payment voucher and returns the settlement result to the payment terminal device. If the network status of the payment terminal device indicates that the network of the payment terminal device is unavailable, the payment terminal device performs signature verification on the payment credential.

14. The method as described in claim 12, characterized in that, If the network status of the payment terminal device indicates that the network of the payment terminal device is unavailable, and the network status of the mobile smart device indicates that the network of the mobile smart device is unavailable, then the method further includes: Update the account balance of the payment account of the mobile smart device according to the payment voucher; A transaction record is generated based on the transaction data of the target transaction and the payment voucher, and the status of the transaction record is set to pending settlement. The transaction records that are pending settlement are encrypted and stored in the mobile smart device.

15. The method as described in claim 14, characterized in that, The method further includes: If the network status of the mobile smart device indicates that the network of the mobile smart device is available, then the transaction records in the pending settlement state are obtained from the mobile smart device. The transaction record is sent to the cloud settlement device, which then processes the transaction record for settlement and returns the settlement result corresponding to the transaction record to the mobile smart device. The transaction records in the mobile smart device are updated based on the settlement results corresponding to the transaction records.

16. A data processing device based on a mobile intelligent device, characterized in that, include: The authentication unit is used to drive the mobile smart device worn by the first object to perform multiple identity authentications on the first object according to a preset authentication cycle, and obtain the identity authentication result; The determining unit is further configured to, in response to the first object entering the payment scenario, obtain the identity authentication result from the mobile smart device, and determine the identity confidence data of the first object based on the identity authentication result; The determining unit is further configured to acquire payment confidence data of the payment scenario, and determine a payment strategy for the first object in the payment scenario based on the identity confidence data of the first object and the payment confidence data of the payment scenario; A payment unit is configured to perform payment processing for the first object in the payment scenario according to the determined payment strategy.

17. A computer device, characterized in that, include: A processor is used to execute computer programs; A computer-readable storage medium storing a computer program, which, when executed by the processor, performs the data processing method based on a mobile intelligent device as described in any one of claims 1-15.

18. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, which, when executed by a processor, performs the data processing method based on a mobile intelligent device as described in any one of claims 1-15.

19. A computer program product, characterized in that, The computer program product includes a computer program or computer instructions, which are executed by a processor to implement the data processing method based on a mobile smart device as described in any one of claims 1-15.

Images