Cloud payment method, device and equipment based on ETC extended application and medium

Abstract

The cloud payment method, device and equipment based on ETC extended application and medium relate to the field of data processing. In the method, a payment request sent by a roadside unit deployed in a transaction scene is received; the payment request is analyzed and converted to obtain a static vehicle identifier and a static scene identifier corresponding to the current transaction; historical trajectory data sequences associated with the static vehicle identifier are extracted according to the static vehicle identifier; a plurality of payment scenario files bound to the static vehicle identifier are generated based on the historical trajectory data sequences; a current trajectory data sequence is obtained, and a target payment scenario file corresponding to the current transaction is determined based on the current trajectory data sequence; a corresponding target specified payment account is extracted from the target payment scenario file, and a payment interface of the target specified payment account is called to complete a payment operation in combination with a transaction amount in the payment request, and a payment result is returned to the roadside unit. The technical scheme provided by the application improves user experience.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of data processing, in particular to a cloud payment method and device based on ETC extended application, equipment and medium. BACKGROUND

[0002] With the rapid development of Internet of Things and intelligent transportation technology, the electronic toll collection system (ETC) realizes the automatic payment of toll fees without stopping the vehicle by installing an on-board unit (OBU) on the vehicle and a road side unit (RSU) at the toll station, and using radio frequency identification (RFID) technology, which greatly improves the road traffic efficiency. However, the traditional ETC system is mainly a closed special system applied to highway tolls, and its transaction processing mode is mainly pre-account deduction or bank background batch processing accounting. This architecture has single function and poor expansibility, which leads to the application scene of ETC being strictly limited in the field of highways, and it is difficult to meet the requirements of payment flexibility and openness of diversified, small and high-frequency social payment scenes such as urban parking lots, gas stations and commercial complexes, thereby limiting its potential as a convenient identity recognition and payment medium.

[0003] In order to break through the application limitations of ETC system, a scheme combining ETC technology with cloud payment platform is proposed in the prior art. The general process of this scheme is as follows: when a vehicle passes through a payment scene (such as a parking lot exit) where a road side unit (RSU) is deployed, the RSU reads the OBU information or recognizes the license plate information of the vehicle, and uploads these vehicle identity information to the cloud payment server through the network. The cloud server queries the binding relationship between the vehicle identity and the user payment account according to the received vehicle information, and then calls the corresponding payment interface to deduct the fee from the user's bound account, and returns the transaction result to the RSU and the user. This way connects the identification function of ETC with the mature Internet payment system, so that ETC can go out of the highway and be applied to a wider payment field.

[0004] Although the above-mentioned scheme combined with cloud payment solves the problem of ETC application scenario expansion to some extent, it still has problems in actual application. The existing scheme usually sets a default subscription in which the vehicle identity is strongly bound to a payment account of a user in the cloud, and the subscription account is used by default for payment in all expanded scenarios. However, in the complex consumption scenarios in reality, a user often has multiple payment accounts for different purposes, such as a personal consumption account, a family shared account, and a business reimbursement account. When a user drives into a large commercial complex, his purpose for parking this time may be to visit for business and use the business account to pay for parking, or it may be for personal shopping and use personal credit card points. Under the existing technical framework, the system cannot perceive the user's immediate payment intention and can only mechanically use the default account to deduct the payment. If the user wants to switch the payment method, he must take out his mobile phone and perform a tedious operation, resulting in poor user experience. SUMMARY

[0005] The present application provides a cloud payment method, device, equipment and medium based on ETC application expansion, which improves the user experience.

[0006] In a first aspect of the present application, a cloud payment method based on ETC application expansion is provided, which comprises: receiving a payment request sent by a roadside unit deployed in a transaction scenario; analyzing and converting the payment request to obtain a static vehicle identifier and a static scenario identifier corresponding to the current transaction; wherein the static vehicle identifier is used to identify the vehicle identity, and the static scenario identifier is used to identify the transaction location; according to the static vehicle identifier, extracting a historical trajectory data sequence associated with the static vehicle identifier from a preset vehicle trajectory database, the historical trajectory data sequence being composed of a plurality of position points arranged in time sequence; based on the historical trajectory data sequence, generating a plurality of payment scenario files bound to the static vehicle identifier; wherein one payment scenario file defines at least one geographic fence area as a trigger condition and a specified payment account corresponding to the trigger condition; obtaining a current trajectory data sequence, determining a target payment scenario file corresponding to the current transaction based on the current trajectory data sequence; extracting a corresponding target specified payment account from the target payment scenario file, and calling a payment interface of the target specified payment account, combining the transaction amount in the payment request to complete the payment operation, and returning the payment result to the roadside unit. This technical solution fundamentally solves the problems of poor payment account flexibility and insufficient scenario adaptability in the existing ETC system by analyzing the static identifiers of vehicles and scenarios, generating payment scenario files using historical trajectory data, and combining dynamic matching and automatic payment mechanism, which significantly improves user experience and payment efficiency.

[0007] By adopting the technical scheme, a payment request sent by a roadside unit in a transaction scene is received and analyzed and converted to obtain a static vehicle identifier and a static scene identifier, so that the vehicle identity initiating the transaction and the transaction location can be accurately identified. Then, according to the static vehicle identifier, historical trajectory data sequence of the vehicle is extracted from a preset vehicle trajectory database, and a plurality of payment scenario files bound to the vehicle are generated based on the historical trajectory data sequence, each payment scenario file defining a geographic fence area of a trigger condition and a corresponding specified payment account. When the vehicle triggers a payment request in a certain transaction scene, the current trajectory data sequence of the vehicle can be obtained, and the most matched target payment scenario file is determined from the plurality of payment scenario files based on the current trajectory data sequence, and the target specified payment account is extracted, and a payment interface thereof is called to complete the payment operation. This method uses vehicle trajectory big data to automatically preset personalized payment scenarios for each vehicle, and dynamically matches the optimal payment method according to the real-time position of the vehicle, so that the vehicle payment is more intelligent and convenient. At the same time, the analysis of the payment request and the generation and matching of the payment scenario are all concentrated in the cloud, reducing the computing and storage burden of the roadside unit and improving the scalability of the system. The technical scheme solves the problems of poor flexibility of payment accounts and insufficient scene adaptability in the existing ETC system by analyzing the vehicle and scene static identifiers, generating payment scenario files using historical trajectory data, and combining dynamic matching and automatic payment mechanism, and significantly improves the user experience

[0008] Optionally, the plurality of payment scenario files bound to the static vehicle identifier are generated based on the historical trajectory data sequence, specifically including: performing a density clustering algorithm on a plurality of the position points to identify a high-density stay point cluster with an overall density exceeding a preset overall density threshold; extracting a center position coordinate of the high-density stay point cluster, and generating a circular geographic fence area with the center position coordinate as the center and a preset distance as the radius; obtaining POI information corresponding to a target position point in the high-density stay point cluster, and performing semantic analysis on the POI information to obtain a corresponding target semantic label; determining a specified payment account matched with the target semantic label according to a preset mapping relationship; associating each of the geographic fence areas with the corresponding specified payment account to generate the payment scenario file, the payment scenario file containing the center position coordinate, the radius size of the geographic fence area, and the account identifier of the corresponding specified payment account; and binding and storing the generated plurality of payment scenario files with the static vehicle identifier.

[0009] By adopting the technical scheme, the density clustering algorithm is performed on the position points in the vehicle historical trajectory data sequence, high-density stay point clusters with overall density exceeding a preset threshold are identified, it is indicated that the vehicle often stays in these areas, and these areas are likely to be the key consumption places of the vehicle owner. Then, the center position coordinates of each high-density stay point cluster are extracted, a circular geofence region is generated with the center position coordinates as the center and a preset distance as the radius, POI information in the region is acquired, target semantic labels are obtained through semantic analysis, and a specified payment account matched with the semantic labels is determined according to a preset mapping relationship. In this way, a payment scenario file is formed for each high-density stay region, which contains the position range of the geofence region and the identifier of the specified payment account. Finally, the generated multiple payment scenario files are bound and stored with the static identifier of the vehicle. This method fully taps the potential value of the vehicle trajectory data, automatically discovers the high-frequency stay regions of the vehicle by using the clustering algorithm and semantic analysis technology, and matches the most suitable payment account for each region according to the position attribute and POI semantic label of the region, to form a personalized payment scenario configuration. When the vehicle triggers a transaction in these regions, the specified payment account related to the region can be automatically used for payment, improving the convenience and contextualization level of payment.

