Contract approval method for highway data circulation based on multi-party countersigning and fine-grained authorization

Abstract

This application provides a method for approving highway data circulation contracts based on multi-party countersigning and fine-grained authorization, belonging to the field of contract approval technology. This application obtains the equity relationship diagram, network information, and authorization applications of the applicant entities. Based on equity and network domains, it groups these entities into target entity groups and splices road segments to obtain a road network map. If the union of data types in a certain time period meets specific conditions, the applications are merged into a joint application. Subsequently, using the road network map and the union of data types as the fine-grained authorization boundary, the application is submitted to the data provider for multi-party countersigning review and authorization contract generation. This invention solves the problems of insufficient overall security risk assessment capability and poor data security protection in existing technologies when multiple entities are authorized, significantly improving the security of data circulation.

Description

Technical Field

[0001] This application belongs to the field of contract approval technology, and in particular relates to a method for approving highway data circulation contracts based on multi-party countersigning and fine-grained authorization. Background Technology

[0002] Highway data encompasses multiple dimensions, including road conditions, vehicle traffic records, and accident information, serving as a crucial data element supporting intelligent traffic management, logistics scheduling optimization, and traffic safety risk assessment. With the deepening of data element market-oriented reforms, the demand for highway data circulation continues to grow, making the establishment of a secure and compliant authorization and approval mechanism an urgent need in the field of data governance. A highway data circulation contract approval method based on multi-party co-signature and fine-grained authorization, through precise definition of the data authorization scope and collaborative management of multiple applicants, has broad application prospects in scenarios such as smart city infrastructure construction, autonomous driving data services, and integrated transportation big data platforms.

[0003] In the existing technology, existing data sharing platforms typically focus on the qualification of the applicant and the review of the purpose of use, and establish a standardized case-by-case approval process, in which the data provider conducts an independent legality assessment of each application in accordance with compliance guidelines.

[0004] However, the aforementioned existing technical solutions struggle to conduct a comprehensive risk assessment of multiple applicants. The existing approval mechanisms lack the ability to effectively perceive the data security risks arising from the overall authorization applications, preventing data providers from setting reasonable authorization boundaries. Therefore, existing technologies suffer from insufficient capability to assess overall security risks in multi-entity authorization scenarios, resulting in data security protection effects that fail to meet practical needs. Summary of the Invention

[0005] The purpose of this application is to provide a method, system, and electronic device for approving highway data circulation contracts based on multi-party countersigning and fine-grained authorization, so as to solve the technical problem that the existing technology is insufficient in the overall security risk assessment capability in multi-entity authorization scenarios, resulting in the data security protection effect being difficult to meet actual needs.

[0006] To address the aforementioned technical problems, in a first aspect, this application provides a method for approving highway data circulation contracts based on multi-party countersigning and fine-grained authorization, comprising: Obtain the equity relationship diagram among multiple applicant entities, as well as the network transmission information and authorization application of each applicant entity. The authorization application includes highway data types and road segment ranges for different authorization periods. The highway data types include at least one of road condition data types, vehicle data types, and accident data types. Based on the equity association diagram, all applicants corresponding to nodes that have a connection path to the same node are grouped into the first subject group. Network affiliation analysis is performed on the network transmission information. Applicants belonging to the same network domain are grouped into the second subject group and then combined with the first subject group to form the target subject group. Based on the connectivity of the highway network, the road segment ranges of each applicant in the target subject group are spliced ​​together to obtain the road network map; Based on the road segment range associated with the authorization applications in the road network map, determine the union of data types for the same authorization period. When the union of data types includes road condition data type, vehicle data type, and accident data type, merge all authorization applications associated with the target subject group into a joint application. The fine-grained authorization boundary is the union of the road segment range and data type of the road network map. The fine-grained authorization boundary and the joint application are submitted to the data provider for initiating a multi-party review. After all data providers have signed the joint application based on fine-grained licensing boundaries, licensing agreements are generated for each applicant entity within the target entity group.

[0007] In one feasible implementation, before stitching together the road network map of each applicant in the target subject group according to the connectivity of the highway network, the method further includes: Retrieve the API call records initiated by each of the multiple applicant entities within a preset time period before the current authorization application submission time. The API call records include the API call timestamp of each applicant entity. The timestamps of each applicant's API call are assigned to corresponding time slots at preset time intervals to obtain the call time slot distribution for each applicant. The call time grid distribution of any two applicants among multiple applicants is compared grid by grid. The number of time grids in which both applicants have interface call records in the same time grid is counted. The total number of time grids of the applicant with the smaller total number of time grids is recorded as the base total number of time grids. The ratio of the number of time grids to the base total number of time grids is calculated to obtain the call synchronization ratio between any two applicants. Requesting entities whose synchronization ratio is greater than the preset synchronization ratio threshold are grouped into a third entity group, and the third entity group is merged into the target entity group.

[0008] In one feasible implementation, the method further includes: Get the target road segment range in the authorization applications of any two applicants whose synchronization ratio is greater than a preset synchronization ratio threshold; Based on the connectivity of the highway network, determine whether there are adjacent road segments on the highway network for the two target road segments. If there are adjacent road segments, merge the applicants corresponding to the two target road segments into the third subject group.

[0009] In one feasible implementation, the equity relationship graph uses each applicant as a node and the equity holding relationship between the applicants as directed edges, with the direction of the directed edges pointing from the held entity to the holding entity. Based on the equity relationship diagram, all applicant entities corresponding to nodes that have a connection path to the same node are grouped into the first entity group, including: Starting from each node in the equity relationship graph, determine each node that directly or indirectly holds shares along the directed edge direction to obtain the control chain of each node; Place the applicant corresponding to the starting node of any two holding links that have a common node into the first subject group.

[0010] In one feasible implementation, the network transmission information includes the data access address and data return address of each applicant entity; Network attribution analysis is performed on network transmission information. Applicants belonging to the same network domain are grouped into a second subject group, which is then combined with the first subject group to form a target subject group, including: The data access address and data return address of each applicant are compared with the address range corresponding to each network domain preset in the platform; Applicants whose data access address and data return address both fall within the same address range are placed in the second subject group; Combine the first subject group and the second subject group into the target subject group.

[0011] In one feasible implementation, the fine-grained authorization boundary is the union of the road segment range and data type of the road network map, including: Extract highway data types from the authorized applications of each applicant within the target subject group; By combining the highway data type with the road segment range and authorization time period of the corresponding authorization application, a single authorization entry is obtained. The single authorization entry includes the road segment range and highway data type corresponding to different authorization time periods accessible to the applicant. The individual authorization entries of all applicants within the target subject group are aggregated into an authorization entry set, and the road segment range and highway data type corresponding to all authorization time periods in the authorization entry set are used as fine-grained authorization boundaries.

