A vehicle-mounted secure payment system and automobile

Abstract

The application discloses a kind of vehicle safety payment systems and car, vehicle safety payment system is carried on car, vehicle safety payment system includes order management module, identity authentication module and secure transmission module.The application can be executed by the module of car-mounted order information acquisition, the identity authentication of specific trusted on-board personnel, payment authorization credential generation and other processes, so as to ensure the premise of property safety, trigger payment platform to execute payment or transfer according to order information, without on-board personnel distraction from driving process to operate user terminal in the payment process, on-board personnel can focus on driving operation, can fully guarantee traffic safety, and by vehicle safety payment system, strict standard verification and authentication process of order information are automatically completed, avoid the lax caused by on-board personnel due to driving, so as to guarantee payment security.The application is widely used in the field of automobile technology.

Description

Technical Field

[0001] This invention relates to the field of automotive technology, and in particular to an in-vehicle secure payment system and an automobile. Background Technology

[0002] As cars become increasingly intelligent, they are becoming more and more integrated into people's lives, and people are spending more and more time in their vehicles. Electronic payments are frequently needed in daily life, and with the widespread use of cars, many electronic payment operations naturally need to be performed in vehicles. For example, when a user is driving or riding in a car, if they need to pay a bill or transfer money to an account, especially if such payments or transfers have high time requirements, the user needs to complete the payment while driving or riding. The use of cars itself also presents specific payment needs; for example, when leaving a paid parking lot, a fee needs to be paid to the parking lot management.

[0003] Currently, electronic payment processes primarily involve users establishing communication with payment platforms using mobile phones or other user terminals. Current automotive technology simply moves this payment process from outside the car to inside, meaning users still need to input amounts, verify their identity, and confirm payments on their mobile terminals when making electronic payments in a car. However, users typically need to drive while in a car, and these operations on the user terminal can easily distract them from driving, leading to traffic risks. Furthermore, operating the user terminal while driving or riding in a car can cause complacency in order verification and authentication processes, resulting in payment risks. Summary of the Invention

[0004] In view of at least one of the above-mentioned technical problems, the purpose of the present invention is to provide an in-vehicle secure payment system and a car.

[0005] On one hand, embodiments of the present invention include an in-vehicle secure payment system, the in-vehicle secure payment system comprising: Order management module; the order management module is used to obtain order information; An identity authentication module; the identity authentication module is used to authenticate the identity of the people on the vehicle, obtain a first authentication result, and generate a payment authorization certificate when the first authentication result is successful. A secure transmission module; the secure transmission module is used to create a secure transmission channel between the vehicle and the payment platform, and to send the payment authorization credential to the payment platform through the secure transmission channel.

[0006] Furthermore, obtaining order information includes: The system detects the movement information of the occupants in the vehicle; the movement information includes voice information, gesture information, and / or facial expression information. The order information is identified based on the action information.

[0007] Furthermore, obtaining order information includes: Establish a communication connection with the user terminal carried by the occupants of the vehicle; Receive the order information sent by the user terminal.

[0008] Furthermore, the in-vehicle secure payment system also includes: A voucher clearing module; the voucher clearing module is used to perform multi-level clearing of the payment authorization voucher throughout the entire process after the order information is completed.

[0009] Furthermore, the in-vehicle secure payment system also includes: Navigation module; the navigation module is used for vehicle positioning and navigation; A risk monitoring module is used to obtain the payment authorization credential issued by the identity authentication module before the secure transmission module, identify the payment scenario based on the order information, determine the risk level of the payment scenario, and perform risk processing on the payment authorization credential based on the risk level.

[0010] Furthermore, the risk processing of the payment authorization certificate based on the risk level includes: When the risk level is Level 1, the payment authorization certificate is released; When the risk level is Level 2, the payment authorization credential is intercepted, the identity authentication module is invoked to perform secondary identity authentication on the occupants of the vehicle, a second authentication result is obtained, and a first matching degree between the second authentication result and the first authentication result is obtained. If the second authentication result is successful and the first matching degree is greater than the matching degree threshold, the payment authorization credential is released; otherwise, the payment authorization credential is cancelled. When the risk level is level three, the payment authorization credential is intercepted, the navigation module is invoked to obtain the current driving route and the historical driving route, and the second matching degree between the current driving route and the historical driving route is obtained. When the second matching degree is greater than the matching degree threshold, the payment authorization credential is allowed to pass; otherwise, the payment authorization credential is cancelled. When the risk level is level four, the payment authorization certificate is intercepted and cancelled; The risks of the first level, the second level, the third level, and the fourth level increase sequentially.