[0010] Optionally, the density clustering algorithm is performed on the multiple position points, and high-density stay point clusters with overall density exceeding a preset overall density threshold are identified, specifically including: calculating a local density of a first position point, the local density being a number of second position points with a spatial distance less than a preset distance threshold from the first position point, the first position point and the second position point being any two position points in the multiple position points; identifying a continuous position point set in the historical trajectory data sequence with a spatial position change less than a preset position threshold in a continuous time period, and accumulating a time length of the continuous time period, the time length being determined as a stay time length of each position point in the continuous position point set; marking a position point with the local density greater than a preset density threshold and the stay time length greater than a preset time length threshold as a core point; creating a clustering cluster with a first core point as the center, and attributing a second core point falling within a preset circular region with the first core point as the center to the clustering cluster, the first core point and the second core point being any two core points in the multiple core points; performing weighted average on the local densities of all position points in each clustering cluster to obtain an overall density of the clustering cluster, and determining the clustering cluster as a high-density stay point cluster when the overall density is greater than a preset overall density threshold.

[0011] By adopting the technical solution, the local density of each position point in the historical trajectory data sequence is calculated, and a core point satisfying certain threshold conditions in both time and space dimensions is identified. The local density reflects the number of other position points in the neighborhood of the position point. The greater the local density, the longer the vehicle stays near the position point and the higher the frequency of staying. At the same time, by identifying a set of continuous position points whose spatial position changes less than a preset threshold in a continuous time period and accumulating the time length as the stay time length, it can be found that the vehicle has stayed in some areas for a long time. The position point with a local density greater than a preset density threshold and a stay time length greater than a preset time length threshold is marked as a core point. Then, a clustering cluster is created with a core point as the center, and other core points falling within a preset circular region centered on the core point are classified into the clustering cluster. The local densities of all position points in each clustering cluster are weighted and averaged to obtain the overall density of the clustering cluster. The greater the overall density, the more the clustering cluster represents a hot area where the vehicle often stays. When the overall density is greater than a preset overall density threshold, the clustering cluster is determined as a high-density stay point cluster. This clustering method fully utilizes the spatiotemporal characteristics of vehicle trajectory points, accurately identifies the stay rules of the vehicle in both time and space dimensions through the dual constraints of local density and stay time length, and ensures the clustering quality of the high-density stay point cluster through the weighted average of local density and the setting of overall density threshold, thereby laying a good data foundation for subsequent payment scenarios.

[0012] Optionally, the POI information corresponding to the target position point in the high-density stay point cluster is obtained, and the POI information is semantically analyzed to obtain a corresponding target semantic label, specifically including: taking the target position point as a query parameter, requesting and obtaining a plurality of POI information within a preset query radius range with the center position coordinate as the center from a preset electronic map service, the POI information including a POI name attribute and a POI category attribute; inputting the POI name attribute and the POI category attribute into a preset semantic analysis model to generate a corresponding semantic label by the preset semantic analysis model; counting the occurrence frequency of each semantic label, and determining the semantic label with the highest occurrence frequency as the target semantic label.

[0013] By adopting the technical solution, the target position point in the high-density stay point cluster is taken as a query parameter, a POI information within a certain range of the position point is requested from a preset electronic map service, and the name attribute and the category attribute of the POI information are extracted. Then, the name attribute and the category attribute of the POI are input into a preset semantic analysis model for analysis to generate a corresponding semantic label. The semantic label reflects the business type and the function attribute of the POI. Next, the occurrence frequency of each semantic label is counted, and the semantic label with the highest frequency is determined as the target semantic label of the high-density stay point cluster, representing the main semantic feature of the stay area. This method automatically extracts the business semantics of the high-density stay area of the vehicle by means of the POI data provided by the electronic map service and by using the semantic analysis technology, associates the position information of the vehicle with the POI information around the vehicle, and mines the commercial intention and the consumption preference behind the stay behavior of the vehicle. Through the frequency statistics of the semantic label, the main business attribute of each stay area is accurately grasped, which provides an important basis for subsequent matching of a specified payment account, and makes the construction of the payment scenario more accurate and personalized. Meanwhile, the complex semantic analysis process is encapsulated in the preset model, the efficiency and the accuracy of the semantic extraction are improved, and the development and maintenance cost of the system is reduced.

[0014] Optionally, the target payment scenario file corresponding to the current transaction is determined based on the current trajectory data sequence, specifically including: taking a starting position point of the current trajectory data sequence as a judgment basis, and performing traversal matching in a plurality of payment scenario files; judging whether the starting position point falls into a target geofence area defined by a first payment scenario file, the first payment scenario file being any one of the plurality of payment scenario files; if it is determined that the starting position point falls into the target geofence area defined by the first payment scenario file, the first payment scenario file is determined as the target payment scenario file.

[0015] By adopting the technical solution, the starting position point of the current trajectory data sequence of the vehicle is taken as the judgment basis, and the multiple payment scenario files bound to the vehicle are traversed and matched to determine whether the starting position point falls within the target geofence region defined by each payment scenario file. The target geofence region is generated according to the historical high-density stay point cluster of the vehicle and represents a hotspot region where the vehicle often stays and consumes. If the starting position point falls within the target geofence region of a certain payment scenario file, it indicates that the vehicle is currently most likely in the consumption scenario corresponding to the payment scenario, and the payment account specified by the payment scenario should be used to complete the transaction. By traversing and matching, the first payment scenario file containing the starting position point is found, and the file is determined as the target payment scenario file corresponding to the current transaction. This method uses real-time location information of the vehicle to dynamically determine the payment scenario in which the vehicle is currently located, quickly matches the most suitable payment method from the multiple payment scenario files of the vehicle, and makes the payment process more automated and intelligent. The vehicle owner does not need to manually select a payment account, and the system can automatically recommend the best payment scenario according to the location of the vehicle, reducing the operation steps of the user and improving the payment efficiency. At the same time, the calculation process of location matching and scenario selection is concentrated in the cloud, simplifying the function of the roadside unit and reducing the deployment and maintenance difficulty of the system.

[0016] Optionally, before determining the first payment scenario file as the target payment scenario file, the method further comprises: determining whether there are multiple first payment scenario files; if it is determined that there are multiple first payment scenario files, extracting parameters of the first payment scenario files, the parameters including a radius size of a first geofence region corresponding to the first payment scenario file, a distance between a center position coordinate of the first geofence region and the starting position point, and a historical calling frequency and a generation timestamp of the first payment scenario file; based on the parameters, determining a comprehensive weight corresponding to the first payment scenario file, and selecting the first payment scenario file with the maximum comprehensive weight as the target payment scenario file.

[0017] By adopting the technical scheme, before determining the target payment scenario file, a priority comparison mechanism for multiple candidate payment scenario files is introduced. When the starting position point of the vehicle falls within the target geographic fence region of multiple payment scenario files, an optimal payment scenario file needs to be selected from them as the final target file. By extracting the parameters of each candidate payment scenario file, including the radius size of the corresponding geographic fence region, the distance between the center position coordinates and the starting position point, the historical calling frequency and the generation timestamp, etc., and based on these parameters, the comprehensive weight of each candidate file is calculated. The smaller the radius, the closer the distance, the higher the calling frequency, and the newer the generation time, the greater the comprehensive weight of the payment scenario file, indicating that the payment scenario is more relevant to the current location and use habits of the vehicle, and should be selected preferentially. By comparing the comprehensive weights of multiple candidate files, the payment scenario file with the largest weight is selected as the final target file. This method further introduces multi-dimensional relevance evaluation based on location matching, comprehensively considers the influence factors of payment scenarios in geographical distance, use frequency, timeliness, etc., and can reasonably select the optimal scheme from multiple candidate schemes, making the payment scenario matching more accurate and comprehensive. At the same time, by pre-extracting parameters and designing a weight calculation formula, the complex scenario evaluation process is quantized and automated, improving the efficiency and accuracy of scenario matching and reducing the computational burden of the system.

[0018] Optionally, the payment interface of the target specified payment account is called, the transaction amount in the payment request is combined to complete the payment operation, and the payment result is returned to the road side unit, specifically including: using the target specified payment account and the transaction amount in the payment request to construct a payment instruction in a preset format; the payment instruction is digitally signed by a preset asymmetric encryption algorithm and a private key associated with the target specified payment account to generate a signed payment instruction; the signed payment instruction is sent to a third-party payment gateway to perform a deduction, and a payment success code or a failure status code returned by the third-party payment gateway is packaged into the payment result and sent to the road side unit.

[0019] By adopting the technical scheme, after the target payment scenario file and the corresponding specified payment account are determined, a standardized payment instruction is constructed by using the specified payment account and the transaction amount in the payment request, the payment instruction contains the necessary information for initiating the transaction, and provides a data basis for subsequent payment operations. Then, using the private key associated with the specified payment account, the payment instruction is digitally signed by a preset asymmetric encryption algorithm to generate a signed payment instruction. The digital signature can ensure the authenticity and integrity of the payment instruction, prevent the instruction from being tampered with or forged, and improve the security of the payment. Then, the signed payment instruction is sent to the third-party payment gateway for actual fund deduction operation, and the payment result (success code or failure status code) returned by the payment gateway is encapsulated and sent to the roadside unit, completing the entire payment process. This method introduces a digital signature mechanism to ensure the security of the payment instruction during transmission and processing, effectively preventing security threats such as man-in-the-middle attacks and replay attacks, and improving the credibility of vehicle payment. At the same time, the core operations such as instruction signing and gateway communication are centralized in the cloud, simplifying the security functions of the roadside unit and reducing the implementation difficulty and operation and maintenance cost of the system. In addition, the use of standardized instruction format and unified payment gateway interface improves the standardization and compatibility of the payment process, facilitating the connection and expansion with different payment services, and enhancing the adaptability and scalability of the system.