[0012] In one feasible implementation, fine-grained authorization boundaries and joint applications are submitted to the data provider for initiating multi-party review, including: The joint application and fine-grained authorization boundaries are sent to each data provider simultaneously. Each data provider will identify the road segments that exist simultaneously in the fine-grained authorization boundaries and the road segments they hold as the review segments. The types of highway data and authorization periods corresponding to the review segments in the fine-grained authorization boundaries will be identified as the review scope for each data provider. Each data provider will compare the types of highway data and authorized time periods in the scope to be reviewed with the range of highway data types and authorized time periods of the data they hold. When all highway data types within the scope of review are within the range of highway data types provided by the corresponding data provider and all authorized time periods are within the range of authorized time periods provided by the corresponding data provider, the data provider returns a signature confirmation for the joint application to the platform and writes the signature confirmation and signature timestamp to the blockchain audit log. Otherwise, the data provider returns a signature rejection to the platform and writes it to the blockchain audit log. Signature rejection includes authorized time periods that exceed the range of authorized time periods and highway data types that exceed the range of highway data types.

[0013] In one feasible implementation, after all data providers have completed signing the joint application based on fine-grained licensing boundaries, a licensing agreement is generated for each applicant entity within the target entity group, including: When any data provider returns a sign rejection, the authorization contracts of all applicants within the target subject group are frozen, and the frozen status and sign rejection are written to the blockchain audit log. After all data providers return signed confirmations, a separate authorization contract is generated for each applicant within the target subject group, based on a single authorization entry for each applicant.

[0014] Secondly, this application provides a highway data circulation contract approval system based on multi-party countersigning and fine-grained authorization, including: The acquisition module is used to acquire the equity relationship diagram among multiple applicant entities, as well as the network transmission information and authorization application of each applicant entity. The authorization application includes highway data types and road segment ranges for different authorization periods. The highway data types include at least one of road condition data types, vehicle data types, and accident data types. The merging module is used to merge applicants corresponding to all nodes that have a connection path to the same node into a first subject group based on the equity relationship diagram. The network transmission information is analyzed for network affiliation, and applicants belonging to the same network domain are merged into a second subject group and then merged with the first subject group into a target subject group. The splicing module is used to splice the road segment ranges of each applicant in the target subject group to obtain a road network map according to the connectivity of the road network. The merging module is also used to determine the union of data types for the same authorization period based on the authorization applications associated with the road segment range of the road network map. When the union of data types includes road condition data types, vehicle data types, and accident data types, all authorization applications associated with the target subject group are merged into a joint application. The review module is used to submit the fine-grained authorization boundary and joint application to the data provider for initiating a multi-party review by using the union of road segment range and data type of the road network map as the fine-grained authorization boundary. The review module is also used to generate authorization contracts for each applicant entity within the target entity group after all data providers have completed signing the joint application based on fine-grained authorization boundaries.

[0015] Thirdly, this application provides an electronic device, comprising: Memory, used to store computer programs; A processor, used to execute a computer program to implement the steps of the highway data circulation contract approval method based on multi-party countersigning and fine-grained authorization as described in the first aspect above.

[0016] This application provides a method for approving highway data circulation contracts based on multi-party co-signature and fine-grained authorization. Addressing the technical problem in existing compliance approval mechanisms that use a single applicant as the evaluation unit and fail to identify the overall data security risks arising from the dispersed applications of multiple related applicants, this application identifies applicants from multiple dimensions, including equity association, network affiliation, interface call synchronization, and road segment spatial connectivity. Multiple applicants with implicit relationships are grouped into a target group, which is then used as a unified evaluation unit for aggregate risk assessment. Fine-grained authorization boundaries are constructed using the union of road network map segment ranges and data types. Review is completed through a multi-party co-signature mechanism, generating corresponding authorization contracts for each applicant, forming a complete closed-loop approval process from association identification and aggregate risk assessment to contract generation. This method effectively fills the data security blind spot created by existing technologies that use dispersed applications to circumvent overall compliance review, significantly improving the overall security risk assessment capability in multi-entity authorization scenarios.

[0017] This application further identifies the behavioral collaboration relationships between applicant entities through interface call record analysis, identifying the coordinated operation relationships between applicant entities at the behavioral level. This supplements the shortcomings of relying solely on equity structure and network infrastructure information for association judgment, further improving the completeness of target entity group identification, enhancing the accuracy of overall aggregation risk assessment, and effectively improving data security protection. Attached Figure Description

[0018] To more clearly illustrate the technical solutions of the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 A flowchart illustrating a highway data circulation contract approval method based on multi-party countersigning and fine-grained authorization, provided for embodiments of this application; Figure 2 This application provides a schematic diagram of an equity relationship structure. Figure 3 A schematic diagram of a multi-party review process is provided for embodiments of this application; Figure 4 A schematic diagram of the structure of a highway data circulation contract approval system based on multi-party countersigning and fine-grained authorization, provided for an embodiment of this application; Figure 5 This is a schematic diagram of the hardware structure of an electronic device provided in one embodiment of this application. Detailed Implementation

[0020] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments. Obviously, the described embodiments are merely some embodiments of the present application, and not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0021] To address the problems of existing technologies, embodiments of this application provide a method, apparatus, device, and computer storage medium for approving highway data circulation contracts based on multi-party countersigning and fine-grained authorization. The method for approving highway data circulation contracts based on multi-party countersigning and fine-grained authorization provided in this application embodiment will be described below first.

[0022] Figure 1 This illustration shows a flowchart of a highway data circulation contract approval method based on multi-party countersigning and fine-grained authorization, according to an embodiment of this application. Figure 1 As shown, S110. Obtain the equity relationship diagram among multiple applicant entities, as well as the network transmission information and authorization application of each applicant entity. The authorization application includes highway data types and road segment ranges for different authorization periods. The highway data types include at least one of road condition data types, vehicle data types, and accident data types.

[0023] When the platform receives an authorization application from the applicant, it collects three key types of information: equity relationship diagram, network transmission information, and authorization application, to support subsequent relationship identification and aggregation risk assessment.

[0024] The equity relationship graph is a directed graph constructed using the applicant and its related controlling entities within the equity system as nodes, and the equity holding relationships between two entities as directed edges. The direction of the directed edges points from the entity being held to the holding entity; that is, if entity A is held by entity B, the directed edge points from A to B. The equity relationship graph is stored within the platform system as a directed graph data structure, specifically containing two parts: a node set and a directed edge set. The node set records all applicants participating in this authorization application and the controlling entities appearing in the equity chain; the directed edge set records each pair of entities with a direct equity holding relationship and its direction.

[0025] Figure 2 This illustration shows a schematic diagram of an equity relationship diagram provided in one embodiment of this application.

[0026] like Figure 2 As shown, A1, A2, A3, A4, I1, and I2 represent the applicant entities, H1, H2, and H3 represent the controlling entities associated with the applicant entities, directed edges point from the held entities to the holding entities, and isolated nodes without directed edges represent applicant entities without equity association.

[0027] Figure 2 The example of an equity relationship graph is shown. The specific data content of the equity relationship graph is as follows: the node set V contains 9 nodes: H1, H2, H3, A1, A2, A3, A4, I1, and I2; the directed edge set E contains five directed edges: (A1, H2), (A2, H2), (H2, H1), (A3, H3), and (H3, H1), where the ordered pair (v, u) indicates that v is directly held by u, and the directed edge arrow points from v to u. Nodes A4, I1, and I2 are isolated nodes with no directed edge connections, representing applicants without equity relationships with other nodes. The platform obtains the above edge set data by connecting to external data sources such as enterprise registration information databases or equity information disclosure platforms.