[0011] Furthermore, the risk processing of the payment authorization certificate based on the risk level includes: Based on the risk level, a driving task is generated; The navigation module is invoked to obtain the vehicle's progress in completing the driving task; If the completion progress reaches the progress threshold within the set time limit, the payment authorization certificate is released; otherwise, the payment authorization certificate is intercepted and cancelled.

[0012] Furthermore, generating the driving task based on the risk level includes: The navigation module is invoked to locate multiple target locations from the electronic map; Based on the risk level, select a corresponding number of target locations; the number of target locations is positively correlated with the risk level. The navigation module is invoked to perform path planning based on the selected target locations, generating a driving route; the driving route passes through all the selected target locations. The driving task is determined based on the route to be traveled.

[0013] Furthermore, the secure transmission module is also used to negotiate with the payment platform and the user terminal to set the vehicle-mounted secure payment system as a necessary communication node between the payment platform and the user terminal.

[0014] On the other hand, embodiments of the present invention also include a vehicle, characterized in that the vehicle includes the in-vehicle secure payment system described in the embodiments.

[0015] The beneficial effects of this invention are as follows: The in-vehicle secure payment system in the embodiments can be implemented by a module mounted on the vehicle, which can perform processes such as obtaining order information, authenticating the identity of specific trusted occupants, and generating payment authorization certificates. This allows the payment platform to be triggered to perform payment or transfer based on the order information while ensuring the safety of property. During the payment process, occupants do not need to be distracted from driving to operate the user terminal, allowing them to concentrate on driving and fully ensuring traffic safety. Furthermore, the in-vehicle secure payment system automatically completes the strict standard verification and authentication of order information, preventing occupants from becoming complacent while driving and thus ensuring payment security. Attached Figure Description

[0016] Figure 1 This is a schematic diagram of the in-vehicle secure payment system in the embodiment; Figure 2 This is a schematic diagram illustrating the steps of the in-vehicle secure payment method in the embodiment; Figure 3 This is a schematic diagram of the target location in the embodiment. Detailed Implementation

[0017] In this embodiment, an in-vehicle secure payment system is provided. This system can be installed in a car and, together with various in-vehicle functional components, forms an integral part of the car.

[0018] Reference Figure 1 The in-vehicle secure payment system includes an order management module, an identity authentication module, and a secure transmission module. In addition, modules such as a credential clearing module, a navigation module, and a risk monitoring module can be added. These modules can be hardware modules, software modules, or hardware modules running software modules with corresponding functions.

[0019] For example, one or more components such as a voice recognition unit, an in-vehicle high-definition camera, and internal wireless communication components can be used as an order management module. The voice recognition unit can detect the speech of passengers and obtain voice information, while the in-vehicle high-definition camera can detect gestures or facial expressions, thus obtaining gesture and facial expression information respectively. Passengers can output voice, gesture, and facial expression information by speaking, making specific gestures, or making specific facial expressions, thereby representing information related to the order that needs payment. For example, a passenger might say, "I need to pay for goods B that were generated yesterday afternoon at 3 pm on payment platform A," or "Please scan the parking fee QR code in front of the car to pay." This speech is detected by the voice recognition unit and converted into computer-recognizable voice information. This voice information can point to a specific order to be paid, thus representing specific order information. For example, a voice message stating "I need to pay for goods B generated yesterday at 3 PM on payment platform A" can be used to search for specific order information based on keywords such as payment platform, order time, and order details. A voice message stating "Scan the parking fee QR code in front of my car to pay" represents a command. This command triggers the voice recognition unit to call the vehicle's high-definition camera to scan and recognize the fee QR code, thereby obtaining an access interface. Through this interface, the parking fee order information can be retrieved. The internal wireless communication component can connect to user terminals carried by passengers via Bluetooth, WiFi, or other communication protocols. The user terminal generates order information by running applications such as bank clients or consumer apps, and sends this order information to the internal wireless communication component, enabling the order management module to obtain the order information.

[0020] For example, one or more components such as an in-vehicle high-definition camera, a wireless identification unit, and an interactive screen can be used as an identity authentication module. The in-vehicle high-definition camera can photograph occupants to perform facial recognition and obtain facial feature information; the wireless identification unit can detect wireless signals with characteristic information transmitted by user terminals such as mobile phones or dedicated tags carried by occupants; and the interactive screen can receive passwords entered by occupants. Facial feature information, wireless signals, and passwords are all information that can only be provided by specific personnel, which can verify the identity of occupants and thus complete identity authentication.