[0020] In a second aspect of the present application, a cloud payment device based on ETC extended application is provided, which comprises a payment request receiving module, a transaction determining module, a historical trajectory extracting module, a payment scenario file generating module, and a payment operation executing module, wherein: the payment request receiving module is configured to receive a payment request sent by a road side unit deployed in a transaction scene; the transaction determining module is configured to parse and convert the payment request to obtain a static vehicle identifier and a static scene identifier corresponding to a current transaction; the static vehicle identifier is used to identify the vehicle identity, and the static scene identifier is used to identify the transaction location; the historical trajectory extracting module is configured to extract a historical trajectory data sequence associated with the static vehicle identifier from a preset vehicle trajectory database according to the static vehicle identifier, the historical trajectory data sequence being composed of a plurality of position points arranged in time sequence; the payment scenario file generating module is configured to generate a plurality of payment scenario files bound to the static vehicle identifier based on the historical trajectory data sequence; wherein one payment scenario file defines at least one geographic fence area as a trigger condition and a specified payment account corresponding to the trigger condition; a current trajectory data sequence is obtained, and a target payment scenario file corresponding to the current transaction is determined based on the current trajectory data sequence; and the payment operation executing module is configured to extract a corresponding target specified payment account from the target payment scenario file, and call a payment interface of the target specified payment account to complete a payment operation in combination with a transaction amount in the payment request, and return a payment result to the road side unit.

[0021] In a third aspect of the present application, an electronic device is provided, which comprises a processor, a memory, a user interface, and a network interface, the memory is configured to store instructions, the user interface and the network interface are both configured to communicate with other devices, and the processor is configured to execute the instructions stored in the memory to enable the electronic device to perform the method according to any one of the above aspects.

[0022] In a fourth aspect of the present application, a computer readable storage medium is provided, which stores instructions, when the instructions are executed, the method according to any one of the above aspects is performed.

[0023] In summary, the one or more technical solutions provided in the present application have at least the following technical effects or advantages:

[0024] 1. The technical solution fundamentally solves the problems of poor flexibility of payment account and insufficient scene adaptability in the existing ETC system by parsing the static identifiers of vehicle and scene, generating payment scenario files by using historical trajectory data, and combining dynamic matching and automatic payment mechanism, thereby significantly improving user experience and payment efficiency. BRIEF DESCRIPTION OF DRAWINGS

[0025] Figure 1 is a flow diagram of a cloud payment method based on ETC extended application disclosed by an embodiment of the present application;

[0026] Figure 2 is another flow diagram of a cloud payment method based on ETC extended application disclosed by an embodiment of the present application;

[0027] Figure 3 is a module diagram of a cloud payment device based on ETC extended application disclosed by an embodiment of the present application;

[0028] Figure 4 is a structural diagram of an electronic device disclosed by an embodiment of the present application.

[0029] Legend: 301, payment request receiving module; 302, transaction determining module; 303, historical trajectory extracting module; 304, payment scenario file generating module; 305, payment operation executing module; 400, electronic device; 401, processor; 402, communication bus; 403, user interface; 404, network interface; 405, memory. DETAILED DESCRIPTION

[0030] In order for those skilled in the art to better understand the technical solutions in the specification, the technical solutions in the specification will be clearly and completely described below in conjunction with the drawings in the embodiments of the specification. Obviously, the described embodiments are only some of the embodiments of the present application, not all the embodiments.

[0031] In the description of the embodiments of the present application, the words such as "for example" or "for instance" are used to represent an example, illustration or description. Any embodiment or design scheme described as "for example" or "for instance" in the embodiments of the present application should not be interpreted as more preferred or more advantageous than other embodiments or design schemes. Rather, the words such as "for example" or "for instance" are intended to present the relevant concept in a specific manner.

[0032] In the description of the embodiments of the present application, the term "a plurality of" means two or more. For example, a plurality of systems means two or more systems, and a plurality of screen terminals means two or more screen terminals. In addition, the terms "first" and "second" are used for description purposes only, and should not be interpreted as indicating or implying relative importance or implicitly indicating the indicated technical features. Therefore, the features defined with "first" and "second" can explicitly or implicitly include one or more of the features. The terms "include", "contain", "have" and their variants mean "include but are not limited to", unless otherwise specifically emphasized.

[0033] The application provides a cloud payment method based on ETC extended application Figure 1 , Figure 1 is a flowchart of a cloud payment method based on ETC extended application provided by an embodiment of the application. The method is applied to a server, the server is used for executing a cloud payment program based on ETC extended application, the server can be a server or a server cluster composed of multiple servers, or a cloud computing service center. The method comprises steps S101 to S106, and the steps are as follows:

[0034] Step S101: receiving a payment request sent by a roadside unit deployed in a transaction scene.

[0035] In step S101, the roadside unit deployed in the transaction scene sends a payment request to the server when detecting that a vehicle enters a transaction area. The payment request can be transmitted to the server through a wired or wireless network, and the payment request usually contains information representing the identity of the vehicle (such as a license plate number, a vehicle identifier, etc.) and information representing a transaction location (such as a roadside unit number, a transaction scene code, etc.).

[0036] Step S102: analyzing and converting the payment request to obtain a static vehicle identifier corresponding to the current transaction and a static scene identifier; wherein the static vehicle identifier is used to identify the identity of the vehicle, and the static scene identifier is used to identify the transaction location.

[0037] In step S102, the server receives the payment request and analyzes and converts the content of the payment request. The server extracts the vehicle identity information and the transaction location information from the payment request and converts them into a static vehicle identifier and a static scene identifier. The static vehicle identifier is a unique string or code used to identify the identity of the vehicle, and the static vehicle identifier of different vehicles is different. The static scene identifier is also a unique string or code used to identify the location where the transaction occurs, and different transaction scenes correspond to different static scene identifiers.

[0038] For example, if the payment request contains a license plate number "JingA12345" and a roadside unit number "RSU001", the server can convert the license plate number "JingA12345" to a static vehicle identifier "VC_1001" and the roadside unit number "RSU001" to a static scene identifier "SC_A001". The specific form of the static vehicle identifier and the static scene identifier can be determined according to system design.

[0039] Step S103: according to the static vehicle identifier, extracting a historical trajectory data sequence associated with the static vehicle identifier from a preset vehicle trajectory database, the historical trajectory data sequence being composed of a plurality of position points arranged in time sequence.

[0040] In step S103, the server extracts a historical trajectory data sequence associated with the vehicle identification from a preset vehicle trajectory database according to the obtained static vehicle identification. The vehicle trajectory database is a database previously established by the server, which stores historical driving trajectory data of each vehicle. These trajectory data can come from multiple channels such as vehicle-mounted GPS devices, roadside monitoring devices, etc.

[0041] The server queries the vehicle trajectory database with the static vehicle identification as an index to obtain the driving trajectory data of the vehicle in the past period of time. These data are arranged in chronological order to form a historical trajectory data sequence. The historical trajectory data sequence is composed of multiple location points, each of which includes latitude and longitude coordinates and a timestamp, representing the position of the vehicle at a certain time.

[0042] For example, for the static vehicle identification "VC_1001", the server queries the vehicle trajectory database to obtain the following historical trajectory data sequence: timestamp 1, longitude 1, latitude 1;...; timestamp n, longitude n, latitude n.

[0043] These data reflect the driving trajectory of vehicle "VC_1001" from timestamp 1 to timestamp n. After obtaining the historical trajectory data sequence of the vehicle, the server can further analyze the vehicle's stay near the current transaction scene in combination with the static scene identification and other information, determine the most suitable payment scenario for the current transaction, and select the corresponding payment account to complete the deduction. These subsequent steps can help the server achieve automatic and personalized payment of vehicles in different scenarios.

[0044] Step S104: Based on the historical trajectory data sequence, generate a plurality of payment scenario files bound to the static vehicle identification; wherein each payment scenario file defines at least one geographic fence area as a trigger condition and a specified payment account corresponding to the trigger condition.

[0045] In step S104, the server generates a plurality of payment scenario files for the vehicle based on the historical trajectory data sequence obtained from the vehicle trajectory database, and binds these payment scenario files to the static vehicle identification of the vehicle. Each payment scenario file defines one or more geographic fence areas as trigger conditions and a specified payment account corresponding to the trigger condition.