[0028] The network transmission information consists of two data items: the first is the data access address, which is the IP address used by the applicant when obtaining authorized highway data; the second is the data return address, which is the target IP address when the highway data is returned to the applicant's system. Both addresses are represented in IPv4 dotted decimal format. Taking this embodiment as an example, the data access address for A1 is 192.168.ab.15, for A2 it is 192.168.ab.23, for A3 it is 192.168.ab.31, and for A4 it is 192.168.ab.42. In these addresses, 'ab' represents the same set of numbers, indicating that the four belong to the same subnet. The data access address for applicant I1 is 10.cd.ef.17, which belongs to a different address range than A1 to A4. These two address information items are filled in by the applicant when submitting the authorization application, or are automatically collected by the platform through network detection methods.

[0029] An authorization application is a data use application submitted by the applicant, which includes the following three specific contents: Highway data type, that is, the type of data to be accessed in this application, which can be selected from at least one of the following: road condition data type, vehicle data type, and accident data type; Road segment range, that is, the set of highway segment numbers to be accessed in this application; Authorization period, that is, the time interval for accessing the data, which is represented by the start and end timestamps, hereinafter referred to as T1.

[0030] The content of the traffic condition data type is the real-time or historical traffic status information of the road segment, specifically including fields such as vehicle speed, traffic flow, and road congestion index. Each record consists of a road segment number, timestamp, and status value. The content of the vehicle data type is the passage record of a specific type of vehicle on a designated road segment. Each record includes a road segment number, vehicle type, and passage timestamp. The content of the accident data type is the traffic accident record that occurred on a designated road segment, including fields such as road segment number, accident time, accident type, and accident severity.

[0031] Taking this embodiment as an example, the authorized application content of each applicant is as follows: A1 applies for road condition data type, with road segments R1 and R2, and authorized time period T1; A2 applies for vehicle data type, with road segments R3 and R4, and authorized time period T1; A3 applies for accident data type, with road segments R5 and R6, and authorized time period T1; A4 applies for road condition data type, with road segment R7, and authorized time period T1; I1 applies for road condition data type, with road segment R8, and authorized time period T1.

[0032] S120. Based on the equity association diagram, all applicant entities corresponding to nodes that have a connection path with the same node are grouped into the first entity group. Network affiliation analysis is performed on the network transmission information. Applicants belonging to the same network domain are grouped into the second entity group and then combined with the first entity group to form the target entity group.

[0033] Step S120 identifies related applicants from two dimensions: equity association and network affiliation, and groups them into target entity groups.

[0034] In one feasible implementation, the equity relationship graph uses each applicant entity as a node and the equity holding relationships between the applicant entities as directed edges, with the direction of the directed edges pointing from the held entity to the holding entity.

[0035] Based on the equity association graph, the applicants corresponding to all nodes that have a connection path with the same node are grouped into the first subject group, including: taking each node in the equity association graph as the starting point, determining each node that directly or indirectly holds shares along the directed edge direction to obtain the control link of each node; and placing the applicants corresponding to the starting node of any two control links that have a common node into the first subject group.

[0036] Starting from each applicant node in the equity relationship graph, visit each direct shareholding node and indirect shareholding node in sequence along the directed edge direction, record the node sequence from the starting point to each reachable node, and obtain the holding link of the applicant node; take the intersection of the node sets traversed by the holding links of any two applicant nodes, and if the intersection is not empty, put the two applicants into the first subject group.

[0037] The control link traversal is implemented using a breadth-first search algorithm, a well-known graph traversal algorithm in the industry, which visits adjacent nodes level by level until no more nodes are reachable. Figure 2 Taking the equity relationship diagram in the figure as an example, the traversal results of each applicant entity are as follows.

[0038] BFS traversal of A1: Starting from A1, follow... Figure 1 In the first layer, A1 accesses H2 via the directed edge pointing to H2, and then accesses H1 via the directed edge from H2 to H1 (second layer). H1 has no outgoing edges, so the traversal ends. The controlling link of A1 passes through H2 and H1 in sequence, and the set of nodes passed through is {H2, H1}.

[0039] BFS traversal of A2: Starting from A2, visit H2 along the directed edge from A2 to H2, and then visit H1 along the directed edge from H2 to H1. The traversal ends. The holding link of A2 also passes through H2 and H1, and the set of nodes passed through is {H2, H1}.

[0040] BFS traversal of A3: Starting from A3, proceed along... Figure 1 The directed edge from A3 to H3 visits H3 (first layer), and then the directed edge from H3 to H1 visits H1 (second layer). H1 has no outgoing edges, so the traversal ends. The controlling link of A3 passes through H3 and H1, and the set of nodes passed through is {H3, H1}.

[0041] BFS traversal of A4: A4 in Figure 1 A4 is an isolated node with no outgoing edges, and the traversal ends there; the set of nodes visited by A4 is empty. I1 and I2 are both isolated nodes, and the set of nodes visited by them is empty.

[0042] For each applicant's set of nodes, take the intersection of each pair of nodes and determine: The intersection of {H2, H1} of A1 and {H2, H1} of A2 is {H2, H1}, which is non-empty; therefore, A1 and A2 are merged. The intersection of {H2, H1} of A1 and {H3, H1} of A3 is {H1}, which is non-empty; therefore, A3 is also merged into the same group, even though the nearest public holding node between A1 and A3 is H1 instead of H2, the intersection is still non-empty, thus satisfying the merge condition. The intersection of {H2, H1} of A2 and {H3, H1} of A3 is also {H1}, which is non-empty; therefore, A2 and A3 are merged. The intersection of the empty set of A4 with any set is empty; therefore, A4 is not merged. The same applies to I1 and I2. Therefore, the first group of applicants is {A1, A2, A3}.

[0043] The above results reveal the core logic of the holding link algorithm: A1 and A2 are identified as related entities because they share H2; although A1 / A2 and A3 only share H1, they still meet the condition of having a common node. The three are uniformly grouped into the first entity group, thereby identifying the group of related applicant entities that are indirectly held by the same top-level holding entity through different intermediate-level holding entities.

[0044] In one feasible implementation, the network transmission information includes the data access address and data return address of each applicant.

[0045] Network attribution analysis is performed on network transmission information. Applicants belonging to the same network domain are grouped into a second subject group, which is then combined with the first subject group to form a target subject group. This includes: comparing the data access address and data return address of each applicant with the address range corresponding to each network domain preset in the platform; placing applicants whose data access address and data return address both fall within the same address range into the second subject group; and merging the first subject group and the second subject group into the target subject group.

[0046] The data access address and data return address of each applicant are compared with the address range corresponding to each network domain preset in the platform; applicants whose data access address and data return address both fall within the same address range are placed into the second subject group; the first subject group and the second subject group are combined to obtain the target subject group.