[0021] For example, an external wireless communication component with encryption and verification functions can be used as a secure transmission module. This secure transmission module connects to a base station via wireless communication protocols such as 4G and 5G, thereby accessing the internet and establishing communication with the payment platform. The secure transmission module and the payment platform negotiate a key, using the key to encrypt and sign data sent to each other, and to verify and decrypt received data, thus resisting potential attacks in the channel and establishing a secure transmission channel between the vehicle and the payment platform. Specifically, the secure transmission module can use symmetric encryption algorithms such as AES-256-GCM for encryption and decryption, and asymmetric encryption algorithms such as RSA-2048 for signing and verification.

[0022] For example, dedicated hardware can be used as a credential erasure module. This module can perform end-to-end multi-level erasure, meaning it clears data at multiple levels across all modules within the in-vehicle secure payment system and the data links between them. For instance, the credential erasure module can employ a three-level erasure mechanism to ensure complete data removal: Memory-level cleanup: Immediately release the memory space occupied by data, and use random data to overwrite the corresponding memory area three times to prevent residual data from being extracted by memory dump tools; Storage-level erasure: Delete cache files, operation logs, and transfer logs from local storage, and overwrite storage sectors with random data three times to ensure that they cannot be recovered by data recovery tools; Secure chip-level erasure: Clears the data stored in the chip of each module, and destroys the corresponding encryption keys simultaneously, eliminating the possibility of core data residue.

[0023] For example, components that navigate using satellite positioning systems such as GPS and BeiDou can be used as navigation modules. These modules can provide real-time vehicle location and perform navigation tasks.

[0024] For example, components with data input, processing, and output functions, such as electronic control units (ECUs), can be used as risk monitoring modules.

[0025] In this embodiment, the order management module, identity authentication module, secure transmission module, credential clearing module, navigation module, and risk monitoring module in the in-vehicle secure payment system are modules that are permanently installed in the vehicle. Through these modules, the in-vehicle secure payment system can execute in-vehicle secure payment methods. When executing in-vehicle secure payment methods, if it is necessary to obtain or process the user's facial features or other private information, or if the processing of such information may affect the user's assets, the in-vehicle secure payment system obtains the user's authorization. The acquisition, processing, and transmission of private information, as well as the processing of information that may affect the user's assets, are only performed with the user's knowledge and authorization.

[0026] Reference Figure 2 The in-vehicle secure payment method includes the following steps: S1. Obtain order information; S2. Verify the identity of the passengers in the vehicle and obtain the first authentication result. If the first authentication result is successful, generate a payment authorization certificate. S3. Create a secure transmission channel between the car and the payment platform, and send the payment authorization credential to the payment platform through the secure transmission channel.

[0027] In this embodiment, step S1 is executed by the order management module, step S2 is executed by the identity authentication module, and step S3 is executed by the secure transmission module.

[0028] In this embodiment, we will illustrate the process by taking the example of a passenger in a vehicle needing to pay for an order while driving, and using an in-vehicle secure payment system to complete the payment. The order to be paid can be a consumption order generated by the passenger on a consumer platform (such as shopping, parking, refueling, charging, car washing, etc.), in which case the payment platform is either the consumer platform itself or a payment institution authorized by the consumer platform; or it can be a transfer order created on a bank's app for the passenger to transfer money to another person or entity, in which case the payment platform is the bank platform.

[0029] When passengers need to pay for an order, they can express information related to the order by speaking, making specific gestures, or using specific facial expressions. For example, passengers can use these actions to trigger the order management module to execute step S1, which detects voice, gesture, and / or facial expression information and extracts information such as the order number, order amount, order time, order items, and payee from this information to identify the specific order and obtain order information. Passengers can also configure their user terminals to send order information to the order management module as soon as it is generated, causing the order management module to execute step S1 to obtain the order information.

[0030] Whether the order management module obtains order information through the passenger's speech, specific gestures, or specific facial expressions, or through the user terminal sending order information, the passenger does not need to manually operate the user terminal or specific components. This allows the passenger to concentrate on driving and ensures traffic safety.

[0031] In step S2, the identity authentication module authenticates the identities of the occupants and obtains the first authentication result. Specifically, the identity authentication module can request to detect the occupants' facial features, wireless signals, or passwords. The priority of these features decreases in that order: facial features are requested first; if facial features cannot be obtained or are invalid, wireless signals are detected; and if wireless signals cannot be obtained or are invalid, passwords are detected. Alternatively, only facial features can be detected.

[0032] Taking the detection of facial features of people in the vehicle as an example, the identity authentication module compares the detected facial features with the pre-reserved facial features (facial features of the vehicle owner or a trusted relative obtained through a trusted means). When the matching degree is greater than the threshold (e.g., 80%), the first authentication result with the content "authentication passed" is generated; otherwise, the first authentication result with the content "authentication failed" is generated.