[0046] The server identifies the geographic locations where the vehicle often stays or frequently appears by analyzing the historical trajectory data of the vehicle, and establishes circular or polygonal geographic fence areas centered on these locations. At the same time, the server infers the types of transactions that may occur in these areas based on the commercial network information near these geographic locations, and specifies one or more payment accounts related to each geographic fence area.

[0047] For example, the server analyzes the historical trajectory of the vehicle "VC_1001" and finds that the vehicle stays in the underground parking lot of a shopping mall for a long time every week, so the server establishes a circular geographic fence region with a radius of 500 meters centered on the geographic coordinates of the parking lot, and takes the region as a trigger condition of a payment scenario file. At the same time, the server specifies two associated payment accounts for the payment scenario file according to the information of the shopping mall: one is the bank card account associated with the vehicle owner in the shopping mall, and the other is the member points account associated with the vehicle owner in the shopping mall. Similarly, the server can generate corresponding payment scenario files for different scenarios such as gas stations, toll roads, scenic spots, etc.

[0048] In one possible implementation, referring to Figure 2 , an embodiment of step S104 is described in detail in combination with Figure 2 , including steps S201-S209, which are as follows:

[0049] Step S201: Calculate the local density of the first position point, the local density being the number of second position points with a spatial distance less than a preset distance threshold from the first position point, the first position point and the second position point being any two position points in the plurality of position points.

[0050] In step S201, the server calculates the local density of each position point in the historical trajectory data sequence. For any two position points, the server determines whether their spatial distance is less than a preset distance threshold. For a certain position point (referred to as the first position point), the server counts the number of other position points (referred to as the second position point) within a preset distance range around it, and takes the number as the local density of the first position point. The local density reflects the distribution of position points near the position point, and the larger the local density, the higher the frequency of the vehicle appearing near the position point.

[0051] Step S202: Identify a set of consecutive position points in the historical trajectory data sequence whose spatial positions change less than a preset position threshold within a continuous time period, and accumulate the length of the continuous time period, and determine the length of stay of each position point in the set of consecutive position points as the length of the continuous time period.

[0052] In step S202, the server identifies the case where the vehicle stays at certain locations. The server traverses the historical trajectory data sequence in chronological order, finds a series of consecutive location points where the spatial position of the vehicle changes less than a preset position threshold in consecutive time periods, and groups them into a consecutive location point set. The server accumulates the duration of the consecutive time periods corresponding to the consecutive location point set to determine the stay duration of each location point in the set. The stay duration reflects the time the vehicle stays at a location. The longer the stay duration, the more likely that the vehicle has some activities or transactions at the location.

[0053] Step S203: Mark the location point with local density greater than a preset density threshold and stay duration greater than a preset duration threshold as a core point.

[0054] In step S203, the server determines whether a location point is a core point according to its local density and stay duration. For a location point with local density greater than a preset density threshold and stay duration greater than a preset duration threshold, the server marks it as a core point. Core points usually correspond to locations frequently visited by the vehicle and with longer stay time, and are the basis for clustering analysis.

[0055] Step S204: Create a clustering cluster with a first core point as the center and assign a second core point falling within a preset circular region centered on the first core point to the clustering cluster, the first core point and the second core point being any two of the plurality of core points.

[0056] In step S204, the server creates a clustering cluster with a core point as the center. The server creates a circular region with the core point as the center and a preset radius, and assigns other core points falling within the circular region to the clustering cluster. The server processes all core points one by one, and finally obtains a plurality of clustering clusters, each consisting of one or more core points adjacent to each other.

[0057] Step S205: Weighted average the local densities of all location points in each clustering cluster to obtain the overall density of the clustering cluster, and determine the clustering cluster as a high-density stay point cluster when the overall density is greater than a preset overall density threshold.

[0058] In step S205, the server calculates the overall density of each clustering cluster to determine whether the clustering cluster is a high-density stay point cluster. The server weighted averages the local densities of all location points in the clustering cluster to obtain the overall density of the clustering cluster. If the overall density of the clustering cluster is greater than a preset overall density threshold, the clustering cluster is determined as a high-density stay point cluster. High-density stay point clusters usually correspond to important locations frequently visited by the vehicle, such as home, company, and frequently visited shopping malls, and are important references for generating payment scenario files.

[0059] For example, the server performs clustering analysis on the historical trajectory data of the vehicle "VC_1001" and identifies three high-density stay point clusters: A, B, and C. Among them, the A point cluster is located near a large shopping mall, contains dozens of core points, and has a high overall density, which is presumed to be the shopping mall frequently visited by the vehicle owner; the B point cluster is located near an office building, contains several core points, and has a relatively high overall density, which is presumed to be the workplace of the vehicle owner; and the C point cluster is located near a residential area, contains several core points, and has an average overall density, which is presumed to be the home of the vehicle owner. The server can generate three payment scenario files for the vehicle "VC_1001" based on this, targeting the consumption scenarios of the large shopping mall, the office building, and the residential area, and associating different payment accounts.

[0060] Step S206: Extract the center position coordinates of the high-density stay point cluster, and generate a circular geofence region with the center position coordinates as the center and a preset distance as the radius.

[0061] In step S206, the server calculates the center position coordinates of each high-density stay point cluster as the representative position of the point cluster. The server can use various methods to calculate the center position coordinates, such as taking the arithmetic mean of all position points within the point cluster, or selecting the position point with the highest local density within the point cluster as the center position. Then, the server generates a circular geofence region with the center position coordinates as the center and a preset distance as the radius. The geofence region covers the main range of the point cluster and can be used as a geographic condition to trigger the payment scenario file.

[0062] Step S207: Request and obtain multiple POI information within a preset query radius range centered on the center position coordinates from a preset electronic map service with the target position point as the query parameter, and the POI information includes POI name attributes and POI category attributes.

[0063] In step S207, the server takes the center position coordinates of the point cluster as the query parameter and initiates a request to a preset electronic map service (such as Baidu Map API, Gaode Map API, etc.) to obtain multiple POI (Point of Interest) information within a preset query radius range centered on the center position coordinates. POI information is a geographic location label on an electronic map, usually including the name attribute and category attribute of the POI. The name attribute represents the specific name of the POI, such as "Wanda Plaza" or "Zhongguancun Software Park"; the category attribute represents the category to which the POI belongs, such as "shopping center" or "office building".

[0064] Step S208: Input the POI name attribute and POI category attribute into a preset semantic analysis model to generate corresponding semantic labels by the preset semantic analysis model.

[0065] In step S208, the server inputs the obtained POI name and category attributes into a preset semantic analysis model for parsing. A semantic analysis model is a natural language processing model capable of extracting semantic information from text data. The server uses the semantic analysis model to analyze the name and category of each POI, extracting the semantic tags contained within. For example, for a POI named "Wanda Plaza" and categorized as "shopping center," the semantic analysis model might generate semantic tags such as "shopping mall," "shopping," "dining," and "entertainment"; for a POI named "Zhongguancun Software Park" and categorized as "office building," the semantic analysis model might generate semantic tags such as "office," "technology," and "company."

[0066] Step S209: Count the frequency of occurrence of each semantic tag and determine the semantic tag with the highest frequency as the target semantic tag.

[0067] In step S209, the server counts the frequency of all semantic tags appearing near the point cluster and selects the semantic tag with the highest frequency as the target semantic tag for that point cluster. The target semantic tag reflects the main semantic attributes of the geographical location of the point cluster and can serve as an important reference for generating payment scenario files.

[0068] For example, for a high-density stop cluster A for vehicle "VC_1001", the server generates a geofence with a radius of 500 meters, centered on its center coordinates. Then, the server obtains the POI information within this area, and after parsing it using a semantic analysis model, obtains semantic tags such as "shopping mall," "shopping," "dining," and "cinema." Among these, the "shopping mall" tag appears most frequently and is identified as the target semantic tag for point cluster A. Based on this, the server can generate a payment scenario file for a large shopping mall, setting the geofence area as the coverage area of ​​point cluster A, setting the trigger condition as entering the geofence area, and setting the payment account as the bank card or membership card associated with the vehicle owner at Wanda Plaza. Similarly, the server can generate a payment scenario file for an office building for point cluster B and a payment scenario file for a residential community for point cluster C.

[0069] Step S210: Determine the specified payment account that matches the target semantic tag according to the preset mapping relationship.

[0070] In step S210, the server queries the preset mapping relationship table to determine the designated payment account matched with each semantic label. The mapping relationship table is a data structure pre-configured by the server, used to store the correspondence between semantic labels and payment accounts. For example, the server can map the "shopping mall" label to the credit card account of the vehicle owner, map the "office building" label to the bus card account of the vehicle owner, and map the "residential community" label to the electronic wallet account of the vehicle owner, etc. These mapping relationships can be preset based on common sense, or dynamically adjusted by analyzing the historical payment data of the vehicle owner.