[0047] A network domain refers to an IP address space uniformly managed by the same organization, represented in Classless Inter-Domain Routing (CIDR) format. The determination method involves performing a bitwise logical AND operation between the applicant's IP address and the subnet mask of the network domain. If the result equals the network address of the network domain, then the IP address is determined to belong to that network domain. The platform pre-maintains a network domain address range registry, recording the known address ranges of each network domain. For example, the address range of ND01 is 192.168.ab.0 / 24, corresponding to a subnet mask of 255.255.255.0. During network affiliation analysis, the platform sequentially performs bitwise AND operations on the data access address and data return address of each applicant against the address ranges of each network domain in the registry.

[0048] Taking this embodiment as an example, a bitwise AND operation is performed on the data access address 192.168.ab.15 of A1 and the subnet mask 255.255.255.0, resulting in 192.168.ab.0, which is equal to the network address of ND01. Therefore, A1 belongs to ND01. The same operation is performed on A2 (192.168.ab.23), A3 (192.168.ab.31), and A4 (192.168.ab.42), and the result is 192.168.ab.0. All four belong to the ND01 address range and are grouped into the second subject group {A1, A2, A3, A4}. The data access address 10.cd.ef.17 of the applicant I1 does not match the address range of each network domain in the registry, and I1 is not included in the second subject group. The target subject group {A1, A2, A3} is obtained by taking the union of the first subject group {A1, A2, A3, A4} and the second subject group {A1, A2, A3, A4}.

[0049] In the aforementioned platform scenario, equity association analysis identified the legal entity-level associations of A1, A2, and A3, while network affiliation analysis further identified the technical-level association of A4 sharing the same network domain with A1, A2, and A3. The formation of the target entity group {A1, A2, A3, A4} achieves a holistic merging of related applications distributed across different brand entities, compensating for the blind spot in the case-by-case review mechanism regarding the risk of cross-business line distributed data mosaics.

[0050] In one feasible implementation, before stitching together the road network map of each applicant in the target subject group according to the connectivity of the highway network, the method further includes: The system retrieves the API call records initiated by each applicant within a preset time period before the current authorization application submission time from multiple applicant entities. These API call records include the API call timestamp for each applicant entity. The system then assigns each applicant entity's API call timestamp to a corresponding time grid according to a preset time interval, resulting in a call time grid distribution for each applicant entity. The system compares the call time grid distributions of any two applicant entities, counting the number of time grids in which both applicant entities have API call records within the same time grid. The system designates the applicant entity with the smaller total number of time grids as the baseline total number of time grids, and calculates the ratio of this ratio to the baseline total number of time grids, obtaining the call synchronization ratio between any two applicant entities. Applicants with a call synchronization ratio greater than a preset synchronization ratio threshold are grouped into a third entity group, and this third entity group is then merged into the target entity group.

[0051] For applicants not yet included in the target entity group, the time synchronization of their interface call behavior with existing members of the target entity group is analyzed to identify potential related entities not discovered in the equity and network dimensions. The process is as follows: First, the platform retrieves all API call records initiated by each applicant within a preset time period from the API access logs. Each record includes the applicant's identifier and the API call timestamp. The preset time period is the historical time window for the platform's backtracking analysis, taking the past 30 days as an example; the specific value can be adjusted according to the platform's sensitivity requirements.

[0052] Second, the platform categorizes all API call timestamps for each applicant into corresponding time cells according to preset time intervals, thus obtaining the call time cell distribution for each applicant. A time cell is a unit of time obtained by equally dividing the time axis according to preset time intervals. Taking one hour as an example, each time cell corresponds to a one-hour time interval. If an applicant has at least one API call timestamp within the one-hour interval covered by a time cell, that time cell is marked as a valid call time cell; otherwise, it is an invalid time cell. Taking applicant A4 as an example, if A4 initiates API calls at 09:23 and 09:51 within a one-hour interval, that time cell is marked as a valid call time cell for A4; if there are also API calls within adjacent one-hour intervals, that time cell is also marked as valid. After classifying all timestamps within the preset duration, the call time cell distribution for A4 is obtained, which is the set of all valid call time cells for A4 within the preset duration.