[0033] If the identity authentication module obtains a first authentication result of "authentication passed" after executing step S2, it indicates that the order information has been confirmed by a trusted person, and the identity authentication module generates a payment authorization credential. This payment authorization credential may include the ID of the in-vehicle secure payment system, the order number of the order information, a confirmation statement of the order information, payment instructions, and the signature of the identity authentication module on the aforementioned information. The in-vehicle secure payment system may pre-negotiate an agreement with the payment platform, according to which the aforementioned payment authorization credential serves as the basis for confirming the order information and agreeing to payment.

[0034] If the identity authentication module obtains a first authentication result of "authentication failed" after executing step S2, it indicates that no trusted person has confirmed the order information. The identity authentication module will not generate a payment authorization certificate, and therefore step S3 will not be executed during this payment process.

[0035] After the identity authentication module generates the payment authorization credential in step S2, it can directly send the credential to the secure transmission module. The secure transmission module then forwards the credential to the payment platform via a secure transmission channel. Once the payment authorization credential is sent to the payment platform, it will trigger the platform to deduct funds from the accounts of the passengers or other relevant parties, transfer the funds to the payee's account in the order information, and mark the order information as paid. This will then trigger the payment platform to execute the payment based on the order information, completing the payment or transfer.

[0036] In this embodiment, by executing steps S1-S3 through the order management module, identity authentication module, and secure transmission module, the vehicle-mounted modules can perform processes such as obtaining order information, authenticating the identity of specific trusted occupants, and generating payment authorization credentials. This ensures property security while triggering the payment platform to execute payment or transfer based on the order information. During the payment process, occupants do not need to be distracted from driving to operate the user terminal, allowing them to focus on driving and fully guaranteeing traffic safety. Furthermore, the in-vehicle secure payment system automatically completes the rigorous verification and authentication of order information, preventing occupants from becoming complacent while driving and thus ensuring payment security.

[0037] In this embodiment, with the risk monitoring module set up, refer to Figure 1 The risk monitoring module can be set between the identity authentication module and the secure transmission module, so that when the identity authentication module generates and issues the payment authorization credential in step S2, the payment authorization credential is sent to the risk monitoring module first. That is, the risk monitoring module obtains the payment authorization credential issued by the identity authentication module before the secure transmission module.

[0038] In this embodiment, when a risk monitoring module is set up, the risk monitoring module can perform the following steps in addition to executing steps S1-S3: S4. Identify the payment scenario based on the order information and determine the risk level of the payment scenario; S5. Perform risk processing on payment authorization credentials according to the risk level.