[0071] Step S211: associate each geofence region with the corresponding designated payment account, and generate a payment scenario file containing the center position coordinates of the geofence region, the radius size, and the account identifier of the corresponding designated payment account.

[0072] In step S211, the server associates the geofence region of each high-density stay point cluster with its matched designated payment account, and generates a complete payment scenario file. The payment scenario file is a structured data format used to describe the payment scenario in a specific geographic location. Each payment scenario file contains the following key fields:

[0073] Center position coordinates of the geofence region: representing the triggering position of the payment scenario;

[0074] Radius size of the geofence region: representing the triggering range of the payment scenario;

[0075] Account identifier of the designated payment account: representing the payment account used in the payment scenario.

[0076] The server generates multiple payment scenario files according to the values of these fields, each configuration file corresponding to a high-density stay point cluster and a payment scenario.

[0077] Step S212: bind and store the generated multiple payment scenario files with the static vehicle identifier.

[0078] In step S212, the server binds and stores the generated multiple payment scenario files with the static identifier of the vehicle. The server takes the static identifier of the vehicle (such as license plate number, vehicle frame number, etc.) as the index, and associates all payment scenario files of the vehicle under this identifier to form a payment scenario file library. When the server receives a payment request from the vehicle, it can quickly query and match the corresponding payment scenario file according to the static identifier carried in the request.

[0079] For example, for the three high-density stay point clusters A, B, and C of the vehicle "VC_1001", the server determines their target semantic labels as "shopping mall", "office building", and "residential area" respectively. Then, the server queries the preset mapping relationship table and obtains the following mapping relationships:

[0080] "shopping mall" label -> credit card account of the vehicle owner (account identifier "CC_001")

[0081] "office building" label -> public transportation card account of the vehicle owner (account identifier "TC_001")

[0082] "residential area" label -> e-wallet account of the vehicle owner (account identifier "EW_001")

[0083] Accordingly, the server generates three payment scenario files:

[0084] Configuration file 1: {geofence area center point: A point cluster center coordinates, geofence area radius: 500 meters, specified payment account identifier: CC_001}

[0085] Configuration file 2: {geofence area center point: B point cluster center coordinates, geofence area radius: 300 meters, specified payment account identifier: TC_001}

[0086] Configuration file 3: {geofence area center point: C point cluster center coordinates, geofence area radius: 200 meters, specified payment account identifier: EW_001}

[0087] Finally, the server binds and stores these three configuration files with the license plate number of the vehicle "VC_1001" to form a payment scenario file library exclusive to the vehicle. When the vehicle triggers a payment request in scenarios such as shopping malls, office buildings, and residential areas, the server can automatically match the corresponding payment scenario file and call the specified payment account to complete the payment.

[0088] Step S105: Obtain the current trajectory data sequence, and determine the target payment scenario file corresponding to the current transaction based on the current trajectory data sequence.

[0089] In step S105, the server obtains the current trajectory data sequence of the vehicle, i.e., the sequence of location points of the vehicle in the recent period of time. The server takes the starting location point of the current trajectory data sequence as the reference and matches it in the multiple payment scenario files bound to the vehicle to determine whether the starting location point falls within the geofence area defined by a payment scenario file. If the matching is successful, the payment scenario file is determined as the target payment scenario file corresponding to the current transaction.

[0090] For example, when the vehicle "VC_1001" enters a certain transaction scenario and triggers a roadside unit to initiate a payment request, the server obtains the trajectory data of the vehicle in the recent period of time, finds that the starting position point falls into the above-mentioned geographic fence area of the parking lot of the shopping mall, and determines the payment scenario file corresponding to the geographic fence area as the target payment scenario file.

[0091] In a possible implementation, based on the current trajectory data sequence, the target payment scenario file corresponding to the current transaction is determined, specifically including steps S1051-S1053, and the steps are as follows:

[0092] Step S1051: Taking the starting position point of the current trajectory data sequence as the basis, the starting position point is matched in the plurality of payment scenario files.

[0093] In step S1051, the server first obtains the starting position point of the current trajectory data sequence of the vehicle, that is, the geographic position of the vehicle when the payment request is triggered. The server takes the latitude and longitude coordinates of the starting position point as the basis, and starts to traverse all the payment scenario files bound to the vehicle, and matches them one by one.

[0094] Step S1052: Determine whether the starting position point falls into the target geographic fence area defined by the first payment scenario file, and the first payment scenario file is any one of the plurality of payment scenario files.

[0095] In step S1052, the server reads the target geographic fence area defined in each payment scenario file in turn, and determines whether the starting position point of the vehicle falls into the area. Specifically, the server compares the latitude and longitude coordinates of the starting position point with the center point coordinates and the radius size of the geographic fence area recorded in the configuration file, calculates the distance between the two points, and determines whether the starting position point is in the circular area with the center point as the center and the radius as the range.

[0096] If the calculated distance is less than or equal to the radius defined in the payment scenario file, it indicates that the starting position point falls into the target geographic fence area corresponding to the configuration file. At this time, the server marks the configuration file as a candidate target payment scenario file, and continues to traverse the next configuration file.

[0097] If the calculated distance is greater than the radius defined in the payment scenario file, it indicates that the starting position point is outside the target geographic fence area corresponding to the configuration file. At this time, the server excludes the payment scenario file and does not mark it as a candidate, and directly traverses the next payment scenario file.

[0098] Step S1053: If the starting location point is determined to fall within the target geofence region defined by the first payment scenario file, the first payment scenario file is determined as the target payment scenario file.

[0099] In step S1053, after the server completes the traversal matching of all configuration files, it checks whether there is a candidate target payment scenario file.

[0100] If none of the configuration files is marked as a candidate, it indicates that the current location of the vehicle does not belong to any known payment scenario, and the payment account cannot be automatically determined. At this time, the server can process the payment request in a default manner, such as sending a prompt to the vehicle owner to select a payment account, or using the default payment account set by the vehicle owner, etc.

[0101] If one or more configuration files are marked as candidates, the server selects one from the candidate configuration files as the final target payment scenario file. Generally, the starting location point of the vehicle does not fall within multiple target geofence regions at the same time, so there will be only one candidate configuration file. However, if there are multiple candidates, the server can select according to preset priority rules, such as preferentially matching a geofence region with a smaller radius, or preferentially matching a payment account with a higher usage frequency, etc.

[0102] For example, when the vehicle "VC_1001" triggers a payment request in a parking lot of a shopping mall, the server obtains the starting location point coordinates (X1, Y1) of the vehicle. Then, the server starts traversing the three payment scenario files bound to the vehicle:

[0103] The geofence region of configuration file 1 is a circular region with A point as the center and a radius of 500 meters. The server calculates the distance between the starting location point (X1, Y1) and point A as 300 meters, which is less than 500 meters, so configuration file 1 is marked as a candidate.

[0104] The geofence region of configuration file 2 is a circular region with B point as the center and a radius of 300 meters. The server calculates the distance between the starting location point (X1, Y1) and point B as 2000 meters, which is greater than 300 meters, so configuration file 2 is excluded.

[0105] The geofence region of configuration file 3 is a circular region with C point as the center and a radius of 200 meters. The server calculates the distance between the starting location point (X1, Y1) and point C as 5000 meters, which is greater than 200 meters, so configuration file 3 is excluded.

[0106] Finally, the server finds out that only profile 1 is marked as a candidate, and thus determines it as the final target payment scenario file. This indicates that the vehicle "VC_1001" is most likely to trigger a payment request within the shopping mall, and the server will use the credit card account specified in profile 1 for the subsequent payment operation.

[0107] In a possible implementation, before determining the first payment scenario file as the target payment scenario file, the method further includes: determining whether there are multiple first payment scenario files; if it is determined that there are multiple first payment scenario files, extracting parameters of the first payment scenario files, the parameters including a radius size of a first geographic fence area corresponding to the first payment scenario file, a distance between a center position coordinate of the first geographic fence area and a starting position point, and a historical calling frequency and a generation timestamp of the first payment scenario file; determining a comprehensive weight corresponding to the first payment scenario file based on the parameters, and selecting the first payment scenario file with the maximum comprehensive weight as the target payment scenario file.

[0108] Specifically, before determining the target payment scenario file, the server first determines whether there are multiple candidate profiles (i.e., the "first payment scenario file" in the foregoing). If there is only one candidate profile, it is directly determined as the target profile without subsequent weight calculation.

[0109] If there are multiple candidate profiles, the server needs to extract the related parameters of each candidate profile for calculating the comprehensive weight. These parameters include:

[0110] The radius size of the geographic fence area corresponding to the candidate profile: the smaller the radius, the more accurate the payment scenario area corresponding to the profile, and the higher the weight.