[0053] Third, the platform compares the call time grid distribution between all applicants pairwise, counts the number of time grids in which both applicants have valid call records within the same time grid, and calculates the call synchronization ratio R. The formula for calculating the call synchronization ratio R is as follows: ; The meanings of the parameters in the formula are as follows: This refers to the number of time frames in which both applicants have valid call records within the same time frame. The total number of valid time slots for applicant P. Let Q be the total number of valid time slots for the applicant Q, and min() is the function to find the minimum value. , , All are pure count values. The synchronization ratio R is a dimensionless ratio, ranging from 0 to 1. The closer R is to 1, the more consistent the timing patterns of the interface call behaviors of the two request entities. (The min( , The denominator is used to measure the degree of synchronization from the perspective of the less active party, so as to avoid underestimating the actual degree of collaboration due to the large difference in the call frequency between the two parties.

[0054] Taking this embodiment as an example, the interface call records of applicants A4 and I1 over the past 30 days are statistically analyzed: A4 has a total of 5 valid time slots, and I1 has a total of 5 valid time slots. Both have a number of time slots with valid call records within the same time slot. There are 4. Substituting into the formula, we get 0.8. Assuming the preset synchronization ratio threshold is 0.6, then 0.8 > 0.6, and applicant I1 is merged into the third subject group. After merging into the target subject group, the target subject group is updated to {A1, A2, A3, A4, I1}. The preset synchronization ratio threshold is set by the platform based on historical experience. Taking 0.6 as an example, it can actually be adjusted between 0.5 and 0.9 according to business needs. A threshold that is too high increases the risk of missed detections, while a threshold that is too low increases the risk of false positives.

[0055] In the aforementioned platform scenario, applicant I1 is nominally an independent applicant with no explicit equity or network domain affiliation to A4. However, its API call synchronization ratio reaches 0.8, indicating that it may be subject to scheduling by the same organization or share the same data collection strategy. By identifying and merging I1 based on the call synchronization ratio, previously uncaptured behavioral collaborations were supplemented, further enhancing the completeness of target entity group identification and effectively improving data security.

[0056] In one feasible implementation, the method further includes: obtaining the target road segment range in the authorization applications of any two applicants whose call synchronization ratio is greater than a preset synchronization ratio threshold; determining whether there are adjacent road segments on the highway network according to the connectivity of the highway network; and merging the applicants corresponding to the two target road segment ranges into a third subject group when there are adjacent road segments.

[0057] Building upon the synchronization ratio screening, spatial dimension verification is added. For applicant pairs (P, Q) whose synchronization ratio exceeds a preset threshold, further examination is conducted to determine whether their target road segments are adjacent in the highway network topology. Adjacent road segments refer to situations where each of the two target road segments directly shares the same node in the highway network topology, either being connected end-to-end or intersecting at the same node. Only when the synchronization ratio exceeds the threshold and both conditions of adjacent target road segments are met simultaneously is the applicant pair merged into the third subject group. This dual independent evidence of behavioral temporal synchronization and geospatial continuity enhances the reliability of the merging decision and reduces the false identification rate caused by accidental temporal synchronization.

[0058] The method for finding adjacent road segments is as follows: the platform obtains the set of nodes involved in all road segments corresponding to the range of two target road segments from the pre-maintained highway network topology database. If the intersection of the two node sets is not empty, it is determined that there are adjacent road segments between them. Taking the applicants I1 and A4 in this embodiment as an example: the node set corresponding to the target road segment R8 of I1 is {N8, N9}, and the node set corresponding to the target road segment R7 of A4 is {N7, N8}. The intersection of the two sets is {N8}, which is not empty, that is, R7 and R8 share the node N8. It is determined that there are adjacent road segments, the additional condition in step three is met, and I1 is merged into the third subject group.

[0059] In the above platform scenario, the R8 segment (N8-N9) of I1 and the R7 segment (N7-N8) of A4 are connected end to end on the highway network, sharing node N8. Combined with the call synchronization ratio of 0.8, the collaborative intention of I1 and A4 is jointly corroborated from two independent dimensions of temporal behavior and spatial segment, making the delineation of the target subject group more reliable and further enhancing the effectiveness of the aggregation risk assessment.

[0060] S130. Based on the connectivity of the highway network, the road segment ranges of each applicant in the target subject group are spliced ​​together to obtain a road network map.

[0061] The target subject group is {A1, A2, A3, A4, I1}. The road segment ranges of all applicants within the target subject group are spatially stitched together to comprehensively display the overall geographic spatial range covered by the associated applicants.

[0062] The platform extracts all road segments for each applicant within the target subject group, resulting in a road segment set {R1, R2, R3, R4, R5, R6, R7, R8}. The platform checks in the highway network topology database whether any two road segments in this set share a node: R1 (N1-N2) and R2 (N2-N3) share node N2; R2 (N2-N3) and R3 (N3-N4) share node N3; R4 (N4-N5) and R5 (N5-N6) share node N5; R6 (N6-N7) and R7 (N7-N8) share node N7; R7 (N7-N8) and R8 (N8-N9) share node N8; non-adjacent road segment pairs (such as R1 and R5) do not share nodes. After integrating all connectivity relationships, the road network map covers the node set {N1, N2, N3, N4, N5, N6, N7, N8, N9} and the road segment set {R1, R2, R3, R4, R5, R6, R7, R8}, forming a continuous road segment chain extending from N1 to N9. This fully presents the overall road network coverage of the five related applicant entities and reveals the potential intention of continuous road segment coverage behind the dispersed applications.

[0063] S140. Determine the union of data types for the same authorization period based on the authorization applications associated with the road segment range of the road network map. When the union of data types includes road condition data type, vehicle data type and accident data type, merge all authorization applications associated with the target subject group into a joint application.

[0064] The platform aggregates the authorization applications of all applicants in the target subject group according to the authorization period; the platform takes the union of the highway data types of all applicants in the same authorization period to obtain the data type union; when the data type union contains road condition data type, vehicle data type and accident data type, the platform triggers the aggregation risk joint review mechanism to merge all authorization applications associated with the target subject group into a joint application.

[0065] The data type union operation employs standard set union: it merges the sets of highway data types applied for by each applicant within the same authorization period, removing duplicate elements. Taking this embodiment as an example, within authorization period T1, the sets of highway data types applied for by each applicant are: SA1 = {road condition data type}, SA2 = {vehicle data type}, SA3 = {accident data type}, SA4 = {road condition data type}, SI1 = {road condition data type}. After performing the set union operation and removing duplicates, the result S = {road condition data type, vehicle data type, accident data type}. All three types of highway data types are included in S, triggering the aggregation risk joint review mechanism, merging the authorization applications of the five applicants into a joint application. The joint application represents the overall authorization request initiated by the target subject group as a unified authorization subject to the data provider, and all subsequent reviews are based on the joint application.

[0066] The logic behind triggering the joint application is that road condition data, vehicle data, and accident data, after being correlated and integrated, can reconstruct a high-value comprehensive traffic profile. The overall data sensitivity far exceeds the expectations of each individual authorization, corresponding to the distributed data puzzle risk scenario of the technical scenario, thus requiring joint review.

[0067] S150. Using the union of road segment ranges and data types in the road network map as the fine-grained authorization boundary, the fine-grained authorization boundary and joint application are submitted to the data provider for initiating a multi-party review.

[0068] In one feasible implementation, the fine-grained authorization boundary is defined by the union of road segment ranges and data types in the road network map. This includes: extracting highway data types from the authorization applications of each applicant within the target subject group; combining the highway data types with the road segment ranges and authorization time periods of the corresponding authorization applications to obtain individual authorization entries, each individual authorization entry including the road segment ranges and highway data types corresponding to different authorization time periods accessible to the applicant; and summarizing the individual authorization entries of all applicants within the target subject group into an authorization entry set, using the road segment ranges and highway data types corresponding to all authorization time periods in the authorization entry set as the fine-grained authorization boundary.

[0069] The process of constructing fine-grained authorization boundaries is as follows: The platform extracts highway data types from the authorization applications of each applicant within the target subject group, combines the highway data types with the road segment range and authorization time period of the corresponding authorization application to obtain the individual authorization entries of the applicant; the platform summarizes the individual authorization entries of all applicants into an authorization entry set; and uses the road segment range and highway data types corresponding to all authorization time periods in the authorization entry set as the fine-grained authorization boundaries.

[0070] A single authorization entry is a fine-grained authorization record extracted from an authorization application by a single applicant. It is formatted as a combination of four elements: applicant identifier, authorization period, road segment range set, and highway data type. Taking this embodiment as an example, the summarized set of authorization entries is shown in Table 1: Table 1. Set of Authorized Entries

[0071] The node interval data in Table 1 corresponds to the node intervals of the authorized road segments of each applicant in step S140 within the highway network. After aggregating all five individual authorization entries from Table 1, the fine-grained authorization boundary includes the following: the road segment range is R1 to R8, i.e., all road segments covered by the road network map in step S140; the highway data type is the combination of road condition data type, vehicle data type, and accident data type, i.e., the data type union in step S150; and the authorization time period is T1.

[0072] Furthermore, the fine-grained authorization boundaries also include the mapping relationship between each road segment and its corresponding highway data type: R1 and R2 correspond to road condition data types (from A1), R3 and R4 correspond to vehicle data types (from A2), R5 and R6 correspond to accident data types (from A3), R7 corresponds to road condition data types (from A4), and R8 corresponds to road condition data types (from I1). This mapping relationship is a key basis for data providers to determine the scope of review during multi-party review and approval.

[0073] In the aforementioned platform scenario, fine-grained authorization boundaries enable each data provider to clearly see the actual scale of data requested by the overall related applicant entities, rather than just seeing the single-dimensional data requested by each applicant entity. This effectively avoids the risk of over-authorization due to incomplete information and safeguards the legitimate right of data providers to make fully informed authorization decisions.

[0074] In one feasible implementation, fine-grained authorization boundaries and joint applications are submitted to the data provider for initiating multi-party review, including: The joint application and fine-grained authorization boundaries are simultaneously sent to each data provider. Each data provider identifies the road segments that simultaneously exist within the fine-grained authorization boundaries and the range of data it holds as review road segments. The highway data types and authorized time periods corresponding to the review road segments within the fine-grained authorization boundaries are defined as the review scope for each data provider. Each data provider compares the highway data types and authorized time periods in the review scope item by item with the range of highway data types and authorized time periods of its own data. When all highway data types in the review scope are within the range of highway data types of the corresponding data provider and all authorized time periods are within the range of authorized time periods of the corresponding data provider, the data provider returns a signature confirmation for the joint application to the platform and writes the signature confirmation and signature timestamp to the blockchain audit log. Otherwise, it returns a signature rejection to the platform and writes it to the blockchain audit log. Signature rejection includes authorized time periods that exceed the range of authorized time periods and highway data types that exceed the range of highway data types.

[0075] Before the multi-party review and approval process, the platform identifies the data providers who should participate in the review by comparing the road segment range covered by the fine-grained authorization boundary with the road segments held by each data provider in the data provider registry. The data provider registry records the road segment range, authorized highway data types, and authorized time periods for each data provider, as shown in Table 2. Table 2 Data Provider Registry

[0076] In Table 2, each data provider holds different road segments, covering different types of highway data and authorized time periods.

[0077] Figure 3 This illustration shows a schematic diagram of a multi-party review process provided in one embodiment of this application.

[0078] The specific process for multi-party review and approval is as follows: Figure 3 As shown, the process includes the following steps: S21: The platform will simultaneously send the joint application and fine-grained authorization boundaries to the three data providers, D1, D2, and D3, in a standardized data packet format.

[0079] S22: Each data provider takes the intersection of the set of road segments {R1 to R8} in the fine-grained authorization boundary with its own held road segments to determine the road segments to be reviewed. D1 holds road segments {R1, R2, R3, R4}, and the road segments to be reviewed are {R1, R2, R3, R4}; D2 holds road segments {R5, R6, R7}, and the road segments to be reviewed are {R5, R6, R7}; D3 holds road segments {R8}, and the road segments to be reviewed are {R8}.

[0080] S23: Each data provider, based on the road segment-data type mapping in Table 1, extracts the highway data type and authorized time period corresponding to the road segment to be reviewed, and determines the scope to be reviewed. Road segment D1 is reviewed for road condition data types (R1, R2 from A1) and vehicle data types (R3, R4 from A2), with an authorized time period of T1; road segment D2 is reviewed for accident data types (R5, R6 from A3) and road condition data types (R7 from A4), with an authorized time period of T1; road segment D3 is reviewed for road condition data types (R8 from I1), with an authorized time period of T1.

[0081] S24: Each data provider will compare each type of highway data in the scope to be reviewed with its own authorized highway data types, and compare the authorized time period T1 to be reviewed with its own authorized time period range.

[0082] Taking D1 as an example: The types to be reviewed are road condition data type and vehicle data type, both of which belong to the authorized types of D1 {road condition data type, vehicle data type}, and the comparison is successful; the authorized time period T1 to be reviewed belongs to the authorized time period range of D1 {T1, T2, T3}, and the comparison is successful; both comparisons are successful, so D1 will proceed to S26. The types to be reviewed for D2 are accident data type and road condition data type, both of which belong to the authorized types of D2 {accident data type, road condition data type}, and T1 belongs to the authorized time period of D2 {T1, T2}, and the comparison is successful, so D2 will proceed to S26. The road condition data type to be reviewed for D3 belongs to the authorized types of D3 {road condition data type}, and T1 belongs to the authorized time period of D3 {T1, T2}, and the comparison is successful, so D3 will proceed to S26.

[0083] S25: Each data provider determines whether all comparison results pass. In this embodiment, if D1, D2, and D3 all pass, proceed to S26. If any comparison fails, proceed to S27.

[0084] S26: When all comparisons pass, the data provider returns a signature confirmation to the platform and writes the signature confirmation and signature timestamp to the blockchain audit log.

[0085] S27: When a certain type of highway data or authorized time period exceeds the scope that the data provider can authorize, the data provider returns a signing rejection to the platform. The signing rejection includes a description of the specific highway data type or authorized time period that exceeds the scope of authorization, and the signing rejection and signing timestamp are written to the blockchain audit log.

[0086] In one embodiment, if the only authorizable time period for D2 is T2 (excluding T1), then the comparison of D2 with the authorizable time period T1 fails, and D2 returns a signing rejection to the platform. The rejection includes a statement that the authorizable time period T1 exceeds the range of D2's authorizable time periods. In this case, the judgment result of S28 is negative, triggering S29b: the generation of authorization contracts for all applicants within the target subject group is frozen. The platform writes the frozen status and signing rejection to the blockchain audit log and feeds back the rejection content to the applicant. The applicant can adjust the authorization time period according to the rejection content, such as changing it to T2 and re-initiating multi-party signing review until all data providers sign and confirm.

[0087] S28: As Figure 3 As shown, the execution results of S26 and S27 are merged and flow into the S28 judgment node. The platform summarizes the signing results of all data providers and determines whether all data providers have returned signature confirmation. If all confirmations are received, S29a is executed; if any returns a signature rejection, S29b is executed.

[0088] S29a: After all data providers have signed and confirmed, proceed to step seven to generate authorization contracts for each applicant.

[0089] S29b: When any data provider signs a rejection, the authorization contract generation of all applicant entities within the target entity group is frozen, and the frozen status and the signing rejection are written to the blockchain audit log.

[0090] In this embodiment, the review road sections, the types of highway data to be reviewed, and the signing results for each data provider are shown in Table 3: Table 3. Results of Multi-Party Review and Approval

[0091] The blockchain audit log is implemented using a permissioned blockchain. Each log record includes the data provider's identifier, joint application number, signing result, signing timestamp, and SHA-256 hash digest of the above content. The immutability of the blockchain ensures the authenticity of the audit records, providing credible evidence for post-event compliance review and dispute arbitration.

[0092] In the aforementioned platform scenarios, the multi-party signing mechanism ensures that each data provider makes an independent authorization decision based on fine-grained authorization boundaries, safeguarding the legitimate rights and interests of data providers to make authorization decisions in a state of informed consent, preventing the circumvention of the data provider's right to know by decentralized application strategies, and providing credible evidence for full-process compliance management through blockchain audit logs.

[0093] S160. After all data providers have completed signing the joint application based on fine-grained licensing boundaries, a licensing agreement is generated for each applicant entity within the target entity group.

[0094] In one feasible implementation, after all data providers have completed signing the joint application based on fine-grained licensing boundaries, a licensing agreement is generated for each applicant entity within the target entity group, including: When any data provider returns a rejection for signing, the generation of authorization contracts for all applicants within the target subject group is frozen, and the frozen status and rejection for signing are written to the blockchain audit log; after all data providers return a confirmation for signing, an authorization contract is generated separately for each applicant within the target subject group, based on the individual authorization entry of each applicant.

[0095] When any data provider returns a rejection for signing, the generation of authorization contracts for all applicants within the target subject group is frozen. The platform writes the frozen status and the rejection to the blockchain audit log, and the authorization process is suspended. Applicants can adjust their authorization applications based on the specific out-of-scope content included in the rejection and resubmit them for review. Once all data providers return confirmation for signing, the platform generates a separate authorization contract for each applicant based on the individual authorization entries for each applicant within the target subject group as shown in Table 1. Each authorization contract clearly records the specific road segment range, highway data type, and authorized time period authorized to the applicant.

[0096] The authorization contract is essentially a digital file recording the authorization elements. Each contract includes a contract number, applicant identifier, authorized road segment scope, road data type, authorization period, contract generation timestamp, and a list of signature confirmation records from all data providers, including signature timestamps from each party and a blockchain log index. The contract generation freeze mechanism ensures that high-risk data combinations cannot form a valid authorization until all data providers approve, preventing aggregated risk data from circumventing overall risk control through partial authorization.

[0097] Taking this embodiment as an example, after D1, D2, and D3 have all returned signed confirmations, the platform generates five authorization contracts based on the five individual authorization items in Table 1: Authorization contract A1 (Road segments R1 and R2, road condition data type, authorization period T1); Authorization contract A2 (Road segments R3 and R4, vehicle data type, authorization period T1); Authorization contract A3 (Road segments R5 and R6, accident data type, authorization period T1); Authorization contract A4 (Road segment R7, road condition data type, authorization period T1); and Authorization contract I1 (Road segment R8, road condition data type, authorization period T1). The scope of each authorization contract precisely corresponds to the individual authorization items of each applicant, achieving comprehensive control over overall joint risks while ensuring the legitimate use rights of each applicant within their respective authorization scope.

[0098] In the aforementioned platform scenario, the combination of the contract generation and freezing mechanism and the individual authorization mechanism for each applicant effectively prevents related applicants from circumventing overall risk review by splitting applications. At the same time, it ensures that each compliant applicant can obtain accurate authorization based on a legitimate application, achieving an organic unity between overall security control and refined individual authorization. This forms a complete compliant closed loop for multi-entity highway data circulation authorization, significantly improving the data security protection effect in multi-entity authorization scenarios.

[0099] As can be seen from the above, this application identifies related applicant entities from multiple dimensions, including equity association, network ownership, interface call behavior synchronization, and road segment spatial connectivity. It then constructs a target entity group for overall aggregation risk assessment, uses the union of road network maps and data types to build fine-grained authorization boundaries, drives a multi-party review mechanism, and generates precise authorization contracts for each applicant entity after all data providers have signed and confirmed them, forming a complete closed loop for the approval of multi-entity highway data circulation contracts. This application effectively solves the technical problem of insufficient overall security risk assessment capability of existing compliance approval mechanisms in multi-entity authorization scenarios. It provides a targeted technical solution for platform enterprises implementing distributed data mapping through an ecosystem partner matrix, significantly improving the security of highway data circulation.

[0100] Figure 4 This application provides a schematic diagram of a specific implementation of a highway data circulation contract approval system based on multi-party countersigning and fine-grained authorization, as illustrated in the embodiments of this application. Figure 4 The system may include: The acquisition module 410 is used to acquire the equity relationship diagram among multiple applicant entities, as well as the network transmission information and authorization application of each applicant entity. The authorization application includes highway data types and road segment ranges for different authorization periods. The highway data types include at least one of road condition data types, vehicle data types and accident data types. The merging module 420 is used to merge the applicant entities corresponding to all nodes that have a connection path with the same node into a first subject group based on the equity relationship diagram. The network transmission information is analyzed for network affiliation, and the applicant entities belonging to the same network domain are merged into a second subject group and then merged with the first subject group into a target subject group. The splicing module 430 is used to splice the road segment ranges of each applicant in the target subject group to obtain a road network map according to the connectivity of the road network. The merging module 420 is also used to determine the union of data types for the same authorization period based on the authorization applications associated with the road segment range of the road network map. When the union of data types includes road condition data types, vehicle data types and accident data types, all authorization applications associated with the target subject group are merged into a joint application. The review module 440 is used to submit the fine-grained authorization boundary and joint application to the data provider for initiating a multi-party review by using the union of the road segment range and data type of the road network map as the fine-grained authorization boundary. The review module 440 is also used to generate authorization contracts for each applicant entity within the target entity group after all data providers have completed signing the joint application based on fine-grained authorization boundaries.

[0101] The highway data circulation contract approval system based on multi-party countersigning and fine-grained authorization in this application embodiment is used to implement the aforementioned highway data circulation contract approval method based on multi-party countersigning and fine-grained authorization. Therefore, the specific implementation of the highway data circulation contract approval system based on multi-party countersigning and fine-grained authorization can be found in the embodiment section of the highway data circulation contract approval method based on multi-party countersigning and fine-grained authorization above. The specific implementation can be referred to the description of the corresponding embodiments, and will not be repeated here.

[0102] Figure 5 A schematic diagram of the hardware structure of an electronic device provided in one embodiment of this application is shown.

[0103] The electronic device may include a processor 510 and a memory 520 storing computer program instructions.

[0104] Specifically, the processor 510 may include a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0105] Memory 520 may include mass storage for data or instructions. For example, and not limitingly, memory 520 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, memory 520 may include removable or non-removable (or fixed) media. Where appropriate, memory 520 may be internal or external to the integrated gateway disaster recovery device. In a particular embodiment, memory 520 is non-volatile solid-state memory.

[0106] Memory may include read-only memory (ROM), random access memory (RAM), disk storage media devices, optical storage media devices, flash memory devices, and electrical, optical, or other physical / tangible memory storage devices. Therefore, typically, memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the method according to the first aspect of this disclosure.

[0107] The processor 510 reads and executes computer program instructions stored in the memory 520 to implement any of the highway data circulation contract approval methods based on multi-party countersigning and fine-grained authorization in the above embodiments.

[0108] In one example, the electronic device may also include a communication interface 530 and a bus 540. Wherein, such as Figure 5 As shown, the processor 510, memory 520, and communication interface 530 are connected through bus 540 and complete communication with each other.

[0109] The communication interface 530 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application.

[0110] Bus 540 includes hardware, software, or both, that couples components of an online data traffic metering device together. For example, and not limitingly, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), HyperTransport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, bus 540 may include one or more buses. Although specific buses are described and illustrated in embodiments of this application, any suitable bus or interconnect is contemplated herein.