[0039] In step S4, the risk monitoring module can preset in-vehicle payment risk scenario rules, including: (1) payment in a different location (e.g., the payment location does not match the frequently used vehicle area); (2) large amount payment (e.g., exceeding the user's preset security limit); (3) frequent payment (e.g., more than 3 payments within 1 hour); (4) payment to an unfamiliar merchant (e.g., the first payment to this merchant); (5) non-bound vehicle machine payment, abnormal biometric verification matching degree (e.g., the matching degree is in the lower range of 30%-60%). The risk monitoring module detects the degree of compliance of the order information with each of the above in-vehicle payment risk scenario rules, counts the number of items that meet the rules, and determines the risk level of the payment scenario based on the number of items. The larger the number of items, the higher the risk level.

[0040] For example, if the number of items that match the criteria is 1-2, the risk monitoring module determines the risk level as the lowest level, Level 1 (low risk); if the number of items that match the criteria is 3, the risk level is determined as the higher level, Level 2 (low-medium risk); if the number of items that match the criteria is 4, the risk level is determined as the higher level, Level 3 (medium risk); and if the number of items that match the criteria is 5, the risk level is determined as the highest level, Level 4 (high risk).

[0041] When the risk monitoring module executes step S5, which involves processing the payment authorization certificate based on the risk level, it can specifically perform the following steps: S501A. When the risk level is Level 1, the payment authorization document shall be released; S502A. When the risk level is Level 2, the payment authorization certificate is intercepted, the identity authentication module is called to perform secondary identity authentication on the passengers, the second authentication result is obtained, and the first matching degree between the second authentication result and the first authentication result is obtained. If the second authentication result is successful and the first matching degree is greater than the matching degree threshold, the payment authorization certificate is released; otherwise, the payment authorization certificate is cancelled. S503A. When the risk level is level 3, the payment authorization certificate is intercepted, the navigation module is called to obtain the current driving route and the historical driving route, and the second matching degree between the current driving route and the historical driving route is obtained. If the second matching degree is greater than the matching degree threshold, the payment authorization certificate is allowed to pass; otherwise, the payment authorization certificate is cancelled. S504A. When the risk level is Level 4, the payment authorization certificate shall be intercepted and cancelled.

[0042] Steps S501A-S504A are the first execution method of step S5.

[0043] Based on the specific magnitude of the risk level determined in step S4, the risk monitoring module selects any one of steps S501A-S504A to execute.

[0044] When the risk level is Level 1 (low risk), the risk monitoring module selects to execute step S501A to release the payment authorization certificate, that is, to directly send the payment authorization certificate to the secure transmission module, so that the secure transmission module sends the payment authorization certificate to the payment platform, triggering the payment platform to execute the payment of the order information.

[0045] When the risk level is Level 2 (low to medium risk), the risk monitoring module executes step S502A. First, the risk monitoring module intercepts the payment authorization credential, meaning it temporarily prevents the credential from being sent to the secure transmission module. Then, the risk monitoring module calls the identity authentication module to perform secondary identity authentication on the passengers, obtaining a second authentication result. The second authentication result is either "authentication passed" or "authentication failed." If the second authentication result is successful, the module also obtains the first matching degree between the second and first authentication results. Specifically, the second and first authentication results are derived from similar feature information (e.g., the comparison matching degree of facial feature information). The first matching degree between the second and first authentication results is the degree of closeness between the comparison matching degree corresponding to the second authentication result and the comparison matching degree corresponding to the first authentication result. When performing step S502A, if the second authentication result is also successful and is sufficiently close to or the same as the first authentication result, the risk monitoring module will allow the payment authorization certificate to pass through, that is, send the payment authorization certificate to the secure transmission module. Otherwise, the risk monitoring module will cancel the payment authorization certificate, that is, not send the payment authorization certificate to the secure transmission module and delete the payment authorization certificate from the local machine, so that the secure transmission module will not obtain the payment authorization certificate.

[0046] By executing step S502A, the risk monitoring module can call the identity authentication module to perform secondary identity authentication on the passengers and set stricter pass conditions than single identity authentication. That is, the payment authorization certificate is only released if both the second authentication result and the first authentication result are passed and the second authentication result is sufficiently close to or the same as the first authentication result, thereby improving the security of payment.

[0047] In cases where the risk level is Level 3 (medium risk), the risk monitoring module executes step S503A. First, the risk monitoring module intercepts the payment authorization credential, meaning it temporarily prevents it from being sent to the secure transmission module. The risk monitoring module then calls the navigation module to obtain the current and historical driving routes. The current driving route can be the route the vehicle has traveled since the car started during this payment process; the historical driving route can be a route the car has previously traveled, recorded by the navigation module, and corresponds to the same relative time period as the current driving route (e.g., both are during commuting or working hours, both are on rest days, both are public holidays, etc.). The risk monitoring module performs a path similarity calculation on the current and historical driving routes, using the obtained similarity as a second matching degree between the two routes, and sets a matching degree threshold (e.g., 70%). If the second matching degree is greater than the matching degree threshold, the payment authorization credential is allowed; otherwise, it is cancelled.

[0048] In this embodiment, the principle behind the risk monitoring module executing step S503A is as follows: In the case of a higher risk level, Level 3 (medium risk), secondary identity authentication of the occupants is insufficient to address such risks (because the possibility of untrusted individuals impersonating trusted individuals to request payment is relatively small, while the possibility of trusted individuals requesting payment due to being deceived is relatively large). Therefore, by calling the navigation module to obtain the historical driving routes generated by the car in the same relative time period as the current driving route, the historical driving habits of the car contained in the historical driving routes can be used to verify the current driving route. If the second matching degree between the current driving route and the historical driving route is less than the matching degree threshold, it is determined that the occupants' driving behavior is significantly different from their historical usage habits, and there is a possibility that the occupants are trusted individuals but have been deceived. Thus, the payment authorization certificate is cancelled, the payment process is prevented, and property security is effectively protected.

[0049] In the case of risk level 4 (high risk), the risk monitoring module selects to execute step S504A, no longer performs verification, and intercepts and cancels the payment authorization certificate, so that the secure transmission module will not receive the payment authorization certificate and directly prevents the payment process from proceeding.

[0050] In this embodiment, the principle of the risk monitoring module executing step S504A is that: when the risk level is the highest level, the fourth level (high risk), various verification methods are insufficient to deal with such risks, so the payment process is directly blocked, effectively protecting property security.

[0051] In this embodiment, the risk monitoring module can select an appropriate risk handling method according to the different levels of risk in the payment scenario by executing steps S501A-S504A, thereby effectively balancing the convenience and security of electronic payment.

[0052] When the risk monitoring module executes step S5, which involves processing the payment authorization certificate based on the risk level, it can specifically perform the following steps: S501B. Generate driving tasks based on risk level; S502B. Call the navigation module to obtain the vehicle's progress in completing the driving task; S503B. If the progress reaches the progress threshold within the set time limit, the payment authorization certificate is released; otherwise, the payment authorization certificate is intercepted and cancelled.

[0053] Steps S501B-S503B are the second execution method of step S5.

[0054] In step S501B, the risk monitoring module can call the navigation module to locate the vehicle, determine its current location on the electronic map, and search for multiple target locations near the current location. The results are as follows: Figure 3 As shown.

[0055] In this embodiment, the target location to be searched can be a park, scenic area, or other publicly accessible location; a location with risk warning information (such as a fraud prevention information board); the location of or near a relevant law enforcement agency; or a combination of the above. The target location can be a place where cars are allowed to stay for a period of time, such as at least 5 minutes, rather than a no-parking location. Figure 3 In the process, the risk monitoring module found multiple target locations, including target location 1, target location 2, target location 3, target location 4, and target location 5, on the electronic map.

[0056] The risk monitoring module selects a corresponding number of target locations based on the risk level. Specifically, the number of selected target locations is positively correlated with the risk level; that is, the higher the risk level, the more target locations are selected. For example, in the case of risk level 1 (low risk) or level 2 (low-medium risk), the number of selected target locations is 0, which is equivalent to not executing steps S501B-S503B; in the case of risk level 3 (medium risk), the number of selected target locations is 1-3; and in the case of risk level 4 (high risk), the number of selected target locations is 3-5.

[0057] In this embodiment, the risk monitoring module can select three target locations: target location 1, target location 3, and target location 4. The risk monitoring module then calls the navigation module to perform route planning based on the selected target locations, generating a driving route that passes through all the selected target locations. In this embodiment, the navigation module generates... Figure 3 The red line in the image shows the path to be traveled, which passes through the selected target locations 1, 3, and 4.

[0058] The navigation module determines the driving task based on the route to be traveled, that is, instructs the occupants to drive the car according to the route. Figure 3 The vehicle will travel along the indicated route, passing through target location 1, target location 3, and target location 4 in sequence. The starting point of the route can be the vehicle's current location, and the ending point can be the target location furthest from the route, for example... Figure 3 Target location 4. The navigation module can also set the dwell time for each target location during the driving task. That is, after the occupants actually drive the car to a target location, they need to stay at that target location for the set dwell time before it is recognized as the car arriving at that target location. The specific dwell time can be positively correlated with the risk level.

[0059] In step S502B, the risk monitoring module calls the navigation module to obtain the vehicle's progress in completing the driving task. Specifically, the navigation module detects the vehicle's position and actual driving path in real time. When the vehicle's actual driving path overlaps with the path to be driven, it calculates the ratio of the length of the actual driving path to the length of the path to be driven, thereby obtaining the progress in completing the driving task.

[0060] The risk monitoring module can access the route planning results from the navigation module to obtain the total travel time required for the car to follow the planned route under current traffic conditions. This total travel time is set as a duration limit, and a progress threshold (e.g., 80%) is also set. The risk monitoring module executes real-time timing to determine if the duration limit has been reached. While the time limit is still active, the order management module can use methods to obtain order information to detect cancellation requests from passengers. If the order management module detects a cancellation request, the risk monitoring module intercepts and cancels the payment authorization voucher. If no cancellation request is detected, the timing continues.

[0061] After the timer reaches the time limit, it is determined whether the progress has reached the progress threshold. If the progress has reached the progress threshold after the timer reaches the time limit, and no cancellation instruction is detected, and the payment authorization certificate is not intercepted or cancelled, then in step S503B, the risk monitoring module releases the payment authorization certificate. Conversely, if the progress has reached the progress threshold after the timer reaches the time limit, then the risk monitoring module intercepts and cancels the payment authorization certificate.

[0062] In this embodiment, the principle behind the risk monitoring module's execution of steps S501B-S503B is as follows: By executing steps S501B-S503B, before releasing the payment authorization voucher, the occupants are required to perform a driving task. The driving task itself requires a certain amount of time, thus providing a payment cooling-off period for the occupants. This allows them to fully consider the necessity of paying for the order information. During the cooling-off period, the occupants can issue a cancellation command, triggering the risk monitoring module to intercept and cancel the payment authorization voucher, thereby canceling the payment for the order information. The driving task passing through specific target locations helps the occupants receive risk warning information, further prompting them to fully consider the necessity of paying for the order information. This also encourages them to issue a cancellation command if they deem payment unnecessary, triggering the risk monitoring module to intercept and cancel the payment authorization voucher. If the driving task is completed on time, the payment authorization voucher is released. Therefore, by executing steps S501B-S503B, the vehicle fulfills its obligation to provide payment security risk warnings, ensuring property safety.

[0063] In this embodiment, since the in-vehicle secure payment system functions by sending payment authorization credentials to the payment platform, rather than the user terminal directly sending payment authorization credentials to the payment platform, the secure transmission module can negotiate with the payment platform and the user terminal to establish the in-vehicle secure payment system as a necessary communication node between the payment platform and the user terminal, with the knowledge, consent, and active configuration of the occupants. Based on the agreement reached through this negotiation, the user terminal and the payment platform do not communicate directly, especially not by directly sending payment authorization credentials. Instead, the in-vehicle secure payment system sends payment authorization credentials to the payment platform, thus preventing the security mechanism of the in-vehicle secure payment system from failing due to the user terminal directly sending payment authorization credentials to the payment platform. Occupants can send instructions to the user terminal, the in-vehicle secure payment system, or the payment platform to terminate the agreement reached through this negotiation, thereby revoking the necessary communication node function of the in-vehicle secure payment system.

[0064] A computer program that executes the vehicle-mounted secure payment method in this embodiment can be written into a computer device or storage medium. When the computer program is read out and run, the vehicle-mounted secure payment method in this embodiment is executed, thereby achieving the same technical effect as the vehicle-mounted secure payment method in the embodiment.

[0065] It should be noted that, unless otherwise specified, when a feature is referred to as "fixed" or "connected" to another feature, it can be directly fixed or connected to the other feature, or indirectly fixed or connected to the other feature. Furthermore, the descriptions of "upper," "lower," "left," and "right" used in this disclosure are only relative to the relative positional relationships of the components of this disclosure in the accompanying drawings. The singular forms "a," "an," and "the" used in this disclosure are also intended to include the plural forms, unless the context clearly indicates otherwise. Moreover, unless otherwise defined, all technical and scientific terms used in this embodiment have the same meaning as commonly understood by one of ordinary skill in the art. The terminology used in this embodiment specification is only for describing particular embodiments and is not intended to limit the invention. The term "and / or" as used in this embodiment includes any combination of one or more of the associated listed items.

[0066] It should be understood that although various elements may be described in this disclosure using terms such as "second," "third," etc., these elements should not be limited to these terms. These terms are used only to distinguish elements of the same type from one another. For example, an element may also be referred to as a second element without departing from the scope of this disclosure, and similarly, a second element may also be referred to as an element. The use of any and all instances or exemplary language ("e.g.," "such as," etc.) provided in this embodiment is intended only to better illustrate embodiments of the invention and, unless otherwise required, does not impose a limitation on the scope of the invention.

[0067] It should be recognized that embodiments of the present invention can be implemented or carried out by computer hardware, a combination of hardware and software, or by computer instructions stored in a non-transitory computer-readable storage medium. The method can be implemented using standard programming techniques—including a non-transitory computer-readable storage medium configured with a computer program, wherein such a storage medium causes the computer to operate in a specific and predefined manner—according to the methods and drawings described in the specific embodiments. Each program can be implemented in a high-level procedural or object-oriented programming language to communicate with the computer system. However, if desired, the program can be implemented in assembly or machine language. In any case, the language can be a compiled or interpreted language. Furthermore, for this purpose, the program can run on a programmed application-specific integrated circuit (ASIC).

[0068] Furthermore, the procedures described in this embodiment can be performed in any suitable order unless otherwise indicated by this embodiment or otherwise obviously contradict the context. The procedures (or variations and / or combinations thereof) described in this embodiment can be executed under the control of one or more computer systems configured with executable instructions, and can be implemented by hardware or a combination thereof as code (e.g., executable instructions, one or more computer programs, or one or more applications) that commonly executes on one or more processors. A computer program includes a plurality of instructions executable by one or more processors.

[0069] Furthermore, the method can be implemented in any suitable type of computing platform, including but not limited to personal computers, minicomputers, mainframes, workstations, networked or distributed computing environments, standalone or integrated computer platforms, or in communication with charged particle tools or other imaging devices, etc. Aspects of the invention can be implemented as machine-readable code stored on a non-transitory storage medium or device, whether removable or integrated into a computing platform, such as a hard disk, optical read and / or write storage medium, RAM, ROM, etc., such that it is readable by a programmable computer, and when the storage medium or device is read by the computer, it can be used to configure and operate the computer to perform the processes described herein. Furthermore, the machine-readable code, or portions thereof, can be transmitted via wired or wireless networks. The invention of this embodiment includes these and other different types of non-transitory computer-readable storage media when such media comprises instructions or programs that implement the steps above in conjunction with a microprocessor or other data processor. When programmed according to the methods and techniques of the invention, the invention also includes the computer itself.

[0070] A computer program can be applied to input data to perform the functions of this embodiment, thereby transforming the input data to generate output data stored in non-volatile memory. The output information can also be applied to one or more output devices, such as a display. In a preferred embodiment of the invention, the transformed data represents physical and tangible objects, including specific visual depictions of physical and tangible objects generated on the display.

[0071] The above are merely preferred embodiments of the present invention. The present invention is not limited to the above-described embodiments. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention, as long as they achieve the technical effects of the present invention by the same means, should be included within the scope of protection of the present invention. Within the scope of protection of the present invention, the technical solutions and / or implementation methods can have various modifications and variations.

Claims

1. A vehicle-mounted secure payment system, characterized in that, The in-vehicle secure payment system is installed in a vehicle, and the in-vehicle secure payment system includes: Order management module; the order management module is used to obtain order information; An identity authentication module; the identity authentication module is used to authenticate the identity of the people on the vehicle, obtain a first authentication result, and generate a payment authorization certificate when the first authentication result is successful. A secure transmission module; the secure transmission module is used to create a secure transmission channel between the vehicle and the payment platform, and to send the payment authorization credential to the payment platform through the secure transmission channel.

2. The vehicle-mounted secure payment system according to claim 1, characterized in that, The process of obtaining order information includes: The system detects the movement information of the occupants in the vehicle; the movement information includes voice information, gesture information, and / or facial expression information. The order information is identified based on the action information.

3. The vehicle-mounted secure payment system according to claim 1, characterized in that, The process of obtaining order information includes: Establish a communication connection with the user terminal carried by the occupants of the vehicle; Receive the order information sent by the user terminal.

4. The vehicle-mounted secure payment system according to claim 1, characterized in that, The in-vehicle secure payment system also includes: A voucher clearing module; the voucher clearing module is used to perform multi-level clearing of the payment authorization voucher throughout the entire process after the order information is completed.

5. The vehicle-mounted secure payment system according to claim 1, characterized in that, The in-vehicle secure payment system also includes: Navigation module; the navigation module is used for vehicle positioning and navigation; A risk monitoring module is used to obtain the payment authorization credential issued by the identity authentication module before the secure transmission module, identify the payment scenario based on the order information, determine the risk level of the payment scenario, and perform risk processing on the payment authorization credential based on the risk level.

6. The vehicle-mounted secure payment system according to claim 5, characterized in that, The risk processing of the payment authorization certificate based on the risk level includes: When the risk level is Level 1, the payment authorization certificate is released; When the risk level is Level 2, the payment authorization credential is intercepted, the identity authentication module is invoked to perform secondary identity authentication on the occupants of the vehicle, a second authentication result is obtained, and a first matching degree between the second authentication result and the first authentication result is obtained. If the second authentication result is successful and the first matching degree is greater than the matching degree threshold, the payment authorization credential is released; otherwise, the payment authorization credential is cancelled. When the risk level is level three, the payment authorization credential is intercepted, the navigation module is invoked to obtain the current driving route and the historical driving route, and the second matching degree between the current driving route and the historical driving route is obtained. When the second matching degree is greater than the matching degree threshold, the payment authorization credential is allowed to pass; otherwise, the payment authorization credential is cancelled. When the risk level is level four, the payment authorization certificate is intercepted and cancelled; The risks of the first level, the second level, the third level, and the fourth level increase sequentially.

7. The vehicle-mounted secure payment system according to claim 5 or 6, characterized in that, The risk processing of the payment authorization certificate based on the risk level includes: Based on the risk level, a driving task is generated; The navigation module is invoked to obtain the vehicle's progress in completing the driving task; If the completion progress reaches the progress threshold within the set time limit, the payment authorization certificate is released; otherwise, the payment authorization certificate is intercepted and cancelled.

8. The vehicle-mounted secure payment system according to claim 7, characterized in that, The process of generating a driving task based on the risk level includes: The navigation module is invoked to locate multiple target locations from the electronic map; Based on the risk level, select a corresponding number of target locations; the number of target locations is positively correlated with the risk level. The navigation module is invoked to perform path planning based on the selected target locations, generating a driving route; the driving route passes through all the selected target locations. The driving task is determined based on the route to be traveled.

9. The vehicle-mounted secure payment system according to claim 1, characterized in that: The secure transmission module is also used to negotiate with the payment platform and the user terminal to set the vehicle-mounted secure payment system as a necessary communication node between the payment platform and the user terminal.

10. A car, characterized in that, The vehicle includes the in-vehicle secure payment system as described in any one of claims 1-9.

Images