[0111] The distance between the center point of the geographic fence area corresponding to the candidate profile and the starting position point of the vehicle: the closer the distance, the closer the vehicle to the center of the payment scenario area corresponding to the profile, and the higher the weight.

[0112] The historical calling frequency of the candidate profile: the higher the calling frequency, the more common the payment scenario corresponding to the profile in the daily use of the vehicle, and the higher the weight.

[0113] The generation timestamp of the candidate profile: the newer the timestamp, the newer the payment scenario information corresponding to the profile, and the higher the weight.

[0114] The server brings the values of the above four parameters into a preset weight calculation formula to obtain the comprehensive weight of each candidate profile. The weight calculation formula can be designed according to actual needs, for example:

[0115] Combined weight = 1 / radius size × 1 / distance × historical call frequency × generation timestamp

[0116] Combined weight = weight coefficient of 1 / radius size + weight coefficient of 1 / distance + weight coefficient of historical call frequency + weight coefficient of generation timestamp

[0117] After the server calculates the combined weight of all candidate configuration files, it selects the configuration file with the highest weight value as the final target payment scenario file. This indicates that the payment scenario corresponding to this configuration file is the most matched with the current location and usage habits of the vehicle, and the accuracy and convenience of using the payment account specified in this configuration file for payment is the highest.

[0118] For example, when the vehicle "VC_1001" triggers a payment request within a large commercial district, its starting location point (X2, Y2) falls within the geographic fence area of three payment scenario files:

[0119] Configuration file A: corresponding to mall A, radius 500 meters, center point distance from starting point 200 meters, historical call 100 times, generation timestamp 2022-01-01.

[0120] Configuration file B: corresponding to mall B, radius 800 meters, center point distance from starting point 400 meters, historical call 50 times, generation timestamp 2022-06-01.

[0121] Configuration file C: corresponding to mall C, radius 1000 meters, center point distance from starting point 600 meters, historical call 80 times, generation timestamp 2022-03-01.

[0122] The server extracts the parameters of these three configuration files and brings them into the preset weight calculation formula:

[0123] Combined weight of configuration file A = 1 / 500 × 1 / 200 × 100 × 20220101 = 4044.04

[0124] Combined weight of configuration file B = 1 / 800 × 1 / 400 × 50 × 20220601 = 7.81

[0125] Combined weight of configuration file C = 1 / 1000 × 1 / 600 × 80 × 20220301 = 2.41

[0126] By comparing the size of the combined weight, the server finds that the weight of configuration file A is the highest, so it is determined as the final target payment scenario file. This indicates that the vehicle "VC_1001" is most likely to trigger a payment request within mall A, and the server will call the payment account specified in configuration file A (such as the membership card of mall A) to complete this payment.

[0127] Step S106: Extract the corresponding target designated payment account from the target payment scenario file, and call the payment interface of the target designated payment account to complete the payment operation in combination with the transaction amount in the payment request, and return the payment result to the roadside unit.

[0128] In step S106, the server extracts the pre-configured designated payment account from the target payment scenario file as the target payment account for this transaction. The server calls the payment interface corresponding to the payment account to deduct the transaction amount in the payment request from the account, and completes the payment operation. After the payment is completed, the server returns the payment result to the roadside unit that initiates the payment request.

[0129] Continuing the above example, the server determines that the payment scenario file of the shopping mall parking lot is the target, and extracts the bank card account associated with the vehicle owner in the mall. The server calls the payment interface of the bank to deduct the parking fee from the bank card account, and returns the result of successful deduction to the roadside unit of the shopping mall parking lot, and the roadside unit controls the parking lot gate to open and release the vehicle.

[0130] Through the above steps, the application realizes the automatic payment of the vehicle in different transaction scenarios. The server dynamically determines the most matched payment scenario and payment account according to the historical trajectory and current position of the vehicle, without the need for the vehicle owner to manually select and operate, thereby improving the convenience and intelligent level of payment. At the same time, the server combines the vehicle trajectory data and commercial network information to customize personalized payment scenario configuration for the vehicle, meeting the payment needs of the vehicle owner in different consumption scenarios.

[0131] In one possible implementation, calling the payment interface of the target designated payment account, combining the transaction amount in the payment request to complete the payment operation, and returning the payment result to the roadside unit, specifically includes steps S1061-S1063, and the above steps are as follows:

[0132] Step S1061: Use the target designated payment account and the transaction amount in the payment request to construct a payment instruction in a preset format.

[0133] In step S1061, the server first constructs a standardized payment instruction according to the type and attribute of the designated payment account. The payment instruction is a data packet in a preset format, which contains necessary information for initiating a payment request, such as payment account identification, transaction amount, transaction time, transaction serial number, etc. The server extracts the identification of the designated payment account (such as bank card number, account ID, etc.) from the target payment scenario file, and extracts the transaction amount from the original payment request, and assembles these information into a complete payment instruction according to the preset format and field.

[0134] Step S1062: digitally sign the payment instruction by a preset asymmetric encryption algorithm and a private key associated with the target specified payment account, to generate a signed payment instruction.

[0135] In step S1062, the server generates a digital signature for the payment instruction to ensure its authenticity and tamper resistance. The server first calls the private key associated with the specified payment account from the secure storage area of the system. The private key is the private key part of an asymmetric encryption algorithm (such as RSA, ECC, etc.) that appears in pairs with the public key of the specified payment account, used for digitally signing data. The server uses the private key and a preset signature algorithm (such as RSA-SHA256, ECDSA, etc.) to sign the payment instruction, generating a digital signature. Then, the server appends the digital signature to the end of the payment instruction, forming a signed payment instruction.

[0136] Step S1063: send the signed payment instruction to the third-party payment gateway to perform the deduction, and encapsulate the payment success code or failure status code returned by the third-party payment gateway into a payment result and send it to the roadside unit.

[0137] In step S1063, the server sends the signed payment instruction to the third-party payment gateway to request it to perform the actual fund deduction operation. The third-party payment gateway is an independent financial service platform, such as UnionPay, Alipay, WeChat Pay, etc., which provides standardized payment interfaces and secure and reliable fund clearing channels. The server establishes a secure connection with the payment gateway through a pre-configured API address and authentication information, and sends the signed payment instruction to the payment gateway. After receiving the instruction, the payment gateway first verifies the digital signature in the instruction to confirm its authenticity. Then, the payment gateway deducts the corresponding funds from the specified account according to the payment account identifier and transaction amount in the instruction, and returns the deduction result to the server.

[0138] After receiving the result returned by the payment gateway, the server encapsulates it into a standardized payment result object, which contains the state code of payment success or failure, transaction serial number, timestamp, etc. If the payment is successful, the state code is a preset success code (such as "0000"), indicating that the deduction has been completed; if the payment fails, the state code is a preset failure code (such as "9999"), indicating that the deduction has not been completed and may carry some error information. The server sends the encapsulated payment result object to the roadside unit that initiated the original payment request, notifying it of the final state of this payment. The roadside unit performs the corresponding subsequent operation according to the payment result, such as opening the parking lot gate, displaying a payment success prompt, etc.

[0139] For example, when the server determines that the payment request triggered by vehicle "VC_1001" at shopping mall A needs to use its associated bank card account "BC_1001" for payment, the server extracts the transaction amount "50.00" from the payment request and extracts the card number and cardholder name of the bank card account from the configuration file, and constructs a payment instruction: payment account: BC_1001; transaction amount: 50.00; transaction time: 2023-05-20 14:30:00; transaction serial number: TN20230520001.

[0140] Then, the server uses the RSA private key associated with the bank card "BC_1001" to digitally sign the payment instruction, obtains a signature string "SIG_20230520001", and attaches it to the payment instruction to form a signed payment instruction.

[0141] Next, the server sends the signed payment instruction to the payment gateway of UnionPay through the API interface provided by UnionPay. The payment gateway verifies the digital signature of the instruction and confirms that the instruction is valid, deducts 50.00 from the account "BC_1001", and returns the payment success code "0000" and the corresponding transaction serial number.

[0142] After receiving the return result of the payment gateway, the server encapsulates it into a payment result object: payment status: success; status code: 0000; transaction serial number: TN20230520001; timestamp: 2023-05-20 14:30:05.

[0143] Finally, the server sends the payment result object to the roadside unit of shopping mall A, notifying it that the payment of vehicle "VC_1001" has been completed. The roadside unit displays a payment success prompt and opens the parking lot gate to release the vehicle.