[0111] The electronic device can execute the highway data circulation contract approval method based on multi-party countersigning and fine-grained authorization in the embodiments of this application, thereby realizing the highway data circulation contract approval method based on multi-party countersigning and fine-grained authorization described in conjunction with the accompanying drawings.

[0112] It should also be noted that the exemplary embodiments mentioned in this application describe methods or systems based on a series of steps or apparatus. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0113] The aspects of this application have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by dedicated hardware performing the specified functions or actions, or can be implemented by a combination of dedicated hardware and computer instructions.

[0114] The foregoing has provided a detailed description of the highway data circulation contract approval method, system, electronic device, and storage medium based on multi-party countersigning and fine-grained authorization provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and its core ideas. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of this application.

Claims

1. A method for approving highway data circulation contracts based on multi-party countersigning and fine-grained authorization, characterized in that, include: Obtain an equity relationship diagram among multiple applicant entities, as well as network transmission information and authorization applications for each applicant entity. The authorization applications include highway data types and road segment ranges for different authorization periods. The highway data types include at least one of road condition data types, vehicle data types, and accident data types. Based on the equity association diagram, all applicants corresponding to nodes that have a connection path to the same node are grouped into a first subject group. The network transmission information is analyzed for network affiliation. Applicants belonging to the same network domain are grouped into a second subject group and then combined with the first subject group to form a target subject group. Based on the connectivity of the highway network, the road segment ranges of each applicant in the target subject group are spliced ​​together to obtain a road network map; Based on the road segment range associated with the authorization applications in the road network map, determine the union of data types for the same authorization period. When the union of data types includes road condition data types, vehicle data types, and accident data types, merge all authorization applications associated with the target subject group into a joint application. Using the road segment range of the road network map and the union of the data types as the fine-grained authorization boundary, the fine-grained authorization boundary and the joint application are submitted to the data provider for initiating a multi-party review. After all data providers have signed the joint application based on the fine-grained licensing boundaries, licensing contracts are generated for each applicant entity within the target entity group.