[0144] Reference Figure 3The application also provides a cloud payment device based on ETC extended application, which is a server, and the server comprises a payment request receiving module 301, a transaction determining module 302, a historical trajectory extracting module 303, a payment scenario file generating module 304 and a payment operation executing module 305, wherein: the payment request receiving module 301 is configured to receive a payment request sent by a road side unit deployed in a transaction scene; the transaction determining module 302 is configured to analyze and convert the payment request to obtain a static vehicle identifier and a static scene identifier corresponding to the current transaction; wherein the static vehicle identifier is used to identify the vehicle identity, and the static scene identifier is used to identify the transaction location; the historical trajectory extracting module 303 is configured to extract a historical trajectory data sequence associated with the static vehicle identifier from a preset vehicle trajectory database according to the static vehicle identifier, and the historical trajectory data sequence is composed of a plurality of position points arranged in time sequence; the payment scenario file generating module 304 is configured to generate a plurality of payment scenario files bound to the static vehicle identifier based on the historical trajectory data sequence; wherein one payment scenario file defines at least one geographic fence region as a trigger condition and a specified payment account corresponding to the trigger condition; a current trajectory data sequence is obtained, and a target payment scenario file corresponding to the current transaction is determined based on the current trajectory data sequence; and the payment operation executing module 305 is configured to extract a corresponding target specified payment account from the target payment scenario file, and call a payment interface of the target specified payment account to complete a payment operation in combination with a transaction amount in the payment request, and return a payment result to the road side unit.

[0145] In a possible implementation, the payment scenario file generating module 304 generates a plurality of payment scenario files bound to the static vehicle identifier based on the historical trajectory data sequence, specifically comprising: the payment scenario file generating module 304 performs a density clustering algorithm on the plurality of position points to identify a high-density stay point cluster with an overall density exceeding a preset overall density threshold; the payment scenario file generating module 304 extracts a central position coordinate of the high-density stay point cluster, and generates a circular geographic fence region with the central position coordinate as the center and a preset distance as the radius; the payment scenario file generating module 304 obtains POI information corresponding to a target position point in the high-density stay point cluster, and performs semantic analysis on the POI information to obtain a corresponding target semantic label; the payment scenario file generating module 304 determines a specified payment account matched with the target semantic label according to a preset mapping relationship; the payment scenario file generating module 304 associates each geographic fence region with the corresponding specified payment account to generate a payment scenario file, wherein the payment scenario file comprises the central position coordinate of the geographic fence region, the radius size and the account identifier of the corresponding specified payment account; and the payment scenario file generating module 304 binds and stores the generated plurality of payment scenario files to the static vehicle identifier.

[0146] In a possible implementation, the payment scenario file generation module 304 performs a density clustering algorithm on the plurality of location points, identifies a high-density stay point cluster with an overall density exceeding a preset overall density threshold, specifically including: the payment scenario file generation module 304 calculates a local density of a first location point, the local density being a number of second location points with a spatial distance less than a preset distance threshold from the first location point, the first location point and the second location point being any two location points in the plurality of location points; the payment scenario file generation module 304 identifies a set of continuous location points with a spatial position change less than a preset position threshold in a continuous time period in the historical trajectory data sequence, and accumulates a time length of the continuous time period, and determines the time length as a stay time length of each location point in the set of continuous location points; the payment scenario file generation module 304 marks a location point with a local density greater than a preset density threshold and a stay time length greater than a preset time length threshold as a core point; the payment scenario file generation module 304 creates a clustering cluster with a first core point as a center, and classifies a second core point falling within a preset circular region with the first core point as the center into the clustering cluster, the first core point and the second core point being any two core points in the plurality of core points; the payment scenario file generation module 304 performs a weighted average on local densities of all location points in each clustering cluster to obtain an overall density of the clustering cluster, and determines the clustering cluster as a high-density stay point cluster when the overall density is greater than a preset overall density threshold.

[0147] In a possible implementation, the payment scenario file generation module 304 obtains POI information corresponding to a target location point in the high-density stay point cluster, and performs semantic analysis on the POI information to obtain a corresponding target semantic label, specifically including: the payment scenario file generation module 304 takes the target location point as a query parameter, requests and obtains a plurality of pieces of POI information within a preset query radius with a center location coordinate as a center from a preset electronic map service, the POI information including a POI name attribute and a POI category attribute; the payment scenario file generation module 304 inputs the POI name attribute and the POI category attribute into a preset semantic analysis model, and generates a corresponding semantic label by the preset semantic analysis model; the payment scenario file generation module 304 counts frequencies of occurrence of each semantic label, and determines a semantic label with the highest frequency of occurrence as the target semantic label.

[0148] In a possible implementation, the payment scenario file generation module 304 determines the target payment scenario file corresponding to the current transaction based on the current trajectory data sequence, specifically including: the payment scenario file generation module 304 takes the starting position point of the current trajectory data sequence as the basis for judgment, and performs traversal matching in the plurality of payment scenario files; the payment scenario file generation module 304 judges whether the starting position point falls within the target geographic fence area defined by the first payment scenario file, and the first payment scenario file is any one of the plurality of payment scenario files; and the payment scenario file generation module 304 determines that the first payment scenario file is the target payment scenario file if it is determined that the starting position point falls within the target geographic fence area defined by the first payment scenario file.

[0149] In a possible implementation, before the payment scenario file generation module 304 determines that the first payment scenario file is the target payment scenario file, the method further includes: the payment scenario file generation module 304 judges whether there are a plurality of first payment scenario files; the payment scenario file generation module 304 extracts parameters of the first payment scenario file if it is determined that there are a plurality of first payment scenario files, the parameters including the radius size of the first geographic fence area corresponding to the first payment scenario file, the distance between the center position coordinates of the first geographic fence area and the starting position point, and the historical calling frequency and generation timestamp of the first payment scenario file; the payment scenario file generation module 304 determines the comprehensive weight corresponding to the first payment scenario file based on the parameters, and selects the first payment scenario file with the maximum comprehensive weight as the target payment scenario file.

[0150] In a possible implementation, the payment operation execution module 305 calls the payment interface of the target specified payment account, combines the transaction amount in the payment request, completes the payment operation, and returns the payment result to the road side unit, specifically including: the payment operation execution module 305 uses the target specified payment account and the transaction amount in the payment request to construct a payment instruction in a preset format; the payment operation execution module 305 generates a signed payment instruction by performing digital signature on the payment instruction through a preset asymmetric encryption algorithm and a private key associated with the target specified payment account; the payment operation execution module 305 sends the signed payment instruction to the third-party payment gateway to perform the deduction, and encapsulates the payment success code or failure status code returned by the third-party payment gateway into a payment result and sends it to the road side unit.

[0151] It should be noted that the apparatus provided in the above examples is only used as an example for the division of the above functional modules in realizing its functions, and in actual application, the above functions can be completed by different functional modules according to the needs, that is, the internal structure of the device is divided into different functional modules to complete all or part of the above described functions. In addition, the apparatus and method embodiments provided in the above examples belong to the same concept, and the specific implementation process is detailed in the method embodiments, which will not be described here.

[0152] The present application also provides an electronic device. Referring to Figure 4 , Figure 4 is a structural schematic diagram of an electronic device provided by an embodiment of the present application. The electronic device 400 can include at least one processor 401, at least one network interface 404, a user interface 403, a memory 405, and at least one communication bus 402.

[0153] The communication bus 402 is used to realize the connection and communication between the components.

[0154] The user interface 403 can include a display screen (Display) and a camera (Camera). Optionally, the user interface 403 can also include a standard wired interface and a wireless interface.

[0155] The network interface 404 can optionally include a standard wired interface and a wireless interface (such as a Wi-Fi interface).

[0156] The processor 401 can include one or more processing cores. The processor 401 connects various parts within the server through various interfaces and lines, performs various functions of the server and processes data by running or executing instructions, programs, code sets or instruction sets stored in the memory 405, and calling data stored in the memory 405. Alternatively, the processor 401 can be implemented in at least one of a hardware form of a digital signal processing (DSP), a field-programmable gate array (FPGA), and a programmable logic array (PLA). The processor 401 can integrate a combination of one or more of a central processing unit (CPU), a graphics processing unit (GPU), and a modem. Among them, the CPU mainly processes operating systems, user interfaces, and application programs; the GPU is responsible for rendering and drawing the content to be displayed on the display screen; and the modem is used for processing wireless communication. It can be understood that the above-mentioned modem can also not be integrated into the processor 401, but can be realized by a separate chip.

[0157] The memory 405 can include a random access memory (RAM) and a read-only memory (ROM). Alternatively, the memory 405 includes a non-transitory computer-readable storage medium. The memory 405 can be used to store instructions, programs, codes, code sets or instruction sets. The memory 405 can include a program storage area and a data storage area, wherein the program storage area can store instructions for implementing an operating system, instructions for at least one function (such as a touch function, a sound playing function, an image playing function, etc.), instructions for implementing the above-mentioned various method embodiments, etc.; the data storage area can store data involved in the above-mentioned various method embodiments, etc. The memory 405 can alternatively be at least one storage device located away from the aforementioned processor 401. Referring to Figure 4 The memory 405 as a computer storage medium can include an operating system, a network communication module, a user interface module, and an application program of the cloud payment method based on the ETC expansion application.

[0158] In Figure 4In the illustrated electronic device 400, the user interface 403 is mainly used to provide an input interface for the user and to acquire user input data; while the processor 401 can be used to call the application stored in the memory 405 for cloud payment methods based on ETC extended applications. When executed by one or more processors 401, the electronic device 400 performs one or more of the methods described in the above embodiments. It should be noted that, for the foregoing method embodiments, for the sake of simplicity, they are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, because according to this application, some steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also understand that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0159] This application also provides a computer-readable storage medium storing instructions. When executed by one or more processors 401, these instructions cause the electronic device 400 to perform one or more of the methods described in the above embodiments.

[0160] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

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

[0162] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

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

[0164] The integrated unit, if implemented in the form of a software function unit and sold or used as an independent product, can be stored in a computer readable memory. Based on such understanding, the technical solutions of the present application essentially or say the part that contributes to the prior art or the whole or part of the technical solutions can be embodied in the form of a software product. The computer software product is stored in a memory and includes a plurality of instructions for causing a computer device (which can be a personal computer, a server or a network device, etc.) to execute all or part of the steps of the embodiments of the present application. The aforementioned memory includes: a U disk, a mobile hard disk, a magnetic disk or an optical disk, and various media that can store program codes.

[0165] The above is only exemplary embodiments of the present disclosure, which cannot limit the scope of the present disclosure. That is, any equivalent changes and modifications made in accordance with the teachings of the present disclosure are still within the scope of the present disclosure. Other embodiments of the present disclosure will be readily apparent to those skilled in the art upon considering the specification and the practical true disclosure.

[0166] The present application is intended to cover any variations, uses, or adaptive changes of the present disclosure that follow the general principles of the present disclosure and include common knowledge or conventional technical means in the technical field not recorded in the present disclosure. The specification and examples are only considered as exemplary, and the scope and spirit of the present disclosure are defined by the claims.

Claims

1. A cloud payment method based on ETC extended application, characterized in that, The method comprises: receiving a payment request sent by a roadside unit deployed in a transaction scene; parsing the payment request to obtain a static vehicle identifier and a static scene identifier corresponding to the current transaction; wherein the static vehicle identifier is used to identify the vehicle identity, and the static scene identifier is used to identify the transaction location; According to the static vehicle identifier, from the preset vehicle trajectory database, extract the historical trajectory data sequence associated with the static vehicle identifier, the historical trajectory data sequence is composed of a plurality of position points arranged in time sequence; Based on the historical trajectory data sequence, a plurality of payment scenario files bound to the static vehicle identifier are generated; wherein one payment scenario file defines at least one geographic fence area as a trigger condition and a specified payment account corresponding to the trigger condition; Obtain the current trajectory data sequence, and determine the target payment scenario file corresponding to the current transaction based on the current trajectory data sequence; From the target payment scenario file, the corresponding target specified payment account is extracted, and the payment interface of the target specified payment account is called, combined with the transaction amount in the payment request, the payment operation is completed, and the payment result is returned to the roadside unit; The method comprises: Performing density clustering algorithm on a plurality of position points to identify high-density stay point clusters with overall density exceeding a preset overall density threshold; Extract the center position coordinates of the high-density stay point cluster, and generate a circular geographic fence area with the center position coordinates as the center and a preset distance as the radius; Obtain the POI information corresponding to the target position point in the high-density stay point cluster, and perform semantic analysis on the POI information to obtain the corresponding target semantic label; According to a preset mapping relationship, determine the specified payment account matched with the target semantic label; Associate each geographic fence area with the corresponding specified payment account to generate the payment scenario file, which includes the center position coordinates, radius size of the geographic fence area, and account identifier of the corresponding specified payment account; Bind and store the generated plurality of payment scenario files with the static vehicle identifier; The method comprises: Calculate the local density of a first position point, the local density being the number of second position points with a spatial distance less than a preset distance threshold from the first position point, the first position point and the second position point being any two position points in the plurality of position points; Identify a set of continuous position points in the historical trajectory data sequence with spatial position change less than a preset position threshold within a continuous time period, and accumulate the duration of the continuous time period, and determine the duration as the stay duration of each position point in the set of continuous position points; Mark the position points with local density greater than a preset density threshold and stay duration greater than a preset duration threshold as core points; create a cluster with the first core point as the center, and attribute a second core point falling within a preset circular region with the first core point as the center to the cluster, the first core point and the second core point being any two of the core points; perform a weighted average on local densities of all position points in each cluster to obtain an overall density of the cluster, and determine the cluster as a high-density stay point cluster when the overall density is greater than a preset overall density threshold.

2. The method of claim 1, wherein, The method further comprises: obtaining POI information corresponding to the target position point, and performing semantic analysis on the POI information to obtain a corresponding target semantic label, specifically comprising: taking the target position point as a query parameter, requesting and obtaining a plurality of pieces of POI information within a preset query radius with the center position coordinate as the center from a preset electronic map service, the POI information including a POI name attribute and a POI category attribute; inputting the POI name attribute and the POI category attribute into a preset semantic analysis model to generate a corresponding semantic label by the preset semantic analysis model; 3. The method of claim 1, wherein, counting the occurrence frequencies of each semantic label, and determining the semantic label with the highest occurrence frequency as the target semantic label. The method further comprises: taking a starting position point of the current trajectory data sequence as a judgment basis, and performing traversal matching in a plurality of payment scenario files; judging whether the starting position point falls within a target geofence region defined by a first payment scenario file, the first payment scenario file being any one of the payment scenario files; 4. The method of claim 3, wherein, if it is determined that the starting position point falls within the target geofence region defined by the first payment scenario file, determining the first payment scenario file as the target payment scenario file. Before determining the first payment scenario file as the target payment scenario file, the method further comprises: judging whether there are a plurality of first payment scenario files; if it is determined that there are a plurality of first payment scenario files, extracting parameters of the first payment scenario file, the parameters including a radius size of a first geofence region corresponding to the first payment scenario file, a distance between a center position coordinate of the first geofence region and the starting position point, and a historical calling frequency and a generation timestamp of the first payment scenario file; 5. The method of claim 1, wherein, based on the parameters, determining a comprehensive weight corresponding to the first payment scenario file, and selecting the first payment scenario file with the maximum comprehensive weight as the target payment scenario file. The method further comprises: using the target specified payment account and the transaction amount in the payment request to construct a payment instruction in a preset format; using the target specified payment account and the transaction amount in the payment request to construct a payment instruction in a preset format; The payment instruction is digitally signed by a preset asymmetric encryption algorithm and a private key associated with the target designated payment account, to generate a signed payment instruction; The signed payment instruction is sent to a third-party payment gateway to perform a deduction, and a payment success code or a failure status code returned by the third-party payment gateway is encapsulated into the payment result and sent to the road side unit.

6. A cloud payment device based on ETC extended application, characterized in that, The device is used to execute the method of any one of claims 1-5, and the device comprises a payment request receiving module (301), a transaction determining module (302), a historical trajectory extracting module (303), a payment scenario file generating module (304), and a payment operation executing module (305), wherein: The payment request receiving module (301) is configured to receive a payment request sent by a road side unit deployed in a transaction scenario. The transaction determining module (302) is configured to analyze and convert the payment request to obtain a static vehicle identifier and a static scenario identifier corresponding to a current transaction; wherein the static vehicle identifier is used to identify a vehicle identity, and the static scenario identifier is used to identify a transaction location. The historical trajectory extracting module (303) is configured to extract a historical trajectory data sequence associated with the static vehicle identifier from a preset vehicle trajectory database according to the static vehicle identifier, wherein the historical trajectory data sequence is composed of a plurality of position points arranged in time sequence. The payment scenario file generating module (304) is configured to generate a plurality of payment scenario files bound to the static vehicle identifier based on the historical trajectory data sequence; wherein one payment scenario file defines at least one geographic fence region as a trigger condition and one designated payment account corresponding to the trigger condition; a current trajectory data sequence is obtained, and a target payment scenario file corresponding to the current transaction is determined based on the current trajectory data sequence. The payment operation executing module (305) is configured to extract a corresponding target designated payment account from the target payment scenario file, and call a payment interface of the target designated payment account to complete a payment operation in combination with a transaction amount in the payment request, and return a payment result to the road side unit.

7. An electronic device, comprising: The electronic device (400) comprises a processor (401), a memory (405), a user interface (403), and a network interface (404), the memory (405) is configured to store instructions, the user interface (403) and the network interface (404) are configured to communicate with other devices, and the processor (401) is configured to execute the instructions stored in the memory (405) to enable the electronic device (400) to execute the method of any one of claims 1-5.

8. A computer-readable storage medium, characterized in that, The computer readable storage medium stores instructions, when the instructions are executed, the method of any one of claims 1-5 is executed.

Images