2. The method according to claim 1, characterized in that, Before stitching together the road segment ranges of each applicant in the target subject group to obtain a road network map according to the connectivity of the road network, the method further includes: Obtain the interface call records initiated by each of the multiple applicant entities to the platform within a preset time period before the current authorization application submission time. The interface call records include the interface call timestamp of each applicant entity. The timestamps of each applicant's API call are assigned to corresponding time slots according to preset time intervals, resulting in the call time slot distribution for each applicant. The call time grid distribution of any two applicants among the multiple applicants is compared grid by grid. The number of time grids in which the interface call record exists for both applicants in the same time grid is counted. The total number of time grids of the applicant with the smaller total number of time grids among the two applicants is recorded as the base total number of time grids. The ratio of the number of time grids to the base total number of time grids is calculated to obtain the call synchronization ratio between the two applicants. The applicants whose call synchronization ratio is greater than the preset synchronization ratio threshold are grouped into a third subject group, and the third subject group is then incorporated into the target subject group.

3. The method according to claim 2, characterized in that, The method further includes: Obtain the target road segment range in the authorization applications of any two applicants whose call synchronization ratio is greater than a preset synchronization ratio threshold; Based on the connectivity of the highway network, determine whether there are adjacent road segments on the highway network for the two target road segments. If there are adjacent road segments, merge the applicants corresponding to the two target road segments into the third subject group.

4. The method according to claim 1, characterized in that, The equity relationship graph uses each applicant as a node and the equity holding relationship between the applicants as directed edges, with the direction of the directed edges pointing from the held entity to the holding entity. Based on the equity association diagram, the applicants corresponding to all nodes that have a connection path to the same node are grouped into a first entity group, including: Starting from each node in the equity relationship diagram, each node that directly or indirectly holds shares is determined sequentially along the directed edge direction to obtain the control chain of each node; The applicants corresponding to the starting nodes of any two of the holding links that have a common node are placed into the first subject group.

5. The method according to claim 1, characterized in that, The network transmission information includes the data access address and data return address of each applicant entity; The step of performing network attribution analysis on the network transmission information, grouping applicants belonging to the same network domain into a second subject group, and then combining this second subject group with the first subject group to form a target subject group, includes: The data access address and data return address of each applicant are compared with the address range corresponding to each network domain preset in the platform. Applicants whose data access address and data return address both fall within the same address range are placed in the second subject group; The first subject group and the second subject group are combined into the target subject group.

6. The method according to claim 1, characterized in that, The use of the union of the road segment range of the road network map and the data type as the fine-grained authorization boundary includes: Extract the highway data type from the authorized application of each applicant within the target subject group; The highway data type is combined with the road segment range and authorization time period corresponding to the authorization application to obtain a single authorization entry. The single authorization entry includes the road segment range and highway data type corresponding to different authorization time periods accessible to the applicant. The individual authorization entries of all applicants within the target subject group are aggregated into an authorization entry set, and the road segment range and highway data type corresponding to all authorization time periods in the authorization entry set are used as the fine-grained authorization boundary.

7. The method according to claim 6, characterized in that, The step of submitting the fine-grained authorization boundaries and the joint application to the data provider for initiating a multi-party review includes: The joint application and the fine-grained authorization boundary are sent synchronously to each data provider. Each data provider determines the road segment that exists simultaneously in the fine-grained authorization boundary and the range of road segments it holds as the review road segment. The type of highway data and the authorization period corresponding to the review road segment in the fine-grained authorization boundary are determined as the review range of each data provider. Each data provider will compare the highway data types and authorized time periods in the scope to be reviewed with the highway data types and authorized time periods of the data they hold. When all highway data types within the scope to be reviewed are within the range of highway data types of the corresponding data provider and all authorized time periods are within the range of authorized time periods of the corresponding data provider, the data provider returns a signature confirmation for the joint application to the platform and writes the signature confirmation and signature timestamp to the blockchain audit log; otherwise, it returns a signature rejection to the platform and writes it to the blockchain audit log. The signature rejection includes authorized time periods that exceed the range of authorized time periods and highway data types that exceed the range of highway data types.

8. The method according to claim 7, characterized in that, The process of generating licensing contracts for each applicant within the target entity group after all data providers have signed the joint application based on the fine-grained licensing boundaries includes: When any data provider returns a signing refusal, the authorization contracts of all applicants within the target subject group are frozen, and the frozen status and the signing refusal are written to the blockchain audit log; After all data providers return signed confirmations, an authorization contract is generated separately for each applicant within the target subject group, based on the individual authorization entries for each applicant.

9. A highway data circulation contract approval system based on multi-party countersigning and fine-grained authorization, characterized in that, include: The acquisition module is used to acquire the equity relationship diagram among multiple applicant entities, as well as the network transmission information and authorization application of each applicant entity. The authorization application includes highway data types and road segment ranges for different authorization periods. The highway data types include at least one of road condition data types, vehicle data types, and accident data types. The merging module is used to merge the applicant entities corresponding to all nodes that have a connection path with the same node into a first entity group based on the equity association diagram. It is also used to perform network affiliation analysis on the network transmission information, merge the applicant entities belonging to the same network domain into a second entity group, and then merge them with the first entity group into a target entity group. The splicing module is used to splice the road segment ranges of each applicant in the target subject group according to the connectivity of the highway network to obtain a road network map; The merging module is also used to determine the union of data types for the same authorization period based on the authorization applications associated with the road segment range of the road network map. When the union of data types includes road condition data type, vehicle data type and accident data type, all authorization applications associated with the target subject group are merged into a joint application. The review module is used to submit the fine-grained authorization boundary and the joint application to the data provider for initiating a multi-party review by using the road segment range of the road network map and the union of the data types as the fine-grained authorization boundary. The review module is also used to generate authorization contracts for each applicant entity within the target entity group after all data providers have completed signing the joint application based on the fine-grained authorization boundaries.

10. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the steps of the method as described in any one of claims 1 to 7.

Images